diff --git a/_handoff-not-committed/00-DESTINATION-MAP.md b/_handoff-not-committed/00-DESTINATION-MAP.md
new file mode 100644
index 0000000..4d4139d
--- /dev/null
+++ b/_handoff-not-committed/00-DESTINATION-MAP.md
@@ -0,0 +1,108 @@
+# DESTINATION MAP -- read before unpacking
+
+Session 2026-07-25, Chat design seat -> Code.
+Authored against bc9a2df, revised against 4ed29aa.
+
+The previous version of this pack was a flat folder with no destinations. This version
+mirrors repo paths for the files that ARE repo artifacts, and quarantines the rest.
+
+================================================================================
+## Unpack behaviour
+================================================================================
+
+  docs/audit/...                 -> unzip over the repo root. Three NEW committed files.
+  _handoff-not-committed/...     -> DO NOT COMMIT. Working instructions whose CONTENT
+                                    lands inside existing surfaces. Delete after use.
+
+If `_handoff-not-committed/` ends up in a commit, that is the bug this revision exists
+to prevent. Nothing in it is a repo artifact.
+
+================================================================================
+## The three NEW committed files
+================================================================================
+
+  docs/audit/operating-model-plan-20260725.md
+      The NetBox -> approve -> apply operating model: recommendations, the agenda, and
+      the research scope the operator asked for. PINNED for a planning session.
+      Implement nothing from it.
+
+  docs/audit/sprygit-requirements-inputs-20260725.md
+      Pinned inputs for the SpryGit dev-handover document. The document itself is the
+      next Chat deliverable and is NOT in this pack.
+
+  docs/audit/skill-divergence-20260725.md
+      The stale-Chat-skill divergence list, for the skill sweep at stage close.
+
+WHY `docs/audit/` and not `docs/`: `docs/` top level is at 21 `.md` files against
+GA-R4's cap of <25 -- three slots of headroom, which dated advisory records should not
+consume. `docs/audit/` is uncapped and is the established home for dated advisory and
+plan documents; precedents already there include `phase5-sweep-plan.md`,
+`skill-additions-proposed.md`, `grounding-audit-charter.md` and
+`decision-recon-20260725.md`. `scripts/repo-lint.sh` carries no file-count or naming rule
+that these would trip (checked).
+
+================================================================================
+## Everything else: content, not files
+================================================================================
+
+| Working file | Content lands in | Form |
+|---|---|---|
+| `10-design-decisions-append.md` | `docs/design-decisions.md` | append at register tail; replace every `D-NNN` with the `ledger-scan` number |
+| `20-ruling-records.md` | distributes -- see below | three separate records |
+| `30-current-state-update.md` | `docs/CURRENT-STATE.md` section 1, Stage-4 bullet | edits in place, SAME COMMIT as item 10 (GA-R1/C1) |
+| `40-session-changelog-items.md` | THIS session's changelog under `docs/changelog-<date>-<label>.md` | append items; do NOT mint a per-topic changelog file (GA-R2/D1) |
+| `50-ledger-bounded-summary.md` | `docs/session-ledger.md` tail | append the 15-line block; never touch the machine-derived fence |
+| `60-vault-vip-values.md` | splits -- see below | values + gates |
+
+### How `20-ruling-records.md` distributes
+
+There is no ruling-record file convention in this repo -- rulings attach to the surface
+they govern (precedent: D-134's amendment records its own question and utterance inline;
+D-131 sub-1 likewise). So:
+
+  Ruling 1, address family      -> an amendment note under `## D-101` in
+                                   `docs/design-decisions.md` (it CONFIRMS D-101 and
+                                   changes nothing in it, so a dated note, not a rewrite)
+                                   + the CURRENT-STATE bullet (b) rewrite in item 30
+  Ruling 2, keystone VERIFY-LIVE -> a gate row in `docs/CURRENT-STATE.md` (item 30)
+                                   + a changelog line
+  Ruling 3, per-DC artifact shape -> already recorded inline in the new D-NNN entry's
+                                   "Artifact shape (RULED 2026-07-25)" paragraph; the
+                                   question and utterance travel with it
+
+Each carries its question and the operator's exact utterance (GA-R5).
+
+### How `60-vault-vip-values.md` splits
+
+  The four confirm-before-write gates -> the phase-4 runbook step that performs the
+      repair (`runbooks/dc-dc-phase4-juju-bundle-per-dc.md`), so the gates sit where the
+      hand is
+  The derivation and the values       -> the changelog item for the repair, which is the
+      review surface
+  The `VIP_COUNT_EXPECT` 11 -> 12 change -> `scripts/lib-net.sh:59`, in the same commit
+      as the vault VIP, or `scripts/pre-flight-checks.sh:99-102` fails
+
+If you want the derivation citable rather than buried in a changelog, the consistent home
+would be `docs/audit/vault-vip-derivation-20260725.md`. Operator's call -- I have not
+created it, because the changelog is the ruled review surface and a fourth audit file
+may not earn its place.
+
+================================================================================
+## Order of operations (unchanged from the previous pack)
+================================================================================
+
+  0. Read `docs/audit/decision-recon-20260725.md`. This pack was revised against it:
+     the scope boundary was CORRECTED (apex writes are IN, not out), the gap statement
+     rewritten to the sub-prefix layer, and a sequencing prerequisite added.
+  1. `bash scripts/ledger-scan.sh` -- assign the D number and all THREE DOCFIX numbers.
+  2. Record the rulings BEFORE dependent work (GA-R5), commit and push.
+  3. Register append + CURRENT-STATE, same commit.
+  4. Changelog items into the existing session changelog.
+  5. Ledger block at session close only, 15-line cap.
+  6. Then the gated execution path.
+
+Placeholders are non-numeric on purpose (`D-NNN`, `DOCFIX-NNN`): `ledger-scan` keys the
+high-water on `^## D-[0-9]+`, and a digit-shaped placeholder inflates the counter -- the
+DOCFIX-174 hazard.
+
+All files ASCII-only, LF-only, byte-verified by Python read before packaging.
diff --git a/_handoff-not-committed/10-design-decisions-append.md b/_handoff-not-committed/10-design-decisions-append.md
new file mode 100644
index 0000000..fbc7219
--- /dev/null
+++ b/_handoff-not-committed/10-design-decisions-append.md
@@ -0,0 +1,246 @@
+# 10 -- Append to docs/design-decisions.md (register tail)
+
+Replace every `D-NNN` with the number `ledger-scan` assigns. Land in the SAME commit
+as item 30 (GA-R1/C1). Status stays PROPOSED -- the operator rules per GA-R5.
+
+--- BEGIN append block ---
+
+## D-NNN: NetBox-coupled per-DC render pipeline for bundle overlays and tfvars [ARCH]
+
+**Status:** PROPOSED 2026-07-25 (Chat design seat, repo HEAD bc9a2df; operator has not
+ruled on the mechanism). Escalates the renderer deferral in
+`docs/audit/committee-20260724-track2-bundle-render.md` (Fork 2, "hand-render dc1 now,
+extract the tool when dc0 forces the second render") to a NetBox-coupled generator.
+Supersedes nothing.
+
+**Problem.** Addressing is authoritative in NetBox (office1-netbox, the VR1 working
+apex, DOCFIX-195) but reaches the deploy as HAND-RENDERED static literals: NetBox ->
+imported by `netbox/*.py` -> literals in `scripts/lib-net.sh` / `lib-hosts.sh` and
+tfvars -> hand-rendered into `bundle.yaml` and `overlays/*.yaml`. There is no live pull
+and no generator. Measured fragility:
+
+- BUNDLEFIX-052 (ceph-rbd-mirror binding) and a YAML flow-comma slip, one session.
+- The app-to-VIP set exists in FOUR live places and no two agree: D-020's ratified list
+  (11 apps, includes vault, excludes ceph-radosgw); `bundle.yaml` and
+  `overlays/vr1-dc1-vips.yaml` (11, vault dropped, ceph-radosgw added);
+  `overlays/dc-dc-ipv6-family-matrix.yaml` (10, plus octavia deliberately commented at
+  lines 140-152).
+- Two overlays own `vip:` for the same 10 applications under per-key REPLACE and
+  last-wins, so the deploy input depends on overlay ORDER, not on a reconciled value.
+- vault carries no `vip:` anywhere in the tracked tree while `overlays/dc-ha-scaleup.yaml`
+  scales it to 3 units and declares `vault-hacluster` at `cluster_count: 3`. HA intent
+  the artifact does not express, and an unrecorded departure from D-020.
+
+Under the 2026-07-25 family ruling (see the ruling record for this date) the per-app
+VIP becomes a six-address dual-family string, for BOTH DCs. That roughly doubles the
+hand-maintained literal count at the precise point where the hand-render has already
+failed twice.
+
+**What the pipeline PULLS** (verified present in
+`netbox/draft/vr1-office1-current-20260725.json`, captured 2026-07-25):
+
+- Six-plane v4 `/22`s and v6 `/60`+`/64` per DC, selectable by `scope_site`
+  (`vr1-dc0`, `vr1-dc1`); 92 of 139 prefixes carry `scope_site`, and the `role` slugs
+  match the plane names exactly.
+- The D-111 API-VIP `/64` per DC (`2602:f3e2:f02:11::/64` dc0, `2602:f3e2:f03:11::/64`
+  dc1) and the shared metal `/60` at `:20`, admin `/64` `:20`, internal `/64` `:21`.
+- Aggregates (`2602:f3e2::/36` ARIN, `fd50:840e:74e2::/48` org ULA, RFC1918,
+  `23.157.124.0/24`), the D-120 bands as ip-ranges, two rack-controller static IPs.
+
+**What it CANNOT pull today** (scoping constraint, not a defect): VIPs -- the record
+holds four ip-addresses and none is a VIP. MAC pins and node inventory -- there is no
+`dcim/devices` and no `dcim/interfaces` in the record at all. VLANs/VIDs -- no
+`ipam/vlans`; the VLAN-group buildout is the open G4 item at
+`docs/dc-dc-netbox-buildout-scope.md` section 4e.
+
+**Where the gap actually is (per `docs/audit/decision-recon-20260725.md`, 4-lens,
+2026-07-25).** The PREFIX layer is COMPLETE and DRIFT-FREE -- all 12 plane `/22`s, both
+transit `/30`s, both uplinks, both GUA `/48`s, the ARIN `/36`, the full v6 subcarves and
+the org ULA are present and match `lib-net.sh` value-for-value. The gap is entirely
+SUB-PREFIX, and it is what this decision exists to close:
+
+- **The D-134 bands** (as amended 2026-07-23, the CONTIGUOUS table: `.1-.3` infra,
+  `.4-.49` reserved utility, `.50-.99` VIP, `.100-.200` nodes with control `.100-.119` /
+  compute `.120-.149` / storage `.150-.200`, `.201-.254` dynamic) exist ONLY as decision
+  prose -- in neither NetBox nor `lib-net.sh`. `lib-net.sh` carries only the dc0 VIP
+  octet band `.50-.60`, UNSET for dc1.
+- **The 33 VIP addresses** (11 services x provider/admin/internal, `.50-.60`) exist ONLY
+  as hand-maintained literals in `overlays/vr1-dc1-vips.yaml`. They are internally
+  consistent with the bundle octet-for-octet, but they are not a projection of the apex.
+
+So a generator has nothing to pull for either. **Division of labour, corrected:** the
+coupling MODELS the bands (as ip-ranges) and the VIP addresses (as scoped ip-addresses)
+IN the apex, then GENERATES the overlays from them, so the overlay becomes a projection
+of NetBox rather than a parallel hand-maintained truth. The per-DC values file is
+therefore TRANSITIONAL -- it carries bands and VIPs by hand only until they land in the
+apex, after which it shrinks to genuinely non-IPAM convention.
+
+**Options.**
+
+- **(A) Build the generator now and gate the dc1 deploy on it.** The forced dual-stack
+  reconciliation IS its first job, so hand-rendering then rebuilding pays twice.
+  Against: an unproven tool on the critical path of an otherwise-ready deploy; its
+  first output has nothing to diff against; MAC pins and VLANs are absent from the
+  record, so the tool cannot be complete on this timeline.
+
+- **(B) Hand-render both DCs dual-stack; build the generator for Roosevelt.** Fork 2's
+  lean, and "render once to learn the parameter surface" has real force. Against:
+  roughly 170 dual-family literals by hand, at the point the hand-render has already
+  produced two defects on the simpler v4-only artifact.
+
+- **(C) Split at the seam: build the BACK half now, add the FRONT half later.
+  RECOMMENDED.** Reconcile once, by hand, INTO a per-DC values file carrying every
+  plane CIDR, VIP band, app-to-VIP map (one reconciled dual-family string per app,
+  vault included) and role tag. Render the overlays from it with a thin deterministic
+  substitution step. Both DCs ship on it. The NetBox front half (record -> values file)
+  is added later without touching the back half, because the interface is frozen.
+
+**Why (C).** It captures the whole benefit -- one source of truth, no two lists to
+drift -- without absorbing the front half's unknowns (VIP representability, MAC and
+VLAN buildout, token handling, network reach), none of which are on this deploy's
+critical path. It makes the front half testable BY REPRODUCTION: once the schema is
+frozen, NetBox-generated values are validated by diffing against known-good
+hand-authored values for a DC that already deployed. Option (A) has no such gate. And
+the values file is not scaffolding -- it is the permanent seam between IPAM fact and
+deployment convention in the target operating model (pinned separately).
+
+**Honest cost of (C):** the schema and substitution layer are written before the NetBox
+schema is fully known, so the seam may need one refactor when the front half lands.
+
+**Eliminated by construction.**
+
+1. The VIP-overlay collision -- one reconciled `vip` per app per DC, emitted once; no
+   second overlay to race, so deploy input stops depending on overlay order.
+2. Vault decorative HA -- an application scaled with an `hacluster` peer and no VIP
+   becomes a GENERATOR-TIME error instead of a silent runtime condition.
+3. Family drift -- D-101's matrix applied once in code instead of by a human ~170
+   times. The validator asserts family-per-plane-per-SITE, not mere presence: the
+   record currently carries GUA storage prefixes for `vr0-dc0` and `willamette` while
+   VR1 storage is ULA, so a generator selecting on `role` alone pulls the wrong family.
+4. Reserved-range skew -- per D-074 the tenant-CIDR reserved set is the six plane
+   `/22`s (today sourced from `scripts/lib-net.sh` into `scripts/net_overlap.py` as
+   argv) plus the live-resolved `capi-mgmt-subnet` and the metadata range. Generating
+   the plane rows from the same values file removes the risk of onboarding a tenant
+   validated against the WRONG DC's planes.
+
+**DC-aware gates (part of this proposal).** `scripts/preflight.sh` validates the real
+per-DC deploy input via `scripts/provider-bundle-check.py --overlay --dc`, not the base
+bundle alone. `scripts/cloud-assert.sh` gains a per-hacluster VIP-owned check, so a
+scaled application with no VIP fails rather than passes. Bootstrap carries the
+controller-tag constraint.
+
+**Mechanism (front half, when built).** Extending `netbox/*.py` is preferred over a
+third-party NetBox OpenTofu provider. The existing tools already establish the correct
+posture: one script per SOURCE (`office1-record-dump.py` vs `prod-draft-dump.py`),
+read-only, token from the environment, never embedded or printed. A provider must
+additionally be mirrorable into the per-DC airgap mirror (D-107) or it is disqualified
+on Roosevelt, and it would put a write-capable credential in the tofu run while
+write-back is deferred (DOCFIX-195). Reads only; no write-back under this decision.
+
+**Scope boundary.**
+
+- IN: the six operator planes per DC, VIP bands, plane CIDRs, per-DC role tags, and the
+  generated per-DC overlays and tfvars.
+- OUT -- TENANT SPACE, permanently. Per `docs/dc-dc-netbox-buildout-scope.md:128`
+  per-tenant `/60`s are Neutron-managed (D-016/D-074) and not enumerated in NetBox. Per
+  D-074 tenant private CIDRs are TENANT-CHOSEN and MAY OVERLAP, enforced only against
+  the reserved-range registry. NetBox models pools, aggregates and reserved ranges; it
+  never models a tenant's own networks. A maintainer extending the generator "one more
+  table" into tenant space would either fight Neutron or gate tenant provisioning on an
+  operator-side IPAM write, breaking the tenant self-service model this cloud is sold
+  on.
+- IN: WRITES TO office1-netbox. DOCFIX-195 (operator ruling 2026-07-15) rules that
+  during VR1 `office1-netbox` takes ALL writes and `netbox.baldurkeep.com` stays a
+  READ-ONLY v1 reference with merge-back DEFERRED to end-of-deployment. Precedent tool:
+  `netbox/d120-compose-bands.py --commit` already loaded the D-120 bands into the apex.
+  (An earlier draft of this entry scoped apex writes OUT on a misreading of DOCFIX-195;
+  that would have scoped the coupling out of its own core job -- see the gap below.)
+- OUT: writes to `netbox.baldurkeep.com` (deferred, DOCFIX-195; P2 merge-back).
+- OUT: VLAN / space / fabric -- PERMANENTLY, not pending. office1-netbox holds zero VLAN
+  objects and that is CORRECT BY DESIGN: VR1 is untagged-per-fabric on every plane in
+  both DCs (D-133, superseding VR0's VID-103/104), so a VLAN object would document
+  tagging that does not exist on the wire. The bundle binds by SPACE NAME -> MAAS subnet
+  by CIDR, never by VLAN/fabric/subnet id. VLAN/space/fabric is MAAS-sourced; NetBox is
+  IPAM only.
+- OUT: MAC pins. They already have a working source of record and are drift-free across
+  substrate `main.tf` <-> `lib-hosts.sh` `HOST_BOOT_MAC` <-> bundle ovn-chassis <->
+  discovery. They stay substrate/lib-hosts-sourced; this is not a NetBox gap.
+
+**Roosevelt-delta (A1).** Roosevelt is N bare-metal DCs. Hand-rendering is O(N) human
+renders of a ~170-literal dual-family artifact; a generator plus one values file per DC
+plus one validator is O(1) tooling and O(N) data. The transferable artifact is the
+triple: renderer, values file, validator. This is why the back half is worth building
+even while the front half waits.
+
+**Artifact shape (RULED 2026-07-25 -- see the ruling record).** Symmetric per-DC
+overlays. `bundle.yaml` becomes VIP-free and holds topology only; every per-DC value,
+dc0's included, arrives via overlay. dc0's VIPs are extracted from base into
+`overlays/vr1-dc0-vips.yaml`. The renderer therefore has ONE output shape per DC and
+Roosevelt's Nth DC is the same shape as its first.
+
+**PREREQUISITE, sequenced FIRST (per the recon's sequencing insight).** Extend
+`netbox/sandbox-fidelity-check.py` BEFORE the coupling is built. Today it covers only the
+D-115/D-117/D-120 delta and diffs the FROZEN 90-prefix `netbox.baldurkeep.com` draft, not
+the current 139-prefix office1-netbox apex; it is blind to D-124 and D-134. It gates every
+apex reconciliation this coupling depends on, and the coupling's whole value proposition
+is eliminating the drift those reconciliations chase. An unextended checker cannot verify
+the apex mutations in the gap list above, so building the generator first would mean
+writing to the apex with no trustworthy fidelity gate.
+
+**A hard tooling coupling nobody has flagged.** `scripts/lib-net.sh:59` sets
+`VIP_COUNT_EXPECT=11`, consumed by `scripts/pre-flight-checks.sh` at :79 (warn on vip
+line count) and :99-102, where a count mismatch is a **fail**, not a warn. Adding vault's
+VIP takes the count to 12, so `VIP_COUNT_EXPECT` must move to 12 in the same change or
+the gate fails. Note that CURRENT-STATE flags `pre-flight-checks.sh` as VR0-frozen (no
+`$DC` selector), so whether it gates VR1 today needs confirming -- but the constant is in
+the shared library and any DC-aware successor inherits it. A generator emitting the VIP
+set should DERIVE this count rather than carry it as a second literal.
+
+**Gate relationship.** This decision does NOT gate the dc1 deploy. What the family
+ruling gates, and what must be resolved before deploy, is three items: (1) the vault
+VIP plus its band octet (a D-020 conformance repair, OPS not ARCH); (2) the octavia
+family sub-ruling; (3) the reconciled dual-family VIP literals for both DCs, in the
+symmetric overlay shape above. The subcarve is NOT among them -- D-111 (ADOPTED
+2026-07-11) already ratifies the per-plane v6 subcarve and the values are imported for
+both DCs.
+
+**Open questions (operator).**
+
+1. Metal VIP host addresses come straight out of the plane `/64` and share it with node
+   addresses; D-111's VIP-dedicated `/64` at `:11` exists only on the provider/GUA leg.
+   Confirm no MAAS deployed-node band claims the VIP octet on the metal planes. A
+   collision is repaired by a D-111 amendment (a metal VIP sub-range), not by values.
+2. Octavia family. D-101 places `lb-mgmt` in the IPv6-only ULA group, but
+   `overlays/dc-dc-ipv6-family-matrix.yaml:63-82` documents live upstream IPv6
+   breakage on that path (LP #1911788, #1913409). Recommendation: dual-stack octavia's
+   API endpoint like its ten peers, keep `lb-mgmt` v4 as a logged D-101 exception, on
+   the ruling's own standard -- a path with open upstream bugs is not where IPv6-only
+   "makes sense". This is an exception to an ADOPTED decision and is the operator's.
+3. Does the reserved-range registry become a first-class NetBox object, or continue to
+   be derived (plane rows from prefixes; `capi-mgmt-subnet` and metadata live-resolved
+   per D-074/D-035)? Deriving is recommended; D-074's stated gain is that NetBox's
+   uniqueness duty shrinks to the routed space. Operator has asked for more information
+   before ruling.
+4. Values-file format and location; and whether generated artifacts are COMMITTED
+   (reviewable diffs, recommended) or generated at deploy time (unreviewable).
+5. Runner and credential for any automated render. GitBucket has no Actions-style
+   runner and SSH access is v2-deferred, so an automated push needs a host (jumphost
+   timer, or a NetBox webhook worker) and an HTTPS credential. That is a
+   security-ledger row, not part of this decision.
+
+**Related:** D-020 (dual provider+metal VIPs -- NOT D-036, mis-cited as such in four
+live sites; see the DOCFIX in this session's changelog), D-100/D-101 (addressing,
+families, mesh), D-111 (per-DC v6 subcarve, ADOPTED), D-052/D-053 (bindings, six-plane
+split), D-104 + 2026-07-24 amendment (controller VM), D-107 (per-DC airgap mirror),
+D-108 (cross-DC), D-119 (region-qualified tags), D-121 (Option C + R-3), D-016/D-074
+(tenant CIDRs), D-035 (capi-mgmt reserved), D-067 (barbican-vault on metal-internal),
+D-110 (repo has moved; never hardcode its path), D-133 (flat per-NIC carve, no VLAN
+stack -- why VLANs are correctly absent from the apex), D-134 + its 2026-07-23
+AMENDMENT (the contiguous band table; the amendment is authoritative and the original
+table above it is superseded), D-124 (rack statics), D-131 (DNS forwarder .3), D-135
+(mirror .4), DOCFIX-195 (apex takes all VR1 writes; baldurkeep merge-back deferred),
+BUNDLEFIX-052. Companion audit records: `docs/audit/decision-recon-20260725.md`,
+`docs/audit/stage5-expansion-review-20260724.md`,
+`docs/audit/committee-20260724-track2-bundle-render.md`.
+
+--- END append block ---
diff --git a/_handoff-not-committed/20-ruling-records.md b/_handoff-not-committed/20-ruling-records.md
new file mode 100644
index 0000000..e11c5e6
--- /dev/null
+++ b/_handoff-not-committed/20-ruling-records.md
@@ -0,0 +1,95 @@
+# 20 -- Operator ruling records (GA-R5)
+
+GA-R5: a ruling exists only when its Status line quotes the QUESTION and the operator's
+EXACT UTTERANCE, dated, committed and pushed BEFORE dependent work. One decision per
+operator exchange -- these three arrived in three separate exchanges on 2026-07-25 and
+were not batched at the point of ruling. If recording them in a single commit would
+read as a batch adoption, split into one commit per ruling; the safe reading wins.
+
+Chat has NOT adopted anything. These are records for Code to commit.
+
+================================================================================
+## RULING 1 -- address family policy (amends nothing; confirms D-101)
+================================================================================
+
+QUESTION PUT TO THE OPERATOR: whether dc1 phase-4 deploys v4-only (deferring IPv6, per
+the expansion review's option (b)) or dual-stack.
+
+OPERATOR UTTERANCE (2026-07-25), verbatim:
+  "Dual stack to be used where IPv4 is required, IPv6 where IPv6 only makes sense."
+
+CLARIFYING EXCHANGE, verbatim: "Dual stack deployment for DC0 and DC1. This is the
+deployment when the dual-stack is added"
+
+EFFECT:
+- This is D-101's family matrix restated, not a new policy. D-101's own rationale line
+  already reads "v6 wherever possible, v4 only where forced". No amendment required.
+- The expansion review's option (b) v4-only phasing is CLOSED.
+- `overlays/vr1-dc1-vips.yaml` (v4-only triple) is not a D-101-conformant deploy input
+  on its own; the reconciliation is forced before deploy.
+- Applies to BOTH DC0 and DC1 in this deployment, so the literal burden is both DCs.
+- What it does NOT reduce: all three API VIP legs remain dual-stack under D-101
+  (provider-public GUA plus v4 for external clients and workload nodes reaching public
+  Keystone; metal-admin v4 because PXE is v4-first; metal-internal v4 for D-020's
+  `resolve_address(INTERNAL)` path). The six-value-per-app string in
+  `overlays/dc-dc-ipv6-family-matrix.yaml` is D-101-correct as authored.
+- STILL OPEN under this ruling: octavia. D-101 places `lb-mgmt` in the IPv6-only ULA
+  group, but the overlay documents live upstream IPv6 breakage there. That sub-ruling
+  is open -- see open question 2 in item 10.
+
+CURRENT-STATE consequence: bullet (b) "v4-only vs dual-stack phasing ... operator
+decides" is RESOLVED. See item 30.
+
+================================================================================
+## RULING 2 -- keystone policy-override VERIFY-LIVE gate
+================================================================================
+
+QUESTION PUT TO THE OPERATOR: whether to add a VERIFY-LIVE gate confirming the
+`policyd-override` resource lands on every keystone unit after `dc-ha-scaleup.yaml`
+scales keystone to 3, given that a broken override is atomic (the whole policy is
+discarded, silently reverting every tenant domain-manager to a plain user).
+
+OPERATOR UTTERANCE (2026-07-25), verbatim:
+  "dc-ha-scaleup: Yes to the verify-live"
+
+EFFECT: add to the Stage-4 VERIFY-LIVE set --
+  `juju status` shows `PO:` on EVERY keystone unit, never `PO (broken):`.
+
+Rationale for the gate's weight: this is the highest-consequence single check in the
+deploy. `bundle.yaml` carries `use-policyd-override: True` with
+`resources: {policyd-override: ./policies/overrides.zip}`; `policies/overrides.zip` is
+present (3419 bytes, single member `domain-manager-policy.yaml`) and
+`scripts/keystone-policy-drift.sh` byte-matches the member against source. The
+mechanism is intact at bc9a2df -- the gate confirms it SURVIVES scale-up. Failure has
+no other symptom, and it takes down the SCS Domain Manager persona (D-051, D-064) that
+the commercial tenant self-service model rests on.
+
+================================================================================
+## RULING 3 -- per-DC artifact shape
+================================================================================
+
+QUESTION PUT TO THE OPERATOR: there is no `vr1-dc0-vips.yaml`; dc0's VIPs are inline in
+`bundle.yaml` while dc1 has an overlay. Under ruling 1 both DCs need v6 legs, so the
+asymmetry must break -- (i) symmetric (extract dc0 to its own overlay, base becomes
+VIP-free, renderer has one output shape per DC) or (ii) asymmetric (dc0 v6 legs into
+base, two renderer output modes forever)?
+
+OPERATOR UTTERANCE (2026-07-25), verbatim:
+  "Your question about 1 or 2, go with 1. Base bundle and everything else is applied
+  via overlay."
+
+EFFECT (option (i), symmetric):
+- `bundle.yaml` becomes VIP-free and holds topology only.
+- dc0's VIPs are extracted from base into `overlays/vr1-dc0-vips.yaml`, mirroring
+  `overlays/vr1-dc1-vips.yaml`.
+- Every per-DC value arrives via overlay, dc0 included. No DC is special.
+- The renderer has ONE output shape per DC; Roosevelt's Nth DC matches its first.
+
+IMPLEMENTATION NOTE for Code: this edits a render the operator has already validated
+(`e898c3b`). Treat the extraction as a mechanical move -- the dc0 VIP values currently
+in base (`keystone: 10.12.4.50 10.12.8.50 10.12.12.50`, and the peer applications on
+the `.50`-`.60` band) move unchanged into the new overlay in the same commit that
+removes them from base. Verify with `provider-bundle-check.py --overlay --dc vr1-dc0`
+that the merged result is byte-equivalent to the pre-move merged result before the
+dual-stack legs are added. Do the MOVE and the ADD as two commits, not one -- the move
+is provably neutral, the add is not.
diff --git a/_handoff-not-committed/30-current-state-update.md b/_handoff-not-committed/30-current-state-update.md
new file mode 100644
index 0000000..7bf9763
--- /dev/null
+++ b/_handoff-not-committed/30-current-state-update.md
@@ -0,0 +1,95 @@
+# 30 -- docs/CURRENT-STATE.md update (SAME COMMIT as item 10)
+
+GA-R1/C1: any commit changing a status CURRENT-STATE carries must update it in the same
+commit; repo-lint L10 enforces. GA-R1 rule 2: legal status tokens are OPEN / BLOCKED /
+HELD / CLOSED, and only in this file.
+
+Target: the Stage-4 / Phase-3 bullet, lines 173-193 (at bc9a2df; re-locate at 4ed29aa).
+It sits in **section 1 "Where the project IS"**, which the 2026-07-25 reconciliation
+confirms is authoritative.
+
+WARNING before editing this file -- `docs/audit/decision-recon-20260725.md` found
+**section 4 "RULED-BUT-NOT-BUILT" comprehensively STALE (HIGH)**: authored 2026-07-18 and
+never updated, with 4 of 5 bullets contradicted by section 1 and by on-disk state -- it
+claims DC0 is unbuilt (built/commissioned, G10 CLOSED), dc1 substrate UNBUILT (roots
+exist, G12 CLOSED), D-100 netem HELD as a comment (instantiated `main.tf:353`), D-129 qga
+not written (shipped, G13 CLOSED). The status authority contradicts itself. Do NOT read
+section 4 as current and do NOT reconcile these edits against it -- section 1 and the
+gate table in section 6 govern. The section-4 repair is queued and operator-deferred;
+this pack does not attempt it.
+
+Also queued from the same record, not addressed here: G14's SEC count says 12 open while
+`ledger-scan` reports 15 (adds SEC-017/-018/-019); and
+`runbooks/dc-dc-phase4-juju-bundle-per-dc.md:192` still claims the bundle "ships NO
+designate", contradicting ADOPTED D-106 and `bundle.yaml:830`.
+
+================================================================================
+## Edit 1 -- the RESOLVE-BEFORE-DEPLOY list (currently lines 173-182)
+================================================================================
+
+Item (a) TEXT FIX plus scope widening. It currently reads "D-036 says vault carries
+VIPs" -- wrong decision (this is DOCFIX-NNN (A); see item 40) -- and "needs a dc1-band
+VIP overlay", which ruling 3 widens to both DCs:
+
+  (a) **vault VIP** -- vault is scaled to 3 with `vault-hacluster` at `cluster_count: 3`
+      but carries NO `vip:` anywhere in the tracked tree, so hacluster has no VIP
+      resource to manage and `vault:secrets` consumers resolve to a unit address.
+      **D-020** (not D-036) lists vault among the applications carrying provider+metal
+      VIPs. Needs a per-DC VIP in the symmetric overlay shape (ruling 3) plus the
+      vault-HA VERIFY-LIVE. Tenant-facing: `barbican-vault` is a `vault:secrets`
+      consumer and barbican holds tenant secrets plus Octavia's TLS material.
+
+Item (b) is RESOLVED by ruling 1 -- replace it:
+
+  (b) **address family: RULED 2026-07-25.** Dual-stack where IPv4 is required, IPv6-only
+      where IPv6-only is sound (D-101's matrix), for BOTH DC0 and DC1 in this
+      deployment. The v4-only phasing option is closed. Consequence: the
+      `vr1-dc1-vips` / `dc-dc-ipv6-family-matrix` per-key REPLACE collision must be
+      reconciled to ONE dual-family `vip` per app per DC before deploy -- it is no
+      longer deferrable. Octavia's family remains an OPEN sub-ruling (`lb-mgmt` IPv6
+      has live upstream breakage; see D-NNN open question 2).
+
+Add item (c):
+
+  (c) **per-DC artifact shape: RULED 2026-07-25.** `bundle.yaml` becomes VIP-free
+      (topology only); every per-DC value arrives via overlay, dc0 included. dc0's VIPs
+      extract from base into `overlays/vr1-dc0-vips.yaml`.
+
+Add to the VERIFY-LIVE gate list (ruling 2):
+
+  `juju status` shows `PO:` on EVERY keystone unit after scale-up, never `PO (broken):`.
+
+================================================================================
+## Edit 2 -- the NetBox-coupling bullet (currently lines 185-190)
+================================================================================
+
+It currently reads "being scoped as a new PROPOSED D-number (next-free per ledger-scan)
+in Chat ... Prompt handed to the operator 2026-07-24." Replace with the outcome:
+
+  - **NetBox->deploy coupling: PROPOSED as D-NNN (Chat, 2026-07-25).** A per-DC
+    renderer generating overlays and tfvars from the NetBox record, recommending option
+    (C) -- build the values-file back half now for both DCs, add the NetBox front half
+    for Roosevelt. Does NOT gate the dc1 deploy. Mechanism awaiting operator ruling.
+    The target OPERATING MODEL (NetBox draft -> approval on the rendered diff -> apply
+    -> bounded self-healing) is PINNED for a dedicated planning session, not ratified.
+
+================================================================================
+## Edit 3 -- correct a stale claim in the same bullet
+================================================================================
+
+The FOLLOW-UP line asserts `cloud-assert.sh` "false-passes decorative HA on the 12
+scaled API services". Keep it -- it is accurate and is what the D-NNN per-hacluster
+VIP-owned check closes. But note in the same bullet that D-111 is ADOPTED, so no
+subcarve trust gate exists on the v6 values (they are imported for both DCs and
+verifiable in `netbox/draft/vr1-office1-current-20260725.json`). This forecloses a live
+analysis error: the Chat seat briefly treated the subcarve as an open blocker on the
+strength of `docs/dc-dc-netbox-buildout-scope.md` section 5, which is stale -- that is
+DOCFIX-NNN (B).
+
+================================================================================
+## Verification
+================================================================================
+
+  bash scripts/repo-lint.sh     # L10 must pass: status change + CURRENT-STATE, same commit
+  grep -nE "OPEN|BLOCKED|HELD|CLOSED" docs/CURRENT-STATE.md | sed -n '1,5p'
+                                # status tokens only here, per GA-R1 rule 2
diff --git a/_handoff-not-committed/40-session-changelog-items.md b/_handoff-not-committed/40-session-changelog-items.md
new file mode 100644
index 0000000..3e41f9b
--- /dev/null
+++ b/_handoff-not-committed/40-session-changelog-items.md
@@ -0,0 +1,145 @@
+# 40 -- Items for the CURRENT session changelog
+
+GA-R2/D1: ONE changelog per session -- append these to Code's existing session
+changelog. Do NOT mint per-topic changelog files. The changelog IS the review surface:
+every item states what, why (evidence), and how to revert. Changelogs are
+session-scoped scratch, consolidated at stage close, never citable as status or
+decision authority.
+
+================================================================================
+## ITEM -- D-NNN PROPOSED: NetBox-coupled per-DC render pipeline [ARCH]
+================================================================================
+
+WHAT: appended the PROPOSED entry to `docs/design-decisions.md`; updated the Stage-4
+bullet in `docs/CURRENT-STATE.md` in the same commit (C1).
+
+WHY: escalates the Fork-2 renderer deferral
+(`docs/audit/committee-20260724-track2-bundle-render.md`) to a NetBox-coupled
+generator. Evidence for the problem statement is measured at bc9a2df, not asserted:
+four disagreeing app-to-VIP lists; two overlays owning `vip:` for the same 10
+applications under per-key REPLACE; no `vip:` for vault anywhere in the tracked tree
+against `vault-hacluster cluster_count: 3`; and the pull/cannot-pull inventory taken
+from `netbox/draft/vr1-office1-current-20260725.json` (139 prefixes with `scope_site`
+on 92; four ip-addresses, none a VIP; no `dcim/interfaces`; no `ipam/vlans`).
+
+REVERT: `git revert <commit>` -- the entry is append-only text plus the CURRENT-STATE
+bullet; no behavioural surface changes. PROPOSED, so nothing downstream depends on it.
+
+================================================================================
+## ITEM -- DOCFIX-NNN (A): the dual-VIP decision is D-020, not D-036
+================================================================================
+
+WHAT: corrected four live citations of `D-036` where `D-020` is meant.
+
+  `docs/CURRENT-STATE.md:175`
+     "... anywhere; D-036 says vault carries VIPs; needs a dc1-band VIP overlay ..."
+  `docs/audit/stage5-expansion-review-20260724.md:74`
+     "... when vault was de-HA'd. D-036 lists vault among the apps carrying
+      provider+metal VIPs."
+  `docs/design-decisions.md:3425`
+     "already carries all 12 hacluster subordinates and, per **D-036**, both
+      provider+metal VIPs on every ..."
+  `docs/design-decisions.md:3541`
+     "D-036 (dual VIPs, already present), D-062 (mysql-at-3), ..."
+  `docs/audit/decision-recon-20260725.md:116`   (NEW -- created 2026-07-25)
+     "... rendered vault (no vip) vs D-036 ..."
+  `docs/audit/decision-recon-20260725.md:121`   (NEW -- created 2026-07-25)
+     "... cloud-assert --capture vs D-121 HA / D-036 vault / D-108 ..."
+
+ESCALATION: the two sites above did not exist when this DOCFIX was drafted. The
+reconciliation record created on 2026-07-25 propagated the mis-citation into a brand-new
+artifact, taking the live count from four to SIX. The error is actively spreading through
+new work, which raises this from bookkeeping to a fix worth doing before the next
+audit record is authored.
+
+WHY: `docs/design-decisions.md:392` is `## D-020: Dual provider + metal API VIPs on
+clustered charms`. `:498` is `## D-036: magnum-capi-helm driver / chart / CAPO coherence
+(resolved)` -- nothing to do with VIPs. The error has already escaped the repo: it
+appeared in the design brief handed to the Chat seat. It also masked substance --
+reading the correct decision is what surfaced that D-020's ratified set includes vault
+and excludes ceph-radosgw, while the deployed set does the exact opposite (one
+substitution, unrecorded in either direction).
+
+DO NOT TOUCH: `docs/design-decisions.md:462, 498, 516, 530, 599, 1182`;
+`runbooks/phase-07-conductor-graft.md:13`;
+`runbooks/phase-08-workload-cluster-acceptance.md:10`; anything under `docs/archive/`.
+Those eight are correct driver/chart/CAPO references.
+
+OPERATOR CHOICE BEFORE EDITING SITE 2: `stage5-expansion-review-20260724.md` is a dated
+audit record. Either (a) correct in place with a bracketed marker
+"[corrected DOCFIX-NNN: D-020, not D-036]" -- recommended, since the document is a live
+design signal still being consumed -- or (b) leave the record verbatim and add a
+correction note at the head. Do not let this be chosen silently.
+
+VERIFY: `git grep -n "D-036" -- ":!docs/archive"` -- expect 8 hits, all driver/chart
+context, zero in VIP context.
+
+REVERT: `git revert <commit>` -- text-only across three files, no behavioural effect.
+
+================================================================================
+## ITEM -- DOCFIX-NNN (B): buildout-scope section 5 contradicts adopted D-111
+================================================================================
+
+WHAT: demoted `docs/dc-dc-netbox-buildout-scope.md` section 5 item 1 from an open
+sub-decision to a pointer at D-111. Sites: line 5
+("(candidate D-111+; assign via `ledger-scan` at adoption)"), line 132 (the section
+heading "Sub-decisions requiring operator ratification (candidate D-111+)"), line 138
+("script's OWN proposal, explicitly un-ratified").
+
+WHY: `## D-111: VR1 per-DC v6 subcarve aligned to the deployed NN mnemonic` carries
+`**Status:** ADOPTED 2026-07-11` and names the very scope-doc sub-decision it ratifies.
+The scope doc was never updated to point back, so it has read as open for two weeks.
+Not cosmetic: it caused a live analysis error on 2026-07-25 -- the Chat seat recommended
+treating the subcarve as a blocking trust gate on the v6 values and withdrew the
+recommendation only after reading the register. Ratified state belongs in one place.
+
+Keep the reasoning below the pointer as history -- the two conflicts recorded there are
+why D-111 chose NN-mnemonic alignment. Audit the REST of section 5 the same way: check
+each remaining item against the register before leaving it as open.
+
+VERIFY: `bash scripts/ledger-scan.sh` -- D-111 must not appear 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 -- three operator rulings recorded (GA-R5)
+================================================================================
+
+WHAT: recorded the 2026-07-25 rulings on address family, the keystone policy-override
+VERIFY-LIVE gate, and per-DC artifact shape. Each carries its question and the
+operator's exact utterance, per item 20 of the handoff pack.
+
+WHY: GA-R5 -- dependent work is invalid until the ruling is committed and pushed. The
+artifact-shape ruling gates the dc0 VIP extraction; the family ruling gates the
+reconciliation; the VERIFY-LIVE ruling adds a Stage-4 gate row.
+
+REVERT: `git revert <commit>` per ruling. Reverting a ruling record invalidates the
+work that depends on it -- revert dependents first.
+
+================================================================================
+## ITEM -- DOCFIX-NNN (C): D-134's superseded band table carries no in-place marker
+================================================================================
+
+WHAT: mark the ORIGINAL D-134 band table as superseded, in place, at
+`docs/design-decisions.md` (the table under `## D-134:`, above
+`## D-134 -- AMENDMENT (2026-07-23)`).
+
+WHY: the amendment's header says it supersedes the original table, but the original table
+itself carries no marker. A reader who greps `D-134` and reads the first table gets
+SUPERSEDED bands -- control `.10-.19`, compute `.20-.49`, storage `.201-.254` -- instead of
+the authoritative contiguous table (`.4-.49` utility, `.50-.99` VIP, `.100-.200` nodes,
+`.201-.254` dynamic). The Chat seat did exactly this on 2026-07-25 and was one read away
+from flagging a false discrepancy against the reconciliation record, which quotes the
+amendment correctly. Anyone authoring the band-modelling tool from prose is in the same
+trap, and the bands are precisely what the coupling must model.
+
+Suggested minimal fix: a `**SUPERSEDED by the 2026-07-23 AMENDMENT below -- do not use
+these bands.**` line immediately above the original table. Do not delete it; the original
+is the record of what the operator rejected and why.
+
+VERIFY: `awk` from `## D-134:` to `## D-134 -- AMENDMENT` shows the marker before the
+first table row.
+
+REVERT: `git revert <commit>` -- single-line text addition, no behavioural effect.
diff --git a/_handoff-not-committed/50-ledger-bounded-summary.md b/_handoff-not-committed/50-ledger-bounded-summary.md
new file mode 100644
index 0000000..0d54d6b
--- /dev/null
+++ b/_handoff-not-committed/50-ledger-bounded-summary.md
@@ -0,0 +1,26 @@
+# 50 -- Session-ledger append (GA-R4 rule 1: 15-LINE HARD CAP)
+
+Append at the ledger TAIL as a new `## SESSION CLOSE ...` block. Do NOT touch the
+machine-derived fence (`<!-- SECTION: machine-derived ... -->` to
+`<!-- END: machine-derived -->`) -- owned by `ledger-scan`, never hand-edited. The full
+session body goes to `docs/archive/` in the same close commit.
+
+Re-count before committing. The block between the markers is 15 lines.
+
+--- BEGIN 15-line block ---
+## SESSION CLOSE 2026-07-25 -- NetBox->deploy coupling scoped in Chat (bounded, GA-R4)
+- D-NNN PROPOSED [ARCH]: NetBox-coupled per-DC render pipeline, option (C) recommended;
+  revised against decision-recon-20260725 -- gap is SUB-PREFIX (D-134 bands + 33 VIP
+  addresses), apex writes are IN scope (DOCFIX-195), VLAN/space/fabric stays MAAS-sourced
+  (D-133), and extending sandbox-fidelity-check.py sequences FIRST. Non-gating for dc1.
+- 3 rulings recorded (GA-R5, exact utterances): family dual-stack-where-v4-required
+  DC0+DC1; keystone PO: per-unit VERIFY-LIVE after scale-up; per-DC shape symmetric
+  (base VIP-free, dc0 VIPs extract to a dc0 overlay).
+- DOCFIX-NNN (A) dual-VIP decision is D-020 not D-036 -- now SIX live sites, two created
+  by the recon itself; (B) buildout-scope s5 demoted to a D-111 pointer; (C) D-134's
+  superseded band table needs an in-place marker (it misled this seat).
+- Found: VIP_COUNT_EXPECT=11 (lib-net:59) is a HARD fail gate in pre-flight-checks
+  :99-102 -- must go to 12 with the vault VIP. Vault .61 is band-legal per D-134 amended.
+- PINNED: operating-model planning session; SpryGit dev-handover doc (Chat next).
+- Chat-side skill copy confirmed STALE vs repo (245 vs 130 lines); operator to upload.
+--- END 15-line block ---
diff --git a/_handoff-not-committed/60-vault-vip-values.md b/_handoff-not-committed/60-vault-vip-values.md
new file mode 100644
index 0000000..9c5a475
--- /dev/null
+++ b/_handoff-not-committed/60-vault-vip-values.md
@@ -0,0 +1,129 @@
+# 60 -- Vault VIP: proposed values, derivation, and confirm-before-write gates
+
+Operator, 2026-07-25: "Give me a recommendation I can relay to Code." This is it.
+
+NOT paste-ready configuration. Hard rule 2 is in force: never use an inferred value in
+a command. Every address below is DERIVED from a point-in-time snapshot plus a ratified
+decision. Code CONFIRMS each against live state before writing. If a value cannot be
+confirmed, stop and report -- do not write it.
+
+This is a D-020 CONFORMANCE REPAIR, not a new decision. Per GA-R3 it is OPS: a
+changelog item plus a values change, no D-number. Doubt resolved down.
+
+Verified against repo HEAD bc9a2df.
+
+================================================================================
+## Why vault needs this
+================================================================================
+
+Measured (`git grep` across the tracked tree excluding `docs/archive`): NO `vip:` for
+vault anywhere. `bundle.yaml`'s vault stanza has no `options` block at all.
+`overlays/dc-ha-scaleup.yaml` sets `vault: {num_units: 3, to: [lxd:0, lxd:1, lxd:2]}`,
+declares `vault-hacluster` with `cluster_count: 3`, and re-adds
+`[vault:ha, vault-hacluster:ha]`.
+
+hacluster manages a VIP resource in pacemaker. With no `vip` on the principal there is
+no VIP resource to manage, so `vault:secrets` consumers resolve to a unit address rather
+than a virtual one. The exact consumer-side behaviour is charm-specific and is NOT
+asserted here -- it belongs in the VERIFY-LIVE set below.
+
+Tenant-facing consequence: `barbican-vault` is a `vault:secrets` consumer, and barbican
+is tenant-facing -- tenant secrets, plus the TLS material Octavia uses for terminated
+listeners. Losing one vault unit degrades tenant secret operations and TLS load
+balancers on a cloud sold on HA. D-020 lists vault among the applications carrying
+provider+metal VIPs; the artifact departs from it with no decision recording the
+departure.
+
+================================================================================
+## Proposed shape
+================================================================================
+
+PLANES: metal-admin + metal-internal ONLY. NO provider leg.
+
+  Vault has no external consumers. D-067 puts `barbican-vault -> vault` (vault-kv) on
+  metal-internal. A provider VIP would expose the cloud's TLS root beyond need for zero
+  benefit. Both planes are already bound in vault's stanza (`""` -> metal-admin;
+  `access`, `certificates`, `cluster`, `external`, `ha`, `secrets`, `shared-db` ->
+  metal-internal), so the VIP lands on bound spaces.
+
+  Tenants receive the Vault root CA as a FILE in the handoff packet, not as network
+  reachability, so omitting the provider leg does not affect tenant handoff.
+
+OCTET: `.61`. A RECOMMENDATION, NOT A DERIVATION. It is next after the band in
+`overlays/vr1-dc1-vips.yaml`: keystone `.50`, barbican `.51`, cinder `.52`, glance
+`.53`, magnum `.54`, neutron-api `.55`, nova-cloud-controller `.56`, octavia `.57`,
+openstack-dashboard `.58`, placement `.59`, ceph-radosgw `.60`.
+
+ARTIFACT: per ruling 3 these land in the per-DC VIP overlays
+(`overlays/vr1-dc0-vips.yaml`, `overlays/vr1-dc1-vips.yaml`), never in `bundle.yaml`.
+
+================================================================================
+## Proposed values
+================================================================================
+
+v4 bands: `netbox/draft/vr1-office1-current-20260725.json`, six-plane prefixes by
+`scope_site`. v6 bands: same snapshot plus the D-111 subcarve (metal `/60` at `:20`,
+admin `/64` `:20`, internal `/64` `:21`).
+
+  DC0 (site vr1-dc0)
+    metal-admin        10.12.8.0/22        -> 10.12.8.61
+    metal-internal     10.12.12.0/22       -> 10.12.12.61
+    metal-admin v6     fd50:840e:74e2:220::/64  -> fd50:840e:74e2:220::61
+    metal-internal v6  fd50:840e:74e2:221::/64  -> fd50:840e:74e2:221::61
+
+  DC1 (site vr1-dc1)
+    metal-admin        10.12.68.0/22       -> 10.12.68.61
+    metal-internal     10.12.72.0/22       -> 10.12.72.61
+    metal-admin v6     fd50:840e:74e2:320::/64  -> fd50:840e:74e2:320::61
+    metal-internal v6  fd50:840e:74e2:321::/64  -> fd50:840e:74e2:321::61
+
+Vault takes NO GUA leg, so it never touches the D-111 API-VIP `/64` at `:11`.
+
+================================================================================
+## CONFIRM BEFORE WRITE -- four gates, not suggestions
+================================================================================
+
+1. `.61` is unallocated in all four v4 plane bands above and in the four v6 `/64`s. The
+   snapshot is point-in-time; re-read live.
+
+2. NO MAAS deployed-node band claims the VIP octet on the metal planes. **Largely
+   answered by decision, 2026-07-25:** D-134 as AMENDED (the authoritative contiguous
+   table -- NOT the superseded original above it) reserves `.50-.99` as the VIP band on
+   row 0 of every VR1 DC plane `/22`, with nodes at `.100-.200` and dynamic/enlistment at
+   `.201-.254`. `.61` therefore sits inside the reserved VIP band with no node or dynamic
+   range anywhere near it, and CURRENT-STATE records the dynamic-range move to `.201-.254`
+   as in place. What remains is the narrow check: confirm `.61` is not already assigned.
+   The v6 side is unaffected -- D-111's VIP-dedicated `/64` at `:11` exists only on the
+   provider/GUA leg, and vault takes no GUA leg.
+   IF `.61` IS TAKEN: the next free octet inside `.50-.99` is the answer, not a band
+   change. A band change would be a D-134 amendment and an operator ruling.
+
+3. The vault charm on `1.8/stable` (pinned; D-068 keeps the 1.16 lineage ruled out)
+   accepts a space-separated dual-family `vip` value. Do not assume -- confirm against
+   the charm's config schema. If it does not, the fallback is single-family plus a
+   recorded D-101 exception, which is an operator ruling.
+
+4. After the change, confirm the VIP is OWNED by a unit, not merely configured.
+   `scripts/cloud-assert.sh` currently false-passes this per
+   `docs/audit/stage5-expansion-review-20260724.md`; the per-hacluster VIP-owned check
+   proposed in D-NNN is what closes it. Until it exists, verify by hand.
+
+================================================================================
+## A HARD GATE COUPLING -- do not miss this
+================================================================================
+
+`scripts/lib-net.sh:59` sets `VIP_COUNT_EXPECT=11`. It is consumed by
+`scripts/pre-flight-checks.sh` at :79 (warn on vip line count) and at :99-102, where a
+count mismatch is a **fail**, not a warn.
+
+Adding vault's VIP takes the real count to 12. `VIP_COUNT_EXPECT` must move to 12 in the
+SAME change, or the gate fails on a correct configuration.
+
+Caveat: CURRENT-STATE flags `pre-flight-checks.sh` as VR0-frozen (no `$DC` selector,
+host_sysid-by-hostname), so whether it gates VR1 today needs confirming. Either way the
+constant lives in the shared library and any DC-aware successor inherits it. D-134's band
+table also quotes `VIP_COUNT_EXPECT=11` in prose, so that reference goes stale in the same
+moment -- point it at the library rather than restating the number.
+
+Longer term: a generator emitting the VIP set should DERIVE this count, not carry it as a
+second literal that has to be remembered.
diff --git a/docs/audit/operating-model-plan-20260725.md b/docs/audit/operating-model-plan-20260725.md
new file mode 100644
index 0000000..469d884
--- /dev/null
+++ b/docs/audit/operating-model-plan-20260725.md
@@ -0,0 +1,150 @@
+# Operating-model plan: NetBox -> deploy (planning session input)
+
+**Date:** 2026-07-25. **Branch:** `dc-dc-stage4-phase3-maas-deploy`.
+**Status:** ADVISORY / planning input. Adopts nothing. `docs/CURRENT-STATE.md` remains
+the sole status authority (GA-R1). Authored in the Chat design seat; PINNED for a
+dedicated operator planning session.
+**Companion to:** `docs/audit/decision-recon-20260725.md`,
+`docs/audit/committee-20260724-track2-bundle-render.md`, and the PROPOSED
+NetBox-coupling decision in `docs/design-decisions.md`.
+
+A PLAN, not a decision. Deliberately NOT a D-NNN entry: the operator asked for a
+recommendation plus a dedicated planning session, so the target operating model is not
+ripe for ratification. Implement NOTHING from this file.
+
+Authored against repo HEAD bc9a2df.
+
+================================================================================
+## 1. The model as the operator described it (2026-07-25)
+================================================================================
+
+  Draft changes in NetBox
+    -> a tool or queued item reads the changes; operator approves before anything begins
+    -> OpenTofu / MAAS / Juju (whichever the change requires) processes the deployment,
+       assignment or change
+    -> the process is as automated and self-healing as possible without operator
+       interaction
+    -> operator is notified on completion, with logs entered and artifacts created
+    -> operator is given next-step instructions derived from the process
+
+This is the standard source-of-truth-driven infrastructure automation shape. The three
+recommendations below are refinements to it, not a different mechanism.
+
+================================================================================
+## 2. Recommendation A -- the approval gate belongs on the RENDERED DIFF
+================================================================================
+
+Approving "someone changed a prefix in NetBox" does not tell the operator what will
+happen to the cloud. Approving "here is the resulting overlay diff, the `tofu plan`, and
+the validator report" does.
+
+  NetBox draft -> renderer emits artifacts onto a git branch
+              -> THE BRANCH DIFF IS THE CHANGE REQUEST
+              -> operator approves the diff
+              -> apply (tofu -> MAAS -> Juju, each gated as today)
+
+- Costs nothing extra: the artifacts are generated either way; the diff is free.
+- Rollback for free (`git revert`); audit for free (the diff IS the record, with
+  reviewer and timestamp attached).
+- Matches existing discipline exactly: verify-before-mutate wants a verification
+  artifact, and the diff plus validator report IS that artifact.
+- Keeps intent store and executable artifact reconciled by construction, not by trust.
+
+================================================================================
+## 3. Recommendation B -- split "self-healing" in two
+================================================================================
+
+SAFE, unattended -- CONVERGENT RE-ASSERT of declarative state:
+  - re-run the renderer; diff generated output against committed output
+  - re-apply idempotent configuration
+  - re-run validators and behavioural assertions (`provider-bundle-check.py`,
+    `cloud-assert.sh`)
+  These read, compare and report. Run them on a timer.
+
+NOT SAFE unattended -- AUTONOMOUS REMEDIATION of observed drift:
+  - On a live multi-tenant cloud the remediation can BE the outage, and the blast radius
+    crosses tenant boundaries. An automated actor that "repairs" a VIP or reassigns a
+    prefix while tenants are running can take down a plane.
+  - It contradicts the standing rules directly: destructive steps gated individually and
+    never batched; no live re-architecture inside a step.
+
+RECOMMENDATION: self-healing is READ / VERIFY / REPORT plus idempotent re-assert. Drift
+detection emits an alert AND a proposed remediation diff; the mutation stays gated. The
+automation's job is to make the operator's decision instant and well-evidenced, not to
+make it unnecessary.
+
+================================================================================
+## 4. Recommendation C -- the draft primitive already exists
+================================================================================
+
+No NetBox branching plugin is required. Code built the source separation in `bc9a2df`:
+
+  `netbox/prod-draft-dump.py`     -> netbox.baldurkeep.com, FROZEN v1 reference (4.5.8),
+                                     read-only for the duration of VR1
+  `netbox/office1-record-dump.py` -> office1-netbox 10.10.1.10:8000, the VR1 WORKING
+                                     APEX / "the RECORD" (4.6.4). Read-only, token from
+                                     environment, never embedded or printed, one script
+                                     per SOURCE so the source can never be confused
+  `netbox/draft/vr1-draft.json` (draft) vs
+  `netbox/draft/vr1-office1-current-20260725.json` (record snapshot)
+
+So: DIFF DRAFT AGAINST RECORD, and that diff is the intent change feeding the same
+approval gate in section 2. Low-tech, already committed, keeps write-back deferred per
+DOCFIX-195, and adds no new dependency to the airgap mirror (D-107).
+
+================================================================================
+## 5. Known gap to close in the session
+================================================================================
+
+GitBucket has no Actions-style CI runner, so "the renderer runs automatically" needs a
+host: a jumphost systemd timer, or a NetBox webhook plus a worker. Either way an
+automated push needs a GitBucket credential over HTTPS basic auth, because SSH access is
+v2-deferred. That is a security-ledger row (credential scope, storage, rotation), NOT a
+design decision, and it should be opened before any automated push exists.
+
+SEQUENCING NOTE: the operator intends to migrate from GitBucket to an in-house product,
+SpryGit. The runner and API surface this operating model needs are therefore
+REQUIREMENTS INPUT for SpryGit -- captured in `docs/audit/sprygit-requirements-inputs-20260725.md`.
+Do not design around GitBucket's
+current limits as if they were permanent.
+
+================================================================================
+## 6. Agenda for the planning session
+================================================================================
+
+1. Ratify or amend the approval-gate placement (section 2).
+2. Ratify the self-healing split; enumerate exactly which checks run unattended (3).
+3. Decide intent-store mechanics: NetBox draft objects, draft-vs-record JSON diff, or
+   both at different tiers (4).
+4. Decide the runner and its credential posture; open the security-ledger row (5).
+5. Decide whether generated artifacts are committed (recommended) or produced at deploy
+   time.
+6. Decide the notification and next-step surface: what the operator receives on
+   completion, and how "next steps" derive from which gates passed.
+7. Decide what this becomes: one process D-NNN (GA-R3: it needs architectural
+   consequence and a Roosevelt-delta to qualify), or a process runbook governed by an
+   existing decision. Doubt resolves DOWN to OPS.
+
+================================================================================
+## 7. Research scope requested by the operator -- NOT YET PERFORMED
+================================================================================
+
+The operator asked for best-practice workflow options grounded in real-world
+documentation and processes used by datacenters running this stack. That research has NOT
+been done; nothing in this file is its result. Candidate sources:
+
+- Canonical Charmed OpenStack reference architectures and operations guidance;
+  `terraform-provider-juju`; Juju bundle/overlay lifecycle practice.
+- Sovereign Cloud Stack (SCS) operational documentation -- directly relevant, since this
+  deployment implements the scs-0302 Domain Manager persona (D-051, D-064).
+- NetBox and Nautobot source-of-truth-driven automation, golden configuration, and
+  intended-vs-actual reconciliation models.
+- GitOps control-loop practice for infrastructure, specifically where the approval gate
+  sits relative to render and apply.
+- MAAS plus OpenTofu substrate lifecycle patterns for multi-site deployments.
+- OpenStack Operations Guide material on change management and drift.
+
+For each: what the pattern is, who runs it at datacenter scale on this stack, where the
+approval gate sits, what it automates unattended, and what it deliberately refuses to
+automate. Deliverable: options with trade-offs plus a recommendation measured against
+the Roosevelt-delta fitness function.
diff --git a/docs/audit/skill-divergence-20260725.md b/docs/audit/skill-divergence-20260725.md
new file mode 100644
index 0000000..1f8f57b
--- /dev/null
+++ b/docs/audit/skill-divergence-20260725.md
@@ -0,0 +1,44 @@
+# 90 -- Skill divergence: the Chat-side copy is stale (operator-flagged 2026-07-25)
+================================================================================
+
+The operator asked whether the Chat seat was using the mounted skill or the repo skill,
+and stated the Chat one is very stale. Confirmed. The Chat seat WAS using the mounted
+copy for the early part of the session and has switched to the repo copy
+(`.claude/skills/openstack-cloud-ops/SKILL.md`, 245 lines at bc9a2df). The mounted copy
+is 130 lines.
+
+The Chat-side copy cannot be rewritten from here -- the skills mount is read-only. The
+repo copy must be uploaded to the Chat/project skill surface by the operator. Until then
+any Chat session starts from the stale text.
+
+## Divergences found (mounted -> repo)
+
+- REPO PATH. Mounted names `openstack-caracal-ipv4` as authoritative and hardcodes a
+  clone URL. Repo says never hardcode the repo's own name or path (it has been
+  renamed/forked once, D-110) and ASK the operator for the exact clone URL. **This is
+  the direct cause of the failed clone at the start of this session** -- the seat tested a
+  path from memory instead of asking. The repo skill would have prevented it.
+- PHASE AUTHORITY. Mounted asserts the current phase is VR0 DC0 testcloud. Repo: phase
+  and stage live in `docs/CURRENT-STATE.md` ONLY (GA-R1) and are never trusted from the
+  skill or memory; the current mission is VR1 two-DC plus Office1 headend.
+- JUMPHOST. Mounted says `vopenstack-jesse`. Repo says `vcloud`, and carries the D-128
+  two-plane operating model (Plane 1 substrate on vcloud; Plane 2 MAAS/NetBox/inner-tofu
+  via `ssh voffice1`).
+- RECORD AUTHORITY. Mounted has NO GA section at all. Repo carries GA-R1..R7: one
+  changelog per session (never per-topic files), one ruling per operator exchange with
+  the exact utterance quoted, the OPEN/BLOCKED/HELD/CLOSED status vocabulary, D-number
+  admission with [ARCH]/[OPS] tags, memory governance, and the reconciliation
+  circuit-breaker.
+- DELIVERY CONVENTION. Mounted says "deliver as repo-relative ZIP plus a changelog
+  entry". Repo says deliver with an entry in the SESSION changelog, ONE per session,
+  GA-R2/D1. **The first draft of this handoff pack was built as per-topic files on the
+  mounted skill's instruction and had to be rebuilt.**
+- ROUTING GAPS. Mounted has no VR1 DC-DC track, no `references/platform-traps.md`, no
+  `references/opentofu-provider-docs.md`, no `site-baseleg.sh` / `dc-rack-net.sh` rows,
+  and no per-DC power-credential invariant (SEC-012/SEC-016).
+
+## Action
+
+Operator uploads the repo copy to the Chat/project skill surface. Per the repo skill's
+own stage-close rule, the skill is swept in the same close as the stage -- this
+divergence should be closed then if not sooner.
\ No newline at end of file
diff --git a/docs/audit/sprygit-requirements-inputs-20260725.md b/docs/audit/sprygit-requirements-inputs-20260725.md
new file mode 100644
index 0000000..014c3fd
--- /dev/null
+++ b/docs/audit/sprygit-requirements-inputs-20260725.md
@@ -0,0 +1,47 @@
+# SpryGit dev-handover: requirements inputs (pinned, document not yet written)
+
+**Date:** 2026-07-25. **Status:** PINNED / inputs only. No requirements have been
+drafted. This file exists so the work resumes without re-derivation.
+
+STATUS: PINNED, not started. The operator ruled 2026-07-25: "Hold the SpryGit document
+creation until after we finish up the Code handover but make sure it is pinned so we can
+continue it shortly." This handoff pack IS the Code handover, so SpryGit is the next Chat
+deliverable.
+
+## What is being produced
+
+A DEV HANDOVER DOCUMENT for the in-house SpryGit team: a full feature list covering
+basic functions, advanced functions, protocols, API surface, and other requirements,
+scoped so the product has everything needed for proper integration into this stack and
+the processes being developed here.
+
+## Why it is sequenced after this pack, and why it matters more than a wishlist
+
+The operating model pinned in item 70 has a REAL DEPENDENCY on git-host capability that
+GitBucket does not meet. SpryGit's requirements are therefore not speculative -- they are
+derived from a concrete pipeline this project is about to build. Known inputs already
+identified:
+
+- CI/runner: GitBucket has no Actions-style runner, which is the gap blocking "the
+  renderer runs automatically" (item 70 section 5).
+- SSH access: deferred to v2 on GitBucket; the current workaround is HTTPS basic auth.
+  An automated push needs a credential posture better than that.
+- Merge-request review as the APPROVAL GATE (item 70 section 2) -- the diff is the change
+  request, so review, required approvals, and merge policy are load-bearing, not
+  cosmetic.
+- Group/path semantics: this repo has already moved once (D-110), and the skill's rule is
+  never to hardcode its path. Redirects on move are a requirement, not a nicety --
+  GitBucket's lack of one cost a failed clone at the start of the 2026-07-25 Chat
+  session.
+- The browse-URL-vs-clone-URL trap: GitBucket's browse URL yields a silent empty clone.
+- Airgap/mirror behaviour per D-107.
+
+## Sources the operator authorised
+
+Current products in use, project knowledge, and online research into other git products'
+feature sets.
+
+## Not started
+
+No requirements have been drafted. Nothing in this file is a requirement list -- it is
+the pin plus the inputs already known, so the work resumes without re-derivation.