opencode-swarm 7.139.4 → 7.139.6

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

@@ -63,112 +63,19 @@ If `council.general.enabled` is true in the resolved opencode-swarm config AND a
 - Write the final spec to `.swarm/spec.md`.
 - Exit when reviewer signs off (or user explicitly accepts remaining disagreements).
 
-**Phase 6: QA GATE SELECTION, PARALLEL CODERS, AND COMMIT FREQUENCY (architect, dialogue only).**
-Auto-loop exception: when BRAINSTORM is running inside MODE: LOOP with
-`autonomy=auto`, do not ask this preference question. Write the balanced-speed
-default `## Pending QA Gate Selection` instead (reviewer, test_engineer,
-sme_enabled, critic_pre_plan, sast_enabled, drift_check ON; council_mode,
-hallucination_guard, mutation_test, phase_council, final_council OFF). Do not
-write `## Pending Parallelization Config` here because task scopes are not known
-until PLAN; MODE: PLAN will choose safe parallelism automatically. Keep commit
-frequency at phase-level only.
-Now ask the user which QA gates to enable for this plan, how many parallel coders to use, the commit frequency, and auto_proceed -- do not select on their behalf. Present all four items together as one unified exchange.
-
-<!-- BEGIN QA_GATE_BODY -->
-
-Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder count, commit frequency, and auto_proceed as a single user-facing section. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
-- reviewer (default: ON) - code review of coder output
-- test_engineer (default: ON) - test verification of coder output
-- sme_enabled (default: ON) - SME consultation during planning/clarification
-- critic_pre_plan (default: ON) - critic review before plan finalization
-- sast_enabled (default: ON) - static security scanning
-- council_mode (default: OFF) - replaces per-task Stage B (reviewer + test_engineer) with the full 5-member council (critic, reviewer, sme, test_engineer, explorer). Requires council.enabled: true in config.
-- hallucination_guard (default: OFF) - when enabled, mandatory per-phase API/signature/claim/citation verification at PHASE-WRAP; phase_complete will REJECT phase completion unless .swarm/evidence/{phase}/hallucination-guard.json exists with an APPROVED verdict.
-- mutation_test (default: OFF) - when enabled, runs mutation testing on source files touched this phase via generate_mutants + mutation_test + write_mutation_evidence at PHASE-WRAP; FAIL verdict blocks phase_complete; WARN is non-blocking.
-- phase_council (default: OFF) - full 5-member council reviews all work in a phase holistically at phase_complete time. Requires council.enabled: true in config.
-- drift_check (default: ON) - mandatory per-phase drift verification via critic_drift_verifier at PHASE-WRAP; hard-blocks phase_complete when spec.md exists and drift evidence is missing or REJECTED; advisory-only when no spec.md exists.
-- 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-6) - 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 declared 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.
-  > COMMON MISCONCEPTION: worktree isolation is baseline for standard parallel coders, governed by the parallel execution profile plus top-level `worktree.policy`. It is not provided by Lean Turbo or Epic. Do not recommend Lean Turbo or Epic to obtain worktree isolation; recommend them only for what they add beyond baseline (Lean Turbo: lane planning, file locks, phase reviewer, integrated diff; Epic: co-change awareness and auto-decide). Worktrees also do not make overlapping scopes safe: dependency readiness, file-disjoint scopes, and merge-back ownership are still required.
-- 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.
-
-<!-- END QA_GATE_BODY -->
-
-The user answers all four items (gates, parallel coders, commit frequency, auto_proceed) in one exchange. Wait for the user's response.
-
-If the user says parallel coders > 1, write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
-```
-## Pending Parallelization Config
-- parallelization_enabled: true
-- max_concurrent_tasks: <user's number>
-- council_parallel: false
-- locked: true
-- recorded_at: <ISO timestamp>
-```
-If the user accepts the default (1), skip writing this section entirely -- serial execution is the default and needs no config.
-
-If the user chooses per-task commits, write this section to `.swarm/context.md`:
-```
-## Task Completion Commit Policy
-- commit_after_each_completed_task: true
-- recorded_at: <ISO timestamp>
-```
-If the user keeps the default phase-level behavior, do not write this section.
-
-<!-- BEHAVIORAL_GUIDANCE_START -->
-GATE SELECTION IS MANDATORY — these thoughts are WRONG and must be ignored:
-  ✗ "I'll use the defaults — they're probably fine"
-    → WRONG: defaults are not the user's decision. The user must be asked every time.
-  ✗ "The user didn't mention gates, so defaults are fine"
-    → WRONG: silence is not consent. The gate dialogue is not optional.
-  ✗ "I'll handle it in MODE: PLAN after the spec is done"
-    → WRONG: ## Pending QA Gate Selection must exist in context.md BEFORE save_plan is called.
-      save_plan will reject with QA_GATE_SELECTION_REQUIRED if this section is absent.
-  ✗ "This feature is simple — gates are obvious"
-    → WRONG: complexity does not exempt this step. Gate selection is mandatory for ALL plans.
-  ✗ "I already know which gates are right for this project"
-    → WRONG: the architect does not configure gates. The user configures gates. Always ask.
-
-MANDATORY PAUSE: Do NOT write the spec summary (Phase 7 transition). Do NOT suggest next steps.
-Exception: MODE: LOOP with `autonomy=auto` uses the balanced-speed defaults
-above and does not pause for this preference exchange.
-You are BLOCKED until ALL THREE of these conditions are met:
-  (1) The unified gate/coders/commit/auto_proceed selection section has been presented to the user in a single message
-  (2) The user has responded (accept defaults OR customized list for all four items)
-  (3) The elected gates, parallel coder config, commit policy, and auto_proceed selection have been written to .swarm/context.md under "## Pending QA Gate Selection" (and related sections as applicable)
-<!-- BEHAVIORAL_GUIDANCE_END -->
-
-Do NOT call `set_qa_gates` yet — `plan.json` does not exist at this point. Once the user answers, write the elected gates to `.swarm/context.md` under a new section:
-```
-## Pending QA Gate Selection
-- reviewer: <true|false>
-- test_engineer: <true|false>
-- sme_enabled: <true|false>
-- critic_pre_plan: <true|false>
-- sast_enabled: <true|false>
-- council_mode: <true|false>
-- hallucination_guard: <true|false>
-- mutation_test: <true|false>
-- phase_council: <true|false>
-- drift_check: <true|false>
-- final_council: <true|false>
-- auto_proceed: <true|false>
-- recorded_at: <ISO timestamp>
-```
-MODE: PLAN applies these after `save_plan` succeeds via `set_qa_gates`.
-- Exit with the elected gates recorded in `.swarm/context.md` (NOT yet persisted to plan.json).
+**Phase 6: DEFER QA AND EXECUTION PROFILE SELECTION.**
+- BRAINSTORM does not collect, infer, or stage QA gates, parallel coder count, commit frequency, or `auto_proceed`.
+- MODE: PLAN owns the unified four-choice dialogue after it has drafted task scopes and frozen the exact plan identity (`swarm_id` plus title). MODE: LOOP with `autonomy=auto` also applies its balanced-speed defaults there without pausing.
+- Do not write execution choices to `.swarm/context.md`.
 
 **Phase 7: TRANSITION.**
