Pass 1 / W1.3 -- Teardown -> Redeploy SEQUENCING for the flat (Option 1) topology

READ-ONLY planning artifact. Container-layer-elimination pass, Phase 1, Worker 3. Confirmed Phase-0 outcome consumed as ground truth (pass0-admin-report.md Section 7a): Option 1 (flat node VMs on vcloud libvirt + a small per-DC vr1-dcN-client VM, D-138 shape); cross-DC handling (a) (accept co-residency + a new vcloud-level host isolation control, DESIGN ITEM, not yet built); MAAS region stays on vr1-dcN-maas-01; rack-controller remainder / D-131 forwarder / artifact-service placement is OPEN, carried here as an unresolved slot in the sequence, not invented.

No mutation performed or proposed as executable here -- this is the ORDERED PLAN only. Tags per item: [vanishes] [reorders] [new] [unchanged], and [D-143] / [container-elim] / [both] for the two riding axes (SCOPE-AND-EXECUTION-PLAN.md Section 7's "keep the two changes distinguishable" instruction).

0. Two teardown questions, kept separate

The worker prompt asks two different things that must not be conflated:

• 0.A -- Teardown of the CURRENT 10.12 Model-B checkpoint. This tears down what is ACTUALLY DEPLOYED today: the two-root, containment-VM, qemu+ssh shape. It uses TODAY's tooling (runbooks/dc-dc-teardown-rollback.md) because that is what matches the live state -- the flat-topology design does not change what commands tear down the OLD shape. This is D-143-tagged work (the checkpoint-then-redeploy pivot), not a container-elim mechanism in itself.
• 0.B -- Where D-122's one-command site-down PRIMITIVE gets replaced going forward. This is a container-elim design question: once the flat topology is BUILT, what does ITS OWN future teardown/DR primitive look like (Phase 4's module-scoped destroy). It is answered here as a target-state design note, not as an action taken during 0.A.

PART A -- TEARDOWN of the current 10.12 checkpoint (Section 0.A)

Baseline: runbooks/dc-dc-teardown-rollback.md Steps 1-5 (Path A, per-DC) / Path B (both DCs), read in full this session. This IS today's two-root shape; most steps below are [unchanged] mechanically -- the D-143/container-elim axes contribute exactly TWO new steps the runbook does NOT yet contain: A.3 (the R7 credential-revocation checklist, confirmed absent by the admin report Section 6 item 6 and open-items-review-20260809.md R7/R15) and A.4 (the MAAS machine-record release/delete that Step 2's own gate implies but the runbook only states as a contingency, not a sequenced step -- advisor-flagged, see below).

1. [unchanged][D-143] Back up state, BOTH roots, BOTH hosts (teardown-rollback.md Step 1): outer opentofu/terraform.tfstate on vcloud; each DC's INNER opentofu/vr1-dcN-substrate/terraform.tfstate, which lives on the Office1 headend (D-128 Plane 2) per the runbook's own callout (:608-615) -- a backup that only touched the vcloud copy has not backed up the substrate about to be destroyed.
2. [unchanged][D-143] MAAS-side machine census FIRST, from the Office1 headend (Step 2, :635-694): LENS 1 (enumerate every power_type=virsh record and attribute it) + LENS 2 (corroborate against lib-hosts.sh's pinned boot-MAC roster for the site). GATE: both lenses succeed and LENS 2 returns zero unattributed records.
3. [new][container-elim, D-143] R7 credential-revocation checklist (owed build, open-items-review-20260809.md:80,398,431; design-decisions.md:8174 D-143 owed-item 5). Run BEFORE the substrate destroy (the credential-bearing hosts must still be up and reachable to revoke cleanly; revoking after they are gone is a "trust it expired" guess, not a verified revocation). Per the admin report's credential-residency inventory (Section 2 row 8) and the security-ledger rows read this session:
   • SEC-026 (security-ledger.md:79): the Juju client credential (juju-vr1-dc0-cred/juju-vr1-dc1-cred, SEC-018/019) resident on the DC client host (today: vvr1-dcN itself, since D-138 put the client inside the containment VM). Confirm juju credentials --client on that host, then REVOKE/rotate the underlying MAAS admin-scoped key per SEC-026's own rotation-trigger note ("if the DC client host is rebuilt or shared" -- this teardown IS that trigger).
   • SEC-028 (security-ledger.md:81): the per-DC juju-vr1-dcN SERVICE credential minted ON the region VM and distributed to the rack (~/vr1-dcN-creds/, 0600). Revoke/rotate per its own OPEN rotation obligation -- "at v1 close, or immediately if the rack or region VM is rebuilt" (this teardown rebuilds both).
   • SEC-029 (security-ledger.md:82): the Octavia PKI overlay COPY on the rack (~/repo-stage/overlays/vr1-dcN-octavia-pki.yaml). Not a mint (SEC-004 is the authority) -- shred the rack-local copy; no upstream rotation needed for the copy itself, but confirm the headend's canonical copy is unaffected.
   • D-126 per-env SSH keypair (~/vr1-dc0-creds/, ~/vr1-dc1-creds/ private halves; opentofu/variables.tf:105-114,158-168): authenticated the now-retired qemu+ssh inner-provider dial. Revoke/shred -- this credential class has NO successor under container-elim (Part B has no qemu+ssh dial at all), so this is a clean retirement, not a rotation.
   • MAAS rack enrollment secret consumed at the rack's original enrollment (one-shot, already spent) -- confirm no residual copy sits readable on the rack filesystem.
   • Register updates riding the same pass (not new mints, bookkeeping): the checklist's BUILD should enumerate from EVERY vm-secret-locations row keyed to the rack/vr1-dcN-client host class, not only the three SEC rows named above by example -- the register-can't-see-a-row-it-doesn't-have discipline (this repo's own rule, creds-folder-convention memory pointer) applies here too: mark each such row RETIRED, not deleted (append-only discipline). GATE: every row above individually confirmed revoked/shredded/rotated, with the confirming command's output captured (not asserted from memory).
