diff --git a/.claude/skills/openstack-cloud-ops-consolidated-20260725.md b/.claude/skills/openstack-cloud-ops-consolidated-20260725.md
deleted file mode 100644
index fdc64f7..0000000
--- a/.claude/skills/openstack-cloud-ops-consolidated-20260725.md
+++ /dev/null
@@ -1,1544 +0,0 @@
-<!-- CONSOLIDATED SKILL SNAPSHOT for Chat/project upload.
-     Source: .claude/skills/openstack-cloud-ops/ (SKILL.md + references/) regenerated at repo HEAD 4dcf898, 2026-07-25.
-     WHY: the Chat-side mount is stale (docs/audit/skill-divergence-20260725.md). Chat's skill
-     surface is single-file, so the on-demand references are FLATTENED here into one document.
-     DERIVED artifact -- regenerate from the skill dir at each stage-close sweep (SKILL.md rule).
-     Authoritative copy remains .claude/skills/openstack-cloud-ops/ in the repo. -->
-
-# openstack-cloud-ops -- consolidated skill (Chat upload snapshot, 2026-07-25)
-
-================================================================================
-## SKILL.md (main entry -- always in context)
-================================================================================
-
----
-name: openstack-cloud-ops
-description: "Operate, install, extend, and troubleshoot the Omega Cloud - a commercial multi-tenant Charmed OpenStack (Caracal 2024.1) deployment managed with Juju and MAAS, with Vault TLS, OVN, Ceph, Octavia, and Magnum/CAPI tenant Kubernetes. Use this skill for ANY work touching OpenStack, Juju, MAAS, Magnum, CAPI, Ceph, OVN, Octavia, Keystone, Vault-for-OpenStack, tenant onboarding, or the repository this skill operates against - including writing or reviewing bash/python operational scripts, debugging failed deploys or cluster creates, runbook work, design-decision (D-NNN) discussion, and incident triage. Use it even for seemingly simple OpenStack questions: this deployment has strict operating discipline and known charm traps that make generic answers wrong."
----
-
-# openstack-cloud-ops
-
-Operating skill for the Omega Cloud: a commercial, multi-tenant, tenant
-self-administered OpenStack cloud, built as virtual rehearsals (VR0 single-DC
-"testcloud"; VR1 two-DC + Office1 headend) for a future bare-metal
-multi-datacenter deployment ("Roosevelt"). The CURRENT phase/stage lives in
-repo `docs/CURRENT-STATE.md` ONLY (GA-R1) -- never trust a phase claim from
-this file or memory. The governing design constraint is
-MINIMIZE DELTA TO ROOSEVELT: the runbooks and scripts are primary deliverables
-alongside the running cloud, so transferable answers beat quick fixes.
-
-## Step 0 - locate the source of truth
-
-This repository (GitBucket, git.baldurkeep.com) is authoritative for
-everything: bundle, runbooks, scripts, design decisions, as-built values. This
-skill is a discipline-and-routing layer OVER that repo, not a substitute for
-it. Never hardcode the repo's own name/path in a command -- it has already been
-renamed/forked once (see D-110) and will again; discover it fresh each session.
-
-1. Look for a local clone: a repo dir in the working tree, or a `$HOME` entry
-   containing `bundle.yaml` + `docs/design-decisions.md`. If found, confirm
-   identity with `git remote -v`, then `git log -1` to note HEAD and work from it.
-2. No clone and you have shell + network: ask the operator for the exact clone
-   URL (org/group and repo name -- do not guess or reuse one from memory; it
-   may have moved, per this same repo's own history). The repo may be private;
-   if the clone fails, ask the operator to provide access or the relevant files.
-3. No clone obtainable (e.g. chat without sandbox network): say so, ask the
-   operator to paste the relevant runbook/script, and proceed only on what is
-   actually in front of you.
-
-**Divergence rule:** if this skill and repo HEAD disagree, the repo wins -
-but FLAG the divergence to the operator rather than silently following either.
-The repo is a living draft; this skill's invariants (discipline, hardening)
-change slowly, its facts (IPs, versions, phase status) go stale fast.
-
-**Session bookends (GA-R1/GA-R4).** OPEN: read `docs/CURRENT-STATE.md` in full
-BEFORE any other doc (it is the only status authority), then `docs/session-ledger.md`
-+ `bash scripts/ledger-scan.sh` to recover what is in flight and reconcile it against
-repo ground truth (open decisions, open SEC count, next-free numbers). Re-do this
-after any compaction. CLOSE: a bounded ledger summary (15-line hard cap, GA-R4 rule
-1); the full session body goes to `docs/archive/` in the same close commit; commit
-and push -- a session ending without its bookend is treated as NOT durable by the
-next session. See `references/operating-discipline.md` (Session continuity).
-## Step 1 - detect the environment
-
-- **Live shell to the jumphost / infra** (Claude Code on `vcloud` or
-  similar): you may RUN read-only audits directly. Every mutation remains
-  individually human-gated - present the command, state what it changes, wait
-  for approval. A live shell relaxes the transport, never the discipline.
-- **Chat / no infra shell**: operate the gated copy-paste model - prepare
-  labeled blocks, the operator runs them and pastes output back. Never assume
-  a block ran or succeeded; wait for the pasted evidence.
-
-Read `references/operating-discipline.md` before doing either.
-
-## The three hard operating rules (non-negotiable)
-
-1. **Execute only the current runbook step, exactly as written.** No added
-   scope, no adjacent improvements, no live re-architecture mid-step. Findings
-   and improvement ideas are LOGGED (changelog / D-NNN proposal), never
-   executed live mid-step.
-2. **Never use an inferred value.** No IP, ID, name, or scope goes into a
-   command unless it was measured this session or carried from confirmed
-   as-built. If a value would be inferred: stop and measure it. Never run a
-   destructive or session-altering command from memory without confirming it
-   is the minimal correct action for the current live state.
-3. **Prefer dynamic lookups over hardcoded literals.** Discover VIPs, project
-   names, IDs, and version sets at runtime. Where a literal is unavoidable it
-   is tagged and centralized (`scripts/lib-net.sh`, `lib-hosts.sh`), keyed by
-   stable identity (CIDR, hostname) - never by drifting IDs.
-
-Corollary that governs everything: **verify before mutate**. A read-only audit
-precedes every mutation; destructive and secret-handling steps are gated
-individually, never batched.
-
-## Routing - where to go for what
-
-| Task | Read first |
-|---|---|
-| Any command block, script, or paste block you are about to write | `references/script-authoring.md` |
-| Deploy / redeploy / teardown (VR0, single-DC testcloud) | repo `runbooks/README.md`, then the phase-NN runbook; conventions in `references/operating-discipline.md` |
-| VR1 DC-DC buildout (two-DC + Office1 headend -- the current live mission) | repo `docs/CURRENT-STATE.md` FIRST (stage/gate STATUS lives there only), then `docs/dc-dc-deployment-workflow.md` (stage identity, links, gap register), then `runbooks/README.md`'s "VR1 DC-DC track" section for the `dc-dc-phase0..6` runbooks + `dc-dc-teardown-rollback.md`. SEPARATE track from VR0's phase-NN above -- do not conflate stage numbers between the two. |
-| Something is broken (triage, incidents) | `references/troubleshooting.md`, then repo `runbooks/appendix-A-troubleshooting.md` |
-| CAPI / Magnum / mgmt-VM recovery | repo `runbooks/ops-capi-recovery.md` |
-| Deliver ANY repo change (script, runbook, doc) | run `bash scripts/repo-lint.sh` + the touched script's `tests/<name>/run-tests.sh` BEFORE handing it over |
-| Pre-deploy gate (before add-model) | `bash scripts/preflight.sh` -- THE single entry; do not run the sub-gates piecemeal |
-| Is the cloud actually healthy? (post-deploy, post-restart, pre-change baseline, incident) | `bash scripts/cloud-assert.sh` (add `--capture` at deploy completion for the committed BOM) |
-| Full-cloud restart after outage/maintenance | repo `runbooks/ops-restart-procedure.md` |
-| VR1 site unreachable after a vcloud reboot (`ssh voffice1` / `office1-*` time out) | `bash scripts/site-baseleg.sh check office1` -- `office1-local` is an ISOLATED libvirt net, so the host's base L3 leg (`10.10.0.10/24` + compose route `10.10.1.0/24 via 10.10.0.20`) is dropped every reboot; the `After=libvirtd` unit re-adds it (D-126 amendment / D-128). If MISS and the unit is not yet installed: `sudo bash scripts/site-baseleg.sh apply office1`. This is the vcloud path; the workstation reaches the same over the tailnet (D-107). |
-| Starting any consequential live session | `bash scripts/run-logged.sh <label>` first (as-executed log; docs/as-executed-log-convention.md) |
-| Credential exposures / security TODOs | repo `docs/security-ledger.md` -- add a row, never only a script comment |
-| Resuming work / what is still in flight (esp. after compaction) | repo `docs/CURRENT-STATE.md` first, then `docs/session-ledger.md` + `bash scripts/ledger-scan.sh` to reconcile against repo ground truth |
-| Tenant onboarding / tenant self-service | repo `scripts/tenant-onboard.sh` + `runbooks/tenant-onboarding-v2-DRAFT.md` + `appendix-C/D` |
-| Network / plane / IPAM questions | `references/environment.md`, repo `scripts/lib-net.sh`, NetBox (the IPAM apex -- but during VR1 the WORKING apex is `office1-netbox`, 10.10.1.10, per DOCFIX-195; `netbox.baldurkeep.com` is a READ-ONLY v1 reference, write-back deferred to end-of-deployment) |
-| ANY change request to a built surface | grep repo `docs/design-decisions.md` for the governing D-NNN FIRST - PROPOSED/OPEN means the operator has not ruled: present options, do not implement |
-| Why is it built this way? / proposing changes | repo `docs/design-decisions.md` (D-NNN); grep before assigning a new number |
-| Versions, channels, pins | repo `docs/CURRENT-STATE.md` section 7 (VR1 substrate -- measured pin authority); `runbooks/appendix-B-asbuilt-version-lock.md` (VR0 charm channels) |
-| Environment facts (hosts, repo, planes) | `references/environment.md` |
-| OpenTofu / libvirt / MAAS / OPNsense IaC work (repo `opentofu/`) | `references/opentofu-provider-docs.md` FIRST (sources + fetch method), then repo `opentofu/README.md` (per-module ground truth, schema notes, audit findings -- but its OPNsense section is SUPERSEDED by D-112/D-113) |
-| Creating/changing a `libvirt_domain`; anything about nested KVM, a libvirt storage pool, LXD versions, an OPNsense edge, or a VM that boots wrong | `references/platform-traps.md` -- per-tool traps + version pins + a verbatim-error index (KiB-vs-MiB memory, `acpi=off`, missing `cpu` block = no `svm`, "in-place" bounces the guest, AppArmor on non-default pools, MAAS-vs-LXD 6.7, lxdbr0's dnsmasq, tcsh on the edge) |
-
-## Standard loops (repeatable session shapes)
-
-**Session bootstrap (jumphost):** Claude Code sessions launch from the repo
-root, always (GA-R7 rule 6 -- a session launched from a subdirectory gets its
-own empty project dir and a divergent auto-memory; the GA-F06 origin).
-`git -C "$REPO" pull` (set `$REPO` once per
-session -- see `runbooks/README.md` Conventions / `references/environment.md`) ->
-`bash scripts/repo-lint.sh` (0 fail expected) -> if touching the live cloud,
-`bash scripts/run-logged.sh <label>` to open the logged shell. Repo HEAD and a
-clean lint are the preconditions for everything else.
-
-**VR1 operating model (D-128 -- invariant; do not re-derive this each session):**
-Claude runs ON the vcloud jumphost -- do NOT relocate the session to a workstation.
-Work splits in two, origins FIXED BY DESIGN: **Plane 1** (substrate -- the OUTER
-`tofu` root `qemu:///system` + local `virsh`, creating the DC *host* VMs) runs on
-vcloud and has no Roosevelt analog; **Plane 2** (MAAS / NetBox / the INNER `tofu`
-root `qemu+ssh`-from-Office1 / tenant tests) EXECUTES on `voffice1` via `ssh
-voffice1 '...'` so runbooks read "from the Office1 headend" and transfer. Claude's
-host only picks the TRANSPORT, not where work runs. Durable Office1 reach = the
-D-126 base-leg oneshot (`scripts/site-baseleg.sh check office1` FIRST if `ssh
-voffice1` is dead post-reboot) -- NOT tailscale-on-vcloud (D-107 is the operator's
-WORKSTATION path / human GUI, left untouched). DCs sit outside the `/22` carve and
-keep the D-126 `-J`-through-`vvr1-dc0` shape. **Durable host->site reach is standing
-per-SITE tooling, DCs included (so the gap does not reopen per-DC):** `site-baseleg.sh`
-is site-keyed. At each DC standup, MEASURE how vcloud reaches that DC's containment/
-service net -- if it is an ISOLATED host-local net, add a MEASURED leg row + `install`
-the unit as part of standup definition-of-done (NEVER an inferred DC IP -- the harness
-fails on an un-commented DC supernet); a routed/NAT net or an already-reachable
-`qemu+ssh` path needs none. Register item 20 tracks this. **Rack-side twin invariant
-(D-131 sub-1, RULED 2026-07-21): every internet-isolated DC rack gets the repo-carried
-`scripts/dc-rack-net.sh install <site>` at standup (reboot-persistent rack bridge legs
-+ the node-DNS dnsmasq forwarder aliased on metal-admin, forwarding to region BIND over
-the rack's own transit) -- MAAS 3.7's rack-only agent resolver SERVFAILs on isolated
-racks, so WITHOUT this, commissioning silently times out (appendix-A carries the
-symptom pair).** Two measured MAAS traps with standing consequences: MAAS virsh PODS
-are refuted for this repo's DCs (per-machine `power_type=virsh` via
-`scripts/maas-node-power.sh` is the ruled shape -- D-103/D-123 amendments 2026-07-20),
-and a pod delete CASCADES to its linked machine records -- read the pod's machine list
-BEFORE any `vm-host delete`; non-empty = STOP (appendix-A, 2026-07-21 incident).
-**Per-DC power credential (SEC-012 dc0, SEC-016 dc1, RULED 2026-07-23 -- standing
-DC-standup invariant): each DC gets its OWN dedicated MAAS->libvirt power key, NEVER
-a cross-DC reuse.** The REGION's MAAS snap dials the power address, so the split is:
-the maas-node-power SCRIPT's mapping virsh uses the DC SERVICE key (via the region's
-`~/.ssh/config` Host <rack-transit-ip>), while MAAS's own power ops use the dedicated
-key installed in the snap (`/var/snap/maas/current/root/.ssh/` + a per-host `ssh
-config` block so each rack uses its own key). FRAGILITY: the snap-side key lives under
-per-revision `/var/snap/maas/current/` and may not survive a snap refresh -- re-assert
-after any refresh. Roosevelt analog: per-DC IPMI/BMC credentials.
-
-**Change-delivery loop:** grep for prior art (zeroth decision) -> grep
-design-decisions for the governing D-NNN -> edit -> `bash scripts/repo-lint.sh`
--> run the touched script's harness (create one if missing -- no script change
-ships without its harness) -> deliver with an entry in the SESSION changelog
-(ONE changelog per session, GA-R2/D1 -- never per-topic files) carrying a
-per-item revert. Under blanket approval, the changelog IS the review surface:
-every item states what, why (evidence), and how to revert. Changelogs are
-session-scoped scratch: consolidated per-stage at stage close, NEVER citable
-as status or decision authority.
-
-**Deploy loop (VR0, single-DC testcloud):** phase-00 runbook (D-061 destroy
-path) -> `bash scripts/preflight.sh` PASS -> phase-01..08 gated -> `bash
-scripts/cloud-assert.sh --capture` -> commit the asbuilt/ BOM.
-
-**Deploy loop (VR1 DC-DC, the current live mission):** read
-`docs/dc-dc-deployment-workflow.md`'s tooling gap register FIRST -- check
-whether the stage you're about to run has any open blocking item -> Stage 1
-(`dc-dc-phase0-vcloud-prep.md`) gated -> Stage 2..7 gated in order, per
-`runbooks/README.md`'s "VR1 DC-DC track" table -> if a stage's `tofu apply`
-fails partway, read `runbooks/dc-dc-teardown-rollback.md`'s rollback decision
-tree BEFORE reaching for a teardown (fix-forward is usually correct). Run
-`bash scripts/opentofu-validate.sh` before any tofu step; whether a given
-root/step has been exercised for real is a STATUS question -- check
-CURRENT-STATE, never this file's memory of it. **At STAGE
-CLOSE** (GA-R6): a stage or verification-type gate CLOSES only on a NAMED executable
-check whose captured output the closing commit cites -- prose cannot close a stage,
-and there is NO conditional close (a remainder splits into its own gate row or the
-stage stays open, E3). Ruling-type gates close per GA-R5 (recorded, pushed ruling).
-The close-out set is executable: gauntlet ALL GREEN, repo-lint 0-fail, the stage's
-GA-R2 consolidation commit landed, the GA-R7 memory review run, MERGE the stage
-branch to `main` (merge commit, NOT squash; operator-gated), then RETIRE the branch
-(local + remote). **ALSO sweep THIS skill in the same close:** fold in any new
-INVARIANT the stage established and reconcile any divergence from repo HEAD (facts
-delegate to the repo and go stale; invariants live here and must be kept current). The
-AUTHORITATIVE, versioned skill is THIS dir (`.claude/skills/openstack-cloud-ops/` -- SKILL.md
-+ references); keep it current here. THEN REGENERATE the dated single-file Chat-upload
-snapshot from it (concatenate SKILL.md + references -> `.claude/skills/openstack-cloud-ops-consolidated-<date>.md`,
-ASCII/LF byte-verified) so the Chat/project skill surface can be refreshed -- the snapshot
-is a DERIVED artifact, never the source, and the Chat mount going stale is a known failure
-mode (it caused a failed clone + a mis-shaped handoff, 2026-07-25; docs/audit/skill-divergence-20260725.md).
-The next stage branches off post-merge `main`. `main` is
-trunk-of-record only for stages that have merged (precedents: Stage 2 -> PR #1 `e468d2e`
-2026-07-15; Stage 3 -> merge commit 2026-07-21, vr1-dc0 scope, dc1 HELD under G12). See
-`docs/dc-dc-deployment-workflow.md` "Cross-cutting discipline".
-
-**Incident loop:** capture the verbatim error -> `bash scripts/cloud-assert.sh`
-(the service-own-verdict sweep localizes the layer) -> appendix-A by exact
-message -> recorded fix, gated -> log the finding (new root causes become
-appendix-A/DOCFIX material).
-
-## Record authority and session discipline (GA-R1..R7, ratified 2026-07-18)
-
-Ratified text: repo `docs/audit/ga-rulings.md` -- this is the operating summary.
-
-- **`docs/CURRENT-STATE.md` is the ONLY status authority (GA-R1).** Stage,
-  gates, plan counts, version pins, decision-queue state live THERE and nowhere
-  else; other surfaces point or are history. Any commit that changes a status it
-  carries updates it in the SAME commit (C1; repo-lint L10 enforces). It is
-  authoritative over documents, never over measurement -- a fresh capture wins
-  and corrects it in the capture's commit (C2).
-- **Plan counts and versions are quoted only from captured command output** --
-  a dated capture file or a quoted command + output; never from memory or
-  another document's prose (GA-R1 rule 2). Legal stage/gate status tokens are
-  OPEN / BLOCKED / HELD / CLOSED, used only in CURRENT-STATE (vocabulary ruling,
-  Option A: readiness is not a state; event words are history, never states).
-- **Rulings are gated like mutations (GA-R5).** ONE decision per operator
-  exchange -- batch adoptions are invalid. A ruling exists only when its Status
-  line quotes the question AND the operator's exact utterance, dated, committed
-  and pushed before dependent work. Ambiguous/template answers rule NOTHING:
-  stop and ask. Never adopt from an inferred or reconstructed ruling -- an
-  operator ruling is a value under hard rule 2.
-- **D-number admission (GA-R3):** a new D-number needs architectural consequence
-  beyond the stage, a Roosevelt-delta (the A1 test: a Roosevelt build session
-  would grep it before touching a built surface), or supersession. Everything
-  else is OPERATIONAL: runbook edit / session-changelog line / as-built row,
-  never a D-number. Entries carry [ARCH]/[OPS] tags; doubt resolves DOWN to OPS.
-- **Memory governance (GA-R7):** auto-memory records observations and
-  conventions ONLY -- never operator policy, priorities, or postures. Any
-  memory claiming operator intent is PROPOSED until confirmed verbatim; remove
-  on discovery. Durable observations GRADUATE to their repo surface; memory is
-  never the only copy. Stage close includes a full memory review (rules 1-4).
-- **Reconciliation circuit-breaker.** If you have been fixing records to match
-  records for more than one cycle without touching the actual deliverable,
-  STOP and report to the operator. Record-churn presenting as progress is this
-  project's measured failure mode (GA-F06); escalating is the correct move.
-
-## Posture
-
-- This is a commercial multi-tenant cloud with HARD tenant isolation (SCS
-  Domain Manager persona). Treat tenant-visible surfaces and cross-domain
-  boundaries as security-relevant in every change.
-- The operator community here values debate and industry best practice over
-  quick fixes. Push back with sources when you disagree; own mistakes plainly
-  and concisely. Fabricated flags, values, or version numbers are the cardinal
-  sin - if you have not verified an option name or version, say so and verify.
-- Responses stay concise. Decisions get explicit rationale.
-
-
-================================================================================
-## references/operating-discipline.md (loaded on demand in Claude Code; inlined here for Chat)
-================================================================================
-
-# Operating discipline
-
-How work is executed on this cloud. These conventions exist because the
-runbooks and scripts ARE the product: a fix that works but is undocumented,
-unrepeatable, or Roosevelt-incompatible is a failure.
-
-## The gated execution model
-
-Every command block is labeled so a command line is never mistaken for prose,
-and so mutation risk is explicit (same convention as the repo runbooks):
-
-- `RUN -- <loc>` - the block CHANGES state; run it at <loc> (jumphost, a unit
-  via `juju ssh`, the mgmt VM...).
-- `CHECK (read-only) -- <loc>` - safe to re-run.
-- `GATE:` - hard stop. Do not proceed unless the stated condition holds.
-- `Expect:` - what a passing result looks like. Always state it: the operator
-  should never have to guess whether output is good.
-- `> CAUTION:` - destructive, secret-handling, or irreversible.
-
-Sequence discipline: read-only audit -> present the mutation -> operator
-approves/runs -> verify the result -> next step. One gated mutation at a time;
-never batch destructive steps. If output comes back unexpected, STOP and
-re-derive from the live state - do not improvise a correction inline.
-
-**Chat (no shell):** you prepare blocks, the operator runs and pastes output.
-Treat pasted output as the only evidence; a block you wrote but saw no output
-for did not happen.
-
-**Live shell:** you may execute `CHECK (read-only)` blocks yourself. `RUN` and
-`> CAUTION:` blocks still get presented and human-approved first - state what
-will change and why it is the minimal correct action.
-
-## Irreversible / one-shot / secret steps
-
-- Start every consequential session with `bash scripts/run-logged.sh <label>`
-  (opens a script(1)-logged shell to ~/as-executed/; index the session in
-  logs/as-executed-index.md -- content NEVER commits, the index always does).
-- Retrieve the exact prior working command from the as-executed log or runbook
-  VERBATIM. Never improvise vault init, unseal, authorize-charm, CA issuance,
-  or anything one-shot. (DOCFIX-006: a mis-redirected `vault operator init`
-  loses the unseal keys forever.)
-- Secrets never transit argv, clipboard, scrollback, or /tmp. Capture straight
-  to a 0600 file under $HOME with `umask 077`; unseal via hidden prompt (L4);
-  transfer via base64 pipe into a root-written 0600 file (L-P6-4). Never echo
-  a secret to verify it - verify by length/format from the file.
-- Never run `maas list` (prints the API key - DOCFIX-016). Never trust a juju
-  action's human-formatted output for a captured secret or cert - pull from
-  `--format json` (indented YAML block-scalars corrupt PEMs; DOCFIX-021).
-- Authorize charms with short-lived child tokens: `juju run` persists action
-  params in the operation log (DOCFIX-011).
-
-## Record-keeping: D-NNN / DOCFIX-NNN / BUNDLEFIX-NNN
-
-- `D-NNN` - design decisions (`docs/design-decisions.md`). Append-only:
-  superseded entries stay in place, marked, with the superseding entry
-  appended. `DOCFIX-NNN` - runbook fixes. `BUNDLEFIX-NNN` - bundle fixes.
-- ALWAYS grep the repo for the next free number before assigning one -
-  collisions have happened. State "next-free verified" when you assign.
-- PARALLEL WORK numbering: when more than one workstream edits the shared numbered
-  ledgers (this repo + a parallel Claude Code stream), do NOT each independently grab
-  "next-free" -- that collides. One stream owns a given number/block; each DECLARES every
-  identifier it consumes in its commit; the other re-greps AFTER the parallel push lands
-  and resumes above it. `scripts/ledger-scan.sh` derives next-free from decision HEADERS
-  (not prose mentions -- a "next-free D-072" pointer must not inflate the count).
-  Keep "Next-free:" pointer lines on ONE line (a word-wrapped continuation escapes the
-  line-based exclusion); or just rely on the scan, which is the next-free authority.
-- Mid-task findings are logged as proposals, not acted on (hard rule 1).
-  A finding that changes a runbook becomes a DOCFIX; one that changes
-  architecture becomes a D-NNN with status PROPOSED until the operator rules.
-- Status vocabulary: PROPOSED/OPEN -> ADOPTED/DECIDED -> SUPERSEDED (by
-  D-MMM). Do not implement PROPOSED items.
-- Before acting on any change request, grep design-decisions for the
-  governing decision on that surface (and its dependents - e.g. a runbook
-  step may rely on the current state). Finding a PROPOSED/OPEN decision
-  means presenting its recorded options for a ruling, not picking one.
-
-## Delivery rules (files handed to the operator)
-
-- Multi-file changes ship as repo-relative ZIPs, never loose files (the
-  Windows/GitHub Desktop loose-file workflow misplaces them).
-- Everything committed is ASCII-only, LF-only. Validate before delivery:
-  non-ASCII with `grep -nP '[^\x00-\x7F]'` (or a Python byte read); CR bytes
-  with a Python `data.count(b"\x0d")` - a `grep $'\r'` false-positives on
-  `$r...` tokens. Non-ASCII in OpenStack config has caused silent daemon
-  failures (mod_wsgi UnicodeDecodeError).
-- On-box script delivery over `juju ssh` goes as a base64 pipe decoded to a
-  file, then the FILE is executed - never a raw heredoc (paste-mangling and
-  stdin-consumption both bite; see script-authoring on `read` vs pipes).
-- Windows-side steps are PowerShell-native (no bash heredocs, no backslash
-  continuations). The operator commits from Windows; the jumphost only pulls.
-
-- Credential exposures and security obligations get a ROW in
-  docs/security-ledger.md at discovery time (owner + status) - never only a
-  script-comment note; the ledger is reviewed at every phase-00 and handoff.
-- Under operator-granted blanket approval, the delivery contract is: implement,
-  then hand over ONE cumulative repo-relative ZIP plus a changelog where every
-  item states what changed, the evidence for why, and a per-item revert. The
-  changelog is the review surface; opinion-weighted calls are flagged as such.
-
-## Session continuity: the in-flight ledger
-
-Long sessions on this cloud get COMPACTED, often several times. Work that lives only in
-chat scrollback is lost at compaction. `docs/session-ledger.md` is the durable record of
-what is IN FLIGHT (active build, backlog, operator-gated items, open decisions, numbering
-state, state facts). Standing practice:
-- Read the ledger AND run `scripts/ledger-scan.sh` at session start; reconcile.
-- The scan is the DRIFT CHECK: it derives open decisions (last Status line per block, so an
-  amendment closes it), OPEN security rows, and next-free numbers straight from the repo.
-  The narrative ledger must not claim CLOSED what the scan shows OPEN, nor omit what it
-  surfaces. A ledger without this check rots (cf. D-070's unexercised-snapshot critique).
-- Update the ledger at every deliverable/commit -- it is a standing deliverable like the
-  changelog. Changelog = what changed; ledger = what is still open.
-
-## Boundary mutations: adds-before-removes with a readback gate
-
-When tightening a security boundary (SG rules, firewall, policy) that a live flow depends on,
-NEVER remove the permissive rule before the specific replacements are proven present. Create
-the narrow rules, READ THEM BACK (fail if any is missing), and only THEN remove the wide rule
-by its MEASURED id. There must be no window in which a required flow (e.g. the magnum
-conductor -> mgmt apiserver poll) is unauthorized. Verify the tightened boundary by FUNCTIONAL
-outcome afterwards, not by assuming the rule text is sufficient.
-
-## Attestation gates for unautomatable safety items
-
-Some acceptance items cannot be scripted -- e.g. a SECOND person performing the Vault unseal
-(D-069). Never auto-pass such an item. Gate it on a ledger ROW (docs/security-ledger.md):
-report PASS_PENDING_MANUAL while the row is OPEN, PASS only when it is attested CLOSED/rehearsed,
-HOLD if the row is missing. Auto-passing an undone safety item is the exact failure D-070 retired.
-
-## Debate and correction norms
-
-- Challenge weak reasoning with sources; the operator prefers industry best
-  practice over the quick fix and will push back hard on unverified claims.
-  When challenged, verify (docs, source, live probe) rather than defend.
-- Own mistakes plainly, in one or two sentences, then fix. No self-flagellation.
-- When a prior decision looks wrong, propose superseding it through the D-NNN
-  process - do not quietly deviate from it.
-
-## Troubleshooting entry discipline
-
-Before any server-side hypothesis for "X used to work, now it doesn't" on a
-web UI: eliminate client state first (incognito window, ~10 seconds), then a
-server-side curl, THEN hypothesize. Before any command that acts on tenant
-resources: confirm which project/domain scope the shell holds
-(`openstack token issue`-level certainty) - `server create` and friends use
-ambient scope silently. Full triage method: references/troubleshooting.md.
-
-## Guards are load-bearing: reword the content, never weaken the check
-
-When a repo-lint guard (or any fail-closed check) goes RED on text you
-believe is legitimate, the fix is to REWORD the text or add the guard's
-own documented opt-out marker -- never to loosen the guard. Precedent: L3
-correctly flagged the config.xml tombstones; the tombstones were reworded
-and the guard kept. (Rotated from the session ledger's standing-lessons
-block, 2026-07-19.)
-
-
-================================================================================
-## references/environment.md (loaded on demand in Claude Code; inlined here for Chat)
-================================================================================
-
-# Environment - Omega Cloud (VR0 DC0 testcloud)
-
-Facts here are ANCHORS, not command inputs. Anything marked (verify) must be
-re-measured or re-read from the repo/live cloud before use in a command -
-hard rule 2 applies. Snapshot date: 2026-07. The repo is fresher than this file.
-
-## The three deployments (this file covers VR0 in detail; VR1 is a pointer)
-
-- **Testcloud (VR0 DC0, now):** four KVM host VMs (openstack0-3) on a single
-  hypervisor, managed by MAAS + Juju. Single-DC virtual rehearsal. The rest
-  of THIS file is VR0's own ground truth.
-- **VR1 DC-DC (in progress, D-100..D-110):** two-DC + Office1-headend
-  rehearsal -- VR0's testcloud host is being REPURPOSED into DC1 (not a
-  second concurrent cloud). This file does NOT carry VR1's own facts (Office1
-  network, DC1/DC2 mesh links, per-DC MAAS/Vault roots, etc.) -- those live
-  in `docs/dc-dc-deployment-workflow.md` (master tracker: stage status +
-  tooling gap register, read this first for any VR1 work) and
-  `docs/dc-dc-buildout-design.md` (the design itself). Runbooks:
-  `runbooks/README.md`'s "VR1 DC-DC track" section. IaC: `opentofu/`
-  (UNVALIDATED -- see its own README).
-- **Roosevelt (future):** bare-metal, multi-DC, commercial production
-  (3310 Roosevelt Blvd, Eugene OR). Dedicated node roles (gateway/controller/
-  compute split) - unlike the hyperconverged testcloud. Every design choice is
-  judged by its transfer to Roosevelt -- VR1 is the rehearsal for THIS, not
-  an end in itself.
-
-## Stack (verify against appendix-B for pins)
-
-Charmed OpenStack Caracal 2024.1 - Juju/MAAS/component versions live in
-`runbooks/appendix-B-asbuilt-version-lock.md` (VR0) and `docs/CURRENT-STATE.md`
-section 7 (VR1 substrate) - Vault TLS (charm-pki
-root CA), OVN 24.03, Ceph Squid, Octavia (amphora), Barbican,
-mysql-innodb-cluster, RabbitMQ, Magnum + magnum-capi-helm driver + azimuth
-(SUBSTRATE below the charms -- pins + traps in `references/platform-traps.md`:
-libvirt/KVM via the `dmacvicar/libvirt` OpenTofu provider `0.9.8` (tofu +
-component pins: `docs/CURRENT-STATE.md` section 7, the pin authority);
-**LXD pinned to the `5.21` LTS track** -- MAAS 3.6/3.7 cannot talk
-to LXD >= 6.7, D-114; OPNsense edges driven by REST API, D-113; the vcloud
-host is ITSELF a KVM guest, so nesting is a per-level requirement)
-capi-helm-charts (kubeadm engine), in-cloud single-homed CAPI mgmt VM
-(capi-mgmt-v2, k8s-snap, D-035). NetBox is the IPAM apex: never hand-edit
-downstream MAAS or overlays for network values.
-
-## Control points
-
-- **Jumphost:** `vcloud` - all live commands run here. Has juju,
-  the openstack CLI (SNAP - cannot read /tmp; use $HOME), jq, kubectl.
-- **Repo:** `https://git.baldurkeep.com/OpenStack/openstack-caracal-dc-dc`
-  (web) / `.../git/OpenStack/openstack-caracal-dc-dc.git` (clone) -- a
-  documented ANCHOR FACT (this repo's name/path has already changed once, see
-  D-110; re-verify with `git remote -v` before trusting it, same as any other
-  fact in this file). repo-lint: allow-selfref. Operator commits from Windows
-  (PowerShell / GitHub Desktop - strips exec bits; `.gitattributes` pins LF);
-  the jumphost only pulls.
-- **Session `$REPO` convention:** set `$REPO` once per session to your clone's
-  root (see `runbooks/README.md` Conventions); every runbook RUN block
-  references `$REPO`, never a hardcoded clone path. `repo-lint` L9 enforces
-  this for scripts/RUN-blocks/skill files.
-- **Juju model:** `openstack`. **MAAS profile:** `admin` (call
-  `maas admin ...` directly; NEVER `maas list` - it prints the API key).
-- **Management substrate (verify; NEVER touch in teardown):** the MAAS
-  machines hosting juju, lxd, and tailscale are hard-excluded from teardown
-  scripts. Resolve system_ids live via `scripts/lib-hosts.sh` - system_ids
-  are re-minted on every re-enrollment (DOCFIX-040).
-
-## The six network planes (D-052 / D-053; verify against scripts/lib-net.sh)
-
-| Plane | CIDR | Carries | Notes |
-|---|---|---|---|
-| provider-public | 10.12.4.0/22 | Public API VIPs + tenant FIPs (Pattern A, D-060) | gw .4.1; untagged |
-| metal-admin | 10.12.8.0/22 | MAAS PXE, operator/admin endpoint, default binding | gw .8.1; DC-local |
-| metal-internal | 10.12.12.0/22 | ALL service-to-service control (internal API, DB, MQ, Vault, peers) | tagged VID 103 via br-internal; no gw |
-| data-tenant | 10.12.16.0/22 | Tenant Geneve overlay | no gw |
-| storage | 10.12.32.0/22 | Ceph public | no gw |
-| replication | 10.12.36.0/22 | Ceph cluster (OSD replication) | no gw |
-
-- API VIPs: triple per clustered charm (provider/admin/internal), matching
-  last octet in the .50-.60 band, 11 clustered charms (verify count live).
-- Tenant pool: 10.20.0.0/16 (hybrid model D-016 - pool in NetBox, per-project
-  /24s Neutron-managed). Avoid collisions with capi-mgmt (10.20.0.0/24) and
-  existing tenant /24s - list live before allocating.
-- Provider NIC rule (D-057/D-060): the provider uplink must land in OVS
-  `br-ex`, never enslaved to a Linux bridge, and `br-ex` carries no L3 config.
-
-## Repo map (what lives where)
-
-- `bundle.yaml` - the canonical bundle; VIPs/units baked in for testcloud.
-- `runbooks/phase-00..08-*.md` - the gated deploy sequence, in order, each
-  ending in a hard gate. `runbooks/README.md` has the label conventions.
-- `runbooks/appendix-A-troubleshooting.md` - symptom->cause->fix index keyed
-  by D-NNN/DOCFIX-NNN. First stop for any known-looking failure.
-- `runbooks/appendix-B` - version lock. `appendix-C` - identity/RBAC.
-  `appendix-D` - Magnum trust model. `ops-capi-recovery.md` - CAPI/Magnum
-  post-deploy operations.
-- `docs/design-decisions.md` - the D-NNN architectural record (append-only
-  discipline; superseded entries stay, marked).
-- `scripts/` - phase scripts + `lib-net.sh` / `lib-hosts.sh` (pinned values)
-  + tenant onboarding/acceptance. `tests/<script>/` - offline fakebin
-  regression harnesses.
-- `policies/domain-manager-policy.yaml` + `policies/overrides.zip` - the SCS
-  Domain Manager RBAC override (D-051/D-064); the zip ships IN the bundle
-  (keystone resources, DOCFIX-071) and provider-bundle-check drift-guards it.
-- Operational tooling (2026-07 hardening set): `scripts/preflight.sh` (single
-  pre-deploy gate: lint -> bundle invariants -> Charmhub channel assert -> live
-  MAAS pre-flight), `scripts/repo-lint.sh`/`repo_lint.py` (static hygiene,
-  L1-L6), `scripts/cloud-assert.sh` (behavioral verifier + `--capture` BOM to
-  `asbuilt/<date>/`), `scripts/run-logged.sh` (as-executed session logger),
-  `scripts/channel_assert.py`. `runbooks/ops-restart-procedure.md` (full-cloud
-  restart). `docs/security-ledger.md` (exposure/obligation rows).
-  `logs/as-executed-index.md` (committed index; log content stays jumphost-only).
-- No KVM snapshot restore path exists (D-070 superseded D-012):
-  rebuild-from-runbooks IS the restore path; baselines come from cloud-assert
-  `--capture`.
-- **VR1 DC-DC additions (2026-07-09/10), not part of VR0's map above:**
-  `docs/dc-dc-deployment-workflow.md` (master tracker), `docs/dc-dc-buildout-
-  design.md` (design), `docs/design-decisions.md` D-100..D-110,
-  `runbooks/dc-dc-phase0..6-*.md` + `dc-dc-teardown-rollback.md`,
-  `opentofu/` (libvirt/MAAS/OPNsense IaC, UNVALIDATED -- see its own
-  README), `netbox/dc-dc-prefixes-import.py`, `scripts/dc-dc-*.sh` (MTU/Ceph
-  budget calculators, Ceph replication tooling).
-
-## Identity / tenancy model (see appendix-C/D and D-051, D-064, D-066)
-
-Domain-per-client. Operator provisions: domain + a domain `manager` (SCS
-Domain Manager persona - the plain `admin` role is NOT domain-confinable) +
-quotas. The tenant self-services everything inside: projects, users, roles
-(only member + load-balancer_member assignable - never admin/manager),
-app credentials, networks, templates, clusters. Magnum mints per-cluster
-trust app-creds carrying the trustor's roles frozen at mint time (D-039:
-trustor needs load-balancer_member or CAPO 403s on Octavia). Cluster create
-must run as a password identity, not an app-cred (trust-creation block,
-D-066). Every identity command is DOMAIN-QUALIFIED (`--domain`,
-`--user-domain`, `--project-domain`) - scope-default resolution silently
-lands in the wrong domain and 404s misleadingly.
-
-
-================================================================================
-## references/platform-traps.md (loaded on demand in Claude Code; inlined here for Chat)
-================================================================================
-
-# Platform traps and version pins -- libvirt/KVM, MAAS+LXD, OPNsense
-
-The substrate BELOW the cloud (the hypervisor, the provisioner, the edge
-routers) has its own version boundaries and its own silent-failure modes.
-Every item below is either (a) sourced to a vendor/upstream URL, or (b)
-MEASURED on this project and sourced to the repo's own D-NNN / changelog.
-Nothing here is generic advice: each entry exists because it cost, or would
-have cost, a session.
-
-Companion files: `references/opentofu-provider-docs.md` (provider schema +
-fetch methodology), `references/troubleshooting.md` (method). Start at the
-verbatim-error index at the bottom if you have an error string in hand.
-
-## Version pins that actually matter (and why)
-
-| Thing | Pin | Why the pin exists |
-|---|---|---|
-| `dmacvicar/libvirt` provider | `0.9.8` | 0.9.0 was a compatibility-BREAKING rewrite; anything remembered from 0.8-era examples is wrong (see below) |
-| OpenTofu | live pin: CURRENT-STATE.md section 7 | Stage-1 as-run value is historical (git history) |
-| LXD | **`5.21` LTS track** | MAAS 3.6/3.7 is INCOMPATIBLE with LXD >= 6.7 (D-114; see below) |
-| MAAS | 3.7.2 (VR0) | the LXD ceiling above is a property of MAAS 3.6/3.7 |
-| OPNsense | live pin: CURRENT-STATE.md section 7 (26.7 as of 2026-07-18) | ISC-DHCP left core AT 26.1 -- Kea/dnsmasq only on every later release (see below) |
-| Vault charm | `1.8/stable` | 1.16 is an incompatible charm, deliberately NOT an upgrade (appendix-B, D-068) |
-
-Charm channels/revisions are appendix-B's job, not this file's. This file
-covers only the substrate the charms sit on.
-
----
-
-## 1. dmacvicar/libvirt provider (pinned 0.9.8)
-
-### 1a. The 0.8 -> 0.9 break invalidates most examples you will find
-
-v0.9.0 (2025-11-08) is a deliberate, compatibility-breaking rewrite on the
-plugin framework, with the design principle "HCL maps almost 1:1 to libvirt
-XML"; the legacy provider stayed on the `v0.8` branch. v0.9.1 (2025-11-30)
-then code-generated the schema from libvirt's XML schema, renaming attributes
-again (`unit` -> `memory_unit`, `os.arch` -> `os.type_arch`, `os.machine` ->
-`os.type_machine`, `os.kernel_args` -> `os.cmdline`, camelCase -> snake_case
-throughout).
-- https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.0
-- https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.1
-
-**Consequence:** blog posts, StackOverflow answers, and model memory almost
-all describe 0.8. Nested structures are attribute-style objects
-(`os = { ... }`, `devices = { ... }`), not HCL blocks. Confirm against
-`docs/resources/*.md` + `examples/*.tf` at the pinned tag, or
-`tofu providers schema -json`.
-
-### 1b. Bare `memory` is KiB, not MiB -- 1024x too little RAM (DOCFIX-188)
-
-The 0.9.1 migration guide states the rule explicitly: "Value/unit pairs are
-explicit -- whenever libvirt exposes a value with a unit attribute the
-provider now has two attributes (`memory` + `memory_unit`, `capacity` +
-`capacity_unit`, etc.). **Leaving the unit unset lets libvirt use its
-default.**"
-(https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.1)
-
-And libvirt's default is KiB: "The units for this value are determined by the
-optional attribute `unit`, which defaults to 'KiB'"
-(https://libvirt.org/formatdomain.html#memory-allocation).
-
-So `memory = 2048` with no `memory_unit` is **2 MiB**, not 2 GiB. In 0.8,
-`memory` meant MiB -- that is exactly how this shipped here.
-
-    memory      = var.memory_mib
-    memory_unit = "MiB"      # REQUIRED. Never omit.
-
-Signatures (all measured, 2026-07-12): QEMU cmdline `-m size=2048k`;
-`virsh dominfo` -> `Max memory: 2048 KiB`; a FreeBSD guest echoes
-`/boot.config` (262 bytes of serial output) and then triple-faults handing off
-to `/boot/loader`. `tofu validate` CANNOT catch it (the attribute is
-optional) -- `scripts/opentofu-validate.sh` check **S1** does.
-Evidence: `docs/archive/changelogs/changelog-20260712-libvirt-memory-unit-rootcause.md`,
-`docs/archive/incident-20260712-opnsense-edge-boot-triplefault.md`.
-
-The provider's own current domain examples now carry `memory_unit = "MiB"`
-(`docs/resources/domain.md`) -- a fresh reader of the docs would get this
-right; a reader of any 0.8-era example would not.
-
-### 1c. No `features` block => `acpi=off` => FreeBSD panics (DOCFIX-190)
-
-The whole `features` attribute is optional, so omitting it is schema-valid --
-and libvirt then renders the machine with `acpi=off` (measured on the QEMU
-cmdline: `-machine pc-i440fx-noble,...,acpi=off`).
-
-    features = {
-      acpi = true
-      apic = {}          # acpi is a Boolean; apic is a nested object
-    }
-
-(schema: `docs/resources/domain.md`, `features.acpi` (Boolean),
-`features.apic` (Attributes).)
-
-Three distinct consequences, only one of which is loud:
-- FreeBSD/OPNsense **panics** (it finds the local APIC via ACPI's MADT and
-  ships no `atpic` fallback): `panic: running without device atpic requires a
-  local APIC` -> `db>` prompt -> domain shows `running` while burning 100% of
-  one core forever.
-- Linux guests boot but degrade: no clean ACPI shutdown/reboot signalling.
-- **MAAS drives power off/on via ACPI**, so a MAAS-managed node VM without
-  ACPI can only ever be hard-stopped. That would have been a nasty Stage-3
-  debug.
-Evidence: `docs/archive/changelogs/changelog-20260712-libvirt-acpi-kernel-panic.md`.
-Guard: `scripts/opentofu-validate.sh` check **S2**.
-
-### 1d. No `cpu` block => generic CPU => NO `svm` => nested KVM impossible
-
-Found 2026-07-13. With no `cpu` attribute, libvirt hands the guest a generic
-emulated CPU model with no virtualization flag. Measured: host is an **AMD
-EPYC 9965**, the default-CPU guest was handed an **`Opteron_G3`**. Nothing
-errors -- the guest just has no `/dev/kvm` and no `svm` in `/proc/cpuinfo`.
-
-Ubuntu's own nested-virt guide states the guest-side requirement: set the
-guest `cpu mode` to `host-model` or `host-passthrough` for the guest to see
-`svm`/`vmx`
-(https://ubuntu.com/server/docs/how-to/virtualisation/enable-nested-virtualisation/).
-
-    cpu = {
-      mode = "host-passthrough"
-      # per-caller: pass svm through, or disable it as router hardening
-      features = var.expose_nested_virt ? [] : [
-        { name = "svm", policy = "disable" }
-      ]
-    }
-
-**The host side is a SEPARATE requirement and bites at every level.** The
-vcloud host is ITSELF a KVM guest (`systemd-detect-virt` -> `kvm`), so nesting
-must be enabled at each level, not just ours:
-- check: `cat /sys/module/kvm_amd/parameters/nested` -> `Y` or `1`
-  (Intel: `/sys/module/kvm_intel/parameters/nested`)
-- persist: `options kvm-amd nested=1` in a file under `/etc/modprobe.d/`
-  (same source as above)
-
-Why this matters here (D-114): LXD **virtual machines** are qemu/KVM guests,
-so MAAS composing service VMs inside a site containment VM needs working
-nested KVM at that depth; and `nova-compute` on the DC nodes needs it one
-level deeper still. `modules/node-vm` still has the missing-`cpu`-block defect
--- logged, NOT fixed, because DC1 is gated behind Office1
-(`docs/archive/changelogs/changelog-20260713-d114-voffice1-nested-virt.md`).
-
-### 1e. "will be updated in-place" DOES NOT mean "the guest stays up"
-
-A plan line reading `libvirt_domain.vm will be updated in-place` **bounced a
-live guest** (measured 2026-07-13: uptime 8m36s -> 6s; ~30s with no routing and
-no DHCP on the Office1 edge). "In-place" is a statement about the Terraform
-RESOURCE, not about the domain.
-
-Upstream confirms the mechanism: the v0.9.4 release notes describe domain
-update as "updating a domain (e.g. changing memory) **would undefine and
-re-define it**" (the 0.9.4 fix was only to preserve NVRAM/TPM files across
-that undefine), and v0.9.6 added "configurable update shutdown behavior so
-domain updates can request guest shutdown and wait with a configurable timeout
-before forcing a stop."
-- https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.4
-- https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.6
-
-**Rule: treat ANY `tofu apply` whose plan touches a `libvirt_domain` as an
-OUTAGE of that guest. Schedule and gate it as one.** Read the plan's resource
-list before applying; `0 to change` on the domains is the only assurance that
-a running guest is not about to bounce
-(`docs/session-ledger.md`, standing lesson 2).
-
-Corollary (DOCFIX-187/DOCFIX-188): some domain attributes are CREATE-time to
-libvirt (max boot memory, `machine`, `cpu`). The provider will happily plan an
-in-place update that libvirt then ignores. If a changed value does not show up
-in `virsh dominfo`, `destroy` + `undefine` the domain and re-apply (volumes
-survive an `undefine`).
-
-Second corollary (measured 2026-07-20/21): the undefine/redefine also
-**REGENERATES every UNPINNED NIC MAC**. The plan reads `0 to add, N to change,
-0 to destroy`, the apply succeeds -- and every touched domain now has brand-new
-MACs. Anything that keys on those MACs is silently stranded: in the 2026-07-21
-commissioning incident all 9 MAAS-enlisted nodes became UNKNOWN at PXE (no
-"Performing PXE boot" event, silent 30-min timeouts), because a serial-console
-retrofit apply had drifted every boot-interface MAC. **Rule: any domain whose
-MACs are load-bearing (MAAS-enlisted nodes above all) carries config-pinned
-MACs** -- `mac = { address = ... }` per interface; see `modules/node-vm`'s
-`interface_macs` + `tests/node-vm`. VR-only trap: Roosevelt metal has fixed
-MACs.
-
-### 1f. Two more upstream behaviours worth knowing (from the release notes)
-
-- `capacity_unit = "GiB"` on a volume caused **"Provider produced inconsistent
-  result after apply"** on every apply before 0.9.4 (libvirt normalizes to
-  bytes). Fixed in 0.9.4 -- if you see that error string, check the provider
-  version first.
-- `tofu destroy` of a **`dir` pool** used to DELETE the backing directory
-  (`StoragePoolDelete`). Since 0.9.4 the directory is preserved by default,
-  with an explicit `destroy.delete = true` to opt back in. Relevant to
-  `modules/dc-storage-pool`.
-  (https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.4)
-- **UNVERIFIED:** the 0.9.4 notes name a `destroy.shutdown.timeout` option
-  while `docs/resources/domain.md` documents `destroy = { graceful, timeout }`,
-  and I could not find the 0.9.6 update-shutdown attribute documented at all.
-  Before relying on either, read the real schema:
-  `tofu providers schema -json | jq '.provider_schemas[].resource_schemas.libvirt_domain'`.
-
-### 1g. `forward=bridge` networks + `br_netfilter`: a global FORWARD-drop silently kills bridged frames (D-125)
-
-A `libvirt_network` with `forward = { mode = "bridge" }` (dmacvicar schema:
-`bridge = { name = "<host-bridge>" }`, no `ips`, no NAT) attaches guest taps to a
-**pre-existing** host bridge -- libvirt does NOT create the bridge, so it must
-already exist (declare it in the host's netplan, not the tofu) or the network
-fails to start. This is the Model B "bridge-in" WAN path (D-125): the inner
-OPNsense WAN rides `br-vr1-dc0-wan` out through `vvr1-dc0`'s IP-less uplink NIC to
-the single vcloud ISP NAT.
-
-Two silent-failure traps ride along:
-
-- **`br_netfilter` makes bridged frames traverse the L3 `FORWARD` chain.** So a
-  GLOBAL forward-drop -- `iptables -P FORWARD DROP`, or an nftables forward hook
-  with `policy drop` and no interface match -- silently kills the WAN bridge even
-  though it is "just L2". Keep any DC-LOCAL forward-drop (SEC-010) **scoped to the
-  transit interface** (`oifname/iifname "<transit>"`), never global. Note
-  `net.ipv4.ip_forward=0` is L3-only and does NOT affect pure bridging -- do not
-  reach for it expecting to gate a bridge, and do not assume `ip_forward=1` is
-  required just because an older NAT-based design needed it.
-- **Foreign-MAC egress across a nested bridge is unprovable until apply.** When the
-  bridged guest is itself inside another guest (OPNsense inside `vvr1-dc0`), the
-  outer NAT's `virbr` sees a foreign source MAC arriving on the containment VM's
-  port; an anti-spoof/nwfilter drop there blackholes egress. `tofu validate` is
-  clean regardless. TEST IN ISOLATION FIRST: attach a throwaway guest to the
-  bridge, confirm it gets an address and pings out, BEFORE the real chain rides
-  it. (D-125's fallback for this failure is double-NAT: masquerade at `vvr1-dc0`
-  instead of relying on nested L2.)
-
-## 2. AppArmor blocks qemu on any non-default pool path
-
-libvirt's stock `abstractions/libvirt-qemu` grants qemu the DEFAULT pool path
-(`/var/lib/libvirt/images`) only. A pool anywhere else is blocked by AppArmor
-**even with perfect POSIX permissions**, and the failure names nothing:
-
-- libvirt/qemu says only: `Could not open '<path>': Permission denied`
-- the actual denial is in the kernel log:
-  `apparmor="DENIED" operation="open" profile="libvirt-<domain-uuid>" name="<path>"`
-- the domain DEFINES fine and fails at START -- so `tofu apply` can "succeed"
-  into a dead guest.
-
-Upstream (still open, provider issue #920, with the same workaround):
-https://github.com/dmacvicar/terraform-provider-libvirt/issues/920
-
-Fix, in the vendor-sanctioned override include (survives package upgrade --
-do NOT edit the shipped abstraction):
-
-    # /etc/apparmor.d/local/abstractions/libvirt-qemu
-    /var/lib/libvirt/vr1/** rwk,
-
-This is now installed by `bash scripts/prereqs/install-apparmor-libvirt.sh`
-(pool parent overridable via `VR1_POOL_PARENT`), wired into
-`scripts/prereqs/install-all.sh` and reported by `check-prereqs.sh`. It cost a
-session on 2026-07-12 (DOCFIX-186) because it existed only as hand-applied host
-state; `docs/archive/changelogs/changelog-20260713-apparmor-libvirt-prereq.md`.
-
-## 3. MAAS + LXD
-
-### 3a. MAAS 3.6/3.7 is INCOMPATIBLE with LXD >= 6.7 (D-114)
-
-Canonical's own announcement: LXD 6.7 "consolidates some API endpoints" that
-MAAS's pinned **pylxd 2.3.5** cannot speak to (fixed in **pylxd >= 2.3.9**,
-not yet in a MAAS release). Verbatim guidance: "We recommend using LXD <=6.6
-or the 5.21 LTS release until further notice."
-https://discourse.maas.io/t/maas-incompatibility-with-lxd-6-7/15749
-
-VR0 runs LXD **5.21.4** and is therefore safe by accident of timing; D-114
-makes it a decision. **LXD 5.21 LTS is supported to June 2029**
-(https://canonical.com/blog/lxd_5-21-0_lts).
-
-**The live hazard is the snap auto-refresh, not the install.** LXD's docs:
-"By default, installed snaps update automatically when new releases are
-published to the channel they're tracking"; the `latest` track "typically
-points to the latest feature release", is "a continuously rolling release
-track", and is "not recommended for general use"; a bare `snap install lxd`
-uses the most recent LTS track, "which is currently 5.21".
-https://canonical.com/lxd/docs/latest/reference/releases-snap/
-=> install/refresh explicitly on `5.21/stable` and verify the tracked channel
-(`snap list lxd`, `snap info lxd`) before blaming MAAS for an LXD it can no
-longer talk to.
-
-### 3b. LXD's own bridge runs a dnsmasq DHCP server -- MAAS says turn it off
-
-"Bridges created by LXD are managed, which means that in addition to creating
-the bridge interface itself, LXD also sets up a local `dnsmasq` process to
-provide DHCP, IPv6 route announcements and DNS services to the network"
-(`ipv4.dhcp` defaults to **true**).
-https://canonical.com/lxd/docs/latest/reference/network_bridge/
-
-MAAS's own LXD VM-host procedure therefore has you disable exactly that,
-because MAAS must be the DHCP/PXE authority for the machines it composes:
-
-    lxc network set lxdbr0 dns.mode=none
-    lxc network set lxdbr0 ipv4.dhcp=false
-    lxc network set lxdbr0 ipv6.dhcp=false
-
-https://canonical.com/maas/docs/how-to-manage-machines
-
-This is the concrete form of D-114's DHCP warning. On `office1-local`,
-**OPNsense/Kea is authoritative** (10.10.0.0/24, pool .100-.199). Two DHCP
-servers on one L2 is an intermittent, genuinely unpleasant failure. Never
-bridge `lxdbr0` onto the site LAN without disabling its DHCP first.
-
-### 3c. Two different LXDs in this cloud -- do not conflate them (D-114)
-
-Conflating these caused a real, recorded error:
-- **Juju-created LXD CONTAINERS** on the OpenStack nodes (`lxd:N` placements
-  in `bundle.yaml`, 21 of them). MAAS never sees these and never needs to.
-- **A MAAS-registered LXD KVM host** (the VR0 `lxd` machine) into which MAAS
-  **COMPOSES VMs** (`maas $PROFILE vm-host compose ...`) -- VR0's `tailscale`
-  machine is one. These ARE MAAS machines: enlisted, commissioned, deployed,
-  powered, released.
-
-D-114 extends the second pattern per site; the first is explicitly out of
-scope. Also note: MAAS only sees VMs in the LXD **project** the VM host was
-registered with -- VMs in other projects are invisible to it and unaffected
-(MAAS LP#1923251, https://bugs.launchpad.net/maas/+bug/1923251).
-
-**Composed-VM networking -- MEASURE, do not assume.** A MAAS-bundled copy of
-the MAAS docs states: "When composing a virtual machine with LXD, MAAS uses
-either the 'maas' LXD profile, or (if that doesn't exist) the 'default' LXD
-profile. The profile is used to determine which bridge to use."
-(served by a MAAS instance's own docs:
-https://maas.cloud.cbh.kth.se/MAAS/docs/cli/how-to-use-lxd.html -- **I could
-NOT locate this sentence on canonical.com/maas.io today; the docs site has been
-reorganized and the old URLs 404. Treat the profile->bridge mechanism as
-PLAUSIBLE-BUT-UNCONFIRMED against a primary source.**) Since a composed machine
-that PXEs on the wrong L2 is the failure this predicts, do the cheap
-measurement instead of trusting either source: `lxc profile show maas` /
-`lxc profile show default` on the LXD host, and confirm the NIC's parent bridge
-before composing.
-
-Because LXD **VMs** (not containers) are qemu/KVM guests, this pattern needs
-nested KVM at whatever depth the LXD host sits -- see 1d.
-
-## 4. OPNsense edge (traps entered at 26.1; they persist on the live 26.7)
-
-### 4a. `config.xml` is GUI-owned. Do not hand-author it. (D-112, D-113)
-
-The config-xml path is **DELETED** (template, renderer, ISO builder, and the
-module's `config_seed` volume + cdrom disk -- D-113 amendment, 2026-07-13).
-Configure the edge over the **REST API** (`scripts/opnsense-api.sh`); mint an
-API key with `scripts/opnsense-bootstrap-apikey.sh`. Three separate defects
-(no sshd, no console, an inert `<dhcpd>` block) all traced to hand-writing
-that file, and a full-config push DROPS ~667 migration-populated elements --
-including the box's only two firewall pass rules -- surviving only on an
-UNDOCUMENTED self-heal at boot. If you think the API cannot express something,
-that is a finding to raise against D-113, not a reason to write XML.
-
-Two traps that follow:
-- **A config ISO can NEVER be read on a nano image** (D-112, root-caused in
-  upstream `opnsense/core:src/sbin/opnsense-importer`: the importer probes for
-  a read-only root and `bootstrap_and_exit 0`s on a pre-installed image before
-  scanning any media). Any instruction to build one is a trap.
-- Factory default: LAN `192.168.1.1/24`, **SSH disabled**, **all inbound
-  blocked on WAN**. An unanswered ping to the WAN address is NOT a fault.
-
-### 4b. ISC dhcpd is GONE from core in 26.1 -- an `<dhcpd>` config is inert
-
-26.1 release notes: "ISC-DHCP moves to a plugin. It will be automatically
-installed during upgrades. **It is not installed on new installations because
-it is not being used**, but you can still install and keep using it." Also:
-"Dnsmasq is now the default for DHCPv4 and DHCPv6 as well as RA out of the
-box."
-https://docs.opnsense.org/releases/CE_26.1.html
-
-So on a fresh 26.1-or-later image: an ISC `<dhcpd>` block configures nothing (that was
-DOCFIX-193), and the GUI default backend is **dnsmasq**, not Kea. This edge
-deliberately runs **Kea** (10.10.0.0/24, pool .100-.199, first real lease
-served to `voffice1` 2026-07-13).
-
-### 4c. REST API: auth, endpoints, and the reconfigure step everyone forgets
-
-- Auth is **HTTP basic with an API key/secret pair**, not the root password:
-  "API access is part of the local user authentication system, but uses
-  key/secret pairs to separate account information from machine to machine
-  communication." URL pattern: `https://<host>/api/<module>/<controller>/<command>`.
-  https://docs.opnsense.org/development/how-tos/api.html
-- Kea DHCPv4 (exact paths):
-  `/api/kea/dhcpv4/get`, `/set`, `/add_subnet`, `/set_subnet/$uuid`,
-  `/del_subnet/$uuid`, `/add_reservation`, `/set_reservation/$uuid`,
-  `/get_reservation`, `/add_option`; service control:
-  `/api/kea/service/reconfigure|restart|start|stop|status`.
-  **A `set*` call only edits config -- it is NOT live until you POST
-  `/api/kea/service/reconfigure`.** A silently-unapplied change looks exactly
-  like a change that did not take.
-  https://docs.opnsense.org/development/api/core/kea.html
-- **Firewall rules have a self-rollback safety net -- use it.** The filter
-  controller exposes `savepoint`, `apply/$rollback_revision`,
-  `cancel_rollback/$rollback_revision`, `revert/$revision`: "When calling
-  `savepoint()` a new config revision will be created and the timestamp will be
-  returned for later use. **If the `cancelRollback(savepoint)` is not called
-  within 60 seconds, the firewall will rollback to the previous state**."
-  For any remote rule change on a router you reach THROUGH that router, a
-  savepoint means a mistake self-reverts instead of locking you out.
-  https://docs.opnsense.org/development/api/core/firewall.html
-- Do NOT re-implement vendor internals to bootstrap. OPNsense stores API
-  secrets as `crypt(secret,'$6$')`; we deliberately do not mint keys offline --
-  a format drift would fail SILENTLY (keys that never authenticate). Call the
-  vendor's own model instead (`scripts/opnsense-bootstrap-apikey.sh`).
-  (D-113 amendment.)
-
-### 4d. root's shell is tcsh -- `$(...)` dies QUIETLY over SSH
-
-Measured on the Office1 edge: root's shell is **tcsh**. tcsh has no `$(...)`
-command substitution (it uses backquotes); a `$(...)` inside a quoted remote
-command is rejected with:
-
-    Illegal variable name.
-
-It already cost a defect: a pre-install snapshot silently no-op'd and the
-install then ran with no rollback point behind it
-(`docs/archive/changelogs/changelog-20260713-office1-dhcp-apply.md`). Because the step was
-non-fatal, nothing stopped.
-
-**Always feed remote commands to `sh -s`:**
-
-    ssh -i "$OPNSENSE_SSH_KEY" root@<edge> 'sh -s' <<'SH'
-    ...POSIX shell here...
-    SH
-
-(tcsh's substitution syntax: https://man.freebsd.org/cgi/man.cgi?query=tcsh)
-
----
-
-## Verbatim error -> cause index (grep this first)
-
-| Exact string you see | Cause | Where |
-|---|---|---|
-| guest triple-faults right after echoing `/boot.config`; `virsh dominfo` -> `Max memory: 2048 KiB`; QEMU `-m size=2048k` | `libvirt_domain.memory` with no `memory_unit` -- KiB, not MiB | 1b |
-| `panic: running without device atpic requires a local APIC` (then `db>`, 100% of one core, domain "running") | no `features` block -> `acpi=off` | 1c |
-| guest has no `/dev/kvm`; `/proc/cpuinfo` has no `svm`; CPU model reads `Opteron_G3` on an EPYC host | no `cpu` block -> generic emulated CPU | 1d |
-| `Could not open '<path>': Permission denied` (domain defines, then fails to START; nothing names AppArmor) -- check `dmesg` for `apparmor="DENIED" operation="open" profile="libvirt-<uuid>"` | non-default libvirt pool path not granted in AppArmor | 2 |
-| `Provider produced inconsistent result after apply` on a volume with `capacity_unit` | provider < 0.9.4 | 1f |
-| plan says `will be updated in-place`, guest uptime resets anyway | provider undefines + redefines the domain | 1e |
-| MAAS commissioning times out at 30 min, NO PXE event for a known machine | an in-place apply regenerated unpinned NIC MACs; MAAS records stale | 1e |
-| `Illegal variable name.` from an `ssh root@<edge> '...'` | root's shell is tcsh; `$(...)` unsupported | 4d |
-| OPNsense boots on FACTORY DEFAULTS with a correct config ISO attached; console shows `>>> Invoking import script 'importer'` and nothing more | the Configuration Importer can never fire on a nano image | 4a |
-| a Kea/firewall API `set` returns success but the box's behaviour does not change | no `service/reconfigure` (or no firewall `apply`) call | 4c |
-| MAAS cannot talk to an LXD VM host after an LXD update | LXD auto-refreshed past 6.6; MAAS 3.6/3.7 needs LXD <= 6.6 or 5.21 LTS | 3a |
-| a MAAS-composed VM gets a lease MAAS did not issue, or PXEs on the wrong L2 | `lxdbr0` runs its own dnsmasq (verified); the composing LXD profile's bridge is the other candidate (unconfirmed -- measure it) | 3b, 3c |
-
----
-
-## NetBox (upstream, `netbox.baldurkeep.com`)
-
-### `HTTP 403 Forbidden` on every API call -- but the SAME token works from `curl`
-
-**Symptom.** `urllib`/`requests`/`pynetbox` get `403 Forbidden` from the upstream NetBox on every
-endpoint, including ones a valid token plainly reads. `curl` with the identical token and URL
-returns `200`. It reads exactly like a bad or revoked token; it is not.
-
-**Cause.** Something in front of upstream NetBox (WAF / reverse proxy) filters on **User-Agent**.
-The default Python UA (`Python-urllib/3.12`) is blocked; `curl/8.5.0` is allowed. Measured
-2026-07-13: same token, same URL, UA the only variable -- `None -> 403`, `curl/8.5.0 -> 200`.
-
-**Fix.** Send an accepted `User-Agent` header. This applies to **`pynetbox`** too (it sends
-`python-requests/...`), so the repo's NetBox tooling must set it:
-
-```python
-nb = pynetbox.api(url, token=tok)
-nb.http_session.headers["User-Agent"] = "curl/8.5.0"
-```
-
-**Do not** diagnose this as a token/permission problem and go re-mint credentials -- that is the
-trap. Confirm with `curl` first; if curl works and Python does not, it is the UA.
-
-**Note:** this is an UPSTREAM-only trap so far. The Office1 sandbox NetBox (4.6.4, no proxy in
-front) accepts the default Python UA. Upstream is 4.5.8 and also uses **v1** (40-char, bare) tokens,
-while the sandbox is 4.6 and uses **v2** (`nbt_<key>.<plaintext>`). Any tool pointed at BOTH must
-handle both auth shapes and the UA -- do not assume they are the same NetBox.
-
-
-================================================================================
-## references/script-authoring.md (loaded on demand in Claude Code; inlined here for Chat)
-================================================================================
-
-# Script authoring - house style and hardening
-
-Every script and paste block in this project follows these rules. They are
-not style preferences: each one encodes a failure that actually happened.
-Read this in full before writing ANY bash or python for this cloud.
-
-## Zeroth decision: does it already exist?
-
-Before writing ANY operational script or check block, search the repo:
-`grep -rli <topic> scripts/ runbooks/` - the deploy/verify surface is heavily
-scripted and duplicating an existing script creates drift (e.g. the haproxy
-backend sweep already exists as `scripts/phase-03-core-verify.sh` 3.1b).
-Route to, extend, or fix the existing artifact; write new only when nothing
-covers the need, and say which search came up empty.
-
-## First decision: what kind of block is this?
-
-The error-handling regime depends on execution mode. Choosing wrong is itself
-a bug:
-
-1. **Executed script** (`bash script.sh`, own process): `set -uo pipefail`
-   at minimum; `set -e` acceptable and usually right, with the capture
-   caveats below. Exit codes are the interface.
-2. **Interactive paste block** (operator pastes into their shell): NEVER a
-   bare `exit` (it kills their shell) and no `set -e` (it can kill their
-   shell's options or abort mid-paste). Wrap the whole block in a subshell
-   `( { ...; } )` so a stray exit is contained; signal failure by printing
-   `FAIL: ...` lines the operator can read.
-3. **Verify/count-gate block** (greps that legitimately return zero matches):
-   run WITHOUT `set -e`, and end every count-grep with `|| true` - a zero
-   count is a valid answer, not an error (L1). `bash -n` cannot catch this;
-   it is behavior, not syntax.
-
-## The header contract (executed scripts)
-
-Every script opens with a comment block stating: path + argument synopsis;
-what it does (one paragraph, referencing the D-NNN/DOCFIX it implements);
-**whether it mutates anything** ("Mutates NOTHING" / what it changes and the
-gate protecting it); usage line; exit-code contract; and "ASCII + LF".
-House exit codes: `0` PROCEED, `1` HOLD (a gate failed), `2` precondition
-missing (tool absent, wrong model, helper not found). Then:
-
-    set -euo pipefail            # or set -uo pipefail; see regime above
-    shopt -s inherit_errexit 2>/dev/null || true
-    IFS=$'\n\t'
-
-Source shared constants instead of restating them:
-`. "$SCRIPT_DIR/lib-net.sh"` (planes, VIP bands, helpers) and `lib-hosts.sh`
-(hostnames, octets, system_id resolution). If a value you need is not in a
-lib, consider adding it there rather than inlining a literal.
-
-## Hardening rules (each one is a scar)
-
-**SIGPIPE races break guards in BOTH directions.** `cmd | grep -q X` under
-pipefail: on match, grep exits, the producer takes SIGPIPE (141), the pipeline
-reports failure despite the match. In an `... || die` verify this FALSE-DIES on
-success; in an `... && die` guard it FAILS OPEN -- the 2026-07 sweep found a
-duplicate-CIDR guard that let collisions through exactly this way. Treat every
-`| grep -q` on a live pipe as a defect regardless of which way the test points.
-
-**Pipefail + SIGPIPE race.** `cmd | grep -q X` under pipefail falsely fails:
-`grep -q` closes the pipe on first match, SIGPIPE (141) kills the producer
-(`juju ssh` especially). Capture, then test:
-
-    OUT=$(cmd 2>&1 || true)
-    grep -q "pattern" <<<"$OUT"
-
-**`set -e` kills id-captures silently.** `ID=$(openstack ... || die ...)` -
-if the subshell exits non-zero before your handler fires, `set -e` aborts the
-assignment line with no message. Append `|| true` to each capture, then
-validate the captured value explicitly (see whole-output validation below).
-
-**Whole-output validation, never extract-then-check.** Do not pipe raw output
-through `awk`/`grep` to extract a field and then test the fragment - a
-partial failure yields a plausible-looking fragment. Capture the WHOLE output,
-validate its shape (e.g. `is_id(){ [[ "$1" =~ ^[0-9a-f]{32}$ ]]; }` for a
-keystone id), and only then use it.
-
-**Centralize `</dev/null` in a wrapper, not per call.** The house pattern is a
-2-line helper (`rc()`, `rcap()`, `J()`) that appends `</dev/null 2>&1` once;
-every call site then stays clean and un-forgettable. Heredoc-payload ssh
-(`ssh ... bash -s <<'EOF'`) is the ONE exemption -- stdin IS the delivery there.
-
-**Inner stdin consumption.** Any `ssh`/`sudo`/`juju ssh` inside a heredoc,
-pipe, or loop eats the remaining stdin and truncates the block. Append
-`</dev/null` to EVERY inner invocation (`</dev/tty` only when it genuinely
-must prompt).
-
-**`read` and `... | bash` are mutually exclusive.** A script piped to bash
-has the pipe as stdin, so `read` returns empty at EOF - this once silently
-created a passwordless user. For paste-safety AND working prompts: base64-
-decode to a file, then run the file (it inherits the terminal stdin).
-
-**juju invocation shape.** `juju ssh -m <model>` - the `-m` flag goes BEFORE
-the target. `juju run <unit> <action>` output: use `--format json` for
-anything captured; confirm long actions via `juju show-operation <N>`, not
-the streamed log (a wait-timeout does not mean the hook failed).
-
-**Snap confinement.** The openstack CLI snap cannot read `/tmp` - stage files
-under `$HOME`. Same for `juju attach-resource` payloads.
-
-**Client output ordering.** `openstack -f value -c X -c Y` returns columns in
-ALPHABETICAL order, not flag order. When order matters: `-f json | jq`, or
-single-column queries. After any jq returning null, run `jq 'keys'` - key
-casing is command-specific (Title-Case in lists, hyphenated in quota show).
-
-**Environment isolation.** Any block that switches identity runs in a
-subshell that first unsets all OS_* vars:
-`( for v in $(env | awk -F= '/^OS_/{print $1}'); do unset "$v"; done; export ... )`
-Thread `OS_CACERT` explicitly into isolated subshells - it gets stripped.
-Confirm scope before acting: which project/domain the token holds, not which
-you intended.
-
-**Stable keys, not drifting IDs.** Look up MAAS subnets by CIDR, machines by
-hostname, CAPI CRs by LISTING then operating on the exact returned name
-(the OpenStackCluster suffix is random per create - a wrong-name patch
-silently no-ops). system_ids are re-minted on re-enrollment.
-
-**Verify the launched cmdline, not the config text.** For OpenStack debs run
-via LSB-init-wrapped systemd: a flag "present in a file" proves nothing.
-Gate on behavior - the init script's `show-args`, `ps -ww -C <daemon> -o args`
-on the live process, and probe under the daemon's RESTRICTED PATH
-(`env -i PATH=/usr/sbin:/usr/bin:/sbin:/bin sh -c 'command -v helm'`) - an
-interactive shell's PATH masks daemon-PATH failures.
-
-**sed is not a verifier.** A non-matching `sed -i` exits 0 having changed
-nothing. Assert the post-edit content; never trust sed's exit code as proof
-of the edit.
-
-**ASCII + LF, validated.** Non-ASCII: `grep -nP '[^\x00-\x7F]'` or a Python
-byte read. CR check: Python `data.count(b"\x0d")` - `grep $'\r'` false-
-positives on `$r...` tokens. Non-ASCII in conf.d has silently killed daemons.
-
-**Python helpers live in .py files** tested against fixtures - no inline
-python-in-bash beyond one-liners. Do not assume `jq` exists off-jumphost;
-gate on it (`need_jq`) or use python3.
-
-**Secrets in scripts:** whitelist-write to 0600 files under a 0700 dir
-(`umask 077` first), never echo, never argv, measure secret length from the
-file rather than asserting an expected length (this deployment's app-cred
-secrets are 86 chars, not the commonly assumed 43 - never hardcode either).
-
-**Structured-output captures take stdout ONLY; never merge stderr.** `x=$(openstack ... -f json 2>&1)`
-is a defect: any stderr line (a `--long` deprecation warning, an SDK notice) lands at char 0 and
-kills the JSON parse -- this fail-closed a live SG audit in 2026-07. Capture stdout alone; send
-stderr to a tempfile; surface it on parse failure, never discard it (`2>/dev/null` trades the bug
-for silent error-masking). The `vr_json` helper in `scripts/lib-validate.sh` encodes this. Also
-drop deprecated flags that only add stderr noise (`--long` is unneeded; fields are present without it).
-
-**Fixture-test throwaway probe one-liners like real code.** A measurement `ss`/`tcpdump`/`awk`
-pipeline is code, and it has the same parse traps: `ss` DROPS the State column under a
-`state established` filter (peer is then `$NF`, not `$5`); `cut -d:` splits IPv4-mapped IPv6
-(`[::ffff:10.0.0.1]:443`) at the wrong colon; `grep -oE 'src [0-9.]+'` greedily eats the trailing
-`.` into the next field; charmed magnum logs to `/var/log/magnum/magnum-conductor.log`, NOT
-journald. One measurement chain in 2026-07 shipped four such bugs before each was caught. Run the
-parse against a fixture line (mapped-v6, plain-v4, the real column layout) BEFORE handing the
-operator a probe -- the same discipline as a committed script.
-
-## Testing: nothing ships on `bash -n`
-
-`bash -n` validates parse, not behavior - and most of the failures above are
-behavioral. Every nontrivial script gets an offline regression harness at
-`tests/<script-name>/run-tests.sh` in the established pattern:
-
-- `fakebin/` contains fake `juju` / `openstack` / `maas` / `kubectl` /
-  `ssh` executables that replay fixture output and log the calls they
-  receive; real coreutils stay real.
-- The harness sets `PATH="$BIN:$PATH"`, a scratch `HOME`, and env-injected
-  fixture paths, runs the target, and asserts BOTH the exit code and an
-  output regex per case: `run <want_rc> <regex> <label>`.
-- Cover: the happy path, each gate's failure branch (asserting HOLD not
-  crash), each precondition (exit 2), and any DOCFIX behavior the script
-  claims (e.g. "verify-first never creates a rule when one exists").
-- Read an existing harness (e.g. `tests/phase-07-conductor-graft/`) before
-  writing a new one; match its shape.
-
-For MUTATING scripts, the harness fakebin is STATEFUL: the fake `maas`/`juju`
-advances a phase file on each mutation call so post-mutation verification reads
-post-mutation reality (see tests/phase-00-teardown-d061 -- canary survival,
-decompose-detection, substrate-collision aborts). A `--no-prompt` flag on a
-destructive script exists FOR its harness, nothing else.
-
-**Harnesses are HERMETIC: fakes shadow, deletion un-shadows.** Never simulate
-an unavailable tool by DELETING its fake -- on a real host that un-shadows the
-real binary and the test falls through to live infrastructure (a jumphost
-gauntlet run reached real Charmhub this way). Simulate failure with a FAILING
-fake (prints a realistic error, exits nonzero); keep the fail-loud-on-unmatched
-arm in every fake so an uncovered call can never silently hit a real CLI.
-
-**A script migration commit MUST carry its harness.** The D-060 revert updated
-the scripts and left their harnesses testing the retired D-058 world -- red-at-
-HEAD tests that trained everyone to ignore red. If you change a script's
-behavior or vocabulary, the same commit updates fixtures and expectations.
-
-**Static contract:** `bash scripts/repo-lint.sh` must exit 0 before anything is
-delivered (L1 ASCII/LF, L2 stale tokens, L3 ghost refs, L4 deprecated refs,
-L5 numbering, L6 bare invocations, L7 clientdocs sweep receipt). Changing any
-tenant-facing surface (tenant-*.sh, the onboarding contract, tenant runbooks,
-the policy zip, clientdocs/ itself) trips lint L7 until clientdocs/ has been
-reviewed for staleness and the receipt is re-recorded:
-`bash scripts/repo-lint.sh --record-clientdocs-sweep` (the sweep IS the review;
-recording without reviewing defeats the rule). A guard script that must NAME stale tokens
-opts out per-file with a `repo-lint: allow-stale-tokens` marker in its header.
-Committed binaries (e.g. policies/overrides.zip) need a `*.zip binary`
-.gitattributes rule or the LF normalization corrupts them in transit.
-Introducing a tool dependency (jq, python module) means adding its presence
-gate in the same change.
-
-Read-only verify scripts DETECT and report; remediation stays a gated human
-step even when the fix is obvious - the script's job is evidence, the
-operator's job is the mutation decision.
-
-**Mock worlds must be TRUTHFUL to the real CLI/contract, and test expectations must match the
-SPECIFIED contract.** A mock that emits a 409 must actually have the resource pre-exist; a mock of
-an openstack list command must emit the real deprecation warning ON STDERR (or the stderr-separation
-rule above never gets exercised); a harness assertion that contradicts the documented exit contract
-(e.g. expecting a lone SKIP to lower the overall verdict when the contract says SKIP never lowers it)
-is a TEST bug, not a code bug -- fix the test. Three 2026-07 "failures" were untruthful mocks or
-wrong assertions, each caught by running the harness before delivery.
-
-
-================================================================================
-## references/troubleshooting.md (loaded on demand in Claude Code; inlined here for Chat)
-================================================================================
-
-# Troubleshooting - method, reflexes, and routing
-
-The repo's `runbooks/appendix-A-troubleshooting.md` is the operational
-symptom->cause->fix index, keyed by D-NNN/DOCFIX-NNN (it now includes the
-mysql-innodb-cluster recovery signatures and a point-of-use identifier index).
-ALWAYS check it before diagnosing from first principles - most failures on
-this cloud have been seen before and have a validated fix.
-`ops-capi-recovery.md` covers the CAPI/Magnum stack;
-`runbooks/ops-restart-procedure.md` covers full-cloud recovery.
-This file gives you the method and the reflexes that must fire BEFORE and
-WHILE you read those.
-
-**Substrate failures (libvirt/KVM guest won't boot, AppArmor, MAAS+LXD,
-OPNsense edge):** these are NOT in appendix-A. Go to
-`references/platform-traps.md` -- it ends in a verbatim-error -> cause index
-keyed to exact strings (`panic: running without device atpic requires a local
-APIC`, `Illegal variable name.`, a bare `Permission denied` that never names
-AppArmor, `-m size=2048k`, ...). Match the string BEFORE hypothesizing.
-
-**VR1 DC-DC track:** appendix-A above is VR0-specific -- nothing in the VR1
-DC-DC track (`docs/dc-dc-deployment-workflow.md`) has been executed yet, so
-there is no equivalent incident index for it (an OpenTofu/MAAS-`vm_host`/
-OPNsense-edge failure will not be in appendix-A). Apply the SAME triage
-method below regardless, but do not expect a pre-catalogued fix for a VR1-
-specific symptom -- log a genuinely new finding as a DOCFIX/D-NNN candidate
-per this repo's own discipline rather than assuming it must already be
-documented somewhere.
-
-## Triage method
-
-1. **Reproduce and capture verbatim.** The exact error text routes you in
-   appendix-A. Paraphrased symptoms match nothing.
-2. **Eliminate cheap layers first.** Web UI misbehaving: incognito/client
-   state (~10s) before any server hypothesis. CLI misbehaving: confirm the
-   token scope (project/domain) before blaming the service - wrong ambient
-   scope produces misleading 404s/403s, especially with domain-per-client
-   identity (an un-domain-qualified lookup resolves in the WRONG domain).
-3. **Establish what is actually true, live.** `bash scripts/cloud-assert.sh`
-   first - it runs every service-own-verdict gate in one read-only sweep and
-   localizes the failing layer. Then the targeted read-only audit of that
-   surface before touching anything. juju status, the service's own state
-   (haproxy admin socket, mysql cluster-status, vault status, ovn-appctl),
-   the relevant logs. Hard rule 2: measurements, not memory.
-4. **Match against appendix-A**, then design-decisions if it smells
-   architectural. If matched: follow the recorded fix exactly (verbatim-
-   reference rule for anything one-shot).
-5. **If unmatched:** smallest-possible hypothesis, read-only test to confirm
-   or kill it, and log the finding. New root causes become appendix-A /
-   DOCFIX material - capturing them is part of the fix.
-6. **Least-destructive first, individually gated.** Reload before restart,
-   restart before rebuild, rebuild before redeploy. Never batch.
-
-## Reflexes (internalize these; they override intuition)
-
-- **juju-green is necessary, not sufficient.** `active/idle` is BLIND to:
-  a DOWN haproxy backend (D-045 - hid a dead nova-api for 3 days), a missing
-  magnum trustee domain (D-046 - magnum reports ready regardless), an
-  unparsed-but-attached policy override, and per-backend/service state
-  generally. Gate on the service's OWN verdict (admin sockets, functional
-  probes), never on juju status alone.
-- **"Reports OK while broken" generalizes.** Charm-side validation is often
-  parse-level only (the keystone policy zip validates YAML, not semantics).
-  Acceptance is BEHAVIORAL: prove the capability works, not that the config
-  is present.
-- **Distinguish down from thrashing.** A host that looks "down" to juju/OVN
-  (ovsdb inactivity-probe storms) may be swap-thrashing, not down (D-040).
-  Check `who -b` / `uptime` / `journalctl -k | grep -i oom` before treating
-  it as an outage.
-- **Read the reason field before the status field.** Magnum health UNHEALTHY
-  has three signatures (D-042 amendment): reason EMPTY = conductor cannot
-  reach the mgmt API (VM down?); all-Ready except infrastructure "not found"
-  = the cosmetic driver-contract miss; a reason citing LB failure = real,
-  check Octavia. Same status, three different responses.
-- **Single-node mgmt VM does not self-heal (D-035/D-041).** Workload nodes
-  wedged with the `uninitialized` taint, magnum reconcile dead, addons
-  Pending -> check `capi-mgmt-v2` is ACTIVE before anything else. Manual
-  start is POLICY (down is a signal), not a defect.
-- **Known blast-radius traps:** `juju destroy-model` decomposes MAAS
-  pod-composed machines - machine retention is `juju remove-machine
-  --keep-instance` (D-061); mysql-innodb-cluster never bootstraps at
-  num_units 1 - deploy at 3 (D-062); `reboot-cluster-from-complete-outage`
-  is destructive against an already-healthy cluster - check cluster status
-  FIRST; vault restarts sealed by design - sealed-after-reboot is expected,
-  not a fault; the magnum `domain-setup` action must be re-run after every
-  redeploy (D-046).
-- **Green-in-the-shell, broken-in-the-daemon.** Interactive shells have a
-  different PATH, env, and stdin than LSB-init daemons. Verify under the
-  daemon's conditions (restricted PATH, live-process args) - see
-  script-authoring.
-- **The absence of an expected resource is a finding, not a gap to fill.**
-  If something that should exist does not (a domain, a rule, an image
-  property), find out WHY it is absent before recreating it - it may have
-  been removed deliberately (check design-decisions) or its absence may be
-  the actual root cause several layers up.
-
-**Prove event-driven flows by FUNCTIONAL OUTCOME, not packet/snapshot forensics.** For a
-bursty, per-operation client flow (e.g. the magnum conductor's helm/watch to the mgmt apiserver),
-an instantaneous `ss` snapshot or a short `tcpdump` window will usually catch NOTHING -- the
-connection is idle at rest and short-lived under load. That absence is expected, not a fault.
-The right proof is a forced real operation that SUCCEEDS end-to-end (a cluster resize reaching
-UPDATE_COMPLETE proves the conductor reached the mgmt apiserver through the boundary), plus a
-TCP handshake from the real source. Reach for established-state or a forced functional op before
-concluding a flow is broken; a service's own successful state transition outranks a captured packet.
-
-## Escalation and blockers
-
-- Missing vault unseal keys, lost one-shot secrets, or anything requiring
-  material only the operator holds: STOP and escalate. Do not improvise
-  around a recovery blocker (a vault re-init wipes the TLS plane).
-- If a fix would deviate from a runbook or contradict a D-NNN: log it as a
-  proposal and get a ruling. Mid-incident is exactly when discipline pays.
-- Two failed fix attempts on the same hypothesis = the hypothesis is wrong.
-  Step back to the audit stage; widen what you are measuring.
-
-
-================================================================================
-## references/opentofu-provider-docs.md (loaded on demand in Claude Code; inlined here for Chat)
-================================================================================
-
-# OpenTofu / provider documentation -- sources, versions, and fetch method
-
-Read this before writing or extending anything under `repo opentofu/` (the
-VR1 DC-DC infrastructure-as-code, D-103). Built up during the 2026-07-09
-OpenTofu delivery; see `repo opentofu/README.md` for the full, per-module
-account (schema notes, an "Audit pass" section, and every finding's exact
-sourcing) -- this file is the index into that plus the fetch methodology,
-so a future session does not have to rediscover it by trial and error.
-
-## The core lesson: doc-summarization is lossy, real example code is not
-
-Every provider doc page fetched this session went through a summarizing
-model, which reliably got FIELD NAMES right but repeatedly lost or
-mis-stated CALL SYNTAX (block vs. attribute style, exact nesting). The
-`opentofu/` scaffold shipped with a real syntax bug from trusting doc
-summaries alone (fixed once real example `.tf` files were fetched and
-read directly -- see `repo opentofu/README.md`'s syntax-bug note). **For any
-new provider/resource: find real example `.tf`/`.go` source before trusting
-a doc-summary's syntax claims.** Doc-summaries are fine for "what fields
-exist"; they are not reliable for "how do I write this."
-
-## Fetch gotchas
-
-- The Terraform/OpenTofu Registry's own doc pages (`registry.terraform.io/
-  providers/.../docs`) are client-side-rendered -- a plain fetch returns only
-  the page shell, no content. Go straight to the provider's GitHub repo
-  instead.
-- GitHub's raw file URLs need the CORRECT default branch (varies: `main` for
-  some repos, `master` for others -- check `api.github.com/repos/<org>/<repo>`
-  for the `default_branch` field first, don't guess).
-- A general web search's own synthesized "summary" of a doc page can itself
-  be wrong (encountered once this session: a search summary confidently
-  named the wrong branch and file path). Treat search-result summaries as
-  leads to verify, not answers -- always follow through to the primary
-  source.
-- When a fetch refuses to "reproduce verbatim" (copyright caution), ask for
-  a specific, narrow thing instead -- "list bare field names only, no
-  prose" reliably works where "reproduce this page" does not.
-- `api.github.com/repos/<org>/<repo>/contents/<path>` (a JSON directory
-  listing) is a reliable way to discover the REAL current file layout when
-  a guessed raw-file path 404s -- doc reorganizations happen (one provider
-  moved from `website/docs/r/*.markdown` to `docs/resources/*.md` between
-  the versions training data and current reality disagree on).
-
-## Providers used in `repo opentofu/`
-
-### `dmacvicar/libvirt` (pinned `0.9.8`, confirmed 2026-07-09)
-
-**Before writing any `libvirt_domain`, read `references/platform-traps.md`
-section 1.** Four schema-level traps there have each cost real time and none
-of them is a validate-time error: bare `memory` is KiB not MiB; no `features`
-block means `acpi=off`; no `cpu` block means no `svm` (nested KVM silently
-impossible); and "will be updated in-place" still BOUNCES the guest.
-
-- Registry: https://registry.terraform.io/providers/dmacvicar/libvirt/latest
-  (JS-rendered -- use the GitHub repo for actual content)
-- GitHub: https://github.com/dmacvicar/terraform-provider-libvirt (default
-  branch `main`; there is no `CHANGELOG.md` -- the release NOTES on the
-  releases page are the changelog, and they are unusually informative:
-  `.../releases/tag/v0.9.0` is the breaking-rewrite rationale, `v0.9.1` is the
-  0.9.0->0.9.1 attribute-rename migration guide)
-- **Version boundary that invalidates most examples on the internet:** 0.9.0
-  (2025-11-08) is a compatibility-BREAKING rewrite (plugin framework, "HCL maps
-  almost 1:1 to libvirt XML"); the legacy provider lives on the `v0.8` branch.
-  0.9.1 then code-generated the schema and renamed attributes again. Anything
-  0.8-era -- including model memory -- is wrong for this pin.
-- Docs: `docs/resources/*.md`, `docs/data-sources/*.md` (NOT the older
-  `website/docs/r/*.markdown` layout some search results/training data
-  reference -- that's stale)
-- **Real example `.tf` files (the higher-value source): `examples/*.tf`** --
-  `domain_with_network.tf`, `alpine_cloudinit.tf` were the two that resolved
-  every syntax question this session. Fetch these FIRST for any new
-  resource, before the doc pages.
-- Key fact: this provider code-generates its schema as a 1:1 mirror of
-  libvirt's own domain/network/pool XML (confirmed via a general search of
-  provider discussion, not the docs pages themselves) -- when a Terraform
-  schema question stalls, libvirt's own native XML docs
-  (https://libvirt.org/formatdomain.html, https://www.libvirt.org/pci-addresses.html)
-  are a legitimate, stable cross-reference for what a nested attribute is
-  likely to be named/shaped, since the mapping is direct.
-
-### `canonical/maas` (pinned `2.7.2`, confirmed 2026-07-09)
-- Registry: https://registry.terraform.io/providers/canonical/maas/latest
-  (same JS-rendering issue -- use GitHub)
-- GitHub: https://github.com/canonical/terraform-provider-maas (default
-  branch `master` -- NOT `main`, confirmed by checking `default_branch`
-  directly rather than assuming)
-- Docs: `docs/resources/*.md`, `docs/index.md` (provider block config)
-- Moved from an older `maas/maas` registry namespace -- use `canonical/maas`,
-  not `maas/maas`, for anything current.
-- Key lesson (see `repo opentofu/README.md`'s "MAAS registration + tc netem
-  research" section for the full account): `maas_vm_host` (register a virsh
-  chassis) and `maas_vm_host_machine` (MAAS composes/creates a new VM
-  itself) are NOT interchangeable -- read the schema (which fields are
-  INPUTS) before assuming a resource matches a design intent just because
-  its name sounds related.
-
-### OpenTofu core (language features, not a provider)
-- `local-exec` provisioner: https://opentofu.org/docs/language/resources/provisioners/local-exec/
-- `terraform_data` (built-in, replaces the older `null_resource` for
-  provisioner-only use): https://opentofu.org/docs/language/resources/tf-data/
-  (note the URL slug is `tf-data`, not `terraform_data` or `terraform-data`)
-- Both pages rendered cleanly on a direct fetch (static docs, no JS-rendering
-  issue) -- these were the most reliable fetches of the whole session.
-
-### OPNsense (not a Terraform provider -- the guest OS itself)
-
-**SUPERSEDED RESEARCH WARNING (2026-07-12/13).** `repo opentofu/README.md`'s
-"OPNsense deployment research" section and the 2026-07-09 changelogs describe a
-**config-ISO / Configuration-Importer** delivery path. That path is DEAD and its
-code is DELETED:
-- **D-112:** the Configuration Importer can NEVER fire on a pre-installed nano
-  image (upstream `opnsense-importer` probes for a read-only root and exits
-  before scanning media). The ISO was inert; nothing was ever going to read it.
-- **D-113 (ADOPTED 2026-07-13, option a2):** OPNsense STAYS, but config moves to
-  the **REST API**. `opentofu/templates/opnsense-config.xml.tmpl`,
-  `scripts/opnsense-render-config.sh` and `scripts/opnsense-build-config-iso.sh`
-  are DELETED, along with the module's `config_seed` volume + cdrom disk.
-  **A rendered-`config.xml` push would now CLOBBER live API-managed DHCP.**
-
-Current path: `scripts/opnsense-api.sh` (REST client) +
-`scripts/opnsense-bootstrap-apikey.sh` (mints a key via OPNsense's own model
-over SSH). Traps, exact endpoints, the mandatory `service/reconfigure` step, the
-60-second firewall auto-rollback, and the tcsh trap: `references/platform-traps.md`
-section 4.
-
-- Official docs: https://docs.opnsense.org/manual/install.html;
-  REST API: https://docs.opnsense.org/development/how-tos/api.html;
-  26.1 release notes (ISC-DHCP left core; dnsmasq is the new default):
-  https://docs.opnsense.org/releases/CE_26.1.html
-- Still-valid finding from the 2026-07-09 research: cloud-init is unreliable on
-  FreeBSD, so `modules/cloudinit-vm` genuinely does not apply to OPNsense
-  (https://forum.opnsense.org/index.php?topic=42517.0), and the nano image (not
-  the installer image) is the one to use.
-- Historical only (the ISO mechanism these describe cannot fire on nano):
-  https://github.com/opnsense/core/issues/5733, .../issues/10017.
-
-## Where the full findings live (don't duplicate here, it will drift)
-
-**Caveat first (2026-07-13):** `repo opentofu/README.md` predates D-112/D-113
-and its "OPNsense deployment research" section still describes the DELETED
-config-ISO path -- see the superseded-research warning above before acting on
-anything it says about OPNsense. Its libvirt schema notes also predate the four
-domain traps in `references/platform-traps.md` section 1. Everything else in it
-still stands.
-
-`repo opentofu/README.md` is the authoritative, per-module account --
-schema notes, what's confirmed vs. assumed per attribute, and a dated
-"Audit pass" section recording a later re-review (a real documentation
-error was found and fixed there: an early claim that libvirt interface
-list-order directly sets OPNsense's LAN/WAN role conflated two separate
-mechanisms -- read that section before trusting anything about NIC
-ordering/roles). Treat this file as the index/methodology; treat that one
-as the ground truth for what each module actually does and why.
diff --git a/.claude/skills/openstack-cloud-ops-consolidated-20260727.md b/.claude/skills/openstack-cloud-ops-consolidated-20260727.md
new file mode 100644
index 0000000..f0065e6
--- /dev/null
+++ b/.claude/skills/openstack-cloud-ops-consolidated-20260727.md
@@ -0,0 +1,1589 @@
+<!-- CONSOLIDATED SKILL SNAPSHOT for Chat/project upload.
+     Source: .claude/skills/openstack-cloud-ops/ (SKILL.md + references/) regenerated at repo HEAD 43256d6, 2026-07-27.
+     Regenerated at the Stage 4 close sweep. New INVARIANTS folded in this round: per-DC artifact
+     delivery is a per-DC STRATEGY (dc0 full mirror / dc1 caching proxy, D-135 amendments) and a
+     utility service OWNS ITS OWN network prerequisites; Stage 4 hands off READY nodes, not
+     deployed ones (DOCFIX-200); and "a checker that cannot fail is not a gate" with the
+     assert-on-content / enumerate-what-exists rules that came out of two measured false greens.
+     Chat's skill surface is single-file, so the on-demand references are FLATTENED here.
+     DERIVED artifact -- regenerate from the skill dir at each stage-close sweep (SKILL.md rule).
+     Authoritative copy remains .claude/skills/openstack-cloud-ops/ in the repo. -->
+
+# openstack-cloud-ops -- consolidated skill (Chat upload snapshot, 2026-07-27)
+
+================================================================================
+## SKILL.md (main entry -- always in context)
+================================================================================
+
+---
+name: openstack-cloud-ops
+description: "Operate, install, extend, and troubleshoot the Omega Cloud - a commercial multi-tenant Charmed OpenStack (Caracal 2024.1) deployment managed with Juju and MAAS, with Vault TLS, OVN, Ceph, Octavia, and Magnum/CAPI tenant Kubernetes. Use this skill for ANY work touching OpenStack, Juju, MAAS, Magnum, CAPI, Ceph, OVN, Octavia, Keystone, Vault-for-OpenStack, tenant onboarding, or the repository this skill operates against - including writing or reviewing bash/python operational scripts, debugging failed deploys or cluster creates, runbook work, design-decision (D-NNN) discussion, and incident triage. Use it even for seemingly simple OpenStack questions: this deployment has strict operating discipline and known charm traps that make generic answers wrong."
+---
+
+# openstack-cloud-ops
+
+Operating skill for the Omega Cloud: a commercial, multi-tenant, tenant
+self-administered OpenStack cloud, built as virtual rehearsals (VR0 single-DC
+"testcloud"; VR1 two-DC + Office1 headend) for a future bare-metal
+multi-datacenter deployment ("Roosevelt"). The CURRENT phase/stage lives in
+repo `docs/CURRENT-STATE.md` ONLY (GA-R1) -- never trust a phase claim from
+this file or memory. The governing design constraint is
+MINIMIZE DELTA TO ROOSEVELT: the runbooks and scripts are primary deliverables
+alongside the running cloud, so transferable answers beat quick fixes.
+
+## Step 0 - locate the source of truth
+
+This repository (GitBucket, git.baldurkeep.com) is authoritative for
+everything: bundle, runbooks, scripts, design decisions, as-built values. This
+skill is a discipline-and-routing layer OVER that repo, not a substitute for
+it. Never hardcode the repo's own name/path in a command -- it has already been
+renamed/forked once (see D-110) and will again; discover it fresh each session.
+
+1. Look for a local clone: a repo dir in the working tree, or a `$HOME` entry
+   containing `bundle.yaml` + `docs/design-decisions.md`. If found, confirm
+   identity with `git remote -v`, then `git log -1` to note HEAD and work from it.
+2. No clone and you have shell + network: ask the operator for the exact clone
+   URL (org/group and repo name -- do not guess or reuse one from memory; it
+   may have moved, per this same repo's own history). The repo may be private;
+   if the clone fails, ask the operator to provide access or the relevant files.
+3. No clone obtainable (e.g. chat without sandbox network): say so, ask the
+   operator to paste the relevant runbook/script, and proceed only on what is
+   actually in front of you.
+
+**Divergence rule:** if this skill and repo HEAD disagree, the repo wins -
+but FLAG the divergence to the operator rather than silently following either.
+The repo is a living draft; this skill's invariants (discipline, hardening)
+change slowly, its facts (IPs, versions, phase status) go stale fast.
+
+**Session bookends (GA-R1/GA-R4).** OPEN: read `docs/CURRENT-STATE.md` in full
+BEFORE any other doc (it is the only status authority), then `docs/session-ledger.md`
++ `bash scripts/ledger-scan.sh` to recover what is in flight and reconcile it against
+repo ground truth (open decisions, open SEC count, next-free numbers). Re-do this
+after any compaction. CLOSE: a bounded ledger summary (15-line hard cap, GA-R4 rule
+1); the full session body goes to `docs/archive/` in the same close commit; commit
+and push -- a session ending without its bookend is treated as NOT durable by the
+next session. See `references/operating-discipline.md` (Session continuity).
+## Step 1 - detect the environment
+
+- **Live shell to the jumphost / infra** (Claude Code on `vcloud` or
+  similar): you may RUN read-only audits directly. Every mutation remains
+  individually human-gated - present the command, state what it changes, wait
+  for approval. A live shell relaxes the transport, never the discipline.
+- **Chat / no infra shell**: operate the gated copy-paste model - prepare
+  labeled blocks, the operator runs them and pastes output back. Never assume
+  a block ran or succeeded; wait for the pasted evidence.
+
+Read `references/operating-discipline.md` before doing either.
+
+## The three hard operating rules (non-negotiable)
+
+1. **Execute only the current runbook step, exactly as written.** No added
+   scope, no adjacent improvements, no live re-architecture mid-step. Findings
+   and improvement ideas are LOGGED (changelog / D-NNN proposal), never
+   executed live mid-step.
+2. **Never use an inferred value.** No IP, ID, name, or scope goes into a
+   command unless it was measured this session or carried from confirmed
+   as-built. If a value would be inferred: stop and measure it. Never run a
+   destructive or session-altering command from memory without confirming it
+   is the minimal correct action for the current live state.
+3. **Prefer dynamic lookups over hardcoded literals.** Discover VIPs, project
+   names, IDs, and version sets at runtime. Where a literal is unavoidable it
+   is tagged and centralized (`scripts/lib-net.sh`, `lib-hosts.sh`), keyed by
+   stable identity (CIDR, hostname) - never by drifting IDs.
+
+Corollary that governs everything: **verify before mutate**. A read-only audit
+precedes every mutation; destructive and secret-handling steps are gated
+individually, never batched.
+
+## Routing - where to go for what
+
+| Task | Read first |
+|---|---|
+| Any command block, script, or paste block you are about to write | `references/script-authoring.md` |
+| Deploy / redeploy / teardown (VR0, single-DC testcloud) | repo `runbooks/README.md`, then the phase-NN runbook; conventions in `references/operating-discipline.md` |
+| VR1 DC-DC buildout (two-DC + Office1 headend -- the current live mission) | repo `docs/CURRENT-STATE.md` FIRST (stage/gate STATUS lives there only), then `docs/dc-dc-deployment-workflow.md` (stage identity, links, gap register), then `runbooks/README.md`'s "VR1 DC-DC track" section for the `dc-dc-phase0..6` runbooks + `dc-dc-teardown-rollback.md`. SEPARATE track from VR0's phase-NN above -- do not conflate stage numbers between the two. |
+| Something is broken (triage, incidents) | `references/troubleshooting.md`, then repo `runbooks/appendix-A-troubleshooting.md` |
+| CAPI / Magnum / mgmt-VM recovery | repo `runbooks/ops-capi-recovery.md` |
+| Deliver ANY repo change (script, runbook, doc) | run `bash scripts/repo-lint.sh` + the touched script's `tests/<name>/run-tests.sh` BEFORE handing it over |
+| Pre-deploy gate (before add-model) | `bash scripts/preflight.sh` -- THE single entry; do not run the sub-gates piecemeal |
+| Is the cloud actually healthy? (post-deploy, post-restart, pre-change baseline, incident) | `bash scripts/cloud-assert.sh` (add `--capture` at deploy completion for the committed BOM) |
+| Full-cloud restart after outage/maintenance | repo `runbooks/ops-restart-procedure.md` |
+| VR1 site unreachable after a vcloud reboot (`ssh voffice1` / `office1-*` time out) | `bash scripts/site-baseleg.sh check office1` -- `office1-local` is an ISOLATED libvirt net, so the host's base L3 leg (`10.10.0.10/24` + compose route `10.10.1.0/24 via 10.10.0.20`) is dropped every reboot; the `After=libvirtd` unit re-adds it (D-126 amendment / D-128). If MISS and the unit is not yet installed: `sudo bash scripts/site-baseleg.sh apply office1`. This is the vcloud path; the workstation reaches the same over the tailnet (D-107). |
+| Starting any consequential live session | `bash scripts/run-logged.sh <label>` first (as-executed log; docs/as-executed-log-convention.md) |
+| Credential exposures / security TODOs | repo `docs/security-ledger.md` -- add a row, never only a script comment. The credential-LIFECYCLE policy (mint -> consolidate -> audit) is **D-137**, not the ledger (SEC-009's convention block is now a pointer); the expected-state register is `creds-matrix.tsv` + `scripts/creds-matrix.py` (tier 1 static, tier 2 existence, tier 3 validity), enforced as a BLOCKING preflight `P5`. `creds-audit` CLEAN is NOT evidence of completeness -- it is declaration-based |
+| Per-DC artifact delivery (apt mirror / caching proxy); "can the nodes get packages?" | dc0 = `bash scripts/dc-mirror.sh check dc0` (full mirror); dc1 = `bash scripts/dc-cache-proxy.sh check dc1` (caching proxy). The two DCs DIFFER BY RULING (D-135 amendments) -- checking dc1 as a mirror fails by design. Both run ON the rack host over `ssh -J voffice1` with `sudo bash -s`; take rack transit IPs from `scripts/lib-hosts.sh`, never memory |
+| Resuming work / what is still in flight (esp. after compaction) | repo `docs/CURRENT-STATE.md` first, then `docs/session-ledger.md` + `bash scripts/ledger-scan.sh` to reconcile against repo ground truth |
+| Tenant onboarding / tenant self-service | repo `scripts/tenant-onboard.sh` + `runbooks/tenant-onboarding-v2-DRAFT.md` + `appendix-C/D` |
+| Network / plane / IPAM questions | `references/environment.md`, repo `scripts/lib-net.sh`, NetBox (the IPAM apex -- but during VR1 the WORKING apex is `office1-netbox`, 10.10.1.10, per DOCFIX-195; `netbox.baldurkeep.com` is a READ-ONLY v1 reference, write-back deferred to end-of-deployment) |
+| ANY change request to a built surface | grep repo `docs/design-decisions.md` for the governing D-NNN FIRST - PROPOSED/OPEN means the operator has not ruled: present options, do not implement |
+| Why is it built this way? / proposing changes | repo `docs/design-decisions.md` (D-NNN); grep before assigning a new number |
+| Versions, channels, pins | repo `docs/CURRENT-STATE.md` section 7 (VR1 substrate -- measured pin authority); `runbooks/appendix-B-asbuilt-version-lock.md` (VR0 charm channels) |
+| Environment facts (hosts, repo, planes) | `references/environment.md` |
+| OpenTofu / libvirt / MAAS / OPNsense IaC work (repo `opentofu/`) | `references/opentofu-provider-docs.md` FIRST (sources + fetch method), then repo `opentofu/README.md` (per-module ground truth, schema notes, audit findings -- but its OPNsense section is SUPERSEDED by D-112/D-113) |
+| Creating/changing a `libvirt_domain`; anything about nested KVM, a libvirt storage pool, LXD versions, an OPNsense edge, or a VM that boots wrong | `references/platform-traps.md` -- per-tool traps + version pins + a verbatim-error index (KiB-vs-MiB memory, `acpi=off`, missing `cpu` block = no `svm`, "in-place" bounces the guest, AppArmor on non-default pools, MAAS-vs-LXD 6.7, lxdbr0's dnsmasq, tcsh on the edge) |
+
+## Standard loops (repeatable session shapes)
+
+**Session bootstrap (jumphost):** Claude Code sessions launch from the repo
+root, always (GA-R7 rule 6 -- a session launched from a subdirectory gets its
+own empty project dir and a divergent auto-memory; the GA-F06 origin).
+`git -C "$REPO" pull` (set `$REPO` once per
+session -- see `runbooks/README.md` Conventions / `references/environment.md`) ->
+`bash scripts/repo-lint.sh` (0 fail expected) -> if touching the live cloud,
+`bash scripts/run-logged.sh <label>` to open the logged shell. Repo HEAD and a
+clean lint are the preconditions for everything else.
+
+**VR1 operating model (D-128 -- invariant; do not re-derive this each session):**
+Claude runs ON the vcloud jumphost -- do NOT relocate the session to a workstation.
+Work splits in two, origins FIXED BY DESIGN: **Plane 1** (substrate -- the OUTER
+`tofu` root `qemu:///system` + local `virsh`, creating the DC *host* VMs) runs on
+vcloud and has no Roosevelt analog; **Plane 2** (MAAS / NetBox / the INNER `tofu`
+root `qemu+ssh`-from-Office1 / tenant tests) EXECUTES on `voffice1` via `ssh
+voffice1 '...'` so runbooks read "from the Office1 headend" and transfer. Claude's
+host only picks the TRANSPORT, not where work runs. Durable Office1 reach = the
+D-126 base-leg oneshot (`scripts/site-baseleg.sh check office1` FIRST if `ssh
+voffice1` is dead post-reboot) -- NOT tailscale-on-vcloud (D-107 is the operator's
+WORKSTATION path / human GUI, left untouched). DCs sit outside the `/22` carve and
+keep the D-126 `-J`-through-`vvr1-dc0` shape. **Durable host->site reach is standing
+per-SITE tooling, DCs included (so the gap does not reopen per-DC):** `site-baseleg.sh`
+is site-keyed. At each DC standup, MEASURE how vcloud reaches that DC's containment/
+service net -- if it is an ISOLATED host-local net, add a MEASURED leg row + `install`
+the unit as part of standup definition-of-done (NEVER an inferred DC IP -- the harness
+fails on an un-commented DC supernet); a routed/NAT net or an already-reachable
+`qemu+ssh` path needs none. Register item 20 tracks this. **Rack-side twin invariant
+(D-131 sub-1, RULED 2026-07-21): every internet-isolated DC rack gets the repo-carried
+`scripts/dc-rack-net.sh install <site>` at standup (reboot-persistent rack bridge legs
++ the node-DNS dnsmasq forwarder aliased on metal-admin, forwarding to region BIND over
+the rack's own transit) -- MAAS 3.7's rack-only agent resolver SERVFAILs on isolated
+racks, so WITHOUT this, commissioning silently times out (appendix-A carries the
+symptom pair).** Two measured MAAS traps with standing consequences: MAAS virsh PODS
+are refuted for this repo's DCs (per-machine `power_type=virsh` via
+`scripts/maas-node-power.sh` is the ruled shape -- D-103/D-123 amendments 2026-07-20),
+and a pod delete CASCADES to its linked machine records -- read the pod's machine list
+BEFORE any `vm-host delete`; non-empty = STOP (appendix-A, 2026-07-21 incident).
+**Per-DC power credential (SEC-012 dc0, SEC-016 dc1, RULED 2026-07-23 -- standing
+DC-standup invariant): each DC gets its OWN dedicated MAAS->libvirt power key, NEVER
+a cross-DC reuse.** The REGION's MAAS snap dials the power address, so the split is:
+the maas-node-power SCRIPT's mapping virsh uses the DC SERVICE key (via the region's
+`~/.ssh/config` Host <rack-transit-ip>), while MAAS's own power ops use the dedicated
+key installed in the snap (`/var/snap/maas/current/root/.ssh/` + a per-host `ssh
+config` block so each rack uses its own key). FRAGILITY: the snap-side key lives under
+per-revision `/var/snap/maas/current/` and may not survive a snap refresh -- re-assert
+after any refresh. Roosevelt analog: per-DC IPMI/BMC credentials.
+
+**Per-DC ARTIFACT DELIVERY is a per-DC STRATEGY, and the two DCs deliberately differ
+(D-135 + its 2026-07-24/27 amendments -- standing invariant).** dc0 tests a FULL MIRROR
+(`dc-mirror.sh`, debmirror+nginx on the D-134 utility `.4`); dc1 tests an APT CACHING
+PROXY (`dc-cache-proxy.sh`, apt-cacher-ng on `.4:3142`, consumed via
+`juju apt-http-proxy`). This is the EXPERIMENT, not an interim state -- there is no
+fallback and no later convergence, and dc1's partial mirror was REMOVED 2026-07-27.
+Consequences that bite: **checking dc1 as a mirror FAILS BY DESIGN** (use its own
+checker), and each DC's gate is its own script's `check <site>`.
+**Corollary invariant, learned the hard way: a per-DC utility service OWNS ITS OWN
+NETWORK PREREQUISITES.** `dc-cache-proxy.sh` originally REUSED `dc-mirror.sh`'s
+`<site>-mirror-net.service` for the `.4` alias + edge default route, so on a proxy-only
+DC three files named `*-mirror-*` were load-bearing FOR THE PROXY: the documented
+mirror-removal procedure would have silently killed it, and the proxy could not be
+REBUILT afterward without reinstalling the whole mirror apparatus (enabled daily
+debmirror timer included). Never let one strategy's teardown be able to break the
+other's; name artifacts for the service that owns them. Roosevelt analog: a DC must be
+able to change artifact strategy without rebuilding the other strategy's apparatus.
+
+**Stage 4 hands off READY nodes, NOT deployed ones (DOCFIX-200, RULED 2026-07-23 --
+standing).** MAAS-deploy is SKIPPED; Juju provisions at Stage 5. Any surface saying
+"nodes Deployed" as a Stage-4 exit condition is a DEFECT, not a fact -- four were found
+and fixed on 2026-07-27 (workflow-doc gate cell, phase-3 DoD + Step 7, phase-4
+prerequisites). Practical consequence: **nothing node-side can be probed in Stage 4**
+(the nodes are powered off), so node-side checks belong at Stage 5 first boot -- that is
+why gate G17 exists.
+
+**A CHECKER THAT CANNOT FAIL IS NOT A GATE (this project's most productive audit move).**
+GA-R6 lets a stage close only on a named executable check, so the check itself must be
+verified capable of failing. Two measured instances, days apart: `creds-audit` is
+DECLARATION-based and read CLEAN on three sites while the D-137 matrix returned 13
+findings; `dc-mirror.sh check` asserted that `last-sync.status` EXISTED and printed its
+contents behind an unconditional `OK`, so a `FAIL` status and a four-day-stale `RUNNING`
+both passed. Working rules that came out of it: assert on CONTENT, never on existence;
+an unrecognised state REFUSES rather than defaulting to success; "could not look" is
+never "nothing there"; and **enumerate what EXISTS rather than only auditing what is
+declared** -- a register cannot report the absence of something it has no row for, which
+is how an unregistered credential at both DC edges survived every audit. When a test
+asserts a literal finding string, remediating the finding turns the harness red: REPLACE
+the assertion with the new invariant and say so, never delete it to go green.
+
+**Change-delivery loop:** grep for prior art (zeroth decision) -> grep
+design-decisions for the governing D-NNN -> edit -> `bash scripts/repo-lint.sh`
+-> run the touched script's harness (create one if missing -- no script change
+ships without its harness) -> deliver with an entry in the SESSION changelog
+(ONE changelog per session, GA-R2/D1 -- never per-topic files) carrying a
+per-item revert. Under blanket approval, the changelog IS the review surface:
+every item states what, why (evidence), and how to revert. Changelogs are
+session-scoped scratch: consolidated per-stage at stage close, NEVER citable
+as status or decision authority.
+
+**Deploy loop (VR0, single-DC testcloud):** phase-00 runbook (D-061 destroy
+path) -> `bash scripts/preflight.sh` PASS -> phase-01..08 gated -> `bash
+scripts/cloud-assert.sh --capture` -> commit the asbuilt/ BOM.
+
+**Deploy loop (VR1 DC-DC, the current live mission):** read
+`docs/dc-dc-deployment-workflow.md`'s tooling gap register FIRST -- check
+whether the stage you're about to run has any open blocking item -> Stage 1
+(`dc-dc-phase0-vcloud-prep.md`) gated -> Stage 2..7 gated in order, per
+`runbooks/README.md`'s "VR1 DC-DC track" table -> if a stage's `tofu apply`
+fails partway, read `runbooks/dc-dc-teardown-rollback.md`'s rollback decision
+tree BEFORE reaching for a teardown (fix-forward is usually correct). Run
+`bash scripts/opentofu-validate.sh` before any tofu step; whether a given
+root/step has been exercised for real is a STATUS question -- check
+CURRENT-STATE, never this file's memory of it. **At STAGE
+CLOSE** (GA-R6): a stage or verification-type gate CLOSES only on a NAMED executable
+check whose captured output the closing commit cites -- prose cannot close a stage,
+and there is NO conditional close (a remainder splits into its own gate row or the
+stage stays open, E3). Ruling-type gates close per GA-R5 (recorded, pushed ruling).
+The close-out set is executable: gauntlet ALL GREEN, repo-lint 0-fail, the stage's
+GA-R2 consolidation commit landed, the GA-R7 memory review run, MERGE the stage
+branch to `main` (merge commit, NOT squash; operator-gated), then RETIRE the branch
+(local + remote). **ALSO sweep THIS skill in the same close:** fold in any new
+INVARIANT the stage established and reconcile any divergence from repo HEAD (facts
+delegate to the repo and go stale; invariants live here and must be kept current). The
+AUTHORITATIVE, versioned skill is THIS dir (`.claude/skills/openstack-cloud-ops/` -- SKILL.md
++ references); keep it current here. THEN REGENERATE the dated single-file Chat-upload
+snapshot from it (concatenate SKILL.md + references -> `.claude/skills/openstack-cloud-ops-consolidated-<date>.md`,
+ASCII/LF byte-verified) so the Chat/project skill surface can be refreshed -- the snapshot
+is a DERIVED artifact, never the source, and the Chat mount going stale is a known failure
+mode (it caused a failed clone + a mis-shaped handoff, 2026-07-25; docs/audit/skill-divergence-20260725.md).
+The next stage branches off post-merge `main`. `main` is
+trunk-of-record only for stages that have merged (precedents: Stage 2 -> PR #1 `e468d2e`
+2026-07-15; Stage 3 -> merge commit 2026-07-21, vr1-dc0 scope, dc1 HELD under G12). See
+`docs/dc-dc-deployment-workflow.md` "Cross-cutting discipline".
+
+**Incident loop:** capture the verbatim error -> `bash scripts/cloud-assert.sh`
+(the service-own-verdict sweep localizes the layer) -> appendix-A by exact
+message -> recorded fix, gated -> log the finding (new root causes become
+appendix-A/DOCFIX material).
+
+## Record authority and session discipline (GA-R1..R7, ratified 2026-07-18)
+
+Ratified text: repo `docs/audit/ga-rulings.md` -- this is the operating summary.
+
+- **`docs/CURRENT-STATE.md` is the ONLY status authority (GA-R1).** Stage,
+  gates, plan counts, version pins, decision-queue state live THERE and nowhere
+  else; other surfaces point or are history. Any commit that changes a status it
+  carries updates it in the SAME commit (C1; repo-lint L10 enforces). It is
+  authoritative over documents, never over measurement -- a fresh capture wins
+  and corrects it in the capture's commit (C2).
+- **Plan counts and versions are quoted only from captured command output** --
+  a dated capture file or a quoted command + output; never from memory or
+  another document's prose (GA-R1 rule 2). Legal stage/gate status tokens are
+  OPEN / BLOCKED / HELD / CLOSED, used only in CURRENT-STATE (vocabulary ruling,
+  Option A: readiness is not a state; event words are history, never states).
+- **Rulings are gated like mutations (GA-R5).** ONE decision per operator
+  exchange -- batch adoptions are invalid. A ruling exists only when its Status
+  line quotes the question AND the operator's exact utterance, dated, committed
+  and pushed before dependent work. Ambiguous/template answers rule NOTHING:
+  stop and ask. Never adopt from an inferred or reconstructed ruling -- an
+  operator ruling is a value under hard rule 2.
+- **D-number admission (GA-R3):** a new D-number needs architectural consequence
+  beyond the stage, a Roosevelt-delta (the A1 test: a Roosevelt build session
+  would grep it before touching a built surface), or supersession. Everything
+  else is OPERATIONAL: runbook edit / session-changelog line / as-built row,
+  never a D-number. Entries carry [ARCH]/[OPS] tags; doubt resolves DOWN to OPS.
+- **Memory governance (GA-R7):** auto-memory records observations and
+  conventions ONLY -- never operator policy, priorities, or postures. Any
+  memory claiming operator intent is PROPOSED until confirmed verbatim; remove
+  on discovery. Durable observations GRADUATE to their repo surface; memory is
+  never the only copy. Stage close includes a full memory review (rules 1-4).
+- **Reconciliation circuit-breaker.** If you have been fixing records to match
+  records for more than one cycle without touching the actual deliverable,
+  STOP and report to the operator. Record-churn presenting as progress is this
+  project's measured failure mode (GA-F06); escalating is the correct move.
+
+## Posture
+
+- This is a commercial multi-tenant cloud with HARD tenant isolation (SCS
+  Domain Manager persona). Treat tenant-visible surfaces and cross-domain
+  boundaries as security-relevant in every change.
+- The operator community here values debate and industry best practice over
+  quick fixes. Push back with sources when you disagree; own mistakes plainly
+  and concisely. Fabricated flags, values, or version numbers are the cardinal
+  sin - if you have not verified an option name or version, say so and verify.
+- Responses stay concise. Decisions get explicit rationale.
+
+
+================================================================================
+## references/operating-discipline.md (load on demand)
+================================================================================
+
+# Operating discipline
+
+How work is executed on this cloud. These conventions exist because the
+runbooks and scripts ARE the product: a fix that works but is undocumented,
+unrepeatable, or Roosevelt-incompatible is a failure.
+
+## The gated execution model
+
+Every command block is labeled so a command line is never mistaken for prose,
+and so mutation risk is explicit (same convention as the repo runbooks):
+
+- `RUN -- <loc>` - the block CHANGES state; run it at <loc> (jumphost, a unit
+  via `juju ssh`, the mgmt VM...).
+- `CHECK (read-only) -- <loc>` - safe to re-run.
+- `GATE:` - hard stop. Do not proceed unless the stated condition holds.
+- `Expect:` - what a passing result looks like. Always state it: the operator
+  should never have to guess whether output is good.
+- `> CAUTION:` - destructive, secret-handling, or irreversible.
+
+Sequence discipline: read-only audit -> present the mutation -> operator
+approves/runs -> verify the result -> next step. One gated mutation at a time;
+never batch destructive steps. If output comes back unexpected, STOP and
+re-derive from the live state - do not improvise a correction inline.
+
+**Chat (no shell):** you prepare blocks, the operator runs and pastes output.
+Treat pasted output as the only evidence; a block you wrote but saw no output
+for did not happen.
+
+**Live shell:** you may execute `CHECK (read-only)` blocks yourself. `RUN` and
+`> CAUTION:` blocks still get presented and human-approved first - state what
+will change and why it is the minimal correct action.
+
+## Irreversible / one-shot / secret steps
+
+- Start every consequential session with `bash scripts/run-logged.sh <label>`
+  (opens a script(1)-logged shell to ~/as-executed/; index the session in
+  logs/as-executed-index.md -- content NEVER commits, the index always does).
+- Retrieve the exact prior working command from the as-executed log or runbook
+  VERBATIM. Never improvise vault init, unseal, authorize-charm, CA issuance,
+  or anything one-shot. (DOCFIX-006: a mis-redirected `vault operator init`
+  loses the unseal keys forever.)
+- Secrets never transit argv, clipboard, scrollback, or /tmp. Capture straight
+  to a 0600 file under $HOME with `umask 077`; unseal via hidden prompt (L4);
+  transfer via base64 pipe into a root-written 0600 file (L-P6-4). Never echo
+  a secret to verify it - verify by length/format from the file.
+- Never run `maas list` (prints the API key - DOCFIX-016). Never trust a juju
+  action's human-formatted output for a captured secret or cert - pull from
+  `--format json` (indented YAML block-scalars corrupt PEMs; DOCFIX-021).
+- Authorize charms with short-lived child tokens: `juju run` persists action
+  params in the operation log (DOCFIX-011).
+
+## Record-keeping: D-NNN / DOCFIX-NNN / BUNDLEFIX-NNN
+
+- `D-NNN` - design decisions (`docs/design-decisions.md`). Append-only:
+  superseded entries stay in place, marked, with the superseding entry
+  appended. `DOCFIX-NNN` - runbook fixes. `BUNDLEFIX-NNN` - bundle fixes.
+- ALWAYS grep the repo for the next free number before assigning one -
+  collisions have happened. State "next-free verified" when you assign.
+- PARALLEL WORK numbering: when more than one workstream edits the shared numbered
+  ledgers (this repo + a parallel Claude Code stream), do NOT each independently grab
+  "next-free" -- that collides. One stream owns a given number/block; each DECLARES every
+  identifier it consumes in its commit; the other re-greps AFTER the parallel push lands
+  and resumes above it. `scripts/ledger-scan.sh` derives next-free from decision HEADERS
+  (not prose mentions -- a "next-free D-072" pointer must not inflate the count).
+  Keep "Next-free:" pointer lines on ONE line (a word-wrapped continuation escapes the
+  line-based exclusion); or just rely on the scan, which is the next-free authority.
+- Mid-task findings are logged as proposals, not acted on (hard rule 1).
+  A finding that changes a runbook becomes a DOCFIX; one that changes
+  architecture becomes a D-NNN with status PROPOSED until the operator rules.
+- Status vocabulary: PROPOSED/OPEN -> ADOPTED/DECIDED -> SUPERSEDED (by
+  D-MMM). Do not implement PROPOSED items.
+- Before acting on any change request, grep design-decisions for the
+  governing decision on that surface (and its dependents - e.g. a runbook
+  step may rely on the current state). Finding a PROPOSED/OPEN decision
+  means presenting its recorded options for a ruling, not picking one.
+
+## Delivery rules (files handed to the operator)
+
+- Multi-file changes ship as repo-relative ZIPs, never loose files (the
+  Windows/GitHub Desktop loose-file workflow misplaces them).
+- Everything committed is ASCII-only, LF-only. Validate before delivery:
+  non-ASCII with `grep -nP '[^\x00-\x7F]'` (or a Python byte read); CR bytes
+  with a Python `data.count(b"\x0d")` - a `grep $'\r'` false-positives on
+  `$r...` tokens. Non-ASCII in OpenStack config has caused silent daemon
+  failures (mod_wsgi UnicodeDecodeError).
+- On-box script delivery over `juju ssh` goes as a base64 pipe decoded to a
+  file, then the FILE is executed - never a raw heredoc (paste-mangling and
+  stdin-consumption both bite; see script-authoring on `read` vs pipes).
+- Windows-side steps are PowerShell-native (no bash heredocs, no backslash
+  continuations). The operator commits from Windows; the jumphost only pulls.
+
+- Credential exposures and security obligations get a ROW in
+  docs/security-ledger.md at discovery time (owner + status) - never only a
+  script-comment note; the ledger is reviewed at every phase-00 and handoff.
+- Under operator-granted blanket approval, the delivery contract is: implement,
+  then hand over ONE cumulative repo-relative ZIP plus a changelog where every
+  item states what changed, the evidence for why, and a per-item revert. The
+  changelog is the review surface; opinion-weighted calls are flagged as such.
+
+## Session continuity: the in-flight ledger
+
+Long sessions on this cloud get COMPACTED, often several times. Work that lives only in
+chat scrollback is lost at compaction. `docs/session-ledger.md` is the durable record of
+what is IN FLIGHT (active build, backlog, operator-gated items, open decisions, numbering
+state, state facts). Standing practice:
+- Read the ledger AND run `scripts/ledger-scan.sh` at session start; reconcile.
+- The scan is the DRIFT CHECK: it derives open decisions (last Status line per block, so an
+  amendment closes it), OPEN security rows, and next-free numbers straight from the repo.
+  The narrative ledger must not claim CLOSED what the scan shows OPEN, nor omit what it
+  surfaces. A ledger without this check rots (cf. D-070's unexercised-snapshot critique).
+- Update the ledger at every deliverable/commit -- it is a standing deliverable like the
+  changelog. Changelog = what changed; ledger = what is still open.
+
+## Boundary mutations: adds-before-removes with a readback gate
+
+When tightening a security boundary (SG rules, firewall, policy) that a live flow depends on,
+NEVER remove the permissive rule before the specific replacements are proven present. Create
+the narrow rules, READ THEM BACK (fail if any is missing), and only THEN remove the wide rule
+by its MEASURED id. There must be no window in which a required flow (e.g. the magnum
+conductor -> mgmt apiserver poll) is unauthorized. Verify the tightened boundary by FUNCTIONAL
+outcome afterwards, not by assuming the rule text is sufficient.
+
+## Attestation gates for unautomatable safety items
+
+Some acceptance items cannot be scripted -- e.g. a SECOND person performing the Vault unseal
+(D-069). Never auto-pass such an item. Gate it on a ledger ROW (docs/security-ledger.md):
+report PASS_PENDING_MANUAL while the row is OPEN, PASS only when it is attested CLOSED/rehearsed,
+HOLD if the row is missing. Auto-passing an undone safety item is the exact failure D-070 retired.
+
+## Debate and correction norms
+
+- Challenge weak reasoning with sources; the operator prefers industry best
+  practice over the quick fix and will push back hard on unverified claims.
+  When challenged, verify (docs, source, live probe) rather than defend.
+- Own mistakes plainly, in one or two sentences, then fix. No self-flagellation.
+- When a prior decision looks wrong, propose superseding it through the D-NNN
+  process - do not quietly deviate from it.
+
+## Troubleshooting entry discipline
+
+Before any server-side hypothesis for "X used to work, now it doesn't" on a
+web UI: eliminate client state first (incognito window, ~10 seconds), then a
+server-side curl, THEN hypothesize. Before any command that acts on tenant
+resources: confirm which project/domain scope the shell holds
+(`openstack token issue`-level certainty) - `server create` and friends use
+ambient scope silently. Full triage method: references/troubleshooting.md.
+
+## Guards are load-bearing: reword the content, never weaken the check
+
+When a repo-lint guard (or any fail-closed check) goes RED on text you
+believe is legitimate, the fix is to REWORD the text or add the guard's
+own documented opt-out marker -- never to loosen the guard. Precedent: L3
+correctly flagged the config.xml tombstones; the tombstones were reworded
+and the guard kept. (Rotated from the session ledger's standing-lessons
+block, 2026-07-19.)
+
+
+================================================================================
+## references/environment.md (load on demand)
+================================================================================
+
+# Environment - Omega Cloud (VR0 DC0 testcloud)
+
+Facts here are ANCHORS, not command inputs. Anything marked (verify) must be
+re-measured or re-read from the repo/live cloud before use in a command -
+hard rule 2 applies. Snapshot date: 2026-07. The repo is fresher than this file.
+
+## The three deployments (this file covers VR0 in detail; VR1 is a pointer)
+
+- **Testcloud (VR0 DC0, now):** four KVM host VMs (openstack0-3) on a single
+  hypervisor, managed by MAAS + Juju. Single-DC virtual rehearsal. The rest
+  of THIS file is VR0's own ground truth.
+- **VR1 DC-DC (in progress, D-100..D-110):** two-DC + Office1-headend
+  rehearsal -- VR0's testcloud host is being REPURPOSED into DC1 (not a
+  second concurrent cloud). This file does NOT carry VR1's own facts (Office1
+  network, DC1/DC2 mesh links, per-DC MAAS/Vault roots, etc.) -- those live
+  in `docs/dc-dc-deployment-workflow.md` (master tracker: stage status +
+  tooling gap register, read this first for any VR1 work) and
+  `docs/dc-dc-buildout-design.md` (the design itself). Runbooks:
+  `runbooks/README.md`'s "VR1 DC-DC track" section. IaC: `opentofu/`
+  (UNVALIDATED -- see its own README).
+- **Roosevelt (future):** bare-metal, multi-DC, commercial production
+  (3310 Roosevelt Blvd, Eugene OR). Dedicated node roles (gateway/controller/
+  compute split) - unlike the hyperconverged testcloud. Every design choice is
+  judged by its transfer to Roosevelt -- VR1 is the rehearsal for THIS, not
+  an end in itself.
+
+## Stack (verify against appendix-B for pins)
+
+Charmed OpenStack Caracal 2024.1 - Juju/MAAS/component versions live in
+`runbooks/appendix-B-asbuilt-version-lock.md` (VR0) and `docs/CURRENT-STATE.md`
+section 7 (VR1 substrate) - Vault TLS (charm-pki
+root CA), OVN 24.03, Ceph Squid, Octavia (amphora), Barbican,
+mysql-innodb-cluster, RabbitMQ, Magnum + magnum-capi-helm driver + azimuth
+(SUBSTRATE below the charms -- pins + traps in `references/platform-traps.md`:
+libvirt/KVM via the `dmacvicar/libvirt` OpenTofu provider `0.9.8` (tofu +
+component pins: `docs/CURRENT-STATE.md` section 7, the pin authority);
+**LXD pinned to the `5.21` LTS track** -- MAAS 3.6/3.7 cannot talk
+to LXD >= 6.7, D-114; OPNsense edges driven by REST API, D-113; the vcloud
+host is ITSELF a KVM guest, so nesting is a per-level requirement)
+capi-helm-charts (kubeadm engine), in-cloud single-homed CAPI mgmt VM
+(capi-mgmt-v2, k8s-snap, D-035). NetBox is the IPAM apex: never hand-edit
+downstream MAAS or overlays for network values.
+
+## Control points
+
+- **Jumphost:** `vcloud` - all live commands run here. Has juju,
+  the openstack CLI (SNAP - cannot read /tmp; use $HOME), jq, kubectl.
+- **Repo:** `https://git.baldurkeep.com/OpenStack/openstack-caracal-dc-dc`
+  (web) / `.../git/OpenStack/openstack-caracal-dc-dc.git` (clone) -- a
+  documented ANCHOR FACT (this repo's name/path has already changed once, see
+  D-110; re-verify with `git remote -v` before trusting it, same as any other
+  fact in this file). repo-lint: allow-selfref. Operator commits from Windows
+  (PowerShell / GitHub Desktop - strips exec bits; `.gitattributes` pins LF);
+  the jumphost only pulls.
+- **Session `$REPO` convention:** set `$REPO` once per session to your clone's
+  root (see `runbooks/README.md` Conventions); every runbook RUN block
+  references `$REPO`, never a hardcoded clone path. `repo-lint` L9 enforces
+  this for scripts/RUN-blocks/skill files.
+- **Juju model:** `openstack`. **MAAS profile:** `admin` (call
+  `maas admin ...` directly; NEVER `maas list` - it prints the API key).
+- **Management substrate (verify; NEVER touch in teardown):** the MAAS
+  machines hosting juju, lxd, and tailscale are hard-excluded from teardown
+  scripts. Resolve system_ids live via `scripts/lib-hosts.sh` - system_ids
+  are re-minted on every re-enrollment (DOCFIX-040).
+
+## The six network planes (D-052 / D-053; verify against scripts/lib-net.sh)
+
+| Plane | CIDR | Carries | Notes |
+|---|---|---|---|
+| provider-public | 10.12.4.0/22 | Public API VIPs + tenant FIPs (Pattern A, D-060) | gw .4.1; untagged |
+| metal-admin | 10.12.8.0/22 | MAAS PXE, operator/admin endpoint, default binding | gw .8.1; DC-local |
+| metal-internal | 10.12.12.0/22 | ALL service-to-service control (internal API, DB, MQ, Vault, peers) | tagged VID 103 via br-internal; no gw |
+| data-tenant | 10.12.16.0/22 | Tenant Geneve overlay | no gw |
+| storage | 10.12.32.0/22 | Ceph public | no gw |
+| replication | 10.12.36.0/22 | Ceph cluster (OSD replication) | no gw |
+
+- API VIPs: triple per clustered charm (provider/admin/internal), matching
+  last octet in the .50-.60 band, 11 clustered charms (verify count live).
+- Tenant pool: 10.20.0.0/16 (hybrid model D-016 - pool in NetBox, per-project
+  /24s Neutron-managed). Avoid collisions with capi-mgmt (10.20.0.0/24) and
+  existing tenant /24s - list live before allocating.
+- Provider NIC rule (D-057/D-060): the provider uplink must land in OVS
+  `br-ex`, never enslaved to a Linux bridge, and `br-ex` carries no L3 config.
+
+## Repo map (what lives where)
+
+- `bundle.yaml` - the canonical bundle; VIPs/units baked in for testcloud.
+- `runbooks/phase-00..08-*.md` - the gated deploy sequence, in order, each
+  ending in a hard gate. `runbooks/README.md` has the label conventions.
+- `runbooks/appendix-A-troubleshooting.md` - symptom->cause->fix index keyed
+  by D-NNN/DOCFIX-NNN. First stop for any known-looking failure.
+- `runbooks/appendix-B` - version lock. `appendix-C` - identity/RBAC.
+  `appendix-D` - Magnum trust model. `ops-capi-recovery.md` - CAPI/Magnum
+  post-deploy operations.
+- `docs/design-decisions.md` - the D-NNN architectural record (append-only
+  discipline; superseded entries stay, marked).
+- `scripts/` - phase scripts + `lib-net.sh` / `lib-hosts.sh` (pinned values)
+  + tenant onboarding/acceptance. `tests/<script>/` - offline fakebin
+  regression harnesses.
+- `policies/domain-manager-policy.yaml` + `policies/overrides.zip` - the SCS
+  Domain Manager RBAC override (D-051/D-064); the zip ships IN the bundle
+  (keystone resources, DOCFIX-071) and provider-bundle-check drift-guards it.
+- Operational tooling (2026-07 hardening set): `scripts/preflight.sh` (single
+  pre-deploy gate: lint -> bundle invariants -> Charmhub channel assert -> live
+  MAAS pre-flight), `scripts/repo-lint.sh`/`repo_lint.py` (static hygiene,
+  L1-L6), `scripts/cloud-assert.sh` (behavioral verifier + `--capture` BOM to
+  `asbuilt/<date>/`), `scripts/run-logged.sh` (as-executed session logger),
+  `scripts/channel_assert.py`. `runbooks/ops-restart-procedure.md` (full-cloud
+  restart). `docs/security-ledger.md` (exposure/obligation rows).
+  `logs/as-executed-index.md` (committed index; log content stays jumphost-only).
+- No KVM snapshot restore path exists (D-070 superseded D-012):
+  rebuild-from-runbooks IS the restore path; baselines come from cloud-assert
+  `--capture`.
+- **VR1 DC-DC additions (2026-07-09/10), not part of VR0's map above:**
+  `docs/dc-dc-deployment-workflow.md` (master tracker), `docs/dc-dc-buildout-
+  design.md` (design), `docs/design-decisions.md` D-100..D-110,
+  `runbooks/dc-dc-phase0..6-*.md` + `dc-dc-teardown-rollback.md`,
+  `opentofu/` (libvirt/MAAS/OPNsense IaC, UNVALIDATED -- see its own
+  README), `netbox/dc-dc-prefixes-import.py`, `scripts/dc-dc-*.sh` (MTU/Ceph
+  budget calculators, Ceph replication tooling).
+
+## Identity / tenancy model (see appendix-C/D and D-051, D-064, D-066)
+
+Domain-per-client. Operator provisions: domain + a domain `manager` (SCS
+Domain Manager persona - the plain `admin` role is NOT domain-confinable) +
+quotas. The tenant self-services everything inside: projects, users, roles
+(only member + load-balancer_member assignable - never admin/manager),
+app credentials, networks, templates, clusters. Magnum mints per-cluster
+trust app-creds carrying the trustor's roles frozen at mint time (D-039:
+trustor needs load-balancer_member or CAPO 403s on Octavia). Cluster create
+must run as a password identity, not an app-cred (trust-creation block,
+D-066). Every identity command is DOMAIN-QUALIFIED (`--domain`,
+`--user-domain`, `--project-domain`) - scope-default resolution silently
+lands in the wrong domain and 404s misleadingly.
+
+
+================================================================================
+## references/platform-traps.md (load on demand)
+================================================================================
+
+# Platform traps and version pins -- libvirt/KVM, MAAS+LXD, OPNsense
+
+The substrate BELOW the cloud (the hypervisor, the provisioner, the edge
+routers) has its own version boundaries and its own silent-failure modes.
+Every item below is either (a) sourced to a vendor/upstream URL, or (b)
+MEASURED on this project and sourced to the repo's own D-NNN / changelog.
+Nothing here is generic advice: each entry exists because it cost, or would
+have cost, a session.
+
+Companion files: `references/opentofu-provider-docs.md` (provider schema +
+fetch methodology), `references/troubleshooting.md` (method). Start at the
+verbatim-error index at the bottom if you have an error string in hand.
+
+## Version pins that actually matter (and why)
+
+| Thing | Pin | Why the pin exists |
+|---|---|---|
+| `dmacvicar/libvirt` provider | `0.9.8` | 0.9.0 was a compatibility-BREAKING rewrite; anything remembered from 0.8-era examples is wrong (see below) |
+| OpenTofu | live pin: CURRENT-STATE.md section 7 | Stage-1 as-run value is historical (git history) |
+| LXD | **`5.21` LTS track** | MAAS 3.6/3.7 is INCOMPATIBLE with LXD >= 6.7 (D-114; see below) |
+| MAAS | 3.7.2 (VR0) | the LXD ceiling above is a property of MAAS 3.6/3.7 |
+| OPNsense | live pin: CURRENT-STATE.md section 7 (26.7 as of 2026-07-18) | ISC-DHCP left core AT 26.1 -- Kea/dnsmasq only on every later release (see below) |
+| Vault charm | `1.8/stable` | 1.16 is an incompatible charm, deliberately NOT an upgrade (appendix-B, D-068) |
+
+Charm channels/revisions are appendix-B's job, not this file's. This file
+covers only the substrate the charms sit on.
+
+---
+
+## 1. dmacvicar/libvirt provider (pinned 0.9.8)
+
+### 1a. The 0.8 -> 0.9 break invalidates most examples you will find
+
+v0.9.0 (2025-11-08) is a deliberate, compatibility-breaking rewrite on the
+plugin framework, with the design principle "HCL maps almost 1:1 to libvirt
+XML"; the legacy provider stayed on the `v0.8` branch. v0.9.1 (2025-11-30)
+then code-generated the schema from libvirt's XML schema, renaming attributes
+again (`unit` -> `memory_unit`, `os.arch` -> `os.type_arch`, `os.machine` ->
+`os.type_machine`, `os.kernel_args` -> `os.cmdline`, camelCase -> snake_case
+throughout).
+- https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.0
+- https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.1
+
+**Consequence:** blog posts, StackOverflow answers, and model memory almost
+all describe 0.8. Nested structures are attribute-style objects
+(`os = { ... }`, `devices = { ... }`), not HCL blocks. Confirm against
+`docs/resources/*.md` + `examples/*.tf` at the pinned tag, or
+`tofu providers schema -json`.
+
+### 1b. Bare `memory` is KiB, not MiB -- 1024x too little RAM (DOCFIX-188)
+
+The 0.9.1 migration guide states the rule explicitly: "Value/unit pairs are
+explicit -- whenever libvirt exposes a value with a unit attribute the
+provider now has two attributes (`memory` + `memory_unit`, `capacity` +
+`capacity_unit`, etc.). **Leaving the unit unset lets libvirt use its
+default.**"
+(https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.1)
+
+And libvirt's default is KiB: "The units for this value are determined by the
+optional attribute `unit`, which defaults to 'KiB'"
+(https://libvirt.org/formatdomain.html#memory-allocation).
+
+So `memory = 2048` with no `memory_unit` is **2 MiB**, not 2 GiB. In 0.8,
+`memory` meant MiB -- that is exactly how this shipped here.
+
+    memory      = var.memory_mib
+    memory_unit = "MiB"      # REQUIRED. Never omit.
+
+Signatures (all measured, 2026-07-12): QEMU cmdline `-m size=2048k`;
+`virsh dominfo` -> `Max memory: 2048 KiB`; a FreeBSD guest echoes
+`/boot.config` (262 bytes of serial output) and then triple-faults handing off
+to `/boot/loader`. `tofu validate` CANNOT catch it (the attribute is
+optional) -- `scripts/opentofu-validate.sh` check **S1** does.
+Evidence: `docs/archive/changelogs/changelog-20260712-libvirt-memory-unit-rootcause.md`,
+`docs/archive/incident-20260712-opnsense-edge-boot-triplefault.md`.
+
+The provider's own current domain examples now carry `memory_unit = "MiB"`
+(`docs/resources/domain.md`) -- a fresh reader of the docs would get this
+right; a reader of any 0.8-era example would not.
+
+### 1c. No `features` block => `acpi=off` => FreeBSD panics (DOCFIX-190)
+
+The whole `features` attribute is optional, so omitting it is schema-valid --
+and libvirt then renders the machine with `acpi=off` (measured on the QEMU
+cmdline: `-machine pc-i440fx-noble,...,acpi=off`).
+
+    features = {
+      acpi = true
+      apic = {}          # acpi is a Boolean; apic is a nested object
+    }
+
+(schema: `docs/resources/domain.md`, `features.acpi` (Boolean),
+`features.apic` (Attributes).)
+
+Three distinct consequences, only one of which is loud:
+- FreeBSD/OPNsense **panics** (it finds the local APIC via ACPI's MADT and
+  ships no `atpic` fallback): `panic: running without device atpic requires a
+  local APIC` -> `db>` prompt -> domain shows `running` while burning 100% of
+  one core forever.
+- Linux guests boot but degrade: no clean ACPI shutdown/reboot signalling.
+- **MAAS drives power off/on via ACPI**, so a MAAS-managed node VM without
+  ACPI can only ever be hard-stopped. That would have been a nasty Stage-3
+  debug.
+Evidence: `docs/archive/changelogs/changelog-20260712-libvirt-acpi-kernel-panic.md`.
+Guard: `scripts/opentofu-validate.sh` check **S2**.
+
+### 1d. No `cpu` block => generic CPU => NO `svm` => nested KVM impossible
+
+Found 2026-07-13. With no `cpu` attribute, libvirt hands the guest a generic
+emulated CPU model with no virtualization flag. Measured: host is an **AMD
+EPYC 9965**, the default-CPU guest was handed an **`Opteron_G3`**. Nothing
+errors -- the guest just has no `/dev/kvm` and no `svm` in `/proc/cpuinfo`.
+
+Ubuntu's own nested-virt guide states the guest-side requirement: set the
+guest `cpu mode` to `host-model` or `host-passthrough` for the guest to see
+`svm`/`vmx`
+(https://ubuntu.com/server/docs/how-to/virtualisation/enable-nested-virtualisation/).
+
+    cpu = {
+      mode = "host-passthrough"
+      # per-caller: pass svm through, or disable it as router hardening
+      features = var.expose_nested_virt ? [] : [
+        { name = "svm", policy = "disable" }
+      ]
+    }
+
+**The host side is a SEPARATE requirement and bites at every level.** The
+vcloud host is ITSELF a KVM guest (`systemd-detect-virt` -> `kvm`), so nesting
+must be enabled at each level, not just ours:
+- check: `cat /sys/module/kvm_amd/parameters/nested` -> `Y` or `1`
+  (Intel: `/sys/module/kvm_intel/parameters/nested`)
+- persist: `options kvm-amd nested=1` in a file under `/etc/modprobe.d/`
+  (same source as above)
+
+Why this matters here (D-114): LXD **virtual machines** are qemu/KVM guests,
+so MAAS composing service VMs inside a site containment VM needs working
+nested KVM at that depth; and `nova-compute` on the DC nodes needs it one
+level deeper still. `modules/node-vm` still has the missing-`cpu`-block defect
+-- logged, NOT fixed, because DC1 is gated behind Office1
+(`docs/archive/changelogs/changelog-20260713-d114-voffice1-nested-virt.md`).
+
+### 1e. "will be updated in-place" DOES NOT mean "the guest stays up"
+
+A plan line reading `libvirt_domain.vm will be updated in-place` **bounced a
+live guest** (measured 2026-07-13: uptime 8m36s -> 6s; ~30s with no routing and
+no DHCP on the Office1 edge). "In-place" is a statement about the Terraform
+RESOURCE, not about the domain.
+
+Upstream confirms the mechanism: the v0.9.4 release notes describe domain
+update as "updating a domain (e.g. changing memory) **would undefine and
+re-define it**" (the 0.9.4 fix was only to preserve NVRAM/TPM files across
+that undefine), and v0.9.6 added "configurable update shutdown behavior so
+domain updates can request guest shutdown and wait with a configurable timeout
+before forcing a stop."
+- https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.4
+- https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.6
+
+**Rule: treat ANY `tofu apply` whose plan touches a `libvirt_domain` as an
+OUTAGE of that guest. Schedule and gate it as one.** Read the plan's resource
+list before applying; `0 to change` on the domains is the only assurance that
+a running guest is not about to bounce
+(`docs/session-ledger.md`, standing lesson 2).
+
+Corollary (DOCFIX-187/DOCFIX-188): some domain attributes are CREATE-time to
+libvirt (max boot memory, `machine`, `cpu`). The provider will happily plan an
+in-place update that libvirt then ignores. If a changed value does not show up
+in `virsh dominfo`, `destroy` + `undefine` the domain and re-apply (volumes
+survive an `undefine`).
+
+Second corollary (measured 2026-07-20/21): the undefine/redefine also
+**REGENERATES every UNPINNED NIC MAC**. The plan reads `0 to add, N to change,
+0 to destroy`, the apply succeeds -- and every touched domain now has brand-new
+MACs. Anything that keys on those MACs is silently stranded: in the 2026-07-21
+commissioning incident all 9 MAAS-enlisted nodes became UNKNOWN at PXE (no
+"Performing PXE boot" event, silent 30-min timeouts), because a serial-console
+retrofit apply had drifted every boot-interface MAC. **Rule: any domain whose
+MACs are load-bearing (MAAS-enlisted nodes above all) carries config-pinned
+MACs** -- `mac = { address = ... }` per interface; see `modules/node-vm`'s
+`interface_macs` + `tests/node-vm`. VR-only trap: Roosevelt metal has fixed
+MACs.
+
+### 1f. Two more upstream behaviours worth knowing (from the release notes)
+
+- `capacity_unit = "GiB"` on a volume caused **"Provider produced inconsistent
+  result after apply"** on every apply before 0.9.4 (libvirt normalizes to
+  bytes). Fixed in 0.9.4 -- if you see that error string, check the provider
+  version first.
+- `tofu destroy` of a **`dir` pool** used to DELETE the backing directory
+  (`StoragePoolDelete`). Since 0.9.4 the directory is preserved by default,
+  with an explicit `destroy.delete = true` to opt back in. Relevant to
+  `modules/dc-storage-pool`.
+  (https://github.com/dmacvicar/terraform-provider-libvirt/releases/tag/v0.9.4)
+- **UNVERIFIED:** the 0.9.4 notes name a `destroy.shutdown.timeout` option
+  while `docs/resources/domain.md` documents `destroy = { graceful, timeout }`,
+  and I could not find the 0.9.6 update-shutdown attribute documented at all.
+  Before relying on either, read the real schema:
+  `tofu providers schema -json | jq '.provider_schemas[].resource_schemas.libvirt_domain'`.
+
+### 1g. `forward=bridge` networks + `br_netfilter`: a global FORWARD-drop silently kills bridged frames (D-125)
+
+A `libvirt_network` with `forward = { mode = "bridge" }` (dmacvicar schema:
+`bridge = { name = "<host-bridge>" }`, no `ips`, no NAT) attaches guest taps to a
+**pre-existing** host bridge -- libvirt does NOT create the bridge, so it must
+already exist (declare it in the host's netplan, not the tofu) or the network
+fails to start. This is the Model B "bridge-in" WAN path (D-125): the inner
+OPNsense WAN rides `br-vr1-dc0-wan` out through `vvr1-dc0`'s IP-less uplink NIC to
+the single vcloud ISP NAT.
+
+Two silent-failure traps ride along:
+
+- **`br_netfilter` makes bridged frames traverse the L3 `FORWARD` chain.** So a
+  GLOBAL forward-drop -- `iptables -P FORWARD DROP`, or an nftables forward hook
+  with `policy drop` and no interface match -- silently kills the WAN bridge even
+  though it is "just L2". Keep any DC-LOCAL forward-drop (SEC-010) **scoped to the
+  transit interface** (`oifname/iifname "<transit>"`), never global. Note
+  `net.ipv4.ip_forward=0` is L3-only and does NOT affect pure bridging -- do not
+  reach for it expecting to gate a bridge, and do not assume `ip_forward=1` is
+  required just because an older NAT-based design needed it.
+- **Foreign-MAC egress across a nested bridge is unprovable until apply.** When the
+  bridged guest is itself inside another guest (OPNsense inside `vvr1-dc0`), the
+  outer NAT's `virbr` sees a foreign source MAC arriving on the containment VM's
+  port; an anti-spoof/nwfilter drop there blackholes egress. `tofu validate` is
+  clean regardless. TEST IN ISOLATION FIRST: attach a throwaway guest to the
+  bridge, confirm it gets an address and pings out, BEFORE the real chain rides
+  it. (D-125's fallback for this failure is double-NAT: masquerade at `vvr1-dc0`
+  instead of relying on nested L2.)
+
+## 2. AppArmor blocks qemu on any non-default pool path
+
+libvirt's stock `abstractions/libvirt-qemu` grants qemu the DEFAULT pool path
+(`/var/lib/libvirt/images`) only. A pool anywhere else is blocked by AppArmor
+**even with perfect POSIX permissions**, and the failure names nothing:
+
+- libvirt/qemu says only: `Could not open '<path>': Permission denied`
+- the actual denial is in the kernel log:
+  `apparmor="DENIED" operation="open" profile="libvirt-<domain-uuid>" name="<path>"`
+- the domain DEFINES fine and fails at START -- so `tofu apply` can "succeed"
+  into a dead guest.
+
+Upstream (still open, provider issue #920, with the same workaround):
+https://github.com/dmacvicar/terraform-provider-libvirt/issues/920
+
+Fix, in the vendor-sanctioned override include (survives package upgrade --
+do NOT edit the shipped abstraction):
+
+    # /etc/apparmor.d/local/abstractions/libvirt-qemu
+    /var/lib/libvirt/vr1/** rwk,
+
+This is now installed by `bash scripts/prereqs/install-apparmor-libvirt.sh`
+(pool parent overridable via `VR1_POOL_PARENT`), wired into
+`scripts/prereqs/install-all.sh` and reported by `check-prereqs.sh`. It cost a
+session on 2026-07-12 (DOCFIX-186) because it existed only as hand-applied host
+state; `docs/archive/changelogs/changelog-20260713-apparmor-libvirt-prereq.md`.
+
+## 3. MAAS + LXD
+
+### 3a. MAAS 3.6/3.7 is INCOMPATIBLE with LXD >= 6.7 (D-114)
+
+Canonical's own announcement: LXD 6.7 "consolidates some API endpoints" that
+MAAS's pinned **pylxd 2.3.5** cannot speak to (fixed in **pylxd >= 2.3.9**,
+not yet in a MAAS release). Verbatim guidance: "We recommend using LXD <=6.6
+or the 5.21 LTS release until further notice."
+https://discourse.maas.io/t/maas-incompatibility-with-lxd-6-7/15749
+
+VR0 runs LXD **5.21.4** and is therefore safe by accident of timing; D-114
+makes it a decision. **LXD 5.21 LTS is supported to June 2029**
+(https://canonical.com/blog/lxd_5-21-0_lts).
+
+**The live hazard is the snap auto-refresh, not the install.** LXD's docs:
+"By default, installed snaps update automatically when new releases are
+published to the channel they're tracking"; the `latest` track "typically
+points to the latest feature release", is "a continuously rolling release
+track", and is "not recommended for general use"; a bare `snap install lxd`
+uses the most recent LTS track, "which is currently 5.21".
+https://canonical.com/lxd/docs/latest/reference/releases-snap/
+=> install/refresh explicitly on `5.21/stable` and verify the tracked channel
+(`snap list lxd`, `snap info lxd`) before blaming MAAS for an LXD it can no
+longer talk to.
+
+### 3b. LXD's own bridge runs a dnsmasq DHCP server -- MAAS says turn it off
+
+"Bridges created by LXD are managed, which means that in addition to creating
+the bridge interface itself, LXD also sets up a local `dnsmasq` process to
+provide DHCP, IPv6 route announcements and DNS services to the network"
+(`ipv4.dhcp` defaults to **true**).
+https://canonical.com/lxd/docs/latest/reference/network_bridge/
+
+MAAS's own LXD VM-host procedure therefore has you disable exactly that,
+because MAAS must be the DHCP/PXE authority for the machines it composes:
+
+    lxc network set lxdbr0 dns.mode=none
+    lxc network set lxdbr0 ipv4.dhcp=false
+    lxc network set lxdbr0 ipv6.dhcp=false
+
+https://canonical.com/maas/docs/how-to-manage-machines
+
+This is the concrete form of D-114's DHCP warning. On `office1-local`,
+**OPNsense/Kea is authoritative** (10.10.0.0/24, pool .100-.199). Two DHCP
+servers on one L2 is an intermittent, genuinely unpleasant failure. Never
+bridge `lxdbr0` onto the site LAN without disabling its DHCP first.
+
+### 3c. Two different LXDs in this cloud -- do not conflate them (D-114)
+
+Conflating these caused a real, recorded error:
+- **Juju-created LXD CONTAINERS** on the OpenStack nodes (`lxd:N` placements
+  in `bundle.yaml`, 21 of them). MAAS never sees these and never needs to.
+- **A MAAS-registered LXD KVM host** (the VR0 `lxd` machine) into which MAAS
+  **COMPOSES VMs** (`maas $PROFILE vm-host compose ...`) -- VR0's `tailscale`
+  machine is one. These ARE MAAS machines: enlisted, commissioned, deployed,
+  powered, released.
+
+D-114 extends the second pattern per site; the first is explicitly out of
+scope. Also note: MAAS only sees VMs in the LXD **project** the VM host was
+registered with -- VMs in other projects are invisible to it and unaffected
+(MAAS LP#1923251, https://bugs.launchpad.net/maas/+bug/1923251).
+
+**Composed-VM networking -- MEASURE, do not assume.** A MAAS-bundled copy of
+the MAAS docs states: "When composing a virtual machine with LXD, MAAS uses
+either the 'maas' LXD profile, or (if that doesn't exist) the 'default' LXD
+profile. The profile is used to determine which bridge to use."
+(served by a MAAS instance's own docs:
+https://maas.cloud.cbh.kth.se/MAAS/docs/cli/how-to-use-lxd.html -- **I could
+NOT locate this sentence on canonical.com/maas.io today; the docs site has been
+reorganized and the old URLs 404. Treat the profile->bridge mechanism as
+PLAUSIBLE-BUT-UNCONFIRMED against a primary source.**) Since a composed machine
+that PXEs on the wrong L2 is the failure this predicts, do the cheap
+measurement instead of trusting either source: `lxc profile show maas` /
+`lxc profile show default` on the LXD host, and confirm the NIC's parent bridge
+before composing.
+
+Because LXD **VMs** (not containers) are qemu/KVM guests, this pattern needs
+nested KVM at whatever depth the LXD host sits -- see 1d.
+
+## 4. OPNsense edge (traps entered at 26.1; they persist on the live 26.7)
+
+### 4a. `config.xml` is GUI-owned. Do not hand-author it. (D-112, D-113)
+
+The config-xml path is **DELETED** (template, renderer, ISO builder, and the
+module's `config_seed` volume + cdrom disk -- D-113 amendment, 2026-07-13).
+Configure the edge over the **REST API** (`scripts/opnsense-api.sh`); mint an
+API key with `scripts/opnsense-bootstrap-apikey.sh`. Three separate defects
+(no sshd, no console, an inert `<dhcpd>` block) all traced to hand-writing
+that file, and a full-config push DROPS ~667 migration-populated elements --
+including the box's only two firewall pass rules -- surviving only on an
+UNDOCUMENTED self-heal at boot. If you think the API cannot express something,
+that is a finding to raise against D-113, not a reason to write XML.
+
+Two traps that follow:
+- **A config ISO can NEVER be read on a nano image** (D-112, root-caused in
+  upstream `opnsense/core:src/sbin/opnsense-importer`: the importer probes for
+  a read-only root and `bootstrap_and_exit 0`s on a pre-installed image before
+  scanning any media). Any instruction to build one is a trap.
+- Factory default: LAN `192.168.1.1/24`, **SSH disabled**, **all inbound
+  blocked on WAN**. An unanswered ping to the WAN address is NOT a fault.
+
+### 4b. ISC dhcpd is GONE from core in 26.1 -- an `<dhcpd>` config is inert
+
+26.1 release notes: "ISC-DHCP moves to a plugin. It will be automatically
+installed during upgrades. **It is not installed on new installations because
+it is not being used**, but you can still install and keep using it." Also:
+"Dnsmasq is now the default for DHCPv4 and DHCPv6 as well as RA out of the
+box."
+https://docs.opnsense.org/releases/CE_26.1.html
+
+So on a fresh 26.1-or-later image: an ISC `<dhcpd>` block configures nothing (that was
+DOCFIX-193), and the GUI default backend is **dnsmasq**, not Kea. This edge
+deliberately runs **Kea** (10.10.0.0/24, pool .100-.199, first real lease
+served to `voffice1` 2026-07-13).
+
+### 4c. REST API: auth, endpoints, and the reconfigure step everyone forgets
+
+- Auth is **HTTP basic with an API key/secret pair**, not the root password:
+  "API access is part of the local user authentication system, but uses
+  key/secret pairs to separate account information from machine to machine
+  communication." URL pattern: `https://<host>/api/<module>/<controller>/<command>`.
+  https://docs.opnsense.org/development/how-tos/api.html
+- Kea DHCPv4 (exact paths):
+  `/api/kea/dhcpv4/get`, `/set`, `/add_subnet`, `/set_subnet/$uuid`,
+  `/del_subnet/$uuid`, `/add_reservation`, `/set_reservation/$uuid`,
+  `/get_reservation`, `/add_option`; service control:
+  `/api/kea/service/reconfigure|restart|start|stop|status`.
+  **A `set*` call only edits config -- it is NOT live until you POST
+  `/api/kea/service/reconfigure`.** A silently-unapplied change looks exactly
+  like a change that did not take.
+  https://docs.opnsense.org/development/api/core/kea.html
+- **Firewall rules have a self-rollback safety net -- use it.** The filter
+  controller exposes `savepoint`, `apply/$rollback_revision`,
+  `cancel_rollback/$rollback_revision`, `revert/$revision`: "When calling
+  `savepoint()` a new config revision will be created and the timestamp will be
+  returned for later use. **If the `cancelRollback(savepoint)` is not called
+  within 60 seconds, the firewall will rollback to the previous state**."
+  For any remote rule change on a router you reach THROUGH that router, a
+  savepoint means a mistake self-reverts instead of locking you out.
+  https://docs.opnsense.org/development/api/core/firewall.html
+- Do NOT re-implement vendor internals to bootstrap. OPNsense stores API
+  secrets as `crypt(secret,'$6$')`; we deliberately do not mint keys offline --
+  a format drift would fail SILENTLY (keys that never authenticate). Call the
+  vendor's own model instead (`scripts/opnsense-bootstrap-apikey.sh`).
+  (D-113 amendment.)
+
+### 4d. root's shell is tcsh -- `$(...)` dies QUIETLY over SSH
+
+Measured on the Office1 edge: root's shell is **tcsh**. tcsh has no `$(...)`
+command substitution (it uses backquotes); a `$(...)` inside a quoted remote
+command is rejected with:
+
+    Illegal variable name.
+
+It already cost a defect: a pre-install snapshot silently no-op'd and the
+install then ran with no rollback point behind it
+(`docs/archive/changelogs/changelog-20260713-office1-dhcp-apply.md`). Because the step was
+non-fatal, nothing stopped.
+
+**Always feed remote commands to `sh -s`:**
+
+    ssh -i "$OPNSENSE_SSH_KEY" root@<edge> 'sh -s' <<'SH'
+    ...POSIX shell here...
+    SH
+
+(tcsh's substitution syntax: https://man.freebsd.org/cgi/man.cgi?query=tcsh)
+
+---
+
+## Verbatim error -> cause index (grep this first)
+
+| Exact string you see | Cause | Where |
+|---|---|---|
+| guest triple-faults right after echoing `/boot.config`; `virsh dominfo` -> `Max memory: 2048 KiB`; QEMU `-m size=2048k` | `libvirt_domain.memory` with no `memory_unit` -- KiB, not MiB | 1b |
+| `panic: running without device atpic requires a local APIC` (then `db>`, 100% of one core, domain "running") | no `features` block -> `acpi=off` | 1c |
+| guest has no `/dev/kvm`; `/proc/cpuinfo` has no `svm`; CPU model reads `Opteron_G3` on an EPYC host | no `cpu` block -> generic emulated CPU | 1d |
+| `Could not open '<path>': Permission denied` (domain defines, then fails to START; nothing names AppArmor) -- check `dmesg` for `apparmor="DENIED" operation="open" profile="libvirt-<uuid>"` | non-default libvirt pool path not granted in AppArmor | 2 |
+| `Provider produced inconsistent result after apply` on a volume with `capacity_unit` | provider < 0.9.4 | 1f |
+| plan says `will be updated in-place`, guest uptime resets anyway | provider undefines + redefines the domain | 1e |
+| MAAS commissioning times out at 30 min, NO PXE event for a known machine | an in-place apply regenerated unpinned NIC MACs; MAAS records stale | 1e |
+| `Illegal variable name.` from an `ssh root@<edge> '...'` | root's shell is tcsh; `$(...)` unsupported | 4d |
+| OPNsense boots on FACTORY DEFAULTS with a correct config ISO attached; console shows `>>> Invoking import script 'importer'` and nothing more | the Configuration Importer can never fire on a nano image | 4a |
+| a Kea/firewall API `set` returns success but the box's behaviour does not change | no `service/reconfigure` (or no firewall `apply`) call | 4c |
+| MAAS cannot talk to an LXD VM host after an LXD update | LXD auto-refreshed past 6.6; MAAS 3.6/3.7 needs LXD <= 6.6 or 5.21 LTS | 3a |
+| a MAAS-composed VM gets a lease MAAS did not issue, or PXEs on the wrong L2 | `lxdbr0` runs its own dnsmasq (verified); the composing LXD profile's bridge is the other candidate (unconfirmed -- measure it) | 3b, 3c |
+
+---
+
+## NetBox (upstream, `netbox.baldurkeep.com`)
+
+### `HTTP 403 Forbidden` on every API call -- but the SAME token works from `curl`
+
+**Symptom.** `urllib`/`requests`/`pynetbox` get `403 Forbidden` from the upstream NetBox on every
+endpoint, including ones a valid token plainly reads. `curl` with the identical token and URL
+returns `200`. It reads exactly like a bad or revoked token; it is not.
+
+**Cause.** Something in front of upstream NetBox (WAF / reverse proxy) filters on **User-Agent**.
+The default Python UA (`Python-urllib/3.12`) is blocked; `curl/8.5.0` is allowed. Measured
+2026-07-13: same token, same URL, UA the only variable -- `None -> 403`, `curl/8.5.0 -> 200`.
+
+**Fix.** Send an accepted `User-Agent` header. This applies to **`pynetbox`** too (it sends
+`python-requests/...`), so the repo's NetBox tooling must set it:
+
+```python
+nb = pynetbox.api(url, token=tok)
+nb.http_session.headers["User-Agent"] = "curl/8.5.0"
+```
+
+**Do not** diagnose this as a token/permission problem and go re-mint credentials -- that is the
+trap. Confirm with `curl` first; if curl works and Python does not, it is the UA.
+
+**Note:** this is an UPSTREAM-only trap so far. The Office1 sandbox NetBox (4.6.4, no proxy in
+front) accepts the default Python UA. Upstream is 4.5.8 and also uses **v1** (40-char, bare) tokens,
+while the sandbox is 4.6 and uses **v2** (`nbt_<key>.<plaintext>`). Any tool pointed at BOTH must
+handle both auth shapes and the UA -- do not assume they are the same NetBox.
+
+
+================================================================================
+## references/script-authoring.md (load on demand)
+================================================================================
+
+# Script authoring - house style and hardening
+
+Every script and paste block in this project follows these rules. They are
+not style preferences: each one encodes a failure that actually happened.
+Read this in full before writing ANY bash or python for this cloud.
+
+## Zeroth decision: does it already exist?
+
+Before writing ANY operational script or check block, search the repo:
+`grep -rli <topic> scripts/ runbooks/` - the deploy/verify surface is heavily
+scripted and duplicating an existing script creates drift (e.g. the haproxy
+backend sweep already exists as `scripts/phase-03-core-verify.sh` 3.1b).
+Route to, extend, or fix the existing artifact; write new only when nothing
+covers the need, and say which search came up empty.
+
+## First decision: what kind of block is this?
+
+The error-handling regime depends on execution mode. Choosing wrong is itself
+a bug:
+
+1. **Executed script** (`bash script.sh`, own process): `set -uo pipefail`
+   at minimum; `set -e` acceptable and usually right, with the capture
+   caveats below. Exit codes are the interface.
+2. **Interactive paste block** (operator pastes into their shell): NEVER a
+   bare `exit` (it kills their shell) and no `set -e` (it can kill their
+   shell's options or abort mid-paste). Wrap the whole block in a subshell
+   `( { ...; } )` so a stray exit is contained; signal failure by printing
+   `FAIL: ...` lines the operator can read.
+3. **Verify/count-gate block** (greps that legitimately return zero matches):
+   run WITHOUT `set -e`, and end every count-grep with `|| true` - a zero
+   count is a valid answer, not an error (L1). `bash -n` cannot catch this;
+   it is behavior, not syntax.
+
+## The header contract (executed scripts)
+
+Every script opens with a comment block stating: path + argument synopsis;
+what it does (one paragraph, referencing the D-NNN/DOCFIX it implements);
+**whether it mutates anything** ("Mutates NOTHING" / what it changes and the
+gate protecting it); usage line; exit-code contract; and "ASCII + LF".
+House exit codes: `0` PROCEED, `1` HOLD (a gate failed), `2` precondition
+missing (tool absent, wrong model, helper not found). Then:
+
+    set -euo pipefail            # or set -uo pipefail; see regime above
+    shopt -s inherit_errexit 2>/dev/null || true
+    IFS=$'\n\t'
+
+Source shared constants instead of restating them:
+`. "$SCRIPT_DIR/lib-net.sh"` (planes, VIP bands, helpers) and `lib-hosts.sh`
+(hostnames, octets, system_id resolution). If a value you need is not in a
+lib, consider adding it there rather than inlining a literal.
+
+## Hardening rules (each one is a scar)
+
+**SIGPIPE races break guards in BOTH directions.** `cmd | grep -q X` under
+pipefail: on match, grep exits, the producer takes SIGPIPE (141), the pipeline
+reports failure despite the match. In an `... || die` verify this FALSE-DIES on
+success; in an `... && die` guard it FAILS OPEN -- the 2026-07 sweep found a
+duplicate-CIDR guard that let collisions through exactly this way. Treat every
+`| grep -q` on a live pipe as a defect regardless of which way the test points.
+
+**Pipefail + SIGPIPE race.** `cmd | grep -q X` under pipefail falsely fails:
+`grep -q` closes the pipe on first match, SIGPIPE (141) kills the producer
+(`juju ssh` especially). Capture, then test:
+
+    OUT=$(cmd 2>&1 || true)
+    grep -q "pattern" <<<"$OUT"
+
+**`set -e` kills id-captures silently.** `ID=$(openstack ... || die ...)` -
+if the subshell exits non-zero before your handler fires, `set -e` aborts the
+assignment line with no message. Append `|| true` to each capture, then
+validate the captured value explicitly (see whole-output validation below).
+
+**Whole-output validation, never extract-then-check.** Do not pipe raw output
+through `awk`/`grep` to extract a field and then test the fragment - a
+partial failure yields a plausible-looking fragment. Capture the WHOLE output,
+validate its shape (e.g. `is_id(){ [[ "$1" =~ ^[0-9a-f]{32}$ ]]; }` for a
+keystone id), and only then use it.
+
+**Centralize `</dev/null` in a wrapper, not per call.** The house pattern is a
+2-line helper (`rc()`, `rcap()`, `J()`) that appends `</dev/null 2>&1` once;
+every call site then stays clean and un-forgettable. Heredoc-payload ssh
+(`ssh ... bash -s <<'EOF'`) is the ONE exemption -- stdin IS the delivery there.
+
+**Inner stdin consumption.** Any `ssh`/`sudo`/`juju ssh` inside a heredoc,
+pipe, or loop eats the remaining stdin and truncates the block. Append
+`</dev/null` to EVERY inner invocation (`</dev/tty` only when it genuinely
+must prompt).
+
+**`read` and `... | bash` are mutually exclusive.** A script piped to bash
+has the pipe as stdin, so `read` returns empty at EOF - this once silently
+created a passwordless user. For paste-safety AND working prompts: base64-
+decode to a file, then run the file (it inherits the terminal stdin).
+
+**juju invocation shape.** `juju ssh -m <model>` - the `-m` flag goes BEFORE
+the target. `juju run <unit> <action>` output: use `--format json` for
+anything captured; confirm long actions via `juju show-operation <N>`, not
+the streamed log (a wait-timeout does not mean the hook failed).
+
+**Snap confinement.** The openstack CLI snap cannot read `/tmp` - stage files
+under `$HOME`. Same for `juju attach-resource` payloads.
+
+**Client output ordering.** `openstack -f value -c X -c Y` returns columns in
+ALPHABETICAL order, not flag order. When order matters: `-f json | jq`, or
+single-column queries. After any jq returning null, run `jq 'keys'` - key
+casing is command-specific (Title-Case in lists, hyphenated in quota show).
+
+**Environment isolation.** Any block that switches identity runs in a
+subshell that first unsets all OS_* vars:
+`( for v in $(env | awk -F= '/^OS_/{print $1}'); do unset "$v"; done; export ... )`
+Thread `OS_CACERT` explicitly into isolated subshells - it gets stripped.
+Confirm scope before acting: which project/domain the token holds, not which
+you intended.
+
+**Stable keys, not drifting IDs.** Look up MAAS subnets by CIDR, machines by
+hostname, CAPI CRs by LISTING then operating on the exact returned name
+(the OpenStackCluster suffix is random per create - a wrong-name patch
+silently no-ops). system_ids are re-minted on re-enrollment.
+
+**Verify the launched cmdline, not the config text.** For OpenStack debs run
+via LSB-init-wrapped systemd: a flag "present in a file" proves nothing.
+Gate on behavior - the init script's `show-args`, `ps -ww -C <daemon> -o args`
+on the live process, and probe under the daemon's RESTRICTED PATH
+(`env -i PATH=/usr/sbin:/usr/bin:/sbin:/bin sh -c 'command -v helm'`) - an
+interactive shell's PATH masks daemon-PATH failures.
+
+**sed is not a verifier.** A non-matching `sed -i` exits 0 having changed
+nothing. Assert the post-edit content; never trust sed's exit code as proof
+of the edit.
+
+**ASCII + LF, validated.** Non-ASCII: `grep -nP '[^\x00-\x7F]'` or a Python
+byte read. CR check: Python `data.count(b"\x0d")` - `grep $'\r'` false-
+positives on `$r...` tokens. Non-ASCII in conf.d has silently killed daemons.
+
+**Python helpers live in .py files** tested against fixtures - no inline
+python-in-bash beyond one-liners. Do not assume `jq` exists off-jumphost;
+gate on it (`need_jq`) or use python3.
+
+**Secrets in scripts:** whitelist-write to 0600 files under a 0700 dir
+(`umask 077` first), never echo, never argv, measure secret length from the
+file rather than asserting an expected length (this deployment's app-cred
+secrets are 86 chars, not the commonly assumed 43 - never hardcode either).
+
+**Structured-output captures take stdout ONLY; never merge stderr.** `x=$(openstack ... -f json 2>&1)`
+is a defect: any stderr line (a `--long` deprecation warning, an SDK notice) lands at char 0 and
+kills the JSON parse -- this fail-closed a live SG audit in 2026-07. Capture stdout alone; send
+stderr to a tempfile; surface it on parse failure, never discard it (`2>/dev/null` trades the bug
+for silent error-masking). The `vr_json` helper in `scripts/lib-validate.sh` encodes this. Also
+drop deprecated flags that only add stderr noise (`--long` is unneeded; fields are present without it).
+
+**Fixture-test throwaway probe one-liners like real code.** A measurement `ss`/`tcpdump`/`awk`
+pipeline is code, and it has the same parse traps: `ss` DROPS the State column under a
+`state established` filter (peer is then `$NF`, not `$5`); `cut -d:` splits IPv4-mapped IPv6
+(`[::ffff:10.0.0.1]:443`) at the wrong colon; `grep -oE 'src [0-9.]+'` greedily eats the trailing
+`.` into the next field; charmed magnum logs to `/var/log/magnum/magnum-conductor.log`, NOT
+journald. One measurement chain in 2026-07 shipped four such bugs before each was caught. Run the
+parse against a fixture line (mapped-v6, plain-v4, the real column layout) BEFORE handing the
+operator a probe -- the same discipline as a committed script.
+
+## Testing: nothing ships on `bash -n`
+
+`bash -n` validates parse, not behavior - and most of the failures above are
+behavioral. Every nontrivial script gets an offline regression harness at
+`tests/<script-name>/run-tests.sh` in the established pattern:
+
+- `fakebin/` contains fake `juju` / `openstack` / `maas` / `kubectl` /
+  `ssh` executables that replay fixture output and log the calls they
+  receive; real coreutils stay real.
+- The harness sets `PATH="$BIN:$PATH"`, a scratch `HOME`, and env-injected
+  fixture paths, runs the target, and asserts BOTH the exit code and an
+  output regex per case: `run <want_rc> <regex> <label>`.
+- Cover: the happy path, each gate's failure branch (asserting HOLD not
+  crash), each precondition (exit 2), and any DOCFIX behavior the script
+  claims (e.g. "verify-first never creates a rule when one exists").
+- Read an existing harness (e.g. `tests/phase-07-conductor-graft/`) before
+  writing a new one; match its shape.
+
+For MUTATING scripts, the harness fakebin is STATEFUL: the fake `maas`/`juju`
+advances a phase file on each mutation call so post-mutation verification reads
+post-mutation reality (see tests/phase-00-teardown-d061 -- canary survival,
+decompose-detection, substrate-collision aborts). A `--no-prompt` flag on a
+destructive script exists FOR its harness, nothing else.
+
+**Harnesses are HERMETIC: fakes shadow, deletion un-shadows.** Never simulate
+an unavailable tool by DELETING its fake -- on a real host that un-shadows the
+real binary and the test falls through to live infrastructure (a jumphost
+gauntlet run reached real Charmhub this way). Simulate failure with a FAILING
+fake (prints a realistic error, exits nonzero); keep the fail-loud-on-unmatched
+arm in every fake so an uncovered call can never silently hit a real CLI.
+
+**A script migration commit MUST carry its harness.** The D-060 revert updated
+the scripts and left their harnesses testing the retired D-058 world -- red-at-
+HEAD tests that trained everyone to ignore red. If you change a script's
+behavior or vocabulary, the same commit updates fixtures and expectations.
+
+**Static contract:** `bash scripts/repo-lint.sh` must exit 0 before anything is
+delivered (L1 ASCII/LF, L2 stale tokens, L3 ghost refs, L4 deprecated refs,
+L5 numbering, L6 bare invocations, L7 clientdocs sweep receipt). Changing any
+tenant-facing surface (tenant-*.sh, the onboarding contract, tenant runbooks,
+the policy zip, clientdocs/ itself) trips lint L7 until clientdocs/ has been
+reviewed for staleness and the receipt is re-recorded:
+`bash scripts/repo-lint.sh --record-clientdocs-sweep` (the sweep IS the review;
+recording without reviewing defeats the rule). A guard script that must NAME stale tokens
+opts out per-file with a `repo-lint: allow-stale-tokens` marker in its header.
+Committed binaries (e.g. policies/overrides.zip) need a `*.zip binary`
+.gitattributes rule or the LF normalization corrupts them in transit.
+Introducing a tool dependency (jq, python module) means adding its presence
+gate in the same change.
+
+Read-only verify scripts DETECT and report; remediation stays a gated human
+step even when the fix is obvious - the script's job is evidence, the
+operator's job is the mutation decision.
+
+**Mock worlds must be TRUTHFUL to the real CLI/contract, and test expectations must match the
+SPECIFIED contract.** A mock that emits a 409 must actually have the resource pre-exist; a mock of
+an openstack list command must emit the real deprecation warning ON STDERR (or the stderr-separation
+rule above never gets exercised); a harness assertion that contradicts the documented exit contract
+(e.g. expecting a lone SKIP to lower the overall verdict when the contract says SKIP never lowers it)
+is a TEST bug, not a code bug -- fix the test. Three 2026-07 "failures" were untruthful mocks or
+wrong assertions, each caught by running the harness before delivery.
+
+
+================================================================================
+## references/troubleshooting.md (load on demand)
+================================================================================
+
+# Troubleshooting - method, reflexes, and routing
+
+The repo's `runbooks/appendix-A-troubleshooting.md` is the operational
+symptom->cause->fix index, keyed by D-NNN/DOCFIX-NNN (it now includes the
+mysql-innodb-cluster recovery signatures and a point-of-use identifier index).
+ALWAYS check it before diagnosing from first principles - most failures on
+this cloud have been seen before and have a validated fix.
+`ops-capi-recovery.md` covers the CAPI/Magnum stack;
+`runbooks/ops-restart-procedure.md` covers full-cloud recovery.
+This file gives you the method and the reflexes that must fire BEFORE and
+WHILE you read those.
+
+**Substrate failures (libvirt/KVM guest won't boot, AppArmor, MAAS+LXD,
+OPNsense edge):** these are NOT in appendix-A. Go to
+`references/platform-traps.md` -- it ends in a verbatim-error -> cause index
+keyed to exact strings (`panic: running without device atpic requires a local
+APIC`, `Illegal variable name.`, a bare `Permission denied` that never names
+AppArmor, `-m size=2048k`, ...). Match the string BEFORE hypothesizing.
+
+**VR1 DC-DC track:** appendix-A above is VR0-specific -- nothing in the VR1
+DC-DC track (`docs/dc-dc-deployment-workflow.md`) has been executed yet, so
+there is no equivalent incident index for it (an OpenTofu/MAAS-`vm_host`/
+OPNsense-edge failure will not be in appendix-A). Apply the SAME triage
+method below regardless, but do not expect a pre-catalogued fix for a VR1-
+specific symptom -- log a genuinely new finding as a DOCFIX/D-NNN candidate
+per this repo's own discipline rather than assuming it must already be
+documented somewhere.
+
+## Triage method
+
+1. **Reproduce and capture verbatim.** The exact error text routes you in
+   appendix-A. Paraphrased symptoms match nothing.
+2. **Eliminate cheap layers first.** Web UI misbehaving: incognito/client
+   state (~10s) before any server hypothesis. CLI misbehaving: confirm the
+   token scope (project/domain) before blaming the service - wrong ambient
+   scope produces misleading 404s/403s, especially with domain-per-client
+   identity (an un-domain-qualified lookup resolves in the WRONG domain).
+3. **Establish what is actually true, live.** `bash scripts/cloud-assert.sh`
+   first - it runs every service-own-verdict gate in one read-only sweep and
+   localizes the failing layer. Then the targeted read-only audit of that
+   surface before touching anything. juju status, the service's own state
+   (haproxy admin socket, mysql cluster-status, vault status, ovn-appctl),
+   the relevant logs. Hard rule 2: measurements, not memory.
+4. **Match against appendix-A**, then design-decisions if it smells
+   architectural. If matched: follow the recorded fix exactly (verbatim-
+   reference rule for anything one-shot).
+5. **If unmatched:** smallest-possible hypothesis, read-only test to confirm
+   or kill it, and log the finding. New root causes become appendix-A /
+   DOCFIX material - capturing them is part of the fix.
+6. **Least-destructive first, individually gated.** Reload before restart,
+   restart before rebuild, rebuild before redeploy. Never batch.
+
+## Reflexes (internalize these; they override intuition)
+
+- **juju-green is necessary, not sufficient.** `active/idle` is BLIND to:
+  a DOWN haproxy backend (D-045 - hid a dead nova-api for 3 days), a missing
+  magnum trustee domain (D-046 - magnum reports ready regardless), an
+  unparsed-but-attached policy override, and per-backend/service state
+  generally. Gate on the service's OWN verdict (admin sockets, functional
+  probes), never on juju status alone.
+- **"Reports OK while broken" generalizes.** Charm-side validation is often
+  parse-level only (the keystone policy zip validates YAML, not semantics).
+  Acceptance is BEHAVIORAL: prove the capability works, not that the config
+  is present.
+- **Distinguish down from thrashing.** A host that looks "down" to juju/OVN
+  (ovsdb inactivity-probe storms) may be swap-thrashing, not down (D-040).
+  Check `who -b` / `uptime` / `journalctl -k | grep -i oom` before treating
+  it as an outage.
+- **Read the reason field before the status field.** Magnum health UNHEALTHY
+  has three signatures (D-042 amendment): reason EMPTY = conductor cannot
+  reach the mgmt API (VM down?); all-Ready except infrastructure "not found"
+  = the cosmetic driver-contract miss; a reason citing LB failure = real,
+  check Octavia. Same status, three different responses.
+- **Single-node mgmt VM does not self-heal (D-035/D-041).** Workload nodes
+  wedged with the `uninitialized` taint, magnum reconcile dead, addons
+  Pending -> check `capi-mgmt-v2` is ACTIVE before anything else. Manual
+  start is POLICY (down is a signal), not a defect.
+- **Known blast-radius traps:** `juju destroy-model` decomposes MAAS
+  pod-composed machines - machine retention is `juju remove-machine
+  --keep-instance` (D-061); mysql-innodb-cluster never bootstraps at
+  num_units 1 - deploy at 3 (D-062); `reboot-cluster-from-complete-outage`
+  is destructive against an already-healthy cluster - check cluster status
+  FIRST; vault restarts sealed by design - sealed-after-reboot is expected,
+  not a fault; the magnum `domain-setup` action must be re-run after every
+  redeploy (D-046).
+- **Green-in-the-shell, broken-in-the-daemon.** Interactive shells have a
+  different PATH, env, and stdin than LSB-init daemons. Verify under the
+  daemon's conditions (restricted PATH, live-process args) - see
+  script-authoring.
+- **The absence of an expected resource is a finding, not a gap to fill.**
+  If something that should exist does not (a domain, a rule, an image
+  property), find out WHY it is absent before recreating it - it may have
+  been removed deliberately (check design-decisions) or its absence may be
+  the actual root cause several layers up.
+
+**Prove event-driven flows by FUNCTIONAL OUTCOME, not packet/snapshot forensics.** For a
+bursty, per-operation client flow (e.g. the magnum conductor's helm/watch to the mgmt apiserver),
+an instantaneous `ss` snapshot or a short `tcpdump` window will usually catch NOTHING -- the
+connection is idle at rest and short-lived under load. That absence is expected, not a fault.
+The right proof is a forced real operation that SUCCEEDS end-to-end (a cluster resize reaching
+UPDATE_COMPLETE proves the conductor reached the mgmt apiserver through the boundary), plus a
+TCP handshake from the real source. Reach for established-state or a forced functional op before
+concluding a flow is broken; a service's own successful state transition outranks a captured packet.
+
+## Escalation and blockers
+
+- Missing vault unseal keys, lost one-shot secrets, or anything requiring
+  material only the operator holds: STOP and escalate. Do not improvise
+  around a recovery blocker (a vault re-init wipes the TLS plane).
+- If a fix would deviate from a runbook or contradict a D-NNN: log it as a
+  proposal and get a ruling. Mid-incident is exactly when discipline pays.
+- Two failed fix attempts on the same hypothesis = the hypothesis is wrong.
+  Step back to the audit stage; widen what you are measuring.
+
+
+================================================================================
+## references/opentofu-provider-docs.md (load on demand)
+================================================================================
+
+# OpenTofu / provider documentation -- sources, versions, and fetch method
+
+Read this before writing or extending anything under `repo opentofu/` (the
+VR1 DC-DC infrastructure-as-code, D-103). Built up during the 2026-07-09
+OpenTofu delivery; see `repo opentofu/README.md` for the full, per-module
+account (schema notes, an "Audit pass" section, and every finding's exact
+sourcing) -- this file is the index into that plus the fetch methodology,
+so a future session does not have to rediscover it by trial and error.
+
+## The core lesson: doc-summarization is lossy, real example code is not
+
+Every provider doc page fetched this session went through a summarizing
+model, which reliably got FIELD NAMES right but repeatedly lost or
+mis-stated CALL SYNTAX (block vs. attribute style, exact nesting). The
+`opentofu/` scaffold shipped with a real syntax bug from trusting doc
+summaries alone (fixed once real example `.tf` files were fetched and
+read directly -- see `repo opentofu/README.md`'s syntax-bug note). **For any
+new provider/resource: find real example `.tf`/`.go` source before trusting
+a doc-summary's syntax claims.** Doc-summaries are fine for "what fields
+exist"; they are not reliable for "how do I write this."
+
+## Fetch gotchas
+
+- The Terraform/OpenTofu Registry's own doc pages (`registry.terraform.io/
+  providers/.../docs`) are client-side-rendered -- a plain fetch returns only
+  the page shell, no content. Go straight to the provider's GitHub repo
+  instead.
+- GitHub's raw file URLs need the CORRECT default branch (varies: `main` for
+  some repos, `master` for others -- check `api.github.com/repos/<org>/<repo>`
+  for the `default_branch` field first, don't guess).
+- A general web search's own synthesized "summary" of a doc page can itself
+  be wrong (encountered once this session: a search summary confidently
+  named the wrong branch and file path). Treat search-result summaries as
+  leads to verify, not answers -- always follow through to the primary
+  source.
+- When a fetch refuses to "reproduce verbatim" (copyright caution), ask for
+  a specific, narrow thing instead -- "list bare field names only, no
+  prose" reliably works where "reproduce this page" does not.
+- `api.github.com/repos/<org>/<repo>/contents/<path>` (a JSON directory
+  listing) is a reliable way to discover the REAL current file layout when
+  a guessed raw-file path 404s -- doc reorganizations happen (one provider
+  moved from `website/docs/r/*.markdown` to `docs/resources/*.md` between
+  the versions training data and current reality disagree on).
+
+## Providers used in `repo opentofu/`
+
+### `dmacvicar/libvirt` (pinned `0.9.8`, confirmed 2026-07-09)
+
+**Before writing any `libvirt_domain`, read `references/platform-traps.md`
+section 1.** Four schema-level traps there have each cost real time and none
+of them is a validate-time error: bare `memory` is KiB not MiB; no `features`
+block means `acpi=off`; no `cpu` block means no `svm` (nested KVM silently
+impossible); and "will be updated in-place" still BOUNCES the guest.
+
+- Registry: https://registry.terraform.io/providers/dmacvicar/libvirt/latest
+  (JS-rendered -- use the GitHub repo for actual content)
+- GitHub: https://github.com/dmacvicar/terraform-provider-libvirt (default
+  branch `main`; there is no `CHANGELOG.md` -- the release NOTES on the
+  releases page are the changelog, and they are unusually informative:
+  `.../releases/tag/v0.9.0` is the breaking-rewrite rationale, `v0.9.1` is the
+  0.9.0->0.9.1 attribute-rename migration guide)
+- **Version boundary that invalidates most examples on the internet:** 0.9.0
+  (2025-11-08) is a compatibility-BREAKING rewrite (plugin framework, "HCL maps
+  almost 1:1 to libvirt XML"); the legacy provider lives on the `v0.8` branch.
+  0.9.1 then code-generated the schema and renamed attributes again. Anything
+  0.8-era -- including model memory -- is wrong for this pin.
+- Docs: `docs/resources/*.md`, `docs/data-sources/*.md` (NOT the older
+  `website/docs/r/*.markdown` layout some search results/training data
+  reference -- that's stale)
+- **Real example `.tf` files (the higher-value source): `examples/*.tf`** --
+  `domain_with_network.tf`, `alpine_cloudinit.tf` were the two that resolved
+  every syntax question this session. Fetch these FIRST for any new
+  resource, before the doc pages.
+- Key fact: this provider code-generates its schema as a 1:1 mirror of
+  libvirt's own domain/network/pool XML (confirmed via a general search of
+  provider discussion, not the docs pages themselves) -- when a Terraform
+  schema question stalls, libvirt's own native XML docs
+  (https://libvirt.org/formatdomain.html, https://www.libvirt.org/pci-addresses.html)
+  are a legitimate, stable cross-reference for what a nested attribute is
+  likely to be named/shaped, since the mapping is direct.
+
+### `canonical/maas` (pinned `2.7.2`, confirmed 2026-07-09)
+- Registry: https://registry.terraform.io/providers/canonical/maas/latest
+  (same JS-rendering issue -- use GitHub)
+- GitHub: https://github.com/canonical/terraform-provider-maas (default
+  branch `master` -- NOT `main`, confirmed by checking `default_branch`
+  directly rather than assuming)
+- Docs: `docs/resources/*.md`, `docs/index.md` (provider block config)
+- Moved from an older `maas/maas` registry namespace -- use `canonical/maas`,
+  not `maas/maas`, for anything current.
+- Key lesson (see `repo opentofu/README.md`'s "MAAS registration + tc netem
+  research" section for the full account): `maas_vm_host` (register a virsh
+  chassis) and `maas_vm_host_machine` (MAAS composes/creates a new VM
+  itself) are NOT interchangeable -- read the schema (which fields are
+  INPUTS) before assuming a resource matches a design intent just because
+  its name sounds related.
+
+### OpenTofu core (language features, not a provider)
+- `local-exec` provisioner: https://opentofu.org/docs/language/resources/provisioners/local-exec/
+- `terraform_data` (built-in, replaces the older `null_resource` for
+  provisioner-only use): https://opentofu.org/docs/language/resources/tf-data/
+  (note the URL slug is `tf-data`, not `terraform_data` or `terraform-data`)
+- Both pages rendered cleanly on a direct fetch (static docs, no JS-rendering
+  issue) -- these were the most reliable fetches of the whole session.
+
+### OPNsense (not a Terraform provider -- the guest OS itself)
+
+**SUPERSEDED RESEARCH WARNING (2026-07-12/13).** `repo opentofu/README.md`'s
+"OPNsense deployment research" section and the 2026-07-09 changelogs describe a
+**config-ISO / Configuration-Importer** delivery path. That path is DEAD and its
+code is DELETED:
+- **D-112:** the Configuration Importer can NEVER fire on a pre-installed nano
+  image (upstream `opnsense-importer` probes for a read-only root and exits
+  before scanning media). The ISO was inert; nothing was ever going to read it.
+- **D-113 (ADOPTED 2026-07-13, option a2):** OPNsense STAYS, but config moves to
+  the **REST API**. `opentofu/templates/opnsense-config.xml.tmpl`,
+  `scripts/opnsense-render-config.sh` and `scripts/opnsense-build-config-iso.sh`
+  are DELETED, along with the module's `config_seed` volume + cdrom disk.
+  **A rendered-`config.xml` push would now CLOBBER live API-managed DHCP.**
+
+Current path: `scripts/opnsense-api.sh` (REST client) +
+`scripts/opnsense-bootstrap-apikey.sh` (mints a key via OPNsense's own model
+over SSH). Traps, exact endpoints, the mandatory `service/reconfigure` step, the
+60-second firewall auto-rollback, and the tcsh trap: `references/platform-traps.md`
+section 4.
+
+- Official docs: https://docs.opnsense.org/manual/install.html;
+  REST API: https://docs.opnsense.org/development/how-tos/api.html;
+  26.1 release notes (ISC-DHCP left core; dnsmasq is the new default):
+  https://docs.opnsense.org/releases/CE_26.1.html
+- Still-valid finding from the 2026-07-09 research: cloud-init is unreliable on
+  FreeBSD, so `modules/cloudinit-vm` genuinely does not apply to OPNsense
+  (https://forum.opnsense.org/index.php?topic=42517.0), and the nano image (not
+  the installer image) is the one to use.
+- Historical only (the ISO mechanism these describe cannot fire on nano):
+  https://github.com/opnsense/core/issues/5733, .../issues/10017.
+
+## Where the full findings live (don't duplicate here, it will drift)
+
+**Caveat first (2026-07-13):** `repo opentofu/README.md` predates D-112/D-113
+and its "OPNsense deployment research" section still describes the DELETED
+config-ISO path -- see the superseded-research warning above before acting on
+anything it says about OPNsense. Its libvirt schema notes also predate the four
+domain traps in `references/platform-traps.md` section 1. Everything else in it
+still stands.
+
+`repo opentofu/README.md` is the authoritative, per-module account --
+schema notes, what's confirmed vs. assumed per attribute, and a dated
+"Audit pass" section recording a later re-review (a real documentation
+error was found and fixed there: an early claim that libvirt interface
+list-order directly sets OPNsense's LAN/WAN role conflated two separate
+mechanisms -- read that section before trusting anything about NIC
+ordering/roles). Treat this file as the index/methodology; treat that one
+as the ground truth for what each module actually does and why.
diff --git a/.claude/skills/openstack-cloud-ops/SKILL.md b/.claude/skills/openstack-cloud-ops/SKILL.md
index 4468553..b04acf2 100644
--- a/.claude/skills/openstack-cloud-ops/SKILL.md
+++ b/.claude/skills/openstack-cloud-ops/SKILL.md
@@ -93,7 +93,8 @@
 | Full-cloud restart after outage/maintenance | repo `runbooks/ops-restart-procedure.md` |
 | VR1 site unreachable after a vcloud reboot (`ssh voffice1` / `office1-*` time out) | `bash scripts/site-baseleg.sh check office1` -- `office1-local` is an ISOLATED libvirt net, so the host's base L3 leg (`10.10.0.10/24` + compose route `10.10.1.0/24 via 10.10.0.20`) is dropped every reboot; the `After=libvirtd` unit re-adds it (D-126 amendment / D-128). If MISS and the unit is not yet installed: `sudo bash scripts/site-baseleg.sh apply office1`. This is the vcloud path; the workstation reaches the same over the tailnet (D-107). |
 | Starting any consequential live session | `bash scripts/run-logged.sh <label>` first (as-executed log; docs/as-executed-log-convention.md) |
-| Credential exposures / security TODOs | repo `docs/security-ledger.md` -- add a row, never only a script comment |
+| Credential exposures / security TODOs | repo `docs/security-ledger.md` -- add a row, never only a script comment. The credential-LIFECYCLE policy (mint -> consolidate -> audit) is **D-137**, not the ledger (SEC-009's convention block is now a pointer); the expected-state register is `creds-matrix.tsv` + `scripts/creds-matrix.py` (tier 1 static, tier 2 existence, tier 3 validity), enforced as a BLOCKING preflight `P5`. `creds-audit` CLEAN is NOT evidence of completeness -- it is declaration-based |
+| Per-DC artifact delivery (apt mirror / caching proxy); "can the nodes get packages?" | dc0 = `bash scripts/dc-mirror.sh check dc0` (full mirror); dc1 = `bash scripts/dc-cache-proxy.sh check dc1` (caching proxy). The two DCs DIFFER BY RULING (D-135 amendments) -- checking dc1 as a mirror fails by design. Both run ON the rack host over `ssh -J voffice1` with `sudo bash -s`; take rack transit IPs from `scripts/lib-hosts.sh`, never memory |
 | Resuming work / what is still in flight (esp. after compaction) | repo `docs/CURRENT-STATE.md` first, then `docs/session-ledger.md` + `bash scripts/ledger-scan.sh` to reconcile against repo ground truth |
 | Tenant onboarding / tenant self-service | repo `scripts/tenant-onboard.sh` + `runbooks/tenant-onboarding-v2-DRAFT.md` + `appendix-C/D` |
 | Network / plane / IPAM questions | `references/environment.md`, repo `scripts/lib-net.sh`, NetBox (the IPAM apex -- but during VR1 the WORKING apex is `office1-netbox`, 10.10.1.10, per DOCFIX-195; `netbox.baldurkeep.com` is a READ-ONLY v1 reference, write-back deferred to end-of-deployment) |
@@ -153,6 +154,46 @@
 per-revision `/var/snap/maas/current/` and may not survive a snap refresh -- re-assert
 after any refresh. Roosevelt analog: per-DC IPMI/BMC credentials.
 
+**Per-DC ARTIFACT DELIVERY is a per-DC STRATEGY, and the two DCs deliberately differ
+(D-135 + its 2026-07-24/27 amendments -- standing invariant).** dc0 tests a FULL MIRROR
+(`dc-mirror.sh`, debmirror+nginx on the D-134 utility `.4`); dc1 tests an APT CACHING
+PROXY (`dc-cache-proxy.sh`, apt-cacher-ng on `.4:3142`, consumed via
+`juju apt-http-proxy`). This is the EXPERIMENT, not an interim state -- there is no
+fallback and no later convergence, and dc1's partial mirror was REMOVED 2026-07-27.
+Consequences that bite: **checking dc1 as a mirror FAILS BY DESIGN** (use its own
+checker), and each DC's gate is its own script's `check <site>`.
+**Corollary invariant, learned the hard way: a per-DC utility service OWNS ITS OWN
+NETWORK PREREQUISITES.** `dc-cache-proxy.sh` originally REUSED `dc-mirror.sh`'s
+`<site>-mirror-net.service` for the `.4` alias + edge default route, so on a proxy-only
+DC three files named `*-mirror-*` were load-bearing FOR THE PROXY: the documented
+mirror-removal procedure would have silently killed it, and the proxy could not be
+REBUILT afterward without reinstalling the whole mirror apparatus (enabled daily
+debmirror timer included). Never let one strategy's teardown be able to break the
+other's; name artifacts for the service that owns them. Roosevelt analog: a DC must be
+able to change artifact strategy without rebuilding the other strategy's apparatus.
+
+**Stage 4 hands off READY nodes, NOT deployed ones (DOCFIX-200, RULED 2026-07-23 --
+standing).** MAAS-deploy is SKIPPED; Juju provisions at Stage 5. Any surface saying
+"nodes Deployed" as a Stage-4 exit condition is a DEFECT, not a fact -- four were found
+and fixed on 2026-07-27 (workflow-doc gate cell, phase-3 DoD + Step 7, phase-4
+prerequisites). Practical consequence: **nothing node-side can be probed in Stage 4**
+(the nodes are powered off), so node-side checks belong at Stage 5 first boot -- that is
+why gate G17 exists.
+
+**A CHECKER THAT CANNOT FAIL IS NOT A GATE (this project's most productive audit move).**
+GA-R6 lets a stage close only on a named executable check, so the check itself must be
+verified capable of failing. Two measured instances, days apart: `creds-audit` is
+DECLARATION-based and read CLEAN on three sites while the D-137 matrix returned 13
+findings; `dc-mirror.sh check` asserted that `last-sync.status` EXISTED and printed its
+contents behind an unconditional `OK`, so a `FAIL` status and a four-day-stale `RUNNING`
+both passed. Working rules that came out of it: assert on CONTENT, never on existence;
+an unrecognised state REFUSES rather than defaulting to success; "could not look" is
+never "nothing there"; and **enumerate what EXISTS rather than only auditing what is
+declared** -- a register cannot report the absence of something it has no row for, which
+is how an unregistered credential at both DC edges survived every audit. When a test
+asserts a literal finding string, remediating the finding turns the harness red: REPLACE
+the assertion with the new invariant and say so, never delete it to go green.
+
 **Change-delivery loop:** grep for prior art (zeroth decision) -> grep
 design-decisions for the governing D-NNN -> edit -> `bash scripts/repo-lint.sh`
 -> run the touched script's harness (create one if missing -- no script change
diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index c0072f9..ac71406 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -340,11 +340,24 @@
     is REPORTED not gated (a first addressing may legitimately have no gateway yet); the hard
     gate stays address-on-the-kernel. Harness **59/59** (was 53), cases 15-15f. No live edge
     touched -- both DC edges are already addressed, so this affects the NEXT one.
-  **REMAINING for the Stage 4 close: the GA-R6 close-out set ONLY** -- GA-R2 consolidation,
-  skill sweep + dated snapshot regeneration, GA-R7 memory review, final gauntlet + repo-lint,
-  operator-gated merge of `dc-dc-stage4-phase3-maas-deploy` to `main` as a MERGE commit (not
-  squash), branch retirement. Every substantive in-stage item is now closed or split to a
-  gate row (G17).
+  - **CLOSE-OUT SET EXECUTED 2026-07-27; only the MERGE remains.** GA-R2 consolidation done
+    (7 stage changelogs archived, top-level `docs/` 25 -> 18, stage record
+    `docs/archive/stage-records/vr1-stage4-record.md`; 12 stale `docs/changelog-*` paths in
+    live surfaces rewritten to the archive, including some already-dangling from the G12
+    close). Skill sweep done -- three new INVARIANTS folded in (per-DC artifact delivery is a
+    per-DC STRATEGY and a utility service owns its own net prerequisites; Stage 4 hands off
+    READY nodes not deployed ones; "a checker that cannot fail is not a gate", with the
+    assert-on-content / enumerate-what-exists rules) plus two routing rows. Dated snapshot
+    REGENERATED as `.claude/skills/openstack-cloud-ops-consolidated-20260727.md` (1589 lines,
+    ASCII/LF verified) and the superseded 20260725 one REMOVED -- a stale snapshot being
+    uploaded is the exact failure `docs/audit/skill-divergence-20260725.md` records, and it is
+    a derived artifact regenerable from any commit. GA-R7 memory review done: NO new memory
+    (everything durable graduated to the skill/repo, which is the correct GA-R7 outcome); both
+    existing entries verified against the repo and extended with the two reasoning traps this
+    stage produced. Gauntlet **ALL GREEN (81)**, repo-lint 0-fail.
+  **REMAINING: the operator-gated merge of `dc-dc-stage4-phase3-maas-deploy` to `main` as a
+  MERGE commit (not squash), then branch retirement (local + remote).** Every substantive
+  in-stage item is closed or split to gate row G17.
 - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6
   exact; convergence zero --
   `docs/audit/outer-plan-20260719-postA-converged.txt`). **Deploy step B
@@ -1092,7 +1105,7 @@
    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/changelog-20260727-creds-consolidation.md`. Superseding figures: matrix **82 rows**,
+   `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
diff --git a/docs/archive/changelogs/changelog-20260723-caveman-optin-guard.md b/docs/archive/changelogs/changelog-20260723-caveman-optin-guard.md
new file mode 100644
index 0000000..b328c98
--- /dev/null
+++ b/docs/archive/changelogs/changelog-20260723-caveman-optin-guard.md
@@ -0,0 +1,46 @@
+# Changelog -- 2026-07-23 -- caveman plugin: off-by-default opt-in guard
+
+Session scope: operator-directed install of the `caveman` Claude Code plugin
+(third-party, `JuliusBrussee/caveman`) plus guards so it never auto-arms while
+operating the cloud. Harness-config only -- NO cloud mutation, NO script/runbook
+change, no status implication (CURRENT-STATE untouched). Kept as an available
+tool for future hardened-workflow deployment testing, where terse
+gated-approval-only output is wanted; verbose fully-gated output stays the
+default for live operations.
+
+## Item 1 -- caveman plugin installed (user scope), hooks inspected read-only
+
+- Installed `caveman@caveman` at user scope (`~/.claude/plugins/`, git SHA
+  `0d95a81`) via `claude plugin marketplace add` + `claude plugin install`,
+  per operator instruction. Purpose: terse "caveman-mode" output (~65% fewer
+  output tokens, per its README).
+- Both auto-wired hooks read in full before trusting them (this host holds
+  cloud credentials + reaches juju/MAAS/OpenStack, so a plugin's hooks are a
+  supply-chain surface): `src/hooks/caveman-activate.js` (SessionStart) and
+  `src/hooks/caveman-mode-tracker.js` (UserPromptSubmit). Finding: purely
+  behavioral -- NO network calls, NO credential-file access, NO exfiltration;
+  the only subprocess spawned is the plugin's own stats script, and only on an
+  explicit `/caveman-stats`. Default mode is `full` (auto-arms on session
+  start unless guarded) -- the reason for item 2.
+- **Revert:** `claude plugin uninstall caveman@caveman`; remove the
+  `extraKnownMarketplaces.caveman` + `enabledPlugins."caveman@caveman"` keys
+  from `~/.claude/settings.json`.
+
+## Item 2 -- opt-in guard: CAVEMAN_DEFAULT_MODE=off (repo + user scope)
+
+- Repo `.claude/settings.json`: added an `env` block setting
+  `CAVEMAN_DEFAULT_MODE=off` -- committed, so the intent is durable/shared for
+  this operating clone. Effect: `getDefaultMode()` returns `off`, the
+  SessionStart hook skips activation and clears any stale flag; an explicit
+  `/caveman lite|full|ultra` still activates on demand. `jq` valid, repo-lint
+  0 fail / 1 legacy warn (unchanged).
+- User `~/.claude/settings.json`: same `env` entry added so the plugin is
+  off-by-default in ALL of the operator's repos, not just this one (the plugin
+  is installed user-wide; its bare default is `full`). This file is OUTSIDE the
+  repo -- NOT committed here; recorded for provenance only.
+- Verified `off` is a valid mode (`VALID_MODES` in the plugin's
+  `caveman-config.js`), so the guard is honored rather than silently ignored.
+- **Revert:** remove the `env.CAVEMAN_DEFAULT_MODE` key from whichever
+  settings.json (repo revert via `git revert <sha>` for the committed one; hand
+  edit for the user-level one). With the plugin still installed, removing the
+  guard restores its `full` auto-arm default.
diff --git a/docs/archive/changelogs/changelog-20260723-stage4-open.md b/docs/archive/changelogs/changelog-20260723-stage4-open.md
new file mode 100644
index 0000000..5901d3e
--- /dev/null
+++ b/docs/archive/changelogs/changelog-20260723-stage4-open.md
@@ -0,0 +1,249 @@
+# Changelog -- 2026-07-23 -- Stage 4 open: discovery + D-133 carve ruling
+
+Session scope: open Stage 4 (Phase 3, MAAS enlist/commission/deploy per DC) on
+branch `dc-dc-stage4-phase3-maas-deploy` off post-merge `main`. Bootstrap ran
+clean (pull up-to-date at bff71d4; repo-lint 0 fail / 1 legacy warn; ledger-scan
+reconciled -- 12 open SEC rows, D next-free 133). No cloud mutation this session
+yet; everything below is read-only measurement + repo records.
+
+## Item 1 -- Stage 4 OPENED: precondition + discovery (read-only), captured
+
+- Branch `dc-dc-stage4-phase3-maas-deploy` created off `main` (bff71d4).
+- Runbook Step 0 precondition PASS: both DC rack controllers enrolled
+  (vvr1-dc0 `7chphy`, vvr1-dc1 `nmpcq4`).
+- Step 2 discovery complete for BOTH DCs, all read-only, captured to
+  `docs/audit/stage4-discovery-20260723.txt`: 9 nodes per DC, ALL Ready,
+  power=virsh; dc0 = boot fabric-4 / MACs 52:54:00:*, dc1 = fabric-142 /
+  pinned 52:54:01:d1:*; zone/pool `default` everywhere (no zone/pool
+  convention exists -- fabric + MAC prefix is the grouping signal).
+  Also captured: one dc0 node's full physical NIC list (6 flat per-plane
+  NICs), `default_distro_series=noble`, and the synced boot-resources list
+  (noble ONLY -- no jammy images on the region).
+- Runbook-vs-reality deltas recorded in CURRENT-STATE (the runbook predates
+  Stage 3's execution): Step 3 commissioning already satisfied; carve comes
+  BEFORE deploy per the runbook's own Ready-state sequencing note; gap #6
+  (pod-discovery landing status) is moot -- the pod path was refuted 2026-07-20.
+- **Revert:** `git branch -D dc-dc-stage4-phase3-maas-deploy` (after moving off
+  it); delete `docs/audit/stage4-discovery-20260723.txt`; revert the
+  CURRENT-STATE Stage-4 bullet. No live state was touched.
+
+## Item 2 -- D-133 ADOPTED: flat per-NIC carve (VR1); hardware-faithful NIC topology next deployment
+
+- New entry `docs/design-decisions.md` D-133 [ARCH], Status ADOPTED 2026-07-23,
+  operator utterance quoted verbatim per GA-R5 ("Fine, keep it flat but on the
+  next deployment we need to build the VMs with exact hardware duplicated
+  networking so we can work out any bonding/trunking kinks.").
+- Part 1: VR1 DC nodes carve every plane FLAT on its dedicated NIC; no
+  VLAN-103 stack in VR1 (supersedes the D-052-era Pattern A shape for VR1 DC
+  nodes only; VR0 untouched).
+- Part 2 (pinned to next deployment): node VMs duplicate target hardware's
+  exact NIC topology (bond members, trunks) -- composes with D-132.
+- Affected-surfaces list recorded IN the entry (buildout-design VID-103 text,
+  workflow Stage 4 row, phase3 runbook Step 5 tree, lib-net vr1-dc0 arm's
+  inherited METAL_INTERNAL_VID) -- queued as this stage's DOCFIX/delivery work,
+  not silently edited.
+- CURRENT-STATE section 1 updated in the same commit (GA-R1 C1): Stage 4 OPEN
+  bullet with discovery facts + the open decision points (deploy OS series,
+  octet plan, mirror gap #5, tag shape).
+- **Revert:** remove the D-133 block from design-decisions.md and the Stage-4
+  bullet from CURRENT-STATE.md (single commit; `git revert <sha>`).
+
+## Item 3 -- D-134 ADOPTED: per-role octet bands for VR1 DC node statics
+
+- New entry `docs/design-decisions.md` D-134 [ARCH], ADOPTED 2026-07-23.
+  Sequence per GA-R5: the flat .40-.48 proposal was presented and REJECTED
+  ("Different band"); operator directed "Per role bands with headroom. Give me
+  a recommendation"; the recommended band table was presented with measured
+  collision checks (bundle VIPs .50-.60 grep, 10.12.12.4, FIP pool, D-120
+  dynamic range) and adopted ("Adopt as recommended").
+- Bands: .1-.9 infra (.4-.9 utility-reserved), .10-.19 control, .20-.49
+  compute, .50-.99 formal VIP band, .100-.200 dynamic (D-120), .201-.254
+  storage. One octet per node across all six planes, both DCs; VR1
+  assignments control .10-.12 / compute .20-.21 / storage .201-.204 keyed by
+  tofu node name via pinned boot MAC.
+- CURRENT-STATE Stage-4 bullet updated in the same commit (octet plan RULED;
+  carve now unblocked on D-133 + D-134).
+- **Revert:** remove the D-134 block + the CURRENT-STATE bullet edit
+  (`git revert <sha>`).
+
+## Item 4 -- D-134 AMENDED: contiguous band table (Option B swap)
+
+- Operator rejected the original table's interleaving (node roles split by the
+  VIP + dynamic blocks); movability analysis presented (pinned: .1/.2/.3 live,
+  .50-.60 bundle VIPs, FIP rows 1-3 on provider; movable: the D-120-inherited
+  dynamic range). Option B ruled: nodes get the contiguous .100-.200 run
+  (control .100-.119 / compute .120-.149 / storage .150-.200), dynamic moves
+  to .201-.254, utility .4-.49, VIP .50-.99.
+- VR1 assignments now: control .100-.102, compute .120-.121, storage
+  .150-.153 (identity table unchanged -- tofu name via pinned boot MAC).
+- Consequence queued: the dc0/dc1 metal-admin dynamic-range MOVE is the
+  carve's first gated live mutation per DC (before static assignment; nodes
+  powered off). Office1's own D-120 ranges untouched.
+- CURRENT-STATE Stage-4 bullet updated same-commit.
+- **Revert:** remove the amendment block + CURRENT-STATE edit
+  (`git revert <sha>`); no live state touched yet.
+
+## Item 5 -- Approvals workflow: session-log-keyed permission rules (operator-directed)
+
+- Operator directed session-length approvals mid-carve (manual mode was
+  prompting per command; the earlier auto-mode classifier BLOCKED the first
+  mutation outright -- the known dc1-session behavior, ledger 2026-07-23).
+- `.claude/settings.local.json` (uncommitted, personal): ADDED allow
+  `Bash(script -aqe ~/as-executed/2026-07-23-stage4-carve.log -c *)` (the
+  logged-window wrapper -- inherently session-scoped, the rule names this
+  window's log file) + ask rule keeping `maas admin machine *` shapes
+  (commission/deploy) prompting inside that same wrapper. PRUNED seven dead
+  rules keyed to retired log files (2026-07-21-ops-commissioning-diag,
+  2026-07-22-dc1-deploy).
+- FLAGGED for stage close, not acted on: local allow list carries a broad
+  `Bash(ssh *)` from a prior session -- prune candidate.
+- Review surface stays the as-executed log + this changelog (GA-R2
+  blanket-approval precedent).
+- **Revert:** remove the two added rules from settings.local.json (file is
+  local-only, not committed).
+
+## Item 6 -- Stage 4 carve EXECUTED, both DCs (logged window stage4-carve)
+
+- All mutations in ~/as-executed/2026-07-23-stage4-carve.log (per-command
+  wrap; helper scripts' full content logged verbatim before first use).
+  Verification capture: `docs/audit/stage4-carve-verify-20260723.txt`.
+- Set 0: dc0+dc1 metal-admin dynamic ranges MOVED to .201-.254 in place
+  (iprange ids 2/3; office1 id 1 untouched) -- the D-134-amendment
+  consequence, done before statics.
+- Set 1: 10 named plane fabrics created (vr1-dc0-* ids 188-192 / vlans
+  5189-5193; vr1-dc1-* ids 193-197 / vlans 5194-5198).
+- Set 2: 90 NIC re-homes, one node per approval-unit, read-back each: every
+  non-boot NIC moved from its private auto-fabric to its plane fabric;
+  boot NICs stay fabric-4 (dc0) / fabric-142 (dc1). MACs matched
+  config-of-record pins throughout.
+- Set 3: provider subnets 10.12.4.0/22 + 10.12.64.0/22 MOVED off shared
+  fabric-5 to their per-DC provider fabrics (+ ruled gateways .1); 8 plane
+  subnets CREATED (dc0 12/16/32/36, dc1 72/76/80/84).
+- Set 4: 6 spaces created (bundle binding names verified against
+  bundle.yaml first); 12 untagged VLANs assigned (metal-admin = the two
+  boot fabrics). Office1/transit subnets remain in `undefined` untouched.
+- Set 5: 18 nodes' statics per D-134-amended assignments (control
+  .100-.102, compute .120-.121, storage .150-.153, same octet all six
+  planes) -- five raw-NIC statics + br-ex (OVS, Pattern A) carrying the
+  provider static, provider NIC left raw (D-100). All nodes remain Ready.
+- Residue NOT touched (flagged): fabric-5 still holds 192.168.1.0/24
+  (factory-LAN residue, both edges re-addressed) and the now-empty
+  ex-provider fabric-5 itself; the ~90 empty auto-created fabrics
+  (fabric-98..187 class) also remain -- cleanup candidates, gated
+  separately at stage close, zero functional impact.
+- **Revert:** MAAS-record-level; reverse order: unlink statics + delete
+  br-ex per node, delete the 8 created subnets, move the 2 provider subnets
+  back to fabric-5, unassign spaces + delete the 6 spaces, re-home NICs to
+  auto-fabrics (or delete the 10 named fabrics after), move dynamic ranges
+  back to .100-.200. Nodes were powered off throughout; no OS-level state
+  exists to revert.
+
+## Item 7 -- Deploy-model ruling + DOCFIX-200 + jammy sync + placement tags
+
+- **RULING (operator: "Ready + jammy images (Recommended)"):** Stage 4 ends
+  with nodes READY + carved + tagged; MAAS-deploy is SKIPPED -- Juju
+  provisions Ready machines at Stage 5 and requests the bundle's
+  `default-base` (ubuntu@22.04). The phase3 runbook's Step 4 as written
+  (`maas machine deploy` per node) contradicted phase-01's own precondition
+  ("machines Ready/power=off") and would have made all 18 nodes
+  un-allocatable to Juju. [OPS -- encoded in the proven phase-01 precedent;
+  no D-number.]
+- **DOCFIX-200:** `runbooks/dc-dc-phase3-maas-enlist-deploy.md` Step 4
+  rewritten (tag + base-image sync, nodes STAY Ready; ruling quoted),
+  sequence table line + GATE "Nodes deployed" bullet corrected against
+  the buildout-design wording.
+- **Jammy images:** boot-source selection id=2 (ubuntu/jammy amd64) created
+  on source 1 + import triggered; `ubuntu/jammy` reads Synced (re-verify at
+  close while sub-resources finish).
+- **RULING (operator: "Adopt per-DC tags (Recommended)"):** deploy-placement
+  tags are region-qualified per-DC -- `openstack-vr1-dc0` /
+  `openstack-vr1-dc1` (D-119 naming), applied 9+9, add=9/remove=0 both.
+  Stage 5's per-DC bundle parameterization constrains on them.
+- **RULING (operator: "Build the mirror now"):** the D-107 per-DC artifact
+  mirror gets BUILT in-stage (rehearsal exception REJECTED); Stage 4's
+  mirror gate bullet stays OPEN until it exists and nodes' reachability is
+  verified. Design presented as its own decision (D-135 candidate).
+- Queued findings: `phase-00-maas-standup.sh`'s hardcoded PLANES table
+  asserts the VR0 VLAN-103 shape and would false-DRIFT against the ruled
+  D-133 flat carve (Step 8 satisfied instead by the spaces cross-check in
+  the carve capture); Step 7's edge-NTP check text is superseded by the
+  D-129(iv) ruling (MAAS hierarchy stays time authority; nodes measured
+  NTP-ing to their rack during Stage 3 commissioning).
+- **Revert:** runbook edits `git revert`; tags
+  `maas admin tag update-nodes <tag> remove=...` x9 + tags delete;
+  boot-source-selection delete id=2 (images age out).
+
+## Item 9 -- INCIDENT (resolved): dc1 edge passed NO LAN traffic -- pf ruleset never regenerated
+
+- Found at the dc1 mirror install: apt through the edge timed out. Measured
+  chain: rack default route present, edge LAN gw ping 0%, internet 100% loss;
+  `pfctl -s nat` on the dc1 edge showed ZERO outbound NAT rules while dc0's
+  edge (identical config -- both carry the single WAN_GW gateway_item) showed
+  the full automatic set. Root cause: the fresh dc1 edge's pf ruleset was
+  NEVER REGENERATED after v4 addressing -- `opnsense-set-interface-v4
+  --commit` runs `configctl interface reconfigure` but NOT a filter reload.
+  dc0 was masked: its 07-20 plugin/qga work triggered filter reloads as a
+  side effect. My dc0-only egress probe earlier this session was wrongly
+  taken as covering dc1 (symmetry inference -- owned).
+- Fix (minimal, logged): `configctl filter reload` on the dc1 edge -> NAT
+  rules present, rack egress 0% loss / HTTP 301 -- identical to dc0.
+- QUEUED: appendix-A entry (symptom: LAN clients of a freshly-addressed DC
+  edge get 100% loss with reachable gateway; check `pfctl -s nat`); DC-standup
+  DoD addition (filter reload + LAN-client egress probe after edge
+  addressing); candidate opnsense-set-interface-v4 amendment (add the filter
+  reload) -- a built-surface change, presented at stage close, not slipped in.
+- **Revert:** n/a (the reload materializes the edge's own committed config).
+
+## Item 10 -- dc-mirror installed BOTH racks; syncs RUNNING; HOME fix (harness 19)
+
+- dc0: install pass-1 net layer up -> apt debmirror/nginx/ubuntu-cloud-keyring
+  -> install PASS (15 checks; mirror answers http://10.12.8.4/ 200).
+- dc1: same, after the item-9 incident fix (install PASS; http://10.12.68.4/
+  200).
+- First sync attempt FAILED both debmirror runs: "HOME not defined in
+  environment!" under systemd's empty env (debmirror needs a GPG home).
+  Fixed in gen_sync_unit (`Environment=HOME=/root`), harness case T19 added
+  (19/19), REINSTALLED both racks (config-diff regeneration path exercised),
+  syncs restarted: both RUNNING and downloading (dc0 400M / dc1 343M within
+  the first minute). Daily timers enabled.
+- Mirror gate remains OPEN until: initial syncs complete (last-sync.status
+  OK) + mirror serves a real node (node-side probe at Stage 5 first boot or
+  a gated rescue-boot check). Stage 4 close blocks on the mirror gate per
+  the operator's build-now ruling.
+- **Revert:** `systemctl stop/disable <site>-mirror-sync.timer + -net.service`,
+  rm the generated files, `rm -rf /var/lib/dc-mirror`, apt remove the three
+  packages; the edge filter reload stands (item 9).
+
+## Item 11 -- Delivery batch: lib-hosts VR1 arms, D-133 guards, appendix-A, DoD
+
+- **lib-hosts.sh VR1 arms POPULATED** (the runbook's standing delivery item):
+  vr1-dc0/vr1-dc1 blocks with tofu-name-keyed HOSTS, D-134-amended octets,
+  config-pinned boot MACs, per-DC power URIs (ruled step-D shape), per-DC
+  tags; NEW `host_sysid_by_bootmac()` (the VR1 resolver -- MAAS hostnames are
+  random and re-minted; MACs survive re-enlistment); one-selection-per-shell
+  guard (lib-net precedent). dc-selector harness rewritten for the populated
+  arms + identity/guard cases: 48 checks PASS.
+- **D-133 guards:** `reenroll-hosts.sh` + `carve-host-interfaces.sh` now
+  REFUSE vr1-* explicitly (VR0 flows: hostname-keyed re-enroll / Pattern-A
+  VLAN-103 carve, both superseded for VR1) -- without the guard, populated
+  VR1 arms would have let VR0 mechanics run against VR1 fleets. Harnesses
+  updated to the refusal messages. Gauntlet **ALL GREEN (77)** after.
+- **lib-net vr1-dc0 arm:** D-133 caveat comment -- inherited
+  METAL_INTERNAL_VID/IFACE are VR0 carve artifacts; never consume for VR1.
+- **appendix-A:** new entry for the edge-pf symptom (LAN 100% loss, gateway
+  fine, `pfctl -s nat` empty; masking trap named). **DoD:** items 8 (filter
+  reload + LAN egress probe) and 9 (dc-mirror install/sync) added; item 4's
+  dynamic-range position corrected to the D-134-amended .201-.254.
+- **Revert:** `git revert <sha>` (repo-only; no live state).
+
+## Item 8 -- OWNED: pipe-masked L10 lint FAIL on the D-135 commit (abd6b92)
+
+- The D-135 commit changed a design-decisions Status line WITHOUT
+  CURRENT-STATE in the same commit (GA-R1 C1 / lint L10) and shipped anyway:
+  my lint invocation piped through `tail`, masking the nonzero exit --
+  the EXACT defect the 2026-07-23 queue-pass session owned same-hour
+  yesterday. Repeated; owned.
+- Repair: this commit carries the owed CURRENT-STATE update (post-carve
+  rulings + D-135 + refreshed NEXT line). Practice fixed in-session: lint
+  exit now checked via PIPESTATUS, never inferred from tail output.
+- **Revert:** n/a (repair commit).
diff --git a/docs/archive/changelogs/changelog-20260724-caveman-disable.md b/docs/archive/changelogs/changelog-20260724-caveman-disable.md
new file mode 100644
index 0000000..1b0c5d9
--- /dev/null
+++ b/docs/archive/changelogs/changelog-20260724-caveman-disable.md
@@ -0,0 +1,225 @@
+# Changelog -- 2026-07-24 -- caveman plugin: disable on live host + governance + guardrails
+
+Session scope: acting on a 4-seat council review of the third-party `caveman`
+Claude Code plugin (installed + off-by-default-guarded 2026-07-23, commit
+338c919). Operator accepted the review recommendations (exact utterance: "I'll
+accept your recommendations"). Harness-config + repo-governance only -- NO cloud
+mutation, NO runbook change. CURRENT-STATE deliberately untouched (adding a SEC
+row is not an L10 trigger; the G14 open-SEC count reconciles at Stage 4 close --
+see item 2). Council finding that drove the disable: `enabled:true` runs
+third-party `node` on every session start + every prompt REGARDLESS of
+`CAVEMAN_DEFAULT_MODE=off` (the env guard gates arming/terse-output, not hook
+execution), and the plugin's own honest docs put net token savings at
+break-even-to-negative on this host's gated-approval workload -- so a standing
+per-turn execution surface on a credential-bearing jumphost was not worth
+carrying.
+
+## Item 1 -- caveman DISABLED on the live host (enabled:false, both scopes)
+
+- `~/.claude/settings.json` (user scope, authoritative for vcloud):
+  `enabledPlugins."caveman@caveman"` flipped `true` -> `false`. Stops the
+  SessionStart + UserPromptSubmit hooks from wiring at the next session start.
+- `/home/jessea123/openstack-caracal-dc-dc/.claude/settings.json` (committed
+  repo scope): added `enabledPlugins {"caveman@caveman": false}`. Project scope
+  outranks user scope (Local > Project > User), so this is a fail-closed,
+  travels-with-the-clone off-switch across the operator's workstations --
+  mirrors the dual placement used for the env guard.
+- `CAVEMAN_DEFAULT_MODE=off` retained in both files as a residual layer; the
+  `extraKnownMarketplaces.caveman` entry RETAINED (plugin stays installed) so a
+  deliberate re-enable for hardened-workflow deployment testing remains cheap.
+- Verified: both settings.json parse (`jq`); user + repo
+  `enabledPlugins."caveman@caveman"` = `false`; no `~/.claude/.caveman-active`
+  flag (not armed). repo-lint 0 fail / 1 legacy warn (unchanged).
+- **Revert:** set both `enabledPlugins."caveman@caveman"` back to `true`
+  (repo copy via `git revert`/edit; user copy by hand). Note: re-enabling
+  re-incurs the SEC-017 re-verify duty.
+
+## Item 2 -- SEC-017 opened (supply-chain re-verify obligation)
+
+- Added row **SEC-017** to `docs/security-ledger.md` (next-free by grep;
+  highest prior = SEC-016). Records the standing third-party per-turn
+  code-execution surface, its point-in-time benign verdict at SHA `0d95a81`,
+  the not-declaratively-pinnable caveat, the disable disposition, and the
+  STANDING DUTY to re-verify the hooks on any re-enable or plugin update.
+- Register call = OPS (no D-number): fails GA-R3's Roosevelt-delta / A1 grep
+  test (no bare-metal analog of a jumphost output-style plugin); precedent
+  D-129 (OPS plugin-install stays OPS). The SEC row is the durable home the
+  security-ledger mandate requires ("a row at discovery, never only a note") --
+  the prior changelog (338c919) is GA-R2 non-citable/archive-bound, so the
+  posture had no durable home before this.
+- Count: open SEC rows 12 -> 13. This is NOT an L10 status-couple trigger
+  (L10 fires on docs/audit/*, design-decisions Status lines, and session-ledger
+  gate rows -- not security-ledger.md), so CURRENT-STATE is untouched; the G14
+  count reconciles at Stage 4 close per its existing deferral pattern.
+- **Self-measured drift baseline (sha256, 2026-07-24; executing cache copy ==
+  git clone at `0d95a81`, only a `.in_use` runtime marker differing):**
+  - `src/hooks/caveman-activate.js`        `bc0af3ba327657630e5f6c60be619e6b5394bf03edc29b1384a15f09a1b348bf`
+  - `src/hooks/caveman-mode-tracker.js`    `3e34f004d4a9e65609f8c95b47dfe5f0e3a6f2d16b88c7f8af730187ee2fb246`
+  - `src/hooks/caveman-config.js`          `f47fe2e6440578eeb20408bc3131b63fb8e1ae4f6ea26dbdcca33e7901e5ee8c`
+  - `src/hooks/caveman-stats.js`           `433a345a279c2d54be51864ef77c0a7b19d0f8604b9a441ce0a1eded31f113e8`
+  - `src/hooks/cavecrew-model-overrides.js` `9f2601e8551653609f0b9d700c9bd75bffa43747d2db18ffe83fb73de5dc3607`
+  - `.claude-plugin/plugin.json`           `b76999bd244fa59c2b8805b1c2b573458e2d065b58e5904fc8e9e545e3dac7a6`
+- **Revert:** delete the SEC-017 row from `docs/security-ledger.md`
+  (`git revert <sha>` for the commit).
+
+## Item 3 -- guardrails: repo-lint L11 + fail-closed compress prohibition
+
+Council-reviewed guardrail set. (a) a repo-lint hash-baseline of the plugin
+files was REJECTED (layering violation -- the plugin lives outside the repo
+under `~/.claude`, non-portable across workstations, and duplicates the
+plugin's own `checksums.sha256`; drift-on-update belongs in the SEC-017
+re-verify duty, not repo-lint). Built (b) and (c):
+
+- **(b) repo-lint L11 -- caveman-compress residue detector.** `scripts/repo_lint.py`
+  gains L11: FAIL on any `*.original.md` in the tree (the backup signature of a
+  lossy in-place `/caveman-compress` rewrite). Excludes `.git`, `.claude`
+  worktrees, `.terraform`, `__pycache__` (reuses the `all_text()` skip set);
+  opt-out marker `repo-lint: allow-original-md` per the L9 convention. Docstring
+  catalog + `repo-lint.sh` header updated L1-L10 -> L1-L11. Harness
+  `tests/repo-lint/run-tests.sh` gains T42 (residue FAILS), T43 (opt-out
+  suppresses), T44 (worktree excluded): **45/45 PASS** (was 42). It is a
+  POST-HOC detector (the original is already overwritten when the backup
+  exists) -- it complements, not replaces, (c).
+- **(c) fail-closed compress prohibition.** Mechanism measured read-only:
+  `/caveman-compress <file>` is a SKILL that mutates by running
+  `python3 -m scripts <file>` from the skill dir (in-place overwrite +
+  `<name>.original.md` backup). Two layers added: (1) `.claude/settings.json`
+  `deny` rules `Bash(*python3 -m scripts*)` + `Bash(*caveman-compress*)` --
+  verified no legit repo usage collides (the strings appear only inside
+  `repo_lint.py`'s L11 text, never in an executed argv); (2) a CLAUDE.md
+  "Tooling guardrails" section prohibiting the compressor against ANY
+  repo-tracked prose file, scoped to the whole record corpus (not a 4-file
+  hand-list, which would rot). Note the pre-existing `Skill(*)` ask rule already
+  gates the skill invocation itself; the deny is the fail-closed backstop that
+  does not depend on that routing.
+- Net enforcement stack: plugin DISABLED (item 1) is primary; `Skill(*)` ask +
+  the compress `deny` gate invocation; L11 catches residue; CLAUDE.md is the
+  human-readable rationale.
+- Verification: `jq` valid; all touched files ASCII/LF; repo-lint 0 fail / 1
+  legacy warn; `bash scripts/run-tests-all.sh` -> **GAUNTLET: ALL GREEN
+  (77 harnesses)**.
+- **Revert:** `git revert <sha>` -- removes L11 (+ its 3 harness cases), the two
+  `deny` rules, and the CLAUDE.md section together.
+
+---
+
+(Session continued into the VR1 DC-mirror work -- distinct topic, same session, so
+per GA-R2 it lands in this one changelog.)
+
+## Item 4 -- DC1 debmirror PAUSED; bandwidth measured NOT the bottleneck
+
+- Operator asked to pause one sync so a single mirror completes before tomorrow,
+  on the premise the two syncs share the vcloud uplink. PAUSED dc1 (live):
+  `systemctl stop dc1-mirror-sync.service dc1-mirror-sync.timer` on the dc1 rack;
+  debmirror killed (0 procs), held at **329.9 GiB** (resumable; status left stale
+  "RUNNING"). Timer stopped so it cannot auto-restart and re-contend.
+- MEASURED result: pausing dc1 did NOT speed dc0 up -- solo dc0 averaged ~37 GiB/h
+  vs ~35 GiB/h while contended. So the vcloud uplink is NOT the binding
+  constraint (it is per-connection/per-file, dominated by universe's small-package
+  tail). The pause neither helped nor hurt dc0; dc0 is on track (~70% at
+  2026-07-24T15:35Z, ETA ~this evening UTC). This finding fed the DC1 decision
+  (item 5): rather than idle dc1, switch it to a caching proxy.
+- **Revert:** resume dc1's full sync -- on the dc1 rack:
+  `systemctl daemon-reload && systemctl start dc1-mirror-sync.service dc1-mirror-sync.timer`
+  (debmirror resumes from 329.9 GiB, skipping downloaded files).
+
+## Item 5 -- DC1 interim apt caching proxy: D-135 amendment + dc-cache-proxy.sh
+
+- **D-135 AMENDED 2026-07-24 (GA-R5, operator utterance quoted in
+  design-decisions.md):** DC1 gets an INTERIM apt caching proxy to unblock its
+  build now; DC0 stays the full-mirror deployment under test; DC1 proxy REPLACED
+  by a full mirror afterward. Both artifact-delivery models exercised this
+  rehearsal (Roosevelt input, D-132/D-133). The paused dc1 debmirror (~330 GiB)
+  is KEPT dormant as the fallback, not deleted.
+- **Shipped `scripts/dc-cache-proxy.sh`** (site-keyed check/install; apt-cacher-ng
+  in proxy mode at the D-134 utility `.4:3142`, consumed via
+  `juju model-config apt-http-proxy=http://<LISTEN>:3142`; caches archive +
+  security + UCA with no per-repo remap). REUSES the `<site>-mirror-net.service`
+  net layer (does not re-create it; fails loud if absent, pointing at dc-mirror.sh).
+  Feasibility recon confirmed read-only first: apt-cacher-ng installable
+  (`3.7.4-1ubuntu5.24.04.1`), all three upstreams 200 via the edge, port 3142 free.
+- **Harness `tests/dc-cache-proxy/run-tests.sh`** (15 static cases: syntax, both
+  sites' utility .4 + ruled edge gw, stable-identity keying, port pin, proxy-mode
+  consumption, archive+UCA smoke coverage, net-layer reuse, MEASURED-tag
+  discipline, arg/site validation) -- **15/15 PASS**.
+- CURRENT-STATE Stage-4 narrative updated (DC0/DC1 artifact-path split). repo-lint
+  0 fail / 1 legacy warn; `bash scripts/run-tests-all.sh` -> **GAUNTLET: ALL GREEN
+  (78 harnesses)** (was 77; +tests/dc-cache-proxy).
+- Live install on the DC1 rack (`apt-get install apt-cacher-ng` + `dc-cache-proxy.sh
+  install dc1`) DONE + verified 2026-07-24 (gated): apt-cacher-ng
+  `3.7.4-1ubuntu5.24.04.1` active on `.4:3142`, drop-in matches, net layer present,
+  **check PASS 8/8 -- proxy serves archive (200) AND UCA caracal (200)** (UCA cached
+  with no remap, as expected in proxy mode). NOTE: the DC1 rack reports a pending
+  kernel reboot (running 6.8.0-134 vs installed -136) -- pre-existing, deferred to a
+  maintenance window (a reboot would disrupt the paused mirror).
+- **Revert:** `git revert <sha>` (removes the script, harness, D-135 amendment
+  paragraph, and CURRENT-STATE split); if installed live, on the dc1 rack:
+  `systemctl disable --now apt-cacher-ng; rm -f /etc/apt-cacher-ng/acng.conf.d/dc1-cache-proxy.conf`.
+
+## Item 6 -- phase-4 runbook: per-DC MAAS service-credential step (Step 2.0)
+
+- Operator-directed: the MAAS API key Juju needs is created by NO prior stage --
+  a standing DEPLOYMENT-TIME task, so it belongs in the runbook. Added **Step 2.0**
+  to `runbooks/dc-dc-phase4-juju-bundle-per-dc.md` (before the bootstrap MUTATION):
+  create a DEDICATED per-DC MAAS admin service user (`sudo maas createadmin`) +
+  issue its own API key (`sudo maas apikey --generate`) -- per-DC credential
+  isolation (SEC-012/-016; Roosevelt: per-DC cloud creds), never a cross-DC reuse.
+- **Creds location corrected (operator-directed):** the key stages in the JUMPHOST
+  per-site creds folder (`~/vr1-<dc>-creds/maas-api-key.txt` on vcloud, SEC-009
+  convention) -- NOT a new location on the region (voffice1) as the first
+  walkthrough had it. Generated FROM the jumphost so it transits ssh stdout with
+  no persistent copy on the region; never printed (SEC-006); consumed by Juju via
+  path/stdin, never argv. Each issued key = a per-DC SEC rotation row.
+- Revert: `git revert <sha>` (removes Step 2.0). No live/cloud state touched.
+
+## Item 7 -- Per-DC MAAS service credentials created (SEC-018/-019) [CLOUD MUTATION, driven]
+
+- Executed phase-4 Step 2.0 for both DCs (operator: "You drive it"), logged
+  window `~/as-executed/2026-07-24-dc-maas-creds.log`. Passwordless sudo on
+  voffice1 confirmed; `maas createadmin --password` supported (read-only precheck).
+- Created dedicated MAAS superusers **`juju-vr1-dc0`** and **`juju-vr1-dc1`**
+  (random passwords generated ON the region, UNSTORED -- Juju auths via the API
+  key), and staged each user's API key into the vcloud per-site folder:
+  `~/vr1-dc0-creds/maas-api-key.txt` and `~/vr1-dc1-creds/maas-api-key.txt` (0600).
+  Keys generated FROM the jumphost (no persistent region copy), verified by
+  FORMAT ONLY (both parts=3, 70 chars), never printed. Result fail=0.
+- **SEC-018** (dc0 key) + **SEC-019** (dc1 key) opened -- per-DC rotation
+  obligations (open SEC 13 -> 15; reconciled at Stage 4 close per the G14 pattern).
+  as-executed index entry added (log itself stays uncommitted, secret-adjacent).
+- Revert: on voffice1 `sudo maas apikey --username=juju-vr1-dc0 --delete=<key>`
+  (+ dc1) and `sudo maas deleteuser juju-vr1-dc0` (+ dc1); `shred -u` the two
+  vcloud key files; `git revert <sha>` for the SEC/index/changelog rows.
+
+## Item 8 -- dc1 VIP overlay drafted (overlays/vr1-dc1-vips.yaml)
+
+- Operator OK'd the overlay approach (vs editing bundle.yaml in place). Drafted
+  `overlays/vr1-dc1-vips.yaml`: re-homes the 11 API-service VIPs from bundle.yaml's
+  vr1-dc0 bands into vr1-dc1's MEASURED bands (lib-net vr1-dc1 PLANE_NAME):
+  provider-public 10.12.4 -> 10.12.64, metal-admin 10.12.8 -> 10.12.68,
+  metal-internal 10.12.12 -> 10.12.72; host octets .50-.60 unchanged. Base
+  bundle.yaml stays the vr1-dc0 source of truth; overlay applied only for the dc1
+  deploy (`juju deploy ./bundle.yaml --overlay ./overlays/vr1-dc1-vips.yaml`).
+  YAML valid (11 apps), repo-lint 0 fail.
+- Revert: `git revert <sha>` (removes the overlay). No live/cloud state.
+
+## Item 9 -- Juju client setup on voffice1 (cloud + credentials) [client config, not a cloud mutation]
+
+- **Juju client location = voffice1** (operator-ruled after reconsideration): the
+  Office1 headend has a Roosevelt analog and D-128 runs MAAS-facing work there so
+  runbooks read "from the headend"; vcloud (substrate host) has no Roosevelt
+  analog, so driving the cloud from it would not transfer. Juju 3.6.25 (3/stable,
+  matches VR0 + the bundle's Juju 3.6 target) installed on voffice1; removed from
+  vcloud.
+- `juju add-cloud --client vr1-maas` -- the ONE Office1 MAAS region
+  (type=maas, endpoint `http://10.10.0.20:5240/MAAS`). `juju add-credential`
+  both DCs: `vr1-dc0-cred` + `vr1-dc1-cred` from the staged keys, piped
+  vcloud->voffice1 into a home-dir yaml (snap can't read /tmp), never printed,
+  `shred -u`'d. Juju credential store on voffice1 now holds runtime copies (noted
+  on SEC-018/-019; canonical files stay on vcloud). Credentials validate at
+  bootstrap (juju does not pre-validate).
+- Two snap gotchas measured + worked around: the juju snap has a private /tmp
+  (stage bundle/overlay/cred files under $HOME); voffice1 ssh sessions have
+  per-session /tmp. Both relevant to the deploy steps.
+- Revert: `ssh voffice1 'juju remove-credential vr1-maas vr1-dc0-cred; juju
+  remove-credential vr1-maas vr1-dc1-cred; juju remove-cloud --client vr1-maas'`;
+  `git revert <sha>` for the SEC/changelog rows.
diff --git a/docs/archive/changelogs/changelog-20260724-stage5-committee-fork1.md b/docs/archive/changelogs/changelog-20260724-stage5-committee-fork1.md
new file mode 100644
index 0000000..c465909
--- /dev/null
+++ b/docs/archive/changelogs/changelog-20260724-stage5-committee-fork1.md
@@ -0,0 +1,294 @@
+# Session changelog 2026-07-24 -- Stage-5 bundle-render committee + Fork-1 ruling
+
+Branch `dc-dc-stage4-phase3-maas-deploy`. Session resumed the DC1 Stage-5
+bundle-rework blocker under a committee review (operator-requested). Status lives
+ONLY in `docs/CURRENT-STATE.md` (GA-R1); this changelog is the review surface --
+each item states what / why / revert. No cloud state was mutated this session.
+
+## Item 1 -- Committee record (Track 2 bundle render)
+
+**What:** new `docs/audit/committee-20260724-track2-bundle-render.md` -- a 4-lens
+(Roosevelt-delta / HA-DR / operational-risk / Juju-MAAS-mechanism) read-only
+committee review of the vr1-dc1 deploy-artifact render, with the adjudication and
+open operator decisions. Advisory/audit record; adopts nothing (GA-R5).
+**Why:** operator: "Deploy a committee to review Track 2 and provide
+recommendations based on overall end project goals and decisions already
+researched." Durable, citable authority (commissioning-committee precedent).
+**Revert:** `git rm docs/audit/committee-20260724-track2-bundle-render.md`.
+
+## Item 2 -- Capacity gate capture (Fork-1 option a)
+
+**What:** new `docs/audit/stage5-controller-capacity-20260724.txt` -- captured
+`scripts/dc-dc-whole-host-budget.py` runs: baseline built layout 3+2+4 x2 DC =
+838/1024 GiB (82%, FIT); +controller (+8 GiB/+4 vCPU per-DC containment overhead)
+= 854/1024 GiB (83%, FIT, 170 GiB headroom). Read-only calculator; nothing
+queried live.
+**Why:** GA-R1 -- the Fork-1 (a) capacity claim must be MEASURED, not inferred
+(the signed doc's 790/77% is the OLD 8-node layout). Gate = PASS.
+**Revert:** `git rm docs/audit/stage5-controller-capacity-20260724.txt`.
+
+## Item 3 -- D-104 amendment (Fork-1 ruling: dedicated 10th controller VM)
+
+**What:** appended a D-104 amendment (2026-07-24) in `docs/design-decisions.md`
+recording the operator's GA-R5 ruling -- the per-DC Juju controller is a DEDICATED
+10th node VM (distinct tag `juju-controller-vr1-dc1`, no role tag), separate from
+the 9 Option C role nodes; additive (`for_each`-keyed); capacity gate PASS
+(cites item 2); the 9-node D-121 layout is unchanged.
+**Why:** Fork 1 was the blocking architectural decision; operator selected
+"Dedicated 10th VM (Recommended)" over shrink-a-role and co-locate. Controller
+placement is D-104's subject; recorded as its amendment (not a new D-number).
+**Revert:** delete the "### D-104 -- AMENDMENT (2026-07-24)" block in
+`docs/design-decisions.md` (git range-diff of this commit).
+
+## Item 4 -- CURRENT-STATE Stage-4 bullet update (GA-R1 / C1)
+
+**What:** rewrote the Stage-4 bullet's render sub-bullets: committee-adjudicated;
+Fork 1 RULED (a) + capacity gate; Fork 2/3 as OPS committee-unanimous
+recommendations (gated at execution); BUNDLEFIX-052 fixed; a corrected NEXT list.
+Also corrected an earlier inaccurate characterization (dc-ha-scaleup is not "stale
+ceph-osd 3" -- it deliberately excludes ceph-osd) and the "consumes 1 of 9"
+arithmetic (now a dedicated 10th VM).
+**Why:** GA-R1/C1 -- a status-changing commit updates CURRENT-STATE in the SAME
+commit (repo-lint L10). Status authority stays single-sourced.
+**Revert:** restore the prior Stage-4 bullet text (git range-diff of this commit).
+
+## Item 5 -- BUNDLEFIX-052: ceph-rbd-mirror duplicate `bindings:`
+
+**What:** removed an orphaned 4-space-indented `bindings:` block in `bundle.yaml`
+(old line ~907) that `yaml.safe_load` take-last had absorbed into `ceph-rbd-mirror`,
+clobbering its real `ceph-local`/`ceph-remote` (replication) + `nrpe-external-master`
+bindings (D-108/D-052) and injecting a phantom `dashboard` binding (a charm with no
+such endpoint) -> `juju deploy` validation reject.
+**Why:** confirmed pre-existing latent defect (committee mechanism lens; verified
+via `yaml.safe_load`). Fork-independent; fix now so the dc1 render starts clean.
+**Validation:** `yaml.safe_load` confirms `ceph-rbd-mirror.bindings` restored to
+`{'': metal-admin, ceph-local: replication, ceph-remote: replication,
+nrpe-external-master: metal-internal}`; `provider-bundle-check.py bundle.yaml` PASS.
+**Revert:** re-insert the orphan block after the vault-hacluster comment (not
+advised -- it is the bug).
+
+## Item 6 -- provider-bundle-check.py: overlay merge + per-DC VIP bands + placement invariants
+
+**What:** extended `scripts/provider-bundle-check.py` with (a) `--overlay FILE`
+(juju-like merge, so the checker validates the EFFECTIVE deploy input), (b) `--dc
+vr1-dc0|vr1-dc1` selecting expected VIP bands (default dc0 = base bundle, so an
+un-parameterized run is byte-identical to before), and (c) placement invariants that
+activate ONLY on a role-separated bundle (machines tagged control/compute/storage)
+and self-skip on the base/un-rendered bundle: no dangling `to:`; LXD containers on
+control, ceph-osd on storage, nova-compute on compute; each num_units>=2 app spread
+across that many DISTINCT machines (anti-affinity); ceph-osd == storage count,
+nova-compute == compute count. Dropped the "controller-tag" idea (the controller is
+the bootstrap machine, not a bundle machine -- verified at the MAAS-tagging step).
+**Why:** the committee's non-negotiable "spine" -- the checker was placement-blind,
+so any render could silently ship decorative HA. Makes the hand-render machine-checked;
+also closes the committee's dc1-VIP-outside-the-check gap.
+**Caveat (VERIFY-LIVE):** the checker's machines-block overlay merge MIRRORS juju's
+documented behavior; the actual machines-retag-via-overlay is confirmed at
+`juju deploy --dry-run` before deploy (no offline juju merger exists). Fallback if it
+does not take: inline the dc1 tags into a rendered bundle.
+**Validation:** harness `tests/provider-bundle-check/run-tests.sh` 15/15 (7 new
+behavioral cases). Gauntlet ALL GREEN (78). repo-lint 0 fail.
+**Revert:** `git checkout <this-commit>~ -- scripts/provider-bundle-check.py
+tests/provider-bundle-check/run-tests.sh`.
+
+## Item 7 -- vr1-dc1 bundle render (9-node role-separated) + retag overlay
+
+**What:** rendered `bundle.yaml` from VR0's 4-node hyperconverged layout to VR1 dc1's
+9-node role-separated one: machines block "8"-"11" (`tags=openstack`) -> "0"-"8" with
+role+DC tags (block style -- flow `{...}` would split the comma-tag); every app `to:`
+re-homed (mysql/ovn-central/ceph-mon -> control 0/1/2; nova-compute 3->2 on compute 3/4;
+ceph-osd -> storage 5/6/7/8; the 14 scaled apps -> control placeholder that the overlay
+spreads; utilities -> control); ovn-chassis MACs -> the 2 dc1 compute provider NICs.
+Rendered `overlays/dc-ha-scaleup.yaml` tokens -> logical control ids 0/1/2 (now
+DC-neutral) + updated its header + fixed the stale ceph-osd-3 comment. New
+`overlays/vr1-dc1-machines.yaml` (per-DC retag; machines-overlay merge is VERIFY-LIVE at
+`juju deploy --dry-run`).
+**Why:** the committee-adjudicated render (Fork 2 = hand-render now); unblocks the dc1
+Stage-5 deploy. Done as an asserted one-shot line-transform (preserves all D-NNN comments)
+reviewed via git diff + the validator.
+**Validation:** `provider-bundle-check.py bundle.yaml` (base standalone) PASS; the FULL dc1
+deploy input (`--overlay vr1-dc1-machines --overlay vr1-dc1-vips --overlay dc-ha-scaleup
+--dc vr1-dc1`) PASS; harness 15/15; gauntlet ALL GREEN (78); repo-lint 0-fail. The
+validator CAUGHT a real render bug (YAML flow-comma dropping the role tag) -- exactly its
+purpose.
+**Revert:** `git checkout <this-commit>~ -- bundle.yaml overlays/dc-ha-scaleup.yaml` +
+`git rm overlays/vr1-dc1-machines.yaml`.
+
+## Item 8 -- provider-bundle-check ovn-chassis role-sep branch + expansion review record
+
+**What:** (a) `provider-bundle-check.py` -- computes `role_sep` early; the ovn-chassis MAC
+check now skips the VR0 openstack0-3 Pattern-A set on a role-separated bundle (verifies
+present + well-formed instead), since dc chassis are the compute-node provider MACs.
+(b) new `docs/audit/stage5-expansion-review-20260724.md` -- three read-only reviewer
+verdicts (relations/bindings/cross-DC; config/pins; deploy-scripts), dispositioned
+(handled / follow-up / VERIFY-LIVE / resolve-before-deploy / no-change).
+**Why:** the operator-requested deployment-script expansion review; captures the
+cross-connection/pinning/gate findings durably so the Chat design session (NetBox-deploy
+coupling) reads them from the repo.
+**Validation:** harness 15/15 (T9's role-sep fixture exercises the ovn role-sep branch);
+gauntlet ALL GREEN (78).
+**Revert:** `git checkout <this-commit>~ -- scripts/provider-bundle-check.py` +
+`git rm docs/audit/stage5-expansion-review-20260724.md`.
+
+## Item 9 -- office1-netbox RECORD dumper (source separation) + current snapshot
+
+**What:** new `netbox/office1-record-dump.py` -- a dedicated READ-ONLY dumper for the
+**office1-netbox RECORD** (the VR1 working apex, `10.10.1.10:8000`, 4.6.4, v2 token),
+separate from `netbox/prod-draft-dump.py` (which pulls the FROZEN v1 reference
+`netbox.baldurkeep.com`). Operator-directed source separation ("one script per source" --
+each holds only its own credential/URL; the token never travels, read from env). Added a
+source-clarity note to `prod-draft-dump.py`'s docstring. New offline harness
+`tests/office1-record-dump/run-tests.sh` (5/5: slim / prefix-scope rewrite / range key /
+source-target). Committed the current snapshot `netbox/draft/vr1-office1-current-20260725.json`.
+**Why:** a Chat design session (NetBox->deploy coupling) has no live infra; the existing
+`vr1-draft.json` is the FROZEN reference (dated 07-15), NOT the current in-cloud state.
+This captures the live apex so Chat designs against current data. Discovery: the standard
+dump targets baldurkeep, not office1-netbox -- corrected before committing wrong-source data.
+**Validation:** dump succeeded READ-ONLY (139 prefixes / 11 sites incl. vr1-dc0/dc1/off1;
+dc1 bands 10.12.64/68/72.0/22 present -- confirms current buildout; differs from the 90-prefix
+frozen reference). Harness 5/5; nothing written to NetBox.
+**Revert:** `git rm netbox/office1-record-dump.py netbox/draft/vr1-office1-current-20260725.json
+tests/office1-record-dump/run-tests.sh` + restore `prod-draft-dump.py` docstring.
+
+## Item 10 -- dc-mirror upstream-host preference note (mirror.uoregon.edu)
+
+**What:** added an UPSTREAM HOST NOTE to `scripts/dc-mirror.sh`'s header (operator,
+2026-07-25): PREFER `http://mirror.uoregon.edu/ubuntu/` (closest/fastest for this
+deployment) over `archive.ubuntu.com` for the MAIN archive debmirror -- future change,
+NOT yet applied. Scoped: main archive only (`--host=mirror.uoregon.edu`, root stays
+`ubuntu`); the UCA cloud-archive uses a separate host uoregon does not mirror; applies
+to dc-cache-proxy.sh + the Roosevelt dedicated mirror too; verify jammy coverage before
+flipping. Header comment only -- does NOT change the generated `<site>-mirror-sync` unit.
+**Why:** operator-provided performance preference, logged for a future mirror-tuning
+session (findings LOGGED, not executed mid-step).
+**Revert:** delete the UPSTREAM HOST NOTE block in `scripts/dc-mirror.sh`.
+
+## Item 11 -- full decision reconciliation (record)
+
+**What:** new `docs/audit/decision-recon-20260725.md` -- a 4-lens read-only recon of
+every ruled IP/VLAN/node decision against the authoritative surfaces (office1-netbox
+apex snapshot, lib-net/lib-hosts, bundle/overlays, MAAS carve captures). CURRENT-STATE
+Stage-4 bullet updated (GA-R1/C1) with a pointer + the key findings + a WARNING that
+this doc's section 4 is stale.
+**Why:** operator-requested full decision recon + "what other reconciliations to queue."
+Feeds the Chat NetBox->deploy coupling design and the stage close.
+**Findings (headline):** IP prefix-layer COMPLETE + drift-free; VLANs correctly absent
+(untagged-per-fabric, D-133); GAP = sub-prefix (D-134 bands + 33 VIP addresses, in
+prose/overlays only) -- blocks the coupling. Node/MAC/power drift-free; Fork-3 tags +
+10th VM pending gated. Decision-status: STALE surfaces flagged (CURRENT-STATE section 4
+HIGH; G14 SEC 12->15; phase-4 designate) -- fixes QUEUED (operator-deferred). Recon
+backlog P0-P2 in the record; extend sandbox-fidelity-check.py first.
+**Revert:** `git rm docs/audit/decision-recon-20260725.md` + restore the CURRENT-STATE
+Stage-4 recon bullet.
+
+## Item 12 -- Ruling 1 recorded (GA-R5): address-family policy
+
+**What:** recorded the operator's 2026-07-25 address-family ruling as a dated RULING NOTE
+under `## D-101` in `docs/design-decisions.md` (verbatim question + utterance) + resolved
+the CURRENT-STATE resolve-before-deploy bullet (b). Confirms D-101's matrix; NO amendment.
+**GA-R5 record.** Question: v4-only vs dual-stack for dc1 phase-4. Operator utterance,
+verbatim: "Dual stack to be used where IPv4 is required, IPv6 where IPv6 only makes sense."
+Clarifying, verbatim: "Dual stack deployment for DC0 and DC1. This is the deployment when
+the dual-stack is added".
+**Why:** GA-R5 -- the VIP reconciliation (dependent work) is invalid until this is
+committed+pushed. Closes the v4-only phasing option for both DCs. From the Chat handoff
+pack (`_handoff-not-committed/20-ruling-records.md`, ruling 1); the verbatim was
+transcribed into durable homes (D-101 note + here) rather than left in the delete-after-use
+pack file (committee BLOCKER-1 fix).
+**Revert:** `git revert <commit>` -- deletes the D-101 ruling note + restores bullet (b).
+
+## Item 13 -- Ruling 2 recorded (GA-R5): keystone policy-override VERIFY-LIVE gate
+
+**What:** added a Stage-4 VERIFY-LIVE gate to CURRENT-STATE -- after `dc-ha-scaleup` scales
+keystone to 3, `juju status` must show `PO:` on EVERY keystone unit, never `PO (broken):`.
+**GA-R5 record.** Question: whether to add a VERIFY-LIVE gate confirming the
+`policyd-override` resource lands on every keystone unit after scale-up (a broken override
+is atomic -- the whole policy is discarded, silently reverting every tenant domain-manager
+to a plain user). Operator utterance, verbatim: "dc-ha-scaleup: Yes to the verify-live".
+**Why:** highest-consequence single check in the deploy -- it protects the SCS Domain
+Manager persona (D-051/D-064) the commercial tenant self-service model rests on, and
+failure has no other symptom. Mechanism intact at HEAD (`bundle.yaml` `use-policyd-override:
+true` + `resources: policyd-override` -> `policies/overrides.zip` 3419 bytes;
+`keystone-policy-drift.sh` byte-matches source) -- the gate confirms it SURVIVES scale-up.
+From the Chat handoff pack ruling 2; verbatim transcribed to a durable home (here), not
+left in the delete-after-use pack file.
+**Revert:** `git revert <commit>` -- removes the gate line.
+
+## Item 14 -- D-136 PROPOSED (NetBox-coupled render pipeline) + Ruling 3 recorded (GA-R5)
+
+**What:** appended D-136 (PROPOSED, [ARCH]) to `docs/design-decisions.md` register tail;
+CURRENT-STATE Stage-4 bullet updated SAME COMMIT (C1) -- bullet (c) artifact-shape, the
+coupling bullet -> "PROPOSED as D-136 / option (C)", the FOLLOW-UP gate blockers. Ruling 3
+is recorded INLINE in D-136's "Artifact shape (RULED 2026-07-25)" paragraph with the
+verbatim question + utterance.
+**GA-R5 (Ruling 3).** Question: symmetric (extract dc0 VIPs to an overlay, base VIP-free)
+vs asymmetric (dc0 v6 into base, two renderer modes)? Operator utterance, verbatim: "Your
+question about 1 or 2, go with 1. Base bundle and everything else is applied via overlay."
+Effect: symmetric per-DC overlays; bundle.yaml VIP-free; gates the dc0 VIP extraction.
+**Pack-review committee corrections folded in (2026-07-25):** verbatim inlined into durable
+homes (D-136 paragraph + here), not the delete-after-use pack file (BLOCKER-1); added the
+`VIP_OCTET_MAX=60` sibling constant + the 2nd stale `VIP_COUNT_EXPECT` site; mis-citation
+count corrected to SEVEN. **Chat correction (2026-07-25) folded in:** open question 5
+rewritten -- Jenkins IS the runner (gap VOID); real requirements are webhooks + status-back
+(unverified vs GitBucket); placement OPEN (voffice1/VR1, per-DC agents Roosevelt, D-132/D-105
+caveats); carry-forward `handoff-20260703-open-items.md:159`.
+**Why:** escalates the Fork-2 renderer deferral; scopes the sub-prefix gap fix. PROPOSED --
+operator rules the mechanism.
+**Revert:** `git revert <commit>` -- deletes D-136 + restores the CURRENT-STATE bullets.
+
+## Item 15 -- DOCFIX-201: the dual-VIP decision is D-020, not D-036 (SEVEN sites)
+
+**What:** corrected SEVEN VIP-context citations of `D-036` where `D-020` is meant
+(`## D-020: Dual provider + metal API VIPs`; `## D-036` is the magnum-capi-helm decision):
+`docs/design-decisions.md` (3: the D-121 "problem this fixes" `per D-036`, the `D-009,
+D-036` HA-scaleup table row, the References `D-036 (dual VIPs)`), `docs/CURRENT-STATE.md`
+(the vault-VIP bullet), `docs/audit/decision-recon-20260725.md` (2 backlog rows), and
+`docs/audit/stage5-expansion-review-20260724.md` (in-place with the bracketed marker
+`[corrected DOCFIX-201: D-020, not D-036]`, operator-chosen).
+**Why:** the mis-citation had spread to SIX sites (2 created by the recon itself); the 7th
+(the `D-009, D-036` table row) was caught by the pack-review committee -- the pack listed
+only 6 and its own verify count would have failed at 9. Reading the correct D-020 also
+surfaced that D-020's ratified set includes vault + excludes ceph-radosgw while the deployed
+set does the opposite (fed into D-136).
+**Verify:** `git grep -n "D-036" -- ':!docs/archive' ':(exclude)_handoff-not-committed/*'`
+-> 8 hits, all driver/chart/CAPO, zero VIP-context.
+**Revert:** `git revert <commit>` -- text-only across four files, no behavioural effect.
+
+## Item 16 -- DOCFIX-202: buildout-scope section 5 demoted to a D-111 pointer
+
+**What:** `docs/dc-dc-netbox-buildout-scope.md` section 5 presented the per-DC v6 subcarve
+(sub-decision 1) as open/un-ratified at lines 5, 132, 138 -- contradicting the ratified
+pointer already present at line 146 ("RATIFIED as D-111 (2026-07-11)"). Demoted the three
+open-framing sites to acknowledge D-111 (ADOPTED); kept the reasoning below as history.
+**Why:** `## D-111` is ADOPTED 2026-07-11 and names this exact sub-decision; the stale open
+framing misled the Chat seat 2026-07-25 (it treated the subcarve as a blocking trust gate,
+withdrawn only after reading the register). Committee-confirmed the targets; the rest of
+section 5 has no other adopted-decision contradiction.
+**Verify:** `bash scripts/ledger-scan.sh` -- D-111 not under PROPOSED/OPEN; `grep -n
+"un-ratified\|candidate D-111" docs/dc-dc-netbox-buildout-scope.md` -- no hit presenting
+the subcarve as open.
+**Revert:** `git revert <commit>` -- single-file text change, no behavioural effect.
+
+## Item 17 -- DOCFIX-203: mark D-134's superseded original band table in place
+
+**What:** added a `**SUPERSEDED ... do NOT use these bands**` marker immediately above the
+ORIGINAL D-134 band table in `docs/design-decisions.md` (control .10-.19 / compute .20-.49 /
+storage .201-.254), pointing at the authoritative 2026-07-23 AMENDMENT (contiguous: .4-.49
+utility, .50-.99 VIP, .100-.200 nodes, .201-.254 dynamic). Original kept as history.
+**Why:** the amendment header says it supersedes the original, but the original table carried
+NO in-place marker -- a reader grepping `D-134` hits the original first and gets the rejected
+bands. The Chat seat did exactly this 2026-07-25 (one read from a false discrepancy), and the
+band-modelling this coupling (D-136) must do reads these bands. Committee-confirmed.
+**Verify:** `awk '/## D-134:/,/## D-134 -- AMENDMENT/'` shows the marker before the first
+table row.
+**Revert:** `git revert <commit>` -- single text addition, no behavioural effect.
+
+## Next (not done this session; gated)
+
+Commit+push this batch (GA-R5: rulings land before dependent work). Then, each
+operator-gated: per-role MAAS tags; author + apply the 10th controller VM
+(egress OPEN); render the 9-node `bundle.yaml` (re-home base placements, re-scope
+tokens) + extend `provider-bundle-check.py` with placement assertions + wire
+overlays + de-stale phase-4 Step 4; gated `juju bootstrap` (by controller tag,
+egress OPEN) -> deploy. Deploy-time VERIFY-LIVE gates: vault-3-unit HA-on-MySQL,
+hacluster cluster_count:3, dc1 VIPs, CRUSH failure-domain=host.
diff --git a/docs/archive/changelogs/changelog-20260725-maas-admin-recovery.md b/docs/archive/changelogs/changelog-20260725-maas-admin-recovery.md
new file mode 100644
index 0000000..7f53e79
--- /dev/null
+++ b/docs/archive/changelogs/changelog-20260725-maas-admin-recovery.md
@@ -0,0 +1,263 @@
+# Session changelog 2026-07-25 -- MAAS admin-account recovery + creds consolidation
+
+Branch `dc-dc-stage4-phase3-maas-deploy`. Operator task: "complete the recovery of
+the MAAS admin accounts ... complete password resets, and save the creds in their
+proper folders so I can retrieve them." Status lives ONLY in `docs/CURRENT-STATE.md`
+(GA-R1); this changelog is the review surface -- each item states what / why / revert.
+
+Measured evidence for every claim below:
+`docs/audit/maas-admin-recovery-20260725.txt` (42 lines, no secret values).
+
+**The task premise was FALSIFIED by measurement before any mutation.** The
+session-ledger's 2026-07-25 "IMMEDIATE NEXT" asserted MAAS web-GUI login "does NOT
+exist ... never minted; no prior task did it". It did exist: the `admin` superuser's
+password was minted 2026-07-13 by `scripts/site-headend-install.sh:452` and is
+MEASURED working (login POST 204 with the stored value, 400 with a wrong-password
+control; `has_usable_password=True`). It was merely root-only on voffice1 at
+`/root/maas-secrets/admin.pass` and never consolidated to `~/vr1-office1-creds/` --
+the SEC-009 miss class, not a missing account. Only the ledger's `juju-*` clause was
+correct. That finding was reported and the scope RE-RULED by the operator before
+execution: **"New account + consolidate only"** -- no existing password rotated.
+
+## Item 1 -- NEW MAAS superuser `operator` (live region mutation, gated)
+
+**What:** minted MAAS superuser `operator` / `jesse.austin@neumatrix.com` on the
+Office1 region for HUMAN GUI login. Password 32-char base64, generated ON vcloud
+straight into `~/vr1-office1-creds/maas-operator-password` (0600), then fed to
+`maas createadmin` over **stdin** -- never in argv, never printed, never in context.
+Verified: account present + `superuser=True`; stored password authenticates (204)
+against a wrong-password control (400).
+**Why:** operator-ruled scope. Gives a human identity distinct from the service
+identity -- until now the only usable GUI login was `admin`, which is simultaneously
+the automation identity (item 6). Note `maas changepassword` has NO `--password`
+flag and `createadmin --password` would place the secret in argv (the shape
+`site-headend-install.sh:452` uses); the stdin path satisfies the SEC-018
+"never printed/echoed/in argv" discipline and is the transferable technique.
+**Revert:** `ssh voffice1 'maas admin user delete operator'` then
+`rm ~/vr1-office1-creds/maas-operator-password` and drop its manifest row (item 3).
+
+## Item 2 -- `admin` password CONSOLIDATED to the jumphost (no rotation)
+
+**What:** copied `voffice1:/root/maas-secrets/admin.pass` ->
+`~/vr1-office1-creds/maas-admin-password` (0600, 28 bytes). Byte-identical,
+sha256-verified both ends. Value moved over ssh into the file; never printed.
+Verified the CONSOLIDATED copy authenticates as `admin` (204).
+**Why:** closes the SEC-009 miss for this secret -- it is now retrievable from the
+operator's own folder instead of being root-only on a VM. Deliberately NOT rotated
+(operator ruling), so **the VM copy REMAINS source-of-record** and the vcloud file is
+a working copy; a future `admin` rotation must update BOTH in one operation or the VM
+copy becomes a stale trap. Recorded in SEC-020.
+**Revert:** `rm ~/vr1-office1-creds/maas-admin-password` + drop its manifest row.
+No loss -- the source-of-record copy on voffice1 was never modified.
+
+## Item 3 -- `creds-manifests/vr1-office1.manifest`: two new declared secrets
+
+**What:** declared `maas-admin-password` (provenance
+`voffice1:/root/maas-secrets/admin.pass` -- the `<vm>:<path>` class the manifest
+format exists for) and `maas-operator-password` (`local`), with a header comment
+recording the mint mechanism, the byte format, and the still-un-consolidated
+residue (item 7).
+**Why:** the manifest is the forcing function -- an undeclared secret is exactly how
+the NetBox token went missing. Declaring makes `creds-audit` enforce presence+mode.
+**Revert:** `git checkout HEAD -- creds-manifests/vr1-office1.manifest`.
+
+## Item 4 -- dc0/dc1 manifest BACKFILL -> `creds-audit` CLEAN on all three sites
+
+**What:** declared the four files that were failing `creds-audit` as UNDECLARED:
+dc0 `maas-api-key.txt` + `vr1-dc0-edge_ed25519{,.pub}`, dc1 `maas-api-key.txt`.
+Provenance `local` for all four (SEC-018/019 state the API keys were generated FROM
+the jumphost so they never persisted on the region; the edge keypair likewise).
+**Why:** `creds-audit` was RED on two of three sites at session open (dc0 3 fails,
+dc1 1 fail) -- the same convention the operator's task is about, so leaving the gate
+red would have been incoherent. The dc0 edge-keypair rows were a KNOWN queued
+finding, named in `creds-manifests/vr1-dc1.manifest:18-20` ("dc0 precedent, whose
+manifest rows are a queued backfill finding") -- this closes it.
+Result: `creds-audit` CLEAN x3 (13/5/8 entries), harness 7/7.
+**Revert:** `git checkout HEAD -- creds-manifests/vr1-dc0.manifest creds-manifests/vr1-dc1.manifest`
+(returns both sites to FAIL).
+
+## Item 5 -- SEC-020 opened (register of record)
+
+**What:** new row in `docs/security-ledger.md` covering (a) the un-consolidated
+VM-minted `admin` password + the falsified "no GUI login" claim, (b) the human/service
+identity conflation that CAUSED the miss, (c) the new `operator` standing credential.
+Status: OPEN -- rotation obligation on TWO region superusers, plus three logged-not-
+actioned residues. Open SEC rows 15 -> 16.
+**Why:** ledger mandate -- every credential exposure/obligation gets a row, never
+only a comment. A new standing credential is a new rotation obligation.
+**Revert:** delete the SEC-020 row.
+
+## Item 6 -- session-ledger: falsified claim corrected + machine block re-seeded
+
+**What:** (a) struck the 2026-07-25 "IMMEDIATE NEXT" block and annotated it
+FALSIFIED + RESOLVED with what was actually true and what was done. (b) Re-seeded the
+machine-derived block from a fresh `ledger-scan.sh`: it was stale on EVERY line --
+open SEC 12 -> **16**, next-free D 133 -> **137** / DOCFIX 200 -> **204** /
+BUNDLEFIX 052 -> **053**, and D-136 was missing from the open-decision list while
+D-071/D-129 were still listed despite being ADOPTED/RESOLVED.
+**Why:** (a) GA-R1 -- a falsified claim left standing misdirects the next session,
+and this one would have sent it to create an account that already existed. (b) my
+SEC-020 changes the count that block carries, so re-seeding is required by this
+change, not added scope; the block's own rule is "regenerate, never hand-edit".
+**Revert:** `git checkout HEAD -- docs/session-ledger.md`.
+
+## Item 7 -- Findings LOGGED, not executed (hard rule 1)
+
+**What:** recorded in SEC-020, no action taken:
+- (i) `voffice1:/root/maas-secrets/{admin.apikey,db.pass,lxd-trust.pass}` remain
+  un-consolidated. `admin.apikey` deliberately NOT copied -- trivially regenerable
+  (`maas apikey --username=admin`) so a second copy is pure added surface;
+  `db.pass`/`lxd-trust.pass` are region infrastructure, outside this task's scope.
+- (ii) the DURABLE fix for the miss class is a `site-headend-install.sh` amendment to
+  consolidate at mint time (the script currently leaves all four secrets on the VM).
+  Queued, unruled -- a script change needs its harness and a ruling.
+- (iii) the human/service conflation is proposable as a D-number, [ARCH] -- still
+  UNASSIGNED after item 9 took D-137 for the credential pipeline; the two are kept
+  separate deliberately (see D-137's "Related, deliberately NOT folded in"):
+  `admin` is both the GUI login and the automation identity (its API key drives the
+  `maas admin` CLI profile across **19 call sites in 4 scripts** --
+  `site-headend-install.sh` 10, `phase-04-network-verify.sh` 5,
+  `phase-04-network-create.sh` 3, `phase-00-teardown-release.sh` 1). Roosevelt-delta:
+  per-identity MAAS separation / audit attribution on a multi-tenant cloud. NOT
+  assigned -- GA-R3 doubt-resolves-DOWN, operator's call.
+**Why:** findings are logged, never executed mid-task.
+**Revert:** n/a (records only).
+
+## Item 8 -- evidence capture
+
+**What:** `docs/audit/maas-admin-recovery-20260725.txt` -- generated, not
+hand-written: user list, Django password-state booleans, both login probes with
+wrong-password controls, the sha256 fidelity compare, file modes/sizes, `creds-audit`
+x3 + harness, and an automation-unaffected check. Machine-scanned for password bytes
+(0 hits) before commit.
+**Why:** GA-R1 rule 2 -- claims are quoted from captured command output, never prose.
+**Revert:** `git rm docs/audit/maas-admin-recovery-20260725.txt`.
+
+## Not done / still open
+
+- `admin`, `juju-vr1-dc0`, `juju-vr1-dc1` passwords UNCHANGED by ruling. The two
+  `juju-*` passwords remain random + unstored; their API keys are load-bearing for the
+  blocked Stage-5 bootstrap and `operator` removes any need to log in as them.
+- `MAAS` and `maas-init-node` are MAAS-internal accounts -- deliberately untouched
+  (`maas-init-node` is also `is_active=False`).
+- Items 7(i)-(iii) above.
+- Pre-existing, NOT touched by this session: CURRENT-STATE G14 SEC count (reads 12,
+  actual 16) and section 4 ("RULED-BUT-NOT-BUILT", flagged comprehensively stale
+  2026-07-25) -- both already operator-deferred to Stage 4 close.
+
+## Item 9 -- D-137 PROPOSED: credential mint-and-consolidate pipeline [ARCH]
+
+**What:** new `docs/design-decisions.md` entry D-137, PROPOSED (not ruled, not
+implemented). Answers the operator's follow-up ask -- a better minting/saving method
+plus "a durable rule to make sure when accounts are created there is a consolidation
+that happens every time". Records the measured diagnosis, a three-part proposal (the
+invariant; `creds-mint.sh` + `creds-audit --all/--remote` + gate wiring +
+`site-headend-install.sh` amendment; the Roosevelt delta), and THREE open forks.
+Section 8 of CURRENT-STATE gains item 9; the ledger's machine block goes 4 -> 5 open
+decisions.
+**Why:** the diagnosis is that the existing SEC-009 control **cannot detect the failure
+class it was built for** -- the audit is DECLARATION-based, so an undeclared secret is
+structurally invisible. `creds-audit vr1-office1` reported CLEAN on 2026-07-15 while
+four secrets minted on the region VM on 2026-07-13 sat undeclared; `admin.pass` surfaced
+only 2026-07-25, twelve days later, and only because a task went looking (SEC-020).
+Compounding it: no `--all` (`creds-audit.sh:25` takes one mandatory site), and the only
+enforcement is PROSE at `runbooks/dc-dc-phase3-maas-enlist-deploy.md:498` -- absent from
+preflight/cloud-assert/repo-lint/gauntlet -- which demonstrably did not fire at either DC
+standup (dc0 3 + dc1 1 undeclared at this session's open). Admitted as a D under GA-R3 on
+the A1 test: Roosevelt mints per-DC IPMI/BMC and Vault material on real hardware, so a
+Roosevelt build session should grep this before creating any credential; today the rule
+lives only in `docs/security-ledger.md`, a register of exposures, which no gate can cite
+as authority.
+**Deliberately NOT done:** no tooling built, no enforcement wired, no SEC-009 demotion --
+PROPOSED means present options, never implement (hard rule 1 + GA-R5). The SEC-020
+identity-conflation question is kept SEPARATE to avoid batching two rulings.
+**Revert:** delete the D-137 block from `docs/design-decisions.md`, CURRENT-STATE
+section 8 item 9, and the ledger machine-block D-137 clause (restore count to 4).
+
+## Item 10 -- SEC-021/-022/-023 opened: live credential defects found during D-137 research
+
+**What:** three new `docs/security-ledger.md` rows recording defects MEASURED read-only
+while researching the credential matrix. None actioned (hard rule 1). Open SEC rows
+16 -> 19; CURRENT-STATE G14's evidence cell reconciled to 19 in this commit (its title
+text keeps the 07-23 figure and is marked superseded); ledger machine block re-seeded.
+- **SEC-021 -- dc0 custody defects.** (a) `changelog-20260719-dc0-deploy-stepB.md:263`
+  records the dc0 edge REST API credential written to `~/vr1-dc0-creds/opnsense-api.txt`;
+  a `find` over vcloud `$HOME` returns that filename for office1 and dc1 ONLY -- no dc0
+  copy -- and `creds-audit vr1-dc0` reports CLEAN because it was never manifested.
+  Severity is a custody/record defect + API-access gap, NOT a lockout: the dc0 edge SSH
+  key is present and D-112(c) makes key-only SSH the primary management path. (b) dc0's
+  power key is `maas-virsh_ed25519` on voffice1 vs dc1's declared
+  `vr1-dc1-maas-power_ed25519{,.pub}` on vcloud -- same purpose, different name, host and
+  custody, dc0 with no `.pub`.
+- **SEC-022 -- unaudited shadow stores.** `voffice1` holds `~/vr1-dc0-creds/` AND
+  `~/vr1-dc1-creds/` with real key material. `creds-audit.sh:29-31` resolves the folder
+  under `$HOME` on whatever host it runs on (vcloud) and contains no ssh at all, so these
+  are structurally invisible. A SCOPE gap in the control, not a one-off -- D-128 puts
+  Plane-2 execution on voffice1, so headend-resident credentials will keep appearing.
+- **SEC-023 -- sprawl blind spots + a PREDICTED Stage-5 exposure.** The globs at
+  `creds-audit.sh:72-73` miss `admin.pass`, `*.apikey`, `*.key`, `*.pem`, `*_ed25519` and
+  even `maas-api-key.txt`. `phase-03-admin-openrc.sh:32,72` will write `OS_PASSWORD` into
+  `$HOME/admin-openrc` at Stage 5 -- home root, outside any creds folder, matching no
+  glob. Recorded BEFORE it exists so the mint is not missed.
+**Why:** the ledger mandate is a row at discovery, never only a note. These are live
+defects independent of any D-137 ruling, and the approved plan lists recording them as
+the one action not gated behind the five open forks. They also constitute the empirical
+case for the matrix: SEC-021/-023 are absence-and-drift (invisible to discovery) while
+SEC-022 is an unknown-unknown (invisible to declaration) -- the two halves are
+complementary, which could not be argued from the discovery-only D-137.
+**NOT done:** no remediation, no tooling, no glob widening -- all coupled to unruled
+forks. Interim obligations are stated per row (notably: whoever runs Stage 5 phase-03
+must consolidate `~/admin-openrc` BY HAND at mint time).
+**Revert:** delete the three rows, restore the G14 evidence cell, re-seed the ledger
+block to 16.
+
+## Item 11 -- D-137 ADOPTED: all five sub-rulings ruled (GA-R5), implementation unblocked
+
+**What:** the operator's follow-up ask ("better best practices method ... and a durable
+rule so credentials aren't misplaced or lost") was designed, committee-reviewed, and
+ruled. D-137 moves PROPOSED -> **ADOPTED 2026-07-26**. Five sub-rulings, each its own
+operator exchange, each committed+pushed BEFORE the next was asked (GA-R5), verbatim
+selections quoted in the Status block: (1) enforcement = "Blocking in preflight";
+(2) derivation = "Derive manifests from matrix"; (3) remote scope = "Declared locations
+only"; (4) policy home = "D-137 is the authority"; (5) identity = "Fold in as a D-137
+invariant". Commits `a3a2d46`, `df8fa21`, `aa67634`, `db85531`, and this one.
+**Why the design changed:** the operator identified the flaw in D-137-as-first-proposed --
+a discovery sweep can never detect a credential that was NEVER MINTED, because absence is
+invisible to discovery. The known creation points support a forward EXPECTED-state
+register, which is the only instrument that catches a missed mint. Research (3 read-only
+agents) then produced four measured findings that validated it and one that qualified the
+premise: `ssh-keygen` returns ZERO hits repo-wide, so **12 declared secrets have no mint
+command anywhere** -- recorded in `docs/audit/creds-creation-points-20260725.md`, and the
+reason `mint-ref` must admit an `operator-terminal` provenance kind.
+**Committee (5 lenses)** produced three amendments now folded into the ruled design:
+cardinality + host-role as first-class columns; manifests DERIVED not dual-maintained
+(the GA-F06 mitigation); and a VALIDITY tier distinct from existence -- prompted by
+finding that `creds-audit` parses provenance and NEVER verifies it, so the SEC-020 stale
+trap is unchecked today.
+**NOT done:** nothing built. No matrix file, no checker, no `--render`, no preflight `Pn`,
+no SEC-009 demotion. Implementation is unblocked but unstarted. Note the first run of the
+identity invariant is expected RED by design (`admin` serves both a human and a service
+row -- that IS the defect).
+**Revert:** flip the D-137 Status line back to PROPOSED and drop the five sub-ruling
+blocks; restore CURRENT-STATE item 9 and the ledger open-decision count to 5.
+
+## Item 12 -- D-137 build spec made repo-durable (handoff to a fresh session)
+
+**What:** new `docs/D-137-implementation-plan.md` -- the executable build detail for the
+ADOPTED D-137: the five ruled decisions and their consequences, the matrix schema
+(logical keys only per the SEC-004 ruling), the checker model and precedents with
+file:line, the three tiers, the inherited hard constraints, the file list, the acceptance
+test, and an explicit "EXPECTED RED BY DESIGN" section. CURRENT-STATE item 9 and the
+ledger addendum now point at it. Also updated the `creds-folder-convention` auto-memory
+pointer: policy authority is now D-137 (ruling 4), with a verify-first caveat that
+`creds-audit` CLEAN is not evidence of completeness and the matrix is not built.
+**Why:** the design and committee review originated in a plan file under
+`~/.claude/plans/`, which is OUTSIDE the repo -- so a fresh session bootstrapping via the
+GA-R4 path (CURRENT-STATE -> session-ledger -> ledger-scan) would never surface it, and
+the repo-is-authoritative rule would leave the build spec undiscoverable. Precedent for a
+D-NNN plan doc in-repo: `docs/D-068-vault-migration-plan-draft.md`. Operator directed the
+build to a fresh session, which makes this durability gap load-bearing rather than tidy.
+**Note:** the spec deliberately tells the next session NOT to make the first run green --
+the acceptance test is that the checker REPRODUCES SEC-021/-022/-023 and the openrc case
+as named failures. A checker that passes on today's tree is wrong.
+**Revert:** `git rm docs/D-137-implementation-plan.md` and drop the two pointers.
diff --git a/docs/archive/changelogs/changelog-20260726-d137-tier1.md b/docs/archive/changelogs/changelog-20260726-d137-tier1.md
new file mode 100644
index 0000000..9e29746
--- /dev/null
+++ b/docs/archive/changelogs/changelog-20260726-d137-tier1.md
@@ -0,0 +1,772 @@
+# Session changelog 2026-07-26 -- D-137 credential matrix, tier 1 (STATIC)
+
+Session-scoped scratch (GA-R2/D1). NOT a status or decision authority -- status lives only
+in `docs/CURRENT-STATE.md`, rulings only in `docs/design-decisions.md`. Consolidated at
+stage close.
+
+Branch `dc-dc-stage4-phase3-maas-deploy`. No cloud state touched: every item below is
+offline repo work. Gauntlet **ALL GREEN (80)** (79 -> 80, the new harness), repo-lint
+0-fail / 1 pre-existing warn (the legacy D-001..018 ASCII carve-out).
+
+---
+
+## Item 1 -- D-137 matrix schema amended 10 -> 12 columns (operator-ruled)
+
+**What.** `docs/D-137-implementation-plan.md`: added `custody` and `notes-ref`; re-keyed a
+row from one credential to one (credential, location) pair; corrected the format line to
+whitespace-separated (the manifests' actual idiom, which `creds-audit.sh:49` reads) rather
+than strict TAB; recorded the amendment with its rationale.
+
+**Why.** A read-first round-trip check of the three checked-in manifests against the
+10-column schema found it could not carry three classes of governance prose that D-137
+ruling 2 forbids dropping:
+- **off-manifest carve-outs** -- four deliberate, reasoned credential copies (both DCs'
+  Juju client-store keys, the dc1 MAAS-snap power key, and the three ruled
+  not-consolidated region files). Ruling 3 puts their locations INSIDE `--remote`'s
+  declared set, so `creds-audit.sh:63-67` will visit every one and report it UNDECLARED.
+  Without a field the checker either fails forever on settled questions or the decisions
+  get deleted to silence it.
+- **multi-copy credentials** -- one credential, several locations, DIFFERENT filenames
+  (`admin.pass` vs `maas-admin-password`), one designated authoritative copy. Tier 3's
+  digest comparison cannot know what to compare without it.
+- **verification-relevant detail** -- format specs, mint dates, the not-reproducible debt.
+
+Ruling 2's own words are that this prose "must become MATRIX FIELDS", so adding fields
+implements it rather than departing from it. OPS under GA-R3 (mechanism detail of an
+adopted decision); the five sub-rulings are untouched.
+
+**Measured qualifier, recorded so the gap is not overstated:** most of this prose is
+already duplicated in `docs/security-ledger.md` (SEC-018 carries the Juju-store copy;
+SEC-020 carries source-of-record, the stale-trap warning, and all three carve-out
+reasons). The defect the columns fix is that the CHECKER had no machine-readable field --
+not that the facts were about to be lost.
+
+**Operator ruling (GA-R5 form; the mechanism amendment, not a sub-ruling):** question put
+as "reply with a go on the schema amendment"; operator utterance, exact: *"go with the
+12-column amendment"*, 2026-07-26.
+
+**Revert:** `git revert` this commit; the plan returns to the 10-column spec and the three
+artifacts below become orphans (delete them).
+
+## Item 2 -- `creds-matrix.tsv` + `creds-matrix-notes.md` (the register)
+
+**What.** 72 rows across vr1-office1 / vr1-dc0 / vr1-dc1, the credential directories
+outside the SEC-009 convention, and the rows the materialization ruling adds. 32 note keys.
+
+**Why the row count is not 55.** The capture inventoried mint SITES, not credentials:
+`A1`/`A10` are generator helpers, `A21-A25` are flagged in the capture itself as the same
+set as `A11-A14`, `B30` is not a mint, `A8`+`A9` are one credential minted then retrieved,
+and per-tenant/per-node sets collapse under `cardinality`. Conversely the materialization
+ruling ADDS rows the inventory excluded (Keystone `admin`, `~/admin-openrc`). Derived from
+identity, never transcribed 1:1.
+
+**Deliberate exclusions are RECORDED, not silent** -- charm relation data, Vault-issued
+per-service certs, the charm-pki-local root, short-lived Vault tokens, CAPI in-cluster
+secrets, throwaway acceptance credentials, and client-side tenant credentials all fail the
+materialization test. The reasoning is in the notes file so a later reader can challenge
+it.
+
+**Revert:** delete both files.
+
+## Item 3 -- `scripts/creds-matrix.py` tier 1 (STATIC)
+
+**What.** Seven check groups in the `provider-bundle-check.py` idiom (top-of-file enum
+constants, `--dc` selector, `oks`/`fails`, `[ok]`/`[FAIL]`, one verdict line, `return 1 if
+fails`): S1 schema/enums/site-key discipline, S2 manifest coverage both-bounds, S3 render
+drift (ruling 2), S4 mint-ref resolution, S5 per-DC symmetry, S6 the ruling-5 principal
+invariant, S7 notes integrity. `--render` prints derived manifests; it does NOT write.
+
+**Two design decisions worth challenging at review:**
+- The manifest **mode column is DERIVED** (`.pub` -> 644, else 600) rather than becoming a
+  13th column. That rule reproduces all three checked-in manifests exactly.
+- **`--render` deliberately does not write.** Replacing the checked-in manifests changes
+  what `creds-audit` demands at three sites (dc0 would go from CLEAN to red on three
+  expected-but-absent rows). That is the correct end state per D-137, but it is a
+  behaviour change to a live audit and so is operator-gated, not a side effect of a build
+  commit. `creds-audit` has no automated callers today (verified: only prose at
+  `dc-dc-phase3-maas-enlist-deploy.md:498`), so nothing is destabilised by waiting.
+
+**Two false-greens found and closed during the build, both self-inflicted:**
+1. **S2 enumerated only the sites the MATRIX mentions**, so an empty or site-truncated
+   matrix examined no manifest, found nothing undeclared, and reported "both bounds clean".
+   That is precisely the defect `netbox/sandbox-fidelity-check.py:131-143` records in-repo
+   ("an upper bound masquerading as an assertion. It must be BOTH bounds") reproduced one
+   level up. The site set is now the UNION of matrix site-keys and manifest files on disk.
+   Regression-locked by harness T9: an empty matrix now yields 58 findings, not a pass.
+2. The uniqueness key was (site, host-role, filename), which false-failed two DISTINCT
+   identities sharing one file -- the Vault init artifact holds both the unseal shares and
+   the root token. Key now includes `id`. Regression-locked by T6.
+
+**Revert:** delete the script and its harness directory; gauntlet returns to 79.
+
+## Item 4 -- `tests/creds-matrix/run-tests.sh` (24 cases, 24/24)
+
+One case per invariant, each named for the real defect it encodes, asserting rc AND an
+output regex. Includes the metadata-only source grep (T22, mirroring
+`tests/creds-audit/run-tests.sh:90-92`) and **T24, which asserts the real tree stays RED**
+-- a guard against someone making the register green by deleting the rows that fail.
+
+The harness found three genuine bugs in the checker before it shipped: the Row-vs-Row sort
+crash on duplicate rows, a prose "more" tripping the metadata-only guard, and a brittle
+render assertion. All three fixed.
+
+**Revert:** delete `tests/creds-matrix/`.
+
+## Item 5 -- corrected a wrong `sec-ref` before it could be cited as authority
+
+`dc1-edge-api` carried `SEC-015`. Verified against `docs/security-ledger.md`: SEC-015 is
+the **dc1 edge SSH private key transiently staged on the rack** (remediated), not the edge
+API credential -- and dc1's edge API is the one that is CORRECT, so it should carry no SEC
+row at all. Moved SEC-015 onto `dc1-edge-key`, which is its actual subject, and set
+`dc1-edge-api` to `-`. Caught at review; a wrong reference in the register is exactly the
+kind of thing a later session cites as fact.
+
+Also tightened two over-readable claims: S3's `[ok]` line now names what it does NOT
+compare (manifest header prose; non-jumphost rows), and the notes file records that S5's
+inclusion of `mint-stage`/`mint-ref` in the per-DC shape is INTENDED strictness, so a
+future session narrows it with a reason rather than silently.
+
+---
+
+## EXPECTED RED -- the 5 findings are the deliverable, not a defect in it
+
+`python3 scripts/creds-matrix.py` exits 1 with:
+- `S6 IDENTITY CONFLATION: id 'maas-region-admin' serves 2 principal types` -- ruling 5
+  working as designed on the live SEC-020 defect. Clears when the 19 `maas admin` call
+  sites migrate to a service identity.
+- `S2 ... EXPECTED-BUT-ABSENT` x3 (dc0 `opnsense-api.txt`, `vr1-dc0-maas-power_ed25519`,
+  `.pub`) -- SEC-021's declaration half.
+- `S5 ASYMMETRY` on dc0's divergently-named headend power key -- SEC-021's other half.
+
+27 rows carry `mint-ref=operator-terminal`: the research FINDING 1 reproducibility debt,
+reported as a counted `[ok]` debt line rather than a failure, because admitting those rows
+is the point.
+
+Going green is a REMEDIATION project, separate from this build and gated per row.
+
+---
+
+# TIER 2 (EXISTENCE) -- tooling built, live sweep NOT run
+
+## Item 6 -- `creds-manifests/vm-secret-locations` (ruling 3)
+
+The absolute bound on discovery. Includes every class the ruling's faithful-implementation
+note names, plus ONE the note did not: the DOCFIX-175
+plaintext `terraform.tfstate` (a secret-at-rest location with no mint of its own -- the
+matrix already carried the row, and the sweep could not see it until the location was
+declared).
+
+**On the tenant directories, which look contradictory and are not:** ruling 3 says no
+tenant surface is touched, and the list includes the per-tenant dirs. Both hold, because
+those dirs are LOCAL operator-held copies on the jumphost; `ssh-target=local` is
+load-bearing. No tenant VM, project, or tenant-operated host is reachable from this file
+and none may be added. D-069 is preserved by construction, not by good behaviour.
+
+`<repo>` is substituted at runtime from the checker's own location -- the repo has been
+renamed once (D-110) and its name is never hardcoded into a data file.
+
+**Revert:** delete the file; tier 2 then refuses to run (by design, T30).
+
+## Item 7 -- tier-2 EXISTENCE checks in `creds-matrix.py`
+
+E1 expected-but-absent, E2 mode, E3 undeclared-at-a-declared-location. `--remote` is
+opt-in and bounded absolutely by the locations list; probes are `stat` over ssh, metadata
+only, never content.
+
+**Two deliberate design choices:**
+- **An unreachable host SKIPS with an explicit `[ok]`.** Treating "could not look" as
+  "nothing there" is the false-green that would make the whole control worthless. T32.
+- **`--pending-stage` is supplied by the CALLER, not the script.** A credential whose
+  mint stage this rehearsal has not reached must defer rather than fail, but encoding
+  which stages have run would put a status claim in code -- GA-R1 puts status in
+  CURRENT-STATE and nowhere else. T27.
+
+**Divergence from the plan's Files list, flagged for objection:** the plan put `--remote`
+on `creds-audit.sh`. It is implemented in `creds-matrix.py` instead, because tier 2 IS the
+preflight `Pn` and the matrix plus the locations list both live here -- putting it in
+creds-audit would mean two implementations of one bounded walk. `creds-audit.sh` keeps its
+per-site role and got the glob widening, which is an independent defect. Ruling 3 does not
+name a script, only the bound.
+
+## Item 8 -- `creds-audit.sh` sprawl globs widened (SEC-023)
+
+Added `*.pass`, `*.apikey`, `*.key`, `*.pem`, `*_ed25519`, `*_rsa`, `*openrc*`. The
+original six patterns had measured blind spots: they would not have matched `admin.pass`
+(the SEC-020 secret that sat undetected for 12 days), any bare SSH private key or PEM, or
+the `~/admin-openrc` phase-03 is predicted to write at Stage 5. Harness grew 7 -> 13: five
+cases are the blind-spot fixtures, and **T13 asserts the widening did NOT make the check
+trigger-happy** (an ordinary `README.md`/`notes.txt` in the home root is still CLEAN).
+
+**Revert:** restore the six-pattern glob line and drop harness T8-T13.
+
+---
+
+## NOT done in this session (stated so the boundary is unambiguous)
+
+- **The LIVE tier-2 sweep has NOT run.** The tooling exists and is harnessed, but no
+  remote host has been probed, so SEC-021's on-disk half, SEC-022's shadow stores and
+  SEC-023's sprawl are NOT yet reproduced as live findings. The plan's acceptance test is
+  therefore still only partly met. Next gated step.
+- Tier 3 (VALIDITY) -- not built. `--all` names it unbuilt with an explicit `[ok]`.
+- `--render`'s source-field derivation from the locations list -- not wired. Two fields
+  are explicitly skipped as pending, not silently matched.
+- The preflight `Pn` of ruling 1 -- **not wired**, and this is an OPEN QUESTION for the
+  operator, not an omission: wiring it blocking (the default, since it is what was ruled)
+  hard-fails `preflight.sh` until remediation; deferring it until after per-row
+  remediation is the departure and needs an exchange.
+- SEC-009's demotion to a pointer (ruling 4) -- not done; it belongs with tier 2.
+- No manifest was rewritten; no cloud state was touched.
+
+---
+
+## Item 9 -- LIVE tier-2 sweep run (read-only) + two probe false-greens it exposed
+
+Capture: `docs/audit/d137-tier2-sweep-20260726.txt`. Read-only, no sudo, metadata only
+(`stat` over ssh); jumphost local + voffice1 + office1-netbox.
+
+**ACCEPTANCE PROGRESS -- SEC-021's on-disk half is REPRODUCED:**
+`vr1-dc0-maas-power_ed25519{,.pub}` are genuinely ABSENT from the dc0 jumphost creds
+folder. Tier 1 had already caught the declaration gap; the live sweep confirms the
+credential is not merely undeclared, it is not there.
+
+**Two false-greens in my own probe, both found only by running it against real hosts:**
+
+1. **"Absent" vs "could not look."** `/root/maas-secrets` and `/root/netbox-secrets`
+   reported *does not exist* on the first sweep. They exist -- SEC-020 is precisely about
+   `admin.pass` living in the first one. An unprivileged `[ -d ]` on a root-owned parent
+   is indistinguishable from a missing directory, so the probe now checks parent
+   traversability and reports **UNREADABLE**, which is a FAIL rather than a benign skip.
+   A credential audit that reports "nothing there" about a directory it could not open is
+   worse than no audit.
+2. **Role-level aggregation manufactured false absences.** Skipping ONE location for a
+   role still let that role's other locations "cover" it, so every credential living in
+   the unprobed location reported EXPECTED-BUT-ABSENT. Absence is now only asserted over
+   FULLY-probed roles; 14 headend/netbox rows report explicitly as NOT JUDGED. A third
+   refinement followed: `absent` is a conclusive observation and does NOT gate a role,
+   only `unreadable`/`unreachable` do.
+
+Harness grew to 35 (T33 unreadable-location, T34 absent-location).
+
+**STILL OUTSTANDING -- needs an operator-gated privileged read.** The two root-owned
+directories are unread, so SEC-022's shadow-store contents and the SEC-020 region secrets
+are UNCONFIRMED. SEC-023's sprawl half is also unverified live. The remaining command is
+a remote-sudo shape and was NOT run.
+
+## Item 10 -- `--privileged` escalation wired; the run itself is BLOCKED
+
+**What.** `creds-matrix.py --privileged` retries a remote probe with `sudo -n` ONLY where
+the unprivileged probe returned `unreadable`. Escalating just where it is needed keeps the
+privileged surface as small as ruling 3 already keeps the search surface. Still metadata
+only -- `stat`, never content -- and the metadata-only source guard (T22) still passes.
+Verified inert when nothing is unreadable: zero escalations attempted on a clean run.
+
+**Why it did not run.** The operator approved the privileged read. The Claude Code
+AUTO-MODE CLASSIFIER denied the remote-sudo shape (`ssh voffice1 'sudo stat ...'`). This is
+the SAME wall the 2026-07-23 close recorded -- "auto-mode classifier blocks remote sudo
+shapes instead of prompting -- manual mode is the fix". It was NOT worked around; the
+denial message explicitly permits reasonable alternatives, and there is no honest
+alternative here, because reading a root-owned directory is precisely the privilege being
+denied. Any workaround would either fail identically or misrepresent the result.
+
+**Consequence, stated plainly:** SEC-022's shadow-store contents and the SEC-020 region
+secrets are UNCONFIRMED. The sweep reports them as `E0 UNREADABLE` FAILs, which is the
+correct outcome -- an audit that could not look must say so.
+
+**To unblock:** run the session in `manual` permission mode, or add a targeted ask rule for
+the `ssh <host> 'sudo stat ...'` shape. Then re-run with `--tier2 --remote --privileged`.
+
+**Revert:** drop the `--privileged` flag and the escalation branch.
+
+## Item 11 -- permission-rule repair; privileged sweep COMPLETED
+
+**The block was a pattern gap, not a policy conflict.** `Bash(ssh * sudo *)` was ALREADY in
+the project ask list. It needs a literal space before `sudo`; the command was
+`ssh <host> 'sudo ...'`, so the quote meant no rule matched and it fell through to the
+classifier. Added `Bash(ssh *'sudo *)`, `Bash(ssh *"sudo *)`, `Bash(ssh *sudo -n *)` and a
+targeted `Bash(*creds-matrix.py *--privileged*)`. All are **ask**, never **allow** -- the
+operator still approves each run, which is what was asked for.
+
+**FLAGGED, NOT FIXED (hard rule 1):** `Bash(ssh * virsh *)` has the identical latent gap --
+a quoted `ssh <host> 'virsh ...'` will not match it either. Logged for a separate step.
+
+**Measured results** (`docs/audit/d137-tier2-privileged-20260726.txt`):
+- Region secrets dir holds exactly `admin.apikey`, `admin.pass`, `db.pass`,
+  `lxd-trust.pass`, all 0600 -- precisely the SEC-020(i) carve-out list, nothing undeclared.
+- Netbox dir: `admin.pass`, `api.token`, `secret_key`, all 0600.
+- SEC-022 shadow stores confirmed and now audited (dc0: `maas-virsh_ed25519` +
+  `vr1-dc0_svc_ed25519{,.pub}`; dc1: `vr1-dc1_svc_ed25519` only).
+- **ZERO undeclared files at any declared location** -- SEC-020 and SEC-022 accounted for.
+
+**OWNED -- six inferred filenames.** The first matrix draft carried plausible-looking names
+I authored rather than measured: `maas-cli-profile`, `maas-enroll-secret`,
+`netbox-secret-key`, `netbox-admin-password`, `juju-credentials`, `maas-snap-power-key`.
+That is a hard-rule-2 miss (no inferred value enters an artifact). The checker's own
+undeclared-detection caught every one on first contact with real hosts, which is the
+register working as designed but is not a substitute for measuring first. Corrected to
+measured values, with their real locations added to the declared list and five colocated
+non-secret artifacts declared so undeclared detection stays meaningful. Matrix 72 -> 77.
+
+**9 findings remain, all TRUE:** SEC-021 (3x declaration + 2x on-disk), the ruling-5
+conflation, and 3x S5 asymmetry -- dc0's snap power key is the generic `id_ed25519` while
+dc1's is the dedicated `id_dc1_power`, i.e. the SEC-012/SEC-016 per-DC-isolation divergence
+made machine-visible.
+
+## Item 12 -- `ssh * virsh *` pattern gap closed (the flagged twin of item 11)
+
+Operator-directed follow-up to the item-11 finding. `Bash(ssh * virsh *)` had the identical
+defect: it requires a literal space before `virsh`, so a quoted remote command
+(`ssh <host> 'virsh list --all'`) matched NO rule and fell through to the classifier.
+Added `Bash(ssh *'virsh *)` and `Bash(ssh *"virsh *)`.
+
+Verified by matching the real command shapes against the parsed rule list: single-quoted,
+double-quoted and bare forms now all resolve to an ask rule, `ssh <host> 'sudo virsh ...'`
+resolves via the sudo rule, and an unrelated `ssh <host> 'ls -la'` still matches nothing --
+the widening did not become a catch-all.
+
+**Revert:** drop the two rules from `.claude/settings.json`.
+
+## Item 13 -- COMMITTEE AUDIT (6 lenses) + phase 1: record corrections
+
+Operator-directed six-lens read-only review (correctness, coverage, claim-verification,
+ruling-fidelity, record-integrity, Roosevelt-transfer). Every defect was REPRODUCED by the
+lens that raised it; FOUR lenses converged independently on the site-blindness defect.
+Full defect list and remediation status: `docs/CURRENT-STATE.md` (GA-R1).
+
+**Record corrections landed in this commit:**
+- `docs/audit/d137-location-listing-20260726.txt` NEW -- the actual `stat` listing for every
+  declared location. CURRENT-STATE previously asserted remote filenames and modes citing
+  the tier-2 capture, which is a checker VERDICT file containing none of them: a GA-R1
+  rule 2 defect (measurements quoted from session output, not from a capture).
+- **`.maas.cli` was never measured** and is WRONG. Measured this session: the MAAS snap CLI
+  stores its profile at `~/snap/maas/current/.maascli.db` (0600). It sat inside the fix for
+  the inferred-filename miss, which is why the corrected count is ~21, not six.
+- CURRENT-STATE's `virsh`-not-fixed sentence corrected (it was fixed in `6d43619`, and the
+  commit that fixed it did not touch the status authority -- L10's trigger set does not
+  include `.claude/settings.json`, so lint passed clean).
+- The **"ZERO undeclared files ... fully accounted for" claim is WITHDRAWN** -- it rested on
+  the site-blind check.
+- **"SEC-021's on-disk half REPRODUCED" corrected** to the power-key artifacts only;
+  `opnsense-api.txt`'s on-disk absence was masked.
+- Superseding figures recorded (77 rows / 35/35 / 13/13 / gauntlet 80); the stale
+  "14 rows NOT JUDGED" corrected to 2; the glob is `*.pass`, not `admin.pass`.
+- **12-column amendment recorded on D-137** in `design-decisions.md` -- it previously existed
+  only in this changelog (non-citable, GA-R2 rule 1) and the build spec.
+- Citations broken by my own edits repaired: the metadata-only guard moved 71-73 -> 90-92
+  when the sprawl globs were widened.
+- Plan's "12 operator-terminal rows" reconciled to the delivered 27.
+- Changelog item 6's "two the ruling's note did not name" corrected to ONE (the ruling DOES
+  name the PKI overlay).
+- `n-juju-user-nopassword`'s "BY RULING (2026-07-25)" replaced -- no such ruling exists;
+  SEC-018/-019 record it as fact on 2026-07-24.
+
+**Revert:** `git revert` this commit; records return to the pre-audit (overstated) state.
+
+## Item 14 -- phase 2: the eight confirmed false-greens, fixed and regression-locked
+
+Every fix below closes a defect the committee REPRODUCED. Harness 35 -> 43 cases
+(`tests/creds-matrix`), creds-audit 13 -> 15. Gauntlet ALL GREEN (80), repo-lint 0-fail.
+
+1. **Tier 2 is now scoped by (host-role, SITE-KEY), not host-role alone.**
+   `vm-secret-locations` gains a `site-key` column. Keying on role merged all three
+   jumphost creds folders into one basename namespace, so a credential present at ANY site
+   satisfied the row for EVERY site -- which is how SEC-021's dc0 `opnsense-api.txt`
+   absence passed a green sweep while tier 1 flagged it. E3 was weakened symmetrically.
+   Regression: **T36**, the fixture shape the old test set could not express (every tier-2
+   fixture declared exactly ONE location per role).
+2. **`probe_remote` no longer reports UNREACHABLE for a location it read.** A loop that
+   simply matched nothing exited non-zero with empty output and was called unreachable,
+   which gated the whole role and converted every absence FAIL there into an `[ok]`. Now a
+   `__DONE__` liveness marker proves the command ran, so "found nothing" is an observation
+   and only its absence means the host was not reached.
+3. **Literal-file locations get absent/unreadable detection.** `_dir_of` returned `None`
+   for any non-`/*` path, so four live rows skipped the state machine entirely and an
+   unreadable directory read as "fully probed, nothing there" -- the same false green T33
+   was written to kill, surviving in the other path form. Regression: **T41**.
+4. **An EMPTY locations list now refuses** like a missing one; ruling 3's bound is
+   absolute. Regression: **T37**.
+5. **Non-empty floor**: a zero-row matrix asserted nothing yet reported clean over the
+   empty set. Regression: **T38**.
+6. **Crash path closed**: a mint-ref pointing at a directory raised `IsADirectoryError`,
+   exiting 1 -- indistinguishable from findings -- and S5/S6/S7 never ran, so the real
+   tree's conflation and asymmetry findings silently vanished from a run that still looked
+   normally red.
+7. **Mode enforcement no longer custody-gated.** Exact-match still applies to
+   `consolidated`; a new WORLD-READABLE check applies to every secret row at any custody
+   (`.pub` halves excluded -- public by design). This covered 43 of 77 rows, including the
+   SEC-020 region dir and SEC-022 shadow stores. Regression: **T39**.
+8. **S5's second direction is tested.** T13 only ever populated the dc0 side, so deleting
+   the dc1->dc0 comparison left the harness green -- an upper bound masquerading as an
+   assertion, in the check whose entire job is symmetry. Regression: **T40**.
+
+**Also:** rows whose (role, site) has no declared location are now DISCLOSED as
+`E4 UNCHECKABLE` instead of `continue`-ing silently (T43); malformed manifest lines are no
+longer dropped, which had disabled the undeclared bound for them; declared paths and ssh
+targets are charset-validated and shell-quoted -- an unvalidated `;` reached a remote shell
+and, under `--privileged`, `sudo -n` (T42); and the `creds-audit` sprawl globs now cover
+DOTFILES, because the previous widening still could not see `.admin.pass`, the dotfile
+sibling of the very secret it cites as motivation (SEC-009's founding case was a dotfile).
+
+**T24 REPLACED with a checked-in finding-CLASS baseline**
+(`tests/creds-matrix/expected-findings.txt` + `classify-findings.py`). The old form
+grepped for the literal `IDENTITY CONFLATION`, so remediating that defect -- the fix the
+plan, the notes and the changelog all prescribe -- would have deleted the string and turned
+the GAUNTLET red for whoever did the right thing, making "edit the test" the cheapest
+response at exactly the moment the guard mattered. Remediation now requires updating the
+baseline in the same commit: a recorded decision instead of a mystery breakage. Verified
+in both directions (removing a class from the baseline fails the test).
+
+**Revert:** `git revert` this commit; the checker returns to role-keyed tier 2 and the
+harness to 35 cases.
+
+## Item 15 -- phase 3: re-measure the register; SEC-024 opened
+
+**~21 inferred filenames corrected against their own mint-refs** (the session had owned
+six; those were only the rows the first sweep physically touched):
+- **octavia, 8 rows** -> `passphrase.txt` x2, `issuing-ca.key.enc`, `issuing-ca.cert.pem`,
+  `controller-ca.key.enc`, `controller-ca.cert.pem`, `controller.key`,
+  `controller.bundle.pem`; and the declared location split into the THREE SUBDIRECTORIES
+  `phase-01-bundle-deploy.md:288` creates -- the bare `~/octavia-pki/*` pattern matched
+  ZERO of the 8 artifacts, including two CA private keys that ruling 3 names as mandatory.
+- **vault, 2 rows** -> `init.txt` (the previous value was the DIRECTORY name).
+- **tenant, 5 rows** -> `<client>-` instance prefix, with a placeholder matcher added
+  (T44) so per-tenant rows can match a real basename at all.
+- `kube-config` -> `config`; `.maas.cli` -> `.maascli.db` (measured: `~/.maas.cli` does
+  not exist; the MAAS snap CLI stores its profile in a SQLite DB under the snap's
+  per-revision `current` symlink -- the same fragility class as the power keys).
+
+**`sec-ref` mis-attribution corrected** -- both `juju-maas-user` rows cited SEC-020
+(region superuser passwords); the on-subject rows are SEC-018/-019. The tfstate row's
+SEC-009 removed (that row is DOCFIX-175). This is the SEC-015 class recurring: one
+instance was fixed by hand in item 5 without checking whether it was systemic. It was.
+
+**`mint-ref` corrected** -- `admin.pass` cited `:452`, a CONSUMER; the mint is `:450`
+(`newpass`). The RGW system key cited a line that *takes it as input* ("never invent it"),
+so it is `operator-terminal` -- which means the reproducibility-debt count was an
+undercount. `opnsense-bootstrap-apikey.sh:89` is a variable assignment; the mint is `:115`.
+
+**Rows added:** the libvirt SSH power password (read from a human into MAAS `power_pass`,
+with a STANDING rotation obligation from a 2026-06-26 plaintext exposure -- it was in
+neither the matrix nor the exclusions), `vault-ca-root`, and the two tfstate siblings.
+`~/as-executed/` deliberately NOT declared, with the reason recorded in the locations file:
+it holds session LOGS, so declaring it made every log a false UNDECLARED; its risk is
+transcript CONTENT, which the PreToolUse guard covers and this register does not model.
+
+**Four further defects in my own phase-2 changes, found by running the sweep** (not by
+reasoning about it): `shlex.quote` on the probe directory broke `~` expansion, so every
+home-relative remote location read as unreadable; a parent that does not EXIST was
+reported unreadable rather than absent; a location with `site-key = -` needed SHARED
+semantics (the MAAS snap ssh dir legitimately holds both DCs' keys) or its contents read
+as undeclared; and the tfstate siblings needed rows, not just a location.
+
+**SEC-024 OPENED -- a new exposure the fixed checker found on its first clean run:**
+`opentofu/terraform.tfstate.backup` is mode **0664** and carries the MAAS API key in
+plaintext (DOCFIX-175); the live state file is 0600. Invisible to every prior control
+because the world-readable check was custody-gated and the siblings were undeclared.
+**Logged, NOT actioned** (hard rule 1): the `chmod` and the retain-or-delete decision are
+mutations outside this step.
+
+Findings 35 -> **13, all true**. Matrix 81 rows. Harness 44/44, creds-audit 15/15,
+gauntlet ALL GREEN (80), repo-lint 0-fail.
+
+**Revert:** `git revert` this commit; the register returns to the inferred filenames and
+SEC-024 closes as unrecorded (the exposure remains, unseen).
+
+## Item 16 -- D-137 ruling 1 EXECUTED: tier 1 wired as the blocking preflight P5
+
+Operator-directed, resolving the open sequencing question. Question as presented: wire the
+blocking `Pn` as ruled, or defer until after per-row remediation. Operator answer, exact
+utterance: **"wire tier 1 as the blocking preflight Pn"**, 2026-07-26. Recorded on D-137 in
+`design-decisions.md`; status in CURRENT-STATE.
+
+**What landed.** `scripts/preflight.sh` gains **P5: credential matrix (D-137 tier 1)**,
+running `python3 scripts/creds-matrix.py` with `note $?` worst-exit aggregation, placed
+ahead of the stage-2 reminders block (now P6) so its verdict participates in the deploy
+decision rather than trailing it. Tier 1 only: it is offline and its findings ARE the three
+ruled failure classes. Tier 2 stays out -- it needs `--remote`, `--privileged` and a
+caller-supplied `--pending-stage`, none of which belong in an unattended gate.
+
+**A fail-open in my own wiring, caught by the new test.** A missing `creds-matrix.py` makes
+`python3` exit 2, which `note` maps to WARN -- so DELETING the gate would have downgraded
+it to a warning instead of stopping the deploy. P4 already guarded this class; P5 did not
+until T9 failed. Now guarded explicitly.
+
+**Harness `tests/preflight` 7 -> 10 cases:** T8 a red register FAILS the deploy (blocking,
+not advisory -- advisory was the posture that demonstrably failed); T9 the gate FAILS
+CLOSED when its checker is absent; T10 the gate runs BEFORE the reminders block. `mkfix`
+gained a fifth parameter so the checker's exit code is controllable and its absence
+testable.
+
+**CONSEQUENCE, stated precisely so it is not overclaimed:** `preflight.sh` exits 1 with P5
+among the reasons -- but **preflight was ALREADY exiting 1 before this change** (P4:
+`overlays/octavia-pki.yaml` absent, 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 it closes
+no deploy path that was open. Verified by stashing the change and re-running.
+
+Gauntlet ALL GREEN (80), repo-lint 0-fail.
+
+**Revert:** drop the P5 block from `scripts/preflight.sh` (renaming P6 back to P5) and
+harness cases T8-T10; the ruling then reverts to ruled-but-unenforced.
+
+## Item 17 -- D-137 ruling 4 EXECUTED: SEC-009 demoted to a pointer
+
+Ruling 4 was already RULED ("D-137 is the authority"); its stated trigger -- tier 2 built --
+had passed, so this is execution, not a decision. No operator exchange needed.
+
+**Moved.** The standing consolidation rule left `docs/security-ledger.md` for
+`docs/design-decisions.md` D-137, restated as six numbered points and updated to D-137's
+own mechanisms (the matrix is the register; manifests are DERIVED; discovery is bounded by
+`vm-secret-locations`; one identity one principal; enforcement is the blocking P5 gate).
+The ledger keeps a POINTER and returns to being purely an exposure/rotation register --
+which is what lets a gate cite a D-number instead of an exposure row.
+
+**Kept as history, deliberately.** SEC-009's founding addendum -- the sandbox NetBox token
+that lived only on the VM and went un-consolidated until it was needed -- stays in the
+ledger. That miss is what established the convention, and history is what the register is
+for. The 2026-07-15 ENFORCEMENT paragraph is relabelled HISTORY and says plainly what
+superseded it.
+
+**Carried forward WITH CORRECTIONS, not verbatim.** The moved text asserted "11 entries"
+and a "7/7" harness and described manifests as hand-declared. All three were stale by
+2026-07-26; they are not reproduced. The rehearsal-scoped posture it recorded (real
+hardening deferred to post-teardown cycles, consolidation now) still holds and is kept.
+
+**Callers repointed in the same commit** -- a demotion that leaves callers citing the moved
+text is not done:
+- `runbooks/dc-dc-phase3-maas-enlist-deploy.md:491` is the ONLY credential definition-of-done
+  in any runbook, and it instructed operators to **hand-edit `creds-manifests/$DC.manifest`**
+  -- which sub-ruling 2 makes a GENERATED artifact, so the live runbook was teaching the
+  anti-pattern. It now directs a `creds-matrix.tsv` row plus, where a new place secrets live
+  is introduced, a `vm-secret-locations` row; and its close-out now requires BOTH
+  `creds-audit` CLEAN and no new `creds-matrix` finding class for that DC.
+- `docs/vr1-office1-as-built.md` restated the convention; now a pointer. An as-built
+  document records this site's credential LOCATIONS, which is a fact, not policy.
+
+Gauntlet ALL GREEN (80), repo-lint 0-fail.
+
+**Revert:** `git revert` this commit; the rule text returns to the ledger and D-137 stops
+being the policy authority in practice while remaining so on paper.
+
+## Item 18 -- tier 3 (VALIDITY) BUILT: cross-copy sha256 provenance
+
+Closes the gap the plan names: `creds-audit` PARSES declared provenance and NEVER verifies
+it, so SEC-020's stale-trap warning -- *"any future rotation MUST update both copies in one
+operation or the region copy becomes a stale trap"* -- has been unchecked prose since it was
+written, and the sha256 equality behind it was a ONE-TIME manual act on 2026-07-25.
+
+**Mechanism.** `--tier3` (with `--tier2`, which supplies the probe results) compares
+cross-copy digests. `sha256sum` is invoked as an EXTERNAL command on both sides so that only
+a 64-hex digest ever enters the checker process -- reading bytes into Python to hash them
+would satisfy the letter of "never transfer content" and not the spirit. Privileged
+escalation reuses the tier-2 pattern: retried only where an unprivileged digest fails.
+
+**RESULT (capture `docs/audit/d137-tier3-provenance-20260726.txt`): 4 groups compared, ALL
+byte-identical, including the SEC-020 pair** (`maas-region-admin` -- region source-of-record
+vs jumphost copy). That equality is now machine-verified instead of remembered. The `[ok]`
+line NAMES the verified groups: "4 compared" is not an audit trail, and a reader must be
+able to see the motivating case was not silently skipped.
+
+**TWO FALSE POSITIVES IN MY OWN FIRST DRAFT, caught by verifying before reporting.** The
+draft keyed digests by `(role, site)`, so an identity's DISTINCT artifacts at one scope
+(`admin.pass`, `admin.apikey`, `.maascli.db`) overwrote each other and it compared unrelated
+files -- reporting drift on `maas-region-admin` and `dc1-svc-key`. Manual `sha256sum`
+comparison showed both were IDENTICAL. Had I reported that output as-is, it would have
+raised a false credential-rotation alarm on the SEC-020 pair.
+
+Root cause was a schema gap, not just a coding error: nothing expressed WHICH rows are
+byte-copies of each other. Two things are not byte-comparable and were being compared:
+distinct artifacts of one identity, and the same credential in a different SERIALIZATION
+(the netbox token is raw on the VM, an assembled env file on the jumphost).
+
+**`custody` gains a fifth token, `verbatim-copy` [OPS]** -- "this row is a byte-identical
+copy of this id's source-of-record". V1 now compares ONLY (a) rows sharing (id, filename)
+across scopes and (b) a `source-of-record` row against its declared `verbatim-copy` rows,
+which is SEC-020's exact shape. Anything else is skipped with a reason: a pair we cannot
+justify comparing is not a pair we may report drift on. `verbatim-copy` is manifest-bearing
+(`IN_FOLDER`) -- the file still lives in the creds folder; the token adds a byte-identity
+assertion, it does not move anything.
+
+**Harness 44 -> 52.** T45 identical copies verify; T46 a rotated-one-copy pair is caught
+(the SEC-020 trap); **T47 and T48 regression-lock the two false positives above**; T49 a
+declared verbatim copy under a different name IS compared, so SEC-020's case cannot fall
+into T48's skip; T50 tier 3 self-announces when not run; T51 asserts the digest path uses
+`sha256sum` and that no content-TRANSFER verb (`scp`/`rsync`/`base64`/`dd`) exists anywhere
+in the checker -- extending T22, which would not have caught a transfer added alongside a
+legitimate digest call.
+
+Gauntlet ALL GREEN (80), repo-lint 0-fail, finding-class baseline UNCHANGED.
+
+**NOT built:** tier 3's per-row BEHAVIOURAL probes (does the credential still authenticate).
+Only provenance equality is implemented; liveness, expiry and revocation state remain
+unverified, as does grant/scope drift.
+
+**Revert:** `git revert` this commit; drop `--tier3`, the `verbatim-copy` token, and T45-T51.
+
+## Item 19 -- session-ledger rotated (GA-R4 rule 3 / amendment F1)
+
+The live ledger was **413 lines against GA-R4's 300-line cap** -- a breach the 2026-07-25
+close recorded as OWED and did not perform.
+
+**Rotated oldest-first, as F1 specifies** ("after writing the close summary, rotate oldest
+closed-session summaries until under cap"): the eight summaries from 2026-07-18 through the
+fifth 2026-07-21 session moved VERBATIM to
+`docs/archive/session-ledger-rotated-20260726.md`. Sessions from 2026-07-22 onward stay
+live. **413 -> 280 lines.** Nothing is lost: 8 summaries moved + 8 remain = the 16 that were
+there, each rotated summary still points at its own archived full body, and only summaries
+moved. Precedent `docs/archive/session-ledger-rotated-20260719.md` was the one-time rule-6
+rotation; this is the first routine F1 one.
+
+**Timing, stated plainly:** F1 binds the cap AT SESSION CLOSE. This was done mid-session at
+operator direction, which is early rather than late. Rule 3's protection -- an open
+session's in-flight section is never rotated -- is not implicated: this session has no
+in-flight section in the ledger.
+
+**Machine-derived block re-seeded** from a fresh `ledger-scan` (it is machine-owned; the
+fences are intact). It had gone stale: open SEC rows **19 -> 20** (SEC-024), next-free D
+**137 -> 138**.
+
+**A status CLAIM corrected to narrative.** GA-R4 rule 5: the ledger records session
+narrative, status is CURRENT-STATE's alone, and a ledger line touching status is a pointer,
+never a claim. The 2026-07-26 addendum asserted D-137 implementation was "UNBLOCKED, not
+started" and directed a fresh session to build it -- both falsified by this same session's
+work hours later. Now marked superseded and repointed at CURRENT-STATE, with the original
+kept as the record of where that session stood.
+
+The 07-25 close's "rotation OWED" line is marked DISCHARGED in place.
+
+Gauntlet ALL GREEN (80), repo-lint 0-fail, `ledger-scan` exit 0.
+
+**Revert:** `git revert` this commit; the eight summaries return inline and the cap is
+breached again.
+
+## Item 20 -- SEC-024 remediated (mode); severity corrected; retention deferred
+
+**Severity corrected BEFORE the fix.** The row as I opened it said "group- and
+world-readable". Measuring the path showed `opentofu/` is 0700 and `~` is 0750, so no other
+account could traverse to the file -- and neither it nor the snapshots are git-tracked, so
+SEC-004's public-repo angle was never implicated. It was a DEFENCE-IN-DEPTH defect, not a
+live exposure. Corrected in its own commit before any remediation, because a ledger row
+that overstates an exposure is its own defect.
+
+**Operator-approved mutation, executed and read-back verified.** `chmod 600` on
+`terraform.tfstate.backup` and `terraform.tfstate.pre-G16-20260721`. All four state files
+now 0600 (matching the live `terraform.tfstate` and `pre-G6`), and the checker's
+`E2 WORLD-READABLE` finding cleared.
+
+**Retention DEFERRED by ruling, not forgotten.** Question put: keep the two `pre-*`
+state-surgery snapshots, delete them, keep permanently, or move them out of the clone.
+Operator selected "Keep, decide at stage close" -- both gates (G6, G16) are CLOSED and the
+outer plan has converged to zero diff repeatedly since, but deletion is irreversible with no
+other copy of that state, so it belongs in the close-out review.
+
+**Two things deliberately NOT done:** the umask CAUSE was out of the ruled scope, so a
+future `tofu apply` may write 0664 again -- the P5 gate will catch it, which is the system
+working rather than a gap. And the underlying issue that the key reaches state files in
+plaintext at all is DOCFIX-175, with rotation owed under SEC-018/-019; neither is closed by
+this.
+
+**Caveat recorded in `creds-matrix-notes.md`:** E2 reports file MODE, not reachability.
+That is the right default for a gate -- directory modes change and a `cp -p` escapes them --
+but whoever writes up an E2 finding owes a reachability check before using the word
+"exposed". This defect is exactly why.
+
+**Revert:** `chmod 664` on the two files (restores the defect) and reopen the row.
+
+## Item 21 -- tier 2 gate shape RULED + wired; --pending-stage replaced by a coupled projection
+
+Two operator decisions, both taking the recommendation.
+
+**Q1: how to gate tier 2.** Selected: **local-only blocking; remote operator-run.**
+`preflight.sh` P5 now runs `creds-matrix.py --tier2` -- tier 1 STATIC plus tier 2 LOCAL,
+which is HERMETIC: no ssh, no sudo, no reachability coupling. It already catches SEC-021's
+three dc0 on-disk absences without leaving the jumphost, so the local half is not a token
+subset. The REMOTE half stays an operator-run check at DC-standup close and stage close.
+
+Reasoning, recorded because it will be re-litigated: wiring `--remote --privileged` into the
+deploy gate would let an unrelated host outage, a NOPASSWD change, or a MAAS snap refresh
+(already recorded as fragile across refreshes) turn the deploy gate red for reasons that are
+not about credentials. A gate that fails environmentally is a gate people learn to bypass,
+and a bypassed credential gate is worse than none because it still looks like coverage.
+This repo already made the same call once: `run-tests-all.sh:7-8` -- "Deliberately NOT
+folded into preflight.sh ... different cadence." And preflight already demonstrates the
+failure mode: P4 currently reads `FAIL: MAAS unreachable` because it runs on vcloud while
+MAAS lives on the headend (D-128).
+
+**Q2: how to supply the stage input.** Selected: **declared file + lint coupling.**
+`--pending-stage` is REPLACED by `creds-manifests/stages-reached`. A gate whose verdict
+depends on a hand-typed parameter can be widened silently -- and GA-R1 puts status in
+CURRENT-STATE and nowhere else, so the declaration is a machine-readable PROJECTION of it,
+not a second authority. New **repo-lint L12** couples the two on the L10 pattern: editing
+the projection without CURRENT-STATE in the same change set FAILS, because a drifted
+projection makes the gate DEFER REAL ABSENCES, which is a false green.
+
+**EXHAUSTIVE BY CONSTRUCTION, both bounds.** An unclassified mint-stage is a hard FAIL and
+a classified-but-unused one is a stale-declaration FAIL. Neither default is safe:
+assume-reached floods the run with false absences, assume-pending silently defers real ones.
+That check earned itself immediately -- it caught `stage4`, which I had classified as
+reached: Stage 4 is OPEN and executing but **mints no credential**, so no matrix row carries
+the token and it did not belong in the file.
+
+**A self-inflicted break, caught by the existing harness.** I first folded L12 into L10's
+message, renaming its prefix to `L10/L12` -- which broke five repo-lint cases that grep the
+established `L10` id. Reverted: L10 keeps its message, L12 is its own check with its own id.
+New rules get their own messages; they do not rebrand old ones.
+
+Harnesses: creds-matrix 52 -> **56** (T52 refuses without a declaration, T53/T54 the two
+exhaustiveness bounds, T55 the same absent credential defers under `pending` and FAILS under
+`reached`); repo-lint 45 -> **47** (T45 L12 fires alone, T46 does not fire when the authority
+moves with it); preflight 10. The per-fixture stage declaration is DERIVED from each
+fixture's own matrix -- a fixed default cannot satisfy an exhaustiveness check in both
+directions.
+
+Gauntlet ALL GREEN (80), repo-lint 0-fail, tier-1 finding-class baseline unchanged.
+
+**Revert:** point P5 back at bare `creds-matrix.py`, drop L12 and `stages-reached`, restore
+`--pending-stage`.
+
+## Item 22 -- tier 3 behavioural half BUILT (boundary + cadence operator-ruled)
+
+Operator selected **"Full -- including OpenStack service credentials"** and **"Stage close
++ DC standup close"**. I had recommended the passive-only boundary and flagged the costs
+(audit-record side effects, lockout risk, liveness being a time-of-check snapshot); the
+operator ruled otherwise and the full scope is built.
+
+**V2 (passive, zero authentication) fires today on a real defect.** A credential whose SEC
+row declares it BURNED/REVOKED/COMPROMISED must not also be registered as a healthy
+consolidated copy. SEC-006 has recorded the NetBox upstream token as BURNED -- "must be
+revoked + reissued, not merely rotated" -- since 2026-07-12, while the matrix carried it as
+an ordinary `consolidated` row. Nothing reconciled those two surfaces. Keyword matching on
+ledger prose is fragile, so it is deliberately conservative: a small explicit word set, and
+every hit REPORTS the matched text so a human can check the basis rather than trust it.
+
+**`scripts/creds-probe.sh` is a SEPARATE script, deliberately.** A behavioural probe must
+USE a credential, and `creds-matrix.py` is metadata-only by an ENFORCED invariant (T22 bans
+content-reading verbs, T51 bans content-transfer verbs). Folding probes in would have meant
+relaxing that guard, and a guard relaxed once stays relaxed. The credential-using component
+is therefore small, separate, and auditable on its own terms -- and it still never prints a
+secret.
+
+**Safety properties, each with a reason:** never retry a failed authentication (retry loops
+are what lock accounts, and the MAAS `admin` identity backs 19 automation call sites);
+never argv; never echo; stage-aware (a `pending` credential SKIPS, it does not fail, or
+every stage-5 OpenStack credential would read as broken); and **per-tenant credentials are
+REFUSED BY CONSTRUCTION** -- a declaration cannot opt them back in, because probing one
+means authenticating AS a tenant (D-069, ruling 3). NOT a deploy gate, for the same reason
+tier 2's remote half is not.
+
+**A false green in my own first real run.** `ssh` inside a `while read` loop consumed the
+loop's stdin: probe 1 ran, probes 2-13 were silently skipped, and the run exited **0**. A
+partial run reporting clean is precisely the failure class this tool exists to catch, in
+the tool itself. Fixed with `ssh -n` plus a redirect, and locked by a TOTAL ACCOUNTING check
+-- every declared probe must land in exactly one bucket or the run is declared VOID.
+Regression-locked as T5; T8 asserts the `-n` that is easy to drop when editing the command.
+
+Declared coverage is 13 probes: 3 active today (one ssh key, two unauthenticated endpoint
+checks that prove the service answers WITHOUT spending the credential), 10 skipped -- 4 as
+stage-pending, 6 as `declared-only` with the reason recorded in the file so the decision is
+visible rather than an omission. OpenStack service credentials are declared NOW and will
+skip until Stage 5 lands, so the coverage exists the moment the stage runs.
+
+Harness `tests/creds-probe` **9/9** (gauntlet 80 -> **81**); phase-3 DC-standup DoD wired.
+
+**Revert:** delete `scripts/creds-probe.sh`, `creds-manifests/probes`, `tests/creds-probe/`,
+and the V2 block; drop the DoD paragraph.
diff --git a/docs/archive/changelogs/changelog-20260727-creds-consolidation.md b/docs/archive/changelogs/changelog-20260727-creds-consolidation.md
new file mode 100644
index 0000000..eafa31a
--- /dev/null
+++ b/docs/archive/changelogs/changelog-20260727-creds-consolidation.md
@@ -0,0 +1,499 @@
+# changelog 2026-07-27 -- credential consolidation batch (SEC-021(b), SEC-025, V2 deferral)
+
+Session changelog (ONE per session, GA-R2/D1). Status claims live ONLY in
+`docs/CURRENT-STATE.md`; this file records WHAT changed, WHY, and HOW TO REVERT.
+
+Branch `dc-dc-stage4-phase3-maas-deploy`. Stage 4 stays OPEN; no gate closed.
+
+Operator question that opened the work (2026-07-27): "Check and confirm that we have a
+consolidated set of login creds on vcloud for all accounts currently created. Are there any
+creds that should be in place that are missing, need to be created, or have not been moved
+into their vcloud folders?" Operator direction after the audit: "clear the whole
+consolidation batch first" -- i.e. the consolidation items, NOT the dc0 edge-API re-mint,
+which was presented as a separate live-mutation item and is deliberately NOT done here.
+
+---
+
+## 1. Audit capture (read-only)
+
+`docs/audit/creds-consolidation-audit-20260727.txt` -- the full three-site sweep, metadata
+only, no credential value read anywhere. Sections: live MAAS account enumeration,
+`creds-audit` x3, both jumphost and headend folder listings, the full
+`creds-matrix.py --tier2 --tier3 --remote --privileged` run, the cardinality/per-site
+blind-spot evidence, the human-principal row set, and the host-role declaration gap.
+
+**The finding that drove everything else:** `creds-audit` read CLEAN on all three sites
+while the matrix returned 13 findings, and the two most consequential gaps were in NEITHER
+surface -- they were found by enumerating the accounts that ACTUALLY EXIST. The register
+cannot report the absence of a credential it has no row for. `creds-audit` CLEAN remains
+not-evidence-of-completeness.
+
+Revert: delete the capture file (it is a record, nothing depends on it).
+
+## 2. dc1 svc public key backfilled to the headend store
+
+`voffice1:~/vr1-dc1-creds/vr1-dc1_svc_ed25519.pub` placed (0644), sha256-verified identical
+to the vcloud copy. Clears one `E1 EXPECTED-BUT-ABSENT` (SEC-022). Public-key material only.
+dc0's shadow store already held both halves; dc1's held only the private -- the mirror image
+of the dc0 gap in item 3.
+
+Revert: `ssh voffice1 'rm ~/vr1-dc1-creds/vr1-dc1_svc_ed25519.pub'`.
+
+## 3. dc0 MAAS->libvirt power key consolidated to vcloud (SEC-021(b))
+
+`~/vr1-dc0-creds/vr1-dc0-maas-power_ed25519` (0600) + `.pub` (0644), plus two rows in
+`creds-manifests/vr1-dc0.manifest`. This is SEC-021(b) executed as written: "dc0's key
+should gain a jumphost copy + manifest row". Clears `S2` x2 and `E1` x2.
+
+MEASURED before acting, because the naming looked like a defect and was not:
+
+- The headend's `maas-virsh_ed25519` and the region MAAS snap's `id_ed25519` are the SAME
+  key (fingerprint `SHA256:Dt/YXTXSF4nXGj9cz8f0owL+qreVpMYBVm/igW10FXY`).
+- It IS the dedicated SEC-012 key, not a reuse: the dc0 SERVICE key is a different key
+  (`SHA256:DBkeStCyf2qGi3SYuvN6hQ+EsepmhpkN9oulLz09uAs`), which is exactly what SEC-012's
+  ruling ("Dedicated MAAS->libvirt key" over reusing the dc0 service key) requires.
+- dc0 having NO per-host block in the snap's `ssh config` (so it uses the default identity)
+  is the RULED design, not drift -- SEC-016 states it: "Host 172.31.0.6 -> that
+  IdentityFile, so 172.31.0.2/dc0 keeps SEC-012".
+
+So NO re-mint was performed and no live power path was touched. The private half was copied
+from the voffice1 shadow store, sha256-verified byte-identical at both ends. The public half
+had never existed anywhere and was DERIVED with `ssh-keygen -y`, its fingerprint verified
+equal to the snap's installed key.
+
+Two things deliberately NOT done, both recorded rather than fixed:
+- The key's INTERNAL comment still reads `maas-virsh-pod (D-123 amendment)` -- it was minted
+  for the qemu+ssh pod attempt that was refuted the same day, and the per-machine
+  `power_type=virsh` ruling correctly retained it. Rewriting a comment alters key material;
+  the file name is now authoritative and the manifest comment carries the explanation.
+- Manifest `source` reads `local` to stay consistent with `--render` (which derives it and
+  would otherwise raise an S3 drift FAIL); the true provenance is in the manifest comment,
+  which S3 explicitly treats as out of scope. Writing `voffice1:<path>` there would have
+  traded one finding for another, and writing a custody change would have created two NEW
+  S5 asymmetries, since S5 compares `custody`.
+
+Revert: `rm ~/vr1-dc0-creds/vr1-dc0-maas-power_ed25519{,.pub}` and drop the two rows +
+comment block from `creds-manifests/vr1-dc0.manifest`. The headend and snap copies were
+never modified, so power control is unaffected either way.
+
+## 4. NetBox web-GUI admin password consolidated (SEC-025 OPENED)
+
+`~/vr1-office1-creds/netbox-admin-password` (0600), byte-identical to
+`office1-netbox:/root/netbox-secrets/admin.pass` (sha256-verified both ends, 28 bytes, value
+never printed or echoed). Register changes: the `netbox-admin` netbox row custody
+`off-manifest-known` -> `source-of-record`; a NEW jumphost row with custody `verbatim-copy`
+(so tier-3 V1 now asserts the two copies stay byte-identical); a manifest row; an extended
+`n-netbox-vm-secrets` note.
+
+This was a HUMAN GUI login that had never left the VM it was minted on -- the third instance
+of one miss class (SEC-009's `api.token`, SEC-020's `admin.pass`, now this). It produced no
+finding before this session because `off-manifest-known` asserts nothing about the jumphost.
+
+SEC-025 is opened for the exposure the remediation CREATES (a plaintext human password at
+rest on the jumphost), not for the gap it closed -- the same shape as SEC-007 and SEC-020,
+with the same rotation obligation and the same both-copies-or-stale-trap hazard.
+
+Revert: `rm ~/vr1-office1-creds/netbox-admin-password`; revert the matrix row pair, the
+manifest row, the note paragraph, and the SEC-025 ledger row. The VM copy is untouched.
+
+## 5. V2 learns the ruled-deferral state, and gains its first harness cases
+
+`scripts/creds-matrix.py`: `load_sec_states` now also reports whether a declared-dead SEC row
+carries an operator-ruled deferral; `v2_declared_state` emits `V2 ACKNOWLEDGED DEFERRAL`
+instead of a FAIL when it does.
+
+WHY: SEC-006 has read "**DEFERRED by operator ruling 2026-07-13: revoke at completion of this
+deployment**" since long before this checker existed. V2 was reporting that standing operator
+ruling as a defect on every run -- which is both wrong and corrosive, because a finding that
+can never be actioned trains readers to skip findings. **Reissuing the token would have
+contravened the ruling**, so the register was the thing that needed to change, not the
+credential.
+
+The acknowledgement is NOT a pass. It names the id, the SEC row, the state word and the
+ruling text, and states that the credential "is still live and still exposed until that
+ruling is discharged".
+
+`DEFERRAL_RE` demands BOTH the emphasis-cased state word AND explicit attribution to an
+operator ruling (the GA-R5 bar), and `[^|]` stops it crossing a ledger table cell. A looser
+match would let prose that merely DISCUSSES deferring buy silence -- the false-green class
+this register exists to prevent. T58 and T59 are the regression locks for exactly that.
+
+Also added `--ledger` (default unchanged). V2 read the SEC register via `--repo`, which the
+harness must point at the REAL repo for S4 mint-ref resolution -- so there was no fixture path
+to the ledger and **V2 had shipped with ZERO harness cases**. The override is what makes it
+testable; it also de-couples the existing tier-3 cases from the live ledger.
+
+New cases T56-T59 (harness 56 -> 60): the founding invariant still fails; a ruled deferral is
+acknowledged and still says EXPOSED; unruled "deferred" prose still fails; a claim spanning
+two ledger cells does not count as ruled.
+
+NOTE: tier 3 is NOT part of preflight `P5` (which runs tier 1 + tier-2-local), so this does
+not change the blocking deploy gate's behaviour.
+
+Revert: `git revert` this commit's changes to `scripts/creds-matrix.py` and
+`tests/creds-matrix/run-tests.sh`; V2 returns to failing on SEC-006 every run.
+
+## 6. Permission allowlist widened for read-only commands (`.claude/settings.json`)
+
+Transcript scan of the 44 most-recent session JSONLs across both project dirs, counting Bash
+leading command+subcommand pairs (and splitting each candidate into LOCAL vs
+nested-inside-`ssh`, since a command that only ever runs inside `ssh host '...'` gains nothing
+from its own rule -- the outer `ssh` is what the permission layer matches).
+
+ADDED to `permissions.allow` only -- 13 entries, 31 -> 44. `ask`, `deny`, `env` and `hooks`
+untouched; nothing removed or reordered; JSON re-validated and de-duplicated:
+
+    bash scripts/creds-audit.sh *          (33)   bash scripts/dc-dc-ceph-disk-budget.sh * (13)
+    bash scripts/site-baseleg.sh check*     (5)   tofu validate* + tofu -chdir=* validate*  (25)
+    tofu state list* + -chdir variant      (16)   tofu state show*                           (3)
+    tofu providers schema*                 (13)   tofu version*                             (11)
+    ip route*                              (22)   systemctl is-active *                      (6)
+
+DELIBERATELY NOT ADDED, and this is the substantive half of the item:
+
+- **`ssh` (693 calls), `scp` (47), `virsh` (234)** -- the three biggest prompt sources, left
+  alone. They are this cloud's MUTATION TRANSPORT. CLAUDE.md hard rule 3 makes the `ask` rules
+  the enforcement mechanism for per-mutation approval and says not to work around them, and
+  the `Bash(ssh *)` disposition is an OPEN operator item queued at the 2026-07-23 close.
+  Allowlisting any ssh shape would bypass the gate AND pre-empt an unresolved operator
+  decision. **This item does NOT discharge that queued prune -- it is still open.**
+- **`python3 scripts/creds-matrix.py` (76 local runs -- the largest genuine miss)** -- skipped
+  because `Bash(*creds-matrix.py *--privileged*)` is an `ask` rule added 2026-07-26 precisely
+  after the auto-mode classifier incident. Every prefix pattern wide enough to cover the
+  observed `... 2>&1 | tail` forms would ALSO match `--privileged`, and allow-vs-ask precedence
+  was not verified this session. Adding a rule that might silently downgrade an
+  operator-installed gate is exactly the class of change hard rule 3 forbids. Needs the
+  precedence question answered first, then a narrow set of EXACT forms.
+- **`tofu plan` (54)** -- read-only in effect, but CURRENT-STATE section 10 says in terms "Do
+  NOT re-run `tofu plan` casually against live state". The prompt is deliberate friction.
+- `python3 -c`/heredocs (324) and shells: arbitrary code execution. `curl` (114): a mutation
+  vector via `-X`/`-d`. `tofu fmt` (26): rewrites files. `tofu init` (10): mutates
+  `.terraform/`. `nft list` (10): normally needs `sudo`, which correctly stays `ask`.
+
+TWO OBSERVATIONS, no action taken (flagged, not fixed): several existing allow entries are
+redundant with Claude Code's built-in auto-allow (`Bash(git status*)`, `Bash(git log*)`,
+`Bash(grep *)`, `Bash(ls *)`, `Bash(jq *)`, `Bash(cat scripts/*)`) -- harmless, and removing
+entries was out of scope; and `Bash(git pull*)` sits in `allow` although it is a fetch-and-merge
+that mutates the working tree.
+
+Revert: drop the 13 appended lines from `permissions.allow` in `.claude/settings.json`. No
+other field was touched, so the revert is a contiguous deletion.
+
+## 7. Stage 4 close-out opened: `dc-mirror.sh check` was FALSE-GREENING the mirror gate
+
+Operator direction: close Stage 4 before resuming the DC1 Stage-5 chain. The Stage 4 DoD
+(`runbooks/dc-dc-phase3-maas-enlist-deploy.md:472-485`) has six bullets; four are already met
+and captured. Verifying the fifth -- "per-DC mirror reachable" -- found that **the check the
+gate would close on could not fail.**
+
+`scripts/dc-mirror.sh:271-273` tested `[ -f last-sync.status ]` and printed the file's contents
+behind an unconditional `OK`. So the status word was displayed but never asserted on, and the
+check exited PASS regardless. MEASURED on both racks, 2026-07-27:
+
+- **dc0** read `FAIL 2026-07-27T00:54:54Z ubuntu=255 uca=0` -> printed `OK`, check PASS.
+- **dc1** read `RUNNING 2026-07-23T21:49:35Z` -- a marker FOUR DAYS stale, left by the
+  debmirror the D-135 amendment killed with a signal, so it never wrote a terminal state ->
+  printed `OK`, check PASS.
+
+FIXED: the status word is now case-analysed. `OK*` passes; `FAIL*` misses; an ABSENT file
+misses (it was a passing `note`, but nothing has attested the content); an unrecognised word
+REFUSES rather than defaulting to success. `RUNNING*` is deliberately neither -- in-flight and
+died-mid-run are indistinguishable from the file alone, so it reports an explicit UNKNOWN and
+cross-checks the unit: a RUNNING marker with no active unit is named as a corpse, not a
+success. Harness `tests/dc-mirror/run-tests.sh` **24/24** (was 19); T20-T24 lock each status
+word, T24 specifically locks out the return of the exact defective shape.
+
+PROOF THE FIX WORKS -- re-run against both live racks, and the gate is now honestly NOT MET:
+`dc-mirror check (dc0): FAIL` on the failed sync, `dc-mirror check (dc1): FAIL` on the stale
+marker. Capture `docs/audit/stage4-mirror-gate-20260727.txt`.
+
+SUBSTANCE BEHIND THE TWO FAILURES (measured, not inferred):
+
+- **dc0's mirror CONTENT is complete and intact** -- 949G ubuntu + 342M cloud-archive, all
+  three dists (`jammy`, `jammy-updates`, `jammy-security`) plus `pool` and `project`. What
+  failed is the overnight INCREMENTAL: `Download of dists/jammy/Release failed: 500 read
+  timeout` -> "Failed to download some Release, Release.gpg or InRelease files!" -> debmirror
+  aborted the ubuntu leg with 255. The UCA leg succeeded (`uca=0`). A transient upstream fetch
+  failure, not mirror damage. The daily timer re-arms for 2026-07-28 00:14:48.
+- **dc1's debmirror is dormant only ACCIDENTALLY.** `dc1-mirror-sync.timer` is `enabled` with
+  an EMPTY `NextElapseUSecRealtime`, because the service sits in `failed`/`Result=signal` from
+  the 07-24 pause. The D-135 amendment RULED it paused and "kept dormant as the fallback", but
+  nothing enforces that -- the dormancy is a side effect of a failed unit, not a declared
+  state, so a `systemctl reset-failed` (or possibly a reboot) re-arms a 330G -> ~949G pull on
+  a rack whose ruled artifact path is now the proxy. dc1's PROXY meanwhile checks **PASS**
+  genuinely: apt-cacher-ng active on `.4:3142`, serving both archive and UCA `Release` with 200.
+
+Revert: `git revert` this commit's `scripts/dc-mirror.sh` + `tests/dc-mirror/run-tests.sh`
+changes -- the check returns to passing unconditionally on last-sync. No live state was
+altered by this item; both racks were read only.
+
+## 8. G17 opened by ruling; DoD bullets 5 and 6 repaired (DOCFIX-204)
+
+**RULING (GA-R5), 2026-07-27.** Question as presented: "The node-side half of bullet 5. Nodes
+are powered off by the READY-handoff ruling, so no node-side probe can run as things stand.
+Either a gated rescue-boot check on one node per DC now (closes it inside Stage 4), or split it
+into its own gate row targeted at Stage 5 first boot (GA-R6 E3 explicitly permits this; a
+conditional close is not permitted)." Operator answer, exact utterance: **"split it into its
+own gate row"**. Recorded in the **G17** row of `docs/CURRENT-STATE.md`, which is the authority;
+committed and pushed before any dependent work (GA-R5).
+
+**G17 -- "Per-DC artifact source reachable FROM A NODE"**, [V], OPEN. Per DC: dc0 -> `curl -sI
+http://10.12.8.4/` returns 200 from a booted node; dc1 -> apt fetches through the proxy at
+`10.12.68.4:3142`, because dc1's ruled artifact path is the CACHING PROXY and it has no
+node-facing mirror (D-135 amendment) -- checking it as one fails by design. Natural trigger is
+Stage 5 first boot. The row states explicitly that G17 is NOT a Stage-5 precondition and must
+not be conflated with one: Stage 5's bootstrap needs OPEN edge egress for the juju agent stream
+and snaps (D-135 items 2-3 unbuilt), which is a different path from the apt artifact source.
+
+What REMAINS in Stage 4 for bullet 5 is the rack-side half -- the source answers on its own
+address with an attested-current sync. dc1's proxy already PASSES; dc0 does not yet, pending
+the sync re-run (item 7).
+
+**DOCFIX-204 -- bullet 6 was unsatisfiable, and its stale text had spread to four surfaces.**
+"NTP from the DC's own OPNsense edge working" is SUPERSEDED by D-129(iv) (RULED 2026-07-21,
+"Keep MAAS hierarchy (Recommended)", no NTP role on the edge). The DoD asked you to confirm the
+edge is the time source, which the ruling had already refused -- so the bullet could never be
+met by a correctly-built DC. Repaired in:
+
+- `runbooks/dc-dc-phase3-maas-enlist-deploy.md` DoD -- bullet 6 STRUCK with its supersession
+  cited; bullet 5 rewritten per-DC with the split recorded.
+- the same runbook's **Step 7, rewritten**. It had THREE defects, each recorded rather than
+  quietly patched because the old text is the kind that gets followed: it still branched on
+  gap #5 ("if the mirror does not exist yet, STOP") which D-135 resolved; it applied one mirror
+  check to both DCs, which fails on dc1 by design; and both its checks said "from a deployed
+  node", which the READY-handoff ruling makes impossible in this stage. Now it invokes the two
+  site checkers (with the hard-rule-2 note to take rack transit IPs from `lib-hosts.sh`, never
+  memory) and carries the MAAS-hierarchy time check as a Stage-5/G17 observation.
+- `docs/dc-dc-deployment-workflow.md:206` -- the Gate cell also still said "Nodes deployed",
+  contradicting DOCFIX-200's READY handoff. Both fixed.
+- `docs/dc-dc-buildout-design.md:120` -- corrected with the supersession noted inline.
+- `runbooks/dc-dc-phase4-juju-bundle-per-dc.md:26` -- prerequisites said "nodes Deployed",
+  which is precisely the expectation DOCFIX-200 removed to stop Stage 5 breaking; plus a new
+  block making this stage the OWNER of G17's captures, with the warning that first boot is the
+  observation window and missing it forces a deliberate rescue-boot.
+
+Revert: `git revert` this commit's doc/runbook changes; the G17 row and the DOCFIX-204 edits
+are text-only, and no live state was touched.
+
+## 9. dc0 sync re-run; dc1 full mirror REMOVED after moving the proxy's net layer (D-135 amendment)
+
+**dc0 (gated).** `systemctl start dc0-mirror-sync.service` -> `OK 2026-07-27T08:43:46Z
+ubuntu=0 uca=0` in **20 seconds**, confirming the transient-`500` diagnosis exactly. Fixed
+`dc-mirror.sh check dc0` now reports **PASS** -- trustworthy precisely because the same check
+FAILED on the same rack twenty minutes earlier. **Stage 4 DoD bullet 5 is now MET for both DCs.**
+
+**dc1 -- the record was wrong about intent.** CURRENT-STATE said the debmirror was "PAUSED ...
+kept dormant as the fallback". Operator, exact utterance: "DC0 is the test of a full mirror.
+DC1 is the test of the mirror proxy. DC1 needed the partially created full mirror and
+associated script/files/settings removed." Recorded as a **D-135 AMENDMENT 2026-07-27**: the
+per-DC split is the DELIBERATE EXPERIMENT, not an interim -- no fallback, no later
+convergence. That also supersedes the "DC1's proxy is REPLACED by a full mirror afterward"
+claim, which was in THREE places (D-135, CURRENT-STATE:109, `dc-cache-proxy.sh:6`); all three
+corrected.
+
+**The coupling trap, and why sequencing mattered.** Asked whether to rip down and rebuild
+rather than pick and choose, I found the rebuild path was BLOCKED, not merely slower:
+`dc-cache-proxy.sh` did not own its utility net layer -- its header said it REUSES
+`dc-mirror.sh`'s `<site>-mirror-net.service` and "fails loud if absent". So on dc1 three files
+named `dc1-mirror-*` (net unit, apply helper, resolved DNS drop-in) were load-bearing FOR THE
+PROXY. Therefore (a) the 07-23 changelog's recorded removal ("stop/disable ... -net.service,
+rm the generated files") would have silently killed the proxy, the Stage-4 bullet-5 PASS, and
+the Stage-5 dc1 apt path; and (b) the proxy could not be REBUILT afterward, since nothing but
+`dc-mirror.sh install` created the net layer -- rebuilding a PROXY meant reinstalling the whole
+MIRROR apparatus, enabled daily timer included. Operator direction: "Do the net layer first,
+then rip it all down."
+
+**Step 1 -- net layer moved (script change).** `dc-cache-proxy.sh` now owns
+`<site>-cache-proxy-net.service` + `<site>-cache-proxy-net-apply` + its own
+`resolved.conf.d/<site>-cache-proxy.conf`, reusing dc-mirror's proven mechanism (bridge
+resolved from the libvirt net NAME at runtime, hard rule 3). Neutrally named so a proxy-only
+DC carries NO mirror-named dependency. Idempotent `ip addr replace` / `ip route replace` on
+identical MEASURED values, so the two net units coexist safely where a site runs both -- dc0
+is unaffected. `check` asserts the ARTIFACTS, not just the live address/route, because
+asserting only the live effect would PASS while the layer was really the mirror's: it would
+look independent and break on teardown, the exact failure being removed.
+
+Harness **20/20** (was 15). **T12 was REPLACED, not deleted** -- it asserted the superseded
+design ("net layer reused ... no ip addr/route writes; points at dc-mirror.sh"), so it failed
+by design once the ruling landed. It is now INVERTED (T12: owns the layer) plus T12b-T12f
+(no operative dc-mirror referral; proxy-named artifacts; enabled-not-just-started; check
+asserts artifacts; idempotent verbs only). T12b is deliberately scoped to NON-COMMENT lines:
+the header's account of WHY the coupling was removed cites `dc-mirror.sh install`, and deleting
+that history to satisfy a grep would lose the reason the trap existed.
+
+**Step 2 -- independence PROVEN before deleting anything.** A `oneshot` with
+`RemainAfterExit=yes` does not undo its work on stop, so merely stopping
+`dc1-mirror-net.service` would have proven nothing. The live state was removed outright --
+`ip addr del 10.12.68.4/22` (count -> 0) and `ip route del default via 10.12.64.1` (count ->
+0) -- then the proxy-owned unit applied ALONE restored both, and `check dc1` returned **PASS
+with the mirror net unit disabled**.
+
+**Step 3 -- wholesale removal, no picking and choosing.** All mirror units, the timer, the sync
+helper, the nginx vhost, the resolved drop-in, the `debmirror` package, and the **330G** of
+partial mirror (33,037 files; `rm -rf` **47.6s**; rack disk 339G -> 9.0G). Zero mirror-named
+residue; every proxy artifact present; proxy PASS throughout and never down. Capture
+`docs/audit/dc1-mirror-teardown-20260727.txt`.
+
+nginx **left installed, deliberately**: it was a mirror prereq, but with the vhost gone it is a
+generic server on its stock `default` vhost. Removing the metapackage while `nginx-core` keeps
+running is a half-measure worse than either extreme, and a full purge is scope creep on a rack
+host. If dc1 is ever rebuilt as a mirror, `dc-mirror.sh install` fail-louds with the exact apt line.
+
+Revert: reinstall via `dc-mirror.sh install dc1` (recreates units/vhost/timer; needs the
+`debmirror` package reinstalled first) then `sync dc1` to re-pull ~950G. **The 330G partial is
+NOT recoverable** -- deliberately, per the amendment. The proxy net layer reverts by
+`git revert` of `scripts/dc-cache-proxy.sh` + its harness, then re-running
+`dc-mirror.sh install dc1` to restore the mirror-owned layer.
+
+## 10. Carve residue cleaned (108 fabrics -> 17); dc1's leftover nginx removed
+
+Capture `docs/audit/stage4-carve-residue-cleanup-20260727.txt`. Both items were queued to the
+stage close at the 2026-07-23 carve.
+
+**nginx on dc1.** Purged `nginx` + `nginx-common` (dry-run first: nothing else depended on them,
+and no `nginx-core` was installed), plus autoremove of `liblockfile-simple-perl` and
+`liblog-agent-perl` -- debmirror's orphaned perl deps. `/etc/nginx` gone, nothing listening on
+:80, proxy still PASS on :3142. dc0 keeps its nginx and was re-verified unaffected (it serves
+the mirror).
+
+**Carve residue: 108 fabrics -> 17.** Deleted subnet id=8 `192.168.1.0/24` (the superseded
+OPNsense FACTORY LAN -- both edges were re-addressed to 10.12.4.1 / 10.12.64.1), then fabric-5,
+then the 90 auto-created empties (ids 6..95).
+
+The audit caught an **ordering dependency the original flag did not state**: the
+192.168.1.0/24 subnet was the ONLY occupant of fabric-5, so deleting the fabric first would
+have cascaded the subnet away rather than removing it cleanly. Subnet first, then the fabric.
+
+METHOD, chosen because of this repo's own history: a MAAS fabric delete cascades to its VLANs,
+and the 2026-07-21 pod-delete incident cost 9 machine records precisely because the association
+check ran AFTER the delete. So emptiness was PROVEN per fabric -- zero subnets, zero ipranges,
+zero node interfaces across all of its VLANs -- against a fresh occupancy snapshot (fabrics +
+subnets + ipranges + every machine's `interface_set`) taken immediately before the batch, and
+the cascade check was re-run afterwards as well.
+
+KEPT, all verified occupied and enumerated in the capture: office1 base + GUA (fabric-0),
+office1 compose with its 2 LXD guests (fabric-1), both transits (fabric-2 / fabric-141), both
+metal-admin/boot fabrics with 9 nodes each (fabric-4 / fabric-142), libvirt default (fabric-3),
+and the 10 named plane fabrics (`vr1-dc0-*` / `vr1-dc1-*`, 9-18 interfaces each).
+
+POST-STATE: 18 Ready + 2 Deployed office1 guests, all 18 still `power_type=virsh`, 7 interfaces
+each (6 flat planes per D-133 + br-ex), **ZERO orphaned interfaces**, placement tags 9+9 intact,
+and both DCs' artifact paths re-verified PASS after everything.
+
+Revert: fabrics and subnets are MAAS records, not config -- there is no undo. Recreating them
+would mean `maas admin fabrics create` + `subnets create`, but nothing needs them: the 90 were
+auto-created empties, and 192.168.1.0/24 was a superseded factory address. The nginx purge
+reverts with `apt-get install nginx` (dc1 has no use for it while it is the proxy DC).
+
+## 11. SEC-024 retention RULED -- keep both state-surgery snapshots
+
+**RULING (GA-R5), 2026-07-27.** Question as presented: 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 Office1 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"**.
+
+`opentofu/terraform.tfstate.pre-G6-20260719` and `.pre-G16-20260721` are RETAINED at 0600,
+neither git-tracked, as the only record of what the state looked like before the two direct
+tfstate edits (G6 autostart injection, G16 `channels = []`).
+
+SEC-024 therefore stays **OPEN as a standing WATCH, not an open remediation**: its mode defect
+is fixed, but the umask CAUSE was out of ruled scope, so a future apply may rewrite 0664 and
+preflight P5 is the detection. Recorded in both the SEC-024 disposition cell and CURRENT-STATE.
+Open SEC count unchanged at 21.
+
+## 12. set-interface-v4 reload amendment RULED + implemented (the last queued stage-close item)
+
+**RULING (GA-R5), 2026-07-27.** Question as presented: (a) add `configctl filter reload` to the
+script's `--commit` path; (b) leave the script and rely on DC standup DoD item 8; (c) add it
+behind an opt-in flag. Operator answer, exact utterance: **"a"**. OPS under GA-R3 -- a script fix
+completing an already-documented operation, governed by D-113; no new D-number.
+
+THE DEFECT (appendix-A, measured on the fresh dc1 edge 2026-07-23): `--commit` ran `configctl
+interface reconfigure`, which applies the address to the kernel but does NOT regenerate the pf
+ruleset, so OPNsense never creates its automatic outbound-NAT rules for the (re-)addressed LAN.
+Forwarded LAN packets leave the WAN un-NAT'd and replies never return -- the edge passes NO LAN
+traffic while looking perfectly configured. Self-masking: any later plugin install or config
+apply reloads the filter as a side effect, so dc0's 07-20 qga work hid it there until dc1, which
+had no later work, exposed it at the mirror build.
+
+Option (b) was rejected on evidence, not taste: DoD item 8 already existed and did not fire at
+dc1, and prose-only controls have a measured failure record here (D-137's own enforcement sat as
+prose at `phase-3:498` and missed BOTH DC standups).
+
+**THE PLACEMENT IS THE SUBSTANCE OF THE FIX, and my first attempt got it wrong.** I initially put
+the reload on the next line of the `interface reconfigure` heredoc. That would have been a fix
+that fixes nothing exactly when it matters: re-addressing the interface you arrived on drops the
+session DURING the reconfigure, so a following command in that stream never executes on the edge
+-- and that drop case IS this incident's scenario (dc1's LAN moved 192.168.1.1 -> 10.12.64.1 over
+the LAN itself). Caught before shipping. As delivered, the reload runs over a FRESH connection to
+`PROBE_HOST`, the address the edge answers on after the move.
+
+Also added a `pfctl -s nat` read-back with the `proto carp` boilerplate filtered out -- that
+boilerplate-only state is precisely appendix-A's broken-state signature. It is REPORTED, not
+gated: at an edge's very first addressing there may legitimately be no gateway and so no NAT to
+generate, and hard-failing would block a correct run. The hard gate stays address-on-the-kernel.
+
+Harness **59/59** (was 53). Cases 15-15f: the reload exists; it is NOT inside the reconfigure
+heredoc; it targets `PROBE_HOST`; the NAT read-back exists with carp excluded; the read-back does
+not hard-exit; and appendix-A no longer calls the amendment an unruled queued option. **Case 15f
+caught a real inconsistency** -- appendix-A still said "not yet ruled" -- and case 15e caught a
+bug in my own first draft of it, which scanned to EOF and so failed the script for having the
+very hard gate the case exists to preserve.
+
+appendix-A's entry rewritten: the FIX stays (for an edge already in this state), plus a
+PREVENTED-IN-THE-TOOL block recording the placement detail and why prose prevention was rejected.
+
+Revert: `git revert` the `scripts/opnsense-set-interface-v4.sh` +
+`tests/opnsense-set-interface-v4/run-tests.sh` + appendix-A changes. No live edge was touched --
+both DC edges are already addressed, so this affects only the NEXT edge addressing.
+
+---
+
+## Findings LOGGED, not actioned (hard rule 1)
+
+1. **dc0 edge API credential (`opnsense-api.txt`) is absent from every DECLARED location** --
+   not the jumphost folder, not the headend shadow store. It exists only inside the dc0
+   edge's own config. Recovery is a re-mint via `scripts/opnsense-bootstrap-apikey.sh` (the
+   dc1-proven path; dc0's edge SSH key IS present on vcloud), which is a live mutation on a
+   running edge and was explicitly OUT of this batch. This is the sole remaining SEC-021(a)
+   item and accounts for 2 of the 7 residual findings.
+2. **No registered root/console credential at EITHER DC edge.** MEASURED: no matrix row, no
+   manifest entry, no SEC row. `office1-edge-root` is `cardinality=per-site` and office1-only.
+   NOT MEASURED, and deliberately not probed: what those root passwords actually are. The
+   phase-2 runbook says DC edges boot on FACTORY DEFAULTS and the D-112(c) chain installs
+   sshd + the service key without setting a root password -- but that is a repo reading, not
+   a measurement (hard rule 2). Root SSH is key-only (proven), so SSH is not the vector; the
+   web GUI is LAN-reachable at both edges and the serial console exists. Proposed as the
+   next-free SEC row once the operator gates a probe.
+3. **Two structural blind spots that let (2) hide.** (a) `S5` compares only
+   `cardinality=per-DC` (`creds-matrix.py:380`); all SIX `per-site` rows are office1-only, so
+   a per-site credential missing at two of three sites is invisible to every check. This is
+   the "cardinality largely inert" item CURRENT-STATE already carries -- now with a concrete
+   consequence. (b) `creds-manifests/vm-secret-locations` declares only `jumphost`,
+   `headend`, `netbox`, while the checker also accepts `rack`, `edge`, `cloud`, `unit`,
+   `client` -- all with zero declared locations, therefore unaudited. SEC-015 was a
+   rack-resident edge-key copy, so the class is not hypothetical.
+4. **The 3 residual S5 power-key asymmetries are RULED, not defects.** SEC-016 designs dc0 to
+   keep the snap's default identity while dc1 gets a named per-host key, so the filenames can
+   never match and `DC_TOKEN_RE` cannot normalise them. The register needs a way to record a
+   ruled exception; suppressing them silently would be wrong and renaming live files to
+   satisfy a checker would be worse. Needs an operator decision on mechanism.
+5. **dc0/dc1 creds folders carry no README** while office1 does (`creds-folder-readme`, also
+   `per-site`). Cosmetic; noted for symmetry.
+6. **The headend shadow stores (SEC-022) are now redundant for dc0's power key** -- vcloud
+   holds the copy SEC-021(b) asked for. Deleting the shadow copy is a plausible follow-up but
+   is destructive and out of scope.
+
+## Verification
+
+- `tests/creds-matrix/run-tests.sh` -- **60/60 PASS** (was 56).
+- `scripts/creds-audit.sh` all three sites -- CLEAN (office1 14 entries, dc0 7, dc1 8).
+- `creds-matrix.py --tier2 --tier3 --remote --privileged` -- 82 rows, findings **13 -> 7**.
+  Cleared: S2 x2, E1 x3 (2 power-key + 1 dc1 `.pub`), V2 x1 (now an acknowledged deferral).
+  Residual 7: dc0-edge-api (2, needs the excluded re-mint), S5 x3 (ruled, item 4 above),
+  S6 conflation x1 (the SEC-020 defect, separate), E4 uncheckable x2 (Stage-5/6 rows).
+  **The register is NOT green and is not expected to be.**
+- `scripts/repo-lint.sh` + full gauntlet: see the commit message for the recorded results.
+- `.claude/settings.json` (item 6): `json.load` parses, 44 allow entries, zero duplicates,
+  `ask` 52 / `deny` 15 / `env` / `hooks` byte-unchanged.
diff --git a/docs/archive/stage-records/vr1-stage4-record.md b/docs/archive/stage-records/vr1-stage4-record.md
new file mode 100644
index 0000000..d20a165
--- /dev/null
+++ b/docs/archive/stage-records/vr1-stage4-record.md
@@ -0,0 +1,128 @@
+# VR1 Stage 4 record -- Phase 3 "MAAS enlist / commission / deploy (per DC)"
+
+**OPENED 2026-07-23** on branch `dc-dc-stage4-phase3-maas-deploy` (off post-merge `main`
+after the Stage 3 / G12 merge). **CLOSED 2026-07-27.** 76 commits.
+
+`docs/CURRENT-STATE.md` is the status authority for everything below; this record is
+history and a pointer table. Nothing here may be cited as status (GA-R1).
+
+## What the stage actually delivered
+
+The stage's goal as authored was "bring the discovered node VMs to a deployed OS, ready
+for Juju". That changed shape en route, by ruling: **MAAS-deploy is SKIPPED.** The deploy
+model was ruled a **READY handoff** (2026-07-23) -- Juju provisions the nodes at Stage 5
+per the phase-01 precondition -- and DOCFIX-200 rewrote the runbook's Step 4, which as
+written would have broken Stage 5. So the delivered end-state is 18 nodes **Ready**,
+carved, tagged, with both DCs' artifact paths serving.
+
+- **Carve executed both DCs** (logged window `stage4-carve`, 2026-07-23): dynamic ranges
+  .201-.254, 10 named plane fabrics, 90 NIC re-homes across 18 nodes each read back
+  against its pinned MAC, 2 provider subnets moved off fabric-5 + 8 plane subnets created,
+  6 spaces with 12 VLANs, 18 nodes' statics + br-ex OVS. All 18 stayed Ready.
+  Rulings behind it: **D-133** (flat per-NIC carve for VR1; hardware-faithful bonds/trunks
+  deferred to the next deployment) and **D-134** + its Option-B amendment (contiguous
+  bands: .4-.49 utility, .50-.99 VIP, nodes .100-.200, dynamic .201-.254).
+- **Placement tags** `openstack-vr1-dc0` / `-dc1` applied 9+9 (D-119 naming), and
+  **verified live 2026-07-27** -- the 07-25 decision-recon had flagged them
+  NEEDS-LIVE-VERIFY because the discovery capture carried no tag column.
+- **jammy boot images synced** to the region (selection id=2).
+- **Per-DC artifact delivery = D-135**, and this is the stage's most-amended decision.
+  The rehearsal-scoped D-107 exception was REJECTED; mirrors were built. Then the
+  2026-07-24 amendment split the two DCs, and the 2026-07-27 amendment made that split
+  the deliberate experiment rather than an interim: **dc0 tests the full mirror
+  (949G+342M), dc1 tests the apt caching proxy.** dc1's partial 330G mirror and its whole
+  apparatus were removed at close.
+- **Tooling shipped:** `dc-mirror.sh` (site-keyed check/install/sync), `dc-cache-proxy.sh`
+  (and, at close, its own utility net layer), `creds-matrix.py` + the D-137 register,
+  preflight **P5**, plus `lib-hosts.sh`'s VR1 arms and D-133 guards in the VR0 flow scripts.
+
+## The three things a future session should read first
+
+1. **The READY-handoff ruling (DOCFIX-200).** Stage 4 does NOT deploy an OS. Four surfaces
+   still said "nodes Deployed" as late as 2026-07-27 and were corrected then; if a fifth
+   turns up, that is the same defect, not a new fact.
+2. **The two DCs' artifact paths are DIFFERENT BY RULING.** Checking dc1 as a mirror fails
+   by design. `dc-cache-proxy.sh check dc1` is dc1's gate; `dc-mirror.sh check dc0` is dc0's.
+3. **A checker that cannot fail is not a gate.** Both of this stage's late findings were
+   false greens in controls that had been passing for days -- see below.
+
+## False greens found in this stage's own controls (the pattern worth carrying forward)
+
+This stage twice discovered that a control everyone trusted could not fail. Both were
+found by *running* the control against reality rather than reading its output history:
+
+- **`creds-audit` is declaration-based**, so an undeclared secret is structurally
+  invisible. It read CLEAN on all three sites while the D-137 matrix returned 13 findings.
+  Beyond that, the matrix itself cannot report the absence of a credential it has no ROW
+  for -- which is how an unregistered root credential at both DC edges, and a human GUI
+  login that had never left the VM it was minted on, both survived every audit. The fix
+  that found them was to ENUMERATE what exists (`maas admin users read`) instead of
+  auditing what is declared.
+- **`dc-mirror.sh check` asserted that `last-sync.status` EXISTED**, printing its contents
+  behind an unconditional `OK`. dc0 read `FAIL ... ubuntu=255` and dc1 read a four-day-stale
+  `RUNNING`; both printed OK and the check exited PASS. Fixed at close (status word
+  case-analysed; `RUNNING` is an explicit UNKNOWN cross-checked against the unit).
+
+The D-137 six-lens committee audit (2026-07-26) is the same lesson at scale: it found
+**8 false greens** in a register built four days earlier, four lenses converging on one
+root cause (tier 2 keyed existence on host-role alone, ignoring site, so one site's
+credential satisfied every site).
+
+## Incidents
+
+- **dc1 edge passed NO LAN traffic** after v4 addressing (2026-07-23): `configctl interface
+  reconfigure` applies the address but does not regenerate the pf ruleset, so the automatic
+  outbound NAT for the re-addressed LAN was never created. Self-masking -- dc0's earlier
+  qga/plugin work had reloaded the filter as a side effect and hid it. Fixed live with
+  `configctl filter reload`; **prevented in the tool at close** (2026-07-27 ruling), with the
+  reload deliberately placed on a FRESH connection to the post-move address, because
+  re-addressing the interface you arrived on drops the session during the reconfigure.
+- **dc0 mirror's overnight incremental failed** on a transient upstream `500 read timeout`
+  for `dists/jammy/Release` (2026-07-27). Content was intact; a re-run succeeded in 20s.
+  Only visible because the check was fixed first.
+- **A fabricated reference** ("D-193") appeared in 2026-07-24 analysis, was corrected to
+  D-121, and was verified never to have reached the repo. Recorded because the cardinal sin
+  is fabrication, and owning it is the control.
+
+## Gates and rulings
+
+Gate rows are in `docs/CURRENT-STATE.md` section 6. This stage opened **G17** (per-DC
+artifact source reachable FROM A NODE) by operator ruling 2026-07-27, splitting the
+node-side half of DoD bullet 5 out rather than closing it conditionally -- GA-R6 E3 forbids
+a conditional close, and the READY-handoff ruling leaves nodes powered off, so no node-side
+probe can run in this stage. G17's trigger is Stage 5 first boot; the phase-4 runbook now
+owns its captures. DoD bullet 6 ("NTP from the DC's own OPNsense edge") was STRUCK by
+DOCFIX-204 as unsatisfiable -- D-129(iv) had already ruled the MAAS hierarchy the time
+authority, so a correctly-built DC could never have met it.
+
+Decisions adopted or amended in this stage: **D-133**, **D-134** (+amendment), **D-135**
+(+two amendments), **D-137** (five sub-rulings, all individually ruled), plus amendments to
+D-104 (dedicated 10th controller VM), D-101 (address family CONFIRMED), and D-113 (the
+set-interface reload). SEC rows opened: **SEC-017** through **SEC-025** (nine), of which
+SEC-024 was opened and remediated the same day.
+
+## Close-out set (GA-R6)
+
+Executed 2026-07-27: every substantive in-stage item closed or split to G17; carve residue
+cleaned (108 fabrics -> 17, cascade-checked); dc1 mirror removed after making the proxy
+self-sufficient; GA-R2 consolidation (this record); skill sweep + dated snapshot
+regeneration; GA-R7 memory review; final gauntlet **ALL GREEN (81)** + repo-lint 0-fail;
+operator-gated merge to `main` as a merge commit; branch retired.
+
+## Sessions (now `docs/archive/changelogs/`)
+
+| file | scope | lines |
+|---|---|---|
+| changelog-20260723-caveman-optin-guard.md | caveman opt-in guard (pre-disable) | 46 |
+| changelog-20260723-stage4-open.md | Stage 4 OPEN, D-133/D-134, carve both DCs, D-135 + dc-mirror.sh, dc1 edge pf incident | 249 |
+| changelog-20260724-caveman-disable.md | caveman plugin DISABLED + SEC-017 + guardrails; DC1 proxy build start; D-135 amendment | 225 |
+| changelog-20260724-stage5-committee-fork1.md | bundle-render committee, D-104 amendment (10th VM), BUNDLEFIX-052, validator spine | 294 |
+| changelog-20260725-maas-admin-recovery.md | SEC-020 premise FALSIFIED, `operator` superuser minted, admin.pass consolidated; D-137 PROPOSED | 263 |
+| changelog-20260726-d137-tier1.md | D-137 tiers 1-3 built, six-lens committee audit, 8 false greens remediated, preflight P5 wired, SEC-024 | 772 |
+| changelog-20260727-creds-consolidation.md | consolidation batch (SEC-021(b)/SEC-025), V2 ruled-deferral, permission allowlist, mirror-gate fix, G17, DOCFIX-204, dc1 teardown, carve residue, set-interface-v4 reload | 499 |
+
+Captures for this stage are in `docs/audit/` (23 added on the branch), including
+`stage4-discovery-20260723.txt`, `stage4-carve-verify-20260723.txt`,
+`stage4-mirror-gate-20260727.txt`, `dc1-mirror-teardown-20260727.txt`,
+`stage4-carve-residue-cleanup-20260727.txt`, `creds-consolidation-audit-20260727.txt`,
+and the D-137 committee/remediation set.
diff --git a/docs/changelog-20260723-caveman-optin-guard.md b/docs/changelog-20260723-caveman-optin-guard.md
deleted file mode 100644
index b328c98..0000000
--- a/docs/changelog-20260723-caveman-optin-guard.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Changelog -- 2026-07-23 -- caveman plugin: off-by-default opt-in guard
-
-Session scope: operator-directed install of the `caveman` Claude Code plugin
-(third-party, `JuliusBrussee/caveman`) plus guards so it never auto-arms while
-operating the cloud. Harness-config only -- NO cloud mutation, NO script/runbook
-change, no status implication (CURRENT-STATE untouched). Kept as an available
-tool for future hardened-workflow deployment testing, where terse
-gated-approval-only output is wanted; verbose fully-gated output stays the
-default for live operations.
-
-## Item 1 -- caveman plugin installed (user scope), hooks inspected read-only
-
-- Installed `caveman@caveman` at user scope (`~/.claude/plugins/`, git SHA
-  `0d95a81`) via `claude plugin marketplace add` + `claude plugin install`,
-  per operator instruction. Purpose: terse "caveman-mode" output (~65% fewer
-  output tokens, per its README).
-- Both auto-wired hooks read in full before trusting them (this host holds
-  cloud credentials + reaches juju/MAAS/OpenStack, so a plugin's hooks are a
-  supply-chain surface): `src/hooks/caveman-activate.js` (SessionStart) and
-  `src/hooks/caveman-mode-tracker.js` (UserPromptSubmit). Finding: purely
-  behavioral -- NO network calls, NO credential-file access, NO exfiltration;
-  the only subprocess spawned is the plugin's own stats script, and only on an
-  explicit `/caveman-stats`. Default mode is `full` (auto-arms on session
-  start unless guarded) -- the reason for item 2.
-- **Revert:** `claude plugin uninstall caveman@caveman`; remove the
-  `extraKnownMarketplaces.caveman` + `enabledPlugins."caveman@caveman"` keys
-  from `~/.claude/settings.json`.
-
-## Item 2 -- opt-in guard: CAVEMAN_DEFAULT_MODE=off (repo + user scope)
-
-- Repo `.claude/settings.json`: added an `env` block setting
-  `CAVEMAN_DEFAULT_MODE=off` -- committed, so the intent is durable/shared for
-  this operating clone. Effect: `getDefaultMode()` returns `off`, the
-  SessionStart hook skips activation and clears any stale flag; an explicit
-  `/caveman lite|full|ultra` still activates on demand. `jq` valid, repo-lint
-  0 fail / 1 legacy warn (unchanged).
-- User `~/.claude/settings.json`: same `env` entry added so the plugin is
-  off-by-default in ALL of the operator's repos, not just this one (the plugin
-  is installed user-wide; its bare default is `full`). This file is OUTSIDE the
-  repo -- NOT committed here; recorded for provenance only.
-- Verified `off` is a valid mode (`VALID_MODES` in the plugin's
-  `caveman-config.js`), so the guard is honored rather than silently ignored.
-- **Revert:** remove the `env.CAVEMAN_DEFAULT_MODE` key from whichever
-  settings.json (repo revert via `git revert <sha>` for the committed one; hand
-  edit for the user-level one). With the plugin still installed, removing the
-  guard restores its `full` auto-arm default.
diff --git a/docs/changelog-20260723-stage4-open.md b/docs/changelog-20260723-stage4-open.md
deleted file mode 100644
index 5901d3e..0000000
--- a/docs/changelog-20260723-stage4-open.md
+++ /dev/null
@@ -1,249 +0,0 @@
-# Changelog -- 2026-07-23 -- Stage 4 open: discovery + D-133 carve ruling
-
-Session scope: open Stage 4 (Phase 3, MAAS enlist/commission/deploy per DC) on
-branch `dc-dc-stage4-phase3-maas-deploy` off post-merge `main`. Bootstrap ran
-clean (pull up-to-date at bff71d4; repo-lint 0 fail / 1 legacy warn; ledger-scan
-reconciled -- 12 open SEC rows, D next-free 133). No cloud mutation this session
-yet; everything below is read-only measurement + repo records.
-
-## Item 1 -- Stage 4 OPENED: precondition + discovery (read-only), captured
-
-- Branch `dc-dc-stage4-phase3-maas-deploy` created off `main` (bff71d4).
-- Runbook Step 0 precondition PASS: both DC rack controllers enrolled
-  (vvr1-dc0 `7chphy`, vvr1-dc1 `nmpcq4`).
-- Step 2 discovery complete for BOTH DCs, all read-only, captured to
-  `docs/audit/stage4-discovery-20260723.txt`: 9 nodes per DC, ALL Ready,
-  power=virsh; dc0 = boot fabric-4 / MACs 52:54:00:*, dc1 = fabric-142 /
-  pinned 52:54:01:d1:*; zone/pool `default` everywhere (no zone/pool
-  convention exists -- fabric + MAC prefix is the grouping signal).
-  Also captured: one dc0 node's full physical NIC list (6 flat per-plane
-  NICs), `default_distro_series=noble`, and the synced boot-resources list
-  (noble ONLY -- no jammy images on the region).
-- Runbook-vs-reality deltas recorded in CURRENT-STATE (the runbook predates
-  Stage 3's execution): Step 3 commissioning already satisfied; carve comes
-  BEFORE deploy per the runbook's own Ready-state sequencing note; gap #6
-  (pod-discovery landing status) is moot -- the pod path was refuted 2026-07-20.
-- **Revert:** `git branch -D dc-dc-stage4-phase3-maas-deploy` (after moving off
-  it); delete `docs/audit/stage4-discovery-20260723.txt`; revert the
-  CURRENT-STATE Stage-4 bullet. No live state was touched.
-
-## Item 2 -- D-133 ADOPTED: flat per-NIC carve (VR1); hardware-faithful NIC topology next deployment
-
-- New entry `docs/design-decisions.md` D-133 [ARCH], Status ADOPTED 2026-07-23,
-  operator utterance quoted verbatim per GA-R5 ("Fine, keep it flat but on the
-  next deployment we need to build the VMs with exact hardware duplicated
-  networking so we can work out any bonding/trunking kinks.").
-- Part 1: VR1 DC nodes carve every plane FLAT on its dedicated NIC; no
-  VLAN-103 stack in VR1 (supersedes the D-052-era Pattern A shape for VR1 DC
-  nodes only; VR0 untouched).
-- Part 2 (pinned to next deployment): node VMs duplicate target hardware's
-  exact NIC topology (bond members, trunks) -- composes with D-132.
-- Affected-surfaces list recorded IN the entry (buildout-design VID-103 text,
-  workflow Stage 4 row, phase3 runbook Step 5 tree, lib-net vr1-dc0 arm's
-  inherited METAL_INTERNAL_VID) -- queued as this stage's DOCFIX/delivery work,
-  not silently edited.
-- CURRENT-STATE section 1 updated in the same commit (GA-R1 C1): Stage 4 OPEN
-  bullet with discovery facts + the open decision points (deploy OS series,
-  octet plan, mirror gap #5, tag shape).
-- **Revert:** remove the D-133 block from design-decisions.md and the Stage-4
-  bullet from CURRENT-STATE.md (single commit; `git revert <sha>`).
-
-## Item 3 -- D-134 ADOPTED: per-role octet bands for VR1 DC node statics
-
-- New entry `docs/design-decisions.md` D-134 [ARCH], ADOPTED 2026-07-23.
-  Sequence per GA-R5: the flat .40-.48 proposal was presented and REJECTED
-  ("Different band"); operator directed "Per role bands with headroom. Give me
-  a recommendation"; the recommended band table was presented with measured
-  collision checks (bundle VIPs .50-.60 grep, 10.12.12.4, FIP pool, D-120
-  dynamic range) and adopted ("Adopt as recommended").
-- Bands: .1-.9 infra (.4-.9 utility-reserved), .10-.19 control, .20-.49
-  compute, .50-.99 formal VIP band, .100-.200 dynamic (D-120), .201-.254
-  storage. One octet per node across all six planes, both DCs; VR1
-  assignments control .10-.12 / compute .20-.21 / storage .201-.204 keyed by
-  tofu node name via pinned boot MAC.
-- CURRENT-STATE Stage-4 bullet updated in the same commit (octet plan RULED;
-  carve now unblocked on D-133 + D-134).
-- **Revert:** remove the D-134 block + the CURRENT-STATE bullet edit
-  (`git revert <sha>`).
-
-## Item 4 -- D-134 AMENDED: contiguous band table (Option B swap)
-
-- Operator rejected the original table's interleaving (node roles split by the
-  VIP + dynamic blocks); movability analysis presented (pinned: .1/.2/.3 live,
-  .50-.60 bundle VIPs, FIP rows 1-3 on provider; movable: the D-120-inherited
-  dynamic range). Option B ruled: nodes get the contiguous .100-.200 run
-  (control .100-.119 / compute .120-.149 / storage .150-.200), dynamic moves
-  to .201-.254, utility .4-.49, VIP .50-.99.
-- VR1 assignments now: control .100-.102, compute .120-.121, storage
-  .150-.153 (identity table unchanged -- tofu name via pinned boot MAC).
-- Consequence queued: the dc0/dc1 metal-admin dynamic-range MOVE is the
-  carve's first gated live mutation per DC (before static assignment; nodes
-  powered off). Office1's own D-120 ranges untouched.
-- CURRENT-STATE Stage-4 bullet updated same-commit.
-- **Revert:** remove the amendment block + CURRENT-STATE edit
-  (`git revert <sha>`); no live state touched yet.
-
-## Item 5 -- Approvals workflow: session-log-keyed permission rules (operator-directed)
-
-- Operator directed session-length approvals mid-carve (manual mode was
-  prompting per command; the earlier auto-mode classifier BLOCKED the first
-  mutation outright -- the known dc1-session behavior, ledger 2026-07-23).
-- `.claude/settings.local.json` (uncommitted, personal): ADDED allow
-  `Bash(script -aqe ~/as-executed/2026-07-23-stage4-carve.log -c *)` (the
-  logged-window wrapper -- inherently session-scoped, the rule names this
-  window's log file) + ask rule keeping `maas admin machine *` shapes
-  (commission/deploy) prompting inside that same wrapper. PRUNED seven dead
-  rules keyed to retired log files (2026-07-21-ops-commissioning-diag,
-  2026-07-22-dc1-deploy).
-- FLAGGED for stage close, not acted on: local allow list carries a broad
-  `Bash(ssh *)` from a prior session -- prune candidate.
-- Review surface stays the as-executed log + this changelog (GA-R2
-  blanket-approval precedent).
-- **Revert:** remove the two added rules from settings.local.json (file is
-  local-only, not committed).
-
-## Item 6 -- Stage 4 carve EXECUTED, both DCs (logged window stage4-carve)
-
-- All mutations in ~/as-executed/2026-07-23-stage4-carve.log (per-command
-  wrap; helper scripts' full content logged verbatim before first use).
-  Verification capture: `docs/audit/stage4-carve-verify-20260723.txt`.
-- Set 0: dc0+dc1 metal-admin dynamic ranges MOVED to .201-.254 in place
-  (iprange ids 2/3; office1 id 1 untouched) -- the D-134-amendment
-  consequence, done before statics.
-- Set 1: 10 named plane fabrics created (vr1-dc0-* ids 188-192 / vlans
-  5189-5193; vr1-dc1-* ids 193-197 / vlans 5194-5198).
-- Set 2: 90 NIC re-homes, one node per approval-unit, read-back each: every
-  non-boot NIC moved from its private auto-fabric to its plane fabric;
-  boot NICs stay fabric-4 (dc0) / fabric-142 (dc1). MACs matched
-  config-of-record pins throughout.
-- Set 3: provider subnets 10.12.4.0/22 + 10.12.64.0/22 MOVED off shared
-  fabric-5 to their per-DC provider fabrics (+ ruled gateways .1); 8 plane
-  subnets CREATED (dc0 12/16/32/36, dc1 72/76/80/84).
-- Set 4: 6 spaces created (bundle binding names verified against
-  bundle.yaml first); 12 untagged VLANs assigned (metal-admin = the two
-  boot fabrics). Office1/transit subnets remain in `undefined` untouched.
-- Set 5: 18 nodes' statics per D-134-amended assignments (control
-  .100-.102, compute .120-.121, storage .150-.153, same octet all six
-  planes) -- five raw-NIC statics + br-ex (OVS, Pattern A) carrying the
-  provider static, provider NIC left raw (D-100). All nodes remain Ready.
-- Residue NOT touched (flagged): fabric-5 still holds 192.168.1.0/24
-  (factory-LAN residue, both edges re-addressed) and the now-empty
-  ex-provider fabric-5 itself; the ~90 empty auto-created fabrics
-  (fabric-98..187 class) also remain -- cleanup candidates, gated
-  separately at stage close, zero functional impact.
-- **Revert:** MAAS-record-level; reverse order: unlink statics + delete
-  br-ex per node, delete the 8 created subnets, move the 2 provider subnets
-  back to fabric-5, unassign spaces + delete the 6 spaces, re-home NICs to
-  auto-fabrics (or delete the 10 named fabrics after), move dynamic ranges
-  back to .100-.200. Nodes were powered off throughout; no OS-level state
-  exists to revert.
-
-## Item 7 -- Deploy-model ruling + DOCFIX-200 + jammy sync + placement tags
-
-- **RULING (operator: "Ready + jammy images (Recommended)"):** Stage 4 ends
-  with nodes READY + carved + tagged; MAAS-deploy is SKIPPED -- Juju
-  provisions Ready machines at Stage 5 and requests the bundle's
-  `default-base` (ubuntu@22.04). The phase3 runbook's Step 4 as written
-  (`maas machine deploy` per node) contradicted phase-01's own precondition
-  ("machines Ready/power=off") and would have made all 18 nodes
-  un-allocatable to Juju. [OPS -- encoded in the proven phase-01 precedent;
-  no D-number.]
-- **DOCFIX-200:** `runbooks/dc-dc-phase3-maas-enlist-deploy.md` Step 4
-  rewritten (tag + base-image sync, nodes STAY Ready; ruling quoted),
-  sequence table line + GATE "Nodes deployed" bullet corrected against
-  the buildout-design wording.
-- **Jammy images:** boot-source selection id=2 (ubuntu/jammy amd64) created
-  on source 1 + import triggered; `ubuntu/jammy` reads Synced (re-verify at
-  close while sub-resources finish).
-- **RULING (operator: "Adopt per-DC tags (Recommended)"):** deploy-placement
-  tags are region-qualified per-DC -- `openstack-vr1-dc0` /
-  `openstack-vr1-dc1` (D-119 naming), applied 9+9, add=9/remove=0 both.
-  Stage 5's per-DC bundle parameterization constrains on them.
-- **RULING (operator: "Build the mirror now"):** the D-107 per-DC artifact
-  mirror gets BUILT in-stage (rehearsal exception REJECTED); Stage 4's
-  mirror gate bullet stays OPEN until it exists and nodes' reachability is
-  verified. Design presented as its own decision (D-135 candidate).
-- Queued findings: `phase-00-maas-standup.sh`'s hardcoded PLANES table
-  asserts the VR0 VLAN-103 shape and would false-DRIFT against the ruled
-  D-133 flat carve (Step 8 satisfied instead by the spaces cross-check in
-  the carve capture); Step 7's edge-NTP check text is superseded by the
-  D-129(iv) ruling (MAAS hierarchy stays time authority; nodes measured
-  NTP-ing to their rack during Stage 3 commissioning).
-- **Revert:** runbook edits `git revert`; tags
-  `maas admin tag update-nodes <tag> remove=...` x9 + tags delete;
-  boot-source-selection delete id=2 (images age out).
-
-## Item 9 -- INCIDENT (resolved): dc1 edge passed NO LAN traffic -- pf ruleset never regenerated
-
-- Found at the dc1 mirror install: apt through the edge timed out. Measured
-  chain: rack default route present, edge LAN gw ping 0%, internet 100% loss;
-  `pfctl -s nat` on the dc1 edge showed ZERO outbound NAT rules while dc0's
-  edge (identical config -- both carry the single WAN_GW gateway_item) showed
-  the full automatic set. Root cause: the fresh dc1 edge's pf ruleset was
-  NEVER REGENERATED after v4 addressing -- `opnsense-set-interface-v4
-  --commit` runs `configctl interface reconfigure` but NOT a filter reload.
-  dc0 was masked: its 07-20 plugin/qga work triggered filter reloads as a
-  side effect. My dc0-only egress probe earlier this session was wrongly
-  taken as covering dc1 (symmetry inference -- owned).
-- Fix (minimal, logged): `configctl filter reload` on the dc1 edge -> NAT
-  rules present, rack egress 0% loss / HTTP 301 -- identical to dc0.
-- QUEUED: appendix-A entry (symptom: LAN clients of a freshly-addressed DC
-  edge get 100% loss with reachable gateway; check `pfctl -s nat`); DC-standup
-  DoD addition (filter reload + LAN-client egress probe after edge
-  addressing); candidate opnsense-set-interface-v4 amendment (add the filter
-  reload) -- a built-surface change, presented at stage close, not slipped in.
-- **Revert:** n/a (the reload materializes the edge's own committed config).
-
-## Item 10 -- dc-mirror installed BOTH racks; syncs RUNNING; HOME fix (harness 19)
-
-- dc0: install pass-1 net layer up -> apt debmirror/nginx/ubuntu-cloud-keyring
-  -> install PASS (15 checks; mirror answers http://10.12.8.4/ 200).
-- dc1: same, after the item-9 incident fix (install PASS; http://10.12.68.4/
-  200).
-- First sync attempt FAILED both debmirror runs: "HOME not defined in
-  environment!" under systemd's empty env (debmirror needs a GPG home).
-  Fixed in gen_sync_unit (`Environment=HOME=/root`), harness case T19 added
-  (19/19), REINSTALLED both racks (config-diff regeneration path exercised),
-  syncs restarted: both RUNNING and downloading (dc0 400M / dc1 343M within
-  the first minute). Daily timers enabled.
-- Mirror gate remains OPEN until: initial syncs complete (last-sync.status
-  OK) + mirror serves a real node (node-side probe at Stage 5 first boot or
-  a gated rescue-boot check). Stage 4 close blocks on the mirror gate per
-  the operator's build-now ruling.
-- **Revert:** `systemctl stop/disable <site>-mirror-sync.timer + -net.service`,
-  rm the generated files, `rm -rf /var/lib/dc-mirror`, apt remove the three
-  packages; the edge filter reload stands (item 9).
-
-## Item 11 -- Delivery batch: lib-hosts VR1 arms, D-133 guards, appendix-A, DoD
-
-- **lib-hosts.sh VR1 arms POPULATED** (the runbook's standing delivery item):
-  vr1-dc0/vr1-dc1 blocks with tofu-name-keyed HOSTS, D-134-amended octets,
-  config-pinned boot MACs, per-DC power URIs (ruled step-D shape), per-DC
-  tags; NEW `host_sysid_by_bootmac()` (the VR1 resolver -- MAAS hostnames are
-  random and re-minted; MACs survive re-enlistment); one-selection-per-shell
-  guard (lib-net precedent). dc-selector harness rewritten for the populated
-  arms + identity/guard cases: 48 checks PASS.
-- **D-133 guards:** `reenroll-hosts.sh` + `carve-host-interfaces.sh` now
-  REFUSE vr1-* explicitly (VR0 flows: hostname-keyed re-enroll / Pattern-A
-  VLAN-103 carve, both superseded for VR1) -- without the guard, populated
-  VR1 arms would have let VR0 mechanics run against VR1 fleets. Harnesses
-  updated to the refusal messages. Gauntlet **ALL GREEN (77)** after.
-- **lib-net vr1-dc0 arm:** D-133 caveat comment -- inherited
-  METAL_INTERNAL_VID/IFACE are VR0 carve artifacts; never consume for VR1.
-- **appendix-A:** new entry for the edge-pf symptom (LAN 100% loss, gateway
-  fine, `pfctl -s nat` empty; masking trap named). **DoD:** items 8 (filter
-  reload + LAN egress probe) and 9 (dc-mirror install/sync) added; item 4's
-  dynamic-range position corrected to the D-134-amended .201-.254.
-- **Revert:** `git revert <sha>` (repo-only; no live state).
-
-## Item 8 -- OWNED: pipe-masked L10 lint FAIL on the D-135 commit (abd6b92)
-
-- The D-135 commit changed a design-decisions Status line WITHOUT
-  CURRENT-STATE in the same commit (GA-R1 C1 / lint L10) and shipped anyway:
-  my lint invocation piped through `tail`, masking the nonzero exit --
-  the EXACT defect the 2026-07-23 queue-pass session owned same-hour
-  yesterday. Repeated; owned.
-- Repair: this commit carries the owed CURRENT-STATE update (post-carve
-  rulings + D-135 + refreshed NEXT line). Practice fixed in-session: lint
-  exit now checked via PIPESTATUS, never inferred from tail output.
-- **Revert:** n/a (repair commit).
diff --git a/docs/changelog-20260724-caveman-disable.md b/docs/changelog-20260724-caveman-disable.md
deleted file mode 100644
index 1b0c5d9..0000000
--- a/docs/changelog-20260724-caveman-disable.md
+++ /dev/null
@@ -1,225 +0,0 @@
-# Changelog -- 2026-07-24 -- caveman plugin: disable on live host + governance + guardrails
-
-Session scope: acting on a 4-seat council review of the third-party `caveman`
-Claude Code plugin (installed + off-by-default-guarded 2026-07-23, commit
-338c919). Operator accepted the review recommendations (exact utterance: "I'll
-accept your recommendations"). Harness-config + repo-governance only -- NO cloud
-mutation, NO runbook change. CURRENT-STATE deliberately untouched (adding a SEC
-row is not an L10 trigger; the G14 open-SEC count reconciles at Stage 4 close --
-see item 2). Council finding that drove the disable: `enabled:true` runs
-third-party `node` on every session start + every prompt REGARDLESS of
-`CAVEMAN_DEFAULT_MODE=off` (the env guard gates arming/terse-output, not hook
-execution), and the plugin's own honest docs put net token savings at
-break-even-to-negative on this host's gated-approval workload -- so a standing
-per-turn execution surface on a credential-bearing jumphost was not worth
-carrying.
-
-## Item 1 -- caveman DISABLED on the live host (enabled:false, both scopes)
-
-- `~/.claude/settings.json` (user scope, authoritative for vcloud):
-  `enabledPlugins."caveman@caveman"` flipped `true` -> `false`. Stops the
-  SessionStart + UserPromptSubmit hooks from wiring at the next session start.
-- `/home/jessea123/openstack-caracal-dc-dc/.claude/settings.json` (committed
-  repo scope): added `enabledPlugins {"caveman@caveman": false}`. Project scope
-  outranks user scope (Local > Project > User), so this is a fail-closed,
-  travels-with-the-clone off-switch across the operator's workstations --
-  mirrors the dual placement used for the env guard.
-- `CAVEMAN_DEFAULT_MODE=off` retained in both files as a residual layer; the
-  `extraKnownMarketplaces.caveman` entry RETAINED (plugin stays installed) so a
-  deliberate re-enable for hardened-workflow deployment testing remains cheap.
-- Verified: both settings.json parse (`jq`); user + repo
-  `enabledPlugins."caveman@caveman"` = `false`; no `~/.claude/.caveman-active`
-  flag (not armed). repo-lint 0 fail / 1 legacy warn (unchanged).
-- **Revert:** set both `enabledPlugins."caveman@caveman"` back to `true`
-  (repo copy via `git revert`/edit; user copy by hand). Note: re-enabling
-  re-incurs the SEC-017 re-verify duty.
-
-## Item 2 -- SEC-017 opened (supply-chain re-verify obligation)
-
-- Added row **SEC-017** to `docs/security-ledger.md` (next-free by grep;
-  highest prior = SEC-016). Records the standing third-party per-turn
-  code-execution surface, its point-in-time benign verdict at SHA `0d95a81`,
-  the not-declaratively-pinnable caveat, the disable disposition, and the
-  STANDING DUTY to re-verify the hooks on any re-enable or plugin update.
-- Register call = OPS (no D-number): fails GA-R3's Roosevelt-delta / A1 grep
-  test (no bare-metal analog of a jumphost output-style plugin); precedent
-  D-129 (OPS plugin-install stays OPS). The SEC row is the durable home the
-  security-ledger mandate requires ("a row at discovery, never only a note") --
-  the prior changelog (338c919) is GA-R2 non-citable/archive-bound, so the
-  posture had no durable home before this.
-- Count: open SEC rows 12 -> 13. This is NOT an L10 status-couple trigger
-  (L10 fires on docs/audit/*, design-decisions Status lines, and session-ledger
-  gate rows -- not security-ledger.md), so CURRENT-STATE is untouched; the G14
-  count reconciles at Stage 4 close per its existing deferral pattern.
-- **Self-measured drift baseline (sha256, 2026-07-24; executing cache copy ==
-  git clone at `0d95a81`, only a `.in_use` runtime marker differing):**
-  - `src/hooks/caveman-activate.js`        `bc0af3ba327657630e5f6c60be619e6b5394bf03edc29b1384a15f09a1b348bf`
-  - `src/hooks/caveman-mode-tracker.js`    `3e34f004d4a9e65609f8c95b47dfe5f0e3a6f2d16b88c7f8af730187ee2fb246`
-  - `src/hooks/caveman-config.js`          `f47fe2e6440578eeb20408bc3131b63fb8e1ae4f6ea26dbdcca33e7901e5ee8c`
-  - `src/hooks/caveman-stats.js`           `433a345a279c2d54be51864ef77c0a7b19d0f8604b9a441ce0a1eded31f113e8`
-  - `src/hooks/cavecrew-model-overrides.js` `9f2601e8551653609f0b9d700c9bd75bffa43747d2db18ffe83fb73de5dc3607`
-  - `.claude-plugin/plugin.json`           `b76999bd244fa59c2b8805b1c2b573458e2d065b58e5904fc8e9e545e3dac7a6`
-- **Revert:** delete the SEC-017 row from `docs/security-ledger.md`
-  (`git revert <sha>` for the commit).
-
-## Item 3 -- guardrails: repo-lint L11 + fail-closed compress prohibition
-
-Council-reviewed guardrail set. (a) a repo-lint hash-baseline of the plugin
-files was REJECTED (layering violation -- the plugin lives outside the repo
-under `~/.claude`, non-portable across workstations, and duplicates the
-plugin's own `checksums.sha256`; drift-on-update belongs in the SEC-017
-re-verify duty, not repo-lint). Built (b) and (c):
-
-- **(b) repo-lint L11 -- caveman-compress residue detector.** `scripts/repo_lint.py`
-  gains L11: FAIL on any `*.original.md` in the tree (the backup signature of a
-  lossy in-place `/caveman-compress` rewrite). Excludes `.git`, `.claude`
-  worktrees, `.terraform`, `__pycache__` (reuses the `all_text()` skip set);
-  opt-out marker `repo-lint: allow-original-md` per the L9 convention. Docstring
-  catalog + `repo-lint.sh` header updated L1-L10 -> L1-L11. Harness
-  `tests/repo-lint/run-tests.sh` gains T42 (residue FAILS), T43 (opt-out
-  suppresses), T44 (worktree excluded): **45/45 PASS** (was 42). It is a
-  POST-HOC detector (the original is already overwritten when the backup
-  exists) -- it complements, not replaces, (c).
-- **(c) fail-closed compress prohibition.** Mechanism measured read-only:
-  `/caveman-compress <file>` is a SKILL that mutates by running
-  `python3 -m scripts <file>` from the skill dir (in-place overwrite +
-  `<name>.original.md` backup). Two layers added: (1) `.claude/settings.json`
-  `deny` rules `Bash(*python3 -m scripts*)` + `Bash(*caveman-compress*)` --
-  verified no legit repo usage collides (the strings appear only inside
-  `repo_lint.py`'s L11 text, never in an executed argv); (2) a CLAUDE.md
-  "Tooling guardrails" section prohibiting the compressor against ANY
-  repo-tracked prose file, scoped to the whole record corpus (not a 4-file
-  hand-list, which would rot). Note the pre-existing `Skill(*)` ask rule already
-  gates the skill invocation itself; the deny is the fail-closed backstop that
-  does not depend on that routing.
-- Net enforcement stack: plugin DISABLED (item 1) is primary; `Skill(*)` ask +
-  the compress `deny` gate invocation; L11 catches residue; CLAUDE.md is the
-  human-readable rationale.
-- Verification: `jq` valid; all touched files ASCII/LF; repo-lint 0 fail / 1
-  legacy warn; `bash scripts/run-tests-all.sh` -> **GAUNTLET: ALL GREEN
-  (77 harnesses)**.
-- **Revert:** `git revert <sha>` -- removes L11 (+ its 3 harness cases), the two
-  `deny` rules, and the CLAUDE.md section together.
-
----
-
-(Session continued into the VR1 DC-mirror work -- distinct topic, same session, so
-per GA-R2 it lands in this one changelog.)
-
-## Item 4 -- DC1 debmirror PAUSED; bandwidth measured NOT the bottleneck
-
-- Operator asked to pause one sync so a single mirror completes before tomorrow,
-  on the premise the two syncs share the vcloud uplink. PAUSED dc1 (live):
-  `systemctl stop dc1-mirror-sync.service dc1-mirror-sync.timer` on the dc1 rack;
-  debmirror killed (0 procs), held at **329.9 GiB** (resumable; status left stale
-  "RUNNING"). Timer stopped so it cannot auto-restart and re-contend.
-- MEASURED result: pausing dc1 did NOT speed dc0 up -- solo dc0 averaged ~37 GiB/h
-  vs ~35 GiB/h while contended. So the vcloud uplink is NOT the binding
-  constraint (it is per-connection/per-file, dominated by universe's small-package
-  tail). The pause neither helped nor hurt dc0; dc0 is on track (~70% at
-  2026-07-24T15:35Z, ETA ~this evening UTC). This finding fed the DC1 decision
-  (item 5): rather than idle dc1, switch it to a caching proxy.
-- **Revert:** resume dc1's full sync -- on the dc1 rack:
-  `systemctl daemon-reload && systemctl start dc1-mirror-sync.service dc1-mirror-sync.timer`
-  (debmirror resumes from 329.9 GiB, skipping downloaded files).
-
-## Item 5 -- DC1 interim apt caching proxy: D-135 amendment + dc-cache-proxy.sh
-
-- **D-135 AMENDED 2026-07-24 (GA-R5, operator utterance quoted in
-  design-decisions.md):** DC1 gets an INTERIM apt caching proxy to unblock its
-  build now; DC0 stays the full-mirror deployment under test; DC1 proxy REPLACED
-  by a full mirror afterward. Both artifact-delivery models exercised this
-  rehearsal (Roosevelt input, D-132/D-133). The paused dc1 debmirror (~330 GiB)
-  is KEPT dormant as the fallback, not deleted.
-- **Shipped `scripts/dc-cache-proxy.sh`** (site-keyed check/install; apt-cacher-ng
-  in proxy mode at the D-134 utility `.4:3142`, consumed via
-  `juju model-config apt-http-proxy=http://<LISTEN>:3142`; caches archive +
-  security + UCA with no per-repo remap). REUSES the `<site>-mirror-net.service`
-  net layer (does not re-create it; fails loud if absent, pointing at dc-mirror.sh).
-  Feasibility recon confirmed read-only first: apt-cacher-ng installable
-  (`3.7.4-1ubuntu5.24.04.1`), all three upstreams 200 via the edge, port 3142 free.
-- **Harness `tests/dc-cache-proxy/run-tests.sh`** (15 static cases: syntax, both
-  sites' utility .4 + ruled edge gw, stable-identity keying, port pin, proxy-mode
-  consumption, archive+UCA smoke coverage, net-layer reuse, MEASURED-tag
-  discipline, arg/site validation) -- **15/15 PASS**.
-- CURRENT-STATE Stage-4 narrative updated (DC0/DC1 artifact-path split). repo-lint
-  0 fail / 1 legacy warn; `bash scripts/run-tests-all.sh` -> **GAUNTLET: ALL GREEN
-  (78 harnesses)** (was 77; +tests/dc-cache-proxy).
-- Live install on the DC1 rack (`apt-get install apt-cacher-ng` + `dc-cache-proxy.sh
-  install dc1`) DONE + verified 2026-07-24 (gated): apt-cacher-ng
-  `3.7.4-1ubuntu5.24.04.1` active on `.4:3142`, drop-in matches, net layer present,
-  **check PASS 8/8 -- proxy serves archive (200) AND UCA caracal (200)** (UCA cached
-  with no remap, as expected in proxy mode). NOTE: the DC1 rack reports a pending
-  kernel reboot (running 6.8.0-134 vs installed -136) -- pre-existing, deferred to a
-  maintenance window (a reboot would disrupt the paused mirror).
-- **Revert:** `git revert <sha>` (removes the script, harness, D-135 amendment
-  paragraph, and CURRENT-STATE split); if installed live, on the dc1 rack:
-  `systemctl disable --now apt-cacher-ng; rm -f /etc/apt-cacher-ng/acng.conf.d/dc1-cache-proxy.conf`.
-
-## Item 6 -- phase-4 runbook: per-DC MAAS service-credential step (Step 2.0)
-
-- Operator-directed: the MAAS API key Juju needs is created by NO prior stage --
-  a standing DEPLOYMENT-TIME task, so it belongs in the runbook. Added **Step 2.0**
-  to `runbooks/dc-dc-phase4-juju-bundle-per-dc.md` (before the bootstrap MUTATION):
-  create a DEDICATED per-DC MAAS admin service user (`sudo maas createadmin`) +
-  issue its own API key (`sudo maas apikey --generate`) -- per-DC credential
-  isolation (SEC-012/-016; Roosevelt: per-DC cloud creds), never a cross-DC reuse.
-- **Creds location corrected (operator-directed):** the key stages in the JUMPHOST
-  per-site creds folder (`~/vr1-<dc>-creds/maas-api-key.txt` on vcloud, SEC-009
-  convention) -- NOT a new location on the region (voffice1) as the first
-  walkthrough had it. Generated FROM the jumphost so it transits ssh stdout with
-  no persistent copy on the region; never printed (SEC-006); consumed by Juju via
-  path/stdin, never argv. Each issued key = a per-DC SEC rotation row.
-- Revert: `git revert <sha>` (removes Step 2.0). No live/cloud state touched.
-
-## Item 7 -- Per-DC MAAS service credentials created (SEC-018/-019) [CLOUD MUTATION, driven]
-
-- Executed phase-4 Step 2.0 for both DCs (operator: "You drive it"), logged
-  window `~/as-executed/2026-07-24-dc-maas-creds.log`. Passwordless sudo on
-  voffice1 confirmed; `maas createadmin --password` supported (read-only precheck).
-- Created dedicated MAAS superusers **`juju-vr1-dc0`** and **`juju-vr1-dc1`**
-  (random passwords generated ON the region, UNSTORED -- Juju auths via the API
-  key), and staged each user's API key into the vcloud per-site folder:
-  `~/vr1-dc0-creds/maas-api-key.txt` and `~/vr1-dc1-creds/maas-api-key.txt` (0600).
-  Keys generated FROM the jumphost (no persistent region copy), verified by
-  FORMAT ONLY (both parts=3, 70 chars), never printed. Result fail=0.
-- **SEC-018** (dc0 key) + **SEC-019** (dc1 key) opened -- per-DC rotation
-  obligations (open SEC 13 -> 15; reconciled at Stage 4 close per the G14 pattern).
-  as-executed index entry added (log itself stays uncommitted, secret-adjacent).
-- Revert: on voffice1 `sudo maas apikey --username=juju-vr1-dc0 --delete=<key>`
-  (+ dc1) and `sudo maas deleteuser juju-vr1-dc0` (+ dc1); `shred -u` the two
-  vcloud key files; `git revert <sha>` for the SEC/index/changelog rows.
-
-## Item 8 -- dc1 VIP overlay drafted (overlays/vr1-dc1-vips.yaml)
-
-- Operator OK'd the overlay approach (vs editing bundle.yaml in place). Drafted
-  `overlays/vr1-dc1-vips.yaml`: re-homes the 11 API-service VIPs from bundle.yaml's
-  vr1-dc0 bands into vr1-dc1's MEASURED bands (lib-net vr1-dc1 PLANE_NAME):
-  provider-public 10.12.4 -> 10.12.64, metal-admin 10.12.8 -> 10.12.68,
-  metal-internal 10.12.12 -> 10.12.72; host octets .50-.60 unchanged. Base
-  bundle.yaml stays the vr1-dc0 source of truth; overlay applied only for the dc1
-  deploy (`juju deploy ./bundle.yaml --overlay ./overlays/vr1-dc1-vips.yaml`).
-  YAML valid (11 apps), repo-lint 0 fail.
-- Revert: `git revert <sha>` (removes the overlay). No live/cloud state.
-
-## Item 9 -- Juju client setup on voffice1 (cloud + credentials) [client config, not a cloud mutation]
-
-- **Juju client location = voffice1** (operator-ruled after reconsideration): the
-  Office1 headend has a Roosevelt analog and D-128 runs MAAS-facing work there so
-  runbooks read "from the headend"; vcloud (substrate host) has no Roosevelt
-  analog, so driving the cloud from it would not transfer. Juju 3.6.25 (3/stable,
-  matches VR0 + the bundle's Juju 3.6 target) installed on voffice1; removed from
-  vcloud.
-- `juju add-cloud --client vr1-maas` -- the ONE Office1 MAAS region
-  (type=maas, endpoint `http://10.10.0.20:5240/MAAS`). `juju add-credential`
-  both DCs: `vr1-dc0-cred` + `vr1-dc1-cred` from the staged keys, piped
-  vcloud->voffice1 into a home-dir yaml (snap can't read /tmp), never printed,
-  `shred -u`'d. Juju credential store on voffice1 now holds runtime copies (noted
-  on SEC-018/-019; canonical files stay on vcloud). Credentials validate at
-  bootstrap (juju does not pre-validate).
-- Two snap gotchas measured + worked around: the juju snap has a private /tmp
-  (stage bundle/overlay/cred files under $HOME); voffice1 ssh sessions have
-  per-session /tmp. Both relevant to the deploy steps.
-- Revert: `ssh voffice1 'juju remove-credential vr1-maas vr1-dc0-cred; juju
-  remove-credential vr1-maas vr1-dc1-cred; juju remove-cloud --client vr1-maas'`;
-  `git revert <sha>` for the SEC/changelog rows.
diff --git a/docs/changelog-20260724-stage5-committee-fork1.md b/docs/changelog-20260724-stage5-committee-fork1.md
deleted file mode 100644
index c465909..0000000
--- a/docs/changelog-20260724-stage5-committee-fork1.md
+++ /dev/null
@@ -1,294 +0,0 @@
-# Session changelog 2026-07-24 -- Stage-5 bundle-render committee + Fork-1 ruling
-
-Branch `dc-dc-stage4-phase3-maas-deploy`. Session resumed the DC1 Stage-5
-bundle-rework blocker under a committee review (operator-requested). Status lives
-ONLY in `docs/CURRENT-STATE.md` (GA-R1); this changelog is the review surface --
-each item states what / why / revert. No cloud state was mutated this session.
-
-## Item 1 -- Committee record (Track 2 bundle render)
-
-**What:** new `docs/audit/committee-20260724-track2-bundle-render.md` -- a 4-lens
-(Roosevelt-delta / HA-DR / operational-risk / Juju-MAAS-mechanism) read-only
-committee review of the vr1-dc1 deploy-artifact render, with the adjudication and
-open operator decisions. Advisory/audit record; adopts nothing (GA-R5).
-**Why:** operator: "Deploy a committee to review Track 2 and provide
-recommendations based on overall end project goals and decisions already
-researched." Durable, citable authority (commissioning-committee precedent).
-**Revert:** `git rm docs/audit/committee-20260724-track2-bundle-render.md`.
-
-## Item 2 -- Capacity gate capture (Fork-1 option a)
-
-**What:** new `docs/audit/stage5-controller-capacity-20260724.txt` -- captured
-`scripts/dc-dc-whole-host-budget.py` runs: baseline built layout 3+2+4 x2 DC =
-838/1024 GiB (82%, FIT); +controller (+8 GiB/+4 vCPU per-DC containment overhead)
-= 854/1024 GiB (83%, FIT, 170 GiB headroom). Read-only calculator; nothing
-queried live.
-**Why:** GA-R1 -- the Fork-1 (a) capacity claim must be MEASURED, not inferred
-(the signed doc's 790/77% is the OLD 8-node layout). Gate = PASS.
-**Revert:** `git rm docs/audit/stage5-controller-capacity-20260724.txt`.
-
-## Item 3 -- D-104 amendment (Fork-1 ruling: dedicated 10th controller VM)
-
-**What:** appended a D-104 amendment (2026-07-24) in `docs/design-decisions.md`
-recording the operator's GA-R5 ruling -- the per-DC Juju controller is a DEDICATED
-10th node VM (distinct tag `juju-controller-vr1-dc1`, no role tag), separate from
-the 9 Option C role nodes; additive (`for_each`-keyed); capacity gate PASS
-(cites item 2); the 9-node D-121 layout is unchanged.
-**Why:** Fork 1 was the blocking architectural decision; operator selected
-"Dedicated 10th VM (Recommended)" over shrink-a-role and co-locate. Controller
-placement is D-104's subject; recorded as its amendment (not a new D-number).
-**Revert:** delete the "### D-104 -- AMENDMENT (2026-07-24)" block in
-`docs/design-decisions.md` (git range-diff of this commit).
-
-## Item 4 -- CURRENT-STATE Stage-4 bullet update (GA-R1 / C1)
-
-**What:** rewrote the Stage-4 bullet's render sub-bullets: committee-adjudicated;
-Fork 1 RULED (a) + capacity gate; Fork 2/3 as OPS committee-unanimous
-recommendations (gated at execution); BUNDLEFIX-052 fixed; a corrected NEXT list.
-Also corrected an earlier inaccurate characterization (dc-ha-scaleup is not "stale
-ceph-osd 3" -- it deliberately excludes ceph-osd) and the "consumes 1 of 9"
-arithmetic (now a dedicated 10th VM).
-**Why:** GA-R1/C1 -- a status-changing commit updates CURRENT-STATE in the SAME
-commit (repo-lint L10). Status authority stays single-sourced.
-**Revert:** restore the prior Stage-4 bullet text (git range-diff of this commit).
-
-## Item 5 -- BUNDLEFIX-052: ceph-rbd-mirror duplicate `bindings:`
-
-**What:** removed an orphaned 4-space-indented `bindings:` block in `bundle.yaml`
-(old line ~907) that `yaml.safe_load` take-last had absorbed into `ceph-rbd-mirror`,
-clobbering its real `ceph-local`/`ceph-remote` (replication) + `nrpe-external-master`
-bindings (D-108/D-052) and injecting a phantom `dashboard` binding (a charm with no
-such endpoint) -> `juju deploy` validation reject.
-**Why:** confirmed pre-existing latent defect (committee mechanism lens; verified
-via `yaml.safe_load`). Fork-independent; fix now so the dc1 render starts clean.
-**Validation:** `yaml.safe_load` confirms `ceph-rbd-mirror.bindings` restored to
-`{'': metal-admin, ceph-local: replication, ceph-remote: replication,
-nrpe-external-master: metal-internal}`; `provider-bundle-check.py bundle.yaml` PASS.
-**Revert:** re-insert the orphan block after the vault-hacluster comment (not
-advised -- it is the bug).
-
-## Item 6 -- provider-bundle-check.py: overlay merge + per-DC VIP bands + placement invariants
-
-**What:** extended `scripts/provider-bundle-check.py` with (a) `--overlay FILE`
-(juju-like merge, so the checker validates the EFFECTIVE deploy input), (b) `--dc
-vr1-dc0|vr1-dc1` selecting expected VIP bands (default dc0 = base bundle, so an
-un-parameterized run is byte-identical to before), and (c) placement invariants that
-activate ONLY on a role-separated bundle (machines tagged control/compute/storage)
-and self-skip on the base/un-rendered bundle: no dangling `to:`; LXD containers on
-control, ceph-osd on storage, nova-compute on compute; each num_units>=2 app spread
-across that many DISTINCT machines (anti-affinity); ceph-osd == storage count,
-nova-compute == compute count. Dropped the "controller-tag" idea (the controller is
-the bootstrap machine, not a bundle machine -- verified at the MAAS-tagging step).
-**Why:** the committee's non-negotiable "spine" -- the checker was placement-blind,
-so any render could silently ship decorative HA. Makes the hand-render machine-checked;
-also closes the committee's dc1-VIP-outside-the-check gap.
-**Caveat (VERIFY-LIVE):** the checker's machines-block overlay merge MIRRORS juju's
-documented behavior; the actual machines-retag-via-overlay is confirmed at
-`juju deploy --dry-run` before deploy (no offline juju merger exists). Fallback if it
-does not take: inline the dc1 tags into a rendered bundle.
-**Validation:** harness `tests/provider-bundle-check/run-tests.sh` 15/15 (7 new
-behavioral cases). Gauntlet ALL GREEN (78). repo-lint 0 fail.
-**Revert:** `git checkout <this-commit>~ -- scripts/provider-bundle-check.py
-tests/provider-bundle-check/run-tests.sh`.
-
-## Item 7 -- vr1-dc1 bundle render (9-node role-separated) + retag overlay
-
-**What:** rendered `bundle.yaml` from VR0's 4-node hyperconverged layout to VR1 dc1's
-9-node role-separated one: machines block "8"-"11" (`tags=openstack`) -> "0"-"8" with
-role+DC tags (block style -- flow `{...}` would split the comma-tag); every app `to:`
-re-homed (mysql/ovn-central/ceph-mon -> control 0/1/2; nova-compute 3->2 on compute 3/4;
-ceph-osd -> storage 5/6/7/8; the 14 scaled apps -> control placeholder that the overlay
-spreads; utilities -> control); ovn-chassis MACs -> the 2 dc1 compute provider NICs.
-Rendered `overlays/dc-ha-scaleup.yaml` tokens -> logical control ids 0/1/2 (now
-DC-neutral) + updated its header + fixed the stale ceph-osd-3 comment. New
-`overlays/vr1-dc1-machines.yaml` (per-DC retag; machines-overlay merge is VERIFY-LIVE at
-`juju deploy --dry-run`).
-**Why:** the committee-adjudicated render (Fork 2 = hand-render now); unblocks the dc1
-Stage-5 deploy. Done as an asserted one-shot line-transform (preserves all D-NNN comments)
-reviewed via git diff + the validator.
-**Validation:** `provider-bundle-check.py bundle.yaml` (base standalone) PASS; the FULL dc1
-deploy input (`--overlay vr1-dc1-machines --overlay vr1-dc1-vips --overlay dc-ha-scaleup
---dc vr1-dc1`) PASS; harness 15/15; gauntlet ALL GREEN (78); repo-lint 0-fail. The
-validator CAUGHT a real render bug (YAML flow-comma dropping the role tag) -- exactly its
-purpose.
-**Revert:** `git checkout <this-commit>~ -- bundle.yaml overlays/dc-ha-scaleup.yaml` +
-`git rm overlays/vr1-dc1-machines.yaml`.
-
-## Item 8 -- provider-bundle-check ovn-chassis role-sep branch + expansion review record
-
-**What:** (a) `provider-bundle-check.py` -- computes `role_sep` early; the ovn-chassis MAC
-check now skips the VR0 openstack0-3 Pattern-A set on a role-separated bundle (verifies
-present + well-formed instead), since dc chassis are the compute-node provider MACs.
-(b) new `docs/audit/stage5-expansion-review-20260724.md` -- three read-only reviewer
-verdicts (relations/bindings/cross-DC; config/pins; deploy-scripts), dispositioned
-(handled / follow-up / VERIFY-LIVE / resolve-before-deploy / no-change).
-**Why:** the operator-requested deployment-script expansion review; captures the
-cross-connection/pinning/gate findings durably so the Chat design session (NetBox-deploy
-coupling) reads them from the repo.
-**Validation:** harness 15/15 (T9's role-sep fixture exercises the ovn role-sep branch);
-gauntlet ALL GREEN (78).
-**Revert:** `git checkout <this-commit>~ -- scripts/provider-bundle-check.py` +
-`git rm docs/audit/stage5-expansion-review-20260724.md`.
-
-## Item 9 -- office1-netbox RECORD dumper (source separation) + current snapshot
-
-**What:** new `netbox/office1-record-dump.py` -- a dedicated READ-ONLY dumper for the
-**office1-netbox RECORD** (the VR1 working apex, `10.10.1.10:8000`, 4.6.4, v2 token),
-separate from `netbox/prod-draft-dump.py` (which pulls the FROZEN v1 reference
-`netbox.baldurkeep.com`). Operator-directed source separation ("one script per source" --
-each holds only its own credential/URL; the token never travels, read from env). Added a
-source-clarity note to `prod-draft-dump.py`'s docstring. New offline harness
-`tests/office1-record-dump/run-tests.sh` (5/5: slim / prefix-scope rewrite / range key /
-source-target). Committed the current snapshot `netbox/draft/vr1-office1-current-20260725.json`.
-**Why:** a Chat design session (NetBox->deploy coupling) has no live infra; the existing
-`vr1-draft.json` is the FROZEN reference (dated 07-15), NOT the current in-cloud state.
-This captures the live apex so Chat designs against current data. Discovery: the standard
-dump targets baldurkeep, not office1-netbox -- corrected before committing wrong-source data.
-**Validation:** dump succeeded READ-ONLY (139 prefixes / 11 sites incl. vr1-dc0/dc1/off1;
-dc1 bands 10.12.64/68/72.0/22 present -- confirms current buildout; differs from the 90-prefix
-frozen reference). Harness 5/5; nothing written to NetBox.
-**Revert:** `git rm netbox/office1-record-dump.py netbox/draft/vr1-office1-current-20260725.json
-tests/office1-record-dump/run-tests.sh` + restore `prod-draft-dump.py` docstring.
-
-## Item 10 -- dc-mirror upstream-host preference note (mirror.uoregon.edu)
-
-**What:** added an UPSTREAM HOST NOTE to `scripts/dc-mirror.sh`'s header (operator,
-2026-07-25): PREFER `http://mirror.uoregon.edu/ubuntu/` (closest/fastest for this
-deployment) over `archive.ubuntu.com` for the MAIN archive debmirror -- future change,
-NOT yet applied. Scoped: main archive only (`--host=mirror.uoregon.edu`, root stays
-`ubuntu`); the UCA cloud-archive uses a separate host uoregon does not mirror; applies
-to dc-cache-proxy.sh + the Roosevelt dedicated mirror too; verify jammy coverage before
-flipping. Header comment only -- does NOT change the generated `<site>-mirror-sync` unit.
-**Why:** operator-provided performance preference, logged for a future mirror-tuning
-session (findings LOGGED, not executed mid-step).
-**Revert:** delete the UPSTREAM HOST NOTE block in `scripts/dc-mirror.sh`.
-
-## Item 11 -- full decision reconciliation (record)
-
-**What:** new `docs/audit/decision-recon-20260725.md` -- a 4-lens read-only recon of
-every ruled IP/VLAN/node decision against the authoritative surfaces (office1-netbox
-apex snapshot, lib-net/lib-hosts, bundle/overlays, MAAS carve captures). CURRENT-STATE
-Stage-4 bullet updated (GA-R1/C1) with a pointer + the key findings + a WARNING that
-this doc's section 4 is stale.
-**Why:** operator-requested full decision recon + "what other reconciliations to queue."
-Feeds the Chat NetBox->deploy coupling design and the stage close.
-**Findings (headline):** IP prefix-layer COMPLETE + drift-free; VLANs correctly absent
-(untagged-per-fabric, D-133); GAP = sub-prefix (D-134 bands + 33 VIP addresses, in
-prose/overlays only) -- blocks the coupling. Node/MAC/power drift-free; Fork-3 tags +
-10th VM pending gated. Decision-status: STALE surfaces flagged (CURRENT-STATE section 4
-HIGH; G14 SEC 12->15; phase-4 designate) -- fixes QUEUED (operator-deferred). Recon
-backlog P0-P2 in the record; extend sandbox-fidelity-check.py first.
-**Revert:** `git rm docs/audit/decision-recon-20260725.md` + restore the CURRENT-STATE
-Stage-4 recon bullet.
-
-## Item 12 -- Ruling 1 recorded (GA-R5): address-family policy
-
-**What:** recorded the operator's 2026-07-25 address-family ruling as a dated RULING NOTE
-under `## D-101` in `docs/design-decisions.md` (verbatim question + utterance) + resolved
-the CURRENT-STATE resolve-before-deploy bullet (b). Confirms D-101's matrix; NO amendment.
-**GA-R5 record.** Question: v4-only vs dual-stack for dc1 phase-4. Operator utterance,
-verbatim: "Dual stack to be used where IPv4 is required, IPv6 where IPv6 only makes sense."
-Clarifying, verbatim: "Dual stack deployment for DC0 and DC1. This is the deployment when
-the dual-stack is added".
-**Why:** GA-R5 -- the VIP reconciliation (dependent work) is invalid until this is
-committed+pushed. Closes the v4-only phasing option for both DCs. From the Chat handoff
-pack (`_handoff-not-committed/20-ruling-records.md`, ruling 1); the verbatim was
-transcribed into durable homes (D-101 note + here) rather than left in the delete-after-use
-pack file (committee BLOCKER-1 fix).
-**Revert:** `git revert <commit>` -- deletes the D-101 ruling note + restores bullet (b).
-
-## Item 13 -- Ruling 2 recorded (GA-R5): keystone policy-override VERIFY-LIVE gate
-
-**What:** added a Stage-4 VERIFY-LIVE gate to CURRENT-STATE -- after `dc-ha-scaleup` scales
-keystone to 3, `juju status` must show `PO:` on EVERY keystone unit, never `PO (broken):`.
-**GA-R5 record.** Question: whether to add a VERIFY-LIVE gate confirming the
-`policyd-override` resource lands on every keystone unit after scale-up (a broken override
-is atomic -- the whole policy is discarded, silently reverting every tenant domain-manager
-to a plain user). Operator utterance, verbatim: "dc-ha-scaleup: Yes to the verify-live".
-**Why:** highest-consequence single check in the deploy -- it protects the SCS Domain
-Manager persona (D-051/D-064) the commercial tenant self-service model rests on, and
-failure has no other symptom. Mechanism intact at HEAD (`bundle.yaml` `use-policyd-override:
-true` + `resources: policyd-override` -> `policies/overrides.zip` 3419 bytes;
-`keystone-policy-drift.sh` byte-matches source) -- the gate confirms it SURVIVES scale-up.
-From the Chat handoff pack ruling 2; verbatim transcribed to a durable home (here), not
-left in the delete-after-use pack file.
-**Revert:** `git revert <commit>` -- removes the gate line.
-
-## Item 14 -- D-136 PROPOSED (NetBox-coupled render pipeline) + Ruling 3 recorded (GA-R5)
-
-**What:** appended D-136 (PROPOSED, [ARCH]) to `docs/design-decisions.md` register tail;
-CURRENT-STATE Stage-4 bullet updated SAME COMMIT (C1) -- bullet (c) artifact-shape, the
-coupling bullet -> "PROPOSED as D-136 / option (C)", the FOLLOW-UP gate blockers. Ruling 3
-is recorded INLINE in D-136's "Artifact shape (RULED 2026-07-25)" paragraph with the
-verbatim question + utterance.
-**GA-R5 (Ruling 3).** Question: symmetric (extract dc0 VIPs to an overlay, base VIP-free)
-vs asymmetric (dc0 v6 into base, two renderer modes)? Operator utterance, verbatim: "Your
-question about 1 or 2, go with 1. Base bundle and everything else is applied via overlay."
-Effect: symmetric per-DC overlays; bundle.yaml VIP-free; gates the dc0 VIP extraction.
-**Pack-review committee corrections folded in (2026-07-25):** verbatim inlined into durable
-homes (D-136 paragraph + here), not the delete-after-use pack file (BLOCKER-1); added the
-`VIP_OCTET_MAX=60` sibling constant + the 2nd stale `VIP_COUNT_EXPECT` site; mis-citation
-count corrected to SEVEN. **Chat correction (2026-07-25) folded in:** open question 5
-rewritten -- Jenkins IS the runner (gap VOID); real requirements are webhooks + status-back
-(unverified vs GitBucket); placement OPEN (voffice1/VR1, per-DC agents Roosevelt, D-132/D-105
-caveats); carry-forward `handoff-20260703-open-items.md:159`.
-**Why:** escalates the Fork-2 renderer deferral; scopes the sub-prefix gap fix. PROPOSED --
-operator rules the mechanism.
-**Revert:** `git revert <commit>` -- deletes D-136 + restores the CURRENT-STATE bullets.
-
-## Item 15 -- DOCFIX-201: the dual-VIP decision is D-020, not D-036 (SEVEN sites)
-
-**What:** corrected SEVEN VIP-context citations of `D-036` where `D-020` is meant
-(`## D-020: Dual provider + metal API VIPs`; `## D-036` is the magnum-capi-helm decision):
-`docs/design-decisions.md` (3: the D-121 "problem this fixes" `per D-036`, the `D-009,
-D-036` HA-scaleup table row, the References `D-036 (dual VIPs)`), `docs/CURRENT-STATE.md`
-(the vault-VIP bullet), `docs/audit/decision-recon-20260725.md` (2 backlog rows), and
-`docs/audit/stage5-expansion-review-20260724.md` (in-place with the bracketed marker
-`[corrected DOCFIX-201: D-020, not D-036]`, operator-chosen).
-**Why:** the mis-citation had spread to SIX sites (2 created by the recon itself); the 7th
-(the `D-009, D-036` table row) was caught by the pack-review committee -- the pack listed
-only 6 and its own verify count would have failed at 9. Reading the correct D-020 also
-surfaced that D-020's ratified set includes vault + excludes ceph-radosgw while the deployed
-set does the opposite (fed into D-136).
-**Verify:** `git grep -n "D-036" -- ':!docs/archive' ':(exclude)_handoff-not-committed/*'`
--> 8 hits, all driver/chart/CAPO, zero VIP-context.
-**Revert:** `git revert <commit>` -- text-only across four files, no behavioural effect.
-
-## Item 16 -- DOCFIX-202: buildout-scope section 5 demoted to a D-111 pointer
-
-**What:** `docs/dc-dc-netbox-buildout-scope.md` section 5 presented the per-DC v6 subcarve
-(sub-decision 1) as open/un-ratified at lines 5, 132, 138 -- contradicting the ratified
-pointer already present at line 146 ("RATIFIED as D-111 (2026-07-11)"). Demoted the three
-open-framing sites to acknowledge D-111 (ADOPTED); kept the reasoning below as history.
-**Why:** `## D-111` is ADOPTED 2026-07-11 and names this exact sub-decision; the stale open
-framing misled the Chat seat 2026-07-25 (it treated the subcarve as a blocking trust gate,
-withdrawn only after reading the register). Committee-confirmed the targets; the rest of
-section 5 has no other adopted-decision contradiction.
-**Verify:** `bash scripts/ledger-scan.sh` -- D-111 not under PROPOSED/OPEN; `grep -n
-"un-ratified\|candidate D-111" docs/dc-dc-netbox-buildout-scope.md` -- no hit presenting
-the subcarve as open.
-**Revert:** `git revert <commit>` -- single-file text change, no behavioural effect.
-
-## Item 17 -- DOCFIX-203: mark D-134's superseded original band table in place
-
-**What:** added a `**SUPERSEDED ... do NOT use these bands**` marker immediately above the
-ORIGINAL D-134 band table in `docs/design-decisions.md` (control .10-.19 / compute .20-.49 /
-storage .201-.254), pointing at the authoritative 2026-07-23 AMENDMENT (contiguous: .4-.49
-utility, .50-.99 VIP, .100-.200 nodes, .201-.254 dynamic). Original kept as history.
-**Why:** the amendment header says it supersedes the original, but the original table carried
-NO in-place marker -- a reader grepping `D-134` hits the original first and gets the rejected
-bands. The Chat seat did exactly this 2026-07-25 (one read from a false discrepancy), and the
-band-modelling this coupling (D-136) must do reads these bands. Committee-confirmed.
-**Verify:** `awk '/## D-134:/,/## D-134 -- AMENDMENT/'` shows the marker before the first
-table row.
-**Revert:** `git revert <commit>` -- single text addition, no behavioural effect.
-
-## Next (not done this session; gated)
-
-Commit+push this batch (GA-R5: rulings land before dependent work). Then, each
-operator-gated: per-role MAAS tags; author + apply the 10th controller VM
-(egress OPEN); render the 9-node `bundle.yaml` (re-home base placements, re-scope
-tokens) + extend `provider-bundle-check.py` with placement assertions + wire
-overlays + de-stale phase-4 Step 4; gated `juju bootstrap` (by controller tag,
-egress OPEN) -> deploy. Deploy-time VERIFY-LIVE gates: vault-3-unit HA-on-MySQL,
-hacluster cluster_count:3, dc1 VIPs, CRUSH failure-domain=host.
diff --git a/docs/changelog-20260725-maas-admin-recovery.md b/docs/changelog-20260725-maas-admin-recovery.md
deleted file mode 100644
index 7f53e79..0000000
--- a/docs/changelog-20260725-maas-admin-recovery.md
+++ /dev/null
@@ -1,263 +0,0 @@
-# Session changelog 2026-07-25 -- MAAS admin-account recovery + creds consolidation
-
-Branch `dc-dc-stage4-phase3-maas-deploy`. Operator task: "complete the recovery of
-the MAAS admin accounts ... complete password resets, and save the creds in their
-proper folders so I can retrieve them." Status lives ONLY in `docs/CURRENT-STATE.md`
-(GA-R1); this changelog is the review surface -- each item states what / why / revert.
-
-Measured evidence for every claim below:
-`docs/audit/maas-admin-recovery-20260725.txt` (42 lines, no secret values).
-
-**The task premise was FALSIFIED by measurement before any mutation.** The
-session-ledger's 2026-07-25 "IMMEDIATE NEXT" asserted MAAS web-GUI login "does NOT
-exist ... never minted; no prior task did it". It did exist: the `admin` superuser's
-password was minted 2026-07-13 by `scripts/site-headend-install.sh:452` and is
-MEASURED working (login POST 204 with the stored value, 400 with a wrong-password
-control; `has_usable_password=True`). It was merely root-only on voffice1 at
-`/root/maas-secrets/admin.pass` and never consolidated to `~/vr1-office1-creds/` --
-the SEC-009 miss class, not a missing account. Only the ledger's `juju-*` clause was
-correct. That finding was reported and the scope RE-RULED by the operator before
-execution: **"New account + consolidate only"** -- no existing password rotated.
-
-## Item 1 -- NEW MAAS superuser `operator` (live region mutation, gated)
-
-**What:** minted MAAS superuser `operator` / `jesse.austin@neumatrix.com` on the
-Office1 region for HUMAN GUI login. Password 32-char base64, generated ON vcloud
-straight into `~/vr1-office1-creds/maas-operator-password` (0600), then fed to
-`maas createadmin` over **stdin** -- never in argv, never printed, never in context.
-Verified: account present + `superuser=True`; stored password authenticates (204)
-against a wrong-password control (400).
-**Why:** operator-ruled scope. Gives a human identity distinct from the service
-identity -- until now the only usable GUI login was `admin`, which is simultaneously
-the automation identity (item 6). Note `maas changepassword` has NO `--password`
-flag and `createadmin --password` would place the secret in argv (the shape
-`site-headend-install.sh:452` uses); the stdin path satisfies the SEC-018
-"never printed/echoed/in argv" discipline and is the transferable technique.
-**Revert:** `ssh voffice1 'maas admin user delete operator'` then
-`rm ~/vr1-office1-creds/maas-operator-password` and drop its manifest row (item 3).
-
-## Item 2 -- `admin` password CONSOLIDATED to the jumphost (no rotation)
-
-**What:** copied `voffice1:/root/maas-secrets/admin.pass` ->
-`~/vr1-office1-creds/maas-admin-password` (0600, 28 bytes). Byte-identical,
-sha256-verified both ends. Value moved over ssh into the file; never printed.
-Verified the CONSOLIDATED copy authenticates as `admin` (204).
-**Why:** closes the SEC-009 miss for this secret -- it is now retrievable from the
-operator's own folder instead of being root-only on a VM. Deliberately NOT rotated
-(operator ruling), so **the VM copy REMAINS source-of-record** and the vcloud file is
-a working copy; a future `admin` rotation must update BOTH in one operation or the VM
-copy becomes a stale trap. Recorded in SEC-020.
-**Revert:** `rm ~/vr1-office1-creds/maas-admin-password` + drop its manifest row.
-No loss -- the source-of-record copy on voffice1 was never modified.
-
-## Item 3 -- `creds-manifests/vr1-office1.manifest`: two new declared secrets
-
-**What:** declared `maas-admin-password` (provenance
-`voffice1:/root/maas-secrets/admin.pass` -- the `<vm>:<path>` class the manifest
-format exists for) and `maas-operator-password` (`local`), with a header comment
-recording the mint mechanism, the byte format, and the still-un-consolidated
-residue (item 7).
-**Why:** the manifest is the forcing function -- an undeclared secret is exactly how
-the NetBox token went missing. Declaring makes `creds-audit` enforce presence+mode.
-**Revert:** `git checkout HEAD -- creds-manifests/vr1-office1.manifest`.
-
-## Item 4 -- dc0/dc1 manifest BACKFILL -> `creds-audit` CLEAN on all three sites
-
-**What:** declared the four files that were failing `creds-audit` as UNDECLARED:
-dc0 `maas-api-key.txt` + `vr1-dc0-edge_ed25519{,.pub}`, dc1 `maas-api-key.txt`.
-Provenance `local` for all four (SEC-018/019 state the API keys were generated FROM
-the jumphost so they never persisted on the region; the edge keypair likewise).
-**Why:** `creds-audit` was RED on two of three sites at session open (dc0 3 fails,
-dc1 1 fail) -- the same convention the operator's task is about, so leaving the gate
-red would have been incoherent. The dc0 edge-keypair rows were a KNOWN queued
-finding, named in `creds-manifests/vr1-dc1.manifest:18-20` ("dc0 precedent, whose
-manifest rows are a queued backfill finding") -- this closes it.
-Result: `creds-audit` CLEAN x3 (13/5/8 entries), harness 7/7.
-**Revert:** `git checkout HEAD -- creds-manifests/vr1-dc0.manifest creds-manifests/vr1-dc1.manifest`
-(returns both sites to FAIL).
-
-## Item 5 -- SEC-020 opened (register of record)
-
-**What:** new row in `docs/security-ledger.md` covering (a) the un-consolidated
-VM-minted `admin` password + the falsified "no GUI login" claim, (b) the human/service
-identity conflation that CAUSED the miss, (c) the new `operator` standing credential.
-Status: OPEN -- rotation obligation on TWO region superusers, plus three logged-not-
-actioned residues. Open SEC rows 15 -> 16.
-**Why:** ledger mandate -- every credential exposure/obligation gets a row, never
-only a comment. A new standing credential is a new rotation obligation.
-**Revert:** delete the SEC-020 row.
-
-## Item 6 -- session-ledger: falsified claim corrected + machine block re-seeded
-
-**What:** (a) struck the 2026-07-25 "IMMEDIATE NEXT" block and annotated it
-FALSIFIED + RESOLVED with what was actually true and what was done. (b) Re-seeded the
-machine-derived block from a fresh `ledger-scan.sh`: it was stale on EVERY line --
-open SEC 12 -> **16**, next-free D 133 -> **137** / DOCFIX 200 -> **204** /
-BUNDLEFIX 052 -> **053**, and D-136 was missing from the open-decision list while
-D-071/D-129 were still listed despite being ADOPTED/RESOLVED.
-**Why:** (a) GA-R1 -- a falsified claim left standing misdirects the next session,
-and this one would have sent it to create an account that already existed. (b) my
-SEC-020 changes the count that block carries, so re-seeding is required by this
-change, not added scope; the block's own rule is "regenerate, never hand-edit".
-**Revert:** `git checkout HEAD -- docs/session-ledger.md`.
-
-## Item 7 -- Findings LOGGED, not executed (hard rule 1)
-
-**What:** recorded in SEC-020, no action taken:
-- (i) `voffice1:/root/maas-secrets/{admin.apikey,db.pass,lxd-trust.pass}` remain
-  un-consolidated. `admin.apikey` deliberately NOT copied -- trivially regenerable
-  (`maas apikey --username=admin`) so a second copy is pure added surface;
-  `db.pass`/`lxd-trust.pass` are region infrastructure, outside this task's scope.
-- (ii) the DURABLE fix for the miss class is a `site-headend-install.sh` amendment to
-  consolidate at mint time (the script currently leaves all four secrets on the VM).
-  Queued, unruled -- a script change needs its harness and a ruling.
-- (iii) the human/service conflation is proposable as a D-number, [ARCH] -- still
-  UNASSIGNED after item 9 took D-137 for the credential pipeline; the two are kept
-  separate deliberately (see D-137's "Related, deliberately NOT folded in"):
-  `admin` is both the GUI login and the automation identity (its API key drives the
-  `maas admin` CLI profile across **19 call sites in 4 scripts** --
-  `site-headend-install.sh` 10, `phase-04-network-verify.sh` 5,
-  `phase-04-network-create.sh` 3, `phase-00-teardown-release.sh` 1). Roosevelt-delta:
-  per-identity MAAS separation / audit attribution on a multi-tenant cloud. NOT
-  assigned -- GA-R3 doubt-resolves-DOWN, operator's call.
-**Why:** findings are logged, never executed mid-task.
-**Revert:** n/a (records only).
-
-## Item 8 -- evidence capture
-
-**What:** `docs/audit/maas-admin-recovery-20260725.txt` -- generated, not
-hand-written: user list, Django password-state booleans, both login probes with
-wrong-password controls, the sha256 fidelity compare, file modes/sizes, `creds-audit`
-x3 + harness, and an automation-unaffected check. Machine-scanned for password bytes
-(0 hits) before commit.
-**Why:** GA-R1 rule 2 -- claims are quoted from captured command output, never prose.
-**Revert:** `git rm docs/audit/maas-admin-recovery-20260725.txt`.
-
-## Not done / still open
-
-- `admin`, `juju-vr1-dc0`, `juju-vr1-dc1` passwords UNCHANGED by ruling. The two
-  `juju-*` passwords remain random + unstored; their API keys are load-bearing for the
-  blocked Stage-5 bootstrap and `operator` removes any need to log in as them.
-- `MAAS` and `maas-init-node` are MAAS-internal accounts -- deliberately untouched
-  (`maas-init-node` is also `is_active=False`).
-- Items 7(i)-(iii) above.
-- Pre-existing, NOT touched by this session: CURRENT-STATE G14 SEC count (reads 12,
-  actual 16) and section 4 ("RULED-BUT-NOT-BUILT", flagged comprehensively stale
-  2026-07-25) -- both already operator-deferred to Stage 4 close.
-
-## Item 9 -- D-137 PROPOSED: credential mint-and-consolidate pipeline [ARCH]
-
-**What:** new `docs/design-decisions.md` entry D-137, PROPOSED (not ruled, not
-implemented). Answers the operator's follow-up ask -- a better minting/saving method
-plus "a durable rule to make sure when accounts are created there is a consolidation
-that happens every time". Records the measured diagnosis, a three-part proposal (the
-invariant; `creds-mint.sh` + `creds-audit --all/--remote` + gate wiring +
-`site-headend-install.sh` amendment; the Roosevelt delta), and THREE open forks.
-Section 8 of CURRENT-STATE gains item 9; the ledger's machine block goes 4 -> 5 open
-decisions.
-**Why:** the diagnosis is that the existing SEC-009 control **cannot detect the failure
-class it was built for** -- the audit is DECLARATION-based, so an undeclared secret is
-structurally invisible. `creds-audit vr1-office1` reported CLEAN on 2026-07-15 while
-four secrets minted on the region VM on 2026-07-13 sat undeclared; `admin.pass` surfaced
-only 2026-07-25, twelve days later, and only because a task went looking (SEC-020).
-Compounding it: no `--all` (`creds-audit.sh:25` takes one mandatory site), and the only
-enforcement is PROSE at `runbooks/dc-dc-phase3-maas-enlist-deploy.md:498` -- absent from
-preflight/cloud-assert/repo-lint/gauntlet -- which demonstrably did not fire at either DC
-standup (dc0 3 + dc1 1 undeclared at this session's open). Admitted as a D under GA-R3 on
-the A1 test: Roosevelt mints per-DC IPMI/BMC and Vault material on real hardware, so a
-Roosevelt build session should grep this before creating any credential; today the rule
-lives only in `docs/security-ledger.md`, a register of exposures, which no gate can cite
-as authority.
-**Deliberately NOT done:** no tooling built, no enforcement wired, no SEC-009 demotion --
-PROPOSED means present options, never implement (hard rule 1 + GA-R5). The SEC-020
-identity-conflation question is kept SEPARATE to avoid batching two rulings.
-**Revert:** delete the D-137 block from `docs/design-decisions.md`, CURRENT-STATE
-section 8 item 9, and the ledger machine-block D-137 clause (restore count to 4).
-
-## Item 10 -- SEC-021/-022/-023 opened: live credential defects found during D-137 research
-
-**What:** three new `docs/security-ledger.md` rows recording defects MEASURED read-only
-while researching the credential matrix. None actioned (hard rule 1). Open SEC rows
-16 -> 19; CURRENT-STATE G14's evidence cell reconciled to 19 in this commit (its title
-text keeps the 07-23 figure and is marked superseded); ledger machine block re-seeded.
-- **SEC-021 -- dc0 custody defects.** (a) `changelog-20260719-dc0-deploy-stepB.md:263`
-  records the dc0 edge REST API credential written to `~/vr1-dc0-creds/opnsense-api.txt`;
-  a `find` over vcloud `$HOME` returns that filename for office1 and dc1 ONLY -- no dc0
-  copy -- and `creds-audit vr1-dc0` reports CLEAN because it was never manifested.
-  Severity is a custody/record defect + API-access gap, NOT a lockout: the dc0 edge SSH
-  key is present and D-112(c) makes key-only SSH the primary management path. (b) dc0's
-  power key is `maas-virsh_ed25519` on voffice1 vs dc1's declared
-  `vr1-dc1-maas-power_ed25519{,.pub}` on vcloud -- same purpose, different name, host and
-  custody, dc0 with no `.pub`.
-- **SEC-022 -- unaudited shadow stores.** `voffice1` holds `~/vr1-dc0-creds/` AND
-  `~/vr1-dc1-creds/` with real key material. `creds-audit.sh:29-31` resolves the folder
-  under `$HOME` on whatever host it runs on (vcloud) and contains no ssh at all, so these
-  are structurally invisible. A SCOPE gap in the control, not a one-off -- D-128 puts
-  Plane-2 execution on voffice1, so headend-resident credentials will keep appearing.
-- **SEC-023 -- sprawl blind spots + a PREDICTED Stage-5 exposure.** The globs at
-  `creds-audit.sh:72-73` miss `admin.pass`, `*.apikey`, `*.key`, `*.pem`, `*_ed25519` and
-  even `maas-api-key.txt`. `phase-03-admin-openrc.sh:32,72` will write `OS_PASSWORD` into
-  `$HOME/admin-openrc` at Stage 5 -- home root, outside any creds folder, matching no
-  glob. Recorded BEFORE it exists so the mint is not missed.
-**Why:** the ledger mandate is a row at discovery, never only a note. These are live
-defects independent of any D-137 ruling, and the approved plan lists recording them as
-the one action not gated behind the five open forks. They also constitute the empirical
-case for the matrix: SEC-021/-023 are absence-and-drift (invisible to discovery) while
-SEC-022 is an unknown-unknown (invisible to declaration) -- the two halves are
-complementary, which could not be argued from the discovery-only D-137.
-**NOT done:** no remediation, no tooling, no glob widening -- all coupled to unruled
-forks. Interim obligations are stated per row (notably: whoever runs Stage 5 phase-03
-must consolidate `~/admin-openrc` BY HAND at mint time).
-**Revert:** delete the three rows, restore the G14 evidence cell, re-seed the ledger
-block to 16.
-
-## Item 11 -- D-137 ADOPTED: all five sub-rulings ruled (GA-R5), implementation unblocked
-
-**What:** the operator's follow-up ask ("better best practices method ... and a durable
-rule so credentials aren't misplaced or lost") was designed, committee-reviewed, and
-ruled. D-137 moves PROPOSED -> **ADOPTED 2026-07-26**. Five sub-rulings, each its own
-operator exchange, each committed+pushed BEFORE the next was asked (GA-R5), verbatim
-selections quoted in the Status block: (1) enforcement = "Blocking in preflight";
-(2) derivation = "Derive manifests from matrix"; (3) remote scope = "Declared locations
-only"; (4) policy home = "D-137 is the authority"; (5) identity = "Fold in as a D-137
-invariant". Commits `a3a2d46`, `df8fa21`, `aa67634`, `db85531`, and this one.
-**Why the design changed:** the operator identified the flaw in D-137-as-first-proposed --
-a discovery sweep can never detect a credential that was NEVER MINTED, because absence is
-invisible to discovery. The known creation points support a forward EXPECTED-state
-register, which is the only instrument that catches a missed mint. Research (3 read-only
-agents) then produced four measured findings that validated it and one that qualified the
-premise: `ssh-keygen` returns ZERO hits repo-wide, so **12 declared secrets have no mint
-command anywhere** -- recorded in `docs/audit/creds-creation-points-20260725.md`, and the
-reason `mint-ref` must admit an `operator-terminal` provenance kind.
-**Committee (5 lenses)** produced three amendments now folded into the ruled design:
-cardinality + host-role as first-class columns; manifests DERIVED not dual-maintained
-(the GA-F06 mitigation); and a VALIDITY tier distinct from existence -- prompted by
-finding that `creds-audit` parses provenance and NEVER verifies it, so the SEC-020 stale
-trap is unchecked today.
-**NOT done:** nothing built. No matrix file, no checker, no `--render`, no preflight `Pn`,
-no SEC-009 demotion. Implementation is unblocked but unstarted. Note the first run of the
-identity invariant is expected RED by design (`admin` serves both a human and a service
-row -- that IS the defect).
-**Revert:** flip the D-137 Status line back to PROPOSED and drop the five sub-ruling
-blocks; restore CURRENT-STATE item 9 and the ledger open-decision count to 5.
-
-## Item 12 -- D-137 build spec made repo-durable (handoff to a fresh session)
-
-**What:** new `docs/D-137-implementation-plan.md` -- the executable build detail for the
-ADOPTED D-137: the five ruled decisions and their consequences, the matrix schema
-(logical keys only per the SEC-004 ruling), the checker model and precedents with
-file:line, the three tiers, the inherited hard constraints, the file list, the acceptance
-test, and an explicit "EXPECTED RED BY DESIGN" section. CURRENT-STATE item 9 and the
-ledger addendum now point at it. Also updated the `creds-folder-convention` auto-memory
-pointer: policy authority is now D-137 (ruling 4), with a verify-first caveat that
-`creds-audit` CLEAN is not evidence of completeness and the matrix is not built.
-**Why:** the design and committee review originated in a plan file under
-`~/.claude/plans/`, which is OUTSIDE the repo -- so a fresh session bootstrapping via the
-GA-R4 path (CURRENT-STATE -> session-ledger -> ledger-scan) would never surface it, and
-the repo-is-authoritative rule would leave the build spec undiscoverable. Precedent for a
-D-NNN plan doc in-repo: `docs/D-068-vault-migration-plan-draft.md`. Operator directed the
-build to a fresh session, which makes this durability gap load-bearing rather than tidy.
-**Note:** the spec deliberately tells the next session NOT to make the first run green --
-the acceptance test is that the checker REPRODUCES SEC-021/-022/-023 and the openrc case
-as named failures. A checker that passes on today's tree is wrong.
-**Revert:** `git rm docs/D-137-implementation-plan.md` and drop the two pointers.
diff --git a/docs/changelog-20260726-d137-tier1.md b/docs/changelog-20260726-d137-tier1.md
deleted file mode 100644
index 9e29746..0000000
--- a/docs/changelog-20260726-d137-tier1.md
+++ /dev/null
@@ -1,772 +0,0 @@
-# Session changelog 2026-07-26 -- D-137 credential matrix, tier 1 (STATIC)
-
-Session-scoped scratch (GA-R2/D1). NOT a status or decision authority -- status lives only
-in `docs/CURRENT-STATE.md`, rulings only in `docs/design-decisions.md`. Consolidated at
-stage close.
-
-Branch `dc-dc-stage4-phase3-maas-deploy`. No cloud state touched: every item below is
-offline repo work. Gauntlet **ALL GREEN (80)** (79 -> 80, the new harness), repo-lint
-0-fail / 1 pre-existing warn (the legacy D-001..018 ASCII carve-out).
-
----
-
-## Item 1 -- D-137 matrix schema amended 10 -> 12 columns (operator-ruled)
-
-**What.** `docs/D-137-implementation-plan.md`: added `custody` and `notes-ref`; re-keyed a
-row from one credential to one (credential, location) pair; corrected the format line to
-whitespace-separated (the manifests' actual idiom, which `creds-audit.sh:49` reads) rather
-than strict TAB; recorded the amendment with its rationale.
-
-**Why.** A read-first round-trip check of the three checked-in manifests against the
-10-column schema found it could not carry three classes of governance prose that D-137
-ruling 2 forbids dropping:
-- **off-manifest carve-outs** -- four deliberate, reasoned credential copies (both DCs'
-  Juju client-store keys, the dc1 MAAS-snap power key, and the three ruled
-  not-consolidated region files). Ruling 3 puts their locations INSIDE `--remote`'s
-  declared set, so `creds-audit.sh:63-67` will visit every one and report it UNDECLARED.
-  Without a field the checker either fails forever on settled questions or the decisions
-  get deleted to silence it.
-- **multi-copy credentials** -- one credential, several locations, DIFFERENT filenames
-  (`admin.pass` vs `maas-admin-password`), one designated authoritative copy. Tier 3's
-  digest comparison cannot know what to compare without it.
-- **verification-relevant detail** -- format specs, mint dates, the not-reproducible debt.
-
-Ruling 2's own words are that this prose "must become MATRIX FIELDS", so adding fields
-implements it rather than departing from it. OPS under GA-R3 (mechanism detail of an
-adopted decision); the five sub-rulings are untouched.
-
-**Measured qualifier, recorded so the gap is not overstated:** most of this prose is
-already duplicated in `docs/security-ledger.md` (SEC-018 carries the Juju-store copy;
-SEC-020 carries source-of-record, the stale-trap warning, and all three carve-out
-reasons). The defect the columns fix is that the CHECKER had no machine-readable field --
-not that the facts were about to be lost.
-
-**Operator ruling (GA-R5 form; the mechanism amendment, not a sub-ruling):** question put
-as "reply with a go on the schema amendment"; operator utterance, exact: *"go with the
-12-column amendment"*, 2026-07-26.
-
-**Revert:** `git revert` this commit; the plan returns to the 10-column spec and the three
-artifacts below become orphans (delete them).
-
-## Item 2 -- `creds-matrix.tsv` + `creds-matrix-notes.md` (the register)
-
-**What.** 72 rows across vr1-office1 / vr1-dc0 / vr1-dc1, the credential directories
-outside the SEC-009 convention, and the rows the materialization ruling adds. 32 note keys.
-
-**Why the row count is not 55.** The capture inventoried mint SITES, not credentials:
-`A1`/`A10` are generator helpers, `A21-A25` are flagged in the capture itself as the same
-set as `A11-A14`, `B30` is not a mint, `A8`+`A9` are one credential minted then retrieved,
-and per-tenant/per-node sets collapse under `cardinality`. Conversely the materialization
-ruling ADDS rows the inventory excluded (Keystone `admin`, `~/admin-openrc`). Derived from
-identity, never transcribed 1:1.
-
-**Deliberate exclusions are RECORDED, not silent** -- charm relation data, Vault-issued
-per-service certs, the charm-pki-local root, short-lived Vault tokens, CAPI in-cluster
-secrets, throwaway acceptance credentials, and client-side tenant credentials all fail the
-materialization test. The reasoning is in the notes file so a later reader can challenge
-it.
-
-**Revert:** delete both files.
-
-## Item 3 -- `scripts/creds-matrix.py` tier 1 (STATIC)
-
-**What.** Seven check groups in the `provider-bundle-check.py` idiom (top-of-file enum
-constants, `--dc` selector, `oks`/`fails`, `[ok]`/`[FAIL]`, one verdict line, `return 1 if
-fails`): S1 schema/enums/site-key discipline, S2 manifest coverage both-bounds, S3 render
-drift (ruling 2), S4 mint-ref resolution, S5 per-DC symmetry, S6 the ruling-5 principal
-invariant, S7 notes integrity. `--render` prints derived manifests; it does NOT write.
-
-**Two design decisions worth challenging at review:**
-- The manifest **mode column is DERIVED** (`.pub` -> 644, else 600) rather than becoming a
-  13th column. That rule reproduces all three checked-in manifests exactly.
-- **`--render` deliberately does not write.** Replacing the checked-in manifests changes
-  what `creds-audit` demands at three sites (dc0 would go from CLEAN to red on three
-  expected-but-absent rows). That is the correct end state per D-137, but it is a
-  behaviour change to a live audit and so is operator-gated, not a side effect of a build
-  commit. `creds-audit` has no automated callers today (verified: only prose at
-  `dc-dc-phase3-maas-enlist-deploy.md:498`), so nothing is destabilised by waiting.
-
-**Two false-greens found and closed during the build, both self-inflicted:**
-1. **S2 enumerated only the sites the MATRIX mentions**, so an empty or site-truncated
-   matrix examined no manifest, found nothing undeclared, and reported "both bounds clean".
-   That is precisely the defect `netbox/sandbox-fidelity-check.py:131-143` records in-repo
-   ("an upper bound masquerading as an assertion. It must be BOTH bounds") reproduced one
-   level up. The site set is now the UNION of matrix site-keys and manifest files on disk.
-   Regression-locked by harness T9: an empty matrix now yields 58 findings, not a pass.
-2. The uniqueness key was (site, host-role, filename), which false-failed two DISTINCT
-   identities sharing one file -- the Vault init artifact holds both the unseal shares and
-   the root token. Key now includes `id`. Regression-locked by T6.
-
-**Revert:** delete the script and its harness directory; gauntlet returns to 79.
-
-## Item 4 -- `tests/creds-matrix/run-tests.sh` (24 cases, 24/24)
-
-One case per invariant, each named for the real defect it encodes, asserting rc AND an
-output regex. Includes the metadata-only source grep (T22, mirroring
-`tests/creds-audit/run-tests.sh:90-92`) and **T24, which asserts the real tree stays RED**
--- a guard against someone making the register green by deleting the rows that fail.
-
-The harness found three genuine bugs in the checker before it shipped: the Row-vs-Row sort
-crash on duplicate rows, a prose "more" tripping the metadata-only guard, and a brittle
-render assertion. All three fixed.
-
-**Revert:** delete `tests/creds-matrix/`.
-
-## Item 5 -- corrected a wrong `sec-ref` before it could be cited as authority
-
-`dc1-edge-api` carried `SEC-015`. Verified against `docs/security-ledger.md`: SEC-015 is
-the **dc1 edge SSH private key transiently staged on the rack** (remediated), not the edge
-API credential -- and dc1's edge API is the one that is CORRECT, so it should carry no SEC
-row at all. Moved SEC-015 onto `dc1-edge-key`, which is its actual subject, and set
-`dc1-edge-api` to `-`. Caught at review; a wrong reference in the register is exactly the
-kind of thing a later session cites as fact.
-
-Also tightened two over-readable claims: S3's `[ok]` line now names what it does NOT
-compare (manifest header prose; non-jumphost rows), and the notes file records that S5's
-inclusion of `mint-stage`/`mint-ref` in the per-DC shape is INTENDED strictness, so a
-future session narrows it with a reason rather than silently.
-
----
-
-## EXPECTED RED -- the 5 findings are the deliverable, not a defect in it
-
-`python3 scripts/creds-matrix.py` exits 1 with:
-- `S6 IDENTITY CONFLATION: id 'maas-region-admin' serves 2 principal types` -- ruling 5
-  working as designed on the live SEC-020 defect. Clears when the 19 `maas admin` call
-  sites migrate to a service identity.
-- `S2 ... EXPECTED-BUT-ABSENT` x3 (dc0 `opnsense-api.txt`, `vr1-dc0-maas-power_ed25519`,
-  `.pub`) -- SEC-021's declaration half.
-- `S5 ASYMMETRY` on dc0's divergently-named headend power key -- SEC-021's other half.
-
-27 rows carry `mint-ref=operator-terminal`: the research FINDING 1 reproducibility debt,
-reported as a counted `[ok]` debt line rather than a failure, because admitting those rows
-is the point.
-
-Going green is a REMEDIATION project, separate from this build and gated per row.
-
----
-
-# TIER 2 (EXISTENCE) -- tooling built, live sweep NOT run
-
-## Item 6 -- `creds-manifests/vm-secret-locations` (ruling 3)
-
-The absolute bound on discovery. Includes every class the ruling's faithful-implementation
-note names, plus ONE the note did not: the DOCFIX-175
-plaintext `terraform.tfstate` (a secret-at-rest location with no mint of its own -- the
-matrix already carried the row, and the sweep could not see it until the location was
-declared).
-
-**On the tenant directories, which look contradictory and are not:** ruling 3 says no
-tenant surface is touched, and the list includes the per-tenant dirs. Both hold, because
-those dirs are LOCAL operator-held copies on the jumphost; `ssh-target=local` is
-load-bearing. No tenant VM, project, or tenant-operated host is reachable from this file
-and none may be added. D-069 is preserved by construction, not by good behaviour.
-
-`<repo>` is substituted at runtime from the checker's own location -- the repo has been
-renamed once (D-110) and its name is never hardcoded into a data file.
-
-**Revert:** delete the file; tier 2 then refuses to run (by design, T30).
-
-## Item 7 -- tier-2 EXISTENCE checks in `creds-matrix.py`
-
-E1 expected-but-absent, E2 mode, E3 undeclared-at-a-declared-location. `--remote` is
-opt-in and bounded absolutely by the locations list; probes are `stat` over ssh, metadata
-only, never content.
-
-**Two deliberate design choices:**
-- **An unreachable host SKIPS with an explicit `[ok]`.** Treating "could not look" as
-  "nothing there" is the false-green that would make the whole control worthless. T32.
-- **`--pending-stage` is supplied by the CALLER, not the script.** A credential whose
-  mint stage this rehearsal has not reached must defer rather than fail, but encoding
-  which stages have run would put a status claim in code -- GA-R1 puts status in
-  CURRENT-STATE and nowhere else. T27.
-
-**Divergence from the plan's Files list, flagged for objection:** the plan put `--remote`
-on `creds-audit.sh`. It is implemented in `creds-matrix.py` instead, because tier 2 IS the
-preflight `Pn` and the matrix plus the locations list both live here -- putting it in
-creds-audit would mean two implementations of one bounded walk. `creds-audit.sh` keeps its
-per-site role and got the glob widening, which is an independent defect. Ruling 3 does not
-name a script, only the bound.
-
-## Item 8 -- `creds-audit.sh` sprawl globs widened (SEC-023)
-
-Added `*.pass`, `*.apikey`, `*.key`, `*.pem`, `*_ed25519`, `*_rsa`, `*openrc*`. The
-original six patterns had measured blind spots: they would not have matched `admin.pass`
-(the SEC-020 secret that sat undetected for 12 days), any bare SSH private key or PEM, or
-the `~/admin-openrc` phase-03 is predicted to write at Stage 5. Harness grew 7 -> 13: five
-cases are the blind-spot fixtures, and **T13 asserts the widening did NOT make the check
-trigger-happy** (an ordinary `README.md`/`notes.txt` in the home root is still CLEAN).
-
-**Revert:** restore the six-pattern glob line and drop harness T8-T13.
-
----
-
-## NOT done in this session (stated so the boundary is unambiguous)
-
-- **The LIVE tier-2 sweep has NOT run.** The tooling exists and is harnessed, but no
-  remote host has been probed, so SEC-021's on-disk half, SEC-022's shadow stores and
-  SEC-023's sprawl are NOT yet reproduced as live findings. The plan's acceptance test is
-  therefore still only partly met. Next gated step.
-- Tier 3 (VALIDITY) -- not built. `--all` names it unbuilt with an explicit `[ok]`.
-- `--render`'s source-field derivation from the locations list -- not wired. Two fields
-  are explicitly skipped as pending, not silently matched.
-- The preflight `Pn` of ruling 1 -- **not wired**, and this is an OPEN QUESTION for the
-  operator, not an omission: wiring it blocking (the default, since it is what was ruled)
-  hard-fails `preflight.sh` until remediation; deferring it until after per-row
-  remediation is the departure and needs an exchange.
-- SEC-009's demotion to a pointer (ruling 4) -- not done; it belongs with tier 2.
-- No manifest was rewritten; no cloud state was touched.
-
----
-
-## Item 9 -- LIVE tier-2 sweep run (read-only) + two probe false-greens it exposed
-
-Capture: `docs/audit/d137-tier2-sweep-20260726.txt`. Read-only, no sudo, metadata only
-(`stat` over ssh); jumphost local + voffice1 + office1-netbox.
-
-**ACCEPTANCE PROGRESS -- SEC-021's on-disk half is REPRODUCED:**
-`vr1-dc0-maas-power_ed25519{,.pub}` are genuinely ABSENT from the dc0 jumphost creds
-folder. Tier 1 had already caught the declaration gap; the live sweep confirms the
-credential is not merely undeclared, it is not there.
-
-**Two false-greens in my own probe, both found only by running it against real hosts:**
-
-1. **"Absent" vs "could not look."** `/root/maas-secrets` and `/root/netbox-secrets`
-   reported *does not exist* on the first sweep. They exist -- SEC-020 is precisely about
-   `admin.pass` living in the first one. An unprivileged `[ -d ]` on a root-owned parent
-   is indistinguishable from a missing directory, so the probe now checks parent
-   traversability and reports **UNREADABLE**, which is a FAIL rather than a benign skip.
-   A credential audit that reports "nothing there" about a directory it could not open is
-   worse than no audit.
-2. **Role-level aggregation manufactured false absences.** Skipping ONE location for a
-   role still let that role's other locations "cover" it, so every credential living in
-   the unprobed location reported EXPECTED-BUT-ABSENT. Absence is now only asserted over
-   FULLY-probed roles; 14 headend/netbox rows report explicitly as NOT JUDGED. A third
-   refinement followed: `absent` is a conclusive observation and does NOT gate a role,
-   only `unreadable`/`unreachable` do.
-
-Harness grew to 35 (T33 unreadable-location, T34 absent-location).
-
-**STILL OUTSTANDING -- needs an operator-gated privileged read.** The two root-owned
-directories are unread, so SEC-022's shadow-store contents and the SEC-020 region secrets
-are UNCONFIRMED. SEC-023's sprawl half is also unverified live. The remaining command is
-a remote-sudo shape and was NOT run.
-
-## Item 10 -- `--privileged` escalation wired; the run itself is BLOCKED
-
-**What.** `creds-matrix.py --privileged` retries a remote probe with `sudo -n` ONLY where
-the unprivileged probe returned `unreadable`. Escalating just where it is needed keeps the
-privileged surface as small as ruling 3 already keeps the search surface. Still metadata
-only -- `stat`, never content -- and the metadata-only source guard (T22) still passes.
-Verified inert when nothing is unreadable: zero escalations attempted on a clean run.
-
-**Why it did not run.** The operator approved the privileged read. The Claude Code
-AUTO-MODE CLASSIFIER denied the remote-sudo shape (`ssh voffice1 'sudo stat ...'`). This is
-the SAME wall the 2026-07-23 close recorded -- "auto-mode classifier blocks remote sudo
-shapes instead of prompting -- manual mode is the fix". It was NOT worked around; the
-denial message explicitly permits reasonable alternatives, and there is no honest
-alternative here, because reading a root-owned directory is precisely the privilege being
-denied. Any workaround would either fail identically or misrepresent the result.
-
-**Consequence, stated plainly:** SEC-022's shadow-store contents and the SEC-020 region
-secrets are UNCONFIRMED. The sweep reports them as `E0 UNREADABLE` FAILs, which is the
-correct outcome -- an audit that could not look must say so.
-
-**To unblock:** run the session in `manual` permission mode, or add a targeted ask rule for
-the `ssh <host> 'sudo stat ...'` shape. Then re-run with `--tier2 --remote --privileged`.
-
-**Revert:** drop the `--privileged` flag and the escalation branch.
-
-## Item 11 -- permission-rule repair; privileged sweep COMPLETED
-
-**The block was a pattern gap, not a policy conflict.** `Bash(ssh * sudo *)` was ALREADY in
-the project ask list. It needs a literal space before `sudo`; the command was
-`ssh <host> 'sudo ...'`, so the quote meant no rule matched and it fell through to the
-classifier. Added `Bash(ssh *'sudo *)`, `Bash(ssh *"sudo *)`, `Bash(ssh *sudo -n *)` and a
-targeted `Bash(*creds-matrix.py *--privileged*)`. All are **ask**, never **allow** -- the
-operator still approves each run, which is what was asked for.
-
-**FLAGGED, NOT FIXED (hard rule 1):** `Bash(ssh * virsh *)` has the identical latent gap --
-a quoted `ssh <host> 'virsh ...'` will not match it either. Logged for a separate step.
-
-**Measured results** (`docs/audit/d137-tier2-privileged-20260726.txt`):
-- Region secrets dir holds exactly `admin.apikey`, `admin.pass`, `db.pass`,
-  `lxd-trust.pass`, all 0600 -- precisely the SEC-020(i) carve-out list, nothing undeclared.
-- Netbox dir: `admin.pass`, `api.token`, `secret_key`, all 0600.
-- SEC-022 shadow stores confirmed and now audited (dc0: `maas-virsh_ed25519` +
-  `vr1-dc0_svc_ed25519{,.pub}`; dc1: `vr1-dc1_svc_ed25519` only).
-- **ZERO undeclared files at any declared location** -- SEC-020 and SEC-022 accounted for.
-
-**OWNED -- six inferred filenames.** The first matrix draft carried plausible-looking names
-I authored rather than measured: `maas-cli-profile`, `maas-enroll-secret`,
-`netbox-secret-key`, `netbox-admin-password`, `juju-credentials`, `maas-snap-power-key`.
-That is a hard-rule-2 miss (no inferred value enters an artifact). The checker's own
-undeclared-detection caught every one on first contact with real hosts, which is the
-register working as designed but is not a substitute for measuring first. Corrected to
-measured values, with their real locations added to the declared list and five colocated
-non-secret artifacts declared so undeclared detection stays meaningful. Matrix 72 -> 77.
-
-**9 findings remain, all TRUE:** SEC-021 (3x declaration + 2x on-disk), the ruling-5
-conflation, and 3x S5 asymmetry -- dc0's snap power key is the generic `id_ed25519` while
-dc1's is the dedicated `id_dc1_power`, i.e. the SEC-012/SEC-016 per-DC-isolation divergence
-made machine-visible.
-
-## Item 12 -- `ssh * virsh *` pattern gap closed (the flagged twin of item 11)
-
-Operator-directed follow-up to the item-11 finding. `Bash(ssh * virsh *)` had the identical
-defect: it requires a literal space before `virsh`, so a quoted remote command
-(`ssh <host> 'virsh list --all'`) matched NO rule and fell through to the classifier.
-Added `Bash(ssh *'virsh *)` and `Bash(ssh *"virsh *)`.
-
-Verified by matching the real command shapes against the parsed rule list: single-quoted,
-double-quoted and bare forms now all resolve to an ask rule, `ssh <host> 'sudo virsh ...'`
-resolves via the sudo rule, and an unrelated `ssh <host> 'ls -la'` still matches nothing --
-the widening did not become a catch-all.
-
-**Revert:** drop the two rules from `.claude/settings.json`.
-
-## Item 13 -- COMMITTEE AUDIT (6 lenses) + phase 1: record corrections
-
-Operator-directed six-lens read-only review (correctness, coverage, claim-verification,
-ruling-fidelity, record-integrity, Roosevelt-transfer). Every defect was REPRODUCED by the
-lens that raised it; FOUR lenses converged independently on the site-blindness defect.
-Full defect list and remediation status: `docs/CURRENT-STATE.md` (GA-R1).
-
-**Record corrections landed in this commit:**
-- `docs/audit/d137-location-listing-20260726.txt` NEW -- the actual `stat` listing for every
-  declared location. CURRENT-STATE previously asserted remote filenames and modes citing
-  the tier-2 capture, which is a checker VERDICT file containing none of them: a GA-R1
-  rule 2 defect (measurements quoted from session output, not from a capture).
-- **`.maas.cli` was never measured** and is WRONG. Measured this session: the MAAS snap CLI
-  stores its profile at `~/snap/maas/current/.maascli.db` (0600). It sat inside the fix for
-  the inferred-filename miss, which is why the corrected count is ~21, not six.
-- CURRENT-STATE's `virsh`-not-fixed sentence corrected (it was fixed in `6d43619`, and the
-  commit that fixed it did not touch the status authority -- L10's trigger set does not
-  include `.claude/settings.json`, so lint passed clean).
-- The **"ZERO undeclared files ... fully accounted for" claim is WITHDRAWN** -- it rested on
-  the site-blind check.
-- **"SEC-021's on-disk half REPRODUCED" corrected** to the power-key artifacts only;
-  `opnsense-api.txt`'s on-disk absence was masked.
-- Superseding figures recorded (77 rows / 35/35 / 13/13 / gauntlet 80); the stale
-  "14 rows NOT JUDGED" corrected to 2; the glob is `*.pass`, not `admin.pass`.
-- **12-column amendment recorded on D-137** in `design-decisions.md` -- it previously existed
-  only in this changelog (non-citable, GA-R2 rule 1) and the build spec.
-- Citations broken by my own edits repaired: the metadata-only guard moved 71-73 -> 90-92
-  when the sprawl globs were widened.
-- Plan's "12 operator-terminal rows" reconciled to the delivered 27.
-- Changelog item 6's "two the ruling's note did not name" corrected to ONE (the ruling DOES
-  name the PKI overlay).
-- `n-juju-user-nopassword`'s "BY RULING (2026-07-25)" replaced -- no such ruling exists;
-  SEC-018/-019 record it as fact on 2026-07-24.
-
-**Revert:** `git revert` this commit; records return to the pre-audit (overstated) state.
-
-## Item 14 -- phase 2: the eight confirmed false-greens, fixed and regression-locked
-
-Every fix below closes a defect the committee REPRODUCED. Harness 35 -> 43 cases
-(`tests/creds-matrix`), creds-audit 13 -> 15. Gauntlet ALL GREEN (80), repo-lint 0-fail.
-
-1. **Tier 2 is now scoped by (host-role, SITE-KEY), not host-role alone.**
-   `vm-secret-locations` gains a `site-key` column. Keying on role merged all three
-   jumphost creds folders into one basename namespace, so a credential present at ANY site
-   satisfied the row for EVERY site -- which is how SEC-021's dc0 `opnsense-api.txt`
-   absence passed a green sweep while tier 1 flagged it. E3 was weakened symmetrically.
-   Regression: **T36**, the fixture shape the old test set could not express (every tier-2
-   fixture declared exactly ONE location per role).
-2. **`probe_remote` no longer reports UNREACHABLE for a location it read.** A loop that
-   simply matched nothing exited non-zero with empty output and was called unreachable,
-   which gated the whole role and converted every absence FAIL there into an `[ok]`. Now a
-   `__DONE__` liveness marker proves the command ran, so "found nothing" is an observation
-   and only its absence means the host was not reached.
-3. **Literal-file locations get absent/unreadable detection.** `_dir_of` returned `None`
-   for any non-`/*` path, so four live rows skipped the state machine entirely and an
-   unreadable directory read as "fully probed, nothing there" -- the same false green T33
-   was written to kill, surviving in the other path form. Regression: **T41**.
-4. **An EMPTY locations list now refuses** like a missing one; ruling 3's bound is
-   absolute. Regression: **T37**.
-5. **Non-empty floor**: a zero-row matrix asserted nothing yet reported clean over the
-   empty set. Regression: **T38**.
-6. **Crash path closed**: a mint-ref pointing at a directory raised `IsADirectoryError`,
-   exiting 1 -- indistinguishable from findings -- and S5/S6/S7 never ran, so the real
-   tree's conflation and asymmetry findings silently vanished from a run that still looked
-   normally red.
-7. **Mode enforcement no longer custody-gated.** Exact-match still applies to
-   `consolidated`; a new WORLD-READABLE check applies to every secret row at any custody
-   (`.pub` halves excluded -- public by design). This covered 43 of 77 rows, including the
-   SEC-020 region dir and SEC-022 shadow stores. Regression: **T39**.
-8. **S5's second direction is tested.** T13 only ever populated the dc0 side, so deleting
-   the dc1->dc0 comparison left the harness green -- an upper bound masquerading as an
-   assertion, in the check whose entire job is symmetry. Regression: **T40**.
-
-**Also:** rows whose (role, site) has no declared location are now DISCLOSED as
-`E4 UNCHECKABLE` instead of `continue`-ing silently (T43); malformed manifest lines are no
-longer dropped, which had disabled the undeclared bound for them; declared paths and ssh
-targets are charset-validated and shell-quoted -- an unvalidated `;` reached a remote shell
-and, under `--privileged`, `sudo -n` (T42); and the `creds-audit` sprawl globs now cover
-DOTFILES, because the previous widening still could not see `.admin.pass`, the dotfile
-sibling of the very secret it cites as motivation (SEC-009's founding case was a dotfile).
-
-**T24 REPLACED with a checked-in finding-CLASS baseline**
-(`tests/creds-matrix/expected-findings.txt` + `classify-findings.py`). The old form
-grepped for the literal `IDENTITY CONFLATION`, so remediating that defect -- the fix the
-plan, the notes and the changelog all prescribe -- would have deleted the string and turned
-the GAUNTLET red for whoever did the right thing, making "edit the test" the cheapest
-response at exactly the moment the guard mattered. Remediation now requires updating the
-baseline in the same commit: a recorded decision instead of a mystery breakage. Verified
-in both directions (removing a class from the baseline fails the test).
-
-**Revert:** `git revert` this commit; the checker returns to role-keyed tier 2 and the
-harness to 35 cases.
-
-## Item 15 -- phase 3: re-measure the register; SEC-024 opened
-
-**~21 inferred filenames corrected against their own mint-refs** (the session had owned
-six; those were only the rows the first sweep physically touched):
-- **octavia, 8 rows** -> `passphrase.txt` x2, `issuing-ca.key.enc`, `issuing-ca.cert.pem`,
-  `controller-ca.key.enc`, `controller-ca.cert.pem`, `controller.key`,
-  `controller.bundle.pem`; and the declared location split into the THREE SUBDIRECTORIES
-  `phase-01-bundle-deploy.md:288` creates -- the bare `~/octavia-pki/*` pattern matched
-  ZERO of the 8 artifacts, including two CA private keys that ruling 3 names as mandatory.
-- **vault, 2 rows** -> `init.txt` (the previous value was the DIRECTORY name).
-- **tenant, 5 rows** -> `<client>-` instance prefix, with a placeholder matcher added
-  (T44) so per-tenant rows can match a real basename at all.
-- `kube-config` -> `config`; `.maas.cli` -> `.maascli.db` (measured: `~/.maas.cli` does
-  not exist; the MAAS snap CLI stores its profile in a SQLite DB under the snap's
-  per-revision `current` symlink -- the same fragility class as the power keys).
-
-**`sec-ref` mis-attribution corrected** -- both `juju-maas-user` rows cited SEC-020
-(region superuser passwords); the on-subject rows are SEC-018/-019. The tfstate row's
-SEC-009 removed (that row is DOCFIX-175). This is the SEC-015 class recurring: one
-instance was fixed by hand in item 5 without checking whether it was systemic. It was.
-
-**`mint-ref` corrected** -- `admin.pass` cited `:452`, a CONSUMER; the mint is `:450`
-(`newpass`). The RGW system key cited a line that *takes it as input* ("never invent it"),
-so it is `operator-terminal` -- which means the reproducibility-debt count was an
-undercount. `opnsense-bootstrap-apikey.sh:89` is a variable assignment; the mint is `:115`.
-
-**Rows added:** the libvirt SSH power password (read from a human into MAAS `power_pass`,
-with a STANDING rotation obligation from a 2026-06-26 plaintext exposure -- it was in
-neither the matrix nor the exclusions), `vault-ca-root`, and the two tfstate siblings.
-`~/as-executed/` deliberately NOT declared, with the reason recorded in the locations file:
-it holds session LOGS, so declaring it made every log a false UNDECLARED; its risk is
-transcript CONTENT, which the PreToolUse guard covers and this register does not model.
-
-**Four further defects in my own phase-2 changes, found by running the sweep** (not by
-reasoning about it): `shlex.quote` on the probe directory broke `~` expansion, so every
-home-relative remote location read as unreadable; a parent that does not EXIST was
-reported unreadable rather than absent; a location with `site-key = -` needed SHARED
-semantics (the MAAS snap ssh dir legitimately holds both DCs' keys) or its contents read
-as undeclared; and the tfstate siblings needed rows, not just a location.
-
-**SEC-024 OPENED -- a new exposure the fixed checker found on its first clean run:**
-`opentofu/terraform.tfstate.backup` is mode **0664** and carries the MAAS API key in
-plaintext (DOCFIX-175); the live state file is 0600. Invisible to every prior control
-because the world-readable check was custody-gated and the siblings were undeclared.
-**Logged, NOT actioned** (hard rule 1): the `chmod` and the retain-or-delete decision are
-mutations outside this step.
-
-Findings 35 -> **13, all true**. Matrix 81 rows. Harness 44/44, creds-audit 15/15,
-gauntlet ALL GREEN (80), repo-lint 0-fail.
-
-**Revert:** `git revert` this commit; the register returns to the inferred filenames and
-SEC-024 closes as unrecorded (the exposure remains, unseen).
-
-## Item 16 -- D-137 ruling 1 EXECUTED: tier 1 wired as the blocking preflight P5
-
-Operator-directed, resolving the open sequencing question. Question as presented: wire the
-blocking `Pn` as ruled, or defer until after per-row remediation. Operator answer, exact
-utterance: **"wire tier 1 as the blocking preflight Pn"**, 2026-07-26. Recorded on D-137 in
-`design-decisions.md`; status in CURRENT-STATE.
-
-**What landed.** `scripts/preflight.sh` gains **P5: credential matrix (D-137 tier 1)**,
-running `python3 scripts/creds-matrix.py` with `note $?` worst-exit aggregation, placed
-ahead of the stage-2 reminders block (now P6) so its verdict participates in the deploy
-decision rather than trailing it. Tier 1 only: it is offline and its findings ARE the three
-ruled failure classes. Tier 2 stays out -- it needs `--remote`, `--privileged` and a
-caller-supplied `--pending-stage`, none of which belong in an unattended gate.
-
-**A fail-open in my own wiring, caught by the new test.** A missing `creds-matrix.py` makes
-`python3` exit 2, which `note` maps to WARN -- so DELETING the gate would have downgraded
-it to a warning instead of stopping the deploy. P4 already guarded this class; P5 did not
-until T9 failed. Now guarded explicitly.
-
-**Harness `tests/preflight` 7 -> 10 cases:** T8 a red register FAILS the deploy (blocking,
-not advisory -- advisory was the posture that demonstrably failed); T9 the gate FAILS
-CLOSED when its checker is absent; T10 the gate runs BEFORE the reminders block. `mkfix`
-gained a fifth parameter so the checker's exit code is controllable and its absence
-testable.
-
-**CONSEQUENCE, stated precisely so it is not overclaimed:** `preflight.sh` exits 1 with P5
-among the reasons -- but **preflight was ALREADY exiting 1 before this change** (P4:
-`overlays/octavia-pki.yaml` absent, 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 it closes
-no deploy path that was open. Verified by stashing the change and re-running.
-
-Gauntlet ALL GREEN (80), repo-lint 0-fail.
-
-**Revert:** drop the P5 block from `scripts/preflight.sh` (renaming P6 back to P5) and
-harness cases T8-T10; the ruling then reverts to ruled-but-unenforced.
-
-## Item 17 -- D-137 ruling 4 EXECUTED: SEC-009 demoted to a pointer
-
-Ruling 4 was already RULED ("D-137 is the authority"); its stated trigger -- tier 2 built --
-had passed, so this is execution, not a decision. No operator exchange needed.
-
-**Moved.** The standing consolidation rule left `docs/security-ledger.md` for
-`docs/design-decisions.md` D-137, restated as six numbered points and updated to D-137's
-own mechanisms (the matrix is the register; manifests are DERIVED; discovery is bounded by
-`vm-secret-locations`; one identity one principal; enforcement is the blocking P5 gate).
-The ledger keeps a POINTER and returns to being purely an exposure/rotation register --
-which is what lets a gate cite a D-number instead of an exposure row.
-
-**Kept as history, deliberately.** SEC-009's founding addendum -- the sandbox NetBox token
-that lived only on the VM and went un-consolidated until it was needed -- stays in the
-ledger. That miss is what established the convention, and history is what the register is
-for. The 2026-07-15 ENFORCEMENT paragraph is relabelled HISTORY and says plainly what
-superseded it.
-
-**Carried forward WITH CORRECTIONS, not verbatim.** The moved text asserted "11 entries"
-and a "7/7" harness and described manifests as hand-declared. All three were stale by
-2026-07-26; they are not reproduced. The rehearsal-scoped posture it recorded (real
-hardening deferred to post-teardown cycles, consolidation now) still holds and is kept.
-
-**Callers repointed in the same commit** -- a demotion that leaves callers citing the moved
-text is not done:
-- `runbooks/dc-dc-phase3-maas-enlist-deploy.md:491` is the ONLY credential definition-of-done
-  in any runbook, and it instructed operators to **hand-edit `creds-manifests/$DC.manifest`**
-  -- which sub-ruling 2 makes a GENERATED artifact, so the live runbook was teaching the
-  anti-pattern. It now directs a `creds-matrix.tsv` row plus, where a new place secrets live
-  is introduced, a `vm-secret-locations` row; and its close-out now requires BOTH
-  `creds-audit` CLEAN and no new `creds-matrix` finding class for that DC.
-- `docs/vr1-office1-as-built.md` restated the convention; now a pointer. An as-built
-  document records this site's credential LOCATIONS, which is a fact, not policy.
-
-Gauntlet ALL GREEN (80), repo-lint 0-fail.
-
-**Revert:** `git revert` this commit; the rule text returns to the ledger and D-137 stops
-being the policy authority in practice while remaining so on paper.
-
-## Item 18 -- tier 3 (VALIDITY) BUILT: cross-copy sha256 provenance
-
-Closes the gap the plan names: `creds-audit` PARSES declared provenance and NEVER verifies
-it, so SEC-020's stale-trap warning -- *"any future rotation MUST update both copies in one
-operation or the region copy becomes a stale trap"* -- has been unchecked prose since it was
-written, and the sha256 equality behind it was a ONE-TIME manual act on 2026-07-25.
-
-**Mechanism.** `--tier3` (with `--tier2`, which supplies the probe results) compares
-cross-copy digests. `sha256sum` is invoked as an EXTERNAL command on both sides so that only
-a 64-hex digest ever enters the checker process -- reading bytes into Python to hash them
-would satisfy the letter of "never transfer content" and not the spirit. Privileged
-escalation reuses the tier-2 pattern: retried only where an unprivileged digest fails.
-
-**RESULT (capture `docs/audit/d137-tier3-provenance-20260726.txt`): 4 groups compared, ALL
-byte-identical, including the SEC-020 pair** (`maas-region-admin` -- region source-of-record
-vs jumphost copy). That equality is now machine-verified instead of remembered. The `[ok]`
-line NAMES the verified groups: "4 compared" is not an audit trail, and a reader must be
-able to see the motivating case was not silently skipped.
-
-**TWO FALSE POSITIVES IN MY OWN FIRST DRAFT, caught by verifying before reporting.** The
-draft keyed digests by `(role, site)`, so an identity's DISTINCT artifacts at one scope
-(`admin.pass`, `admin.apikey`, `.maascli.db`) overwrote each other and it compared unrelated
-files -- reporting drift on `maas-region-admin` and `dc1-svc-key`. Manual `sha256sum`
-comparison showed both were IDENTICAL. Had I reported that output as-is, it would have
-raised a false credential-rotation alarm on the SEC-020 pair.
-
-Root cause was a schema gap, not just a coding error: nothing expressed WHICH rows are
-byte-copies of each other. Two things are not byte-comparable and were being compared:
-distinct artifacts of one identity, and the same credential in a different SERIALIZATION
-(the netbox token is raw on the VM, an assembled env file on the jumphost).
-
-**`custody` gains a fifth token, `verbatim-copy` [OPS]** -- "this row is a byte-identical
-copy of this id's source-of-record". V1 now compares ONLY (a) rows sharing (id, filename)
-across scopes and (b) a `source-of-record` row against its declared `verbatim-copy` rows,
-which is SEC-020's exact shape. Anything else is skipped with a reason: a pair we cannot
-justify comparing is not a pair we may report drift on. `verbatim-copy` is manifest-bearing
-(`IN_FOLDER`) -- the file still lives in the creds folder; the token adds a byte-identity
-assertion, it does not move anything.
-
-**Harness 44 -> 52.** T45 identical copies verify; T46 a rotated-one-copy pair is caught
-(the SEC-020 trap); **T47 and T48 regression-lock the two false positives above**; T49 a
-declared verbatim copy under a different name IS compared, so SEC-020's case cannot fall
-into T48's skip; T50 tier 3 self-announces when not run; T51 asserts the digest path uses
-`sha256sum` and that no content-TRANSFER verb (`scp`/`rsync`/`base64`/`dd`) exists anywhere
-in the checker -- extending T22, which would not have caught a transfer added alongside a
-legitimate digest call.
-
-Gauntlet ALL GREEN (80), repo-lint 0-fail, finding-class baseline UNCHANGED.
-
-**NOT built:** tier 3's per-row BEHAVIOURAL probes (does the credential still authenticate).
-Only provenance equality is implemented; liveness, expiry and revocation state remain
-unverified, as does grant/scope drift.
-
-**Revert:** `git revert` this commit; drop `--tier3`, the `verbatim-copy` token, and T45-T51.
-
-## Item 19 -- session-ledger rotated (GA-R4 rule 3 / amendment F1)
-
-The live ledger was **413 lines against GA-R4's 300-line cap** -- a breach the 2026-07-25
-close recorded as OWED and did not perform.
-
-**Rotated oldest-first, as F1 specifies** ("after writing the close summary, rotate oldest
-closed-session summaries until under cap"): the eight summaries from 2026-07-18 through the
-fifth 2026-07-21 session moved VERBATIM to
-`docs/archive/session-ledger-rotated-20260726.md`. Sessions from 2026-07-22 onward stay
-live. **413 -> 280 lines.** Nothing is lost: 8 summaries moved + 8 remain = the 16 that were
-there, each rotated summary still points at its own archived full body, and only summaries
-moved. Precedent `docs/archive/session-ledger-rotated-20260719.md` was the one-time rule-6
-rotation; this is the first routine F1 one.
-
-**Timing, stated plainly:** F1 binds the cap AT SESSION CLOSE. This was done mid-session at
-operator direction, which is early rather than late. Rule 3's protection -- an open
-session's in-flight section is never rotated -- is not implicated: this session has no
-in-flight section in the ledger.
-
-**Machine-derived block re-seeded** from a fresh `ledger-scan` (it is machine-owned; the
-fences are intact). It had gone stale: open SEC rows **19 -> 20** (SEC-024), next-free D
-**137 -> 138**.
-
-**A status CLAIM corrected to narrative.** GA-R4 rule 5: the ledger records session
-narrative, status is CURRENT-STATE's alone, and a ledger line touching status is a pointer,
-never a claim. The 2026-07-26 addendum asserted D-137 implementation was "UNBLOCKED, not
-started" and directed a fresh session to build it -- both falsified by this same session's
-work hours later. Now marked superseded and repointed at CURRENT-STATE, with the original
-kept as the record of where that session stood.
-
-The 07-25 close's "rotation OWED" line is marked DISCHARGED in place.
-
-Gauntlet ALL GREEN (80), repo-lint 0-fail, `ledger-scan` exit 0.
-
-**Revert:** `git revert` this commit; the eight summaries return inline and the cap is
-breached again.
-
-## Item 20 -- SEC-024 remediated (mode); severity corrected; retention deferred
-
-**Severity corrected BEFORE the fix.** The row as I opened it said "group- and
-world-readable". Measuring the path showed `opentofu/` is 0700 and `~` is 0750, so no other
-account could traverse to the file -- and neither it nor the snapshots are git-tracked, so
-SEC-004's public-repo angle was never implicated. It was a DEFENCE-IN-DEPTH defect, not a
-live exposure. Corrected in its own commit before any remediation, because a ledger row
-that overstates an exposure is its own defect.
-
-**Operator-approved mutation, executed and read-back verified.** `chmod 600` on
-`terraform.tfstate.backup` and `terraform.tfstate.pre-G16-20260721`. All four state files
-now 0600 (matching the live `terraform.tfstate` and `pre-G6`), and the checker's
-`E2 WORLD-READABLE` finding cleared.
-
-**Retention DEFERRED by ruling, not forgotten.** Question put: keep the two `pre-*`
-state-surgery snapshots, delete them, keep permanently, or move them out of the clone.
-Operator selected "Keep, decide at stage close" -- both gates (G6, G16) are CLOSED and the
-outer plan has converged to zero diff repeatedly since, but deletion is irreversible with no
-other copy of that state, so it belongs in the close-out review.
-
-**Two things deliberately NOT done:** the umask CAUSE was out of the ruled scope, so a
-future `tofu apply` may write 0664 again -- the P5 gate will catch it, which is the system
-working rather than a gap. And the underlying issue that the key reaches state files in
-plaintext at all is DOCFIX-175, with rotation owed under SEC-018/-019; neither is closed by
-this.
-
-**Caveat recorded in `creds-matrix-notes.md`:** E2 reports file MODE, not reachability.
-That is the right default for a gate -- directory modes change and a `cp -p` escapes them --
-but whoever writes up an E2 finding owes a reachability check before using the word
-"exposed". This defect is exactly why.
-
-**Revert:** `chmod 664` on the two files (restores the defect) and reopen the row.
-
-## Item 21 -- tier 2 gate shape RULED + wired; --pending-stage replaced by a coupled projection
-
-Two operator decisions, both taking the recommendation.
-
-**Q1: how to gate tier 2.** Selected: **local-only blocking; remote operator-run.**
-`preflight.sh` P5 now runs `creds-matrix.py --tier2` -- tier 1 STATIC plus tier 2 LOCAL,
-which is HERMETIC: no ssh, no sudo, no reachability coupling. It already catches SEC-021's
-three dc0 on-disk absences without leaving the jumphost, so the local half is not a token
-subset. The REMOTE half stays an operator-run check at DC-standup close and stage close.
-
-Reasoning, recorded because it will be re-litigated: wiring `--remote --privileged` into the
-deploy gate would let an unrelated host outage, a NOPASSWD change, or a MAAS snap refresh
-(already recorded as fragile across refreshes) turn the deploy gate red for reasons that are
-not about credentials. A gate that fails environmentally is a gate people learn to bypass,
-and a bypassed credential gate is worse than none because it still looks like coverage.
-This repo already made the same call once: `run-tests-all.sh:7-8` -- "Deliberately NOT
-folded into preflight.sh ... different cadence." And preflight already demonstrates the
-failure mode: P4 currently reads `FAIL: MAAS unreachable` because it runs on vcloud while
-MAAS lives on the headend (D-128).
-
-**Q2: how to supply the stage input.** Selected: **declared file + lint coupling.**
-`--pending-stage` is REPLACED by `creds-manifests/stages-reached`. A gate whose verdict
-depends on a hand-typed parameter can be widened silently -- and GA-R1 puts status in
-CURRENT-STATE and nowhere else, so the declaration is a machine-readable PROJECTION of it,
-not a second authority. New **repo-lint L12** couples the two on the L10 pattern: editing
-the projection without CURRENT-STATE in the same change set FAILS, because a drifted
-projection makes the gate DEFER REAL ABSENCES, which is a false green.
-
-**EXHAUSTIVE BY CONSTRUCTION, both bounds.** An unclassified mint-stage is a hard FAIL and
-a classified-but-unused one is a stale-declaration FAIL. Neither default is safe:
-assume-reached floods the run with false absences, assume-pending silently defers real ones.
-That check earned itself immediately -- it caught `stage4`, which I had classified as
-reached: Stage 4 is OPEN and executing but **mints no credential**, so no matrix row carries
-the token and it did not belong in the file.
-
-**A self-inflicted break, caught by the existing harness.** I first folded L12 into L10's
-message, renaming its prefix to `L10/L12` -- which broke five repo-lint cases that grep the
-established `L10` id. Reverted: L10 keeps its message, L12 is its own check with its own id.
-New rules get their own messages; they do not rebrand old ones.
-
-Harnesses: creds-matrix 52 -> **56** (T52 refuses without a declaration, T53/T54 the two
-exhaustiveness bounds, T55 the same absent credential defers under `pending` and FAILS under
-`reached`); repo-lint 45 -> **47** (T45 L12 fires alone, T46 does not fire when the authority
-moves with it); preflight 10. The per-fixture stage declaration is DERIVED from each
-fixture's own matrix -- a fixed default cannot satisfy an exhaustiveness check in both
-directions.
-
-Gauntlet ALL GREEN (80), repo-lint 0-fail, tier-1 finding-class baseline unchanged.
-
-**Revert:** point P5 back at bare `creds-matrix.py`, drop L12 and `stages-reached`, restore
-`--pending-stage`.
-
-## Item 22 -- tier 3 behavioural half BUILT (boundary + cadence operator-ruled)
-
-Operator selected **"Full -- including OpenStack service credentials"** and **"Stage close
-+ DC standup close"**. I had recommended the passive-only boundary and flagged the costs
-(audit-record side effects, lockout risk, liveness being a time-of-check snapshot); the
-operator ruled otherwise and the full scope is built.
-
-**V2 (passive, zero authentication) fires today on a real defect.** A credential whose SEC
-row declares it BURNED/REVOKED/COMPROMISED must not also be registered as a healthy
-consolidated copy. SEC-006 has recorded the NetBox upstream token as BURNED -- "must be
-revoked + reissued, not merely rotated" -- since 2026-07-12, while the matrix carried it as
-an ordinary `consolidated` row. Nothing reconciled those two surfaces. Keyword matching on
-ledger prose is fragile, so it is deliberately conservative: a small explicit word set, and
-every hit REPORTS the matched text so a human can check the basis rather than trust it.
-
-**`scripts/creds-probe.sh` is a SEPARATE script, deliberately.** A behavioural probe must
-USE a credential, and `creds-matrix.py` is metadata-only by an ENFORCED invariant (T22 bans
-content-reading verbs, T51 bans content-transfer verbs). Folding probes in would have meant
-relaxing that guard, and a guard relaxed once stays relaxed. The credential-using component
-is therefore small, separate, and auditable on its own terms -- and it still never prints a
-secret.
-
-**Safety properties, each with a reason:** never retry a failed authentication (retry loops
-are what lock accounts, and the MAAS `admin` identity backs 19 automation call sites);
-never argv; never echo; stage-aware (a `pending` credential SKIPS, it does not fail, or
-every stage-5 OpenStack credential would read as broken); and **per-tenant credentials are
-REFUSED BY CONSTRUCTION** -- a declaration cannot opt them back in, because probing one
-means authenticating AS a tenant (D-069, ruling 3). NOT a deploy gate, for the same reason
-tier 2's remote half is not.
-
-**A false green in my own first real run.** `ssh` inside a `while read` loop consumed the
-loop's stdin: probe 1 ran, probes 2-13 were silently skipped, and the run exited **0**. A
-partial run reporting clean is precisely the failure class this tool exists to catch, in
-the tool itself. Fixed with `ssh -n` plus a redirect, and locked by a TOTAL ACCOUNTING check
--- every declared probe must land in exactly one bucket or the run is declared VOID.
-Regression-locked as T5; T8 asserts the `-n` that is easy to drop when editing the command.
-
-Declared coverage is 13 probes: 3 active today (one ssh key, two unauthenticated endpoint
-checks that prove the service answers WITHOUT spending the credential), 10 skipped -- 4 as
-stage-pending, 6 as `declared-only` with the reason recorded in the file so the decision is
-visible rather than an omission. OpenStack service credentials are declared NOW and will
-skip until Stage 5 lands, so the coverage exists the moment the stage runs.
-
-Harness `tests/creds-probe` **9/9** (gauntlet 80 -> **81**); phase-3 DC-standup DoD wired.
-
-**Revert:** delete `scripts/creds-probe.sh`, `creds-manifests/probes`, `tests/creds-probe/`,
-and the V2 block; drop the DoD paragraph.
diff --git a/docs/changelog-20260727-creds-consolidation.md b/docs/changelog-20260727-creds-consolidation.md
deleted file mode 100644
index eafa31a..0000000
--- a/docs/changelog-20260727-creds-consolidation.md
+++ /dev/null
@@ -1,499 +0,0 @@
-# changelog 2026-07-27 -- credential consolidation batch (SEC-021(b), SEC-025, V2 deferral)
-
-Session changelog (ONE per session, GA-R2/D1). Status claims live ONLY in
-`docs/CURRENT-STATE.md`; this file records WHAT changed, WHY, and HOW TO REVERT.
-
-Branch `dc-dc-stage4-phase3-maas-deploy`. Stage 4 stays OPEN; no gate closed.
-
-Operator question that opened the work (2026-07-27): "Check and confirm that we have a
-consolidated set of login creds on vcloud for all accounts currently created. Are there any
-creds that should be in place that are missing, need to be created, or have not been moved
-into their vcloud folders?" Operator direction after the audit: "clear the whole
-consolidation batch first" -- i.e. the consolidation items, NOT the dc0 edge-API re-mint,
-which was presented as a separate live-mutation item and is deliberately NOT done here.
-
----
-
-## 1. Audit capture (read-only)
-
-`docs/audit/creds-consolidation-audit-20260727.txt` -- the full three-site sweep, metadata
-only, no credential value read anywhere. Sections: live MAAS account enumeration,
-`creds-audit` x3, both jumphost and headend folder listings, the full
-`creds-matrix.py --tier2 --tier3 --remote --privileged` run, the cardinality/per-site
-blind-spot evidence, the human-principal row set, and the host-role declaration gap.
-
-**The finding that drove everything else:** `creds-audit` read CLEAN on all three sites
-while the matrix returned 13 findings, and the two most consequential gaps were in NEITHER
-surface -- they were found by enumerating the accounts that ACTUALLY EXIST. The register
-cannot report the absence of a credential it has no row for. `creds-audit` CLEAN remains
-not-evidence-of-completeness.
-
-Revert: delete the capture file (it is a record, nothing depends on it).
-
-## 2. dc1 svc public key backfilled to the headend store
-
-`voffice1:~/vr1-dc1-creds/vr1-dc1_svc_ed25519.pub` placed (0644), sha256-verified identical
-to the vcloud copy. Clears one `E1 EXPECTED-BUT-ABSENT` (SEC-022). Public-key material only.
-dc0's shadow store already held both halves; dc1's held only the private -- the mirror image
-of the dc0 gap in item 3.
-
-Revert: `ssh voffice1 'rm ~/vr1-dc1-creds/vr1-dc1_svc_ed25519.pub'`.
-
-## 3. dc0 MAAS->libvirt power key consolidated to vcloud (SEC-021(b))
-
-`~/vr1-dc0-creds/vr1-dc0-maas-power_ed25519` (0600) + `.pub` (0644), plus two rows in
-`creds-manifests/vr1-dc0.manifest`. This is SEC-021(b) executed as written: "dc0's key
-should gain a jumphost copy + manifest row". Clears `S2` x2 and `E1` x2.
-
-MEASURED before acting, because the naming looked like a defect and was not:
-
-- The headend's `maas-virsh_ed25519` and the region MAAS snap's `id_ed25519` are the SAME
-  key (fingerprint `SHA256:Dt/YXTXSF4nXGj9cz8f0owL+qreVpMYBVm/igW10FXY`).
-- It IS the dedicated SEC-012 key, not a reuse: the dc0 SERVICE key is a different key
-  (`SHA256:DBkeStCyf2qGi3SYuvN6hQ+EsepmhpkN9oulLz09uAs`), which is exactly what SEC-012's
-  ruling ("Dedicated MAAS->libvirt key" over reusing the dc0 service key) requires.
-- dc0 having NO per-host block in the snap's `ssh config` (so it uses the default identity)
-  is the RULED design, not drift -- SEC-016 states it: "Host 172.31.0.6 -> that
-  IdentityFile, so 172.31.0.2/dc0 keeps SEC-012".
-
-So NO re-mint was performed and no live power path was touched. The private half was copied
-from the voffice1 shadow store, sha256-verified byte-identical at both ends. The public half
-had never existed anywhere and was DERIVED with `ssh-keygen -y`, its fingerprint verified
-equal to the snap's installed key.
-
-Two things deliberately NOT done, both recorded rather than fixed:
-- The key's INTERNAL comment still reads `maas-virsh-pod (D-123 amendment)` -- it was minted
-  for the qemu+ssh pod attempt that was refuted the same day, and the per-machine
-  `power_type=virsh` ruling correctly retained it. Rewriting a comment alters key material;
-  the file name is now authoritative and the manifest comment carries the explanation.
-- Manifest `source` reads `local` to stay consistent with `--render` (which derives it and
-  would otherwise raise an S3 drift FAIL); the true provenance is in the manifest comment,
-  which S3 explicitly treats as out of scope. Writing `voffice1:<path>` there would have
-  traded one finding for another, and writing a custody change would have created two NEW
-  S5 asymmetries, since S5 compares `custody`.
-
-Revert: `rm ~/vr1-dc0-creds/vr1-dc0-maas-power_ed25519{,.pub}` and drop the two rows +
-comment block from `creds-manifests/vr1-dc0.manifest`. The headend and snap copies were
-never modified, so power control is unaffected either way.
-
-## 4. NetBox web-GUI admin password consolidated (SEC-025 OPENED)
-
-`~/vr1-office1-creds/netbox-admin-password` (0600), byte-identical to
-`office1-netbox:/root/netbox-secrets/admin.pass` (sha256-verified both ends, 28 bytes, value
-never printed or echoed). Register changes: the `netbox-admin` netbox row custody
-`off-manifest-known` -> `source-of-record`; a NEW jumphost row with custody `verbatim-copy`
-(so tier-3 V1 now asserts the two copies stay byte-identical); a manifest row; an extended
-`n-netbox-vm-secrets` note.
-
-This was a HUMAN GUI login that had never left the VM it was minted on -- the third instance
-of one miss class (SEC-009's `api.token`, SEC-020's `admin.pass`, now this). It produced no
-finding before this session because `off-manifest-known` asserts nothing about the jumphost.
-
-SEC-025 is opened for the exposure the remediation CREATES (a plaintext human password at
-rest on the jumphost), not for the gap it closed -- the same shape as SEC-007 and SEC-020,
-with the same rotation obligation and the same both-copies-or-stale-trap hazard.
-
-Revert: `rm ~/vr1-office1-creds/netbox-admin-password`; revert the matrix row pair, the
-manifest row, the note paragraph, and the SEC-025 ledger row. The VM copy is untouched.
-
-## 5. V2 learns the ruled-deferral state, and gains its first harness cases
-
-`scripts/creds-matrix.py`: `load_sec_states` now also reports whether a declared-dead SEC row
-carries an operator-ruled deferral; `v2_declared_state` emits `V2 ACKNOWLEDGED DEFERRAL`
-instead of a FAIL when it does.
-
-WHY: SEC-006 has read "**DEFERRED by operator ruling 2026-07-13: revoke at completion of this
-deployment**" since long before this checker existed. V2 was reporting that standing operator
-ruling as a defect on every run -- which is both wrong and corrosive, because a finding that
-can never be actioned trains readers to skip findings. **Reissuing the token would have
-contravened the ruling**, so the register was the thing that needed to change, not the
-credential.
-
-The acknowledgement is NOT a pass. It names the id, the SEC row, the state word and the
-ruling text, and states that the credential "is still live and still exposed until that
-ruling is discharged".
-
-`DEFERRAL_RE` demands BOTH the emphasis-cased state word AND explicit attribution to an
-operator ruling (the GA-R5 bar), and `[^|]` stops it crossing a ledger table cell. A looser
-match would let prose that merely DISCUSSES deferring buy silence -- the false-green class
-this register exists to prevent. T58 and T59 are the regression locks for exactly that.
-
-Also added `--ledger` (default unchanged). V2 read the SEC register via `--repo`, which the
-harness must point at the REAL repo for S4 mint-ref resolution -- so there was no fixture path
-to the ledger and **V2 had shipped with ZERO harness cases**. The override is what makes it
-testable; it also de-couples the existing tier-3 cases from the live ledger.
-
-New cases T56-T59 (harness 56 -> 60): the founding invariant still fails; a ruled deferral is
-acknowledged and still says EXPOSED; unruled "deferred" prose still fails; a claim spanning
-two ledger cells does not count as ruled.
-
-NOTE: tier 3 is NOT part of preflight `P5` (which runs tier 1 + tier-2-local), so this does
-not change the blocking deploy gate's behaviour.
-
-Revert: `git revert` this commit's changes to `scripts/creds-matrix.py` and
-`tests/creds-matrix/run-tests.sh`; V2 returns to failing on SEC-006 every run.
-
-## 6. Permission allowlist widened for read-only commands (`.claude/settings.json`)
-
-Transcript scan of the 44 most-recent session JSONLs across both project dirs, counting Bash
-leading command+subcommand pairs (and splitting each candidate into LOCAL vs
-nested-inside-`ssh`, since a command that only ever runs inside `ssh host '...'` gains nothing
-from its own rule -- the outer `ssh` is what the permission layer matches).
-
-ADDED to `permissions.allow` only -- 13 entries, 31 -> 44. `ask`, `deny`, `env` and `hooks`
-untouched; nothing removed or reordered; JSON re-validated and de-duplicated:
-
-    bash scripts/creds-audit.sh *          (33)   bash scripts/dc-dc-ceph-disk-budget.sh * (13)
-    bash scripts/site-baseleg.sh check*     (5)   tofu validate* + tofu -chdir=* validate*  (25)
-    tofu state list* + -chdir variant      (16)   tofu state show*                           (3)
-    tofu providers schema*                 (13)   tofu version*                             (11)
-    ip route*                              (22)   systemctl is-active *                      (6)
-
-DELIBERATELY NOT ADDED, and this is the substantive half of the item:
-
-- **`ssh` (693 calls), `scp` (47), `virsh` (234)** -- the three biggest prompt sources, left
-  alone. They are this cloud's MUTATION TRANSPORT. CLAUDE.md hard rule 3 makes the `ask` rules
-  the enforcement mechanism for per-mutation approval and says not to work around them, and
-  the `Bash(ssh *)` disposition is an OPEN operator item queued at the 2026-07-23 close.
-  Allowlisting any ssh shape would bypass the gate AND pre-empt an unresolved operator
-  decision. **This item does NOT discharge that queued prune -- it is still open.**
-- **`python3 scripts/creds-matrix.py` (76 local runs -- the largest genuine miss)** -- skipped
-  because `Bash(*creds-matrix.py *--privileged*)` is an `ask` rule added 2026-07-26 precisely
-  after the auto-mode classifier incident. Every prefix pattern wide enough to cover the
-  observed `... 2>&1 | tail` forms would ALSO match `--privileged`, and allow-vs-ask precedence
-  was not verified this session. Adding a rule that might silently downgrade an
-  operator-installed gate is exactly the class of change hard rule 3 forbids. Needs the
-  precedence question answered first, then a narrow set of EXACT forms.
-- **`tofu plan` (54)** -- read-only in effect, but CURRENT-STATE section 10 says in terms "Do
-  NOT re-run `tofu plan` casually against live state". The prompt is deliberate friction.
-- `python3 -c`/heredocs (324) and shells: arbitrary code execution. `curl` (114): a mutation
-  vector via `-X`/`-d`. `tofu fmt` (26): rewrites files. `tofu init` (10): mutates
-  `.terraform/`. `nft list` (10): normally needs `sudo`, which correctly stays `ask`.
-
-TWO OBSERVATIONS, no action taken (flagged, not fixed): several existing allow entries are
-redundant with Claude Code's built-in auto-allow (`Bash(git status*)`, `Bash(git log*)`,
-`Bash(grep *)`, `Bash(ls *)`, `Bash(jq *)`, `Bash(cat scripts/*)`) -- harmless, and removing
-entries was out of scope; and `Bash(git pull*)` sits in `allow` although it is a fetch-and-merge
-that mutates the working tree.
-
-Revert: drop the 13 appended lines from `permissions.allow` in `.claude/settings.json`. No
-other field was touched, so the revert is a contiguous deletion.
-
-## 7. Stage 4 close-out opened: `dc-mirror.sh check` was FALSE-GREENING the mirror gate
-
-Operator direction: close Stage 4 before resuming the DC1 Stage-5 chain. The Stage 4 DoD
-(`runbooks/dc-dc-phase3-maas-enlist-deploy.md:472-485`) has six bullets; four are already met
-and captured. Verifying the fifth -- "per-DC mirror reachable" -- found that **the check the
-gate would close on could not fail.**
-
-`scripts/dc-mirror.sh:271-273` tested `[ -f last-sync.status ]` and printed the file's contents
-behind an unconditional `OK`. So the status word was displayed but never asserted on, and the
-check exited PASS regardless. MEASURED on both racks, 2026-07-27:
-
-- **dc0** read `FAIL 2026-07-27T00:54:54Z ubuntu=255 uca=0` -> printed `OK`, check PASS.
-- **dc1** read `RUNNING 2026-07-23T21:49:35Z` -- a marker FOUR DAYS stale, left by the
-  debmirror the D-135 amendment killed with a signal, so it never wrote a terminal state ->
-  printed `OK`, check PASS.
-
-FIXED: the status word is now case-analysed. `OK*` passes; `FAIL*` misses; an ABSENT file
-misses (it was a passing `note`, but nothing has attested the content); an unrecognised word
-REFUSES rather than defaulting to success. `RUNNING*` is deliberately neither -- in-flight and
-died-mid-run are indistinguishable from the file alone, so it reports an explicit UNKNOWN and
-cross-checks the unit: a RUNNING marker with no active unit is named as a corpse, not a
-success. Harness `tests/dc-mirror/run-tests.sh` **24/24** (was 19); T20-T24 lock each status
-word, T24 specifically locks out the return of the exact defective shape.
-
-PROOF THE FIX WORKS -- re-run against both live racks, and the gate is now honestly NOT MET:
-`dc-mirror check (dc0): FAIL` on the failed sync, `dc-mirror check (dc1): FAIL` on the stale
-marker. Capture `docs/audit/stage4-mirror-gate-20260727.txt`.
-
-SUBSTANCE BEHIND THE TWO FAILURES (measured, not inferred):
-
-- **dc0's mirror CONTENT is complete and intact** -- 949G ubuntu + 342M cloud-archive, all
-  three dists (`jammy`, `jammy-updates`, `jammy-security`) plus `pool` and `project`. What
-  failed is the overnight INCREMENTAL: `Download of dists/jammy/Release failed: 500 read
-  timeout` -> "Failed to download some Release, Release.gpg or InRelease files!" -> debmirror
-  aborted the ubuntu leg with 255. The UCA leg succeeded (`uca=0`). A transient upstream fetch
-  failure, not mirror damage. The daily timer re-arms for 2026-07-28 00:14:48.
-- **dc1's debmirror is dormant only ACCIDENTALLY.** `dc1-mirror-sync.timer` is `enabled` with
-  an EMPTY `NextElapseUSecRealtime`, because the service sits in `failed`/`Result=signal` from
-  the 07-24 pause. The D-135 amendment RULED it paused and "kept dormant as the fallback", but
-  nothing enforces that -- the dormancy is a side effect of a failed unit, not a declared
-  state, so a `systemctl reset-failed` (or possibly a reboot) re-arms a 330G -> ~949G pull on
-  a rack whose ruled artifact path is now the proxy. dc1's PROXY meanwhile checks **PASS**
-  genuinely: apt-cacher-ng active on `.4:3142`, serving both archive and UCA `Release` with 200.
-
-Revert: `git revert` this commit's `scripts/dc-mirror.sh` + `tests/dc-mirror/run-tests.sh`
-changes -- the check returns to passing unconditionally on last-sync. No live state was
-altered by this item; both racks were read only.
-
-## 8. G17 opened by ruling; DoD bullets 5 and 6 repaired (DOCFIX-204)
-
-**RULING (GA-R5), 2026-07-27.** Question as presented: "The node-side half of bullet 5. Nodes
-are powered off by the READY-handoff ruling, so no node-side probe can run as things stand.
-Either a gated rescue-boot check on one node per DC now (closes it inside Stage 4), or split it
-into its own gate row targeted at Stage 5 first boot (GA-R6 E3 explicitly permits this; a
-conditional close is not permitted)." Operator answer, exact utterance: **"split it into its
-own gate row"**. Recorded in the **G17** row of `docs/CURRENT-STATE.md`, which is the authority;
-committed and pushed before any dependent work (GA-R5).
-
-**G17 -- "Per-DC artifact source reachable FROM A NODE"**, [V], OPEN. Per DC: dc0 -> `curl -sI
-http://10.12.8.4/` returns 200 from a booted node; dc1 -> apt fetches through the proxy at
-`10.12.68.4:3142`, because dc1's ruled artifact path is the CACHING PROXY and it has no
-node-facing mirror (D-135 amendment) -- checking it as one fails by design. Natural trigger is
-Stage 5 first boot. The row states explicitly that G17 is NOT a Stage-5 precondition and must
-not be conflated with one: Stage 5's bootstrap needs OPEN edge egress for the juju agent stream
-and snaps (D-135 items 2-3 unbuilt), which is a different path from the apt artifact source.
-
-What REMAINS in Stage 4 for bullet 5 is the rack-side half -- the source answers on its own
-address with an attested-current sync. dc1's proxy already PASSES; dc0 does not yet, pending
-the sync re-run (item 7).
-
-**DOCFIX-204 -- bullet 6 was unsatisfiable, and its stale text had spread to four surfaces.**
-"NTP from the DC's own OPNsense edge working" is SUPERSEDED by D-129(iv) (RULED 2026-07-21,
-"Keep MAAS hierarchy (Recommended)", no NTP role on the edge). The DoD asked you to confirm the
-edge is the time source, which the ruling had already refused -- so the bullet could never be
-met by a correctly-built DC. Repaired in:
-
-- `runbooks/dc-dc-phase3-maas-enlist-deploy.md` DoD -- bullet 6 STRUCK with its supersession
-  cited; bullet 5 rewritten per-DC with the split recorded.
-- the same runbook's **Step 7, rewritten**. It had THREE defects, each recorded rather than
-  quietly patched because the old text is the kind that gets followed: it still branched on
-  gap #5 ("if the mirror does not exist yet, STOP") which D-135 resolved; it applied one mirror
-  check to both DCs, which fails on dc1 by design; and both its checks said "from a deployed
-  node", which the READY-handoff ruling makes impossible in this stage. Now it invokes the two
-  site checkers (with the hard-rule-2 note to take rack transit IPs from `lib-hosts.sh`, never
-  memory) and carries the MAAS-hierarchy time check as a Stage-5/G17 observation.
-- `docs/dc-dc-deployment-workflow.md:206` -- the Gate cell also still said "Nodes deployed",
-  contradicting DOCFIX-200's READY handoff. Both fixed.
-- `docs/dc-dc-buildout-design.md:120` -- corrected with the supersession noted inline.
-- `runbooks/dc-dc-phase4-juju-bundle-per-dc.md:26` -- prerequisites said "nodes Deployed",
-  which is precisely the expectation DOCFIX-200 removed to stop Stage 5 breaking; plus a new
-  block making this stage the OWNER of G17's captures, with the warning that first boot is the
-  observation window and missing it forces a deliberate rescue-boot.
-
-Revert: `git revert` this commit's doc/runbook changes; the G17 row and the DOCFIX-204 edits
-are text-only, and no live state was touched.
-
-## 9. dc0 sync re-run; dc1 full mirror REMOVED after moving the proxy's net layer (D-135 amendment)
-
-**dc0 (gated).** `systemctl start dc0-mirror-sync.service` -> `OK 2026-07-27T08:43:46Z
-ubuntu=0 uca=0` in **20 seconds**, confirming the transient-`500` diagnosis exactly. Fixed
-`dc-mirror.sh check dc0` now reports **PASS** -- trustworthy precisely because the same check
-FAILED on the same rack twenty minutes earlier. **Stage 4 DoD bullet 5 is now MET for both DCs.**
-
-**dc1 -- the record was wrong about intent.** CURRENT-STATE said the debmirror was "PAUSED ...
-kept dormant as the fallback". Operator, exact utterance: "DC0 is the test of a full mirror.
-DC1 is the test of the mirror proxy. DC1 needed the partially created full mirror and
-associated script/files/settings removed." Recorded as a **D-135 AMENDMENT 2026-07-27**: the
-per-DC split is the DELIBERATE EXPERIMENT, not an interim -- no fallback, no later
-convergence. That also supersedes the "DC1's proxy is REPLACED by a full mirror afterward"
-claim, which was in THREE places (D-135, CURRENT-STATE:109, `dc-cache-proxy.sh:6`); all three
-corrected.
-
-**The coupling trap, and why sequencing mattered.** Asked whether to rip down and rebuild
-rather than pick and choose, I found the rebuild path was BLOCKED, not merely slower:
-`dc-cache-proxy.sh` did not own its utility net layer -- its header said it REUSES
-`dc-mirror.sh`'s `<site>-mirror-net.service` and "fails loud if absent". So on dc1 three files
-named `dc1-mirror-*` (net unit, apply helper, resolved DNS drop-in) were load-bearing FOR THE
-PROXY. Therefore (a) the 07-23 changelog's recorded removal ("stop/disable ... -net.service,
-rm the generated files") would have silently killed the proxy, the Stage-4 bullet-5 PASS, and
-the Stage-5 dc1 apt path; and (b) the proxy could not be REBUILT afterward, since nothing but
-`dc-mirror.sh install` created the net layer -- rebuilding a PROXY meant reinstalling the whole
-MIRROR apparatus, enabled daily timer included. Operator direction: "Do the net layer first,
-then rip it all down."
-
-**Step 1 -- net layer moved (script change).** `dc-cache-proxy.sh` now owns
-`<site>-cache-proxy-net.service` + `<site>-cache-proxy-net-apply` + its own
-`resolved.conf.d/<site>-cache-proxy.conf`, reusing dc-mirror's proven mechanism (bridge
-resolved from the libvirt net NAME at runtime, hard rule 3). Neutrally named so a proxy-only
-DC carries NO mirror-named dependency. Idempotent `ip addr replace` / `ip route replace` on
-identical MEASURED values, so the two net units coexist safely where a site runs both -- dc0
-is unaffected. `check` asserts the ARTIFACTS, not just the live address/route, because
-asserting only the live effect would PASS while the layer was really the mirror's: it would
-look independent and break on teardown, the exact failure being removed.
-
-Harness **20/20** (was 15). **T12 was REPLACED, not deleted** -- it asserted the superseded
-design ("net layer reused ... no ip addr/route writes; points at dc-mirror.sh"), so it failed
-by design once the ruling landed. It is now INVERTED (T12: owns the layer) plus T12b-T12f
-(no operative dc-mirror referral; proxy-named artifacts; enabled-not-just-started; check
-asserts artifacts; idempotent verbs only). T12b is deliberately scoped to NON-COMMENT lines:
-the header's account of WHY the coupling was removed cites `dc-mirror.sh install`, and deleting
-that history to satisfy a grep would lose the reason the trap existed.
-
-**Step 2 -- independence PROVEN before deleting anything.** A `oneshot` with
-`RemainAfterExit=yes` does not undo its work on stop, so merely stopping
-`dc1-mirror-net.service` would have proven nothing. The live state was removed outright --
-`ip addr del 10.12.68.4/22` (count -> 0) and `ip route del default via 10.12.64.1` (count ->
-0) -- then the proxy-owned unit applied ALONE restored both, and `check dc1` returned **PASS
-with the mirror net unit disabled**.
-
-**Step 3 -- wholesale removal, no picking and choosing.** All mirror units, the timer, the sync
-helper, the nginx vhost, the resolved drop-in, the `debmirror` package, and the **330G** of
-partial mirror (33,037 files; `rm -rf` **47.6s**; rack disk 339G -> 9.0G). Zero mirror-named
-residue; every proxy artifact present; proxy PASS throughout and never down. Capture
-`docs/audit/dc1-mirror-teardown-20260727.txt`.
-
-nginx **left installed, deliberately**: it was a mirror prereq, but with the vhost gone it is a
-generic server on its stock `default` vhost. Removing the metapackage while `nginx-core` keeps
-running is a half-measure worse than either extreme, and a full purge is scope creep on a rack
-host. If dc1 is ever rebuilt as a mirror, `dc-mirror.sh install` fail-louds with the exact apt line.
-
-Revert: reinstall via `dc-mirror.sh install dc1` (recreates units/vhost/timer; needs the
-`debmirror` package reinstalled first) then `sync dc1` to re-pull ~950G. **The 330G partial is
-NOT recoverable** -- deliberately, per the amendment. The proxy net layer reverts by
-`git revert` of `scripts/dc-cache-proxy.sh` + its harness, then re-running
-`dc-mirror.sh install dc1` to restore the mirror-owned layer.
-
-## 10. Carve residue cleaned (108 fabrics -> 17); dc1's leftover nginx removed
-
-Capture `docs/audit/stage4-carve-residue-cleanup-20260727.txt`. Both items were queued to the
-stage close at the 2026-07-23 carve.
-
-**nginx on dc1.** Purged `nginx` + `nginx-common` (dry-run first: nothing else depended on them,
-and no `nginx-core` was installed), plus autoremove of `liblockfile-simple-perl` and
-`liblog-agent-perl` -- debmirror's orphaned perl deps. `/etc/nginx` gone, nothing listening on
-:80, proxy still PASS on :3142. dc0 keeps its nginx and was re-verified unaffected (it serves
-the mirror).
-
-**Carve residue: 108 fabrics -> 17.** Deleted subnet id=8 `192.168.1.0/24` (the superseded
-OPNsense FACTORY LAN -- both edges were re-addressed to 10.12.4.1 / 10.12.64.1), then fabric-5,
-then the 90 auto-created empties (ids 6..95).
-
-The audit caught an **ordering dependency the original flag did not state**: the
-192.168.1.0/24 subnet was the ONLY occupant of fabric-5, so deleting the fabric first would
-have cascaded the subnet away rather than removing it cleanly. Subnet first, then the fabric.
-
-METHOD, chosen because of this repo's own history: a MAAS fabric delete cascades to its VLANs,
-and the 2026-07-21 pod-delete incident cost 9 machine records precisely because the association
-check ran AFTER the delete. So emptiness was PROVEN per fabric -- zero subnets, zero ipranges,
-zero node interfaces across all of its VLANs -- against a fresh occupancy snapshot (fabrics +
-subnets + ipranges + every machine's `interface_set`) taken immediately before the batch, and
-the cascade check was re-run afterwards as well.
-
-KEPT, all verified occupied and enumerated in the capture: office1 base + GUA (fabric-0),
-office1 compose with its 2 LXD guests (fabric-1), both transits (fabric-2 / fabric-141), both
-metal-admin/boot fabrics with 9 nodes each (fabric-4 / fabric-142), libvirt default (fabric-3),
-and the 10 named plane fabrics (`vr1-dc0-*` / `vr1-dc1-*`, 9-18 interfaces each).
-
-POST-STATE: 18 Ready + 2 Deployed office1 guests, all 18 still `power_type=virsh`, 7 interfaces
-each (6 flat planes per D-133 + br-ex), **ZERO orphaned interfaces**, placement tags 9+9 intact,
-and both DCs' artifact paths re-verified PASS after everything.
-
-Revert: fabrics and subnets are MAAS records, not config -- there is no undo. Recreating them
-would mean `maas admin fabrics create` + `subnets create`, but nothing needs them: the 90 were
-auto-created empties, and 192.168.1.0/24 was a superseded factory address. The nginx purge
-reverts with `apt-get install nginx` (dc1 has no use for it while it is the proxy DC).
-
-## 11. SEC-024 retention RULED -- keep both state-surgery snapshots
-
-**RULING (GA-R5), 2026-07-27.** Question as presented: 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 Office1 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"**.
-
-`opentofu/terraform.tfstate.pre-G6-20260719` and `.pre-G16-20260721` are RETAINED at 0600,
-neither git-tracked, as the only record of what the state looked like before the two direct
-tfstate edits (G6 autostart injection, G16 `channels = []`).
-
-SEC-024 therefore stays **OPEN as a standing WATCH, not an open remediation**: its mode defect
-is fixed, but the umask CAUSE was out of ruled scope, so a future apply may rewrite 0664 and
-preflight P5 is the detection. Recorded in both the SEC-024 disposition cell and CURRENT-STATE.
-Open SEC count unchanged at 21.
-
-## 12. set-interface-v4 reload amendment RULED + implemented (the last queued stage-close item)
-
-**RULING (GA-R5), 2026-07-27.** Question as presented: (a) add `configctl filter reload` to the
-script's `--commit` path; (b) leave the script and rely on DC standup DoD item 8; (c) add it
-behind an opt-in flag. Operator answer, exact utterance: **"a"**. OPS under GA-R3 -- a script fix
-completing an already-documented operation, governed by D-113; no new D-number.
-
-THE DEFECT (appendix-A, measured on the fresh dc1 edge 2026-07-23): `--commit` ran `configctl
-interface reconfigure`, which applies the address to the kernel but does NOT regenerate the pf
-ruleset, so OPNsense never creates its automatic outbound-NAT rules for the (re-)addressed LAN.
-Forwarded LAN packets leave the WAN un-NAT'd and replies never return -- the edge passes NO LAN
-traffic while looking perfectly configured. Self-masking: any later plugin install or config
-apply reloads the filter as a side effect, so dc0's 07-20 qga work hid it there until dc1, which
-had no later work, exposed it at the mirror build.
-
-Option (b) was rejected on evidence, not taste: DoD item 8 already existed and did not fire at
-dc1, and prose-only controls have a measured failure record here (D-137's own enforcement sat as
-prose at `phase-3:498` and missed BOTH DC standups).
-
-**THE PLACEMENT IS THE SUBSTANCE OF THE FIX, and my first attempt got it wrong.** I initially put
-the reload on the next line of the `interface reconfigure` heredoc. That would have been a fix
-that fixes nothing exactly when it matters: re-addressing the interface you arrived on drops the
-session DURING the reconfigure, so a following command in that stream never executes on the edge
--- and that drop case IS this incident's scenario (dc1's LAN moved 192.168.1.1 -> 10.12.64.1 over
-the LAN itself). Caught before shipping. As delivered, the reload runs over a FRESH connection to
-`PROBE_HOST`, the address the edge answers on after the move.
-
-Also added a `pfctl -s nat` read-back with the `proto carp` boilerplate filtered out -- that
-boilerplate-only state is precisely appendix-A's broken-state signature. It is REPORTED, not
-gated: at an edge's very first addressing there may legitimately be no gateway and so no NAT to
-generate, and hard-failing would block a correct run. The hard gate stays address-on-the-kernel.
-
-Harness **59/59** (was 53). Cases 15-15f: the reload exists; it is NOT inside the reconfigure
-heredoc; it targets `PROBE_HOST`; the NAT read-back exists with carp excluded; the read-back does
-not hard-exit; and appendix-A no longer calls the amendment an unruled queued option. **Case 15f
-caught a real inconsistency** -- appendix-A still said "not yet ruled" -- and case 15e caught a
-bug in my own first draft of it, which scanned to EOF and so failed the script for having the
-very hard gate the case exists to preserve.
-
-appendix-A's entry rewritten: the FIX stays (for an edge already in this state), plus a
-PREVENTED-IN-THE-TOOL block recording the placement detail and why prose prevention was rejected.
-
-Revert: `git revert` the `scripts/opnsense-set-interface-v4.sh` +
-`tests/opnsense-set-interface-v4/run-tests.sh` + appendix-A changes. No live edge was touched --
-both DC edges are already addressed, so this affects only the NEXT edge addressing.
-
----
-
-## Findings LOGGED, not actioned (hard rule 1)
-
-1. **dc0 edge API credential (`opnsense-api.txt`) is absent from every DECLARED location** --
-   not the jumphost folder, not the headend shadow store. It exists only inside the dc0
-   edge's own config. Recovery is a re-mint via `scripts/opnsense-bootstrap-apikey.sh` (the
-   dc1-proven path; dc0's edge SSH key IS present on vcloud), which is a live mutation on a
-   running edge and was explicitly OUT of this batch. This is the sole remaining SEC-021(a)
-   item and accounts for 2 of the 7 residual findings.
-2. **No registered root/console credential at EITHER DC edge.** MEASURED: no matrix row, no
-   manifest entry, no SEC row. `office1-edge-root` is `cardinality=per-site` and office1-only.
-   NOT MEASURED, and deliberately not probed: what those root passwords actually are. The
-   phase-2 runbook says DC edges boot on FACTORY DEFAULTS and the D-112(c) chain installs
-   sshd + the service key without setting a root password -- but that is a repo reading, not
-   a measurement (hard rule 2). Root SSH is key-only (proven), so SSH is not the vector; the
-   web GUI is LAN-reachable at both edges and the serial console exists. Proposed as the
-   next-free SEC row once the operator gates a probe.
-3. **Two structural blind spots that let (2) hide.** (a) `S5` compares only
-   `cardinality=per-DC` (`creds-matrix.py:380`); all SIX `per-site` rows are office1-only, so
-   a per-site credential missing at two of three sites is invisible to every check. This is
-   the "cardinality largely inert" item CURRENT-STATE already carries -- now with a concrete
-   consequence. (b) `creds-manifests/vm-secret-locations` declares only `jumphost`,
-   `headend`, `netbox`, while the checker also accepts `rack`, `edge`, `cloud`, `unit`,
-   `client` -- all with zero declared locations, therefore unaudited. SEC-015 was a
-   rack-resident edge-key copy, so the class is not hypothetical.
-4. **The 3 residual S5 power-key asymmetries are RULED, not defects.** SEC-016 designs dc0 to
-   keep the snap's default identity while dc1 gets a named per-host key, so the filenames can
-   never match and `DC_TOKEN_RE` cannot normalise them. The register needs a way to record a
-   ruled exception; suppressing them silently would be wrong and renaming live files to
-   satisfy a checker would be worse. Needs an operator decision on mechanism.
-5. **dc0/dc1 creds folders carry no README** while office1 does (`creds-folder-readme`, also
-   `per-site`). Cosmetic; noted for symmetry.
-6. **The headend shadow stores (SEC-022) are now redundant for dc0's power key** -- vcloud
-   holds the copy SEC-021(b) asked for. Deleting the shadow copy is a plausible follow-up but
-   is destructive and out of scope.
-
-## Verification
-
-- `tests/creds-matrix/run-tests.sh` -- **60/60 PASS** (was 56).
-- `scripts/creds-audit.sh` all three sites -- CLEAN (office1 14 entries, dc0 7, dc1 8).
-- `creds-matrix.py --tier2 --tier3 --remote --privileged` -- 82 rows, findings **13 -> 7**.
-  Cleared: S2 x2, E1 x3 (2 power-key + 1 dc1 `.pub`), V2 x1 (now an acknowledged deferral).
-  Residual 7: dc0-edge-api (2, needs the excluded re-mint), S5 x3 (ruled, item 4 above),
-  S6 conflation x1 (the SEC-020 defect, separate), E4 uncheckable x2 (Stage-5/6 rows).
-  **The register is NOT green and is not expected to be.**
-- `scripts/repo-lint.sh` + full gauntlet: see the commit message for the recorded results.
-- `.claude/settings.json` (item 6): `json.load` parses, 44 allow entries, zero duplicates,
-  `ask` 52 / `deny` 15 / `env` / `hooks` byte-unchanged.
diff --git a/docs/security-ledger.md b/docs/security-ledger.md
index a0ffb3a..697592b 100644
--- a/docs/security-ledger.md
+++ b/docs/security-ledger.md
@@ -23,17 +23,17 @@
 | SEC-013 | 2026-07-20 | **MAAS API key materialized to disk on the region.** An admin-scoped MAAS API key (`consumer:token:secret`) was placed by the operator in a 0600 file on `voffice1` so the `opentofu/vr1-dc0-maas` root could consume it via `TF_VAR_maas_api_key`. It grants FULL MAAS admin API access (machines, power, deploy, users). Two exposure surfaces beyond the file itself: (a) the OpenTofu **state file** of any root that uses the maas provider records it -- unavoidable with this provider, so that state inherits credential handling (0600, never committed); (b) a MAAS CLI profile was also created for the operator user from the same key. It was verified by FORMAT ONLY (71 bytes, 3 colon-separated parts) and never printed, echoed, or passed in argv. | 2026-07-20 step-D part 2; `opentofu/vr1-dc0-maas/main.tf` header; session changelog item 15 | operator | **OPEN -- rotation obligation (surface NARROWED 2026-07-21).** The retire-fully ruling was executed 2026-07-21: `opentofu/vr1-dc0-maas` removed from the repo, the on-disk key file (`~/vr1-dc0-creds/maas-api-key.txt` on voffice1) and the root's `terraform.tfstate` DELETED, absence verified by listing (session changelog 2026-07-21 items 13-15; NOTE the pod-object deletion cascaded to the 9 machine records -- incident capture `docs/audit/incident-20260721-pod-delete-cascade.txt`, recovered same-day). REMAINING surface: the operator's MAAS CLI profile only. Rotate the underlying API key at v1 close, or immediately if `voffice1` is rebuilt/shared. Custody detail off-repo per D-069. |
 | SEC-014 | 2026-07-21 | **Rack cluster secret exposed to session context.** During the commissioning diagnosis, a read of `/var/snap/maas/<rev>/agent.yaml` on the DC0 rack (hunting the agent resolver's config surface) returned the rack's MAAS cluster `secret` into the Claude session context, the operator terminal scrollback, and the as-executed log (`~/as-executed/2026-07-21-ops-commissioning-diag.log`, 0600, jumphost-only). The secret authenticates rack<->region enrollment. The read was not anticipated to contain a credential (config file, not a key file); disclosed same-session. | 2026-07-21 session changelog item 6; docs/audit/commissioning-diag-20260721.txt | operator | **OPEN -- rotation obligation.** Rotate the MAAS shared secret (= rack re-enrollment for `7chphy`) at a convenient maintenance point, or immediately if session artifacts leave the jumphost. Process fix queued: add `agent.yaml` to the guard hook's never-read list alongside key/cred globs. |
 | SEC-011 | 2026-07-16 | **Node least-connectivity gap (not an L2 breach).** Under D-121 Option C role separation, all nodes get a uniform 6-plane NIC set, so a ceph-osd STORAGE node has a leg on provider-public (external/FIP) + data-tenant (tenant geneve) -- planes it never binds per D-052. Planes stay isolated L2 (no crosstalk). | 2026-07-16 plane-segregation review; `opentofu/main.tf` `local.vr1_dc0_node_nics` | operator | **CLOSED 2026-07-16 (operator ruling -- keep uniform 6-NIC).** Review R3-F10: A2's cross-examination refuted the attack-surface concern -- in the isolated-L2 sim the unbound vNICs have no reachability out, and pruning would INCREASE Roosevelt-delta (baremetal trunks all VLANs to every node on bonded NICs, so all planes are present regardless of L3 binding). Uniform 6-NIC is the more Roosevelt-faithful model. Accepted non-issue; no code change. |
-| SEC-015 | 2026-07-23 | **dc1 edge SSH private key staged transiently on the DC1 rack.** The `vr1-dc1-edge_ed25519` private key (root-granting on `vr1-dc1-opnsense`) was scp'd to `vvr1-dc1:~/vr1-dc1-edge_ed25519` (0600) so `opnsense-bootstrap-apikey.sh` -- which SSHes the edge directly, no ProxyJump -- could mint the API key there (dc0 method). It existed on the rack only for the mint + v4-addressing phase and was `shred -u`'d immediately after (absence verified by `ls`). The permanent copy stays on vcloud `~/vr1-dc1-creds/` (SEC-007 pattern: edge SSH is the only management path -- a rotation obligation, not a delete-me). | 2026-07-23 session changelog item 6; docs/changelog-20260723-g12-dc1-edge.md | operator | **OPEN -- rotation obligation (transient exposure already remediated).** The on-disk rack copy is gone; the standing surface is the vcloud key + the minted API key/secret (`~/vr1-dc1-creds/opnsense-api.txt`). Rotate both at v1 close, or immediately if vcloud is rebuilt/shared. Roosevelt note: metal edges reached differently may avoid the rack-staging step entirely (a ProxyCommand-from-vcloud mint keeps the key off the rack -- deferred, not adopted this build to stay on the dc0-proven path). |
+| SEC-015 | 2026-07-23 | **dc1 edge SSH private key staged transiently on the DC1 rack.** The `vr1-dc1-edge_ed25519` private key (root-granting on `vr1-dc1-opnsense`) was scp'd to `vvr1-dc1:~/vr1-dc1-edge_ed25519` (0600) so `opnsense-bootstrap-apikey.sh` -- which SSHes the edge directly, no ProxyJump -- could mint the API key there (dc0 method). It existed on the rack only for the mint + v4-addressing phase and was `shred -u`'d immediately after (absence verified by `ls`). The permanent copy stays on vcloud `~/vr1-dc1-creds/` (SEC-007 pattern: edge SSH is the only management path -- a rotation obligation, not a delete-me). | 2026-07-23 session changelog item 6; docs/archive/changelogs/changelog-20260723-g12-dc1-edge.md | operator | **OPEN -- rotation obligation (transient exposure already remediated).** The on-disk rack copy is gone; the standing surface is the vcloud key + the minted API key/secret (`~/vr1-dc1-creds/opnsense-api.txt`). Rotate both at v1 close, or immediately if vcloud is rebuilt/shared. Roosevelt note: metal edges reached differently may avoid the rack-staging step entirely (a ProxyCommand-from-vcloud mint keeps the key off the rack -- deferred, not adopted this build to stay on the dc0-proven path). |
 
-| SEC-016 | 2026-07-23 | **Dedicated dc1 MAAS->libvirt power key (per-DC isolation -- operator-ruled).** dc1 commissioning needs `power_type=virsh`, which has the REGION's MAAS snap SSH to the dc1 rack's libvirt to power-cycle nodes. RULING (GA-R5) -- question presented: "How should the region drive the dc1 rack's libvirt for node power control (power_type=virsh)?" options (A) reuse the SEC-012 key on dc1, (B) mint a dedicated dc1 power key. Operator answer, exact utterance (option selected): **"Mint a dedicated dc1 power key"** -- a SEPARATE per-DC MAAS->libvirt keypair, NOT cross-DC reuse of SEC-012's key. Mechanism: private half in the region MAAS snap (`/var/snap/maas/current/root/.ssh/` + per-host `ssh config` Host 172.31.0.6 -> that IdentityFile, so 172.31.0.2/dc0 keeps SEC-012 and 172.31.0.6/dc1 uses this one); public half authorizes jessea123 (libvirt group) on the dc1 rack. The maas-node-power SCRIPT's own mapping virsh (jessea123 on voffice1) uses the dc1 SERVICE key via voffice1 `ssh config` -- the dc0 split exactly (script=svc key, MAAS=dedicated key). | 2026-07-23 session changelog; docs/changelog-20260723-g12-dc1-edge.md; dc0 precedent SEC-012 | operator | **OPEN -- rotation obligation.** (1) ROTATE at v1 close or if the region/dc1 rack is rebuilt/shared. (2) Same libvirt-group SCOPE hardening candidate as SEC-012 (power-only polkit grant). (3) FRAGILITY: the snap-side key + ssh config live under per-revision `/var/snap/maas/current/` and may not survive a snap refresh -- re-assert after any refresh (queued to DC standup DoD). Roosevelt-relevance: establishes PER-DC power-credential isolation (bare metal: per-DC IPMI/BMC creds, never a shared cross-DC power credential) -- whether that becomes a standing D-principle is a follow-up, not blocking. |
+| SEC-016 | 2026-07-23 | **Dedicated dc1 MAAS->libvirt power key (per-DC isolation -- operator-ruled).** dc1 commissioning needs `power_type=virsh`, which has the REGION's MAAS snap SSH to the dc1 rack's libvirt to power-cycle nodes. RULING (GA-R5) -- question presented: "How should the region drive the dc1 rack's libvirt for node power control (power_type=virsh)?" options (A) reuse the SEC-012 key on dc1, (B) mint a dedicated dc1 power key. Operator answer, exact utterance (option selected): **"Mint a dedicated dc1 power key"** -- a SEPARATE per-DC MAAS->libvirt keypair, NOT cross-DC reuse of SEC-012's key. Mechanism: private half in the region MAAS snap (`/var/snap/maas/current/root/.ssh/` + per-host `ssh config` Host 172.31.0.6 -> that IdentityFile, so 172.31.0.2/dc0 keeps SEC-012 and 172.31.0.6/dc1 uses this one); public half authorizes jessea123 (libvirt group) on the dc1 rack. The maas-node-power SCRIPT's own mapping virsh (jessea123 on voffice1) uses the dc1 SERVICE key via voffice1 `ssh config` -- the dc0 split exactly (script=svc key, MAAS=dedicated key). | 2026-07-23 session changelog; docs/archive/changelogs/changelog-20260723-g12-dc1-edge.md; dc0 precedent SEC-012 | operator | **OPEN -- rotation obligation.** (1) ROTATE at v1 close or if the region/dc1 rack is rebuilt/shared. (2) Same libvirt-group SCOPE hardening candidate as SEC-012 (power-only polkit grant). (3) FRAGILITY: the snap-side key + ssh config live under per-revision `/var/snap/maas/current/` and may not survive a snap refresh -- re-assert after any refresh (queued to DC standup DoD). Roosevelt-relevance: establishes PER-DC power-credential isolation (bare metal: per-DC IPMI/BMC creds, never a shared cross-DC power credential) -- whether that becomes a standing D-principle is a follow-up, not blocking. |
 
-| SEC-017 | 2026-07-24 | **Third-party Claude Code plugin `caveman@caveman` (JuliusBrussee/caveman) installed at USER scope on vcloud -- a standing per-session/per-prompt third-party code-execution surface on a credential-bearing jumphost.** SessionStart + UserPromptSubmit hooks run `node` on every session start and every prompt while `enabledPlugins` is true, INDEPENDENT of the `CAVEMAN_DEFAULT_MODE` guard (the env var gates terse-output ARMING, NOT hook EXECUTION). Inspected benign at SHA `0d95a81` by a 4-seat council audit + operator self-remeasure 2026-07-24: no network egress, no shell, one gated subprocess (`/caveman-stats` only), symlink-hardened flag I/O, zero PATH contribution/shadowing. This verdict is POINT-IN-TIME: `plugin.json` carries no `version` field (every git commit is a new "version"), the marketplace source tracks the default branch with no tag/SHA ref -> the code is NOT declaratively pinnable; third-party-marketplace auto-update is OFF by default (Claude Code 2.1.218) but flippable via the `/plugin` UI or managed settings. Baseline: git clone HEAD `0d95a81d35a9f2d123a5e9430d1cfc43d55f1bb0` (tree clean), executing cache copy == clone (only a `.in_use` runtime marker differs); 6 audited files' full sha256 recorded in the 2026-07-24 changelog. | docs/changelog-20260723-caveman-optin-guard.md (commit 338c919); docs/changelog-20260724-caveman-disable.md; this session's council audit | operator | **OPEN -- supply-chain re-verify obligation (NOT a credential rotation).** DISABLED on the live host 2026-07-24: `enabledPlugins."caveman@caveman"=false` at BOTH user (`~/.claude/settings.json`) and committed repo (`.claude/settings.json`, higher precedence) scope, `CAVEMAN_DEFAULT_MODE=off` retained -- this STOPS the per-turn hook execution from the next session start. Marketplace entry RETAINED so a deliberate re-enable for hardened-workflow deployment TESTING stays possible. STANDING DUTY: on ANY re-enable OR plugin update, RE-VERIFY the hooks against the baseline (confirm the clone is at `0d95a81`; re-hash + `diff` the cache copy vs the marketplace clone) BEFORE trusting -- the benign verdict does not survive a version bump. Keep-available-vs-uninstall decision DEFERRED (NOT yet ruled). Provenance for the disable: operator accepted the council-review recommendations this session (exact utterance: "I'll accept your recommendations"). Register note: OPS adoption, no D-number (GA-R3 -- no Roosevelt-delta; precedent D-129); this row is the durable home the ledger mandate requires ("row at discovery, never only a note"). Count note: this row takes open SEC rows 12 -> 13; CURRENT-STATE G14 reconciles the count at Stage 4 close per its existing deferral pattern. |
+| SEC-017 | 2026-07-24 | **Third-party Claude Code plugin `caveman@caveman` (JuliusBrussee/caveman) installed at USER scope on vcloud -- a standing per-session/per-prompt third-party code-execution surface on a credential-bearing jumphost.** SessionStart + UserPromptSubmit hooks run `node` on every session start and every prompt while `enabledPlugins` is true, INDEPENDENT of the `CAVEMAN_DEFAULT_MODE` guard (the env var gates terse-output ARMING, NOT hook EXECUTION). Inspected benign at SHA `0d95a81` by a 4-seat council audit + operator self-remeasure 2026-07-24: no network egress, no shell, one gated subprocess (`/caveman-stats` only), symlink-hardened flag I/O, zero PATH contribution/shadowing. This verdict is POINT-IN-TIME: `plugin.json` carries no `version` field (every git commit is a new "version"), the marketplace source tracks the default branch with no tag/SHA ref -> the code is NOT declaratively pinnable; third-party-marketplace auto-update is OFF by default (Claude Code 2.1.218) but flippable via the `/plugin` UI or managed settings. Baseline: git clone HEAD `0d95a81d35a9f2d123a5e9430d1cfc43d55f1bb0` (tree clean), executing cache copy == clone (only a `.in_use` runtime marker differs); 6 audited files' full sha256 recorded in the 2026-07-24 changelog. | docs/archive/changelogs/changelog-20260723-caveman-optin-guard.md (commit 338c919); docs/archive/changelogs/changelog-20260724-caveman-disable.md; this session's council audit | operator | **OPEN -- supply-chain re-verify obligation (NOT a credential rotation).** DISABLED on the live host 2026-07-24: `enabledPlugins."caveman@caveman"=false` at BOTH user (`~/.claude/settings.json`) and committed repo (`.claude/settings.json`, higher precedence) scope, `CAVEMAN_DEFAULT_MODE=off` retained -- this STOPS the per-turn hook execution from the next session start. Marketplace entry RETAINED so a deliberate re-enable for hardened-workflow deployment TESTING stays possible. STANDING DUTY: on ANY re-enable OR plugin update, RE-VERIFY the hooks against the baseline (confirm the clone is at `0d95a81`; re-hash + `diff` the cache copy vs the marketplace clone) BEFORE trusting -- the benign verdict does not survive a version bump. Keep-available-vs-uninstall decision DEFERRED (NOT yet ruled). Provenance for the disable: operator accepted the council-review recommendations this session (exact utterance: "I'll accept your recommendations"). Register note: OPS adoption, no D-number (GA-R3 -- no Roosevelt-delta; precedent D-129); this row is the durable home the ledger mandate requires ("row at discovery, never only a note"). Count note: this row takes open SEC rows 12 -> 13; CURRENT-STATE G14 reconciles the count at Stage 4 close per its existing deferral pattern. |
 
-| SEC-018 | 2026-07-24 | **Dedicated dc0 MAAS admin API key (Juju -> MAAS cloud credential).** Created so the vr1-dc0 Juju controller can authenticate to the Office1 MAAS region (bootstrap + provision dc0 nodes). Per-DC credential isolation (SEC-012/-016 pattern; NEVER a cross-DC key): dedicated MAAS superuser `juju-vr1-dc0`, its API key staged at `~/vr1-dc0-creds/maas-api-key.txt` on vcloud (SEC-009, 0600), generated FROM the jumphost so it never persisted on the region, verified by FORMAT ONLY (parts=3, 70 chars), never printed/echoed/in argv. The user's password is random + UNSTORED (Juju auths via the key). GRANT: admin-scoped MAAS API (full machine/power/deploy). | 2026-07-24 driven creation (as-executed `2026-07-24-dc-maas-creds`); phase-4 Step 2.0; docs/changelog-20260724-caveman-disable.md item 7 | operator | **OPEN -- rotation obligation.** Rotate at v1 close, or immediately if it leaks or the region/jumphost is rebuilt/shared. Note it also lands in whatever Juju add-credential store + the maas-provider state of any root that consumes it (same 0600 handling). **2026-07-24: a runtime copy now lives in Juju's client credential store on voffice1 (`~/.local/share/juju/credentials.yaml`, cloud `vr1-maas`, credential `vr1-dc0-cred`) -- the canonical file stays on vcloud; this is the operator-noted consequence of running the Juju client on the headend (voffice1) per D-128.** Roosevelt: per-DC cloud credential. Custody off-repo per D-069. |
+| SEC-018 | 2026-07-24 | **Dedicated dc0 MAAS admin API key (Juju -> MAAS cloud credential).** Created so the vr1-dc0 Juju controller can authenticate to the Office1 MAAS region (bootstrap + provision dc0 nodes). Per-DC credential isolation (SEC-012/-016 pattern; NEVER a cross-DC key): dedicated MAAS superuser `juju-vr1-dc0`, its API key staged at `~/vr1-dc0-creds/maas-api-key.txt` on vcloud (SEC-009, 0600), generated FROM the jumphost so it never persisted on the region, verified by FORMAT ONLY (parts=3, 70 chars), never printed/echoed/in argv. The user's password is random + UNSTORED (Juju auths via the key). GRANT: admin-scoped MAAS API (full machine/power/deploy). | 2026-07-24 driven creation (as-executed `2026-07-24-dc-maas-creds`); phase-4 Step 2.0; docs/archive/changelogs/changelog-20260724-caveman-disable.md item 7 | operator | **OPEN -- rotation obligation.** Rotate at v1 close, or immediately if it leaks or the region/jumphost is rebuilt/shared. Note it also lands in whatever Juju add-credential store + the maas-provider state of any root that consumes it (same 0600 handling). **2026-07-24: a runtime copy now lives in Juju's client credential store on voffice1 (`~/.local/share/juju/credentials.yaml`, cloud `vr1-maas`, credential `vr1-dc0-cred`) -- the canonical file stays on vcloud; this is the operator-noted consequence of running the Juju client on the headend (voffice1) per D-128.** Roosevelt: per-DC cloud credential. Custody off-repo per D-069. |
 
-| SEC-019 | 2026-07-24 | **Dedicated dc1 MAAS admin API key (Juju -> MAAS cloud credential).** Same as SEC-018 for the vr1-dc1 Juju controller: dedicated MAAS superuser `juju-vr1-dc1`, key staged at `~/vr1-dc1-creds/maas-api-key.txt` on vcloud (0600), generated from the jumphost, format-verified (parts=3, 70 chars), never printed; random unstored password. GRANT: admin-scoped MAAS API. | 2026-07-24 driven creation (as-executed `2026-07-24-dc-maas-creds`); phase-4 Step 2.0; docs/changelog-20260724-caveman-disable.md item 7 | operator | **OPEN -- rotation obligation** (same disposition as SEC-018). **2026-07-24: runtime copy now in Juju's client credential store on voffice1 (`vr1-maas` / `vr1-dc1-cred`); canonical file stays on vcloud.** Roosevelt: per-DC cloud credential. Custody off-repo per D-069. |
+| SEC-019 | 2026-07-24 | **Dedicated dc1 MAAS admin API key (Juju -> MAAS cloud credential).** Same as SEC-018 for the vr1-dc1 Juju controller: dedicated MAAS superuser `juju-vr1-dc1`, key staged at `~/vr1-dc1-creds/maas-api-key.txt` on vcloud (0600), generated from the jumphost, format-verified (parts=3, 70 chars), never printed; random unstored password. GRANT: admin-scoped MAAS API. | 2026-07-24 driven creation (as-executed `2026-07-24-dc-maas-creds`); phase-4 Step 2.0; docs/archive/changelogs/changelog-20260724-caveman-disable.md item 7 | operator | **OPEN -- rotation obligation** (same disposition as SEC-018). **2026-07-24: runtime copy now in Juju's client credential store on voffice1 (`vr1-maas` / `vr1-dc1-cred`); canonical file stays on vcloud.** Roosevelt: per-DC cloud credential. Custody off-repo per D-069. |
 
-| SEC-020 | 2026-07-25 | **MAAS region superuser passwords: an un-consolidated VM-minted secret, plus a new human GUI identity -- and the human/service identity conflation underneath both.** (a) The `admin` superuser's password was minted ON the region VM by `scripts/site-headend-install.sh:452` (`newpass` -> 28 chars alphanumeric, no trailing newline) and sat root-only at `voffice1:/root/maas-secrets/admin.pass` since 2026-07-13, never consolidated to `~/vr1-office1-creds/` -- the SAME SEC-009 miss class the NetBox token established (a site-VM-minted secret with no forcing function to reach the folder). It was NOT lost and NOT unset: MEASURED working this session (login POST 204 with the stored value vs 400 with a wrong-password control; Django `has_usable_password=True`). The prior claim that MAAS web-GUI login "does NOT exist / was never minted" (session-ledger 2026-07-25 close) is FALSIFIED and corrected in the same commit. (b) ROOT CAUSE of the miss: `admin` is simultaneously the human GUI login AND the automation identity -- the installer mints its API key (`:453`) and logs the CLI in as profile `admin` (`:455`), and 19 `maas admin ...` call sites across 4 scripts (`site-headend-install.sh` 10, `phase-04-network-verify.sh` 5, `phase-04-network-create.sh` 3, `phase-00-teardown-release.sh` 1) hardcode that profile. Automation only ever needed the KEY, so nobody ever needed the PASSWORD, so nothing forced it into the folder. (c) NEW standing credential: superuser `operator` (email `jesse.austin@neumatrix.com`) minted 2026-07-25 for HUMAN GUI login, 32-char base64 generated on vcloud, set via **stdin -- never argv** (SEC-018 discipline; note `maas changepassword` has no `--password` and `createadmin --password` would expose it in argv, the shape `site-headend-install.sh:452` uses). Both passwords now at `~/vr1-office1-creds/{maas-admin-password,maas-operator-password}` 0600, declared in `creds-manifests/vr1-office1.manifest`, `creds-audit vr1-office1` CLEAN. | this session (operator-ruled scope: "New account + consolidate only" -- no existing password rotated); measured captures in `docs/changelog-20260725-maas-admin-recovery.md`; `scripts/site-headend-install.sh:452-455` | operator | **OPEN -- rotation obligation on TWO credentials** (`admin` + `operator` region superusers; rotate at v1 close, or immediately if vcloud/the region is rebuilt or shared). `admin`'s password was deliberately NOT rotated this session (operator-ruled) -- so `voffice1:/root/maas-secrets/admin.pass` REMAINS source-of-record and the vcloud file is a byte-identical (sha256-verified) working copy; **any future `admin` rotation MUST update both copies in one operation or the VM copy becomes a stale trap.** ALSO OPEN, un-actioned by ruling (hard rule 1, findings are logged not executed): (i) `voffice1:/root/maas-secrets/{admin.apikey,db.pass,lxd-trust.pass}` are still un-consolidated -- `admin.apikey` is deliberately NOT copied (trivially regenerable via `maas apikey --username=admin`, and a second copy is pure added surface), `db.pass`/`lxd-trust.pass` are region infrastructure and out of this task's scope; (ii) the DURABLE fix for the miss class is a `site-headend-install.sh` amendment to consolidate at mint time (queued, unruled); (iii) the human/service conflation in (b) is proposable as the next-free D-number, tagged [ARCH], a Roosevelt-delta (per-identity MAAS separation / audit attribution on a multi-tenant cloud) -- NOT assigned, GA-R3 doubt-resolves-DOWN, operator's call. Count note: this row takes open SEC rows 15 -> 16; CURRENT-STATE G14 (which still reads 12) reconciles at Stage 4 close per its existing deferral. Custody off-repo per D-069. |
+| SEC-020 | 2026-07-25 | **MAAS region superuser passwords: an un-consolidated VM-minted secret, plus a new human GUI identity -- and the human/service identity conflation underneath both.** (a) The `admin` superuser's password was minted ON the region VM by `scripts/site-headend-install.sh:452` (`newpass` -> 28 chars alphanumeric, no trailing newline) and sat root-only at `voffice1:/root/maas-secrets/admin.pass` since 2026-07-13, never consolidated to `~/vr1-office1-creds/` -- the SAME SEC-009 miss class the NetBox token established (a site-VM-minted secret with no forcing function to reach the folder). It was NOT lost and NOT unset: MEASURED working this session (login POST 204 with the stored value vs 400 with a wrong-password control; Django `has_usable_password=True`). The prior claim that MAAS web-GUI login "does NOT exist / was never minted" (session-ledger 2026-07-25 close) is FALSIFIED and corrected in the same commit. (b) ROOT CAUSE of the miss: `admin` is simultaneously the human GUI login AND the automation identity -- the installer mints its API key (`:453`) and logs the CLI in as profile `admin` (`:455`), and 19 `maas admin ...` call sites across 4 scripts (`site-headend-install.sh` 10, `phase-04-network-verify.sh` 5, `phase-04-network-create.sh` 3, `phase-00-teardown-release.sh` 1) hardcode that profile. Automation only ever needed the KEY, so nobody ever needed the PASSWORD, so nothing forced it into the folder. (c) NEW standing credential: superuser `operator` (email `jesse.austin@neumatrix.com`) minted 2026-07-25 for HUMAN GUI login, 32-char base64 generated on vcloud, set via **stdin -- never argv** (SEC-018 discipline; note `maas changepassword` has no `--password` and `createadmin --password` would expose it in argv, the shape `site-headend-install.sh:452` uses). Both passwords now at `~/vr1-office1-creds/{maas-admin-password,maas-operator-password}` 0600, declared in `creds-manifests/vr1-office1.manifest`, `creds-audit vr1-office1` CLEAN. | this session (operator-ruled scope: "New account + consolidate only" -- no existing password rotated); measured captures in `docs/archive/changelogs/changelog-20260725-maas-admin-recovery.md`; `scripts/site-headend-install.sh:452-455` | operator | **OPEN -- rotation obligation on TWO credentials** (`admin` + `operator` region superusers; rotate at v1 close, or immediately if vcloud/the region is rebuilt or shared). `admin`'s password was deliberately NOT rotated this session (operator-ruled) -- so `voffice1:/root/maas-secrets/admin.pass` REMAINS source-of-record and the vcloud file is a byte-identical (sha256-verified) working copy; **any future `admin` rotation MUST update both copies in one operation or the VM copy becomes a stale trap.** ALSO OPEN, un-actioned by ruling (hard rule 1, findings are logged not executed): (i) `voffice1:/root/maas-secrets/{admin.apikey,db.pass,lxd-trust.pass}` are still un-consolidated -- `admin.apikey` is deliberately NOT copied (trivially regenerable via `maas apikey --username=admin`, and a second copy is pure added surface), `db.pass`/`lxd-trust.pass` are region infrastructure and out of this task's scope; (ii) the DURABLE fix for the miss class is a `site-headend-install.sh` amendment to consolidate at mint time (queued, unruled); (iii) the human/service conflation in (b) is proposable as the next-free D-number, tagged [ARCH], a Roosevelt-delta (per-identity MAAS separation / audit attribution on a multi-tenant cloud) -- NOT assigned, GA-R3 doubt-resolves-DOWN, operator's call. Count note: this row takes open SEC rows 15 -> 16; CURRENT-STATE G14 (which still reads 12) reconciles at Stage 4 close per its existing deferral. Custody off-repo per D-069. |
 
 | SEC-021 | 2026-07-25 | **dc0 credential custody defects -- a consolidated credential is ABSENT from its recorded location, and the per-DC power key diverges in name, host and custody.** (a) `docs/archive/changelogs/changelog-20260719-dc0-deploy-stepB.md:263` records the dc0 edge REST API credential written to `~/vr1-dc0-creds/opnsense-api.txt` (0600, secret never printed). A `find` over vcloud `$HOME` returns `opnsense-api.txt` for `vr1-office1` (2026-07-13) and `vr1-dc1` (2026-07-23) ONLY -- **there is no dc0 copy**. It was never added to dc0's manifest, so `creds-audit vr1-dc0` reports CLEAN. A changelog asserting consolidation is not evidence the consolidation survived. SEVERITY: this is a custody/record defect plus an API-access gap, NOT a management lockout -- `vr1-dc0-edge_ed25519{,.pub}` IS present, and D-112(c) makes key-only SSH the primary edge management path. (b) The dc0 MAAS->libvirt power key (SEC-012) is `maas-virsh_ed25519` on **voffice1**, while dc1's equivalent (SEC-016) is `vr1-dc1-maas-power_ed25519{,.pub}` on **vcloud** and manifest-declared: same purpose, different filename, different host, and dc0 carries no `.pub`. Per-DC rows that should be symmetric are not, and nothing compares them. | measured read-only this session (folder listings both hosts, `find` over vcloud `$HOME`, both manifests); D-137 research; plan `whimsical-wandering-spindle` findings F1+F3 | operator | **OPEN.** (a) needs a decision between RE-MINT (D-113(a2) vendor model, the dc1-proven path) and locating an off-jumphost copy; until then dc0 has no API management path from vcloud. (b) needs a naming/custody reconciliation to the dc1 shape, and dc0's key should gain a jumphost copy + manifest row -- note SEC-016's standing fragility applies harder to dc0: the snap-side key lives under per-revision `/var/snap/maas/current/` and may not survive a snap refresh, and dc0 currently has NO jumphost copy to re-assert from. NOT actioned this session (hard rule 1; findings are logged, never executed mid-task). Custody off-repo per D-069. |
 
diff --git a/docs/session-ledger.md b/docs/session-ledger.md
index 5c349d0..f1e23f4 100644
--- a/docs/session-ledger.md
+++ b/docs/session-ledger.md
@@ -157,7 +157,7 @@
   set-interface-v4 reload amendment (queued OPTION, unruled); local permission-rules
   prune (`Bash(ssh *)` flag); then the stage close-out set (consolidation, skill sweep,
   GA-R7 memory review, final gauntlet, operator-gated merge).
-- Details: docs/changelog-20260723-stage4-open.md. Status ONLY in CURRENT-STATE.md.
+- Details: docs/archive/changelogs/changelog-20260723-stage4-open.md. Status ONLY in CURRENT-STATE.md.
 
 ## SESSION CLOSE 2026-07-23 -- queue pass + D-068 rulings (bounded, GA-R4)
 
@@ -198,7 +198,7 @@
 - OWNED: I fabricated a "D-193" reference in analysis (cardinal sin) -- corrected to D-121;
   verified NOT persisted to repo. NEXT SESSION: render vr1-dc1 role-separated HA bundle +
   wire overlays + de-stale phase-4, THEN bootstrap. Full detail: CURRENT-STATE Stage-4 bullet.
-- Status ONLY in CURRENT-STATE.md. Changelog: docs/changelog-20260724-caveman-disable.md.
+- Status ONLY in CURRENT-STATE.md. Changelog: docs/archive/changelogs/changelog-20260724-caveman-disable.md.
 
 ## SESSION CLOSE 2026-07-25 -- handoff-pack execution + recon + Chat D-136 coupling (bounded, GA-R4)
 - ~~**IMMEDIATE NEXT (do FIRST):** MAAS WEB-GUI login does NOT exist -- SEC-018/019 are API/Juju-only
@@ -239,7 +239,7 @@
 - LOGGED not executed: headend-install consolidate-at-mint; conflation proposable as next-free D
   [ARCH]; 3 /root secrets unmoved. **GA-R4 F1: ledger 370 lines at OPEN vs 300 cap -- rotation OWED.** (DISCHARGED 2026-07-26: rotated oldest-first to 280 lines; see the ROTATED block above.)
 - Gauntlet 79 GREEN, repo-lint 0-fail, b2b0c80 pushed. Bookend EARLY (07-21 precedent); further
-  work appends a POST-CLOSE ADDENDUM. Details: docs/changelog-20260725-maas-admin-recovery.md.
+  work appends a POST-CLOSE ADDENDUM. Details: docs/archive/changelogs/changelog-20260725-maas-admin-recovery.md.
 
 ## POST-CLOSE ADDENDUM 2026-07-26 -- D-137 ADOPTED (GA-R4; 07-18/07-21 addendum precedent)
 - The 2026-07-25 close bookend landed early by design; this addendum records the work that
@@ -264,7 +264,7 @@
 - NEXT as recorded at the time: build per `docs/D-137-implementation-plan.md`. THAT HAPPENED
   in the same-day successor session (tiers 1-3 built, six-lens committee audit, remediation,
   preflight P5 wired, SEC-009 demoted). Current status: CURRENT-STATE only.
-- Status ONLY in CURRENT-STATE.md. Detail: docs/changelog-20260725-maas-admin-recovery.md.
+- Status ONLY in CURRENT-STATE.md. Detail: docs/archive/changelogs/changelog-20260725-maas-admin-recovery.md.
 
 ## SESSION CLOSE 2026-07-26 -- D-137 build + committee audit + remediation (bounded, GA-R4)
 
@@ -283,3 +283,27 @@
 - NEXT: live mission has NOT moved -- resume the DC1 Stage-5 chain per CURRENT-STATE.
   Unbuilt/unruled advice: `creds-mint.sh` BEFORE Stage 5 (largest minting event).
 - Full body: `docs/archive/session-20260726-d137-build.md`. Status ONLY in CURRENT-STATE.md.
+
+## SESSION CLOSE 2026-07-27 -- creds consolidation + STAGE 4 CLOSE-OUT (bounded, GA-R4)
+
+- Opened on a creds question; ended closing Stage 4. 8 commits `c13cfe4..` pushed. Merge to
+  `main` is the ONLY remaining step and is operator-gated.
+- Creds: dc0 SEC-012 power key consolidated + `.pub` derived (SEC-021(b) as written -- measured
+  first: it IS the dedicated key, and dc0 using the snap default is SEC-016's ruled design, so
+  NO re-mint); NetBox GUI admin password consolidated (**SEC-025**, rows 20->21); dc1 svc `.pub`
+  backfilled. Findings 13 -> 7. MAAS account set verified COMPLETE by enumeration.
+- V2 taught the ruled-deferral state -- reissuing SEC-006's token would have CONTRAVENED a
+  standing 2026-07-13 ruling; the register was what needed changing. `--ledger` added; V2 had
+  shipped with ZERO harness cases.
+- **Two false greens fixed, both in controls that had passed for days:** `dc-mirror.sh check`
+  asserted last-sync EXISTED (dc0 `FAIL`, dc1 4-day-stale `RUNNING` both read OK); and
+  `creds-audit` CLEAN x3 alongside 13 matrix findings. Lesson repo-carried in the skill.
+- Rulings (GA-R5, all quoted): **G17** opened (node-side reachability split out -- powered-off
+  nodes cannot be probed); SEC-024 retention "Keep both"; set-interface-v4 reload "a"; D-135
+  AMENDED (dc0 tests full mirror / dc1 tests proxy -- dc1's 330G mirror REMOVED, not paused).
+- DOCFIX-204: DoD bullet 6 was UNSATISFIABLE (D-129(iv) had ruled the opposite); 4 surfaces.
+  Carve residue: 108 fabrics -> 17, cascade-checked. dc1 nginx purged.
+- OWNED: first draft of the pf reload sat inside the reconfigure heredoc -- would have fixed
+  nothing in the very drop case that caused the bug. Caught pre-ship.
+- Gauntlet ALL GREEN (81), repo-lint 0-fail. Full body: `docs/archive/changelogs/changelog-20260727-creds-consolidation.md`;
+  stage record `docs/archive/stage-records/vr1-stage4-record.md`. Status ONLY in CURRENT-STATE.md.