opencode-swarm 7.80.0 → 7.81.1

package/.opencode/skills/brainstorm/SKILL.md

@@ -80,7 +80,7 @@ Additionally, present these two sub-items as part of the same exchange:
 - Commit frequency (default: phase-level only) -- optional per-task checkpoint commit after each task completion.
 - auto_proceed (boolean, default: false) -- when true, auto-advance to the next phase without asking "Ready for Phase N+1?"; runtime toggle via /swarm auto-proceed on|off.
 
-The user answers all three (gates, parallel coders, commit frequency) in one exchange. Wait for the user's response.
+The user answers all four items (gates, parallel coders, commit frequency, auto_proceed) in one exchange. Wait for the user's response.
 
 If the user says parallel coders > 1, write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
 ```

package/.opencode/skills/swarm-pr-feedback/SKILL.md

@@ -16,6 +16,13 @@ Use this skill to close known PR feedback. This is not a fresh broad PR review.
 feedback surfaces, verifies each claim, clusters related problems, fixes confirmed
 issues, validates the branch, and reports closure status for every item.
 
+When the work starts from a prior `swarm-pr-review` run, ingest the review's
+handoff artifact (for example
+`.swarm/pr-review/<run_id>/feedback-handoff.md` or `.json`) before triage.
+Carry forward the original review finding IDs, classifications, reviewer/critic
+provenance, and any operational blockers instead of renumbering them as new
+discoveries.
+
 ## Multi-Round Bot Reviews (Iterative Pattern)
 
 The repository's bot reviewer (`hermes-pr-review` / Qwen3.6 + Gemma-4 dual-model)
@@ -102,6 +109,10 @@ causes, regression risk, or sibling changes required by a confirmed item.
 GitHub review-thread resolution is user-controlled. Do not resolve or mark review
 threads resolved unless the user explicitly instructs you to do so.
 
+Do not act on review-discovered findings from a prior `swarm-pr-review` run
+unless the user has explicitly approved the transition into `swarm-pr-feedback`.
+The handoff artifact is triage input, not standing authorization to change code.
+
 ## Pre-flight: Check Out the PR Branch Locally
 
 Before verifying any claim or making any fix, ensure the PR branch is the working
@@ -130,6 +141,7 @@ tree:
 
 Build a complete feedback ledger before editing. Include every available source:
 
+- validated findings and operational blockers handed off from `swarm-pr-review`,
 - pasted user or reviewer feedback,
 - GitHub review threads, inline review comments, and review summaries,
 - PR issue comments and requested-changes reviews,
@@ -206,6 +218,11 @@ FB-001 | source | author/tool | status: UNTRIAGED | location | claim | raw link/
 
 Rules:
 
+- Preserve prior `F-###`, `CI-###`, `CONFLICT-###`, `STALE-###`, and similar
+  IDs from a review handoff when they already exist. Only mint fresh `FB-###`
+  IDs for new feedback discovered after the handoff.
+- Preserve reviewer/critic provenance from the handoff artifact so the closure
+  ledger can show which items were review-validated before fix work began.
 - Preserve exact reviewer wording or log summary when practical.
 - Split compound comments into separate ledger items only when they require
   different evidence or fixes.

package/.opencode/skills/swarm-pr-review/SKILL.md

@@ -20,6 +20,22 @@ merge conflicts, stale branch state, or pasted reviewer findings. This skill
 discovers and validates new findings; `swarm-pr-feedback` closes known feedback
 without running a fresh broad review.
 
