Changelog 2026-08-08 -- dc0 activation (checkpoint) + re-IP ruling prep

Session body (GA-R2, one per session). Branch dc-dc-stage5-preconditions. Status authority is docs/CURRENT-STATE.md ONLY; this file is the review surface (blanket-approval: every item states what / why / how-to-revert).

Mission: drive dc0 to FULL deployment as a CHECKPOINT (STANDING PIVOT 2026-08-08), then teardown + redeploy on 10.13.0.0/16. Scope this session: dc0 activation (networks -> Octavia 1-LB -> Designate 1-zone -> wrap gates), plus a parallel re-IP GA-R5 ruling-prep package.

Item 1 -- DOCFIX-213: phase-04 network scripts made MAAS_PROFILE-aware (F3/D-138 co-location fix)

What. scripts/phase-04-network-create.sh and scripts/phase-04-network-verify.sh now honour MAAS_PROFILE="${MAAS_PROFILE:-admin}" (matching the established carve-host-interfaces.sh / maas-role-tags.sh idiom) instead of hardcoding maas admin. Three maas admin ... call sites became maas "$MAAS_PROFILE" ... (create:41 subnets; verify:57 subnets, verify:88 ipranges) plus the verify precondition error message. Header "Requires" comments updated. The admin default preserves VR0 single-DC behaviour unchanged; VR1 overrides to the DC regional (e.g. MAAS_PROFILE=vr1-dc0-region).

Why. F3 (queued-findings-20260808): the dc0 rack vvr1-dc0 carries the openstack CLI + admin-openrc + cloud L3, but an EMPTY maas profile db; the maas profiles live on voffice1 (no L3 to the dc0 cloud -- D-138). phase-04-network-create.sh needs BOTH maas (DOCFIX-047 gateway cross-check by CIDR) AND openstack on ONE host, so it could run on neither. MEASURED this session: the authoritative in-DC regional vr1-dc0-region (running on dc0 node hot-kid, 10.12.8.6:5240) carries 10.12.4.0/22 gw 10.12.4.1, and the rack reaches that API (HTTP 200 via metal-admin virbr2). Operator directive (verbatim, 2026-08-08): "each DC should have its site regional maas and the racks register up to the DC regional controller" -- so the fix threads the DC-regional profile through rather than the office1 admin default. The script change is durable and transfers to the 10.13 rebuild; it does NOT strip the maas two-source gate (advisor: disarming it is the instrument-#16 recurrence).

Tests. Extended both existing harnesses (tests/phase-04-create, tests/phase-04) with an EXPECT_PROFILE-keyed fake maas so a case can prove the SUT threads MAAS_PROFILE through (not hardcoded admin). New cases: create "MAAS_PROFILE=vr1-dc0-region passed through" (exit 0), verify "MAAS_PROFILE=vr1-dc0-region passed through" (PROCEED). Failability PROVEN out-of-band: with MAAS_PROFILE=vr1-dc0-region EXPECT_PROFILE=admin the create GATE-FAILs (exit 1, empty gateway) and the verify hits precondition exit 2 reporting 'maas vr1-dc0-region subnets read' -- confirming the profile is really threaded. Both harnesses ALL PASS; repo-lint 0 fail (1 legacy L1 warn).

Revert. git checkout HEAD -- scripts/phase-04-network-create.sh scripts/phase-04-network-verify.sh tests/phase-04-create/ tests/phase-04/ restores the hardcoded-admin scripts and the prior harnesses. Behaviour reverts to VR0-only.

OWED (not in this item -- live, operator-gated): register the vr1-dc0-region maas CLI profile ON the rack (credential one-shot, SEC-safe -- generated on hot-kid, piped to maas login, never printed), then run MAAS_PROFILE=vr1-dc0-region scripts/phase-04-network-create.sh on the rack. Task #1 remains OPEN until that runs.

Rebuild-plan finding (LOGGED, not executed): the outer substrate hosts vvr1-dc0 / vvr1-dc1 are currently MAAS rack controllers under the OFFICE1 admin region, NOT their DC regionals -- exactly the gap the operator directive names. The 10.13 rebuild tooling should register each rack up to its in-DC regional at standup.

Item 2 -- Re-IP GA-R5 ruling-prep package (Task #6, background agent)

What. docs/audit/reip-1013-ga-r5-ruling-prep-20260808.md created (read-only analysis; no live mutation, no D-number minted). Reconciles D-101/D-115/D-124/D-134 for the 10.12 -> 10.13 re-IP, drafts the GA-R5 ruling question + options, enumerates the consumer blast radius, and lists the OWED live-free checks.

Why. The re-IP is a D-115 interaction + terminates D-101 inheritance; it needs a GA-R5 ruling before any dependent re-carve (Task #2, the 10.13 NetBox scope, is blocked on it). Preparing the package in parallel keeps the operator's ruling exchange fact-based.

Key content. Live vr0-dc0 stays on 10.12 (never edited), so the re-IP CREATES 10.13 as a NEW allocation -> the ruling must decide whether the NetBox Cloud role gains 10.13 (B1), a new "Cloud -- VR1 rebuild" role owns it (B2, agent-recommended), or the Cloud role moves (B3). Decision verbs: D-101 TERMINATES (v4-inheritance), D-115 AMENDS (factual premise, not wholesale supersession), D-124/D-134 CONSISTENT. Blast radius (measured, excl. frozen history): ~3765 10.12 hits / 326 files, ~1191 in eight must-change code/config surfaces. Next-free D verified D-143 (NOT minted).

OWED before the operator can rule (no read-only access from the agent): (1) Headscale advertised/approved route table -- no overlap with 10.13.0.0/16; (2) live office1-netbox apex -- 10.13.0.0/16 free; (3) live vr0-dc0 MAAS/neutron -- 10.13 not in use. All three need the foreground/operator; a "is this /16 free" tool is a tooling gap to propose rather than improvise.

Revert. git rm docs/audit/reip-1013-ga-r5-ruling-prep-20260808.md (analysis artifact only; nothing consumes it).