opencode-swarm 7.79.7 → 7.81.0

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

@@ -76,11 +76,11 @@ Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder
 - final_council (default: OFF) -- when enabled, after all phases complete the architect dispatches the full 5-member council (critic, reviewer, sme, test_engineer, explorer) -- NOT the General Council -- at project scope, collects `CouncilMemberVerdict` objects, and calls `write_final_council_evidence`. This does not require `council.general.enabled`.
 
 Additionally, present these two sub-items as part of the same exchange:
-- Parallel coders (default: 1, range: 1-4) -- how many coders should run in parallel.
+- Parallel coders (default: 1, range: 1-4) -- how many coders should run in parallel. Parallel coders each run in an isolated git worktree (separate working dir + branch) and merge back automatically, so they never overwrite each other's files -- safe and faster, but only for tasks whose file scopes do NOT overlap. The per-task file scopes that determine a safe parallel count are not known until the plan is finalized, so default to 1 (serial) here; the precise recommendation is made at plan time once the tasks and their scopes exist.
 - 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/codebase-review-swarm/SKILL.md

@@ -63,3 +63,9 @@ Use these baselines unless repository policy explicitly requires stricter or old
 6. Run inline critic for CRITICAL/HIGH defects, enhancement critic for all kept enhancements, and final whole-report critic.
 7. Write `review-report.md` only after coverage closure and final critic PASS.
 8. Final response reports only the run path, selected tracks, counts summary, highest-risk items, coverage limitations, and confirmation that no source files were modified.
+
+## Async advisory lanes
+
+When selected-track inventory or candidate generation decomposes into independent read-only units, launch those units with `dispatch_lanes_async` when available. Record each returned `batch_id`, then continue architect-owned deterministic work that does not depend on lane output: update the coverage ledger shell, run safe local tools, prepare validation shards, and document unresolved coverage units. Do not mark coverage `REVIEWED`, promote candidates to findings, or write the final report from running lanes.
+
+At every coverage, validation, and synthesis boundary, call `collect_lane_results` with `wait: true` for all open batches. Missing, stale, cancelled, or failed lanes are explicit coverage gaps and must become `BLOCKED` or `SKIPPED_WITH_REASON`; they cannot be silently ignored. If `dispatch_lanes_async` is unavailable, use the existing blocking dispatch pattern and record that async advisory lanes were unavailable.

package/.opencode/skills/codebase-review-swarm/references/review-protocol-v8.2.md

@@ -126,9 +126,9 @@ Before writing under `.swarm/`, verify `.swarm/` is ignored or locally excluded.
 ## Phase 0 safe ordering
 
 1. Run 0A alone.
-2. After 0A, run 0B and 0C in parallel only if the repository is large enough to benefit.
-3. After 0B, run 0D and 0E in parallel only if 0E can leave `linked_claims` blank for Architect linking in 0J. Otherwise run 0D before 0E.
-4. Preferred batch order: batch 1 = 0F and 0G; batch 2 = 0H and 0I. Never exceed two Phase 0 agents.
+2. After 0A, run 0B and 0C through `dispatch_lanes_async` only if the repository is large enough to benefit. While those lanes run, the Architect continues deterministic inventory work that does not depend on their results.
+3. After 0B, run 0D and 0E through `dispatch_lanes_async` only if 0E can leave `linked_claims` blank for Architect linking in 0J. Otherwise run 0D before 0E.
+4. Preferred async batch order: batch 1 = 0F and 0G; batch 2 = 0H and 0I. Never exceed two Phase 0 agents.
 5. Run 0F after 0E when possible.
 6. Run 0G after 0B and 0C.
 7. Run 0H and 0I after 0B and 0C.
@@ -136,7 +136,7 @@ Before writing under `.swarm/`, verify `.swarm/` is ignored or locally excluded.
 9. Run 0K after 0J. Stop for user track selection unless preselected.
 10. Run 0L after track selection and before Phase 1 candidate generation. 0L is the last Phase 0 step before Phase 1.
 