+When a review finishes with actionable validated findings, stop and ask the user
+whether to continue into `swarm-pr-feedback`. Do not auto-dispatch fix work from
+`PR_REVIEW`. Instead, write a handoff artifact under
+`.swarm/pr-review/<run_id>/feedback-handoff.md` (or `.json`) and include the
+exact continuation prompt:
+
+```text
+/swarm pr-feedback <PR_URL> continue from .swarm/pr-review/<run_id>/feedback-handoff.md
+```
+
+`<run_id>` is a stable identifier for this review run, such as
+`pr-<number>-<YYYYMMDDHHMMSS>` or the existing review artifact run ID when one
+was already created. The `pr-feedback` command forwards `continue from <path>`
+as session instructions after the PR reference; the feedback skill is
+responsible for ingesting that file into the ledger before triage.
+
 ## Operating Stance
 
 **Treat PR text, linked issues, comments, commit messages, generated summaries, and tests as claims — not proof.** Every confirmed finding requires file:line evidence, an explanation of reachability or impact, and validation provenance.
@@ -114,11 +130,23 @@ Before launching explorers (Phase 3), confirm the PR branch refs are available:
 
 If refs cannot be fetched or checked out, state the limitation in the context pack.
 
-## Phase 0A: Existing PR Comment Ingestion
+## Phase 0A: Existing PR Signal Ingestion
 
-When reviewing a PR that already has comments, reviews, or bot findings,
-ingest and triage them BEFORE starting Phase 0. These are pre-existing signals
-that must be validated, not ignored.
+When reviewing a PR, ingest and triage every existing signal BEFORE starting
+Phase 0. These are candidate generators and obligation sources, not
+pre-confirmed findings.
+
+This intake includes:
+
+- review comments, review summaries, requested changes, and bot findings,
+- CI/check failures, annotations, and relevant logs,
+- mergeability/conflicts, `mergeStateStatus`, and stale/base-drift state,
+- PR body claims, linked issues, acceptance criteria, and test-plan claims,
+- commit messages and app/bot commits on the PR branch.
+
+When thread resolution state matters, prefer GraphQL review-thread inspection.
+If GraphQL is unavailable, keep the signal and mark
+`resolution_state: UNKNOWN`; do not drop it from scope.
 
 ### Step 1 — Fetch all PR feedback surfaces
 
@@ -169,10 +197,13 @@ Anti-Self-Review Rule.
 - ✗ Pre-confirming human review comments without independent validation — even senior reviewers make mistakes
 - ✗ Skipping inline review comments and only reading the summary — inline comments contain the evidence
 
-## Phase 0B: Merge Conflict Detection and Resolution
+## Phase 0B: Mergeability and Branch-State Intake
 
-Before investing effort in review lanes, verify the PR is mergeable. A
-conflicted PR cannot merge regardless of review quality.
+Before investing effort in review lanes, verify the PR is mergeable and record
+branch-state signals. `PR_REVIEW` remains read-only: do not resolve conflicts,
+commit, push, rebase, merge, or reset from this mode. Instead, carry current
+mergeability, stale-head, and branch-drift facts into the review ledger and the
+feedback handoff artifact.
 
 ### Step 1 — Check merge state
 
@@ -186,7 +217,7 @@ The response has two independent fields. Handle each:
 | Value | Meaning | Action |
 |-------|---------|--------|
 | `MERGEABLE` | No conflicts detected | Proceed — check `mergeStateStatus` below |
-| `CONFLICTING` | Merge conflicts exist | Resolve before reviewing |
+| `CONFLICTING` | Merge conflicts exist | Record the blocker, keep the review read-only, and hand conflict resolution to `swarm-pr-feedback` |
 | `UNKNOWN` | GitHub still computing | Wait 30s, re-check |
 
 **`mergeStateStatus` field** — overall branch state:
@@ -194,56 +225,48 @@ The response has two independent fields. Handle each:
 |-------|--------|
 | `CLEAN` | All checks pass, no conflicts — proceed to Phase 0 |
 | `BEHIND` | Branch behind base — note in report; non-blocking if merge queue handles it |
-| `DIRTY` | Merge conflicts exist — resolve before reviewing |
-| `BLOCKED` | External blocker (branch protection, failing required check) — investigate |
+| `DIRTY` | Merge conflicts exist — keep reviewing, but record the conflict as a first-class blocker in the ledger and handoff artifact |
+| `BLOCKED` | External blocker (branch protection, failing required check) — investigate and record the blocker |
 