-- Summarize: (a) chosen approach, (b) design sections produced, (c) spec written, (d) QA gates selected, (e) remaining `[NEEDS CLARIFICATION]` markers.
-- Offer the user two next steps: `PLAN` (go to MODE: PLAN and write plan.md) or `CLARIFY-SPEC` (resolve remaining markers first).
+- Summarize: (a) chosen approach, (b) design sections produced, (c) spec written, and (d) remaining `[NEEDS CLARIFICATION]` markers.
+- Offer the user two next steps: `PLAN` (go to MODE: PLAN and persist the plan via the authoritative ledger-backed `save_plan` tool; never write `.swarm/plan.md` directly) or `CLARIFY-SPEC` (resolve remaining markers first).
 - Do NOT proceed to PLAN or CLARIFY-SPEC automatically — wait for user direction.
 
 BRAINSTORM RULES:
 - No skipping phases. Each phase's exit condition must be met before moving on.
-- One question per message in DIALOGUE — never batch. Exception: the QA gate selection section (Phase 6) presents gates, parallel coders, and commit frequency together as one unified exchange.
+- One question per message in DIALOGUE — never batch. MODE: PLAN owns the later unified QA and execution-profile exchange.
 - Always offer an informed default for every question.
 - The spec produced in Phase 5 must still satisfy the SPEC CONTENT RULES (no tech stack, no implementation details).
-- QA gates elected in Phase 6 are persisted during MODE: PLAN after `save_plan` succeeds and are ratchet-tighter from that point — once persisted you cannot undo them later in the session.
+- QA gates are first selected and persisted during MODE: PLAN against the exact plan identity; they are ratchet-tighter from that point.

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

