docs: record resume concurrency guard

docs/current_roadmap.md

@@ -55,10 +55,11 @@ The v1 durable run and resume path exists, including persisted interrupted runs,
 bounded trace reads, dependency revalidation, and process-rebuild resume tests.
 Remaining hardening should focus on correctness under real server use.
 
-- Add same-run concurrency protection around `resume_run`.
+- Completed: same-process `resume_run` calls are serialized per run id.
-  Active implementation plan:
+  Implementation:
-  [`resume run concurrency guard`](superpowers/plans/2026-06-09-resume-run-concurrency-guard.md).
+  [`resume run concurrency guard`](historical/superpowers/plans/2026-06-09-resume-run-concurrency-guard.md).
-- Clarify store-level locking/transaction expectations for filesystem stores.
+- Clarify store-level locking/transaction expectations for future filesystem
+  and transactional stores.
 - Preserve existing semantics: broken pinned dependencies return blocked
   readiness and diagnostics; ordinary live tool/source failures are failed runs,
   not implicit pauses.

docs/superpowers/specs/2026-06-03-persisted-run-resume-contract.md

@@ -192,6 +192,8 @@ Current implementation:
 
 - `WorkflowRunApi.resume_run()` follows this contract for stored interrupted
   runs and blocked dependency validation.
+- Same-process callers are serialized per `run_id` around the restore,
+  dependency validation, runtime resume, and checkpoint write sequence.
 - `restore_interrupted_run()` rejects non-interrupted statuses.
 - `mark_resume_blocked()` updates run summary without writing a checkpoint.
 
@@ -242,10 +244,13 @@ behavior, and checkpoint boundaries.
 
 Current limits:
 
-- The file store uses per-process locking only.
+- `WorkflowRunApi.resume_run()` provides a process-local per-run critical
-- It is appropriate for local/dev/single-process use.
+  section for one API/server process.
-- A long-lived API or multi-worker deployment should use a transactional store
+- `FileRunStore` locks individual file writes only; it does not provide
-  later.
+  compare-and-swap or cross-process transactions.
+- The file store is appropriate for local/dev/single-process use.
+- A multi-worker or cloud deployment still needs SQLite/Postgres or another
+  transactional store before claiming strong concurrent resume safety.
 
 ## Frontend Contract
 
@@ -288,11 +293,9 @@ hardening and frontend durability:
      store to avoid lost writes and weak concurrent resume behavior.
 
 4. **Resume concurrency guard**
-   - Concurrent `resume_run` calls for the same interrupted run should not both
+   - Implemented for same-process API callers through a per-`run_id` async
-     advance from the same checkpoint.
+     critical section in `WorkflowRunApi.resume_run()`.
-   - V1 file store does not provide compare-and-swap semantics.
+   - Cross-process protection remains part of the transactional backend gap.
-   - Active implementation plan:
-     [`resume run concurrency guard`](../plans/2026-06-09-resume-run-concurrency-guard.md).
 
 5. **Protocol-native long-running progress**
    - MCP tasks/progress or an HTTP streaming/event surface should report active