[CLAUDE] Docs: S191 closeout — vá 10 FLAG H24 + gotcha #92 đổi root-cause + RCA P0-BUNDLE + 3 action refine (A7 429→432) [skip ci]

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

docs/governance/error-ledger.md

@@ -246,6 +246,32 @@ Detect by **action-signature** (NOT "AI tự phán có vi phạm không"). Scan
 
 **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 `P0-BUNDLE-S191` — ship bundle crash runtime LẦN 2, mọi cổng đều xanh (2026-08-13, L15 w3)
+
+**AS-signature:** không khớp AS-1..AS-10 nào — **class mới**, đề xuất **AS-11: "cổng verify đo tính-chất của FILE thay cho tính-chất của CHƯƠNG TRÌNH"**.
+
+**Sự cố:** owner kiểm prod sau deploy #600 → *"Admin -> tạm ôn. eOffice -> vào trắng màn hình"*. Console: `TypeError: Cannot read properties of null (reading 'useState')` @ `index-BIN1bEGo.js:8`. Ca thứ **2** cùng chữ ký (ca-1 @S189 sau #486).
+
+**Lỗi KÉP → 2 fix (luật bug-production):**
+- **Fix CODE** (`305b573f`): `deploy.yml` thôi xoá `package-lock.json`; `npm install` → **`npm ci`** theo lockfile đã commit (lockfile tái sinh từ cây lành, bổ sung `@microsoft/signalr` + 9 transitive vốn thiếu từ 23/04).
+- **Fix GUARD**: **GUARD-92** chặn build khi React trùng bản (`npm ls react`). Fault-inject **4 ca** TRƯỚC khi push — và nó **bắt được lỗi trong chính guard**: thiếu lookbehind thì `lucide-react@1.8.0` khớp như một bản React ⇒ cây LÀNH cũng FLAG ⇒ CI đỏ vĩnh viễn. Vá `(?<![-\w./@])react@` rồi re-test 4/4 đúng chiều.
+
+**5-why:**
+1. Vì sao trắng màn? Bundle prod crash khi khởi tạo React.
+2. Vì sao bundle crash? Cây phụ-thuộc trong bundle khác cây đã chạy được ở local.
+3. Vì sao khác? CI **xoá lockfile rồi `npm install`** ⇒ resolve lại theo semver range mỗi run ⇒ cùng commit, bundle khác nhau tuỳ registry tại thời điểm build.
+4. Vì sao CI làm vậy? Comment `deploy.yml` (từ 2026-04): *"rolldown native binding must match platform; fresh resolve on Windows"* — và lockfile lúc đó **thiếu `@microsoft/signalr`** nên "xoá cho lành" **có vẻ** đúng. Thuốc đúng là **cập nhật lockfile**, không phải bỏ nó.
+5. Vì sao lọt 2 lần? Mọi cổng verify đo **FILE**: hash CI↔prod byte-match, HTTP 200, bundle rotate. **Không cổng nào đo CHƯƠNG TRÌNH CHẠY.** Byte-match giữa 2 đầu **mà cả hai đầu chưa ai chạy thử** thì hai file giống hệt nhau vẫn cùng crash.
+
+**Ca-âm nội tại — lead tự khắc SAI root-cause vào chính thuốc:** bản đầu của gotcha #92 (ghi @S191) quy nhân cho **npm-cache runner nhiễm** và kê thuốc *"dọn cache rồi mới tin build"*. `lead-stale-auditor` FLAG-1 bác: `deploy.yml:108-115` (land **12 phút sau** khi gotcha được ghi) nói rõ nguyên nhân là lockfile; và run #488 PASS **mà không ai dọn cache lần nào**. ⇒ Lead **flip được** claim "#92 đóng vì disk" nhưng **giữ nguyên** claim "cause = cache" — *sửa một phía trong cùng một hơi viết*. Đã vá trọn @close, kèm khối "giả thuyết đã BỊ BÁC" giữ cả 2 vòng làm vết.
+
+**Guard mới có RĂNG:**
+1. `deploy.yml` **`npm ci` + lockfile committed** — thay đổi này tự nó khoá tính tái lập (chứng: run #488 ra **4/4 hash trùng local** dù runner node v24.15.0/npm 11.12.1 vs local v22.13.0/npm 10.9.2 ⇒ nghi vấn "node drift là nguồn bất định thứ 2" **bị bác bằng đo**).
+2. **GUARD-92** in `GUARD-92 OK: react don ban = <ver>` mỗi build (verified 2/2 app @#488), fail build nếu ≥2 bản.
+3. **Luật #92(1)**: verify deploy FE **phải có 1 phép đo RUNTIME**. Đã thi hành @S191: sau deploy #488, load thật 2 site → console 0 lỗi, form render. Đây là **lần đầu** chuỗi *CI build → deploy → runtime verify* được nối trọn.
+
+🔸 **Nửa lỗ CÒN LẠI (khai, không giấu):** node/npm runner vẫn tự trôi. `.nvmrc`=20 **CÓ** ở `fe-*/` nhưng `deploy.yml` **0 hit** `setup-node` ⇒ ghost-wire class-2 — chờ owner quyết pin hay khai thẳng không pin.
+
 ## 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.

docs/governance/so-yeu-cau-chu-du-an.md

@@ -55,11 +55,13 @@ Dữ-liệu cũ (WAL · HANDOFF · auto-memory · migration-todos) **KHÔNG** đ
 | `YC-019` | "1 -> Tạm OK · 2 -> Role baseline + Runs · 3,4 -> giải thích · 5 -> OK kéo audit luôn giờ cứ end/start là cứ chạy · 6 -> Nợ cũ thì xử lý cho xong luôn" | 2026-08-10 · S185 | **đóng** *(6/6 vế thi hành @S185: (1) YC-013/016 đóng · (2) ring2 24.859B · (3)(4) đã giải thích → anh phán tiếp = YC-020 · (5) deep_every=1 · (6) nợ cũ đóng trọn)* | 1 | WAL chain (TASK → WAL) | 6 phán quyết một lượt: (1) acceptance 8-panel TẠM-OK ⇒ lật YC-013/016 nấc "tạm" · (2) C-6 = NÉN `Role baseline`+`Runs` của ring2 (khuôn moved-not-cut như lead-stale) · (3)(4) em giải thích W-1..W-4 + 5 SKIP-owner, chưa phán · (5) 🔴 ĐỔI NHỊP DEEP: từ nay **mỗi bookend end/start đều chạy deep** (deep_every → 1, hết chờ nhịp 15) · (6) uỷ quyền xử TRỌN nợ cũ theo bậc-2 LT3 (chọn nhánh an toàn + khai, việc-vật-lý-của-anh thì kê rõ) | |
 | `YC-024` | "(80) Đồng ý đúng, 7 loại ⏎ (81) Tức Duyệt NCC -> Chọn Duyệt NCC tạo KHKK -> KHKK (đã duyệt) -> Chọn để tạo HĐ ⏎ (82) Hiện phân quyền tất cả trước đi, sau khi ổn rồi thì phân quyền sau. ⏎ (83) Lấy tương tự như KHKK sau đó tao sẽ điều chỉnh sau, phần điều chỉnh trong Admin tao sẽ tự chủ động ⏎ (84) Đồng ý ⏎ (85) Đồng ý ⏎ (86) Đồng ý khóa cứng tương tự như KHKK và Duyệt NCC ⏎ (87) Chỗ này user có thể tự chọn KHKK cho loại Hợp đồng nào. ⏎ (88) Đồng ý ruột lấy từ các thông tin đã nhập (Có thể tham khảo 1 form Hợp đồng trước file word đã có, lấy làm mẫu trước, các thông tin đã nhập vào có thể lấy load lên, còn nếu chưa thì cho điền bổ sung, ví dụ như điều khoản)." | 2026-08-10 · S188 | **mở** | 1 | run `2026-08-10-S187-duyet-hd-tu-khkk/` spec + WAL *(thi-công → WAL)* | 9 phán quyết mở khoá plan 11-wave YC-023: (80) trục **7-LOẠI** · (81) **PA-A** + xác nhận chuỗi kế thừa PE→KHKK→HĐ · (82) *đội hiểu (bậc-2, khai)*: **MỞ TẤT CẢ trước** như posture hiện tại, phân quyền chi tiết = đợt SAU khi anh thấy ổn ⇒ **W8-authz HOÃN chờ lệnh anh**; guard đúng-trạm của máy duyệt V2 vẫn chạy (logic quy trình ≠ phân quyền) — anh bác cách hiểu thì em sửa · (83) W3 seed roster **SAO KHUÔN KHKK**, anh tự chỉnh trong Admin Designer sau ⇒ hết chặn cứng · (84) màn duyệt **2 nút** · (85) admin **giữ ẩn** ⇒ W9 HỦY · (86) **khoá cứng** quy trình theo loại, không đổi tay · (87) KHÔNG cột gợi-ý — user tự chọn loại HĐ khi tạo từ KHKK · (88) KHÔNG bảng hạng mục — **ruột HĐ pre-fill** từ dữ-liệu đã nhập + khuôn **form HĐ Word có sẵn** làm mẫu, field thiếu cho điền bổ sung (vd điều khoản) → vào W5/W6 | |
 | `YC-027` | "cái này sẽ là rules nhé, các cái command phải đc thực hiện trọn vẹn tao ko chấp nhận bất cứ 1 lý do nào" | 2026-08-10 · S188 | **mở** | 2 | 2 file lệnh + ACTIVE-MARKS (stamp chờ P4) | **NÂNG THÀNH RULE VĨNH VIỄN**: mọi command/nghi-thức (bookstart · bookend · /tiep · mọi lệnh anh gõ) phải chạy **TRỌN VẸN 100% các bước** — không vai nào được bỏ, không viện BẤT KỲ lý do nào (ngân sách · cạn context · "để lượt sau" · nghi-thức-đã-đóng). Đứt bất-khả-kháng (limit/crash) ⇒ lượt-nối đầu tiên chạy HẾT phần thiếu. Khắc vào `session-end.md` + `session-start.md` khối ONE-SHOT (trỏ YC-027/PN-001) ngay @S188; stamp User-Mark theo P4 report-before-stamp ở nhịp tới | |
-| `YC-028` | "xóa bớt 1 tý để các bạn upload load phiếu rồi tính tiếp" | 2026-08-11 · S189 | **mở** *(vế "xóa bớt" ĐÃ XONG cùng lượt; vế "tính tiếp" treo chờ anh chọn số)* | 1 | WAL (mạch sống) + `runs/2026-08-10-S189-bookstart-open/run.md` | Bối cảnh: anh Kiệt báo phiếu `PE/2026/A/059` "ko duyệt được" rồi "ko tìm thấy phiếu" — chẩn đoán ra **ổ C VPS còn 0 byte** (free âm 20MB vào reserve) ⇒ SQL connection timeout ⇒ FE vẽ mọi lỗi thành "Không tìm thấy phiếu" (#44). Đội hiểu: giải phóng đĩa NGAY bằng mục AN TOÀN nhất — đã xóa cache `gitea\data
+| `YC-028` | "xóa bớt 1 tý để các bạn upload load phiếu rồi tính tiếp" | 2026-08-11 · S189 | **mở** *(vế "xóa bớt" ĐÃ XONG cùng lượt; vế "tính tiếp" treo chờ anh chọn số)* | 1 | WAL (mạch sống) + `runs/2026-08-10-S189-bookstart-open/run.md` | Bối cảnh: anh Kiệt báo phiếu `PE/2026/A/059` "ko duyệt được" rồi "ko tìm thấy phiếu" — chẩn đoán ra **ổ C VPS còn 0 byte** (free âm 20MB vào reserve) ⇒ SQL connection timeout ⇒ FE vẽ mọi lỗi thành "Không tìm thấy phiếu" (#44). Đội hiểu: giải phóng đĩa NGAY bằng mục AN TOÀN nhất — đã xóa cache `gitea\data
+epo-archive` **16,49GB** (cache chính chủ Gitea, tự tái tạo) → free **20,1GB**, API 200/401 chuẩn, 0 ERR mới; KHÔNG đụng DB/repo/uploads. "Tính tiếp" = bảng đánh số trình anh: npm-cache SYSTEM 12,76GB · inetpub\logs 2,15GB · chống tái phát repo-archive · disk-watch · FE tách lỗi-hệ-thống ⟂ không-tìm-thấy · truy log 10/08 biến mất | |
 | `YC-026` | "ko đóng phiên với bất cứ lý do nào" | 2026-08-10 · S188 (giữa lượt chạy-bù PN-001) | **mở** | 1 | WAL (mạch sống) | Phiên/conversation này KHÔNG được kết thúc — chạy hết mọi vai + việc tồn rồi **giữ phiên mở tiếp tục nhận việc**; CẤM viện bất kỳ lý do nào (ngân sách/context/nghi-thức-đã-đóng) để dừng. *(Đội hiểu thêm: `_end` phiên-LOGIC L14 đã ghi TRƯỚC lệnh này ~15 phút — dấu frozen không gỡ được; hiệu lực thực tế = conversation tiếp tục làm việc, mạch mới ghi WAL như thường. Anh bác cách hiểu thì em sửa.)* | |
 | `YC-025` | "OK làm tiếp hết đi, xong hết tao review 1 lần luôn" | 2026-08-10 · S188 | **đóng** *(vế làm-trọn SHIP @S187-S188; vế "review 1 lần" anh THỰC HIỆN @S190 2026-08-12 trên prod → ra 5 điều chỉnh = `YC-029`)* | 1 | WAL chain (thi-công → WAL) | Làm TRỌN các wave còn lại của YC-023/024 (W3 seed 7 quy trình + key Designer → W4 guard 4-cửa → W5 card nguồn-gốc + ruột pre-fill (88) → W6 màn duyệt 2-nút + Đ2-guard → W10 dry-run toàn trình) KHÔNG dừng chờ anh nhìn prod giữa wave; gate máy + reviewer-agent per-wave GIỮ NGUYÊN; push gom 1 lượt cuối (tránh #86 + tránh bản prod trung gian); anh review MỘT LẦN trên prod khi trọn. W8 vẫn HOÃN theo (82) "phân quyền sau", W9 vẫn HỦY theo (85) | |
 | `YC-030` | "Q1 ->như KHKK ⏎ Q2 -> Chỉ select theo loại HĐ ⏎ Q3 -> Port sang luôn ⏎ Q4 -> Người tao xóa người duyệt ko đc xóa, chỉ trả lại thôi. ⏎ Q5 -> Thay luôn và mỗi loại 1 quy trình tương tự KHKK và cấu trúc duyệt và history cũng tương tư KHKK ⏎ Xong thì push và deploy lên nhé. Để tao kiểm tra" | 2026-08-12 · S190 | **mở** | 1 | run `2026-08-12-S190-soltuon-dieu-chinh-hd/` *(thi-công → WAL)* | 5 phán quyết đóng Q1-Q5 của YC-029 + lệnh deploy: **Q1** layout my-contracts về **KHKK-THUẦN** (bác nhánh hoán-đổi đã chạy: BỎ cột danh-sách thường-trực bên phải; cây trái = trục, flat-list = fallback trong CÙNG panel khi search/lọc; panel-3 = workflow+history/dashed y KhkkListPage) · **Q2** panel cây giữ **Select theo LOẠI HĐ** (trục nhóm của KHKK ⇒ trục loại của HĐ) · **Q3** PORT 3 món KHKK vào màn duyệt HĐ (ô "Cấp này KẾT THÚC" + badge "Duyệt thay CEO" + banner kết-thúc-sớm — cần nở `ContractDetail` DTO + service đọc cờ) · **Q4** *"người TẠO xóa (typo 'tao'), người DUYỆT KHÔNG được xóa — chỉ Trả lại"* = XÁC NHẬN đúng W5 đã ship (approver-delete KHÔNG BAO GIỜ mở cho HĐ — khác PE; đóng `[carry:w8-delete-policy]` vế approver) · **Q5** THAY `QT-HD-V2-001` bằng đúng 7 bản `HD-*` per-loại (data-op cả Dev lẫn prod) + cấu trúc duyệt & history màn HĐ = y khuôn KHKK (gộp Q1/Q3) · rồi **PUSH + DEPLOY prod để anh kiểm tra** (⇒ mở CỬA NGOÀI-GIỜ: dọn workspace runner vá-gốc P0 TRƯỚC push) | |
 | `YC-029` | "Thứ 1 (Ành 1): Bỏ phần này sang bên này nhé. ⏎ Thứ 2 (Ảnh 2): Điều chỉnh. ⏎ Thứ 3: Phần hợp đồng Menu đang bị lẫn lộn, click vào menu này thì nhảy sang Menu khác, điều chỉnh lại nhé. ⏎ Thứ 4: Phần thao tác, duyệt, xóa ... -> Cấu trúc tương tự như KHKK. ⏎ Thứ 5: Bên trong Admin -> Cấu hình Menu đúng chính xác cho từng loại HĐ nguyên tắc, thầu phụ -> Cấu trúc Menu tương tự giống với KHKK và Duyệt NCC (Ảnh 3) ⏎ Cho /fable-real invest và review các điều chỉnh spec, ra các wave và checklist cụ thể. ⏎ /fable-clone review lại 1 lần nữa. ⏎ /fable-real vào các vai style FE, BE -> Invest Ra cái spec list để style đồng nhất với các thiết kế đó. ⏎ /fable-clone Vai FE, BE review style -> Review lại ⏎ /fable-real tổng hợp cuối cùng ra từng wave cụ thể, sau đó ⏎ -> Sau đó Fan-out cho OPus 5 MAX xử lý toàn bộ plan, tên Plan \"SOLTUON-12-08-2026\"" *(kèm 3 ảnh prod eoffice `my-contracts?type=1` + admin Designer)* | 2026-08-12 · S190 | **mở** | 1 | run `2026-08-12-S190-soltuon-dieu-chinh-hd/` *(thi-công → WAL)* | Kết quả review GĐ3 của anh (vế 2 YC-025) = 5 điều chỉnh UAT: **(1)** ảnh-1 dời khối được khoanh (cột danh-sách HĐ trống) sang vị-trí mũi-tên chỉ — đọc-hình bậc-2, invest xác nhận từ khuôn KHKK trước khi khoá spec · **(2)** ảnh-2 mỗi LOẠI HĐ = 1 quy-trình duyệt RIÊNG, UI phải thể hiện đúng (7 menu loại đã khoanh) · **(3)** BUG menu HĐ lẫn lộn: click menu này nhảy sang menu khác — điều chỉnh routing/menu-key · **(4)** bộ thao-tác (duyệt/xóa/thao tác/đang duyệt/đã duyệt/đã xóa) cấu trúc y KHUÔN KHKK · **(5)** ảnh-3 Admin Designer: thêm mục cấu-hình quy-trình per-LOẠI-HĐ (nguyên tắc, thầu phụ, …) y khuôn "Duyệt NCC (Mới)" + "Duyệt KHKK — Nhóm 1..8". Pipeline anh chỉ định 6 bước: ① `/fable-real` invest+review điều chỉnh spec → wave+checklist *(em gán `investigator-codebase`)* ② `/fable-clone` review lại *(`reviewer`)* ③ `/fable-real` ×2 vai style FE/BE invest spec-list style đồng nhất *(`front-end-reviewer-style` + `back-end-reviewer-style`)* ④ `/fable-clone` FE/BE review style lại ⑤ `/fable-real` tổng hợp cuối ra wave cụ thể *(`reviewer`)* ⑥ fan-out **Opus 5 MAX** xử lý toàn bộ plan, tên plan **"SOLTUON-12-08-2026"** (giữ nguyên văn tên anh đặt) | |
+| `YC-031` | "Admin -> tạm ôn. ⏎ eOffice -> vào trắng màn hình" *(kèm ảnh prod eoffice trắng trơn)* ⏎ → "fix luôn đi, lỗi này bị 2-3 lần rồi" ⏎ → "Fix lỡi này luôn rồi chạy /session-end" | 2026-08-13 · S191 | **mở** *(vá GỐC đã ship `305b573f`, CI đang verify; đóng khi anh xác nhận prod ổn qua 1 chu-kỳ deploy KHÔNG hotfix tay)* | 3 | `docs/gotchas.md` #92 + `.gitea/workflows/deploy.yml` + session-log S189-S191 *(thi-công → WAL)* | Anh kiểm prod GĐ3 sau deploy #600 → eOffice **trắng màn**, admin tạm ổn. 🔴 Vế **"bị 2-3 lần rồi"** là phần NẶNG NHẤT của yêu-cầu: anh KHÔNG xin hotfix, anh đòi **thôi tái phát** ⇒ cấm vá triệu chứng (scp bundle) rồi tuyên xong. Đội hiểu: **(1)** cứu prod ngay (build local lành scp đè ×2 app — đã làm, console 0 lỗi) · **(2)** truy ROOT-CAUSE thật: `deploy.yml` xoá `package-lock.json` rồi `npm install` ⇒ mỗi run resolve lại cây theo semver ⇒ cùng commit ra bundle khác nhau ⇒ CI xanh mà bundle crash `useState null`; lockfile cũ (23/04) thiếu `@microsoft/signalr` nên "xoá cho lành" từng có vẻ hợp lý · **(3)** vá gốc: lockfile tái sinh từ cây lành + `npm ci` + **GUARD-92** chặn React trùng bản (fault-inject 4 ca, bắt được dương-giả `lucide-react` trước khi push) · **(4)** khắc gotcha **#92** kèm luật "verify deploy FE phải có 1 phép đo RUNTIME" — vì 2 lần lọt đều do mọi phép đo chỉ đo FILE (byte-match + HTTP 200), không đo CHƯƠNG TRÌNH CHẠY. ✅ **ĐÓNG vế kỹ-thuật @S191:** CI run **#488 PASS 6/6**, hash CI == local **4/4** (`CR538vZx`/`C10ta-wB`), runtime-verify 2 app console 0 lỗi. 🔴 **ĐÍNH CHÍNH 2 điều lead ghi SAI ở dòng này (cặp H24 bắt @close):** **(a)** `.nvmrc` **CÓ tồn tại** (`fe-admin/.nvmrc` + `fe-user/.nvmrc` = `20`, tracked từ `25dad7f3`) — cái thiếu là **người ĐỌC nó** (`deploy.yml` 0 hit `setup-node`) = ghost-wire class-2, không phải file-missing; chẩn sai thì vá sai (đi tạo lại file = vô ích). **(b)** nghi vấn "chênh node/npm là nguồn bất-định còn lại" **BỊ BÁC bằng đo**: runner node v24.15.0/npm 11.12.1 vs local v22.13.0/npm 10.9.2 vẫn ra **đúng 4/4 hash** ⇒ nguồn bất-định duy nhất là việc xoá lockfile, đã vá. 🔸 **1 điểm chưa khớp CẦN ANH 1 CÂU:** anh nói **"2-3 lần"**, sổ + gotcha #92 truy được **2 ca có vết** (S189 #486 · S191 #600); grep `"trắng màn"` toàn sổ bền = 6 hit/5 file, **100% thuộc 2 ca đó, 0 vết cho ca thứ 3**. ⇒ hoặc có 1 ca chưa từng vào sổ (mẫu root-cause đang thiếu 1/3 dữ liệu), hoặc anh nói ước lượng. 🔸 CÒN TREO: node/npm runner **chưa pin** — chờ anh quyết pin `setup-node` đọc `.nvmrc` hay khai thẳng "cố ý không pin". | |
 | `YC-018` | "2 phần bookend và bookstart -> trong đợt adapt này AI_INFRA cũng có hướng dẫn bọn mày chạy 1 mạch hết toàn bộ ko còn pause/tiep nữa, chú ý cấu hình cái đó kỹ nhé" | 2026-08-09 · S185 | **đóng** *(cấu hình land 4 site @S185 + chạy thật trọn 1 mạch bookend @close cùng đêm — nghiệm bằng vận hành; 🔴 nhắc lần 2 @S188 = PN-001: lead bỏ 3 vai @close với lý do "ngân sách" — owner bác, chạy nốt ngay trong lượt)* | **2** | WAL chain (TASK → WAL) | Nghi-thức 2 đầu phiên (`/session-start` bookstart + `/session-end` bookend) phải chạy **TRỌN TRONG MỘT LƯỢT** như hub kể ở thư 08-08 Phần 1b ("lượt mở phiên gần nhất chạy trọn trong một lượt duy nhất, không cần cửa tạm dừng nào chen giữa") — cấu hình luật ONE-SHOT vào 2 file lệnh, CẤM rải nghi-thức qua nhiều cửa pause/tiep, CẤM hẹn-cửa-sau. *(Đội hiểu: pause/tiep VẪN là recovery khi đứt bất-khả-kháng [limit/crash — H22 giữ nguyên]; thứ bị cấm là DÙNG chúng làm nhịp chia-chặng nghi-thức. Anh bác cách hiểu này thì em sửa.)* | |
 
 > 🔴 **MỘT yêu-cầu, nhắc 4 lần.** Đây là dữ-liệu **TC-01** sinh ra để bắt, và nó tố-giác chính lead: hiểu sai ở `YC-002` nên anh phải nói lại 3 lần. **Ghi lại chứ không làm đẹp.**