@@ -137,13 +137,13 @@ Treating pre_check_batch as a substitute for the active swarm's reviewer agent i
     5l-bis. REGRESSION SWEEP (automatic after test_engineer-verification PASS):
     Iterate the changed source files preemptively and run one `test_runner` call per changed source file with { scope: "graph", files: [<one changed source file>] }.
     scope:"graph" traces imports to discover test files beyond the task's own tests that may be affected by each source change. Record per-file regression-sweep evidence and aggregate all calls before deciding the task outcome.
-    
+
     Outcomes (based on test_runner result.outcome field):
     - any outcome: "regression" → Print "regression-sweep: FAIL — REGRESSION DETECTED in [source → failing tests]. The failing tests are CORRECT — fix the source code, not the tests." Return to coder with retry from 5g.
     - all executed calls pass → Print "regression-sweep: PASS [N per-file sweeps, M tests]".
     - outcome: "skip" → Record "[source]: SKIPPED — [actual tool reason]". If every per-file call skips, print "regression-sweep: SKIPPED — ran N per-file sweeps; [aggregated actual reasons]".
     - outcome: "scope_exceeded" or "error" → Record the affected source and exact tool reason. Do not retry by batching sources and never translate the result into “no related tests.” Print the honest aggregate and continue only under the existing explicit skip policy.
-    
+
     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 — N per-file sweeps | FAIL — REGRESSION DETECTED | SKIPPED — N per-file sweeps with exact reasons]"
 
@@ -154,7 +154,7 @@ Treating pre_check_batch as a substitute for the active swarm's reviewer agent i
     - 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
@@ -213,12 +213,13 @@ This step supplements (not replaces) the existing regression-sweep and test-drif
   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.
+    5q. OPTIONAL TASK-COMPLETION CHECKPOINT: after `update_task_status(status="completed")` succeeds and every PRE-COMMIT RULE gate above has passed, read `plan.execution_profile.commit_after_each_completed_task` from the current durable plan.
+        - If the persisted value is `true`, immediately call:
+          `checkpoint({ action: "save_task_completion", task_id: "<task-id>" })`
+        - If the field is absent or false, skip this step. Never infer the policy from chat or context.
+        - This optional checkpoint NEVER bypasses PRE-COMMIT RULE checks above.
+        - A successful result with `idempotent: true` is idempotent success: the task was already checkpointed by a prior completion or retry, so continue without another commit.
+        - Any other checkpoint failure is advisory: report the exact error and continue to the next task. Do not revert the completed status and do not retry in a loop.
     5r. Proceed to next task.
 
 ## Dispatch-lanes empty-output fallback

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

@@ -57,7 +57,7 @@ Flags parsed from signal:
 4. If the issue is a bug: spec must describe the correct behavior, not the broken behavior.
 5. If the issue is a feature: spec must describe the user-facing outcome, not the implementation.
 6. Carry forward any `[NEEDS REPRO]` / `[NEEDS CLARIFICATION]` flags from Phase 1 into the spec as open questions; do not silently drop them.
-7. QA GATE SELECTION: Ask user which QA gates to enable (same dialogue as MODE: SPECIFY). Write to `.swarm/context.md` under `## Pending QA Gate Selection`.
+7. QA AND EXECUTION PROFILE SELECTION: Defer all four choices (QA gates, parallel coder count, commit frequency, and `auto_proceed`) to MODE: PLAN. PLAN first drafts task scopes and freezes the exact plan identity, then persists the choices before the first plan save. Do not stage execution choices in `.swarm/context.md`.
 
 #### Phase 4: TRANSITION
 Based on flags:

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

@@ -62,8 +62,8 @@ Before drafting or saving the plan, the architect MUST offer General Council adv
   1. Run the General Council Research Phase: formulate 1-3 targeted `web_search` queries grounded in the work being planned.
   2. 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 with the RESEARCH CONTEXT.
   3. Collect responses and call `convene_general_council` with mode `general`.
-  4. Record the council consensus, disagreements, cited sources, and any plan-impacting assumptions in `.swarm/context.md` under `## Decisions`.
-  5. Use that recorded council input as planning context before calling `save_plan`.
+  4. Carry the council consensus, disagreements, cited sources, and any plan-impacting assumptions into the relevant plan task descriptions or acceptance criteria supplied to `save_plan`.
+  5. Use that council input as planning context before calling `save_plan`.
 - If General Council is unavailable and the user explicitly requested council input, surface the config/key requirement and stop before `save_plan` rather than writing an ungrounded plan.
 
 General Council is advisory and distinct from `council_mode`, `phase_council`, and `final_council`. It is not a QA gate. Its purpose here is to make current external context available before the architect writes any plan and before any critic pre-plan review.
