opencode-swarm 7.107.4 → 7.107.6

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

@@ -64,6 +64,21 @@ Use these baselines unless repository policy explicitly requires stricter or old
 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.
 
+## Pre-flight: PR Branch Checkout Before Explorer Dispatch
+
+When the review target is a PR branch or commit range, complete this before any
+explorer or candidate-generation dispatch:
+
+1. Verify the working tree is clean with `git status --porcelain`. If
+   uncommitted changes exist, stash them or abort the checkout to prevent data
+   loss.
+2. Fetch and check out the PR head branch locally. Explorer agents read the
+   working-tree filesystem (`Read`/`Glob`/`Grep`), not git history, so reviewing
+   a PR while the base branch is checked out produces invalid candidates.
+3. Record the exact commit range (`base_ref..head_ref`) in the source-of-truth
+   packet and pass that range in every explorer/candidate-generation delegation
+   so agents have revision context for targeted `git show` inspection.
+
 ## 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.

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

@@ -190,6 +190,21 @@ The source-of-truth packet must include repo identity, tech stack, commands, pub
 
 The repository-context packet must be concise and global: architectural style, key modules and responsibilities, primary data flows, trust boundaries, notable tech decisions, and cross-cutting patterns visible from quoted Phase 0 inventory.
 
+### 0J-bis - PR branch checkout pre-flight
+
+If the review target is a PR branch or commit range, complete this before Phase 1
+candidate-generation dispatch:
+
+1. Verify the working tree is clean with `git status --porcelain`. If
+   uncommitted changes exist, stash them or abort the checkout to prevent data
+   loss.
+2. Fetch and check out the PR head branch locally. Explorer agents read the
+   working-tree filesystem (`Read`/`Glob`/`Grep`), not git history; without the
+   checkout, they inspect the base branch and produce invalid candidates.
+3. Record `base_ref..head_ref` in `source-of-truth-packet.md` and pass that
+   commit range in every explorer/candidate-generation delegation so lanes can
+   use `git show` for revision-specific inspection.
+
 ### 0K — User review mode gate
 
 Stop and present the ten review choices unless the user’s original request already selected tracks and explicitly authorized continuing. If the user selects a focused review, do not run unrelated tracks; record omitted tracks in coverage notes.

package/.opencode/skills/engineering-conventions/SKILL.md

@@ -102,7 +102,7 @@ The `commit-pr` skill Tier 1 - quality section pins the biome command to the pac
 The cross-tree skill mirror contract is the authoritative registry at `src/config/skill-mirrors.ts`. If your PR modifies `.opencode/skills/<X>/SKILL.md` or `.claude/skills/<X>/SKILL.md`, consult that file to determine the contract kind for skill `<X>`:
 
 - **`identical`:** `.opencode` and `.claude` SKILL.md must be byte-identical (the `canonical` field records which side wins when they drift). Update both trees byte-for-byte in the same commit. Verify with `bun run drift:check`. PR #1512 (lane-dispatch) introduced drift in council/deep-dive by only updating `.opencode` — a contract violation.