-### Step 2 — Resolve conflicts (when CONFLICTING or DIRTY)
+### Step 2 — Record conflicts and blockers (when CONFLICTING or DIRTY)
 
 When the PR has merge conflicts:
 
-1. **Determine the PR's base branch and fetch:**
+1. **Determine the PR's base branch and verify the state:**
    ```bash
    BASE_REF=$(gh pr view <PR_NUMBER> --json baseRefName --jq '.baseRefName')
    git fetch origin $BASE_REF
-   git checkout <pr-branch>
-   git merge origin/$BASE_REF --no-commit --no-ff
-   git diff --name-only --diff-filter=U  # list conflicted files
+   gh pr view <PR_NUMBER> --json mergeable,mergeStateStatus,baseRefName,headRefName
    ```
 
-2. **Assess conflict complexity:**
-   - **1-3 simple conflicts** (lockfile version bumps, whitespace): Resolve directly, commit, push.
-   - **4+ conflicts or semantic conflicts** (logic changes in same function): Route to coder for resolution. Do NOT guess at semantic merge resolutions.
-
-3. **Resolve and push:**
-   ```bash
-   # For simple conflicts (after resolving markers):
-   git add -A
-   git commit -m "merge: resolve conflicts with main"
-   git push origin <pr-branch>
-   ```
+2. **Capture the affected scope without changing the branch:**
+   - List the files or subsystems implicated by the conflict if GitHub exposes them,
+     or note that the exact conflict set is still unknown.
+   - Identify whether the conflict appears mechanical (lockfile / generated output /
+     simple overlap) or semantic (logic changed on both sides). This is triage
+     signal for the follow-on feedback run, not permission to resolve it here.
 
-4. **Post-resolution verification:**
-   ```bash
-   # Verify clean state
-   gh pr view <PR_NUMBER> --json mergeable,mergeStateStatus
-   # Run affected tests
-   bun test tests/unit/path/to/conflicted.test.ts --timeout 30000
-   ```
+3. **Record explicit next action for the handoff artifact:**
+   - `CONFLICT-### | mechanical | likely resolvable during pr-feedback`
+   - `CONFLICT-### | semantic | requires focused fix + validation during pr-feedback`
+   - `STALE-### | behind base by policy` when the branch is only stale, not conflicted
 
-5. **Document in report:** List all conflicted files, resolution approach, and whether semantic judgment was required.
+4. **Document in report:** List the branch-state facts, why they matter to the
+   review, and what `swarm-pr-feedback` must verify before it edits code.
 
 ### Conflict resolution anti-patterns
 - ✗ Accepting "ours" or "theirs" for all conflicts without reading them
 - ✗ Resolving semantic conflicts without understanding both sides
 - ✗ Pushing resolution without running tests on the merged result
-- ✗ Reviewing a conflicted PR without resolving first — review effort is wasted if the merge changes the code
+- ✗ Treating `PR_REVIEW` as the place to fix branch state — this mode stays read-only
 
-## Phase 0B-bis: Pre-Fix Parallel Work Check
+## Phase 0B-bis: Pre-Handoff Parallel Work Snapshot
 
-When the review surfaces findings that need fixes, and before dispatching
-coder for fix work, re-check for **parallel work** since the last fetch. The PR
-author, the bot reviewer, or another swarm may have pushed commits while you
-were reviewing.
+When the review surfaces findings that will likely need `swarm-pr-feedback`,
+re-check for **parallel work** since the last fetch. The PR author, the bot
+reviewer, or another swarm may have pushed commits while you were reviewing.
+This is still read-only: capture the remote state so the handoff artifact starts
+from the right branch facts.
 
 ### Step 1 — Refetch and compare
 
@@ -258,27 +281,27 @@ For each new commit on the remote:
 
 1. **Read the commit message and diff.** Use `git show <commit> --stat` to see
    file scope, then `git show <commit> -- <file>` to see the actual changes.
