docs: record surgical-deploys docker-dev live gate (PASSED) + correct rename-vs-identity rebuild wording

CLAUDE.md

@@ -140,7 +140,10 @@ is still default-closed; what changed is which deltas it whitelists.
 
 - **Still a full rebuild:** an **alarm-bearing** raw-tag delta (`Alarm != null` on either
   side — the WP4 guard: only a rebuild clears and re-wires native-alarm notifiers), an
-  **identity** change on a raw tag (`TagId`/`DriverInstanceId`/`Name`/`ParentNodeId`/`Realm`),
+  **identity** change on a *paired* raw-tag delta (`TagId`/`DriverInstanceId`/`ParentNodeId`/`Realm`
+  — pairing is by RawPath, so this guard catches a tag deleted and re-created under the same path;
+  a plain **rename never pairs** and is served surgically as remove-one-node + add-one-node with any
+  referencing UNS mirror re-pointed, live-gated 2026-08-15),
   a raw **container** (Folder/Driver/Device/TagGroup) rename or removal, `ChangedEquipment` /
   `ChangedAlarms`, a non-surgical equipment-tag delta, and anything else the
   `with`-equality whitelist does not name (including any FUTURE field).

docs/plans/2026-08-15-surgical-deploys.md

@@ -378,3 +378,34 @@ from the Direct apply path, but the boot/restore path still reads the artifact a
 publish actor a bytes-less `RebuildAddressSpace`, which re-reads it. That is **one** extra SQL read per
 node restart — not per apply — which is why it was left out of scope. Threading `appliedBlob` through
 `RestoreApplied` the same way `ApplyAndAck` now does would finish the job.
+
+## Live gate — PASSED (docker-dev, 2026-08-15)
+
+Run against the local docker-dev rig (6 nodes, image rebuilt from merged master `169ee6a4`), with the
+value-pipeline-batching branch included. Every leg green:
+
+1. **Boot back-compat (gzip sniff):** all six nodes restarted on the new image over a pre-upgrade
+   *uncompressed* `ArtifactBlob` and restored the full 73-node address space from it (`PureAdd, added=73`).
+2. **First post-compression deploy re-hashes + gzips:** deploy `e869a136` produced a new `RevisionHash`
+   for identical config (the documented one-time re-dispatch) and a 7,173-byte blob starting `1F 8B`
+   (previous uncompressed blob: 28,742 bytes — ~4×). All six nodes fetched over the config-serve stream
+   (1 chunk), applied (empty plan — no address-space churn), acked, sealed. Data-plane authority still
+   installed (generation 2) on the empty-plan path.
+3. **Surgical UNS-reference add mid-subscription:** with 17 monitored items open across 4 sessions
+   (raw pymodbus subtree, two UNS mirrors, one Sql-driver tag), adding a `UnsTagReference`
+   (`press1` → `Probe0`) and deploying (`318f04c8`) applied with `rebuild=False, added=1,
+   surgicalRawTags=1` (the backing tag's `ReferencingEquipmentPaths` updated in place) and one-node
+   subset materialisation. **Zero items ever went Bad; all ended Good; all received updates.** The new
+   node `ns=3;s=gate481/line1/press1/Probe0` served Good immediately. A DevSql value change written
+   *after* the surgical apply streamed into the pre-deploy subscription (42.5 → 777.25, both Good) —
+   the batched pipeline stayed live end to end.
+4. **Rename contra-test:** renaming a raw tag (deploy `e691615d`) applied as `AddRemoveMix, added=1,
+   removed=1, unsRefDeltas=1, rebuild=False` — a rename never pairs as a `RawTagDelta` (pairing is by
+   RawPath; the delta identity guard is for same-path re-creates), so it is served surgically with a
+   blast radius of exactly the renamed node + its re-pointed referencing mirror. Both new NodeIds served
+   Good. CLAUDE.md's "identity change ⇒ rebuild" wording was corrected to match.
+5. **Revert deploy** (`5848e289`) sealed clean, all six acked, original nodes restored.
+
+Not covered by this gate: site-node `FetchAndCache` flip (rig stayed in its default modes), alarm-bearing
+surgical ratchet (no native-alarm tag on the rig), and load-scale batching throughput (single-tag cadence
+only).