@@ -161,7 +161,7 @@ The critic may improve wording or confirm prior context, but these categories MU
 
 #### Assumptions Recording
 
-All items resolved in Stages 2-3 (self_resolved, critic_resolved, deferred_nonblocking) MUST be recorded as explicit assumptions in `.swarm/context.md` under `## Decisions` before calling `save_plan`. Silently dropping resolved uncertainties is a protocol violation — every uncertainty that entered the funnel must have a recorded outcome.
+All items resolved in Stages 2-3 (self_resolved, critic_resolved, deferred_nonblocking) MUST be recorded as explicit assumptions in the relevant plan task descriptions or acceptance criteria passed to `save_plan`. Silently dropping resolved uncertainties is a protocol violation — every uncertainty that entered the funnel must have a recorded outcome.
 
 The plan generated by `save_plan` MUST include explicit assumptions and remaining unresolved decisions in the task descriptions or acceptance criteria — not silently omit them.
 
@@ -171,64 +171,20 @@ The plan generated by `save_plan` MUST include explicit assumptions and remainin
 
 This mechanical enforcement prevents the following failure mode: the architect prompt instructs the override, but due to parsing errors, context limits, or model behavior variance, the DROP verdict is mistakenly applied to an always-surface item and silently accepted. The validation should occur in the decision-packet assembly code (when building the final clarification packet to surface to the user) and should emit a warning log when an override is applied. This is tracked as future work in a follow-up issue; until then, enforcement relies on the skill instructions.
 
-Use the `save_plan` tool to create the implementation plan. Required parameters:
+Draft the complete implementation plan in memory first. 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" }] }] })
+**QA AND EXECUTION PROFILE BOOTSTRAP (before first `save_plan`).**
 
-**EXECUTION PROFILE (Optional — set during planning, lock before first task)**
+1. Finish drafting the title, swarm identifier, phases, tasks, dependencies, and `files_touched` scopes. Freeze the exact raw plan identity as `swarm_id` plus `plan_title` (the same title passed to `save_plan`). Do not normalize, shorten, or rename either value between profile creation and plan save. An intentional identity replacement must use `confirm_identity_change: true`; never silently create a second profile because wording changed.
+2. Inspect dependency-ready tasks and their file scopes before recommending parallelism. File-disjoint task groups may run concurrently in isolated worktrees; overlapping or unknown scopes require serial execution.
+3. Present the following unified four-choice dialogue in one message and wait for one complete answer. Silence is not consent.
 
-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 10): Maximum simultaneous tasks when parallel is enabled.
-- `council_parallel` (boolean, default true): 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.**
-Auto-loop exception: when this PLAN step is running inside MODE: LOOP with
-`autonomy=auto`, do not ask the gate/parallelism/commit-frequency question. Use
-the balanced-speed defaults from the loop skill, call `set_qa_gates` with those
-values after `save_plan`, keep phase-level commits, and set a locked
-`execution_profile` automatically when the plan has dependency-ready,
-file-disjoint tasks. Choose the largest safe count, clamped to the configured
-limit (currently 6); use serial execution when scopes overlap or are unknown.
-After `save_plan` succeeds, read `.swarm/context.md`:
-- If a `## Pending QA Gate Selection` section exists: parse the gate values (including `auto_proceed` if present), call `set_qa_gates` with those flags, confirm with the user ("QA gates applied: <list>"), then remove the section from context.md. `auto_proceed` is parsed from the dialogue and persisted in `execution_profile` on re-save.
-- 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, ask the user inline now. Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder count, commit frequency, and auto_proceed as a single user-facing section. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
-  <!-- BEGIN QA_GATE_BODY -->
+<!-- BEGIN QA_GATE_BODY -->
 
 Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder count, commit frequency, and auto_proceed as a single user-facing section. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
 - reviewer (default: ON) - code review of coder output
@@ -244,52 +200,39 @@ 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-6) - 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 declared 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.
+- Parallel coders (default: 1, range: 1-6) - 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 declared file scopes do NOT overlap. Inspect the drafted plan and recommend the number of dependency-ready, file-disjoint task groups, clamped to 1-6; recommend 1 when scopes overlap or are unknown.
   > COMMON MISCONCEPTION: worktree isolation is baseline for standard parallel coders, governed by the parallel execution profile plus top-level `worktree.policy`. It is not provided by Lean Turbo or Epic. Do not recommend Lean Turbo or Epic to obtain worktree isolation; recommend them only for what they add beyond baseline (Lean Turbo: lane planning, file locks, phase reviewer, integrated diff; Epic: co-change awareness and auto-decide). Worktrees also do not make overlapping scopes safe: dependency readiness, file-disjoint scopes, and merge-back ownership are still required.
 - 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.
 
 <!-- END QA_GATE_BODY -->