-Do not run dependent inventory passes merely to keep agents busy. Missing dependency context is `unknown`, not guessed.
+Collect every async batch with `collect_lane_results` before consuming its ledger output or advancing to a dependent step. If `dispatch_lanes_async` or `collect_lane_results` is unavailable, fall back to blocking `dispatch_lanes`; if deterministic dispatch is unavailable, run isolated local passes and record that fallback. Do not run dependent inventory passes merely to keep agents busy. Missing dependency context is `unknown`, not guessed.
 
 ## Phase 0 inventory
 
@@ -205,7 +205,7 @@ Rules:
 
 ## Phase 1 — Candidate generation
 
-Every dispatch includes selected track(s), exact file list or surface IDs, source-of-truth packet, repository-context packet, relevant ledgers, the applicable `TRACK_DEPTH_PLAN`, candidate format, `out_of_scope_note` rule, and anti-cursory/non-dilution reminder.
+Every dispatch includes selected track(s), exact file list or surface IDs, source-of-truth packet, repository-context packet, relevant ledgers, the applicable `TRACK_DEPTH_PLAN`, candidate format, `out_of_scope_note` rule, and anti-cursory/non-dilution reminder. Prefer `dispatch_lanes_async` for independent candidate-generation coverage units so the Architect can continue building the review ledger, coverage map, and validation routing while lanes inspect subsystems. Call `collect_lane_results` before Phase 2 reviewer validation; no candidate may be routed, counted, or synthesized until its async batch has settled or been explicitly marked blocked/skipped.
 
 File-size rule: no more than 15 files per deep pass; no more than 8 dense files per deep pass. Dense = >300 logical lines, multiple unrelated responsibilities, or interleaved UI/state/network/security logic. No sampling inside assigned scope. Large selections require more deep passes, not larger batches or lower depth.
 

package/.opencode/skills/council/SKILL.md

@@ -87,8 +87,12 @@ RESEARCH CONTEXT
 
 3. Dispatch `the active swarm's council_generalist agent`,
    `the active swarm's council_skeptic agent`, and
-   `the active swarm's council_domain_expert agent` in PARALLEL -- one message
-   per agent, then STOP and wait for all responses. Each dispatch message must
+   `the active swarm's council_domain_expert agent` with `dispatch_lanes_async`
+   when available -- one lane per agent. Record the returned `batch_id`, then
+   continue only non-dependent architect work: prepare the synthesis outline,
+   normalize the RESEARCH CONTEXT citations, and draft disagreement categories.
+   Do not call `convene_general_council` or present conclusions from running
+   lanes. Each dispatch message must
    include:
    - The question
    - Round number: 1
@@ -99,7 +103,10 @@ RESEARCH CONTEXT
 
 Do NOT share other agents' responses at this stage.
 
-4. Collect all three JSON responses. The `round1Responses` array will contain
+4. Call `collect_lane_results` with `wait: true` for the Round 1 batch and collect
+   all three JSON responses. If `dispatch_lanes_async` is unavailable, use
+   blocking parallel dispatch and record that async advisory lanes were
+   unavailable. The `round1Responses` array will contain
    entries with `memberId` of `council_generalist`, `council_skeptic`, and
    `council_domain_expert` and `role` of `generalist`, `skeptic`, and
    `domain_expert` respectively. These come from the agents' JSON output; no

package/.opencode/skills/deep-dive/SKILL.md

@@ -45,7 +45,7 @@ Produce a SCOPE MAP: list of files, modules, and interfaces within the audit bou
 
 ## Step 3 — Explorer Missions (Parallel Waves)
 
-Dispatch explorer waves using parallel Task calls. Each wave contains up to `max_explorers` missions.
+Dispatch explorer waves with `dispatch_lanes_async` when available. Each wave contains up to `max_explorers` missions.
 
 **File caps per mission:**
 - 8 files maximum per mission
@@ -71,7 +71,9 @@ Each explorer mission receives:
 - The scope map context from Step 2
 - Instruction: "You are performing a [LANE] audit. Report findings as candidate observations with severity (INFO/LOW/MEDIUM/HIGH/CRITICAL), location, and evidence."
 
