40 -- Items for the CURRENT session changelog

GA-R2/D1: ONE changelog per session -- append these to Code's existing session changelog. Do NOT mint per-topic changelog files. The changelog IS the review surface: every item states what, why (evidence), and how to revert. Changelogs are session-scoped scratch, consolidated at stage close, never citable as status or decision authority.

================================================================================

ITEM -- D-NNN PROPOSED: NetBox-coupled per-DC render pipeline [ARCH]

================================================================================

WHAT: appended the PROPOSED entry to docs/design-decisions.md; updated the Stage-4 bullet in docs/CURRENT-STATE.md in the same commit (C1).

WHY: escalates the Fork-2 renderer deferral (docs/audit/committee-20260724-track2-bundle-render.md) to a NetBox-coupled generator. Evidence for the problem statement is measured at bc9a2df, not asserted: four disagreeing app-to-VIP lists; two overlays owning vip: for the same 10 applications under per-key REPLACE; no vip: for vault anywhere in the tracked tree against vault-hacluster cluster_count: 3; and the pull/cannot-pull inventory taken from netbox/draft/vr1-office1-current-20260725.json (139 prefixes with scope_site on 92; four ip-addresses, none a VIP; no dcim/interfaces; no ipam/vlans).

REVERT: git revert <commit> -- the entry is append-only text plus the CURRENT-STATE bullet; no behavioural surface changes. PROPOSED, so nothing downstream depends on it.

================================================================================

ITEM -- DOCFIX-NNN (A): the dual-VIP decision is D-020, not D-036

================================================================================

WHAT: corrected four live citations of D-036 where D-020 is meant.

docs/CURRENT-STATE.md:175 "... anywhere; D-036 says vault carries VIPs; needs a dc1-band VIP overlay ..." docs/audit/stage5-expansion-review-20260724.md:74 "... when vault was de-HA'd. D-036 lists vault among the apps carrying provider+metal VIPs." docs/design-decisions.md:3425 "already carries all 12 hacluster subordinates and, per D-036, both provider+metal VIPs on every ..." docs/design-decisions.md:3541 "D-036 (dual VIPs, already present), D-062 (mysql-at-3), ..." docs/audit/decision-recon-20260725.md:116 (NEW -- created 2026-07-25) "... rendered vault (no vip) vs D-036 ..." docs/audit/decision-recon-20260725.md:121 (NEW -- created 2026-07-25) "... cloud-assert --capture vs D-121 HA / D-036 vault / D-108 ..."

ESCALATION: the two sites above did not exist when this DOCFIX was drafted. The reconciliation record created on 2026-07-25 propagated the mis-citation into a brand-new artifact, taking the live count from four to SIX. The error is actively spreading through new work, which raises this from bookkeeping to a fix worth doing before the next audit record is authored.

WHY: docs/design-decisions.md:392 is ## D-020: Dual provider + metal API VIPs on clustered charms. :498 is ## D-036: magnum-capi-helm driver / chart / CAPO coherence (resolved) -- nothing to do with VIPs. The error has already escaped the repo: it appeared in the design brief handed to the Chat seat. It also masked substance -- reading the correct decision is what surfaced that D-020's ratified set includes vault and excludes ceph-radosgw, while the deployed set does the exact opposite (one substitution, unrecorded in either direction).

DO NOT TOUCH: docs/design-decisions.md:462, 498, 516, 530, 599, 1182; runbooks/phase-07-conductor-graft.md:13; runbooks/phase-08-workload-cluster-acceptance.md:10; anything under docs/archive/. Those eight are correct driver/chart/CAPO references.

OPERATOR CHOICE BEFORE EDITING SITE 2: stage5-expansion-review-20260724.md is a dated audit record. Either (a) correct in place with a bracketed marker "[corrected DOCFIX-NNN: D-020, not D-036]" -- recommended, since the document is a live design signal still being consumed -- or (b) leave the record verbatim and add a correction note at the head. Do not let this be chosen silently.

VERIFY: git grep -n "D-036" -- ":!docs/archive" -- expect 8 hits, all driver/chart context, zero in VIP context.

REVERT: git revert <commit> -- text-only across three files, no behavioural effect.

================================================================================

ITEM -- DOCFIX-NNN (B): buildout-scope section 5 contradicts adopted D-111

================================================================================

WHAT: demoted docs/dc-dc-netbox-buildout-scope.md section 5 item 1 from an open sub-decision to a pointer at D-111. Sites: line 5 ("(candidate D-111+; assign via ledger-scan at adoption)"), line 132 (the section heading "Sub-decisions requiring operator ratification (candidate D-111+)"), line 138 ("script's OWN proposal, explicitly un-ratified").

WHY: ## D-111: VR1 per-DC v6 subcarve aligned to the deployed NN mnemonic carries **Status:** ADOPTED 2026-07-11 and names the very scope-doc sub-decision it ratifies. The scope doc was never updated to point back, so it has read as open for two weeks. Not cosmetic: it caused a live analysis error on 2026-07-25 -- the Chat seat recommended treating the subcarve as a blocking trust gate on the v6 values and withdrew the recommendation only after reading the register. Ratified state belongs in one place.

Keep the reasoning below the pointer as history -- the two conflicts recorded there are why D-111 chose NN-mnemonic alignment. Audit the REST of section 5 the same way: check each remaining item against the register before leaving it as open.

VERIFY: bash scripts/ledger-scan.sh -- D-111 must not appear under PROPOSED/OPEN; grep -n "un-ratified\|candidate D-111" docs/dc-dc-netbox-buildout-scope.md -- no hit presenting the subcarve as open.

REVERT: git revert <commit> -- single-file text change, no behavioural effect.

================================================================================

ITEM -- three operator rulings recorded (GA-R5)

================================================================================

WHAT: recorded the 2026-07-25 rulings on address family, the keystone policy-override VERIFY-LIVE gate, and per-DC artifact shape. Each carries its question and the operator's exact utterance, per item 20 of the handoff pack.

WHY: GA-R5 -- dependent work is invalid until the ruling is committed and pushed. The artifact-shape ruling gates the dc0 VIP extraction; the family ruling gates the reconciliation; the VERIFY-LIVE ruling adds a Stage-4 gate row.

REVERT: git revert <commit> per ruling. Reverting a ruling record invalidates the work that depends on it -- revert dependents first.

================================================================================

ITEM -- DOCFIX-NNN (C): D-134's superseded band table carries no in-place marker

================================================================================

WHAT: mark the ORIGINAL D-134 band table as superseded, in place, at docs/design-decisions.md (the table under ## D-134:, above ## D-134 -- AMENDMENT (2026-07-23)).

WHY: the amendment's header says it supersedes the original table, but the original table itself carries no marker. A reader who greps D-134 and reads the first table gets SUPERSEDED bands -- control .10-.19, compute .20-.49, storage .201-.254 -- instead of the authoritative contiguous table (.4-.49 utility, .50-.99 VIP, .100-.200 nodes, .201-.254 dynamic). The Chat seat did exactly this on 2026-07-25 and was one read away from flagging a false discrepancy against the reconciliation record, which quotes the amendment correctly. Anyone authoring the band-modelling tool from prose is in the same trap, and the bands are precisely what the coupling must model.

Suggested minimal fix: a **SUPERSEDED by the 2026-07-23 AMENDMENT below -- do not use these bands.** line immediately above the original table. Do not delete it; the original is the record of what the operator rejected and why.

VERIFY: awk from ## D-134: to ## D-134 -- AMENDMENT shows the marker before the first table row.

REVERT: git revert <commit> -- single-line text addition, no behavioural effect.