-  The user answers all four (gates, parallel coders, commit frequency, auto_proceed) in one exchange. Wait for the user's response.
-  If the user says parallel coders > 1, write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
-  ```
-  ## Pending Parallelization Config
-  - parallelization_enabled: true
-  - max_concurrent_tasks: <user's number>
-  - council_parallel: false
-  - locked: true
-  - recorded_at: <ISO timestamp>
-  ```
-  If the user accepts the default (1), skip writing this section entirely; serial execution is the default and needs no config.
-  If the user chooses per-task commits, write this section to `.swarm/context.md`:
-  ```
-  ## Task Completion Commit Policy
-  - commit_after_each_completed_task: true
-  - recorded_at: <ISO timestamp>
-  ```
-  If the user keeps the default phase-level behavior, do not write this section.
-- 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 pending gate/parallelization 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.
-<!-- 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.
-
-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 the active swarm's coder agent:
-⚠️ 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.
-ACCEPTANCE: DONE = .swarm/plan.md contains the verbatim plan content provided in INPUT, byte-for-byte, with no modification, summarization, or interpretation. (This fallback has no fr_refs — per ACCEPTANCE FIELD RESOLUTION in your system prompt, use this one-line task-derived DONE restatement. A missing or empty ACCEPTANCE line is BLOCKED by ACCEPTANCE_FIELD_REQUIRED before the coder runs.)
+
+4. MODE: LOOP exception: when `autonomy=auto`, do not pause. Use the loop skill's balanced-speed defaults: reviewer, test_engineer, sme_enabled, critic_pre_plan, sast_enabled, and drift_check ON; council_mode, hallucination_guard, mutation_test, phase_council, and final_council OFF. Choose the largest safe parallel count from the drafted scopes (1 when overlap or uncertainty exists), keep phase-level commits (`commit_after_each_completed_task: false`), and set `auto_proceed: true`.
+5. Before the first `save_plan`, persist all eleven gate booleans with `set_qa_gates({ swarm_id: <exact swarm_id>, plan_title: <exact title>, ...gates })`. If it fails, stop and resolve the profile error; do not save a plan without the matching profile.
+   Recovery for upgraded legacy plans: if `get_qa_gate_profile`, `save_plan`, or an execution gate reports that the QA profile is not exact-bound, run `set_qa_gates({ swarm_id: <exact swarm_id>, plan_title: <exact title>, adopt_legacy_binding_only: true })`. This exact-binds the existing profile without changing gates or its lock, then you retry the blocked read/save/enforcement step.
+6. Immediately call `save_plan` with the same exact identity, the full drafted phases, and the complete locked profile:
+
+```
+save_plan({
+  title: <exact plan_title>,
+  swarm_id: <exact swarm_id>,
+  phases: [...],
+  execution_profile: {
+    parallelization_enabled: <parallel coders > 1>,
+    max_concurrent_tasks: <selected count>,
+    council_parallel: false,
+    locked: true,
+    auto_proceed: <selected boolean>,
+    commit_after_each_completed_task: <selected boolean>
+  }
+})
+```
+
+7. Read the persisted profile with `get_qa_gate_profile({ swarm_id: <exact swarm_id>, plan_title: <exact plan_title> })`. Use its persisted `critic_pre_plan` value for the critic decision; do not rely on a default, conversation memory, or transient context. Any retry must reuse the frozen identity and the full execution profile.
+
+The locked execution profile is plan-scoped and authoritative. Do not change it after tasks start. A global concurrency setting cannot override it.
+
+If the authoritative ledger-backed `save_plan` tool is unavailable, STOP and report the blocker. Never ask a coder to hand-write `.swarm/plan.md` or any other derived plan projection.
 
 TASK GRANULARITY RULES:
 - SMALL task: 1 file, 1 logical concern. Delegate as-is.
@@ -324,7 +267,7 @@ PHASE COUNT GUIDANCE:
 - 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.
+Do not create or hand-edit `.swarm/context.md` as part of PLAN. Durable plan and execution policy must flow through the authoritative tools above.
 
 TRACEABILITY CHECK (run after plan is written, when an effective spec exists):
 
@@ -349,9 +292,9 @@ REPORT FORMAT:
 
 ### Transition to CRITIC-GATE
 