-Explorer missions are dispatched in parallel waves. Wait for ALL missions in a wave to complete before dispatching the next wave.
+Explorer missions are dispatched in parallel waves. Launch the wave, record the returned `batch_id`, then continue deterministic architect work that does not depend on lane output: refine the scope map, build the candidate ledger shell, inspect local evidence with read-only tools, and prepare reviewer shard structure. Do not synthesize findings from running lanes.
+
+At the Step 4 boundary, call `collect_lane_results` with `wait: true` for every open wave batch. Treat missing, stale, cancelled, or failed lanes as explicit coverage gaps; do not silently proceed past a required lane. If `dispatch_lanes_async` is unavailable, use blocking `dispatch_lanes` or parallel Task calls and record that async advisory lanes were unavailable.
 
 Explorers generate CANDIDATE FINDINGS only — they do NOT make verdicts. All findings are unverified until Step 5.
 

package/.opencode/skills/deep-research/SKILL.md

@@ -97,8 +97,12 @@ RESEARCH CONTEXT — <subtopic>
 
 ## Step 4 — Parallel Synthesis Workers
 
-Dispatch up to `max_researchers` `the active swarm's sme agent` calls IN PARALLEL
-— one per subtopic — then STOP and wait for all responses. Each sme dispatch must
+Dispatch up to `max_researchers` `the active swarm's sme agent` calls with
+`dispatch_lanes_async` when available — one per subtopic. Record the returned
+`batch_id`, then continue architect-owned retrieval quality work that does not
+depend on worker output: tighten the evidence ledger, check source authority,
+prepare reviewer shard structure, and identify unresolved gaps. Do not write final
+claims from running lanes. Each sme dispatch must
 include:
 - `DOMAIN`: the subtopic
 - `TASK`: "Synthesize an evidence-grounded answer for this subtopic. Cite each
@@ -109,9 +113,13 @@ include:
 - `OUTPUT`: claims with evidence refs, contradictions noted, confidence (0–1)
 - `SKILLS: none`
 
-The sme synthesizes only from the provided evidence — it does not fetch. Collect
-all worker responses into a candidate findings set, each finding tagged with its
-subtopic, evidence refs, and the worker's confidence.
+The sme synthesizes only from the provided evidence — it does not fetch. Before
+Step 5, call `collect_lane_results` with `wait: true` for every open synthesis
+batch. Collect all completed worker responses into a candidate findings set, each
+finding tagged with its subtopic, evidence refs, and the worker's confidence.
+Treat missing, stale, cancelled, or failed lanes as explicit coverage gaps. If
+`dispatch_lanes_async` is unavailable, use blocking parallel dispatch and record
+that async advisory lanes were unavailable.
 
 ## Step 5 — Dual-Reviewer Claim Verification
 

package/.opencode/skills/plan/SKILL.md

@@ -214,7 +214,7 @@ After `save_plan` succeeds, read `.swarm/context.md`:
   - drift_check (default: ON) - mandatory per-phase drift verification at PHASE-WRAP
   - final_council (default: OFF) - when enabled, after all phases complete the architect dispatches the full 5-member council (critic, reviewer, sme, test_engineer, explorer) -- NOT the General Council -- at project scope, collects `CouncilMemberVerdict` objects, and calls `write_final_council_evidence`. This does not require `council.general.enabled`.
   Additionally, present these two sub-items as part of the same exchange:
-  - Parallel coders (default: 1, range: 1-4) - how many coders should run in parallel.
+  - Parallel coders (default: 1, range: 1-4) - how many coders should run in parallel. Parallel coders each run in an isolated git worktree (separate working dir + branch) and merge back automatically, so they never overwrite each other's files - safe and faster, but only for tasks whose file scopes do NOT overlap. Inspect the plan and recommend a count equal to the number of dependency-ready, file-disjoint task groups (clamped 1-4); recommend 1 (serial) when scopes overlap or are unknown. State your recommendation and reasoning when you ask.
   - Commit frequency (default: phase-level only) - optional per-task checkpoint commit after each task completion.
   The user answers all three (gates, parallel coders, commit frequency) 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/specify/SKILL.md

