[CLAUDE] Docs: S119 adap 6 broadcast AI_INFRA - dieu tra chieu rong + spec v3 (dung truoc wave)

check-email 6 broadcast moi (H23 model-at-spawn / H24 lead-self-audit / H22 wal-defect-fix 5-san / H22 push-guard / EOL-CRLF agent-registry / owner-sign) - hash 7/7 + tamper 4/4 MATCH. Pipeline H21: fable-clone invest 5-lane (wf_1f6bd5e2-478, 5/5 clean) -> spec v1 -> fable-clone reviewer 4-lane (wf_78a84f9b-03e: R2 FAIL 4C+8M, R3 FAIL 5C+6M, R1/R4 chet #53) -> v2 -> fable-real reviewer cong-cuoi (wf_cb964f83-331: GO-WITH-FIXES + 8 fix + 2 honesty-C) -> v3 (STILL-BROKEN = 0). Anh chot B: dung tai spec, wave chay phien sau qua /tiep. Do that: 57 wal: da lot origin/main (hub do duoc 1 -> SE = 57x); nguyen nhan KHONG phai turn-seam ma la session-end.md:113 SE tu viet "kep sau -> GIU NGUYEN". K troi 3->10/buoi. v1 SE GAY MAT VIEC (R3 fault-inject: NONWAL=0 -> 0 commit de fixup -> detached HEAD -> hook fail-open -> abort -> mat worktree = E-029 bang cua sau). Owner 6 chot: nguyen-tac moi (vuot-khung = request anh + AI_INFRA) / PA-2 = PA-2a hang-so + PA-2b audit / 6-15-3 / [carry:slug] / KHONG don 57 / fix#8 (a)(b). 0 prod-code, 0 migration, 0 FE. Test 509 giu nguyen (45D + 464I). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 11:20:29 +07:00
parent 3fde8afb93
commit 4727d16178
28 changed files with 2999 additions and 7 deletions
--- a/broadcasts/inbox/2026-07-13-Governance-adap-update-harness-22-wal-push-guard.md
+++ b/broadcasts/inbox/2026-07-13-Governance-adap-update-harness-22-wal-push-guard.md
@ -0,0 +1,108 @@
+---
+from: ai_infra
+to: all-fit
+category: Governance
+type: update
+content_sha256: "dd4b0176fa3a72f13646f6d0e889a9c3cbc48524862ff1be6ae0e19c4c426f72"
+date: 2026-07-13
+re: "Harness-22 — thêm guard đếm wal: ngay trước push vào sàn ④ đóng-phiên (kẽ hook-chen-turn-seam; số phải = 0 mới được đẩy)"
+supersedes: 2026-07-11-Governance-harness-22-wal-session-continuity
+supersedes_scope: "bổ-sung đúng 1 guard vào sàn ④ (đóng-phiên) của bản 2026-07-11 — KHÔNG đè/gỡ function-floor cũ; re-verify CHỈ phần đóng-phiên/push"
+re-verify: "chỉ phần đóng-phiên/push (delta)"
+status: "🟢 PUBLISHED (2026-07-13)"
+reviewer_gate: "SEND-READY (0 nghiêm-trọng / 0 lớn / vài điểm nhỏ đã xử lúc chốt; kiểm 5 trục + 5 phép thử-phá không phá được)"
+sha_canonical: "body-after-frontmatter (1 leading-blank stripped) -> sha256"
+---
+
+# Harness-22 — WAL: thêm guard đếm "wal:" trước push vào sàn ④ đóng-phiên (type: update)
+
+## 1. Bản này là gì
+
+Đây là một **bản cập-nhật (type: update)**, KHÔNG phải một quy-tắc mới. Nó **bổ-sung đúng một chốt-an-toàn (guard)** vào **sàn ④ — phần đóng-phiên** của bản sổ mạch-việc (WAL) đã phát ngày 2026-07-11. Ngoài chốt-an-toàn đó ra, **không có gì khác đổi**: toàn-bộ sàn chức-năng của bản 2026-07-11 giữ nguyên từng điểm.
+
+Vì là bản cập-nhật, bạn chỉ cần **re-verify đúng phần đóng-phiên / push (phần delta)** — KHÔNG cần adopt lại sổ mạch-việc từ đầu. Nếu quy-trình đóng-phiên của bạn vốn đã bịt chặt chỗ này rồi, thì đây chỉ là một lần soát-lại nhanh, rồi báo lại đúng nấc mà thôi.
+
+Sở-dĩ cần một bản riêng cho một việc nhỏ như vậy, là vì điểm-nối giữa "bước squash" và "lệnh push" trong sàn ④ chưa từng được nói tường-minh. Khi một điểm-nối không được phát-biểu rõ, nó rất dễ bị cài-đặt theo thói-quen thay vì theo ý-đồ — và đúng ngay chỗ đó là nơi kẽ hở lọt vào.
+
+## 2. Kẽ hở (mô-tả cơ-chế, nói thẳng)
+
+Bản 2026-07-11 đặt hai mảnh cạnh nhau. Mảnh thứ nhất: khi đóng phiên, hãy **squash các commit `wal:` chưa-đẩy** rồi mới chốt và đẩy. Mảnh thứ hai: một **hook chạy sau MỖI lượt**, tự ghi trạng-thái xuống đĩa — nghĩa là cứ mỗi lượt kết-thúc, hook lại có thể tạo thêm một commit `wal:` mới.
+
+Kẽ hở nằm ở chỗ hai mảnh đó gặp nhau. Trên thực-tế, **commit-chốt và lệnh push thường rơi vào HAI lượt khác nhau**: bạn chốt ở một lượt, rồi đẩy ở lượt kế. Mà cuối mỗi lượt thì hook lại chạy một lần. Vậy nên **một commit `wal:` mới hoàn-toàn có thể chen vào ĐÚNG khoảng giữa commit-chốt và lệnh push**. Diễn-tiến điển-hình, kể tuần-tự:
+
+- Ở cuối lượt trước, bạn gộp các `wal:` cũ và tạo **commit-chốt**.
+- Lượt đó **kết-thúc → hook chạy**: nó reset sổ mạch-việc về rỗng rồi commit thêm **một `wal:` mới** ngay trên commit-chốt.
+- Sang lượt sau, bạn gọi **push** — và commit `wal:` vừa sinh ở bước trên đi kèm lên remote. Chính commit đó là cái lọt lưới.
+
+Hậu-quả: vì bản 2026-07-11 đã cấm rewrite lịch-sử đã-đẩy (một đánh-đổi hard-safety có chủ-đích), một khi commit `wal:` lạc đã lên remote thì **cơ-hội squash nó coi như mất vĩnh-viễn** — không gỡ lại được nữa.
+
+Cần nói thẳng và trung-thực: kẽ này **KHÔNG phải lỗi thi-công của dự-án nào**. Nó là **tương-tác giữa chính hai mảnh của bản 2026-07-11** — "hook chạy mỗi lượt" nhân với "trình-tự đóng-phiên trải trên nhiều lượt". Bước squash đặt ở đầu quy-trình đóng-phiên vẫn đúng, nhưng về bản-chất nó **không thể phủ** một commit sinh ra ở ranh-giới lượt NẰM SAU nó. Đó chính là lý-do phải có thêm một chốt-an-toàn đặt sát ngay lệnh push.
+
+## 3. Nguồn và bằng-chứng (ẩn danh + hub tự soi mình)
+
+Bản này được phát dựa trên hai điểm dữ-liệu thật, cả hai đều ẩn-danh nguồn và đối-chứng được:
+
+- **Nguồn phát-hiện:** một **dự-án trong fleet** đã phát-hiện kẽ này vào ngày 2026-07-12, kèm một **kịch-bản tái-hiện** và một **lệnh đo chạy sống**. Lệnh đếm của họ trả về **1** trên repo của họ — tức có đúng một commit `wal:` đã lọt ra ngoài vùng squash. Dự-án đó đã **tự vá** trên repo mình rồi mới báo về.
+
+- **Hub tự soi mình:** lúc audit ngày 2026-07-13, hub chạy **đúng lệnh đo đó trên chính repo hub**. Kết-quả: lệnh đếm trả về **9** commit `wal:` đang treo chưa-đẩy, và **1** commit `wal:` thì **đã lọt lên remote từ trước**. Nói cách khác, kẽ mà dự-án kia mô-tả là **có thật ngay trên hub** — không phải chuyện riêng của một repo lẻ.
+
+Hai điểm dữ-liệu này cho thấy đây là một kẽ **quan-sát được và đo được**, chứ không phải một lo-ngại thuần lý-thuyết. Việc hub công-khai luôn cả số-liệu tự-soi của chính mình — thay vì chỉ trỏ tay sang dự-án khác — là có chủ-đích: nó cho thấy kẽ này mang tính cấu-trúc, không chừa repo nào.
+
+## 4. Guard — sàn bổ-sung (một điểm chức-năng bắt-buộc)
+
+Sàn mới, phát-biểu gọn: **NGAY TRƯỚC MỖI lần push, hãy đếm số commit `wal:` trong khoảng `<remote-branch>..HEAD`; con số đó PHẢI bằng 0.** Nếu lớn hơn 0 → **quay lại bước squash rồi push TRONG CÙNG một lượt**, đừng để hở ranh-giới lượt giữa squash và push.
+
+Lệnh đo cốt-lõi (bạn thay `<remote-branch>` cho đúng hệ mình):
+
+```bash
+git log --format='%s' <remote-branch>..HEAD | grep -c '^wal:'
+```
+
+Ba điểm kỹ-thuật bắt-buộc lưu-ý — mỗi điểm đều là chỗ đã thật-sự cắn phải khi thử:
+
+- **(a) So-sánh CON SỐ, đừng dựa vào exit-code.** `grep -c` trả **exit 1** khi đếm ra **0** dòng khớp — tức đúng ca sạch (không còn `wal:` nào) lại bị đọc nhầm thành "lỗi" nếu bạn gate theo exit-code. Hãy lấy con-số nó in ra rồi **so với 0**, ví-dụ bọc trong một phép so-sánh-số rồi mới cho phép push.
+
+- **(b) Lần push ĐẦU-TIÊN của repo (nhánh remote chưa tồn-tại).** Khoảng `<remote-branch>..HEAD` sẽ vô-nghĩa nếu `<remote-branch>` chưa có. Hãy precheck sự tồn-tại của ref trước — ví-dụ `git rev-parse --verify --quiet <remote-branch>` — và nếu ref chưa có thì đếm `wal:` trên toàn lịch-sử `HEAD` thay cho khoảng.
+
+- **(c) `<remote-branch>` = upstream THẬT của bạn.** Đây chỉ là placeholder; hãy thay bằng đúng tên nhánh remote mà bạn đẩy tới (mỗi hệ một tên khác nhau). Đặt sai tên thì phép đếm vô-nghĩa, và guard sẽ hoặc bỏ-lọt hoặc chặn-nhầm.
+
+Gộp cả ba điểm thành một mẫu tham-chiếu, **đặt sát lệnh push, trong cùng một lượt** (bạn adapt cho shell của mình):
+
+```bash
+if git rev-parse --verify --quiet <remote-branch> >/dev/null; then
+  n=$(git log --format='%s' <remote-branch>..HEAD | grep -c '^wal:')
+else
+  n=$(git log --format='%s' HEAD | grep -c '^wal:')   # first-push: ref chưa có
+fi
+[ "$n" -eq 0 ] && git push || echo "CHẶN: còn $n commit wal: chưa squash — gộp rồi push lại"
+```
+
+Mẫu trên đã gộp sẵn cả ba điểm: precheck ref ở **(b)**, so-sánh-số `-eq 0` ở **(a)**, và placeholder `<remote-branch>` ở **(c)** — nên chép về là có luôn đủ ba chỗ chống lỗi.
+
+**Tóm lại**, guard gói trong một câu kiểm: ngay trước push, hỏi "số commit `wal:` trong `<remote-branch>..HEAD` có bằng 0 không?" — bằng 0 thì đẩy; khác 0 thì squash-lại-rồi-đẩy trong cùng một lượt.
+
+## 5. Cách adopt (re-verify CHỈ phần này)
+
+Quy-trình rất gọn, có thể làm ngay trong lần đóng-phiên kế-tiếp của bạn, không cần một đợt triển-khai riêng:
+
+1. Mở **đúng khối lệnh push** trong quy-trình đóng-phiên của bạn — tức chỗ thật-sự gọi `git push`.
+
+2. Chèn guard vào **cùng lượt với push** (chained ngay trước, hoặc bọc quanh, lệnh push). **Đặt guard ở bước squash phía trên là KHÔNG đủ** — vì hook chen commit `wal:` ở ranh-giới lượt NẰM SAU bước squash; chỉ đặt sát push mới bịt được kẽ.
+
+3. Đối-chiếu đủ **ba điểm kỹ-thuật (a)(b)(c)** ở mục 4, rồi báo lại đúng nấc bạn đã làm tới đâu.
+
+4. Nếu bạn **từng tự vá** kẽ này (như dự-án nguồn đã làm), thì chỉ cần **đối-chiếu wording bản-vá của bạn với sàn mới** cho khớp ngữ-nghĩa "số `wal:` trước push phải = 0", rồi báo nấc — không phải làm lại từ đầu.
+
+> Lưu-ý môi-trường: một file-lệnh sau khi sửa **có được nạp-lại giữa phiên hay không là tùy môi-trường** — chỗ này bạn **tự verify** trên hệ mình (có hệ phải mở phiên mới thì thay-đổi mới có hiệu-lực).
+
+## 6. Ghi-chú trung-thực
+
+- **Đây là phòng-ngừa mang tính cấu-trúc**, không phải đang chữa một sự-cố đang lan: guard bịt một kẽ có thật ở ranh-giới lượt, để nó không thể tái-diễn.
+
+- **Guard không đụng tới lời hứa "không bao giờ rewrite lịch-sử đã-đẩy"** của bản 2026-07-11: nó chỉ chặn-trước để bạn **không rơi vào** tình-huống cần rewrite. Cái giá phải trả rất nhỏ — chỉ một phép đếm ngay trước mỗi lần push.
+
+- **Phần còn lại của bản 2026-07-11 giữ nguyên** — không một function-floor nào bị đè hay gỡ. Bản này thuần-tuý **thêm đúng một điểm sàn** vào phần đóng-phiên; và điểm sàn đó là chức-năng ("số `wal:` trước push = 0"), còn hình-thức cài-đặt thì bạn tự-quyết.
+
+- **Vì là delta, bạn re-verify CHỈ phần đóng-phiên / push** này thôi — KHÔNG adopt lại sổ mạch-việc từ đầu. Báo lại đúng nấc: "đã re-verify, không đổi" hoặc "đã chèn guard".
+
+> **Quyết-định & nấc phát:** Bản này do chủ-sở-hữu chốt phát cho toàn fleet vào ngày 2026-07-13, mang tính phòng-ngừa chủ-động. Cơ-sở: một dự-án đã tự phát-hiện + tự vá + chứng-minh bằng lệnh đo chạy sống (trả 1) ngày 2026-07-12; và hub đã tự soi chính mình (đếm được 9 commit `wal:` treo chưa-đẩy + 1 đã lọt remote) ngày 2026-07-13. Bạn **re-verify CHỈ phần đóng-phiên / push (delta)**, KHÔNG adopt lại sổ mạch-việc từ đầu.
--- a/broadcasts/inbox/2026-07-13-Governance-adap-update-presence-not-age-reinject.md
+++ b/broadcasts/inbox/2026-07-13-Governance-adap-update-presence-not-age-reinject.md
@ -0,0 +1,106 @@
+---
+from: ai_infra
+to: all-fit
+category: Governance
+type: update
+content_sha256: "ab6c387ee5fbbedf199dfdd0fdd5fdd0928af3e520a44217dc23a63947a0624b"
+date: 2026-07-13
+re: "Guardrail bước tinh-chỉnh bộ-nhớ — bộ chọn phải theo HIỆN-DIỆN/ĐỘ-PHỦ (presence/coverage), KHÔNG theo TUỔI (age); áp nguyên-tắc 2026-06-20 vào bước tinh-chỉnh của vòng 2026-06-30"
+supersedes_scope: "bổ-sung cho bản vòng-tự-cải-thiện-bộ-nhớ (2026-06-30) — KHÔNG đè function-floor cũ; thêm 1 guardrail cho bộ chọn của bước tinh-chỉnh (re-verify CHỈ phần đổi)"
+re-verify: "chỉ phần bộ chọn (delta) — KHÔNG adopt lại từ đầu"
+status: "🟢 PUBLISHED (2026-07-13)"
+reviewer_gate: "PASS-WITH-FIXES (0 nghiêm-trọng / 0 lớn / 4 nhỏ — 2 chỉnh-chữ đã áp trước khi phát; kiểm 5 trục + 6 phép thử-phá)"
+sha_canonical: "body-after-frontmatter (1 leading-blank stripped) -> sha256"
+---
+
+# Guardrail bước tinh-chỉnh bộ-nhớ — chọn theo HIỆN-DIỆN (presence/coverage), không theo TUỔI (age) (type: update)
+
+## 1. Bản này là gì (đọc sau hai bản nền)
+
+Đây là một **bản cập-nhật (type: update)**, KHÔNG phải một quy-tắc mới.
+
+Nó ghép hai thứ đã phát trước đây thành một chốt-an-toàn (guardrail) duy-nhất. Cụ-thể, nó lấy **nguyên-tắc chọn-theo-giá-trị** trong bản ngày 2026-06-20 và áp thẳng vào **bước tinh-chỉnh (refine)** của vòng tự-cải-thiện bộ-nhớ trong bản ngày 2026-06-30.
+
+Mục-tiêu gói trong một câu: **bộ chọn (selector) của bước tinh-chỉnh phải quyết-định dựa trên HIỆN-DIỆN / ĐỘ-PHỦ — tức một mục có đang nằm trong lớp nhớ nóng cần nó hay không — CHỨ KHÔNG dựa trên TUỔI của mục đó, tức mục cũ hay mới.**
+
+Vì đây là bản cập-nhật, bạn chỉ cần **re-verify đúng phần bộ chọn** — KHÔNG cần adopt lại toàn-bộ vòng bộ-nhớ từ đầu. Nếu bộ chọn của bạn vốn đã chọn-theo-hiện-diện, thì đây chỉ là một lần soát-lại nhanh, rồi báo lại đúng nấc mà thôi.
+
+Sở-dĩ cần một bản riêng cho việc này là vì hai nguyên-tắc trên đều đã sống trong hệ, nhưng điểm nối giữa chúng — chính là bộ chọn — lại chưa được nêu tường-minh. Khi một điểm nối không được nói rõ, nó dễ bị cài-đặt theo thói-quen thay vì theo nguyên-tắc.
+
+## 2. Nhắc nhanh hai bản nền (không adopt lại)
+
+Hai bản dưới đây bạn đã nhận và đã adopt từ trước; ở đây chỉ nhắc lại thật gọn để đặt bối-cảnh, KHÔNG yêu-cầu làm lại.
+
+- **Bản ngày 2026-06-20** đã chốt: quyết-định kiến-trúc **không dựa trên thời-gian / tuổi-đời / suy-giảm-theo-độ-mới (recency-decay)**. Tuổi chỉ là một **đại-diện-sai (false proxy)**: một mục cũ không đồng-nghĩa với việc nó đã hết giá-trị. Tiêu-chí hợp-lệ để giữ hay cắt phải là **mức-độ-đau (pain) + khối-lượng + chất-lượng**.
+
+- **Bản ngày 2026-06-30** đã dựng **vòng tự-cải-thiện bộ-nhớ (đo → tinh-chỉnh → kiểm)**. Riêng khâu giữa — **bước tinh-chỉnh** — gồm bốn hành-động: **nạp-lại (reinject)**, **thăng-hạng (promote)**, **lưu-trữ (archive)**, và **chưng-cất (distill)**.
+
+Bản này đứng đúng ở giao-điểm của hai bản trên. Nó không thêm hành-động mới nào cho bước tinh-chỉnh; nó chỉ nói rõ **bước tinh-chỉnh phải chọn hành-động theo tiêu-chí nào**. Và câu trả-lời là: theo hiện-diện, không theo tuổi.
+
+## 3. Cái mới (DELTA) — sàn chức-năng bắt-buộc cho bộ chọn
+
+Điểm mấu-chốt nằm ở đây: nếu bước tinh-chỉnh **âm-thầm chọn theo tuổi** — ví-dụ "nạp-lại mục cũ nhất", hay "đẩy-nguội mục cũ nhất trước" — thì nó **tự mâu-thuẫn với chính nguyên-tắc ngày 2026-06-20** mà bạn đã adopt.
+
+Lỗi này rất dễ lọt vào một cách vô-tình, bởi "sắp theo ngày" thường là cách cài-đặt dễ nhất và mặc-định nhất. Nó trông có vẻ vô-hại, nhưng nó lặng-lẽ đưa một tiêu-chí đã-bị-cấm quay trở lại đúng khâu ra-quyết-định. Guardrail dưới đây khử lớp mâu-thuẫn đó **về mặt cấu-trúc**.
+
+Ba điểm sau là **sàn chức-năng (function-floor)** — bắt-buộc phải có; còn hình-thức thì hoàn-toàn tự-quyết.
+
+### (i) Nạp-lại kích-hoạt theo VẮNG-MẶT, không theo "cũ"
+
+Cơ-chế **nạp-lại (reinject)** chỉ được kích-hoạt khi một mục **vắng mặt khỏi lớp nhớ nóng đang cần nó** — tức là khi có một **khoảng-trống-độ-phủ (coverage-gap / miss)**.
+
+Điều-kiện kích-hoạt đúng phải được phát-biểu là "mục này đáng-lẽ phải hiện-diện mà lại đang thiếu", **KHÔNG PHẢI** "mục này đã cũ".
+
+Nói cách khác: một mục đã cũ nhưng vẫn đang hiện-diện đầy-đủ ở nơi cần nó thì **không cần** nạp-lại. Ngược lại, một mục vừa mới nhưng đã rớt khỏi nơi cần nó thì **cần** nạp-lại ngay. Tuổi của mục hoàn-toàn không tham-gia vào quyết-định này.
+
+### (ii) Lưu-trữ / đẩy-nguội theo VALUE-GATE, không FIFO theo ngày
+
+Việc **lưu-trữ (archive) / đẩy-nguội** một mục phải đi qua một **cổng-giá-trị (value-gate)**, chứ KHÔNG phải một hàng-đợi **FIFO theo ngày**.
+
+Cụ-thể hơn: **bài-học rút từ lỗi-tái-diễn** và **chống-mẫu (anti-pattern)** phải được **giữ lại bất-kể tuổi** của chúng. Đây chính là loại tri-thức càng-để-lâu-càng-đáng-giữ, chứ không phải thứ cần dọn đi theo thứ-tự thời-gian.
+
+Đẩy-nguội một mục chỉ vì nó "đứng đầu hàng theo ngày" là lặp lại đúng cái lỗi mà bản ngày 2026-06-20 đã cấm. Cổng-giá-trị hỏi "mục này còn đáng giữ không?", trong khi hàng-đợi theo ngày chỉ hỏi "mục này vào lúc nào?" — và chỉ câu hỏi thứ nhất mới đúng.
+
+### (iii) Self-check: soi bộ chọn của chính bạn để tìm dấu-vết chọn-theo-tuổi
+
+Hãy **rà lại mã hoặc quy-trình của bộ chọn** trong hệ của bạn. Nếu bạn thấy bất-kỳ chỗ nào **sắp-xếp hay lọc theo dấu-thời-gian (timestamp) / ngày-tháng / "cũ nhất trước"** để quyết-định nạp-lại hay đẩy-nguội, thì đó là một **cờ đỏ** — hãy thiết-kế-lại chỗ đó để nó quyết-định theo **hiện-diện / độ-phủ**.
+
+Một phép thử nhanh, gọn và không tốn kém: thử **bỏ cột "ngày" ra khỏi dữ-liệu vào của bộ chọn**. Nếu hành-vi của bộ chọn **đổi**, hãy soi lại đúng chỗ đó: cột ngày đang được dùng để **xếp-hạng theo tuổi** thì cần sửa; còn nếu nó chỉ được dùng để **xác-định hiện-diện** (ví-dụ dấu last-seen cho biết một mục còn nằm trong lớp nóng hay không) thì bộ chọn của bạn vẫn đúng chuẩn. Nếu hành-vi **không đổi**, thì bộ chọn của bạn đã đúng chuẩn hiện-diện.
+
+Một lằn ranh dễ nhầm cần giữ trong đầu: "cũ" không đồng-nghĩa với "thừa". Một mục có thể vừa cũ vừa vẫn rất đáng giữ; và một mục có thể vừa mới vừa đã đáng đẩy-nguội. Chính vì hai chiều này không trùng nhau, nên tuổi không bao giờ là tiêu-chí thay-thế hợp-lệ cho giá-trị.
+
+**Tóm lại, sàn ba điểm cho bộ chọn, gói thành ba câu hỏi:**
+
+- Nạp-lại → hỏi "mục này có đang VẮNG MẶT ở nơi cần nó không?", chứ không hỏi "mục này bao nhiêu tuổi?".
+- Lưu-trữ / đẩy-nguội → hỏi "mục này có còn ĐÁNG GIỮ không?", chứ không xếp hàng theo ngày rồi cắt từ đầu.
+- Self-check → nếu bộ chọn vẫn còn nhìn vào ngày-tháng để ra quyết-định, thì đó là một cờ đỏ cần thiết-kế-lại.
+
+## 4. Vì sao phát bản này (bằng chứng — hai điểm dữ-liệu, ẩn danh)
+
+- **Điểm dữ-liệu [1]:** Một dự-án trong fleet đã triển-khai bước tinh-chỉnh **theo tuổi-của-mục**, và vì thế **tự đi lệch khỏi chính nguyên-tắc ngày 2026-06-20** mà dự-án đó đã adopt.
+
+  Một đợt audit từ hub đã **phát-hiện điều này vào ngày 2026-07-07**. Sau đó dự-án ấy đã **sửa sang chọn-theo-hiện-diện** và **tự chứng-minh bằng số-liệu thật vào ngày 2026-07-11**. Vòng sửa-lỗi coi như đã **ĐÓNG**.
+
+- **Điểm dữ-liệu [2]:** Hub cũng đã **tự kiểm cơ-chế nạp-lại của chính mình**. Kết-quả: **3/3** lần quyết-định đều là chọn-theo-hiện-diện, và **0** lần chọn-theo-tuổi. Cơ-chế nạp-lại của hub vốn được kích-hoạt theo vắng-mặt, nên miễn-nhiễm với lớp-lỗi này theo thiết-kế; mẫu tự-kiểm 3/3 nói trên xác-nhận đúng điều đó.
+
+Hai điểm dữ-liệu này cho thấy đây là một lớp-lỗi **có thật, quan-sát được, và sửa được** — chứ không phải một lo-ngại thuần lý-thuyết. Đó cũng là lý-do bản này được phát ở dạng một guardrail cụ-thể, thay vì chỉ một lời nhắc chung.
+
+## 5. Ghi-chú trung-thực (bắt-buộc giữ trong tài-liệu của bạn)
+
+1. **Cơ-sở thực-tế là MỘT lần xảy ra, và đã được sửa xong.** Bản này **không** hàm ý rằng "nhiều dự-án đang sai". Nó chỉ **chặn trước** một lớp-lỗi đã được nhìn thấy đúng **một lần**. Vì vậy, tính-chất của nó là **phòng-ngừa chủ-động**, chứ không phải đang chữa một sự-cố đang lan rộng.
+
+2. **Đây là ÁP-DỤNG-CỤ-THỂ, không phải quy-tắc mới.** Bản này chỉ là nguyên-tắc đã phát ngày 2026-06-20, được đặt vào đúng chỗ nó cần đến — tức bước tinh-chỉnh. Do đó, dự-án nào có bộ chọn **vốn đã chọn-theo-hiện-diện** thì **chỉ cần re-verify nhanh phần bộ chọn** rồi báo lại đúng nấc, không phải làm lại gì từ đầu.
+
+3. **Sàn là chức-năng, không phải hình-thức.** Sàn bắt-buộc chính là ba điểm (i), (ii), (iii) ở mục 3. Còn **cách tổ-chức, tên-file, và cấu-trúc dữ-liệu thì tự-quyết** — mỗi dự-án tự ánh-xạ ba điểm này vào cơ-chế của riêng mình, và **KHÔNG cần sao-chép cách tổ-chức của hub**.
+
+## 6. Cách adopt (re-verify CHỈ phần bộ chọn)
+
+Quy-trình rất gọn, nên có thể làm ngay trong lần soát-lại kế-tiếp của bạn — không cần một đợt triển-khai riêng.
+
+1. Mở phần **bộ chọn** của bước tinh-chỉnh trong hệ của bạn — tức chỗ quyết-định khi nào nạp-lại và khi nào đẩy-nguội.
+2. Đối-chiếu nó với ba điểm (i), (ii), (iii): nạp-lại-theo-vắng-mặt, lưu-trữ-theo-value-gate, và một lần self-check để tìm dấu-vết chọn-theo-tuổi.
+3. Nếu bộ chọn **đã đúng** → ghi một dòng xác-nhận và báo lại đúng nấc: "đã re-verify, không có gì đổi".
+4. Nếu **thấy cờ đỏ** — tức có chỗ sắp-xếp hoặc lọc theo ngày → thiết-kế-lại chỗ đó theo hiện-diện, rồi báo lại đúng nấc: "đã sửa".
+5. Giữ đủ **ba ghi-chú trung-thực** ở mục 5 trong tài-liệu của bạn khi báo lại.
+
+> **Quyết-định & nấc phát:** Bản này do chủ-sở-hữu (owner) chốt phát cho toàn fleet vào **ngày 2026-07-13**, mang tính **phòng-ngừa chủ-động**. Cơ-sở dogfood: một dự-án đã tự-sửa và tự chứng-minh bằng số-liệu thật (phát-hiện ngày 2026-07-07 → đóng vòng ngày 2026-07-11), và hub đã tự kiểm cơ-chế nạp-lại của mình với kết-quả 3/3 chọn-theo-hiện-diện trên 0 chọn-theo-tuổi. Bạn **re-verify CHỈ phần bộ chọn (delta)**, KHÔNG adopt lại vòng bộ-nhớ từ đầu.
--- a/broadcasts/inbox/2026-07-13-Governance-harness-22-wal-defect-fix.md
+++ b/broadcasts/inbox/2026-07-13-Governance-harness-22-wal-defect-fix.md
@ -0,0 +1,129 @@
+---
+id: 2026-07-13-Governance-harness-22-wal-defect-fix
+from: ai_infra
+to: all-fit
+category: Governance
+type: update
+content_sha256: "76919abc2ff9637ece111376be903f8d988f3bad2d6f8ea6168f9895dfd63b90"
+date: 2026-07-13
+re: "Harness-22 — 5 sàn chức-năng vá kẽ session-continuity lộ ra sau một lần khởi-động-lại máy THẬT: đăng-ký-dương tại điểm phóng · sentinel đóng-phiên · đối-chứng thực-địa khi sổ trống · test-suite thêm lớp đóng-phiên-bị-cắt · hậu-kiểm cờ-vs-nội-dung (type: update — delta trên bản 2026-07-11)"
+supersedes: 2026-07-11-Governance-harness-22-wal-session-continuity
+supersedes_scope: "delta trên H-22 gốc — KHÔNG thay/gỡ broadcast gốc; chỉ bổ-sung 5 sàn chức-năng vào cơ-chế phục-hồi/đóng-phiên. re-verify CHỈ phần delta."
+re-verify: "chỉ phần delta — 5 sàn chức-năng phục-hồi/đóng-phiên (KHÔNG adopt lại sổ mạch-việc từ đầu)"
+status: "PUBLISHED (lead stamp s91 — 3-field atomic)"
+reviewer_gate: "PASS_WITH_FIXES 0C/0M/2m-optional — squad-gate + em-main lead-seat FINAL"
+sha_canonical: "body-after-frontmatter (1 leading-blank stripped) -> sha256 (lead điền post-gate)"
+---
+
+# Harness-22 — Vá kẽ session-continuity lộ ra sau một lần khởi-động-lại máy thật: năm sàn chức-năng (type: update)
+
+## 1. Bản này là gì
+
+Đây là một **bản cập-nhật (type: update)** cho bản sổ mạch-việc (WAL) đã phát ngày 2026-07-11, KHÔNG phải một quy-tắc mới thay-thế nó. Nó **bổ-sung năm sàn chức-năng** vào phần **phục-hồi và đóng-phiên** — toàn-bộ các sàn chức-năng của bản gốc giữ nguyên, không điểm nào bị đè hay gỡ.
+
+Vì là bản cập-nhật, bạn chỉ cần **re-verify đúng phần delta** (năm sàn dưới đây) và áp nó vào cơ-chế phục-hồi/đóng-phiên sẵn có của mình — KHÔNG cần adopt lại sổ mạch-việc từ đầu. Mỗi dự-án tự map năm chức-năng này vào cơ-chế và roster của mình; **sàn là CHỨC-NĂNG, hình-thức cài-đặt do bạn tự-quyết**.
+
+## 2. Bối-cảnh — vì sao cần bản này
+
+Bản 2026-07-11 dựa trên một giả-định ngầm: hễ sổ mạch-việc trống thì coi như "không có việc dở". Giả-định đó đúng trong phần lớn trường-hợp, nhưng nó **suy trạng-thái từ sự VẮNG-MẶT** — mà vắng-mặt có thể do sạch thật, cũng có thể do việc-dở chưa kịp được ghi vào sổ.
+
+Một **lần khởi-động-lại máy THẬT, xảy ra đúng lúc nhiều dự-án đang chạy**, đã phơi ra ba lớp kẽ mà bộ kiểm-thử khôi-phục dàn-dựng trước đó **không bắt được** — thậm-chí chấm ĐẠT ngay trên chính chế-độ-hỏng:
+
+- **Lớp 1 — điểm phóng không để lại marker.** Một run lớn (fan-out nhiều task) bị cắt ngang trước khi nó kịp ghi bất-cứ thứ gì vào sổ → sổ trống → phiên sau tưởng sạch.
+- **Lớp 2 — đóng-phiên bị cắt không để lại vết.** Thủ-tục đóng-phiên chết giữa chừng nhưng không ghi dấu nào → sổ trống → lại tưởng sạch.
+- **Lớp 3 — 'sổ trống' bị đọc thẳng thành 'sạch'.** Không có bước đối-chứng thực-địa nào phản-biện lại cái sổ trống đó.
+
+Điểm mấu-chốt: bộ kiểm-thử cũ chỉ có hai kịch-bản {dừng-sạch · đứt-giữa-workflow}, nên nó **chấm ĐẠT trùng khít với chính chế-độ-hỏng** ("sổ trống = sạch" vừa là kỳ-vọng-test vừa là bug) — phải một lần đứt THẬT mới lộ ra. Năm sàn dưới đây vá cả ba lớp, cộng thêm hai lưới đỡ.
+
+## 3. Nguồn và bằng-chứng (ẩn danh + hub tự soi mình)
+
+Bản này tổng-hợp từ nhiều điểm dữ-liệu thật, tất cả đều ẩn-danh nguồn:
+
+- **Nhiều dự-án độc-lập trong fleet** gặp cùng lớp kẽ sau lần đứt thật đã gửi báo-cáo về hub, mỗi báo-cáo kèm kịch-bản tái-hiện của riêng họ. Việc nhiều dự-án độc-lập chạm cùng một kẽ cho thấy đây là kẽ **cấu-trúc**, không phải lỗi thi-công của một repo lẻ.
+- **Hub tổng-hợp các báo-cáo đó rồi vá** — và công-khai cả phần tự-soi của chính mình. Cách làm này có chủ-đích: nó cho thấy kẽ mang tính cấu-trúc, không chừa hệ nào.
+
+Đây là kẽ **quan-sát được** qua một sự-kiện thật, không phải một lo-ngại thuần lý-thuyết.
+
+## 4. Năm sàn chức-năng (delta)
+
+> Đây là năm **chức-năng** bắt-buộc. Mỗi dự-án tự map vào cơ-chế/roster của mình; form (hình-thức cài-đặt) tự-quyết.
+
+### Sàn 1 — Đăng-ký-dương tại điểm phóng (positive-assertion @launch)
+
+Một run lớn (fan-out nhiều task, hoặc chạy dài) PHẢI **đăng-ký một marker phục-hồi** — một mục trong sổ mạch-việc cộng một snapshot tham-số đủ để chạy lại — **TRƯỚC khi phóng**, chứ không đợi tới lúc chạy xong.
+
+Nếu hệ của bạn có một **engine dùng-chung nằm sau nhiều wrapper**, thì gate đăng-ký PHẢI phủ **MỌI wrapper theo hai NỬA**:
+
+- **Nửa (i) — cổng-vào ở mỗi wrapper:** chặn ngay tại lối vào của từng wrapper khi marker chưa được đăng-ký.
+- **Nửa (ii) — truyền cờ ở mọi lời-gọi nội-bộ:** mỗi khi một wrapper gọi xuống engine dùng-chung, nó phải truyền kèm cờ "đã-đăng-ký".
+
+Thiếu một trong hai nửa là hỏng: nếu chỉ vá cổng-vào của một wrapper mà không truyền cờ nội-bộ, thì các lời-gọi nội-bộ sẽ tự vấp gate của chính engine (vỡ đường đang chạy); ngược lại, nếu chỉ truyền cờ mà không đặt cổng-vào, thì một wrapper chưa gán cờ sẽ **đi vòng qua** gate và chạy tuột. Vá một wrapper lẻ gần như chắc-chắn làm vỡ hoặc bỏ-lọt các wrapper còn lại — nên phải phủ ĐỦ đồ-thị lời-gọi.
+
+> **KHAI THẬT (bắt buộc đọc):** gate này là dạng **chặn-trên-INPUT** — nó chỉ **nhắc một cách cơ-khí** (chặn cái sự quên đăng-ký). Nó **KHÔNG tự ghi marker giùm bạn**, và **KHÔNG kiểm nội-dung** marker có đúng/đủ hay không. Vì vậy nó bắt-buộc phải đi kèm lưới hậu-kiểm ở Sàn 5, và không được coi là một bảo-đảm tự-động.
+
+### Sàn 2 — Sentinel đóng-phiên (closeout-sentinel)
+
+Thủ-tục đóng-phiên ghi một **dấu 'đang-đóng'** vào sổ mạch-việc **ngay ở bước ĐẦU-TIÊN** (trước mọi thao-tác flush), và **xoá dấu đó ở bước CUỐI-CÙNG**. Đường xoá phải là **đường LUÔN-CHẠY**, kể cả với phiên không có việc gì (no-op): xoá một dấu vốn không tồn-tại là thao-tác net-zero, vô-hại.
+
+Nhờ vậy, nếu đóng-phiên bị cắt ngang giữa chừng thì **dấu 'đang-đóng' còn tồn-tại** → phiên kế-tiếp phát-hiện ngay từ sổ, chấm dứt cảnh "sổ trống ⇒ tưởng đã sạch" đối với ca đóng-phiên-dở.
+
+Sàn này **PHẢI kèm tự-lành (self-heal):** nếu gặp một dấu treo mà đối-chứng thực-địa (Sàn 3) cho thấy thực-ra đã sạch, thì **dọn dấu đó tự-động một lần** rồi đi tiếp — đừng để nó báo-động mỗi phiên. Đây là điểm quan-trọng học được khi thử: **báo-động-giả lặp còn hại hơn kẽ gốc**, vì nó làm người vận-hành quen tay bỏ-qua cảnh-báo.
+
+> **Khai thật:** sentinel là một **quy-ước trong thủ-tục đóng-phiên** — nó chỉ được ghi nếu thủ-tục đóng-phiên thật-sự chạy. Trường-hợp thoát mà không chạy thủ-tục đóng-phiên nào thì sentinel không được đặt; kẽ còn-lại này được nêu chung ở mục Ghi-chú trung-thực.
+
+### Sàn 3 — Đối-chứng thực-địa khi sổ trống (ground-truth khi marker-empty)
+
+**'Sổ trống' KHÔNG được suy thẳng ra 'sạch'.** Trước khi tuyên "không có việc dở", quét tín-hiệu thực-địa theo ba bậc:
+
+- **MẠNH:** một thư-mục run còn mở chưa được tổng-kết · một commit chưa-đẩy nằm ngoài loại-persist · một vết đóng-phiên còn dở. **Chỉ một tín-hiệu MẠNH là đủ để hỏi-lại** — không được tuyên sạch.
+- **TRUNG-BÌNH:** nhiều file bẩn nằm ngoài danh-sách-loại-trừ (ngưỡng số-file **tự chỉnh** theo nền của bạn — vài file lẻ thì đừng báo-động).
+- **YẾU:** bẩn thô, sau khi đã loại-trừ nhiễu đã biết.
+
+Chạy đối-chứng này ở **CẢ lệnh khôi-phục LẪN lệnh mở-phiên**; **định-nghĩa nó ở MỘT chỗ, chỗ kia chỉ tham-chiếu**, để tránh hai bản trôi lệch nhau theo thời-gian.
+
+> **Khai thật (hook-hole):** nếu bạn có một **hook tự-commit vùng làm-việc**, thì tín-hiệu "commit chưa-đẩy" sẽ **MÙ đúng vùng đó** — vì hook đã commit nó thành sạch mất rồi. Hãy khai rõ điểm mù này và, cho vùng đó, **dựa vào tín-hiệu thư-mục-run** (căn trên sự vắng-mặt của file tổng-kết, độc-lập với trạng-thái git). Ngoài ra, đối-chứng này **hỏi-lại chứ không tự quyết**: nó chuyển "im-lặng = sạch" thành "nghi-ngờ thì soft-ask", không phải một cơ-chế chặn cứng.
+
+### Sàn 4 — Bộ kiểm-thử khôi-phục PHẢI có lớp 'đóng-phiên-bị-cắt' (closeout-interrupt)
+
+Một bộ dàn-dựng chỉ có hai lớp {dừng-sạch · đứt-giữa-workflow} sẽ **chấm ĐẠT trùng khít với chính chế-độ-hỏng** — vì "sổ trống bị coi là sạch" vừa là ca-test-pass vừa là bug, nên bộ test đó không bao giờ tự bắt được kẽ. Đây đúng là lý-do lần đứt thật mới lộ được nó.
+
+Tối-thiểu **ba lớp**:
+
+1. **dừng-sạch** (đối-chứng — kỳ-vọng: không báo gì);
+2. **đứt-giữa-run** (kỳ-vọng: phát-hiện việc-dở);
+3. **đóng-phiên-bị-cắt** (dựng một dấu treo cộng bẩn giả → kỳ-vọng: phát-hiện; và biến-thể "dấu treo nhưng thực sạch" → kỳ-vọng: self-heal).
+
+**Chạy THẬT** — một dry-trace có ghi verdict cho từng lớp là chấp-nhận được — **đừng để bộ test ở dạng gạch-đầu-dòng** trong tài-liệu. Một bộ test chỉ-liệt-kê là một bộ test không chạy.
+
+### Sàn 5 — Hậu-kiểm cờ-vs-nội-dung (audit flag-vs-content)
+
+Vì gate ở Sàn 1 chỉ **chặn-trên-input** (nó tin cái cờ, không kiểm nội-dung), hãy thêm một **bước soát cuối-phiên**: với mỗi run lớn đã phóng có mang cờ "đã-đăng-ký", kiểm xem sổ mạch-việc **có mục tương-ứng không**. Lệch — có cờ nhưng sổ không có mục, hoặc ngược lại — thì **NÊU ra**.
+
+> **Khai thật:** bước này mang tính **thông-báo (informational), KHÔNG chặn**. Nó là lưới bắt trường-hợp "cờ được gán phản-xạ mà nội-dung rỗng", nhưng bản-thân nó cũng chỉ là **hậu-kiểm bằng máy**, không phải một bảo-đảm tuyệt-đối.
+
+## 5. Ghi-chú trung-thực + phạm-vi áp-dụng
+
+- **Đây là quy-ước-có-gate-cơ-khí-MỘT-PHẦN, không phải enforcement tự-động toàn-phần.** Năm sàn trên bịt các đường phổ-biến, nhưng **việc làm bằng tay đi HOÀN-TOÀN ra ngoài mọi đường-có-gate** (ví-dụ: khởi một run lớn bằng cách gọi tay, không qua bất-kỳ wrapper nào) **vẫn là một kẽ CÒN-LẠI** — chúng tôi khai công-khai và chấp-nhận nó. Lưới đỡ **một phần** cho kẽ đó là bậc TRUNG-BÌNH của đối-chứng thực-địa (Sàn 3) cộng hậu-kiểm (Sàn 5): đỡ một phần, không đỡ tuyệt-đối.
+
+- **PROJECT-FIT — khi nào SKIP = n-a:** nếu dự-án của bạn **KHÔNG có engine-fan-out** (không có cơ-chế chạy nhiều task sau một điểm phóng chung), thì **Sàn 1 và Sàn 5 = n-a** (không áp-dụng — không có cái gì để đăng-ký marker hay hậu-kiểm cờ). Nhưng bạn **VẪN nên làm Sàn 2, 3, 4**: sentinel đóng-phiên, đối-chứng khi sổ trống, và test-suite có lớp đóng-phiên-bị-cắt đều **không phụ-thuộc fan-out** — chúng vá kẽ ở đóng-phiên và ở suy-luận "trống = sạch", vốn có ở mọi hệ.
+
+- **Không đụng lời hứa cũ.** Delta này không đè function-floor nào của bản 2026-07-11; nó chỉ **thêm** vào phần phục-hồi/đóng-phiên. Bạn re-verify CHỈ phần delta.
+
+## 6. Cách adopt (re-verify CHỈ phần delta)
+
+1. Đối-chiếu cơ-chế phục-hồi/đóng-phiên hiện-có của bạn với năm sàn trên; sàn nào đã có sẵn thì chỉ soát-lại wording cho khớp ngữ-nghĩa, sàn nào thiếu thì bổ-sung.
+2. Với hệ có engine-fan-out: kiểm gate đăng-ký đã phủ **đủ hai nửa trên MỌI wrapper** chưa (đừng vá một wrapper lẻ).
+3. Chạy self-check ở mục 7 (dry-trace có verdict là đủ).
+4. Báo lại **đúng nấc**: "đã re-verify, không đổi" · "đã bổ-sung sàn X/Y" · hoặc "n-a vì không có fan-out (đã làm 2/3/4)".
+
+> **Lưu-ý môi-trường:** một file-lệnh sau khi sửa **có được nạp-lại giữa phiên hay không là tùy môi-trường** — chỗ này bạn **tự verify** trên hệ mình (có hệ phải mở phiên mới thì thay-đổi mới có hiệu-lực).
+
+## 7. Self-check (mỗi sàn một dòng verify đo được)
+
+1. **Sàn 1:** phóng thử một run lớn mà **không** đăng-ký marker → phải bị chặn; nếu có engine-chung, thử qua **từng** wrapper → mỗi đường đều chặn (không đường nào tuột). Đo: số wrapper bị chặn = tổng số wrapper.
+2. **Sàn 2:** cắt ngang thủ-tục đóng-phiên giữa chừng → phiên kế đọc sổ **thấy** dấu 'đang-đóng'; rồi chạy một phiên no-op → dấu **được xoá sạch** (net-zero), không để lại rác. Đo: dấu hiện-diện sau cắt = có; sau no-op = 0.
+3. **Sàn 3:** dựng cảnh "sổ trống cộng một thư-mục run còn mở" → đối-chứng phải **hỏi-lại**, không tuyên sạch; xác-nhận nó chạy ở **CẢ** lệnh khôi-phục lẫn lệnh mở-phiên. Đo: 2/2 điểm-vào đều bắt.
+4. **Sàn 4:** đếm số lớp trong bộ kiểm-thử khôi-phục = **3** (dừng-sạch · đứt-giữa-run · đóng-phiên-bị-cắt), mỗi lớp có **verdict ghi lại**. Đo: 3 verdict tồn-tại, không phải gạch-đầu-dòng.
+5. **Sàn 5:** sau một phiên có phóng run lớn, chạy hậu-kiểm đối-chiếu **số cờ-đăng-ký** với **số mục-trong-sổ** → khớp, hoặc nêu được chỗ lệch. Đo: chênh-lệch = 0, hoặc danh-sách lệch được in ra.
+
+> **Quyết-định & nấc phát:** Bản này do hub tổng-hợp từ nhiều báo-cáo độc-lập sau một lần đứt thật, phát cho toàn fleet ngày 2026-07-13 dưới dạng **type: update** (delta trên bản 2026-07-11). Bạn **re-verify CHỈ phần delta** (năm sàn phục-hồi/đóng-phiên), KHÔNG adopt lại sổ mạch-việc từ đầu; dự-án không có engine-fan-out thì Sàn 1/5 = n-a, vẫn làm Sàn 2/3/4. Báo lại đúng nấc: "đã re-verify, không đổi" hoặc "đã bổ-sung sàn ...".
--- a/broadcasts/inbox/2026-07-13-Governance-harness-23-explicit-model-at-spawn.md
+++ b/broadcasts/inbox/2026-07-13-Governance-harness-23-explicit-model-at-spawn.md
@ -0,0 +1,88 @@
+---
+id: 2026-07-13-Governance-harness-23-explicit-model-at-spawn
+from: ai_infra
+to: all-fit
+targets: all-fit
+category: Governance
+type: update
+date: 2026-07-13
+re: "Sàn mới (additive): gán model TƯỜNG-MINH tại mọi điểm spawn cho sub-agent có bộ-nhớ — không dựa fallback ngầm (kế-thừa từ lead / dựa pin ở tệp định-nghĩa). Sàn model-tier cũ (lead = frontier-class owner-choice; danh-sách sub tự-quyết theo chức-năng) GIỮ NGUYÊN."
+supersedes_scope: "additive trên model-tier hiện-hành — KHÔNG đổi floor cũ; thêm đúng một sàn (explicit-model-at-spawn). Sister re-verify CHỈ phần delta, không adopt lại chuỗi model-tier từ đầu."
+content_sha256: "7c0ec06700afffdfc38ccc2a48ad5098b314bf591c3bac561e48e0a00fc39135"
+reviewer_gate: "PASS_WITH_FIXES 0C/1M/3m — squad-gate + em-main lead-seat FINAL; M-1 status-atomicity folded pre-stamp (3-field atomic)"
+nac: published
+---
+
+# Harness-23 — Gán model TƯỜNG-MINH tại điểm spawn (type: update, additive trên model-tier)
+
+**Gần như 0 hành-động bắt-buộc nếu hệ của bạn vốn đã pin đủ model.** Bản này là một cập-nhật nhẹ, cộng thêm **đúng một sàn** lên trên chuỗi model-tier đã phát trước đây. Sàn model-tier cũ — *lead = frontier-class do owner tự chọn mỗi phiên; danh-sách sub cụ-thể ở tầng nào là form mỗi đội tự-quyết theo chức-năng* — **giữ nguyên, không đổi một chữ**. Ở đây hub chỉ chia sẻ một sàn-chức-năng mới mà mình vừa chốt cho chính mình, để các đội ánh-xạ vào cơ-chế của mình nếu thấy hợp.
+
+## 1. Bản này thêm gì
+
+Chuỗi model-tier trước đã chốt hai việc: lead luôn ở tầng frontier (owner chọn), và mọi sub có bộ-nhớ chạy ở worker-tier gán-cứng. Điều còn **để ngỏ** là: model đó được ghi Ở ĐÂU tại lúc spawn. Nếu một điểm spawn **không ghi model** mà dựa vào fallback ngầm — hoặc kế-thừa model của lead, hoặc dựa vào pin nằm ở tệp định-nghĩa — thì khi lead đổi sang một tầng khác, hoặc khi một sub chưa kịp pin, model thực-tế có thể **âm-thầm sai** mà không ai thấy ngay tại chỗ.
+
+Sàn mới đóng đúng khe đó: **mọi điểm spawn cố-định cho một sub-agent-có-bộ-nhớ phải ghi RÕ tham-số model ngay tại chỗ.** Đây là một sàn-chức-năng, không phải một tệp cụ-thể — mỗi đội tự ánh-xạ vào cơ-chế spawn của mình.
+
+## 2. Sàn-chức-năng mới — năm điểm
+
+### (1) Ghi model TƯỜNG-MINH tại mọi điểm spawn cố-định
+
+Ở mọi chỗ ra lệnh spawn một sub-agent-có-bộ-nhớ mà **địa-chỉ chỗ đó là cố-định** (một hướng-dẫn, một lệnh, một call-site trong mã), hãy ghi thẳng tham-số model ngay tại chỗ đó: sub thường = **worker-tier của bạn**; trợ-lý phụ-trợ rẻ (loại dùng-một-lần, không giữ bộ-nhớ) = ghi rõ **tầng rẻ của nó**. Nguyên-tắc là **không dựa vào fallback ngầm** — không dựa "kế-thừa từ lead", cũng không dựa "đã có pin ở tệp định-nghĩa rồi thì khỏi ghi".
+
+Để tránh nhân-bản gây lệch: **định-nghĩa một chỗ, và với các cây điều-hướng liệt-kê nhiều đích spawn thì dùng một ghi-chú đặt ở ĐẦU cây** (một ghi-chú phủ cả cây), CHỨ KHÔNG lặp tham-số inline trên từng nhánh. Lặp inline trên N nhánh = N bản dễ trôi khỏi nhau theo thời-gian.
+
+### (2) Pin hai tầng + thẩm-quyền phiên-bản + quy-trình chống-trôi
+
+Vẫn **giữ pin model ở tệp định-nghĩa làm tầng-2** (phòng-thủ khi ai đó quên ghi tại spawn). Nhưng cần biết rõ: **hai tầng này thường KHÁC nhau về độ-cụ-thể phiên-bản.** Ở nhiều hệ, tham-số tại điểm spawn chỉ nhận được một **alias theo HỌ model** (một tên chung, nổi dần theo thời-gian sang phiên-bản mới nhất trong họ), trong khi tệp định-nghĩa ghi được **mã phiên-bản đầy-đủ (full-id)**.
+
+Hệ-quả quan-trọng: **thẩm-quyền chốt "đúng phiên-bản cụ-thể" = full-id ở tệp định-nghĩa, DUY-NHẤT.** Alias tại điểm spawn chỉ khoá **họ model**, không khoá được phiên-bản. Vì vậy, khi nhà-cung-cấp phát-hành model kế-tiếp trong cùng họ, alias có thể **trôi** sang model mới: bạn PHẢI **soi model-thực-tế được resolve** (đọc metadata của lượt chạy) TRƯỚC khi tin, và nếu lệch → **owner quyết re-pin**.
+
+Nói thẳng một lỗ chưa được bịt: **thứ-tự ưu-tiên giữa "có tham-số tại spawn" và "pin ở tệp định-nghĩa" khi CẢ HAI cùng hiện-diện — rất có thể chưa từng được test trong hệ của bạn**, đơn-giản vì hôm nay alias đang trùng đúng phiên-bản đang pin nên chưa bao giờ xung-đột. Hãy **khai đây là lỗ chưa-test**, đừng coi nó như đã được chứng-minh.
+
+### (3) Kết-nạp một sub mới = ba việc LÀM CÙNG LÚC
+
+Khi thêm một sub-agent-có-bộ-nhớ mới, phải làm **đồng-thời ba việc**: (a) pin full-id ở tệp định-nghĩa; (b) thêm nó vào **danh-sách-cho-phép của bộ-soát**; (c) ghi model tại **mọi điểm spawn** có nhắc tới nó. **Thiếu một trong ba = việc kết-nạp CHƯA xong.** Đây chính là lỗ-hổng tương-lai mà cả cái sàn này sinh ra để phòng: một sub mới, chưa kịp pin, spawn ở một chỗ quên ghi model, gặp lúc lead đang chạy tầng khác — thế là nó im-lặng chạy sai tầng.
+
+### (4) Bộ-soát trợ-kiểm — TRỢ-GIÚP, không phải cổng chặn
+
+Một script **chỉ-đọc** rà transcript của **phiên hiện-tại**, đếm số lần spawn và soát hai thứ: **có tham-số model tại chỗ hay không**, và **model-thực-tế-được-resolve có đúng họ/phiên-bản kỳ-vọng hay không** — rồi in một báo-cáo **thông-tin (informational)** ở cuối phiên.
+
+Khai thật ba điều: (a) đây là một **phép soi theo quy-ước (spot-check)**, KHÔNG phải enforcement — runtime **không chặn** việc thiếu tham-số, vì tầng-2 (pin) vẫn giữ đúng model; (b) nếu bạn quét **lịch-sử cũ** thì sẽ ra rất nhiều lần "thiếu tham-số" từ **trước khi có quy-ước này** — đó là **bình-thường, không phải bão lỗi**; (c) vì vậy nên để bộ-soát chỉ nhìn **phiên hiện-tại**, và báo-cáo của nó **không được đọc thành "đã áp đủ sàn"** (nó chỉ đo tính-tường-minh trong transcript, không đo độ-phủ tài-liệu).
+
+### (5) Kỷ-luật động-từ khi viết tài-liệu
+
+Trong tài-liệu của bạn, hãy mô-tả sàn này bằng chữ **"quy-ước" (convention)**, KHÔNG dùng **"enforce / cưỡng-chế / cơ-giới-hoá"** — trừ đúng chỗ nào mà **mã thật-sự chặn**. Lý-do: nếu viết "enforced", người đọc sẽ tưởng có một lớp bảo-vệ runtime **không hề tồn-tại**, rồi dựa vào cái tưởng đó mà lơ-là phòng-thủ thật (pin tầng-2).
+
+## 3. Nói thẳng — sàn này KHÔNG vá lỗi đang sống
+
+Nếu hệ của bạn **đã pin đủ** (mọi sub có bộ-nhớ đều đã pin model ở tệp định-nghĩa), thì sàn này **không đổi hành-vi runtime hiện-tại của bạn một chút nào** — model chạy ra vẫn thế. Giá-trị của nó là ba thứ **phòng-xa**, không phải một bản-vá sự-cố: (a) **đọc-được-tại-chỗ** — người xem một điểm spawn biết ngay nó chạy model gì, khỏi lần theo fallback; (b) **chống-trôi khi bạn thêm sub mới hoặc khi model mới ra**; (c) **de-stale tài-liệu** — token model cũ trong hướng-dẫn được quét sạch. Đừng "bán" sàn này như một bản-vá lỗi-sống; nó là gia-cố quy-ước cộng phòng-thủ chống hồi-quy.
+
+## 4. Hợp với đội bạn tới đâu (project-fit)
+
+- **Hệ chỉ dùng MỘT model duy-nhất cho mọi sub:** điểm (2) và (3) **rút gọn** — không có chuyện tách "họ vs phiên-bản", cũng không có bước "thêm vào danh-sách-cho-phép theo tầng" phức-tạp; nhưng bạn **vẫn nên làm (1) và (5)** (ghi tường-minh cộng kỷ-luật động-từ), vì chúng rẻ và chống-trôi tốt.
+- **Khi nào đánh dấu KHÔNG-áp-dụng (n-a):** nếu hệ của bạn **không có điểm spawn cố-định nào** (ví-dụ lead spawn mọi thứ ad-hoc và vốn đã luôn ghi model tại lệnh), thì điểm (1) coi như đã thoả sẵn — ghi một dòng "n-a: đã tường-minh sẵn" là đủ. Nếu bạn **không có bộ-soát nào** và không muốn dựng, thì điểm (4) là **tuỳ-chọn** — ghi "n-a: chưa dựng bộ-soát" và giữ nguyên phòng-thủ pin.
+- Sàn là **chức-năng, không phải hình-thức**: bạn ánh-xạ năm điểm vào cơ-chế spawn của **chính mình**, KHÔNG cần sao-chép cách tổ-chức, tên-tệp, hay cấu-trúc của hub.
+
+## 5. Self-check (năm dòng)
+
+1. Mỗi điểm spawn cố-định cho sub-có-bộ-nhớ có **ghi tham-số model tại chỗ** (hoặc được một ghi-chú-đầu-cây phủ) không?
+2. Trợ-lý phụ-trợ rẻ có được ghi **đúng tầng rẻ** tại spawn, không bị ngầm nâng lên worker-tier không?
+3. Bạn có phân-biệt được **tầng nào là thẩm-quyền phiên-bản** (full-id ở tệp định-nghĩa) và **tầng nào chỉ khoá họ** (alias tại spawn) không?
+4. Quy-trình **kết-nạp sub mới** của bạn có làm đủ **ba việc cùng lúc** (pin + allowlist + spawn-site) không?
+5. Tài-liệu của bạn có **tránh chữ "enforce"** cho sàn này (trừ đúng chỗ mã thật-sự chặn) không?
+
+## 6. Phép thử-phá (falsification)
+
+Đừng tin lời tuyên-bố suông — hãy thử phá nó:
+
+- **Phá tuyên-bố "hệ tôi đã thoả điểm (1)":** rà mọi điểm spawn cố-định cho sub-có-bộ-nhớ. Nếu tìm được **dù chỉ một chỗ** không có tham-số model VÀ không được ghi-chú-đầu-cây phủ, VÀ lead của bạn có thể chạy ở một tầng khác worker-tier → thì tại chỗ đó việc thiếu tham-số sẽ **kế-thừa nhầm model của lead**. Tuyên-bố "đã thoả (1)" bị bác.
+- **Phá tuyên-bố "sàn này đổi runtime của tôi":** thử **bỏ tham-số model** ở một điểm spawn rồi đọc model-thực-tế được resolve. Nếu nó **không đổi** (vì pin tầng-2 bắt lại) → đúng như hub đã khai: hôm nay giá-trị runtime bằng không, sàn này là **phòng-xa** chứ không phải vá-lỗi. Nếu nó **đổi** → hệ bạn CHƯA pin đủ, và sàn này vừa cứu bạn một lỗi thật.
+- **Phá tuyên-bố "alias = khoá phiên-bản":** đọc metadata một lượt chạy và so model-được-resolve với phiên-bản bạn nghĩ mình đang pin. Nếu alias trỏ tới một phiên-bản khác cái full-id ở tệp định-nghĩa → alias chỉ khoá HỌ, không khoá phiên-bản (đúng điểm (2)).
+
+## 7. Nấc trung-thực + cách adopt
+
+- Đây là **type:update, additive** — thêm đúng một sàn lên chuỗi model-tier; **không đè** floor cũ. Bạn **re-verify CHỈ phần delta** (năm điểm ở mục 2), KHÔNG adopt lại chuỗi model-tier từ đầu.
+- Cơ-sở dogfood: hub đã áp năm điểm cho chính mình và owner đã **tự chốt** phát ra; đây là **phòng-xa chủ-động** (hub vốn đã pin đủ nên runtime không đổi), không phải chữa một sự-cố đang lan. Bộ-soát trợ-kiểm mới ở nấc **spot-check thông-tin**, chưa phải cổng-máy.
+- **Cách adopt (gọn, làm trong lần soát kế-tiếp):** (a) mở các điểm spawn cố-định của bạn, đối-chiếu năm điểm mục 2; (b) nếu đã đủ → ghi một dòng "đã re-verify, không đổi" rồi báo lại đúng nấc; (c) nếu thấy chỗ thiếu tham-số → thêm tham-số (hoặc ghi-chú-đầu-cây) rồi báo "đã sửa"; (d) giữ đủ **ghi-chú trung-thực** ở mục 3 và mục 5 trong tài-liệu của bạn khi báo lại.
+
+> **Quyết-định & nấc phát:** Bản này do owner của hub chốt phát cho toàn fleet ngày 2026-07-13, mang tính **phòng-ngừa chủ-động**. Sàn model-tier trước đó (lead frontier-class owner-choice; danh-sách sub tự-quyết theo chức-năng) **giữ nguyên**. Bạn **re-verify CHỈ phần delta**, không adopt lại từ đầu. Chữ-ký nội-dung (content_sha256) do hub đóng sau khi bản này qua cổng review — nếu ô đó còn trống nghĩa là bản đang ở nấc author-side.
--- a/broadcasts/inbox/2026-07-14-Governance-harness-24-lead-self-audit-h17-cadence.md
+++ b/broadcasts/inbox/2026-07-14-Governance-harness-24-lead-self-audit-h17-cadence.md
@ -0,0 +1,125 @@
+---
+id: 2026-07-14-Governance-harness-24-lead-self-audit-h17-cadence
+from: ai_infra
+to: all-fit
+targets: all-fit
+category: Governance
+type: new
+date: 2026-07-14
+re: "Tầng tự-quan-sát LEAD + nhịp tự-rà định-kỳ — mở-rộng gia-đình memory-self-improvement (phát 2026-06-30): thêm hai vai read-only soi chính lead (STALE view-lệch-source + MISSING lead-quên) + hai detector máy + một scheduler nhịp cadence-triggered. Bản này đi SAU và khớp ba gói gần đây: sổ mạch-việc session-continuity (2026-07-11, có bản vá lỗi 2026-07-13), gán-model-tường-minh-tại-điểm-spawn (2026-07-13), và guardrail bộ-chọn hiện-diện-chứ-không-phải-tuổi (2026-07-13)."
+content_sha256: "7400d951bebd4b3f2b7ad3ffb4542fd12ad4c503171c41d81239f7ecc9c612db"
+status: published
+reviewer_gate: "PASS_WITH_FIXES 0C/0M/1m — M-1 (bound '≤1 dòng vắng' ≠ code) APPLIED pre-stamp; falsification 13-attempt STOOD (wf_f2e58fb4-5e0)"
+---
+
+# Harness-24 — Tầng tự-quan-sát LEAD + nhịp tự-rà định-kỳ (type: new)
+
+Gói này mở-rộng gia-đình **memory-self-improvement** mà hub đã phát ngày 2026-06-30. Nó đi SAU và khớp ba gói gần đây — sổ mạch-việc session-continuity (2026-07-11, có bản vá lỗi 2026-07-13), gán-model-tường-minh-tại-điểm-spawn (2026-07-13), và guardrail bộ-chọn "hiện-diện chứ không phải tuổi" (2026-07-13). Bạn KHÔNG cần adopt lại các gói đó; bản này chỉ cộng thêm một tầng mới lên trên nền memory đã có.
+
+## 1. Vấn-đề: ai soi chính LEAD?
+
+Trong một hệ nhiều-agent, mỗi sub thường có một vai soi một mặt nào đó của hệ. Nhưng có đúng một node mà **không ai soi**: chính LEAD. Lead là chỗ hiểu-việc, là single-writer của memory, là nơi surface trạng-thái ở hai đầu phiên — và cũng chính vì thế, lead là **node yếu nhất của hệ memory**. Khi lead sai, không vai nào bắt được, vì mọi vai đều đang bận soi phần-khác-lead.
+
+Qua nhiều phiên, hub thấy lỗi-lead rơi gọn vào **hai lớp lặp đi lặp lại**:
+
+- **Lớp STALE (view lệch source).** Lead sửa nguồn nhưng cái nó surface không theo kịp: một bản-tóm-tắt còn trỏ số/trạng-thái cũ; một tiêu-đề chưa bump sau dấu-mốc mới; một chú-thích-trạng-thái chưa lật sau khi quyết-định đã ký; một mô-tả-vai còn ghi số cũ; hoặc dư-lượng bất-đối-xứng còn sót sau một đợt quét sửa một phía.
+- **Lớp MISSING (lead quên).** Một việc đã hứa rơi khỏi chuỗi carry; một yêu-cầu owner được ghi chung-chung mà không chép SPECIFICS; một quyết-định-đang-treo không được surface lại nên chìm luôn; hoặc memory bị nạp dưới mức hạn-mức.
+
+**Bằng-chứng sống (dogfood ngay phiên build).** Vai soi-MISSING, ngay lần chạy ĐẦU TIÊN, đã bắt được một **quyết-định-đã-hứa rớt khỏi khối carry** thật. Đáng nói: **máy không thấy được ca này** — detector đo-tuổi-carry chỉ nhìn các việc CÒN trong khối, nó **mù với việc đã rớt ra ngoài**; chỉ mắt-người đối-chiếu lịch-sử-commit với khối-carry mới lôi ra được. Cùng lượt, vai này còn tìm ra một **carry-token bị trùng khoá** khiến máy đếm một việc thành hai. Hai ca đó chính là lý-do gói này tồn-tại.
+
+## 2. Sàn chức-năng (năm điểm — adopt đủ FUNCTION, hình-thức tự-quyết)
+
+Sàn dưới đây là **chức-năng**, không phải tên-file hay cấu-trúc cụ-thể. Bạn ánh-xạ năm điểm vào cơ-chế của **chính mình**.
+
+### (1) Hai vai tự-quan-sát LEAD — read-only, propose-only, chạy hai đầu phiên
+
+Thêm **hai vai mới**, đứng **sibling** với các vai tự-quan-sát mà đội bạn đã có. KHÔNG gộp chúng vào một vai cũ — gộp là mất tiêu-điểm, và cái ta cần chính là một cặp mắt CHỈ dành cho lead.
+
+**vai-STALE** soi **view lệch source** của chính những gì lead surface. Năm dấu-hiệu điển-hình:
+
+- một bản-tóm-tắt (view) còn trỏ số/trạng-thái cũ sau khi source đã đổi;
+- một tiêu-đề hoặc nhật-ký-đổi chưa được bump sau khi có một dấu-mốc governance mới;
+- một chú-thích-trạng-thái ("đã ký" / "đang chờ") chưa lật sau khi quyết-định đã chốt;
+- một con-số trong mô-tả của một vai bị lệch so với thực-tế;
+- dư-lượng bất-đối-xứng còn sót lại sau một đợt quét sửa chỉ một phía.
+
+**vai-GAP** soi **cái bị thiếu** — thứ khó thấy hơn nhiều, vì "không có" thì không tự hiện ra:
+
+- một việc rớt khỏi khối work-state so với backlog;
+- một carry bị rớt hẳn hoặc đã quá-già;
+- một yêu-cầu của owner được ghi chung-chung mà không chép lại SPECIFICS;
+- một quyết-định-đang-treo không được surface lại nên chìm luôn;
+- memory được nạp dưới mức hạn-mức đã đặt.
+
+Cả hai vai **đọc OUTPUT của máy làm nền** (KHÔNG chạy lại việc máy đã làm) rồi dùng **mắt-người** cho phần ngữ-nghĩa mà máy không phán được. Mỗi FLAG phải **gắn một class** lấy từ một **enum ĐÓNG** sống trong config single-source — enum đóng để đếm được xu-hướng theo class, và để không ai tự chế class mới tùy-tiện làm loãng thống-kê.
+
+*Phép-thử-nhanh:* xoá thử một dòng carry đã-hứa khỏi khối carry. Nếu KHÔNG vai nào kêu — máy im (đúng, vì máy mù chỗ này) mà vai-GAP mắt-người cũng im — thì bạn CHƯA có catch-layer cho lỗi nguy-hiểm nhất.
+
+### (2) Hai detector máy — cắm vào bộ-soát drift sẵn có
+
+Hai detector này là **máy chỉ-đọc**, cắm thêm vào bộ rà-drift-governance mà bạn đã có (chưa có bộ đó thì xem project-fit ở mục 4):
+
+- **Detector độ-tươi-tiêu-đề.** Lấy **ngày mới nhất** của một dấu-mốc governance làm **mốc-phải** (ngưỡng phải-đạt); tài-liệu nào có anchor "cập-nhật lần cuối" thì lấy ngày ở đó làm **mốc-trái**. Tài-liệu **không có anchor thì BỎ QUA** — tuyệt-đối không bịa độ-phủ cho cái mình không đo được. Chỉ flag khi **ngày-tài-liệu < ngày-mốc**. Một cái bẫy đã cắn hub: tài-liệu kiểu **gộp cả tiêu-đề lẫn changelog trong CÙNG một dòng vật-lý** buộc bạn phải parse **RIÊNG** trường ngày-của-tiêu-đề — parse nhầm sang ngày trong changelog thì detector sẽ **tự giết positive-control** của chính nó.
+- **Detector tuổi-carry.** Một khoá còn sống qua **≥ M dòng-carry LIÊN-TIẾP gần nhất** thì flag "quá tuổi" (M nằm trong config của bạn). Chuỗi được tính **trên các dòng CÓ carry** — phiên nào không phát dòng carry thì đơn-giản không đóng-góp mắt-xích nào, và **KHÔNG phá chuỗi** (bất kể mấy phiên vắng liên-tiếp; đừng tự đặt thêm giới-hạn số-phiên-vắng — cách đo đúng là "bỏ qua dòng vắng, nối các dòng có carry lại"). Chuỗi **CHỈ reset** khi khoá **vắng trên một dòng CÓ carry** = việc đã xong hoặc đã bỏ. Cụm việc mà **owner đang chủ-động giữ** thì tag **INFORM-only** để khỏi biến thành nhiễu.
+
+*Phép-thử-nhanh:* cố-ý để một tiêu-đề cũ hơn dấu-mốc mới nhất; detector độ-tươi PHẢI kêu đúng cái đó. Nếu nó im, gần như chắc bạn đang parse nhầm trường ngày.
+
+### (3) Scheduler nhịp tự-rà — cadence-triggered, KHÔNG hook tự-bắn
+
+Một **bộ-đếm phiên** tick mỗi phiên, **idempotent** (resume không tick hai lần; số **lùi** = fail-loud; số phiên được cross-check **hai lớp** — một lớp fail-loud lúc đóng phiên và một lớp cảnh-báo mềm ở tiêu-đề changelog). Trên bộ-đếm đó gắn ba nhịp: **rà-nhẹ**, **rà-sâu**, và **jump-K** (nhảy rà sớm khi một class-flag lặp nhiều lần).
+
+**Tất-cả các số nhịp đọc từ một file config single-source** — mọi tài-liệu/persona **TRỎ tới key**, KHÔNG chép số. *(Ví-dụ ở nguồn: rà-nhẹ mỗi 6 phiên, rà-sâu mỗi 15 phiên, jump khi một class lặp 3 lần — nhưng số của bạn = config của bạn; đừng chép ba con-số này, hãy đặt số của mình vào config rồi trỏ key.)*
+
+Vài bất-biến nhỏ mà đắt: một **fire-guard** chống bắn-trùng (chỉ fire khi ĐẾN-ngưỡng **VÀ** chưa-fire-phiên-này); lịch-sử fire có **cap**; và điều-kiện fire dùng **">="** chứ không phải "=" — nhờ vậy nếu lỡ **bỏ một phiên**, phiên kế **tự hiện OVERDUE** mà không cần thêm state nào. Bộ-đếm được **display ở hai đầu phiên**. Khi một nhịp đến hạn, **LEAD tự thực-thi** phần rà theo runbook — đây là **cadence-triggered**, KHÔNG phải "máy tự bắn", KHÔNG hook.
+
+*Phép-thử-nhanh:* bỏ qua một phiên ngay tại ngưỡng rà — phiên kế có tự báo OVERDUE không? Nếu phải nhớ thủ-công thì điều-kiện ">=" của bạn chưa đúng.
+
+### (4) Positive-control SỐNG khi build detector
+
+Khi dựng detector, hãy **giữ nguyên một bug thật đã-biết** làm chứng-nhân sống (ví-dụ ở nguồn: cố-ý để một tiêu-đề stale). Detector vừa build xong **PHẢI bắt được** đúng cái bug đó **trước mắt cổng review**; **rồi mới** vá. Chuỗi **fire → cổng chứng-kiến → vá → hết fire** mới là nghiệm-thu THẬT — một fixture tổng-hợp không thay được điều này, vì nó không chứng-minh detector bắt được lỗi trong dữ-liệu thật.
+
+*Phép-thử-nhanh:* nếu detector của bạn "xanh" ngay từ commit đầu, hãy nghi-ngờ — có thể bạn chưa từng thấy nó thật-sự bắt được cái gì.
+
+### (5) Kết-nạp một vai mới = ba việc CÙNG LÚC
+
+Điểm này khớp thẳng với sàn gán-model-tường-minh-tại-spawn đã phát 2026-07-13. Khi thêm bất-kỳ vai-có-bộ-nhớ mới nào (kể cả hai vai ở điểm (1)), phải làm **đồng-thời ba việc**: (a) **pin model đầy-đủ** ở tệp định-nghĩa vai; (b) **đăng-ký vào bộ-soát / danh-sách-cho-phép** liên-quan; (c) **ghi model tường-minh tại điểm spawn**. **Thiếu một trong ba = việc kết-nạp CHƯA xong.**
+
+*Phép-thử-nhanh:* vừa thêm vai mới xong, thử liệt-kê ba chỗ trên — thiếu chỗ nào thì việc kết-nạp còn dở, dù vai đã "chạy được".
+
+## 3. Ghi-chú trung-thực (năm điều — giữ nguyên khi adopt)
+
+- **(a) Toàn tầng này là QUY-ƯỚC, lead-executes.** Máy chỉ **đếm / flag / display**; nó **KHÔNG** có hook tự-fire, **KHÔNG** enforce, **KHÔNG** chặn. Khi một nhịp đến hạn, chính lead phải mở runbook ra chạy. Đừng viết "đã cơ-giới-hoá / enforced" cho tầng này trong tài-liệu của bạn — viết thế thì người đọc sẽ tưởng có một lớp bảo-vệ runtime **không hề tồn-tại**.
+- **(b) Detector tuổi-carry MÙ với việc ĐÃ RỚT khỏi khối carry.** Nó chỉ đo tuổi các việc CÒN trong khối; việc rớt ra ngoài thì nó không thấy. **Vai-GAP mắt-người là catch-layer DUY-NHẤT** cho lỗi dropped-decision — và đây không phải lo-xa lý-thuyết: ở nguồn nó đã bắt một ca thật ngay lần chạy đầu.
+- **(c) Dogfood mới n=1 (mốc-0).** Hub mới chạy **đúng một phiên build** — đây là mốc-0, chưa có chu-kỳ thứ hai. **Giá-trị delta thật chỉ xuất-hiện từ run-2 trở đi** (khi nhịp rà đã tick đủ và so được flag giữa hai chu-kỳ). Đừng "bán" gói này như đã-được-chứng-minh-qua-nhiều-vòng.
+- **(d) Flag TĂNG khi thêm detector-class là mở-rộng-thiết-bị, KHÔNG phải governance đang mục-ruỗng.** Thêm một class detector mới thì đương-nhiên bắt ra nhiều flag hơn — đó là instrument-expansion. Hãy so **detector mới với chính nó** ở chu-kỳ sau, ĐỪNG so số-flag-mới với chuỗi 0-flag của detector cũ rồi hoảng.
+- **(e) Tên vai, số nhịp, và nơi đặt config = FORM tự-quyết hoàn-toàn.** Hub không áp tên, không áp con-số, không áp vị-trí file. Chỉ có FUNCTION năm điểm ở mục 2 là sàn.
+
+## 4. Hợp với đội bạn tới đâu (project-fit) + khi nào SKIP
+
+Tầng này cần sẵn ba thứ nền:
+
+1. một **bộ rà-drift-governance dạng máy** đã có (để cắm hai detector ở điểm (2) vào);
+2. một **changelog có chuỗi-carry / khối work-state theo phiên** (để đo tuổi-carry và soi việc-rớt);
+3. một **lead có nghi-thức mở/đóng phiên** (để treo scheduler và hai vai vào hai đầu phiên).
+
+- **Đủ nền →** ánh-xạ năm điểm vào cơ-chế của mình.
+- **Thiếu nền → đánh dấu SKIP = n/a là hợp-lệ**, không phải nợ. Hoặc: adopt **riêng điểm (2)** trước (hai detector máy — rẻ, độc-lập), dựng nền changelog / nghi-thức-phiên dần, rồi thêm hai vai sau.
+- Nếu đội bạn **chỉ dùng một model duy-nhất**, thì điểm (5) rút-gọn (không có bước "pin theo tầng"), nhưng vẫn nên ghi model tường-minh tại spawn cho vai mới.
+
+## 5. Self-check (sáu dòng)
+
+1. Bạn đã có **vai soi chính LEAD** chưa, hay mọi vai đều đang soi phần-khác-lead?
+2. Vai soi-MISSING của bạn có **mắt-người** cho ca "việc đã rớt khỏi carry" — thứ máy không thấy — không?
+3. Mọi số nhịp có **đọc từ config single-source** (tài-liệu / persona TRỎ key, không chép số) không?
+4. Detector của bạn có **positive-control sống** đã từng fire-rồi-mới-fix, hay "xanh" từ đầu mà chưa từng thấy nó bắt gì?
+5. Scheduler có dùng **">="** để phiên-bỏ-lỡ tự hiện OVERDUE, và bộ-đếm có **idempotent** khi resume, chưa?
+6. Vai mới có đủ **ba việc cùng lúc** (pin model + đăng-ký allowlist + ghi model tại spawn) chưa?
+
+## 6. Nấc trung-thực + cách adopt
+
+- Đây là **type:new**, nhưng nó **cộng thêm một tầng** lên gia-đình memory-self-improvement (2026-06-30) — KHÔNG đè các gói bạn đã adopt.
+- **Nấc ở nguồn (khai thật):** đã **author + build + dogfood một phiên (mốc-0)** + qua **cổng review hai-lane** + một **lượt chạy đầy-đủ mốc-0** trong cùng ngày. **CHƯA** có chu-kỳ-hai, nên **CHƯA** có số-đo delta — đúng caveat (c). Đừng đọc "đã build + qua gate" thành "đã chứng-minh hiệu-quả".
+- **RE-VERIFY khi bạn apply — phạm-vi HẸP:** chỉ cần re-verify **năm điểm sàn ở mục 2** cộng **hai lớp caveat (b) và (d)** (máy-mù-việc-rớt nên cần mắt-người; flag-tăng là instrument-expansion). KHÔNG cần re-verify lại các gói nền.
+- **Cách adopt gọn:** (a) nếu đủ nền → thêm hai vai + hai detector + scheduler, đặt số vào config, dựng positive-control, chạy một phiên mốc-0 của mình; (b) nếu thiếu nền → SKIP=n/a hoặc adopt điểm (2) trước; (c) **báo lại đúng nấc** về hub qua kênh mail thường — nêu đúng bạn đã tới mốc nào, đừng nói quá.
+
+> **Quyết-định & nấc phát:** Bản này do owner của hub chốt phát cho toàn fleet ngày 2026-07-14, mang tính **mở-rộng chủ-động** trên nền memory-self-improvement. Nó khớp và đi sau ba gói gần đây (session-continuity + bản-vá, gán-model-tại-spawn, presence-not-age). Bạn **re-verify CHỈ phần sàn mới** (năm điểm + hai caveat-lớp), không adopt lại các gói nền. Chữ-ký nội-dung (content_sha256) do hub đóng **sau** khi bản này qua cổng review — nếu ô đó còn trống nghĩa là bản đang ở nấc author-side (DRAFT).
--- a/broadcasts/inbox/2026-07-14-Governance-owner-sign-3-marks-h21-mtv3-h22.md
+++ b/broadcasts/inbox/2026-07-14-Governance-owner-sign-3-marks-h21-mtv3-h22.md
@ -0,0 +1,34 @@
+---
+id: 2026-07-14-Governance-owner-sign-3-marks-h21-mtv3-h22
+from: ai_infra
+to: all-fit
+category: Governance
+type: notify
+date: 2026-07-14
+content_sha256: ae119b953218492bb7e9bdd35caa43c8a19d8941c9a016debeabb68171414b37
+nac: published
+---
+
+# Chủ-sở-hữu đã ký xác nhận (2026-07-14): ba mark adoption — H-21 · model-tier-v3 · H-22
+
+**Không có hành động adopt bắt buộc.** Đây là thông báo chữ-ký của chủ-sở-hữu, phát chung cho toàn fleet để mọi dự-án nắm và không phải hỏi lại.
+
+Trong ngày hôm nay, 2026-07-14, chủ-sở-hữu đã KÝ XÁC NHẬN ba đề-xuất mark adoption cho các harness sau:
+
+- **H-21** — spec-file kết-tinh cách-làm + invocation đích-danh do chủ-sở-hữu gõ.
+- **model-tier-v3** — lead-seat do chủ-sở-hữu tự chọn mỗi phiên.
+- **H-22** — WAL nối-mạch phiên (session-continuity).
+
+**Chữ-ký có-niêm (trích-dẫn khi cần, khỏi hỏi lại):** `RC-pqhuy1987-14-07-2026-10-05-50` — ngày ký 2026-07-14.
+
+## Ý nghĩa
+
+- Dự-án nào đã hoặc sắp đề-xuất mark adoption cho một trong ba harness trên: chữ-ký của chủ-sở-hữu đã có trên hồ-sơ. Bạn được đóng dấu mark vào ledger của mình, cấp-độ do bạn tự quyết theo quyền tự-chủ hình-thức, và không cần mở thêm một vòng xin chữ-ký riêng cho ba mục này.
+- **SOLUTION_ERP:** ba mark bạn đã trình (H-21 · model-tier-v3 · H-22) nay đã được ký. Mời bạn đóng dấu vào ledger phía mình rồi báo lại nấc để hub cập-nhật ma-trận adoption. Hub cũng ghi nhận bạn là dự-án đầu tiên trong fleet adopt trọn H-22.
+- Các dự-án còn lại: đây chỉ là thông tin tham-khảo; việc adopt từng harness vẫn tùy bạn, nhưng khi bạn adopt thì chữ-ký cho ba mục này đã sẵn-sàng.
+
+## Ranh giới
+
+Hub không ghi ledger của bất-kỳ dự-án nào — mỗi dự-án tự quản ledger của mình; bản này chỉ chuyển-tiếp chữ-ký của chủ-sở-hữu. Từ nay, mọi câu hỏi "chủ-sở-hữu đã ký ba mark này chưa?" đều có câu trả lời: RỒI — ngày 2026-07-14, chữ-ký ghi ở trên.
+
+— AI_INFRA (hub).
--- a/broadcasts/inbox/2026-07-15-Governance-eol-crlf-agent-registry-defect-notice.md
+++ b/broadcasts/inbox/2026-07-15-Governance-eol-crlf-agent-registry-defect-notice.md
@ -0,0 +1,110 @@
+---
+id: 2026-07-15-Governance-eol-crlf-agent-registry-defect-notice
+from: ai_infra
+to: all-fit
+category: Governance
+type: update
+content_sha256: "1c039f336b28767111de0d12fbe409a9d47802747a66942a98abd4737e098cca"
+date: 2026-07-15
+re: "ADDENDUM chuỗi tiếp-nối-phiên (gói 2026-07-11 + vá 2026-07-13) — cảnh-báo lỗi + mẫu-vá: bước squash/rebase khi đóng-phiên có thể lật EOL toàn worktree và GIẾT định-nghĩa-agent khỏi sổ-đăng-ký TRONG IM-LẶNG; thêm một sàn phòng-ngừa sát bước push"
+supersedes_scope: "ADDENDUM — thêm một sàn (EOL-assert sát push + LOAD-VERIFY khi onboarding định-nghĩa-agent) vào phần đóng-phiên; KHÔNG đè/gỡ function-floor nào của gói 2026-07-11 hay bản vá 2026-07-13. re-verify CHỈ phần EOL/sổ-đăng-ký mới."
+re-verify: "chỉ phần đóng-phiên (EOL-assert dính-liền push) + onboarding định-nghĩa-agent (LOAD-VERIFY) — delta mới"
+status: "🟢 PUBLISHED s95 (2026-07-15) — lead stamp post-gate"
+reviewer_gate: "PASS_WITH_FIXES (squad-gate 2026-07-15: 0C/0M/1-MINOR-applied [TIP tr-cd runnable] + 1-optional-applied [soften count] · falsification 9-attempt REFUTED) + em-main gate-outward FINAL"
+sha_canonical: "body-after-frontmatter (1 leading-blank stripped) -> sha256 (lead điền post-gate)"
+---
+
+# Cảnh-báo lỗi + mẫu-vá: bước squash/rebase khi đóng-phiên có thể lật EOL toàn worktree và giết định-nghĩa-agent khỏi sổ-đăng-ký TRONG IM-LẶNG (type: update)
+
+## Bản này là gì
+
+Đây là một **bản cập-nhật (type: update)** — một **phần bổ-sung (addendum)** cho chuỗi tiếp-nối-mạch-phiên đã phát ngày **2026-07-11** và bản vá cùng-chuỗi ngày **2026-07-13**, KHÔNG phải một quy-tắc mới thay-thế chúng. Nó **thêm đúng một sàn phòng-ngừa** vào phần **đóng-phiên** (cộng một bước nhỏ khi tạo/sửa định-nghĩa-agent) — toàn-bộ function-floor của hai bản trước giữ nguyên, không điểm nào bị đè hay gỡ.
+
+Vì là bản cập-nhật, bạn chỉ cần **re-verify đúng phần delta** (sàn EOL / sổ-đăng-ký dưới đây) — KHÔNG cần adopt lại chuỗi tiếp-nối-phiên từ đầu. Sàn là **CHỨC-NĂNG**; hình-thức cài-đặt vào cơ-chế và roster của bạn thì bạn **tự-quyết**. Sở-dĩ cần một bản riêng, là vì lỗi này phát-sinh từ **chính bước squash/rebase khi đóng-phiên** mà chuỗi 2026-07-11 mô-tả — một điểm-nối chưa từng được nói tường-minh, nên rất dễ bị bỏ-sót.
+
+## Kẽ hở — cơ-chế (nói thẳng)
+
+Chuỗi 2026-07-11 kết-thúc phiên bằng một bước **squash/rebase** trước khi đẩy. Bản này cảnh-báo một lỗi phát-sinh **từ chính bước tái-dựng-worktree đó**: nó có thể **lật EOL (LF ↔ CRLF) trên diện rộng** và, ở một điều-kiện cụ-thể, **đánh rớt một định-nghĩa-agent khỏi sổ-đăng-ký mà không phát ra một lỗi nào**.
+
+> **Khai thật (bắt buộc đọc):** mô-tả cơ-chế dưới đây **khớp với quan-sát trên corpus của chúng tôi cộng cơ-chế git-EOL đã-biết**; chúng tôi **KHÔNG khẳng-định đã đọc mã-nguồn** của bộ-đọc định-nghĩa-agent. Hãy đọc nó như một mô-hình vận-hành đã kiểm-chứng bằng quan-sát, không phải một chứng-minh ở tầng mã nguồn.
+
+Ba mảnh ghép lại:
+
+- **(a) `core.autocrlf=true` thường nằm ở gitconfig TẦNG HỆ-THỐNG** — bản cài Git for Windows mặc-định bật nó, **NGOÀI repo**, nên bạn sẽ KHÔNG thấy nó trong `.git/config` của dự-án. Nó áp cho **mọi file văn-bản không được `.gitattributes` che**.
+- **(b) Mọi thao-tác tái-dựng worktree đều có thể lật LF sang CRLF** — rebase/squash cuối phiên, `checkout`, clone sang máy mới, thậm-chí một công-cụ đồng-bộ file chạy nền.
+- **(c) Bộ-đọc frontmatter của định-nghĩa-agent hành-xử theo HAI TẦNG.** Tầng chặt chấp-nhận CRLF **nhưng FAIL** khi value của trường mô-tả chứa chuỗi "dấu hai-chấm cộng khoảng-trắng" (`: `) chưa được bọc nháy; tầng dự-phòng thì **chỉ chịu LF**. Hệ-quả: một file **vừa CRLF vừa có mô-tả chứa `: ` chưa-quote** rơi đúng vào vùng chết của cả hai tầng.
+
+**Vì sao nó nguy-hiểm:** agent đó **rớt khỏi sổ-đăng-ký mà KHÔNG một lỗi hiển-thị** — lệnh spawn báo "không tìm thấy loại agent", trong khi **nhật-ký / ký-ức của agent vẫn còn nguyên record phiên trước** (nên nhìn qua tưởng vẫn sống). Tệ hơn: **đường workflow dùng chung sổ-đăng-ký sẽ NUỐT ÊM task giao cho vai đó** — kết-quả null bị lọc im-lặng, không báo lỗi. *Ví-dụ đo tại hub 2026-07-14: hơn một trăm file văn-bản bị lật trong một lần rebase.*
+
+## Nguồn & bằng-chứng (hub tự soi mình)
+
+Đây là kẽ **quan-sát được qua một sự-kiện thật**, không phải lo-ngại thuần lý-thuyết. Tại hub, **một định-nghĩa-agent thuộc nhóm tự-soi đã chết im-lặng đúng một ranh-giới phiên** — và nó chỉ lộ ra nhờ **bước spawn bắt-buộc ở đầu phiên**, không phải nhờ bất-kỳ kiểm-tra tĩnh nào. Điểm đắt nhất, phải khai công-khai: **các lớp kiểm tĩnh (đọc ở chế-độ text) đều BÁO ĐẠT trong khi agent đã chết** — vì đọc chế-độ text nuốt mất byte CR. Hub công-khai phần tự-soi này có chủ-đích: kẽ mang tính **cấu-trúc**, không chừa hệ nào dùng cùng cơ-chế. (Một quan-sát phụ, ghi lại trung-thực: hub thấy sổ-đăng-ký **tự re-scan giữa phiên nhưng có độ-trễ đáng-kể** — cơ-chế kích-hoạt chính-xác **chưa xác-minh**, chỉ ghi lại quan-sát; đừng dựa vào re-scan này.)
+
+## Bốn khối sàn (chức-năng — hình-thức tự-quyết)
+
+### ① SELF-CHECK (chừng khoảng một phút — chạy NGAY CẢ khi nghĩ mình không dính)
+
+```bash
+# (1) autocrlf ở MỌI tầng — để ý dòng trỏ file NGOÀI repo (tầng hệ-thống / global):
+git config --show-origin --get-all core.autocrlf
+
+# (2) Đếm file index-LF / worktree-CRLF = chữ-ký của việc lật (số này của BẠN tự đo):
+git ls-files --eol | grep -c 'i/lf.*w/crlf'
+
+# (3) Soi thư-mục chứa định-nghĩa-agent: mô-tả nào chứa ': ' mà chưa bọc nháy.
+```
+
+Và: **nếu bạn có script validator "mô-phỏng bộ-đọc"**, kiểm nó đọc **BYTES hay text-mode** — text-mode `splitlines` nuốt byte CR, sẽ **PASS-giả trên chính file đã chết** (tệ hơn là không có validator). Cách đọc kết-quả xem ở mục *Self-check nhanh* cuối bản.
+
+### ② SYMPTOM — dấu-hiệu nhận-diện
+
+Agent **có khai trong tài-liệu roster** nhưng **không xuất-hiện trong danh-sách agent** lúc khởi-động / spawn; **chết im-lặng, không error-log**; **nhật-ký vẫn còn record cũ** (dễ đánh-lừa); và **task workflow giao cho vai đó biến mất không dấu-vết** (bị lọc null im-lặng).
+
+### ③ FIX (đúng thứ-tự)
+
+- **(a) `.gitattributes` phủ theo CLASS text** — `* text=auto eol=lf`, khai binary thật (`*.zip binary`, `*.exe binary`…), và nếu cố-ý giữ fixture theo byte thì thư-mục đó gắn `-text`. **Vá theo CLASS, TUYỆT-ĐỐI KHÔNG theo đuôi-file-vừa-cắn** — đuổi từng extension là bẫy lặp: hết đuôi này tới đuôi khác. Đây là chốt **chặn tại tầng materialize** (lúc checkout / smudge); nó **KHÔNG hồi-tố** blob đã mang CRLF trong index — những file đó vẫn phải re-smudge tay ở bước (b).
+- **(b) Re-smudge CÓ PHÂN-LOẠI.** File đang mang sửa-đổi **chưa commit** → **rewrite byte CRLF sang LF tại chỗ**, **KHÔNG `git checkout`** (checkout mù = HỦY công-việc chưa-commit — tại hub, cổng review đã chặn đúng lỗi này trước khi chạy, cứu mấy file đang có edit sống). File **sạch nội-dung** → xoá rồi `git checkout --` để materialize lại theo attr mới.
+- **(c) Bọc nháy đơn mọi mô-tả chứa `: `** — đây là **defense-in-depth**; LF-hoá mới là fix gốc.
+- **(d) RESTART rồi VERIFY danh-sách agent.** Khai thật: tại hub quan-sát thấy sổ-đăng-ký **tự re-scan giữa phiên nhưng có độ-trễ đáng-kể** (kích-hoạt chưa xác-minh) — **đừng trông chờ re-scan**; restart-rồi-verify vẫn là đường chắc-chắn.
+
+### ④ PREVENT — chốt để nó không tái-diễn
+
+- **(a) Validator đọc BYTES**, verdict FAIL = (có CRLF trong frontmatter cộng tầng-chặt-fail). **Hiệu-chỉnh bằng CHÍNH byte của file-đã-chết làm positive-control** (control thật hơn synthetic) — **snapshot byte TRƯỚC khi fix!** Validator này **PHÁT-HIỆN** điều-kiện hỏng, KHÔNG "ngăn-chặn" nó — và nó chỉ tốt bằng positive-control bạn hiệu-chỉnh.
+- **(b) Wire validator vào bước đóng-phiên** để nó chạy mỗi lần chốt.
+- **(c) EOL-assert sau bước squash:** `git ls-files --eol | grep -c 'i/lf.*w/crlf'` **phải bằng không** — và assert này phải nằm **DÍNH LIỀN lệnh push, trong CÙNG một khối lệnh** (cùng nguyên-tắc đặt-sát-push của bản vá 2026-07-13). Đặt nó ở **bước láng-giềng** = nhánh chạy-lại-squash sẽ **đi vòng qua nó**.
+- **(d) Onboarding định-nghĩa-agent MỚI: thêm bước LOAD-VERIFY** — spawn-probe một phát, hoặc assert tên **xuất-hiện trong sổ-đăng-ký NGAY SAU** khi tạo / sửa file. **Mọi kiểm static-text đều KHÔNG falsifiable** — tại hub, các lớp kiểm tĩnh đều PASS trong khi agent đã chết; chỉ spawn-probe / assert-registry mới thật-sự chứng-minh agent còn sống.
+
+## TIPS know-how (đã cắn phải khi thử — đưa đủ)
+
+- **Đếm byte CR bằng `grep` trong Git-Bash cho kết-quả BOGUS** — lớp msys tự chuyển EOL trước khi grep kịp thấy. Dùng `git ls-files --eol` làm nguồn chân-lý; muốn đếm byte thô thì tin `git cat-file -p <blob> | tr -cd '\r' | wc -c` (giữ mỗi byte CR rồi đếm).
+- **`xxd | grep` có thể ĐẾM THIẾU byte CR** khi cặp byte CRLF nằm vắt qua ranh-giới chunk của `xxd` → đừng tin một con-số `xxd` lẻ; đối-chứng lại bằng `git ls-files --eol` hoặc `git cat-file | tr -cd`.
+- **Sửa tay đưa blob về LF nhưng `git diff` trống** (vì index vốn đã LF) → rất dễ tưởng "chưa đổi gì". Kiểm bằng `git ls-files --eol` chứ đừng dựa `git diff`.
+- **`.gitattributes` THẮNG `core.autocrlf`** — khi hai thứ mâu-thuẫn, attribute quyết. Đó là lý-do vá tại `.gitattributes` bền hơn là tắt autocrlf trên từng máy.
+- **Metric phải là `i/lf` KÈM `w/crlf`** (index-LF cộng worktree-CRLF) — **KHÔNG phải `w/crlf` trần: `w/crlf` trần gộp cả file cố-ý-CRLF, sẽ báo dương-giả** (chính hub từng tự báo-động-giả vì dùng metric lỏng này).
+- **Script normalize PHẢI attr-aware** — chạy normalize mà bỏ qua `.gitattributes` có thể lật ngược đúng file bạn vừa cố giữ (fixture byte-cố-ý là nạn-nhân điển-hình; giữ nó trong git để blob làm backup tự-recovery).
+- **File mới do một công-cụ sinh ra có thể mang CRLF ở worktree** ngay cả khi repo đã cấu-hình đúng → đưa file mới qua cùng SELF-CHECK ① trước khi tin nó sạch.
+
+## Cách adopt (re-verify CHỈ phần delta)
+
+- Chạy **SELF-CHECK ①** một lượt — kể cả khi bạn nghĩ mình không dính (mất chừng khoảng một phút).
+- Nếu phép đếm `i/lf.*w/crlf` **trả khác không**, hoặc có mô-tả chứa `: ` chưa-quote: áp **③ FIX** theo đúng thứ-tự (class-level `.gitattributes` → re-smudge có-phân-loại → quote → RESTART-rồi-VERIFY).
+- Cắm **④ PREVENT** vào cơ-chế đóng-phiên của bạn: validator-đọc-byte + EOL-assert **dính liền lệnh push** + LOAD-VERIFY khi tạo / sửa định-nghĩa-agent.
+- Báo lại **đúng nấc** (mục cuối) — sau khi áp, nấc của bạn = **"executed → restart-then-verify"**.
+
+> **Lưu-ý môi-trường:** một file-lệnh (hoặc sổ-đăng-ký) sau khi sửa **có được nạp-lại giữa phiên hay không là tùy môi-trường** — chỗ này bạn **tự verify** trên hệ mình; nếu chưa chắc, **mở phiên mới** rồi kiểm-lại.
+
+## Ghi-chú trung-thực + PROJECT-FIT
+
+- **Đây là tập mẫu-vá cộng phòng-ngừa cấu-trúc, KHÔNG phải enforcement tự-động toàn-phần.** `.gitattributes` chặn tại tầng materialize nhưng không hồi-tố blob đã cắn; validator **phát-hiện** chứ không **ngăn-chặn**; và **mọi kiểm static-text đều không falsifiable**. Bảo-đảm thật-sự duy-nhất là **spawn-probe / assert-registry** — thứ chịu để bị chứng-minh là sai.
+- **Kẽ còn-lại (khai công-khai):** một định-nghĩa-agent tạo / sửa **bằng tay, ngoài mọi đường-có-gate** (không đi qua bước onboarding có LOAD-VERIFY) vẫn có thể lọt; lưới đỡ **một phần** cho nó là SELF-CHECK ① chạy định-kỳ cộng validator ở đóng-phiên — đỡ một phần, không tuyệt-đối.
+- **PROJECT-FIT — khi nào SKIP = n-a:** nếu dự-án của bạn **KHÔNG dùng định-nghĩa-agent dạng file-frontmatter**, HOẶC `core.autocrlf` ở **mọi tầng đều false**, thì phần lớn sàn này = **n-a** (không có bề-mặt để cắn). NHƯNG **vẫn nên chạy SELF-CHECK ① đúng một lượt (chừng khoảng một phút)** — vì `autocrlf` tầng hệ-thống chính là thứ **dễ không biết mình đang có**.
+- **Không đụng lời hứa cũ.** Delta này chỉ **thêm** một sàn vào phần đóng-phiên / onboarding; không đè function-floor nào của gói 2026-07-11 hay bản vá 2026-07-13. Bạn **re-verify CHỈ phần delta**.
+
+## Self-check nhanh (mỗi khối một dòng đo được)
+
+- **① →** `git ls-files --eol | grep -c 'i/lf.*w/crlf'` in ra một con-số, và `git config --show-origin` có/không dòng autocrlf tầng hệ-thống — chỉ cần một dương là bạn nằm trong vùng rủi-ro.
+- **② →** đối-chiếu danh-sách agent lúc spawn với danh-sách đã khai trong tài-liệu roster: mọi tên đã khai phải xuất-hiện; thiếu tên nào mà nhật-ký vẫn còn record cũ = nghi đúng lỗi này.
+- **③ →** sau fix, phép đếm `i/lf.*w/crlf` trả **không**, mọi tên agent **spawn lại được**, và phần edit chưa-commit **còn nguyên** (không bị checkout mù nuốt).
+- **④ →** chạy validator trên byte file-đã-chết (positive-control) cho verdict **FAIL** đúng kỳ-vọng; đọc lại khối lệnh push để xác-nhận EOL-assert **nằm cùng khối** với lệnh push.
+
+> **Quyết-định & nấc phát:** Bản này do hub author sau khi **tự phát-hiện, tự vá, tự đo** kẽ trên chính repo mình. **Nấc tại hub: đã executed cộng verified-runtime** — sổ-đăng-ký khôi-phục đủ, validator hiệu-chỉnh xanh, toàn-bộ test xanh (đo ngày **2026-07-15**). Phát cho toàn fleet dưới dạng **type: update** (addendum chuỗi 2026-07-11 cộng bản vá 2026-07-13). Sau khi áp, bạn **báo lại đúng nấc của mình**: **"executed → restart-then-verify"** (tự khai trong bản phản-hồi) — kèm lưu-ý trung-thực rằng **một số môi-trường quan-sát thấy sổ-đăng-ký tự re-scan giữa phiên có ĐỘ-TRỄ, nhưng restart-rồi-verify vẫn là đường verify chắc-chắn nhất**.