Incomex AI Portal
KB-423B

F5 — Scanner / Observability / Heartbeat + Runtime / Config / Operational Safety — Reuse Survey Packet (read-only, non-authorizing)

25 min read Revision 1
laws-newmatrix-assemblystamp-governancef5scannerobservabilityheartbeatruntimeconfig-deliveryoperational-safetyreuse-survey-packetread-onlynon-authorizing2026-06-16

F5 — Scanner / Observability / Heartbeat + Runtime / Config / Operational Safety — Reuse Survey Packet

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 (§6c F5 = D11 + D12; D11 Scanner/Observability/Heartbeat = "Scanner chỉ liệt kê … no auto-fix scanner / no full-system backfill"; D12 Runtime/Config/Operational Safety = "required-stamps KB→runtime delivery … operational risks vẫn là survey/design gates"; §19 STOP; §20 self-check). Concept basis: de-bai-cai-tien.md rev33 (§IV.6/§IV.7 anti-bloat scanner · §V.4 object states + PROMOTE_BLOCKED · §V.6 cơ quan quét liệt kê · §V.9 scanner nguyên tắc chốt · §V.17 scanner chỉ liệt kê · §VI.4 delete-fast/TTL · §VI.7 scanner→no auto-fix · §12 required-stamps trong metadata không hardcode · §16 không né production gate). Catalog basis: cau-hoi-khi-tai-cau-truc.md rev82 (Dependency-map L7 Scanner/Report/heartbeat + L5b Operational Risk Gates; Nhóm L SCAN-001..015 + SCAN-REUSE-001/002; Nhóm R RISK-AP/IDX/STL/GC/CELL/RUN/BYPASS/CRASH/CAP/TIME; STG-012/015; DOT-006; DOT-CAP; OP-1..12). Spec basis (documentary): required-stamps.v0.1.json rev6 (DRAFT — runtime delivery not defined) · promote-checker-v0.1-spec.md rev11 (DRAFT — verdict-only, "No checker, no lane") · matrix-stamp-governance-addendum.md rev14 (§6 scanner = ghép 3 nền sẵn có read-only; §7b atomic promote HOLD-2; §7c TTL/cleanup fail-safe; §8 birth_registry documentary). Evidence/gate basis: F4 owner decision record rev1 (F4 gate CLOSED) + F4 execution report rev1 (PARTIAL) + F4 packet rev1 + F3/F2/F1/F0 decision records + constitution v4.6.3 + OR v7.58 (reused under CONS-004).

1. Status / non-authorization banner

STATUS: PREPARATION PACKET — NON-AUTHORIZING. This is a read-only program package that prepares the F5 layer. It is not an F5 execution authorization on its own (the F5 read-only execution in this Program Macro runs only if the internal safety gate in §10 passes), not a Phase-1 survey, not an implementation authorization. It performs no live DB / runtime / production query, mutates nothing, creates no schema/table/registry/index, builds and runs no scanner / heartbeat / checker / promote / DOT / formula / assembly, writes no canonical birth / BIRTH_STAMP / PROMOTE_STAMP / PROMOTE_BLOCKED state, and creates no dashboard. It is structured around the same 3 reuse-first Owner questions as F0/F1/F2/F3/F4 and is intended for GPT → Codex → Owner review.

Banner boundary invariants:

  • F5 = D11 + D12 — the operational "roof" (mái), built last. D11 Scanner/Observability/Heartbeat; D12 Runtime/Config/Operational Safety. F5 is observation and safety only — it does not build the lanes it observes; it is cross-cut by FX (Governance One Roof).
  • Scanner only lists (chỉ liệt kê). Per de-bai §V.6/§V.9/§V.17: the scanner lists missing-stamp / orphan / promote-blocked objects to a warning table; it does not fix the system, does not replace the promote checker, and does not become a new governance macro. "Làm được bằng scanner/report → KHÔNG tạo auto-fix" (§VI.7).
  • No scanner / heartbeat is implemented. Every F5 element is DOCUMENTARY_ONLY / GAP / UNKNOWN (framework D11 evidence level = "DOCUMENTARY_ONLY / GAP (scanner chưa implementation)"). F5 must NOT claim anything is implemented or running.
  • Runtime / config delivery is UNKNOWN. required-stamps.v0.1.json is a KB-side static config; whether/how it reaches a runtime checker is UNKNOWN (framework D12; RISK-RUN-005/006, SRC-009/010). F5 may NOT infer delivery from the file.
  • The lanes F5 would observe are documentary / HOLD. The checker is DRAFT verdict-only and not built ("No checker, no lane"); the promote lane is HOLD-2 / BLOCKED; the pre-promote staging store is HOLD-1; birth_registry / fn_birth_* are documentary only. F5 observes them as documentary lanes, never asserting they exist live.
  • Canonical birth boundary unchanged. Canonical birth + BIRTH_STAMP + PROMOTE_STAMP are outputs at promote (D10/F4). F5 observes their absence (orphan/freshness), it does not write them.
  • Carried conflicts/risks are obligations, not solved. 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 — and the full Nhóm R operational-risk set (R1–R9, ~40 rows, all TODO) — are respected by F5, not inherited as solved.
  • Documentary ≠ live proof · Prior-session ≠ current proof · Engineering PASS ≠ Authority PASS · Reuse-now ≠ live-proven · Codex PASS ≠ Owner phase-authorization.

