# 30 -- docs/CURRENT-STATE.md update (SAME COMMIT as item 10)

GA-R1/C1: any commit changing a status CURRENT-STATE carries must update it in the same
commit; repo-lint L10 enforces. GA-R1 rule 2: legal status tokens are OPEN / BLOCKED /
HELD / CLOSED, and only in this file.

Target: the Stage-4 / Phase-3 bullet, lines 173-193 (at bc9a2df; re-locate at 4ed29aa).
It sits in **section 1 "Where the project IS"**, which the 2026-07-25 reconciliation
confirms is authoritative.

WARNING before editing this file -- `docs/audit/decision-recon-20260725.md` found
**section 4 "RULED-BUT-NOT-BUILT" comprehensively STALE (HIGH)**: authored 2026-07-18 and
never updated, with 4 of 5 bullets contradicted by section 1 and by on-disk state -- it
claims DC0 is unbuilt (built/commissioned, G10 CLOSED), dc1 substrate UNBUILT (roots
exist, G12 CLOSED), D-100 netem HELD as a comment (instantiated `main.tf:353`), D-129 qga
not written (shipped, G13 CLOSED). The status authority contradicts itself. Do NOT read
section 4 as current and do NOT reconcile these edits against it -- section 1 and the
gate table in section 6 govern. The section-4 repair is queued and operator-deferred;
this pack does not attempt it.

Also queued from the same record, not addressed here: G14's SEC count says 12 open while
`ledger-scan` reports 15 (adds SEC-017/-018/-019); and
`runbooks/dc-dc-phase4-juju-bundle-per-dc.md:192` still claims the bundle "ships NO
designate", contradicting ADOPTED D-106 and `bundle.yaml:830`.

================================================================================
## Edit 1 -- the RESOLVE-BEFORE-DEPLOY list (currently lines 173-182)
================================================================================

Item (a) TEXT FIX plus scope widening. It currently reads "D-036 says vault carries
VIPs" -- wrong decision (this is DOCFIX-NNN (A); see item 40) -- and "needs a dc1-band
VIP overlay", which ruling 3 widens to both DCs:

  (a) **vault VIP** -- vault is scaled to 3 with `vault-hacluster` at `cluster_count: 3`
      but carries NO `vip:` anywhere in the tracked tree, so hacluster has no VIP
      resource to manage and `vault:secrets` consumers resolve to a unit address.
      **D-020** (not D-036) lists vault among the applications carrying provider+metal
      VIPs. Needs a per-DC VIP in the symmetric overlay shape (ruling 3) plus the
      vault-HA VERIFY-LIVE. Tenant-facing: `barbican-vault` is a `vault:secrets`
      consumer and barbican holds tenant secrets plus Octavia's TLS material.

Item (b) is RESOLVED by ruling 1 -- replace it:

  (b) **address family: RULED 2026-07-25.** Dual-stack where IPv4 is required, IPv6-only
      where IPv6-only is sound (D-101's matrix), for BOTH DC0 and DC1 in this
      deployment. The v4-only phasing option is closed. Consequence: the
      `vr1-dc1-vips` / `dc-dc-ipv6-family-matrix` per-key REPLACE collision must be
      reconciled to ONE dual-family `vip` per app per DC before deploy -- it is no
      longer deferrable. Octavia's family remains an OPEN sub-ruling (`lb-mgmt` IPv6
      has live upstream breakage; see D-NNN open question 2).

Add item (c):

  (c) **per-DC artifact shape: RULED 2026-07-25.** `bundle.yaml` becomes VIP-free
      (topology only); every per-DC value arrives via overlay, dc0 included. dc0's VIPs
      extract from base into `overlays/vr1-dc0-vips.yaml`.

Add to the VERIFY-LIVE gate list (ruling 2):

  `juju status` shows `PO:` on EVERY keystone unit after scale-up, never `PO (broken):`.

================================================================================
## Edit 2 -- the NetBox-coupling bullet (currently lines 185-190)
================================================================================

It currently reads "being scoped as a new PROPOSED D-number (next-free per ledger-scan)
in Chat ... Prompt handed to the operator 2026-07-24." Replace with the outcome:

  - **NetBox->deploy coupling: PROPOSED as D-NNN (Chat, 2026-07-25).** A per-DC
    renderer generating overlays and tfvars from the NetBox record, recommending option
    (C) -- build the values-file back half now for both DCs, add the NetBox front half
    for Roosevelt. Does NOT gate the dc1 deploy. Mechanism awaiting operator ruling.
    The target OPERATING MODEL (NetBox draft -> approval on the rendered diff -> apply
    -> bounded self-healing) is PINNED for a dedicated planning session, not ratified.

================================================================================
## Edit 3 -- correct a stale claim in the same bullet
================================================================================

The FOLLOW-UP line asserts `cloud-assert.sh` "false-passes decorative HA on the 12
scaled API services". Keep it -- it is accurate and is what the D-NNN per-hacluster
VIP-owned check closes. But note in the same bullet that D-111 is ADOPTED, so no
subcarve trust gate exists on the v6 values (they are imported for both DCs and
verifiable in `netbox/draft/vr1-office1-current-20260725.json`). This forecloses a live
analysis error: the Chat seat briefly treated the subcarve as an open blocker on the
strength of `docs/dc-dc-netbox-buildout-scope.md` section 5, which is stale -- that is
DOCFIX-NNN (B).

================================================================================
## Verification
================================================================================

  bash scripts/repo-lint.sh     # L10 must pass: status change + CURRENT-STATE, same commit
  grep -nE "OPEN|BLOCKED|HELD|CLOSED" docs/CURRENT-STATE.md | sed -n '1,5p'
                                # status tokens only here, per GA-R1 rule 2