queued-findings-20260803-stage5-deploy-ovn.txt
==============================================
SAVEGAME SWEEP for the 2026-08-03 session (Stage-5 dc0 deploy: DOCFIX-208, deploy
executed, controller rebuilt, vault brought up, ovn-central cert issue deferred).
Method (ruled 2026-07-31): read the whole session, enumerate every finding/decision/
measurement/mistake, grep each against repo surfaces. Hit = ALREADY ON SURFACE. No hit
= FIRST SURFACE, would be lost on /clear.

Status claims live in docs/CURRENT-STATE.md ONLY.

--------------------------------------------------------------------------------------
FIRST SURFACE -- existed ONLY in the transcript. Listed first, by consequence.
--------------------------------------------------------------------------------------

F1. >>> GAUNTLET IS RED AT CLOSE: provider-bundle-check 1/98 FAILED (4 cases). <<<
    `bash scripts/run-tests-all.sh` -> "GAUNTLET: 1/98 FAILED -- provider-bundle-check".
    The 4 failing cases are ALL dual-family assertions: T19 (every app dual-family in the
    real deploy input), T21 (v6 legs without the option passes), T25 (dual-family + unreadable
    apex REFUSES), T45 (six dual-family vips with no prefer-ipv6 pass).
    CAUSE, measured: this session reverted the dc0 VIP overlay to IPv4-ONLY (D-141 / the
    render values `family: v4`), so the real deploy input is no longer dual-family -- but the
    provider-bundle-check HARNESS still asserts it is. This is the "remediating a finding turns
    the harness red -- REPLACE the assertion with the new invariant" class (repo's own rule).
    LOGGED NOT FIXED (savegame hard rule 1). NEXT SESSION: reconcile tests/provider-bundle-check
    to the v4-only deploy input under D-141 (the four dual-family fixtures/expectations), OR
    gate them behind the family so a v4-only overlay is expected to be v4-only. A built-surface
    change (v4 revert) shipped WITHOUT its companion harness update -- that is the defect.
    grep "T19 every app is dual-family" tests/: hit (the test exists); grep the RED result in
    docs/: 0 hits before this file -> FIRST SURFACE.

F2. settings.local.json (GITIGNORED) grew 310 -> 313 allow rules this session; the added
    ones include BROAD wildcards `Bash(ssh vr1-dc0-rack *)` and `Bash(ssh vr1-dc0-maas *)`
    -- ANY command on the dc0 rack (the D-138 deploy client) and the MAAS region VM. Same
    broad-ssh-allow class flagged on 2026-07-30 and 2026-08-02, now recurring a third time.
    ask=11, deny=0 (unchanged). Gitignored, so this text is the only recovery copy. Recommend
    narrowing to the read-only + specific-mutation forms actually used. (SEC-030 posture: the
    real gate is operator presentation-approval, not the rule engine.)

F3. voffice1 clone was 36 COMMITS BEHIND at close (it was not used this session -- all deploy
    work ran on the dc0 rack via juju). BROUGHT INTO SYNC by the new savegame Step 1b
    (`git pull --ff-only`), now at HEAD 46f3ab2 lag 0. It will need ONE more pull for the
    bookend commit itself. dc0 rack ~/repo-stage MATCHES HEAD (bundle 2af8a358, vips cf42b937,
    machines e8ca794c). Recorded because a lagging clone is a hazard even when synced at close.

F4. LIVE MODEL STATE carried to next session (the deploy is MID-STAGE-5, not closed):
    9 machines started; mysql-innodb-cluster ONLINE 3/3; vault INITIALISED+UNSEALED+root-CA
    (active); ~25+ units active, 0 in error; v4 VIPs live on the 11 API charms; ovn-central x3
    DEGRADED (no server cert, OVN NB/SB cluster not formed, 6641/6642 not listening);
    certificates relation is certificates:142 (bounced this session); ovn-central "" default =
    metal-internal (bundle+live). Expected-tail blocked: ceph-rbd-mirror (cross-DC),
    designate (Stage 7), octavia (awaiting-configure). All in CURRENT-STATE; consolidated here
    as the single resume snapshot.

