KB-3C7C

F4 — Stamp Lifecycle + Checker / Promote / Rollback — Read-only Execution Report

34 min read Revision 1
laws-newf4execution-reportstamp-lifecyclecheckerpromoterollbackread-onlypartialnon-authorizing2026-06-16

F4 — Stamp Lifecycle + Checker / Promote / Rollback — Read-only Execution Report

Ngày: 2026-06-16 · Soạn: Claude Code CLI (read-only AgentData KB) · Track: knowledge/dev/laws-new/ Packet basis: f4-stamp-checker-promote-rollback-reuse-survey-packet.md rev1 (this run; internal gate §10 passed — see §1). Control basis: technical-slice-framework.md rev56 (§6c F4 = D8 + D9 + canonical-output of D10; D8 Stamp Lifecycle / D9 Checker·Promote·Rollback·Atomic Boundary / D10 Birth·Identity·Canonical Root; build-order note "canonical birth là OUTPUT tại promote, không front-load"; §19 STOP; §20 self-check). Concept basis: de-bai-cai-tien.md rev33 (§IV.4 / §IV.6 / §V.4 / §V.5 / §V.7 / §V.11 / §V.13 / §V.16 / §V.18 / §VI.4 / §VI.7). Spec basis (documentary): required-stamps.v0.1.json rev6 (DRAFT — not enacted) · promote-checker-v0.1-spec.md rev11 (DRAFT — KHÔNG PHẢI BAN HÀNH) · matrix-stamp-governance-addendum.md rev14 (DRAFT — KHÔNG PHẢI BAN HÀNH). Catalog basis: cau-hoi-khi-tai-cau-truc.md rev82 (DOT-006; STG-012/015; STG-REUSE-001/003; DOT-CAP-001/004/006/010; Nhóm R RISK-; CONS-002/003; CELL-003/004/007). Evidence/gate basis: F3 owner decision record rev1 (F3 gate CLOSED) + F3 execution report rev6 (PARTIAL) + F3 packet rev1 + F2/F1/F0 decision records + constitution v4.6.3 (NT9/NT14/NT15/Đ20/Đ32) + OR v7.58. Run authorization: GPT/Owner authorized the F4 Program Macro; this read-only execution ran only because the packet §10 internal gate passed (all 8 items GREEN). No Phase-1, no live DB/runtime, no implementation, no schema/registry, no checker build/run, no scanner, no DOT/formula/assembly execution, no promote run, no canonical birth write, no BIRTH_STAMP/PROMOTE_STAMP/PROMOTE_BLOCKED write, no fn_birth_* live call, no CONS-002/003 / CELL- resolution, no cell_id/dot_role materialization. Layer: F4 = one layer above F3 in the §6c build order; sits below F5 (Scanner / Observability + Runtime / Operational Safety = D11 + D12). F4 is the layer where canonical birth is the OUTPUT at the promote boundary (D10) — never earlier.


0. STATUS (one line at top)

STATUS: PARTIAL — F4 read-only execution is complete and honest. All F4 candidate assets are classified into Q1/Q2/Q3 from F4-critical current-pass KB evidence plus carried-pinned F0/F1/F2/F3 authority and decision lineage, the 3 Owner questions are answered, the F4 boundary (stamps = documentary vocabulary with runtime delivery UNKNOWN; checker = verdict-only DRAFT spec, not built; Atomic Promote Contract = HOLD-2 / BLOCKED; PROMOTE_BLOCKED = verdict/state, not a stamp; BIRTH_STAMP/PROMOTE_STAMP = post-promote OUTPUTS only; canonical birth = output at promote, never the survey) is held, and every forbidden action remained blocked. PARTIAL (not PASS) because every F4 asset is DOCUMENTARY_ONLY, DRAFT, BLOCKED, or UNKNOWNrequired-stamps.v0.1.json and both checker/promote specs are DRAFT/not-enacted; the checker is never written/selftested; atomic promote has no transaction/rehearsal; and the gating conflicts/risks (CONS-002, CONS-003, CELL-003/004/007, HOLD-1, HOLD-2, STG-012/015, STG-REUSE-001/003, DOT-CAP-001/004/006/010, RISK-GC/CAP/BYPASS) remain Owner-/Phase-1-gated and are carried, not resolved. No forbidden action performed. Documentary ≠ live proof · Prior-session ≠ current proof · Engineering PASS ≠ Authority PASS · Reuse-now ≠ live-proven · Codex PASS ≠ Owner phase-authorization.


1. Status / boundary confirmation

Internal gate (packet §10) result — all 8 GREEN → executed.