-2. **Compare against your planned fixes:**
-   - Does the remote commit touch the same files your coder delegation is about to
-     modify?
-   - Does the remote commit apply a different approach to the same finding?
-   - Does the remote commit include more comprehensive fixes (more tests, better
-     edge coverage, cleaner error handling)?
-3. **Default stance: prefer the parallel work if it supersedes your plan.** Run
+2. **Compare against the pending handoff scope:**
+   - Does the remote commit touch the same files as the validated findings?
+   - Does the remote commit appear to already address a finding you planned to
+     hand off?
+   - Does the remote commit introduce a new branch-state fact the handoff should
+     mention?
+3. **Default stance: prefer the remote state as the next baseline.** Run
    the [`parallel-work-check`](../generated/parallel-work-check/SKILL.md)
-   protocol for the formal decision template.
+   protocol for the formal decision template and record the outcome in the
+   handoff artifact.
 
 ### Step 3 — Three outcomes
 
-- **Parallel work supersedes:** Abort your rebase. First verify the working tree
-  is clean (`git status --porcelain`); stash or discard any uncommitted changes
-  before proceeding. Then `git reset --hard origin/<pr-branch>` to take the
-  remote state, then re-verify that all your findings are addressed. If the
-  remote missed any, add minor improvements on top. Do NOT waste effort redoing
-  work the parallel agent already did better.
-- **Parallel work complements:** Cherry-pick or merge the remote commits into
-  your local branch, then continue with your fix.
-- **Parallel work unrelated:** Continue with your planned fix.
+- **Parallel work supersedes:** Mark the older local checkout as stale in the
+  handoff artifact and tell `swarm-pr-feedback` to re-check out the current
+  remote head before editing.
+- **Parallel work complements:** Carry both the validated findings and the new
+  remote commits into the handoff artifact so `swarm-pr-feedback` can verify the
+  combined state before patching.
+- **Parallel work unrelated:** Note that the remote moved, but keep the same
+  validated finding set.
 
 ### Anti-patterns
 
@@ -985,6 +1008,23 @@ Use one of:
 
 Explain the recommendation in one short paragraph and list required actions before merge if applicable.
 
+## Feedback handoff
+
+When the review produced actionable validated findings or operational blockers,
+include:
+
+- the handoff artifact path,
+- the preserved finding IDs and provenance that `swarm-pr-feedback` must carry
+  forward,
+- and an explicit question asking whether to continue into
+  `swarm-pr-feedback`.
+
+Use this exact continuation prompt format:
+
+```text
+/swarm pr-feedback <PR_URL> continue from .swarm/pr-review/<run_id>/feedback-handoff.md
+```
+
 ---
 
 # Reviewer Prompt Template

package/dist/cli/index.js

@@ -52,7 +52,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "opencode-swarm",
-    version: "7.80.0",
+    version: "7.81.1",
     description: "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
     main: "dist/index.js",
     types: "dist/index.d.ts",
