opencode-swarm 7.126.6 → 7.127.1

package/.opencode/skills/issue-tracer/SKILL.md

@@ -4,7 +4,7 @@ audience: swarm-plugin
 description: Evidence-first investigation and full resolution of issues and bugs. Use when asked to investigate, trace, root-cause, reproduce, plan, fix, resolve, close, or prepare a PR for an issue, bug report, defect, regression, failing test, crash, or confusing runtime behavior. Drives intake, reproduction, reasoning-guided localization, no-gap fix planning, independent critic and implementation review, recurrence-class eradication, and invariant-aware PR-ready closure under a mandatory full-resolution contract that forbids partial fixes, deferred work, and unwired code.
 license: MIT
 metadata:
-  version: 2.0.0
+  version: 2.1.0
   source: .opencode/skills/issue-tracer/SKILL.md
 ---
 
@@ -48,11 +48,11 @@ This skill is agent-neutral. Wherever the protocol says "your file-edit tool", "
 |---|---|---|---|---|
 | OpenCode | `edit`, `write` | `todowrite` | `webfetch` | `task` / lane dispatch |
 | Claude Code | `Edit`, `Write`, `MultiEdit` | `TodoWrite` | `WebFetch`, `WebSearch` | `Agent` / `Task` |
-| OpenAI Codex | `apply_patch` | `update_plan` | `web` | not available in-session |
-| ZCode | `apply_patch` | `update_plan` | `web` | not available in-session |
-| GitHub coding agent | `edit` (native commit) | built-in task list | `web` | not available in-session |
+| OpenAI Codex | `apply_patch` | `update_plan` | `web` | native subagent dispatch (fresh context) |
+| ZCode | `apply_patch` | `update_plan` | `web` | native subagent dispatch (fresh context) |
+| GitHub coding agent | `edit` (native commit) | built-in task list | `web` | native subagent dispatch (fresh context) |
 
-Fill each cell from your own current tool docs (see `references/install.md` for per-agent details and the rationale behind each row). "Not available in-session" means the agent cannot spawn an independent subagent; use the fallback self-review/self-critic passes (Phase 4.5 / 4.6) and disclose the limitation. Any agent without a plan/tasklist tool keeps the phase checklist inline in its working notes.
+Fill each cell from your own current tool docs (see `references/install.md` for per-agent details and the rationale behind each row). Every listed agent currently exposes fresh-context subagent dispatch — treat the subagent column as capability-first: detect availability from the session's actual tool list, never from the agent's name. A restricted session on any harness may genuinely lack a subagent mechanism; only then do the fallback self-review/self-critic passes (Phase 4.5 / 4.6) apply, with the limitation disclosed. Any agent without a plan/tasklist tool keeps the phase checklist inline in its working notes.
 
 ## Source Policy
 
@@ -155,6 +155,7 @@ Read the relevant reference before starting that phase:
 3. If the worktree has unrelated user changes, do not overwrite them. Continue read-only until you can isolate your changes or ask the user.
 4. Run `.opencode/skills/issue-tracer/scripts/trace-init.sh <issue-slug>` (from the repo root) to create the trace directory and its exclusion, and initialize `state.md` (or the compact inline trail).
 5. Build a phase checklist with your plan/tasklist tool (or inline). Mark only one step in progress at a time, and mark steps complete only after gate verification.
+6. Scale investigation and review depth to change size and risk, mirroring the S/M/L depth-tier model of the sibling swarm PR skills: trivial low-risk fixes take the lighter paths already marked in this protocol (Phase 2 item 7's single pass, Phase 3 item 1's reduced candidate bar), while risk triggers — auth/identity/secrets, untrusted input, subprocess/filesystem execution, concurrency/state, dependencies/build/release, schema/migrations, payments or PII, generated artifacts — always take the deeper passes regardless of diff size. Depth scaling never waives a phase gate.
 
 ### Phase 0 Gate
 
