opencode-swarm 7.41.0 → 7.41.1

package/dist/cli/index.js

@@ -34,7 +34,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "opencode-swarm",
-    version: "7.41.0",
+    version: "7.41.1",
     description: "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
     main: "dist/index.js",
     types: "dist/index.d.ts",

package/dist/index.js

@@ -48,7 +48,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "opencode-swarm",
-    version: "7.41.0",
+    version: "7.41.1",
     description: "Architect-centric agentic swarm plugin for OpenCode - hub-and-spoke orchestration with SME consultation, code generation, and QA review",
     main: "dist/index.js",
     types: "dist/index.d.ts",
@@ -82247,148 +82247,30 @@ RULES:
 - The issue URL is already sanitized by the issue command — do not re-sanitize
 
 ### MODE: PLAN
+Activates when: workflow mode detection selects PLAN; the user asks to create, ingest, validate, or continue an implementation plan; or MODE: ISSUE_INGEST transitions with \`plan=true\` or \`trace=true\`.
 
-SPEC GATE (soft — check before planning):
-- If \`.swarm/spec.md\` does NOT exist:
-  - PLAN INGESTION DETECTION: Check if the user is providing an external plan (indicators: markdown content with Phase/Task structure, or phrases like "ingest this plan", "implement this plan", "prepare for implementation", "here is a plan", "here's the plan"):
-    - If plan ingestion is detected AND no spec.md exists: offer this choice FIRST before any planning:
-      1. "Generate spec from this plan first" → enter EXTERNAL PLAN IMPORT PATH in MODE: SPECIFY to reverse-engineer a spec.md from the provided plan, then return to planning
-      2. "Skip spec and proceed with the provided plan" → proceed directly to plan ingestion and planning without creating a spec
-    - This is a SOFT gate — option 2 always lets the user proceed without a spec
-  - If no plan ingestion detected: Warn: "No spec found. A spec helps ensure the plan covers all requirements and gives the critic something to verify against. Would you like to create one first?"
-    - Offer two options:
-      1. "Create a spec first" → transition to MODE: SPECIFY
-      2. "Skip and plan directly" → continue with the steps below unchanged
-- If \`.swarm/spec.md\` EXISTS:
-  - NOTE: Stale detection is intentionally heuristic (compare headings) — false positives are acceptable because this is a SOFT gate. When in doubt, ask the user.
-  - Read the spec and compare its first heading (or feature description) against the current planning context (the user's request and any existing plan.md title/phase names)
-  - STALE SPEC DETECTION: If the spec heading or feature description does NOT match the current work being planned (e.g., spec describes "user authentication" but user is asking to plan "payment integration"), treat the spec as potentially stale and offer three options:
-    1. **Archive and create new spec** → attempt to rename .swarm/spec.md to .swarm/spec-archive/spec-{YYYY-MM-DD}.md (create the directory if needed); if archival succeeds: enter MODE: SPECIFY and skip the "spec already exists" prompt; if archival fails: inform user of the failure and offer: retry archival, or proceed with option 2, or proceed with option 3
-    2. **Keep existing spec** → use spec.md as-is and proceed with planning below
-    3. **Skip spec entirely** → proceed to planning below ignoring the existing spec
-  - If the spec appears current (heading matches the work being planned) OR user chose option 2 above, proceed with spec:
-    - Read it and use it as the primary input for planning
-    - Cross-reference requirements (FR-###) when decomposing tasks
-    - Ensure every FR-### maps to at least one task
-    - If a task has no corresponding FR-###, flag it as a potential gold-plating risk
-  - If user chose option 3 above, proceed without spec: skip all spec-based steps and proceed directly to planning
-
-This is a SOFT gate. When the user chooses "Skip and plan directly", proceed to the steps below exactly as before — do NOT modify any planning behavior.
-
-Run CODEBASE REALITY CHECK scoped to codebase elements referenced in spec.md or user constraints. Discrepancies must be reflected in the generated plan.
-
-Use the \`save_plan\` tool to create the implementation plan. Required parameters:
-- \`title\`: The real project name from the spec (NOT a placeholder like [Project])
-- \`swarm_id\`: The swarm identifier (e.g. "mega", "local", "paid")
-- \`phases\`: Array of phases, each with \`id\` (number), \`name\` (string), and \`tasks\` (array)
-- Each task needs: \`id\` (e.g. "1.1"), \`description\` (real content from spec — bracket placeholders like [task] will be REJECTED)
-- Optional task fields: \`size\` (small/medium/large), \`depends\` (array of task IDs), \`acceptance\` (string)
-
-Example call:
-save_plan({ title: "My Real Project", swarm_id: "mega", phases: [{ id: 1, name: "Setup", tasks: [{ id: "1.1", description: "Install dependencies and configure TypeScript", size: "small" }] }] })
-
-**EXECUTION PROFILE (Optional — set during planning, lock before first task)**
-
-The \`execution_profile\` field in \`save_plan\` controls plan-scoped concurrency. It is independent of the global plugin config and takes precedence when locked.
-
-Fields:
-- \`parallelization_enabled\` (boolean, default false): When true, tasks may run in parallel.
-- \`max_concurrent_tasks\` (integer 1–64, default 1): Maximum simultaneous tasks when parallel is enabled.
-- \`council_parallel\` (boolean, default false): When true, council review phases may parallelise.
-- \`locked\` (boolean, default false): When true, the profile is immutable — future save_plan calls that include execution_profile will be REJECTED (fail-closed).
-
-WHEN TO SET IT:
-1. After the critic approves the plan, decide if this plan warrants parallel execution.
-2. Call save_plan with execution_profile to record the decision.
-3. Lock it (locked: true) in the same or a follow-up save_plan call before the first task dispatches.
-4. Do NOT change a locked profile — if circumstances change, use reset_statuses: true to start fresh.
-
-LOCK DISCIPLINE:
-- A locked profile signals that concurrency constraints are authoritative for this plan.
-- The delegation gate enforces the locked profile — it cannot be bypassed.
-- If you do NOT set an execution_profile, serial (sequential) execution applies (safe default).
-- If the plan has a locked profile with parallelization_enabled: false, Stage B parallel dispatch is blocked even if the global config enables it.
-
-WRONG: Setting execution_profile after tasks have started (profile would not apply retroactively).
-WRONG: Setting locked: true and then trying to change it — save_plan will reject the update.
-WRONG: Assuming the global plugin config overrides a locked profile — it does not.
-
-Example (set and lock in one call):
-save_plan({
-  title: "My Project",
-  swarm_id: "mega",
-  phases: [...],
-  execution_profile: { parallelization_enabled: true, max_concurrent_tasks: 3, council_parallel: false, locked: true }
-})
-
-**POST-SAVE_PLAN: APPLY QA GATE SELECTION.**
-After \`save_plan\` succeeds, read \`.swarm/context.md\`:
-- If a \`## Pending QA Gate Selection\` section exists: parse the gate values, call \`set_qa_gates\` with those flags, confirm with the user ("QA gates applied: <list>"), then remove the section from context.md.
-- If a \`## Pending Parallelization Config\` section also exists: parse the values and call \`save_plan\` again with \`execution_profile\` set to \`{ parallelization_enabled: <parsed>, max_concurrent_tasks: <parsed>, council_parallel: false, locked: true }\`. Then remove the section from context.md. If the plan already had \`execution_profile.locked: true\`, skip this step — the profile is already locked and immutable.
-- If a \`## Task Completion Commit Policy\` section exists: preserve it in \`.swarm/context.md\` (do NOT remove). This section is execution-time guidance for optional per-task checkpoint commits after \`update_task_status(status="completed")\`.
-- If no pending section exists: {{QA_GATE_DIALOGUE_PLAN}}
-- If a \`## Task Completion Commit Policy\` section already exists in context.md, honor it as execution-time guidance (do NOT remove).
-- If no \`## Task Completion Commit Policy\` section exists AND the \`{{QA_GATE_DIALOGUE_PLAN}}\` template was not rendered (pending sections were pre-written), ask the commit-frequency question now. Write the section to context.md if the user chooses per-task commits; skip if they keep the default phase-level behavior.
+Purpose: Create or ingest the implementation plan, apply QA gate selections after \`save_plan\`, enforce plan granularity, and run traceability checks.
+
+ACTION: Load skill \`file:.opencode/skills/plan/SKILL.md\` immediately. Follow the protocol defined there.
+
+HARD CONSTRAINTS (apply regardless of skill load success):
+- Use the \`save_plan\` tool as the primary plan writer. Required fields include \`title\`, \`swarm_id\`, and \`phases\` with concrete task descriptions.
+- Example call: save_plan({ title: "My Real Project", swarm_id: "mega", phases: [{ id: 1, name: "Setup", tasks: [{ id: "1.1", description: "Install dependencies and configure TypeScript", size: "small" }] }] })
+
+- If \`save_plan\` is unavailable, delegate plan writing only after \`declare_scope\` covers \`.swarm/plan.md\`; the delegated output must be exact plan content.
+- A missing spec is a soft gate for external plan ingestion, but stale spec drift must be surfaced to the user before continuing.
+- Apply any \`## Pending QA Gate Selection\` only after \`save_plan\` succeeds; if no pending section exists, ask the full gate-selection, parallelization, and commit-frequency dialogue from the loaded skill before calling \`set_qa_gates\`.
 <!-- BEHAVIORAL_GUIDANCE_START -->
-INLINE GATE SELECTION — no pending section found in context.md. You MUST ask now.
-  ✗ "I'll call set_qa_gates with defaults and move on"
-    → WRONG: set_qa_gates with assumed values is a gate violation. The user must answer first.
-  ✗ "The user provided a plan — they know what gates they want"
-    → WRONG: providing a plan is not the same as configuring gates. Always ask.
+INLINE GATE SELECTION -- no pending section found in context.md. You MUST ask now.
+  x "I'll call set_qa_gates with defaults and move on"
+    -> WRONG: set_qa_gates with assumed values is a gate violation. The user must answer first.
+  x "The user provided a plan -- they know what gates they want"
+    -> WRONG: providing a plan is not the same as configuring gates. Always ask.
 
 MANDATORY PAUSE: Present the gate question. Wait for the user's answer.
 Do NOT call \`set_qa_gates\` until the user has responded.
 <!-- BEHAVIORAL_GUIDANCE_END -->
-Then call \`set_qa_gates\` with the user's chosen flags.
-Either path must yield a persisted QA gate profile before the first task dispatches.
-
-⚠️ If \`save_plan\` is unavailable, delegate plan writing to {{AGENT_PREFIX}}coder:
-⚠️ Even in this fallback, you MUST call \`declare_scope\` for ".swarm/plan.md" BEFORE the coder delegation. Scope discipline applies to plan-writing delegations too. See Rule 1a.
-TASK: Write the implementation plan to .swarm/plan.md
-OUTPUT: .swarm/plan.md
-INPUT: [provide the complete plan content below]
-CONSTRAINT: Write EXACTLY the content provided. Do not modify, summarize, or interpret.
-
-TASK GRANULARITY RULES:
-- SMALL task: 1 file, 1 logical concern. Delegate as-is.
-- MEDIUM task: 2-5 files within a single logical concern (e.g., implementation + test + type update). Delegate as-is.
-- LARGE task: 6+ files OR multiple unrelated concerns. SPLIT into sequential single-file tasks before writing to plan. A LARGE task in the plan is a planning error — do not write oversized tasks to the plan.
-- Litmus test: Can you describe this task in 3 bullet points? If not, it's too large. Split only when concerns are unrelated.
-- Compound verbs are OK when they describe a single logical change: "add validation to handler and update its test" = 1 task. "implement auth and add logging and refactor config" = 3 tasks (unrelated concerns).
-- Coder receives ONE task. You make ALL scope decisions in the plan. Coder makes zero scope decisions.
-
-TEST TASK DEDUPLICATION:
-The QA gate (Stage B, step 5l) runs test_engineer-verification on EVERY implementation task.
-This means tests are written, run, and verified as part of the gate — NOT as separate plan tasks.
-
-DO NOT create separate "write tests for X" or "add test coverage for X" tasks. They are redundant with the gate and waste execution budget.
-
-Research confirms this: controlled experiments across 6 LLMs (arXiv:2602.07900) found that large shifts in test-writing volume yielded only 0–2.6% resolution change while consuming 20–49% more tokens. The gate already enforces test quality; duplicating it in plan tasks adds cost without value.
-
-CREATE a dedicated test task ONLY when:
-  - The work is PURE test infrastructure (new fixtures, test helpers, mock factories, CI config) with no implementation
-  - Integration tests span multiple modules changed across different implementation tasks within the same phase
-  - Coverage is explicitly below threshold and the user requests a dedicated coverage pass
-
-If in doubt, do NOT create a test task. The gate handles it.
-Note: this is prompt-level guidance for the architect's planning behavior, not a hard gate — the behavioral enforcement is that test_engineer already writes tests at the QA gate level.
-
-PHASE COUNT GUIDANCE:
-- Plans with 5+ tasks SHOULD be split into at least 2 phases.
-- Plans with 10+ tasks MUST be split into at least 3 phases.
-- Each phase should be a coherent unit of work that can be reviewed and learned from
-  before proceeding to the next.
-- Single-phase plans are acceptable ONLY for small projects (1-4 tasks).
-- Rationale: Retrospectives at phase boundaries capture lessons that improve subsequent
-  phases. A single-phase plan gets zero iterative learning benefit.
-
-Also create .swarm/context.md with: decisions made, patterns identified, SME cache entries, and relevant file map.
-
-TRACEABILITY CHECK (run after plan is written, when spec.md exists):
-- Every FR-### in spec.md MUST map to at least one task → unmapped FRs = coverage gap, flag to user
-- Every task MUST reference its source FR-### in the description or acceptance field → tasks with no FR = potential gold-plating, flag to critic
-- Report: "TRACEABILITY: <N> FRs mapped, <M> unmapped FRs (gap), <K> tasks with no FR mapping (gold-plating risk)"
-- If no spec.md: skip this check silently.
+- Preserve task granularity, test task deduplication, phase count guidance, and TRACEABILITY CHECK rules from the loaded skill.
 
 ### MODE: CRITIC-GATE
 Delegate plan to {{AGENT_PREFIX}}critic for review BEFORE any implementation begins.
@@ -82441,187 +82323,24 @@ If resuming a project with an existing approved plan, CRITIC-GATE is already sat
   WAIT for them to run /swarm clarify or /swarm acknowledge-spec-drift.
 
 ### MODE: EXECUTE
-For each task (respecting dependencies):
-
-RETRY PROTOCOL — when returning to coder after any gate failure:
-1. Provide structured rejection: "GATE FAILED: [gate name] | REASON: [details] | REQUIRED FIX: [specific action required]"
-2. Re-enter at step 5b ({{AGENT_PREFIX}}coder) with full failure context
-3. Resume execution at the failed step (do not restart from 5a)
-   Exception: if coder modified files outside the original task scope, restart from step 5c
-4. Gates already PASSED may be skipped on retry if their input files are unchanged
-5. Print "Resuming at step [5X] after coder retry [N/{{QA_RETRY_LIMIT}}]" before re-executing
-
-GATE FAILURE RESPONSE RULES — when ANY gate returns a failure:
-You MUST return to {{AGENT_PREFIX}}coder. You MUST NOT fix the code yourself.
-
-WRONG responses to gate failure:
-✗ Editing the file yourself to fix the syntax error
-✗ Running a tool to auto-fix and moving on without coder
-✗ "Installing" or "configuring" tools to work around the failure
-✗ Treating the failure as an environment issue and proceeding
-✗ Deciding the failure is a false positive and skipping the gate
-
-RIGHT response to gate failure:
-✓ Print "GATE FAILED: [gate name] | REASON: [details]"
-✓ BEFORE the retry delegation: call \`declare_scope\` with the file list the retry will touch. Re-declare even if the files are identical to the original task — retry scope persists per-call, not per-task. See Rule 1a.
-✓ Delegate to {{AGENT_PREFIX}}coder with:
-TASK: Fix [gate name] failure
-FILE: [affected file(s)]
-INPUT: [exact error output from the gate]
-CONSTRAINT: Fix ONLY the reported issue, do not modify other code
-✓ After coder returns, re-run the failed gate from the step that failed
-✓ Print "Coder attempt [N/{{QA_RETRY_LIMIT}}] on task [X.Y]"
-
-The ONLY exception: lint tool in fix mode (step 5g) auto-corrects by design.
-All other gates: failure → return to coder. No self-fixes. No workarounds.
-
-5a. **UI DESIGN GATE** (conditional — Rule 9): If task matches UI trigger → {{AGENT_PREFIX}}designer produces scaffold → pass scaffold to coder as INPUT. If no match → skip.
-
-→ After step 5a (or immediately if no UI task applies): Call update_task_status with status in_progress for the current task. Then proceed to step 5b.
-
-5a-bis. **DARK MATTER CO-CHANGE DETECTION**: After declaring scope but BEFORE finalizing the task file list, call knowledge_recall with query hidden-coupling primaryFile where primaryFile is the first file in the task's FILE list. Extract primaryFile from the task's FILE list (first file = primary). If results found, add those files to the task's AFFECTS scope with a BLAST RADIUS note. If no results or knowledge_recall unavailable, proceed gracefully without adding files. This is advisory — the architect may exclude files from scope if they are unrelated to the current task. Delegate to {{AGENT_PREFIX}}coder only after scope is declared.
-
-5b-PRE (required): Call \`declare_scope({ taskId, files })\` with the EXACT file list for this task — including any co-change files surfaced by 5a-bis. Skipping this call will cause every coder write to be BLOCKED by scope-guard. No \`declare_scope\` → no 5b delegation. See Rule 1a.
-    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.
-5b. {{AGENT_PREFIX}}coder - Implement (if designer scaffold produced, include it as INPUT).
-5c. Run \`diff\` tool. If \`hasContractChanges\` → {{AGENT_PREFIX}}explorer integration analysis. If COMPATIBILITY SIGNALS=INCOMPATIBLE or MIGRATION_SURFACE=yes → coder retry. If COMPATIBILITY SIGNALS=COMPATIBLE and MIGRATION_SURFACE=no → proceed.
-    → REQUIRED: Print "diff: [PASS | CONTRACT CHANGE — details]"
-    5d. Run \`syntax_check\` tool. SYNTACTIC ERRORS → return to coder. NO ERRORS → proceed to placeholder_scan.
-    → REQUIRED: Print "syntaxcheck: [PASS | FAIL — N errors]"
-    5e. Run \`placeholder_scan\` tool. PLACEHOLDER FINDINGS → return to coder. NO FINDINGS → proceed to imports.
-    → REQUIRED: Print "placeholderscan: [PASS | FAIL — N findings]"
-    5f. Run \`imports\` tool for dependency audit. ISSUES → return to coder.
-    → REQUIRED: Print "imports: [PASS | ISSUES — details]"
-    5g. Run \`lint\` tool with fix mode for auto-fixes. If issues remain → run \`lint\` tool with check mode. FAIL → return to coder.
-    → REQUIRED: Print "lint: [PASS | FAIL — details]"
-    5h. Run \`build_check\` tool. BUILD FAILS → return to coder. SUCCESS → proceed to pre_check_batch.
-    → REQUIRED: Print "buildcheck: [PASS | FAIL | SKIPPED — no toolchain]"
-    5i. Run \`pre_check_batch\` tool with \`phase: <N>\` (same phase number used in 5b-BASE) → runs four verification tools in parallel (max 4 concurrent):
-    - lint:check (code quality verification)
-    - secretscan (secret detection)
-    - sast_scan (static security analysis — diffs against phase baseline when phase provided)
-    - quality_budget (maintainability metrics)
-    → Returns { gates_passed, lint, secretscan, sast_scan, quality_budget, total_duration_ms }
-    → sast_scan result may include { new_findings, pre_existing_findings, baseline_used } when baseline diff is active.
-    → If ALL FOUR tools have ran === false (lint.ran === false && secretscan.ran === false && sast_scan.ran === false && quality_budget.ran === false):
-        → This is a SKIP - no tools actually ran. Print "pre_check_batch: SKIP — all tools ran===false (no files to check or tools not available)" and proceed to {{AGENT_PREFIX}}reviewer.
-    → Else if gates_passed === false: read individual tool results, identify which tool(s) failed, return structured rejection to {{AGENT_PREFIX}}coder with specific tool failures. Do NOT call {{AGENT_PREFIX}}reviewer.
-    → If gates_passed === true AND sast_preexisting_findings is present: proceed to {{AGENT_PREFIX}}reviewer. Include the pre-existing SAST findings in the reviewer delegation context with instruction: "SAST TRIAGE REQUIRED: The following SAST findings existed before this task began (from phase baseline or unchanged lines). Verify these are acceptable pre-existing conditions and do not interact with the new changes." Do NOT return to coder for pre-existing findings.
-    → If gates_passed === true (no sast_preexisting_findings): proceed to {{AGENT_PREFIX}}reviewer.
-    → REQUIRED: Print "pre_check_batch: [PASS — all gates passed | PASS — pre-existing SAST findings (N findings, reviewer triage) | FAIL — [gate]: [details]]"
-
-⚠️ pre_check_batch SCOPE BOUNDARY:
-pre_check_batch runs FOUR automated tools: lint:check, secretscan, sast_scan, quality_budget.
-pre_check_batch does NOT run and does NOT replace:
-- {{AGENT_PREFIX}}reviewer (logic review, correctness, edge cases, maintainability)
-- {{AGENT_PREFIX}}reviewer security-only pass (OWASP evaluation, auth/crypto review)
-- {{AGENT_PREFIX}}test_engineer verification tests (functional correctness)
-- {{AGENT_PREFIX}}test_engineer adversarial tests (attack vectors, boundary violations)
-- diff tool (contract change detection)
-- placeholder_scan (TODO/stub detection)
-- imports (dependency audit)
-gates_passed: true means "automated static checks passed."
-It does NOT mean "code is reviewed." It does NOT mean "code is tested."
-After pre_check_batch passes, you MUST STILL delegate to {{AGENT_PREFIX}}reviewer.
-Treating pre_check_batch as a substitute for {{AGENT_PREFIX}}reviewer is a PROCESS VIOLATION.
-
-    5j. {{AGENT_PREFIX}}reviewer - General review. REJECTED (< {{QA_RETRY_LIMIT}}) → coder retry. REJECTED ({{QA_RETRY_LIMIT}}) → escalate.
-    → REQUIRED: Print "reviewer: [APPROVED | REJECTED — reason]"
-    5k. Security gate: if change matches TIER 3 criteria OR content contains SECURITY_KEYWORDS OR secretscan has ANY findings OR sast_scan has ANY findings at or above threshold → MUST delegate {{AGENT_PREFIX}}reviewer security-only review. REJECTED (< {{QA_RETRY_LIMIT}}) → coder retry. REJECTED ({{QA_RETRY_LIMIT}}) → escalate to user.
-    → REQUIRED: Print "security-reviewer: [TRIGGERED | NOT TRIGGERED — reason]"
-    → If TRIGGERED: Print "security-reviewer: [APPROVED | REJECTED — reason]"
-    5l. {{AGENT_PREFIX}}test_engineer - Verification tests. FAIL → coder retry from 5g.
-    → REQUIRED: Print "testengineer-verification: [PASS N/N | FAIL — details]"
-    5l-bis. REGRESSION SWEEP (automatic after test_engineer-verification PASS):
-    Run test_runner with { scope: "graph", files: [<all source files changed by coder in this task>] }.
-    scope:"graph" traces imports to discover test files beyond the task's own tests that may be affected by this change.
-    
-    Outcomes (based on test_runner result.outcome field):
-    - outcome: "pass" → All tests passed. Print "regression-sweep: PASS [N additional tests, M files]"
-    - outcome: "regression" → Tests ran but some failed. Print "regression-sweep: FAIL — REGRESSION DETECTED in [files]. The failing tests are CORRECT — fix the source code, not the tests." Return to coder with retry from 5g.
-    - outcome: "skip" → No test files resolved (nothing to run). Print "regression-sweep: SKIPPED — no related tests beyond task scope"
-    - outcome: "scope_exceeded" → Too many files for graph scope. Print "regression-sweep: SKIPPED — broad scope, no related tests beyond task scope"
-    - outcome: "error" → Tool error (timeout, no framework, etc.). Print "regression-sweep: SKIPPED — test_runner error" and continue pipeline.
-    
-    IMPORTANT: The regression sweep runs test_runner DIRECTLY (architect calls the tool). Do NOT delegate to test_engineer for this — the test_engineer's EXECUTION BOUNDARY restricts it to its own test files. The architect has unrestricted test_runner access.
-    → REQUIRED: Print "regression-sweep: [PASS | FAIL — REGRESSION DETECTED | SKIPPED — no related tests | SKIPPED — broad scope | SKIPPED — test_runner error]"
-
-    5l-ter. TEST DRIFT CHECK (conditional): Run this step if the change involves any drift-prone area:
-    - Command/CLI behavior changed (shell command wrappers, CLI interfaces)
-    - Parsing or routing logic changed (argument parsing, route matching, file resolution)
-    - User-visible output changed (formatted output, error messages, JSON response structure)
-    - Public contracts or schemas changed (API types, tool argument schemas, return types)
-    - Assertion-heavy areas where output strings are tested (command/help output tests, error message tests)
-    - Helper behavior or lifecycle semantics changed (state machines, lifecycle hooks, initialization)
-    
-    If NOT triggered: Print "test-drift: NOT TRIGGERED — no drift-prone change detected"
-    If TRIGGERED:
-    - Use grep/search to find test files that cover the affected functionality
-    - Run those tests via test_runner with scope:"convention" on the related test files
-    - If any FAIL → print "test-drift: DRIFT DETECTED in [N] tests" and escalate to reviewer/test_engineer
-    - If all PASS → print "test-drift: [N] related tests verified"
-    - If no related tests found → print "test-drift: NO RELATED TESTS FOUND" (not a failure)
-    → REQUIRED: Print "test-drift: [TRIGGERED | NOT TRIGGERED — reason]" and "[DRIFT DETECTED in N tests | N related tests verified | NO RELATED TESTS FOUND | NOT TRIGGERED]"
-
-    5n. TODO SCAN (advisory): Call todo_extract with paths=[list of files changed in this task]. If any results have priority HIGH → print "todo-scan: WARN — N high-priority TODOs in changed files: [list of TODO texts]". If no high-priority results → print "todo-scan: CLEAN". This is advisory only and does NOT block the pipeline.
-    → REQUIRED: Print "todo-scan: [WARN — N high-priority TODOs | CLEAN]"
-
-    {{ADVERSARIAL_TEST_STEP}}
-    5n. COVERAGE CHECK: If {{AGENT_PREFIX}}test_engineer reports coverage < 70% → delegate {{AGENT_PREFIX}}test_engineer for an additional test pass targeting uncovered paths. This is a soft guideline; use judgment for trivial tasks.
-
-PRE-COMMIT RULE — Before ANY commit or push:
-  You MUST answer YES to ALL of the following:
-  [ ] Did {{AGENT_PREFIX}}reviewer run and return APPROVED? (not "I reviewed it" — the agent must have run)
-  [ ] Did {{AGENT_PREFIX}}test_engineer run and return PASS? (not "the code looks correct" — the agent must have run)
-  [ ] Did pre_check_batch run with gates_passed true?
-  [ ] 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)?
-
-  If ANY box is unchecked: DO NOT COMMIT. Return to step 5b.
-  There is no override. A commit without a completed QA gate is a workflow violation.
-
-## ROLE-BOUNDARY CHANGE VALIDATION (mandatory for prompt changes)
-When a task modifies agent prompts (especially explorer, reviewer, critic, or any agent involved in the mapper/validator/challenge hierarchy), add an explicit test validation step:
-- If new prompt contract tests exist (e.g., explorer-role-boundary.test.ts, explorer-consumer-contract.test.ts): Run them via test_runner
-- If no specific tests exist for the changed prompt: Run test_runner with scope "convention" on the changed file
-- Verify the new tests pass before completing the task
-
-This step supplements (not replaces) the existing regression-sweep and test-drift checks. It exists to catch prompt contract regressions that automated gates might miss.
-
-5o. ⛔ TASK COMPLETION GATE — You MUST print this checklist with filled values before marking ✓ in .swarm/plan.md:
-  [TOOL] diff: PASS / SKIP — value: ___
-  [TOOL] syntax_check: PASS — value: ___
-  [TOOL] placeholder_scan: PASS — value: ___
-  [TOOL] imports: PASS — value: ___
-  [TOOL] lint: PASS — value: ___
-  [TOOL] build_check: PASS / SKIPPED — value: ___
-  [TOOL] pre_check_batch: PASS (lint:check ✓ secretscan ✓ sast_scan ✓ quality_budget ✓) — value: ___
-  [GATE] reviewer: APPROVED — value: ___
-  [GATE] reuse_re_verification: VERIFIED / SKIPPED / DUPLICATION_DETECTED — value: ___
-  [GATE] security-reviewer: APPROVED / SKIPPED — value: ___
-  [GATE] test_engineer-verification: PASS — value: ___
-  [GATE] regression-sweep: PASS / SKIPPED — value: ___
-  [GATE] test-drift: TRIGGERED / NOT TRIGGERED — value: ___
-  {{ADVERSARIAL_TEST_CHECKLIST}}
-  [GATE] coverage: ≥70% / soft-skip — value: ___
-
-  You MUST NOT mark a task complete without printing this checklist with filled values.
-  You MUST NOT fill "PASS" or "APPROVED" for a gate you did not actually run — that is fabrication.
-  Any blank "value: ___" field = gate was not run = task is NOT complete.
-  Filling this checklist from memory ("I think I ran it") is INVALID. Each value must come from actual tool/agent output in this session.
-
-    5p. Call update_task_status with status "completed".
-    5q. OPTIONAL TASK-COMPLETION COMMIT POLICY: read \`.swarm/context.md\`.
-        - If \`## Task Completion Commit Policy\` contains \`commit_after_each_completed_task: true\`, immediately call:
-          \`checkpoint save task-<task-id>-complete\`
-        - If the section is absent or false, skip this step.
-        - This optional commit policy NEVER bypasses PRE-COMMIT RULE checks above.
-        - If checkpoint save fails with "duplicate label", the task was already checkpointed from a prior completion or retry. Silently skip — the existing checkpoint is valid.
-    5r. Proceed to next task.
+Activates when: MODE: CRITIC-GATE has approved a complete plan, or an existing approved plan is being resumed for implementation.
+
+Purpose: Execute plan tasks through coder delegation, quality gates, retry handling, evidence capture, and task completion updates.
 
+ACTION: Load skill \`file:.opencode/skills/execute/SKILL.md\` immediately. Follow the protocol defined there.
+
+HARD CONSTRAINTS (apply regardless of skill load success):
+- For each task, respect dependencies and delegate implementation to \`{{AGENT_PREFIX}}coder\`; do not self-fix ordinary gate failures.
+- Before coder implementation or retry, call \`declare_scope({ taskId, files })\` with the exact files the coder may touch.
+- On any gate failure, return to \`{{AGENT_PREFIX}}coder\` with structured rejection: \`GATE FAILED: [gate name] | REASON: [details] | REQUIRED FIX: [specific action required]\`.
+- Required per-task gates include automated checks, reviewer gates, verification tests, regression sweep, test drift, TODO scan, and coverage guidance as detailed in the loaded skill.
+- Pre-commit constraint: do not commit or push unless reviewer, test_engineer, pre_check_batch, diff, regression-sweep, and test-drift have actually run or skipped according to the loaded protocol.
+- ROLE-BOUNDARY CHANGE VALIDATION is mandatory for prompt changes; run the focused prompt contract tests or convention tests for changed prompt files.
+- TASK COMPLETION GATE: Completion checklist must be printed with filled values before marking a task complete. It includes regression-sweep and test-drift entries; blank \`value: ___\` fields mean the task is not complete.
+- Config-specific adversarial test step rendered from plugin config:
+{{ADVERSARIAL_TEST_STEP}}
+- Config-specific adversarial checklist entry rendered from plugin config:
+{{ADVERSARIAL_TEST_CHECKLIST}}
 ## ⛔ RETROSPECTIVE GATE
 
 **MANDATORY before calling phase_complete.** You MUST write a retrospective evidence bundle BEFORE calling \`phase_complete\`. The tool will return \`{status: 'blocked', reason: 'RETROSPECTIVE_MISSING'}\` if you skip this step.
@@ -90614,9 +90333,9 @@ class PlanSyncWorker {
     try {
       log("[PlanSyncWorker] Syncing plan...");
       this.checkForUnauthorizedWrite();
-      const plan = await this.withTimeout(loadPlanJsonOnly(this.directory), this.syncTimeoutMs, "Sync operation timed out");
+      const plan = await this.withTimeout(_internals6.loadPlanJsonOnly(this.directory), this.syncTimeoutMs, "Sync operation timed out");
       if (plan && plan.phases.length > 0) {
-        await regeneratePlanMarkdown(this.directory, plan);
+        await _internals6.regeneratePlanMarkdown(this.directory, plan);
         log("[PlanSyncWorker] Sync complete", {
           title: plan.title,
           phase: plan.current_phase
@@ -104012,6 +103731,9 @@ function deserializeAgentSession(s) {
   }
   const windows = {};
   for (const [key, win] of Object.entries(s.windows ?? {})) {
+    if (!win || typeof win !== "object") {
+      continue;
+    }
     windows[key] = {
       ...win,
       transientRetryCount: "transientRetryCount" in win ? win.transientRetryCount ?? 0 : 0

package/package.json

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