# Pass 0 -- ADMINISTRATOR REPORT: baseline & target topology (container-layer elimination)

**Author:** the Phase-0 administrator (multi-agent pass, `SCOPE-AND-EXECUTION-PLAN.md` Section 4).
**Date:** 2026-08-09. **Inputs:** `pass0-w1-substrate-map.md`, `pass0-w2-network-map.md`,
`pass0-w3-consumers.md`, `pass0-w4-targets.md` -- read in full, adversarially cross-checked
against repo ground truth (checks logged in Section 3). READ-ONLY synthesis; no mutation.

**This report ends in the Phase-0 OPERATOR GATE (Section 7). Do not start Phase 1 before the
operator rules on it.**

---

## 1. As-is map (W0.1 + W0.2 reconciled into one picture)

### 1.1 The substrate (Model B, D-122/D-123)

```
vcloud (outer libvirt, qemu:///system)               <- OUTER ROOT: opentofu/main.tf
|-- Office1 arm: office1_network / office1-wan / office1_opnsense / voffice1  (NOT container-layer)
|-- ubuntu_noble_base (shared base image)                                     (persists)
|-- D-100 mesh TRIANGLE (mesh-link x3, MTU 9000) + netem on dc0<->dc1         (persists)
|     office1<->dc0 leg = D-124 transit: voffice1 NIC2 172.31.0.1/30 <-> vvr1-dc0 NIC1 172.31.0.2/30
|     office1<->dc1 leg = transit:       voffice1 NIC3 172.31.0.5/30 <-> vvr1-dc1 NIC1 172.31.0.6/30
|-- vr1_dc0_uplink / vr1_dc1_uplink (site-wan NAT 172.30.2.0/24 / 172.30.3.0/24, MTU 1500, D-125)
|-- vr1_dc0_storage / vr1_dc1_storage (outer pool -- holds ONLY the containment VM's own disk)
|
`-- vvr1-dc0 / vvr1-dc1  ==== CONTAINMENT VM (D-123 Model B) ====
      108 vCPU / 480 GiB / ~3000 GiB (opentofu/variables.tf:137-156; RAM raised 416->480 2026-08-01)
      NIC1 = transit (SEC-010 FORWARD-drop keys here); NIC2 = IP-less, enslaved into the
      br-vr1-dcN-wan netplan bridge (D-125 bridge-in); expose_nested_virt = true
      |
      |== BOOTSTRAP GATE (scripts/site-headend-install.sh --role rack --host-nodes):
      |   nested libvirtd + inner pool dir + kvm nested=1 + OPNsense image staging +
      |   SEC-010 nftables writer + D-125 bridge verify. Bash, NOT tofu -- sits BETWEEN the roots.
      |
      `== INNER ROOT: opentofu/vr1-dcN-substrate/ (qemu+ssh into the containment VM, run
          from voffice1 per D-128; D-126 per-env key auth)
           |-- inner_storage pool (inside the containment VM's own disk image)
           |-- the SIX planes (dc-planes, isolated L2, MTU 9000) -- RELOCATED here by D-123
           |-- vr1_dcN_wan (wan-bridge onto br-vr1-dcN-wan) + vr1_dcN_opnsense (DC edge)
           `-- vr1_dcN_node x 12: 9 D-121 role nodes (3 control / 2 compute / 4 storage)
               + vr1-dcN-juju-01 (.5, D-104) + vr1-dcN-maas-01 (.6, D-132 addendum)
               + vr1-dcN-tailscale-01 (.7, D-129(iii)); all MAC-pinned
