# 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)

5. **[unchanged]** vcloud host prep (Phase 0 runbook) -- OpenTofu reaches vcloud libvirt,
   host-level prerequisites. Not container-layer; runs regardless of target topology.
6. **[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)

7. **[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

8. **[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.
9. **[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.
10. **[vanishes][container-elim]** The two `opentofu/vr1-dcN-substrate/` roots AS
    SEPARATE ROOTS/STATES -- their bodies survive (step 8), the ROOT BOUNDARY does not.
11. **[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.
12. **[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.
13. **[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)

14. **[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.
15. **[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.
16. **[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.
17. **[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)

18. **[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.
19. **[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`).
20. **[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)

21. **[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.
22. **[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.
23. **[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).
24. **[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)

25. **[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).
26. **[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

| Redeploy step # | D-143 content (10.12->10.13 address shift) | container-elim content (flatten the topology) |
|---|---|---|
| B.1.1 (capacity) | sizing feeds the rebuild | sizing also proves/disproves the "~176 GiB freed" claim |
| B.1.2 (NetBox apex) | ENTIRE content -- new B2 role, re-carve | none |
| B.1.3 (lib-net.sh) | ENTIRE content -- 10.13 literal blocks | none |
| B.1.4 (transit/statics) | the octet-preserving math | the BEARER host changes (rack -> client VM) |
| B.3 (isolation control) | none | ENTIRE content -- new artifact, new SEC row |
| B.4 (flat apply) | node/plane addresses land in 10.13 (via lib-net.sh) | ENTIRE structural content -- root collapse, module re-homing, client VM |
| B.5 (rack-role slot) | none | ENTIRE content -- placement question, MAAS enrollment retarget |
| B.6 (MAAS enlist) | none (addresses are downstream of lib-net.sh, not re-derived here) | the power-address VALUE changes (row 17) |
| B.7 (juju/bundle) | overlay literals carry 10.13 addresses | execution HOST identity changes (rack -> client VM) |
| Part A.3 (R7 revocation) | owed BY the re-IP ruling (D-143 item 5) | the credentials being revoked are container-elim-eliminated host classes |

**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.
