diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index bf2f25b..1f87149 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -121,9 +121,17 @@
   nine domains. **The pod is however UNNECESSARY** -- its D-103 job was
   DISCOVERY, already done via PXE -- and per-machine `power_type=virsh` is
   MEASURED WORKING (`query-power-state` -> `{"state":"off"}` on the canary),
-  which is also the Roosevelt shape (per-node IPMI). **AWAITING RULING**
-  between per-machine power and the node-vm disk conversion; session
-  changelog items 15-16. THEN: netem (step E).
+  which is also the Roosevelt shape (per-node IPMI). **RULED 2026-07-20:
+  per-machine virsh power.** **STEP D IS COMPLETE**: shipped
+  `scripts/maas-node-power.sh` + harness (24/24; gauntlet now 72 ALL GREEN),
+  MAC-matched (MAAS renames machines at enlistment), dry-by-default, each
+  write verified by a real `query-power-state`. All 9 nodes have power
+  (`docs/audit/stepD-power-20260720.txt`) and **commissioning works end to
+  end -- 3 Ready / 6 Commissioning at time of writing**, shapes still exact
+  to D-121 Option C. `opentofu/vr1-dc0-maas/` is retained but UNUSED (the pod
+  route is refuted); retire-or-keep is a stage-close question, as is the
+  D-103/D-123 amendment text. Session changelog items 15-17.
+  REMAINING IN G10: netem (step E) only.
 - 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-power-20260720.txt b/docs/audit/stepD-power-20260720.txt
new file mode 100644
index 0000000..10c400f
--- /dev/null
+++ b/docs/audit/stepD-power-20260720.txt
@@ -0,0 +1,12 @@
+snrnaa     loving-dane            vr1-dc0-compute-01       -
+
+== setting power_type=virsh ==
+  [ok] ace-oyster -> vr1-dc0-control-01 (power state: off)
+  [ok] cuddly-bengal -> vr1-dc0-storage-01 (power state: off)
+  [ok] pro-coyote -> vr1-dc0-storage-03 (power state: off)
+  [ok] hardy-dove -> vr1-dc0-storage-04 (power state: off)
+  [ok] sought-chimp -> vr1-dc0-storage-02 (power state: off)
+  [ok] pro-orca -> vr1-dc0-compute-02 (power state: off)
+  [ok] valid-gecko -> vr1-dc0-control-03 (power state: off)
+  [ok] sunny-earwig -> vr1-dc0-control-02 (power state: off)
+  [ok] loving-dane -> vr1-dc0-compute-01 (power state: off)
diff --git a/docs/changelog-20260719-dc0-deploy-stepB.md b/docs/changelog-20260719-dc0-deploy-stepB.md
index 4b056c4..9c5f81f 100644
--- a/docs/changelog-20260719-dc0-deploy-stepB.md
+++ b/docs/changelog-20260719-dc0-deploy-stepB.md
@@ -632,6 +632,39 @@
   change here.
 - Both routes are recorded for the operator's ruling; nothing further applied.
 
+## 17. STEP D COMPLETE: per-machine power shipped as tooling; nodes COMMISSIONING to Ready
+
+- **RULING RECORD (GA-R5), 2026-07-20.** Question: pods are incompatible with
+  node-vm's pool+volume disks (measured) and the pod's discovery role is
+  already satisfied by PXE -- per-machine virsh power, or convert node-vm to
+  file-path disks and keep the pod? Operator answer, exact utterance (option
+  selected): "Per-machine virsh power (Recommended)". [Amends D-103/D-123's
+  stated vm-host mechanism; amendment text queued for stage close.]
+- SHIPPED `scripts/maas-node-power.sh` + `tests/maas-node-power/` (24/24 PASS
+  first run; **gauntlet 71 -> 72 harnesses ALL GREEN**; repo-lint 0 fail) --
+  delivered as TOOLING rather than nine hand-typed CLI calls so dc1 and any
+  re-run are repeatable. Design points the harness pins:
+  (i) matching is **BY MAC, never by name** -- MAAS assigns random hostnames
+  at enlistment (`ace-oyster`, not `vr1-dc0-control-01`), so a name match
+  would map nothing or, worse, the wrong node;
+  (ii) dry by default;
+  (iii) every write is verified by an actual `query-power-state` -- a stored
+  power parameter proves nothing about whether MAAS can REACH the hypervisor;
+  (iv) the measured pod-refutation reasoning travels in the script header.
+- Prereqs measured and fixed on the region: it had **no `virsh`** (it is the
+  MAAS/LXD host, not a libvirt host) -> installed `libvirt-clients`; and the
+  `maas` CLI profile was root-only -> created a user profile with `maas login
+  ... -` reading the key from STDIN (never printed, never in argv).
+- LIVE RESULT (`docs/audit/stepD-power-20260720.txt`): 10 domains found, **9
+  mapped and set, each confirmed `power state: off` by query**. The 10th
+  (the edge) is correctly unmapped -- it is not a MAAS machine.
+- **COMMISSIONING NOW WORKS END TO END:** all 9 commissioned; at the time of
+  writing **3 Ready, 6 Commissioning**, shapes still exactly D-121 Option C.
+  `Ready` means MAAS commissioned the node and it is deployable -- the whole
+  point of step D. The remaining six finish unattended.
+- **Revert:** `maas admin machine update <id> power_type=` (clears power) per
+  machine; the script itself reverts by commit.
+
 ## 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