@@ -180,7 +181,7 @@ Proceed only when one is true: the issue is reproduced with exact failing output
 Goal: isolate the root cause to the narrowest truthful granularity: file, symbol, line range, invariant, and triggering input. Use `references/localization-playbook.md`.
 
 1. Build candidate locations from issue evidence: stack traces and error text, failing test names, UI route/API endpoint/CLI command names, labels and linked PRs, recent commits touching related areas.
-2. Search and read in parallel where possible: search for symbols, routes, commands, strings, errors, config keys; confirm against tracked files; use `git log`/`git blame` where useful.
+2. Search and read in parallel where possible: search for symbols, routes, commands, strings, errors, config keys; confirm against tracked files; use `git log`/`git blame` where useful. When the candidate surface is broad or ambiguous, fan out to independent fresh-context explorer subagents with disjoint scopes — 1–2 for a trivial surface, 3–5 for a typical one, more only for genuinely multi-module scopes. Explorers return candidate locations with file:line evidence, never verdicts; their candidates enter the same ranking and bug-specific-explanation bar as your own.
 3. Use reasoning-guided hierarchical localization — file → element (function/class/handler/config) → line/condition.
 4. Maintain `03-localization-log.md`: every hypothesis, files read and why, commands run and results, evidence for and against, ruled-out paths.
 5. Follow call chains in both directions — from input/event to failure, and from failure back to origin — through config, serialization, async boundaries, state transitions, and feature flags.

package/.opencode/skills/issue-tracer/references/install.md

