diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index 1e326cc..e73ce22 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -1699,6 +1699,48 @@
   Gauntlet **ALL GREEN (87) on vcloud** (was 86); repo-lint 0 fail / 614 files; `preflight`
   verdict unchanged in kind (2 fatal -- the absent octavia-pki secret, MAAS unreachable from
   vcloud).
+- **BOTH REMAINING STAGE-5 BLOCKERS AUTHORED 2026-07-29 (NOT APPLIED), R1 PRECONDITION 3
+  VERIFIED, and the Octavia merge question RESOLVED.** Changelog items 31-34; capture
+  `docs/audit/r1-precondition3-verify-20260729.txt`.
+  **OCTAVIA -- CLEAN NEGATIVE, no defect.** The chain audit flagged that `octavia-pki.yaml`
+  lands LAST and writes the same `applications.octavia.options` map as the vips overlay, so
+  under REPLACE semantics octavia would lose `vip` + `prefer-ipv6` with every offline gate
+  green. Researched against SOURCE (the docs are silent on merge mechanics): juju 3.6 pins
+  `charm v12.1.1`, whose `mergeStructs` does `dstMap.SetMapIndex(srcKey, srcMapVal)` PER KEY
+  for map-kind fields, and `ApplicationSpec.Options` is a Go map. **DEEP-MERGE -- both
+  overlays' keys survive.** The merge path is byte-identical 2.9 -> 3.6. This also makes
+  `provider-bundle-check`'s "MIRRORS juju's documented merge" comment SOURCED rather than
+  assumed. **Logged: LP #2002371 (Triaged/High, unfixed) -- an EMPTY/null `options:` key
+  WIPES the base map instead of merging; our overlays lack that shape and nothing gates it.**
+  **R1 AUTHORED:** `modules/node-vm` gains `osd_disk_size_bytes` (default 0 = creates
+  nothing; volume `count`-gated, disk entry appended via `concat`), so an opted-out node has
+  no extra resource and NO plan diff -- precondition 4 verbatim. Four storage nodes per DC
+  set `osd_gib = 500`: **8 volumes, not 18**. 500 GiB is D-121's own budgeted figure
+  (`4x500Gi/DC = PASS, 5.31 TiB margin`); D-121 records that footprint as an ASSUMPTION
+  pending an OSD-sizing decision, so it is evidenced but not separately ruled.
+  **D-104 AUTHORED:** a 10th keyed entry per root, `<dc>-juju-01`, planning **1 add /
+  0 change / 0 destroy**; the nine role nodes untouched. 8 GiB / 4 vCPU are the values the
+  capacity gate actually modelled; disk 100 GiB is the authoring value the amendment left
+  open. **MACs deliberately EMPTY** -- correct only pre-enlistment, and they MUST be pinned
+  from measurement after the first apply or this reproduces the 2026-07-21 trap.
+  **R1 PRECONDITION 3 IS NOW ANSWERED, read-only from voffice1.** Baseline measured: 18
+  Ready nodes, 7 interfaces, **12 static links each** (6 planes x 2 families). **MAAS 3.7's
+  commission API carries `skip_networking`** -- "Whether to skip re-configuring the
+  networking on the machine after the commissioning has completed" -- so the DEFAULT
+  reconfigures, which is exactly the flagged risk, and `skip_networking=1` with
+  `skip_storage` UNSET preserves the network while re-scanning storage so the new
+  `/dev/vdb` enters inventory. And the tofu change does NOT touch NICs: both inner roots
+  plan **6 add / 4 change / 0 destroy**, the four in-place diffs change `devices.disks`
+  ONLY, and a grep for mac/interface across the whole diff returns one hit, inside the NEW
+  `juju-01` CREATE block. **NOT OVERCLAIMED: a clean plan was necessary but NOT sufficient
+  on 2026-07-20, when a 0/9/0 in-place apply regenerated every MAC** -- so the ruled
+  sequence puts a `virsh domiflist` MAC verification BETWEEN the apply and the
+  re-commission; that incident became fleet-wide precisely because MAAS was told to
+  re-commission while its records were already stale.
+  **NEITHER APPLY HAS BEEN RUN.** `opentofu-validate` PASS on both roots.
+  **FLAGGED, not blocking: dc0 `/var/lib/libvirt` has 2.0T available against 4 x 500 GiB =
+  2.0 TiB nominal.** Thin-provisioned so creation is nearly free, but there is no room for
+  those OSDs to FILL. dc1 has 2.9T.
 - **THREE PLATFORM BEHAVIOURS GRADUATED to `references/platform-traps.md`** at session close,
   having been recorded only in this status document (which is consolidated over time, so a
   durable trap does not belong here alone): MAAS auto-reserves `::1`-`::ffff:ffff` on EVERY