4. [new][D-143] MAAS machine-record release/delete [MUTATION, operator-gated per record class]. Step 2's LENS 2 will return NON-ZERO by construction on a live commissioned checkpoint -- the runbook's own text treats this as a contingency ("if records DO exist and you intend to lose them... release or delete them via MAAS's own documented flow FIRST, then re-run both lenses," :686-690), but for THIS teardown it is a guaranteed sequenced step, not an edge case. Release/delete every attributed record for the site (individually operator-approved, MAAS's own current documented flow, never invented here), then RE-RUN both lenses and confirm LENS 2 now returns zero -- only then does the GATE in Step 2 actually close. Also clean the REGION-SIDE residue that goes stale once the rack host is destroyed and is otherwise easy to miss: the vvr1-dcN rack-controller's own enrollment record on the Office1 region (it enrolled via the one-shot enroll-secret, site-headend-install.sh:25-29), and the region's primary_rack/DHCP-on-metal-admin reference to it. Flag both for confirmation as part of this step, not left implicit.
5. [unchanged][D-143] Pick the root, INNER first (Step 3, :751-836): plan -destroy in opentofu/vr1-dcN-substrate/ from the Office1 headend; capture the pre-destroy virsh -c "$VIRSH_POWER_ADDRESS" list/net-list/pool-list --all baseline while the containment VM is still reachable.
6. [unchanged][D-143] Pick the root, OUTER second (Step 3 cont'd, :838-882): plan -destroy -target=module.vvr1_dcN -target=module.vr1_dcN_uplink -target=module.vr1_dcN_storage on vcloud. Do NOT target the mesh-link/netem modules (shared with the surviving/adjacent site legs) -- carried forward unchanged into the redeploy since the mesh triangle persists per Part B step B.4.
7. [unchanged][D-143] Apply, INNER then OUTER (Step 4, :838-935): tofu destroy teardown-vr1-dcN-inner.tfplan from the Office1 headend, THEN tofu destroy teardown-vr1-dcN-outer.tfplan on vcloud. Verify each half from the host that can actually see it (inner via the containment VM's virsh BEFORE it is gone; outer via vcloud's own virsh after) -- the runbook's own trap: a vcloud-local virsh list never saw the DC's inner objects even when they were fully intact.
8. [unchanged][D-143] Confirm no drift outside the torn-down scope (Step 5, untargeted tofu plan on the outer root; equivalent check on the surviving DC's inner root if one exists). GATE: zero unexpected drift.
9. [new][D-143] NetBox DCIM decommission of the vvr1-dcN device record(s) (admin report Section 2 row 11, netbox/dc-rack-mgmt-import.py) -- a system-of-record data migration, not a code change; run against the LIVE NetBox after the substrate is confirmed gone.
10. [unchanged] Repeat 1-9 per DC (Path A) or run the Path B batched form (teardown-rollback.md:914-958) for both DCs at once if tearing down together; either way the mesh-link teardown note (:960-998) applies only if BOTH ends of a leg are going away -- confirm against Part B before deciding whether the mesh triangle itself is torn down or kept live through the pivot (Part B step B.4 assumes it is KEPT).

A.10 -- where does D-122's one-command site-down get replaced, for THIS teardown. It doesn't, in Part A -- Part A tears down the shape that HAS the one-command primitive (a single virsh destroy vvr1-dcN is still literally available here, per D-122 AMENDMENT 2026-07-16, design-decisions.md:4838-4842), even though this runbook does not use it raw (module-scoped tofu destroy is the reviewed, gated path; a raw virsh destroy bypasses state and is the exact class of error CLAUDE.md hard rule 4 was added to prevent, 2026-08-03 incident). The primitive's REPLACEMENT is a target-state property of the NEW flat topology, not of this teardown -- see Part B.0 below.

PART B -- REDEPLOY on flat 10.13 (Option 1)

Numbered against TODAY's chain (worker-prompt's own framing, confirmed by pass0-w1-substrate-map.md Section 3): outer-apply -> bootstrap-gate (site-headend-install.sh --host-nodes) -> inner-apply (qemu+ssh, from voffice1) -> MAAS enlist/commission -> juju deploy. Runbook baseline for the surviving mechanics: runbooks/dc-dc-phase0..phase6, docs/tool-index.md.

B.0 -- the site-down primitive's replacement (design note, answers Part A.10)

Under Option 1 there is no single VM whose destruction equals "the DC is gone" -- the DC is now N flat sibling domains (planes x6, edge, 12 node VMs, 1 client VM) on vcloud's own libvirt/state, the same shape docs/design-decisions.md:4903-4914's Model A already named: "Site-down DR = destroy the vr1-dcN-* domain group... as a scripted op (owned by dc-dc-teardown-rollback.md), NOT a single virsh destroy." Concretely this becomes ONE module-scoped tofu destroy -target=... (or a full-root destroy once the DC is the whole root/state) against the flat root, listing every vr1_dcN_* module in one plan/apply pair -- functionally Part A's steps 5-6 OUTER half alone (the runbook's own Step 3's OUTER sub-plan), because there is no separate inner half left to sequence around it. This re-earns the "one scripted command" property (not literally "one virsh destroy") and is exactly what admin report Section 6 item 7 flags as owed to Phase 4's module design -- noted here as the target shape, not built here.

B.1 -- capacity + IPAM prerequisites (run once, ahead of any apply)

1. [unchanged][both] vcloud host-capacity re-measurement (admin report Section 8 item 1) -- dc-dc-whole-host-budget.py's committed 256 vCPU / 1024 GiB / 10240 GiB needs a fresh read before any FIT verdict for the flat 12+1-VM/DC roster (item 2, calculator currently lacks the 3 utility-node flags -- extend or hand-total first). Feeds BOTH axes: D-143 needs it for the rebuild sizing, container-elim needs it for the "~176 GiB freed" claim to stop being directional-only.
2. [unchanged][D-143] NetBox apex re-carve: mint the B2 role Cloud -- VR1 rebuild owning 10.13.0.0/16; re-carve VR1 prefixes/VIPs/ranges octet-preserving (design-decisions.md:8165-8166, D-143 owed-execution item 1). Pure IPAM, topology- agnostic -- runs whether the topology is flat or nested.
3. [unchanged][D-143] scripts/lib-net.sh: keep flat defaults at 10.12 (vr0-dc0 no- op preserved); give vr1-dc0/vr1-dc1 full 10.13 literal blocks; update the now-false :124-134 inherits-VR0 comment (owed-execution item 2, F13).
4. [both] D-124 transit routes re-point + the DC-side static IP shifts 12->13 (owed-execution item 4). Under container-elim the ADDRESS this step touches changes HOST from vvr1-dcN's rack-transit IP to the new vr1-dcN-client VM's transit leg -- same octet-preserving math (D-143), different bearer (container-elim). Tag [both] because neither axis is separable at this one line item; call it out explicitly in the change-set so a reviewer does not assume it is pure D-143.

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

1. [unchanged] vcloud host prep (Phase 0 runbook) -- OpenTofu reaches vcloud libvirt, host-level prerequisites. Not container-layer; runs regardless of target topology.
2. [unchanged] Office1 headend standup (Phase 1 runbook), IF not already up from the dc0 checkpoint -- voffice1 remains the MAAS region host (D-132 addendum unaffected) and remains the D-128 Plane-2 execution host for whatever STILL needs a remote dial (mesh-link tofu, if any; NOT the DC substrate apply any more -- see B.4).

B.3 -- the new cross-DC isolation control (container-elim design item, gate-confirmed)

1. [new][container-elim] Build + install the vcloud-level host isolation control (admin report Section 5 handling (a), CONFIRMED at the Phase-0 gate, Section 7a): an nftables/isolation artifact asserting no inter-plane/inter-DC forwarding on vcloud itself, with a mechanical --check gate and its own new SEC-NNN ledger row (SEC-010's pattern, one layer up). MUST run BEFORE step B.4 -- the moment two DCs' plane bridges share vcloud's one kernel (the instant the flat apply creates the second DC's planes) is the moment the gap becomes live; the control has to already exist, not be retrofitted after the fact. This is a genuinely NEW artifact with no direct precursor in today's chain (SEC-010 was interface-scoped to the transit leg, a different boundary -- see admin report Section 1.4/Section 5 for why it does not already cover this). This is ONE of TWO SEC-010-successor controls, not the whole story -- the re-authored transit-leg FORWARD-drop itself is a SEPARATE, still-OPEN item, sequenced at B.5 step 17; do not read this step as closing SEC-010's full scope.

B.4 -- the (formerly) outer + bootstrap-gate + inner sequence, COLLAPSED

1. [reorders][container-elim] ONE FLAT tofu root, ONE apply cycle, run FROM VCLOUD directly on qemu:///system (no qemu+ssh dial exists any more -- the opentofu/vr1-dcN-substrate/ roots are RETIRED as separate roots; their module bodies -- planes x6, WAN, edge, 12 node VMs -- are UNCHANGED HCL, re-homed into the flat root/provider per pass0-w1-substrate-map.md Section 2.3's own observation that none of those modules hardcode "vvr1-dcN"). Per DC, this single apply creates:
   • [unchanged] mesh triangle legs, uplink NAT /24 (D-125 addressing/IPAM identity untouched, design-decisions.md:4830-4844) -- these already exist at vcloud level and are UNCHANGED by the flattening.
   • [reorders] the per-DC storage pool -- was two separate pools (outer holding only the containment VM's disk, inner holding everything else); COLLAPSES to one pool per DC on vcloud's own filesystem, no nested-disk-inside-a-disk indirection (pass0-w1-substrate-map.md Section 4).
   • [reorders] the six planes (dc-planes x6) -- re-homed from the inner root's provider to the flat root's qemu:///system; same module, same CIDRs/MTU/family (D-139 unaffected).
   • [reorders] the DC edge (opnsense-edge) -- re-homed; its WAN attachment changes from vr1_dcN_wan (wan-bridge onto the containment VM's own bridge) to attaching DIRECTLY to the outer vr1_dcN_uplink NAT (Model A shape, D-122 AMENDMENT :4844-4846's intent preserved, mechanism reverted).
   • [reorders] the 12 role/utility node VMs (node-vm x9 + juju-01 + maas-01 + tailscale-01) -- re-homed to the flat root's provider; MAC-pinning must be RE-MEASURED post-move (admin report/W0.1 risk #3 -- treat every MAC as unmeasured until re-pinned, hard rule 2).
   • [new] the per-DC vr1-dcN-client VM (Option 1's small non-hypervisor VM, ~4/8192/80, metal-admin + transit legs, Model-A-headend shape per admin report Section 3 item 2) -- genuinely new module instance, no D-143 content, pure container-elim.
2. [vanishes][container-elim] The containment VM itself (module "vvr1_dc0" / "vvr1_dc1", opentofu/main.tf:410-519,537-623) and its sizing/rack-addressing/pubkey vars (variables.tf:137-156,175-194,196-244,105-114,158-168) -- deleted from the module set entirely, not re-homed.
3. [vanishes][container-elim] The two opentofu/vr1-dcN-substrate/ roots AS SEPARATE ROOTS/STATES -- their bodies survive (step 8), the ROOT BOUNDARY does not.
4. [vanishes][container-elim] The qemu+ssh provider dial + connection vars (vvr1_dcN_transit_ip/_ssh_user/_ssh_keyfile) and D-126 per-env SSH keys -- already revoked in Part A step 3; here confirmed as having NO successor to re-mint.
5. [vanishes][container-elim] modules/wan-bridge calls (vr1_dcN_wan) and the br-vr1-dcN-wan netplan bridge -- no containment-VM bridge to attach to; folded into step 8's direct-NAT edge attachment.
6. [vanishes][container-elim] The BOOTSTRAP GATE's node-host duty -- site-headend-install.sh --host-nodes (nested libvirtd, inner pool dir + AppArmor grant, kvm nested=1, OPNsense base-image staging) -- confirmed dead code for VR1 once step 8 removes the nested hypervisor it exists to prepare (scripts/site-headend-install.sh:82-85,122-123 gates --host-nodes on --role rack explicitly; with no rack-as-node-host, this flag is simply never passed again).

B.5 -- the bootstrap gate's SURVIVING duty, re-targeted (OPEN placement)

1. [reorders][container-elim] site-headend-install.sh --role rack WITHOUT --host-nodes -- MAAS rack enrollment against the Office1 region (--region-url .../MAAS --enroll-secret-file ...) -- still real work (site-headend-install.sh:14-21), just stripped of the node-host half. Runs AFTER step 8 creates its target host, not before an inner apply that no longer exists. Placement is OPEN (admin report Section 6 item 3, gate outcome Section 7a "not resolved at this gate"): the leading candidate is the new vr1-dcN-client VM (same host that already carries D-138's client role and the SEC-026/028/029 residencies -- co-locating the rack role there is the lowest-delta reading of Option 1), but vr1-dcN-maas-01 (the region-adjacent utility VM) and a ruled retirement are both still live options per the gate outcome. This sequencing document does not pick one -- it places a slot here and flags it for Phase 2 (tools review, which owns site-headend-install.sh changes) to close.
2. [reorders][container-elim] D-131 node-DNS forwarder + rack-legs persistence (scripts/dc-rack-net.sh install <site>, dc-rack-net.sh:1-19) -- same OPEN placement question as step 14 (today it "RUNS ON THE DC RACK HOST", admin report Section 2 row 7); sequenced immediately after step 14 since both target the same host class. Losing this silently reintroduces the SERVFAIL bug the forwarder exists to prevent (admin report Section 2 row 7) -- it must land SOMEWHERE, not be dropped by omission.
3. [reorders][container-elim] Artifact-service placement (.4, dc-mirror.sh comment "runs on the rack host") -- same OPEN question, same slot; dc0's debmirror / dc1's apt-caching-proxy content is unaffected, only WHICH flat VM serves it.
4. [new][container-elim] -- OPEN, distinct from B.3. The re-authored SEC-010 TRANSIT-LEG FORWARD-drop. B.3 builds the NEW cross-DC vcloud-level control; this is a SEPARATE control -- the admin report is explicit that the two are not the same thing ("DISTINCT from rebuilding SEC-010's transit drop on the client VM (row 6) -- two controls," Section 5) and that WHICH ends receive the re-authored drop is itself unresolved (Section 6 item 5: "which ends get the re-authored FORWARD-drop -- client VM + voffice1?"). Today SEC-010 is scoped to the transit NIC on vvr1-dcN (and its voffice1-side peer) precisely because the qemu+ssh dial and the inner-planes-bridging made that interface the isolation boundary; B.4 step 11 removes the qemu+ssh dial entirely, so the boundary's PURPOSE partly dissolves, but any surviving operator ssh -J access / Office1-originated management flow (B.5 step 14's MAAS enrollment traffic, for one) still rides SOME leg that needs a FORWARD-drop decision. Sequenced here, alongside steps 14-16, because it shares their "which flat host" open question -- NOT resolved by this document; a reader must not conclude B.3 already covers it.

B.6 -- MAAS enlist / commission / carve (Phase 3, largely unchanged mechanics)

1. [unchanged]* MAAS discovers the node VMs via the vcloud-registered virsh vm-host -> Office1 region (the per-machine virsh power mechanism, D-123 AMENDMENT 2026-07-20, design-decisions.md -- the pod mechanism was already refuted and replaced by per-machine virsh BEFORE this pass; that mechanism itself does not change under flattening). * = the VALUE changes, the STEP does not: scripts/lib-hosts.sh's VIRSH_POWER_ADDRESS* re-derives from "dial the containment VM's libvirtd" to "dial vcloud's own libvirtd directly" (admin report Section 2 row 4) -- a measured-value change, not a new step or a reordering. maas-node-power.sh itself needs NO code change (power address is an argument, topology-agnostic, row 5) -- every invocation SITE (runbook examples, scripts) needs the new address.
2. [unchanged] Commission each discovered node (Phase 3 Step 3); tag each node, nodes stay Ready (Step 4); Pattern-A interface carve via scripts/dc-node-carve.sh (Step 5) -- mechanically identical against flat-topology node VMs; simpler in that there is only ONE virsh hop to reason about (no "which host can even see this domain" confusion the containment layer introduced, teardown-rollback.md :868-878).
3. [unchanged] PXE/boot-fabric verify (Step 6); per-DC artifact-source + time- authority verify (Step 7, target host is whatever step 16 lands on); topology consistency check (Step 8).

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

1. [unchanged] Juju controller bootstrap on a tagged machine, preflight.sh gate, model/spaces setup, DC egress gate, juju deploy bundle.yaml + overlays, dry-run first, mid-deploy watch (Phase 4 Steps 1-4b) -- runs from the vr1-dcN-client VM (D-138's execution host, "never the vcloud jumphost" doctrine intact per admin report Section 3 item 6) instead of vvr1-dcN. Same commands, renamed host.
2. [unchanged] SEC-026/028/029 credentials are (re-)MINTED here, not migrated -- Part A already revoked the old copies, so this is a clean mint onto the new client VM, the same "OPEN, rotate at v1 close or on rebuild" posture the ledger already carries.
3. [unchanged] 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).
4. [reorders][both] VERIFY-LIVE gates (Step 12): Ceph-over-v6 bind check (unchanged mechanically, D-143 gives it new literal addresses); geneve-over-v6 encap-family assert (scripts/geneve-encap-assert.sh, unaffected by container-elim per admin report Section 1.4 -- same MTU budget, no extra hop removed or added). Add here the container-elim's OWN new live check: the B.3 cross-DC isolation control's --check gate, re-run now that BOTH DCs' planes are actually co-resident on vcloud -- this is the first point in the sequence where the control's claim becomes testable against real traffic.

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

1. [new][container-elim] NetBox DCIM: register the new vr1-dcN-client VM + the flat node roster device records (mirrors Part A step 9's decommission, other direction).
2. [new, deferred] Enter the container-elim [ARCH] decision record (D-123 amendment vs. new D-number, per SCOPE Section 7 -- Phase 4 frames it, the operator rules it, GA-R5). Not an executable step; flagged here so the sequence does not read as "done" without it. The redeploy should not be called closed while this ruling is still owed.

PART C -- D-143 vs container-elim, pulled apart explicitly

Reading: the two axes are NOT cleanly separable at every line (B.1.4, B.6, B.7, A.3 are genuinely [both]), but the STRUCTURAL steps (root collapse, module re-homing, client VM, isolation control, rack-role placement) are container-elim-only, and the ADDRESSING steps (NetBox apex, lib-net.sh, overlay literals) are D-143-only. A change-set reviewer can use this table to confirm a given diff hunk belongs to the axis it claims.

PART D -- where the pre-Roosevelt bare-metal hardware specs plug in

Per the operator's own framing (SCOPE Section 1, "a good test of the module deployment project... during the teardown and redeploy") and D-138's own history (the vr1-dcN-client VM is explicitly "the D-138 Roosevelt bastion analog, rehearsed early," admin report Section 4): the hardware specs, once provided, feed B.1.1's capacity math and B.4's module bodies, not a new sequence. Concretely:

• B.4's flat-apply module set (planes x6, edge, node-vm roster, client VM) is the SAME module composition intended to transfer -- the hardware specs let Phase 4's module design re-derive sizing for bare metal instead of vcloud-hosted VMs, WITHOUT changing which modules exist or their call order (only their provider target and concrete sizing numbers change, same class of change as B.4 itself already is relative to today's inner root).
• Nesting-depth honesty, not overclaimed: flat-Option-1 is vcloud (libvirt) -> node VM -> nova KVM guest = depth 2 (VR0-proven, admin report Section 4). Roosevelt bare metal removes the vcloud hypervisor layer entirely -- bare host -> KVM guest = depth
  1. The flattening is a rehearsal of the MODULE SHAPE and the single-apply/no-bootstrap- gate WORKFLOW, not of the exact nesting depth; do not let a future session assume parity it does not have.
• B.5's OPEN rack-role placement is the one item that should be RE-DECIDED, not carried forward blindly, once real hardware specs exist -- a bare-metal Roosevelt 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.
• Not required to unblock THIS sequencing document (SCOPE Section 8: "hardware-agnostic"; hardware specs are noted here per the worker prompt's explicit ask, not treated as a blocking input).

PART E -- top sequencing risks (this dimension only)

1. B.3 (isolation control) must precede B.4's second-DC apply, not follow it -- the gap is live the instant both DCs' planes exist on one kernel; sequencing it after would leave a real window of unmitigated cross-DC adjacency during the build itself, not just in the final state.
2. B.5's OPEN placement (rack-role/D-131/artifact-service) is a genuine sequencing dependency, not a footnote -- steps 14-16, 17 (MAAS enlist target), and 20 (juju execution host) all key off "which flat VM plays this role," and it is currently UNRESOLVED. A session that runs this sequence without closing it first will improvise the answer live, which is exactly the class of error CLAUDE.md hard rule 4 exists to prevent.
3. MAC re-pinning (B.4 step 8) is understated if treated as cosmetic -- 24 node MACs + 2 edge MACs move provider; pass0-w1-substrate-map.md risk #3 flags this as a likely force-replace, not a metadata update, with real MAAS re-enlistment cost. Sequence a re-measurement pass explicitly after B.4, before B.6 trusts any MAC.
4. A.3-4 (R7 revocation + MAAS record release) run too late is a real gap, not a formality -- if the substrate destroy (A.5-7) runs before revocation, the credential-bearing hosts are gone and "revoke" degrades to "assume it's moot," which is exactly the conditional-supersession risk open-items-review-20260809.md:396-399 names explicitly.
5. The flat root's single-state blast radius (admin report/W0.1 risk #2, ~38 domains x 2 DCs under one state/provider) changes the RISK PROFILE of every apply in B.4 even though it removes complexity elsewhere -- Phase 4's module design should weigh one-state-per-DC vs. one-state-total before B.4 is treated as a single monolithic step in the executable runbook (this document leaves that split as a Phase-4 decision, not pre-empting it).
6. This document does not verify the MTU/geneve claim it inherits ("analytically unchanged," admin report Section 1.4/8 item 3) -- B.7 step 23 carries the OWED live assert forward explicitly so it is not silently dropped.

Sources read this session (path:line, for a future session to re-verify)

• docs/audit/container-elim-pass/SCOPE-AND-EXECUTION-PLAN.md (full)
• docs/audit/container-elim-pass/pass0-admin-report.md (full)
• docs/audit/container-elim-pass/pass0-w1-substrate-map.md (full)
• runbooks/dc-dc-teardown-rollback.md:600-998 (Steps 1-5, Path A/B, mesh-link note)
• docs/design-decisions.md:4830-4965 (D-122 amendments, D-123 body + both amendments)
• docs/design-decisions.md:8083-8182 (D-143 full ruling + owed-execution list)
• docs/security-ledger.md:79,81,82 (SEC-026, SEC-028, SEC-029)
• docs/audit/open-items-review-20260809.md:60-100,380-435 (R1, R7, R15, R16)
• docs/audit/roosevelt-held-decisions-review-20260809.md:70-95 (D-137/R7 pull-forward)
• scripts/site-headend-install.sh:1-125 (--role, --host-nodes gating, full flag set)
• scripts/dc-node-carve.sh:1-13, scripts/dc-rack-net.sh:1-19 (headers)
• docs/tool-index.md:96-134 (tested-artifact lookups used for every script cited above)
• runbooks/dc-dc-phase2-tofu-dc-substrate.md, phase3-maas-enlist-deploy.md, phase4-juju-bundle-per-dc.md (section headers, for today's step names/numbers)

No inferred values used; every address, path, and status cited above resolves to the line given. Items marked OPEN are stated as open, not resolved by inference.