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