@@ -14,11 +14,11 @@ The canonical version is the `metadata.version` field in the canonical `SKILL.md
 | ZCode | `.agents/skills/issue-tracer/SKILL.md` | adapter shim → canonical |
 | GitHub coding agent | repo-root `AGENTS.md` pointer | canonical |
 
-The adapter shims are one-line pointers to `../../../.opencode/skills/issue-tracer/SKILL.md`; they carry no protocol of their own, so a project checkout always executes a single canonical body.
+The adapter shims point to `../../../.opencode/skills/issue-tracer/SKILL.md` as the canonical workflow and add only short per-agent execution notes (tool bindings, fallback labels, publish routing); the protocol itself lives in the single canonical body, so a project checkout always executes one protocol.
 
 ### Agent Adapter table — how each row was filled
 
-The canonical SKILL.md's Agent Adapter table maps each capability to a concrete tool per agent. Those rows were filled from each agent's current tool surface: OpenCode (`edit`/`write`, `todowrite`, `webfetch`, `task`), Claude Code (`Edit`/`Write`/`MultiEdit`, `TodoWrite`, `WebFetch`/`WebSearch`, `Agent`/`Task`), OpenAI Codex (`apply_patch`, `update_plan`, `web`), and the GitHub coding agent (`edit`, built-in task list, `web`). **ZCode** is mapped to the Codex-native tool surface (`apply_patch`/`update_plan`/`web`) because it is a Codex-family CLI that shares the project-level `.agents/skills/` discovery tree with Codex; if your ZCode build exposes different tool names, treat the table as capability-first and substitute your build's names.
+The canonical SKILL.md's Agent Adapter table maps each capability to a concrete tool per agent. Those rows were filled from each agent's current tool surface: OpenCode (`edit`/`write`, `todowrite`, `webfetch`, `task`), Claude Code (`Edit`/`Write`/`MultiEdit`, `TodoWrite`, `WebFetch`/`WebSearch`, `Agent`/`Task`), OpenAI Codex (`apply_patch`, `update_plan`, `web`, plus native fresh-context subagent dispatch), and the GitHub coding agent (`edit`, built-in task list, `web`, plus native fresh-context subagent dispatch). **ZCode** is mapped to the Codex-native tool surface (`apply_patch`/`update_plan`/`web`, plus native fresh-context subagent dispatch) because it is a Codex-family CLI that shares the project-level `.agents/skills/` discovery tree with Codex; if your ZCode build exposes different tool names, treat the table as capability-first and substitute your build's names.
 
 ## User-level installs can SHADOW the project copy
 
@@ -60,4 +60,6 @@ diff <(grep 'version:' ~/.codex/skills/issue-tracer/SKILL.md 2>/dev/null || echo
 
 The safest default is to keep no user-level `issue-tracer` copy at all and let each project ship its own canonical, so version drift cannot occur. If you do keep a user-level copy, reconcile it whenever the project canonical's `metadata.version` changes.
 
-GitHub coding agents load the repository's checked-in `AGENTS.md` and `.opencode/skills/issue-tracer/SKILL.md` directly, with no user-level home directory, so shadowing does not apply to that surface.
+Maintainer rule: bump `metadata.version` (canonical SKILL.md plus both adapter shims, in lockstep) in the same changeset as any canonical content edit — the stamp is the only reconciliation signal user-level copies have, and an unbumped edit silently defeats it.
+
+GitHub coding agents load the repository's checked-in `AGENTS.md` and `.opencode/skills/issue-tracer/SKILL.md` directly, with no user-level home directory, so shadowing does not apply to that surface; their sessions can spawn fresh-context subagents, so the independent critic/review gates run as the preferred path there too.

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

@@ -123,6 +123,35 @@ 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.
 
+## Runtime Capability Profiles
+
+This skill runs on any agent harness. Detect the active profile from the
+actual tool list before triage — the same three profiles defined in
+`../swarm-pr-review/SKILL.md` (Runtime Capability Profiles):
+
+- **Profile A — mechanical PR-feedback controller.** The plugin's tools are
+  present in this session: `dispatch_lanes_async`, `collect_lane_results`,
+  `retrieve_lane_output`, `prepare_pr_feedback_scope`,
+  `run_pr_feedback_stage_a`, `complete_pr_workflow`. The controller's
+  fail-closed accounting (immutable inventory, ordered gate lanes, content
+  digests, arming, bound push) is authoritative; bypassing it — direct
+  subagent calls, blocking dispatch, prose verdicts — is BLOCKED while it is
+  active.
+- **Profile B — native parallel subagents, no controller.** Run the same
+  intake → verify → fix → gate → publish discipline using your harness's
+  subagent tool for verification lanes and gate roles; you maintain the
+  ledger, the ownership partition, and the digest accounting yourself in
+  session/task workspace files (never under `.swarm/`, which belongs to the
+  plugin runtime).
+- **Profile C — single context, no subagents.** Same discipline as strictly
+  separated sequential passes that re-derive rather than restate earlier
+  reasoning, plus explicit disclosure in the closure ledger that gate
+  independence was procedural.
+
+Controller-tool absence is NOT a blocker; Profiles B and C are first-class
+execution paths. BLOCKED is reserved for bypassing an active controller and
+for verification or coverage gaps that stay unclosable after bounded retries.
+
 ## Pre-flight: Check Out the PR Branch Locally
 
 Before verifying any claim or making any fix, ensure the PR branch is the working
@@ -141,9 +170,11 @@ tree:
   Abort your rebase, take the remote state, then add minor improvements on top.
 - Verify the working tree is clean first (`git status --porcelain`). If tracked
   changes exist, call `prepare_pr_workflow_checkout` with every explicit dirty
-  tracked path. It creates an auditable, path-scoped stash and returns its
+  tracked path (Profile A). It creates an auditable, path-scoped stash and returns its
   recovery command. Do not issue `git stash` through shell. The controller never
   stashes untracked files; move or remove those manually, or abort the checkout.
+  Without the controller, surface dirty tracked state to the user or abort the
+  checkout — do not blind-stash.
 - **Check out the head branch locally before dispatching feedback lanes.** Feedback verification reads the working-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
@@ -174,6 +205,9 @@ preview and call `retrieve_lane_output` before using it to classify, resolve,
 disprove, or group feedback items. If the result is `output_degraded`,
 `transcript_incomplete`, or truncated without a usable ref, keep the affected
 ledger items as `NEEDS_MORE_EVIDENCE` or re-dispatch a narrower read-only lane.
+(Profile A. On Profiles B/C, read each verification subagent's or pass's full
+report directly — a truncated or summary-only report is a preview, not
+verification evidence, and keeps its items open the same way.)
 
 ## Pre-flight: Dirty Worktree Handling
 
@@ -253,7 +287,8 @@ If a source is unavailable, retry with alternative access paths. If unavailable
 
 ### Async advisory verification lanes
 
-After the complete feedback ledger exists and before editing, use
+After the complete feedback ledger exists and before editing, run independent
+read-only verification lanes. Under Profile A, use
 `dispatch_lanes_async` with `mode: "swarm-pr-feedback:verification"`, the
 complete immutable `feedback_inventory` ID list, the exact current
 `pr_head_sha`, and each lane's exact
@@ -298,12 +333,21 @@ COVERAGE GATE:
 retry failed lanes (max 2) as another
 `swarm-pr-feedback:verification` async batch with the same immutable inventory,
 exact `pr_head_sha`, agent type, prompt, scope, and isolation, or stop and
-surface the lane failure to the user as BLOCKED. Blocking and direct-Task
-fallbacks are rejected because they cannot satisfy the durable ownership and
-head-provenance gate.
+surface the lane failure to the user as BLOCKED. Under Profile A, blocking and
+direct-Task fallbacks are rejected because they cannot satisfy the durable
+ownership and head-provenance gate.
 Do not proceed with "blocking verification and record that async advisory lanes
 were unavailable" — record-and-continue is not coverage closure.
 
+Under Profile B, partition the same immutable inventory across fresh read-only
+verification subagents — every `FB-###` item owned by exactly one lane and the
+union of lanes covering the entire ledger — with each prompt stating its owned
+IDs and the exact `pr_head_sha`, and each lane returning one
+`[FEEDBACK-VERIFIED]` row per owned item. Under Profile C, verify the ledger
+in sequential category passes with the same one-row-per-item contract. On
+every profile, no item may be classified until its verification lane or pass
+has settled, and unclosable verification gaps are surfaced as BLOCKED.
+
 ### CI matrix cascade check (do this before fixing)
 
 When the PR's `unit` job is a matrix across multiple OSes and downstream jobs
