F0 Source / Authority / Evidence Program Package (read-only execution plan, non-authorizing)
F0 Source / Authority / Evidence Program Package
Ngày: 2026-06-16 · Soạn: Claude Code CLI (read-only AgentData KB) · Track: knowledge/dev/laws-new/
Control basis: technical-slice-framework.md rev56 — Codex verdict PASS_WITH_COSMETIC_NOTES (relayed by GPT/Owner), accepted as final control basis.
Layer: F0 — Source / Authority / Evidence (deepest layer of the §6c build/dependency order; domain D1; gated by CONS-004 authority-order UNKNOWN).
1. Status / Boundary / Non-authorization banner
Status: DRAFT — READ-ONLY PROGRAM PACKAGE FOR F0. Tự thân nó KHÔNG ủy quyền bất cứ điều gì. This document prepares an F0 read-only execution program so that — after a separate GPT/Owner authorization — an agent can run F0 source/authority/evidence work without re-asking the basic questions. It is not the execution itself.
Tài liệu này KHÔNG phải, và KHÔNG cho phép:
- Not F0 execution — không chạy F0; chỉ thiết kế chương trình F0 read-only.
- Not Phase-1 survey — không khảo sát substrate sống (
iu_staging_*, HOLD-1) — đó là pha sau, Owner-gated. - Not a live DB / runtime query — không truy vấn DB sống / production / runtime config.
- Not a source manifest system — không dựng hệ thống manifest nguồn; chỉ inline evidence trong report.
- Not implementation / design — không sinh mã, migration, DDL, DML; không thiết kế chi tiết.
- Not schema/registry/table/DOT/index/checker/scanner change — không tạo/sửa bất kỳ thứ nào trong số này.
- Not pilot selection / slice design — không chọn lát thử, không thiết kế lát.
- Not an authority-order resolution — KHÔNG tự chốt thứ tự authority KB-vs-checkout-vs-runtime (đó là CONS-004, Owner-only).
- Not Owner authorization — Engineering PASS (kể cả Codex PASS sau này) ≠ Authority PASS. Chỉ Owner mở pha.
- Not production mutation — không chạm production / DB / CI / secrets /
knowledge/dev/laws/.
Mutation phạm vi (tài liệu này): chỉ đúng một KB document — f0-source-authority-evidence-program-package.md — được tạo/cập nhật; read-only trên mọi nguồn khác; không DB/production/CI/secrets/laws/.
1.1 rev56 controls preserved (verbatim obligations carried into F0)
The following rev56 controls are carried forward unchanged and bind every F0 step:
| rev56 control | Carried into F0 as |
|---|---|
| No implementation | F0 execution writes no code/migration/DDL/DML; output is an evidence report only (§11, §16). |
| No Phase-1 survey yet | F0 ≠ Phase-1. F0 touches KB + checkout existence, never live substrate; iu_staging_* / HOLD-1 stays downstream (§9, §14). |
| No live DB query unless Owner later authorizes | Runtime/DB authority leg stays UNKNOWN/DOCUMENTARY_ONLY → obligation; F0 does not read runtime/DB (§6, §9, §14). |
| No source manifest system by default | Source/authority evidence is inline in the F0 report; any manifest file/system is Owner-gated Mức 3 (§8, §10, §15). |
| No schema/registry/table/DOT/checker/scanner/pilot | F0 creates none of these; STOP-before-schema-change inherited (§10, §14). |
| Engineering PASS ≠ Owner authorization | F0 PASS = report quality only; phase transition is Owner-only (§12, §17). |
1.2 Owner View — F0 trả lời 3 câu hỏi reuse-first
Đây là bề mặt điều khiển (control surface) cho Owner/GPT. Toàn bộ phần còn lại của package (§2–§18) là chiều sâu kỹ thuật Agent/Codex đứng sau 3 câu hỏi này. Owner View = control surface; các mục kỹ thuật (§2–§18) = evidence machinery. Owner có thể đọc riêng §1.2 để hiểu F0 làm gì / không làm gì mà không cần đọc các mục sâu.
F0 quy về 3 câu hỏi reuse-first:
- Q1 — Hiện tại đang có gì có thể sử dụng lại được? (reuse now)
- Q2 — Có gì cần sửa chữa / kiểm chứng mới sử dụng lại được? (repair / verify before reuse)
- Q3 — Cần làm thêm những gì nữa? (add later — chỉ khi reuse không đủ)
Ranh giới giữ nguyên (non-authorization): §1.2 KHÔNG ủy quyền bất cứ điều gì. Reuse-now không có nghĩa "đã chứng minh live". Add-new chỉ là future Owner-gated, không phải cho phép tạo mới. Mọi phân loại tôn trọng §1 / §1.1 / §10 / §12 (non-authorization · rev56 controls · forbidden · completion contract). Documentary ≠ live proof · Prior-session ≠ current proof · Engineering PASS ≠ Authority PASS.
Q1 — Đang có gì có thể sử dụng lại được? (reuse now)
| # | Thứ có thể reuse | Reuse cho F0 thế nào | Mức độ tin (honest) | Deep ref |
|---|---|---|---|---|
| 1 | AgentData KB = nơi giữ nguồn thực tế hiện tại cho track laws-new |
Là bề mặt đọc read-only của F0 (pin rev/length/hash) | Reusable cho F0 planning/execution; KB-only, chưa phải live/runtime-proven | §2, §6.1, §9 |
| 2 | Các governed document + revision đang có: constitution rev44 · operating-rules rev51 · technical-slice-framework rev56 · de-bai rev33 · question catalog rev82 · required-stamps rev6 · checker spec rev11 · addendum rev14 · quick-rules rev8 · implementation plan rev5 · roadmap rev1 | Nguồn bắt buộc F0 pin làm freeze-CANDIDATE | Reusable; rev là EXPECTED (quan sát lúc soạn), F0 phải re-confirm current-pass trước khi PROVEN | §2, §8 |
| 3 | Cách tiếp cận inline evidence (bằng chứng nằm ngay trong report) | F0 tái dùng nguyên, không dựng manifest | Reusable by-design (SRC-005 = NO manifest) | §8, §10 |
| 4 | Bộ từ vựng evidence: PROVEN / DOCUMENTARY_ONLY / UNKNOWN / CONFLICT / BLOCKED / DEFER / PRIOR_SESSION_EVIDENCED | F0 dùng lại nguyên văn, không thêm từ mới | Reusable nguyên văn (framework §17) | §5, §7 |
| 5 | Mẫu freeze-candidate: path + revision + content_length + sha256 + checkout presence + currency + status | F0 điền inline cho mỗi nguồn | Reusable as template (chưa phải baseline đã freeze) | §8, §13 |
| 6 | Completion contract / stop conditions / adversarial checks đã có trong chính package này | F0 execution chạy theo + tự kiểm | Reusable nguyên | §12, §14, §15 |
Đánh dấu trung thực: mọi mục Q1 là reusable cho việc lập kế hoạch / thực thi F0, KHÔNG đương nhiên là live / runtime-proven. Đọc một KB revision chỉ chứng minh KB revision đó — không chứng minh checkout hay runtime (§7).
Q2 — Có gì cần sửa chữa / kiểm chứng mới sử dụng lại được? (repair / verify before reuse)
| # | Cái đang có | Sai / không chắc ở đâu | Phải verify / repair gì | Chặn chấp nhận package F0? | Chặn thực thi F0 / pha sau? | Deep ref |
|---|---|---|---|---|---|---|
| 1 | Thứ tự authority KB vs checkout vs runtime | Chưa có order ban hành | Owner ratify order | Không | Có — CONS-004 OWNER_DECISION_REQUIRED |
§4 A7/A11, §6 |
| 2 | Baseline freeze | F0 chỉ được đề xuất candidate, không freeze | Owner freeze | Không | Có — CONS-005 Owner-only | §8, §17 |
| 3 | Codex review artifact của rev56 | Hiện là Owner-relay / PRIOR_SESSION_EVIDENCED; chưa thấy file KB riêng |
F0 phải định vị artifact hoặc xác nhận Owner relay là bản ghi chính thức | Không | Có (currency obligation) | §2 R2, §13 |
| 4 | Catalog rev82 vs header self-label rev3/rev4 | Lệch cosmetic | Ghi nhận CONFLICT, không chặn |
Không | Không (cosmetic) | §2 S5, §5, §8 |
| 5 | Checkout absence | Là prior-session / phụ thuộc môi trường | F0 execution re-check current-pass per environment, không generalize | Không | Có (per-env) | §6.1, §11 Step 2, §15 #3 |
| 6 | required-stamps KB→runtime delivery | UNKNOWN |
Runtime read ngoài F0, Owner-gated về sau | Không | Có (downstream/runtime) | §4 A9/A10, §9 |
| 7 | Phân biệt current-pass vs prior-session | Dễ nhầm prior-session thành proof | Phải verify current-pass trước khi mark PROVEN |
Không | Có | §5, §7, §15 #1 |
Mỗi mục Q2 trả lời đủ: cái gì đang có · sai/không chắc ở đâu · phải verify/repair gì · có chặn chấp nhận package không · có chặn thực thi F0/pha sau không. Conflict luôn được phân loại ở đây (repair/verify-before-reuse), không ép vào Q1.
Q3 — Cần làm thêm những gì nữa? (add later — chỉ khi reuse không đủ)
| # | Cần làm thêm | Trạng thái trong package này |
|---|---|---|
| 1 | Báo cáo F0 read-only execution (về sau) | Not done here · not authorized here · future Owner-gated |
| 2 | Owner quyết định CONS-004 (authority order) | Not done · not authorized · Owner-only |
| 3 | Owner quyết định CONS-005 (freeze baseline) | Not done · not authorized · Owner-only |
| 4 | Kiểm tra runtime config delivery (nếu chạm checker / runtime config) | Not done · not authorized · future Owner-gated runtime read |
| 5 | Phase-1 substrate survey cho HOLD-1 / iu_staging_* |
Not done · not authorized · future Owner-gated |
| 6 | Package F1 / F2 sau khi có quyết định F0 | Not done · not authorized · future Owner-gated |
| 7 | Hệ thống source manifest | KHÔNG làm — trừ khi tương lai Owner ra exception chứng minh inline evidence không đủ |
Mọi mục Q3: không thực hiện trong package này · không được package này ủy quyền · chỉ future Owner-gated. Một mục "add-new" không bao giờ tự biến thành authorization (§10, §15 #5). Nếu một thứ không thể xếp là reusable-now thì để ở Q2 hoặc Q3 — không ép vào Q1.
1.2.1 Owner View self-check (surface ↔ depth)
| Owner question | Answered at surface level? | Linked to deep sections? |
|---|---|---|
| Q1 — reuse now | Yes (bảng Q1) | Yes — §2, §5, §7, §8, §9, §13 |
| Q2 — repair / verify before reuse | Yes (bảng Q2) | Yes — §4, §6, §8, §9, §17 |
| Q3 — add later only-if-needed | Yes (bảng Q3) | Yes — §3, §10, §14, §17 |
2. Mandatory source list and expected revisions
These are the sources F0 must pin. Revisions below were observed during package authoring (2026-06-16); for F0 execution they are EXPECTED values that F0 must re-confirm current-pass and freeze-as-candidate (§7, §8). This list is inline evidence, not a manifest system.
| # | Source path | Expected rev (KB index) | Note / authority class |
|---|---|---|---|
| S1 | knowledge/dev/laws/constitution.md |
44 (v4.6.3 BAN HÀNH) | Enacted constitution — READ-ONLY, never patch. Holds NT14. |
| S2 | knowledge/dev/ssot/operating-rules.md |
51 (doc version v7.58) | Enacted SSOT operating rules — READ-ONLY. |
| S3 | knowledge/dev/laws-new/technical-slice-framework.md |
56 | Control basis (Codex PASS_WITH_COSMETIC_NOTES). |
| S4 | knowledge/dev/laws-new/de-bai-cai-tien.md |
33 | Problem-statement (governance = relationship completion). |
| S5 | knowledge/dev/laws-new/cau-hoi-khi-tai-cau-truc.md |
82 (header self-label rev3/rev4 — cosmetic discrepancy per Codex) | Question Catalog; holds Nhóm S (SRC-) + CONS-. |
| S6 | knowledge/dev/laws-new/required-stamps.v0.1.json |
6 | Config-as-metadata; KB→runtime delivery UNKNOWN (SRC-009/010). |
| S7 | knowledge/dev/laws-new/promote-checker-v0.1-spec.md |
11 | Checker spec (not built; not authorized). |
| S8 | knowledge/dev/laws-new/matrix-stamp-governance-addendum.md |
14 | Stamp governance addendum. |
| S9 | knowledge/dev/laws-new/matrix-refactor-quick-rules.md |
8 | Quick rules. |
| S10 | knowledge/dev/laws-new/matrix-refactor-implementation-plan.md |
5 | Refactor plan. |
| S11 | knowledge/dev/laws-new/roadmap-cai-tien.md |
1 | Detailed technical roadmap (avoid two SoT vs de-bai §VII). |
| R1 | knowledge/dev/laws-new/reports/codex/codex-final-question-catalog-approval-review-2026-06-15.md |
1 | Codex catalog review = PASS_WITH_COSMETIC_NOTES. |
| R2 | Codex review of framework rev56 | PRIOR_SESSION_EVIDENCED | Verdict PASS_WITH_COSMETIC_NOTES relayed by GPT/Owner; no distinct KB report file located at authoring. F0 obligation: locate the rev56 review artifact or confirm Owner relay is the authoritative record. |
Pin baseline echoes framework §3:
constitution rev44 · OR rev51 · de-bai rev33 · catalog rev82 · required-stamps rev6 · checker-spec rev11 · addendum rev14 · quick-rules rev8 · plan rev5 · roadmap rev1(+ framework rev56 itself).
If any S-row cannot be read at F0 time → mark BLOCKED / NOT_FOUND / UNREADABLE, never silently treat as unchanged (§14, §15).
3. F0 scope and non-scope
F0 question (from framework §6c / D1): What sources are authoritative, at which revision, with what evidence currency, and where do KB / checkout / runtime disagree — gathered read-only so the Owner can later freeze a baseline and resolve the authority order (CONS-004)?
3.1 In F0 scope (read-only)
- Pin the current KB revision + content_length + content hash of each mandatory source (§2, §8) — inline.
- Check checkout (working-copy/filesystem) presence/absence of
laws-new/*and the enacted law files — read-only existence checks only (no DB). - Classify the evidence currency of each fact (current-pass / prior-session / documentary) (§7).
- Record the KB ↔ checkout drift observed (e.g., laws-new exists only in KB) as evidence — without resolving the order (§6).
- Identify the runtime/config-delivery question (SRC-009/010 for
required-stamps.v0.1.json) and carry it as an obligation (runtime read is NOT in F0 scope) (§9, §14). - Produce a freeze-CANDIDATE baseline + the exact evidence the Owner needs to decide CONS-004 (authority order) and CONS-005 (freeze decision).
3.2 Out of F0 scope (downstream / forbidden here)
- Any live DB / runtime / production read or write (Phase-1 substrate survey, HOLD-1; runtime config delivery).
- Resolving the KB-vs-checkout-vs-runtime authority order (CONS-004 = Owner decision).
- Freezing the baseline as enacted (CONS-005 = Owner decision; F0 only proposes a candidate).
- Substrate inventory verification (
iu_staging_*,birth_registry, atomic promote — HOLD-1/HOLD-2): these belong to F1/F2+ phases, Owner-gated. - Pilot slice selection / slice design / checker / scanner / schema change.
4. F0 authority questions
These are the planning-level questions F0 read-only execution must answer with evidence or with an explicit obligation (mapped to Question Catalog Nhóm S / CONS):
| Q | F0 authority question | Catalog id | F0 answerable read-only? |
|---|---|---|---|
| A1 | What is the single authoritative source for each active laws-new/* file right now? |
SRC-001 | Partly — KB is de-facto sole holder; order not enacted → CONS-004 obligation. |
| A2 | Do the active laws-new files exist in the local checkout? |
SRC-002 | Yes — read-only filesystem existence check (per-environment). |
| A3 | If only in KB, what is the KB→checkout sync/export process? | SRC-003 | Partly — record whether any sync process is evidenced; gaps → obligation. |
| A4 | What revision/hash is the canonical baseline per file before any survey? | SRC-004 | Yes — record rev + content_length + sha256 inline (§8). |
| A5 | Is there a manifest of file + revision/hash + location? | SRC-005 | Yes, answered NO-BY-DESIGN — inline evidence only; do not create manifest. |
| A6 | Are Codex / Claude / Agent reading the same revision? | SRC-006 | Partly — record the rev each consumer last cited; flag drift. |
| A7 | If KB and checkout disagree, which source wins? | SRC-007 / CONS-004 | No — OWNER_DECISION_REQUIRED. F0 gathers evidence; Owner decides. |
| A8 | Is a source-sync preflight required before any further survey/prompt? | SRC-008 | Yes — F0 is that preflight (read-only). |
| A9 | How is config (required-stamps.v0.1.json) delivered KB→runtime? |
SRC-009 | No (runtime) — obligation. Carry as DOCUMENTARY_ONLY/UNKNOWN; needs Owner-authorized runtime read. |
| A10 | If config delivery is broken/stale, how must checker/promote fail-closed? | SRC-010 | No (downstream) — design obligation for F4; record as BLOCKER-if-checker. |
| A11 | What is the authority order if Quick Rules / Addendum / de-bai / Constitution conflict? | CONS-004 | No — OWNER_DECISION_REQUIRED. |
| A12 | Is an Owner freeze decision needed before survey-of-a-slice? | CONS-005 | Yes, answered YES — Owner must freeze; F0 proposes candidate. |
| A13 | Do stamps/verdicts carry rule_version/config_hash so staleness is detectable? |
RISK-STL-001 | Documentary/design — carry as obligation (source-currency relevance only at F0). |
F0 read-only can answer A2, A4, A5, A8, A12 with current-pass evidence; must carry A1, A7, A9, A10, A11 as Owner-decision / runtime / downstream obligations. No F0 answer authorizes a phase transition.
5. F0 evidence model
F0 reuses the framework's evidence vocabulary unchanged (framework §17). No new vocabulary is introduced.
| Label | Meaning (verbatim-aligned with framework §17) |
|---|---|
PROVEN |
Verified by an action in this F0 execution pass (e.g., KB revision read now; checkout file-existence checked now). |
DOCUMENTARY_ONLY |
KB/prose/[GR] claim only; not verified live. Default for any "live/runtime" assertion. |
UNKNOWN |
Not yet determined. |
CONFLICT |
Sources disagree (e.g., KB index rev82 vs header rev3/rev4; or KB vs checkout). |
BLOCKED |
Cannot read / does not exist / blocked by gate. |
DEFER |
Intentionally postponed to a later phase. |
PRIOR-SESSION-EVIDENCED |
Provenance tag: evidenced in an earlier session/artifact (e.g., framework §1 checkout check; Codex rev56 relay). Must be re-verified current-pass before being treated as PROVEN. |
Hard rules (carried verbatim from framework §17):
- KHÔNG mark
PROVENcho live runtime fact trừ khi đã verify live. F0 does not verify live → no substrate/runtime fact may bePROVENin F0. - KB/prose →
DOCUMENTARY_ONLYonly. - Source says "live" but addendum says HOLD →
CONFLICT/UNKNOWN, khôngPROVEN. - Documentary ≠ live proof. Prior-session ≠ current proof. Engineering PASS ≠ Authority PASS.
6. KB vs checkout vs runtime authority model
F0 does NOT resolve this. It records the evidence; the Owner resolves CONS-004.
6.1 Observed facts (provenance noted; not an enacted order)
laws-new/*exist only in AgentData KB; local checkout absent here (pwd=/Users/nmhuyen, not a git repo, 0 files) and in Codex's repo. → KB is the de-facto sole holder for the laws-new track. (PRIOR-SESSION-EVIDENCED by framework §1 + Codex; F0 must re-confirm current-pass per environment.)- Operating-rules §0.3 (enacted): "VPS = SSOT code/runtime nếu đụng hệ thống đang chạy."
- Operating-rules §0.4 (enacted): "PG/Directus là đường dữ liệu chuẩn."
- Constitution NT10 (enacted): "Text = documentation. PG = truth." · NT13: "PG FIRST · PG NATIVE · PG DRIVEN."
6.2 The conflict (why CONS-004 is real)
The enacted authority statements (VPS=SSOT for runtime/code; PG=truth for machine-enforced data) do not cover governance documents that live only in KB and exist in neither checkout nor runtime. There is no enacted single KB-vs-checkout-vs-runtime order. → CONFLICT / UNKNOWN.
6.3 What F0 may record (candidate framing, NON-BINDING, Owner must ratify)
F0 execution MAY record the following proposal as DOCUMENTARY_ONLY / OWNER_DECISION_REQUIRED — it does not enact it:
Candidate (pending CONS-004): for the
laws-new/*governance track, KB is de-facto authoritative pending Owner ratification; for code/runtime, VPS = SSOT (OR §0.3); for machine-enforced data, PG = truth (NT10/NT13). The cross-class precedence when these overlap remains an Owner decision.
F0 obligation: gather the evidence (what exists where, at which rev, with what drift) that lets the Owner decide CONS-004 — and stop there.
7. Current-pass vs prior-session vs documentary evidence rules
| Currency class | Definition | Allowed status | Rule |
|---|---|---|---|
| Current-pass | Verified by an action in this F0 run (read KB rev now; test -f now). |
may be PROVEN only for what the action checks |
Reading a KB revision proves the KB revision — it does not prove checkout or runtime state. |
| Prior-session | Evidenced in an earlier session/artifact (framework §1; Codex relay). | PRIOR-SESSION-EVIDENCED until re-checked |
Must be re-verified current-pass before becoming PROVEN; otherwise carry as obligation. |
| Documentary | KB/prose/[GR] claim about live/runtime/substrate. |
DOCUMENTARY_ONLY |
Never promote to live proof. A documentary row count or "LIVE/GOVERNED" label is a hypothesis, not evidence. |
This is the exact failure the framework once made and fixed (hostile case "row13"): documentary labels were treated as live proof. F0 must never repeat it.
8. Revision / hash freeze plan
F0 produces a freeze-CANDIDATE (inline, no manifest system). The freeze act is Owner-only (CONS-005).
For each mandatory source (§2), F0 execution records inline in its report:
pathkb_revision(current-pass)content_length(current-pass)content_sha256— sha256 over the exact bytes retrieved this pass (tamper/drift anchor)checkout_present(true/false, per environment, read-only fs check)currency(current-pass / prior-session / documentary)status(PROVEN / CONFLICT / BLOCKED / …)
Rules:
- No manifest file/system is created (SRC-005 answered NO-BY-DESIGN; framework §12.4). The freeze-candidate lives inline in the F0 execution report.
- The freeze-candidate is a proposal for Owner (Owner Decision §14.4). F0 does not declare a frozen/enacted baseline.
- If a source's hash/length cannot be computed (unreadable) →
BLOCKED, not assumed. - Header/index discrepancies (e.g., catalog rev82 vs header rev3/rev4) are recorded as
CONFLICT(non-blocking cosmetic) for Owner awareness.
9. Read-only execution surfaces
The only surfaces F0 execution may touch (all read-only):
| Surface | Operation | Tool class | In scope? |
|---|---|---|---|
| AgentData KB documents (§2) | read content + revision + length; compute hash | KB read (get_document / get_document_for_rewrite) |
Yes |
| Local checkout / filesystem | existence + path checks of laws-new/* and enacted laws (read-only) |
test -f, find, ls (no writes) |
Yes |
| Codex repo / other agents' checkout | record which revision each last cited (from existing artifacts) | read existing artifacts only | Yes (documentary) |
| Live DB / Postgres / Directus | — | — | NO — Owner-gated, Phase-1/runtime |
Runtime config delivery (required-stamps → runtime) |
— | — | NO — runtime read needs Owner authorization (SRC-009/010 obligation) |
Production / CI / secrets / knowledge/dev/laws/ |
— | — | NO — forbidden |
Reading runtime config counts as touching runtime and is therefore out of F0 read-only scope; it is carried as an obligation (A9/A10), not executed.
10. Forbidden actions (F0 execution)
F0 execution MUST NOT:
- run any live DB / runtime / production query or mutation;
- run the Phase-1 substrate survey (
iu_staging_*, HOLD-1) or any substrate verification; - read runtime config delivery without separate Owner authorization;
- create a source manifest file or system;
- create/alter any schema / table / registry / index / DOT / checker / scanner;
- perform any ALTER / ADD COLUMN / metadata change (STOP-before-schema-change, framework §19);
- write code, migrations, DDL, DML;
- select or design a pilot slice;
- resolve the KB-vs-checkout-vs-runtime authority order (CONS-004) — gather evidence only;
- freeze/enact the baseline (CONS-005) — propose a candidate only;
- patch enacted laws under
knowledge/dev/laws/; - claim runtime/source authority is "proven" unless actually verified current-pass in that F0 run;
- treat documentary or prior-session evidence as live/current proof;
- treat any engineering/Codex PASS as Owner authorization.
Allowed: read KB; read-only checkout existence checks; compute inline hashes; write exactly one F0 execution report document (KB) when later authorized.
11. F0 execution plan (read-only only)
This plan runs only after GPT/Owner authorize F0 read-only execution (and Codex review of this package, per §17). It is a plan, not an execution.
Step 0 — Preflight / boundary check. Re-read this package + framework rev56 §0/§19/§20; confirm no forbidden action is implied; confirm Owner authorization token for F0 read-only execution is present. If absent → STOP (§14).
Step 1 — KB pin (current-pass). For each §2 source: read content; record kb_revision, content_length, content_sha256. Mark PROVEN for KB-revision facts only.
Step 2 — Checkout existence (current-pass, read-only). For each laws-new/* and enacted law file: record checkout_present per environment via test -f/find (no DB, no writes). Record the environment id (e.g., /Users/nmhuyen non-repo) so absence is not generalized across environments.
Step 3 — Drift & consistency. Compare KB vs checkout presence; record KB↔checkout drift. Record header-vs-index revision discrepancies as CONFLICT (cosmetic). Record which revision each consumer (Codex/Claude/Agent) last cited (documentary).
Step 4 — Currency classification. Tag every fact current-pass / prior-session / documentary (§7). Re-verify any prior-session fact (e.g., framework §1 checkout check) current-pass before PROVEN.
Step 5 — Authority-order evidence (no resolution). Assemble the CONS-004 evidence bundle (§6): observed facts, the conflict, the non-binding candidate framing. Mark OWNER_DECISION_REQUIRED.
Step 6 — Runtime/config obligations (no runtime read). Record A9/A10 (SRC-009/010) as DOCUMENTARY_ONLY/UNKNOWN obligations for a later Owner-authorized runtime read; do not read runtime.
Step 7 — Freeze-candidate. Emit the inline freeze-candidate baseline (§8) as a proposal for Owner (CONS-004 + CONS-005), plus the F0 evidence table (§13).
Step 8 — Self-check & report. Run §15 adversarial checks + the framework-style final self-check; emit the F0 execution report (§16). Default at every uncertainty: HOLD + record blocker + wait for Owner (OR §8).
No step writes anything except the single F0 execution report; no step touches DB/runtime/production.
12. F0 completion contract (PASS / PARTIAL / BLOCKED / FAIL)
Control layer, self-verifying. This contract governs the F0 execution run, not this package. (This package's own readiness is reported separately to Owner.)
F0 execution = PASS only if all hold:
- Every §2 source pinned current-pass (rev + length + sha256) or explicitly
BLOCKEDwith reason. - Checkout existence recorded per environment (read-only), absence not generalized.
- Every authority question (§4) answered with current-pass evidence or carried as an explicit obligation (Owner-decision / runtime / downstream).
- No documentary or prior-session evidence presented as live/current proof.
- CONS-004 marked
OWNER_DECISION_REQUIREDwith the gathered evidence bundle; not resolved unilaterally. - Freeze-candidate emitted as a proposal (CONS-005), not enacted.
- No forbidden action (§10) performed.
- No manifest system created.
F0 execution = PARTIAL if: mostly complete but ≥1 source only PRIOR-SESSION-EVIDENCED and not re-verified current-pass, or ≥1 authority leg unresolved but carried honestly as an obligation. Package/report remains honest.
F0 execution = BLOCKED if: a mandatory source cannot be read; or completion would require a live DB/runtime read; or would require creating a manifest; or would require an Owner decision to proceed; or a KB↔checkout conflict cannot be represented honestly.
F0 execution = FAIL if: any forbidden action performed; or documentary/prior-session evidence claimed as live/current; or CONS-004 resolved unilaterally; or engineering/Codex PASS claimed as Owner authorization.
Engineering PASS (report self-verifying complete) is achievable by F0. Authority PASS (permission to move to F1 / Phase-1) is NOT — Owner-only (framework §20.3).
13. F0 evidence table template
F0 execution fills this table inline (framework §17 columns + a Provenance column). Example rows are illustrative placeholders — not results.
| Claim / Area | What would prove it | Evidence currently present | Evidence still missing | Provenance | Status | Blocks next phase? |
|---|---|---|---|---|---|---|
KB revision of constitution.md |
Read KB rev current-pass | (filled at F0 run) | — | current-pass | PROVEN (when run) | No |
laws-new/* present in checkout |
test -f current-pass per env |
framework §1: absent here & Codex repo | per-env re-check | prior-session → re-verify | CONFLICT/UNKNOWN until re-checked | Yes if sync required |
| Authority order KB vs checkout vs runtime | Owner ratifies an order | §6 observed facts + conflict | Owner CONS-004 decision | documentary | OWNER_DECISION_REQUIRED (CONS-004) | Yes |
required-stamps KB→runtime delivery |
Owner-authorized runtime read | KB config rev6 only | runtime delivery check (SRC-009/010) | documentary | DOCUMENTARY_ONLY → obligation | Yes if checker (downstream) |
| Codex rev56 review artifact | Locate file or confirm Owner relay | task relay = PASS_WITH_COSMETIC_NOTES | distinct KB report file | prior-session/relay | PRIOR-SESSION-EVIDENCED | No |
| Freeze baseline | Owner freeze (CONS-005) | F0 freeze-candidate (proposal) | Owner freeze decision | current-pass (candidate) | proposal — not enacted | Yes |
Rule: any source-currency row that cannot be made current-pass stays UNKNOWN/CONFLICT/BLOCKED — never silently PROVEN.
14. F0 stop conditions
Default at every layer: HOLD. Nghi ngờ → dừng + ghi blocker + chờ Owner; không workaround ngoài scope (OR §8).
STOP before running F0 execution if: GPT/Owner have not authorized F0 read-only execution; or this package + framework rev56 controls have not been re-read; or any step would imply implementation/mutation.
STOP before any live read if: the operation would touch live DB / Postgres / Directus / runtime config / production — that is Phase-1/runtime, Owner-gated (HOLD-1). F0 ≠ Phase-1.
STOP before resolving authority order if: you are about to pick a winner between KB / checkout / runtime — do not; mark CONS-004 / OWNER_DECISION_REQUIRED and define the evidence F0 gathered.
STOP before freezing if: you are about to declare an enacted/frozen baseline — do not; emit a freeze-candidate proposal (CONS-005) for Owner.
STOP before creating any artifact if: the action would create a manifest / schema / table / registry / index / DOT / checker / scanner / pilot — forbidden (§10).
STOP before any schema change (verbatim, framework §19): STOP before ALTER / new column / new metadata (incl. dot_role/cell_id) unless Owner has authorized detailed design + implementation for that change — never in F0.
STOP and report BLOCKED if: a mandatory source is unreadable; or honesty of the package/report cannot be preserved; or an Owner decision is required to continue.
15. Bad-input / adversarial checks
Self-attack F0 with hostile assumptions (Codex-style). If a bad assumption still leads to a PASS or to action, F0 is fail-open and must be fixed.
| # | Bad assumption | Must be REJECTED to / enforced by |
|---|---|---|
| 1 | "The KB revision I read last session is still current." | Re-verify current-pass; prior-session ≠ current (RISK-STL / §7). |
| 2 | "Documentary [GR] row counts / 'LIVE/GOVERNED' labels prove substrate." |
Documentary ≠ live proof (the framework's once-failed row13; §7). |
| 3 | "Checkout absent here ⇒ checkout absent everywhere." | Per-environment; record env id; do not generalize (§11 Step 2). |
| 4 | "When KB/checkout/runtime disagree I can use the convenient one." | CONS-004 unresolved → mark CONFLICT, do not resolve (§6). |
| 5 | "F0 should create a source manifest file/system to track sources." | Inline evidence only; manifest = Owner-gated Mức 3 (SRC-005, §8, §10). |
| 6 | "Reading runtime config for SRC-009/010 is read-only so it's fine." | Touching runtime needs Owner authorization → obligation, not done (§9). |
| 7 | "Codex/Owner PASS on framework = authority to run F0 or freeze." | Engineering PASS ≠ Authority PASS; Owner-only (§1.1, §12, §17). |
| 8 | "A source I couldn't read can be assumed unchanged / PROVEN." | NOT_FOUND/UNREADABLE → BLOCKED, never silently PROVEN (§14). |
| 9 | "F0 read-only execution can pin AND freeze the baseline itself." | F0 proposes a candidate; Owner freezes (CONS-005; §8). |
| 10 | "F0 resolves the authority order so downstream can proceed." | F0 gathers evidence only; CONS-004 is Owner's (§6). |
| 11 | "F0 can query live DB (iu_staging_*) to verify a source." |
That is Phase-1 substrate survey, HOLD-1, Owner-gated; F0 ≠ Phase-1 (§3, §14). |
| 12 | "Revision number alone is enough; hash/length is overkill." | Record rev + content_length + sha256 inline for tamper/drift — but no manifest (§8). |
| 13 | "F0 is small, so it can also peek at one substrate table." | Scope is KB + checkout existence only; no substrate (§9, §10). |
Conclusion target: no bad assumption may lead to a PASS-to-act or to a forbidden action → F0 program is not fail-open.
16. Expected output format for F0 execution report
When later authorized, F0 execution emits exactly one KB report document with:
STATUS: PASS / PARTIAL / BLOCKED / FAIL (per §12)
F0 SCOPE CONFIRMATION:
- read-only only: yes
- no live DB/runtime/production touched: yes
- no manifest/schema/registry/DOT/checker/scanner/pilot created: yes
- authority order NOT resolved (CONS-004 obligation): yes
- baseline NOT frozen (CONS-005 proposal only): yes
FREEZE-CANDIDATE BASELINE (inline, no manifest):
| path | kb_revision | content_length | content_sha256 | checkout_present(env) | currency | status |
F0 EVIDENCE TABLE: (§13 columns)
AUTHORITY QUESTIONS (§4): | Q | answer/obligation | status |
CONS-004 EVIDENCE BUNDLE: observed facts · conflict · non-binding candidate framing · OWNER_DECISION_REQUIRED
OBLIGATIONS CARRIED: | id | obligation | needs |
(e.g., SRC-009/010 runtime delivery; R2 locate rev56 review; SRC-003 sync process)
ADVERSARIAL CHECK RESULT (§15): | # | rejected? | evidence |
STOP/BLOCKER LOG: | item | status | reason |
SELF-CHECK: Engineering PASS = …; Authority PASS = NOT granted (Owner-only)
NEXT GATE: (§17)
Provenance must be explicit on every factual row (current-pass / prior-session / documentary). Any missing evidence appears as an obligation, never hidden.
17. How F0 feeds the next gate
- F0 execution report → GPT/Owner. Owner reviews the freeze-candidate baseline + CONS-004 evidence bundle.
- Owner decisions unlocked by F0 (framework §14):
- §14.4 — Freeze source authority/revision/hash baseline (accept/adjust the F0 freeze-candidate).
- §14.5 — Freeze or flag CONS invariants, esp. CONS-004 (authority order) and CONS-005 (freeze decision).
- Codex checkpoint. Owner may route the F0 report to Codex for an independent control review (as with rev56).
- Only after Owner freezes the baseline and resolves/records CONS-004 may the program move toward:
- the next build-order layer (F1 — Birth/Identity root + registries/matrix classification), and/or
- a separately-authorized scoped read-only Phase-1 substrate survey (HOLD-1: verify
iu_staging_*— still read-only, still Owner-gated).
- Nothing downstream is authorized by F0. Default HOLD for everything touching canonical/production/runtime/schema. A clean F0 (or a Codex PASS on it) confirms evidence quality only — it does not open the next phase. Only Owner opens phases.
18. Self-check (before this package is reported)
- Read the actual governed files (KB), not local prose or memory: yes (constitution rev44, OR rev51/v7.58, framework rev56, de-bai rev33, catalog rev82, Codex catalog review rev1).
- NT14 "THỰC THI ĐƯỢC NGAY" available verbatim from constitution rev44 (6-question test): yes — this package's F0 questions (§4) are written so a later agent need not re-ask the basics (NT14 spirit), while leaving execution Owner-gated.
- Document-package PASS distinguished from Owner authorization: yes (§1.1, §12, §17).
- Invalid/missing authority cannot become PASS silently: yes (§7, §8, §14, §15 #8).
- Documentary/prior-session cannot become live/current proof: yes (§5, §7, §15 #1/#2).
- F0 package does not become a source manifest system: yes (§8, §10, §15 #5).
- No forbidden action performed in authoring (only this one KB document created; read-only elsewhere): yes.
- Owner-facing 3-question reuse-first surface (§1.2) added on top of the Agent/Codex technical depth (not replacing it); Q1/Q2/Q3 keep reuse-now / repair-before-reuse / add-new-only-if-needed separate; §1.2 adds no authorization and removes no safety section: yes.
F0 Source / Authority / Evidence Program Package v0.1 | 2026-06-16 | DRAFT — READ-ONLY, NOT-ENACTED, NON-AUTHORIZING. Documentary ≠ live proof. Prior-session ≠ current proof. Freeze-candidate ≠ frozen baseline. Engineering PASS ≠ Authority PASS. F0 gathers authority evidence; only Owner resolves CONS-004 and opens the next phase.