Operator, exact utterance: "MAAS static assignment is correct". Recorded on the
D-134 R4 amendment. The question offered MAAS static assignment, DHCPv6, or
SLAAC/RA -- materially different, only the first already satisfied.

It CLOSES work rather than opening it: the v6 carve already applied is sufficient
for node addressing; the rack-bridge v6 legs are NOT needed and were not applied,
so dc-rack-net.sh's LEGS table stays v4-only; dhcpd6 staying off is correct rather
than a gap; and no plane needs a router advertising RAs, so the DC edges take no
new role. It mirrors how v4 node addressing already works here.

RESOLVES U17. Its "the rack bridges need v6 too" was a correct observation on the
data path, but under static assignment nothing consumes a rack v6 leg, so the
widening it proposed does not follow -- the observation held, the conclusion did
not, which is this project's standing lesson about lens findings.

Verification owed at Stage-5 first boot, since nodes are powered off: PROPOSED,
not adopted, a fourth G17 assertion that a booted node carries a global v6 address
from its plane's /64 in the ruled ::100-::200 band. Amending a gate row is the
operator's call, so G17's three assertions are unchanged here.

STEP 3 COMPLETE. MAAS, lib-net and the apex all carry the ruled values. D-134's
bands and the D-020/R11 VIP set are now artifacts rather than prose. Machines 18
Ready + 2 Deployed unchanged across every mutation. Gauntlet ALL GREEN (83).

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