# Gate item Result
G1 Mandatory sources readable GREEN — F3 report rev6, F3 packet rev1, F3 decision rev1, F2/F1/F0 records, framework rev56, de-bai rev33, catalog rev82, required-stamps.v0.1.json rev6, promote-checker-v0.1-spec.md rev11, matrix-stamp-governance-addendum.md rev14, constitution v4.6.3, OR v7.58 — all read this pass
G2 F3 gate closed first GREENreports/f3/f3-owner-decision-record-2026-06-16.md rev1 exists and accepts F3
G3 Every F4 asset classifiable honestly GREEN — each Q1/Q2/Q3 row maps to a KB evidence pin; runtime delivery kept UNKNOWN; checker kept DOCUMENTARY_ONLY
G4 No live DB/runtime/Phase-1 needed GREEN — documentary-only; iu_staging_* / dot_tools / birth_registry untouched; no fn_birth_* call
G5 No conflict resolution needed GREEN — CONS-002 / CONS-003 / CELL-003/004/007 carried, not resolved
G6 No schema/design/implementation needed GREEN — no cell_id/dot_role/stamp-column materialization; no checker/scanner build; no promote/canonical-birth write; no atomic-promote design/run
G7 Boundary held GREEN — stamps = documentary vocabulary (runtime delivery UNKNOWN); checker = verdict-only spec only; atomic promote = HOLD-2/BLOCKED; PROMOTE_BLOCKED = verdict/state; BIRTH_STAMP/PROMOTE_STAMP = post-promote outputs; no canonical birth
G8 3 Owner questions preserved GREEN — Q1/Q2/Q3 answered in §2

Boundary held this run: F4 = D8 + D9 + canonical-output of D10. F4 did not: deliver/enforce any stamp at runtime; build/run/selftest the checker; treat PROMOTE_OK as a mutation; merge checker + mutation; design or rehearse the atomic promote transaction; run a promote; write canonical birth; close BIRTH_STAMP; write PROMOTE_STAMP; write a PROMOTE_BLOCKED state; call fn_birth_register / fn_birth_gate / fn_birth_registry_auto live; touch birth_registry / iu_staging_* / dot_tools; materialize cell_id / dot_role; create/register/run any DOT; run any formula; build any assembly machine; create or run a scanner; resolve CONS-002 / CONS-003 / CELL-003/004/007; touch live DB / Postgres / Directus / runtime / production; run Phase-1; create schema / table / registry / store / index / source-manifest; do any code / migration / DDL / DML / pilot.


2. Owner View — 3 câu hỏi (answered)

Q1 — Cái gì đang có và dùng lại được? As documentary candidates carried into the F4 stamp/checker/promote layer (not live-proven): the stamp vocabulary in required-stamps.v0.1.json (7 core stamps TEMP_ID_STAMP·BIRTH_STAMP·CELL_STAMP·IO_STAMP·VALIDATION_STAMP·ROLLBACK_STAMP·PROMOTE_STAMP + 2 high-risk GOV_STAMP·OWNER_STAMP) with its workspace_required / promote_preconditions / promote_outputs / canonical_required lifecycle ordering; the F1/F2/F3 accepted boundaries; the candidate-packet-as-view binding (candidate_id + packet_hash); the pre-promote stamp path (TEMP_ID_STAMP·CELL_STAMP·IO_STAMP·VALIDATION_STAMP·ROLLBACK_STAMP); the post-promote stamp path (BIRTH_STAMP·PROMOTE_STAMP, OUTPUT only); PROMOTE_BLOCKED as a verdict/state, not a canonical stamp; the promote-checker-v0.1-spec as a documentary verdict-only checker spec; birth_registry / fn_birth_register / fn_birth_gate as documentary candidates, not live proof; and the rollback / delete-fast boundary from F2/F3. (Reuse-now = ứng viên documentary mang sang F4-implementation/F5 — KHÔNG = đã chứng minh live.)

Q2 — Cái gì đang có nhưng cần sửa/kiểm chứng mới dùng lại được? required-stamps runtime delivery is UNKNOWN (DRAFT/static; not inferable from JSON); the checker is not implemented/selftested ("No checker, no lane"); the checker must be verdict-only and fail-closed (spec, not verified behavior); candidate-packet binding depends on STG-015 packet_hash coverage; staging / pre-promote metadata depends on HOLD-1 (iu_staging_* "HOLD FOR SYSTEM CHECK"); atomic promote is HOLD-2 / BLOCKED (no transaction/rehearsal); birth_registry / fn_birth_register / fn_birth_gate are documentary only (analog fn_birth_registry_auto); the birth gate warning + bypass = RISK-BYPASS; rollback/delete-fast depends on STG-012 + RISK-GC/CAP; CELL_STAMP depends on CONS-003 / CELL-003/004/007; IO_STAMP depends on CONS-002 / IO examples GAP; DOT-CAP-001/004/006/010 affect DOT-based validation (the inspector→stamp mapping); runtime/checkout sync not proven (CONS-005 caveat).

