CURRENT-STATE.md -- the single status authority (Omega Cloud / VR1 DC-DC)

Authored 2026-07-18 by the grounding-audit Phase-2 ground-truth agent (charter: docs/audit/grounding-audit-charter.md, section 3) at repo HEAD e999b03 on branch dc-dc-stage3-phase2-dc-substrate. Every claim below carries its evidence (path:line, quoted command output, or commit hash). Claims that could not be evidenced read-only are marked UNKNOWN with what would resolve them. Nothing here is guessed.

STATUS OF THIS DOCUMENT: SIGNED by the operator 2026-07-19 (section 11; charter Phase 6 item 5). STANDING RULE (GA-R1, RATIFIED 2026-07-18 with amendments C1+C2 -- docs/audit/ga-rulings.md): no status claim is hand-written anywhere else; other documents point HERE; this document cites captured command output, and measurement always wins over it (C2). Other status surfaces are pointers or history; where one still carries a claim, it is a defect (Phase 1 proved they contradict: docs/audit/record-inventory.md, 12 groups; findings GA-F01..GA-F15).

1. Where the project IS

>>> STANDING OPERATOR DIRECTIVE, 2026-07-30: THE NEXT SESSION PROCEEDS TO THE JUJU DEPLOYMENT (STAGE 5). NO MATTER WHAT. <<<

Verbatim: "we have to continue to juju deployment next session no matter what".

Precondition work is DONE. Stage-5 preconditions were hardened across 2026-07-27..30 (allocation blocker closed, per-DC Octavia PKI generated AND reissued, gate integrity fixed, P7 wired, identity centralised). Further hardening, auditing, or record repair is OUT OF SCOPE next session unless it directly blocks the deploy.

This is the GA-F06 circuit-breaker made explicit by the operator. This project's measured failure mode is record-churn presenting as progress; the standing rule already says to STOP and escalate after one cycle of fixing records to match records. The directive removes the judgement call: open the stage and deploy.

Entry facts so the next session does not re-derive them:

• Run FROM voffice1 (D-128 Plane-2 host). juju 3.6.27 is there; the jumphost has none.
• preflight.sh currently exits FAIL on P5 only -- the credential register is red on PRE-EXISTING defects (SEC-021 declaration gaps, the SEC-020 identity conflation, three power-key asymmetries). Decide accept-or-remediate AT the gate; do not re-audit it. Every other gate is green, and P7 reports [ok] for both DCs on the headend.
• The deploy input is the bundle + that DC's -vips, -machines and -octavia-pki overlays.
• G17 arms at first boot -- it is a Stage-5 artefact, not a precondition. Capture it when the nodes come up rather than treating it as a blocker beforehand.
• Stage-5 runbook: runbooks/dc-dc-phase4-juju-bundle-per-dc.md; Step 4 delegates to phase-01-bundle-deploy.md verbatim.

2. What is APPLIED (from tofu state + live measurement, not from docs)

2.1 OpenTofu outer-root state (command: tofu -chdir=opentofu state list,

run 2026-07-18, 20 resources)

Office1 site (live, load-bearing):

• module.voffice1.libvirt_domain.vm + .libvirt_volume.disk + .libvirt_volume.seed + .libvirt_cloudinit_disk.seed (BUT see divergence 2.3-i: the cloudinit staging ISO no longer exists live)
• module.office1_opnsense.libvirt_domain.vm + .libvirt_volume.disk
• module.office1_network.libvirt_network.office1_local
• module.office1_storage.libvirt_pool.dc
• module.ubuntu_noble_base.libvirt_volume.base

Inter-site fabric and DC scaffolding:

• module.mesh_vr1_dc0_vr1_dc1.libvirt_network.link, module.mesh_vr1_dc0_office1.libvirt_network.link, module.mesh_vr1_dc1_office1.libvirt_network.link (the D-100 mesh triangle)
• module.vr1_dc0_planes.libvirt_network.plane["data-tenant" | "metal-admin" | "metal-internal" | "provider-public" | "replication" | "storage"] -- applied and live, but REMOVED from config (see 2.3-iii)
• module.vr1_dc0_storage.libvirt_pool.dc, module.vr1_dc1_storage.libvirt_pool.dc

2.2 Live environment (measured this session, 2026-07-18, read-only)

• hostname -> vcloud; uname -r -> 6.8.0-136-generic.
• virsh list --all -> exactly two domains, both running: voffice1 (Id 1), office1-opnsense (Id 2).
• virsh dominfo -> Autostart: enable on BOTH domains.
• ssh voffice1 'snap list maas lxd; uname -r' -> maas 3.7.2-17972-g.35e297c4d rev 41649 (3.7/stable), lxd 5.21.5-f2a1a0e rev 40074 (5.21/stable, held), guest kernel 6.8.0-136-generic.
• ssh office1-netbox 'curl -s -o /dev/null -w "netbox=%{http_code}" http://localhost:8000/' -> netbox=302 (service up, redirecting to login).
• ssh office1-tailscale 'tailscale status | head -1' -> 100.64.0.53 office1-tailscale ... linux - (subnet-router VM up).
• D-126 base leg: scripts/site-baseleg.sh check office1 passed at the Phase-1 snapshot (docs/audit/env-snapshot-20260718.md:16-17); not re-run this session.
• OPNsense edge version: 26.7 per confirmed as-built (docs/vr1-office1-as-built.md:42, updated 2026-07-18). NOT re-measured this session -- measuring requires the gated API credential path; see section 7.
• SEC-010 nft files (2026-07-23, operator-approved live re-assert, logged window ops-sec010-reassert): /etc/nftables-sec010.nft on voffice1 and BOTH DC racks now carries the idempotent declare-then-delete preamble -- sec010-fw double-restart converged with no rule duplication (4/2/2 drops; pre/post capture docs/audit/sec010-reassert-20260723.txt; per-host backup .pre-reassert-20260723 on each host). Generator fixed the same day (queue-pass changelog items 3/8).