-- **`divergent`:** both must exist but content intentionally differs per runtime. Examples: `engineering-conventions` is divergent (different frontmatter, different conventions per Claude Code vs OpenCode); `writing-tests` is divergent pending maintainer confirmation (#1497).
+- **`divergent`:** both must exist but content intentionally differs per runtime. Examples: `engineering-conventions` is divergent (different frontmatter, different conventions per Claude Code vs OpenCode). `writing-tests` is classified divergent because the additional-contract model does not yet have an adapter kind, but operationally `.opencode/skills/writing-tests/SKILL.md` is canonical and `.claude/skills/writing-tests/SKILL.md` delegates to it.
 - **`opencode-only`:** `.opencode` exists; no `.claude` mirror expected. Examples: `loop` (would shadow Claude Code's built-in `/loop`), `running-tests` (OpenCode-runtime guidance).
 - **Adapter shim pattern:** for architect MODE skills like `swarm-pr-review` and `swarm-pr-feedback`, the `.claude` and `.agents` files are thin adapter shims that delegate to the canonical `.opencode` file via `expectedCanonicalRef`. When updating these, the canonical content goes in `.opencode`; the adapter shim typically needs no change unless the cross-tree delegation interface changes.
 

package/.opencode/skills/execute/SKILL.md

@@ -53,6 +53,7 @@ All other gates: failure → return to coder. No self-fixes. No workarounds.
     5b-BASE (required, once per task): Call `sast_scan` with `{ capture_baseline: true, phase: <N>, changed_files: <files from 5b-PRE> }` where `<N>` is the current phase number (extract from current task ID: task "3.2" → phase 3, task "1.5" → phase 1). The tool maintains `.swarm/evidence/{phase}/sast-baseline.json` as a phase-scoped, incrementally merged baseline of pre-existing SAST findings. Calling twice for the same files is safe (idempotent merge). Do NOT re-capture mid-task.
     → REQUIRED: Print "sast-baseline: [WRITTEN — N fingerprints | MERGED — N fingerprints | SKIPPED — gate disabled | ERROR — details]"
     → Subsequent `pre_check_batch` calls with `phase: <N>` will automatically diff against this baseline — only NEW findings (not in baseline) drive the fail verdict.
+    -> PREFLIGHT CHECKLIST: Before first coder delegation, answer "SAST baseline captured before first coder delegation? yes/no/disabled/error". If the answer is no, do not delegate to coder; run 5b-BASE first. If disabled or error, record the exact tool result.
 5b. the active swarm's coder agent - Implement (if designer scaffold produced, include it as INPUT).
 5b-bis. **CODER OUTPUT VERIFICATION**: After the coder reports completion, do NOT accept the self-report alone. Run `diff` (step 5c) and inspect at least one of the modified files yourself to confirm the change exists. The coder may report DONE without having produced any diff. A 30-second read of the changed file(s) catches this failure mode. This is NOT a separate explorer dispatch — the existing `diff` tool at step 5c is the verification mechanism; the key discipline is checking that `diff` returns actual changes before proceeding, rather than forwarding the coder's self-report to the next gate.
 5c. Run `diff` tool. If `hasContractChanges` → the active swarm's explorer agent integration analysis. If COMPATIBILITY SIGNALS=INCOMPATIBLE or MIGRATION_SURFACE=yes → coder retry. If COMPATIBILITY SIGNALS=COMPATIBLE and MIGRATION_SURFACE=no → proceed.
@@ -157,6 +158,7 @@ PRE-COMMIT RULE — Before ANY commit or push:
   [ ] Did the active swarm's reviewer agent run and return APPROVED? (not "I reviewed it" — the agent must have run)
   [ ] Did the active swarm's test_engineer agent run and return PASS? (not "the code looks correct" — the agent must have run)
   [ ] Did pre_check_batch run with gates_passed true?
+  [ ] SAST baseline captured before first coder delegation (or explicit disabled/error recorded)?
   [ ] Did the diff step run?
   [ ] Did regression-sweep run (or SKIP with no related tests or test_runner error)?
   [ ] Did test-drift check run (or NOT TRIGGERED)?

package/.opencode/skills/phase-wrap/SKILL.md

@@ -95,7 +95,12 @@ The tool will automatically write the retrospective to \`.swarm/evidence/retro-{
    - `.swarm/evidence/{phase}/drift-verifier.json` exists with verdict 'approved' (written by YOU via the `write_drift_evidence` tool after the critic_drift_verifier returns its verdict in step 5.5) — required when .swarm/spec.md exists
    - `.swarm/evidence/{phase}/hallucination-guard.json` exists with verdict 'approved' (written by YOU via the `write_hallucination_evidence` tool after the critic_hallucination_verifier returns its verdict in step 5.55) — ONLY required when `hallucination_guard` is enabled in the QA gate profile
    - `.swarm/evidence/{phase}/mutation-gate.json` exists with verdict 'pass' or 'warn' (written by YOU via the `write_mutation_evidence` tool after step 5.56) — ONLY required when `mutation_test` is enabled in the QA gate profile
-   If any required file is missing, run the missing gate first. Turbo mode skips all gates automatically.
+    - regression-test falsification evidence exists for at least one regression
+      test added or modified in this phase: fix removed/bypassed -> test fails
+      for the expected reason -> fix restored -> test passes. If the phase
+      changed no regression tests, record `not applicable` with the changed-file
+      evidence.
+    If any required file is missing, run the missing gate first. Turbo mode skips all gates automatically.
    NOTE: Steps 5.5, 5.55, and 5.56 are enforced by runtime hooks. If `hallucination_guard` is enabled and you skip the critic_hallucination_verifier delegation (or fail to call `write_hallucination_evidence`), phase_complete will be BLOCKED by the plugin. Similarly, if `mutation_test` is enabled and you skip step 5.56 (or fail to call `write_mutation_evidence`), phase_complete will be BLOCKED. These are not suggestions — they are hard enforcement mechanisms.
 5.65. **Phase Council (conditional on QA gate — `phase_council`)**: Check whether `phase_council` is enabled in the effective QA gate profile (visible via `get_qa_gate_profile`). If disabled, skip silently and proceed to step 5.7.
    This gate is triggered by the `phase_council` QA gate, NOT by `council_mode`. (`council_mode` controls per-task Stage B replacement in MODE: EXECUTE; `phase_council` controls holistic phase-level review here in MODE: PHASE-WRAP.)

package/.opencode/skills/swarm-implement/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: swarm-implement
+description: Execute complex implementation work with a swarm-like workflow: parallel exploration, scoped planning, objective validation, mandatory independent implementation review for changed work, and final critic approval. Use for feature work, bug fixes, refactors, and multi-file changes.
+disable-model-invocation: true
+---
+
+# /swarm-implement
+
+Use this skill for implementation work when you want a fast, high-quality swarm
+workflow rather than a single-threaded assistant.
+
+## Purpose
+
+Complete real coding tasks while preserving speed and adding swarm-style quality
+discipline.
+
+## Core operating model
+
+Use this execution ladder:
+
+1. Explore in parallel.
+2. Build a scoped plan.
+3. Implement in small, coherent units.
+4. Run objective validation.
+5. For any worktree edit, use independent reviewer validation on the latest diff
+   and evidence.
+6. For any worktree edit, use a separate final critic after reviewer approval.
+7. Synthesize and report what changed, what was verified, and what remains risky.
+
+## Command Namespace
+
+Swarm commands always use `/swarm <subcommand>`. Never invoke bare subcommand
+names that collide with host commands such as `/plan`, `/reset`, `/checkpoint`,
+or `/status`.
+
+## High-risk work
+
+Always use the deeper validation path for auth, permissions, payments,
+destructive actions, dependency changes, public APIs, schemas, migrations,
+concurrency, queues, retries, state machines, caching, file access, subprocesses,
+parsing, secrets, security-sensitive logic, and large cross-file refactors with
+correctness risk.
+
+## Recommended workflow
+
+### Phase 0 - Establish scope
+
+Determine the exact task scope first:
+
+- what changed or needs to change,
+- what files are likely involved,
+- what success looks like,
+- what must not be broken,
+- what verification is required.
+
+If the task is unclear, ask targeted questions or create a short written plan
+before coding.
+
+### Phase 0a - Parallel work check
+
+If this project has the OpenCode-generated
+[`parallel-work-check` skill](../generated/parallel-work-check/SKILL.md), follow
+its full protocol. Otherwise, before starting implementation on an existing
+branch:
+
+1. Fetch remote state and compare with local (`git fetch` plus HEAD hashes).
+2. If parallel swarm work is detected on the target branch, read the new commits,
+   decide whether to integrate, supersede, or proceed, and document the decision.
+3. Prefer the parallel work unless you can clearly articulate why your approach
+   is better.
+
+### Phase 0b - PR branch checkout pre-flight
+
+When implementation or review-scoping work depends on explorer agents reading a
+PR branch or commit range, complete this before Phase 1 explorer dispatch:
+
+1. Verify the working tree is clean with `git status --porcelain`. If
+   uncommitted changes exist, stash them or abort the checkout to prevent data
+   loss.
+2. Fetch and check out the PR head branch locally. Explorer agents read files
+   from the working tree (`Read`/`Glob`/`Grep`), not from git history, so a stale
+   checkout makes them inspect the base branch.
+3. Pass the exact commit range (`base_ref..head_ref`) in every explorer
+   delegation so agents have revision context for targeted `git show`
+   inspection.
+
+### Phase 1 - Parallel exploration
+
+Launch parallel subagents for disjoint investigation tasks such as repository
+mapping, locating existing patterns, finding tests/contracts, side-effect
+analysis, and dependency or migration checks. Keep the main context focused.
+
+### Phase 2 - Plan
+
+Create a concrete implementation plan before editing for any non-trivial task.
+Include files to change, intended behavior, risks, validation commands, and
+whether reviewer and critic passes are required.
+
+### Phase 3 - Implement in scoped units
+
+Implement in coherent, reviewable chunks. Follow existing repository patterns.
+
+**`declare_scope` discipline.** Before every coder or test-engineer delegation (and before every retry of one), call `declare_scope({ taskId, files })` with the exact file list the delegated agent is allowed to modify — including generated/lockfile paths the change will produce (e.g. `dist/*`, `package-lock.json`, `bun.lock`). Scope is enforced at the Edit/Write/Patch tool layer only — bash-based writes (`sed -i`, `echo >`, `cat > <<HEREDOC`, heredoc-to-file redirects) bypass the check (see issue #520), so do not rely on `declare_scope` to bound shell-redirect writes. If the file list is not 100% obvious from the prompt, declare the containing directories instead. Repeat the declaration before every retry, even when files appear unchanged — scope state is per-attempt, not per-task.
+
+If the project exposes `sast_scan` with `capture_baseline`, capture the
+phase-scoped SAST baseline before first coder delegation so later scans fail only
+on new findings rather than pre-existing infrastructure noise.
+
+### Phase 4 - Objective validation
+
+Run the strongest objective checks available for the task: tests, lint,
+typecheck, build, targeted repro scripts, and local runtime verification where
+relevant. If you cannot verify it, do not claim it is done.
+
+### Phase 5 - Independent reviewer validation
+
+Use an independent reviewer subagent when the task edits code, tests, docs,
+package metadata, release notes, or skill files. The reviewer must inspect the
+actual current diff and validation evidence after implementation. Any later edit
+invalidates approval and requires re-review.
+
+Reviewer responsibilities:
+
+- inspect the implementation with fresh context,
+- look for correctness bugs, edge cases, regressions, claim-vs-actual
+  mismatches, and test blind spots,
+- default to disbelief until evidence supports the change,
+- classify issues as `CONFIRMED`, `DISPROVED`, `UNVERIFIED`, or `PRE_EXISTING`
+  when useful,
+- verify that at least one regression test in the diff has falsification
+  evidence when the task claims regression coverage: the fix was temporarily
+  removed or bypassed, the test failed for the expected reason, the fix was
+  restored, and the test passed again. If no regression test is applicable, the
+  reviewer must record why,
+- return `APPROVE`, `NEEDS_REVISION`, or `BLOCKED`.
+
+`NEEDS_REVISION` or `BLOCKED` blocks completion until fixed and re-reviewed.
+
+### Phase 6 - Critic challenge
+
+Use a critic subagent after independent reviewer approval for any task that edits
+code, tests, docs, package metadata, release notes, or skill files. The critic
+must challenge the reviewer-approved current diff and evidence. Any later edit
+invalidates critic approval and requires another critic pass.
+
+### Phase 7 - Final synthesis
+
+Before calling work complete, verify:
+
+- objective validation ran and results were recorded,
+- the independent reviewer approved the latest diff and evidence,
+- a separate critic approved after reviewer approval,
+- every `NEEDS_REVISION` or `BLOCKED` item was fixed and re-reviewed,
+- no edit occurred after the latest reviewer/critic approval,
+- no behavior is unwired or deferred without explicit user instruction.
+
+## Adapter notes
+
+Runtime-specific adapter skills in `.claude/skills/swarm-implement/` and
+`.agents/skills/swarm-implement/` must stay thin and delegate to this canonical
+`.opencode` workflow.

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

@@ -141,8 +141,11 @@ tree:
   filesystem (`Read`/`Glob`/`Grep`), and fixes must land on the PR branch — without a
   checkout you would verify and patch the base branch's code instead. Record the
   `base_ref..head_ref` range for diff-scoped inspection.
- - If no PR reference was provided (a pasted-feedback session on the current branch),
-   confirm the current branch is the intended PR branch before editing.
+- Pass the `base_ref..head_ref` commit range in every read-only verification or
+  explorer/advisory-lane delegation so lane agents can inspect specific revisions
+  with `git show` when needed.
+- If no PR reference was provided (a pasted-feedback session on the current branch),
+  confirm the current branch is the intended PR branch before editing.
 
 When a verification lane result includes `output_ref`, treat `output` as a
 preview and call `retrieve_lane_output` before using it to classify, resolve,

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

@@ -422,6 +422,54 @@ The context pack must include, when available:
 
 ---
 
+## Review Finding Persistence
+
+Do not rely on conversation context to preserve review findings. Create a run
+artifact under `.swarm/pr-review/<run_id>/findings.jsonl` when file writes are
+allowed, or under `.swarm/evidence/pr-review-<run_id>-findings.jsonl` when the
+review already uses the evidence tree.
+
+Each persisted finding record must include at least:
+
+```json
+{"finding_id":"F-001","status":"PENDING","file_line":"src/file.ts:123","evidence":"quote, command output, lane id, or reviewer rationale","next_action":"route_to_reviewer"}
+```
+
+Minimum field contract:
+
+- `finding_id`: stable ID from the candidate/reviewer/critic ledger.
+- `status`: one of `PENDING`, `CONFIRMED`, `DISPROVED`, or `PRE_EXISTING`.
+- `file_line`: exact `file:line` reference, or `N/A` with reason when the
+  finding is cross-file or artifact-only.
+- `evidence`: compact source-backed proof, including lane/reviewer/critic IDs or
+  command output references when available.
+- `next_action`: the next required action, such as `route_to_reviewer`,
+  `route_to_critic`, `report`, `suppress_with_reason`, or `handoff_to_feedback`.
+
+Persist after every major validation boundary:
+
+1. **Post-explorer:** after Phase 3/4 candidate parsing and before reviewer
+   dispatch, write all candidates as `PENDING` with their lane provenance.
+2. **Post-reviewer:** after Phase 6 reviewer validation, update each reviewed
+   record to `CONFIRMED`, `DISPROVED`, `PRE_EXISTING`, or keep `PENDING` with a
+   concrete `next_action` if more evidence is required.
+3. **Post-critic:** after Phase 8 critic challenge, update final status,
+   severity/action notes in `evidence`, and final reporting or handoff action.
+
+Resume/reload procedure:
+
+1. Before continuing any compacted or resumed review, read the latest
+   `findings.jsonl` artifact and reconstruct the candidate/reviewer/critic
+   ledger from disk before dispatching more lanes.
+2. If the artifact is missing but a review context says prior lanes ran, stop and
+   surface the missing artifact as a coverage gap instead of reclassifying from
+   memory.
+3. Append new records rather than overwriting history unless the artifact format
+   explicitly tracks revisions; latest record for a `finding_id` wins during
+   reload.
+
+---
+
 ## Phase 1: Intent Reconstruction / Obligation Extraction
 
 Reconstruct what the PR is obligated to deliver before looking for bugs.
@@ -551,6 +599,10 @@ rather than preview-text extraction:
 
 If a lane has `output_degraded: true`, `transcript_incomplete: true`, or no usable `output_ref`, apply the COVERAGE GATE from Phase 3: retry (max 2) with materially different parameters, then use blocking `dispatch_lanes` or the Task tool as verified-equivalent fallbacks when lane tools do not work. If the gap cannot be closed, stop and surface the lane failure to the user as BLOCKED. Do not mark affected candidates UNVERIFIED to proceed past the gap. Never infer candidate absence from a preview.
 
+After candidate parsing and before reviewer dispatch, persist the post-explorer
+candidate ledger using the Review Finding Persistence contract. This is the
+durable recovery point for context compaction before Phase 6.
+
 **Fallback convention:** If the parser is unavailable, the explorer MAY emit
 `[CANDIDATE]` rows in the lane output as a fallback convention (see the
 Explorer Prompt Template at the end of this skill), but the orchestrator
@@ -728,6 +780,11 @@ Reviewer output format:
 
 `DISPROVED` findings must include the reason. `PRE_EXISTING` findings must include the base-branch evidence if available.
 
+After reviewer lanes settle, persist the post-reviewer finding ledger before
+critic routing or synthesis. The artifact must preserve `CONFIRMED`,
+`DISPROVED`, `PRE_EXISTING`, and still-`PENDING` records with reviewer IDs and
+next actions.
+
 ---
 
 ## Phase 7: Falsification Probe Requirement
@@ -782,6 +839,10 @@ The `[CRITIC]` row in the format above is **mandatory contract**, not advisory o
 
 Refuted findings become `DISPROVED` or `ADVISORY`, depending on critic rationale. Downgrades must be listed in the final validation provenance.
 
+After critic lanes settle, persist the post-critic finding ledger before final
+synthesis. This artifact is the source of truth for resumed reporting and for
+any later `swarm-pr-feedback` handoff.
+
 ---
 
 ## Runtime-Aware False-Positive Guard Checklist

package/.opencode/skills/writing-tests/SKILL.md

@@ -580,6 +580,13 @@ Rules:
 - The leading comment in the body explains the **prior buggy behavior** in concrete terms — what the code did before, not what it does now.
 - One regression test per finding. Do not pile unrelated assertions into a single regression block.
 
+Regression tests must be falsifiable. Before marking regression coverage
+complete, temporarily remove or bypass the fix, run the regression test and
+confirm it fails for the expected reason, restore the fix, then rerun the test
+and confirm it passes. Record both commands/results in the task evidence. If the
+fix cannot be safely reverted, document the exact reason and use the smallest
+equivalent mutation that would reintroduce the bug.
+
 Examples in-tree: `tests/unit/graph/graph-query.test.ts`, `tests/unit/graph/import-extractor.test.ts`, `tests/unit/graph/graph-store.test.ts`.
 
 ### Guardrail Authority Tests

package/dist/cli/{curator-rb05fjjk.js → curator-jpwvkpdv.js}

@@ -11,11 +11,11 @@ import {
   runCuratorInit,
   runCuratorPhase,
   writeCuratorSummary
-} from "./index-gyzxeza3.js";
+} from "./index-572t1qff.js";
 import"./index-4vsgp5a8.js";
 import"./index-c8s9a3zh.js";
 import"./index-wvxhynxq.js";
-import"./index-9b7a6agd.js";
+import"./index-6h82c2h0.js";
 import"./index-91j1sqzm.js";
 import"./index-xg18az81.js";
 import"./index-09xpycan.js";
@@ -28,7 +28,7 @@ import"./index-xmarctsf.js";
 import"./index-n1sptn1w.js";
 import"./index-bfwt3abw.js";
 import"./index-v4fcn4tr.js";
-import"./index-r8f89sm9.js";
+import"./index-0kxc7t16.js";
 import"./index-9b7qp18e.js";
 import"./index-4r5z8sgw.js";
 import"./index-57ymmh7h.js";

package/dist/cli/{curator-llm-factory-abw56kg0.js → curator-llm-factory-9y15npd5.js}

@@ -1,11 +1,11 @@
 // @bun
 import {
   createCuratorLLMDelegate
-} from "./index-gyzxeza3.js";
+} from "./index-572t1qff.js";
 import"./index-4vsgp5a8.js";
 import"./index-c8s9a3zh.js";
 import"./index-wvxhynxq.js";
-import"./index-9b7a6agd.js";
+import"./index-6h82c2h0.js";
 import"./index-91j1sqzm.js";
 import"./index-xg18az81.js";
 import"./index-09xpycan.js";
@@ -18,7 +18,7 @@ import"./index-xmarctsf.js";
 import"./index-n1sptn1w.js";
 import"./index-bfwt3abw.js";
 import"./index-v4fcn4tr.js";
-import"./index-r8f89sm9.js";
+import"./index-0kxc7t16.js";
 import"./index-9b7qp18e.js";
 import"./index-4r5z8sgw.js";
 import"./index-57ymmh7h.js";

package/dist/cli/{evidence-summary-service-nwdfnbz1.js → evidence-summary-service-6zsgw7x7.js}

@@ -6,9 +6,9 @@ import {
   loadPlanJsonOnly,
   mergeDurableGateEntriesFromEvidence,
   readDurableGateEvidence
-} from "./index-9b7a6agd.js";
+} from "./index-6h82c2h0.js";
 import"./index-91j1sqzm.js";
-import"./index-r8f89sm9.js";
+import"./index-0kxc7t16.js";
 import"./index-9b7qp18e.js";
 import"./index-57ymmh7h.js";
 import"./index-5e4e2hvv.js";

package/dist/cli/{gate-evidence-ywys9vfs.js → gate-evidence-pgr7d942.js}

@@ -9,7 +9,7 @@ import {
   readTaskEvidenceRaw,
   recordAgentDispatch,
   recordGateEvidence
-} from "./index-r8f89sm9.js";
+} from "./index-0kxc7t16.js";
 import"./index-9b7qp18e.js";
 import"./index-293f68mj.js";
 import"./index-3naa2ajc.js";

package/dist/cli/{guardrail-explain-dayy7zw4.js → guardrail-explain-jk0amzae.js}

@@ -1,12 +1,12 @@
 // @bun
 import {
   handleGuardrailExplain
-} from "./index-f45hbd5x.js";
-import"./index-gyzxeza3.js";
+} from "./index-57rthc1z.js";
+import"./index-572t1qff.js";
 import"./index-4vsgp5a8.js";
 import"./index-c8s9a3zh.js";
 import"./index-wvxhynxq.js";
-import"./index-9b7a6agd.js";
+import"./index-6h82c2h0.js";
 import"./index-91j1sqzm.js";
 import"./index-xg18az81.js";
 import"./index-09xpycan.js";
@@ -19,7 +19,7 @@ import"./index-xmarctsf.js";
 import"./index-n1sptn1w.js";
 import"./index-bfwt3abw.js";
 import"./index-v4fcn4tr.js";
-import"./index-r8f89sm9.js";
+import"./index-0kxc7t16.js";
 import"./index-9b7qp18e.js";
 import"./index-4r5z8sgw.js";
 import"./index-57ymmh7h.js";

package/dist/cli/{hive-promoter-34bdmw1w.js → hive-promoter-j2krbdn9.js}

@@ -5,11 +5,11 @@ import {
   isHiveEligible,
   promoteFromSwarm,
   promoteToHive
-} from "./index-gyzxeza3.js";
+} from "./index-572t1qff.js";
 import"./index-4vsgp5a8.js";
 import"./index-c8s9a3zh.js";
 import"./index-wvxhynxq.js";
-import"./index-9b7a6agd.js";
+import"./index-6h82c2h0.js";
 import"./index-91j1sqzm.js";
 import"./index-xg18az81.js";
 import"./index-09xpycan.js";
@@ -22,7 +22,7 @@ import"./index-xmarctsf.js";
 import"./index-n1sptn1w.js";
 import"./index-bfwt3abw.js";
 import"./index-v4fcn4tr.js";
-import"./index-r8f89sm9.js";
+import"./index-0kxc7t16.js";
 import"./index-9b7qp18e.js";
 import"./index-4r5z8sgw.js";
 import"./index-57ymmh7h.js";

package/dist/cli/{index-r8f89sm9.js → index-0kxc7t16.js}

@@ -216,7 +216,8 @@ function readTaskEvidenceRaw(directory, taskId) {
     const raw = readFileSync(evidencePath, "utf-8");
     return TaskEvidenceSchema.parse(JSON.parse(raw));
   } catch (error) {
-    if (error.code === "ENOENT")
+    const code = error.code;
+    if (code === "ENOENT" || code === "ENAMETOOLONG")
       return null;
     throw error;
   }

package/dist/cli/{index-gyzxeza3.js → index-572t1qff.js}

@@ -47,7 +47,7 @@ import {
   savePlan,
   transientBackoff,
   validateProjectRoot
-} from "./index-9b7a6agd.js";
+} from "./index-6h82c2h0.js";
 import {
   buildOpenSpecProjectionSync,
   detectSpeckit,
@@ -5678,6 +5678,7 @@ var BUNDLED_PROJECT_SKILLS = [
   "deep-dive",
   "deep-research",
   "codebase-review-swarm",
+  "swarm-implement",
   "design-docs",
   "swarm-pr-review",
   "swarm-pr-feedback",
@@ -7936,11 +7937,11 @@ var _internals8 = {
     return KnowledgeConfigSchema2.parse({});
   },
   applyCuratorKnowledgeUpdates: async (directory, recommendations, knowledgeConfig) => {
-    const { applyCuratorKnowledgeUpdates } = await import("./curator-rb05fjjk.js");
+    const { applyCuratorKnowledgeUpdates } = await import("./curator-jpwvkpdv.js");
     return applyCuratorKnowledgeUpdates(directory, recommendations, knowledgeConfig);
   },
   checkHivePromotions: async (entries, knowledgeConfig) => {
-    const { checkHivePromotions } = await import("./hive-promoter-34bdmw1w.js");
+    const { checkHivePromotions } = await import("./hive-promoter-j2krbdn9.js");
     return checkHivePromotions(entries, knowledgeConfig);
   },
   applyProposalTriage: async (directory, triage) => {
@@ -17266,8 +17267,8 @@ var _internals22 = {
   loadCuratorDeps: async () => {
     const [{ CuratorConfigSchema }, curator, { createCuratorLLMDelegate: createCuratorLLMDelegate2 }] = await Promise.all([
       import("./schema-x0ekqzvs.js"),
-      import("./curator-rb05fjjk.js"),
-      import("./curator-llm-factory-abw56kg0.js")
+      import("./curator-jpwvkpdv.js"),
+      import("./curator-llm-factory-9y15npd5.js")
     ]);
     return { CuratorConfigSchema, curator, createCuratorLLMDelegate: createCuratorLLMDelegate2 };
   }
@@ -17763,7 +17764,7 @@ import { fileURLToPath } from "url";
 // package.json
 var package_default = {
   name: "opencode-swarm",
-  version: "7.107.4",
+  version: "7.107.6",
   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",
@@ -17815,6 +17816,7 @@ var package_default = {
     ".opencode/skills/deep-dive",
     ".opencode/skills/deep-research",
     ".opencode/skills/codebase-review-swarm",
+    ".opencode/skills/swarm-implement",
     ".opencode/skills/design-docs",
     ".opencode/skills/swarm-pr-review",
     ".opencode/skills/swarm-pr-feedback",
@@ -20020,7 +20022,7 @@ async function handleEvidenceCommand(directory, args) {
   return formatTaskEvidenceMarkdown(evidenceData);
 }
 async function handleEvidenceSummaryCommand(directory) {
-  const { buildEvidenceSummary } = await import("./evidence-summary-service-nwdfnbz1.js");
+  const { buildEvidenceSummary } = await import("./evidence-summary-service-6zsgw7x7.js");
   const artifact = await buildEvidenceSummary(directory);
   if (!artifact) {
     return "No plan found. Run `/swarm plan` to check plan status.";
@@ -32287,7 +32289,7 @@ function buildDetailedHelp(commandName, entry) {
 async function handleHelpCommand(ctx) {
   const targetCommand = ctx.args.join(" ");
   if (!targetCommand) {
-    const { buildHelpText } = await import("./index-19vxtwa6.js");
+    const { buildHelpText } = await import("./index-h28wfp7n.js");
     return buildHelpText();
   }
   const tokens = targetCommand.split(/\s+/);
@@ -32296,7 +32298,7 @@ async function handleHelpCommand(ctx) {
     return _internals49.buildDetailedHelp(resolved.key, resolved.entry);
   }
   const similar = _internals49.findSimilarCommands(targetCommand);
-  const { buildHelpText: fullHelp } = await import("./index-19vxtwa6.js");
+  const { buildHelpText: fullHelp } = await import("./index-h28wfp7n.js");
   if (similar.length > 0) {
     return `Command '/swarm ${targetCommand}' not found.
 
@@ -32429,7 +32431,7 @@ var COMMAND_REGISTRY = {
   },
   "guardrail explain": {
     handler: async (ctx) => {
-      const { handleGuardrailExplain } = await import("./guardrail-explain-dayy7zw4.js");
+      const { handleGuardrailExplain } = await import("./guardrail-explain-jk0amzae.js");
       return handleGuardrailExplain(ctx.directory, ctx.args);
     },
     description: "Dry-run: show what the guardrails would do to a command or write target (executes nothing)",

package/dist/cli/{index-f45hbd5x.js → index-57rthc1z.js}

@@ -12,7 +12,7 @@ import {
   detectPosixWrites,
   detectWindowsWrites,
   resolveWriteTargets
-} from "./index-gyzxeza3.js";
+} from "./index-572t1qff.js";
 import {
   checkFileAuthority,
   classifyFile,