Q3 — Cái gì thật sự còn phải làm thêm? Only future, Owner-gated, default-NO: this F4 report (produced because the §10 gate passed); checker implementation only after design + Owner gate; atomic promote design only after the evidence decision (HOLD-2 lifted by Owner); runtime stamp-delivery check only Owner-gated / Phase-1; schema / materialization (cell_id/dot_role/stamp columns/packet store; a new mandatory stamp = Mức 3) only after reuse-insufficiency proof + Owner-gated detailed design; canonical birth write / promote only in future implementation, never the survey; scanner / observability belongs to F5 (D11 + D12). (Mỗi "add-new" phải chứng minh đủ 5 điều kiện no-new — catalog §2c.)


3. F4 asset classification table

Asset Currency Classification Reason / evidence pin
required-stamps.v0.1.json (vocabulary) current-pass Q1 — DOCUMENTARY_ONLY rev6, _meta.status = "DRAFT - not enacted"; 7 core + 2 high-risk; static config "checker ĐỌC file này"
TEMP_ID_STAMP current-pass Q1 — DOCUMENTARY_ONLY (pre-promote) workspace_required + promote_preconditions; workspace_id/candidate_id (required-stamps lifecycle)
CELL_STAMP current-pass Q2 — DOCUMENTARY / BLOCKED-dep precondition + canonical_required; = COLLECTION+SPECIES; blocked by CONS-003 / CELL-003/004/007
IO_STAMP current-pass Q2 — DOCUMENTARY / BLOCKED-dep precondition + canonical_required; IO source unresolved (CONS-002); IO examples GAP (F3)
VALIDATION_STAMP current-pass Q1 — DOCUMENTARY_ONLY (pre-promote) precondition + canonical_required; addendum §5 "DOT validate → FIX7 rút gọn"
ROLLBACK_STAMP current-pass Q1 — DOCUMENTARY_ONLY (pre-promote) precondition + canonical_required; rollback proof; STG-012 / RISK-GC/CAP dependent
BIRTH_STAMP current-pass Q1 — DOCUMENTARY_ONLY (post-promote OUTPUT) promote_outputs + canonical_required; closed AFTER promote (de-bai §IV.4/§V.5)
PROMOTE_STAMP current-pass Q1 — DOCUMENTARY_ONLY (post-promote OUTPUT) promote_outputs + canonical_required; closed AFTER PROMOTE_OK (de-bai §V.7)
PROMOTE_BLOCKED current-pass Q1 — DOCUMENTARY (verdict/state, NOT a stamp) checker verdict + packet status; absent from stamp vocabulary (de-bai §V.4; spec §4)
candidate packet / packet_hash current-pass Q1 reuse / Q2 verify matrix_candidate_packet.v0.1 view; sha256; one packet; binding coverage = STG-015 BLOCKER
checker / verdict-only boundary current-pass Q1 spec / Q2 not-built spec §4 verdict-only; no canonical write; DOT-006; "No checker, no lane"
promote-checker-v0.1-spec current-pass Q2 — DOCUMENTARY_ONLY (DRAFT) rev11 "DRAFT — KHÔNG PHẢI BAN HÀNH"; never written/selftested
Atomic Promote Contract current-pass Q2 — BLOCKED / HOLD-2 addendum §7b all-or-nothing; "Chưa có transaction + rehearsal proof... CHƯA mở pilot promote thật"
birth_registry current-pass Q2 — DOCUMENTARY_ONLY addendum §1.2/§8 reported inspect_* cols + "162 triggers / enacted v1.0"; framework §4 downgrades reported-LIVE
fn_birth_register / fn_birth_gate carried-pinned (F1) Q2 — DOCUMENTARY_ONLY names from F1 lineage; addendum analog = fn_birth_registry_auto; not re-proven this pass
ROLLBACK / delete-fast path current-pass Q1 reuse / Q2 verify de-bai §VI.4 "sai thì xóa" + TTL; fn_iu_staging_cleanup; STG-012 scheduler unproven
staging / pre-promote metadata current-pass Q2 — HOLD-1 proposed pre-promote stamp store iu_staging_* "HOLD FOR SYSTEM CHECK"; UNKNOWN→likely-LIVE
post-promote canonical output current-pass Q3 — boundary/output only canonical birth + stamps written ONLY at promote (D10); never the survey
required-stamps runtime delivery current-pass Q2 — UNKNOWN framework D8 "runtime delivery unknown"; D12 "KB→runtime delivery" UNKNOWN; not inferable from file
F1/F2/F3 accepted baselines carried-pinned Q1 — ACCEPTED F0/F1/F2/F3 decision records; authority/evidence basis

