Session changelog part 3 (part 1 = changelog-20260730-docfix205-d117-annotation.md, part 2 = changelog-20260730-octavia-reissue-tool.md). Branch dc-dc-stage5-preconditions. Status claims live ONLY in docs/CURRENT-STATE.md.
Trigger. The standing operator directive recorded at the 2026-07-30 part-2 close: "we have to continue to juju deployment next session no matter what". This session opens Stage 5 and runs the deployment.
No new D-number (GA-R3). Opening a stage is OPS; the P5 acceptance is an operational gate disposition against existing SEC rows, not architecture. Next-free UNCHANGED: D 138 / DOCFIX 206 / BUNDLEFIX 053.
docs/CURRENT-STATE.md section 1 (the status authority). The six enumerated findings are accepted, known, pre-existing exposure; preflight.sh continues to exit FAIL on P5 for the stage's duration and that RED is ruled-accepted. The acceptance covers those six and nothing else.docs/CURRENT-STATE.md section 1. The executed bootstrap carries BOTH --bootstrap-constraints and --constraints. D-104 is NOT amended; only the flag implementing it is clarified.What. docs/CURRENT-STATE.md section 1 gains the Stage-5 OPEN entry: the branch decision and why, the measured entry gate, the P5 ruling with the question and the operator's exact utterance, and one logged-not-executed finding. New capture docs/audit/stage5-preflight-dc0-20260730.txt (237 lines, DC=vr1-dc0 bash scripts/preflight.sh run ON voffice1, exit 1).
Why (evidence). GA-R1/C1 puts the status change and the document update in one commit; GA-R5 requires the ruling committed and pushed before dependent work. Four read-only checks were made BEFORE putting the question, so it was asked once and asked grounded:
c58bf95, same branch, clean. voffice1 was found on a 105-commit-stale retired branch at the 2026-07-27 close and the "back to main at merge" follow-up never fired, because nothing merged. Verified rather than assumed: a stale clone silently deploys the wrong bundle.bundle.yaml VR1 9-node role-separated; both per-DC -vips/-machines/-octavia-pki overlays present, the PKI pair 0600 and gitignored). This is the standing "RULED IS NOT BUILT -- check the artifact" rule applied to the 2026-07-24 committee record, which is now superseded by measurement.CURRENT-STATE.md:986). There is no ruled DC ordering; dc1-first artifacts are not a divergence.Revert. git revert <this commit> -- it removes the Stage-5 OPEN entry, the recorded ruling and the capture reference. The capture file itself can be deleted separately; it is evidence, not configuration, and nothing reads it. Reverting the ruling does NOT un-ask the question: re-asking would need a fresh GA-R5 exchange.
ceph-osd carries the stale VR0 constraint tags=openstackWhat. bundle.yaml:592. Recorded in docs/CURRENT-STATE.md section 1; no edit made.
Why (evidence). ceph-osd is the ONLY application of 56 carrying a tag constraint -- every other reads arch=amd64 alone (parsed from bundle.yaml, not grepped). The tag is measured ABSENT from the VR1 region: maas admin tags read returns virtual, pod-console-logging, serial-console, openstack-vr1-dc0, openstack-vr1-dc1, control, compute, storage, juju-controller-vr1-dc0, juju-controller-vr1-dc1 -- no bare openstack. Neither machines overlay overrides it (vr1-dc0-machines.yaml is applications:-only and says so).
What is NOT measured, and is labelled as such. ceph-osd has explicit placement (to: ["5","6","7","8"]), so the initial deploy is EXPECTED to place by machine id regardless. The reasoned-not-measured exposure is a later unplaced juju add-unit ceph-osd matching no machine. The real impact is observable at Step 4.2's --dry-run and nowhere earlier, which is why it is recorded now and decided there. Hard rule 1 forbids fixing it mid-step, and the standing rule is that a finding is an observation, not a conclusion.
Revert. Nothing to revert -- no artifact was changed.
What. Not yet assigned a number (next-free DOCFIX is 206; assign at the point of delivery, per the standing numbering rule -- do not write the token above the high-water mark in prose before it exists). Two surfaces state the bootstrap machine is targeted by juju bootstrap --constraints tags=juju-controller-$DC: runbooks/dc-dc-phase4-juju-bundle-per-dc.md:277-278 and the D-104 amendment's "Distinct tag, no role tag" bullet in docs/design-decisions.md.
Why (evidence). Juju 3.6.27's own help, read ON voffice1 rather than from memory, assigns machine-targeting to --bootstrap-constraints and model-defaulting to --constraints (both sentences quoted verbatim in docs/CURRENT-STATE.md section 1). The operator ruled "Use both flags", so the live command is correct; the RUNBOOK is what still reads wrong, and a future DC standup following it literally would get the single-flag form. No gate reads prose, so nothing in this repo can catch it -- the same class as the citation defect the 2026-07-27 audit recorded.
Scope note. The DOCFIX corrects the FLAG only. D-104's decision -- a dedicated per-DC controller VM carrying its own tag and none of the role tags -- is untouched and was independently confirmed live this session: moved-troll (7n87bt) carries juju-controller-vr1-dc0 and no openstack-vr1-dc0.
Revert. N/A -- nothing delivered yet; this item is the record that it is owed.