Danh mục câu hỏi trước khi tái cấu trúc — Matrix Assembly + Stamp Governance

Trạng thái: DRAFT — QUESTION CATALOG / CHECKLIST. Không phải roadmap, không phải gap report, không phải thiết kế kỹ thuật, không phải quyết định triển khai. Vị trí: knowledge/dev/laws-new/cau-hoi-khi-tai-cau-truc.md · Ngày: 2026-06-15 (rev3 — bám đề bài rev33: thêm nguyên tắc reuse-first / minimal-fastest, Nhóm 0 — Reuse Baseline, mục Reuse-first / Minimal-fastest Decision Rule, cột Reuse Check + Minimal/Fastest Path cho bảng reuse, và câu hỏi reuse-first cho từng nhóm A–N; rev2 — tách Answer Status / Gate Impact, thêm Acceptance Criteria + Dependency Map + câu hỏi bổ sung; rev4 — bổ sung Nhóm R: Operational Risk Gates + thêm L5b vào Dependency Map, để kiểm rủi ro triển khai và vận hành trước atomic promote rehearsal / pilot). Mục tiêu: chốt danh sách câu hỏi bắt buộc phải trả lời TRƯỚC khi tái cấu trúc → chống bỏ sót, chống khảo sát lan man, chống kết luận thiếu. Đây là bộ câu hỏi kiểm soát phạm vi, KHÔNG phải nơi chứa câu trả lời. Đọc kèm (active laws-new): de-bai-cai-tien.md (rev33 — §IV governance = bản đồ quan hệ, §V khai sinh + đóng dấu, §VI Lego Protocol, §III.6 IO Contract v0.1 = 5 field) · roadmap-cai-tien.md (rev1) · matrix-refactor-implementation-plan.md (rev5) · matrix-refactor-quick-rules.md (rev8) · matrix-stamp-governance-addendum.md (rev14) · promote-checker-v0.1-spec.md (rev11) · required-stamps.v0.1.json (rev6). Báo cáo khảo sát cũ (CHỈ để đối chiếu sơ bộ — KHÔNG coi là đầy đủ, KHÔNG nâng câu hỏi lên APPROVED): /Users/nmhuyen/matrix-stamp-gap-reports-2026-06-14.md. Dưới đây gọi tắt là [GR]. Mọi nội dung từ [GR] chỉ xuất hiện ở cột Old Survey Coverage dưới dạng tóm tắt rất ngắn ("Old survey: …" / "Needs verification: …").

1. Mục đích tài liệu

Đây là danh mục câu hỏi trước khi tái cấu trúc — bộ câu hỏi kiểm soát phạm vi.
Chưa phải roadmap. Chưa phải thiết kế kỹ thuật. Chưa phải quyết định triển khai.
Mục tiêu duy nhất: chống bỏ sót. Biết câu nào đã trả lời, câu nào chưa, câu nào trả lời chưa thỏa mãn, câu nào mâu thuẫn — và câu nào chặn cổng (gate).
File này không trả lời dứt điểm. Việc trả lời đúng/đủ làm ở vòng sau, sau khi Owner duyệt danh mục.
Báo cáo khảo sát cũ [GR] không được biến file này thành Gap Report: cột Old Survey Coverage chỉ tóm tắt cực ngắn để biết câu nào "đã có câu trả lời sơ bộ / cần kiểm chứng".
Tài liệu này không triển khai, không mutate DB/production, không sửa knowledge/dev/laws/, không viết checker, không mở pilot, không tạo registry/table/collection/DOT thật.

1b. Nguyên tắc reuse-first / minimal-fastest (bám đề bài rev33)

Question Catalog này KHÔNG nhằm hỏi để thiết kế lại toàn hệ. Mỗi nhóm câu hỏi phải bắt đầu từ thực tế: hệ đã có gì, dùng lại được gì, thiếu gì tối thiểu, cách nào nhanh nhất/nhẹ nhất để đạt mục tiêu.
Mỗi câu hỏi không chỉ hỏi "cần gì" mà phải hỏi: (1) hệ đã có phần tương đương nào · (2) dùng lại nguyên trạng được không · (3) nếu không, cần chỉnh tối thiểu gì · (4) có cần tạo mới không · (5) nếu tạo mới thì vì sao cái cũ không đủ.
Bám tinh thần đề bài rev33: reuse-first · minimal-change · fastest path to working pilot · workspace-first · delete-fast · IO Contract boundary · no monster system · no unnecessary registry/ledger/workflow (de-bai §IV.5–§IV.6, §V.11, §V.13, §VI.7).
Câu chốt: Có nhiều cách làm đúng về lý thuyết, nhưng cách đúng cho v0.1 là cách dùng lại nhiều nhất, ít thay đổi nhất, chạy được nhanh nhất trong kho tạm, sai thì xóa được, đúng thì promote được.

2. Cách dùng checklist

Mỗi vòng khảo sát theo pilot slice phải cập nhật Answer Status + Mức thỏa mãn cho các câu áp dụng cho selected pilot slice + direct dependencies + cross-cutting gates, gắn bằng chứng; các câu ngoài slice được giữ TODO/DEFER và không chặn slice.
Answer Status (trạng thái trả lời) và Gate Impact (mức ảnh hưởng cổng) là HAI trục khác nhau — không trộn. BLOCKER không còn là Answer Status; nó là Gate Impact.
Không chuyển sang checker/rehearsal/pilot nếu mọi câu Gate Impact = BLOCKER áp dụng cho selected pilot slice + direct dependencies + cross-cutting gates chưa đạt Answer Status ≥ ANSWERED và Mức ≥ 3.
Không gọi Codex để trả lời toàn bộ; chỉ gọi Codex để audit chất lượng Question Catalog + Dependency Map. Việc trả lời từng dòng áp dụng cho selected pilot slice + direct dependencies làm sau khi Owner duyệt slice và blocker set.
Báo cáo khảo sát cũ chỉ cho mức tối đa 3. Mức 4 / APPROVED chỉ Owner hoặc Codex cấp — không câu nào lên APPROVED chỉ vì [GR] đã đề cập.
Một câu hỏi "đủ" khi đạt Acceptance Criteria của nó (cột riêng) — đây là tiêu chí "đạt/chưa đạt" cho vòng sau.

Schema bảng câu hỏi (bảng trả lời chuẩn — 9 cột)

Schema bảng câu hỏi reuse-first (BẮT BUỘC cho Nhóm 0 + các khối `*-REUSE` per-nhóm)

Hai cột Reuse Check và Minimal/Fastest Path là phần bổ sung bắt buộc theo đề bài rev33. Để tránh phá vỡ/làm phình các bảng 9 cột đang có, reuse-first được chứa trong bảng reuse riêng (Nhóm 0 + khối *-REUSE của từng nhóm A–N) theo schema dưới đây, thay vì nhồi thêm cột vào mọi bảng trả lời. Vòng khảo sát sau phải điền cả hai cột cho mọi câu reuse trước khi đề xuất bất kỳ việc tạo-mới nào.

Reuse Check = phải trả lời: hệ hiện đã có artifact/schema/table/function/DOT/metadata nào tương đương, dùng lại được tới đâu (nguyên trạng / chỉnh metadata / wrapper nhẹ / phải viết mới).
Minimal/Fastest Path = phải trả lời: cách ít sửa nhất, nhanh nhất, chạy được trong kho tạm, sai thì xóa được — để đạt mục tiêu của câu đó.
Mọi câu trong bảng reuse mặc định Answer Status = TODO cho tới khi vòng khảo sát reuse-first điền bằng chứng (đề bài rev33 vừa chốt, chưa có vòng khảo sát reuse nào chạy).

Quy ước Answer Status (trạng thái trả lời)

Status	Nghĩa
`TODO`	chưa khảo sát / chưa có câu trả lời
`PARTIAL`	đã trả lời nhưng chưa đủ (chưa đạt Acceptance Criteria)
`ANSWERED`	đã trả lời đủ theo Acceptance Criteria (bằng chứng), chưa Owner duyệt
`CONFLICT`	có câu trả lời mâu thuẫn giữa các nguồn
`APPROVED`	Owner/Codex đã duyệt là đủ (chỉ cấp ở vòng sau)

Quy ước Gate Impact (mức ảnh hưởng cổng)

Gate Impact	Nghĩa
`BLOCKER`	thiếu/chưa đạt câu này thì không được đi tiếp (checker/pilot). Phải ≥ ANSWERED & Mức ≥ 3.
`REQUIRED`	bắt buộc cho v0.1 nhưng không tự mình chặn cổng
`OPTIONAL`	nên có, không bắt buộc v0.1
`DEFER`	để sau v0.1

Quy ước Mức thỏa mãn

Mức	Nghĩa
0	chưa có bằng chứng
1	có nhận định nhưng thiếu bằng chứng
2	có bằng chứng sơ bộ
3	đủ bằng chứng để quyết định sơ bộ
4	Owner/Codex duyệt

Lưu ý áp dụng: Answer Status / Mức điền sẵn dưới đây là trạng thái sơ bộ suy từ [GR] một lượt — chưa Owner duyệt (không câu nào ở APPROVED/Mức 4). Gate Impact điền sẵn cũng provisional; Owner sẽ chốt lại câu nào thực sự BLOCKER.

2b. Dependency Map — thứ tự trả lời từ tầng thấp lên tầng cao

Trả lời câu hỏi theo lớp; không nhảy cóc. Lớp dưới chưa đạt thì lớp trên không đủ bằng chứng để trả lời.

Lớp	Nhóm câu hỏi phải trả lời trước	Vì sao phải trước	Nếu chưa trả lời thì chặn nhóm nào phía sau
L0. Reuse Baseline	Nhóm 0 (Reuse Baseline) + các khối `-REUSE` trong phạm vi pilot slice*	Phải biết hệ đã có gì / dùng lại được gì / thiếu tối thiểu gì trước khi hỏi "cần thiết kế gì" — nếu không sẽ thiết kế lại thứ đã có (de-bai rev33 §IV.5). L0 chặn mọi thiết kế/tạo mới trong phạm vi pilot slice + dependency trực tiếp của slice đó nếu chưa chứng minh reuse không đủ; L0 KHÔNG yêu cầu khảo sát toàn hệ trước khi làm một lát thử hẹp (xem §2e Pilot Slice First)	Chặn mọi đề xuất tạo mới hoặc thiết kế mới trong pilot slice nếu chưa chứng minh reuse không đủ; không chặn khảo sát read-only ngoài slice
L1. Substrate hiện trạng trong phạm vi pilot slice	C (Registries) · D (Staging) · A (Birth)	Mọi tọa độ/dấu/máy trong pilot slice đều ngồi trên các sổ + kho tạm + khai sinh đang có thật	Chặn L2–L8 trong phạm vi pilot slice + direct dependencies; không yêu cầu khảo sát toàn substrate toàn hệ trước lát thử hẹp
L2. Tọa độ & vật liệu	E (Collection) · F (Matrix Cell) · G (Formula) · H (IO Contract)	cell_id 4 chiều + kho theo tầng + công thức + hợp đồng IO định nghĩa "vật" được lắp	Chặn L3 (stamp gắn vào cell/IO), L5 (checker đọc cell/IO), L6 (promote ghi theo cell)
L3. Dấu & governance	I (Stamp Lifecycle) + STAMP-GOV · B (Governance declaration)	Dấu khép kín khi mảnh thông tin governance đã được DOT kiểm chứng, có evidence tối thiểu và nơi lưu rõ; chỉ vùng high-risk/canonical mới cần governance/approval nặng	Chặn L4 (DOT đóng dấu), L5 (checker kiểm dấu), L6 (promote đóng BIRTH/PROMOTE stamp)
L4. Máy lắp & năng lực	J (DOT gap) + DOT-CAP (capability contract)	Phải biết DOT nào có/viết mới, input/output/no-mutation/fail-closed trước khi giao việc	Chặn L5 (checker là 1 DOT), L6 (atomic promote là 1 DOT), L7 (scanner là 1 DOT)
L5. Cổng promote	DOT_PROMOTE_CHECKER (DOT-006 + DOT-CAP)	Cổng read-only fail-closed phải xong trước khi cho phép bất kỳ promote nào	Chặn L6 (không promote khi chưa có cổng), L8 (pilot cần checker selftest PASS)
L5b. Operational Risk Gates	R + S (RISK-AP · RISK-IDX · RISK-STL · RISK-GC · RISK-CELL · RISK-RUN · RISK-BYPASS · RISK-CRASH · RISK-CAP/TIME · SRC · OWNER · CONS)	Trước rehearsal/pilot phải chặn rủi ro vận hành và điều hành: lock/transaction, JSONB/full scan, stale verdict/config drift, cleanup blob, UNKNOWN/PENDING context, runtime/config liveness, bypass/write path, crash/retry/outbox, retention/time source, source authority và Owner checkpoints	Chặn L6/L8 nếu BLOCKER áp dụng cho selected pilot slice + direct dependencies chưa đạt Mức ≥ 3 và chưa có Owner checkpoint tương ứng
L6. Atomic promote	K (Atomic Promote)	all-or-nothing + fold birth + chặn negative state — chỉ thiết kế sau khi có checker	Chặn L8 (pilot promote BLOCKED tới khi rehearsal PASS)
L7. Scanner / Report / Minimal heartbeat	L (Scanner)	Scanner/report read-only và heartbeat tối thiểu dùng để phát hiện thiếu dấu, partial state, runtime/config/source stale trong phạm vi pilot slice	Minimal scoped scanner/heartbeat evidence là blocker trước pilot; broad/full-system scanner coverage có thể DEFER
L8. Pilot	M (Pilot)	chỉ chạy khi L1–L6 đạt + checker selftest PASS + rehearsal PASS	(lớp cuối — không chặn ai)

Nhóm N (Order) là meta-trình tự, đọc song song. Các câu Gate Impact = BLOCKER nằm chủ yếu ở L1 (STG-012 scheduler, STG-015 packet_hash), L2 (CELL-004 species), L3 (blast-radius GOV-016/017), L5 (DOT-006 checker), L5b (RISK-AP-001/002/004/005, RISK-IDX-001..004, RISK-STL-001/005/006/007, RISK-CELL-001..004), L6 (AP birth-fold + rehearsal).

L5b. Operational Risk Gates — kiểm lock/transaction, JSONB/index, stale verdict, cleanup blob, UNKNOWN/PENDING context. Nếu các câu BLOCKER nhóm R chưa đạt Mức ≥ 3 thì không được atomic promote rehearsal/pilot. Bước này chỉ đặt câu hỏi + yêu cầu bằng chứng — không tạo index/worker/scheduler/ledger/registry/scanner/checker/DOT mới.