4. Stamp lifecycle analysis

required-stamps.v0.1.json (rev6, DRAFT — not enacted) is the documentary core stamp vocabulary. It defines 7 core stamps (TEMP_ID_STAMP · BIRTH_STAMP · CELL_STAMP · IO_STAMP · VALIDATION_STAMP · ROLLBACK_STAMP · PROMOTE_STAMP) plus 2 high-risk-extra (GOV_STAMP · OWNER_STAMP), under the v0.1 ceiling of 8–10 core stamps (addendum §4 keeps the core at 7; de-bai §V.11). The lifecycle ordering (verbatim keys):

  • workspace_required = [TEMP_ID_STAMP] — kho tạm minimum.
  • promote_preconditions = [TEMP_ID_STAMP, CELL_STAMP, IO_STAMP, VALIDATION_STAMP, ROLLBACK_STAMP] — what the checker reads BEFORE promote.
  • promote_outputs = [BIRTH_STAMP, PROMOTE_STAMP] — closed AFTER PROMOTE_OK.
  • canonical_required = [BIRTH_STAMP, CELL_STAMP, IO_STAMP, VALIDATION_STAMP, ROLLBACK_STAMP, PROMOTE_STAMP].

Precondition ≠ output is the load-bearing invariant: BIRTH_STAMP + PROMOTE_STAMP are outputs of atomic promote, not preconditions — the JSON _lifecycle_note states "Checker kiểm promote_preconditions, KHÔNG yêu cầu promote_outputs trước khi chạy" (avoids circular requirement), matching de-bai §V.5/§V.7 and framework D8/D10. Pre-promote vs post-promote store split (JSON store_split): pre-promote stamps live in candidate/workspace staging metadata (proposed iu_core.iu_staging_record / iu_staging_payloadHOLD FOR SYSTEM CHECK); post-promote stamps live on canonical substrate / birth_registry inspect_* (written ONLY after the atomic promote transaction passes).

Runtime delivery = UNKNOWN. The JSON is a static config a checker is meant to READ; framework D8 explicitly says "stamp config runtime delivery unknown" and D12 lists "required-stamps KB→runtime delivery" as UNKNOWN. This report does not infer delivery/enforcement from the file's existence. No stamp-per-piece, no new core mandatory stamp (that = Mức 3 / Canonical-Kernel Governance), no stamp ledger (de-bai §IV.6/§V.11; framework D8 forbidden). CELL_STAMP is dependency-blocked by CONS-003 / CELL-003/004/007 (cell dimensions); IO_STAMP by CONS-002 (IO source) + the F3 IO-examples GAP.


5. Checker / verdict-only analysis

promote-checker-v0.1-spec.md (rev11, DRAFT — KHÔNG PHẢI BAN HÀNH) is a documentary spec for a checker — not a built, run, or selftested checker. The hard rule (§1): "No checker, no lane. A paper lane is no lane." — until this checker runs for real (fail-closed, passes selftest) there is no promote lane. Verdict-only boundary (§4): the checker checks exactly one candidate packet, does not scan the whole system, does not sign birth, does not write canonical, and does not close BIRTH_STAMP/PROMOTE_STAMP. PROMOTE_OK is only a verdict — creating canonical birth + closing the output stamps + consuming staging belongs to the Atomic Promote Contract (runs AFTER the checker). The checker emits one of PROMOTE_OK / PROMOTE_BLOCKED / ESCALATE_L3.

Fail-closed (§2.2 + §5): missing one required precondition/stamp/binding → PROMOTE_BLOCKED, no canonical write; tamper → quarantined; uncertainty → escalate to Mức 3 (no self-downgrade); blast-radius is computed, not self-declared. §2.2 binding: every artifact must bind by candidate_id and match packet_hash; candidate_id mismatch / wrong packet_hash / stale / missing artifact / artifact tampered / cell_id still UNKNOWN/PENDING / missing rollback proof all force PROMOTE_BLOCKED (or quarantined). The §6 selftest requirement — "Tamper/empty input → fail-closed, không rò token PROMOTE_OK" — is mandated but not shown to have run; this report keeps the checker DOCUMENTARY_ONLY / not-selftested. PROMOTE_BLOCKED is used as a verdict and as a candidate-packet status — never as a stamp.