--------------------------------------------------------------------------------------
ALREADY ON SURFACE (grep-confirmed) -- recorded for completeness, not first-surface.
--------------------------------------------------------------------------------------
- DOCFIX-208 (machines overlay missing from dc0 deploy cmd): CURRENT-STATE + changelog-20260802-deploy-input.md + phase-4 runbook.
- Dry-run prints no options at any verbosity: references/platform-traps.md (Juju section) + memory instrument-currency #14.
- Designate "contradiction" withdrawn (D-106 additive): CURRENT-STATE + memory vr0-to-vr1-is-additive.md.
- D-135 amendment (b) dc0 converges on proxy; D-141 IPAM dual-stack reserved-until-capable: design-decisions.md + CURRENT-STATE.
- UCA signing-key failure + proxy convergence: CURRENT-STATE + changelog-20260802-deploy-input.md + docs/audit/uca-*.
- Controller --force orphaned the model / Path M + Path C teardown-rebuild: runbooks/dc-dc-teardown-rollback.md + CURRENT-STATE.
- cloud-init apt stall on 3 units (fix): CURRENT-STATE.
- ovn-central LP #2044324 (missing common_name), D-052 amendment (metal-internal), binding sweep: CURRENT-STATE + design-decisions.md + docs/audit/binding-plane-purpose-sweep-20260803.txt.
- MAAS region installed-not-migrated correction: SKILL.md + design-decisions.md D-132 annotation.
- tool-index.md, CLAUDE.md hard rule 4, repo-rebuild-project-brief.md, charm-ip-family-compatibility.md: all committed.

--------------------------------------------------------------------------------------
OWNED (mistakes this session -- the first thing a clear destroys)
--------------------------------------------------------------------------------------
- TWICE asserted an ovn-central cert root cause the evidence did not support: (i) that the
  metal-admin default binding caused it (the rebind did nothing); (ii) implicitly, by ruling
  the D-052 amendment on that premise. The categorization (metal-internal) is right; the
  cert-fix rationale was wrong. Owned in CURRENT-STATE.
- Flagged openstack-dashboard:cluster as a binding deviation; it is D-072/BUNDLEFIX-011, a
  RULED exception documented in a comment right above the line. Caught by reading the bundle
  before applying, NOT by the sweep -- I classified by binding VALUE without grepping the
  governing D-NNN (which CLAUDE.md requires). Nearly reverted a fix that would have killed
  Horizon HTTPS.
- Shipped the D-141 v4 revert without updating the provider-bundle-check harness (F1) -- a
  built-surface change without its companion test reconcile, caught by the gauntlet at close.
- Nested-quote / paren shell errors bit several remote one-liners (harmless, re-run).
- Guard hook blocked two commit MESSAGES (kill-controller, vault-init command names) -- correct
  conservative behaviour; reworded via a message file.

--------------------------------------------------------------------------------------
AMENDED 2026-08-03 (post-bookend, harness-reconcile session) -- F1 CLOSED + 2 follow-ons
--------------------------------------------------------------------------------------
F1 CLOSED: provider-bundle-check reconciled to D-141 (v4-only deploy input). T19 assertion
    REPLACED with the v4-only invariant; T21/T25/T45 re-pointed to a new all-GUA dual.yaml
    fixture (checker unchanged). Gauntlet ALL GREEN (98). Body:
    docs/changelog-20260803-provider-bundle-check-d141-reconcile.md.

FN1 (LOGGED, not fixed). tests/provider-bundle-check DUAL6 constant (run-tests.sh:61) uses
    the ULA family fd50:840e:74e2:220::/221:: for the metal-admin/internal v6 legs -- the
    family D-139 step 6 DEPRECATED (do-not-allocate under D-141). It still validates only
    because step 6 deprecated rather than deleted those /64s and _apex_v6_bands ignores
    NetBox status. So negative controls T22/T23 grade against a retired family while the new
    dual.yaml (FN closed) is on GUA -- the harness holds two notions of "valid dual-family".
    Fix: re-pin DUAL6 to GUA + assert the apex marks the ULA /64s deprecated. Operator to rule.

FN2 (LOGGED, not fixed). overlays/vr1-dc0-vips.yaml GENERATED header still describes
    dual-family legs ("each vip carries the three v4 legs THEN the three v6 legs") over
    v4-only VIP lines -- a renderer/render-values divergence from the D-141 revert. Fix is in
    scripts/render-dc-overlays.py + render/values, not the harness.

FN3 (LOGGED, watch item, advisor-flagged). The dual.yaml builder skips any app whose vip is
    not exactly 3 tokens, so if the overlay is ever re-rendered dual-family, the builder
    silently yields good.yaml unchanged and T21/T45 keep passing while asserting nothing new
    ("a clean zero deserves suspicion"). When D-141 rule-3 promotes v6, make the builder
    ASSERT it appended legs (or drive dual.yaml from the rendered dual overlay directly).
