KB-1651 rev 25
Danh mục câu hỏi trước khi tái cấu trúc Matrix/Stamp (Question Catalog)
102 min read Revision 25
laws-newmatrix-assemblystamp-governancequestion-catalogchecklistscope-controlacceptance-criteriadependency-mapdraftnot-roadmappre-refactor2026-06-15
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). 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 phải cập nhật Answer Status + Mức thỏa mãn từng câu hỏi (không bỏ trống), gắn bằng chứng.
- 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 thiết kế checker/pilot nếu mọi câu Gate Impact = BLOCKER 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 làm sau khi Owner duyệt.
- 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)
| 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ú |
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
*-REUSEcủ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.
| 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 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 per-nhóm |
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) | Chặn TẤT CẢ (L1–L8): không được thiết kế mới / đề xuất tạo mới khi chưa trả lời reuse baseline |
| L1. Substrate hiện trạng | C (Registries) · D (Staging) · A (Birth) | Mọi tọa độ/dấu/máy đều ngồi trên các sổ + kho tạm + khai sinh đang có thật | Chặn TẤT CẢ các lớp trên (L2–L8): không biết substrate thì không thiết kế được cell/stamp/DOT |
| 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 chỉ khép kín khi có governance declaration (ai đóng, evidence, version, revoke) | 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) |
| 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 | L (Scanner) | read-only, liệt kê thiếu dấu — phụ trợ, làm sau cổng/promote | Không chặn cứng; nhưng pilot nên có scanner để quan sát |
| 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), L6 (AP birth-fold + rehearsal).
Quy tắc reuse-first cho Dependency Map (bám đề bài rev33):
- L0 đứng trước tất cả. Không được thiết kế mới (cell/stamp/DOT/collection/formula/atomic-promote) khi chưa trả lời xong Reuse Baseline của lớp đó.
- 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.
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 §IV.1–IV.2, §IV.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 §IV.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 §IV; 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 §IV.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 §IV.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, §IV.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, §IV.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 §IV.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, §IV.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 §IV.14–IV.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 §IV.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 §IV.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 §IV.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 §IV.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
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 §IV.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 §IV.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, livedot_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
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, livefn_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 §IV.6, §IV.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 §IV.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 §IV.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 §IV.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 §IV.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 §IV.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 §V. (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 |
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 |
| TỔNG | ~286 | ~67 | ~152 | 1 | ~59 | ~31 | + AQ1–AQ13 |
Đố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).
Đố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, Agent mới đối chiếu câu hỏi từng dòng (vòng sau) để tạo gap reports — theo đúng thứ tự Dependency Map (L1→L8).
- 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 phải đạt Answer Status ≥ ANSWERED & Mức ≥ 3 trước khi đi tiếp checker/pilot. 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, 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), rồi mới tới các nhóm A–N theo Dependency Map.
- 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.
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.