```

### 1.2 The two-stage apply ordering (structurally forced, not preferred)

OUTER apply (vcloud, Plane 1) -> BOOTSTRAP GATE (bash, over SSH) -> INNER apply (voffice1,
Plane 2, qemu+ssh). Forced because "a libvirt provider cannot be configured from a resource
created in the same apply" (`opentofu/main.tf:28-29`). Eliminating the containment VM removes
the forcing function entirely: one root, one state axis, no gate script, no cross-host provider
dial. This is the single largest structural simplification the elimination buys (W0.1 Sec 3).

### 1.3 What the "container layer" is, precisely

The `vvr1-dcN` VMs + their inner libvirtd + the inner roots + the bootstrap gate's node-host
mode + the D-125 bridge-in plumbing (wan-bridge module, IP-less uplink NIC, `br-vr1-dcN-wan`)
+ the qemu+ssh provider dial and its D-126 keys. It is NOT: the six planes, the node VMs, the
DC edge, the mesh triangle, the uplink NATs, or the LXD API-charm containers on deployed nodes
(all of which persist; the first three re-home, W0.1 Sec 5 / W0.2 Sec 4).

### 1.4 Network facts the elimination must preserve (W0.2)

- MTU/geneve budget: 9000 jumbo underlay -> tenant MTU 1500 with ~56-byte v6-geneve overhead.
  The containment hop was a same-MTU bridge with no extra encapsulation -- **removing it changes
  no byte budget** (W0.2 Sec 3). Do not let later phases imply an MTU benefit.
- The 2026-08-08/09 geneve-over-v6 defects (encap-family split, bracketed encap-ip) were
  OVN/OVS-layer, NOT containment-layer -- container-elim neither caused nor fixes them.
- SEC-010 (CLOSED) is an interface-scoped FORWARD-drop on the transit leg of vvr1-dcN and
  voffice1. Its ledger rationale is nesting-specific: vvr1-dcN "bridges ALL 6 inner planes +
  the transit" -- SEC-010 is doing the isolation a separate host would do for free.

---

## 2. Consolidated blast-radius inventory (W0.3 + W0.1/W0.2, deduplicated)

Census baseline: 424 `vvr1-dc` occurrences across 78 canonical files; ~26 in scripts, 17 tofu
files; the bulk is decision-record prose (append-only -- superseding notes only, never edits).

| # | Consumer (file:line) | Keys to the containment layer via | On flattening | Severity |
|---|---|---|---|---|
| 1 | `opentofu/main.tf:410-519,537-623` (`module vvr1_dc0/_dc1`) + sizing vars `variables.tf:137-156,175-194` + D-124 rack-addressing vars `:196-244` + D-126 pubkey vars | IS the containment VM + its sizing/addressing/keys | DELETED. Sizing/rack-addressing/pubkey vars go with it; `dc-dc-whole-host-budget.py` containment-overhead flags re-derived or dropped | HIGH |
| 2 | `opentofu/vr1-dc0-substrate/`, `vr1-dc1-substrate/` (whole inner roots + states) | qemu+ssh provider into vvr1-dcN | RETIRED as roots; their module CALLS (planes, edge, 12 node VMs, storage) re-home into the outer/flat root -- bodies unchanged, provider changes | HIGH |
| 3 | `modules/wan-bridge` + `vr1_dcN_wan` calls + the IP-less uplink NIC + `br-vr1-dcN-wan` netplan | D-125 bridge-in (exists only to fix OBS-3 nesting egress) | DELETED; DC edge WAN attaches directly to the outer `vr1_dcN_uplink` NAT (Model A item 8 -- same /24, no re-address) | MEDIUM |
| 4 | `scripts/lib-hosts.sh:52,157-168,212-214,246-251` (`VIRSH_POWER_ADDRESS*`) | qemu+ssh power URIs dial the containment VM's libvirtd | Re-derived to vcloud's own virsh; the FROM_OFFICE1/FROM_DCREGION split may collapse. Wrong values = "MAAS unreachable" masquerading as a network fault | HIGH |
| 5 | `scripts/maas-node-power.sh` | power address as ARGUMENT (topology-agnostic) | No code change; every invocation site/runbook example needs the new address | MEDIUM |
| 6 | `scripts/site-headend-install.sh` `--host-nodes` (~140 lines) + SEC-010 writer | THE containment-VM bootstrap + SEC-010 enforcement point | node-host mode = dead code for VR1; SEC-010's implementation must be REBUILT for the new boundary (Section 5), not moved. Rack-role remainder needs a re-homing decision (Section 6) | HIGH |
| 7 | `scripts/dc-rack-net.sh` (rack bridge-leg IPs `.2`/`.3` + D-131 node DNS forwarder) | runs ON vvr1-dcN; addresses are the containment VM's identity on its own inner bridges | Needs a NEW HOME (the Option-1 client VM is the natural candidate) or a ruled retirement -- D-131 is a DNS-availability control; silently losing it reintroduces the SERVFAIL bug | HIGH |
| 8 | SEC-028 juju service key + SEC-029 Octavia PKI overlay, resident on "the rack"; `vm-secret-locations` `rack` rows; SEC-026 isolation control | vvr1-dcN is a credential-bearing host (first `rack` rows in the register) | Residencies MIGRATE to the replacement client host; matrix/register rows re-point; SEC-026 "only that DC's credential" must be re-asserted; rotation triggers ("if the rack is rebuilt") FIRE on this change | HIGH |
| 9 | `runbooks/dc-dc-teardown-rollback.md` (Paths A/B/C/M) | `vvr1-dcN` as the teardown unit; D-122's "site-down = one `virsh destroy`" | Re-authored around a scripted group-destroy of the `vr1-dcN-*` domain set. The one-command site-down is a REAL D-123 regression to carry honestly; module design should re-earn it (tofu-module-scoped destroy) | MEDIUM-HIGH |
| 10 | D-128/D-138 execution-host surface (`runbooks/dc-dc-phase3:424,430`, `phase4:165-167`; `ssh -J voffice1` to the rack transit IP) | vvr1-dcN is the concrete D-138 client host | THE load-bearing decision -- answered by proposal in Section 4 (Option 1's client VM), ruled at the gate | CRITICAL (gate item) |
| 11 | `netbox/dc-rack-mgmt-import.py` + its harness | imports vvr1-dcN as a NetBox DCIM device | NetBox-side decommission/repoint (system-of-record data migration, not just code) | MEDIUM |
| 12 | `scripts/site-baseleg.sh:40-48` DC rows | deferred BECAUSE DCs nest behind qemu+ssh (deferral answered by D-138) | premise disappears; new leg only if the target needs one -- currently a no-op | LOW |
| 13 | `scripts/dc-mirror.sh:6`, `maas-profile-assert.sh:39`, `maas-role-tags.sh:37`, `dc-egress-check.sh:63,72` | doc-comments / usage examples naming vvr1-dcN or "the rack host" | doc-currency only; logic is host-agnostic | LOW |
| 14 | `lib-hosts.sh:69-72` `NIC_PLANE_ORDER`/`BREX_PARENT_NIC`; `:29-34` `CARVE_AUX_HOSTS` | conventions realized by the inner root's MAC pinning | Conventions carry forward; the FILE that encodes the pinning changes (row 2). MAC re-capture owed post-rebuild (moot-ish: 10.13 rebuilds the fleet anyway) | LOW-MEDIUM |
| 15 | **Non-consumers, named to prevent double-counting:** `scripts/lib-net.sh` (0 hits -- IPAM facts change under D-143 only, a separate ruled axis); plane CIDRs/families (D-139); the 66+17 design-decision/CURRENT-STATE hits (append-only record) | -- | -- | NONE |

---

## 3. Adversarial-check results (worker claims corrected or confirmed)

All checks run against repo ground truth this session; a plausible finding was not accepted
as a verified one.

1. **W0.3's "three ruled roles on vvr1-dcN" CONFLATES region and rack -- corrected.** The
   D-132 AMENDMENT ADDENDUM (`docs/design-decisions.md:7216-7243`, RULED 2026-07-30, exact
   utterance "Dedicated region VM per DC at utility .6 (Recommended)") puts each DC's MAAS
   REGION (regiond + PostgreSQL) in its OWN VM -- `vr1-dcN-maas-01`, already one of the 12
   inner-root node VMs. **The region survives flattening as a flat sibling with no redesign.**
   What vvr1-dcN actually carries: the MAAS **rack** controller (`--role rack`), the D-131
   node-DNS forwarder, and the D-138 client + SEC-028/SEC-029 credential residencies. This
   RE-GRADES W0.3's CRITICAL: the execution-host question is real but narrower than "three
   roles orphaned," and it is now ANSWERED-BY-PROPOSAL (Option 1's client VM), pending the gate.
2. **"Model A fallback is a validated artifact" -- TRUE but NOT TURNKEY; do not overstate.**
   Verified: `docs/archive/model-a-fallback-plan.md` exists; tag `model-a-fallback` resolves to
   `114d392`, dated **2026-07-16**. That PREDATES the D-132 amendment + addendum and D-138
   (both 2026-07-30), D-139's IPv6 family rulings (07-31), D-143 (10.13), the three utility
   node VMs, and the lb-mgmt plane. Its own MAAS line -- "region on Office1 + rack" -- is
   **contradicted by D-132 as now ruled**. Its Section-4 revert procedure (`git checkout
   model-a-fallback -- opentofu/`) must NOT be run: it would resurrect a 10.12-era, 9-node,
   Office1-region substrate. **The real build path is re-homing the CURRENT inner-root module
   calls (W0.1's map) into a flat root, with Model A as shape precedent** -- "Model A PLUS the
   rulings Model A never had," freshly validated. One thing the archive DOES verify in Option
   1's favor: Model A itself kept a small non-hypervisor `vvr1-dc0` headend (4/8192/80,
   `expose_nested_virt=false`, metal-admin + transit legs) -- Option 1's client VM is exactly
   that shape, repurposed.
3. **D-138 citation CONFIRMED.** `docs/design-decisions.md:7118-7124`: "the per-DC management
   bastion holds only its own DC's cloud credential" / "Each DC has a management entry point
   inside it; the NOC reaches that entry point." The RULING is "the cloud-facing client lives
   IN the DC" -- a principle, with vvr1-dcN only as the then-concrete host. Option 1's client
   VM (inside the DC's planes, holding one DC's credential) is **consistent with D-138's
   principle**; the concrete-host change still needs recording (amendment vs. new D -- Phase 4
   frames it, Section 6).
4. **Cross-DC adjacency gap: W0.4 does NOT address it -- OPEN.** Grep-confirmed: the only
   "cross-DC" text in `pass0-w4-targets.md` is the credential row of the tradeoff table. Both
   options put both DCs' plane bridges and node VMs on vcloud's single libvirtd. See Section 5.
5. **Worker contradictions logged:** (a) W0.2's diagram says "416 GiB" for the containment VM
   -- STALE; `variables.tf:143-150` shows 416->480 GiB raised 2026-08-01 (W0.1/W0.4 are
   correct). (b) MTU: W0.2 rules the budget analytically unaffected; W0.4 lists it OWED --
   reconciled as: **analytically unchanged** (same `underlay_mtu=9000` var; vcloud-level
   mesh/office1 networks already run 9000), with a live jumbo/geneve assert still owed
   post-build (Section 8). (c) W0.3 row 4's "MAAS region is SHARED" echo (from SEC-026's
   pre-amendment text) is superseded by D-132's per-DC regions -- SEC-026's regional-blast
   -radius note is historical context, not current topology.
6. **Option-2 counter-evidence found during verification:**
   `runbooks/dc-dc-phase4-juju-bundle-per-dc.md:167` -- tool-placement table row: "anything at
   all | **never the vcloud jumphost** ... It picks the transport only" (measured 2026-07-29:
   no juju/maas binaries on vcloud). Runbook doctrine, not a D-ruling -- but Option 2 would
   reverse it, on top of inverting SEC-026's isolation control.
7. **No inferred-value violations found** in the four worker docs beyond the items above --
   claims spot-checked (ssh -J runbook lines, lib-hosts power URIs, SEC ledger rows, D-132
   addendum, sizing vars) all resolved to the cited lines.

---

## 4. Target-topology options + recommendation

Both options share the flat core: 12 node VMs + DC edge as vcloud-libvirt siblings; the six
planes re-homed to vcloud level (same CIDRs/families/MTU -- IPAM identity untouched); D-125
bridge-in deleted (edge WAN -> direct NAT); mesh triangle unchanged; nesting depth 4 -> 2
(VR0-proven); one tofu root/state axis, no bootstrap gate, no qemu+ssh dial.

### Option 1 (RECOMMENDED) -- flat nodes + a small per-DC client VM (Model A shape, D-132/D-138-updated)

A dedicated ~4/8192/80 non-hypervisor VM per DC (`vr1-dcN-client`), legs = metal-admin +
transit, carrying: the D-138 client role, the SEC-028/SEC-029 credential residencies, and
(pending Section 6) the D-131 forwarder / rack-controller remainder. It is a flat utility
sibling -- no nested libvirt, no `expose_nested_virt` -- so the containment PATTERN is gone
even though a small VM remains.

- **For:** lowest-delta path (Model A precedent + current inner-root module bodies re-homed);
  preserves SEC-026 per-DC credential isolation exactly as today; is LITERALLY the D-138
  Roosevelt bastion analog, rehearsed early (transfers to the pre-Roosevelt bare-metal test);
  keeps the phase-4 "never the vcloud jumphost" doctrine intact.
- **Against:** SEC-010 must be re-authored + re-measured for the new VM (new NIC-naming trap);
  D-123's one-command site-down is lost (re-earn via module-scoped destroy); the cross-DC gap
  (Section 5) still needs a ruling; ~2 small VMs of overhead retained (~8 GiB each).
- **Capacity:** directionally frees ~176 GiB host RAM (2 x 96 GiB containment overhead removed,
  minus 2 x 8 GiB client VMs); vCPU a wash. QUALITATIVE -- exact FIT owed (Section 8).

### Option 2 (NOT recommended) -- fully flat: client + credentials on vcloud itself

Same flat core; no client VM; juju/openstack + both DCs' MAAS-admin-scoped keys land on the
shared jumphost via a new host-side leg into metal-admin.

- **For:** ~8 GiB/DC less overhead; one fewer VM class.
- **Against:** inverts SEC-026's load-bearing isolation control (both DCs' credentials on the
  widest-blast-radius host); contradicts the phase-4 runbook's "never the vcloud jumphost" row;
  no Roosevelt analog -- throwaway work undone at the bare-metal test; net-new unprecedented
  surface (host-side veth/bridge into a MAAS plane on the live jumphost).

**Recommendation: Option 1.** Every verified axis -- risk delta, credential isolation,
Roosevelt fidelity, runbook doctrine -- favors it; Option 2's only advantage is a marginal
~8 GiB/DC. The cross-DC gap (Section 5) applies EQUALLY to both options, so it is a gate
condition on the flattening itself, not a tiebreaker. Framing per W0.4: "eliminate the
container layer" is fully satisfied by Option 1 -- no VM is a hypervisor for another VM; the
retained client VM is the same class as juju-01/maas-01. If the operator's intent is literally
zero additional VMs, that is Option 2 with the above accepted knowingly.

---

## 5. THE CROSS-DC ADJACENCY GAP -- unresolved by W0.4, stated plainly

**W0.2's finding (Sec 4, "the single largest wiring risk"):** today dc0's and dc1's six plane
bridges live on SEPARATE kernels (each containment VM's own libvirtd). Flattening puts BOTH
DCs' plane bridges + node VMs co-resident on vcloud's ONE libvirtd/kernel for the first time
in any deployed shape. SEC-010 -- interface-scoped to transit legs that no longer carry this
function -- does NOT cover host-level cross-DC leakage (an accidental host address on a plane
bridge, a forward rule, br_netfilter interactions). **Neither W0.4 option addresses this;
verified absent from the doc.** Nuances carried honestly: the adjacency existed in Model A's
committed design, but Model A was never deployed and SEC-010 was priced AFTER it against
Model-B's separate-kernel shape -- so no ruled control covers the flattened adjacency. This is
DISTINCT from rebuilding SEC-010's transit drop on the client VM (row 6) -- two controls.

Handling options for the gate (presented, not picked -- GA-R5):
- **(a) Accept co-residency + a new host-level control:** a vcloud-level nftables/isolation
  artifact asserting no inter-plane/inter-DC forwarding, with a mechanical `--check` gate and
  its own SEC-NNN row (SEC-010's proven pattern, one layer up). Designed in Phase 1/2.
- **(b) A per-DC isolation mechanism in the target design itself** (e.g., per-DC network
  namespaces or equivalent separation on vcloud) -- stronger boundary, more engineering,
  partially re-introduces the complexity being eliminated.
- **(c) Reject single-host flattening** for both DCs (not what the operator's directive
  implies, listed for completeness).

---

## 6. UNRESOLVED at Phase 0 / needs operator or later-phase decision

1. **Target topology itself** -- the gate (Section 7).
2. **Cross-DC isolation mechanism** -- Section 5's (a)/(b)/(c); at minimum a Phase-1 design
   item + a new SEC row if flattening proceeds.
3. **Rack-controller remainder + D-131 forwarder + mirror home:** does MAAS rackd co-locate
   onto `vr1-dcN-maas-01` (region VM), onto the Option-1 client VM, or elsewhere? Ditto the
   D-131 node-DNS forwarder and the `.4` artifact-service placement (`dc-mirror.sh` says "runs
   on the rack host" today). W0.3 flagged; no worker resolved it.
4. **The client VM's octet + naming:** inherit the rack's `.2` metal-admin identity or take a
   new utility-band octet (D-134 standing map is a cross-DC STANDARD -- needs a ruled octet);
   name should NOT be `vvr1-dcN` (avoid conflation with the eliminated containment class).
5. **Transit leg's surviving purpose + SEC-010 re-pin points:** qemu+ssh dial disappears;
   operator `ssh -J` access and any Office1-originated flows remain -- which ends get the
   re-authored FORWARD-drop (client VM + voffice1?), and does the mesh triangle survive
   unchanged (W0.4 implicitly kept it; W0.2 flagged it as a decision)?
6. **Credential-residency migration plan** (SEC-026/-028/-029 + `vm-secret-locations` `rack`
   rows + rotation obligations that FIRE on rack rebuild) -- Phase 1/2 work, listed so it is
   not lost.
7. **Teardown-primitive replacement:** the module-scoped group-destroy that re-earns D-122's
   one-command site-down (Phase 4 module design).
8. **Decision-record form:** D-123 amendment vs. new D-number for the container-elim (+ the
   D-138 concrete-host change and the D-125 bridge-in retirement ride along). Phase 4 FRAMES
   it; the operator rules it. NOT ruled at this gate.
9. **NetBox DCIM migration** for the vvr1-dcN device records (row 11).

---

## 7. >>> OPERATOR GATE (Phase-0 hard stop -- SCOPE plan Section 4) <<<

**Decision put to the operator:**

1. **Target topology -- confirm one:**
   - **Option 1 (recommended):** flat node VMs on vcloud libvirt + one small non-hypervisor
     per-DC client VM (metal-admin + transit legs) carrying the D-138 client role and the
     per-DC credential residencies.
   - **Option 2:** fully flat; client + both DCs' credentials on vcloud itself (weakens
     SEC-026 isolation; contradicts the phase-4 "never the vcloud jumphost" doctrine row; no
     Roosevelt analog).
2. **Cross-DC isolation gap (applies to EITHER option):** choose handling -- (a) accept
   co-residency + a new host-level isolation control with a mechanical gate + SEC row
   (designed Phase 1); (b) require a per-DC isolation mechanism in the target design; or
   (c) reject single-host flattening.
3. **Role re-homing:** confirm the MAAS region stays on `vr1-dcN-maas-01` (per D-132 addendum
   -- no change needed), and rule where the rack-controller remainder + D-131 forwarder land
   (client VM / maas-01 / retire-with-evidence).

Items 4-9 of Section 6 are flagged as downstream (Phase 1-4) work, not gate blockers.

---

## 7a. PHASE-0 GATE OUTCOME (operator, 2026-08-09)

Recorded as a DIRECTIONAL PLANNING CONFIRMATION at the Phase-0 gate -- NOT a GA-R5 [ARCH]
ruling and NOT a D-number (the formal container-elim ruling, D-123 amendment vs. new D, is
framed in Phase 4 and ruled then, per SCOPE Section 7). The operator was shown the
layer+separation diagram (artifact, Option-1 target) before confirming.

- **Target topology: OPTION 1 CONFIRMED** -- flat node VMs on vcloud libvirt + one small
  non-hypervisor per-DC client VM (metal-admin + transit legs) carrying the D-138 client role
  and that DC's credential residencies. Phases 1-4 plan against this.
- **Cross-DC adjacency gap (Section 5): handling (a) CONFIRMED** -- accept co-residency and
  design a new vcloud-level host isolation control (SEC-010's nftables pattern one layer up)
  with a mechanical `--check` gate and its own SEC-NNN row. This is now a Phase-1 DESIGN ITEM,
  not an open gate fork.
- **Role re-homing:** the MAAS region stays on `vr1-dcN-maas-01` (.6, D-132 addendum -- no
  change). The rack-controller remainder + D-131 forwarder + artifact-service placement (client
  VM vs. maas-01 vs. retire-with-evidence) is carried into Phase 1 as an open placement decision
  (Section 6 item 3), not resolved at this gate.

Feeds forward to Phase 1: plan against Option 1; treat (a) as a required design deliverable;
keep the container-elim change-set DISTINGUISHABLE from D-143's 10.12->10.13 address change
(two rulable axes riding one redeploy).

## 8. OWED live measurements (read-only; do not infer -- W0.4 Sec 5 + reconciliation)

1. **vcloud host-capacity currency:** `dc-dc-whole-host-budget.py:66-67`'s committed "MEASURED
   host budget" (256 vCPU / 1024 GiB / 10240 GiB) needs a fresh read-only measurement before
   any FIT verdict.
2. **Exact FIT for the flat 12-VM/DC roster:** the calculator lacks flags for the 3 utility
   node classes (juju/maas/tailscale, added after authoring) -- extend or hand-total before
   any freed-capacity number enters the Phase-4 change-set. Until then "~176 GiB freed" is
   directional only.
3. **MTU/jumbo/geneve assert on vcloud-level planes post-build:** analytically unchanged
   (Section 3.5), but the live gate (`geneve-encap-assert.sh` + a jumbo-path check) is owed
   once the planes exist at vcloud level.
