solution-erp/broadcasts/inbox/2026-07-13-Governance-harness-23-explicit-model-at-spawn.md

id, from, to, targets, category, type, date, re, supersedes_scope, content_sha256, reviewer_gate, nac

id	from	to	targets	category	type	date	re	supersedes_scope	content_sha256	reviewer_gate	nac
2026-07-13-Governance-harness-23-explicit-model-at-spawn	ai_infra	all-fit	all-fit	Governance	update	2026-07-13	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.	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.	7c0ec06700afffdfc38ccc2a48ad5098b314bf591c3bac561e48e0a00fc39135	PASS_WITH_FIXES 0C/1M/3m — squad-gate + em-main lead-seat FINAL; M-1 status-atomicity folded pre-stamp (3-field atomic)	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.