@@ -506,9 +550,9 @@ pre-checks; Stage B = `reviewer` + `test_engineer` per-task gates (consistent
 with `execute`, `plan`, `specify`, `brainstorm`, `docs/swarm-briefing.md`, and
 `docs/council/README.md`).
 
-**Mechanical controller contract.** Prose acknowledgements, direct `Task` calls,
+**Mechanical controller contract (Profile A).** Prose acknowledgements, direct `Task` calls,
 blocking dispatch, reused conversations, and free-form `APPROVE`/`PASS` text do
-not satisfy these gates. The durable controller requires this exact sequence on
+not satisfy these gates while the controller is active. The durable controller requires this exact sequence on
 one content digest:
 
 Controller authority follows the parent/child session ancestry. Coder and
@@ -564,6 +608,23 @@ immutable intake head, so zero commits, multiple commits, merge commits,
 amend/non-descendant histories,
 `--allow-empty`, and partially committed reviewed content fail closed. There is no speed, efficiency, token, or time exception.
 
+**Without the controller (Profiles B/C).** The same gates run in the same
+order with the same one-row-per-feedback-ID verdict contracts; what changes is
+the executor. Stage A: run the repository's discovered build, typecheck, and
+lint/format obligations, exact `git diff --check`, and one targeted
+reproduction/regression command yourself, recording each command and its
+output as a receipt in the ledger; track the content digest manually (for
+example `git rev-parse HEAD` plus a working-tree diff hash) so stale receipts
+are detectable, and re-run the whole set after any content change. Stage B:
+one fresh reviewer subagent, then one fresh test-engineer-role subagent
+(Profile B), or two strictly separated re-derivation passes (Profile C).
+Closeout: a separate fresh reviewer, then a separate fresh critic, per the
+swarm closeout contract. Emit the same `[STAGE-B-REVIEW]`, `[STAGE-B-TEST]`,
+`[CLOSEOUT-REVIEW]`, and `[CLOSEOUT-CRITIC]` rows, record the verdicts in the
+session task-gates artifact, and disclose Profile C's procedural independence
+in the closure ledger. Any edit after a gate verdict invalidates that verdict
+and every later one; restart at Stage A.
+
 If a gate failure is suspected pre-existing, prove it on the base branch or
 label it `UNVERIFIED`. Do not call the branch green while required checks are
 non-green.