-After the QA gate selection has been persisted via `set_qa_gates` and the TRACEABILITY CHECK is complete:
+After the QA gate selection and execution profile are persisted and the TRACEABILITY CHECK is complete:
 
-1. If `critic_pre_plan` is enabled (default: ON): the plan MUST be reviewed by the critic before any implementation begins.
+1. If the persisted QA profile returned by `get_qa_gate_profile` has `critic_pre_plan: true`, the plan MUST be reviewed by the critic before any implementation begins. If false, skip only this critic gate.
 2. Transition to **MODE: CRITIC-GATE** by delegating the full plan to the active swarm's critic agent:
    - The critic receives: the plan, the spec (if one exists), and codebase context
    - The critic returns: APPROVED / NEEDS_REVISION / REJECTED

package/.opencode/skills/specify/SKILL.md

@@ -50,98 +50,12 @@ Activates when: user asks to "specify", "define requirements", "write a spec", o
     - `[NEEDS CLARIFICATION]` markers for items where uncertainty could change scope, security, or core behavior, BUT ONLY after running the clarification funnel: (1) inventory all material uncertainties without numeric cap, (2) classify each as self_resolved/critic_resolved/research_needed/user_decision/deferred_nonblocking — **Overconfidence guard:** if the default is not directly supported by user request, spec, or recorded context, classify as `user_decision` rather than `self_resolved`, (3) consult critic_sounding_board with candidate items — critic responds per SoundingBoardVerdict: UNNECESSARY→DROP, RESOLVE→RESOLVE, REPHRASE→REPHRASE, APPROVED→ASK_USER — **always-surface protection:** always-surface categories must not receive UNNECESSARY/DROP; override to APPROVED/ASK_USER, (4) record all resolved items as explicit assumptions in the spec, (5) use markers only for items that survive the funnel (ASK_USER or unresolved after critic consultation). Decision packet format: grouped by category, recommended defaults, blocking vs optional markers, impact of accepting default. Prefer informed defaults over asking
      - **Important:** If research is ongoing, apply a fixed 5-minute protocol budget to `research_needed`. If research does not complete before the budget expires, automatically reclassify the item to `user_decision` with a note that research was incomplete, then surface it to the user. This prevents the clarification funnel from stalling while waiting for external research.
  5. Write the spec to `.swarm/spec.md`.