2. Owner View — 3 câu hỏi reuse-first

Mục này KHÔNG ủy quyền vận hành. It states, in plain terms, what F5 expects to find so the Owner can steer the next gate.

Q1 — Cái gì đang có và dùng lại được? (likely reusable, documentary)

  • The scanner / observability concept from framework D11 + de-bai §V.6/§V.17 — a read-only "máy quét đơn giản" whose job is only to list (liệt kê), not fix.
  • The missing-stamp scan concept — list objects whose required stamps are absent (UNSTAMPED / MISSING_STAMP), scoped to the selected pilot slice.
  • The orphan / candidate scan concept — list orphan/phantom objects and candidates that never promoted (Đ23 inverse-check + birth_registry query certified=false / inspect_* IS NULL + Đ0-G §2.5 orphan/phantom).
  • The heartbeat / freshness / report concept — minimal scoped freshness/liveness measurement and a warning table.
  • The F4 stamp lifecycle vocabulary as the documentary contract a missing-stamp scanner would check against.
  • The F4 checker / promote / canonical boundary as the documentary lane F5 observes (verdict-only checker; HOLD-2 promote; canonical-at-promote).
  • The F0 → F4 accepted evidence lineage (decision records) as the authority/evidence basis.
  • Existing reports (F0–F4 execution reports) as observability evidence, not runtime proof.
  • Existing observability substrate as documentary candidates to assemble, not build new: system_issues / fn_log_issue (warning table with severity), event_outbox (register-before-emit), the orphan-scan index idx_birth_uncertified (SCAN-REUSE-001). "Không tạo cơ quan mới. Ghép 3 nền sẵn có" (addendum §6).

Q2 — Cái gì đang có nhưng cần sửa/kiểm chứng mới dùng lại được? (repair / verify before reuse)

  • No scanner is implemented — the concept is documentary; nothing scans today.
  • No live runtime or DB verification — the substrate counts (birth_registry ~1.2M, dot_tools coverage, iu_staging_*) are documentary, not live-proven; verifying them is Phase-1.
  • required-stamps runtime delivery is UNKNOWN — KB→runtime load/parse/version-pin/fail-closed is undefined (RISK-RUN-005/006).
  • The checker lane does not exist live — DRAFT spec, never built/selftested ("No checker, no lane").
  • The promote lane is HOLD-2 — no atomic transaction, no rehearsal; F5 cannot observe a lane that is not open.
  • The pre-promote staging store is HOLD-1 — iu_staging_* "HOLD FOR SYSTEM CHECK"; observability of staging depends on it.
  • birth_registry / birth functions are documentary only — orphan/freshness scan depends on them being verified (Phase-1).
  • STG-012 cleanup scheduler is unknown — who runs cleanup / on what schedule (also SCAN-007); affects orphan/garbage observability.
  • STG-015 packet_hash binding is unknown — affects whether candidate-packet tamper state can be observed.
  • RISK-GC / RISK-CAP affect orphan / blob_ref / payload observability (blob lifecycle, retention, CASCADE).
  • RISK-BYPASS affects gate observability — the birth-gate warning+bypass surface and role/write-permission matrix (RISK-BYPASS-001..006) must be surveyed before a heartbeat can be trusted.
  • CONS-002 / CONS-003 / CELL-003/004/007 affect stamp / cell / IO observability — CELL_STAMP / IO_STAMP cannot be observed against a resolved cell_id (RISK-CELL-001..006).
  • DOT-CAP-001/004/006/010 block trusting DOT-based validation/observability (capability contract / no-mutation flag / bad-input tests / read-vs-mutate).
  • Runtime / checkout sync not proven — CONS-005 freeze baseline is KB-only; it does not prove runtime/checkout sync.