Nhóm R gắn vào earliest affected layer (Codex HOLD fix #4): Nhóm R là roll-up rủi ro vận hành, nhưng một số câu phải được xét sớm hơn L5b:

RISK-GC gắn L1 / D Staging (cleanup/blob trước khi chứng minh delete-fast);

RISK-CELL gắn L2 / L3 Cell/Stamp (context phải hợp lệ trước IO/Validation);

RISK-STL gắn L3 / L5 Stamp/Checker (stale verdict trước khi checker verdict có nghĩa);

RISK-IDX gắn L4 / L5 / L7 DOT/Checker/Scanner (query path/index trong lúc thiết kế, không chỉ sau checker);

RISK-AP / RISK-CRASH gắn L5 / L6 Checker/Atomic Promote (transaction/crash shape phải định hình design trước rehearsal);

RISK-RUN / SRC gắn trước mọi survey/pilot liên quan runtime/config (xem Nhóm S). L5b là điểm roll-up cuối trước rehearsal/pilot, không phải thời điểm đầu tiên mới xét risk.

Quy tắc reuse-first cho Dependency Map (bám đề bài rev33):

L0 đứng trước mọi thiết kế/tạo mới trong phạm vi pilot slice. Không được thiết kế mới (cell/stamp/DOT/collection/formula/atomic-promote) trong pilot slice + dependency trực tiếp của nó khi chưa trả lời xong Reuse Baseline của lát đó; L0 không chặn khảo sát read-only ngoài slice (xem §2e Pilot Slice First).

Không được tạo mới (registry/table/ledger/workflow/DOT/collection) nếu chưa chứng minh reuse không đủ (xem mục Reuse-first / Minimal-fastest Decision Rule).

Thứ tự nhanh nhất theo đề bài rev33: reuse baseline → substrate hiện trạng → lego boundary (collection/cell/IO/formula tối thiểu) → stamp + governance information modules → DOT reuse/gap → checker selftest → atomic promote rehearsal → scanner/report → pilot.

2c. Reuse-first / Minimal-fastest Decision Rule

Quy tắc đọc kèm mọi nhóm câu hỏi. Bám đề bài rev33 §IV.5 (thứ tự ưu tiên khi cần quản lý thêm thông tin), §IV.6 + §VI.7 (anti-bloat), §V.11/§V.13 (không tạo ledger/store mới mặc định).

Mỗi câu hỏi không chỉ hỏi "cần gì", mà phải lần lượt hỏi:

hiện hệ đã có phần nào tương đương;
dùng lại được nguyên trạng không;
nếu không, cần chỉnh tối thiểu gì (metadata/config trước, rồi wrapper nhẹ);
có cần tạo mới không;
nếu tạo mới, vì sao không dùng được cái cũ;
cách nhanh nhất để có v0.1 chạy trong kho tạm là gì;
nếu sai, xóa/rollback thế nào.

Quy tắc chặn tạo-mới (bắt buộc): Không được đề xuất tạo registry / table / ledger / workflow / DOT mới nếu chưa chứng minh đủ cả 5 điều:

registry/metadata hiện có không đủ;
staging (iu_staging_record/iu_staging_payload) không đủ;
IO Contract tối thiểu (§III.6 — 5 field) không đủ;
scanner/report không đủ (không thay được bằng liệt kê);
reuse làm chậm hơn tạo mới (nếu reuse nhanh hơn hoặc bằng → reuse thắng).

Thứ tự ưu tiên vật liệu (de-bai §IV.5): metadata/jsonb hiện có → staging payload → DOT nhẹ/wrapper → stamp xác nhận → (chỉ khi bất khả kháng) sửa birth core hoặc tạo registry mới.

2e. Pilot Slice First — dùng catalog theo lát thử, không biến thành checklist monster

Bám Codex audit 2026-06-15 (HOLD fix #2 — vertical-slice gate scope). Đọc kèm §2b Dependency Map + §2c Decision Rule + Nhóm S (source/runtime gates).

Question Catalog là bản đồ rủi ro toàn hệ, không phải checklist bắt buộc phải trả lời toàn bộ trước mọi hành động. Vòng khảo sát tiếp theo phải chọn một pilot slice hẹp trước, sau đó chỉ bắt buộc trả lời:

Nhóm 0 / Reuse Baseline trong phạm vi pilot slice (không phải toàn bộ L0 toàn hệ);
các câu BLOCKER thuộc dependency trực tiếp của pilot slice;
các câu Operational Risk Gates (Nhóm R) liên quan trực tiếp đến pilot slice;
các câu source/revision/runtime/config (Nhóm S) cần để không đi sai nguồn;
các Owner checkpoint (Owner Decision Checkpoints) tương ứng với bước đang xin duyệt.

Các câu ngoài pilot slice vẫn nằm trong catalog nhưng không chặn lát thử đầu tiên, trừ khi chúng tác động trực tiếp đến checker, atomic promote, runtime safety, source authority, hoặc production/canonical boundary.

Không dùng con số ~318+ câu để biến v0.1 thành khảo sát toàn hệ. Dùng catalog để chọn đúng câu cho pilot slice, không phải để ép trả lời hết trước khi làm một lát mỏng.

Chống hiểu sai: Pilot Slice First không có nghĩa là bỏ qua rủi ro; nó có nghĩa là chỉ áp blocker vào lát đang làm và dependency trực tiếp của lát đó.

Dependency closure và proof boundary của pilot slice

Trước survey theo slice phải ghi rõ:

selected pilot slice là gì;
direct dependencies gồm những artifact/schema/function/DOT/config/runtime nào;
câu hỏi nào áp dụng cho slice;
câu hỏi nào được DEFER ngoài slice;
slice chứng minh điều gì;
slice không chứng minh điều gì;
risk classes nào bị loại khỏi phạm vi slice và cần slice khác kiểm sau.

Một pilot slice thành công chỉ chứng minh các invariant trong proof boundary của nó; không được suy rộng thành toàn hệ.

Cảnh báo chọn slice: Không chọn slice chỉ vì dễ pass. Slice phải đủ đại diện cho ít nhất một đường workflow thật: workspace → candidate → cell/context → IO/check → stamp/verdict → delete/rehearsal boundary.

2d. Nhóm 0 — Reuse Baseline / Dùng lại tối đa

Lớp L0 — phải trả lời TRƯỚC mọi nhóm A–N. Đây là bộ câu ép vòng khảo sát sau khảo sát hệ đã có gì, không phải thiết kế gì. Dùng schema bảng reuse-first (Reuse Check + Minimal/Fastest Path). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
REUSE-001	Với mỗi khối cần cải tiến, hệ hiện đã có artifact/schema/table/function/DOT/metadata nào tương đương?	Liệt kê per-khối: substrate/sổ/staging/birth/DOT/stamp-store hiện có	Bắt đầu từ inventory read-only, không thiết kế gì trước khi liệt kê xong	BLOCKER	TODO
REUSE-002	Cái nào dùng lại nguyên trạng được?	Đánh dấu artifact reuse 0-sửa	Ưu tiên dùng thẳng, ghi rõ "0 thay đổi"	REQUIRED	TODO
REUSE-003	Cái nào dùng lại được nếu chỉ chỉnh metadata/config?	Liệt kê chỗ chỉ cần thêm field/jsonb/config (vd dot_role, cell_id, required-stamps.json)	Patch metadata thay vì schema mới	REQUIRED	TODO
REUSE-004	Cái nào dùng lại được nếu chỉ thêm wrapper nhẹ?	Liệt kê fn/DOT chỉ cần wrapper (vd extend `fn_iu_cut_from_manifest`)	Wrapper mỏng trên fn hiện có, không viết lại	REQUIRED	TODO
REUSE-005	Cái nào bắt buộc phải viết mới?	Chỉ những thứ không phủ được bởi 002–004	Giữ danh sách net-new tối thiểu	REQUIRED	TODO
REUSE-006	Mỗi đề xuất viết mới đã chứng minh vì sao không dùng được cái cũ chưa?	Với mỗi item ở 005, đối chiếu lại 001–004	Bắt buộc 1 dòng lý do/đề xuất; thiếu lý do = không được tạo	BLOCKER nếu có đề xuất tạo mới	TODO
REUSE-007	Cách nhanh nhất để chạy được trong kho tạm là gì?	iu_staging + dry-run + DOT reuse hiện có	Chọn đường ít DOT mới nhất chạy được 1 vòng	REQUIRED	TODO
REUSE-008	Cách nhanh nhất để chứng minh "sai thì xóa được"?	`fn_iu_staging_cleanup` + TTL + BEGIN..ROLLBACK	Rollback/cleanup chứng minh trong staging, không cần cơ chế mới	REQUIRED	TODO
REUSE-009	Việc nào nếu làm bây giờ sẽ làm hệ phình?	Đối chiếu anti-bloat §IV.6/§VI.7 (ledger/workflow/ontology/auto-fix)	Gắn cờ defer/loại bỏ ngay	REQUIRED	TODO
REUSE-010	Việc nào nên defer sau v0.1 dù đúng về lý thuyết?	formula registry, per-layer, block-mode, domain tree…	Đưa vào danh sách defer, không chặn v0.1	DEFER	TODO
REUSE-011	Có cách nào đạt 80% mục tiêu bằng 20% thay đổi không?	Tìm patch nhỏ phủ phần lớn mục tiêu	Chọn lát cắt mỏng nhất cho pilot	REQUIRED	TODO
REUSE-012	Có thể dùng metadata/jsonb/staging payload thay vì bảng mới không?	staging.metadata jsonb + payload parts	Lưu trong jsonb/payload, không tạo table	REQUIRED	TODO
REUSE-013	Có thể dùng DOT hiện có bằng wrapper thay vì DOT mới không?	dot_tools (309) + FIX7 validator/rollback	Wrapper/extend trước khi nghĩ DOT mới	REQUIRED	TODO
REUSE-014	Có thể dùng scanner/report thay vì auto-fix không?	system_issues + fn_log_issue + orphan-scan	Liệt kê lỗi, không tự sửa toàn hệ	REQUIRED	TODO
REUSE-015	Có thể dùng IO Contract tối thiểu (5 field) thay vì Module Contract lớn không?	dot_agent_api_contract pattern; de-bai §III.6	IO Contract 5 field ở payload, không Module Contract First	REQUIRED	TODO

3. Nhóm A — Khai sinh / Birth

Đọc nền: de-bai §V.1–V.2, §V.10, addendum §3, §7, §7b. (Lớp L1.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
BIRTH-001	`birth_registry` hiện có những cột nào?	nền BIRTH_STAMP/căn cước	live `birth_registry` schema	Liệt kê đủ cột + kiểu + default + NOT NULL/UNIQUE	ANSWERED	REQUIRED	3	Old survey: 22 cột (8-field+inspect_*+certified+jsonb_profile).
BIRTH-002	8 trường khai sinh tối thiểu là gì?	xác nhận minimal birth	`de-bai §V.2`	Map đủ 8 trường ↔ cột thật, không thừa	ANSWERED	REQUIRED	3	Old survey: ai/tầng/loài/kho/miền/trạng-thái/ai-tạo/khi-nào.
BIRTH-003	Function nào tạo canonical birth?	chốt đường ghi birth	live `fn_birth_register`	Tên fn + chữ ký + dry_run default + idempotency	ANSWERED	REQUIRED	3	Old survey: `fn_birth_register(...dry_run DEFAULT true)`.
BIRTH-004	`fn_birth_gate` warning hay block?	quyết định enforcement	live `fn_birth_gate` body	Xác định mode mặc định + kill-switch + điều kiện block	ANSWERED	REQUIRED	3	Old survey: WARNING (kill-switch `app.bypass_birth_gate`).
BIRTH-005	Có trigger/function nào gọi birth?	đo blast-radius	live trigger inventory	Con số chính xác + phân loại legacy vs DOT-119	PARTIAL	REQUIRED	2	Needs verification: ~192 match `%birth%` vs "162" đề bài.
BIRTH-006	Có phân biệt candidate/workspace/canonical trong birth?	tách pre-promote	live data profile	Xác nhận birth chỉ chứa canonical; pre-promote ở staging	ANSWERED	REQUIRED	3	Old survey: status chỉ `born`; phân biệt ở staging.
BIRTH-007	Object kho tạm đã từng ghi `birth_registry` chưa?	xác nhận nguyên tắc	live data profile	0 row temp/sandbox/candidate trong birth	ANSWERED	REQUIRED	3	Old survey: 0 temp-row.
BIRTH-008	"12c / object sinh từ kho tạm" có trong tài liệu/code?	phần net-new	`de-bai §V`; live QT-001/002	Xác định: chỉ giấy hay đã có fn/trigger; cần formal hoá ở đâu	PARTIAL	REQUIRED	2	Old survey: chỉ DRAFT, chưa có fn/trigger.
BIRTH-009	Chỗ nào đang dồn governance vào khai sinh?	tránh lặp lỗi	live trigger body	Liệt kê field/logic governance trong birth path	ANSWERED	REQUIRED	3	Old survey: rất ít — trigger chỉ ghi 8 trường.
BIRTH-010	V0.1 sửa birth ở mức giấy hay code?	định mức can thiệp	`de-bai §V.2`	Quyết định rõ giấy vs code + lý do	PARTIAL	REQUIRED	2	Old survey đề xuất giấy trước; cần Owner chốt.
BIRTH-011	`TEMP_ID_STAMP` sinh ở đâu, liên quan birth?	tách căn cước tạm	`addendum §4`; live `iu_staging_record`	Xác định nơi sinh + không đụng birth	PARTIAL	REQUIRED	2	Old survey: ở `iu_staging_record`; cần xác nhận key.
BIRTH-012	`BIRTH_STAMP` chỉ sinh sau promote — khớp fn hiện tại?	birth là output stamp	`addendum §7`; `fn_birth_register`	Xác nhận birth đóng SAU promote, không là precondition	PARTIAL	REQUIRED	2	Old survey: khớp `fn_birth_register(dry_run=false)`.
BIRTH-013	Atomic promote dùng fn birth hiện có hay wrapper?	thiết kế promote	`addendum §7b`	Đủ khi: rõ dùng `fn_birth_register` hay wrapper, chạy trong txn nào, output nào ghi, negative state nào bị chặn	PARTIAL	BLOCKER	2	Old survey: dùng fn hiện có + wrapper trong txn cut (chưa chứng minh).
BIRTH-014	Làm sao tránh birth-only state?	negative state cấm	`addendum §7b`	Cơ chế: birth chỉ ghi TRONG txn promote; có test chứng minh	PARTIAL	BLOCKER	2	Old survey: cần fold birth vào txn (chưa có).
BIRTH-015	V0.1 bật birth gate block hay giữ warning?	quyết định enforcement	`de-bai §V.16`	Quyết định rõ + điều kiện chuyển block-mode sau	PARTIAL	REQUIRED	2	Old survey đề xuất giữ warning v0.1.
BIRTH-016	Cần DOT nào liên quan birth?	lập danh sách DOT	`addendum §5`; `dot_tools`	Liệt kê DOT birth (có/mới) + vai trò	PARTIAL	REQUIRED	2	Old survey: DOT_TEMP_ID(mới)+`fn_birth_register`(có)+DOT-118/119.
BIRTH-017	Việc nào trước checker / trước pilot / sau v0.1?	thứ tự thi công	`roadmap §3`	Phân loại 3 nhóm việc rõ ràng	PARTIAL	REQUIRED	2	Old survey: chốt giấy→checker; DOT_TEMP_ID+wrapper→pilot; block-mode sau.

A-REUSE — Reuse-first cho Birth

Bám de-bai rev33 §IV.1 (khai sinh tối thiểu), §V.10 (hai loại căn cước), §V.5 (DOT đóng dấu từng phần). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
BIRTH-REUSE-001	`birth_registry` / `fn_birth_register` / `fn_birth_gate` hiện dùng lại được gì?	3 artifact đã có (registry 22 cột, fn dry_run-default, gate WARNING)	Dùng thẳng làm BIRTH_STAMP post-promote; không viết lại	BLOCKER	TODO
BIRTH-REUSE-002	Cần chỉnh gì tối thiểu để giữ birth core minimal?	8 trường khai sinh đã khớp cột thật	Chỉ giữ 8 trường; mọi thứ khác = stamp/metadata bên ngoài	REQUIRED	TODO
BIRTH-REUSE-003	Có cần sửa birth core không, hay chỉ cần stamp/metadata extension?	inspect_*/jsonb_profile có sẵn để chứa post-stamp	Ưu tiên stamp extension; chỉ sửa core nếu là căn cước bất biến (liên quan BIRTH-013/014)	REQUIRED	TODO
BIRTH-REUSE-004	Cách nhanh nhất để chứng minh canonical birth chỉ xảy ra sau promote?	`fn_birth_register(dry_run=false)` chạy trong txn promote	Rehearsal BEGIN..ROLLBACK trên clone, fold birth vào txn cut	REQUIRED	TODO
BIRTH-REUSE-005	Có thể giữ `fn_birth_gate` ở mode WARNING ở v0.1 để tránh mở rộng blast-radius?	gate đã là WARNING + kill-switch	Giữ WARNING v0.1; chỉ chuyển block-mode sau (Mức 3)	REQUIRED	TODO

4. Nhóm B — Governance

Đọc nền: de-bai §II.5, §V.16, addendum §10, §11. (Lớp L3.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
GOV-001	Đ32 route approval thế nào?	nền routing Mức 3	live `approval_requests`/`apr_*`/`nrm_approval_rules`	Mô tả bảng + luồng + quorum re-prove tại apply	ANSWERED	REQUIRED	3	Old survey: approval_requests(230)+apr_*(42/14/14)+nrm(3).
GOV-002	`governance_role` hiện có không?	dùng phân loại	live `birth_registry`/`collection_registry`	Liệt kê giá trị governance_role + nơi dùng	ANSWERED	REQUIRED	3	Old survey: governed/observed/excluded/locked/law_artifact.
GOV-003	Blast-radius A–E có code thật không?	chọn A–E hay risk_level	live schema	Xác nhận có/không cột+code A–E	ANSWERED	REQUIRED	3	Old survey: KHÔNG implement; A–E chỉ giấy.
GOV-004	Hệ dùng `risk_level`/`doc_level` thế nào?	thay thế A–E	live `apr_action_types`/`normative_registry`	Liệt kê giá trị + nơi routing	ANSWERED	REQUIRED	3	Old survey: risk_level(low/med/high)+doc_level(1–6).
GOV-005	Owner/scope lưu ở đâu?	OWNER_STAMP	live `birth_registry.owner`/`collection_registry.owner`	Xác định cột owner + nơi lưu scope	PARTIAL	REQUIRED	2	Old survey: owner cột; scope chưa có cột riêng.
GOV-006	High-risk quorum có hardcode không?	giữ hay sửa	live `fn_apr_quorum_check`/`quorum_passed`	Trích luật quorum theo risk + self-approve	ANSWERED	REQUIRED	3	Old survey: high⇒president≥1 & ai_council≥2; reject>0 chặn.
GOV-007	`governance_audit_log` dùng thế nào?	có là Đ32 ledger?	live count	Xác định vai trò thật + có phải ledger chính	ANSWERED	REQUIRED	3	Old survey: 1 row (gần rỗng), không phải ledger Đ32.
GOV-008	`governance_candidate_state` tồn tại/có writer?	tránh subsystem chết	live	Xác nhận row count + writer fn	ANSWERED	REQUIRED	3	Old survey: 0 row, 0 writer (design-only).
GOV-009	Việc nào thuộc Mức 1?	phân lớp governance	`de-bai §II.5`	Danh sách hành vi Mức 1 + tiêu chí	PARTIAL	REQUIRED	2	Old survey: workspace/kho tạm pending.
GOV-010	Việc nào thuộc Mức 2?	phân lớp governance	`de-bai §II.5`	Danh sách hành vi Mức 2 + tiêu chí	PARTIAL	REQUIRED	2	Old survey: promote (checker preconditions).
GOV-011	Việc nào bắt buộc Mức 3?	phân lớp governance	`de-bai §II.5, §V.16`	Danh sách hành vi Mức 3 + tiêu chí	PARTIAL	REQUIRED	2	Old survey: khai sinh/kernel/canonical/owner/prod gate/approval rule.
GOV-012	Khi nào `PROMOTE_BLOCKED`?	định nghĩa fail-closed	`checker-spec §3, §5`	Liệt kê điều kiện block đầy đủ	PARTIAL	REQUIRED	2	Old survey: thiếu stamp/cell UNKNOWN/tamper/expired.
GOV-013	Khi nào `ESCALATE_L3`?	định nghĩa escalate	`addendum §10`	Điều kiện escalate rõ ràng	PARTIAL	REQUIRED	2	Old survey: chạm kernel/canonical/prod; risk high.
GOV-014	Khi nào cần `GOV_STAMP`?	high-risk gate	`addendum §4, §7`	Điều kiện đóng GOV_STAMP	PARTIAL	REQUIRED	2	Old survey: vùng canonical/kernel/high-risk.
GOV-015	Khi nào cần `OWNER_STAMP`?	high-risk gate	`addendum §4`	Điều kiện đóng OWNER_STAMP	PARTIAL	REQUIRED	2	Old survey: high-risk cần owner/scope.
GOV-016	Ai/DOT nào tính blast-radius/risk?	thiếu máy tính class	live (không có máy tính)	Đủ khi: có map A–E (hoặc risk) ↔ 3 Mức + DOT/logic tính + nguồn dữ liệu	TODO	BLOCKER	1	Needs verification: chưa có máy tính A–E (B-GOV-1).
GOV-017	Không tính được risk thì fail thế nào?	fail-closed governance	`addendum §11`	Quy tắc fail-closed lên Mức 3 + có code/giả lập	TODO	BLOCKER	1	Needs verification: nguyên tắc có, code chưa.
GOV-018	Matrix/Stamp có được bypass Đ32 không?	bảo toàn chủ quyền	`de-bai §V.16`; `addendum §10`	Khẳng định không bypass + dẫn chứng	ANSWERED	REQUIRED	3	Old survey: KHÔNG bypass; quorum nguyên vẹn.
GOV-019	Governance khai báo gì để stamp lifecycle khép kín?	gắn stamp với gov	`addendum §4, §7`; `required-stamps.v0.1.json`	Map stamp→Mức + điều kiện GOV/OWNER (giấy)	PARTIAL	REQUIRED	2	Needs verification: chưa chốt map. Xem §11b.
GOV-020	DOT scanner/checker ghi audit/provenance ở đâu?	đường audit	live `event_outbox`/`registry_changelog`/`system_issues`	Xác định bảng audit cho từng loại ghi	PARTIAL	REQUIRED	2	Old survey: event_outbox+registry_changelog; gov_audit_log gần rỗng.

B-REUSE — Reuse-first cho Governance

Bám de-bai rev33 §IV.2 (governance = bản đồ quan hệ/trạng thái, không phải bộ máy quản trị mới), §VI.6 (governance lắp theo module nhỏ). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
GOV-REUSE-001	Các bảng/registry quan hệ hiện có có đủ biểu diễn governance graph tối thiểu không?	universal_edges (2,199) + governance_role + owner hiện có	Dùng graph/field hiện có; không dựng governance machine mới	BLOCKER	TODO
GOV-REUSE-002	Có thể dùng `universal_edges` / `registry_changelog` / `event_outbox` / metadata hiện có không?	3 bảng audit/edge + metadata jsonb đã có	Map governance vào các bảng này, không tạo store mới	REQUIRED	TODO
GOV-REUSE-003	Governance module nào chỉ là field/metadata, không cần registry mới?	governance_role/owner/scope là field	Thêm field/jsonb, không tạo registry governance	REQUIRED	TODO
GOV-REUSE-004	Risk classification có thể map từ `risk_level`/`doc_level` hiện có không?	risk_level(low/med/high)+doc_level(1–6) đã có	Map A–E → risk_level thay vì cài cột A–E mới (liên quan GOV-016/017)	REQUIRED	TODO
GOV-REUSE-005	Approval/quorum hiện có chỉ dùng lại cho high-risk/canonical được không?	approval_requests + apr_* + quorum_passed đã có	Chỉ gọi Đ32 ở vùng high-risk; v0.1 không governance hóa workspace	REQUIRED	TODO
GOV-REUSE-006	Cách nhẹ nhất để chia Điều 39 thành module thông tin nhỏ là gì?	de-bai §VI.6 liệt kê các module thông tin	Mỗi module = 1 nhóm field + DOT bổ sung + stamp; không macro governance	REQUIRED	TODO

5. Nhóm C — Registries / Các sổ

Đọc nền: addendum §8, §9. (Lớp L1.) 10 câu hỏi chuẩn áp cho từng sổ; chi tiết per-sổ ở bảng đối chiếu cuối nhóm.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
REG-001	Mỗi sổ có tồn tại không?	xác định substrate	live schema	Xác nhận tồn tại/không cho 12 sổ	ANSWERED	REQUIRED	3	Old survey: 11/12 tồn tại; `canonical_fields` không là bảng.
REG-002	Vai trò hiện tại của mỗi sổ?	hiểu SSOT	live + `[GR]`	Một câu vai trò/sổ	PARTIAL	REQUIRED	2	Old survey: xem bảng per-sổ.
REG-003	Mỗi sổ có bao nhiêu record?	đo độ "sống"	live count	Con số count/sổ	ANSWERED	REQUIRED	3	Old survey: xem bảng per-sổ.
REG-004	Dùng lại cho Matrix/Stamp thế nào?	tái sử dụng	`addendum §8`	Vai trò Matrix/Stamp/sổ	PARTIAL	REQUIRED	2	Needs verification per sổ.
REG-005	Mỗi sổ KHÔNG được dùng làm gì?	tránh lạm dụng	`[GR]`	Liệt kê cấm dùng làm candidate/stamp ledger	PARTIAL	REQUIRED	2	Old survey: cấm system_issues/event_outbox/meta_catalog/birth làm ledger.
REG-006	Có cần thêm metadata không?	mở rộng tối thiểu	live schema	Liệt kê metadata cần thêm + sổ nào	PARTIAL	REQUIRED	2	Old survey: dot_tools cần cell_id+dot_role.
REG-007	Có cần DOT kiểm drift không?	nhất quán	live DOT	DOT drift/sổ (nếu cần)	PARTIAL	OPTIONAL	2	Old survey: Đ23 inverse/DOT-120/DOT-138/self.
REG-008	Có cần thêm `cell_id` không?	tọa độ ma trận	`checker-spec §2.1`	cell_id là thuộc tính ở đâu, KHÔNG sổ mới	PARTIAL	REQUIRED	2	Old survey: metadata/jsonb, không sổ mới.
REG-009	Có cần thêm `dot_role` không?	phân vai DOT	live `dot_tools`	Cách thêm dot_role (cột vs extra_metadata)	PARTIAL	REQUIRED	2	Old survey: dot_tools thiếu dot_role.
REG-010	Có cần registry mới không? Nếu có, tại sao không dùng sổ cũ?	chống bloat	`addendum §9`	Khẳng định 0 sổ mới + bằng chứng phủ bởi sổ cũ	PARTIAL	REQUIRED	2	Old survey: KHÔNG cần. Cần Owner xác nhận.

Bảng đối chiếu per-sổ (read-only, [GR] — provisional):

#	Sổ	Tồn tại / count	Vai trò hiện tại	Dùng lại	KHÔNG dùng làm	Answer Status
REG-S01	`birth_registry`	✅ 1,212,803	SSOT canonical identity (8-field)	BIRTH_STAMP/post-promote; scanner	candidate ledger	PARTIAL
REG-S02	`collection_registry`	✅ 168	SSOT kho/collection	COLLECTION_STAMP; phân loại kho	candidate ledger	PARTIAL
REG-S03	`meta_catalog`	✅ 169	Catalog entity per-layer	nguồn Tầng cho cell_id	per-candidate store	PARTIAL
REG-S04	`dot_tools`	✅ 309	SSOT DOT (Đ35)	đăng ký DOT (+cell_id/dot_role)	candidate/stamp ledger	PARTIAL
REG-S05	`universal_edges`	✅ 2,199	Relation graph	RELATION_STAMP; Object Card	chiều ma trận	PARTIAL
REG-S06	`system_issues`	✅ 224,102	Log lỗi	QUARANTINE/scanner	stamp ledger (cấm)	PARTIAL
REG-S07	`event_outbox`	✅ 215,526	Provenance event	audit atomic promote	nguồn pre-promote stamp (cấm)	PARTIAL
REG-S08	`registry_changelog`	✅ 81,341	Change ledger	provenance promote	candidate ledger	PARTIAL
REG-S09	`governance_audit_log`	✅ 1 (gần rỗng)	Relation-check audit	(yếu)	Đ32 approval ledger	PARTIAL
REG-S10	`governance_candidate_state`	✅ 0 row / 0 writer	Candidacy group-grain	(tương lai)	đừng giả định đã build	TODO
REG-S11	`canonical_fields`	❌ KHÔNG là bảng	—	—	—	ANSWERED
REG-S12	`normative_registry`	✅ 47	SSOT luật/NRM (doc_level)	Mức 3 reference	candidate/stamp store	PARTIAL

C-REUSE — Reuse-first cho Registries

Bám de-bai rev33 §IV.5 (xem registry/metadata hiện có trước), §IV.6/§VI.7 (không tạo registry mới nếu metadata đủ). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
REG-REUSE-001	Registry nào là SSOT hiện có và có thể reuse?	birth_registry/collection_registry/dot_tools/normative_registry (bảng per-sổ §5)	Dùng đúng SSOT đang có làm nguồn, không nhân bản	BLOCKER	TODO
REG-REUSE-002	Registry nào tuyệt đối không dùng làm store mới?	system_issues/event_outbox/meta_catalog/birth_registry (cấm làm ledger)	Ghi rõ cấm dùng làm candidate/stamp ledger	REQUIRED	TODO
REG-REUSE-003	Metadata/jsonb nào có thể chứa extension thay vì tạo bảng mới?	extra_metadata (dot_tools), jsonb_profile (birth), staging.metadata	Patch jsonb/metadata thay vì DDL bảng mới	REQUIRED	TODO
REG-REUSE-004	`dot_tools` thiếu gì tối thiểu để dùng lại?	thiếu `dot_role` + `cell_id`	Thêm 2 field (cột hoặc extra_metadata), không sổ DOT mới	REQUIRED	TODO
REG-REUSE-005	`collection_registry` thiếu gì tối thiểu để dùng lại?	có owner/governance_role; thiếu scope/domain/ttl/layer	Thêm field còn thiếu, không tạo registry kho mới	REQUIRED	TODO
REG-REUSE-006	Có cần registry mới nào ở v0.1 không? Nếu có, chứng minh bắt buộc.	kỳ vọng 0 sổ mới (addendum §9)	Mặc định 0; nếu đề xuất → phải qua REUSE-006 (chứng minh sổ cũ không đủ)	BLOCKER nếu có đề xuất tạo mới	TODO

6. Nhóm D — Staging / Candidate Store

Đọc nền: addendum §2b, §7c. (Lớp L1.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
STG-001	Có `iu_core.iu_staging_record`?	substrate kho tạm	live schema	Xác nhận + đếm cột + PK	ANSWERED	REQUIRED	3	Old survey: CÓ, 26 cột, PK uuid.
STG-002	Có `iu_core.iu_staging_payload`?	payload multi-part	live schema	Xác nhận + FK + UNIQUE + cap	ANSWERED	REQUIRED	3	Old survey: CÓ, 11 cột, CASCADE, cap 10MiB/part.
STG-003	Schema cụ thể là gì?	hiểu binding	live schema	Đầy đủ cột + CHECK	ANSWERED	REQUIRED	3	Old survey: xem [GR §2].
STG-004	Có `candidate_id`?	định danh ổn định	live	Xác định cột định danh ổn định	ANSWERED	REQUIRED	3	Old survey: staging_record_id + idempotency_key.
STG-005	Có `workspace_id`?	gom theo workspace	live	Xác định cột/cơ chế workspace	PARTIAL	OPTIONAL	2	Old survey: không cột riêng; dùng owner_actor/purpose/metadata.
STG-006	Có status lifecycle?	fail-closed	live CHECK	Liệt kê đủ giá trị + CHECK	ANSWERED	REQUIRED	3	Old survey: 7 giá trị CHECK enforced.
STG-007	Có TTL/`expires_at`?	cleanup fail-safe	live CHECK	Xác nhận expires_at + ceiling	ANSWERED	REQUIRED	3	Old survey: NOT NULL, ceiling ≤ +30d.
STG-008	Có metadata JSON?	chứa pre-promote stamps	live	Xác nhận metadata jsonb	ANSWERED	REQUIRED	3	Old survey: `metadata` jsonb.
STG-009	Có payload JSON?	chứa io/validator/rollback parts	live	Xác nhận payload_json/text/blob_ref	ANSWERED	REQUIRED	3	Old survey: payload_json+text+blob_ref.
STG-010	Có hash/checksum?	tamper-binding	live `fn_iu_staging_create`	Xác định content_hash bao phần nào	ANSWERED	REQUIRED	3	Old survey: content_hash = sha256(payload parts), KHÔNG bao metadata.
STG-011	Có cleanup function?	xóa được	live `fn_iu_staging_cleanup`	Xác nhận fn + pass logic	ANSWERED	REQUIRED	3	Old survey: CÓ fn 3-pass + dry-run.
STG-012	Có cleanup scheduler?	TTL chạy thật?	live (no `cron.job`)	Đủ khi: xác định ai gọi cleanup (cron/flow/worker) hoặc kết luận thủ công + chứng minh chạy	TODO	BLOCKER	1	Needs verification: không pg_cron (AQ2, B-STG-2).
STG-013	`sandbox_tac` là gì?	phân biệt design vs live	KB Đ38 P7B	Xác nhận deploy hay design-only	ANSWERED	REQUIRED	3	Old survey: design Đ38, chưa deploy; live = iu_staging.
STG-014	Candidate packet lưu ở đâu?	thiết kế packet	`checker-spec §2.1`	Cấu trúc packet (header+stamps+parts)	PARTIAL	REQUIRED	2	Old survey: record(metadata)+payload(parts).
STG-015	`packet_hash` hash phần nào?	tamper bao stamps	`checker-spec §2.2`; `fn_iu_staging_create`	Đủ khi: chốt định nghĩa packet_hash bao cell_id+stamps (option a/b) + cách tính	PARTIAL	BLOCKER	2	Old survey: chọn (a) stamps là 1 payload part (chưa chốt giấy).
STG-016	Pre-promote stamps lưu ở đâu?	nơi đóng 5 dấu	`addendum §2b`	Chuẩn 5 metadata-key cho stamps	PARTIAL	REQUIRED	2	Old survey: metadata jsonb (chưa chuẩn key).
STG-017	Candidate đang promote có lock/status?	chống cleanup nhầm	live CHECK	Xác nhận approved không bị cleanup	ANSWERED	REQUIRED	3	Old survey: approved không bị expire; fail-safe.
STG-018	Có cần bảng mới không?	chống bloat	`[GR §2]`	Khẳng định 0 bảng mới + bằng chứng đủ	PARTIAL	REQUIRED	2	Old survey: KHÔNG. Cần Owner xác nhận.
STG-019	Nếu không dùng staging tables, fallback?	dự phòng	`[GR §2]`	Nêu fallback hoặc kết luận không cần	ANSWERED	OPTIONAL	3	Old survey: không cần fallback.
STG-020	Staging có đủ gỡ HOLD-1?	quyết định Phase	`roadmap §1, §3 Phase 1`	Kết luận GO/NO-GO substrate	PARTIAL	REQUIRED	3	Old survey: GO phần lớn. Cần Owner/Codex xác nhận.

D-REUSE — Reuse-first cho Staging / Candidate

Bám de-bai rev33 §V.13 (candidate packet = view/packet logic trên staging metadata, KHÔNG store mới), §VI.4 (delete-fast/TTL). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
STG-REUSE-001	`iu_staging_record`/`iu_staging_payload` có đủ làm kho tạm chung không?	record 26 cột + payload multi-part + metadata jsonb	Dùng làm kho tạm chung cho mọi tầng v0.1	BLOCKER	TODO
STG-REUSE-002	Candidate packet có thể là view logic trên staging metadata/payload không?	metadata jsonb + payload parts + content_hash	Packet = view/binding logic, không bảng riêng	REQUIRED	TODO
STG-REUSE-003	Có cần packet store mới không? (mặc định KHÔNG)	§V.13 cấm store/registry mới cho packet	Giữ 0 store mới; nếu đề xuất → qua REUSE-006	BLOCKER nếu có đề xuất tạo mới	TODO
STG-REUSE-004	TTL/cleanup hiện có gì, thiếu gì tối thiểu?	expires_at (≤30d) + `fn_iu_staging_cleanup` 3-pass	Chỉ thiếu scheduler (STG-012) → xác minh ai gọi cleanup	REQUIRED	TODO
STG-REUSE-005	Cách nhanh nhất để chứng minh delete-fast?	cleanup fn + payload CASCADE + rejected/expired	Chạy cleanup trên record giả trong staging, đo xóa được	REQUIRED	TODO

7. Nhóm E — Collection / Kho theo tầng

Đọc nền: de-bai §II.3, §V.7. (Lớp L2.) 12 câu chuẩn/tầng + 5 câu chung + 8 câu bổ sung per-tầng. Bảng 6 tầng ở cuối nhóm.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
COL-001	Kho tạm hiện có mỗi tầng là gì?	nguồn pre-promote	live `collection_registry`	Xác định kho tạm/tầng	PARTIAL	REQUIRED	2	Old survey: 1 kho chung `iu_staging_*`.
COL-002	Kho chính hiện có mỗi tầng là gì?	đích promote	`[GR §4]`	Xác định kho chính/tầng + count	PARTIAL	REQUIRED	2	Old survey: atom dày; material/product/building gần rỗng.
COL-003	Có kho candidate riêng từng tầng?	tránh tạo thừa	`[GR §4]`	Kết luận có/không	ANSWERED	REQUIRED	3	Old survey: KHÔNG, dùng iu_staging.
COL-004	Có kho quarantine?	trạng thái xấu	`[GR §4]`	Quarantine = kho hay lifecycle status	ANSWERED	REQUIRED	3	Old survey: = `rejected`/`expired`.
COL-005	Có kho archive?	tombstone	`[GR §4]`	Archive = kho hay tombstone	ANSWERED	REQUIRED	3	Old survey: = consumed+cleaned tombstone.
COL-006	V0.1 cần thêm kho nào?	quyết định tạo mới	`[GR §4]`	Số kho mới (kỳ vọng 0) + lý do	PARTIAL	REQUIRED	2	Old survey: 0. Cần Owner xác nhận.
COL-007	Kho nào để sau?	hoãn hợp lý	`[GR §4]`	Danh sách kho hoãn	PARTIAL	DEFER	2	Old survey: per-layer split; material/product/building.
COL-008	Collection nào liên quan domain/TAC?	gắn miền	`[GR §4]`	Liệt kê collection-domain/TAC	PARTIAL	OPTIONAL	2	Old survey: sandbox_tac không là collection.
COL-009	Collection nào có TTL/cleanup?	fail-safe	live	Liệt kê collection có TTL	ANSWERED	REQUIRED	3	Old survey: chỉ iu_staging_* (30d).
COL-010	Collection nào có owner/scope/domain?	governance attribute	live `collection_registry`	Liệt kê cột attribute có/thiếu	PARTIAL	REQUIRED	2	Old survey: có owner/governance_role; thiếu scope/domain/ttl/layer.
COL-011	Promote đi từ kho nào sang kho nào?	luồng promote	`[GR §4, §11]`	Sơ đồ source→target	PARTIAL	REQUIRED	2	Old survey: iu_staging→information_unit+birth.
COL-012	Cleanup xóa ở kho nào?	xóa đúng chỗ	`[GR §4]`	Xác định kho bị xóa	ANSWERED	REQUIRED	3	Old survey: payload xóa, record tombstone.
COL-013	`collection_registry` có bao nhiêu collection?	đo độ phủ	live count	Con số	ANSWERED	REQUIRED	3	Old survey: 168.
COL-014	`sandbox_tac` đăng ký trong collection_registry?	design vs live	`[GR §4]`	Có/không	ANSWERED	REQUIRED	3	Old survey: KHÔNG.
COL-015	V0.1 cần tạo collection mới không?	chống bloat	`[GR §4]`	Kết luận + lý do	PARTIAL	REQUIRED	2	Old survey: KHÔNG. Cần Owner.
COL-016	Nếu cần, tạo mấy cái tối thiểu?	giới hạn	`[GR §4]`	Con số tối thiểu	ANSWERED	REQUIRED	3	Old survey: 0.
COL-017	Nếu không cần, dùng collection nào cho pilot?	chọn kho pilot	`[GR §4, §13]`	Tên kho tạm+chính pilot	PARTIAL	REQUIRED	2	Old survey: iu_staging→information_unit+birth.
COL-018	Với mỗi tầng, source collection là gì?	per-tầng rõ ràng	live `meta_catalog`/`collection_registry`	Bảng source/tầng	TODO	REQUIRED	1	Needs verification per-tầng (bảng 6 tầng dưới mới sơ bộ).
COL-019	Với mỗi tầng, staging collection là gì?	per-tầng rõ ràng	live	Bảng staging/tầng	PARTIAL	REQUIRED	2	Old survey: iu_staging chung mọi tầng.
COL-020	Với mỗi tầng, target canonical collection là gì?	per-tầng rõ ràng	live	Bảng target/tầng	TODO	REQUIRED	1	Needs verification: material/product/building gần rỗng.
COL-021	Với mỗi tầng, quarantine ở collection hay lifecycle status?	rõ cơ chế	`[GR §4]`	Khẳng định cơ chế/tầng	ANSWERED	REQUIRED	3	Old survey: lifecycle status (rejected/expired).
COL-022	Với mỗi tầng, archive/tombstone ở đâu?	rõ cơ chế	`[GR §4]`	Khẳng định nơi tombstone	PARTIAL	OPTIONAL	2	Old survey: consumed+cleaned.
COL-023	Có cần collection riêng cho formula/object/rule?	tránh tạo thừa	`addendum §9`; `[GR §6]`	Kết luận + lý do	TODO	OPTIONAL	1	Needs verification: formula lưu ở KB/object?
COL-024	Có cần collection riêng cho evidence/rollback proof?	nơi lưu bằng chứng	`[GR §2, §8]`	Kết luận: dùng payload part hay collection riêng	TODO	REQUIRED	1	Needs verification: hiện đề xuất payload part.
COL-025	Nếu v0.1 dùng 0 collection mới, bằng chứng nào chứng minh đủ?	chống kết luận thiếu	`[GR §2, §4]`	Liệt kê bằng chứng đủ (iu_staging+birth+information_unit)	PARTIAL	REQUIRED	2	Old survey: substrate đủ; cần đóng gói bằng chứng.

Bảng 6 tầng (kho hiện có vs cần — [GR §4], provisional):

Tầng	Kho tạm	Kho chính	Candidate	Quarantine	Archive	V0.1 thêm kho	Để sau
Nguyên tử (atom)	`iu_staging_*`	birth+collection_registry (atom 1.21M)	iu_staging	rejected	consumed tombstone	KHÔNG	per-layer split
Phân tử (molecule)	`iu_staging_*`	molecule 986	iu_staging	rejected	—	KHÔNG	—
Hợp chất (compound)	`iu_staging_*`	compound 172	iu_staging	rejected	—	KHÔNG	—
Vật liệu (material)	—	material 2 (gần rỗng)	iu_staging	rejected	—	KHÔNG	cần data trước
Thành phẩm (product)	—	product 1	iu_staging	rejected	—	KHÔNG	—
Hệ con/Công trình (building)	—	building 1	iu_staging	rejected	—	KHÔNG	—

E-REUSE — Reuse-first cho Collection

Bám de-bai rev33 §VI.7 (làm được bằng metadata/staging → không tạo collection mới), §V.14 (kho tạm cho UNKNOWN/PENDING). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
COL-REUSE-001	V0.1 có thể dùng 0 collection mới không?	collection_registry (168) + iu_staging + information_unit + birth	Mặc định 0 collection mới; chứng minh đủ bằng substrate hiện có	BLOCKER nếu có đề xuất tạo mới	TODO
COL-REUSE-002	Kho tạm chung `iu_staging` có đủ cho mọi tầng ở v0.1 không?	iu_staging dùng chung mọi tầng	Pilot dùng iu_staging chung, không kho tạm per-tầng	REQUIRED	TODO
COL-REUSE-003	Tầng nào đã có kho chính đủ dùng?	atom 1.21M, molecule 986, compound 172	Chọn tầng đủ data làm pilot (atom)	REQUIRED	TODO
COL-REUSE-004	Tầng nào chưa đủ data nên defer?	material/product/building gần rỗng	Defer per-layer split tới khi có data	DEFER	TODO
COL-REUSE-005	Nếu cần collection mới, điều kiện bắt buộc là gì?	addendum §9 + REUSE-006	Chỉ tạo khi chứng minh staging+metadata không đủ	REQUIRED	TODO

8. Nhóm F — Matrix Cell / cell_id

Đọc nền: checker-spec §2.1, addendum §4, §10, de-bai §V.14–V.15. (Lớp L2.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
CELL-001	`cell_id` gồm field nào?	định nghĩa tọa độ	`checker-spec §2.1`	Liệt kê đủ field	ANSWERED	REQUIRED	3	Old survey: {layer, species, collection, domain}.
CELL-002	Dùng tên collection hay store?	tránh nhập nhằng	`[GR §5]`	Khẳng định nguồn tên	ANSWERED	REQUIRED	3	Old survey: collection_name/iu_staging purpose.
CELL-003	`layer` lấy từ đâu?	nguồn chiều tầng	live `birth_registry`/`meta_catalog`	Chốt 1 nguồn chuẩn (composition_level vs layer)	PARTIAL	BLOCKER	2	Needs verification: 2 nguồn (composition_level vs meta_catalog.layer) — AQ10.
CELL-004	`species` lấy từ đâu?	nguồn chiều loài	live `entity_species`/`species_collection_map`	Đủ khi: hợp nhất 2 namespace code thành 1 nguồn cho CELL_STAMP	CONFLICT	BLOCKER	2	Needs verification: SPE-* vs lowercase (AQ3).
CELL-005	`collection`/`store` lấy từ đâu?	nguồn chiều kho	live `collection_registry`	Khẳng định nguồn	ANSWERED	REQUIRED	3	Old survey: collection_registry (168).
CELL-006	`domain` lấy từ đâu?	nguồn chiều miền	live `law_jurisdiction`	Khẳng định nguồn + đếm domain	ANSWERED	REQUIRED	3	Old survey: law_jurisdiction 14 domain.
CELL-007	Có danh mục 6 tầng chuẩn không?	catalog chiều tầng	live	Đủ khi: chốt danh mục 6 tầng chuẩn (nguồn nào)	PARTIAL	BLOCKER	2	Needs verification: composition_level chưa enacted; AQ10.
CELL-008	Có taxonomy species không?	catalog chiều loài	live `entity_species`	Xác nhận taxonomy + độ sâu	PARTIAL	REQUIRED	2	Old survey: entity_species (tree phẳng).
CELL-009	Có domain catalog không?	catalog chiều miền	live `law_jurisdiction`	Xác nhận catalog	ANSWERED	REQUIRED	3	Old survey: CÓ (14 domain).
CELL-010	UNKNOWN/PENDING được phép ở kho nào?	ranh giới	`de-bai §V.14`	Khẳng định chỉ kho tạm	ANSWERED	REQUIRED	3	Old survey: chỉ iu_staging pending.
CELL-011	UNKNOWN/PENDING bị chặn ở bước nào?	fail-closed	`de-bai §V.14`; `checker-spec §3`	Khẳng định chặn tại promote	PARTIAL	REQUIRED	2	Old survey: tại promote (CELL_STAMP).
CELL-012	`CELL_STAMP` kiểm những gì?	điều kiện pass	`addendum §4`	Liệt kê điều kiện kiểm 4 chiều	PARTIAL	REQUIRED	2	Old survey: 4 chiều ∈ danh mục, không UNKNOWN.
CELL-013	SPECIES/COLLECTION là stamp riêng?	chống stamp bloat	`addendum §4`; `de-bai §V.11`	Khẳng định gom dưới CELL_STAMP	ANSWERED	REQUIRED	3	Old survey: gom CELL_STAMP.
CELL-014	Object nhiều domain xử lý thế nào?	đa miền	`[GR §5]` (AQ4)	Quy ước domain chính + tag phụ	TODO	OPTIONAL	1	Needs verification: law_jurisdiction 1 domain/law.
CELL-015	Pilot cell đề xuất là gì?	chọn pilot	`[GR §5, §13]`	Tọa độ cell pilot rõ	PARTIAL	REQUIRED	2	Old survey: (atom, information_unit, iu_staging→IU, iu/normative).

F-REUSE — Reuse-first cho Matrix Cell

Bám de-bai rev33 §V.14 (UNKNOWN/PENDING ở kho tạm, không kẹt taxonomy), §V.15 (domain = tag có kiểm soát). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
CELL-REUSE-001	layer/species/collection/domain hiện lấy được từ nguồn nào có sẵn?	meta_catalog/composition_level · entity_species · collection_registry · law_jurisdiction	Map 4 chiều từ nguồn sẵn có; chốt 1 nguồn/chiều (liên quan CELL-003/004/007)	BLOCKER	TODO
CELL-REUSE-002	Có thể chốt `cell_id` v0.1 bằng mapping nhẹ thay vì taxonomy lớn không?	4 chiều đã có catalog cơ bản	Mapping nhẹ + UNKNOWN; không dựng ontology mới	REQUIRED	TODO
CELL-REUSE-003	UNKNOWN/PENDING có đủ để tránh kẹt taxonomy không?	iu_staging cho phép pending	Cho phép UNKNOWN ở kho tạm, chặn tại promote	REQUIRED	TODO
CELL-REUSE-004	Cần tối thiểu gì để `CELL_STAMP` chạy được?	CELL_STAMP gom 4 chiều ∈ danh mục	Chốt nguồn 4 chiều + hợp nhất namespace species (CELL-004)	REQUIRED	TODO

9. Nhóm G — Công thức / Formula

Đọc nền: quick-rules (rule 18–19), KB Đ38/Đ44. (Lớp L2.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
FORMULA-001	Hệ có UMC/BOM/formula?	có engine chưa	live (0 bảng match)	Khẳng định có/không registry+engine	ANSWERED	REQUIRED	3	Old survey: KHÔNG registry/engine.
FORMULA-002	Công thức nằm ở đâu?	nguồn hiện tại	KB Đ44/Đ38	Xác định nơi (KB schema vs DDL)	ANSWERED	REQUIRED	3	Old survey: KB UMC-10/BOM draft.
FORMULA-003	Có formula registry?	sổ công thức	live	Có/không	ANSWERED	REQUIRED	3	Old survey: KHÔNG.
FORMULA-004	Có công thức cho TAC/IU?	nhu cầu thực	KB Đ44	Phân biệt schema vs công thức lắp ráp	PARTIAL	OPTIONAL	2	Old survey: chỉ 10 ô UMC (schema).
FORMULA-005	Có object input/steps/output?	gần-formula	live `iu_staging.metadata.pieces[]`	Xác định gần-formula nào	PARTIAL	OPTIONAL	2	Old survey: manifest+cut (steps cứng).
FORMULA-006	Có DOT assemble?	máy lắp	live (0 match)	Có/không	ANSWERED	REQUIRED	3	Old survey: KHÔNG (0 DOT assembl).
FORMULA-007	V0.1 cần formula registry?	quyết định hoãn	quick-rules 18–19	Kết luận + lý do	PARTIAL	DEFER	2	Old survey: KHÔNG bắt buộc; cut pipeline.
FORMULA-008	Formula v0.1 cần field nào?	nếu làm	`[GR §6]`	Schema field tối thiểu (nếu làm)	PARTIAL	DEFER	1	Old survey: {cell_id,inputs,steps,output,dot_ref,rollback}.
FORMULA-009	Formula bind `cell_id`?	gắn tọa độ	`[GR §6]`	Khẳng định bind	PARTIAL	DEFER	1	Old survey: có.
FORMULA-010	Formula bind DOT nào?	máy chạy	`[GR §6, §9]`	Tên DOT	PARTIAL	DEFER	1	Old survey: DOT_FORMULA_ASSEMBLE (hoãn).
FORMULA-011	Formula có rollback rule?	an toàn	`[GR §6]`	Có field rollback	PARTIAL	DEFER	1	Old survey: có (nếu làm).
FORMULA-012	Formula dùng IO Contract riêng hay của cell?	tránh trùng	`[GR §6, §7]`	Khẳng định	PARTIAL	OPTIONAL	2	Old survey: của cell.
FORMULA-013	Pilot cần mấy formula?	giới hạn pilot	`[GR §6, §13]`	Con số (kỳ vọng 0–1)	PARTIAL	REQUIRED	2	Old survey: 0–1 (cut-from-manifest).
FORMULA-014	Formula nào làm trước?	thứ tự	`[GR §6]`	Danh sách trước	PARTIAL	DEFER	2	Old survey: 0 trước.
FORMULA-015	Formula nào để sau?	hoãn	`[GR §6]`	Danh sách sau	PARTIAL	DEFER	2	Old survey: material/product/building.
FORMULA-016	Mỗi tầng sau cần loại công thức gì?	tầm nhìn	KB Đ38	Phác per-tầng	TODO	DEFER	1	Needs verification per-tầng.
FORMULA-017	Nếu pilot dùng cut-from-manifest như formula tối thiểu, cần khai báo là formula v0.1 không?	tránh "formula ẩn"	`addendum §7b`; `[GR §6]`	Quyết định khai báo formula.v0.1 cho cut hay coi là pipeline	TODO	REQUIRED	1	Needs verification: cut hiện không gắn nhãn formula.
FORMULA-018	Công thức tối thiểu cần `dot_assemble` và `dot_check` riêng không?	tách lắp vs kiểm	`addendum §5`; `[GR §9]`	Kết luận có/không + lý do	TODO	OPTIONAL	1	Needs verification.
FORMULA-019	Formula evidence lưu ở đâu?	provenance	`[GR §2, §8]`	Nơi lưu evidence công thức	TODO	OPTIONAL	1	Needs verification: payload part vs object.
FORMULA-020	Formula có version không?	change-control	KB Đ38	Quy ước version	TODO	DEFER	0	Chưa khảo sát.
FORMULA-021	Formula có owner/scope không?	governance	KB Đ38	Quy ước owner/scope	TODO	DEFER	0	Chưa khảo sát.
FORMULA-022	Công thức khác nhau theo tầng thế nào?	tầm nhìn per-tầng	KB Đ38	Phác khác biệt per-tầng	TODO	DEFER	0	Chưa khảo sát.
FORMULA-023	Tầng nào chưa đủ dữ liệu để có formula?	thực tế data	`[GR §4]`	Liệt kê tầng thiếu data	PARTIAL	DEFER	2	Old survey: material/product/building gần rỗng.

G-REUSE — Reuse-first cho Formula

Bám de-bai rev33 §VI.5 (scale bằng công thức, không macro), §VI.7 (không formula registry mặc định). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
FORMULA-REUSE-001	Có thể dùng procedure/`fn_iu_cut_from_manifest` hiện có như formula tối thiểu không?	cut-from-manifest + manifest.pieces[] đã có	Khai cut-pipeline là formula.v0.1, không engine mới	REQUIRED	TODO
FORMULA-REUSE-002	Có cần formula registry ở v0.1 không? (mặc định KHÔNG)	KHÔNG có registry/engine; §VI.7 cấm mặc định	Giữ 0 formula registry; defer	BLOCKER nếu có đề xuất tạo mới	TODO
FORMULA-REUSE-003	Formula tối thiểu có thể chỉ là `input_refs + procedure + output_schema + rollback` không?	gần-formula = manifest+cut+payload	Định nghĩa 4 phần trong payload/metadata, không schema mới	REQUIRED	TODO
FORMULA-REUSE-004	Tầng nào chưa cần formula riêng ở v0.1?	material/product/building gần rỗng	Defer formula per-tầng tới khi có data	DEFER	TODO

10. Nhóm H — IO Contract

Đọc nền: matrix-refactor-implementation-plan §11, KB Đ30/Đ31. (Lớp L2.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
IO-001	Có IO Contract nào trong Đ30/Đ31/tests/contracts?	nguồn khuôn	KB Đ30/Đ31; repo web-test	Inventory file + nơi lưu	PARTIAL	REQUIRED	2	Needs verification: file web-test, không query DB (AQ8, B-IO-1).
IO-002	Format hiện tại là gì?	khuôn mẫu	live `dot_agent_api_contract`	Mô tả schema có sẵn	PARTIAL	REQUIRED	2	Old survey: dot_agent_api_contract (output/verifier+no_mutation).
IO-003	Có contract per route/per sensor?	độ phủ	KB Đ30/Đ31	Có/không + phạm vi	PARTIAL	OPTIONAL	2	Old survey: CÓ (file).
IO-004	Có contract cho KB object?	net-new?	`[GR §7]`	Có/không	ANSWERED	REQUIRED	3	Old survey: KHÔNG.
IO-005	Có contract cho candidate/staging?	net-new?	`[GR §7]`	Có/không	ANSWERED	REQUIRED	3	Old survey: KHÔNG (chỉ ad-hoc).
IO-006	IO Contract v0.1 gồm field nào?	thiết kế giấy	plan §11	Đủ khi: schema field tối thiểu chốt (accepts/returns/checks/rollback/owner_scope)	PARTIAL	REQUIRED	2	Old survey: có phác plan §11.
IO-007	IO Contract nằm ở đâu?	nơi lưu	`[GR §7]`	Nơi lưu (payload part + ref)	PARTIAL	REQUIRED	2	Old survey: payload part `io_contract`.
IO-008	Có cần file `io-contract-minimal.v0.1.json`?	schema giấy	`[GR §7]`	Quyết định tạo file giấy	PARTIAL	REQUIRED	2	Old survey: CÓ (schema giấy).
IO-009	Bind `candidate_id` hay `cell_id`?	gắn định danh	`[GR §7]`	Khẳng định bind	PARTIAL	REQUIRED	2	Old survey: bind staging_record_id + chứa cell_id.
IO-010	DOT nào kiểm IO Contract?	máy kiểm	`[GR §7, §9]`	Tên DOT + vai trò	PARTIAL	REQUIRED	2	Old survey: DOT_IO_CHECK (mới).
IO-011	Thiếu IO Contract thì status gì?	fail-closed	`checker-spec §3`	Khẳng định PROMOTE_BLOCKED	PARTIAL	REQUIRED	2	Old survey: PROMOTE_BLOCKED.
IO-012	IO pass thì đóng `IO_STAMP` ở đâu?	nơi đóng dấu	`[GR §7, §8]`	Nơi đóng IO_STAMP	PARTIAL	REQUIRED	2	Old survey: metadata.IO_STAMP.
IO-013	IO fail thì object đi đâu?	đường thất bại	`[GR §7]`	Trạng thái khi fail	PARTIAL	REQUIRED	2	Old survey: pending/rejected.
IO-014	Pilot cần mấy IO Contract?	giới hạn	`[GR §7, §13]`	Con số	PARTIAL	REQUIRED	2	Old survey: 1.
IO-015	Có cần chuẩn hóa IO theo tầng?	tầm nhìn	`[GR §7]`	Kết luận	PARTIAL	DEFER	2	Old survey: sau v0.1.
IO-016	IO Contract có version không?	change-control	plan §11	Quy ước version	TODO	REQUIRED	1	Needs verification.
IO-017	IO Contract có fixture/bad-input tests không?	fail-closed	live `dot_agent_api_contract` (fixture_ref)	Quy ước fixture + bad-input ≥8 lớp	TODO	REQUIRED	1	Needs verification: pattern có fixture_ref.
IO-018	IO Contract có owner/scope không?	governance	plan §11	Quy ước owner/scope	TODO	OPTIONAL	1	Needs verification.
IO-019	IO Contract đổi thì stamp cũ có invalid không?	tính nhất quán	`addendum §7`	Quy tắc invalidation khi IO đổi	TODO	REQUIRED	1	Needs verification (liên quan STAMP-GOV-004/006).
IO-020	IO Contract bind với formula hay chỉ cell?	ranh giới bind	`[GR §6, §7]`	Khẳng định bind	TODO	OPTIONAL	1	Needs verification: hiện bind cell.
IO-021	IO Contract output có cần schema hash không?	tamper output	`[GR §7]`	Quyết định schema hash	TODO	OPTIONAL	1	Needs verification.

H-REUSE — Reuse-first cho IO Contract

Bám de-bai rev33 §III.6 (IO Contract v0.1 = 5 field, KHÔNG Module Contract First), §VI.3 (100% giao tiếp qua IO Contract). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
IO-REUSE-001	Có IO Contract pattern hiện có nào dùng lại được không?	`dot_agent_api_contract` (output/verifier/no_mutation/fixture_ref)	Reuse pattern này làm khuôn; không khuôn mới	REQUIRED	TODO
IO-REUSE-002	IO Contract v0.1 đúng 5 field đã đủ chưa?	§III.6: nhận/trả/schema tối thiểu/lỗi-fail/rollback	Chốt đúng 5 field; không nhồi thêm	BLOCKER	TODO
IO-REUSE-003	Có thể tránh Module Contract First không?	§III.6/§V.16: Module Contract chỉ tham khảo high-risk	Dùng IO Contract tối thiểu; không module contract lớn cho việc nhỏ	REQUIRED	TODO
IO-REUSE-004	IO Contract lưu ở staging payload/metadata được không?	payload part `io_contract` + bind staging_record_id	Lưu là 1 payload part, không bảng contract mới	REQUIRED	TODO
IO-REUSE-005	Cần gì tối thiểu để `DOT_IO_CHECK` chạy?	pattern contract có sẵn để extend	Wrapper kiểm IO Contract tồn tại+pass → IO_STAMP	REQUIRED	TODO

11. Nhóm I — Stamp Lifecycle

Đọc nền: addendum §4, §7, §2b, required-stamps.v0.1.json. (Lớp L3.) Câu hỏi lifecycle 9 stamp + cắt ngang; governance declaration ở §11b.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
STAMP-001	Chốt lifecycle `TEMP_ID_STAMP`	căn cước tạm	`addendum §4`	Đóng khi nào · ai/DOT · lưu đâu · pass · fail	PARTIAL	REQUIRED	2	Old survey: tạo ở iu_staging_record (PK+idempotency).
STAMP-002	Chốt lifecycle `CELL_STAMP`	định vị 4 chiều	`addendum §4`	5 chiều lifecycle rõ	PARTIAL	REQUIRED	2	Old survey: metadata.CELL_STAMP; fail→BLOCKED.
STAMP-003	Chốt lifecycle `IO_STAMP`	kiểm IO	`addendum §4`	5 chiều lifecycle rõ	PARTIAL	REQUIRED	2	Old survey: metadata.IO_STAMP.
STAMP-004	Chốt lifecycle `VALIDATION_STAMP`	validator	`addendum §4`	5 chiều + ≥8 lớp/any_fail_open=false	PARTIAL	REQUIRED	2	Old survey: reuse FIX7 validator.
STAMP-005	Chốt lifecycle `ROLLBACK_STAMP`	xóa được	`addendum §4`	5 chiều + PROVEN_IN_STAGING	PARTIAL	REQUIRED	2	Old survey: reuse FIX7 rollback-proof.
STAMP-006	Chốt lifecycle `BIRTH_STAMP`	căn cước canonical	`addendum §7, §7b`; `fn_birth_register`	Đủ khi: rõ đóng ở đâu, bởi txn nào, bằng evidence nào, audit ở đâu	PARTIAL	BLOCKER	2	Old survey: birth_registry row+inspect_pen; cần fold vào txn.
STAMP-007	Chốt lifecycle `PROMOTE_STAMP`	dấu promote	`addendum §7b` (AQ9)	Đủ khi: rõ nơi đóng (inspect_stamp/jsonb_profile/dot_iu_command_run) + txn + evidence + audit	PARTIAL	BLOCKER	2	Old survey: chưa có nơi đóng rõ.
STAMP-008	Chốt lifecycle `GOV_STAMP`	high-risk	`addendum §4, §7`	5 chiều + điều kiện quorum	PARTIAL	REQUIRED	2	Old survey: governance_role+apr_*; fail→ESCALATE_L3.
STAMP-009	Chốt lifecycle `OWNER_STAMP`	high-risk	`addendum §4`	5 chiều + owner/scope rõ	PARTIAL	REQUIRED	2	Old survey: birth_registry.owner.
STAMP-010	Mỗi stamp ghi audit không?	truy vết	`[GR §8, §11]`	Xác định audit/stamp	PARTIAL	REQUIRED	2	Old survey: post→event_outbox; pre→metadata.
STAMP-011	Stamp nào cần governance khai báo?	gắn Mức	`addendum §7`; `required-stamps.v0.1.json`	Map stamp→Mức	PARTIAL	REQUIRED	2	Old survey: GOV/OWNER cho high-risk.
STAMP-012	Có cần ledger stamp riêng không?	chống bảng thừa	`addendum §8`	Kết luận 0 ledger + bằng chứng	PARTIAL	REQUIRED	2	Old survey: KHÔNG — staging.metadata + birth inspect_*.
STAMP-013	Không ledger thì bằng chứng staging/canonical đủ chưa?	xác nhận đủ	`[GR §8]`	Liệt kê nơi chứa đủ stamp	PARTIAL	REQUIRED	2	Old survey: đủ (metadata jsonb + birth jsonb_profile).
STAMP-014	Required stamps cấu hình metadata, không hardcode?	chống cứng hóa	`de-bai §V.12`; `required-stamps.v0.1.json`	Xác nhận config-driven + khớp substrate	PARTIAL	REQUIRED	2	Old survey: required-stamps.v0.1.json có.

Bảng lifecycle 9 stamp (reference — [GR §8], provisional):

Stamp	Pre/Post	Ai/DOT	Lưu ở đâu	Điều kiện pass	Nếu fail
TEMP_ID_STAMP	tạo (kho tạm)	DOT_TEMP_ID (mới)	iu_staging_record (PK+idempotency)	record tạo, có id	không vào kho tạm
CELL_STAMP	pre-promote	DOT_CELL_MAP (mới)	metadata.CELL_STAMP	4 chiều ∈ danh mục	PROMOTE_BLOCKED
IO_STAMP	pre-promote	DOT_IO_CHECK (mới)	metadata.IO_STAMP	IO Contract tồn tại+pass	PROMOTE_BLOCKED
VALIDATION_STAMP	pre-promote	DOT_VALIDATE (reuse)	metadata.VALIDATION_STAMP	validator pass ≥8 lớp	PROMOTE_BLOCKED
ROLLBACK_STAMP	pre-promote	DOT_ROLLBACK_PROOF (reuse)	metadata.ROLLBACK_STAMP	PROVEN_IN_STAGING	PROMOTE_BLOCKED
BIRTH_STAMP	post-promote	fn_birth_register (có)	birth_registry+inspect_pen	birth trong txn	rollback txn
PROMOTE_STAMP	post-promote	Atomic Promote (extend cut)	jsonb_profile/inspect_stamp	toàn txn pass	rollback txn
GOV_STAMP	high-risk	DOT_GOV (Đ32)	governance_role+apr_*	risk≥high→quorum	ESCALATE_L3
OWNER_STAMP	high-risk	DOT_OWNER	birth_registry.owner	owner/scope rõ	PROMOTE_BLOCKED

11b. Stamp Governance Declaration

Guard anti-bloat: Các câu hỏi dưới đây dùng để kiểm xem stamp cần metadata/evidence tối thiểu nào để đáng tin. Không mặc định tạo stamp governance system, stamp registry, stamp ledger, hay workflow approval riêng. Ưu tiên dùng required-stamps.v0.1.json, staging metadata, birth_registry/jsonb_profile, event_outbox/registry_changelog hiện có. Câu nào không cần cho v0.1 thì đánh DEFER.

Lý do: stamp không chỉ "đóng dấu" — phải khép kín bằng governance (ai đóng, evidence, version, revoke, change-control). (Lớp L3.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
STAMP-GOV-001	Mỗi stamp có governance declaration ở đâu?	khép kín governance	`required-stamps.v0.1.json`; `addendum §7`	Xác định nơi khai báo từng stamp	TODO	BLOCKER	1	Needs verification: required-stamps có core/lifecycle nhưng chưa declaration đầy đủ.
STAMP-GOV-002	Ai/DOT nào được quyền đóng từng stamp?	phân quyền đóng dấu	`addendum §5`; `dot_tools`	Map stamp→DOT/issuer được phép	TODO	REQUIRED	1	Needs verification (bảng lifecycle mới sơ bộ).
STAMP-GOV-003	Stamp pass/fail phải kèm `evidence_ref` nào?	chống dấu khống	`[GR §8]`	Quy ước evidence_ref bắt buộc/stamp	TODO	BLOCKER	1	Needs verification: hiện stamp chỉ pass/fail, chưa bắt evidence_ref.
STAMP-GOV-004	Stamp có version không?	change-control	`required-stamps.v0.1.json`	Quy ước stamp_version	TODO	REQUIRED	1	Needs verification.
STAMP-GOV-005	Stamp có issuer/timestamp không?	provenance	`[GR §8]`	Quy ước issuer+ts bắt buộc	TODO	REQUIRED	1	Needs verification.
STAMP-GOV-006	Stamp sai thì sửa bằng cách nào?	sửa lỗi có kiểm soát	`addendum §7`	Quy trình sửa stamp (re-issue)	TODO	REQUIRED	1	Needs verification.
STAMP-GOV-007	Stamp revoke/override có được phép không?	tránh override lén	`addendum §7, §10`	Quy tắc revoke/override + ai duyệt	TODO	BLOCKER	1	Needs verification.
STAMP-GOV-008	Audit/provenance của từng stamp ghi ở đâu?	truy vết	live `event_outbox`/`registry_changelog`	Bảng audit/stamp	TODO	REQUIRED	1	Needs verification (trùng STAMP-010).
STAMP-GOV-009	Thêm core stamp mới cần qua governance mức nào?	chống stamp bloat	`de-bai §V.11`; `addendum §10`	Khẳng định Mức governance để thêm stamp	TODO	REQUIRED	1	Needs verification: de-bai cấm mở rộng tùy tiện.
STAMP-GOV-010	`required-stamps` config được change-control ra sao?	config-as-law	`required-stamps.v0.1.json`; `de-bai §V.12`	Quy trình đổi config (ai duyệt, version, audit)	TODO	REQUIRED	1	Needs verification (trùng AQ13).

I-REUSE — Reuse-first cho Stamp

Bám de-bai rev33 §IV.4 (stamp = dấu xác nhận một mảnh thông tin đã đủ), §IV.6 + §V.11 (không tạo stamp ledger nếu metadata đủ; ≤8–10 dấu lõi). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
STAMP-REUSE-001	Pre-promote stamps có thể lưu trong staging metadata không?	staging.metadata jsonb (addendum §2b)	5 metadata-key trong jsonb, không bảng stamp	BLOCKER	TODO
STAMP-REUSE-002	Post-promote stamps có thể lưu trong canonical substrate / birth_registry / jsonb_profile không?	inspect_* + jsonb_profile của birth_registry	Đóng BIRTH/PROMOTE vào substrate canonical hiện có	REQUIRED	TODO
STAMP-REUSE-003	Có cần stamp ledger không? (mặc định KHÔNG)	§V.11: default v0.1 KHÔNG tạo ledger	Giữ 0 ledger; nếu đề xuất → qua REUSE-006 + Mức 3	BLOCKER nếu có đề xuất tạo mới	TODO
STAMP-REUSE-004	Stamp nào thật sự bắt buộc v0.1?	required-stamps.v0.1.json (7 dấu lõi)	Chỉ dùng bộ dấu lõi đã khai trong config	REQUIRED	TODO
STAMP-REUSE-005	Stamp nào defer hoặc chỉ high-risk?	GOV_STAMP/OWNER_STAMP chỉ high-risk	Defer dấu nâng cao; chỉ bắt buộc vùng canonical/kernel	DEFER	TODO

12. Nhóm J — DOT / Máy lắp ráp

Đọc nền: addendum §5, live dot_tools. (Lớp L4.) Bảng 14 DOT (reference) + câu hỏi cắt ngang + capability contract (§12b).

Bảng 14 DOT (reference — [GR §9], provisional):

DOT	Có sẵn	Tên/tool hiện tại	Viết mới?	Mutate?	Đóng stamp	Trước checker	Trước pilot
DOT_TEMP_ID	❌	—	CÓ	staging	TEMP_ID	—	✅
DOT_CELL_MAP	❌	—	CÓ	staging meta	CELL	—	✅
DOT_IO_CHECK	⚠️ pattern	dot_agent_api_contract	CÓ	staging meta	IO	—	✅
DOT_VALIDATE	✅	FIX7 validator	extend	read	VALIDATION	—	✅
DOT_ROLLBACK_PROOF	✅	FIX7 rollback, DOT-062	extend	staging	ROLLBACK	—	✅
DOT_PROMOTE_CHECKER	❌	—	CÓ	read-only	—	build chính	✅
DOT_ATOMIC_PROMOTE_REHEARSAL	⚠️ ~70%	fn_iu_cut_from_manifest	extend	txn	BIRTH+PROMOTE	sau checker	✅
DOT_CLEANUP_TTL	✅	fn_iu_staging_cleanup	reuse	allowlist	—	—	✅
DOT_STAMP_SCANNER	⚠️ phần	orphan-scan+idx_birth_uncertified	assemble	read-only	—	—	(sau)
DOT_FORMULA_ASSEMBLE	❌	—	(hoãn)	staging	—	—	(không)
DOT_GOV_ESCALATE	⚠️	apr_*+quorum_passed	reuse	—	GOV	—	(high-risk)
DOT_COLLECTION_REGISTER	✅	DOT-120/DOT-TAC	reuse	CÓ	COLLECTION	—	(nếu cần)
DOT_DOMAIN_CLASSIFY	⚠️	law_jurisdiction	(nhẹ)	read	(CELL)	—	(nếu unclear)
DOT_SPECIES_CLASSIFY	⚠️	entity_species	(nhẹ)	read	(CELL)	—	(nếu unclear)

Câu hỏi cắt ngang:

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
DOT-Q01	DOT nào tận dụng từ `dot_tools`?	reuse	live `dot_tools`	Danh sách DOT reuse	PARTIAL	REQUIRED	2	Old survey: VALIDATE/ROLLBACK/CLEANUP/COLLECTION_REGISTER/birth/scan.
DOT-Q02	DOT nào viết mới trước checker?	net-new tối thiểu	`[GR §9]`	Danh sách (kỳ vọng chỉ checker)	PARTIAL	REQUIRED	2	Old survey: chỉ DOT_PROMOTE_CHECKER.
DOT-Q03	DOT nào chỉ cần trước pilot?	thứ tự	`[GR §9, §13]`	Danh sách trước pilot	PARTIAL	REQUIRED	2	Old survey: TEMP_ID/CELL_MAP/IO_CHECK/ATOMIC+5 reuse.
DOT-Q04	DOT nào để sau v0.1?	hoãn	`[GR §9]`	Danh sách hoãn	PARTIAL	DEFER	2	Old survey: FORMULA_ASSEMBLE, per-layer.
DOT-Q05	Có cần đăng ký DOT trong `dot_tools`?	governance DOT	`[GR §9]`	Quyết định + field đăng ký	PARTIAL	REQUIRED	2	Old survey: CÓ — thêm dot_role+cell_id.
DOT-Q06	Có cần thêm `dot_role`/`cell_id` metadata?	phân vai	live `dot_tools`	Xác nhận thiếu + cách thêm	ANSWERED	REQUIRED	3	Old survey: dot_tools thiếu cell_id/dot_role.
DOT-Q07	DOT nào có nguy cơ mutate production?	an toàn	`[GR §9, §11]`	Liệt kê DOT mutate + biện pháp	PARTIAL	BLOCKER	2	Old survey: DOT_ATOMIC_PROMOTE — phải rehearsal clone.
DOT-Q08	DOT nào phải read-only?	fail-closed	`[GR §9]`	Danh sách read-only	PARTIAL	REQUIRED	2	Old survey: checker/scanner/*_CHECK.
DOT-Q09	DOT nào fail-closed?	an toàn	`checker-spec §5`	Danh sách fail-closed	PARTIAL	REQUIRED	2	Old survey: checker + *_CHECK.
DOT-Q10	DOT nào chỉ scanner/report?	phân loại	`[GR §9, §12]`	Danh sách scanner	ANSWERED	OPTIONAL	3	Old survey: DOT_STAMP_SCANNER.
DOT-Q11	Tổng DOT tối thiểu trước checker?	đếm	`[GR §9]`	Con số	PARTIAL	REQUIRED	2	Old survey: 1.
DOT-Q12	Tổng DOT tối thiểu trước pilot?	đếm	`[GR §9, §13]`	Con số	PARTIAL	REQUIRED	2	Old survey: ~5 net-new/extend + 3 reuse.

12b. DOT Capability Contract

Guard anti-bloat: Các câu hỏi dưới đây dùng để kiểm DOT có ranh giới tối thiểu chưa: input, output, mutate/read-only, fail behavior, evidence. Không mặc định tạo DOT capability system hoặc DOT governance workflow. Ưu tiên khai tối thiểu trong dot_tools/extra_metadata hoặc reuse dot_agent_api_contract pattern. Câu nào không cần cho v0.1 thì đánh DEFER.

Lý do: trước khi giao việc cho DOT, phải biết năng lực + ranh giới (input/output/no-mutation/fail-closed/owner/version). (Lớp L4.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
DOT-CAP-001	Mỗi DOT có capability contract không?	nền giao việc	live `dot_agent_api_contract`; `dot_tools`	Xác định có/không + nơi lưu contract	PARTIAL	BLOCKER	2	Old survey: chỉ dot_agent_api_contract (2 row). Chưa phủ DOT mới.
DOT-CAP-002	DOT input schema là gì?	hợp đồng vào	live `dot_agent_api_contract`	Schema input/DOT cốt lõi	TODO	REQUIRED	1	Needs verification cho DOT mới.
DOT-CAP-003	DOT output schema là gì?	hợp đồng ra	live `dot_agent_api_contract` (expected_output_schema)	Schema output/DOT cốt lõi	TODO	REQUIRED	1	Needs verification.
DOT-CAP-004	DOT no-mutation flag nằm ở đâu?	an toàn read-only	live (no_mutation_assertion)	Xác định nơi khai no-mutation	PARTIAL	BLOCKER	2	Old survey: dot_agent_api_contract có no_mutation_assertion.
DOT-CAP-005	DOT fail-closed behavior định nghĩa ở đâu?	fail-closed	live (error_behavior); `checker-spec §5`	Xác định nơi khai fail-closed	TODO	REQUIRED	1	Needs verification.
DOT-CAP-006	DOT bad-input tests tối thiểu là gì?	chống fail-open	`[GR §9]`; plan §11	Quy ước ≥8 lớp bad-input + any_fail_open=false	TODO	BLOCKER	1	Needs verification cho checker/*_CHECK.
DOT-CAP-007	DOT owner là ai?	governance	live `dot_tools`	Xác định cột owner	TODO	REQUIRED	1	Needs verification.
DOT-CAP-008	DOT đăng ký trong `dot_tools` bằng field nào?	đăng ký chuẩn	live `dot_tools` schema	Liệt kê field đăng ký (+ dot_role/cell_id)	PARTIAL	REQUIRED	2	Old survey: category/domain/operation/tier/extra_metadata; thiếu role.
DOT-CAP-009	DOT có version không?	change-control	live `dot_tools`	Quy ước dot_version	TODO	REQUIRED	1	Needs verification.
DOT-CAP-010	DOT nào read-only / mutate staging / tuyệt đối không chạm production?	phân vùng an toàn	`[GR §9, §11]`	Bảng 3 lớp quyền/DOT	PARTIAL	BLOCKER	2	Old survey: checker/scanner read-only; ATOMIC_PROMOTE chạm canonical (rehearsal clone).

J-REUSE — Reuse-first cho DOT

Bám de-bai rev33 §IV.3 (DOT = máy làm một việc hẹp, khai tối thiểu, không hồ sơ quản trị nặng), §VI.7 (không DOT governance system riêng). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
DOT-REUSE-001	DOT nào hiện có dùng lại nguyên trạng?	DOT_VALIDATE(FIX7) · DOT_CLEANUP_TTL · DOT_COLLECTION_REGISTER · gov quorum	Dùng thẳng các DOT reuse trong bảng 14 DOT	BLOCKER	TODO
DOT-REUSE-002	DOT nào dùng lại bằng wrapper nhẹ?	DOT_ROLLBACK_PROOF(extend) · DOT_IO_CHECK(pattern) · DOT_ATOMIC(~70% cut) · species/domain classify	Extend/wrapper, không viết mới	REQUIRED	TODO
DOT-REUSE-003	DOT nào phải viết mới trước checker?	chỉ DOT_PROMOTE_CHECKER	Viết đúng 1 DOT mới (checker), không hơn	REQUIRED	TODO
DOT-REUSE-004	DOT nào phải viết mới trước pilot?	DOT_TEMP_ID · DOT_CELL_MAP · (+IO_CHECK/ATOMIC từ wrapper)	Giữ danh sách net-new tối thiểu cho pilot	REQUIRED	TODO
DOT-REUSE-005	DOT nào defer sau v0.1?	DOT_FORMULA_ASSEMBLE · per-layer	Defer, không chặn v0.1	DEFER	TODO
DOT-REUSE-006	Có thể dùng DOT declaration tối thiểu thay vì DOT governance system không?	§IV.3: khai 5 dòng (bổ sung gì/input/output/mutate/fail)	Khai dot_role+cell_id+capability tối thiểu trong dot_tools	REQUIRED	TODO

13. Nhóm K — Atomic Promote

Đọc nền: addendum §7b, live fn_iu_cut_from_manifest. (Lớp L6.) Lane chứa HOLD-2.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
AP-001	Promote transaction chạy ở đâu?	nơi thực thi	live `fn_iu_cut_from_manifest`	Xác định fn/nơi chạy	ANSWERED	REQUIRED	3	Old survey: plpgsql directus.public.
AP-002	Dùng fn hiện có hay mới?	reuse vs new	`[GR §11]`	Quyết định extend vs new	PARTIAL	REQUIRED	2	Old survey: extend fn hiện có.
AP-003	Lock staging bằng gì?	chống double-promote	live	Xác định lock	ANSWERED	REQUIRED	3	Old survey: SELECT FOR UPDATE.
AP-004	Verify packet bằng gì?	tamper/expiry	live (G1–G7)	Đủ khi: rõ verify content_hash + expires_at/TTL ngoài 7 guard	PARTIAL	BLOCKER	2	Old survey: có G1–G7; thiếu content_hash+TTL.
AP-005	Tạo birth bằng gì?	fold birth	live (writes_birth=false)	Cơ chế fold fn_birth_register vào txn	PARTIAL	BLOCKER	2	Old survey: birth path riêng; cần fold.
AP-006	Ghi canonical object vào đâu?	đích canonical	live `fn_iu_create`	Đích canonical (generic vs chỉ IU)	PARTIAL	REQUIRED	2	Old survey: chỉ information_unit.
AP-007	Đóng `BIRTH_STAMP` ở đâu?	post-stamp	`[GR §11]`	Đủ khi: rõ đóng trong txn + evidence + audit	PARTIAL	BLOCKER	2	Old survey: chưa fold.
AP-008	Đóng `PROMOTE_STAMP` ở đâu?	post-stamp	`[GR §11]` (AQ9)	Đủ khi: rõ nơi đóng + txn + evidence	PARTIAL	BLOCKER	2	Old survey: chưa có nơi đóng.
AP-009	Mark consumed ở đâu?	tiêu thụ candidate	live	Xác nhận consumed fields	ANSWERED	REQUIRED	3	Old survey: consumed_at/run_id/referenced_iu_ids.
AP-010	Audit ghi ở đâu?	provenance	live `dot_iu_command_run`	Xác định audit + bổ sung event_outbox	PARTIAL	REQUIRED	2	Old survey: dot_iu_command_run; thiếu event_outbox.
AP-011	Rollback all-or-nothing bằng gì?	atomicity	live	Xác nhận EXCEPTION abort + dry-run/apply	ANSWERED	REQUIRED	3	Old survey: 1 txn EXCEPTION abort.
AP-012	Chặn birth-only thế nào?	negative state	`addendum §7b`	Cơ chế chặn + test	PARTIAL	BLOCKER	2	Old survey: cần fold birth vào txn.
AP-013	Chặn promote-stamp-only thế nào?	negative state	`[GR §11]`	Cơ chế chặn + test	PARTIAL	BLOCKER	2	Old survey: cần PROMOTE_STAMP trong txn.
AP-014	Chặn canonical write thiếu rollback proof?	negative state	`[GR §11]`	Guard kiểm ROLLBACK_STAMP precondition	TODO	BLOCKER	1	Needs verification: guard chưa kiểm ROLLBACK.
AP-015	Chặn staging consumed nhưng canonical fail?	negative state	live	Xác nhận abort cả consume	ANSWERED	REQUIRED	3	Old survey: chặn được (EXCEPTION).
AP-016	Chặn canonical pass nhưng staging chưa consumed?	negative state	live	Xác nhận cùng txn	ANSWERED	REQUIRED	3	Old survey: chặn được (cùng txn).
AP-017	Chặn double-promote?	negative state	live	Xác nhận FOR UPDATE+lifecycle	ANSWERED	REQUIRED	3	Old survey: chặn được.
AP-018	Rehearsal cần dữ liệu gì?	chuẩn bị rehearsal	`roadmap §3 Phase 5`	Liệt kê dữ liệu clone	PARTIAL	BLOCKER	2	Old survey: clone staging+manifest (D36).
AP-019	Cần clone/staging nào?	môi trường an toàn	`[GR §11]`	Xác định clone secret-free	PARTIAL	BLOCKER	2	Old survey: BEGIN..ROLLBACK / pg-restore-test.
AP-020	DOT nào chạy rehearsal?	máy chạy	`[GR §9, §11]`	Tên DOT + negative tests	PARTIAL	BLOCKER	2	Old survey: DOT_ATOMIC_PROMOTE + negative.
AP-021	Transaction isolation level cần là gì?	tránh anomaly	live PG; `addendum §7b`	Chốt isolation (READ COMMITTED/SERIALIZABLE) + lý do	TODO	REQUIRED	1	Needs verification: chưa khảo sát.
AP-022	Retry/idempotency xử lý thế nào?	an toàn lặp	live (idempotency_key)	Quy tắc retry dựa idempotency_key	TODO	REQUIRED	1	Needs verification.
AP-023	Client gửi promote hai lần thì sao?	double-submit	live (FOR UPDATE+lifecycle)	Hành vi lần 2 (no-op/abort)	PARTIAL	REQUIRED	2	Old survey: lifecycle approved→consumed chặn.
AP-024	Checker verdict hết hạn trước promote thì sao?	verdict staleness	`checker-spec §4`; `[GR §11]`	Quy tắc TTL verdict + re-check	TODO	BLOCKER	1	Needs verification: chưa có TTL verdict.
AP-025	`required-stamps` config đổi sau PROMOTE_OK thì sao?	config drift	`required-stamps.v0.1.json`	Quy tắc re-validate khi config đổi	TODO	REQUIRED	1	Needs verification (liên quan STAMP-GOV-010).
AP-026	Có detector quét partial-state sau crash không?	phục hồi	`[GR §11, §12]`	Quyết định có detector + nơi	TODO	REQUIRED	1	Needs verification: scanner có thể đảm nhận.
AP-027	Atomic promote có dry-run packet không?	rehearsal an toàn	live (dry-run/apply split)	Xác nhận dry-run packet	PARTIAL	REQUIRED	2	Old survey: fn có dry-run/apply split.

K-REUSE — Reuse-first cho Atomic Promote

Bám de-bai rev33 §V.5/§V.7 (BIRTH/PROMOTE = output của atomic promote trong 1 txn), §VI.4 (rehearsal trong staging/dry-run, không ghi canonical). Mặc định Answer Status = TODO. Lane chứa HOLD-2.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
AP-REUSE-001	`fn_iu_cut_from_manifest` hiện dùng lại được bao nhiêu phần?	~70% (lock FOR UPDATE, G1–G7, dry-run/apply, consumed)	Extend phần đã có; chỉ bổ sung phần thiếu	BLOCKER	TODO
AP-REUSE-002	Cần wrapper nhẹ hay function mới?	cut fn đã có khung txn	Wrapper/extend (content_hash+TTL+birth fold), không fn mới	REQUIRED	TODO
AP-REUSE-003	Có thể fold `fn_birth_register` vào transaction hiện có không?	birth path riêng (writes_birth=false)	Gọi fn_birth_register trong txn cut, không birth-only state	BLOCKER	TODO
AP-REUSE-004	Có thể rehearsal bằng `BEGIN...ROLLBACK` hoặc clone hiện có không?	dry-run/apply split + staging clone	BEGIN..ROLLBACK trên clone, không môi trường mới	REQUIRED	TODO
AP-REUSE-005	Negative tests tối thiểu để chứng minh không gãy là gì?	birth-only/promote-stamp-only/double-promote (AP-012..017)	Tập negative test tối thiểu trên staging, fail-closed	REQUIRED	TODO

14. Nhóm L — Scanner / Missing Stamp Report

Đọc nền: de-bai §V.6, §V.17, addendum §6. (Lớp L7.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
SCAN-001	Scanner đọc từ đâu?	nguồn dữ liệu	`[GR §12]`	Liệt kê nguồn đọc	PARTIAL	OPTIONAL	2	Old survey: birth_registry+iu_staging+system_issues.
SCAN-002	Scan staging/canonical/cả hai?	phạm vi	`[GR §12]`	Khẳng định phạm vi	PARTIAL	OPTIONAL	2	Old survey: cả hai.
SCAN-003	Báo loại lỗi nào?	output type	`de-bai §V.6`	Liệt kê loại lỗi	PARTIAL	OPTIONAL	2	Old survey: chưa khai sinh/chưa map cell/thiếu IO/thiếu dấu...
SCAN-004	Scanner có sửa gì không?	chỉ liệt kê	`de-bai §V.17`	Khẳng định read-only	ANSWERED	REQUIRED	3	Old survey: KHÔNG sửa.
SCAN-005	Output lưu ở đâu?	nơi báo cáo	live `system_issues`/`fn_log_issue`	Xác định nơi lưu	PARTIAL	OPTIONAL	2	Old survey: system_issues (dedup).
SCAN-006	Dùng `system_issues` không?	reuse	live	Có/không	ANSWERED	OPTIONAL	3	Old survey: CÓ.
SCAN-007	Scanner chạy định kỳ không?	scheduler	live (no pg_cron)	Xác định scheduler/tần suất	TODO	REQUIRED	1	Needs verification (AQ2, trùng STG-012).
SCAN-008	Cần DOT riêng không?	máy chạy	`[GR §9, §12]`	Xác định DOT scanner	PARTIAL	OPTIONAL	2	Old survey: DOT_STAMP_SCANNER (assemble).
SCAN-009	Scanner có thay checker không?	ranh giới	`[GR §12]`	Khẳng định không thay	ANSWERED	REQUIRED	3	Old survey: KHÔNG.
SCAN-010	Scanner có governance/audit không?	provenance	`[GR §12]`	Xác định audit	PARTIAL	OPTIONAL	2	Old survey: read-only, qua system_issues.
SCAN-011	Scanner có SLA/frequency không?	vận hành	`addendum §6`	Quy ước SLA/tần suất	TODO	OPTIONAL	1	Needs verification.
SCAN-012	Scanner output có severity không?	phân loại lỗi	live `system_issues` (severity)	Xác nhận severity	PARTIAL	OPTIONAL	2	Old survey: system_issues có severity.
SCAN-013	Scanner có owner xử lý issue không?	trách nhiệm	`[GR §12]`	Xác định owner/route	TODO	OPTIONAL	1	Needs verification.
SCAN-014	Scanner phân biệt false positive không?	chất lượng báo cáo	`[GR §12]`	Cơ chế phân biệt FP	TODO	OPTIONAL	1	Needs verification.
SCAN-015	Scanner report theo candidate/cell/collection/domain không?	chiều báo cáo	`[GR §5, §12]`	Khẳng định chiều group-by	TODO	OPTIONAL	1	Needs verification.

L-REUSE — Reuse-first cho Scanner

Bám de-bai rev33 §V.17 (scanner chỉ liệt kê, không sửa toàn hệ, không macro governance), §VI.7 (làm được bằng scanner/report → không auto-fix). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
SCAN-REUSE-001	Scanner hiện có gì dùng lại được?	orphan-scan + idx_birth_uncertified + system_issues	Assemble từ thành phần có sẵn, không scanner mới	REQUIRED	TODO
SCAN-REUSE-002	Có thể dùng `system_issues`/`fn_log_issue`/report thay vì auto-fix không?	system_issues (dedup, severity) + fn_log_issue	Chỉ liệt kê/report; cấm auto-fix toàn hệ	BLOCKER nếu có đề xuất tạo mới	TODO
SCAN-REUSE-003	Scanner v0.1 chỉ cần report những lỗi nào?	de-bai §V.6 (chưa khai sinh/chưa map cell/thiếu IO/thiếu dấu/orphan)	Giới hạn đúng danh sách lỗi tối thiểu	REQUIRED	TODO
SCAN-REUSE-004	Scanner có cần chạy toàn hệ không, hay chỉ candidate/cell pilot?	có thể giới hạn theo candidate/cell	V0.1 chỉ quét phạm vi pilot, không toàn hệ	REQUIRED	TODO

15. Nhóm M — Pilot Cell

Đọc nền: de-bai §V.18, roadmap §3 Phase 6. (Lớp L8 — chỉ chạy khi L1–L6 đạt.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
PILOT-001	Pilot cell cụ thể là gì?	chọn pilot	`[GR §13]`	Tọa độ cell đầy đủ	PARTIAL	REQUIRED	2	Old survey: (atom, information_unit, iu_staging→IU, iu/normative).
PILOT-002	Layer nào?	tránh tầng rỗng	`[GR §4, §13]`	Khẳng định tầng	PARTIAL	REQUIRED	2	Old survey: atom.
PILOT-003	Species nào?	chiều loài	`[GR §5, §13]`	Khẳng định species (sau khi hợp nhất namespace)	PARTIAL	REQUIRED	2	Old survey: information_unit_atom; lưu ý CELL-004.
PILOT-004	Kho tạm nào?	nguồn	`[GR §13]`	Tên kho tạm	PARTIAL	REQUIRED	2	Old survey: iu_staging_record/payload.
PILOT-005	Kho chính đích nào?	đích	`[GR §13]`	Tên kho chính	PARTIAL	REQUIRED	2	Old survey: information_unit+birth_registry.
PILOT-006	Domain nào?	chiều miền	`[GR §13]`	Khẳng định domain	PARTIAL	REQUIRED	2	Old survey: iu/normative.
PILOT-007	Formula nào?	công thức pilot	`[GR §6, §13]`	Tên formula (hoặc cut pipeline)	PARTIAL	REQUIRED	2	Old survey: cut-from-manifest.
PILOT-008	IO Contract nào?	hợp đồng IO	`[GR §7, §13]`	Tên IO contract	PARTIAL	REQUIRED	2	Old survey: 1 × io-contract-minimal.v0.1.
PILOT-009	DOT nào chạy?	máy chạy	`[GR §9, §13]`	Danh sách DOT	PARTIAL	REQUIRED	2	Old survey: TEMP_ID/CELL_MAP/IO_CHECK/VALIDATE/ROLLBACK/CHECKER/ATOMIC.
PILOT-010	Stamp nào đóng?	dấu pilot	`[GR §8, §13]`	Danh sách stamp pre/post	PARTIAL	REQUIRED	2	Old survey: pre 5 + post 2 (rehearsal).
PILOT-011	Cleanup/rollback thế nào?	sai thì xóa	`[GR §13]`	Cơ chế cleanup+rollback	PARTIAL	REQUIRED	2	Old survey: fn_iu_staging_cleanup+BEGIN..ROLLBACK.
PILOT-012	Có đụng canonical thật không?	an toàn	`de-bai §V.18`	Khẳng định không đụng canonical	ANSWERED	REQUIRED	3	Old survey: KHÔNG (staging+dry-run).
PILOT-013	Pilot thành công khi nào?	tiêu chí pass	`[GR §13]`	Đủ khi: tiêu chí pass định lượng rõ	PARTIAL	REQUIRED	2	Old survey: trọn vòng+rehearsal pass+rollback proven+0 canonical mutation.
PILOT-014	Pilot thất bại khi nào?	tiêu chí fail	`[GR §13]`	Tiêu chí fail rõ	PARTIAL	REQUIRED	2	Old survey: fail-open/không xóa được/nửa vời.
PILOT-015	Thất bại thì xóa cái gì?	rollback	`[GR §13]`	Danh sách xóa	PARTIAL	REQUIRED	2	Old survey: iu_staging_record→rejected→cleanup+payload CASCADE.
PILOT-016	Cần Codex xác nhận trước pilot không?	gate	`roadmap §4`	Khẳng định Codex CP trước pilot	PARTIAL	REQUIRED	2	Old survey: Codex CP2/CP3.
PILOT-017	Pilot có success metrics định lượng không?	đo lường	`roadmap §3 Phase 6`	Liệt kê metric số (vd 0 canonical mutation, N stamp đóng)	TODO	REQUIRED	1	Needs verification: chưa định lượng.
PILOT-018	Pilot có allowed/forbidden surfaces không?	an toàn phạm vi	`de-bai §V.18`	Bảng allowed vs forbidden surfaces	TODO	BLOCKER	1	Needs verification: chưa liệt kê forbidden surfaces.
PILOT-019	Pilot có rollback packet không?	sai thì xóa	`[GR §11, §13]`	Định nghĩa rollback packet	TODO	REQUIRED	1	Needs verification.
PILOT-020	Pilot có handoff criteria sang phase tiếp?	chuyển giao	`roadmap §3 Phase 6`	Tiêu chí handoff	TODO	REQUIRED	1	Needs verification.
PILOT-021	Pilot có stop condition sau 7–10 ngày không?	giới hạn thời gian	`roadmap §3`	Stop condition + thời hạn	TODO	OPTIONAL	1	Needs verification.

M-REUSE — Reuse-first cho Pilot

Bám de-bai rev33 §V.18 (pilot phải chứng minh "sai thì xóa được", không ghi canonical), §VI.4 (kho tạm/delete-fast). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
PILOT-REUSE-001	Pilot dùng được substrate hiện có nào?	iu_staging → information_unit + birth_registry (atom)	Dùng substrate atom đã đủ data, không tạo mới	BLOCKER	TODO
PILOT-REUSE-002	Pilot có thể chạy với 0 collection mới, 0 registry mới không?	iu_staging + birth + information_unit	Mặc định 0 mới; chứng minh đủ	BLOCKER nếu có đề xuất tạo mới	TODO
PILOT-REUSE-003	Pilot nhanh nhất chứng minh điều gì?	trọn vòng workspace→stamp→checker→rehearsal	Chọn 1 cell chứng minh đủ-dấu + rollback + 0 canonical mutation	REQUIRED	TODO
PILOT-REUSE-004	Pilot thất bại thì xóa gì?	iu_staging_record→rejected→cleanup + payload CASCADE	Cơ chế xóa có sẵn, không cần rollback packet mới	REQUIRED	TODO
PILOT-REUSE-005	Pilot thành công mà không ghi canonical được không?	staging + dry-run + rehearsal	Chứng minh trọn vòng ở staging/dry-run, không đụng kho chính	REQUIRED	TODO

16. Nhóm N — Thứ tự làm trước/sau

Đọc nền: roadmap §3, §7, de-bai §VII. (Meta-trình tự, đọc cùng §2b Dependency Map.)

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức	Old Survey Coverage / Ghi chú
ORDER-001	Việc đầu tiên có phải viết checker không?	chống sai thứ tự	`roadmap §3`	Khẳng định checker KHÔNG phải việc đầu	PARTIAL	REQUIRED	2	Old survey: chốt giấy+CP1 trước; checker Phase 3.
ORDER-002	Việc đầu tiên có phải kiểm staging/registry thực tế không?	substrate-first	`roadmap §3 Phase 1`	Khẳng định Phase 1 substrate trước	PARTIAL	REQUIRED	2	Old survey: CÓ (đã làm 1 lượt = [GR]).
ORDER-003	Trước khi chọn DOT cần biết gì?	tiền đề	§2b L1–L3	Liệt kê tiền đề DOT	PARTIAL	REQUIRED	2	Old survey: cell_id+stamp+atomic promote shape.
ORDER-004	Trước khi chọn collection cần biết gì?	tiền đề	§2b L1	Liệt kê tiền đề collection	PARTIAL	REQUIRED	2	Old survey: tầng pilot + iu_staging đủ.
ORDER-005	Trước khi thiết kế atomic promote cần biết gì?	tiền đề	§2b L1–L5	Liệt kê tiền đề atomic promote	PARTIAL	REQUIRED	2	Old survey: cut shape+birth fold+packet_hash+ROLLBACK_STAMP.
ORDER-006	Trước khi gọi Codex cần gap report nào?	điều kiện CP1	`roadmap §4`	Danh sách gap report lõi	PARTIAL	REQUIRED	2	Old survey: 5 gap report lõi.
ORDER-007	Trước pilot cần pass những gì?	điều kiện pilot	`roadmap §3 Phase 6`	Danh sách điều kiện pass	PARTIAL	REQUIRED	2	Old survey: checker selftest+atomic rehearsal (HOLD-2).
ORDER-008	Cái gì có thể làm song song?	tối ưu	`roadmap §3`	Danh sách song song	PARTIAL	OPTIONAL	2	Old survey: chốt giấy + 5 gap report.
ORDER-009	Cái gì tuyệt đối không làm song song?	an toàn	`roadmap §3`	Danh sách tuần tự bắt buộc	PARTIAL	REQUIRED	2	Old survey: rehearsal SAU checker; pilot SAU cả hai.
ORDER-010	Cái gì phải để sau v0.1?	hoãn	`[GR §C]`	Danh sách hoãn	PARTIAL	DEFER	2	Old survey: formula registry/block-mode/per-layer/QT001.

N-REUSE — Reuse-first cho Order / Thứ tự

Bám de-bai rev33 §VII (thứ tự định hướng: đề bài → Question Catalog → Codex audit → trả lời theo dependency → gap report → roadmap → checker/pilot). Mặc định Answer Status = TODO.

ID	Câu hỏi reuse-first	Reuse Check (hệ đã có gì / dùng lại được gì)	Minimal/Fastest Path (ít sửa nhất, nhanh nhất)	Gate Impact	Answer Status
ORDER-REUSE-001	Việc đầu tiên có phải là reuse survey (Nhóm 0 / L0) không?	Nhóm 0 + Dependency Map L0	Bắt đầu bằng reuse baseline trước mọi thiết kế	BLOCKER	TODO
ORDER-REUSE-002	Trước khi viết mới, có bắt buộc chứng minh không reuse được không?	REUSE-006 + Decision Rule §2c	Mọi đề xuất tạo-mới phải qua chứng minh reuse không đủ	REQUIRED	TODO
ORDER-REUSE-003	Có thể đạt mục tiêu v0.1 bằng những patch nhỏ nào?	metadata patch + wrapper + IO Contract 5 field	Liệt kê các patch nhỏ thay vì đại tu	REQUIRED	TODO
ORDER-REUSE-004	Việc nào nếu làm bây giờ sẽ làm chậm toàn hệ?	đối chiếu anti-bloat (ledger/workflow/ontology)	Gắn cờ defer/loại; không làm ở v0.1	REQUIRED	TODO
ORDER-REUSE-005	Thứ tự nhanh nhất: reuse baseline → blockers → pilot substrate → checker selftest → rehearsal?	khớp Dependency Map L0→L8	Theo đúng thứ tự này; không nhảy cóc	REQUIRED	TODO

Nhóm R — Operational Risk Gates / Rủi ro vận hành trước pilot

Đọc nền: bám đề bài rev33 (delete-fast/TTL §VI.4, anti-bloat §V.11/§V.13) + addendum stamp/atomic-promote. (Lớp L5b — kiểm song song L1–L5, chặn L6/L8.)

Nhóm này KHÔNG yêu cầu thiết kế mới. Nó buộc vòng khảo sát sau kiểm tra các rủi ro vận hành có thể làm hệ thống gãy khi pilot hoặc scale. Không được tạo index, worker, scheduler, ledger, registry, scanner, checker hay DOT mới trong bước này — chỉ đặt câu hỏi và yêu cầu bằng chứng. Mọi câu mặc định Answer Status = TODO (chưa trả lời), Mức = —.

R1 — Atomic Promote: lock / transaction risk

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-AP-001	Atomic promote transaction có được giữ ngắn không?	transaction dài giữ lock lâu → nghẽn/khoá toàn hệ khi scale	live đường ghi atomic promote (DOT atomic promote + `fn_birth_register` fold)	Xác định độ dài/biên transaction + cam kết "ghi tối thiểu", không I/O nặng trong transaction	TODO	BLOCKER	—	Câu mới; liên quan Nhóm K (Atomic Promote).
RISK-AP-002	Pre-commit Check read-only đã tách khỏi Commit transaction chưa?	checker đọc nặng nằm trong transaction sẽ kéo dài lock	live DOT_PROMOTE_CHECKER + ranh giới atomic promote	Chứng minh checker chạy read-only TRƯỚC, transaction cuối không gọi lại checker nặng	TODO	BLOCKER	—	Câu mới; liên quan DOT-006 / Nhóm J, K.
RISK-AP-003	Trong transaction cuối, có còn logic đọc/scan/validate nặng không?	scan/validate trong transaction = lock kéo dài + nguy cơ deadlock	live atomic promote body	Liệt kê mọi câu lệnh trong transaction cuối; xác nhận 0 scan/validate nặng	TODO	REQUIRED	—	Câu mới; chỉ đọc body, không sửa.
RISK-AP-004	`SELECT FOR UPDATE` lock những row nào, trong bao lâu?	lock range rộng/giữ lâu → nghẽn concurrent promote	live atomic promote + birth fold SQL	Xác định tập row bị lock + thời gian giữ + phạm vi (row vs range)	TODO	BLOCKER	—	Câu mới; chỉ EXPLAIN/đọc, KHÔNG chạy mutate.
RISK-AP-005	Có risk deadlock khi fold birth + consume staging + write canonical không?	3 nguồn ghi đồng thời, thứ tự lock không nhất quán = deadlock	live thứ tự ghi birth/staging/canonical	Xác định thứ tự acquire lock nhất quán hoặc chứng minh các tập lock không giao nhau	TODO	BLOCKER	—	Câu mới; liên quan Nhóm D (Staging) + K.
RISK-AP-006	Có cần EXPLAIN / lock rehearsal trước pilot không?	phải đo trước khi rehearsal/pilot thay vì phát hiện khi gãy	kế hoạch rehearsal read-only (chưa chạy)	Có ít nhất kế hoạch EXPLAIN/lock rehearsal read-only trước atomic promote rehearsal	TODO	REQUIRED	—	Câu mới; chỉ kế hoạch, KHÔNG mở pilot.

Acceptance Criteria (nhóm R1): đủ khi xác định rõ — checker làm read-only TRƯỚC transaction; transaction cuối chỉ gồm ghi tối thiểu; không scan toàn hệ trong transaction; có negative/concurrency rehearsal hoặc ít nhất kế hoạch rehearsal read-only. Gate Impact: RISK-AP-001 / -002 / -004 / -005 = BLOCKER trước atomic promote rehearsal/pilot.

R2 — JSONB / Index / Scanner performance risk

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-IDX-001	Scanner/DOT sẽ query những JSONB path nào?	không biết path bị query thì không lường được full scan	live scanner/DOT query dự kiến + `staging.metadata`/`jsonb_profile`	Inventory đủ các JSONB path bị query (stamp/cell/io/validation/rollback)	TODO	BLOCKER	—	Câu mới; liên quan Nhóm L (Scanner) + I (Stamp).
RISK-IDX-002	Các path stamp/cell/io/validation/rollback hiện có index chưa?	thiếu index trên path nóng → full scan khi scale	live index inventory (`pg_indexes`/schema)	Liệt kê index hiện có ↔ path; đánh dấu path nào chưa có index	TODO	BLOCKER	—	Câu mới; chỉ đọc schema, KHÔNG tạo index.
RISK-IDX-003	Nếu dùng `staging.metadata` / `jsonb_profile`, query nào có nguy cơ full table scan?	JSONB không index = seq scan trên bảng lớn	live query dự kiến + EXPLAIN (read-only)	Chỉ ra query nào seq-scan; phân loại an toàn vs nguy hiểm	TODO	BLOCKER	—	Câu mới; liên quan Nhóm D (Staging).
RISK-IDX-004	Với bảng lớn như `birth_registry`, scanner có bị cấm full scan không?	full scan bảng lớn làm pilot/scale gãy	live `birth_registry` size + phạm vi scanner	Có quy tắc cấm full scan trên bảng lớn cho scanner v0.1	TODO	BLOCKER	—	Câu mới; liên quan Nhóm A (Birth) + L.
RISK-IDX-005	Cần GIN / B-tree / partial index tối thiểu nào trước pilot?	nếu thiếu, chỉ ĐỀ XUẤT index tối thiểu, không tạo bảng mới	live index inventory + path nóng	Đề xuất index tối thiểu (chỉ đề xuất, KHÔNG tạo); không thêm bảng	TODO	REQUIRED	—	Câu mới; chỉ đề xuất, không enact.
RISK-IDX-006	Có cần EXPLAIN plan cho scanner/checker query trước pilot không?	đo plan trước thay vì phát hiện seq-scan khi pilot	kế hoạch EXPLAIN read-only (chưa chạy)	Có kế hoạch EXPLAIN cho mọi scanner/checker query trước pilot	TODO	REQUIRED	—	Câu mới; read-only, không mở pilot.
RISK-IDX-007	Có thể giới hạn scanner v0.1 theo candidate/cell pilot thay vì toàn hệ không?	giới hạn phạm vi tránh full scan toàn hệ ở v0.1	live phạm vi scanner + scope pilot cell	Xác định scanner v0.1 chạy theo candidate/cell pilot, không toàn hệ	TODO	REQUIRED	—	Câu mới; liên quan Nhóm M (Pilot) + L.

Acceptance Criteria (nhóm R2): đủ khi có inventory — danh sách JSONB path bị query; index hiện có; query nào được phép trong pilot; query nào bị cấm vì full scan; nếu cần index, chỉ đề xuất index tối thiểu, không tạo bảng mới. Gate Impact: RISK-IDX-001..004 = BLOCKER trước scanner/pilot; RISK-IDX-005..007 = REQUIRED.

R3 — Stale verdict / config drift risk

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-STL-001	Mỗi stamp/verdict có gắn `rule_version` hoặc `config_hash` không?	không version → không phát hiện stamp stale khi rule đổi	live stamp/verdict schema + nơi lưu	Xác định field version/hash trên mỗi stamp/verdict, hoặc xác nhận thiếu	TODO	BLOCKER	—	Câu mới; liên quan Nhóm I (Stamp) + 11b STAMP-GOV.
RISK-STL-002	`IO_STAMP` có gắn IO Contract hash/version không?	IO Contract đổi → IO_STAMP cũ thành stale	live IO_STAMP + IO Contract (Nhóm H)	Xác định IO_STAMP có gắn hash/version của IO Contract	TODO	REQUIRED	—	Câu mới; liên quan Nhóm H (IO Contract).
RISK-STL-003	`VALIDATION_STAMP` có gắn validator rule hash/version không?	validator rule đổi → verdict cũ stale	live VALIDATION_STAMP + validator rule	Xác định VALIDATION_STAMP có gắn hash/version rule validate	TODO	REQUIRED	—	Câu mới; liên quan Nhóm J (DOT_VALIDATE).
RISK-STL-004	`ROLLBACK_STAMP` có gắn rollback rule version không?	rollback rule đổi → rollback stamp stale	live ROLLBACK_STAMP + rollback rule	Xác định ROLLBACK_STAMP có gắn version rule rollback	TODO	REQUIRED	—	Câu mới; liên quan Nhóm I/K.
RISK-STL-005	`PROMOTE_OK` có TTL hoặc expiry không?	PROMOTE_OK cũ vẫn dùng sau khi config đổi = promote sai	live PROMOTE_OK semantics	Xác định PROMOTE_OK có TTL/expiry hay vô thời hạn	TODO	BLOCKER	—	Câu mới; liên quan Nhóm K; de-bai PROMOTE_STAMP=output.
RISK-STL-006	Nếu `required-stamps.v0.1.json` đổi sau `PROMOTE_OK` thì promote xử lý thế nào?	config required-stamps đổi → PROMOTE_OK cũ không còn hợp lệ	live required-stamps contract + promote logic	Xác định promote so PROMOTE_OK với required-stamps hiện hành, fail-closed nếu lệch	TODO	BLOCKER	—	Câu mới; liên quan Nhóm K + I.
RISK-STL-007	Nếu rule/config đổi, object quay về `MISSING_STAMP` hay yêu cầu re-run DOT nào?	phải có hành vi rõ khi stale: re-stamp hay chặn	live stamp lifecycle + đường re-run DOT	Xác định trạng thái object khi stale (MISSING_STAMP / re-run DOT cụ thể)	TODO	BLOCKER	—	Câu mới; liên quan Nhóm I (Stamp Lifecycle).

Acceptance Criteria (nhóm R3): đủ khi xác định cách phát hiện stale stamp/verdict — hash/version nào lưu; lưu ở staging metadata hay packet; promote so với current config thế nào; lệch thì fail-closed ra sao. Gate Impact: RISK-STL-001 / -005 / -006 / -007 = BLOCKER trước promote checker / atomic promote.

R4 — Cleanup / blob_ref / external artifact garbage risk

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-GC-001	`iu_staging_payload.blob_ref` trỏ tới tài nguyên ngoài DB nào?	blob ngoài DB không dọn theo DB → rác vật lý	live `iu_staging_payload` schema + semantics `blob_ref`	Xác định blob_ref trỏ tới đâu (file/cache/vector/none)	TODO	REQUIRED	—	Câu mới; liên quan Nhóm D (Staging).
RISK-GC-002	`fn_iu_staging_cleanup` hiện chỉ dọn DB hay có emit `event_outbox` để dọn blob/cache?	cleanup chỉ-DB để lại blob/cache orphan	live `fn_iu_staging_cleanup` body	Xác định cleanup phạm vi DB-only hay có emit event dọn ngoài DB	TODO	REQUIRED	—	Câu mới; chỉ đọc body, không sửa.
RISK-GC-003	Khi xóa candidate, `payload_json` / `text` / `blob_ref` được dọn theo cơ chế nào?	xóa candidate phải dọn cả payload + blob	live đường cleanup/delete	Xác định cơ chế dọn payload_json/text/blob_ref khi xóa candidate	TODO	REQUIRED	—	Câu mới; liên quan delete-fast (de-bai `§VI.4`).
RISK-GC-004	Có nguy cơ orphan blob / cache / vector artifact sau cleanup không?	orphan tích tụ khi scale → rác + chi phí	live phạm vi cleanup + inventory artifact	Xác định có/không orphan + nơi orphan có thể tồn tại	TODO	REQUIRED	—	Câu mới; trước pilot delete-fast.
RISK-GC-005	Có cần cleanup event contract tối thiểu không?	nếu có blob thật, cần hợp đồng event dọn tối thiểu	live event_outbox + blob_ref thực tế	Xác định cần/không cần cleanup event contract tối thiểu (chỉ đề xuất)	TODO	OPTIONAL	—	Câu mới; thành REQUIRED nếu có blob_ref thật.
RISK-GC-006	Có cần worker ngoài DB không, hay v0.1 chỉ report orphan blob?	tránh xây worker khi v0.1 chỉ cần report	live phạm vi v0.1 + tính khả thi report orphan	Xác định v0.1 chỉ report orphan hay cần worker (KHÔNG tạo worker ở bước này)	TODO	OPTIONAL	—	Câu mới; thành REQUIRED nếu có blob_ref thật; không tạo worker.

Acceptance Criteria (nhóm R4): đủ khi phân biệt — DB cleanup; external blob cleanup; event_outbox hoặc report cần thiết; phạm vi cleanup v0.1 tối thiểu. Gate Impact: RISK-GC-001..004 = REQUIRED trước pilot delete-fast; RISK-GC-005 / -006 = OPTIONAL (thành REQUIRED nếu tồn tại blob_ref thật).

R5 — UNKNOWN / PENDING cell context risk

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-CELL-001	`DOT_IO_CHECK` có được chạy khi `cell_id` còn UNKNOWN/PENDING không?	chạy IO check khi cell chưa resolve → sai ngữ cảnh	live precondition DOT_IO_CHECK + trạng thái cell	Xác định DOT_IO_CHECK có chặn/fail-fast khi cell UNKNOWN/PENDING	TODO	BLOCKER	—	Câu mới; liên quan Nhóm F (Cell) + J (DOT).
RISK-CELL-002	`DOT_VALIDATE` có được chạy khi `cell_id` còn UNKNOWN/PENDING không?	validate trên cell chưa resolve → verdict sai ngữ cảnh	live precondition DOT_VALIDATE + trạng thái cell	Xác định DOT_VALIDATE có chặn/fail-fast khi cell UNKNOWN/PENDING	TODO	BLOCKER	—	Câu mới; liên quan Nhóm F + J.
RISK-CELL-003	`CELL_STAMP` có phải chạy trước `IO_STAMP` và `VALIDATION_STAMP` không?	thứ tự stamp sai → IO/Validation gắn vào cell chưa resolve	live thứ tự stamp (DOT_CELL_MAP → IO → Validation)	Xác định CELL_STAMP bắt buộc trước IO_STAMP/VALIDATION_STAMP	TODO	BLOCKER	—	Câu mới; liên quan Nhóm I (Stamp Lifecycle) + F.
RISK-CELL-004	IO Contract có bind với `resolved cell_id` không?	IO Contract không bind cell → IO_STAMP mơ hồ	live binding IO Contract ↔ cell_id (Nhóm H/F)	Xác định IO Contract gắn với resolved cell_id	TODO	BLOCKER	—	Câu mới; liên quan Nhóm H (IO Contract) + F.
RISK-CELL-005	Nếu cell đổi sau `IO_STAMP`, IO_STAMP có stale không?	cell đổi → IO_STAMP cũ không còn đúng ngữ cảnh	live binding IO_STAMP ↔ cell + đường đổi cell	Xác định IO_STAMP thành stale/invalid khi cell đổi (liên kết RISK-STL)	TODO	REQUIRED	—	Câu mới; liên quan R3 (stale) + F.
RISK-CELL-006	DOT nào được phép chạy trên UNKNOWN/PENDING? DOT nào phải fail-fast?	cần ranh giới rõ DOT nào an toàn trên cell chưa resolve	live DOT capability contract (12b) + trạng thái cell	Phân loại DOT được phép vs phải fail-fast trên cell UNKNOWN/PENDING	TODO	REQUIRED	—	Câu mới; liên quan Nhóm J 12b DOT-CAP.

Acceptance Criteria (nhóm R5): đủ khi có rule rõ — DOT_CELL_MAP trước; IO/Validation chỉ chạy sau resolved cell_id; nếu cell pending thì fail-fast hoặc chỉ report; cell đổi thì IO/Validation stamp invalid hoặc yêu cầu re-run. Gate Impact: RISK-CELL-001..004 = BLOCKER trước checker / pilot.

R6 — Runtime liveness / config availability

Codex HOLD fix #5 — runtime/config readiness. Một verdict "đúng logic" trên runtime chết hoặc config stale vẫn không an toàn. Chỉ đặt câu hỏi; không tạo healthcheck/worker.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-RUN-001	Các runtime cần sống cho pilot slice là gì?	không biết runtime nào phải sống thì không đảm bảo pilot/checker chạy an toàn	live inventory runtime theo phạm vi pilot slice	Liệt kê đủ runtime bắt buộc-sống cho pilot slice	TODO	BLOCKER	—	Câu mới (Codex HOLD #5); liên quan Nhóm S + M.
RISK-RUN-002	Làm sao kiểm tra liveness của Agent Data MCP, Postgres, Qdrant, Directus/worker (nếu có)?	không có cách đo liveness = không phát hiện runtime chết	live endpoint/health của từng runtime	Xác định cách đo liveness read-only cho mỗi runtime	TODO	REQUIRED	—	Câu mới; chỉ read-only, không tạo healthcheck.
RISK-RUN-003	Nếu một runtime chết, checker/survey/pilot fail thế nào?	runtime chết giữa chừng → verdict/partial state sai	live đường phụ thuộc runtime của checker/scanner	Xác định hành vi fail (fail-closed/abort/skip) khi runtime chết	TODO	REQUIRED	—	Câu mới; liên quan R8 crash.
RISK-RUN-004	Có healthcheck read-only trước survey/pilot không?	phải biết runtime sống TRƯỚC khi chạy thay vì gãy giữa chừng	kế hoạch preflight read-only (chưa có)	Có (hoặc đề xuất) preflight read-only trước survey/pilot	TODO	BLOCKER	—	Câu mới; chỉ đề xuất, KHÔNG tạo worker.
RISK-RUN-005	Nếu `required-stamps`/config không load/parse/version-pin được thì checker có fail-closed không?	config không load = checker chạy mù → verdict sai	live đường load config + promote-checker spec	Xác định checker fail-closed + lộ lý do máy-đọc-được khi config lỗi	TODO	BLOCKER	—	Câu mới; liên quan Nhóm S (SRC-010).
RISK-RUN-006	Config source freshness được đo thế nào?	config stale = verdict đúng-logic nhưng sai-thực-tế	live config delivery + freshness signal	Xác định cách đo freshness/độ trễ của config source	TODO	REQUIRED	—	Câu mới; liên quan SRC-009/010.

Acceptance Criteria (nhóm R6): đủ khi xác định — runtime nào phải sống; cách đo liveness read-only; hành vi khi runtime chết; preflight trước survey/pilot; config load/parse/version-pin fail-closed; cách đo freshness. Không tạo healthcheck/worker — chỉ đặt câu hỏi. Gate Impact: RISK-RUN-001 / -004 / -005 = BLOCKER trước survey/checker/pilot (tùy pha); RISK-RUN-002 / -003 / -006 = REQUIRED.

R7 — Bypass / write-permission risk

Codex HOLD fix #5 — privilege/bypass surface. Một đường ghi canonical bỏ qua checker/atomic promote làm vô hiệu mọi cổng. Chỉ đặt câu hỏi; không sửa quyền/role.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-BYPASS-001	Có bypass flag / kill-switch / role nào có thể ghi thẳng canonical không?	bypass path = vô hiệu hóa checker/atomic promote	live grant/role + đường ghi canonical	Liệt kê mọi đường có thể ghi canonical/consumed bỏ qua cổng	TODO	BLOCKER	—	Câu mới; liên quan Nhóm K + L5 checker.
RISK-BYPASS-002	Trong pilot, role nào được phép ghi staging, role nào tuyệt đối không được ghi canonical?	không tách quyền = pilot có thể chạm canonical	live phân quyền staging vs canonical	Xác định ma trận role↔staging/canonical cho pilot	TODO	BLOCKER	—	Câu mới; liên quan PILOT-018 forbidden surfaces.
RISK-BYPASS-003	Có audit cho mọi bypass/write path không?	không audit = không phát hiện ghi lén canonical	live audit/event_outbox trên đường ghi	Xác định audit bao phủ mọi write/bypass path	TODO	REQUIRED	—	Câu mới; liên quan R8 outbox/audit.
RISK-BYPASS-004	Nếu phát hiện bypass path chưa kiểm soát, pilot có bị chặn không?	bypass chưa kiểm soát = rủi ro production mutation	rule chặn pilot khi có bypass mở	Xác định pilot BLOCKED khi tồn tại bypass chưa kiểm soát	TODO	BLOCKER	—	Câu mới; liên quan Owner Decision Checkpoints.
RISK-BYPASS-005	Existing production path có còn là authoritative path trong pilot không?	new path không được tiếm quyền production khi pilot	live đường production hiện hành	Xác nhận existing production path vẫn authoritative trong pilot	TODO	REQUIRED	—	Câu mới; liên quan COEXIST.
RISK-BYPASS-006	New path có thể disable mà không ảnh hưởng existing path không?	phải tắt được new path mà không gãy production	live coupling new↔existing path	Xác định new path disable-được, không ảnh hưởng existing	TODO	REQUIRED	—	Câu mới; liên quan rollback/delete-fast.

Acceptance Criteria (nhóm R7): đủ khi xác định — mọi đường ghi canonical/consumed; role ghi staging vs cấm ghi canonical; audit cho bypass/write path; chặn pilot nếu có bypass chưa kiểm soát; existing production path vẫn authoritative; new path disable-được không ảnh hưởng existing. Gate Impact: RISK-BYPASS-001 / -002 / -004 = BLOCKER trước pilot; RISK-BYPASS-003 / -005 / -006 = REQUIRED.

R8 — Crash / retry / outbox consistency

Codex HOLD fix #5 — crash/retry boundary. Rủi ro không chỉ là transaction dài mà là trạng thái dở dang quanh commit. Chỉ đặt câu hỏi; không tạo recovery worker.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-CRASH-001	Nếu crash sau birth write nhưng trước consumed mark thì trạng thái gì?	partial state có thể để birth không gắn consumed	live thứ tự ghi birth → consumed	Xác định trạng thái + cách phục hồi tại boundary này	TODO	BLOCKER	—	Câu mới; liên quan Nhóm A + K.
RISK-CRASH-002	Nếu crash sau consumed mark nhưng trước audit/outbox thì trạng thái gì?	consumed nhưng thiếu audit = mất dấu vết	live thứ tự consumed → audit/outbox	Xác định trạng thái + cách phát hiện consumed-without-audit	TODO	BLOCKER	—	Câu mới; liên quan R7 audit + AP-010.
RISK-CRASH-003	Retry promote có tạo double-promote không?	retry không idempotent = ghi canonical 2 lần	live idempotency key/guard của promote	Xác định promote idempotent (retry không double-promote)	TODO	BLOCKER	—	Câu mới; liên quan Nhóm K.
RISK-CRASH-004	Có thể tạo canonical-without-audit hoặc consumed-without-canonical không?	trạng thái lệch giữa canonical/consumed/audit phá toàn vẹn	live ranh giới transaction canonical/consumed/audit	Xác định không thể tạo trạng thái lệch này (hoặc detector bắt được)	TODO	BLOCKER	—	Câu mới; liên quan K + R7.
RISK-CRASH-005	`event_outbox`/audit ghi trong transaction hay sau transaction?	ghi ngoài transaction = mất audit khi crash	live atomic promote body + outbox write	Xác định outbox/audit ghi trong hay sau transaction	TODO	REQUIRED	—	Câu mới; liên quan AP-010.
RISK-CRASH-006	Có recovery/detector read-only cho partial state không?	phải phát hiện trạng thái dở dang thay vì để âm thầm	live phạm vi detector/scanner	Xác định có (hoặc đề xuất) detector read-only cho partial state	TODO	REQUIRED	—	Câu mới; chỉ report, KHÔNG tự sửa.

Acceptance Criteria (nhóm R8): đủ khi xác định — trạng thái tại mọi commit boundary; retry không double-promote; không canonical-without-audit / consumed-without-canonical; outbox/audit trong hay sau transaction; có detector read-only cho partial state. Gate Impact: RISK-CRASH-001..004 = BLOCKER trước atomic promote rehearsal/pilot; RISK-CRASH-005 / -006 = REQUIRED.

R9 — Retention / backpressure / time source

Codex HOLD fix #5 — retention/cardinality/backpressure + clock/TTL semantics. Chỉ đặt câu hỏi; không tạo limit/worker/scheduler.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
RISK-CAP-001	Retention/cardinality giới hạn thế nào cho candidate packets, verdicts, `system_issues`, `event_outbox`?	tăng vô hạn = rác + chi phí + chậm khi scale	live size/retention của packets/verdicts/issues/outbox	Xác định giới hạn retention/cardinality cho mỗi loại	TODO	REQUIRED	—	Câu mới; liên quan Nhóm D + L.
RISK-CAP-002	Nếu `system_issues`/`event_outbox` tăng nhanh thì có backpressure/limit không?	bùng nổ row = nghẽn/đầy ổ khi pilot scale	live đường ghi issues/outbox	Xác định có/không backpressure hoặc limit khi tăng nhanh	TODO	REQUIRED	—	Câu mới; liên quan R8.
RISK-CAP-003	Scanner/report có giới hạn batch/scope không?	scanner không giới hạn = full scan toàn hệ	live phạm vi scanner + batch size	Xác định scanner có giới hạn batch/scope (theo pilot slice)	TODO	REQUIRED	—	Câu mới; liên quan R2 + Nhóm L.
RISK-TIME-001	TTL/expiry dùng clock/source nào?	không rõ nguồn clock = TTL/expiry không tin được	live nguồn now()/clock cho TTL/verdict	Xác định clock/source định nghĩa TTL/expiry	TODO	BLOCKER	—	Câu mới; BLOCKER trước TTL/verdict expiry; liên quan R3.
RISK-TIME-002	Clock skew giữa runtime/DB ảnh hưởng verdict expiry thế nào?	lệch clock → verdict hết hạn sai thời điểm	live runtime clock vs DB clock	Xác định ảnh hưởng clock skew tới expiry	TODO	REQUIRED	—	Câu mới; liên quan R3 stale.
RISK-TIME-003	Nếu `now()` / app clock lệch thì fail-closed hay warning?	hành vi khi clock lệch phải rõ ràng	live xử lý lệch clock	Xác định fail-closed hay warning khi clock lệch	TODO	REQUIRED	—	Câu mới; liên quan R3 + R6.

Acceptance Criteria (nhóm R9): đủ khi xác định — ngưỡng retention/cardinality/backpressure cho packets/verdicts/issues/outbox; giới hạn batch/scope scanner; clock/source định nghĩa TTL; ảnh hưởng clock skew; fail-closed hay warning khi clock lệch. Gate Impact: RISK-CAP-001..003 = REQUIRED; RISK-TIME-001 = BLOCKER trước TTL/verdict expiry; RISK-TIME-002 / -003 = REQUIRED.

Nhóm S — Source / Revision / Delivery Gates

Đọc nền: Codex audit 2026-06-15 (HOLD fix #1 — source authority / revision pin). Mục tiêu: tránh việc Claude/Codex/Agent/runtime đọc các bản khác nhau. Codex báo: các file active knowledge/dev/laws-new/* tồn tại trong Agent Data KB nhưng không có trong checkout. Chỉ đặt câu hỏi; không tạo manifest/source map/config delivery trong task này. Mọi câu mặc định Answer Status = TODO, Mức = —.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
SRC-001	Source of truth hiện tại cho `knowledge/dev/laws-new/*` là Agent Data KB, git checkout, hay runtime config?	đọc khác nguồn = drift kiến trúc	Agent Data KB revision + git checkout listing + runtime config location	Xác định 1 nguồn authoritative cho mỗi file active	TODO	BLOCKER	—	Câu mới (Codex HOLD #1).
SRC-002	Các file active `laws-new` có tồn tại trong checkout local không?	Codex thấy checkout KHÔNG có file laws-new → đọc nhầm/không đọc được	`ls knowledge/dev/laws-new/` trong checkout	Xác nhận có/không + liệt kê file thiếu	TODO	BLOCKER	—	Câu mới; Codex evidence: No such file.
SRC-003	Nếu chỉ tồn tại trong Agent Data KB, quy trình sync/export vào checkout để Claude/Codex đọc/chạy là gì?	không có đường export = Codex/Claude không đọc cùng bản	quy trình export KB → checkout (nếu có)	Xác định quy trình sync/export (hoặc xác nhận thiếu)	TODO	BLOCKER	—	Câu mới; liên quan SRC-002.
SRC-004	Mỗi file active có revision/hash nào là bản chuẩn trước khi khảo sát?	không pin revision = mỗi agent đọc bản khác	revision/hash từng file active	Xác định revision/hash chuẩn cho mỗi file	TODO	BLOCKER	—	Câu mới; vd catalog rev hiện hành.
SRC-005	Có manifest liệt kê file + revision/hash + location không?	thiếu manifest = không kiểm chứng cùng-bản	manifest/source map (nếu có)	Xác định có/không manifest đủ field	TODO	BLOCKER	—	Câu mới; KHÔNG tạo manifest ở task này.
SRC-006	Codex/Claude/Agent có đang đọc cùng một bản tài liệu không?	đọc lệch bản = audit/khảo sát không tin được	revision mỗi tác nhân đọc	Xác nhận mọi tác nhân đọc cùng revision/hash	TODO	BLOCKER	—	Câu mới; liên quan SRC-004/005.
SRC-007	Nếu Agent Data KB và checkout lệch nhau thì nguồn nào thắng?	phải có quy tắc thắng khi lệch	quy tắc authority KB vs checkout	Xác định nguồn thắng khi lệch	TODO	REQUIRED	—	Câu mới; liên quan CONS-004.
SRC-008	Trước mọi survey/prompt tiếp theo, có cần source-sync preflight không?	tránh khảo sát trên bản cũ	kế hoạch preflight (chưa có)	Xác định có/không cần source-sync preflight	TODO	REQUIRED	—	Câu mới; chỉ đề xuất.
SRC-009	Config như `required-stamps.v0.1.json` được delivery từ KB vào runtime như thế nào?	config phải tới runtime đúng bản	đường delivery config KB → runtime	Xác định cơ chế delivery config vào runtime	TODO	REQUIRED	—	Câu mới; liên quan RISK-RUN-005/006.
SRC-010	Nếu config delivery lỗi/stale thì checker/promote phải fail-closed thế nào?	config stale = verdict đúng-logic nhưng sai-thực-tế	promote-checker spec + đường load config	Xác định checker/promote fail-closed khi config lỗi/stale	TODO	BLOCKER (nếu checker/promote dùng config runtime)	—	Câu mới; liên quan RISK-RUN-005.

Acceptance Criteria (Nhóm S): đủ khi có manifest/source map rõ — file nào; location nào; revision/hash nào; ai đọc nguồn nào; cách sync/export; stale/mismatch thì fail thế nào. Không tạo manifest file trong task này — chỉ đặt câu hỏi. Gate Impact: SRC-001..006 = BLOCKER trước survey/gap report; SRC-007..009 = REQUIRED; SRC-010 = BLOCKER nếu checker/promote dùng config runtime. Anti-bloat (source map/manifest): Source map / manifest có thể là inline evidence record trong report/survey; không mặc định tạo file/hệ thống manifest mới trừ khi Owner duyệt. SRC-005 hỏi có/không manifest đủ field — không phải yêu cầu tạo một hệ thống manifest mới.

Owner Decision Checkpoints

Codex HOLD fix #3 — explicit Owner decision checkpoints. ANSWERED + Mức 3 là trạng thái bằng chứng, KHÔNG phải quyền tự động chuyển pha. Mỗi pha chuyển trạng thái cần Owner duyệt tương ứng. Mặc định Answer Status = TODO, Mức = —.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
OWNER-001	Owner cần duyệt pilot slice nào trước khi survey theo slice?	survey không có slice được duyệt = khảo sát tràn lan	quyết định Owner chọn pilot slice	Có Owner decision record chọn pilot slice	TODO	BLOCKER	—	Câu mới (Codex HOLD #3); liên quan §2e.
OWNER-002	Owner cần duyệt danh sách BLOCKER áp dụng cho pilot slice không?	BLOCKER toàn hệ ≠ BLOCKER của slice	danh sách BLOCKER theo slice	Có Owner duyệt tập BLOCKER cho slice	TODO	BLOCKER	—	Câu mới; liên quan Dependency Map.
OWNER-003	Owner cần duyệt các câu DEFER để không làm phình v0.1 không?	tránh kéo câu ngoài slice vào v0.1	danh sách DEFER đề xuất	Có Owner duyệt tập DEFER	TODO	REQUIRED	—	Câu mới; anti-bloat.
OWNER-004	Owner cần duyệt khi nào mới chuyển từ Question Catalog sang gap report?	chuyển pha cần mốc Owner	mốc chuyển pha catalog → gap report	Có Owner decision record cho chuyển pha này	TODO	BLOCKER	—	Câu mới; liên quan §19.
OWNER-005	Owner cần duyệt mọi exception tạo mới (registry/table/ledger/workflow/DOT/index/worker) không?	tạo mới không Owner duyệt = phình hệ	đề xuất tạo mới + lý do reuse không đủ	Có Owner exception record cho mỗi tạo mới	TODO	BLOCKER	—	Câu mới; liên quan REUSE-006 + §2c.
OWNER-006	Owner cần duyệt khi nào mới cho checker design/selftest?	checker design là pha riêng cần duyệt	mốc cho phép checker design/selftest	Có Owner decision record trước checker design/selftest	TODO	BLOCKER	—	Câu mới; liên quan L5.
OWNER-007	Owner cần duyệt khi nào mới cho atomic promote rehearsal?	rehearsal chạm trạng thái nguy hiểm	mốc cho phép atomic promote rehearsal	Có Owner decision record trước rehearsal	TODO	BLOCKER	—	Câu mới; liên quan L6 + R8.
OWNER-008	Owner cần duyệt khi nào mới cho pilot?	pilot là pha cuối, rủi ro cao nhất	mốc cho phép pilot	Có Owner decision record trước pilot	TODO	BLOCKER	—	Câu mới; liên quan L8 + R7.

Gate Impact: OWNER-001 / -002 / -004 = BLOCKER trước survey/gap report; OWNER-005 = BLOCKER trước mọi tạo mới; OWNER-006 = BLOCKER trước checker design/selftest; OWNER-007 = BLOCKER trước atomic promote rehearsal; OWNER-008 = BLOCKER trước pilot; OWNER-003 = REQUIRED. Codex APPROVED / PASS ≠ quyền chuyển pha: Codex APPROVED / PASS chỉ xác nhận chất lượng câu hỏi hoặc chất lượng câu trả lời theo phạm vi audit; nó không thay thế Owner Decision Checkpoint và không tự động cho phép chuyển phase. Owner duyệt theo batch/slice: Một Owner decision có thể duyệt theo batch/slice để tránh approval ceremony quá nặng, nhưng phải ghi rõ phạm vi được duyệt.

Cross-draft Consistency Gates

Codex HOLD fix #5 — cross-draft contradictions phải được chốt trước survey kỹ thuật. Khi các nguồn (Quick Rules / Addendum / de-bai / Constitution) mâu thuẫn, phải có thứ tự authority rõ. Mặc định Answer Status = TODO, Mức = —.

ID	Câu hỏi	Vì sao cần hỏi	Bằng chứng cần đọc	Acceptance Criteria	Answer Status	Gate Impact	Mức thỏa mãn	Old Survey Coverage / Ghi chú
CONS-001	Pre-promote stamps lưu ở staging metadata hay *`inspect_` birth_registry**? Nguồn nào thắng?	Quick Rules S3 (inspect_* trên birth_registry) mâu thuẫn Addendum §2b/required-stamps (staging metadata)	Quick Rules S3 + Addendum §2b + required-stamps.v0.1.json	Chốt nơi lưu pre-promote stamp + nguồn thắng	TODO	BLOCKER	—	Câu mới (Codex); BLOCKER trước survey stamp.
CONS-002	IO Contract v0.1 giữ 5 field hay gồm DOT/evidence/owner? Nguồn nào thắng?	de-bai §III.6 (5 field tối thiểu) mâu thuẫn Quick Rules rule 17 / plan schema (thêm DOT/check/owner)	de-bai §III.6 + Quick Rules rule 17 + implementation-plan schema	Chốt biên IO Contract v0.1 + nguồn thắng	TODO	BLOCKER	—	Câu mới (Codex); BLOCKER trước survey IO.
CONS-003	Mô hình cấu tạo hiện dùng 6 tầng hay 7 composition levels? Nguồn nào thắng?	drafts 6 tầng mâu thuẫn skill/constitution 7 composition levels	drafts (6 tầng) + skill/constitution (7 levels)	Chốt mô hình tầng + nguồn thắng	TODO	BLOCKER	—	Câu mới (Codex); BLOCKER trước survey cell.
CONS-004	Nếu Quick Rules, Addendum, de-bai, Constitution mâu thuẫn thì thứ tự authority là gì?	không có thứ tự authority = mỗi survey chọn nguồn khác	4 nguồn + bất kỳ rule authority hiện có	Chốt thứ tự authority giữa 4 nguồn	TODO	BLOCKER	—	Câu mới; BLOCKER trước Owner approval/survey.
CONS-005	Có cần Owner decision để freeze các invariant này trước survey slice không?	invariant chưa freeze = survey chạy trên nền lỏng	quyết định Owner freeze invariant	Có Owner decision freeze invariant trước survey slice	TODO	BLOCKER	—	Câu mới; liên quan Owner Decision Checkpoints.

Gate Impact: CONS-001..003 = BLOCKER trước survey kỹ thuật liên quan stamp/IO/cell; CONS-004..005 = BLOCKER trước Owner approval / survey.

17. Additional Questions Found

Câu hỏi Agent phát hiện thêm (AQ1–AQ13). Đưa vào vòng khảo sát sau.

ID	Câu hỏi bổ sung	Vì sao quan trọng	Cần đọc gì để trả lời	Ảnh hưởng tới checker/pilot?
AQ1	`content_hash` bao trùm stamps? (RESOLVED)	packet_hash cần option (a)/(b)	đã dump `fn_iu_staging_create`	đã đóng
AQ2	Ai gọi `fn_iu_staging_cleanup` (không pg_cron)?	TTL fail-safe chạy thật?	host cron/Directus flow/worker	CÓ — pilot "sai thì xóa" (STG-012/SCAN-007)
AQ3	2 namespace species code hợp nhất thế nào?	CELL_STAMP lệch	`entity_species` mapping	CÓ — CELL-004
AQ4	Object đa-domain xử lý ra sao?	cell_id.domain đơn trị	Đ37 jurisdiction	pilot atom: thấp (CELL-014)
AQ5	A–E blast-radius map sang risk_level/doc_level?	Mức 2↔3 routing	apr_action_types+nrm_approval_rules	CÓ — GOV-016/017
AQ6	`staging.record_*` event types emit khi nào?	audit register-before-emit	event_outbox sample	CÓ — AP-010
AQ7	`governance_candidate_state` (0 row) nên dùng hay bỏ?	tránh subsystem chết	SB-10 design	sau v0.1 (REG-S10)
AQ8	IO contract files web-test inventory?	khuôn IO Contract	repo web-test filesystem	IO-001
AQ9	`birth_registry` cần cột inspect_* hay jsonb_profile?	nơi đóng post-stamp	Đ0-G ALTER policy	AP-008/STAMP-007
AQ10	`meta_catalog.layer` vs `composition_level` — danh mục 6 tầng chuẩn?	nguồn Tầng	Đ36/layer-catalog	CELL-003/007
AQ11	`fn_iu_staging_create` body chi tiết (idempotency_key + part validation)?	packet_hash option (a) khả thi	dump fn đầy đủ	STG-015
AQ12	Số trigger birth chính xác + phân loại legacy vs DOT-119?	blast-radius nếu đổi birth	live trigger inventory	BIRTH-005
AQ13	`required-stamps.v0.1.json` khớp substrate live chưa?	config-driven stamps phải khớp metadata-key	required-stamps + `[GR §8]`	STAMP-014/STAMP-GOV-010

18. Đối chiếu với khảo sát đã có

⚠️ CẢNH BÁO: Old survey coverage is provisional.

Không câu nào được nâng APPROVED chỉ vì [GR] đã trả lời.

Các câu có Old Survey Coverage vẫn phải qua Owner/Codex nếu Gate Impact = BLOCKER hoặc REQUIRED.

Cột Old Survey Coverage chỉ là tóm tắt sơ bộ một lượt khảo sát read-only — không thay thế việc trả lời từng dòng ở vòng sau. Mức tối đa từ [GR] = 3.

Nhóm	Tổng câu hỏi	ANSWERED (≥3, khách quan)	PARTIAL	CONFLICT	TODO	BLOCKER (Gate Impact)	Ghi chú
A — Birth	17	7	10	0	0	2	BIRTH-013/014 (birth fold)
B — Governance	20	9	9	0	2	2	GOV-016/017 (blast-radius)
C — Registries	10 (+12 sổ)	3	7	0	0	0	gov_candidate_state design-only
D — Staging	20	13	5	0	2	2	STG-012 scheduler, STG-015 packet_hash
E — Collection	25 (+6 tầng)	9	11	0	5	0	per-tầng source/target chưa rõ (COL-018/020)
F — Matrix Cell	15	6	6	1	2	3	CELL-003/004/007
G — Formula	23	5	11	0	7	0	phần lớn DEFER
H — IO Contract	21	2	13	0	6	0	net-new KB object; web-test UNKNOWN
I — Stamp Lifecycle	14 (+9 ref)	0	14	0	0	2	STAMP-006/007
I-b — Stamp Governance	10	0	0	0	10	3	STAMP-GOV mới — chưa khảo sát
J — DOT	12 cross + 14 ref	2	10	0	0	1	DOT-Q07 mutate prod
J-b — DOT Capability	10	0	4	0	6	4	DOT-CAP mới — chủ yếu chưa khảo sát
K — Atomic Promote	27	7	11	0	9	11	HOLD-2 lane
L — Scanner	15	3	7	0	5	0	read-only, sau checker
M — Pilot	21	1	15	0	5	1	PILOT-018 forbidden surfaces
N — Order	10	0	9	0	0	0	trình tự rõ; chờ Owner duyệt
R — Operational Risk Gates	56	0	0	0	56	27	R1–R5 (32) + R6 RISK-RUN / R7 RISK-BYPASS / R8 RISK-CRASH / R9 RISK-CAP+TIME (+24 câu, +11 BLOCKER) — runtime liveness/config, bypass/write, crash/retry/outbox, retention/backpressure/time (mới — chưa khảo sát)
S — Source / Revision / Delivery	10	0	0	0	10	7	SRC mới (Codex HOLD #1) — nguồn/revision/hash; BLOCKER trước survey/gap report
S-b — Owner Decision Checkpoints	8	0	0	0	8	7	OWNER mới (Codex HOLD #3) — `ANSWERED+Mức3` ≠ quyền chuyển pha
S-c — Cross-draft Consistency	5	0	0	0	5	5	CONS mới (Codex) — stamp store / IO 5-field / 6-vs-7 levels / authority order
TỔNG	~365	~67	~152	1	~138	~77	+ AQ1–AQ13; +Nhóm R R1–R9 (56 câu, +27 BLOCKER) +Nhóm S (10) +Owner Checkpoints (8) +Cross-draft (5) = +47 câu / +30 BLOCKER mới (đều TODO) sau Codex HOLD 2026-06-15

Đối chiếu nhanh với [GR]:

Đã có câu trả lời sơ bộ (bằng chứng): nhóm A/B/C/D + cấu trúc cell/stamp/DOT/atomic-promote (schema DB khách quan).
Trả lời chưa thỏa mãn (cần Owner/Codex để lên 4): mọi quyết định giấy — packet_hash, metadata-key 5 stamp, vocabulary mapping, risk→3-Mức, 12c, nơi đóng PROMOTE_STAMP.
[GR] chưa chạm tới: toàn bộ STAMP-GOV-001..010 và DOT-CAP (governance declaration + capability contract), per-tầng source/target collection (COL-018/020/023/024), atomic-promote vận hành (AP-021..027), pilot định lượng (PILOT-017..021), scanner vận hành (SCAN-011..015), formula version/owner (FORMULA-017..023), và toàn bộ Nhóm R — Operational Risk Gates (lock/transaction, JSONB/index, stale verdict/config drift, cleanup blob_ref/external artifacts, UNKNOWN/PENDING cell context). Bổ sung sau Codex HOLD 2026-06-15 — chưa chạm tới: source authority / revision / hash (Nhóm S — SRC), Owner checkpoint trước mỗi phase transition (Owner Decision Checkpoints), runtime liveness / config delivery (R6 — RISK-RUN), bypass / write permission (R7 — RISK-BYPASS), crash / retry / outbox consistency (R8 — RISK-CRASH), retention / backpressure / time source (R9 — RISK-CAP/TIME), cross-draft consistency (CONS — stamp store / IO 5-field / 6-vs-7 levels / authority order).

Đối chiếu reuse-first với [GR] (chưa trả lời — chỉ là ghi chú cho vòng sau, theo đề bài rev33):

Vòng khảo sát sau phải đánh giá lại [GR] qua 4 lăng kính reuse-first. Đây là câu hỏi đối chiếu, không phải kết luận; điền vào khi đối chiếu từng dòng.

RUS-MAP-1 — Báo cáo cũ đã trả lời reuse được đến đâu? [GR] mạnh ở substrate hiện trạng (A/B/C/D — schema/count khách quan) nhưng chưa khung hóa theo reuse-first/minimal-fastest; cần map lại từng kết luận sang "dùng lại nguyên trạng / chỉnh metadata / wrapper / viết mới". Status: TODO.
RUS-MAP-2 — Có câu nào [GR] kết luận "cần làm mới" quá sớm không? Rà các chỗ đề xuất DOT mới / cột mới / collection mới xem có thể thay bằng reuse (vd A–E → risk_level, dot_role qua extra_metadata, packet qua view). Status: TODO.
RUS-MAP-3 — Có chỗ nào có thể reuse nhiều hơn không? Đối chiếu với Nhóm 0 + các khối *-REUSE: metadata/jsonb/staging payload, wrapper trên cut fn, IO Contract 5 field, scanner thay auto-fix. Status: TODO.
RUS-MAP-4 — Có chỗ nào substrate đã đủ nhưng vẫn bị coi là blocker không? Soát các BLOCKER (STG-012, STG-015, CELL-003/004, AP birth-fold…) xem cái nào thực ra chỉ cần xác minh/chốt giấy trên substrate hiện có chứ không cần xây mới. Status: TODO.

19. Kết luận (bắt buộc)

Sau bản chỉnh này, Owner sẽ duyệt Question Catalog — rà đủ nhóm, đủ câu, đủ ID; xác nhận Gate Impact (câu nào thực sự BLOCKER); xác nhận Acceptance Criteria; duyệt Dependency Map.
Sau khi Owner duyệt slice + blocker set, Agent mới đối chiếu câu hỏi từng dòng cho selected pilot slice + direct dependencies (vòng sau) để tạo gap reports — theo thứ tự Dependency Map (L0→L8, bao gồm L5b Operational Risk Gates) trong phạm vi slice; các câu ngoài slice giữ TODO/DEFER.
Codex chỉ nên được gọi để audit chất lượng Question Catalog + Dependency Map, KHÔNG yêu cầu Codex trả lời toàn bộ ngay.
Ràng buộc cứng: mọi câu Gate Impact = BLOCKER áp dụng cho selected pilot slice + direct dependencies + cross-cutting gates phải đạt Answer Status ≥ ANSWERED & Mức ≥ 3 trước khi đi tiếp checker/rehearsal/pilot; các câu BLOCKER ngoài slice giữ TODO/DEFER và không chặn slice. Không câu nào lên APPROVED nếu chưa qua Owner/Codex. Báo cáo khảo sát cũ chỉ là Old Survey Coverage — provisional.
Sau khi Owner duyệt Question Catalog + pilot slice, vòng khảo sát tiếp theo phải trả lời theo nguyên tắc reuse-first / minimal-fastest — bắt đầu từ Nhóm 0 (Reuse Baseline / L0) trong phạm vi pilot slice, rồi tới các nhóm A–N thuộc slice + direct dependencies theo Dependency Map; không ép trả lời Nhóm 0 rồi A–N toàn hệ trước lát thử.
Mỗi đề xuất tạo mới (registry/table/ledger/workflow/DOT/collection) phải có bằng chứng rằng reuse không đủ (REUSE-006 + Decision Rule §2c). Không có bằng chứng = không được tạo.
Cách đúng cho v0.1 là cách nhẹ nhất, nhanh nhất, chạy được trong kho tạm, xóa được nếu sai, promote được nếu đúng — không xây "monster system", không thêm registry/ledger/workflow không cần thiết.
Các câu Operational Risk Gates (Nhóm R) có Gate Impact = BLOCKER áp dụng cho selected pilot slice + direct dependencies phải được trả lời trước Codex CP cuối / atomic promote rehearsal / pilot. Reuse-first không được hiểu là bỏ qua hiệu suất, lock, index, stale verdict, cleanup rác vật lý hoặc context UNKNOWN/PENDING.

Bổ sung sau Codex HOLD 2026-06-15 (năm điểm chốt phạm vi/nguồn/Owner/vận hành):

Catalog dùng theo pilot slice, không phải checklist toàn hệ (§2e Pilot Slice First). ~365 câu là bản đồ rủi ro; vòng sau chọn một lát thử hẹp và chỉ áp blocker cho lát đó + dependency trực tiếp, không ép trả lời toàn bộ trước khi làm.
L0 / L5b áp dụng theo pilot slice + direct dependencies, không chặn khảo sát read-only ngoài slice; không biến reuse baseline / risk gate thành khảo sát toàn hệ.
Source / revision / hash gate (Nhóm S) phải đạt trước survey / gap report — Agent Data KB ↔ checkout ↔ runtime/config phải cùng một bản; đọc lệch nguồn = drift kiến trúc. Đây là rủi ro triển khai nghiêm trọng nhất theo Codex (file laws-new có trong KB nhưng vắng trong checkout).
Owner checkpoint bắt buộc trước mọi phase transition (Owner Decision Checkpoints). ANSWERED + Mức 3 là trạng thái bằng chứng, KHÔNG phải quyền tự động chuyển pha; chọn pilot slice / exception tạo mới / checker design-selftest / atomic promote rehearsal / pilot đều cần Owner decision record tương ứng.
Operational readiness cần bằng chứng runtime / config / bypass / crash / liveness, không chỉ logic đúng (Nhóm R + R6–R9). Một verdict "đúng logic" trên config stale, runtime chết, hoặc bypass path chưa kiểm soát vẫn không an toàn.
Cross-draft contradictions phải được chốt trước survey kỹ thuật (CONS): nơi lưu pre-promote stamp (staging metadata vs inspect_*), biên IO Contract (5-field vs DOT/evidence/owner), mô hình tầng (6 vs 7 composition levels), và thứ tự authority giữa Quick Rules / Addendum / de-bai / Constitution.

Tài liệu này là bộ câu hỏi kiểm soát phạm vi, không phải roadmap, không phải báo cáo khảo sát. Trả lời đúng/đủ (đạt Acceptance Criteria) làm ở vòng sau — theo hướng reuse-first / minimal-fastest.

DRAFT — read-only authoring. Không enact, không production, không tạo bảng/registry/collection/DOT mới, không sửa knowledge/dev/laws/, không viết checker, không mở pilot.