-5b. **QA GATE SELECTION, PARALLEL CODERS, COMMIT FREQUENCY, AND AUTO_PROCEED (dialogue only).**
-Ask the user which QA gates to enable for this plan, how many parallel coders to use, the commit frequency, and auto_proceed -- do not select on their behalf. Present all four items together as one unified exchange. Exception: when SPECIFY is running inside MODE: LOOP with `autonomy=auto`, write the balanced-speed default `## Pending QA Gate Selection` instead (reviewer, test_engineer, sme_enabled, critic_pre_plan, sast_enabled, drift_check ON; council_mode, hallucination_guard, mutation_test, phase_council, final_council OFF), keep phase-level commits, and let MODE: PLAN choose safe parallelism after task scopes exist.
-
-<!-- BEGIN QA_GATE_BODY -->
-
-Present the eleven gates with their defaults (DEFAULT_QA_GATES), parallel coder count, commit frequency, and auto_proceed as a single user-facing section. Offer the user a one-shot choice: accept defaults, or customize. The eleven gates are:
-- reviewer (default: ON) - code review of coder output
-- test_engineer (default: ON) - test verification of coder output
-- sme_enabled (default: ON) - SME consultation during planning/clarification
-- critic_pre_plan (default: ON) - critic review before plan finalization
-- sast_enabled (default: ON) - static security scanning
-- council_mode (default: OFF) - replaces per-task Stage B (reviewer + test_engineer) with the full 5-member council (critic, reviewer, sme, test_engineer, explorer). Requires council.enabled: true in config.
-- hallucination_guard (default: OFF) - when enabled, mandatory per-phase API/signature/claim/citation verification at PHASE-WRAP; phase_complete will REJECT phase completion unless .swarm/evidence/{phase}/hallucination-guard.json exists with an APPROVED verdict.
-- mutation_test (default: OFF) - when enabled, runs mutation testing on source files touched this phase via generate_mutants + mutation_test + write_mutation_evidence at PHASE-WRAP; FAIL verdict blocks phase_complete; WARN is non-blocking.
-- phase_council (default: OFF) - full 5-member council reviews all work in a phase holistically at phase_complete time. Requires council.enabled: true in config.
-- drift_check (default: ON) - mandatory per-phase drift verification via critic_drift_verifier at PHASE-WRAP; hard-blocks phase_complete when spec.md exists and drift evidence is missing or REJECTED; advisory-only when no spec.md exists.
-- 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-6) - 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 declared 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.
-  > COMMON MISCONCEPTION: worktree isolation is baseline for standard parallel coders, governed by the parallel execution profile plus top-level `worktree.policy`. It is not provided by Lean Turbo or Epic. Do not recommend Lean Turbo or Epic to obtain worktree isolation; recommend them only for what they add beyond baseline (Lean Turbo: lane planning, file locks, phase reviewer, integrated diff; Epic: co-change awareness and auto-decide). Worktrees also do not make overlapping scopes safe: dependency readiness, file-disjoint scopes, and merge-back ownership are still required.
-- 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.
-
-<!-- END QA_GATE_BODY -->
-
-The user answers all four (gates, parallel coders, commit frequency, auto_proceed) in one exchange. Wait for the user's response.
-
-If the user says parallel coders > 1, write a `## Pending Parallelization Config` section to `.swarm/context.md` alongside the gate selection:
-```
-## Pending Parallelization Config
-- parallelization_enabled: true
-- max_concurrent_tasks: <user's number>
-- council_parallel: false
-- locked: true
-- recorded_at: <ISO timestamp>
-```
-If the user accepts the default (1), skip writing this section entirely -- serial execution is the default and needs no config.
-
-If the user chooses per-task commits, write this section to `.swarm/context.md`:
-```
-## Task Completion Commit Policy
-- commit_after_each_completed_task: true
-- recorded_at: <ISO timestamp>
-```
-If the user keeps the default phase-level behavior, do not write this section.
-
-<!-- BEHAVIORAL_GUIDANCE_START -->
-GATE SELECTION IS MANDATORY — these thoughts are WRONG and must be ignored:
-  ✗ "I'll use the defaults — they're probably fine"
-    → WRONG: defaults are not the user's decision. The user must be asked every time.
-  ✗ "The user didn't mention gates, so defaults are fine"
-    → WRONG: silence is not consent. The gate dialogue is not optional.
-  ✗ "I'll handle it in MODE: PLAN after the spec is done"
-    → WRONG: ## Pending QA Gate Selection must exist in context.md BEFORE save_plan is called.
-      save_plan will reject with QA_GATE_SELECTION_REQUIRED if this section is absent.
-  ✗ "This feature is simple — gates are obvious"
-    → WRONG: complexity does not exempt this step. Gate selection is mandatory for ALL plans.
-  ✗ "I already know which gates are right for this project"
-    → WRONG: the architect does not configure gates. The user configures gates. Always ask.
-
-MANDATORY PAUSE: Do NOT write the spec summary (step 7). Do NOT suggest next steps.
-Exception: MODE: LOOP with `autonomy=auto` uses the balanced-speed defaults
-above and does not pause for this preference exchange.
-You are BLOCKED until ALL THREE of these conditions are met:
-  (1) The unified gate/coders/commit/auto_proceed selection section has been presented to the user in a single message
-  (2) The user has responded (accept defaults OR customized list for all four items)
-  (3) The elected gates, parallel coder config, commit policy, and auto_proceed selection have been written to .swarm/context.md under "## Pending QA Gate Selection" (and related sections as applicable)
-<!-- BEHAVIORAL_GUIDANCE_END -->
-
-Do NOT call `set_qa_gates` yet — `plan.json` does not exist at this point. Once the user answers, write the elected gates to `.swarm/context.md` under a new section:
-```
-## Pending QA Gate Selection
-- reviewer: <true|false>
-- test_engineer: <true|false>
-- sme_enabled: <true|false>
-- critic_pre_plan: <true|false>
-- sast_enabled: <true|false>
-- council_mode: <true|false>
-- hallucination_guard: <true|false>
-- mutation_test: <true|false>
-- phase_council: <true|false>
-- drift_check: <true|false>
-- final_council: <true|false>
-- auto_proceed: <true|false>
-- recorded_at: <ISO timestamp>
-```
-MODE: PLAN will read this section after `save_plan` succeeds and persist via `set_qa_gates`.
+5b. **DEFER QA AND EXECUTION PROFILE SELECTION.**
+SPECIFY does not collect, infer, or stage QA gates, parallel coder count, commit frequency, or `auto_proceed`. Those choices depend on the drafted task graph and its exact plan identity. MODE: PLAN freezes the exact `swarm_id` and plan title, presents the unified four-choice dialogue, persists the gate profile, and saves the execution profile. Do not write execution choices to `.swarm/context.md`.
 
 General Council advisory input is offered as an early workflow option in MODE: BRAINSTORM (Phase 1b) and MODE: PLAN before `save_plan`, not as a SPECIFY step. If the user wants council input during SPECIFY, they can use `/swarm council <question>` manually.
 