6. Promote / atomic promote analysis

The Atomic Promote Contract v0.1 (addendum §7b) is the mutation step that runs after the verdict-only checker returns PROMOTE_OK. In one all-or-nothing transaction it must: lock the candidate/staging record; verify the packet is not expired/consumed and packet_hash is still valid; create the canonical birth_id/entity_code; write the canonical object to the main store; close BIRTH_STAMP (post-promote store); close PROMOTE_STAMP; mark the staging record consumed; write provenance/audit (register-before-emit) — and if ANY step fails → ROLLBACK the whole transaction (all-or-nothing). Negative states that must be blocked: birth-only; promote-stamp-only; canonical write missing rollback proof; staging consumed but canonical write failed; canonical written but staging not consumed.

This is HOLD-2 / BLOCKED. The hard condition (addendum §7b; spec §7): "Chưa có atomic promote transaction + rehearsal proof (staging, kiểu FIX7) thì CHƯA được mở pilot promote thật." No real transaction and no rehearsal exist; F4 surveys this documentary-only. The checker (verdict) and the atomic promote (mutation) are two separate steps, not merged (addendum §7b "checker = verdict-only; atomic promote transaction = mutation. Hai bước riêng, không gộp"). F4 did not design, rehearse, or run any promote, and wrote no canonical birth and no output stamps. de-bai §V.16 is respected: production/kernel/birth-gate keep heavy governance (Mức 3 / Đ32); Matrix/Stamp is not used to bypass them.


7. Rollback / delete-fast analysis

ROLLBACK_STAMP is a pre-promote precondition (required-stamps lifecycle; addendum §7) — the lifecycle requires a rollback path/proof before promote is even checked. The delete-fast principle (de-bai §VI.4): everything new runs in kho tạm first; "sai → sửa hoặc xóa ngay"; candidate/kho tạm must have a TTL or explicit cleanup condition; kho tạm must not become a shadow production (no using un-promoted candidates as a canonical source for upper tiers). de-bai §V.18: a pilot only counts if it proves "sai thì xóa được" end-to-end in staging, with no canonical write.

Verify-before-trust: the cleanup/rollback mechanics are unproven. STG-012 (who calls fn_iu_staging_cleanup; no pg_cron) blocks trusting TTL/delete-fast; RISK-GC (blob_ref orphan/cleanup) and RISK-CAP (CASCADE / 10 MiB cap under load) are OPEN. The all-or-nothing rollback of the atomic promote transaction is part of HOLD-2 (§6). F4 keeps the rollback/delete-fast path as a documentary boundary the lifecycle must satisfy — it ran no cleanup, deleted nothing, and proved nothing live.


8. Candidate packet / staging / metadata handling

The candidate packet (matrix_candidate_packet.v0.1, spec §2.1) is a view/projection / binding logic over existing staging/candidate metadata (candidate_id + packet_hash: sha256), read by the verdict-only checker — NOT a new store or registry (de-bai §V.13; STG-REUSE-002/003 default NO). Its status enum (draft|ready_for_check|promote_blocked|promote_ok|consumed|expired|quarantined) carries PROMOTE_BLOCKED as a state, confirming it is not a stamp. Packet lives in the pre-promote stamp store (candidate/workspace staging metadata; proposed iu_core.iu_staging_record/iu_staging_payloadHOLD FOR SYSTEM CHECK); it does not write birth_registry canonical.

Open obligations: STG-015 — whether packet_hash covers cell_id + stamps is undefined → tamper-binding unproven (BLOCKER). HOLD-1 — the iu_staging_* substrate (the proposed pre-promote stamp store) is UNKNOWN→likely-LIVE, Phase-1-gated (separate Owner gate). STG-REUSE-001 — whether iu_staging_* is a sufficient shared kho tạm for all tiers v0.1 is unverified. F4 treats the packet/staging as view/projection candidates, touched nothing, and created no store.


9. Canonical birth boundary analysis

Per framework §6c D10 and the build-order note: canonical birth is the OUTPUT at the promote boundary (F4) — never front-loaded, never earlier than promote. The boundary holds across the lineage: in F1, "Birth" is only the minimal identity root (TEMP_ID), not canonical birth; BIRTH_STAMP (= the birth_registry row created at promote, addendum §3) and PROMOTE_STAMP are post-promote outputs, closed by the atomic promote transaction after PROMOTE_OK. Before promote, an object lives in kho tạm (Đ41 zones / sandbox_tac) stamp-light, carrying only TEMP_ID_STAMP, with no canonical birth row.

