KB-4C2E
FIX7 Implementation Precondition Checklist (2026-06-10)
3 min read Revision 1
tool-kiem-thufix7authority-closureimplementation-preconditions2026-06-10
FIX7 Implementation Precondition Checklist
- Date: 2026-06-10 · Status: checklist only — implementation NOT started, NOT authorized by this doc.
- Purpose: when owner/Codex pass the seal step, the next FIX7 implementation macro must satisfy every row below before its first mutation.
| # | Precondition | Required? | Detail |
|---|---|---|---|
| 1 | Codex/authority seal complete | YES — hard gate | N7 computed from authorized approval event; N8 detached seal authored by Codex; P7 pins canonicalizer rev3 49c386a9…b734d0 @ revision 3. Implementation against an unsealed candidate is prohibited. |
| 2 | Owner approval of the implementation macro | YES — hard gate | Owner option 4 (or explicit equivalent). Option 2/3 alone does NOT authorize execution. |
| 3 | Seal-vs-bytes recheck at macro start | YES | First step: fresh-fetch SSOT rev at sealed revision, recompute SHA-256, compare to P7 pin. Mismatch → STOP, TRUE_BLOCKER, no mutation. |
| 4 | Allowed mutations | Enumerated only | Only mutations the owner-approved implementation macro lists explicitly, each with a gate. Default = deny. |
| 5 | Forbidden mutations (standing) | YES | PG/Directus/registry/system_issues mutation outside the enumerated list; permit issuance; activation; repoint; cutover; registries-pivot; auto-birth repair. |
| 6 | Rollback requirement | YES | Every mutation must have a rollback/disable path VERIFIED BEFORE apply (operating-skill "2 khóa"). No rollback → no apply. |
| 7 | REAL_RUN | Separate approval | Not covered by seal or by implementation authorization; needs its own explicit owner grant. |
| 8 | QT001 / apply / permit / activation / repoint / cutover | Separate approval each | Each requires its own explicit authorization; none is implied by the seal. |
| 9 | Evidence discipline | YES | No fake PASS; every gate produces executed output (Article 14); candidate/rehearsal values never presented as sealed. |
| 10 | Governance | YES | Every new object/accessory in the implementation lane is birthed/governed or gets an action-ready blocker in the same macro. |
| 11 | Required FIRST step after approval | YES | Run precondition rows 1–3 verification and write a readback table (sealed values, allowed/forbidden lists, rollback plan) BEFORE any mutation. |