@@ -47,7 +47,7 @@ Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder
 - final_council (default: OFF) -- when enabled, after all phases complete the architect dispatches the full 5-member council (critic, reviewer, sme, test_engineer, explorer) -- NOT the General Council -- at project scope, collects `CouncilMemberVerdict` objects, and calls `write_final_council_evidence`. This does not require `council.general.enabled`.
 
 Additionally, present these three sub-items as part of the same exchange:
-- Parallel coders (default: 1, range: 1-4) -- how many coders should run in parallel.
+- Parallel coders (default: 1, range: 1-4) -- how many coders should run in parallel. Parallel coders each run in an isolated git worktree (separate working dir + branch) and merge back automatically, so they never overwrite each other's files -- safe and faster, but only for tasks whose file scopes do NOT overlap. The per-task file scopes that determine a safe parallel count are not known until the plan is finalized, so default to 1 (serial) here; the precise recommendation is made at plan time once the tasks and their scopes exist.
 - 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.
 

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,
@@ -142,6 +154,24 @@ Build a complete feedback ledger before editing. Include every available source:
 If a source is unavailable, record that limitation. Do not treat missing access as
 evidence that no feedback exists.
 
+### Async advisory verification lanes
+
+After the complete feedback ledger exists and before editing, use
+`dispatch_lanes_async` when available for independent read-only verification lanes:
+comment classification, CI/log root-cause inspection, test impact mapping,
+release/docs claim checks, and stale-branch/conflict analysis. Record each
+returned `batch_id`, then continue only ledger-safe architect work: normalize
+feedback IDs, gather deterministic PR metadata, prepare reproduction commands,
+and plan likely fix groups. Do not edit, close items, or mark feedback resolved
+from running lanes.
+
+Before the Verification step can mark any item `RESOLVED`, `DISPROVED`,
+`PRE_EXISTING`, `NEEDS_MORE_EVIDENCE`, or `NEEDS_USER_DECISION`, call
+`collect_lane_results` with `wait: true` for every open verification batch.
+Missing, stale, cancelled, or failed lanes remain explicit ledger limitations.
+If `dispatch_lanes_async` is unavailable, use blocking verification and record
+that async advisory lanes were unavailable.
+
 ### CI matrix cascade check (do this before fixing)
 
 When the PR's `unit` job is a matrix across multiple OSes and downstream jobs
@@ -188,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
 
@@ -468,11 +491,11 @@ Tool candidate rules:
 
 ## Phase 3: Parallel Base Explorer Lanes
 
-Launch all base lanes with the `dispatch_lanes` tool in one call. Pass the six lane specs together, set `max_concurrent` to `6`, and treat the returned `lane_results` as the join barrier before synthesis. Use read-only explorer/reviewer-style agents; do not rely on model-emitted background Agent calls or native background flags for base-lane parallelism.
+Launch all base lanes with `dispatch_lanes_async` when available. Pass the six lane specs together, set `max_concurrent` to `6`, record the returned `batch_id`, and continue only non-dependent architect work: refine the obligation ledger, inspect PR metadata, prepare micro-lane trigger checks, and run deterministic read-only local tools. Do not synthesize findings from running lanes.
 
-If `dispatch_lanes` is unavailable, simulate isolated passes. Do not let one lane's conclusions bias another lane, and record that deterministic dispatch was unavailable in the validation gate.
+Before Phase 4 or synthesis, call `collect_lane_results` with `wait: true` for the base-lane batch and treat the collected `lane_results` as the join barrier. Missing, stale, cancelled, or failed base lanes are explicit review coverage gaps. If `dispatch_lanes_async` is unavailable, use blocking `dispatch_lanes`; if that is also unavailable, simulate isolated passes. Do not let one lane's conclusions bias another lane, and record unavailable deterministic dispatch in the validation gate.
 