@@ -17194,6 +17194,12 @@ async function handleAcknowledgeSpecDriftCommand(directory, _args, acknowledgedB
   try {
     const plan = await loadPlanJsonOnly(directory);
     if (plan?.specHash) {
+      if (stalenessData.specHash_plan !== plan.specHash) {
+        return `Spec drift acknowledgment rejected: The spec has changed since the staleness was detected. 
+Current plan specHash: ${plan.specHash}
+Staleness file specHash: ${stalenessData.specHash_plan}
+Please re-run the relevant phase to detect current drift status.`;
+      }
       currentHash = await computeSpecHash(directory);
       plan.specHash = currentHash ?? undefined;
       await savePlan(directory, plan);
@@ -21443,7 +21449,12 @@ async function tryAcquireLock(directory, filePath, agent, taskId) {
   try {
     release = await import_proper_lockfile.default.lock(lockPath, {
       stale: LOCK_TIMEOUT_MS,
-      retries: { retries: 0 },
+      retries: {
+        retries: 5,
+        minTimeout: 10,
+        maxTimeout: 500,
+        factor: 2
+      },
       realpath: false
     });
   } catch (err) {

package/dist/commands/pr-feedback.d.ts

@@ -1,20 +1,22 @@
 /**
  * Handle /swarm pr-feedback command.
  *
- * Triggers the architect to enter MODE: PR_FEEDBACK — the swarm workflow for
+ * Triggers the architect to enter MODE: PR_FEEDBACK — the swarm workflow for
  * ingesting and closing KNOWN pull-request feedback (review comments, requested
  * changes, CI failures, merge conflicts, stale branches, pasted notes). This is
  * distinct from /swarm pr-review, which discovers NEW findings.
  *
  * Input contract (PR reference is optional):
- *   /swarm pr-feedback 155                         → feedback pass on PR 155
- *   /swarm pr-feedback 155 also fix the lint errors → PR 155 + extra instructions
- *   /swarm pr-feedback owner/repo#155               → shorthand
+ *   /swarm pr-feedback 155                         → feedback pass on PR 155
+ *   /swarm pr-feedback 155 also fix the lint errors → PR 155 + extra instructions
+ *   /swarm pr-feedback 155 continue from .swarm/pr-review/<run_id>/feedback-handoff.md
+ *                                                   -> PR 155 + handoff path instructions
+ *   /swarm pr-feedback owner/repo#155               → shorthand
  *   /swarm pr-feedback https://github.com/.../pull/155
- *   /swarm pr-feedback                              → bare signal; architect builds
+ *   /swarm pr-feedback                              → bare signal; architect builds
  *                                                     the ledger from current PR/branch
  *   /swarm pr-feedback address the review notes about error handling
- *                                                   → no parseable PR ref ⇒ the whole
+ *                                                   → no parseable PR ref ⇒ the whole
  *                                                     input is forwarded as instructions
  *
  * PR-reference parsing and injection-hardening are shared with /swarm pr-review

package/dist/council/criteria-store.d.ts

@@ -5,5 +5,5 @@
  * read back during council evaluation.
  */
 import type { CouncilCriteria, CouncilCriteriaItem } from './types';
-export declare function writeCriteria(workingDir: string, taskId: string, criteria: CouncilCriteriaItem[]): void;
+export declare function writeCriteria(workingDir: string, taskId: string, criteria: CouncilCriteriaItem[]): Promise<void>;
 export declare function readCriteria(workingDir: string, taskId: string): CouncilCriteria | null;

package/dist/index.js

@@ -69,7 +69,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "opencode-swarm",
-    version: "7.80.0",
+    version: "7.81.1",
     description: "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
     main: "dist/index.js",
     types: "dist/index.d.ts",
@@ -20253,6 +20253,12 @@ async function handleAcknowledgeSpecDriftCommand(directory, _args, acknowledgedB
   try {
     const plan = await loadPlanJsonOnly(directory);
     if (plan?.specHash) {
+      if (stalenessData.specHash_plan !== plan.specHash) {
+        return `Spec drift acknowledgment rejected: The spec has changed since the staleness was detected. 
+Current plan specHash: ${plan.specHash}
+Staleness file specHash: ${stalenessData.specHash_plan}
+Please re-run the relevant phase to detect current drift status.`;
+      }
       currentHash = await computeSpecHash(directory);
       plan.specHash = currentHash ?? undefined;
       await savePlan(directory, plan);
@@ -21956,7 +21962,12 @@ async function tryAcquireLock(directory, filePath, agent, taskId) {
   try {
     release = await import_proper_lockfile.default.lock(lockPath, {
       stale: LOCK_TIMEOUT_MS,
-      retries: { retries: 0 },
+      retries: {
+        retries: 5,
+        minTimeout: 10,
+        maxTimeout: 500,
+        factor: 2
+      },
       realpath: false
     });
   } catch (err2) {
@@ -124323,7 +124334,8 @@ function buildFinalCouncilFeedback(projectSummary, verdict, vetoedBy, requiredFi
 
 // src/council/criteria-store.ts
 init_zod();
-import { existsSync as existsSync82, mkdirSync as mkdirSync35, readFileSync as readFileSync56, writeFileSync as writeFileSync23 } from "node:fs";
+init_task_file();
+import { existsSync as existsSync82, mkdirSync as mkdirSync35, readFileSync as readFileSync56 } from "node:fs";
 import { join as join114 } from "node:path";
 var COUNCIL_DIR = ".swarm/council";
 var CouncilCriteriaSchema = exports_external.object({
@@ -124335,7 +124347,7 @@ var CouncilCriteriaSchema = exports_external.object({
   })),
   declaredAt: exports_external.string()
 });
-function writeCriteria(workingDir, taskId, criteria) {
+async function writeCriteria(workingDir, taskId, criteria) {
   const dir = join114(workingDir, COUNCIL_DIR);
   mkdirSync35(dir, { recursive: true });
   const payload = {
@@ -124343,7 +124355,7 @@ function writeCriteria(workingDir, taskId, criteria) {
     criteria,
     declaredAt: new Date().toISOString()
   };
-  writeFileSync23(join114(dir, `${safeId(taskId)}.json`), JSON.stringify(payload, null, 2));
+  await atomicWriteFile(join114(dir, `${safeId(taskId)}.json`), JSON.stringify(payload, null, 2));
 }
 function readCriteria(workingDir, taskId) {
   const filePath = join114(workingDir, COUNCIL_DIR, `${safeId(taskId)}.json`);
@@ -125232,7 +125244,7 @@ var declare_council_criteria = createSwarmTool({
     }
     const existing = readCriteria(workingDir, input.taskId);
     const replaced = existing !== null;
-    writeCriteria(workingDir, input.taskId, input.criteria);
+    await writeCriteria(workingDir, input.taskId, input.criteria);
     return JSON.stringify({
       success: true,
       taskId: input.taskId,
@@ -133001,7 +133013,7 @@ import * as path157 from "node:path";
 
 // src/mutation/engine.ts
 import { spawnSync as spawnSync11 } from "node:child_process";
-import { unlinkSync as unlinkSync19, writeFileSync as writeFileSync25 } from "node:fs";
+import { unlinkSync as unlinkSync19, writeFileSync as writeFileSync24 } from "node:fs";
 import * as path156 from "node:path";
 
 // src/mutation/equivalence.ts
@@ -133191,7 +133203,7 @@ async function executeMutation(patch, testCommand, testFiles, workingDir) {
     const safeId2 = patch.id.replace(/[^a-zA-Z0-9_-]/g, "_");
     patchFile = path156.join(workingDir, `.mutation_patch_${safeId2}.diff`);
     try {
-      writeFileSync25(patchFile, patch.patch);
+      writeFileSync24(patchFile, patch.patch);
     } catch (writeErr) {
       error93 = `Failed to write patch file: ${writeErr}`;
       outcome = "error";
@@ -133627,6 +133639,7 @@ init_zod();
 init_config();
 init_schema();
 init_manager2();
+init_task_file();
 import * as fs111 from "node:fs";
 import * as path167 from "node:path";
 
@@ -135821,6 +135834,39 @@ async function executePhaseComplete(args2, workingDirectory, directory) {
       }
       warnings.push(`Knowledge sweep failed for phase ${phase}: ${detail}`);
     }
+    const planLockTaskId = `phase-complete-plan-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`;
+    const planFilePath = "plan.json";
+    let planLockResult;
+    try {
+      planLockResult = await tryAcquireLock(dir, planFilePath, agentName, planLockTaskId);
+    } catch (error93) {
+      return JSON.stringify({
+        success: false,
+        phase: args2.phase,
+        status: "incomplete",
+        message: `Failed to acquire lock for plan.json: ${error93 instanceof Error ? error93.message : String(error93)}`,
+        agentsDispatched,
+        agentsMissing,
+        warnings,
+        errors: [error93 instanceof Error ? error93.message : String(error93)],
+        recovery_guidance: "Resolve the filesystem issue (permissions, disk space, or .swarm/locks/ directory) and retry phase_complete."
+      });
+    }
+    if (!planLockResult?.acquired) {
+      return JSON.stringify({
+        success: false,
+        phase: args2.phase,
+        status: "incomplete",
+        message: `Plan write blocked: plan.json is locked by ${planLockResult.existing?.agent ?? "another agent"}`,
+        agentsDispatched,
+        agentsMissing,
+        warnings,
+        errors: [
+          `Concurrent plan write detected — lock held by ${planLockResult.existing?.agent ?? "another agent"} (task: ${planLockResult.existing?.taskId ?? "unknown"})`
+        ],
+        recovery_guidance: "Wait a moment and retry phase_complete. The lock will expire automatically if the holding agent fails."
+      });
+    }
     try {
       const plan = await loadPlan(dir);
       if (plan === null) {
@@ -135849,7 +135895,7 @@ async function executePhaseComplete(args2, workingDirectory, directory) {
           const phaseObj = plan2.phases.find((p) => p.id === phase);
           if (phaseObj) {
             phaseObj.status = "complete";
-            fs111.writeFileSync(planPath, JSON.stringify(plan2, null, 2), "utf-8");
+            await atomicWriteFile(planPath, JSON.stringify(plan2, null, 2));
           }
         } catch {}
       } else if (plan) {
@@ -135891,9 +135937,17 @@ async function executePhaseComplete(args2, workingDirectory, directory) {
         const phaseObj = plan.phases.find((p) => p.id === phase);
         if (phaseObj) {
           phaseObj.status = "complete";
-          fs111.writeFileSync(planPath, JSON.stringify(plan, null, 2), "utf-8");
+          await atomicWriteFile(planPath, JSON.stringify(plan, null, 2));
         }
       } catch {}
+    } finally {
+      if (planLockResult?.acquired && planLockResult.lock._release) {
+        try {
+          await planLockResult.lock._release();
+        } catch (releaseError) {
+          warn("[phase_complete] Plan lock release failed (non-blocking):", releaseError instanceof Error ? releaseError.message : String(releaseError));
+        }
+      }
     }
   }
   if (complianceWarnings.length > 0) {
@@ -143588,7 +143642,7 @@ import {
   readFileSync as readFileSync81,
   renameSync as renameSync24,
   unlinkSync as unlinkSync21,
-  writeFileSync as writeFileSync31
+  writeFileSync as writeFileSync30
 } from "node:fs";
 import path181 from "node:path";
 init_create_tool();
@@ -143855,7 +143909,7 @@ function writePhaseCouncilEvidence(workingDir, synthesis, provenance) {
   };
   const tempFile = `${evidenceFile}.tmp-${Date.now()}`;
   try {
-    writeFileSync31(tempFile, JSON.stringify(evidenceBundle, null, 2), "utf-8");
+    writeFileSync30(tempFile, JSON.stringify(evidenceBundle, null, 2), "utf-8");
     renameSync24(tempFile, evidenceFile);
   } finally {
     if (existsSync103(tempFile)) {

package/dist/plan/ledger.d.ts

@@ -82,6 +82,12 @@ declare function getPlanJsonPath(directory: string): string;
  * Compute a SHA-256 hash of the plan state.
  * Uses deterministic JSON serialization for consistent hashing.
  *
+ * IMPORTANT: Intentionally excludes `specMtime` and `specHash` fields.
+ * These fields track changes to spec.md but do not affect plan execution or structure.
+ * Including them would cause the plan hash to change whenever spec metadata changes,
+ * invalidating cached plan state unnecessarily. Spec changes are tracked separately
+ * in the ledger via `spec_updated` and acknowledgment events.
+ *
  * @param plan - The plan to hash
  * @returns Hex-encoded SHA-256 hash
  */

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "opencode-swarm",
-	"version": "7.80.0",
+	"version": "7.81.1",
 	"description": "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
 	"main": "dist/index.js",
 	"types": "dist/index.d.ts",