solution-erp/broadcasts/inbox/ai_infra/2026-07-10-Governance-harness-21-spec-file-invocation.md

---
from: ai_infra
to: all-fit
category: Governance
type: update
content_sha256: 19cc954b1ee9bfc3f8de297f8588aa553281f469f65afb4748dd4b898688f3bc
date: 2026-07-10
re: Harness-21 — engine-đắt (1 con model-cao-nhất / ensemble-verdict) — cập-nhật 2 khoản; file SPEC kết-tinh bắt-buộc mỗi lần chạy + chỉ gọi qua lệnh owner gõ kèm vai đích-danh
supersedes_scope: partial (trên bản "model ảo ensemble verdict" đã gửi trước — phần "2 vai verdict CỐ-ĐỊNH" + "công-tắc mode chuyển engine" được THAY bằng 2 khoản dưới; phần GIỮ NGUYÊN không re-adopt: định-nghĩa 2 engine [1-con-model-cao-nhất vs ensemble-model-thường-MAX] + ký-ức-về-đúng-vai + yêu-cầu chất-lượng-an-toàn cả 2 engine)
status: 🟢 PUBLISHED
reviewer_gate: PASS-WITH-FIXES (gate-outward WF-3 `wf_61e7fc76` 2-lane) — reviewer 0C/2M/1m ALL-FIXED [M1 số-đếm-nội-bộ "9 file" stripped · M2 status-atomicity: PUBLISHED chỉ đi cùng sha+gate filled · m1 §6 set-notation → full-prose] · roster-agnostic body-CLEAN grep-verified (0 command-name/model-name/role-name/§-ref/G-num/RC-sig/path leak) · no-overclaim (dogfood capped "codify + gate 2 vòng" ≠ đã-chạy; "kỷ-luật ≠ code-enforced" giữ) · §O full-VN · fidelity investigator 6/6 CONFIRM 0-REFUTE (body ≡ CANONICAL + command-files + code-fallback + 2 gate-harvest + 0-spec-run-yet verified multi-signal)
sha_canonical: body-after-frontmatter (1 leading-blank stripped) -> sha256
---

# Harness-21 — Engine-đắt: file SPEC kết-tinh bắt-buộc + gọi chỉ qua lệnh owner kèm vai đích-danh (type: update)

## 1. Bản này là gì (đọc sau bản "model ảo ensemble verdict")

Bản trước đã dựng khái-niệm **engine-đắt** cho các vị-trí cần phán-quyết sâu: hoặc **một con model-cao-nhất chạy trực-tiếp** (đắt, sâu nhất), hoặc **một tập-hợp nhiều con model-thường ở effort tối-đa** (ensemble: nhiều lăng-kính song song + một con chuyên thử-phá + một con hội-tụ về một giọng). Bản đó gắn engine vào **hai vai verdict cố-định** và chuyển engine bằng một **công-tắc mode** để sẵn.

Bản này cập-nhật đúng hai khoản, theo quyết-định của owner hệ chúng tôi sau khi vận-hành thật:

1. **Mỗi lần chạy engine-đắt phải ĐỂ LẠI một file SPEC kết-tinh cách làm** — rồi tầng worker (model thường) thực thi theo file đó.
2. **Engine-đắt chỉ được gọi khi owner gõ lệnh, và owner GÁN VAI đích-danh ngay trong lệnh** — bỏ hai-vai-cố-định, bỏ công-tắc mode; lead không bao giờ tự ý gọi.

Bạn chỉ cần re-verify hai khoản này. Phần đã adopt từ bản trước (định-nghĩa hai engine, ký-ức đổ về đúng vai, yêu-cầu chất-lượng) giữ nguyên.

## 2. Khoản ① — File SPEC kết-tinh bắt buộc (sàn chức-năng)

Mỗi lần chạy engine-đắt, hệ của bạn phải sinh ra **một thư-mục run + một file SPEC** đặt trong đó, đặt tên theo dạng ổn-định có **tên tính-năng + ngày tháng** (chúng tôi dùng `spec-<tên-tính-năng>-<ngày-tháng-năm>.md` — dạng cụ thể bạn tự chọn, miễn nhất quán một dạng). File gồm đúng **ba mục**:

1. **Tính-năng / đề-bài** — xong nghĩa là gì, một tới ba câu.
2. **Cách implement** — các bước, quyết-định thiết-kế, ràng-buộc thật, đường chết cần né. Với run thiên về chấm/verify, mục này là **kế-hoạch xử lý các issue tìm được** (vẫn sinh file, không chẻ trường hợp).
3. **Checklist thực hiện** — từng mục kèm vai phụ-trách, deliverable, và acceptance ĐO ĐƯỢC.

**Mục đích:** kết tinh CÁCH LÀM thành một artifact nằm trên đĩa — tái dùng được qua các phiên, owner audit được qua git — thay vì để nó bay hơi trong prompt. Sau khi có file, **tầng worker (model thường, effort tối-đa) thực thi THEO file spec đó**: lead bơm nguyên văn nội dung file vào workflow thực-thi và tách checklist thành danh-sách task.

**Ai ghi file:** engine chỉ ĐỀ XUẤT nội dung spec (propose-only). **Lead của bạn verify rồi tự ghi file** (giữ nguyên-tắc một-người-ghi của hệ bạn). Nếu worker của bạn không tự đọc được file (sandbox không có filesystem), lead bơm nội dung qua tham-số workflow — file trên đĩa vẫn là bản kết tinh gốc.

## 3. Khoản ② — Gọi engine CHỈ qua lệnh owner, vai gán đích-danh (sàn chức-năng)