birth_registry (addendum §1.2/§8: reported inspect_pen/inspect_stamp/inspect_gate columns + "162 birth triggers / enacted v1.0") is treated as DOCUMENTARY_ONLY — framework §4 downgrades all reported-LIVE substrate to documentary, and this pass ran no live query. fn_birth_register / fn_birth_gate are documentary candidates carried from F1 lineage, not re-proven this pass; the addendum's named analog is fn_birth_registry_auto (UNKNOWN whether the same function). RISK-BYPASS (framework D10: "birth_gate chưa block (warning); bypass kill-switch = BYPASS surface") means the gate cannot be trusted to block at promote today — Phase-1 + controlled+audited pilot. F4 wrote no canonical birth, closed no BIRTH_STAMP, wrote no PROMOTE_STAMP, and called no fn_birth_* live. The canonical-birth write is classified Q3 — future implementation only.


10. Evidence currency table

Dimension Status Detail
Sources PROVEN (KB-rev currency only) F4-critical read this pass: required-stamps.v0.1.json rev6, promote-checker-v0.1-spec.md rev11, matrix-stamp-governance-addendum.md rev14, framework rev56, de-bai rev33, catalog rev82, F3 report rev6 / packet rev1 / decision rev1, F2/F1/F0 records. Constitution v4.6.3 + OR v7.58 read this pass.
Evidence DOCUMENTARY_ONLY every stamp/checker/promote/birth asset is documentary, DRAFT, BLOCKED, or UNKNOWN; zero live-proof; no row count / trigger count treated as live.
Authority carried-pinned + current CONS-004 working precedence + CONS-005 KB-only baseline (DECIDED F0); F1/F2/F3 decisions reused; constitution NT9 (uncertain=STOP), NT14, NT15/Đ20 (design-before-implementation), Đ32 (approval); OR §7 read-only inventory + §8 STOP.
Conflict CARRIED (not resolved) CONS-002 (IO source), CONS-003 (6 vs 7 tầng; Đ0-B/Đ29/NT6/Đ5 ambiguity confirmed, not adjudicated), CELL-003/004/007.
Runtime NOT QUERIED / UNKNOWN required-stamps KB→runtime delivery UNKNOWN; checker not run; promote not run; iu_staging_* / dot_tools / birth_registry untouched; runtime/checkout sync not proven (CONS-005).
Provenance current-pass vs carried-pinned distinguished spec/framework/de-bai/catalog pins = current-pass; fn_birth_register/fn_birth_gate names + "162 triggers" = carried/prior-session documentary; F0/F1/F2/F3 decisions = carried-pinned.
Safety lock HELD no Phase-1, no DB/runtime, no checker/promote/canonical-birth, no schema/materialization, no conflict resolution; STOP discipline (NT9/OR §8) respected.

11. Conflict / HOLD log

Item Status Blocks what Carried to
CONS-002 TODO / BLOCKER which source wins for IO Contract fields → IO_STAMP Owner decision (keep 5 fields meanwhile)
CONS-003 CONFLICT / BLOCKER 6 tầng vs 7 Lớp/dimensions → cell placement, cell_id, CELL_STAMP Owner decision (Đ0-B/Đ29 vs NT6/Đ5; not adjudicated)
CELL-003 PARTIAL / BLOCKER cell_id "Tầng" dimension (layer source) → CELL_STAMP Owner + Phase-1
CELL-004 CONFLICT / BLOCKER cell_id "Loài" dimension (species, 2 namespaces) → CELL_STAMP Owner + Phase-1
CELL-007 PARTIAL / BLOCKER cell_id tier catalog (composition_level chưa enacted) → CELL_STAMP Owner (tied to CONS-003)
HOLD-1 UNKNOWN→likely-LIVE / CONFLICT live home for pre-promote stamp store (iu_staging_*) Phase-1 read-only survey (separate Owner gate)
HOLD-2 BLOCKED (no real transaction) canonical birth / promote write; atomic promote F4 implementation (Owner lifts) — survey-only here
STG-012 TODO / BLOCKER trusting TTL/delete-fast; who calls fn_iu_staging_cleanup Phase-1
STG-015 PARTIAL / BLOCKER candidate-packet tamper-binding (packet_hash cover cell_id+stamps?) Owner/spec + Phase-1
STG-REUSE-001 TODO / BLOCKER iu_staging_* as shared kho tạm for all tiers v0.1 Phase-1
STG-REUSE-003 BLOCKER-if-proposed any new packet store/registry default NO (de-bai §V.13)
DOT-CAP-001/004/006/010 BLOCKER (PARTIAL/TODO) DOT capability contract / no-mutation flag / ≥8 bad-input tests / read-vs-mutate → DOT inspector→stamp trust Owner/spec + Phase-1
RISK-GC OPEN trusting blob_ref lifecycle + delete-fast Phase-1
RISK-CAP OPEN trusting payload under CASCADE / 10 MiB cap Phase-1
RISK-BYPASS OPEN (inherited F1; framework D10) trusting birth gate at promote (warning + bypass surface) Phase-1 + controlled+audited pilot
required-stamps runtime delivery UNKNOWN trusting stamps are enforced Phase-1 (D12)
promote-checker implementation DOCUMENTARY_ONLY (DRAFT) declaring a promote lane exists F4 implementation (design + Owner gate)
CONS-004 (authority order) DECIDED at F0 reused as authority basis
CONS-005 (freeze baseline) DECIDED at F0 (KB-only) reused — caveat: no runtime/checkout sync proof

