# 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).