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

Stage-5 Phase 0 EXECUTED: clone advanced, refs pruned, openstack client installed ...

Readiness-doc preconditions 0.1/0.2/0.3, operator-approved step by step
("Approve A, B, and C, and retire the audit branch"). NO STAGE OPENED.

0.1 voffice1 is at main (HEAD == origin/main == 6495cfb, asserted). The real
risk was that both DCs' inner tfstate -- the substrate's state-of-record --
lives inside that working tree; every state artifact was proven gitignored and
origin/main proven to track an identical file set at those paths BEFORE the
switch. Both tfstate sha256s are byte-identical after. The two dc1 overlays are
now present and bundle.yaml is the 9-node role-separated layout.

0.3 three stale remote-tracking refs pruned, two stale local branches deleted
(the record named one), containment proven first. The audit branch was retired
on origin BEFORE the fetch so the clone could not be handed a fresh stale ref.

0.2 python3-openstackclient 6.6.0-0ubuntu2 on voffice1, verified behaviourally.
The snap was refuted by measurement: no Caracal channel (newest stable zed,
2023), plus the home-only confinement already recorded at design-decisions:638.

Two NEW findings from the payoff runs, logged not fixed (hard rule 1):
- the gauntlet is HOST-DEPENDENT (2/81 on voffice1 vs ALL GREEN on vcloud, same
  commit); both failures are host-portability defects, one of them an aggregate
  FAIL over all-passing sub-checks
- preflight P5 is HOST-BLIND (34 findings vs 7), and between the two hosts there
  is no single host on which preflight is currently correct

R10's ruled consequence is confirmed: P3 now verifies all 33 charm-channel pins
(previously zero) and P4 reports MAAS reachable.

Capture: docs/audit/stage5-phase0-20260727.txt

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