Pull c9cc79f -> 75e3657. Both inner tfstates confirmed git check-ignore
IGNORED before the pull and sha256 byte-identical after -- the Phase-0 safety
proof, since those files are the substrate's state-of-record and live inside
the working tree.

A diff the pull revealed, explained rather than waved through: both inner
roots now plan 0 add / 1 change / 0 destroy. That is MAC ADOPTION, not drift
-- the plan adds mac = { address = ... } blocks carrying values IDENTICAL to
live, because tofu state has no mac block for a domain created unpinned.
Exactly the 2026-07-21 shape. NOT applied: a separate gated in-place update
on a running domain, which 'set power_type' did not authorise.

Power set scoped to the vr1-dcN-juju prefix so the nine already-configured
role nodes per DC were not re-touched. Both verified by a real
query-power-state returning off, which is ground truth -- a stored parameter
is not power control.

WHY power_type was not set during commissioning, answered with evidence:
(1) these machines were never commissioned; New is post-enlistment and
pre-commissioning, and those are distinct phases. (2) Even commissioned, MAAS
auto-configures power only for IPMI-based machines by probing the BMC in-band
-- per this MAAS's own CLI, 'skip_bmc_config ... for IPMI based machines'. A
KVM guest has no BMC, and the virsh parameters (qemu+ssh URI, credential,
libvirt domain name) are hypervisor facts nothing inside the guest can
discover. That is the chicken-and-egg behind 2026-07-20: commissioning needs
power control, but for a virsh VM power config cannot be discovered by
commissioning. Structural and already known; the only gap was that nobody had
run the step for two brand-new machines.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf