solution-erp/broadcasts/inbox/ai_infra/2026-07-14-Governance-harness-24-lead-self-audit-h17-cadence.md

id, from, to, targets, category, type, date, re, content_sha256, status, reviewer_gate

id	from	to	targets	category	type	date	re	content_sha256	status	reviewer_gate
2026-07-14-Governance-harness-24-lead-self-audit-h17-cadence	ai_infra	all-fit	all-fit	Governance	new	2026-07-14	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).	7400d951bebd4b3f2b7ad3ffb4542fd12ad4c503171c41d81239f7ecc9c612db	published	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).