-**lane id uniqueness for parallel dispatches:** When re-dispatching failed or re-running explorer lanes, every `dispatch_lanes` lane `id` MUST be unique within that dispatch batch and should include lane and attempt suffixes (e.g. `pr_review_explore_lane1_attempt2`). Never reuse an id in the same batch unless intentionally replacing that exact lane before dispatch.
+**lane id uniqueness for parallel dispatches:** When re-dispatching failed or re-running explorer lanes, every `dispatch_lanes_async` or `dispatch_lanes` lane `id` MUST be unique within that dispatch batch and should include lane and attempt suffixes (e.g. `pr_review_explore_lane1_attempt2`). Never reuse an id in the same batch unless intentionally replacing that exact lane before dispatch.
 
 Explorers optimize for recall. Over-reporting is expected. Explorers produce candidates only.
 
@@ -510,7 +533,7 @@ Explorers must not use `CONFIRMED`, `DISPROVED`, or `PRE_EXISTING`.
 
 ## Phase 4: Triggered Swarm Plugin Micro-Lanes
 
-After `dispatch_lanes` returns for base lanes, inspect the context pack risk triggers. Launch focused micro-lanes for triggered categories only, using `dispatch_lanes` again when more than one read-only micro-lane is needed. Do not launch irrelevant micro-lanes.
+After `collect_lane_results` returns for base lanes, inspect the context pack risk triggers. Launch focused micro-lanes for triggered categories only, using `dispatch_lanes_async` again when more than one read-only micro-lane is needed. Collect every micro-lane batch with `wait: true` before reviewer classification. Do not launch irrelevant micro-lanes.
 
 Each micro-lane receives:
 
@@ -793,7 +816,7 @@ Council mode is opt-in only and adversarial.
 When triggered:
 
 1. Build the same context pack as default mode.
-2. Launch all council agents with one `dispatch_lanes` call when available; use the returned `lane_results` as the join barrier before reviewer classification.
+2. Launch all council agents with one `dispatch_lanes_async` call when available; continue only non-dependent context preparation while they run, then use `collect_lane_results` with `wait: true` as the join barrier before reviewer classification. Fall back to blocking `dispatch_lanes` when async launch is unavailable.
 3. Each council agent assumes all work is wrong until code evidence proves otherwise.
 4. Each agent hunts within its lane only.
 5. Agents return evidence states only: `EVIDENCE_FOUND`, `SUSPICIOUS`, or `CLEAN`.
@@ -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/background/completion-observer.d.ts

@@ -1,5 +1,5 @@
 /**
- * Background subagent completion OBSERVER (issue #1151, PR 2 Stage A).
+ * Background subagent completion observer/ingester.
  *
  * Registers as a swarm `event` hook to watch for the upstream background-completion signal:
  * a message part with `synthetic === true` whose text is a task envelope with
@@ -7,9 +7,9 @@
  * background-delegation record, it is logged (debug-gated) as the empirical confirmation
  * instrument operators use to verify the runtime signal in a real environment.
  *
- * Stage A is strictly READ-ONLY: this observer NEVER advances workflow gates, records gate
- * evidence, or mutates the durable store. Gate-affecting completion ingestion is Stage B,
- * gated on runtime confirmation produced by exactly this observer.
+ * PR1 async advisory lanes ingest trusted terminal completions into the durable
+ * background-delegation ledger only. This still NEVER advances workflow gates or records
+ * gate evidence; gate-bearing execution is intentionally outside this advisory path.
  *
  * The `synthetic` flag is the trust gate (set by OpenCode, not the model/user). Non-synthetic
  * text that merely looks like an envelope is ignored. The observer is fail-open: any error is
@@ -19,7 +19,7 @@ interface ObserverConfig {
     enabled: boolean;
 }
 /**
- * Build the Stage A completion observer. Returns an `event` handler suitable for the
+ * Build the background completion observer. Returns an `event` handler suitable for the
  * OpenCode plugin `event` hook. No-op (cheap early return) when the feature is disabled.
  */
 export declare function createBackgroundCompletionObserver(opts: {