Q3 — Cái gì thật sự phải làm thêm? (add later only if needed, Owner-gated, default-NO)

  • A real scanner implementation — only after design + Owner gate (de-bai forbids auto-fix; "chỉ liệt kê").
  • A live heartbeat / runtime monitor — later, Owner-gated; no heartbeat is run by F5.
  • A missing-stamp scanner — later.
  • An orphan scanner — later.
  • Runtime config-delivery proof (KB→runtime required-stamps) — later, Phase-1/Owner-gated.
  • Dashboard / reporting UI — later; F5 creates none.
  • A Phase-1 read-only runtime/substrate survey (RISK-RUN/SRC liveness preflight; OP-1..12) — later, separate Owner gate.
  • Technical design of any of the above — only after an Owner gate. Each add-new must first prove all 5 no-new conditions (catalog §2c) and that assembling existing substrate is insufficient. Forbidden throughout: auto-fix scanner, full-system backfill, full-table-scan of large tables, new config-delivery subsystem/manifest, uncontrolled bypass, any schema change.

3. F5 scope and non-scope

In scope (survey/classify only, all documentary):

  • Scanner concept; missing-stamp scan; orphan/candidate scan; heartbeat/freshness/report concept.
  • Observability via existing system_issues / fn_log_issue; severity classification.
  • Runtime / config-delivery survey: KB→runtime required-stamps delivery (UNKNOWN); config load/parse/version-pin/fail-closed; runtime liveness of Agent Data MCP / Postgres / Qdrant / Directus.
  • Operational-safety survey gates only: bypass/write-permission (RISK-BYPASS), crash/retry/outbox consistency (RISK-CRASH), TTL/clock-skew (RISK-TIME), blob_ref garbage/cleanup (RISK-GC), retention/backpressure (RISK-CAP), stale verdict/config drift (RISK-STL), JSONB/index/full-scan risk (RISK-IDX), atomic-promote lock/transaction observability (RISK-AP, documentary — HOLD-2).
  • Observability of the F4 lanes as documentary: stamp lifecycle (missing-stamp target), checker (verdict-only, not built), promote (HOLD-2), canonical birth (output-at-promote).
  • F0→F4 accepted evidence lineage as observability evidence.

Out of scope / FORBIDDEN (D11/D12 "Forbidden" + §19 STOP + de-bai §IV.6/§VI.7):

  • Auto-fix scanner; full-system backfill; full-table-scan of large tables (e.g. birth_registry ~1.2M); scanner as macro-governance; scanner replacing the checker.
  • New config-delivery subsystem/manifest; treating KB config as runtime config; uncontrolled bypass.
  • Any schema change (ALTER / new column / new metadata, incl. dot_role/cell_id on dot_tools); new index/worker/scheduler/ledger/registry/scanner/checker/DOT.
  • Running any scanner / heartbeat; building or running a checker/promote; writing canonical birth / BIRTH_STAMP / PROMOTE_STAMP / PROMOTE_BLOCKED; creating a dashboard.
  • Phase-1; any live DB / runtime / production query; touching iu_staging_* / dot_tools / birth_registry live; resolving CONS-002/003/CELL-*.
  • Turning the F5 report or the cross-F matrix into technical design or an implementation prompt.

4. Reuse-now inventory template (Q1 detail)

Each row to be classified in execution as DOCUMENTARY_ONLY (reuse-now = documentary candidate, NOT live-proven):

Asset (concept / substrate) Source pin Reuse note
Scanner "chỉ liệt kê" concept framework D11; de-bai §V.6/§V.9/§V.17 read-only list-only machine; no auto-fix
Missing-stamp scan de-bai §V.4 (UNSTAMPED/MISSING_STAMP); addendum §6.1 (1 SQL on birth_registry) list objects lacking required stamps, scoped to slice
Orphan / candidate scan Đ23 inverse-check; Đ0-G §2.5 orphan/phantom; birth_registry certified=false/inspect_* IS NULL; addendum §6.2 list orphan/phantom + unpromoted candidates
Heartbeat / freshness / report framework D11; catalog L7 (minimal scoped heartbeat) freshness/liveness measurement (read-only), warning table
system_issues / fn_log_issue addendum §6; SCAN-005/006/010 existing warning table w/ severity = observability output
event_outbox register-before-emit framework D12 existing consistency substrate
Orphan-scan index idx_birth_uncertified SCAN-REUSE-001 reuse existing scanner parts; assemble, no new scanner
F4 stamp lifecycle vocabulary required-stamps rev6; F4 report the contract a missing-stamp scanner checks against
F4 checker / promote / canonical boundary F4 report §5/§6/§9 documentary lane to observe (verdict-only / HOLD-2 / output-at-promote)
F0→F4 accepted lineage F0–F4 decision records observability evidence, not runtime proof