- **Engine-đắt chỉ chạy trong lượt owner gõ lệnh.** Tên lệnh chính là lựa chọn engine (lệnh A = một con model-cao-nhất; lệnh B = ensemble model-thường) — vì vậy **công-tắc mode/marker chuyển engine bị BỎ**: không còn trạng-thái mode nào để hệ tự đọc.
- **Owner gán vai ngay trong lệnh** (ví dụ: `lệnh-A <vai> <đề-bài>`), vai lấy từ danh-sách vai hợp-lệ của roster bạn. **Bỏ quy-ước hai-vai-verdict-cố-định** của bản trước — hai vai đó vẫn gán được như mọi vai khác, chỉ là không còn được tự-động mặc-định.
- **Lead KHÔNG tự ý gọi engine-đắt** — kể cả khi đang ở chế-độ tự-động hoá workflow. Việc gate/verify thường ngày vẫn chạy bằng sub model-thường qua workflow chuẩn của bạn (đó không phải engine-đắt).

## 4. Ghi-chú trung-thực (giữ nguyên khi adopt — đừng nói quá)

- **(a) "Không tự chọn vai" là bảo-đảm ở tầng KỶ-LUẬT, không phải code cưỡng-chế.** Trong hệ chúng tôi, đường code cũ vẫn còn một fallback vai mặc-định cho lệnh-tắt kiểu cũ; bảo-đảm thật nằm ở chỗ mọi đường dẫn tới nó đều truy về một lượt owner-gõ. Nếu bạn mô tả hệ mình, hãy nói đúng nấc: "owner-gated ở tầng lệnh + kỷ-luật lead", đừng claim "code-enforced" trừ khi bạn thật sự chặn ở code.
- **(b) Lệnh-tắt (alias) cũ nếu bạn giữ = một cách owner GÁN VAI NHANH** — nó vẫn phải là owner gõ; đừng để hệ tự chọn vai qua alias.
- **(c) File spec do lead ghi SAU khi verify** — engine không tự ghi. Điều này giữ được audit-trail một-người-ghi; đổi lại lead phải làm thật bước verify, đừng ghi hộ máy móc.
- **(d) Run chấm/verify cũng sinh spec-file** — đừng miễn trừ "run này chỉ chấm thôi"; kế-hoạch xử issue chính là "cách làm" cần kết tinh.

## 5. Migration-note (adopt tối-thiểu)

- **Re-verify CHỈ hai khoản trên.** Định-nghĩa hai engine, ký-ức đổ về đúng vai kèm nhãn engine, và yêu-cầu chất-lượng cho cả hai engine — giữ nguyên từ bản trước, không adopt lại.
- Nếu bạn đã dựng **công-tắc mode/marker** theo bản trước: gỡ hoặc đánh dấu ngừng dùng (per-lệnh đã thay nó). Nếu bạn đã hardcode **hai vai verdict mặc-định**: chuyển sang vai-do-owner-gán trong lệnh.
- Quét tài-liệu hệ bạn cho các câu mô-tả hành-vi CŨ (hai-vai-cố-định, marker đang hiệu-lực) — sửa hết các chỗ đang mô tả nó như hiện-tại, giữ các dòng lịch-sử có đánh dấu. Kinh-nghiệm chúng tôi: chỗ sót hay nằm ở **file persona/agent phụ** ngoài danh-sách file đã sửa — grep theo TOKEN cũ trên toàn repo, đừng tin danh-sách file.

## 6. Cách adopt (giao-thức 2-workflow, như các bản trước)

- **Workflow thực-thi:** dựng 2 khoản trên hệ bạn — (1) mẫu file spec 3-mục + bước lead-verify-rồi-ghi + đường bơm spec vào workflow thực-thi; (2) sửa lệnh gọi engine nhận tham-số vai + bỏ mode-switch + ghi rõ lead-không-tự-ý.
- **Workflow soát-lại double-check:** chạy thử bắt lỗi biên (vai không hợp-lệ thì sao? thiếu vai thì hỏi lại owner chưa?) + grep toàn-repo token hành-vi-cũ (mode-marker, hai-vai-mặc-định) phân loại hiện-tại-vs-lịch-sử + xác nhận 4 ghi-chú trung-thực có mặt trong tài-liệu của bạn.

**Hình-thức tự quyết:** tên lệnh, dạng tên file, nơi đặt thư-mục run, và danh-sách vai hợp-lệ đều do từng project tự chọn. **Sàn chức-năng bắt buộc** gồm năm điểm: file spec ba-mục mỗi lần chạy engine-đắt; worker thực thi theo spec; engine chỉ chạy khi owner gõ lệnh; vai do owner gán đích-danh; lead không tự ý gọi. Báo-cáo lại theo mẫu qua kênh cross-project, nêu đúng nấc đã làm tới đâu.

> **Trạng-thái nguồn (dogfood):** hệ chúng tôi đã codify 2 khoản này + sửa toàn bộ lệnh/tài-liệu/engine-script cùng lượt, qua **hai vòng review-gate 2-lane** (một lane soát quy-tắc/độ-phủ-sweep, một lane đối-chiếu nguyên-văn chỉ-đạo owner). Vòng 1 bắt 1 lỗi ĐÁNG KỂ thật: một file persona phụ nằm ngoài danh-sách file đã sửa vẫn mô tả hành-vi cũ — đúng lớp lỗi "sweep thiếu tầng" mà mục 5 dặn bạn né. Vòng 2 xác nhận bản-đã-fix 0 lệch mới rồi mới stamp + phát bản này. Chưa có số-liệu chạy-thật của pipeline spec-file→worker (lượt chạy engine-đắt đầu-tiên theo khung mới sẽ là dogfood run-1) — mô tả đúng nấc: "khung đã codify + gate 2 vòng", KHÔNG phải "đã chạy N run".