Question as presented: does Stage 5 deploy vr1-dc0 first -- restoring the phase-4
runbook's own "DC1 first" sequence, whose DC1 IS vr1-dc0 (export DC=vr1-dc0) --
and make DC0 the NOC, or proceed dc1-first as the artifacts assume? Raised after
the operator described the test posture (Office1 as simulated regional office ->
dark fiber to DC0 -> DC0 fully bootstrapped becomes the NOC -> technician at
Office1 pushes a deployment to DC1) and observed those steps were not in the
roadmap.

Operator utterance recorded verbatim in CURRENT-STATE. Effect: no ruled DC
ordering for this deployment, both DCs deploy from voffice1 by the same
procedure, and the NOC-ordering posture moves to the NEXT deployment. The
dc1-first artifact state is therefore no longer a divergence.

Confirmed by measurement: 'NOC' appears nowhere in the live repo, nor does the
technician scenario; D-100 defines the fabric and calls the Office1<->DC fiber
management-only but never states the sequenced test.

The "only differences should be the NetBox assignments" target is nearly right
and its exceptions are the point. NetBox-derived and symmetric: the VIP overlay
is a pure prefix remap. Per-DC but NOT NetBox-derived: the MAAS DC tag, the
per-DC octavia-pki CA overlay, and ovn-chassis bridge-interface-mappings.

That last one is PROMOTED FROM LATENT TO LIVE by this ruling. bundle.yaml:462
carries 52:54:01:d1:04:02 / :05:02 -- measured against lib-hosts.sh, that is
vr1-dc1's pinned MAC scheme, in the file documented as vr1-dc0's source of
truth. dc0's MACs are a different, non-schematic set that cannot be derived from
a pattern. On a dc0 deploy no local MAC matches, ovn-chassis builds no br-ex
mapping, provider egress is dead on dc0 compute, and no gate fails. Harmless
while dc1-first; now certain to be reached. Logged, not fixed (hard rule 1).

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