opencode-swarm 7.79.7 → 7.80.0

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

@@ -76,7 +76,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 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.
 

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

@@ -142,6 +142,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

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

@@ -468,11 +468,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 +510,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 +793,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`.

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: {

package/dist/background/pending-delegations.d.ts

@@ -3,17 +3,17 @@
  *
  * Append-only JSONL event log under project-root `.swarm/background-delegations.jsonl`.
  * Each line is a full record snapshot; readers fold to the latest snapshot per
- * `correlationId`. This tracks background swarm `Task` dispatches so a later (Stage B)
- * trusted completion can be correlated to a real dispatch. The stale sweep bounds the
- * number of permanently-running (unresolved) entries by transitioning them to `stale`, so
- * the folded in-memory view stays bounded by distinct correlationIds. Note: the on-disk
- * log itself is append-only and is NOT compacted in Stage A — each dispatch leaves a small,
- * fixed number of lines; on-disk compaction of dropped/stale records is a future stage.
+ * `correlationId`. This tracks native background `Task` dispatches and deterministic
+ * async advisory lanes so trusted completions can be correlated to a real dispatch.
+ * The stale sweep bounds the number of permanently-running entries by transitioning
+ * them to `stale`, so the folded in-memory view stays bounded by distinct correlationIds.
+ * The on-disk log itself is append-only and is NOT compacted; each dispatch leaves a
+ * small, fixed number of lines.
  *
- * Stage A scope: dispatch records a `pending` snapshot and the stale sweep records
- * `stale` snapshots. There is NO gate advancement and NO completion mutation here — the
- * completion observer (Stage A) is read-only. Gate-affecting completion ingestion is
- * Stage B, gated on runtime confirmation of the upstream completion signal.
+ * Scope: dispatch records `pending`/`running` snapshots, collection or trusted synthetic
+ * completions record terminal snapshots, and the stale sweep records `stale` snapshots.
+ * This store still has NO gate advancement and NO gate evidence side effect; it is an
+ * advisory result ledger only.
  *
  * Concurrency: all writes (append, sweep) run under a single project-scoped lock via
  * `withEvidenceLock`, so concurrent dispatches/sweeps cannot interleave appends. Reads are
@@ -23,9 +23,9 @@
  * `.swarm/` (Invariant 4).
  */
 export declare const BACKGROUND_DELEGATIONS_FILE = "background-delegations.jsonl";
-export type BackgroundDelegationStatus = 'pending' | 'completed' | 'error' | 'stale';
+export type BackgroundDelegationStatus = 'pending' | 'running' | 'completed' | 'error' | 'cancelled' | 'stale' | 'consumed';
 export interface BackgroundDelegationRecord {
-    schemaVersion: 1;
+    schemaVersion: 1 | 2;
     /** Subagent session id from the dispatch envelope — the correlation key. */
     correlationId: string;
     /** Structured jobId from dispatch metadata when available, else null. */
@@ -46,6 +46,33 @@ export interface BackgroundDelegationRecord {
     status: BackgroundDelegationStatus;
     createdAt: number;
     updatedAt: number;
+    /** Async advisory lane batch id. Present for dispatch_lanes_async records. */
+    batchId?: string;
+    /** Stable lane id within batchId. */
+    laneId?: string;
+    /** Advisory workflow/mode that launched the lane. */
+    mode?: string;
+    /** Canonical hash of prompt/provenance inputs captured at dispatch time. */
+    promptHash?: string;
+    /** Project/root provenance captured at dispatch time. */
+    workspace?: BackgroundWorkspaceSnapshot;
+    generation?: number;
+    result?: BackgroundDelegationResult;
+    completedAt?: number;
+}
+export interface BackgroundWorkspaceSnapshot {
+    directory: string;
+    gitHead: string | null;
+    dirtyHash: string | null;
+    prHeadSha: string | null;
+    scope: string | null;
+}
+export interface BackgroundDelegationResult {
+    text?: string;
+    error?: string;
+    chars: number;
+    truncated: boolean;
+    digest: string;
 }
 /**
  * Read and fold the store to the latest snapshot per correlationId. Lock-free and
@@ -53,10 +80,8 @@ export interface BackgroundDelegationRecord {
  * (never throws). Records are returned in first-seen correlationId order.
  *
  * Cost: O(lines on disk) per call — a full read + parse + fold with no in-memory cache.
- * This is intentionally simple and acceptable at Stage A volumes (a swarm has few concurrent
- * background delegations, and the on-disk log is small). If sustained high-throughput
- * background load ever makes this hot, a future stage should add a stat-invalidated in-memory
- * cache and/or JSONL compaction (the same future-compaction work noted in the module header).
+ * This is intentionally simple and acceptable at advisory-lane volumes (a swarm has few
+ * concurrent background delegations, and the on-disk log is small).
  */
 export declare function readDelegations(directory: string): BackgroundDelegationRecord[];
 /** Returns the folded record for a correlationId, or null. Lock-free read. */
@@ -71,16 +96,32 @@ export interface RecordPendingInput {
     swarmPrefixedAgent: string;
     planTaskId: string | null;
     evidenceTaskId: string | null;
+    batchId?: string;
+    laneId?: string;
+    mode?: string;
+    promptHash?: string;
+    workspace?: BackgroundWorkspaceSnapshot;
+    generation?: number;
 }
 /**
  * Record a `pending` background delegation. Runs the stale sweep first (lazy maintenance,
  * no plugin-init cost), then appends the pending snapshot — all under one lock acquisition
  * so concurrent dispatches cannot interleave. Best-effort: returns null on lock timeout or
- * write failure (Stage A has no gate effects, so a missed record is non-fatal).
+ * write failure. Async advisory launchers must treat null as a launch failure so they do
+ * not create untracked background work.
  */
 export declare function recordPendingDelegation(directory: string, input: RecordPendingInput, options?: {
     staleTimeoutMs?: number;
 }): Promise<BackgroundDelegationRecord | null>;
+export declare function appendDelegationTransition(directory: string, correlationId: string, transition: {
+    status: BackgroundDelegationStatus;
+    result?: BackgroundDelegationResult;
+    completedAt?: number;
+}): Promise<BackgroundDelegationRecord | null>;
+export declare function findByBatchId(directory: string, batchId: string, opts?: {
+    parentSessionId?: string;
+}): BackgroundDelegationRecord[];
+export declare function findOpenAsyncLaneBatches(directory: string): BackgroundDelegationRecord[];
 /**
  * Public stale sweep: acquires the store lock and marks overdue pendings as `stale`.
  * Best-effort; returns the number swept (0 on lock timeout / error).

package/dist/background/task-envelope.d.ts

@@ -21,6 +21,11 @@ export interface TaskEnvelope {
     /** The subagent session id from `<task id="...">` — the cross-event correlation key. */
     sessionId: string;
     state: TaskEnvelopeState;
+    summary?: string;
+    resultText?: string;
+    errorText?: string;
+    resultChars?: number;
+    resultTruncated?: boolean;
 }
 /**
  * Parse a task envelope from arbitrary text. Returns null when the text does not contain