LIVE: dc0 v6 plane carve applied -- 6 MAAS subnets, each read back ...

Operator-gated ("Run carve-v6 vr1-dc0 --commit"). dc0 only; dc1 not authorised
and not touched.

Pre-apply re-verified in the same session per the G8 precedent -- plan unchanged
at 6/1/0 -- then applied: 6 applied, 1 skipped, 0 errors, every create READ BACK
on its intended vlan. MAAS subnets 18 -> 24, v6 1 -> 7.

Each v6 plane landed on the SAME vlan as its v4 twin, so the plane is genuinely
dual-stack on one L2 rather than a parallel fabric. The provider GUA VIP /64 was
deliberately not created -- it holds hacluster-managed API VIPs, not node
addresses, so MAAS never allocates from it.

Idempotency proven LIVE rather than only in fixture: --commit ran twice (the
second to read the script's true exit code rather than a pipeline's) and the
post-state carries zero duplicate CIDRs.

Nothing else moved: 18 Ready + 2 Deployed unchanged, no node touched, no tfstate
involved, dc1 still measures 6 v6 planes absent. The gate now reports dc0's six
v6 planes [ok]; its remaining reds are the 12 unreserved D-134 bands.

Changelog item 9 carries the revert, with the 2026-07-21 pod-delete cascade
lesson attached: read occupancy BEFORE deleting a subnet.

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

R15(2): the gauntlet pins a harness MANIFEST, completing the R15 gate work ...

tests/HARNESS-MANIFEST (82 names) plus a drift gate in run-tests-all.sh, with
--record-manifest for deliberate re-recording. The zero-floor already existed;
what was missing was any pin on WHICH harnesses ran, so a renamed or deleted
harness was neither run nor failed while the gauntlet still printed ALL GREEN.
The figure 81 existed only as prose.

Proven able to fail on both cases, including the one a bare count cannot catch:
renaming a harness is reported, and renaming one WHILE adding a decoy -- so the
count holds at exactly 82 -- is still caught, naming both the missing and the
unpinned entry. That case is why the ruling chose a manifest over a count.

Sequenced LAST of R15's three deliberately: the ruling warns a manifest must be
seeded from a verified tree, not from whatever is on disk. Seeded here from a
tree with the gauntlet ALL GREEN and repo-lint 0 fail in the same session.

The gate runs only on a full gauntlet -- a filtered run legitimately executes a
subset. A missing manifest is itself a FAIL, since ALL GREEN would otherwise be
unfalsifiable.

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

R15(3): preflight no longer fails open on an unexpected sub-gate exit ...

Reproduced first, in isolation with the exact note() from preflight.sh:27 --
sub-gate exits 127 (command not found), 126 (not executable), 130 (interrupted)
and 3 (undefined) ALL left "PREFLIGHT: PASS -- clear to add-model / deploy".
This is the gate that authorises the deploy.

rc=2 handled PER GATE rather than blanket-remapped, because R15's stated
rationale is only partly right on measurement: repo-lint and pre-flight-checks
both DOCUMENT rc2 as a legitimate warning, while provider-bundle-check and
creds-matrix use it only for could-not-evaluate. A blanket 2->FAIL would have
turned the standing L1 legacy-ASCII warn into a deploy blocker. channel_assert
uses 2 for BOTH meanings, so it is ambiguous in the checker and kept WARN; its
missing-PyYAML root cause is caught by P2 anyway, which shares it and is strict.
Flagged rather than guessed -- fixing that belongs in channel_assert.py.

Harness 16/16 (was 10): T11-T13 lock the fail-open cases, T14/T15 lock
could-not-evaluate -> FAIL, and T16 locks the non-over-correction (P1 rc=2 stays
WARN). Gauntlet ALL GREEN (82). Real-repo preflight still exits 1 for the same
known reasons with no new failure classes fired.

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

R15(1): repo-lint can no longer report PASS over zero files ...

Reproduced before fixing, both cases printing "PASS: repo lint (0 fail, 0 warn)"
with exit 0: `repo_lint.py --recordd` and `repo_lint.py /nonexistent-path`. Only
the two known flags were stripped, so any other --flag became argv[0] i.e. the
ROOT; it resolved nowhere, rglob yielded nothing, and zero findings read as
clean. This is the gate whose "0-fail" every GA-R6 stage close in this project's
history cites, and it could not tell a clean repo from an unexamined one.

Fix: reject unrecognised options (the actual root cause) and >1 positional root;
require the root to be a directory carrying repo markers, refusing rather than
defaulting to success; add a files-scanned floor; and PRINT the files-scanned
count -- Phase 0 found repo-lint emitted no such figure at all, so a reader could
not distinguish a thorough pass from a vacuous one.

The floor SCALES, and a flat one was wrong: the first implementation used a flat
100 and failed 20 of the 47 existing harness cases, because tests/repo-lint
legitimately builds ~7-file fixture repos. The strong floor now applies only to a
full checkout of THIS repo, detected by two files no fixture creates; any other
tree must still scan at least one file. Caught by running the harness.

Harness 54/54 (was 47) -- T48-T54 lock each reproduced defect, including that the
floor does NOT punish a legitimate minimal tree. Gauntlet ALL GREEN (82).
repo-lint on the real repo: 0 fail, 1 standing warn, 596 files scanned.

No consumer breaks -- preflight P1 reads the exit code, not the summary text;
harness regexes match the unchanged "PASS: repo lint" prefix. Both verified.

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

Phase 0 delivery cleanup: session changelog with reverts, and a mis-filed finding corrected ...

Three gaps in the Phase 0 delivery, plus one new measured finding.

1. SESSION CHANGELOG ADDED (GA-R2/D1) -- docs/changelog-20260727-stage5-phase0.md.
   It was missing, and it is the only revert surface: no logged window was
   opened for this session, so the changelog + capture are the entire
   as-executed record of five live mutations (two branch deletions on origin,
   two on voffice1, a 68-package install on the region host). Each item now
   carries WHAT / WHY / HOW TO REVERT with the pre-state hashes recorded
   (39e8988, 61c416e, 57836b1) and the apt purge scoped with a caution that
   68 packages were pulled and some are shared.

2. CURRENT-STATE section 7 no longer carries two rows for one component. The
   prior "ABSENT ON BOTH HOSTS" state is folded into the single pin row as
   history, following the Juju row's in-row supersession precedent. A pin
   table asserting both presence and absence of the same client is the same
   stale-surface class the audit close-out sweep found the audit itself
   creating.

3. A FINDING I MIS-FILED IS CORRECTED BY MEASUREMENT. P4's
   "metal-admin gateway=none (want 10.12.8.1)" was dismissed as covered by
   readiness item 3.7. It is not -- 3.7 is specifically the VID-103 /
   br-internal assertions. Measured from the dc0 rack: 10.12.8.1 answers 0/2
   pings with an INCOMPLETE ARP entry (never resolved -- nothing holds it),
   against a control ping to the edge at 10.12.4.1 at 0% loss. So MAAS is
   right to carry no gateway and lib-net.sh:37's expectation is the defect, a
   VR0 inheritance; the D-134 carve ruled .1 gateways for the PROVIDER subnets
   only. Logged as P0-5, not fixed (hard rule 1). The dc1 arm (lib-net.sh:149)
   carries the same shape at 10.12.68.1.

Also queued for one GA-R5 exchange, no D-number assigned: which host is
authoritative for the gates. R10 (preflight on voffice1) and R15(3) (preflight
stops failing open) executed together make preflight-on-voffice1 permanently
unpassable given P0-2, and R15(2)'s manifest does not reach P0-1 -- so the R15
execution scope needs this answered first.

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