[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/gotchas.md

@@ -1421,6 +1421,40 @@ for h in resp.points:    # ← .points không phải iterable trực tiếp
 
 **Luật:** thấy `Msg 5118` / RECOVERY_PENDING sau sự cố disk ⇒ **`compact <file>` kiểm cờ nén TRƯỚC** khi nghĩ tới restore backup; và **CẤM bật compression trên cây thư mục SQL DATA** (freeing-space bằng nén = bẫy hẹn giờ cho mọi DB đang offline/detached). Bonus bảo mật lộ ra cùng lượt đọc errorlog: port 1433 phơi Internet, `sa` bị brute-force liên tục từ IP lạ — vá firewall riêng.
 
+### 89. Cache của AUTOMATION phình vô hình ăn sạch ổ C → SQL Error -2 — triệu chứng đội lốt lỗi DATA (Session 189)
+
+**Triệu chứng:** UAT anh Kiệt: phiếu *"ko duyệt được"* rồi *"Giờ nó ko tìn thấy phiếu"* (A/059 hiện trong cây, panel đỏ "Không tìm thấy phiếu."). Đo: `fsutil` free = **−20.189.184 byte** (âm vào 5GB reserve); log `[ERR] Microsoft.Data.SqlClient … OpenAsync … Error Number:-2` + `SlaExpiryJob/ItTicketSlaJob iteration failed`; file log Serilog hôm trước **biến mất** (đợt "giải phóng dung lượng" quét — cùng đợt NÉN file .mdf template, vân tay #88).
+
+**Cơ chế:** 2 kho **cache của máy móc** phình theo NHỊP CI chứ không theo hành vi người dùng nên không ai thấy: `C:\gitea\data\repo-archive` **16,49GB** (ZIP sinh mỗi lần tải archive — cache thuần, Gitea tự tái tạo; cron `archive_cleanup` CHƯA bật) + `npm-cache` của SYSTEM **12,76GB** (`System32\config\systemprofile\AppData\Local` — CI build FE chạy dưới SYSTEM, tích từ tháng 4). Disk 0 byte → SQL không cấp phát/grow được → **lệnh GHI chết trước** ("ko duyệt được"), query nặng chết theo (GET detail 500), query nhẹ lúc được lúc không → FE gom mọi nhánh lỗi vào **"Không tìm thấy phiếu"** (#44) ⇒ người dùng lẫn người chẩn đoán **nghi oan phiếu/DB** trong khi phiếu còn nguyên (Phase=ChoDuyet, workflow sống).
+
+**Fix (S189):** xóa `repo-archive\*` (an toàn — cache) + npm-cache + 567 `u_ex*.log` >30 ngày → free 20GB+; `ALTER DATABASE … SET AUTO_CLOSE OFF` ×3 DB (ON = mỗi connection mở lại DB ~5s — đo `COUNT(*)` 1 dòng mất 5.420ms); FE tách "404 thật ⟂ lỗi hệ thống + nút thử lại" 5 site ×2 app (`lib/apiError.ts isNotFound`). **Guard đã wire:** runbook §"Disk-free + orphan guard" + `cicd-monitor` bước 1b (`fsutil` free <5GB = FAIL). **TODO ngoài giờ:** bật `[cron.archive_cleanup]` Gitea (restart service dùng chung VIETREPORT) + `compact /u` `Vietreport_Master.mdf` (đang mở, cần OFFLINE ~10s).
+
+**Luật:** prod "chậm / không thấy / không lưu được" ⇒ **`fsutil volume diskfree C:` TRƯỚC** khi nghi data hay code — thông điệp UI chỉ là lớp vỏ (#44); và **cache của automation phải có vòng dọn tự động**, không có thì nó là bom hẹn giờ đúng nghĩa.
+
+### 90. `ssh … | head` cắt pipe → process Windows-OpenSSH MỒ CÔI spin full core — người chẩn đoán tự làm bẩn hiện trường (Session 189)
+
+**Triệu chứng:** SAU khi dọn đĩa xong server **vẫn** chậm (anh: *"vẫn ko tải phiếu lên đc, vẫn chậm lắm"*): GET detail MỌI phiếu 5-15s, A/059 (5 NCC) 500-sau-29,8s ×3 lần `"A task was canceled"`, curl chờ được thì 200 sau 47,6s. SQL khai: `wait_type=ASYNC_NETWORK_IO, wait_time=3ms, elapsed=29s` — CPU query chỉ **66ms**, reads ~1.500 ⇒ **SQL xong việc từ lâu, client không nhận nổi data**. CPU-delta 5 giây: **3 process `sshd` = 10,6+10,5+10,5 core-giây trên máy 3 core** = bão hòa 100%.
+
+**Cơ chế:** lệnh dạng `ssh vps '…quét nặng…' | head -N` phía local đóng pipe sau N dòng → ssh client thoát, **nhưng sshd + lệnh phía Windows-OpenSSH KHÔNG chết** — spin trọn core vô hạn. 3 lượt quét-đo bị cắt = 3 orphan = w3wp đói CPU → materialize kết quả SQL chậm ×100 → mọi API rùa → request vượt trần hủy ~30s → 500 → FE "Không tìm thấy phiếu" **tiếp**, dù gốc disk đã chữa. Người chẩn đoán tự tạo ra tầng bệnh thứ hai bằng chính công cụ chẩn đoán.
+
+**Fix:** kill orphan sshd — 🔴 **CHỪA chuỗi tổ tiên session đang chạy** (walk `ParentProcessId` từ `$PID` lên, kill sshd ∉ chain). Sau kill: A/059 **47s→0,38s**, phiếu bé 0,17s, inbox 0,12s — tức thì, không cần deploy gì.
+
+**Luật:** (1) cần cắt output ssh thì `Select-Object -First N` **phía REMOTE**, cấm `| head` phía local; (2) recycle app pool xong phải đợi **cold-start ~48s** rồi mới đo (đo sớm = đo app đang khởi động, ra số rác); (3) mọi op đo/quét nặng trên prod tự hỏi *"op này để lại gì sau khi tôi ngắt?"* — hiện trường bẩn làm phép đo sau nói dối.
+
+### 91. Push land trên ĐĨA nhưng tầng-app Gitea CÂM → CI không có run để mà đỏ — phát hiện bằng 2 nguồn LỆCH trong CÙNG một API (Session 189)
+
+**Triệu chứng:** push `92d8215a` terminal SẠCH (`Processed 1 references`), `git ls-remote` đúng SHA — nhưng **0 ActionRun** (0 hit trong 484 task), commit-status rỗng, bundle prod đứng im. **Mọi tín hiệu quen đều XANH**: runner `Running`, `[actions] ENABLED=true`, path-filter đúng (cặp đối chứng: `9b3c0edb` có run · `d4799ddd` WAL-only không run — filter sống), không có push đè (#86).
+
+**Phép đo tố cáo (2 nguồn trong CÙNG API Gitea):** `GET /repos/{r}/branches/main → commit.id` (đọc **git trên đĩa**) = SHA mới ⟂ `GET /repos/{r} → updated_at` (đọc **DB**) = vẫn mốc push TRƯỚC ⇒ ref tiến trên đĩa nhưng **tầng ứng dụng chưa từng thấy cú push** (nghi internal hook `post-receive` lỗi/timeout đúng thời điểm). KHÔNG phải CI fail — **CI chưa từng được gọi**. Cùng lớp `absence looks like clean`: chỉ "vắng mặt cái đáng-lẽ-phải-có" mới tố cáo.
+
+**Defect quan trắc đi kèm:** `C:\gitea\log\gitea.log` **0 byte từ 00:00** (xoay log nửa đêm xong không mở lại file) ⇒ mù server-side 11,5h đúng lúc cần chẩn. Restart service mở lại logger (31,9MB flush về).
+
+**Fix (S189):** `Restart-Service gitea` (không đụng app phiếu — eoffice/admin/api KHÔNG phụ thuộc Gitea) → `workflow_dispatch` qua API (`POST /repos/{r}/actions/workflows/deploy.yml/dispatches`, token lấy từ remote-URL local, HTTP 204) → run **#486** head đúng `92d8215a` → ship trọn (gate 680 EXACT · bundle rotate ×2 khớp CI-log từng byte · marker 10/10).
+
+**Cost của thuốc — ghi thật, không giấu dưới "transient":** restart Gitea kích **re-index ~25 phút** (317MB RSS + 512s CPU) tranh RAM/CPU với SQL trên máy 4GB/3-core → cửa sổ đo sau đó latency bimodal 0,6s ⟂ 5-8,7s (cache-miss, PLE 522s). Vá tầng RAM cùng lượt: `sp_configure 'max server memory (MB)'` từ **2147483647 (unbounded default!)** → **1200** — ăn ngay không restart, PLE hồi 1123s, A/059 về 0,58s. Máy ít RAM mà SQL unbounded = Windows với SQL giằng RAM qua lại vô hạn.
+
+**Luật:** (1) verifier tuyên "đang chờ CI" phải đo **`repo.updated_at ≥ thời-điểm-push`** trước — head khớp chưa đủ; (2) sau restart service có re-index/warm-up: **phép đo latency trong cửa sổ đó là số bẩn**, khai rõ hoặc đợi lắng; (3) SQLEXPRESS trên máy nhỏ: **pin `max server memory` ngay lúc setup** (ghi vào runbook), đừng để default unbounded.
+
 ## Checklist debug bug mới
 
 1. Build pass không? → fail → check using + package version compat