diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index b4dfebc..97035c3 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -916,6 +916,35 @@
   cannot match the real timestamped archive, so it reads as one MISSING + one UNDECLARED.
   Predates this session and is not deploy-blocking. The two credentials added here are NOT
   among its findings.
+  **>>> THE JUJU CONTROLLER IS BOOTSTRAPPED. `vr1-dc0-controller` IS LIVE, 2026-07-30. <<<**
+  Capture `docs/audit/stage5-bootstrap-dc0-20260730.txt` (50 lines, full transcript).
+  **This is the FOURTH attempt and the first to succeed**; the three failures on 2026-07-30
+  were each a real defect at a deeper layer (no client->node L3 path; controller with no
+  default route; `jujud` unable to reach the Office1 MAAS region), and all three are now
+  closed by D-138 + the under-carve fix + D-132 q1 respectively.
+  Run FROM THE dc0 RACK per D-138, against cloud endpoint `http://10.12.8.6:5240/MAAS`,
+  with BOTH constraint flags per the operator ruling and `--bootstrap-base ubuntu@22.04`.
+  **MEASURED RESULT: `juju controllers` -> `vr1-dc0-controller*  admin  superuser  vr1-maas
+  1 model  1 node  HA none  3.6.27`; `juju status -m controller` -> app `controller`
+  **active** 1/1 on charm `juju-controller` rev 311 (channel `3.6/stable`), unit
+  `controller/0*` **active/idle**, machine 0 **started** `ubuntu@22.04`, inst id
+  `subtle-grouse`.** MAAS reads the same machine `arfr7p` as **Deployed ubuntu/jammy**.
+  **WHAT THE TRANSCRIPT PROVES, beyond "it worked":** (i) agent binaries resolved on the
+  FIRST attempt from `streams.canonical.com` -- the 339-retry failure class stays closed;
+  (ii) machine targeting bit again, taking the tagged controller VM and not one of the nine
+  role nodes; (iii) juju tried `10.12.8.5`, `[fd50:840e:74e2:220::5]` AND `10.12.4.5` before
+  `Connected to 10.12.8.5` -- so the v6 leg restored earlier this session is live in MAAS
+  and offered to juju, and the metal-admin leg is what actually carried the SSH; (iv) the
+  controller's `Public address` is `10.12.4.5`, the provider-public leg that supplies its
+  default route.
+  **NEXT, and it is now the bundle itself:** `preflight.sh` for this DC (expected RED on P5
+  only -- ruled-accepted, and note the two NEW dc1 juju rows are NOT covered by that
+  acceptance), then Step 3.5 `add-model` + spaces gate + per-DC artifact source, then
+  Step 4 `juju deploy bundle.yaml` with the `-vips`, `-machines` and `-octavia-pki`
+  overlays. **`bundle.yaml:592`'s `ceph-osd` `tags=openstack` constraint is the known
+  exposure to decide at Step 4.2's `--dry-run`** -- that tag is MEASURED ABSENT from this
+  region too (`maas-role-tags.sh` creates control/compute/storage/juju-controller-* and
+  `dc-region-topology.sh` creates `openstack-vr1-dc0`; no bare `openstack`).
 
 - Project: Omega Cloud, VR1 DC-DC rehearsal -- a two-DC + Office1-headend
   virtual rehearsal on KVM (vcloud host), rehearsing the future bare-metal
diff --git a/docs/audit/stage5-bootstrap-dc0-20260730.txt b/docs/audit/stage5-bootstrap-dc0-20260730.txt
new file mode 100644
index 0000000..7478a27
--- /dev/null
+++ b/docs/audit/stage5-bootstrap-dc0-20260730.txt
Binary files differ
diff --git a/docs/changelog-20260730-dc0-node-carve.md b/docs/changelog-20260730-dc0-node-carve.md
index 009df04..05be3fc 100644
--- a/docs/changelog-20260730-dc0-node-carve.md
+++ b/docs/changelog-20260730-dc0-node-carve.md
@@ -267,3 +267,36 @@
 were all added.
 
 **Revert.** `git checkout <this-commit>^ -- runbooks/dc-dc-phase4-juju-bundle-per-dc.md`.
+
+## Item 8 -- JUJU CONTROLLER BOOTSTRAPPED (fourth attempt, first success)
+
+**What.** `juju bootstrap vr1-maas vr1-dc0-controller --constraints
+"tags=juju-controller-vr1-dc0" --bootstrap-constraints "tags=juju-controller-vr1-dc0"
+--bootstrap-base ubuntu@22.04`, run FROM THE dc0 RACK per D-138. Capture
+`docs/audit/stage5-bootstrap-dc0-20260730.txt`.
+
+**Result, measured.** `juju controllers` -> `vr1-dc0-controller* admin superuser vr1-maas,
+1 model, 1 node, HA none, 3.6.27`. `juju status -m controller` -> app `controller` ACTIVE
+1/1 on `juju-controller` rev 311 (`3.6/stable`), unit `controller/0*` ACTIVE/IDLE, machine 0
+STARTED `ubuntu@22.04`, inst id `subtle-grouse`. MAAS reads `arfr7p` as Deployed
+ubuntu/jammy.
+
+**Why this one worked where three failed the same day.** Each earlier failure was a real
+defect one layer deeper, and all three are now closed by a different fix:
+1. no L3 path from the juju client to any node plane -> **D-138** moved the client into the DC;
+2. the controller VM had NO DEFAULT ROUTE (added after both Stage-4 carves) -> the
+   under-carve fix, now re-applied by `dc-node-carve.sh` as part of the standard carve;
+3. `jujud` could not reach the Office1 MAAS region API -> **D-132 q1**, per-DC regions.
+
+**What the transcript proves beyond "it worked":**
+- Agent binaries resolved on the FIRST attempt from `streams.canonical.com`. The 339-retry
+  failure class stays closed.
+- Machine targeting bit again: it took the tagged controller VM, not one of the nine role
+  nodes. (As before, this run cannot show WHICH of the two ruled flags did the selecting.)
+- Juju tried `10.12.8.5`, `[fd50:840e:74e2:220::5]` and `10.12.4.5` before
+  `Connected to 10.12.8.5`. So the controller v6 leg restored in item 4 is live in MAAS and
+  offered to juju, and metal-admin is what actually carried the SSH.
+- `Public address` is `10.12.4.5` -- the provider-public leg that supplies the default route.
+
+**Revert.** `juju kill-controller vr1-dc0-controller` (the controller API is up this time,
+so unlike attempt 3 this WILL work), then release `arfr7p` in MAAS.