diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index ec62c39..70fabf1 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -102,9 +102,19 @@
   single root cause. Details + the queued detection-gap finding
   (cloud-assert trusts MAAS's self-report and missed a dead DHCP server):
   session changelog items 13-14; appendix-A entry queued.
-  REMAINING: `TF_VAR_maas_api_key` + `maas-vm-host` registration so MAAS has
-  power control (commissioning ends in a power-off; the module is BUILT but
-  UNVALIDATED) -- step D part 2 -- then netem (step E).
+  **Step D part 2 BLOCKED on a ruling (2026-07-20):** the nine nodes fell
+  back to `New` with no `power_type` -- commissioning cannot finish without
+  power control. New root `opentofu/vr1-dc0-maas/` is shipped and its plan
+  is clean, but the apply FAILED: `Failed talking to pod: Failed to login to
+  virsh console`. MEASURED cause -- the MAAS snap is confined, gets
+  `Permission denied` on `/var/run/libvirt/libvirt-sock`, and `snap
+  connections maas` lists NO libvirt interface, so a LOCAL `qemu:///system`
+  pod is IMPOSSIBLE with snap MAAS. **This refutes the mechanism stated in
+  D-123 Model B and in `modules/maas-vm-host`'s header** (intent survives,
+  mechanism does not); both need an amendment once the replacement is ruled.
+  Measured-feasible replacement: `qemu+ssh://jessea123@172.31.0.2/system`
+  (snap ships ssh; the rack user is in `libvirt`), needing a key the snap
+  can read. Session changelog item 15. THEN: netem (step E).
 - The grounding audit is COMPLETE and EXITED (2026-07-19): Phases 1-6 all
   closed (charter `148dcef`; rulings `docs/audit/ga-rulings.md`; the
   Phase-5 sweep ran as six operator-gated batches in one session; exit
diff --git a/docs/audit/stepD-vmhost-20260720.txt b/docs/audit/stepD-vmhost-20260720.txt
new file mode 100644
index 0000000..7d8a36d
--- /dev/null
+++ b/docs/audit/stepD-vmhost-20260720.txt
@@ -0,0 +1,8 @@
+module.vr1_dc0_vm_host.maas_vm_host.dc: Creating...
+
+Error: ServerError: 503 Service Unavailable (Failed talking to pod: Failed to login to virsh console.)
+
+  with module.vr1_dc0_vm_host.maas_vm_host.dc,
+  on ../modules/maas-vm-host/main.tf line 30, in resource "maas_vm_host" "dc":
+  30: resource "maas_vm_host" "dc" {
+
diff --git a/docs/changelog-20260719-dc0-deploy-stepB.md b/docs/changelog-20260719-dc0-deploy-stepB.md
index ba63ed2..2b6af51 100644
--- a/docs/changelog-20260719-dc0-deploy-stepB.md
+++ b/docs/changelog-20260719-dc0-deploy-stepB.md
@@ -546,6 +546,50 @@
   and unaffected by a brief DHCP/API outage), which makes this the cheapest
   moment to fix it.
 
+## 15. Step D part 2: NEW root for MAAS registration; and a MEASURED REFUTATION
+## of D-123's "power_address = qemu:///system LOCAL to the rack"
+
+- SHIPPED `opentofu/vr1-dc0-maas/` -- a THIRD root holding the MAAS
+  registration alone. Rationale is DOCFIX-179's own measured lesson applied
+  rather than repeated: a `provider "maas"` block forces EVERY plan in its
+  root to demand `maas_api_url` + the SENSITIVE key, even for plans creating
+  zero MAAS resources (the DOCFIX-175 plaintext-secret surface). Putting it
+  in the inner substrate root would make routine substrate work require MAAS
+  creds. Substrate roots stay credential-free. Validated explicitly --
+  **note `opentofu-validate.sh` covers only the outer root + modules, so
+  neither extra root is gauntlet-covered; extending it stays QUEUED and is
+  now more load-bearing (two uncovered roots).**
+- Secret handling: key supplied ONLY as `TF_VAR_maas_api_key` from the
+  operator-placed 0600 file; verified by FORMAT alone (71 bytes, 3
+  colon-separated parts), never printed. Caveat recorded in the root's
+  header: the key DOES land in that root's tfstate (unavoidable with this
+  provider), so that state inherits credential handling.
+- Plan was clean (1 to add). **APPLY FAILED:**
+  `ServerError: 503 ... Failed talking to pod: Failed to login to virsh
+  console.`
+- **ROOT CAUSE, MEASURED (not inferred):** the MAAS snap is strictly
+  confined. From inside it, `virsh -c qemu:///system` ->
+  `Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission
+  denied`. And `snap connections maas` lists **NO libvirt interface at all**
+  -- there is nothing to `snap connect`. So a LOCAL `qemu:///system` VM host
+  is ARCHITECTURALLY IMPOSSIBLE with snap-based MAAS.
+- **THIS REFUTES A DOCUMENTED DESIGN LINE.** D-123 Model B and
+  `modules/maas-vm-host`'s header both state the DC pod is registered with
+  `power_address = qemu:///system` LOCAL to the rack ("vvr1-dc0 is BOTH the
+  MAAS rack AND the libvirt host, so no cross-fiber virsh dial"). The
+  no-cross-fiber INTENT survives; the stated MECHANISM cannot work. Both
+  surfaces need an amendment once the replacement is ruled. Roosevelt-
+  relevant: the same constraint hits every DC pod and any snap-MAAS metal
+  build, so this is not a VR1 quirk.
+- Feasibility of the replacement, MEASURED: the snap DOES ship an ssh client
+  (`/snap/maas/41649/usr/bin/ssh`), and `jessea123` on the rack is in the
+  `libvirt` group (113) -- so `qemu+ssh://jessea123@172.31.0.2/system`
+  reaches libvirt through sshd (unconfined) instead of the blocked socket.
+  It needs a key the snap's root can read (`/var/snap/maas/current/root/.ssh/`
+  does not exist yet) plus that pubkey in the rack user's authorized_keys.
+- **Revert:** the failed apply created nothing (state empty); `git rm -r
+  opentofu/vr1-dc0-maas` removes the root.
+
 ## 8. STAGE-CLOSE QUEUE ITEM (operator directive, 2026-07-20): OPNsense 26.7 review
 
 - Operator directive (verbatim intent): at the proper time/place, review the