LIVE: D-134's bands now EXIST -- both DCs at pass=24 fail=0, from a 6/18 baseline ...

Operator-gated, dependency-ordered: dc1 v6 carve (6 subnets), dc0 reserve (13
ranges), dc1 reserve (12 ranges). Each pre-apply re-verified in the same session;
every write read back. Subnets 18 -> 30, ipranges 3 -> 28. Machines 18 Ready + 2
Deployed unchanged throughout -- no node, no tfstate, no running service touched.

This closes the "RULED IS NOT BUILT" finding for D-134: its band table had been
prose since 2026-07-23 while MAAS held zero reserved ranges.

FINDING -- MAAS already reserves the entire low IPv6 block. Every explicit v6 band
create failed with "Requested reserved range conflicts with an existing range".
Measured via `subnet reserved-ip-ranges`: MAAS auto-reserves ::1-::ffff:ffff on
every IPv6 subnet plus :: per RFC 4291 s2.6.1, with allocatable space starting at
<prefix>:0:1::. The ruled bands sit entirely inside it, so the write is impossible
AND unnecessary. R4's "v6 bands as a second pass" is not executable in MAAS and
need not be; the tool now verifies coverage instead of writing. Execution-level
correction -- R4's intent is satisfied. Same on ULA and GUA.

Harness T19 asserted a literal string the fix removed. Re-pointed at the surviving
invariant (textual 4-99, never hex 4-63) rather than deleted, per the standing rule
against going green by removing an assertion. 25/25, gauntlet ALL GREEN (83).

dc1's FIP pool still correctly REFUSED -- unset by design, so R4 cannot close for
dc1 until ruled.

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

dc-plane-ipam: carve-v6 and reserve actions, dry by default, harness 25/25 ...

Both are DRY BY DEFAULT, IDEMPOTENT, and READ BACK every write -- this repo has
been bitten by a script whose `apply` always silently dry-ran, so a create that
reports success is re-read before being called done.

carve-v6 places each v6 plane on the SAME MAAS vlan as its v4 twin, so the plane
is genuinely dual-stack on one L2 rather than a parallel fabric, and REFUSES to
create anything if that vlan cannot be resolved. The provider GUA VIP /64 is
skipped by design.

reserve does the D-134 bands plus the FIP pool. Two deliberate refusals:
- dc1's FIP pool is UNSET in lib-net BY DESIGN ("UNSET so any use fails loud").
  Mirroring dc0's shape would be an inferred value, so it refuses and reports
  that R4 cannot be fully executed for dc1 until the pool is ruled. Real finding.
- a same-bounds range of the wrong type is REFUSED, not overwritten.
v6 bands are skipped until carve-v6 has run -- R4's forced sequencing, surfaced
rather than silently passing.

TWO BUGS CAUGHT PRE-SHIP, neither by review:
- printf '%x' 50 yields 32, so the v6 bands would have been created at ::32-::63
  -- a plausible-looking band that is NOT the one ruled. The ruling mirrors the
  DIGITS (v4 .50 -> ::50). T19 locks it.
- `shift 2` with a single argument fails, leaving "$@" holding the action, which
  the option loop rejected as an unknown option instead of printing usage. Found
  by the harness.
The header claiming the mutating actions were absent is also corrected -- it went
stale the moment they landed.

Gauntlet ALL GREEN (83), repo-lint 0 fail.

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

Step 3: dc-plane-ipam.sh check -- D-134's missing executable gate, with a measured baseline ...

R4's D-134 amendment ruled a site-keyed tool that "also gives D-134 an EXECUTABLE
gate instead of prose". This is that gate. Read-only half only; the mutating
actions are deliberately not in this commit (hard rule 3 -- the gate ships and
runs first, so the mutation is planned against a MEASURED baseline).

Expected state is derived, never hardcoded: v4 planes from lib-net's DC selector,
v6 planes from the NetBox apex record (D-136 option (D) applied -- the apex is the
source, so this does not create a second hand-maintained table), bands from the
D-134 2026-07-23 amendment.

LIVE BASELINE, both DCs, symmetric at 6 pass / 18 fail: all six v4 planes present;
ZERO of six v6 planes present; ZERO of twelve D-134 bands reserved. MAAS holds 17
v4 subnets and exactly one v6, which is Office1's -- a third-layer confirmation of
U17. Cloud-wide there are 3 ipranges, all dynamic, matching R4's measurement.

Proven able to BOTH fail and pass: every live run fails because everything it
asserts is absent, so T6 drives a fully-provisioned fixture to green. A gate only
ever observed failing is as untrustworthy as one only ever observed passing. It
REFUSES rather than reporting clean on an unreachable MAAS, an unreadable apex, or
a band of unrecognised type, and distinguishes an ABSENT maas binary from an
unreachable MAAS -- the misdiagnosis class this audit found three times.

The provider GUA VIP /64 is reported but NOT asserted as a MAAS subnet: it holds
hacluster-managed VIPs, not node addresses, so MAAS cannot hand one out. Whether it
should also be a MAAS subnet is left open rather than decided by a gate.

Harness 14/14. Gauntlet ALL GREEN (83) -- the R15(2) manifest gate correctly caught
the new harness as unpinned drift and was re-recorded deliberately, which is the
mechanism working end to end in its first real use.

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