# Pass 1 -- W1.2: deployment-workflow doc + stage/gate structure vs the layered-module framing

**Worker:** W1.2 (Phase 1, container-layer-elimination pass). **Date:** 2026-08-09.
**Scope:** `docs/dc-dc-deployment-workflow.md` (stage identity, gates, tooling gap register) and
the G-series gate register in `docs/CURRENT-STATE.md` section 6, read against the CONFIRMED
Phase-0 outcome (`pass0-admin-report.md`): **Option 1** (flat node VMs on vcloud libvirt +
per-DC non-hypervisor `vr1-dcN-client` VM), cross-DC isolation handling **(a)** (new vcloud-level
host-isolation control, new SEC-NNN row, mechanical `--check` gate), MAAS region unchanged
(`vr1-dcN-maas-01`). READ-ONLY. No inferred values -- every claim below cites path:line from
`docs/dc-dc-deployment-workflow.md`, `docs/CURRENT-STATE.md`, `docs/design-decisions.md`, or
`pass0-admin-report.md`.

---

## 0. A framing correction before the analysis (measured, not inferred)

The task brief's example -- "does the Stage-2 substrate / bootstrap-gate stage collapse" --
names the wrong stage number. **Measured against the workflow doc:**

- **Stage 2** (`docs/dc-dc-deployment-workflow.md:60-146`) is the **Office1 SITE standup**
  (D-114): it builds `voffice1`, a *different* containment VM (MAAS-region + LXD 5.21-track +
  MAAS-composed service VMs). Pass0 confirmed `voffice1` is explicitly **NOT container-layer**
  (`pass0-admin-report.md:19,60`, "Office1 arm ... NOT container-layer"). Container-elim does
  **not** touch Stage 2's shape. This distinction matters for module design later in this doc:
  the project will carry TWO different "containment VM" patterns going forward -- one retired
  (Model B `vvr1-dcN`), one kept (`voffice1`'s D-114 LXD-composition model) -- and a future
  session must not conflate them.
- **Stage 3** (`docs/dc-dc-deployment-workflow.md:149-197`) is the actual **bootstrap-gate /
  two-root Model-B DC-substrate stage** -- its own Build line says it verbatim: *"D-123 **Model
  B** (TWO OpenTofu roots + a bootstrap gate between)"* (`:154`). **This is the stage
  container-elim restructures.** All findings below key off Stage 3, not Stage 2.

---

## 1. Stage-by-stage change table

| Stage / Gate | Container-layer dependency (measured) | Option-1 change | Maps to (module layer) |
|---|---|---|---|
| **Stage 0** (decision ratification) | None | None | N/A (history) |
| **Stage 1** (`:36-57`, vcloud host prep) | None directly, but its 2026-07-10 as-built note (`:47-56`) shows the **six DC planes were originally built HERE, at vcloud level**, before D-123 later relocated them into the per-DC inner root (`opentofu/main.tf:22-33`, quoted at `pass0-w4-targets.md:79-80`: *"the 6 vr1-dc0 planes MOVED to the INNER root ... under Model B"*). Nested-KVM enablement here is a **shared prerequisite for two different purposes**: (i) `voffice1`'s LXD nesting (Stage 2, KEPT) and (ii) the now-eliminated per-DC containment VM's inner libvirtd (Stage 3, GONE). | Gate content is UNCHANGED (nested-KVM still needed for Stage 2's voffice1; pool/MTU/mesh gates untouched, D-100/D-101 own them regardless). **What changes is Stage 1's RELATIONSHIP to Stage 3**: under Option 1 the six per-DC planes land back at vcloud level via `modules/dc-planes`, the SAME level and SAME module family Stage 1 already establishes for the mesh/pools -- Stage 3 RECONVERGES onto Stage 1's own execution shape (single vcloud-local `qemu:///system` root) rather than diverging into it via D-123's later two-root split. | IaC module -- `vcloud-host-prep` (host-wide, invoked ONCE) |
| **Stage 2** (`:60-146`, Office1/voffice1) | **NOT a consumer** (pass0-confirmed; Section 0 above) | **NONE.** D-114's containment-VM pattern is architecturally distinct from D-123's Model B and is out of this pass's scope. Flag this explicitly in the Phase-4 change-set so it is not swept in by name-similarity ("containment VM" appears in both stages' prose). | Unaffected -- stays its own IaC module (`office1-site`) + procedure module (MAAS/LXD compose steps) |
| **Stage 3** (`:149-197`, per-DC OpenTofu substrate) -- **THE STAGE MOST RESTRUCTURED** | **Total.** Build line = Model B outer+bootstrap+inner (`:154`); Gate line = `vvr1-dc0` sizing/nested-KVM + "inner node VMs boot at depth-4 (D-114/D-123 boot gate)" (`:155`); Owns D-103-as-amended-by-D-123, D-122, D-123, D-124, D-125 (`:156`); Reuse-vs-new explicitly calls it NEW with "no OpenTofu/multi-rack precedent" BECAUSE of the two-root/bootstrap-gate mechanics (`:157`) | **Collapses to ONE tofu root, ONE apply, ONE execution host.** Per `pass0-w4-targets.md:69-76,97-111`: node VMs, planes, edge, and the new client VM all target vcloud's own `qemu:///system` DIRECTLY -- no `qemu+ssh`-from-Office1 dial for the substrate build at all. This means Stage 3's substrate creation shifts from a **two-plane execution stage** (outer root = Plane 1/vcloud; inner root + bootstrap gate = Plane 2/voffice1 via qemu+ssh, D-128 `docs/design-decisions.md:5354-5358`) to a **Plane-1-ONLY stage** -- the entire DC substrate is built from vcloud with local virsh/tofu, matching Stage 1's own execution shape. The "OUTER -> BOOTSTRAP GATE -> INNER" apply-ordering contract (`opentofu/main.tf:301-331`, cited `pass0-w4-targets.md:130-131`) disappears outright: no bootstrap gate script (`site-headend-install.sh --host-nodes` node-host mode retires, `pass0-admin-report.md:87`), no cross-root state, no D-126 per-env qemu+ssh key auth for the substrate dial. **Nesting depth 4 -> 2** (`pass0-admin-report.md` Section 4, `pass0-w4-targets.md:158`), so the D-114/D-123 "depth-4 boot gate" concept becomes a depth-2 boot gate -- a materially lower-risk check, closer to Stage 2's already-proven depth-3 (vcloud->voffice1->LXD) shape than to anything Stage 3 has attempted before. Stage 3's own "Reuse vs new" framing (`:157`, "NEW, no precedent") should be revisited in Phase 4: under Option 1 the stage is now MORE reusable (closer to Stage-1's flat-vcloud-libvirt shape) not less. **Owns line changes**: D-123 as currently phrased ("Model B site-down + two-root") is VOID under Option 1 and needs its Phase-4-framed amendment/new-D (per `SCOPE-AND-EXECUTION-PLAN.md:197-200`); D-125's "bridge-in" realization is retired (edge WAN -> direct NAT, `pass0-admin-report.md:84,169`), so D-125's Owns-line text needs updating alongside whatever D-number the container-elim ruling becomes. D-124's rack-transit addressing survives only for the CLIENT VM's transit leg, not for a rack-sizing purpose (D-124's own Stage-3 entry already flags its sizing clause VOID under Model B, `:180`; under Option 1 it stays void, now for a different reason -- no rack to size at all, only the small client VM). | IaC module -- `dc-substrate-flat` (planes + edge + 12 node VMs + client VM, ONE apply, invoked per DC) -- see Section 3 |
| **Stage 4** (`:200-212`, MAAS enlist/commission) | Indirect, via the rack-hosted services. `dc-rack-net.sh` (D-131 forwarder) and the per-DC artifact mirror/proxy (`.4`) run **on the containment VM today** (`pass0-admin-report.md` row 6-7, table). G17's dc0 check literal (`curl -fsS http://10.12.8.4/...`) targets that same host. | **Placement, not mechanism, changes -- and it is UNRESOLVED at Phase 0** (`pass0-admin-report.md` Section 6 item 3: "client VM / maas-01 / retire-with-evidence", carried into Phase 1 as an open item). Whichever placement is ruled, Stage 4's Gate-line prose (`:206`, "per-DC artifact source answering on its own address") and G17's check literal both need the new address substituted -- **this is a genuine intersection with D-143's 10.12->10.13 re-IP**: G17 will need BOTH edits (new address family per D-143, new HOST per container-elim) in the same pass, but they are two distinguishable causes per `SCOPE-AND-EXECUTION-PLAN.md:194-196`'s own instruction, and this doc should record them as two line-items even though they land in one edit. Stage 4's own commission/deploy mechanics (`:206-209`) are otherwise UNCHANGED -- node VMs still PXE/commission the same way regardless of hypervisor nesting depth. | Procedure module -- `maas-enlist-commission` (per-DC); its config INPUT (mirror/forwarder host) changes, its STEPS do not |
| **Stage 5** (`:215-230`, Juju + bundle) | **Structural, via D-138.** D-138 (`docs/design-decisions.md:7118-7180`, RULED 2026-07-30) already moved the cloud-facing client (Juju CLI, `openstack` CLI) INTO the DC because `voffice1` has no L3 path to any DC node plane and SEC-010/D-052/D-100 forbid opening one. The concrete host D-138 names is `vvr1-dc0` (the containment VM) -- it is currently the D-138 execution host by NECESSITY, not by a separate design choice. | **The D-138 PRINCIPLE is preserved, its concrete host changes.** Option 1's `vr1-dcN-client` VM is explicitly built to BE the D-138 host (`pass0-admin-report.md:163-169`, "carrying: the D-138 client role"; `pass0-w4-targets.md:97-111` confirms the client VM occupies exactly D-138's required shape -- metal-admin + transit legs, an L3 presence). **No Stage-5 gate content changes** -- `preflight.sh` PASS, post-deploy `cloud-assert.sh --capture`, controller backup, geneve-over-v6/Ceph-over-v6 verification (`:221`) are all unaffected by WHICH VM the Juju client runs from. What DOES change: every literal address/host-alias in Stage-5 runbooks and CURRENT-STATE's version-pins table that names the containment VM's transit IP (e.g. `docs/CURRENT-STATE.md:7829`, "openstackclient ... INSTALLED ON THE dc0 RACK (172.31.0.2)" -- that IP is `vvr1-dc0`'s transit address) must be re-pointed to the client VM's new address once it exists. **D-140 constrains this stage's module mapping directly** (Section 4 below) -- the Juju layer itself stays a PROCEDURE module (scripted, bundle-based) for this redeploy by an ALREADY-RULED pin (`docs/design-decisions.md:7781-7787`), not a design choice this pass is free to make. | Procedure module -- `juju-bundle-deploy` (per-DC); execution-host param changes (vvr1-dcN client VM), D-140 keeps it out of IaC scope for now |
| **Stage 6** (`:233-244`, DR/failover) | **None found.** Ceph replication, radosgw multisite, rbd-mirror all run on deployed OpenStack units, not on the containment layer. | None. | Procedure module -- `dr-failover-drill` (unaffected) |
| **Stage 7** (`:248-259`, Designate/COS/Magnum) | **None found.** | None. | Procedure module -- `designate-cos-magnum` (unaffected) |
| **Cross-cutting: branch-per-stage/merge-at-close discipline** (`:424-436`) | Indirect -- Stage 3's branch would carry the container-elim change-set as part of its definition-of-done | Stage 3's branch (whatever it is named for the 10.13 rebuild) is where the module collapse actually lands; its close-out sweep must also reconcile `.claude/skills/openstack-cloud-ops/` for the new invariant (per `:430-433`'s standing rule) | N/A -- process discipline, not a module |
| **Teardown runbook** (`dc-dc-teardown-rollback.md`, gap #19a, `:958-975`) | **Direct** (pass0 row 9: "`vvr1-dcN` as the teardown unit; D-122's 'site-down = one `virsh destroy`'") | Re-authored around a scripted group-destroy of the flat `vr1-dcN-*` domain set OR, better, a **module-scoped `tofu destroy -target=module.vr1_dc0`** now that the whole DC is ONE module call under the single flat root -- this would PARTIALLY re-earn the lost D-123 one-command convenience via tofu itself rather than virsh scripting (flagged for Phase 4, pass0 Section 6 item 7 already names this as owed design work) | IaC-module-scoped teardown, one call per DC module |

---

## 2. G-series gate register: which are keyed to the container layer

Read against `docs/CURRENT-STATE.md` section 6 (`:7786-7813`) in full.

- **G9** (DC0 outer apply, `:7803`) -- keyed to the two-stage apply by its own SEC dependency
  note: *"SEC-010's transit FORWARD-drop is applied+verified at deploy step B via
  `site-headend-install.sh --host-nodes --check` on vvr1-dc0 (gate G10)"*. This gate is CLOSED
  (historical, dc0's checkpoint build) -- it does not reopen, but it is the **template** the
  next DC-substrate apply gate (whatever supersedes it for the 10.13 rebuild) must NOT copy
  verbatim: under Option 1 there is no outer/inner split for it to key off, so a redrawn gate
  is a SINGLE apply-and-verify, not a two-step G9+G10 pair.
- **G10** (`:7804`, deploy steps B-E) -- the sub-items most exposed:
  - *"SEC-010 `--host-nodes --check` on vvr1-dc0"* -- this exact check RETIRES with
    `site-headend-install.sh`'s node-host mode (`pass0-admin-report.md:87`). Its REPLACEMENT is
    the new cross-DC host-isolation control's own `--check` (the confirmed Phase-0 gate handling
    (a), `pass0-admin-report.md:288-291`) -- but that control is scoped to the WHOLE vcloud host
    (both DCs' co-residency), not to a single DC's apply step, so it likely does NOT slot into a
    per-DC G10-style gate at all; it is closer in shape to a Stage-1-level, apply-once gate (see
    Section 4). This is a genuine **stage-home question for Phase 1/2 design**, not resolved by
    this worker's dimension alone -- flagged forward.
  - *"depth-4 nested boot"* -- becomes depth-2 (Section 1, Stage 3 row).
  - *"D-125 foreign-MAC egress test"* -- the MECHANISM changes (no bridge-in to test the
    isolation of), but an analogous direct-NAT egress-isolation assertion is still owed; do not
    read this as "the egress gate goes away", only that what it tests changes shape.
  - *"MAAS reachability + `TF_VAR_maas_api_key`"* and *"netem placeholder"* -- both UNAFFECTED
    (Plane-2/mesh concerns, not containment-layer concerns).
- **G12** (`:7806`, vr1-dc1 build) -- CLOSED/historical, but it is the **fullest worked example**
  of what a per-DC Stage-3 gate sequence looks like today (outer apply -> Step B SEC-010 check
  -> inner apply -> rack standup -> commissioning). Its structure is the thing that collapses;
  future sessions writing the reshaped gate should read G12's own text as "the shape being
  replaced," not as a template to repeat.
- **G17** (`:7811`, per-DC artifact source reachable from a node) -- **OPEN today**, and its
  check literals directly name the containment-VM-hosted mirror address (`10.12.8.4` for dc0).
  As covered in Section 1's Stage-4 row: this gate's eventual close needs BOTH the D-143
  address-family edit and the container-elim placement edit, kept distinguishable per the
  SCOPE plan's instruction.
- **G18** (`:7813`, lb-mgmt IPAM apex) -- **no container-layer dependency found**; Octavia's
  charm-owned lb-mgmt network is unrelated to the substrate hypervisor topology. Named here only
  to confirm it was checked and correctly excluded (a "manufactured contradiction" risk this
  repo's own instrument-currency record warns about -- do not let G18 get swept into the
  container-elim change-set by proximity in the same table).
- **G1-G8, G11, G13, G15, G16** -- read; **no container-layer dependency found** in any of them
  (audit/ratification gates, D-068/D-071 rulings, office1 edge state-surgery gates). Confirmed
  by direct read of `:7795-7802,7805,7807,7809-7810`, not assumed from gate NAME.
- **G14** (`:7808`, open SEC rows) -- indirect only: container-elim MIGRATES several credential
  residencies (SEC-026/-028/-029, `vm-secret-locations` `rack` rows, per pass0 row 8) and ADDS
  at least one new SEC-NNN row for the cross-DC isolation control -- both are G14 COUNT-affecting
  events when they land, not gate-SHAPE changes. Flag for whoever next runs `ledger-scan.sh`
  after this pass's changes land, so the count is not read as unexplained drift (the project's
  own instrument-currency lesson #25 applies directly here).

**Net finding:** exactly **one G-series gate concept is directly restructured (G9/G10's DC-apply
sequence)**; **one is a placement-pending intersection with D-143 (G17)**; the rest are either
unaffected or affected only as a downstream credential-count/ledger consequence (G14). No gate
needs to be DELETED outright -- G9/G10's successor for the 10.13 rebuild is a simplified
redraw, not a removal, since a substrate apply + SEC verification + boot proof + egress test are
all still real checks, just fewer steps and one execution host instead of two.

---

## 3. Tooling gap register -- what closes, reshapes, or is added

Read against `docs/dc-dc-deployment-workflow.md:447-1354` in full.

- **Gap #2 (OpenTofu, `:499-578`)** -- RESHAPES. The still-open line *"`tofu plan`/`apply` has
  NOT been exercised for the Stage 3 DC substrate"* (`:537`) changes SCOPE under Option 1: the
  first real exercise of Stage-3 apply becomes a single flat-root apply, not an outer+bootstrap
  +inner sequence. The module inventory itself shrinks: `modules/wan-bridge` (D-125 bridge-in)
  is DELETED (pass0 row 3); the inner-root files (`opentofu/vr1-dc0-substrate/`,
  `vr1-dc1-substrate/`) RETIRE as separate roots, their module CALLS folding into the outer/flat
  root (pass0 row 2). `modules/maas-vm-host`'s target changes from `vvr1-dc0`'s inner virsh to
  vcloud's own virsh directly (`pass0-w4-targets.md:109-111`) -- this closes the DOCFIX-179
  deferral note this gap still carries (`:553-554`, "deliberately NOT `maas_vm_host_machine`")
  differently than originally anticipated, since there is no longer an inner virsh to register.
- **Gap #17 (per-site ISP uplink, `:857-933`)** -- STAYS CLOSED, but its "how it was actually
  closed" mechanism description (`:894-904`, the bridge-in shape: outer NAT + inner bridge onto
  `br-vr1-dcN-wan`) becomes HISTORICAL under Option 1's direct-NAT attachment
  (`pass0-w4-targets.md:88-93`, "exactly like Office1's edge does today ... Model A's item 8").
  Flag so a future reader does not rebuild the retired bridge-in mechanism by reading this gap's
  closing note as current practice; a doc-currency addendum is owed here at the point the
  container-elim ruling lands, not a reopening of the gap itself.
- **Gap #19b (`$DC` region-qualified namespace, `:976-1038`)** -- UNAFFECTED. D-119's
  region-qualified selectors (`vr1-dc0`/`vr1-dc1`) are an IPAM/naming-layer fix, orthogonal to
  hypervisor nesting depth.
- **Gap #20 (host->site reachability / `site-baseleg.sh`, `:1039-1109`)** -- **verdict likely
  still holds, but the reasoning chain it rests on shifts and should be RE-VERIFIED, not
  carried forward silently.** Today's "no leg required on vcloud" verdict (`:1075-1093`) rests on
  D-128: *"no vcloud-originated DC operation exists ... Plane 2 ... EXECUTES on `voffice1`"*.
  Under Option 1 the SUBSTRATE build itself now originates from vcloud directly via a local
  `qemu:///system` provider (Section 1, Stage 3 row) -- but that is Plane 1 (host-VM creation),
  the SAME category D-128 already assigns to vcloud today for the outer root, not a new
  vcloud-originated L3 dial into a DC's own MAAS/Juju/openstack layer (which stays Plane 2, via
  `voffice1`, or D-138's client VM). The verdict's PREMISE is therefore probably unchanged, but
  this gap's own text explicitly warns *"If a future change makes vcloud originate to a DC
  directly, this verdict expires and branch 1 applies"* (`:1092`) -- container-elim is exactly
  such a change to the SUBSTRATE layer, even if not to the Plane-2 boundary, so a fresh
  re-measurement (not an inference from today's text) is owed once the flat root is built. Named
  here as a Phase-2/3 tooling-review item, not resolved by this worker.
- **Gap #21 (per-DC Tailscale, `:1189-1310`)** -- **UNAFFECTED in shape.** The tailscale router
  VM (`vr1-dcN-tailscale-01`, utility `.7`) is already one of the 12 flat node-VM siblings inside
  today's inner root (pass0 table row 2's "12 node VMs") and folds into the flat root exactly
  like every other node VM -- same re-homing mechanism, no gap-content change. Confirmed
  explicitly so it is not mis-swept into the container-elim change-set by proximity (it is a
  D-129(iii) item, not a D-123/Model-B item).
- **Gap #22 (ceph-rbd-mirror HA, `:1310-1354`)** -- **NOT a consumer.** Confirmed by direct read;
  this is a D-108 application-layer HA question, unrelated to substrate nesting. Named to record
  it was checked, per this repo's "a clean negative still needs the check shown" discipline.
- **New gap to REGISTER (not yet in the doc):** the cross-DC adjacency control itself
  (`pass0-admin-report.md` Section 5, handling (a)) has **no register entry today** because it
  is a Phase-0-confirmed-but-not-yet-designed deliverable. It should land as a NEW numbered item
  in this register (next-free per the register's own numbering, distinct from the D-NNN/SEC-NNN
  numbering it also needs) once Phase 1/2 design work produces its concrete shape, so it is
  trackable the same way every other gap here is.

---

## 4. The current stage/gate flow re-expressed as layered modules (first sketch)

Per `SCOPE-AND-EXECUTION-PLAN.md:40-43`, "module" means BOTH IaC (OpenTofu) modules for the
substrate AND procedure/runbook modules for the orchestration layered on top. This sketch maps
today's Stage 1-7 flow onto that split, incorporating Option 1 and the (a) isolation control.

```
IaC-MODULE LAYER (OpenTofu, vcloud-executed, Plane 1 -- D-128)
  [1] vcloud-host-prep         (Stage 1)  -- ONCE.  pools, mesh triangle, MTU, nested-KVM base.
  [2] office1-site             (Stage 2)  -- ONCE.  voffice1 containment VM (D-114, UNCHANGED
                                              by this pass -- kept as its own IaC module, its
                                              LXD-compose half stays a procedure step inside it).
  [3] cross-dc-isolation       (NEW)      -- ONCE, vcloud-level. The Phase-0-confirmed (a)
                                              deliverable: nftables/isolation artifact +
                                              mechanical --check + new SEC-NNN row. STAGE-HOME
                                              OPEN (Section 2): candidate slots are (i) folded
                                              into [1] as a host-prep-time control, applied once
                                              and re-verified whenever a second DC lands, or
                                              (ii) its own micro-module invoked once, before the
                                              first per-DC substrate apply. Phase-1/2 design item,
                                              not resolved here.
  [4] dc-substrate-flat        (Stage 3)  -- PER DC (dc0, dc1, futureN). The collapsed module:
                                              6 planes + edge + 12 node VMs + client VM, ONE
                                              apply. Directly supersedes today's
                                              outer+bootstrap-gate+inner three-part sequence.
                                              Gate: single apply-and-verify (Section 2) --
                                              SEC check via [3], depth-2 boot, direct-NAT egress
                                              isolation test.

PROCEDURE-MODULE LAYER (scripted/runbook, mixed Plane 1/2/DC-local execution)
  [5] maas-enlist-commission   (Stage 4)  -- PER DC. Unaffected mechanically; artifact-mirror/
                                              rack-controller/D-131-forwarder PLACEMENT is an
                                              input this module now takes as a parameter (client
                                              VM vs maas-01 vs retire -- pass0 Section 6 item 3),
                                              not a hardcoded containment-VM address.
  [6] juju-bundle-deploy       (Stage 5)  -- PER DC. D-138's client role executes here, now on
                                              the [4]-created client VM instead of the retired
                                              containment VM. STAYS a procedure module, not an
                                              IaC module, by the ALREADY-RULED D-140 pin (Section
                                              1, Stage 5 row) -- this pass's module design must
                                              not silently fold Juju into [4].
  [7] dr-failover-drill        (Stage 6)  -- PER DC (or cross-DC pair). Unaffected.
  [8] designate-cos-magnum     (Stage 7)  -- PER DC. Unaffected.

TEARDOWN (mirrors the IaC layer, module-scoped)
  [T] tofu destroy -target=module.<dc>   -- PER DC, one call per [4] module instance -- the
                                             candidate re-earning of D-123's lost one-command
                                             site-down (Section 1, teardown row).
```

**Sequencing note for W4.3 (not this worker's dimension, flagged forward):** `[3]` cross-DC
isolation logically needs to exist and be verified BEFORE the second DC's `[4]` apply lands
(otherwise dc0-alone co-residency has nothing yet to leak into, but dc0+dc1 co-residency does) --
this is a real ordering constraint on the module-invocation sequence Phase 4 designs, not merely
a stage-numbering question.

---

## 5. Top risks for this dimension

1. **The (a) isolation control has no stage home yet** -- it is a confirmed Phase-0 DESIGN
   REQUIREMENT with no gate row, no stage slot, and no register entry (Section 3, "New gap to
   register"). If Phase 1/2 do not give it one explicitly, it risks being built ad hoc and
   under-gated relative to the SEC-010 pattern it is explicitly modeled on.
2. **G17's dual-cause edit (D-143 address + container-elim placement) is easy to under-scope**
   if a future session only remembers the address-family half; this doc names both causes
   explicitly so neither is dropped.
3. **D-140 is an easy module-design trap** -- the layered-module goal's own IaC-modules-for-
   substrate framing could tempt folding Stage 5 (Juju) into the IaC layer "while we're at it";
   D-140 already RULES that OUT for this redeploy (pinned to end-of-deployment review). Phase 4
   must treat Stage 5 as a procedure module, full stop, for the 10.13 rebuild.
4. **Stage 3's "Owns" D-number list is stale the moment Option 1 is ruled formally** (D-123,
   D-125 both need their Phase-4-framed amendment text); this doc's Section 1 table can serve as
   the input list for that edit but does not itself perform it (out of scope, GA-R5 territory).

---

## 6. Sources consulted (path:line, for the adversarial-check pass)

`docs/dc-dc-deployment-workflow.md` (full read, 1354 lines); `docs/CURRENT-STATE.md:7786-7835`
(section 6 gate register + section 7 version pins); `docs/design-decisions.md:7118-7180` (D-138
full text), `:7781-7787` (D-140 full text), `:8083-8143` (D-143 excerpt); `pass0-admin-report.md`
(full read); `pass0-w4-targets.md:1-220` (full read, targeted at execution-host/plane detail not
fully covered in the admin report's synthesis).
