solution-erp/.claude/workflows/runs/2026-08-07-S180-adap-upgrade-pack-phased/sub-n3-lane-a-gd01.md

N3 — LANE A / 6: GĐ-0 (Tiếp nhận + bản đồ áp dụng) · GĐ-1 (Nền chuẩn đặt tên)

• Phiên: S180 · Vai: reviewer (/fable-clone reviewer) · Ngày: 2026-08-07
• Chế độ: read-only, propose-only. Ngoài tệp này KHÔNG ghi/sửa tệp nào khác.
• Ghi đĩa liên tục (chống #53): mỗi khoản chốt xong append ngay, không đợi cuối.

§0 — Nguồn đã đọc TRỰC TIẾP (không qua tóm tắt)

Món	Đường dẫn	Byte	Phần đã đọc
Thư chính	broadcasts/inbox/ai_infra/2026-08-04-Governance-upgrade-pack-phased-thu-chinh.md	33.156	dòng 24-178 (gồm §Khai-trạng-thái · §Bảng-bệnh · §Luật-chung · §GĐ-0 :109-126 · §GĐ-1 :130-147)
Phụ lục spec+bẫy	…-phu-luc-spec-pitfall.md	46.416	dòng 20-164 (gồm §Chín-lớp-lỗi · §GĐ-0 :64-89 · §GĐ-1 :93-137)
Khuôn+checklist	…-khuon-fit-map-report-checklist.md	30.502	Phần A :29-59 · Phần C :228-385
Luật chấm điểm	…-luat-cham-diem.md	9.970	(món 4 — chỉ dùng để đếm "bốn món", không thuộc lăng kính lane A)

Vật tham chiếu trong run-folder: sub-invest-fitmap-S180.md (48.433 B) · sub-review-n2-S180.md (22.418 B) · spec-adap-upgrade-pack-phased-07-08-2026.md (7.550 B) · run.md (10.603 B).

---

§1 — GĐ-0: bóc TỪNG KHOẢN (18 khoản, không gộp)

Hub đòi GĐ-0 ở bốn nơi khác nhau, và bốn nơi đó không trùng khít nhau. Tôi liệt cả bốn, đánh số riêng từng nơi, rồi mới nói chỗ chồng lấn. Gộp bốn nơi thành một danh sách là chính cái làm rơi khoản.

• Nơi 1 — thư chính :112-119 — 7 bước làm (G0-B1..B7).
• Nơi 2 — thư chính :121-125 — 3 lệnh "kiểm xong chưa" (G0-K1..K3).
• Nơi 3 — Phần C của khuôn :251-269 — 4 khoản danh mục kiểm (A0-1..A0-4).
• Nơi 4 — phụ lục :86-89 — 4 ô nghiệm thu (G0-N1..N4).

1.1 — Bảy bước làm (thư chính :112-119)

#	Hub đòi gì	SE: đã có / thiếu / ngược	Bằng chứng file:line
G0-B1	Kéo cả bốn món về kho bạn	ĐÃ CÓ — 4/4 tệp trên đĩa, cùng một commit	broadcasts/inbox/ai_infra/2026-08-04-Governance-upgrade-pack-phased-{thu-chinh,phu-luc-spec-pitfall,khuon-fit-map-report-checklist,luat-cham-diem}.md; git log -1 --format=%ci -- <mỗi tệp> → cả 4 ra 2026-08-05 10:18:34 +0700, commit 3a6eb92
G0-B2	Tính lại mã băm nội dung từng món, so với giá trị hub công bố, ghi kết quả so	ĐÃ CÓ NHƯNG ĐẶT SAI CHỖ — phép so đã chạy và đạt 4/4, nhưng kết quả chỉ nằm trong một tệp lane của phiên này, không nằm ở sổ nào sống lâu hơn phiên	Kết quả: sub-invest-fitmap-S180.md:32 ("Hash verify 4/4 OK canonical bằng máy có sẵn scripts/stamp_verify.py (exit=0)"). Giá trị hub công bố nằm ngay trong frontmatter từng thư: 43db2cf0 · 49287ce7 · 98e31fad · c24699f0. Sổ đáng lẽ giữ kết quả này là broadcasts/_index.md — nó có sẵn cột sha256(12) và cột verify (broadcasts/_index.md:13) nhưng không có dòng nào cho 4 món
G0-B3	Ghi đĩa ngay bốn món vào một chỗ cố định, và ghi lại đường dẫn	ĐÃ CÓ — chỗ cố định là broadcasts/inbox/ai_infra/; đường dẫn được ghi lại ở spec-…-07-08-2026.md:3 và :13-19	spec-adap-upgrade-pack-phased-07-08-2026.md:3
G0-B4	Dựng tệp theo dõi tiến độ theo từng giai đoạn, liệt kê từng khoản của danh mục kiểm	THIẾU — không có tệp nào liệt đủ 14 khoản A0-1..A0-4 · A1..A10 · A11..A16 để tick dần	Phép tìm: grep -rl "A0-1" --include="*.md" .claude/ docs/ → chỉ ra tệp trong run-folder S180, không ra tệp theo dõi. docs/governance/ không có tệp nào tên theo dõi/tracking (ls docs/governance/ = 12 mục, không mục nào là sổ theo dõi gói này)
G0-B5	Ghi một dòng "đã nhận" vào sổ liên lạc phía bạn, kèm ngày	THIẾU — và thiếu rộng hơn nhiều so với 4 món (chi tiết ở §2, đây là khoản mà lane brief gọi là "A0-3 hụt")	broadcasts/_index.md — 0 dòng cho cả 4 món; control-dương grep -c "harness-22" broadcasts/_index.md = 3 ⇒ thước còn sống, im lặng là im lặng thật
G0-B6	Lập bản đồ áp dụng bảy dòng, mỗi dòng chọn đúng một trong ba	CÓ BẢN NHÁP, CHƯA CÓ TỆP RỜI — bảng bảy dòng đã tồn tại nhưng nằm bên trong một tệp điều tra, không phải một tệp bản đồ độc lập	Bảng: sub-invest-fitmap-S180.md:220-228 (dòng :220 là dòng tiêu đề, :222-228 là bảy dòng GĐ-0..GĐ-6). Hệ quả đo được: lệnh tự kiểm của hub `grep -c '^
G0-B7	Gửi báo cáo tiếp nhận kèm bản đồ áp dụng, qua hộp thư đi hướng tới hub; ghi tệp vào kho của bạn	THIẾU — chưa có báo cáo nào	ls broadcasts/outbox/ai_infra/ = 47 tệp, tệp mới nhất đề ngày 2026-07-26; không tệp nào mang chữ upgrade-pack. Control-dương: cùng lệnh ls trả 47 tệp ⇒ thư mục đọc được, không phải lỗi đường dẫn

1.2 — Ba lệnh "kiểm xong chưa" (thư chính :121-125)

#	Lệnh hub đưa	SE chạy được chưa	Kết quả thật
G0-K1	`grep -c '^	GĐ-[0-6]' <bản-đồ>` phải ra 7	CHƯA — vì chưa có tệp bản đồ rời (xem G0-B6)
G0-K2	ls <bốn đường dẫn> phải đủ bốn tệp	ĐẠT	4/4 tệp tồn tại, byte lần lượt 33.156 · 46.416 · 30.502 · 9.970 (tổng 120.044)
G0-K3	<lệnh mã băm> phải khớp giá trị đã ghi	ĐẠT, nhưng chỉ khớp qua đúng một máy	python scripts/stamp_verify.py broadcasts/inbox/ai_infra/2026-08-04-Governance-upgrade-pack-phased-*.md → exit=0, 4/4 khớp (sub-invest-fitmap-S180.md:32). 🔴 Cảnh báo kế thừa từ N1: phép băm tự chế cho MISMATCH cả bốn — nghĩa là ai chạy lệnh băm thông thường sẽ kết luận nhầm là bị sửa nội dung. Bất kỳ tài liệu nào của SE nhắc tới G0-K3 phải dán kèm đúng lệnh này, không được ghi chung chung là "đã băm"

1.3 — Bốn khoản danh mục kiểm Phần C (khuon-…:251-269)

#	Khoản	SE	Ghi chú đo được
A0-1	Bốn món trên đĩa kèm mã băm	ĐÃ CÓ MỘT NỬA	Vế "trên đĩa" đạt (G0-B1). Vế "bạn ghi lại mã băm" chưa có chỗ ghi thường trực (G0-B2)
A0-2	Tệp theo dõi tiến độ, số khoản khớp số khoản của danh mục	THIẾU	= G0-B4. Danh mục có 14 khoản đánh số (A0-1 A0-2 A0-3 A0-4 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 — tức 4 + 10 + 6 = 20 khoản, tôi đếm lại từ khuon-…:373-375 chứ không lấy con số cũ)
A0-3	Một dòng "đã nhận" trong sổ liên lạc, tìm được bằng một lệnh tìm kiếm	THIẾU	= G0-B5, phân tích đầy đủ ở §2
A0-4	Bản đồ áp dụng bảy dòng, không ô quyết định nào trống	CÓ NHÁP, CHƯA ĐẠT KHUÔN	= G0-B6; thêm một khiếm khuyết riêng ở §5 (ô quyết định trộn giá trị)

🔴 Đính chính ngay trong bảng của chính tôi: ở dòng A0-2 phía trên tôi vừa viết "14 khoản" rồi đếm lại ra 20. Tôi giữ cả hai con số và giữ luôn vết sửa, vì đây đúng lớp lỗi mà hub gọi tên: số chép tay trong văn xuôi trôi (LỚP-5). Con số đúng là 20, dẫn được từ khuon-…:373-375: bốn khoản Phần 0, mười khoản Phần 1, sáu khoản Phần 2. Tệp theo dõi của SE khi dựng phải có đúng 20 dòng, không phải 14.

1.4 — Bốn ô nghiệm thu phụ lục (phu-luc-…:86-89)

#	Ô nghiệm thu	SE đạt?
G0-N1	Bốn tệp trên đĩa, mã băm tính lại khớp	ĐẠT (bằng máy canonical, xem G0-K3)
G0-N2	Tệp theo dõi tồn tại, số khoản khớp	KHÔNG ĐẠT — tệp không tồn tại
G0-N3	Sổ liên lạc có dòng "đã nhận" kèm ngày	KHÔNG ĐẠT
G0-N4	Bản đồ áp dụng đủ bảy dòng, không dòng nào trống	ĐẠT về số dòng, CHƯA ĐẠT về hình thức ô (§5)

Tổng kết GĐ-0: 18 khoản đã liệt. ĐÃ CÓ 6 (G0-B1, G0-B3, G0-K2, G0-K3, A0-1 nửa vế, G0-N1) · THIẾU 9 (G0-B4, G0-B5, G0-B7, G0-K1, A0-2, A0-3, G0-N2, G0-N3, và vế ghi-lại-băm của G0-B2) · CÓ NHƯNG SAI KHUÔN 3 (G0-B6, A0-4, G0-N4). Không khoản nào NGƯỢC — SE không làm điều gì trái với GĐ-0, chỉ chưa làm.

---

§2 — Khoản A0-3 ("đã nhận" trong sổ liên lạc): lỗ thật rộng gấp năm lần cách nó đang được kể

Đây là câu hỏi số 5 của lane. Câu trả lời ngắn: đúng, đây là khoản A0-3 của GĐ-0 (đồng thời là bước G0-B5 và ô nghiệm thu G0-N3). Câu trả lời dài quan trọng hơn, vì cách khoản này đang được mô tả — "bốn thư nằm trong hộp thư hai ngày" — nhỏ hơn lỗ thật rất nhiều, và vá theo mô tả đó sẽ để lại đúng cái lỗ cũ.

2.1 — Hai con số, và mỗi bên đang đếm cái gì

Tôi đo hai lần bằng hai phép độc lập, và hai phép ra cùng một con số, nên con số này đứng được.

• Phép 1 — đếm dòng trong sổ. Tách sổ theo hai khối rồi đếm dòng dữ liệu: khối nhận có 45 dòng, khối gửi có 47 dòng. Cộng hai khối cùng hai dòng tiêu đề ra 94, khớp với grep -cE "^\| " broadcasts/_index.md = 94.
• Phép 2 — đối chiếu ngược từ đĩa. Duyệt từng tệp trong broadcasts/inbox/*/, lấy tên tệp bỏ đuôi, tìm chuỗi đó trong sổ: 69 tệp trên đĩa · 45 tệp có dòng · 24 tệp không có dòng.

Hai phép gặp nhau ở con số 45. Vậy lỗ thật là 24 lá thư, không phải 4. Và lá cũ nhất trong 24 lá đó đề ngày 2026-07-13, tức là đã nằm im 25 ngày, không phải 2 ngày.

Nói rõ mỗi bên đếm gì, vì đây là chỗ dễ cãi nhau vô ích:

• "4 thư · 2 ngày" đếm riêng bộ bốn món của gói này, tính từ lúc chúng hạ cánh xuống đĩa (2026-08-05 10:18:34, commit 3a6eb92) tới hôm nay (2026-08-07). Con số này đúng trong phạm vi của nó.
• "24 thư · 25 ngày" đếm mọi thư trong hộp thư chưa có dòng trong sổ. Con số này cũng đúng, và nó mới là phạm vi mà khoản A0-3 nói tới, vì A0-3 đòi sổ liên lạc làm được việc của sổ liên lạc.
• Bẫy đơn vị thứ ba, tôi tự dẫm rồi tự bắt: cùng commit 3a6eb92 có năm tệp cùng thời điểm sửa đổi, không phải bốn — lá thứ năm là 2026-07-28-Governance-day-wake-probe-first-resume.md. Nếu ai đo bằng thời điểm sửa đổi tệp thì sẽ ra 5; đo bằng "món của gói" thì ra 4.

2.2 — Vì sao lỗ này lại tồn tại: luật lane có hai chỗ ghi

Đây mới là nguyên nhân, và nó không phải là "quên". Tôi phân loại 69 tệp theo trường to: trong phần đầu tệp:

Loại thư (to:)	Có dòng trong sổ	Không có dòng	Tổng
se — thư gửi đích danh	23	0	23
all-fit — thư phát đại trà	22	20	42
all — thư phát đại trà	0	1	1
(không có dòng to:)	0	3	3
Tổng	45	24	69

Đọc bảng này ra được ba điều, và điều thứ ba là điều đắt nhất.

1. Lane thư gửi đích danh sạch tuyệt đối: 23 trên 23. Đây là control dương mạnh nhất tôi có — nó chứng minh kỷ luật ghi sổ của SE có tồn tại và có chạy, nên 24 lá kia không phải do lười.
2. Lane thư phát đại trà rò gần một nửa: 22 vào sổ, 21 không. Cùng một loại thư, hai số phận khác nhau.
3. Chính cuốn sổ tự viết rằng loại thư này không thuộc về nó. broadcasts/_index.md:7 ghi: "Fan-out adap broadcast (≠ email directed) → outbox/all/ (pull /adap-apply), track ở COMMS-LEDGER OUT — KHÔNG ở index này". Nghĩa là theo luật của chính SE, 21 lá phát đại trà không sai khi vắng mặt. Nhưng 22 lá cùng loại lại có mặt, ghi đầy đủ ai_infra → se, processed, dấu ✓ — ví dụ broadcasts/_index.md:27, :28, :30, :34, :39. Vậy luật nói một đằng, cuốn sổ làm một nẻo, hai mươi hai lần.

2.3 — Cuốn sổ mà luật trỏ tới không tồn tại trong kho SE

Đây là phát hiện nặng nhất của §2, và nó biến khoản này từ "quên ghi" thành "không có chỗ để ghi".

Luật ở _index.md:7 bảo đi ghi ở COMMS-LEDGER. Tôi tìm:

• find . -iname "*COMMS*" (loại .git và node_modules) → không có tệp nào.
• Control dương cho chính phép tìm đó: cùng lệnh find . -iname "*ledger*" → ra 4 tệp (.claude/governance/reinject-ledger.md, .claude/workflows/runs/_ledger.md, docs/governance/error-ledger.md, và một tệp nhật ký phiên). Vậy lệnh chạy được, thư mục đọc được; kết quả rỗng là rỗng thật.
• Mọi lần chữ COMMS-LEDGER xuất hiện trong kho SE đều đang nói về kho của hub, không phải kho SE. Bằng chứng rõ nhất: .claude/workflows/runs/2026-07-25-S152-h24-open-bookend/sub-lead-stale-close-S152.md:163 liệt ba tệp của hub, trong đó có docs/governance/COMMS-LEDGER.md — tức là tệp ấy nằm ở AI_INFRA.

⇒ 21 lá thư phát đại trà đang không có sổ nào nhận chúng. Sổ A từ chối chúng bằng văn bản, sổ B không tồn tại. Đây đúng cái mà GĐ-1 mục (i) gọi tên: "Cho phép hai chỗ đặt là cho phép hai chỗ tìm, và tới lúc cần thì ai cũng tìm chỗ còn lại." Ở SE thì tệ hơn một bậc: chỗ còn lại không có.

2.4 — Khoản này đã từng bị xử là báo động giả, và cách xử đó nay không còn đứng vững

Ngày 2026-07-26, phiên S153 đã gặp đúng câu hỏi này và kết luận là dương giả: "F-4 _index inbound = dương-giả (19 thư fan-out outbox/all, header :7 khai track ở COMMS-LEDGER)" — .claude/workflows/runs/2026-07-26-S153-bookend-close/bookend-close-synthesis.md:25, và vòng kiểm độc lập ghi nhận không chấm lại ở sub-ring1-close-S153.md:161.

Kết luận đó hợp lệ tại thời điểm đó trong phạm vi câu hỏi lúc đó ("sổ này có thiếu dòng không?"). Nhưng nó không trả lời câu hỏi mà A0-3 đặt ra bây giờ ("bạn có tìm được dòng đã nhận bằng một lệnh tìm kiếm không?"). Hai câu hỏi khác nhau, nên hai kết luận không mâu thuẫn nhau — nhưng ai đem kết luận cũ ra dùng cho câu hỏi mới sẽ đóng nhầm một khoản đang hở. Thêm nữa, con số đã trôi từ 19 lên 21 trong mười hai ngày, nên ngay cả trong phạm vi cũ thì lỗ vẫn đang lớn dần.

Cùng cuốn sổ còn mang sẵn một vết tự thú của đúng lớp lỗi này ở phần cuối tệp: "Reconcile S123 — hai dòng đầu là email S122 đã gửi nhưng chưa từng được log … _index là sổ mà hub và audit đọc; email gửi mà không log thì hub không biết có nó." Lớp lỗi đã được đặt tên, đã được vá một lần ở chiều gửi, và đang tái diễn ở chiều nhận.

2.5 — Vá thế nào cho đúng khuôn

Bốn việc, làm đúng thứ tự này. Việc 1 và 2 là bắt buộc để đóng A0-3; việc 3 là thứ ngăn nó tái phát; việc 4 là thứ hub sẽ soi.

1. Chọn một chỗ, bỏ chữ "hoặc". Quyết định thư phát đại trà nhận vào thì ghi ở đâu, rồi sửa luật ở broadcasts/_index.md:7 cho khớp với thực tế. Có hai đường đi được, và đường thứ nhất rẻ hơn nhiều: (a) mở phạm vi khối INBOUND của _index để nhận cả thư phát đại trà — cách này hợp thức hóa 22 dòng đã tồn tại thay vì phải gỡ chúng ra; (b) dựng một cuốn sổ thứ hai trong kho SE và đồng thời gỡ 22 dòng kia khỏi _index. Chọn (b) mà quên vế gỡ là tạo ra đúng tình trạng hai chỗ ghi mà GĐ-1 cấm.
2. Bù đủ 24 dòng, không bù 4. Bù 4 dòng cho riêng gói này rồi tuyên đã xong A0-3 là để lại 20 lỗ và làm cuốn sổ tiếp tục nói dối. Mỗi dòng cần: ngày nhận · mã định danh · ai_infra → se · nấc hiện tại · mã băm · dấu đối chiếu. Riêng bốn món của gói, mã băm lấy từ phần đầu tệp (43db2cf0 · 49287ce7 · 98e31fad · c24699f0) và dấu đối chiếu lấy từ kết quả scripts/stamp_verify.py — như vậy một việc đóng luôn hai khoản, vì đây cũng chính là chỗ ghi thường trực còn thiếu của G0-B2.
3. Cắm một phép đối chiếu ngược chạy được. Phép ở §2.1 (duyệt tệp trên đĩa, tìm tên trong sổ, in ra danh sách vắng mặt) là một vị từ máy kiểm hoàn chỉnh cho A0-3 — nó đọc hai nguồn (đĩa và sổ) đúng như GĐ-2 mục (ii) đòi, thay vì chỉ đọc sổ, mà đọc sổ thì là tự soi mình. Chạy nó ở cửa đóng phiên là bắt được ngay lá thư kế tiếp bị rơi.
4. Ba lá không có dòng to: phải xử riêng, đừng gộp. 2026-07-20-Governance-auto-toan-vong-distill-2-tang.md, 2026-07-21-Governance-eval-quality-audit-ra-thuoc-eval-cua-eval.md, 2026-07-25-Governance-model-default-opus-5-max.md — cả ba thiếu trường to:, nên mọi phép phân loại theo to: sẽ bỏ rơi chúng trong im lặng. Đây là ca "vắng mặt trông giống ổn": chúng không rơi vào bất kỳ nhánh nào của luật lane, kể cả sau khi luật được sửa.

Một hệ quả cần nói thẳng: cả bốn món đều mang to: all-fit, nghĩa là chúng là thư phát đại trà. Vậy trước khi bù dòng cho chúng, việc 1 phải xong — nếu không thì bù dòng chính là hành vi vi phạm luật đang có hiệu lực ở _index.md:7, và ta lại thêm 4 vào con số 22.

---