5. Repair / verify-before-reuse inventory template (Q2 detail)

Item Status Verify gate
Scanner implementation NOT IMPLEMENTED (documentary) design + Owner gate
Live runtime / DB substrate (birth_registry/dot_tools/iu_staging_* counts) DOCUMENTARY_ONLY Phase-1 read-only survey
required-stamps KB→runtime delivery UNKNOWN RISK-RUN-005/006; SRC-009/010 (Phase-1/Owner)
Checker lane DRAFT, not built ("No checker, no lane") F4 implementation behind Owner gate
Promote lane HOLD-2 / BLOCKED atomic transaction + rehearsal (Owner)
Pre-promote staging store iu_staging_* HOLD-1 Phase-1
birth_registry / fn_birth_* DOCUMENTARY_ONLY Phase-1
STG-012 cleanup scheduler (= SCAN-007) TODO / BLOCKER Phase-1
STG-015 packet_hash binding PARTIAL / BLOCKER Owner/spec + Phase-1
RISK-GC blob_ref lifecycle / delete-fast OPEN Phase-1
RISK-CAP payload / CASCADE / 10 MiB cap / retention OPEN Phase-1
RISK-BYPASS birth gate + role/write matrix OPEN Phase-1 + controlled+audited pilot
CONS-002 / CONS-003 / CELL-003/004/007 BLOCKER Owner decision (+ Phase-1)
DOT-CAP-001/004/006/010 BLOCKER Owner/spec + Phase-1
Runtime / checkout sync NOT PROVEN (CONS-005 caveat) Phase-1

6. Add-later-only-if-needed template (Q3 detail)

Future item Condition to add Default
Real scanner implementation design + Owner gate; assemble-existing insufficient NO
Live heartbeat / runtime monitor Owner gate; Phase-1 first NO
Missing-stamp scanner (built) Owner gate NO
Orphan scanner (built) Owner gate NO
Runtime config-delivery proof / mechanism Phase-1 + Owner gate NO
Dashboard / reporting UI Owner gate NO
Phase-1 read-only runtime/substrate survey (OP-1..12; RISK-RUN/SRC) separate Owner gate NO until gated
Technical design of any of the above Owner gate after survey NO

Forbidden regardless: auto-fix scanner; full-system backfill; full-table-scan of large tables; new config-delivery subsystem/manifest; uncontrolled bypass; any schema change.

7. F5 evidence obligations

The F5 execution must, for every asset:

  • Pin each claim to a KB evidence source (framework / de-bai / catalog / addendum / required-stamps / checker-spec / F0–F4 records) — never invent live proof.
  • Keep runtime delivery UNKNOWN; keep the checker / promote lane documentary (not live); keep scanner / heartbeat DOCUMENTARY_ONLY (not implemented/running).
  • Cover the deep layer: sources, evidence, authority, conflict, runtime, provenance, safety lock (evidence-currency table).
  • Distinguish documentary vs live proof on every row.
  • Carry CONS-002/003, CELL-003/004/007, HOLD-1/HOLD-2, STG-012/015, STG-REUSE, DOT-CAP, RISK-* honestly as obligations.
  • Respect the Nhóm R operational-risk gates (R1–R9) as survey/design gates, not solved facts.

8. Known risks / stop conditions

  • Pretending a lane exists. If F5 needs the checker/promote lane to observe, mark it documentary / HOLD-2 — do not pretend it exists live.
  • Inferring runtime delivery. If F5 needs required-stamps runtime delivery, keep UNKNOWN — do not infer from JSON.
  • Treating documentary substrate as live. Row counts (birth_registry ~1.2M etc.) are documentary — never live proof.
  • Scanner over-reach. Any move toward auto-fix / full-system scan / macro-governance / full-table-scan of large tables = STOP (de-bai §IV.6/§VI.7; D11 forbidden; RISK-IDX-004 BLOCKER).
  • Operational-risk over-claim. RISK-AP/CRASH/TIME/BYPASS/RUN are hard BLOCKERs in the catalog — survey only, never declare safe.
  • §19 STOP triggers. STOP before detailed slice design while runtime-delivery + atomic-promote are hard BLOCKERs; STOP before Phase-1 while RISK-RUN/SRC preflight is undefined.
  • If F5 cannot classify a critical item safely → mark BLOCKED / PARTIAL and do not execute beyond the survey.