12. Adversarial check result

# Bad assumption Verdict
1 required-stamps.v0.1.json existing ⇒ stamps delivered/enforced at runtime ✅ Rejected — UNKNOWN; DRAFT/static; framework D8/D12
2 A checker spec ⇒ the checker is implemented ✅ Rejected — rev11 DRAFT; never written/selftested
3 PROMOTE_OK is a mutation / checker writes canonical ✅ Rejected — verdict-only (spec §4)
4 PROMOTE_BLOCKED is a canonical stamp ✅ Rejected — verdict/state; absent from stamp set (de-bai §V.4)
5 BIRTH_STAMP / PROMOTE_STAMP are preconditions ✅ Rejected — post-promote outputs (de-bai §V.5/§V.7)
6 Atomic promote exists because the contract is written ✅ Rejected — HOLD-2; no transaction/rehearsal
7 birth_registry / fn_birth_register / fn_birth_gate are live-proven ✅ Rejected — documentary; F1 lineage; analog fn_birth_registry_auto
8 The birth gate blocks today ✅ Rejected — warning + bypass surface = RISK-BYPASS
9 CELL_STAMP can be closed because we know the cell ✅ Rejected — CONS-003 / CELL-* unresolved
10 The IO source for IO_STAMP is settled ✅ Rejected — CONS-002 BLOCKER
11 Rollback/delete-fast is trustworthy ✅ Rejected — STG-012 / RISK-GC / RISK-CAP open
12 Candidate-packet binding is tamper-proof ✅ Rejected — STG-015 packet_hash coverage undefined
13 We can reuse iu_staging_* as the pre-promote store now ✅ Rejected — HOLD-1 / "HOLD FOR SYSTEM CHECK"
14 Closing F3 / Codex PASS authorizes building the checker or promoting ✅ Rejected — Owner/GPT only; F4 = survey

Conclusion: no bad assumption led to a PASS-to-act or a forbidden action → F4 execution is not fail-open. (14 numbered bad-assumptions, all Rejected.)


13. Non-authorization confirmation + self-check

Non-authorization confirmation:

  • no Phase-1 — none run; HOLD-1 / substrate survey untouched.
  • no DB/runtime — no live Postgres / Directus / runtime / production query or mutation; iu_staging_* / dot_tools / birth_registry untouched; no fn_birth_* live call.
  • no checker execution — checker kept DOCUMENTARY_ONLY (DRAFT); not built, not run, not selftested.
  • no promote execution — no promote run; Atomic Promote Contract kept HOLD-2 / BLOCKED; not designed, not rehearsed.
  • no canonical birth — none written; canonical birth kept as the output-at-promote boundary (D10).
  • no BIRTH_STAMP / PROMOTE_STAMP write — kept as post-promote outputs only; none closed/written. PROMOTE_BLOCKED kept as verdict/state, none written.
  • no schema/table/registry — no DDL/DML; no cell_id/dot_role/stamp columns; no packet store; no source-manifest.
  • no implementation — no code / migration / DOT / formula / assembly / scanner; no conflict resolution.