-7. Report a summary to the user (MUST count, SHALL count, scenario count, clarification markers, elected QA gates) and suggest the next step: `CLARIFY-SPEC` (if markers exist) or `PLAN`.
+7. Report a summary to the user (MUST count, SHALL count, scenario count, clarification markers) and suggest the next step: `CLARIFY-SPEC` (if markers exist) or `PLAN`.
 
 SPEC CONTENT RULES — the spec MUST NOT contain:
 - Technology stack, framework choices, library names

package/dist/agents/architect.d.ts

@@ -68,9 +68,8 @@ export declare function buildCouncilWorkflow(council?: CouncilWorkflowConfig): s
  *   - tests/unit/agents/architect-hallucination-gate.test.ts:3
  *   - tests/unit/skills/plan-protocol.test.ts:8
  *
- * Future work (task 3.2) will create `references/qa-gate-gates-body.md` and
- * migrate those tests to assert against the canonical body. Once migrated,
- * this helper may be deleted.
+ * `references/qa-gate-gates-body.md` is the canonical runtime skill body. This
+ * helper remains as a compatibility oracle for direct prompt-contract tests.
  */
 export declare function buildQaGateSelectionDialogue(modeLabel: 'BRAINSTORM' | 'SPECIFY' | 'PLAN'): string;
 export declare function createArchitectAgent(model: string, customPrompt?: string, customAppendPrompt?: string, adversarialTesting?: AdversarialTestingConfig, council?: CouncilWorkflowConfig, uiReview?: UIReviewConfig, memoryEnabled?: boolean, architecturalSupervision?: ArchitectureSupervisionWorkflowConfig, designDocsEnabled?: boolean, externalSkillsEnabled?: boolean, turboEnabled?: boolean, skillsEnabled?: boolean): AgentDefinition;

package/dist/cli/{config-doctor-whxr386t.js → config-doctor-7v9at76j.js}

@@ -12,11 +12,11 @@ import {
   shouldRunOnStartup,
   writeBackupArtifact,
   writeDoctorArtifact
-} from "./index-e1k9vpqn.js";
+} from "./index-7qx874pn.js";
 import"./index-ee3x66a5.js";
 import"./index-zgwm4ryv.js";
-import"./index-5s23pfsy.js";
-import"./index-4wjk296r.js";
+import"./index-n3ppm2gt.js";
+import"./index-r4t92q32.js";
 import"./index-zjygnfay.js";
 import"./index-bk5tah7q.js";
 import"./index-bpmtbmy9.js";

package/dist/cli/{core-aj5g7an6.js → core-jtj9j6z5.js}

@@ -14,12 +14,12 @@ import {
   resolveWorktreeBaseDir,
   shortenWorktreePath,
   writeLaneProfileToDiskReal
-} from "./index-6z0a940s.js";
+} from "./index-hbnsmnb0.js";
 import"./index-ee3x66a5.js";
 import"./index-4nt52yr9.js";
 import"./index-4rhhvd1a.js";
 import"./index-zgwm4ryv.js";
-import"./index-4wjk296r.js";
+import"./index-r4t92q32.js";
 import"./index-zjygnfay.js";
 import"./index-a76rekgs.js";
 export {

package/dist/cli/{curation-policy-anym2y3v.js → curation-policy-rbrx3kd2.js}

@@ -4,18 +4,18 @@ import {
   authorizeCuration,
   buildConfigFingerprintInput,
   readCohortConfigFingerprint
-} from "./index-5azdnaty.js";
+} from "./index-1tw24kcp.js";
 import"./index-rtry5xyf.js";
-import"./index-k41dn8me.js";
+import"./index-68gh7p3t.js";
 import"./index-ae75rja9.js";
-import"./index-33skgk1a.js";
-import"./index-6r522srn.js";
+import"./index-rs1f1bh0.js";
+import"./index-h2waehqq.js";
 import"./index-ed5ykebp.js";
-import"./index-s0qc4gj6.js";
+import"./index-hfvxhk4z.js";
 import"./index-7g4c7s5r.js";
 import"./index-4nt52yr9.js";
 import"./index-zgwm4ryv.js";
-import"./index-rsrx77fg.js";
+import"./index-ry0hgg3m.js";
 import"./index-bpmtbmy9.js";
 import"./index-a76rekgs.js";
 export {