@@ -688,7 +749,8 @@ pre-checks and must not be folded into Stage A.
 ## Publishing And Communication
 
 After every ordered local gate passes on one unchanged content digest, create
-the reviewed commit with one standalone `git commit` command. Then call
+the reviewed commit with one standalone `git commit` command. Under Profile A,
+then call
 `complete_pr_workflow` once with `mode: "PR_FEEDBACK"` and the immutable intake
 `pr_head_sha`. A `ready-to-publish` result arms publication but deliberately
 keeps the durable gate active and binds that post-commit HEAD to the current
@@ -713,6 +775,12 @@ branch; a locally forged or fetched tracking ref is never publication proof.
 The gate clears only after both observations agree, before any PR
 comment/body/thread write.
 
+Under Profiles B/C, the same publication invariants apply procedurally: one
+reviewed commit on the PR branch, a single non-force push of exactly that
+commit to the PR head branch through the repository's normal workflow, then
+read-only verification that the actual remote head equals the pushed commit
+before any PR comment/body/thread write.
+
 Commits and pushes follow the repository's commit/PR workflow (for example
 `file:.swarm/bundled-skills/commit-pr/SKILL.md` when that bundled workflow is
 available) — do not push ad-hoc.
@@ -735,18 +803,23 @@ head, and record the exact evidence used.
 
 ## Final Output
 
-Before emitting the user-facing final response, call `complete_pr_workflow` a
+Under Profile A, before emitting the user-facing final response, call
+`complete_pr_workflow` a
 second time with the same mode and immutable verification `pr_head_sha`. The
 tool clears the durable session gate only when the content digest still equals
 the independently approved digest, the exact approved commit remains current,
 its bound upstream remote-tracking ref points to that exact commit, every
 feedback ID has exact-provenance evidence, and no PR-workflow lanes remain
-open. While the gate remains active, the runtime replaces architect
-final-response text with a mechanical blocked notice and normally re-wakes an
+open. While the gate remains active, the runtime prepends a workflow-active
+banner to architect text (the model's text is preserved below it) and normally re-wakes an
 idle parent session. A user interruption pauses automatic wakes until a later
 explicit user turn settles; the durable gate remains available to continue or
 abort.
 
+Under Profiles B/C, no mechanical gate exists: emit the final response only
+after the closure ledger accounts for every original item and the pushed
+remote head has been verified read-only.
+
 Report:
 
 - intake sources checked and unavailable sources,
@@ -759,7 +832,7 @@ Report:
 
 End with a complete ledger mapping every original item to its outcome.
 
-## Aborting an unrecoverable feedback workflow (pre-armed only)
+## Aborting an unrecoverable feedback workflow (Profile A, pre-armed only)
 
 If the verification bind is genuinely unreachable (the PR head cannot be
 fetched or checked out, or a compound `git fetch … && git checkout …` keeps
@@ -772,4 +845,5 @@ arming you MUST complete via `complete_pr_workflow` (or push the bound
 commit first), because aborting an armed gate would drop the immutable-
 commit binding and leave a half-published commit. The user can also run
 `/swarm abort-pr-workflow` once the wake budget suspends. Abort is a
-recovery tool, not a gate-skip shortcut.
+recovery tool, not a gate-skip shortcut. On Profiles B/C there is no durable
+gate to abort: report the blocker to the user and stop.