[CLAUDE] Docs: YC-028 đóng trọn — gotcha #89/#90/#91 + RCA YC028-S189 + STATUS row 88→91 + run-trace cicd 2 vòng

Sự cố prod 3 tầng (A/059 "ko tìm thấy phiếu") giải trọn trong phiên, chi tiết error-ledger RCA YC028-S189:
- T1 disk 0-byte (cache automation 30GB) → #89 · T2 orphan-sshd bão hòa 3 core (lỗi lead, tự khai) → #90
- T3 lộ khi ship: Gitea tầng-app câm nuốt push (0 run dù mọi tín hiệu xanh) → #91; restart + dispatch
  → run #486 ship trọn (gate 680 EXACT · bundle rotate ×2 · marker 10/10 — cicd-monitor 2 vòng PARTIAL 8/9)
- Vá RAM cùng lượt: sp_configure max server memory unbounded→1200MB (PLE 522→1123 · A/059 0,58s)

Sổ: +YC-028 4 tầng xử · run-trace sub-cicd-monitor-yc028.md (FAIL vòng-1 giữ nguyên làm vết,
vòng-2 append) · AS-10 cicd-monitor tự-curate memory qua Bash (persona 0 Write) = verify-KEPT
(27,4→17KB + archive/_INDEX đúng khuôn + sửa stale Mig 71→72 đúng canonical) · squash wal: theo §5.0.
Docs-only ⇒ CI skip (đã đối chứng #486 xong trước khi push — không đụng #86).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/governance/error-ledger.md

@@ -232,6 +232,20 @@ Detect by **action-signature** (NOT "AI tự phán có vi phạm không"). Scan
 
 > **Maintenance:** append RCA on each AS-hit; promote a guard to `procedural` on its 2nd strike; mark `verified` once it holds through a session; retire by net-effect. Pointer entries only — full narrative lives in session-logs (summary-index).
 
+## RCA `YC028-S189` — sự cố prod 2 tầng, tầng-2 do CHÍNH LEAD gây khi chẩn đoán (2026-08-11)
+
+**Triệu chứng:** UAT anh Kiệt (Zalo): phiếu A/059 *"ko duyệt được"* → *"Giờ nó ko tìn thấy phiếu"* + *"check kỹ tí"*; sau đợt cứu đầu anh vẫn báo *"vẫn ko tải phiếu lên đc, vẫn chậm lắm"*.
+
+**Tầng-1 (không do đội):** ổ C VPS **0 byte** (free −20MB vào reserve) — cache automation phình vô hình (`repo-archive` 16,49GB + `npm-cache` SYSTEM 12,76GB) → SQL `Error -2` → lệnh ghi/duyệt chết, FE gom mọi lỗi vào "Không tìm thấy phiếu" (#44 → gotcha **#89**). Xử: dọn ~30GB + `AUTO_CLOSE OFF` ×3 + FE tách 404⟂500 (commit `92d8215a`).
+
+**Tầng-2 (LỖI LEAD — phần phải RCA):** sau khi dọn đĩa, server VẪN chậm — vì **3 sshd mồ côi do chính các lệnh quét-đo của lead** (`ssh … | head` cắt pipe, process phía Windows-OpenSSH không chết) **bão hòa 3/3 core** → mọi GET detail 5-47s (gotcha **#90**).
+
+**5-why tầng-2:** (1) Vì sao chậm? — w3wp đói CPU, SQL `ASYNC_NETWORK_IO` chờ client. (2) Vì sao đói? — 3 sshd spin full-core. (3) Vì sao có orphan? — `| head` phía local đóng pipe sớm, ssh client thoát nhưng Windows-OpenSSH **không kill process tree**. (4) Vì sao lead không thấy sớm? — đo bằng `Get-Process` CPU **tích lũy** (thước sai — không phân biệt đang-ăn với đã-từng-ăn); chỉ khi đo **CPU-delta 5s** mới lộ. (5) Vì sao lặp ×3? — mỗi vòng quét mới lại `head`, và lead **không có phản xạ "op này ngắt rồi để lại gì?"** — người chẩn đoán tự làm bẩn hiện trường, rồi đo hiện trường bẩn và kết luận tiếp.
+
+**Fix:** kill 3 orphan (walk `ParentProcessId` CHỪA ancestor-chain của session mình) → A/059 **47s→0,38s** đo ×2 lượt + inbox 0,12s — executed+verified. **Guard:** luật #90 3 vế (Select-Object -First N phía REMOTE · đợi cold-start ~48s sau recycle · tự hỏi op-để-lại-gì) khắc gotchas + runbook §"Disk-free + orphan guard" + `cicd-monitor` bước 1b; răng thật = cicd-monitor chạy MỖI post-push.
+
+**Khai thêm 2 nhánh đúng-quy-trình đáng giữ:** lead **đã tự khai** với owner phần lỗi mình gây (không đợi bị bắt); và 2 lần bác-giả-thuyết bằng số (cartesian: đếm đủ 7 bảng mới kết luận · lock-mồ-côi: 0 session ôm transaction) tránh được 2 bản vá sai hướng (AsSplitQuery-vội · recycle-mù).
+
 ## RCA `SCORE-T2-S189` — TẦNG-2 chấm sai PHÉP ĐẾM (2026-08-11, bookstart L15)
 
 **Chấm sai — TẦNG NÀO:** **TẦNG-2** (`score-counter`). **Tầng-1 (lead) = 0 lỗi**, khớp 4/4 khoản, số tái lập được (`score-count-auditor` tự chạy lại `nhip-no-probe.ps1`, khớp verbatim; 27/27 dòng `parts=10`, 0 lệch cột). 🔴 **KHÔNG** nhét nhãn *chấm sai* vào `lead_self_audit.flag_classes` — tập ĐÃ NIÊM PHONG `_sealed_P3B_S181`, máy từ chối exit 2.