9. Bad-input / adversarial checks

The F5 execution must reproduce and reject (Rejected = does not lead to a PASS-to-act or a forbidden action) at least these bad assumptions:

  1. "required-stamps.v0.1.json exists ⇒ stamps are delivered/enforced at runtime." → Rejected (UNKNOWN; D12).
  2. "The scanner concept is documented ⇒ a scanner exists / runs." → Rejected (DOCUMENTARY_ONLY; not implemented).
  3. "Closing F4 / Codex PASS ⇒ I may build or run a scanner/heartbeat." → Rejected (Owner/GPT only; F5 = survey).
  4. "birth_registry ~1.2M ⇒ live proof I can full-scan for orphans." → Rejected (documentary; RISK-IDX-004 forbids full-scan).
  5. "Checker spec exists ⇒ a promote lane exists to observe." → Rejected ("No checker, no lane"; HOLD-2).
  6. "I can read system_issues / dot_tools / iu_staging_* live to confirm observability." → Rejected (no live query; Phase-1).
  7. "Scanner can also fix what it lists." → Rejected (de-bai §VI.7 → no auto-fix; D11 forbidden).
  8. "A heartbeat proves runtime liveness now." → Rejected (no heartbeat run; RISK-RUN survey only).
  9. "RISK-BYPASS is observable ⇒ the bypass is controlled." → Rejected (RISK-BYPASS-001/004 BLOCKER; pilot-gated).
  10. "Freshness measurement requires a clock ⇒ I may assume a clock source." → Rejected (RISK-TIME-001 BLOCKER).
  11. "Cell/IO observability works ⇒ CONS-003/CONS-002 effectively resolved." → Rejected (carried unresolved; RISK-CELL BLOCKERs).
  12. "Documentary scanner = a built scanner, just on paper." → Rejected (documentary ≠ implemented).
  13. "F5 can write PROMOTE_BLOCKED/orphan states it lists." → Rejected (verdict/state writes are forbidden; observation only).
  14. "Cross-F matrix may design how to close the blockers." → Rejected (matrix is non-authorizing; no technical design).

If any bad assumption would lead to a forbidden action, F5 is fail-open → STOP.

10. Internal gate — when to proceed from packet to F5 execution

Run all 8 gate items. All GREEN → run the read-only F5 survey from KB/documentary evidence only and emit Document 3 (STATUS honest — PARTIAL is acceptable and expected where every candidate is documentary-only / GAP / UNKNOWN / Owner-gated). Any RED → the macro STOPS at PARTIAL/BLOCKED and Document 3 is not created.

# Gate item Pass condition
G1 Mandatory sources readable F5-critical sources read this pass: F4 report rev1, F4 packet rev1, F4 decision rev1, F3/F2/F1/F0 records, framework rev56 (§6c D11/D12 + §19 + §20), de-bai rev33 (scanner/observability/runtime), catalog rev82 (L7, Nhóm L SCAN-, Nhóm R RISK-, STG-012/015, DOT-006/DOT-CAP), required-stamps rev6, checker-spec rev11, addendum rev14, constitution v4.6.3, OR v7.58
G2 F4 gate closed first reports/f4/f4-owner-decision-record-2026-06-16.md exists and accepts F4 (rev1)
G3 Every F5 asset classifiable honestly each Q1/Q2/Q3 row maps to a KB evidence pin without inventing live proof; runtime delivery kept UNKNOWN; scanner/heartbeat kept DOCUMENTARY_ONLY; checker/promote lane kept documentary/HOLD-2
G4 No live DB/runtime/Phase-1 needed classification is documentary-only; iu_staging_* / dot_tools / birth_registry / system_issues untouched live; no fn_* call; no runtime/config query
G5 No conflict resolution needed CONS-002 / CONS-003 / CELL-003/004/007 carried, not resolved; Nhóm R gates carried, not closed
G6 No schema/design/implementation needed no cell_id/dot_role/stamp-column materialization; no scanner/heartbeat/checker/promote build or run; no canonical-birth/stamp write; no dashboard; no new index/worker/scheduler
G7 Boundary held scanner = list-only documentary concept; runtime delivery UNKNOWN; checker/promote lane documentary/HOLD-2; staging HOLD-1; canonical birth output-at-promote; no auto-fix; no full-system scan
G8 3 Owner questions preserved Q1/Q2/Q3 present in the execution report

