00 — Overview, State Recovery & Test-Mode Authority

Package: one-roof-phase1-test-mode-build-2026-06-02 Mode: TEST-MODE controlled foundation build — PERSISTENT PG COMMITS within authorized scope. Channels: write = ssh contabo → docker exec -i postgres psql -U workflow_admin -d directus (PG 16.13); read-only verify = MCP query_pg. Date: 2026-06-02.

0.1 Headline

STATUS: PASS (7/7 authorized substrate areas built + verified; 0 out-of-scope mutation).

Step	Object(s)	Verdict
SB-0	governance_build_authorization + quorum_passed/valid_sovereign_esign + v_build_auth_valid + fn_build_commit_allowed + 4 idx	COMMITTED
SB-12	governance_ruleset	COMMITTED
SB-13	gov_worker_cursor	COMMITTED
SB-10	governance_candidate_state (keystone)	COMMITTED (aux candidate_scan_run/governance_candidate_object DEFERRED)
SB-11	5 governance-domain rows in event_type_registry, all active=false	COMMITTED
SB-2	governance_responsibility_scope (+6 scopes) + governance_object_ownership + v_object_effective_owner	COMMITTED
SB-1	F-83-1 trigger re-wire + 8 governance action-type rows (unimplemented)	COMMITTED

0.2 What long-term gate is being deferred

The L2 council + L4 sovereign ratification of the authorization model (the "one gate" — redefine M-1, adopt SB-0; hardening doc 14 N1). Per prior packages (…go-nogo…/07, …human-ratification-handoff…) the persistent build was NO-GO until that human ratification, because os_proposal_approvals=0 and only the President's e-sign can satisfy M-1. This mission does NOT solve that gate and makes no claim that it is solved. The substrate built here is test-mode foundation only, inert and reversible, with no production activation.

0.3 Why test-mode operator authorization is used

The user explicitly delegated authority to operate for test progress:

"Tôi cho phép bạn thay mặt tôi điều hành nhanh nhất có thể để đạt được mục tiêu. Bạn tự ra quyết định thay cho user."

This is the system owner authorizing, on their own infrastructure, a bounded, reversible, internal test-mode build. The confirm-first bar (for hard-to-reverse / outward-facing actions) is cleared because the authorized scope is additive, fully reversible (DROP/DELETE/restore-trigger), and internal — and every genuinely irreversible/outward action remains forbidden (§0.5). Each step was rehearsed BEGIN..ROLLBACK before commit and verified after.

0.4 Authorized build scope (exact)

SB-0, SB-12, SB-13, SB-10, SB-11 (register-only/no emit), SB-2, SB-1 (with mandatory F-83-1 trigger fix). axis_registry/axis_assignment were preflight-checked only — NOT in this mission's build list (§2.3 of the mission authorizes the 7 SB-items; axis is downstream).

0.5 Forbidden scope (all honored — see doc 09 §out-of-scope check)

No production activation · no T6/T7 scanner run · no backfill · no event emit · no notification emit · no DOT run/registration · no Nuxt/UI/route mutation · no Directus mutation · no Qdrant mutation · no law enactment/version/status change · no os_proposal_approvals write · no e-sign fabrication · no Phase-B handler activation · no auto-approve bypass · no mutation outside the listed substrate · no hardcode · no hidden local governance island.

0.6 Rollback strategy

Additive build ⇒ every step reverses by DROP/DELETE + (SB-1) restore-trigger. Per-step rollback scripts staged in sql/*_rollback.sql (doc 10). Pre-build schema-only backup: /opt/incomex/backups/directus-pre-phase1-testmode-20260602T062711Z.schema.sql. Most recent full VPS backup: vps-backup-20260601_203701.tar.gz.

0.7 Stop conditions (none triggered)

Backup/rollback missing · object conflict · trigger mismatch unfixable · post-step verification failure · any event emit · any DOT run · any Directus/Nuxt/Qdrant mutation · production worker consuming data · unexpected approval/e-sign rows · birth_registry NULL entity_code · lingering idle transaction · rollback readiness unprovable. All clear throughout.