Self-check (recorder discipline):

  1. Preserved the 3 Owner questions? Yes (§2). 2. Kept F4 = Stamp Lifecycle + Checker/Promote/Rollback only? Yes (§4–§9). 3. Avoided Phase-1/DB/runtime? Yes (§1/§13). 4. Avoided checker/promote execution + canonical birth? Yes (§5/§6/§9). 5. Kept BIRTH_STAMP/PROMOTE_STAMP as future promote outputs only? Yes (§4/§9). 6. Kept PROMOTE_BLOCKED as verdict/state, not a stamp? Yes (§5/§8/§12). 7. Kept required-stamps runtime delivery UNKNOWN? Yes (§4/§10). 8. Avoided cell_id/dot_role materialization? Yes (§4/§13). 9. Carried CONS-002/003 + CELL-* honestly? Yes (§11). 10. Avoided checker/scanner implementation? Yes (§5/§14). 11. Distinguished documentary vs live proof? Yes (§3/§9/§10). 12. Kept Owner/GPT as the only phase authority (Codex = control verdict only)? Yes (§0/§12 row 14). Engineering PASS achieved with the explicitly-flagged PARTIAL condition; Authority PASS NOT granted — Owner-only.

14. F5 handoff / next-gate recommendation

F5 handoff. F5 (§6c) = Scanner / Observability + Runtime / Operational Safety (= D11 + D12): read-only observation (missing-stamp scan, orphan scan, heartbeat/freshness) + runtime/config/operational safety wrapping the running system — "chỉ quan sát / safety, không tạo build mới". F4 hands F5:

  • the stamp lifecycle vocabulary (7 core stamps; pre-promote vs post-promote) as the contract a missing-stamp scanner (D11) would read — not implemented;
  • the verdict-only checker / Atomic Promote Contract boundary (HOLD-2) as the lane F5 observes — documentary only;
  • the canonical birth boundary (birth_registry documentary; canonical birth output at promote) as the substrate an orphan/freshness scan would observe;
  • the runtime-delivery UNKNOWN for required-stamps (D12 config-delivery) as an explicit open obligation F5 must verify, not assume;
  • the carried conflicts (CONS-002, CONS-003, CELL-003/004/007) and risks (HOLD-1, HOLD-2, STG-012/015, STG-REUSE-001/003, DOT-CAP-001/004/006/010, RISK-GC/CAP/BYPASS) as obligations F5 must respect, not inherit as solved.

Next-gate recommendation:

  1. GPT/Owner read the F3 decision record + F4 packet + this F4 report.
  2. Route all three together to Codex for an independent control review (Codex = control verdict only).
  3. After Codex, Owner decides whether F5 may proceed, or whether Phase-1 / CONS-002 / CONS-003 / CELL- / HOLD-1 / HOLD-2* must be resolved first — given that every F4 candidate is documentary-only / DRAFT / BLOCKED / UNKNOWN, the conservative default is to resolve the checker-implementation / atomic-promote (HOLD-2) and staging (HOLD-1) obligations before F5 builds observability on top of an unproven lane.
  4. Default = HOLD. Codex PASS ≠ Owner phase-authorization. No checker build, no promote, no canonical birth, no Phase-1 until a separate Owner gate.

F4 Read-only Execution Report | 2026-06-16 | STATUS: PARTIAL (honest, non-blocking). F4 = D8 + D9 + canonical-output of D10. Internal gate §10 all-8-GREEN → ran. Stamps = documentary vocabulary; runtime delivery UNKNOWN. Checker = verdict-only DRAFT spec (not built/selftested). Atomic promote = HOLD-2 / BLOCKED (no transaction/rehearsal). PROMOTE_BLOCKED = verdict/state ≠ stamp. BIRTH_STAMP/PROMOTE_STAMP = post-promote outputs only. Canonical birth = output at promote, never the survey. Adversarial 14/14 rejected — not fail-open. No Phase-1 · no DB/runtime · no checker/promote/canonical-birth · no BIRTH_STAMP/PROMOTE_STAMP/PROMOTE_BLOCKED write · no schema/cell_id/dot_role · no implementation. CONS-002 / CONS-003 / CELL-003/004/007 carried (BLOCKER). HOLD-1 Phase-1-gated. HOLD-2 = F4 subject (not resolved). STG-012/015 / STG-REUSE-001/003 / DOT-CAP-001/004/006/010 / RISK-GC/CAP/BYPASS open. Documentary ≠ live proof. Engineering PASS ≠ Authority PASS. Codex PASS ≠ Owner phase-authorization. Feeds F5 (D11 + D12). NEXT = GPT → Codex (all three together) → Owner decides F5 vs resolve Phase-1 / CONS-002/003 / CELL- / HOLD-1 / HOLD-2 first. Default HOLD.*

Back to Knowledge Hub knowledge/dev/laws-new/reports/f4/f4-stamp-checker-promote-rollback-execution-report-2026-06-16.md