DOCFIX-208 part 2: the dry-run graded the gate, and three items could not fail ...

The corrected dc0 command dry-ran EXIT 0 from the dc0 rack against an empty
vr1-dc0 model, staged input sha256-verified against HEAD first. Nine machines
0-8, all nine constraints tags=openstack-vr1-dc0,<role> in the 3/2/4 split,
all three overlays consumed. Capture: docs/audit/stage5-dryrun-dc0-20260802.txt.

The run also measured what the command can and cannot show. juju deploy
--dry-run on a bundle prints NO application options and NO VIPs at any
verbosity; --debug adds only the per-machine constraint lines. Greps over the
--debug capture: bridge-interface-mappings 0, physnet1 0, openstack-origin 0,
cloud-archive 0, prefer-chassis 0.

So three Step-4.2 gate items could not be graded by the command the gate names:
item 1 (tags) needed --debug, which is now in the named command; the
PRE-EXISTING VIP item could never have failed because no VIP is ever in the
plan, and its property is relocated in writing to preflight P2; and the two
option-reading items I added earlier this session had the same defect and are
removed within the hour. Their properties become new Step 4.4 -- a juju config
read run the moment deploy returns, which is the only thing that can prove
juju merged the options map rather than replacing it.

Both machines overlays' VERIFY-LIVE headers said to assert this "at the live
dry-run". Measured impossible; corrected in place, pointed at 4.4.

Also settles the deferred ceph-osd tags=openstack item (placed by explicit
placement, bare tag absent from the plan) and logs a contradiction not resolved
here: the runbook says the bundle ships NO designate, the plan deploys four
designate applications.

The deploy itself is NOT run -- 4.3 is a gated mutation.

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

3.8 fixed per-DC -- and the fix exposed two repo records naming the wrong NIC ...

bridge-interface-mappings is out of bundle.yaml and per-DC in overlays/vr1-dc0-machines.yaml
(new) and vr1-dc1-machines.yaml. The machines overlay was chosen over the vips overlay for a
measured reason: both *-vips.yaml are marked GENERATED / do-not-hand-edit, so a key added
there is clobbered on the next render, and preflight.sh already assembles ${DC}-machines.yaml.
Creating the dc0 file also closes NEW-3 from the other side -- preflight's [ -f ] guard was
silently skipping a file the deploy needs.

THE WORSE DEFECT THE FIX EXPOSED. dc0's compute provider-public MACs are 52:54:00:8c:2a:8c /
52:54:00:50:48:88 -- position [1] in each node's macs list. Audit register row U5 and the
D-124 correction both name the [0] values, which are the PXE/boot MACs, and D-124 further
tells the reader to source them "from lib-hosts.sh" -- verified independently: lib-hosts.sh
declares only HOST_BOOT_MAC and cannot supply a provider MAC at all. Following either record
would have bridged br-ex onto the boot NIC: not a missing mapping that fails loudly, but a
wrong one that comes up and misbehaves. Confirmed three ways -- substrate main.tf:109-116 list
order, the macpin plan capture, and live MAAS showing br-ex over enp2s0. The correct values
and the [0]-vs-[1] trap are now recorded in the overlay, next to the data.

NEW-1: 10.12.12.0/22 was named as the geneve/DATA plane; that is metal-internal, data-tenant
is 10.12.16.0/22. Deliberately not swept repo-wide -- the 10.12.12.5x VIP legs are correct
metal-internal values.

NEW-2 phantom vr0-dc0-testcloud.yaml removed. NEW-4/6 stale octavia-pki name and the phantom
${DC}-hostnames.yaml removed (juju errors on a missing overlay). NEW-7 scale-up removed from
the VIP deploy command per R6, ${DC1_MODEL} -> ${DC_MODEL}.

R5/D-106 BUILT: phase-6 Step 5 rewritten configure-not-deploy, the unsatisfiable diff gate
replaced by a presence-and-state assertion, and the "no designate block exists" claim
corrected against bundle.yaml. os-public-hostname stays unset, per the ruling's refused
option (c).

Verified independently rather than from reported output: provider-bundle-check PASSes for
both DCs in preflight P2's own overlay order. repo-lint 0 fail / 617 files.

Logged not fixed: provider-bundle-check treats an absent bridge-interface-mappings as a silent
skip and never checks the MAC prefix against --dc, so it could not fail on either variant.

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

vr1-dc1 bundle render (9-node role-separated) + expansion review record ...

Render (committee Fork-2 hand-render), validated by the extended checker:
- bundle.yaml: machines "8"-"11" (tags=openstack) -> "0"-"8" role+DC tags (block
  style); every `to:` re-homed (quorum trio -> control 0/1/2; nova-compute 3->2 on
  compute 3/4; ceph-osd -> storage 5-8; scaled apps + utilities -> control);
  ovn-chassis -> the 2 dc1 compute provider MACs (52:54:01:d1:04:02/05:02).
- overlays/vr1-dc1-machines.yaml (NEW): per-DC retag (machines-overlay merge is
  VERIFY-LIVE at `juju deploy --dry-run`).
- overlays/dc-ha-scaleup.yaml: tokens rendered to logical control ids 0/1/2
  (DC-neutral); header updated; stale ceph-osd-3 comment -> 4.
- provider-bundle-check.py: ovn-chassis MAC check skips the VR0 Pattern-A set on a
  role-separated bundle (the validator CAUGHT a real YAML flow-comma render bug).

Validated: base + FULL dc1 deploy input (3 overlays, --dc vr1-dc1) PASS; harness
15/15; gauntlet ALL GREEN (78); repo-lint 0-fail.

Expansion review (3 read-only reviewers) recorded in
docs/audit/stage5-expansion-review-20260724.md: relations/bindings/subordinates
HOLD under role-sep (uniform 6-NIC, SEC-011); no channel/pin change; open
resolve-before-deploy items (vault VIP, v4-vs-dual-stack phasing) + deploy-gate
script gaps + VERIFY-LIVE gates. NetBox->deploy coupling routed to Chat as a new
PROPOSED D-number (Fork-2 escalation). No cloud state mutated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUjEb7onHpdqFHUnio6iVw