11. Expected F5 execution report format

Mirrors the F0–F4 report shape (§0–§13):

  • §0 STATUS (one line): PASS / PARTIAL / BLOCKED, honest.
  • §1 Status / boundary confirmation (incl. internal gate result).
  • §2 Owner View — 3 reuse-first questions (Q1/Q2/Q3) answered at the control surface.
  • §3 F5 asset classification table — Q1/Q2/Q3, verdict + evidence pin + documentary/live label per row.
  • §4 Scanner / missing-stamp analysis.
  • §5 Observability / heartbeat / freshness analysis.
  • §6 Runtime / config-delivery analysis (KB→runtime UNKNOWN; RISK-RUN/SRC; liveness preflight).
  • §7 Orphan / rollback / delete-fast observability analysis (RISK-GC/CAP; STG-012; TTL fail-safe).
  • §8 Checker / promote lane observability analysis (verdict-only; HOLD-2; canonical-at-promote; RISK-AP/CRASH).
  • §9 Evidence-currency table (sources / evidence / authority / conflict / runtime / provenance / safety-lock; documentary vs live).
  • §10 Conflict / HOLD log — 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 + Nhóm R carried.
  • §11 Adversarial check result — §9 bad-assumptions, all Rejected.
  • §12 Non-authorization confirmation + self-check.
  • §13 Post-F0→F5 next-gate recommendation.
  • Closing note: "PARTIAL is acceptable and honest where evidence is documentary-only / GAP / UNKNOWN or a verification is Owner-gated. Engineering PASS ≠ Authority PASS."

12. How F5 feeds the post-survey decision / technical-design phase

After F5: GPT → Codex → Owner review the F4 decision record + F5 packet + F5 report + the cross-F evidence/readiness matrix together. The Owner then chooses the post-survey route: A. Phase-1 read-only substrate/runtime survey (OP-1..12; RISK-RUN/SRC liveness preflight; HOLD-1; birth_registry/dot_tools/iu_staging_*); B. blocker decision notes (CONS-002/003, CELL-, HOLD-2 atomic-promote, STG-, DOT-CAP, RISK-*); C. technical-design preparation (checker build, atomic-promote transaction, scanner) — only after a gate; D. implementation planning later. F5 produces no design and no implementation prompt; it scopes the survey surface so the Owner can sequence A/B/C/D. Default = HOLD. Codex PASS ≠ Owner phase-authorization.

13. Self-check (packet discipline)

  1. Did I keep the packet non-authorizing and read-only? Yes.
  2. Did I keep F5 = Scanner/Observability (D11) + Runtime/Operational Safety (D12) only? Yes.
  3. Did I keep the 3 Owner reuse-first questions at the control surface? Yes.
  4. Did I keep runtime delivery UNKNOWN and scanner/heartbeat DOCUMENTARY_ONLY? Yes.
  5. Did I keep the checker/promote lane documentary/HOLD-2 and staging HOLD-1? Yes.
  6. Did I forbid auto-fix / full-system scan / new config subsystem / uncontrolled bypass / schema change? Yes.
  7. Did I carry CONS-002/003, CELL-, HOLD-1/2, STG-, DOT-CAP, RISK-* (incl. Nhóm R) as obligations? Yes.
  8. Did I define an 8-item internal gate that stops the macro if any item is RED? Yes.
  9. Did I avoid technical design and any implementation prompt? Yes.
  10. Is GPT/Owner the only phase authority (Codex = control verdict only)? Yes.

F5 Reuse Survey Packet | 2026-06-16 | STATUS: PREPARATION PACKET — NON-AUTHORIZING. Prepares F5 = D11 (Scanner/Observability/Heartbeat) + D12 (Runtime/Config/Operational Safety). Read-only; the F5 execution runs only if the §10 internal gate is all-8-GREEN. Scanner = list-only documentary; runtime delivery UNKNOWN; checker/promote lane documentary/HOLD-2; staging HOLD-1; canonical birth output-at-promote; no auto-fix / no full-system scan / no new subsystem / no schema. Documentary ≠ live proof. Engineering PASS ≠ Authority PASS. Codex PASS ≠ Owner phase-authorization.