Operator approval, exact utterance: "Queue up the MAAS half to run after you complete
netbox. I approve the MAAS deletes to clean up the data and config. Go ahead with both now".

APEX HALF APPLIED, exit 0: CREATE 26 | ALREADY 0 | DEPRECATE-ADDR 26 | DEPRECATE-PFX 9,
both read-backs OK. Independently re-verified rather than taken on the tool's own word --
a re-run reports CREATE 0 | ALREADY 26 | DEPRECATE-ADDR 0 | DEPRECATE-PFX 0, fully
idempotent and converged.

Recorded so a later reader is not misled: d139-gua-carve.py STILL reports "dependent
objects ... 26 ip-address(es)". That is correct -- the ULA records still EXIST, deprecated
rather than deleted, per the ruling. The carve tool counts existence, not status.

VERIFY BEFORE MUTATE FOUND A REAL HAZARD AND THE FIFTH SUBNET WAS NOT DELETED. The approval
was given before anyone knew what fd50:840e:74e2:220::/64 held. Measured: ::5 STICKY user
juju-vr1-dc0 (the JUJU CONTROLLER) and ::6 STICKY user MAAS (the MAAS REGION VM ITSELF),
with NO GUA counterpart -- the GUA metal-admin subnet holds exactly the nine tagged role
nodes (::100-102, ::120-121, ::150-153). This matches the record that dc-node-v6-carve.py
walks only those nine and that the controller's v6 was "restored separately", on ULA and
never migrated. Deleting it would remove the only recorded v6 of the deploy client AND of
the region the delete is issued to. HELD for its own decision.

The four empty subnets were proven safe twice: zero allocations AND zero machine-interface
links across all five -- the stronger check, since "no allocated IP" does not mean "nothing
references it". Zero links also confirms D-139 step 3 succeeded. Deleted INDIVIDUALLY with
a fresh re-check before each, never looped (hard rule 3; this repo has a logged incident
from batching nine deletes in a loop): subnet 9 :221::/64 metal-internal, 8 :230::/64
data-tenant, 12 :240::/64 storage, 11 :250::/64 replication -- all rc=0.

Post-state measured: six GUA /64s remain, one ULA held; machines unchanged and healthy at
9 Ready + 1 Deployed, total 10.

Still open: the held subnet (migrate controller/region v6 to GUA then delete, or delete and
accept the loss, or leave). And NO REPO TOOL exists for the MAAS half -- these were
hand-issued maas subnet delete calls, so the dc1 rebuild cannot reproduce them. Owed.

repo-lint 0 fail.

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