# Pass 4 / W4.3 -- Execution sequencing into the teardown -> redeploy (module invocations)

READ-ONLY planning artifact. Container-layer-elimination pass, Phase 4, Worker 3.
Confirmed ground truth consumed: `pass0-admin-report.md` Section 7a (**Option 1**;
cross-DC handling **(a)**; MAAS region stays on `vr1-dcN-maas-01`); `pass1-admin-report.md`
Sections 3-7 (planning change-set, the (a)-control spec, the L0-L5 layer model); `pass1-w3-
sequencing.md` (the base ordered sequence, adversarially corrected by the pass1 admin);
`pass2-admin-report.md` Sections 2-5 (the THREE isolation concerns, the 13 owed artifacts,
Phase-2 recommendation-grade resolutions); `pass3-admin-report.md` Sections 2-4 (the unified
tests change-set, the gate-home map, the #11 critical-path constraint). No mutation
proposed or performed here -- this is the ORDERED PLAN, expressed as module/artifact
invocations, for later gated execution.

**Layer model used (adopted from `pass1-admin-report.md` Section 5, W1.4's design --
NOT redefined here; W4.2 owns its full specification):** L0 host/inter-site substrate ->
L1 site/edge nodes (incl. the client VM as a `cloudinit-vm` instance) -> L2 DC substrate
(planes + node VMs; the two-root split collapses into L2) -> L3 enlist/commission -> L4
Juju/OpenStack deploy (D-140 pins as procedure) -> L5 verify/gate (cross-cutting).

Axis tags throughout: **[D-143]** (value/address substitution) / **[CE]** (container-elim,
shape change) / **[both]** (four confirmed dual-cause items, per pass1 check 5) /
**[unchanged]** (persists across the pivot, neither axis's content).

---

## 0. Four critical-path invariants -- where each lands, verified against the sequence below

| # | Invariant (source) | Lands at | Verified honored |
|---|---|---|---|
| 1 | **(a)-control BEFORE any flat substrate apply** (`pass1-admin-report.md` Section 3; `pass2-admin-report.md` Section 2.1) | **B.3, before B.4** | YES -- B.3 gate-closes before B.4.0/B.4.1 open; B.4 is the first step that can co-locate two DCs' plane bridges on vcloud's kernel |
| 2 | **Power-key mitigation (#11) BEFORE lib-hosts power-address re-derivation** -- blocks a 6-item test cluster (`pass3-admin-report.md` Section 4) | **B.6.1, before B.6.2** | YES -- B.6.2 (the `lib-hosts.sh` edit) is sequenced strictly after B.6.1's mechanism ruling + C4 harness; B.6.2's own gate lists the same 6-item cluster as blocked-together |
| 3 | **R7 revocation + MAAS record-release BEFORE substrate destroy** (`pass1-w3-sequencing.md` Part A steps 3-4; Part E risk 4) | **A.3-A.4, before A.5-A.7** | YES -- A.3/A.4 precede the destroy-plan/apply steps A.5-A.7 in Part A below, unchanged from pass1's ordering |
| 4 | **D-143 value-substitution kept attributable, separate from container-elim shape-change** (`SCOPE-AND-EXECUTION-PLAN.md` Section 7; pass1 check 5) | **Every row's tag column** | YES -- every step below carries its axis tag; the four genuinely dual-cause items (B.1.4, B.4/B.6.2 power-address, R7/A.3, B.7.1/B.7.4) are marked `[both]`, not silently folded into one axis |

No step below violates any of the four; the invariant table above is the single
cross-check a future session should re-run if this document is ever amended.

---

## PART A -- TEARDOWN of the current 10.12 Model-B checkpoint

Baseline unchanged from `pass1-w3-sequencing.md` Part A (pass1-admin-report.md consumed it
without correction) -- today's tooling (`runbooks/dc-dc-teardown-rollback.md`) tears down
today's actually-deployed two-root shape; the flat-topology target does not change what
commands remove the OLD shape.

| # | Module/artifact invoked | Layer (old shape) | Tag | Depends-on | Gate that closes it |
|---|---|---|---|---|---|
| A.1 | `tofu state pull` / backup, BOTH roots BOTH hosts (outer state on vcloud; each DC's inner state on the Office1 headend, D-128 Plane 2) | L2 (old two-root) | [D-143] | -- | backup file exists for both roots, both hosts, verified present before proceeding |
| A.2 | MAAS machine census, from voffice1 -- LENS 1 (every `power_type=virsh` record) + LENS 2 (corroborate vs `lib-hosts.sh` pinned boot-MAC roster) | L3 | [D-143] | A.1 | both lenses succeed; LENS 2 returns zero unattributed records |
| A.3 | **R7 credential-revocation checklist** (owed artifact #4) -- SEC-026 client cred, SEC-028 service cred, SEC-029 rack-local PKI copy (shred), D-126 per-env SSH keypair (clean retirement, no successor), MAAS rack enroll-secret residue; enumerated from EVERY `vm-secret-locations` row keyed to the rack/`vr1-dcN-client` host class, not only the named examples | L5 (credential gate) | **[both]** -- owed BY D-143's re-IP ruling (owed-execution item 5); the credentials revoked are container-elim-eliminated host classes | A.2 (hosts still up and reachable) | every row individually confirmed revoked/shredded/rotated with captured command output (never asserted from memory); rows marked RETIRED, append-only |
| A.4 | MAAS machine-record release/delete [MUTATION, operator-gated per record class] (owed artifact #5, amended by pass2 to include `maas rack-controller delete` decommission of `vvr1-dcN`'s Office1 registration + the region's `primary_rack`/DHCP reference) | L3 | [D-143] | A.3 (revoke before the record that names the credential-bearing host disappears) | LENS 2 (A.2's check) re-run and now returns zero; region-side rack-controller/`primary_rack` residue confirmed clean |
| A.5 | Plan destroy, INNER root (`opentofu/vr1-dcN-substrate/`), from voffice1; capture pre-destroy `virsh list/net-list/pool-list --all` baseline while the containment VM is still reachable | L2 (old inner root) | [D-143] | A.4 | plan reviewed; baseline captured |
| A.6 | Plan destroy, OUTER root (vcloud): `-target=module.vvr1_dcN -target=module.vr1_dcN_uplink -target=module.vr1_dcN_storage` only -- **do NOT target mesh/netem modules** (mesh triangle survives the pivot, confirmed at Phase 2/pass2 4.5) | L1 (old containment shape) | [D-143] | A.5 | plan reviewed; mesh/netem legs confirmed excluded from the target set |
| A.7 | Apply destroys, INNER then OUTER (`tofu destroy` plans from A.5/A.6); verify each half from the host that can see it (inner via the containment VM's virsh before it's gone; outer via vcloud's own virsh after) | L2 then L1 | [D-143] | A.6; each destroy individually operator-approved (hard rule 3 -- destructive steps never batched) | inner half destroyed + verified; outer half destroyed + verified |
| A.8 | Untargeted `tofu plan` drift gate (outer root; equivalent check on any surviving DC's inner root) | L5 | [D-143] | A.7 | zero unexpected drift |
| A.9 | NetBox DCIM decommission of the `vvr1-dcN` device record(s) (`netbox/dc-rack-mgmt-import.py`) | system-of-record (cross-layer) | [D-143] | A.7 confirmed gone | record marked decommissioned in live NetBox |
| A.10 | Repeat A.1-A.9 per DC (Path A) or run the Path B batched form for both DCs at once | -- | [D-143] | A.1-A.9 per DC | both DCs' checkpoints torn down and drift-gated |

**A.10 note (site-down primitive):** D-122's one-command site-down (`virsh destroy
vvr1-dcN`) is still literally available during Part A (the shape being torn down still has
it) but is NOT used raw here -- module-scoped `tofu destroy` is the reviewed, gated path
(CLAUDE.md hard rule 4, the 2026-08-03 incident this rule exists to prevent). The
PRIMITIVE'S REPLACEMENT for the new flat shape is a Part-B design note (B.0), not built or
exercised during this teardown.

---

## PART B -- REDEPLOY on flat 10.13 (Option 1), as module invocations

### B.0 -- site-down primitive replacement (design note only; not an executable step)

Under Option 1 there is no single VM whose destruction equals "the DC is gone." The
target-state primitive is **one module/root-scoped `tofu destroy` against the flat root's
`vr1_dcN_*` module set** (owed artifact #1, root-shape-(B)-dependent; owed artifact #6 is
the emergency `virsh destroy` loop over the same root's state-listed domains as a distinct
non-gated lever). Neither is built during the redeploy itself -- noted here so B.4/B.8 do
not read as having silently re-earned it without a delivered artifact.

### B.1 -- prerequisites (run once, before any apply; GATES B.4)

| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate that closes it |
|---|---|---|---|---|---|
| B.1.1 | **`dc-dc-whole-host-budget.py` FIT-calculator extension + fresh vcloud capacity re-measurement** (owed artifact #7, amended to include the 3 utility-node classes + artifact-service disk sizing) | L5 | **[both]** -- D-143 needs it for rebuild sizing; container-elim needs it to convert "~176 GiB freed" from directional to measured | -- | **>>> HARD GATE, closes before B.4's first apply <<<** live-measured host budget + extended FIT verdict for the flat 12+1-VM/DC roster, both DCs; a roster total exceeding the measured budget must FAIL, not be rounded or omitted (test A8) |
| B.1.2 | NetBox apex re-carve: mint B2 role `Cloud -- VR1 rebuild` owning `10.13.0.0/16`; re-carve VR1 prefixes/VIPs/ranges octet-preserving (D-143 owed-execution item 1) | system-of-record | [D-143] | -- | 10.13 prefixes exist under the new role; `Cloud` (10.12) role confirmed untouched |
| B.1.3 | `scripts/lib-net.sh`: flat defaults stay 10.12 (vr0-dc0 no-op preserved); `vr1-dc0`/`vr1-dc1` gain full 10.13 literal blocks; `:124-134` stale "inherits VR0" comment corrected (D-143 owed-execution item 2, F13) | L0 library | [D-143] | B.1.2 | `tests/lib-validate` green against the new literals |
| B.1.3a | 10.13 naming-collision DOCFIX (D-143 owed-execution item 3): `netbox/README.md:49` and `tests/dc-rack-mgmt-import/test_logic.py:265` reconciled so the /16 adoption doesn't leave a rack-IP test fixture inside the new Cloud space | doc/test currency | [D-143] | B.1.2 | repo-lint clean; no residual `10.13.0.5`-class fixture collision |
| B.1.4 | D-124 transit routes re-point + DC-side static shift (12->13) -- octet-preserving math is D-143; the BEARER host changes from `vvr1-dcN`'s rack-transit IP to the new `vr1-dcN-client` VM's transit leg (CE) | L1 (client-VM identity) / L0 (transit) | **[both]** | B.1.2 | NetBox shows the client VM's transit `/30` address; carried into B.4's client-VM module inputs |

### B.2 -- Office1 + vcloud prep (persists, off the container layer entirely)

| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.2.1 | vcloud host prep (Phase-0 runbook) | L0 | [unchanged] | -- | existing Phase-0 runbook gate |
| B.2.2 | Office1 headend standup (Phase-1 runbook), if not already up from the dc0 checkpoint -- voffice1 remains MAAS region host (D-132 addendum, unaffected) and remains Plane-2 host for whatever still needs a remote dial | L0/L1 | [unchanged] | -- | existing Phase-1 runbook gate |

### B.3 -- the NEW cross-DC isolation control (concern i) -- MUST precede B.4

| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.3.1 | Build + install the vcloud-level host isolation control (owed artifact #2): nftables artifact asserting no inter-plane/inter-DC forwarding on vcloud's own kernel; new SEC-NNN row (next-free SEC-034 per pass3 check 6); harness `tests/<name>` (C2, offline fixture model) | **NEW L5 artifact** (SEC-010's pattern, one layer up) | **[CE]** | B.2.1 (vcloud host prep) | **>>> HARD GATE, closes before B.4 <<<** `--check` enumerates the live bridge set for BOTH DCs' six planes and REFUSES if fewer than the full plane count resolves; must be installed and verified **before the first flat apply of EITHER per-DC root** (fork-robust invariant #1, honored regardless of root shape) |

### B.4 -- the flat apply (formerly outer + bootstrap-gate + inner), COLLAPSED into L1/L2

Root shape recommended (B) shared-outer + per-DC-flat roots (pass2 Section 3.1,
recommendation grade, Phase-4 ratifies). One apply CYCLE per DC.

| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.4.0 | Shared-outer root apply: mesh triangle legs (x3, MTU 9000) + uplink NAT `/24` -- already exist at vcloud level, UNCHANGED by flattening | L0 | [unchanged] | B.3 gate closed | existing mesh/uplink module state clean |
| B.4.1 | Per-DC-flat root apply invoking **`modules/dc-site`** (owed artifact #12, new IaC composition unit): composes storage pool (collapsed from 2-per-DC to 1) + six planes (`dc-planes`, unchanged CIDRs/MTU/family, D-139 unaffected) + DC edge (`opnsense-edge`, WAN input re-pointed to attach directly to `vr1_dcN_uplink` NAT, no `wan-bridge`) + 12 role/utility node VMs (`node-vm` x9 + juju-01 + maas-01 + tailscale-01) | L2 | **[CE]** structural; address VALUES inside these modules are **[D-143]** via B.1.3's lib-net literals | B.3 gate closed; B.1.1 FIT gate closed; B.1.3 lib-net literals present; B.1.4 client-VM address minted | apply succeeds (harness C1, `tests/dc-site`: 6-plane tree, 13-node roster incl. client VM = exactly one client-VM call, `mtu=1500` tenant / 9000 underlay, site-token parameterized, no hardcoded DC literal) |
| B.4.2 | Same `dc-site` composition, `client_vm` sub-call: the new **`vr1-dcN-client` VM** (`cloudinit-vm` module type, ~4/8192/80, octet `.8` metal-admin + D-124 transit leg per B.1.4) -- Option 1's non-hypervisor D-138 client host | L1 | **[CE]**, no D-143 content | B.4.1 (same apply) | client VM boots; identity confirmed live (not `lib-hosts.sh`/`CARVE_AUX_HOSTS`-tracked -- pass2 3.2 resolution) |
| B.4.3 | **MAC re-measurement pass** (owed artifact #8) -- 24 node MACs + 2 edge MACs move provider under the re-home; treat every MAC as unmeasured until re-pinned (hard rule 2) | L2 verify | [CE] | B.4.1 apply complete | live MAC roster captured and matches `dc-site`'s MAC invariant (rides C1's harness, pass3 3-rides list) -- **must close before B.6 trusts any MAC** |
| -- | *Vanished from the module set entirely (not re-homed, not a step):* `vvr1_dc0`/`vvr1_dc1` containment modules + sizing/rack-addressing/pubkey vars; the two `opentofu/vr1-dcN-substrate/` roots as separate roots/states; the qemu+ssh provider dial + D-126 keys (already revoked at A.3, no successor); `modules/wan-bridge` + `br-vr1-dcN-wan` netplan; the bootstrap gate's `--host-nodes` duty in `site-headend-install.sh` | -- | [CE] | -- | (deletion confirmed by B.4.1's module inventory containing none of these) |

### B.5 -- surviving duties, re-targeted (Phase-2 recommendation-grade placement; Phase-4 ratifies)

Pass1 left this OPEN ("THE highest-leverage open item"); pass2's W2.3 measurement
**largely dissolves it** -- carried here as pass2's recommended placement, explicitly
flagged not-yet-ratified.

| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.5.1 | **Rack-controller: RECOMMEND RETIRE the standalone Office1 enrollment entirely** (pass2 4.2(i)) -- both `vr1-dcN-maas-01` VMs already run `region+rack` (dc1 transcript-grade, dc0 functional-grade, `pass2-admin-report.md` check 2); NO `--role rack` re-enrollment step runs against the client VM. **A current-day live re-measure of both DCs' `primary_rack`/rackd state is OWED before this is treated as settled** (instrument-currency discipline) | L3 (was; now dissolved) | [CE] | B.4.1 (maas-01 exists) | live re-measure confirms `region+rack` on both fresh `-maas-01` VMs; A.4's decommission of the OLD `vvr1-dcN` rack record already closed this in Part A |
| B.5.2 | **D-131 forwarder: RECOMMEND RETIRE-WITH-EVIDENCE** for both DCs (pass2 4.2(ii)) -- each fresh 10.13 region sets its own BIND from the start; retirement evidence = a dig test against the fresh region's own BIND (owed artifact #13, harness C5). dc1's asymmetry (its forwarder was load-bearing pre-teardown) is a standing-RED case in C5 **until this live retirement is confirmed on the new build** | L3 verify (one-time evidence capture, not a standing service) | [CE] | B.4.1 (region exists), B.5.1 | dig-resolver-identity test PASSES against each fresh region's BIND (both DCs); captured into the build changelog |
| B.5.3 | Artifact-service (`.4`) placement -- **OPEN, sizing decision, not resolved here.** Neither the client VM (~80 GiB) nor `vr1-dcN-maas-01` (150 GiB earmarked, no spare) fits dc0's full mirror as authored; resolved WITH NUMBERS by B.1.1's extended FIT calculator (dc0 full-mirror vs dc1 cache per D-135) | L2/L3 storage | [CE] | **B.1.1 gate** (numbers), B.4.1 | a right-sized, explicitly-provisioned home is chosen and confirmed before B.6.6 (artifact-source verify) depends on it |
| B.5.4 | **SEC-010 transit-leg FORWARD-drop successor (concern ii)** -- endpoints RESOLVED by pass2 recommendation: client VM (DC side) + voffice1 (Office1 side); ONE extracted role-agnostic installer subcommand (out of `site-headend-install.sh`'s `node_host_setup()`) installs BOTH ends (owed artifact #3) | **NEW L5 artifact**, distinct from B.3 | [CE] | B.4.2 (client VM exists, its transit NIC re-measured -- NIC-naming trap: dc0 live was `enp1s0`, not `mgmt`) | harness A3 (`site-headend-install` Section-8 sub-case, migrated): both-ends fixture passes; wrong-role interface-name fixture FAILS; new SEC-row disposition (possibly a SEC-010 amendment) minted |

### B.6 -- MAAS enlist / commission / carve (largely unchanged mechanics; power-address value is BLOCKED)

**>>> Invariant #2, the load-bearing one for this section: owed artifact #11 (power-key
blast-radius mitigation) MUST close, with its harness green, before B.6.2 -- B.6.2 is the
edit that a 6-item test cluster is pinned to (pass3 Section 4). A guessed URI/key value
here is exactly the false-green mint the inferred-value rule (hard rule 2) exists to
prevent. <<<**

| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.6.1 | **Choose the concern-(iii) power-key mitigation mechanism** (owed artifact #11: `command=`-restricted SSH key / per-DC-scoped virsh wrapper / libvirt polkit ACL) -- required because BOTH DCs' region VMs + voffice1 now dial the SAME vcloud `qemu:///system` connection with no per-domain scoping (verified this pass, `pass2-admin-report.md` Section 2.3); root-shape (B) does NOT mitigate this (state isolation, not connection scoping) | **NEW L5 artifact** | [CE] | B.4.1 (flat topology exists to design against); B.2.1 (vcloud host prep) | **>>> HARD GATE <<<** harness C4 (offline rendered-ACL/`authorized_keys`/polkit parsing) green: dc0's key reaching a dc1 domain FAILS; reaching voffice1 FAILS (mirrored both directions); new SEC-NNN row minted with the mechanism |
| B.6.2 | `scripts/lib-hosts.sh` `VIRSH_POWER_ADDRESS_FROM_OFFICE1`/`_FROM_DCREGION` re-derivation to vcloud's own libvirtd (whether the FROM_OFFICE1/FROM_DCREGION split survives is itself a #11 design output) | L0 library | **[both]** -- D-143-shaped value change, CE-shaped mechanism dependency | **B.6.1 gate closed** | the SAME edit session closes A4 (`dc-selector`) + A5 (`maas-region-power-key` URI assertions) together -- editing one without the other is the named hazard H1 (a plausible-but-unenforced URI swap) |
| B.6.3 | `scripts/maas-node-power.sh` invocation-site/runbook literal updates -- no code change (address is `$1`, topology-agnostic) | L3 | [D-143 value] | B.6.2 | every invocation-site/runbook example carries the new address |
| B.6.4 | MAAS discovers node VMs via per-machine `power_type=virsh` (mechanism unchanged, D-123 amendment 2026-07-20 -- the pod/`vm-host` mechanism was already refuted before this pass; only the VALUE re-derives) | L3 | [D-143 value] | B.6.2, B.6.3 | discovery succeeds against the new power addresses |
| B.6.5 | Commission each node (Phase-3 Step 3); tag; nodes stay Ready; Pattern-A interface carve via `scripts/dc-node-carve.sh` (no code change, grep-verified zero containment hits, pure MAAS-API, `<site>`-parameterized) | L3 | [unchanged] | B.6.4, B.4.3 (MACs re-measured) | commission + carve succeed; single virsh hop, no "which host can see this domain" ambiguity (the old containment-layer confusion is structurally gone) |
| B.6.6 | PXE/boot-fabric verify (Step 6); per-DC artifact-source + time-authority verify (Step 7, target host = wherever B.5.3 lands); topology consistency check (Step 8) | L3 | [D-143 value for target host] | B.6.5, **B.5.3 resolved** | verify steps pass against the ruled artifact-service host |

### B.7 -- Juju + OpenStack bundle deploy (mechanically unchanged, host renamed)

| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.7.1 | Juju controller bootstrap on a tagged machine, run FROM the `vr1-dcN-client` VM (D-138 execution host, "never the vcloud jumphost" doctrine intact) -- same commands, renamed host from `vvr1-dcN` | L4 | **[both]** -- mechanics [D-143] unchanged, execution-host identity [CE] changed | B.4.2 (client VM up), B.6.6 (enlist/commission/carve complete) | `preflight.sh` gate (incl. new P10 for B.5.4, P4 dependent on B.6.1's mitigation, P8's declared-root-list loop replacing the single hardcoded `opentofu/` path) |
| B.7.2 | model/spaces setup, DC egress gate (`dc-egress-check.sh`, invocation-host literal re-points to the client VM), `juju deploy bundle.yaml` + overlays, dry-run first, mid-deploy watch | L4 | [unchanged mechanics] | B.7.1 | Phase-4 runbook's own dry-run + watch gates |
| B.7.3 | SEC-026/028/029 credentials (re-)MINTED on the client VM -- Part A step A.3 already revoked the old copies; this is a clean mint, not a migration (pass1 check 7 reconciliation) | L4 credential | **[both]** | B.7.1 | ledger register rows (P5 creds-matrix) re-point to the `client` host class; new rows added for B.3/B.5.4/B.6.1's own key material |
| B.7.4 | vault bring-up (Step 5), IPv6 family-matrix overlay (Step 6), phase-03/04/05 steps (7-9), `cloud-assert.sh --capture` (Step 10), controller backup (Step 11) | L4/L5 | [D-143 for literal addresses; mechanics unchanged] | B.7.2 | existing Phase-4 gates, unchanged content |
| B.7.5 | **VERIFY-LIVE gates** (Step 12): Ceph-over-v6 bind check (D-143 new literals); `geneve-encap-assert.sh` (owed artifact #10 -- MTU budget analytically unchanged by container-elim, live assert still owed as a NEW invocation point, not a script edit); **PLUS the B.3 (a)-control's `--check` RE-RUN**, now that both DCs' planes are actually co-resident on vcloud -- the first point in the whole sequence where the isolation claim is tested against real traffic (cloud-assert A11a periodic re-verify begins here) | L5 | [D-143] for Ceph literals; **[CE]** for the (a)-control re-run and the geneve re-invocation point | B.7.4 | Ceph bind check passes; geneve-encap-assert passes; (a)-control `--check` passes with BOTH DCs' planes live |

### B.8 -- close-out (both axes)

| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.8.1 | NetBox DCIM: register the new `vr1-dcN-client` VM + the flat node roster device records (owed artifact #9; mirrors A.9's decommission, opposite direction) | system-of-record | [CE] | B.4.1, B.4.2 | roster fully registered in live NetBox |
| B.8.2 | **Enter the container-elim [ARCH] decision record** (D-123 amendment vs. new D-number; ride-alongs: D-125 bridge-in retirement, D-138 concrete-host change, D-128 amendment -- Plane 2 shrinks to MAAS/NetBox, D-122 site-down re-earn, D-124 sizing-void re-cause, D-132-addendum premises note, Stage-3 Owns/Reuse-vs-new rewrite, the client-VM `.8` octet into the D-134 map) | -- (decision-record, not a build step) | [CE] | all of Part B substantively complete | operator ruling recorded (GA-R5) -- **the redeploy is NOT "done" while this is owed**, per SCOPE Section 7 |

---

## Bare-metal-test plug-in points (pre-Roosevelt, hardware specs owed "within days")

Per the operator's own framing and D-138's history (the client VM is explicitly "the D-138
Roosevelt bastion analog, rehearsed early," `pass0-admin-report.md` Section 4), the specs
plug into **sizing and provider targets inside existing steps**, not a new sequence. Split
by whether a step is hardware-PARAMETERIZED (re-run with new numbers/roster once specs
land) or hardware-AGNOSTIC (unaffected either way):

**Hardware-parameterized (specs plug in directly):**
- **B.1.1** -- capacity/FIT math re-derives from real host specs instead of vcloud's
  measured budget; the node-class roster may shrink ("a smaller set of hardware").
- **B.4.1/B.4.2** -- `dc-site`'s module bodies (planes x6, edge, node roster, client VM)
  are the SAME composition intended to transfer; the specs let sizing be re-derived for
  bare metal without changing which modules exist or their call order -- only the provider
  target (bare libvirt host vs vcloud-hosted VM) and concrete sizing numbers change.
- **B.4.3 / B.6.4** -- MAC handling: bare metal uses real NIC MACs discovered via MAAS
  enlistment, not libvirt-injected MACs from a tofu module -- the RE-MEASUREMENT discipline
  transfers, the injection mechanism does not.
- **B.5.3** -- artifact-service sizing is explicitly hardware-dependent (disk on real
  spinning/SSD capacity vs a vcloud-hosted volume).

**Hardware-agnostic (unaffected; the reusable asset IS the sequence/module shape):**
- **B.1.2/B.1.3** -- NetBox/lib-net addressing is pure IPAM, runs identically regardless of
  substrate.
- **B.6.5** -- carve scripts (`dc-node-carve.sh` etc.) are already `<site>`-parameterized,
  pure MAAS-API; grep-verified zero containment hits (pass2 3.3).
- **B.7** -- Juju/bundle deploy mechanics are unchanged by substrate class (D-140 pins L4 as
  procedure regardless).
- **The module INVOCATION ORDER itself (B.1 -> B.8)** is the reusable deliverable -- the
  "layered module system" the operator asked this pass to produce IS the thing rehearsed
  early, independent of whether L1/L2 target vcloud-libvirt VMs or bare hosts.

**Two controls that likely do NOT transfer as-is (flag explicitly, do not let a future
session assume parity):**
- **B.3's (a) cross-DC isolation control** is an artifact of hosting BOTH DCs' plane
  bridges on ONE vcloud-libvirt kernel. Genuinely separate physical hardware per DC at
  Roosevelt would not have this specific exposure -- the CONTROL PATTERN (host-level
  forwarding assertion) may still be good practice, but the gap it closes here may not
  exist at bare metal. Phase-4 should note this, not assume the artifact ships unchanged.
- **B.6.1's power-key mitigation (#11)** is a libvirt/`qemu:///system`-connection-scoping
  problem specific to multiple VMs dialing one shared hypervisor's virsh. Bare-metal power
  management (IPMI/Redfish, not virsh) is a structurally different credential-scope
  problem; the MITIGATION DISCIPLINE (per-DC credential separation, verified by a negative
  test) transfers, the concrete artifact does not.

**Nesting-depth honesty (carried from `pass1-w3-sequencing.md` Part D, not restated as new
here):** flat-Option-1 = `vcloud (libvirt) -> node VM -> nova KVM guest`, depth 2
(VR0-proven). Roosevelt bare metal = `bare host -> KVM guest`, depth 1. The flattening
rehearses the MODULE SHAPE and the single-apply/no-bootstrap-gate WORKFLOW, not the exact
nesting depth.

**B.5's placement should be RE-DECIDED, not carried forward blindly, once hardware specs
exist** -- a bare-metal build may have a materially different answer for where MAAS-rack/
D-131/artifact-service duties land than a VM-hosted `vr1-dcN-client` does (this echoes
`pass1-w3-sequencing.md` Part D verbatim; not re-derived, cited).

---

## Sources read this session

`SCOPE-AND-EXECUTION-PLAN.md` (full), `pass0-admin-report.md` (full), `pass1-admin-report.md`
(full), `pass1-w3-sequencing.md` (full), `pass2-admin-report.md` (full), `pass3-admin-report.md`
(full), plus `docs/design-decisions.md:8083-8182` (D-143 full ruling + owed-execution list,
re-read directly this session to confirm the five owed-execution items and their exact
wording). No inferred values used; every module name, owed-artifact number, and gate
condition traces to the cited pass document. Items marked OPEN/RECOMMENDATION-GRADE above
are stated as such, not silently upgraded to settled.