# Pass 2 -- ADMINISTRATOR REPORT: tools review (container-layer elimination) **Author:** the Phase-2 administrator (multi-agent pass, `SCOPE-AND-EXECUTION-PLAN.md` Section 4). **Date:** 2026-08-09. **Inputs:** `pass2-w1-tofu-modules.md`, `pass2-w2-lib-hosts-net.md`, `pass2-w3-scripts.md`, `pass2-w4-module-decomposition.md` -- read in full, adversarially cross-checked against repo ground truth (checks logged in Section 1). Baseline consumed: `pass0-admin-report.md` incl. Section 7a (**Option 1 CONFIRMED**; **cross-DC handling (a) CONFIRMED**; MAAS region stays on `vr1-dcN-maas-01`) and `pass1-admin-report.md` (planning change-set; Section 7 open items 1-7 carried to this phase). READ-ONLY synthesis; no mutation; findings are LOGGED, not executed. All recommendations here are proposals for Phase 4 -> operator (GA-R5); "recommend," never "ruled." --- ## 1. Adversarial-check results (run against repo ground truth this session) 1. **THREE isolation concerns confirmed distinct, each real, each open -- Section 2 is the canonical separation.** (i) the cross-DC plane-bridge adjacency on vcloud's kernel (Phase-0 Section 5, handling (a) operator-confirmed); (ii) the SEC-010 transit-leg FORWARD-drop successor (pass1 check 3); (iii) **NEW this phase (W2.3 Sec 3): the MAAS power-key blast radius** -- verified REAL this session, evidence in Section 2.3. They are two network controls and one credential-scope control; no one artifact covers two of them; root-shape (B) mitigates NONE of them (check 3 below). 2. **W2.3's "rack controller already retired in practice" -- CONFIRMED, with one citation correction.** Spot-checked all three cites by direct read: - `docs/changelog-20260807-dc1-region-sequence.md:80-89`: dc1 DHCP cutover executed 2026-08-07 -- `primary_rack=qtw8pm` in `vr1-dc1-region`; verified `ss :67` on the region VM's `enp1s0` only; "vvr1-dc1 has NO `:67` on the node segment." CONFIRMED. - `docs/changelog-20260730-dc0-region-migration.md` Item 15 (~:532-549): dc0 DHCP handover table -- `pgrep -c dhcpd` on the rack = **0**, `ps -ef` on `hot-kid` = 2 dhcpd on the region VM; `primary_rack=c3aqh8` (= hot-kid in its own region). CONFIRMED, process-measured. - **Citation correction:** W2.3 cites `changelog-20260807-dc0-tailscale-provisioning.md :200,254` for "BOTH maas-01 VMs installed `region+rack`." Read directly: line 200 is the PLANNED init instruction and line 254 the EXECUTED `maas init region+rack ... --maas-url http://10.12.68.6:5240/MAAS --force` -- **both are dc1's `.6`**. No dc0 init transcript was found in the changelogs (grep `region+rack` across changelog-*). dc0's region+rack status rests on FUNCTIONAL evidence instead: `hot-kid` is a registered rack in `vr1-dc0-region` (`changelog-20260730:49` "racks=hot-kid"), is `primary_rack`, and measurably runs the segment's only dhcpd (rackd-managed in MAAS). Evidence grade: dc1 = transcript; dc0 = functional. The claim carries at both grades; the DIRECTION (retire the standalone rack) is unaffected. W2.3's own caveat stands: **a current-day live re-measure (both DCs' `primary_rack`, `vvr1-dcN` rackd state) is OWED before "settled"** -- the cites are 2-10 days old (instrument-currency #20/#25). 3. **Root-topology (B): rationale confirmed, and it is about tofu STATE isolation, NOT L2 network isolation.** W2.1 Sec 2.2's three winning axes are state blast radius, destroy scoping, and apply-ordering simplicity -- all state/apply-plane facts. Under (B) both DCs' plane bridges and node VMs STILL share vcloud's one libvirtd/kernel; W2.1 Sec 2.3 itself keeps the (a) control's `--check` "before the first `tofu apply` of EITHER per-DC-flat root." **Do not read per-DC roots as addressing the cross-DC network gap (concern i) or the power-key blast radius (concern iii) -- (B) changes neither.** 4. **dc0/dc1 D-131 asymmetry: CONFIRMED by direct read.** dc0's forwarder is NOT load-bearing: `changelog-20260730-dc0-region-migration.md` Item 9 (~:336-352) -- `dns_servers=10.12.8.6` (the region's own BIND), dig-proven (`archive.ubuntu.com`, `flags: qr rd ra`, ANSWER: 9), "Pointing node DNS at the DC-LOCAL region is the correct end state." dc1's forwarder IS load-bearing: `changelog-20260807-dc1-region-sequence.md :80-89` -- cutover config "replicated verbatim," `dns_servers=10.12.68.3` (the D-131 forwarder alias). A real rebuild cleanup item: the 10.13 build sets each fresh region's own BIND from the start and collapses the asymmetry (Section 4.2). 5. **Client-VM octet `.8` / name `vr1-dcN-client` (W2.2) vs W2.1's grouping: NO CONFLICT.** W2.2 assigns identity (D-134 utility band, `.8` = next free slot after the `.7` amendment; cross-DC standard so it binds every DC); W2.1 assigns the apply site (the per-DC flat root, via `dc-site`'s `client_vm` input taking `metal_admin_ip`/`transit_ip` as NetBox-assigned inputs). Identity vs grouping -- orthogonal, both hold. W2.2's hedge is proper: `.8` reads on the metal-admin plane; the transit leg keeps its D-124 /30 addressing (not a plane octet); exact leg addressing confirmed at build, not inferred. 6. **Worker contradictions reconciled + inferred-claim sweep:** - **W2.4 Sec 5 row 2 vs W2.3 rack retirement -- superseded conditional, not a contradiction.** W2.4 has `site-headend-install.sh --role rack` landing on the client VM "pending the OPEN placement ruling"; W2.3's measured finding recommends RETIRING the standalone rack enrollment entirely. W2.4's row was explicitly conditional; with retirement adopted, **nothing rack-shaped lands on the client VM**, whose duty roster shrinks to: D-138 client role + SEC-028/SEC-029 credential residencies + concern-(ii) DC-side endpoint + the transit leg. This simplifies W2.1's open `dc-site` `client_vm.user_data` content question. - **W2.4 "no tooling gap here" (Sec 5 row 4) vs W2.3's decommission GAP -- reconciled.** W2.4's claim was about re-targeting existing script bodies (true); W2.3 correctly identifies one missing artifact on the retirement path: a `maas rack-controller delete` decommission step for `vvr1-dcN`'s Office1-registered rack object exists in NO script. Resolution: it FOLDS INTO owed artifact #5 (the MAAS machine-record release/delete step, which pass1 already scoped to include "region-side residue -- the rack-controller's own enrollment record + `primary_rack`/DHCP reference") -- amended to name the command class explicitly, plus W2.3's runbook note (new builds install directly as `region+rack` on the region VM, never a separate `--role rack` enrollment). Not double-counted (Section 5). - **W2.4's "net new procedure-module bodies: exactly TWO" -- CORRECTED, do not carry.** With W2.3's findings adopted, net-new bodies are at least FOUR: the (a) control, the teardown primitive, the power-key mitigation (+ its SEC row), and the `dc-site` IaC module (W2.4's count was procedure-only and predates the power-key finding). The SEC-010-writer extraction is a refactor of an existing body; the rack decommission step folds into #5. - **W2.2 Sec 4 item 1 and W2.3 Sec 3 are the SAME object seen from two sides -- MERGED** (Section 2.3): the undetermined power-address target (W2.2) and the blast radius of re-deriving it (W2.3). Consequence wired into the change-set: the `lib-hosts.sh` power-address re-derivation AND every call-site/runbook literal update (pass0 row 5) are **BLOCKED on the mitigation design**, because the mitigation (restricted key / wrapper / ACL) determines the URI and key shape. Not a literal swap. - **No inferred-value violations found.** W2.2 and W2.3 both state unknowns as OWED (power-address target, client-VM plane legs, dc1 cache sizing) rather than asserting. Spot-checked load-bearing cites resolved: `maas-region-power-key.sh:1-40` (key resident ON the region host; SEC-012/SEC-016 per-DC), `maas-node-power.sh:28-30` ("MEASURED to be the REGION" dials power), `opentofu/vr1-dc0-substrate/main.tf: 176-181` (maas-01's 150 GiB earmarked for PostgreSQL + boot images, "no spare"), `opentofu/main.tf:175` (voffice1 on the outer/vcloud root), D-134 octet map + D-143 C.3 as quoted by W2.2. --- ## 2. THE THREE ISOLATION CONCERNS -- separated, not conflated Three distinct controls/mitigations are owed. Different layers, different attack surfaces, different SEC rows. None substitutes for another; root-shape (B) resolves none of them. ### 2.1 Concern (i): cross-DC plane-bridge NETWORK adjacency -> the (a) vcloud host control Both DCs' six plane bridges + node VMs become co-resident on vcloud's ONE libvirtd/kernel for the first time in any deployed shape. **Status: operator-confirmed at the Phase-0 gate (handling (a)); design requirement consolidated at pass1 Section 3** -- a vcloud-level nftables artifact asserting no inter-plane/inter-DC forwarding, with a mechanical `--check` gate, its own harness, a new SEC-NNN row, a gap-register entry, Stage-1 home, installed and verified **before the first flat apply of EITHER per-DC root** (fork-robust invariant, unchanged by (B)). Artifact kind: procedure/L5 gate, NOT a tofu module (W2.1 Sec 3.4 and W2.4 Sec 5 row 1 both re-confirm; built ONCE). This is a network/forwarding control on vcloud's own kernel. Owed artifact #2. ### 2.2 Concern (ii): the SEC-010 transit-leg FORWARD-drop successor The interface-scoped FORWARD-drop on the Office1<->DC transit legs. The qemu+ssh purpose dissolves, but operator `ssh -J` and Office1-originated flows still ride the transit, and the protective claim (nothing routes from DC planes across the transit) is unchanged in spirit. **Endpoints resolved by recommendation (W2.3 Sec 4, this phase's owned decision): client VM (DC side) + voffice1 (Office1 side).** The client VM is structurally forced -- it is the ONLY DC-side VM with a transit leg under Option 1, and it reproduces SEC-010's original exposure shape ("straddles metal-admin + the transit," `security-ledger.md:21`) verbatim. voffice1's end never was containment-bound and does not move. Implementation shape: **extract the SEC-010 nftables writer out of `site-headend-install.sh`'s `node_host_setup()` (`:273-320`) into a role-agnostic subcommand that installs BOTH ends** -- closing today's hand-mirrored voffice1 install rather than carrying it forward. Carry the NIC-naming trap (live dc0 interface was `enp1s0`, not `mgmt`; re-measure the client VM's transit NIC before writing the rule). This is a network control on the transit endpoints. Owed artifact #3 (spec amended). ### 2.3 Concern (iii): the MAAS power-key BLAST RADIUS -- NEW, VERIFIED REAL **The most consequential risk Phase 2 surfaced (W2.3 Sec 3), verified this session on all three legs:** 1. **The region VM holds the power key.** `scripts/maas-region-power-key.sh` installs "the per-DC MAAS->libvirt power key inside a MAAS region's snap. Runs ON the region host" (SEC-012 dc0 / SEC-016 dc1, per-DC keys, never cross-DC reuse). `maas-node-power.sh: 28-30`: "MAAS dials the power address from whichever controller it chooses -- MEASURED to be the REGION." So each `vr1-dcN-maas-01` holds a live qemu+ssh virsh credential. 2. **voffice1 is a domain on vcloud's libvirtd.** `opentofu/main.tf:175` -- `voffice1` is created by the OUTER root (`qemu:///system` on vcloud), alongside (post-flatten) both DCs' entire node fleets, edges, and client VMs. 3. **One libvirtd connection scopes to all its domains.** libvirt's default `qemu:///system` access model is all-or-nothing per connection -- no per-domain scoping. **No repo artifact configures any libvirt access scoping** (grep of `scripts/` + `opentofu/` for polkit/ACL: only an unrelated file-ACL comment in `modules/opnsense-edge`). A read of vcloud's LIVE polkit/libvirt config is delivery work, not asserted here. **Consequence:** re-deriving the power address to vcloud's own libvirtd hands EACH DC's region VM a virsh credential with power control (start/destroy/undefine/console) over **every domain vcloud manages: both DCs' fleets + voffice1 + the vcloud substrate (mesh/pool objects)** -- virsh control, not a host shell; do not overstate. This recreates, through the power-credential door, exactly the cross-DC blast radius SEC-026/D-132 removed for the MAAS/cloud credential. **SEC-012/SEC-016's per-DC key separation becomes vacuous under Option 1: the keys stay distinct but both open the same libvirtd.** Neither concern (i) nor (ii) covers this (both are network controls; this is credential scope at the libvirt layer), and root-shape (B) does not touch it (state isolation, not connection scoping). **Owed: a THIRD control -- its own mitigation artifact + its own SEC-NNN row** (owed artifact #11). Candidate mechanisms (Phase-4 choice, not picked here): a `command=`-restricted SSH key on vcloud (virsh RPC / per-DC domain-set allowlist), a per-DC-scoped virsh wrapper as the forced command, or a libvirt polkit ACL scoping each key's connection. **Dependency wired into the change-set: the `lib-hosts.sh` power-address re-derivation (rows 2-3 of Section 3.2) and every `maas-node-power.sh` call-site/runbook literal are BLOCKED on this mitigation's design** -- the mechanism determines the URI and key shape. --- ## 3. The tools change-set ### 3.1 OpenTofu roots + modules (W2.1 -- full table in `pass2-w1-tofu-modules.md` Sec 1) **Zero module bodies need rewriting.** Of 12 module types: **1 collapses** (`wan-bridge` -- D-125 bridge-in dead; edge WAN -> direct `site-wan` NAT), **1 dead/orthogonal** (`maas-vm-host`, never instantiated; SEC-013 retire-or-keep flagged to its owner, not acted on), **3 untouched** (`office1-network`, `mesh-link` -- resolving pass1 open item 6: the mesh triangle survives, only the office1-leg consumer changes from `vvr1-dcN` NIC1 to the client VM's transit NIC -- and `netem-link`), **1 rewired input** (`site-wan` output feeds the DC edge directly), **6 re-home with unchanged bodies** (`cloudinit-vm` -- loses the 2 containment calls, gains the client-VM call; `dc-planes`; `dc-storage-pool` -- 2-per-DC collapses to 1; `node-vm` x12/DC; `opnsense-edge` -- one input re-pointed; `base-image`). **Root topology: recommend (B) -- shared-outer + per-DC-flat roots (3 total).** Rationale (state blast radius incl. this repo's own CLAUDE.md-cited incident class; destroy scoping = `cd && tofu destroy`, the closest re-earn of D-122's one-command site-down; apply-ordering: DC1's planes structurally cannot be created from DC0's root, so the (a) ordering invariant reduces to "check before the first apply of either root"). (A)'s only edge (DRY) is absorbed by `dc-site`. **STATE isolation only -- see check 3.** Directional, Phase 4 ratifies. Root naming (`vr1-dcN-flat` vs reserving `-substrate`) is Phase 4's call. **New IaC: `modules/dc-site`** (highest-leverage new artifact) -- composes pool + 6 planes + edge + 12 node VMs + client VM; replaces the ~230-266-line copy-pasted per-DC inner-root bodies; interface sketched W2.1 Sec 3.1 (site-token parameterized; `client_vm.user_data` stays a pass-through input -- now simpler, per the shrunken client-VM duty roster of check 6). A `site-client-vm` wrapper is explicitly NOT built yet. The client VM apply-groups with its DC's flat root (teardown symmetry, SEC-026 state-level isolation, D-138 fidelity). D-140 stays a separate future L4 root consuming `dc-site` outputs -- noted, not folded in. ### 3.2 `lib-hosts.sh` / `lib-net.sh` (W2.2 -- full table in `pass2-w2-lib-hosts-net.md` Sec 1) | Surface | Change | |---|---| | `VIRSH_POWER_ADDRESS` (VR0 default, `:52`) | UNCHANGED (VR0 out of scope) | | `VIRSH_POWER_ADDRESS_FROM_OFFICE1` / `_FROM_DCREGION` (`:212-213,246-251`) | **THE two load-bearing edits, value UNKNOWN and BLOCKED on the concern-(iii) mitigation design** (Section 2.3). Whether the FROM_OFFICE1/FROM_DCREGION split survives (both DCs' dials may converge on one vcloud endpoint) is part of that same design. Wrong value = "MAAS unreachable" masquerading as a network fault (pass0 row 4) | | `CARVE_AUX_HOSTS`, `NIC_PLANE_ORDER`, `BREX_PARENT_NIC`, `HOST_OCTET` maps, suffixes, `HOST_TAG`, resolver fns | UNCHANGED under container-elim (octet maps change under D-143 only). **The client VM does NOT join `CARVE_AUX_HOSTS`** -- it is L1 `cloudinit-vm`, not MAAS-carved | | Client-VM lib-hosts identity | **Resolved by recommendation:** NO `lib-hosts.sh` row now -- the client VM is not MAAS/virsh-power-managed; its identity lives in tofu (`dc-site` inputs) + NetBox IPAM. Revisit only if a script consumer appears | | `REGION_HOST_SUFFIX` comment (`:95-100`) | Comment-currency: the build-via-Office1-profile procedure needs re-verification for the flat path (rides the rewrites) | | **`lib-net.sh` (whole file)** | **ZERO container-elim edits -- D-143 address-axis ONLY** (grep-verified zero `vvr1` hits; D-143 C.3 shape (i) governs). Keeps the two rulable axes cleanly separable for this file | ### 3.3 Scripts (W2.3 -- full table in `pass2-w3-scripts.md` Sec 1) | Script | Change | |---|---| | `maas-node-power.sh` | **NO CODE CHANGE** (address is `$1`). Every invocation-site/runbook literal updates -- BLOCKED on the concern-(iii) mitigation (Section 2.3) | | `dc-rack-net.sh` | **Legs half RETIRES with the containment layer** (no flat VM is a libvirt host with its own bridges; `LEGS`/`br_of()` has no home to move to; `DNS_UPSTREAM=10.10.0.20` confirmed STALE for dc0). DNS-forwarder half: per the D-131 resolution (Section 4.2) | | `site-headend-install.sh` | `node_host_setup()`/`node_host_check()` (~134 lines): **DEAD, delete wholesale**. **EXTRACT the SEC-010 writer (`:273-320`) into a role-agnostic subcommand installing BOTH concern-(ii) ends** (Section 2.2). `--role rack`: **retired IF the rack-retirement recommendation is adopted** (Section 4.2) -- do not delete prematurely. D-125 WAN-bridge verify code: dead | | `dc-node-carve.sh`, `dc-node-v6-carve.py`, `carve-host-interfaces.sh`, `maas-role-tags.sh` | **NO CODE CHANGE** (grep-verified zero containment hits; pure MAAS-API, ``-parameterized). Invocation-host currency only (D-128 amendment territory) | | `site-baseleg.sh` | Stays a no-op; comment block re-cites D-138 + the (a) control instead of the retired qemu+ssh premise (doc-currency) | | `dc-mirror.sh` / `dc-cache-proxy.sh` (`dc-snap-proxy.sh` rides) | **New host + EXPLICIT disk sizing, not a relabel.** Neither Option-1 VM fits dc0's several-hundred-GB mirror as authored (maas-01: 150 GiB earmarked, verified `vr1-dc0-substrate/main.tf:176-181`; client VM: ~80 GiB). Decision rides the FIT-calculator extension (Section 4.4). The `.4` alias becomes a guest-netplan/MAAS-static concern | | `maas-region-power-key.sh` | Body unchanged; the KEY it installs is the concern-(iii) object -- its URI/key shape re-derives per that mitigation | ### 3.4 Module decomposition (W2.4 -- full tables in `pass2-w4-module-decomposition.md`) 51 deploy-path scripts classified: 4 libraries, 13 gates, 34 procedure modules (32/34 with harnesses; the 2 gaps routed in Section 6). The procedure-module contract (7 points, all grounded in existing repo patterns: single-purpose, `$SITE`-parameterized, own harness, declared I/O + exit contract, idempotent, layer-respecting, changelog+revert) is ADOPTED as the Phase-4 backbone. The IaC<->procedure boundary is **identity, not orchestration**: tofu ends at "booted domain with correct MACs/planes"; procedures re-derive everything from live identity (MAC/hostname/API) and never read tofu state -- and Option 1 structurally removes the one existing violation (the inner root's qemu+ssh provider dial). **Net-new bodies: corrected to at least FOUR** (check 6): the (a) control (L5 gate), the teardown primitive (L2/L5 wrapper), the concern-(iii) mitigation, and the `dc-site` IaC module. Everything else is re-instantiation or re-targeting via existing parameterization. --- ## 4. Resolutions of the Phase-2-owned open decisions (all: recommendation grade, Phase 4 ratifies) ### 4.1 Root topology (pass1 open item 1): **(B) shared-outer + per-DC-flat roots** Per Section 3.1. Teardown primitive builds against (B): gated `tofu destroy` of one DC root + emergency `virsh destroy` loop over that root's state-listed domains. NOT an L2-isolation answer (check 3). ### 4.2 Rack-controller remainder (pass1 open item 2, "THE highest-leverage open item") -- **largely DISSOLVES, three components, three answers (W2.3, verified check 2):** - **(i) MAAS rack controller: RETIRE the standalone registration.** Both maas-01 VMs already run `region+rack` (dc1 transcript-grade, dc0 functional-grade -- check 2); DHCP authority measurably cut over on both DCs (2026-07-30 / 2026-08-07). `vvr1-dcN`'s rackd is a vestigial Office1-region registration doing no work. Delta artifact = the decommission step folded into owed #5 + the runbook note (new builds init `region+rack` on the region VM directly; `--role rack` retires). **OWED before settled: current-day live re-measure.** Phase-4 ride-along: this touches D-132-addendum PREMISES (nothing is being co-located; the addendum's hypervisor-fate rationale is moot under Option 1) -- name it in the [ARCH] package. - **(ii) D-131 forwarder: RETIRE-WITH-EVIDENCE as the 10.13 end state for BOTH DCs.** D-131's precondition (rack-only controller, remote region) is removed by D-132's per-DC regions; dc0 already proves the end state (dig-verified region BIND); dc1's forwarder is presently load-bearing (verbatim-replicated config) -- the asymmetry is real and must not be assumed equal (check 4). The fresh 10.13 regions set their own BIND from the start; the retirement EVIDENCE step (the dig test dc0's migration used) is owed artifact #13. If retirement is rejected, the forwarder co-locates with component (i)'s host. - **(iii) Artifact service (`.4`): a right-sized, explicitly-provisioned home -- a STORAGE decision, not a MAAS-adjacency one.** Neither existing VM fits dc0's full mirror as authored (verified sizing cites, Section 3.3). Options: dedicated volume on a chosen VM, or a small dedicated utility VM. Decided WITH NUMBERS via the FIT-calculator extension (owed #7, spec amended to include mirror-disk sizing; dc0 full-mirror vs dc1 cache per D-135) -- not guessed here. **Net effect: the client VM's duty roster SHRINKS to** D-138 client role + SEC-028/029 credential residencies + concern-(ii) DC-side endpoint + transit leg (check 6) -- no rackd, no forwarder, and the artifact service only if the sizing decision puts it there. ### 4.3 Client-VM octet + name (pass1 open item 5): **octet `.8`, name `vr1-dcN-client`** (W2.2 Sec 2; D-134's ruled utility-band table enumerates through `.7`; cross-DC standard so `.8` binds every DC; octet-preserving under D-143). Consistent with W2.1's flat-root grouping (check 5). The D-134 map addition is a RULING -- Phase 4 package. ### 4.4 SEC-010 successor endpoints (pass1 open item 4): **client VM + voffice1**, one extracted installer for both ends (Section 2.2). ### 4.5 Also resolved at this phase - **Mesh-triangle survival (pass1 open item 6): CONFIRMED at the module level** -- all 3 `mesh-link` legs + `netem-link` unchanged; only the office1-leg consumer re-points. - **`site-headend-install.sh` refactor scope (pass1 open item 7):** delete `--host-nodes` (~134 lines) + extract the SEC-010 writer + retire `--role rack` contingent on 4.2(i). - **Client-VM lib-hosts identity:** no row (Section 3.2). - **The (a) control's mechanism (pass1 open item 3): NOT resolved this phase** -- concrete nftables rule set/check shape/SEC number remain Phase-3/4 design work; kind, home, and ordering are settled (Section 2.1). --- ## 5. OWED ARTIFACTS -- consolidated (Phase-1 list updated; count = 13) | # | Artifact | Status vs Phase 1 | |---|---|---| | 1 | Teardown primitive (gated, root-scoped `tofu destroy` of one DC root) | Spec sharpened by (B) | | 2 | The (a) cross-DC host isolation control (concern i): nftables + `--check` + harness + SEC-NNN + gap-register + gate row | Unchanged spec (pass1 Sec 3) | | 3 | SEC-010 transit-leg successor (concern ii): **endpoints resolved (client VM + voffice1); ONE extracted role-agnostic installer for both ends** (out of `node_host_setup()`); own SEC-row disposition | Spec AMENDED this phase | | 4 | R7 credential-revocation checklist | Unchanged | | 5 | MAAS machine-record release/delete step -- **AMENDED: + `maas rack-controller delete` decommission of `vvr1-dcN`'s Office1 registration + the region+rack runbook note** | Amended (absorbs W2.3's gap; check 6) | | 6 | Emergency site-down lever (`virsh destroy` loop over the DC root's domain set) | Spec sharpened by (B) | | 7 | FIT-calculator extension + fresh vcloud capacity measure -- **AMENDED: + artifact-service disk sizing (dc0 mirror vs dc1 cache)** | Amended (4.2 iii) | | 8 | MAC re-measurement pass post-apply | Unchanged | | 9 | NetBox DCIM migration (decommission `vvr1-dcN`; register client VM + roster) | Unchanged | | 10 | Post-build live asserts (geneve/jumbo; gap-#20 re-verify) | Unchanged | | 11 | **NEW: concern-(iii) power-key blast-radius mitigation** (restricted key / wrapper / libvirt ACL) **+ its own SEC-NNN row**; BLOCKS the lib-hosts power-address re-derivation + all call-site literals | NEW this phase | | 12 | **NEW: `modules/dc-site` + the per-DC flat-root pattern** (the container-elim's IaC deliverable) | NEW this phase | | 13 | **NEW: D-131 retirement-evidence step** (dig test against each fresh region's BIND; collapses the dc1 asymmetry) | NEW this phase | Not double-counted: the rack decommission (folds into #5), artifact-service sizing (rides #7), the SEC-010-writer extraction (IS #3's implementation shape). --- ## 6. OPEN -- carried forward **To Phase 3 (tests):** harness requirements for #1/#2/#3/#11/#12; the `maas-fabric-prune.sh`/`maas_fabric_classify.py` harness gap (ROUTE as a named decision: build vs accept-as-named-exception -- pre-existing, surfaced W2.4); `lib-identity.sh` harness status (W2.4 flagged to W2.2, which did not cover it -- an unclosed worker handoff, re-routed to Phase 3); which existing harnesses assume the container layer (Phase 3's own charter). **To Phase 4 (decision framing; operator rules, GA-R5):** 1. The container-elim [ARCH] ruling (D-123 amendment vs new D) + ride-alongs: D-125 retirement, D-138 concrete-host, D-128 amendment (Plane 2 shrinks), D-122 site-down re-earn, D-124 sizing-void, **+ NEW: the D-132-addendum premises note (4.2 i)**. 2. Ratify root topology (B) + root NAMING (`-flat` vs reserving `-substrate`). 3. Ratify rack-retirement (i) / D-131 retire-with-evidence (ii) -- after the owed live re-measure -- and rule the artifact-service home WITH the #7 numbers. 4. Rule the client-VM `.8` octet into the D-134 standing map + the name. 5. Choose the concern-(iii) mitigation mechanism + mint its SEC row; then unblock the power-address re-derivation (URI + FROM_OFFICE1/FROM_DCREGION split question). 6. The (a) control's concrete mechanism + SEC number (with Phase 3's harness spec). 7. `wan-bridge` module directory: delete vs leave-unreferenced (repo append-only bias). 8. SEC-013 `maas-vm-host` retire-or-keep -- flagged to its owner, not this pass's ruling. 9. State-blast-radius weighing rides item 2 (per pass1). **Owed live measurements (delivery, not this pass):** current-day rack/`primary_rack` state (4.2 i); vcloud's live polkit/libvirt access config (2.3); plus pass0 Sec 8's standing three (capacity, FIT, geneve/jumbo). --- ## 7. Settled vs open -- two grades, kept distinct **OPERATOR-CONFIRMED (do not re-open):** Option-1 target; handling (a) as a required deliverable; MAAS region stays on `vr1-dcN-maas-01`; plus pass1's settled list (Stage-2/ D-114 out of scope; D-140 pins L4 as procedure; two-axis attribution; (a) ordering invariant + Stage-1 home). **RESOLVED BY RECOMMENDATION -- pending Phase-4 ratification (GA-R5):** root topology (B); rack-controller retirement; D-131 retire-with-evidence; artifact-service = explicit sizing decision via #7; client-VM `.8` + `vr1-dcN-client`; SEC-010 endpoints (client VM + voffice1) + single-installer shape; client VM out of `lib-hosts.sh`/`CARVE_AUX_HOSTS`; mesh triangle unchanged; `dc-site` as the IaC composition unit. **OPEN:** everything in Section 6; the concern-(iii) mechanism; the (a) mechanism; the power-address value (blocked, by design, on #11). --- ## 8. Verification note Author = "the administrator" (no model name asserted, operator instruction). Direct reads this session: the four worker docs in full; `docs/changelog-20260807-dc1-region-sequence.md :70-95`; `docs/changelog-20260730-dc0-region-migration.md:330-355,525-555` + grep for region+rack/`hot-kid`; `docs/changelog-20260807-dc0-tailscale-provisioning.md:180-260` (incl. the :200/:254 cite correction); `scripts/maas-region-power-key.sh:1-60`; `scripts/maas-node-power.sh:25-35`; `opentofu/vr1-dc0-substrate/main.tf:172-185`; `opentofu/main.tf` module greps; repo-wide polkit/ACL grep. Worker citations were spot-checked at their load-bearing points, not re-derived wholesale; every correction in Section 1 names its source lines. READ-ONLY; findings LOGGED only; nothing executed.