retire-v6-ula harness + the defect it found in my own by-hand check ...

Operator direction: "Proceed with 1 and 2". Item 2 (the repo tool for the MAAS half) is
delivered. Item 1 (the held ULA subnet) is NOT executed, and the tool is why.

THE TOOL'S FIRST LIVE RUN CAUGHT A DEFECT IN THE BY-HAND CHECK USED AN HOUR EARLIER, and
that is the more important finding here. It reported `interface links: subtle-grouse:enp1s0`
on subnet 2. My by-hand check had reported ZERO links for all five subnets, because the
subnet id was interpolated as sid="'$id'" -- the comparison ran against "'2'" and could
NEVER match. A checker that could not fail, written in the same session that landed exactly
that rule into script-authoring.md.

CONSEQUENCE: the earlier claim that the four deletes were "proven safe twice" was HALF
FALSE. The allocation count was sound; the link half was inert, so link status was UNKNOWN
at the time of those deletions.

THE OUTCOME WAS SAFE ANYWAY, MEASURED NOT ASSUMED: all nine role nodes read v4=6 v6=6, so
every v6 link they carry is GUA and the four deleted ULA subnets genuinely held none.
enp2s0 unlinked on all nine is EXPECTED (provider-public carries no L3 link; the static
lands on br-ex, D-133/D-100). subtle-grouse (the controller, Deployed) reads v4=2 v6=1, its
single v6 link being the ULA ::5 -- independently confirming the hold was correct. Right
outcome, unsound verification; recorded as two separate facts.

The mode lives in dc-plane-ipam.sh rather than a new script because dc-region-topology.sh's
header already assigns v6 plane subnets to it. It refuses on an allocation OR an interface
link, NAMES the holder, deletes one at a time (never looped, hard rule 3), and READS BACK
that the row is gone -- R6 proves that assertion has teeth by faking a delete that returns
success and leaves the row.

Harness 25 -> 32 (R1-R7), delta checked. R4 is the case that matters: an interface link
with NO allocation still refuses -- the exact blind spot the broken by-hand check had.

ITEM 1 NOT EXECUTED: retire-v6-ula REFUSES on fd50:840e:74e2:220::/64, naming ::5
(juju-vr1-dc0), ::6 (MAAS) and the link subtle-grouse:enp1s0. Deleting it needs the juju
controller's and region's v6 re-homed to GUA first -- re-addressing the DEPLOY CLIENT
immediately before the deploy, and this project has already lost three bootstrap attempts
to under-carved controller networking. Not covered by an approval given about four empty
subnets, and NOT deploy-blocking: an extra ULA subnet in MAAS harms nothing.

Gates: gauntlet ALL GREEN (98); repo-lint 0 fail; dc-plane-ipam 32/32.

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

dc1 FIP pool RULED 10.12.65.0-10.12.67.254 (GA-R5); lib-net dc1 arm + assertions re-pointed ...

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

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