d139-step1-apex-push-dc0-20260801.txt
======================================
D-139 execution STEP 1 -- apex CREATE-only push, vr1-dc0. EXECUTED 2026-08-01.
Tool: netbox/d139-gua-carve.py --dc vr1-dc0 --commit   (exit 0)
Apex: office1-netbox http://10.10.1.10:8000 (the WORKING VR1 apex, DOCFIX-195).
Host: vcloud. Operator-approved ("Work through the open items in order").

PRE-WRITE, verified immediately before the mutation:
  apex prefix count                       139
  dry-run prefix set vs the reviewed capture (docs/audit/d139-carve-dryrun-20260801.txt)
                                          IDENTICAL for the 11 originally-reviewed rows
  the 2 OOB rows are NEW since that review -- added by the 2026-08-01 ruling, covered by
  harness T07/T08/T12/T17 and mutation-proven (removing them turns T07 + both T08 red).

TOOL RESULT: CREATE 13 | EXISTS 3 | RETIRE-REPORT 9;  READ-BACK: 13/13 present; errors=0.

INDEPENDENT READ-BACK (not the tool's own word -- a separate API query):
  apex prefix count                       152   (139 + 13, exact)
  GUA rows scoped vr1-dc0                 17    (4 pre-existing + 13 new)
    :20::/60 :20::/64   role=metal-admin
    :21::/64            role=metal-internal
    :30::/60 :30::/64   role=data-tenant
    :40::/60 :40::/64   role=storage
    :50::/60 :50::/64   role=replication
    :80::/60 :80::/64   role=lbaas-mgmt
    :f0::/60 :f0::/64   role=oob            <- the 2026-08-01 OOB ruling
  ULA prefixes still present               9     (the tool has NO delete path)
  ULA VIP legs still present               26    (nothing orphaned)

WHAT THIS DOES NOT DO, stated so no one reads more into it: it writes PREFIXES into the
apex only. No MAAS subnet, no node address, no VIP was created, moved or deleted. Steps
2 (MAAS GUA /64s alongside the ULA) and 3 (node v6 re-carve while v4 is still present)
remain outstanding, and the ULA retirement is step 6.

vr1-dc1 has NOT been pushed -- the two DCs are separately approved.