Matrix Assembly Refactor Implementation Plan

Trạng thái: DRAFT — KHÔNG PHẢI BAN HÀNH. Tài liệu kế hoạch, không tự ủy quyền bất kỳ thay đổi production nào. Ngày: 2026-06-13 · Soạn: Claude Fable 5 (khảo sát read-only KB + đề bài nền của Owner) Vị trí: knowledge/dev/laws-new/matrix-refactor-implementation-plan.md Đọc kèm: matrix-refactor-quick-rules.md (rule ngắn chống đi lệch) · UI tham khảo: https://vps.incomexsaigoncorp.vn/ui-preview/mcp-writes/constitution-new-index.html Quan hệ với track cũ trong laws-new/: tài liệu này ĐỀ XUẤT thay thế định hướng "Module Contract First / Federated Registry" (README.md + modular-architecture-proposal.md + constitution.md v4.7 draft) bằng mô hình Ma trận lắp ráp. Các file cũ KHÔNG bị xóa — được phân loại lại ở §5/§6. Khi nào Owner chốt, README của track cần một dòng supersede để tránh hai SSOT định hướng song song.

1. Executive Summary

Kết luận: KHẢ THI — nên làm tiếp, với điều kiện ở §15. Mô hình ma trận không đòi xây máy móc mới; nó là cách tổ chức lại các nguyên thủy đã có.
Cả 4 chiều định vị đã có chỗ đứng trong hệ: Tầng (6 lớp cấu tạo + NT8 ASSEMBLY FIRST trong 15 NT), Loài (Đ29 + species taxonomy), Kho (collection_registry/HC-REG + meta_catalog), Miền (law_jurisdiction Đ37).
Ba lớp vận hành cũng có nền: Công thức (UMC/BOM Đ38, dispatcher Đ43), DOT (Đ35 v5.2 + NT12 cặp DOT + dot_tools), Governance state (governance_role managed/observed/excluded + candidate-state GCOS).
IO Contract tối thiểu có tiền lệ chạy thật: contracts per-route/per-sensor của Đ30/Đ31 (tests/contracts/*.json) — chỉ cần chuẩn hóa thành 1 record gọn cho mỗi ô, KHÔNG cần gói 5 artifact của module-contract-standard.
Luồng kho tạm → promote → canonical khả thi: đã có sandbox Đ41 (S0–S5), sandbox_tac, bộ staging/rollback-proof FIX7; cái thiếu là chuẩn hóa kho tạm theo tầng và quy promote 3 mức.
UI tham khảo constitution-new-index.html đã render đúng mô hình 4+3, governance 3 mức, bản đồ 6 tầng, relation graph 9 loại quan hệ, Object Card, mapping GCOS — mô hình và mặt hiển thị đã khớp nhau.
Track laws-new hiện tại (6 file, 2026-06-12) đáng giá nhất ở bằng chứng khảo sát và blast-radius A–E; phần module/federated-registry/Integration-Bus là quá nặng so với nhu cầu → hạ vai trò (§6).
Điểm hardcode chặn chạy live: fn_birth_gate còn mode=warning, "trường hợp thứ ba" khai sinh (12c) chưa được công nhận, amend_law/enact_nrm unimplemented, approver high-risk hardcode, Đ20 §6.9 cấm agent song song.
Rủi ro lớn nhất không phải kỹ thuật mà là quản trị: hai track định hướng song song trong laws-new/, ceremony tự mọc lại, và "paper lane" (lane trên giấy không ai chạy).
Khuyến nghị: chốt đề bài nền này làm định hướng track, chạy 7–10 ngày đầu chỉ ở mức giấy + kho tạm (§8), không đụng production; mọi enact đi lane Canonical như hiện hành.

2. Mục tiêu tái cấu trúc

Biến hệ từ "một khối khó sửa" thành "các ô nhỏ lắp ráp được": mỗi việc mới được định vị vào một ô ma trận, triển khai cô lập trong kho tạm, kiểm nhanh, sai thì xóa, đúng thì promote.
Triệt để hóa tư duy đã có sẵn trong Hiến pháp (NT8 ASSEMBLY FIRST, Đ7 Luật Tận dụng, 6 lớp cấu tạo, species Đ29) thành cấu trúc vận hành, không chỉ tư duy.
Mục tiêu tối thượng: Triển khai nhỏ hơn, cô lập hơn, nhanh hơn, ít rủi ro hơn. Hết tình trạng mỗi thay đổi nhỏ phải rà soát như sửa toàn hệ.
KHÔNG mục tiêu: không viết lại kernel an toàn, không thay Đ32/Đ0-G/production gate, không tạo ontology song song, không enact gì trong phạm vi kế hoạch này.

3. Mô hình cốt lõi

3.1 Bốn chiều định vị (chiều lõi — duy nhất 4)

Tầng × Loài × Kho × Miền chuyên môn

Chiều	Định nghĩa	Nền đã có
Tầng	6 tầng lắp ráp: nguyên tử → phân tử → hợp chất → vật liệu → thành phẩm → hệ con/công trình	Trường `layer` trong `meta_catalog`; "6 lớp cấu tạo" trong species-taxonomy v1.2; NT8
Loài	Nhóm đối tượng cùng bản chất, cùng cách quản lý	Đ29 v2.0; species tree 3 cấp (parent_id + depth); Luật Loài v0.5 (chờ duyệt)
Kho	Nơi lưu theo tầng/loài/trạng thái: kho tạm · kho chính · canonical	`collection_registry` (HC-REG), `meta_catalog` (CAT-*), Đ36 draft
Miền	Miền chuyên môn/nghiệp vụ (jurisdiction)	Cột `jurisdiction` Đ37 — content per-law, hạ tầng chung, đã chạy production

Lưu ý chống nhầm: Tầng lắp ráp (6 tầng cấu tạo đối tượng) KHÁC Đ5 "Kiến trúc 5 Tầng" (hạ tầng→giám sát) và KHÁC L1–L5 của modular-proposal (tầng quy trình). Kế hoạch này chỉ dùng chữ "Tầng" cho 6 tầng lắp ráp; hai hệ kia giữ tên riêng (Đ5 giữ nguyên; L1–L5 nghỉ — §6).

3.2 Ba lớp vận hành gắn vào mỗi ô

Công thức + DOT + Governance state   (kèm IO Contract — §11)

Công thức: mô tả lắp một đối tượng từ nguyên liệu trực tiếp của tầng dưới (input refs + các bước + output schema). Công thức tầng nào chỉ xử lý nguyên liệu trực tiếp tầng đó.
DOT: máy lắp/kiểm/promote/rollback — tái dùng Đ35 v5.2 + NT12 (cặp DOT), đăng ký trong dot_tools như hiện hành. Không sinh "engine" mới.
Governance state: trạng thái quản trị của ô và của object trong ô (workspace_candidate → promoted → canonical; cùng governance_role managed/observed/excluded đã có).

3.3 Những thứ KHÔNG phải chiều

Quan hệ = graph riêng (universal_edges đã có, 2.199 cạnh; IU-edges uuid riêng theo thiết kế 2026-05-28 "no hidden second graph SoT"). Trả lời: thuộc ai / ai thuộc tôi / dùng ai / ai dùng tôi / sinh bởi công thức nào / DOT nào kiểm / nằm kho nào / governed_by ai. UI: Object Card.
Capability/năng lực/điều kiện đáp ứng = thuộc tính lọc trên object, không phải chiều.
Task/request/người thực hiện = overlay vận hành bên ngoài ma trận.
Cấm quay lại thiết kế "7 chiều phẳng" (species-taxonomy v1.2 từng tuyên bố "Registries UI = 7 chiều = 6 lớp + 1 meta-layer species"). Ma trận chỉ có 4 chiều; species là 1 chiều thật, không phải meta-layer dán thêm.

3.4 Mỗi ô tối thiểu phải khai báo

cell_id (tầng, loài, kho, miền) + công thức + DOT lắp/kiểm + IO Contract (§11) + governance state + rollback. Thiếu một trong các mục này → ô chưa hợp lệ để promote (vẫn được phép thử trong kho tạm).

4. Đánh giá tận dụng hệ cũ (khảo sát 2026-06-13, read-only)

4.1 `laws-new/` hiện có (6 file DRAFT, track "Modular Architecture", 2026-06-12)

File	Đánh giá
`architecture-survey.md`	Giá trị nhất — bằng chứng trung lập với mô hình: 7 bottleneck, 14 nguyên thủy tái dùng, risk map R1–R10, danh sách hardcode (§4.6 dưới). Giữ làm tham khảo bắt buộc.
`modular-architecture-proposal.md`	Giữ: blast-radius A–E (computed, fail-closed-upward), anti-ceremony cap, pipeline Levels 0–4 (gập về 3 mức), globalization test, kernel-frozen. Bỏ/hạ: 5-layer L1–L5, module=Đ44-family, Integration Bus L4, federated envelope/slice registry.
`module-contract-standard.md`	Giữ làm kho vật liệu schema: `mutation_contract`/`operations` → IO Contract; `rollback_contract`/`evidence_contract` → check promote; F1–F9 forbidden patterns → rule promote-gate (đổi "module"→"ô/kho tạm"). Bỏ: gói 5 artifact bắt buộc, semver/consumer re-test, namespace-prefix theo module.
`migration-map.md`	Giữ phương pháp: same-filename SSOT, strangler/shadow-run 2–4 tuần, "checker fail-closed chạy block-mode trước khi mở lane", prerequisites P2–P5. Wording các amendment (module-shaped) phải viết lại theo ô/miền. P1 (internal edges) có thể tự tan vì quan hệ không phải chiều.
`constitution.md` (v4.7 draft)	Part I (kernel giữ nguyên cường độ, 15 NT verbatim) dùng lại gần nguyên. Bỏ NT16 "MODULE CONTRACT FIRST", M-1 (5 layers), M-5 (federation). Giữ gần nguyên M-2/M-3/M-4/M-6 với "module"→"phạm vi ô khai báo". M-6 chính là luật kho tạm.
`README.md`	Giữ cơ chế track (SSOT rule, filename rule, draft≠enact); mục "target direction" cần dòng supersede khi Owner chốt ma trận.

4.2 Luật cũ (`knowledge/dev/laws/` — enacted baseline, KHÔNG sửa trong phạm vi này)

Hiến pháp v4.6.3 BAN HÀNH: 15 NT, 4-DB + 3 lớp Não–Kho–Cổng, catalog Đ0–Đ44 — là baseline; ma trận là lớp tổ chức bên trên, không thay kernel.
Đ0-G Khai sinh (+ birth_registry, fn_birth_register, chuỗi 5 trigger): giữ nguyên làm lớp identity; thiếu phần khai sinh cho object sinh trong kho tạm (12c) — §7.
Đ29 / species-taxonomy v1.2 / Luật Loài v0.5: nền chiều Loài; cần hợp nhất thành 1 danh mục loài chuẩn (v0.5 đang "chờ phê duyệt").
Đ35 DOT v5.2 BAN HÀNH: giữ nguyên — DOT của ô đăng ký như mọi DOT khác.
Đ36 Collection v5.0 DRAFT 30%: đúng chỗ để chuẩn hóa Kho theo tầng — hoàn thiện theo hướng ma trận thay vì viết luật mới.
Đ30/Đ31: contracts per-route/per-sensor đã chạy thật → khuôn mẫu IO Contract.
Đ32 Phê duyệt: trục duy nhất; promote mức 2 nối vào đây, không tạo trục thứ hai.
Đ38 TAC + LSL-01 ("Miếng thông tin làm trung tâm", council-pass): miếng thông tin = viên gạch nguyên tử của hệ tri thức — ô pilot tự nhiên (§8). sandbox_tac là kho tạm mẫu đang tồn tại.
Đ39 Knowledge Graph v2.3 BAN HÀNH: chạy lane độc lập (Bước 6 đề bài) — KG hỗ trợ gợi ý quan hệ/ngữ nghĩa, không là blocker; quan hệ canonical vẫn qua rule/DOT/promote.
Đ44 UOSL v0.1.2 controlled DRAFT: hạ vai trò từ "spine liên bang" xuống "một cách hiện thực hóa kho + object model"; UMC 10 phần tử lõi tái dùng cho Công thức.
Đ20 (thiết kế trước triển khai) + Đ41 (zones S0–S5): giữ; §6.9 cấm song song cần nới theo ranh giới ô (sửa luật theo §13, chưa làm ngay).

4.3 Governance / GCOS / One-Roof (pack 2026-06-01, design-only, BUILD NO-GO)

Nguyên tắc One-Roof giữ nguyên làm trần: một governance_registry, một trục Đ32, một hệ phát hiện Đ31+Đ45, một mô hình DOT Đ35 — "không có đảo quản trị cục bộ". Ma trận không thiết kế governance mới; governance 3 mức (§10) chỉ là cách route vào trần One-Roof theo blast radius.
GCOS substrate (SB-10..SB-13, C-7, ruleset/worker-cursor) vẫn design-only — ma trận đối xử GCOS là lớp dưới sẽ tới sau, ô ma trận = view/control layer như chính UI preview mô tả ("GCOS mapping"). Không chờ GCOS mới chạy kho tạm.
Các DOT scanner coverage của One-Roof (dot_governance_coverage_scan…) chưa tồn tại — không được giả định có.

4.4 Khai sinh / birth

Một chuỗi khai sinh duy nhất vào một birth_registry — đúng tinh thần One-Roof, giữ. Gap: fn_birth_gate còn mode=warning (đếm được nhưng chưa chặn được), và object sinh trong kho tạm chưa có loại khai sinh phù hợp (QT-001/QT-002 + "trường hợp thứ ba" 12c chưa formal). Đề xuất nguyên tắc: vào kho tạm = chưa cần khai sinh canonical; promote = thời điểm khai sinh/ghi sổ (một lần, qua đường fn_birth_register hiện có).

4.5 Collection / species / DOT (hiện trạng production)

collection_registry (HC-REG: unregistered = CRITICAL), meta_catalog CAT-* có trường layer, dot_tools (code space toàn cục + paired-DOT FK), canonical_fields, universal_edges 2.199 cạnh (integer-keyed; IU edges uuid riêng), normative_registry, governance_audit_log, system_issues + fn_log_issue, apr_action_types.risk_level. → Cả 3 sổ cần cho ma trận đều đã có; việc cần làm là gắn tọa độ ô (4 chiều) làm thuộc tính/cột bổ sung trên sổ hiện hành, KHÔNG tạo registry mới.

4.6 Điểm hardcode đang chặn chạy live (từ architecture-survey, giữ nguyên ý)

fn_birth_gate còn mode=warning; 2. Đ41 enforcement chưa xây (không có vps_deploy_log, thiếu 6 guard DOT, không deploy script); 3. QT001 apply bị đánh giá NOT_SAFE; 4. FIX7 CI seal-vs-bytes chưa adopt vào CI; 5. Nuxt main divergent + không push credentials; 6. amend_law/enact_nrm = handler_ref='unimplemented' (Đ32 §3.3/§7) — mọi enact phải đi đường thủ công có chủ quyền; 7. high-risk hardcode "president + 2 AI-council" mọi nơi; 8. một approver waiver duy nhất (Đ30); 9. Đ20 §6.9 cấm agent song song; 10. một PG cluster / một GSM password; 11. O11 isolation runner chưa provision. → Ma trận chạy được ở mức kho tạm + giấy ngay; chạy live đầy đủ cần xử lý dần các mục này (ưu tiên ở §7/§9).

5. Danh sách GIỮ LẠI

Kernel an toàn nguyên cường độ: 15 NT, 4-DB/3-lớp, Đ0-G, Đ32, production gate Tier-0, rollback law, audit log (Part I của v4.7 draft dùng lại).
One-Roof làm trần governance duy nhất; GCOS design làm lớp dưới tương lai.
Blast-radius A–E computed, fail-closed-upward + anti-ceremony cap ("thêm artifact bắt buộc vào lane A/B tự nó là thay đổi Class D").
M-6 sandbox law (≈ luật kho tạm), M-2/M-3/M-4 với "module"→"phạm vi ô".
Schema vật liệu từ module-contract-standard: operations, mutation_contract (target pg.* | kb.* | qdrant.*), rollback_contract (PROVEN_IN_STAGING + 2 gate ROLLBACK_*), evidence_contract (bad-input ≥8 lớp, any_fail_open:false), F1–F9.
Phương pháp migration: same-filename SSOT, strangler/shadow 2–4 tuần, checker-before-lane, prerequisites P2–P5, "rollback = ngừng dùng lane mới".
Đ35 DOT, Đ29 species, Đ30/Đ31 contracts, Đ37 jurisdiction, Đ39 KG (lane riêng), Đ38 TAC + LSL-01 + sandbox_tac.
Sổ hiện hành: birth_registry, collection_registry, meta_catalog, dot_tools, universal_edges, canonical_fields, system_issues.
UI constitution-new-index.html làm thiết kế hiển thị chuẩn (4+3, 3 mức, bản đồ 6 tầng, Object Card, bảng đỏ 10 vi phạm).
Toàn bộ kết quả FIX7 (validator hardened, staging rollback-proof, bad-input probes) làm bộ đồ nghề kiểm promote.

6. Danh sách LOẠI BỎ hoặc HẠ VAI TRÒ

Mục	Xử lý	Lý do
NT16 "MODULE CONTRACT FIRST" + Điều M-1 (5 layers) + M-5 (federated registry)	Loại khỏi bản hiến pháp ma trận tương lai	Mâu thuẫn trực tiếp: đơn vị phân hoạch là Ô, không phải module
Naming L1–L5 (Core Kernel→Promotion Pipeline)	Nghỉ	Đụng chữ "tầng/layer" với 6 tầng lắp ráp — rủi ro nhầm cao
Module ≈ Đ44 family, MODULE_MANIFEST, namespace-prefix theo module	Hạ vai trò → chi tiết hiện thực hóa kho, không phải spine	Ma trận không có chiều module
L4 Integration Bus (adapter/version-negotiation/broker)	Hạ → chỉ giữ "boundary validation fail-closed" như thuộc tính IO Contract	Máy móc mới không cần thiết khi quan hệ không phải chiều
Federated envelope/slice registry + drift-checker DOT per module	Bỏ	Tự sinh failure-mode mới (R4); kho tạm/canonical đạt cùng mục đích với 1 sổ
Gói 5 artifact contract bắt buộc per module	Hạ → chỉ mức Canonical mới cần packet đầy đủ (kiểu FIX7); ô thường = 1 record IO Contract	Chống phình ceremony
Semver/compatibility/consumer re-test machinery	Hạ → ghi chú tương lai	Tiền giả định dependency-graph module
Thiết kế "7 chiều phẳng" (6 lớp + meta-layer species)	Không dùng lại	Ràng buộc D6 đề bài; ma trận 4 chiều thay thế
§7 recommendation của architecture-survey ("Đ44/SCMR/UMC làm federated registry")	Supersede bằng kế hoạch này	Tránh hai định hướng SSOT trong cùng track

7. Danh sách THIẾU cần làm

Nhóm thiếu	Hiện trạng	Mức nguy hiểm	Cần làm tối thiểu	Ưu tiên
Khai sinh	`fn_birth_gate`=warning; 12c (sinh trong kho tạm) chưa formal	CAO (đếm được, chưa chặn được)	Định nghĩa "khai sinh khi promote"; spec 12c trên giấy; lộ trình bật block-mode sau khi đo coverage	P1
Tầng	6 tầng có trong dữ liệu (`layer`) nhưng chưa có danh mục chuẩn enacted; lẫn lộn với Đ5 5-tầng	TRUNG	1 file danh mục 6 tầng + quy tắc "tầng trên lắp từ tầng dưới trực tiếp" + bảng phân定 tên gọi	P1
Loài	Đ29 v2.0 + taxonomy v1.2 + Luật Loài v0.5 chưa hợp nhất, v0.5 chờ duyệt	TRUNG	1 danh mục loài chuẩn (map cả 3 nguồn), mỗi loài → tầng mặc định	P1
Kho/Collection	`collection_registry` chạy; kho tạm chỉ có cục bộ (`sandbox_tac`, Đ41 zones); Đ36 draft 30%	CAO (không có kho tạm chuẩn → mọi việc dồn lane nặng)	Chuẩn kho tạm per-tầng (naming, TTL, quyền xóa); hoàn thiện Đ36 theo ma trận	P1
Công thức	UMC 10 phần tử + BOM Đ38 có; chưa có sổ công thức	TRUNG	Schema công thức v0.1 (inputs trực tiếp + steps + output + DOT ref); lưu như object thường trong kho, không registry mới	P2
DOT	`dot_tools` + cặp DOT chạy; thiếu phân vai lắp/kiểm/promote/rollback theo ô	TRUNG	Quy ước gắn `cell_id` + vai trò (assemble/check/promote/rollback) vào DOT registration hiện có	P2
IO Contract	Đ30/Đ31 contracts chạy cho route/sensor; chưa có chuẩn per-ô	TRUNG	Schema IO Contract tối thiểu (§11) — 1 record JSON	P1
Governance 3 mức	Đủ nguyên thủy (governance_role, Đ32, FIX7) nhưng chưa có bảng route chính thức	CAO	Bảng map A–E → 3 mức (§10) + checker fail-closed cho promote chạy block-mode trước khi mở lane	P1
Relation graph / Object Card	`universal_edges` 2.199 cạnh integer-keyed; IU-edges uuid riêng; Object Card chỉ có trong UI preview	TRUNG-THẤP	Chuẩn 9 loại quan hệ (theo UI preview); Object Card đọc từ edges hiện có; KHÔNG gộp 2 store cạnh	P3
Knowledge graph	Đ39 enacted, độc lập	THẤP	Không làm gì trong 10 ngày; giữ nguyên lane riêng, không blocker	P4
Constitution / laws-new	v4.7 draft module-shaped; track có 2 định hướng	CAO (rủi ro 2 SSOT)	Dòng supersede trong README + đề cương v4.7-matrix (Part I giữ, Part II = ma trận)	P1

8. Kế hoạch 7–10 ngày đầu (chỉ giấy + kho tạm, KHÔNG production)

Ngày 1–2 — Chốt đề bài + dọn track: Owner duyệt tài liệu này làm định hướng; thêm dòng supersede vào README.md (track mechanics giữ nguyên); đánh dấu disposition 6 file cũ theo §5/§6.
Ngày 2–4 — Bốn danh mục chuẩn hóa (draft): matrix-layer-catalog.md (6 tầng), matrix-species-catalog.md (hợp nhất Đ29/taxonomy/v0.5), matrix-collection-catalog.md (kho theo tầng + chuẩn kho tạm), matrix-domain-catalog.md (miền, từ jurisdiction). Mỗi file ngắn, dạng bảng, không luật mới.
Ngày 4–6 — IO Contract + tọa độ ô: schema io-contract-minimal.v0.1 (§11) + quy ước cell_id; map thử 20–30 object hiện có trong meta_catalog vào ô để đo độ phủ 4 chiều (read-only, xuất báo cáo).
Ngày 6–8 — Pilot 1–2 ô trong kho tạm: ô đề xuất: (a) (nguyên tử, information_unit, sandbox_tac, TAC) — miếng thông tin, tận dụng Đ38; (b) một ô tầng "vật liệu/thành phẩm" phía UI (Đ28 template). Chạy đủ vòng: mở ô tạm → lắp bằng công thức → DOT kiểm → IO Contract check → xóa thử (chứng minh "sai thì xóa") → diễn tập promote trong staging với rollback-proof kiểu FIX7. Không ghi canonical.
Ngày 8–10 — Governance route + tổng kết: bảng A–E→3 mức (§10) + draft checker promote fail-closed (selftest, chưa gắn lane); báo cáo pilot + danh sách điều chỉnh; Owner quyết bước kế (mặc định HOLD đối với mọi thứ chạm canonical/production).

Định nghĩa DONE của 10 ngày: 2 pilot cell chạy hết vòng trong kho tạm với bằng chứng xóa được + promote-rehearsal pass trong staging; 4 danh mục + IO Contract v0.1 nằm trên laws-new/; chưa có bất kỳ mutation canonical/production nào.

9. Roadmap sau 10 ngày

Tuần 3–4: shadow-run (strangler): việc mới đi luồng ô-ma-trận song song luồng cũ, so chi phí/sự cố (tiền lệ Đ38 R9). Mở rộng pilot lên 5–10 ô ở ≥3 tầng.
Hiệu chỉnh luật (paper trước): Đ36 hoàn thiện theo ma trận; Đ32 thêm scope-routing (quorum giữ nguyên); Đ20 §6.9 nới theo ranh giới ô; Đ35 thêm thuộc tính cell/vai trò DOT; 12c formal hóa khai sinh-khi-promote. Tất cả qua lane Canonical hiện hành.
Bật dần enforcement: fn_birth_gate warning→block sau khi đo coverage đạt; checker promote block-mode trước khi mở lane promote thật (rule "no lane before checker").
Object Card + relation view đọc từ universal_edges/IU-edges (read-only trước).
KG lane riêng tiếp tục theo Đ39; gợi ý quan hệ từ KG chỉ thành canonical qua promote.
Production: mọi thứ chạm production giữ nguyên trạng thái khóa hiện hành (các blocker prod đang OPEN ở track khác); ma trận không tự mở thêm bất kỳ cổng production nào.

10. Governance 3 mức (route vào One-Roof, không thay One-Roof)

Mức	Phạm vi	Kiểm	Map blast-radius
Mức 1 — Workspace/kho tạm	Thử nghiệm, lắp, candidate	Kiểm nhẹ (schema thô + an toàn cô lập). Sai thì xóa. Không ghi canonical, không sửa lõi, không sửa công thức/kho/loài canonical	Class A, B
Mức 2 — Promotion	Đưa kết quả vào kho chính	Chỉ kiểm cục bộ: đúng ô? đúng input? đúng schema? DOT kiểm pass? relation bắt buộc đủ? rollback có? owner/scope rõ? — checker fail-closed, evidence kiểu FIX7 rút gọn	Class C
Mức 3 — Canonical/Kernel	Khai sinh-luật, kernel, tầng/loài/collection canonical mới, công thức canonical, owner/scope, production gate, approval/audit/rollback rule	Chặt như hiện tại: Đ32 đầy đủ + packet đầy đủ + rollback PROVEN_IN_STAGING	Class D, E

Nguyên tắc: class được tính, không tự khai; phân loại sai → incident + nâng lane (probation); nghi ngờ → fail-closed lên mức trên. Trần ceremony: lane mức 1–2 có số artifact bắt buộc cố định; muốn thêm artifact bắt buộc = thay đổi mức 3.

10b. Stamp-based Governance (cách thực thi lớp "Governance state")

Chi tiết: matrix-stamp-governance-addendum.md (khảo sát 2026-06-13 → GO/ADJUST).

Khai sinh chỉ cấp căn cước tối thiểu (8 trường birth_registry hiện có). Governance state được hoàn thiện dần bằng các dấu kiểm soát do DOT đóng — tổng quát hóa mô hình PEN/STAMP/GATE đã ban hành ở Điều 0-G (cột inspect_pen/stamp/gate, mỗi dấu một DOT inspector độc lập, certified khi đủ dấu; thêm dấu = ALTER ADD COLUMN inspect_*, không sửa code). Object thiếu dấu bị liệt kê/cảnh báo/chặn promote (certified=false chờ trong idx_birth_uncertified; fail → system_issues/fn_log_issue), KHÔNG vô hiệu hóa entity đang chạy. Promote vào kho chính fail-closed nếu thiếu dấu bắt buộc.

Stamp KHÔNG phải chiều ma trận — là nội dung lớp "Governance state" (§3.2) ở mức object. 3 mức governance (§10) = 3 tập dấu theo lifecycle stamp (đồng bộ required-stamps.v0.1.json):
- Mức 1 — kho tạm: required = TEMP_ID_STAMP (object có workspace_id/candidate_id để thao tác/xóa/rollback; KHÔNG ghi birth_registry canonical).
- Mức 2 — promote: checker chỉ kiểm promote_preconditions = TEMP_ID_STAMP + CELL_STAMP + IO_STAMP + VALIDATION_STAMP + ROLLBACK_STAMP; nếu pass mới đóng promote_outputs = BIRTH_STAMP + PROMOTE_STAMP (OUTPUT, KHÔNG phải precondition — tránh circular). COLLECTION/SPECIES nằm trong CELL_STAMP, không phải dấu bắt buộc riêng.
- Mức 3 — canonical/kernel/high-risk: canonical_required = BIRTH_STAMP + CELL_STAMP + IO_STAMP + VALIDATION_STAMP + ROLLBACK_STAMP + PROMOTE_STAMP; GOV_STAMP/OWNER_STAMP chỉ áp dụng vùng canonical/kernel/high-risk, không bắt buộc mọi object.
Tận dụng, không tạo bảng mới: post-promote stamp ledger = cột inspect_* của birth_registry, pre-promote stamps ở candidate/workspace staging metadata (addendum §2b); provenance = event_outbox/registry_changelog/vps_deploy_log/governance_audit_log; scanner thiếu dấu = Đ23 inverse-check + truy vấn birth_registry. governance_candidate_state (SB-10, design-only) là lớp candidacy group-grain — bổ sung, không trùng. Chỉ đề xuất governance_stamp_ledger nếu thật sự cần stamp per-object trước-khai-sinh (xem addendum §9).
BIRTH_STAMP đóng tại promote — thống nhất với §4.4/§12.3 "khai sinh khi promote".
Candidate packet + Atomic Promote Contract: checker đọc 1 candidate packet (verdict-only, không tự mutate); tạo birth + đóng BIRTH/PROMOTE + consume staging là atomic transaction riêng sau checker (addendum §7b, spec §2). Pre/post-promote stamp store tách ở addendum §2b.

11. IO Contract tối thiểu (1 record / ô — không phải gói 5 file)

io_contract.v0.1:
  cell_id: {layer, species, collection, domain}
  accepts:   [{ref, layer_check: "direct lower layer only", schema_min}]
  returns:   [{schema_min, target: "pg.<db>.<schema>.<table> | kb.<path> | qdrant.<collection>"}]
  checks:    {dot_check: <dot_code>, bad_input_min_classes: 8, any_fail_open: false}
  rollback:  {how: "delete-workspace | reverse-patch | snapshot-restore", proof: "required at promotion"}
  owner_scope: {owner, scope}

Đủ để ghép ô mà không sinh module-contract khổng lồ: phần compatibility/semver/consumer của chuẩn cũ chỉ kích hoạt ở mức 3 nếu thật sự cần.

12. Quy tắc kho tạm / kho chính

Mặc định mọi triển khai mới đi vào kho tạm: mở ô tạm → lắp thử → kiểm nhanh → sai thì xóa → đúng thì promote.
Không ghi thẳng kho chính; kho chính chỉ nhận qua promote (mức 2).
Kho tạm phải xóa được trọn vẹn (delete = rollback hợp lệ của mức 1); object kho tạm không cần khai sinh canonical — khai sinh xảy ra khi promote.
Mỗi tầng có kho tạm + kho chính + công thức + DOT lắp/kiểm/promote + validator + quy tắc promote + rollback của tầng đó.
Output kho tạm là thông tin/candidate — không bao giờ là thay đổi đã áp (theo M-6: "Sandbox output is information… never an applied change"; "A paper lane is no lane").
Sandbox hiện có (sandbox_tac, Đ41 S0–S5, mktemp staging) được công nhận là kho tạm hợp lệ trong khi chờ chuẩn hóa danh mục kho.

13. Quy tắc cập nhật luật cũ

Luật cũ không bị bỏ — thành nền tham khảo + mục tiêu chuyên môn; giữ tinh thần đúng, bỏ phần làm phình, diễn giải lại theo ma trận.
Không sửa luật cũ trước khi có mapping sang ma trận (bảng mapping điều-khoản → ô/chiều/mức, theo phương pháp migration-map: preserved/amended/moved, không xóa-không-làm-yếu).
Sửa same-filename trong laws-new/ (SSOT cho track), luật enacted thắng cho tới khi enact bản mới qua lane mức 3.
Thứ tự sửa đề xuất: Đ36 (Kho) → Đ32 scope-routing → Đ20 §6.9 → Đ35 cell-attribute → Đ0-G/12c. Mỗi bản sửa cần checker/DOT đi kèm chạy block-mode trước khi mở lane tương ứng.

14. Rủi ro và giảm rủi ro

Rủi ro	Giảm thiểu
Hai SSOT định hướng trong `laws-new/` (module-track vs matrix)	Dòng supersede ở README ngay ngày 1; disposition rõ từng file (§5/§6)
Ceremony tự mọc lại (R8)	Trần artifact cố định lane 1–2; thêm yêu cầu = thay đổi mức 3
Paper lane — lane trên giấy không dùng được (R9)	Checker chạy block-mode + pilot thật trong kho tạm trước khi tuyên bố lane mở
Phân loại blast-radius sai (R2)	Class computed, fail-closed-upward, misdeclare = incident + probation
Drift giữa tọa độ ô và sổ hiện hành (R4)	Không tạo registry mới; cell_id là thuộc tính trên `meta_catalog`/`collection_registry`; 1 DOT đối soát định kỳ
Nhầm "Tầng" (3 nghĩa: 6 tầng lắp ráp / Đ5 5-tầng / L1–L5)	Bảng phân định tên gọi trong layer-catalog; L1–L5 nghỉ
Kho tạm thành bãi rác không xóa	TTL + quyền xóa trong chuẩn kho tạm; "sai thì xóa" là hành vi mặc định
Hardcode chặn live (birth gate warning, amend_law unimplemented…)	Chạy giấy+kho tạm trước (không bị chặn); xử lý hardcode theo ưu tiên §7, không coi là blocker của 10 ngày đầu
KG bị kéo thành blocker	Lane KG độc lập (Đ39); ma trận không phụ thuộc KG
Promote thành nút cổ chai mới	Kiểm mức 2 CHỈ cục bộ (7 câu hỏi §10); việc cross-cell mới lên mức 3

15. Kết luận

NÊN LÀM TIẾP. Mô hình Tầng × Loài × Kho × Miền + Công thức + DOT + Governance state + IO Contract tối thiểu là đủ để định vị và vận hành phần lớn object hiện có — bằng chứng: cả 4 chiều và 3 lớp đều đã có nền chạy thật hoặc design đã duyệt; UI tham khảo đã render đúng mô hình. Không cần khái niệm mới nào ngoài: (1) cell_id như thuộc tính trên sổ hiện hành, (2) chuẩn kho tạm per-tầng, (3) IO Contract 1-record — cả ba đều là chuẩn hóa, không phải máy móc mới.

Điều kiện trước khi vượt khỏi giấy + kho tạm: (a) Owner chốt supersede track module; (b) 4 danh mục + IO Contract v0.1 được duyệt; (c) checker promote fail-closed pass selftest; (d) pilot chứng minh "sai thì xóa" và promote-rehearsal trong staging. Mọi enact luật và mọi thứ chạm production vẫn đi lane Canonical/Đ32 hiện hành và các cổng production hiện đang khóa — kế hoạch này không mở chúng.