2.3 State vs live vs config disagreements (REPORTED, not harmonized)

i. module.voffice1.libvirt_cloudinit_disk.seed is IN STATE but its staging ISO was deleted by the reboot -- it still plans as a benign re-create (1 of section 5's 6 adds). The FORCED REPLACEMENT it used to force on libvirt_volume.seed (the GA-F01 defect that stopped the apply) is FIXED: D-130 ADOPTED (a) + implemented 2026-07-19, verified by the v8/v7 captures (gate rows G4/G5). Mechanism history: docs/finding-20260718-voffice1-cloudinit-seed-replace.md:186-228. ii. Autostart: RESOLVED 2026-07-19 by the G6 state surgery (operator- ruled (ii), gate row G6): state now records autostart = true on both domains (state show | grep -c autostart -> 1 each); the 2 in-place changes are gone from the plan (section 5 capture). Guests were never touched. iii. The six vr1-dc0 plane networks exist live and in state but are REMOVED from config -- the INTENDED Model B relocation (planes get recreated inside vvr1-dc0 by the inner root, opentofu/vr1-dc0-substrate/main.tf:28). Their emptiness (0 leases, 0 attached domains) was verified in a PRIOR session (docs/dc0-deploy-readiness.md:43-45) and must be re-verified in the same session as any apply (finding doc:259-265). iv. RESOLVED 2026-07-19 (Batch 2, GA-F02): the readiness doc's falsified deploy-ready banner and its three contradictory plan counts are demoted -- status and the expected triple point HERE; the fresh- session banner points at the G9 canonical entry doc.

3. What is AUTHORED-BUT-NOT-APPLIED (in the tree, not in state / live)

• (2026-07-20) The step-B transit-reach work is APPLIED and verified -- voffice1 holds the region end 172.31.0.1/30 on enp2s0 (plus its in-guest drop-in /etc/netplan/60-transit.yaml); vvr1-dc0 answers at 172.31.0.2 (netplan set-name root cause fixed, kernel names enp1s0/enp2s0 kept); ssh -J voffice1 with the dc0 key works; rack->region ping 10.10.0.20 0% loss. Kea reservation re-keyed to the regenerated voffice1 MAC (incident, session changelog item 3). Consequence for the G10 bootstrap: call site-headend-install.sh with --transit-if enp1s0 --uplink-if enp2s0.

• module "vvr1_dc0" (opentofu/main.tf:360) -- the DC0 containment VM (416 GiB / 108 vCPU, D-121/D-123 sizing) + its disk, seed volume, and cloudinit seed. 4 of the 5 committed DC0 creates in the plan capture.

• module "vr1_dc0_uplink" (opentofu/main.tf:341) -- the D-125 simulated ISP NAT network 172.30.2.0/24 (capture lines 226-247). The 5th create.
• The ENTIRE inner root opentofu/vr1-dc0-substrate/ (main/variables/ versions.tf; no state file exists in that directory) -- inner storage pool, the six relocated planes, bridge-in WAN, and the rest of the Model B step-C build.
• The removal of module "vr1_dc0_planes" from the outer config (the 6 intended destroys; see 2.3-iii).
• autostart = true on voffice1/office1-opnsense in config (D-127) -- live-true but state-absent (2.3-ii).
• scripts/opnsense-plugins.sh + tests/opnsense-plugins/ (D-129 profile-installer; commit 4cefa8b). BUILT and green; the live apply against the edge is an operator-gated firmware mutation, NOT run (docs/design-decisions.md:4050-4056).
• SEC-010 enforcement artifact (scripts/site-headend-install.sh --host-nodes writing the transit FORWARD-drop) -- COMMITTED, applies on vvr1-dc0 at deploy step B; ledger row stays OPEN until applied+verified (bash scripts/ledger-scan.sh output, SEC-010 row).
• Stage 4-7 runbooks (runbooks/dc-dc-phase3..6-*.md) -- written, not executed (docs/dc-dc-deployment-workflow.md:873).

4. What is RULED-BUT-NOT-BUILT (ADOPTED/RULED with no artifact yet)

• D-121/D-122/D-123/D-124/D-125 (all ADOPTED/RULED, status lines at docs/design-decisions.md:3291,3474,3543,3635,3713): the DC0 deploy sequence they rule (steps A-E, docs/dc0-deploy-readiness.md:170-179) exists only as config + runbook. Nothing DC0 is built.
• vr1-dc1: topology ruled (D-100/D-101) and addressing RATIFIED 2026-07-21 (D-124 amendment: planes contiguous in 10.12.64.0/19, transit 172.31.0.4/30, uplink 172.30.3.0/24; apex confirm-free at authoring). Still UNBUILT: no vr1_dc1_rack_* variables, no dc1 substrate root; only its storage pool and mesh legs exist (state list, 2.1). Gate row G12 carries the remaining [V] leg.
• D-100 netem: mechanism authored (opentofu/modules/netem-link) but HELD as a comment in the root (opentofu/main.tf:309-319); placeholder parameters ruled for the rehearsal (readiness doc:73-75); final parameters unruled (section 8).
• D-129 Roosevelt metal-edge plugin profile (os-smart, os-nut | os-apcupsd, microcode, os-lldpd) -- recorded, inert until the Roosevelt edge build (docs/design-decisions.md:4030-4031).
• D-129 qga enablement: designed (opt-in module variable, default OFF; the guest-agent virtio channel is MISSING from the live edge domain) but not written; retrofit deferred to the edge's next scheduled restart (docs/design-decisions.md:4041-4047,4057-4063).

5. The outer plan count (wording per operator direction, GA-F01)

The true EXPECTED outer plan count is currently NOBODY'S:

• expected count: UNRESOLVED pending D-130;
• last captured: 7/2/7 (docs/audit/outer-plan-20260718.txt, line 428: "Plan: 7 to add, 2 to change, 7 to destroy." -- the ONLY citable plan-count source);
• pre-reboot gate was 5/0/6 (recorded at docs/dc0-deploy-readiness.md:59, docs/session-ledger.md:278).

The EXPECTED outer plan is ZERO DIFF ("no differences"), re-recorded 2026-07-22 with its evidencing capture (docs/audit/outer-plan-20260722-postdc1-converged.txt) after the G12 dc1 substrate step-A apply (saved plan 5/0/0 exact -- vvr1-dc1 + vr1-dc1-uplink adds only, zero touches to live resources). A future outer plan showing ANY diff is a STOP (investigate drift before touching anything). History: 7/2/7 post-reboot symptom -> 6/2/6 post-D-130 -> 6/0/6 post-G6-reconcile -> applied exact -> zero diff -> 1/1/1 (voffice1 transit, ruled+applied) -> 2/0/2 (rack netplan fix, applied) -> zero diff converged 2026-07-20 -> 1/1/0 netem-wire STOP -> targeted netem apply 1/0/0 exact -> 0/1/0 office1 residual -> G16 state surgery -> zero diff converged 2026-07-21 -> 5/0/0 dc1 substrate adds (G12 step A, saved-plan applied exact 2026-07-22) -> zero diff converged -> 0/1/0 office1 qga channel (G13 bundle, saved-plan applied exact 2026-07-23) -> zero diff converged (docs/audit/outer-plan-20260723-postqga-converged.txt, this entry) -> RE-CONFIRMED ZERO DIFF 2026-07-27 by the Stage-5 grounding audit, and for the FIRST TIME across ALL THREE roots in one session: the outer root on vcloud (docs/audit/outer-plan-20260727-stage5-audit.txt, "No changes") AND both inner roots on voffice1 (vr1-dc0-substrate and vr1-dc1-substrate, each "No changes", exit 0). Validity of the inner pair was established FIRST by proving the voffice1 clone's inner roots are byte-identical to main despite that clone being 105 commits behind (git diff --stat 61c416e..main -- opentofu/vr1-dc0-substrate/ opentofu/vr1-dc1-substrate/ opentofu/modules/ -> EMPTY); had that diff been non-empty the inner plans would have been UNMEASURED, not green. Full capture: docs/audit/stage5-live-measurement-20260727.txt.

6. Open gates

Owner legend: operator (human ruling/approval), session (agent work under gating), external (outside this repo/track). Type legend (GA-R6/E1): [V] = verification-type (closes on its named executable check); [R] = ruling-type (closes per a GA-R5 recorded ruling).

| G18 | IPAM apex completeness for the Octavia lb-mgmt plane -- does the charm-created lb-mgmt-net prefix get BACK-FILLED into the NetBox apex, or is that plane recorded as deliberately charm-owned and out of apex scope? | [R] ruling-type gate (GA-R6 rule 6): closes ONLY on a GA-R5 recorded ruling with the operator's exact utterance, dated, committed and pushed. DEFERRED BY OPERATOR DIRECTION 2026-07-27 until the cloud is LIVE and IPv6 behaviour has been observed -- it is not answerable from artifacts alone. BLOCKING: the deployment may NOT be declared complete while this is open. ANSWERABLE from Stage 5 onward (the prefix exists once Octavia deploys); BLOCKS the FINAL stage close / project close. | operator | OPEN 2026-07-27. WHY IT EXISTS: R8 ruled that Octavia creates and owns its own IPv6 lb-mgmt network. Measured consequence -- the octavia charm exposes NO CIDR, address-family or router configuration option (create-mgmt-network, default True, is the only related option), so the prefix is CHARM-GENERATED and cannot come from the D-111 carve. NetBox is therefore knowingly INCOMPLETE for exactly one plane. That is the authority-inversion concern the Stage-5 grounding audit's lens 7 raised (the apex being back-filled to match a deploy rather than driving it), and it is adjacent to the UNRULED D-136 NetBox-coupled render pipeline -- so ruling it early would pre-empt D-136. OPERATOR DIRECTION, verbatim: "leave this as an open decision that will need a ruling once we have the cloud live and we have a better read on the network and how everything is functioning with the addition of the new IPv6 configurations. Make this a gated decision so we cannot close the project (or whatever phase you think it best ruled in) without a ruling on this item." RELATED AND ALSO RECORDED: the absence of an lb-mgmt :x80 prefix in the VR1 ULA carve is CORRECT under R8, not a gap -- see the D-101 R8 ruling note; a future session must not "fix" it. Options to present at ruling time: (a) back-fill the charm-created prefix into NetBox post-deploy as a documented record; (b) record the plane as charm-owned and explicitly out of apex scope; (c) fold the decision into D-136's render-pipeline ruling if that is taken first. |

7. Version pins (measured; the authority for every pin)

The known-stale pin sites this table used to enumerate (the GA-F03/F04/ F05 tofu, OPNsense, and jumphost-name values -- stated token-free here so the scan does not count them) were ALL fixed or demoted to pointers in sweep Batches 2-3, 2026-07-19 (session changelog).

8. Open decision queue (the exact questions the operator must answer)

1. D-130: RULED 2026-07-19, ADOPTED (a) ignore_changes -- rotated to docs/design-decisions.md D-130 (question + utterance + captures).
2. D-100 netem parameter sub-item (gap #11) -- placeholder CONFIRMED STANDING 2026-07-21 (operator, GA-R5; D-100 sub-items block). No open question remains; the item is AWAITING EXTERNAL INPUT (the Roosevelt inter-DC link spec), trigger defined: re-tune via a gated apply when the spec exists, not before.
3. D-068 -- Vault substrate hardening. Items 2-3 RULED 2026-07-21; item 1 re-scoped plan DRAFTED 2026-07-23 (docs/D-068-vault-migration-plan-draft.md). Q1 RULED 2026-07-23 (rehearsal-scoped EOL risk-acceptance, posture 1b -- amendment in design-decisions.md is the authority). Q2 structural assumption RULED 2026-07-23 (Roosevelt baselines on 1.8/stable + a FUNDED remediation track; path 2a/2b/2c + deadline stay OPEN to Roosevelt design time on re-verified V1-V5). Q3 RULED 2026-07-23 (monthly-review lines delivered into ops-update-procedure 0c; design-time re-verify trigger). SOLE remainder on item 1: Q2 path selection (2a/2b/2c) + deadline, at Roosevelt Vault design time (item 1 Status line: OPEN on exactly that remainder -- reworded at the 2026-07-23 close for scan attribution).
4. D-071 -- ADOPTED 2026-07-21: all four policy points ruled (monthly review trigger; patch-only controller jumps; standing order; in-channel-only refreshes), each its own GA-R5 exchange -- status line in design-decisions.md is the authority. No open question remains; ops-update-procedure is the policy vehicle.
5. D-129 -- ALL FOUR sub-decisions RULED 2026-07-21 ((i) COS scrapes the edge in-scope per-DC; (ii) os-frr pinned to Roosevelt design; (iii) per-site Tailscale = dedicated node on metal-admin, edge excluded; (iv) MAAS hierarchy stays the time authority -- status line in design-decisions.md is the authority). No open question remains; the operator-gated live install of the ruled VR1 profile on office1-opnsense (scripts/opnsense-plugins.sh apply vr1-edge)
   • the qga retrofit at that edge's next restart are EXECUTION items tracked at gate G13.
6. Audit Phase 4 rulings: GA-R1..GA-R6 individually, plus the legal stage-status vocabulary A/B (GA-F10 operator note) -- each gated, one ruling per exchange.
7. D-132 -- Roosevelt per-DC MAAS topology (PROPOSED 2026-07-21, operator-pinned to the next deployment; three question groups: HA regions per DC, rack-top rack controllers, cross-site backup custody). Present at Roosevelt MAAS design time, not before.
8. D-131 sub-4 + pinned DNS architectural review (operator-directed 2026-07-21: stack best practices, forwarder security implications, vendor guidance on the "utility nodes" DC-to-DC configuration) -- executes at next-deployment design time; feeds the sub-4 ruling with the LP outcome.
9. D-137 -- credential mint-and-consolidate pipeline (PROPOSED 2026-07-25, operator-requested: "a durable rule to make sure when accounts are created there is a consolidation that happens every time"). Diagnosis is MEASURED: the SEC-009 audit is DECLARATION-based, so an undeclared secret is structurally undetectable -- creds-audit vr1-office1 read CLEAN on 2026-07-15 while four region-VM secrets minted 2026-07-13 sat undeclared, and admin.pass surfaced only 2026-07-25 (SEC-020). It is also wired in exactly ONE place and as PROSE (phase-3 runbook:498), not in preflight/cloud-assert/repo-lint/gauntlet -- and that line did not fire at EITHER DC standup (dc0 3 + dc1 1 undeclared at this session's open). THREE forks await a ruling, one exchange each (GA-R5): enforcement strength (advisory / preflight-blocking / plus a PreToolUse guard); --remote discovery scope (declared-directories vs broader sweep, a tenant-isolation concern); policy home (this D as authority with SEC-009 demoted to a pointer, vs policy stays in the ledger). NOT implemented -- PROPOSED means present options, never build. SUB-RULING 1 RULED 2026-07-25 (GA-R5, utterance quoted in the D-137 Status block): "Blocking in preflight" -- the check lands as a new Pn in scripts/preflight.sh and HARD-FAILS on any expected-but-absent / undeclared / per-DC-asymmetric credential. The PreToolUse guard and advisory-only were NOT adopted. SUB-RULING 2 RULED 2026-07-25: "Derive manifests from matrix" -- the matrix is SINGLE SOURCE, --render regenerates creds-manifests/*.manifest, gauntlet fails on rendered-vs-checked-in drift; accepted cost is that manifests become generated (their governance prose must become matrix fields, not be dropped). SUB-RULING 3 RULED 2026-07-26: "Declared locations only" -- a creds-manifests/vm-secret-locations list bounds --remote absolutely (no tenant surface touched, D-069 preserved). To be faithful the list must include the headend shadow stores (SEC-022), the region maas-secrets dir, and the three dirs outside the SEC-009 convention found by the creation-point inventory. SUB-RULING 4 RULED 2026-07-26: "D-137 is the authority" -- D-137 becomes the credential-lifecycle policy authority and the SEC-009 convention block demotes to a pointer (its founding history stays in the ledger as history); gates may then cite a D-number instead of an exposure register. SUB-RULING 5 RULED 2026-07-26: "Fold in as a D-137 invariant" -- the invariant is ONE IDENTITY SERVES ONE PRINCIPAL TYPE, enforced by the matrix principal column, so the SEC-020 conflation becomes machine-detectable and needs no separate D-number. ALL FIVE SUB-RULINGS RULED -> D-137 is ADOPTED 2026-07-26 and implementation is UNBLOCKED, with the build spec at docs/D-137-implementation-plan.md (Status line in design-decisions.md is the authority). Expect the first run to be RED by design: admin serves both a human and a service row, which is the defect the invariant names. Research capture: docs/audit/creds-creation-points-20260725.md -- its APPENDIX now carries the FULL per-row inventory (55 MINT rows with file:line, host, destination, stage and human/service classification), transcribed in-repo 2026-07-26 so the matrix SEED does not depend on a session transcript. TIER 1 BUILT 2026-07-26 (offline/STATIC half only; tiers 2-3 NOT built, and the preflight Pn of ruling 1 is NOT wired -- see the sequencing question below). Shipped: creds-matrix.tsv (72 rows), creds-matrix-notes.md, scripts/creds-matrix.py (S1 schema / S2 manifest coverage both-bounds / S3 render drift / S4 mint-ref resolution / S5 per-DC symmetry / S6 ruling-5 principal invariant / S7 notes integrity), harness tests/creds-matrix/run-tests.sh 24/24; gauntlet ALL GREEN (80), repo-lint 0-fail. SCHEMA AMENDED 10 -> 12 columns (operator-ruled 2026-07-26, "go with the 12-column amendment"): custody + notes-ref added and rows re-keyed to (credential, location), because a read-first round-trip check proved the 10-column form could not carry what ruling 2 forbids dropping -- and because ruling 3 puts four deliberate, reasoned credential copies INSIDE --remote's declared locations, where creds-audit.sh:63-67 would report every one as UNDECLARED. Detail + rationale in docs/D-137-implementation-plan.md; OPS under GA-R3, the five sub-rulings are untouched. RED BY DESIGN AND CORRECTLY SO -- 5 findings, do not "fix" by deleting rows: the ruling-5 identity conflation on maas-region-admin (its own SEC-020 defect), 3x EXPECTED-BUT-ABSENT for SEC-021 (dc0 declares neither an edge API credential nor a jumphost-consolidated power key, both of which dc1 declares), and the S5 asymmetry of dc0's divergently-named headend power key. 27 rows carry mint-ref=operator-terminal = the research FINDING 1 reproducibility debt, admitted and counted, not faulted. Acceptance test PARTIALLY met (corrected from the plan's original text): SEC-021's DECLARATION half is tier-1 detectable and is reproduced; SEC-022/-023 and SEC-021's on-disk half need tier 2. OPEN SEQUENCING QUESTION for the operator: ruling 1 lands the check as a BLOCKING preflight Pn and the first run is red, so wiring it hard-fails preflight.sh until the credential defects are remediated; wiring-as-ruled is the default and deferring until after per-row remediation is the departure. RESOLVED + EXECUTED 2026-07-26. Question as presented: wire the blocking Pn as ruled, or defer it until after per-row remediation. Operator answer, exact utterance: "wire tier 1 as the blocking preflight Pn". TIER 1 IS NOW WIRED as preflight.sh P5, blocking, ahead of the stage-2 reminders block so its verdict participates in the deploy decision; it FAILS CLOSED if the checker is absent (a missing file made python3 exit 2, which note maps to WARN -- so deleting the gate would have downgraded it to a warning; harness T9 encodes this). Tier 2's Pn is NOT wired and remains a separate decision: it needs --remote/--privileged and a caller-supplied --pending-stage, none of which belong in an unattended gate. CONSEQUENCE, STATED PRECISELY: preflight.sh exits 1 and P5 is one of the reasons -- but preflight was ALREADY exiting 1 before this change (P4: overlays/octavia-pki.yaml absent, and MAAS unreachable from the jumphost). P5 adds a fifth reason to an already-red gate; it did NOT flip preflight from pass to fail, and no deploy path that was open is closed by it. TIER 2 TOOLING BUILT 2026-07-26, NOT YET RUN LIVE. Shipped: creds-manifests/vm-secret-locations (ruling 3's absolute bound -- jumphost creds folders, the headend shadow stores of SEC-022, the region secrets dir of SEC-020, the three dirs outside the SEC-009 convention, the in-clone PKI overlay, and the DOCFIX-175 plaintext tfstate; tenant dirs are LOCAL-only so no tenant surface is reachable and D-069 holds by construction); creds-matrix.py --tier2 [--remote] (E1 expected-but- absent / E2 mode / E3 undeclared-at-a-declared-location, with an unreachable host SKIPPED explicitly because "could not look" must never read as "nothing there", and a --pending-stage selector so a not-yet-reached mint stage defers instead of failing -- the CALLER supplies it, the script carries no status claim, GA-R1); creds-audit.sh sprawl globs WIDENED for the SEC-023 blind spots (admin.pass, *.apikey, *.key, *.pem, *_ed25519, *_rsa, *openrc*) -- the old six patterns could not have seen the SEC-020 secret or the predicted Stage-5 ~/admin-openrc. Harnesses creds-matrix 33/33 and creds-audit 13/13 (was 7); gauntlet ALL GREEN (80), repo-lint 0-fail. LIVE TIER-2 SWEEP RUN 2026-07-26, read-only, no sudo (capture docs/audit/d137-tier2-sweep-20260726.txt; jumphost local + voffice1 + office1-netbox, stat over ssh, metadata only). SEC-021's ON-DISK half is now REPRODUCED as a named failure -- vr1-dc0-maas-power_ed25519{,.pub} are genuinely ABSENT from the dc0 jumphost creds folder, not merely undeclared. The sweep ALSO corrected two of its own false-greens, both found by running it: (a) an unprivileged [ -d ] on a root-owned directory is indistinguishable from absent, so /root/maas-secrets and /root/netbox-secrets first reported "does not exist" -- they are now correctly reported UNREADABLE ("could not look" is never "nothing there"), which is a FAIL, not a skip; (b) a role with any unprobed location no longer lets its other locations' listings manufacture false EXPECTED-BUT-ABSENT findings -- 14 headend/netbox rows are explicitly NOT JUDGED instead. STILL OUTSTANDING: the two root-owned directories need a privileged read, so SEC-022's shadow-store verification and the SEC-020 region secrets remain unconfirmed; that run is a remote-sudo shape and is operator-gated. ESCALATION PATH WIRED BUT BLOCKED 2026-07-26: --privileged adds a sudo -n retry attempted ONLY where an unprivileged probe returned unreadable, so the privileged surface stays as small as the ruling-3 bound keeps the search surface (still metadata only, stat, never content). The operator APPROVED the run, but the Claude Code AUTO-MODE CLASSIFIER denied the remote-sudo shape -- the same wall recorded at the 2026-07-23 close, whose noted fix is manual permission mode (a targeted ask rule is the alternative). NOT worked around. PRIVILEGED SWEEP COMPLETED 2026-07-26 (capture docs/audit/d137-tier2-privileged-20260726.txt; supersedes the unprivileged capture). ROOT CAUSE of the block was NOT the classifier overriding a rule: Bash(ssh * sudo *) was ALREADY in the project ask list, but the pattern needs a literal space before sudo and the command was ssh <host> 'sudo ...' -- the quote meant NO rule matched, so it fell through to the classifier. Fixed by adding the quoted variants (ssh *'sudo *, ssh *"sudo *, ssh *sudo -n *) plus a targeted ask rule for the privileged invocation; all are ask, never allow. Bash(ssh * virsh *) carried the IDENTICAL latent gap; it was flagged-not-fixed at discovery (hard rule 1) and then FIXED 2026-07-26 under operator direction (commit 6d43619, quoted variants added). MEASURED RESULTS -- capture docs/audit/d137-location-listing-20260726.txt (a stat listing; the tier-2 capture cited here previously is a checker VERDICT file and contains none of these values -- a GA-R1 rule 2 defect found by the committee and corrected in this commit). Region secrets dir: admin.apikey, admin.pass, db.pass, lxd-trust.pass (0600) -- precisely the SEC-020(i) carve-out list. Netbox dir: admin.pass, api.token, secret_key (0600). SEC-022 shadow stores confirmed. The claim that "ZERO undeclared files remain, so SEC-020/SEC-022 are fully accounted for" is WITHDRAWN -- it rested on a site-blind check (see the committee block below). INFERRED-FILENAME MISS (hard rule 2), corrected count: the session first reported SIX; the committee measured ~21, because only the rows the sweep physically touched were re-measured. .maas.cli was itself never measured and is WRONG -- the MAAS snap CLI stores its profile at ~/snap/maas/current/.maascli.db (measured this session). Matrix 77 rows at that point. The 9 findings then reported were true so far as they went, but the run that produced them is superseded below. COMMITTEE AUDIT 2026-07-26 (6 independent read-only lenses: correctness, coverage, claim-verification, ruling-fidelity, record-integrity, Roosevelt-transfer). VERDICT: the register's DESIGN holds, but TIER 2's VERDICTS ARE NOT TRUSTWORTHY as delivered and this document overstated what was verified. Every defect below was REPRODUCED, and FOUR lenses converged independently on the first one. Superseding figures (these are current; earlier figures in this entry are history): matrix 77 rows, creds-matrix harness 35/35, creds-audit 13/13, gauntlet ALL GREEN (80). The earlier "14 rows NOT JUDGED" was from the unprivileged run; the privileged run reports 2. The widened sprawl glob is *.pass, not admin.pass. Confirmed false greens (a real missing or misplaced credential passes a green sweep): (1) tier 2 is SITE-BLIND -- observed/declared are keyed by host-role only, so a file in the wrong site's folder satisfies the row; this masked SEC-021's opnsense-api.txt on-disk absence, so "SEC-021's on-disk half REPRODUCED" is corrected to the power-key artifacts ONLY; (2) probe_remote reports UNREACHABLE for a location it successfully read (empty-but-readable dir, or absent literal-file path), which gates the whole role and converts every absence FAIL at that role into an [ok]; (3) literal-file locations get no absent/unreadable detection at all -- the T33 fix covered only dir/* patterns; (4) an empty locations file bypasses ruling 3's refusal and affirms existence over zero locations; (5) no non-empty floor -- a 0-row matrix passes every check; (6) a mint-ref pointing at a directory crashes with exit 1, indistinguishable from findings, and S5/S6/S7 never run; (7) E2 MODE is custody-gated so 43 of 77 rows are never mode-checked; (8) S5's dc1->dc0 direction is untested -- deleting it leaves the harness green (the in-repo both-bounds precedent, in the symmetry check itself). Also outstanding: ruling 4's SEC-009 demotion is NOT done and its stated trigger (tier 2 built) has passed; the 12-column amendment is recorded in no D-numbered surface; sec-ref mis-attribution recurs (both juju-maas-user rows cite SEC-020; correct is SEC-018/-019); the libvirt SSH power password (standing rotation obligation, reenroll-hosts.sh:22-25) has no row; and T24 asserts literal finding strings, so remediating the ruling-5 conflation would turn the GAUNTLET red -- the test punishes the fix it exists to protect. Remediation is IN PROGRESS under operator direction ("Do as many as you can autonomously"); this block is the authority on what is fixed. REMEDIATION COMPLETE 2026-07-26 (phases 1-3), capture docs/audit/d137-tier2-postcommittee-20260726.txt (supersedes the pre-committee privileged capture, whose verdicts predate the site-scoping fix and are NOT comparable). ALL EIGHT false greens are FIXED and individually regression-locked; harness 44/44 (was 35), creds-audit 15/15, gauntlet ALL GREEN (80), repo-lint 0-fail. PROOF THE SITE FIX WORKS: E1 EXPECTED-BUT-ABSENT: dc0-edge-api 'opnsense-api.txt' now appears. That on-disk absence was masked in EVERY prior run, so SEC-021's on-disk half is NOW genuinely reproduced in full (the earlier withdrawal stands as history). The ~21 inferred filenames were re-measured against their mint-refs (octavia's 8 real basenames + its three SUBDIRECTORIES, which the bare ~/octavia-pki/* pattern matched none of; vault's init.txt; the tenant rows' <client>- instance prefix, now supported by a placeholder matcher); sec-ref mis-attributions corrected (both juju-maas-user rows SEC-020 -> SEC-018/-019; tfstate SEC-009 -> none); admin.pass's mint-ref moved from the consumer (:452) to the mint (:450); the libvirt power password and vault-ca-root added as rows. Matrix 81 rows. Findings 35 -> 13, all TRUE: SEC-021 (3x S2 + 3x E1), 3x S5 power-key asymmetry, the ruling-5 conflation, one SEC-022 shadow-store gap, SEC-024, and 2 rows disclosed as UNCHECKABLE. NEW EXPOSURE FOUND BY THE FIXED CHECKER -- SEC-024 OPENED: opentofu/terraform.tfstate.backup is mode 0664 (group- and world-readable) and carries the Office1 MAAS API key in plaintext per DOCFIX-175; the live state file is correctly 0600. Invisible to every prior control because the world-readable check was custody-gated and the siblings were undeclared. REMEDIATED 2026-07-26 (mode): operator-approved chmod 600 on terraform.tfstate.backup and .pre-G16-20260721, read-back verified -- all four state files now 0600 and the E2 finding cleared. SEVERITY CORRECTED first: the row's original "group- and world-readable" overstated it -- opentofu/ is 0700 and ~ is 0750, so no other account could traverse to it, and neither file is git-tracked, so SEC-004 was never implicated. It was defence-in-depth, not live exposure. The RETENTION question is RULED 2026-07-27 (GA-R5). Question as presented: whether to delete both pre-* state-surgery snapshots (cleanest, closes SEC-024 fully), keep both and let P5 keep watching them, or keep pre-G6 and delete pre-G16; noting both gates are CLOSED, both carry the MAAS API key in plaintext per DOCFIX-175, and deletion is irreversible with no other copy of that pre-surgery state. Operator answer, exact utterance: "Keep both". So terraform.tfstate.pre-G6-20260719 and .pre-G16-20260721 are RETAINED as the only record of what the state looked like before the two direct tfstate edits; both are 0600 and neither is git-tracked. SEC-024 stays OPEN as a standing WATCH rather than an open remediation: its mode defect is remediated, but the umask CAUSE was out of ruled scope, so a future apply may rewrite 0664 -- P5 is the detection. The key reaching state files in plaintext at all remains DOCFIX-175, rotation owed under SEC-018/-019. STILL OUTSTANDING (not done, not silently dropped): ruling 1's TIER 2 remote Pn (tier 1 + tier-2-local ARE wired -- see the tier-2 gate block below); --render's source-field derivation and the manifest flip to generated output; and the cardinality field remains largely inert with a one-token S5 bypass (per-DC -> singleton). (A dangling fragment here, left by an earlier edit in this same session, was repaired at session close -- noted rather than silently fixed, since CURRENT-STATE is the status authority and its defects are worth seeing.) CONSOLIDATION BATCH EXECUTED 2026-07-27 (operator question: is there a consolidated set of login creds on vcloud for every account that exists; operator direction after the audit: "clear the whole consolidation batch first"). Capture docs/audit/creds-consolidation-audit-20260727.txt; detail docs/archive/changelogs/changelog-20260727-creds-consolidation.md. Superseding figures: matrix 82 rows, creds-matrix harness 60/60 (was 56; V2 had shipped with ZERO cases), creds-audit CLEAN on all three sites, gauntlet ALL GREEN (81), repo-lint 0-fail, findings 13 -> 7. VERIFIED POSITIVE, both previously only asserted: the MAAS account set is COMPLETE -- all 6 accounts enumerated live (maas admin users read) are accounted for (admin + operator passwords on vcloud, juju-vr1-dc0/dc1 random+unstored BY RULING with their API keys present, MAAS/maas-init-node MAAS-internal) -- and tier-3 V1 now MEASURES maas-admin-password byte-identical to the headend source-of-record, so the stale-trap risk SEC-020 records is clear as of this date. DONE: dc0's SEC-012 power key consolidated to vcloud + .pub DERIVED (SEC-021(b) as written; measured first -- the headend maas-virsh_ed25519 and the snap's id_ed25519 are the SAME key, it IS dedicated (distinct from the dc0 service key), and dc0 using the snap default identity is SEC-016's ruled design, so NO re-mint and no live power path touched); dc1 svc .pub backfilled to the headend; NetBox web-GUI admin password consolidated (SEC-025 OPENED for the at-rest exposure the copy creates -- open rows 20 -> 21); V2 taught the ruled-deferral state so SEC-006's standing "revoke at completion of this deployment" ruling is ACKNOWLEDGED (still naming the credential as live and exposed) instead of failing every run -- reissuing it would have CONTRAVENED that ruling. Tier 3 is not in preflight P5, so the blocking gate's behaviour is unchanged. RESIDUAL 7 findings, expected, NOT green: dc0-edge-api x2 (the opnsense-api.txt re-mint is a live edge mutation, deliberately EXCLUDED from the batch -- sole remaining SEC-021(a) item), S5 x3 (RULED by SEC-016, the register needs a ruled-exception mechanism -- operator decision), S6 conflation x1 (the SEC-020 defect), E4 uncheckable x2 (Stage-5/6 rows). NEW FINDINGS LOGGED NOT ACTIONED: (i) NO registered root/console credential at EITHER DC edge -- measured absence of row, manifest entry and SEC row; what those passwords ARE is UNKNOWN and deliberately unprobed (hard rule 2), vector is the LAN-reachable GUI + serial console, not SSH (key-only, proven); (ii) two structural blind spots that let (i) hide -- S5 compares only cardinality=per-DC while all six per-site rows are office1-only, and vm-secret-locations declares no rack/edge/cloud/unit/client location though the checker accepts them (SEC-015 was rack-resident, so the class is real). The lesson generalises D-137's founding argument one level up: absence of a ROW is invisible to the register, so enumerating what EXISTS is a distinct control from auditing what is declared. RE-RUN 2026-07-27 (Stage-5 grounding audit), operator-authorized privileged sweep: python3 scripts/creds-matrix.py --tier2 --remote --privileged -> exit 1, capture docs/audit/stage5-creds-privileged-20260727.txt. This is a RE-CONFIRMATION of the 2026-07-26 privileged run against the current 82-row matrix, NOT a newly-closed item. Result: still exactly 7 findings, the same set (S2 dc0-edge-api, S5 x3 power-key asymmetry, S6 conflation, E1 dc0-edge-api on-disk, E4 x2 uncheckable) -- no drift in a day. All three root-owned locations read successfully via ESCALATION (sudo -n, metadata only): /root/maas-secrets/*, /var/snap/maas/current/root/.ssh/*, /root/netbox-secrets/*. ZERO E3 findings -- no undeclared file at any declared location. Note the checker's own honesty on the V1 arm, worth preserving: "V1 provenance: no identity had two digestible copies -- NOTHING was verified here; this is a skip, not a pass." QUEUED FINDINGS CAPTURED 2026-07-26 at session close: docs/audit/queued-findings-20260726.txt -- an end-of-session sweep for content that existed ONLY in the session transcript. Part A: the three secrets-storage items NOT already repo-carried (Tang/Clevis as the no-HSM unseal mechanism; MAAS 3.7's Vault integration MEASURED status: disabled, with the MAAS/Vault circular dependency that must be designed around before enabling it on bare metal; a Vault SSH CA to retire the static keypairs) plus sequencing advice -- framed so a future session does not re-propose what D-068's analysis and D-137 item 2(a) ALREADY carry. Part B: ten committee findings ACKNOWLEDGED but deliberately NOT acted on, the most consequential being that mint-ref line pins rot SILENTLY (S4 checks existence and EOF, never content, so every pin becomes wrong-but-passing when the runbooks are rewritten for Roosevelt) and that ruling-5 REMEDIATION and ruling-5 EVASION are indistinguishable to S6. Part C: items deferred by ruling, recorded so they are not later mistaken for oversights. NONE of it is ruled or built; cardinality (B6) needs an operator ruling.

9. Additional defect found while authoring (FIXED in sweep Batch 0.3,

2026-07-19 -- wrap-aware exclusion, GA-F15; history below)

ledger-scan.sh's mention-derived next-free counters (DOCFIX, BUNDLEFIX) are SELF-INFLATED by any doc that quotes a "next-free" value and lets the hyphenated token wrap onto a line without the words "next-free" -- the per-line exclusion filter (scripts/ledger-scan.sh:121-129, the grep -viE 'next[- ]free' at :124) then counts the quote as a real assignment; the script's own CAUTION comment (:112-120) documents exactly this failure class. It happened TWICE inside the audit itself on 2026-07-18: the Phase-1 env snapshot's wrapped next-free line inflated the BUNDLEFIX counter (051 -> reported 052), and this document's own first draft of this very section inflated the DOCFIX counter the same way while asserting DOCFIX was unaffected. Both audit surfaces were reworded token-free the same day and the counters re-verified at their true values (D=130, DOCFIX=197, BUNDLEFIX=052 -- see GA-F15). The D counter is header-authoritative and was never affected. Batch 0.3 hardened the scanner: an excluded line now also suppresses the immediately following line (the wrap case); counters re-verified unchanged post-fix. The authoring discipline stands regardless: never write a hyphenated register-token quote of a next-free value into any doc; state the numbers token-free as this section does.

10. How to verify this document (cold-session re-derivation)

Run read-only, from the repo root:

• Repo identity: git rev-parse HEAD; git status --short (this doc was authored at e999b03, clean tree).
• Applied set: tofu -chdir=opentofu state list (expect the 20 resources in section 2.1); virsh list --all; virsh dominfo voffice1 | grep -i autostart (and office1-opnsense).
• Authored-not-applied: grep -n '^module ' opentofu/main.tf (12 blocks; vvr1_dc0 + vr1_dc0_uplink absent from state list); ls opentofu/vr1-dc0-substrate/ (no *.tfstate).
• Plan count: read docs/audit/outer-plan-20260718.txt line 428. Do NOT re-run tofu plan casually against live state; if a fresh capture is taken, it must be written to a new dated capture file and cited here.
• Versions: tofu version; ssh voffice1 'snap list maas lxd; uname -r' </dev/null; uname -r; grep -A2 provider opentofu/.terraform.lock.hcl.
• Open decisions + SEC + next-free: bash scripts/ledger-scan.sh (BUNDLEFIX caveat: section 9); decision status lines: grep -n '^## D-' docs/design-decisions.md then read each Status line -- a decision's Status line in that file is the ONLY ruling authority.
• Gates: sections 1a and 4-7 of docs/audit/grounding-audit-charter.md; docs/audit/grounding-audit-20260718.md for GA-F01..F14.
• Live service probes: ssh office1-netbox 'curl -s -o /dev/null -w "%{http_code}" http://localhost:8000/' </dev/null (expect 302); ssh office1-tailscale 'tailscale status | head -1' </dev/null.

What this document is NOT built from and you must not rebuild it from: the prose of the 95 docs/changelog-*.md files, the docs/session-ledger.md narrative, or auto-memory -- all proven to carry false status (GA-F14, GA-F06..F08).

11. Operator signature (G11)

SIGNED 2026-07-19 (re-signature at audit exit; REPLACES the 2026-07-18 signature per GA-R1 rule 7 -- git history keeps it). Question as presented (Batch 6 item 6, 2026-07-19): read this document top to bottom, then provide the signature statement. Operator answer, exact utterance: "Reviewed, approved, continue." This document is the signed status authority; charter Phase 6 item 5 MET at this baseline (repo HEAD at signing recorded in the close commit).