probe(dstamp): race concern CLOSED — Builder harden(e9c26c7) 2-phase StartedAt protocol deterministically distinguishes new update from stale base-deploy state; assessed CORRECT AND COMPLETE

REVIEW-dstamp.md

@@ -126,4 +126,16 @@ with a less specific error ("wait_healthy timeout" rather than "swarm rolled bac
 NOT weakened even if the race fires. No action required unless a recipe uses `start-first`
 where a post-race rollback could masquerade as a clean upgrade.
 
+**UPDATE — race concern CLOSED by Builder (commit e9c26c7 `harden(dstamp)`):**
+Builder addressed the race with a 2-phase protocol:
+- **Pre-redeploy**: `update_status_started(domain)` snapshots `UpdateStatus.StartedAt`.
+- **Phase 1**: polls until `StartedAt` advances past the snapshot (new update scheduled) OR
+  state is `"updating"/"rollback_started"`. 30s grace: if no new update appears → no-op
+  redeploy, nothing to converge.
+- **Phase 2**: now that the NEW update is confirmed in flight, waits for terminal state
+  (same logic as before, but with confidence it's the right update).
+Assessment: **CORRECT AND COMPLETE**. Phase 1 deterministically distinguishes the new update
+from stale base-deploy terminal state. No new failure modes introduced. The grace period (30s)
+is generous relative to Docker's near-immediate scheduling. Race concern fully closed.
+
 **Status:** no `claim(dstamp)` commit yet. Awaiting M1 claim to issue formal verdict.