opencode-dispatcher 0.2.10 → 0.3.0

package/README.md

@@ -29,7 +29,7 @@ flowchart TD
     User[User] --> Orchestrator[Orchestrator]
 
     Orchestrator -->|Question or review| Direct[Direct answer]
-    Orchestrator -->|Tiny exact edit| Executor[Executor]
+    Orchestrator -->|Exact mechanical edit| Executor[Executor]
     Orchestrator -->|Substantial task| Planner[Task Planner]
     Orchestrator -->|External facts needed| Research[Research]
     Orchestrator -->|Commit or push requested| Shipper[Shipper]
@@ -113,9 +113,9 @@ The orchestrator is the main entry point. It talks with you, clarifies the reque
 
 | Agent    | Role                                   | Used When                               |
 | -------- | -------------------------------------- | --------------------------------------- |
-| Executor | Performs tiny single-file atomic edits | For exact, unambiguous one-file changes |
+| Executor | Performs exact, mechanical, low-risk edits | For edits where a task spec would not improve safety |
 
-The executor is used when a full task spec would be unnecessary.
+The executor is used when the edit is exact, mechanical, and low-risk — a task spec would not improve safety.
 
 Example:
 
@@ -216,7 +216,7 @@ flowchart LR
     User --> Orchestrator --> Executor --> Orchestrator --> Summary[Summary]
 ```
 
-Used for exact, single-file changes.
+Used for exact, mechanical, low-risk edits that do not need task planning or acceptance criteria.
 
 ### Substantial Feature or Fix
 
@@ -407,7 +407,7 @@ Current payloads include agents for:
 * validation
 * research
 * shipping
-* tiny atomic edits
+* exact mechanical edits
 
 The installer does **not** install or manage:
 
@@ -526,6 +526,13 @@ Use Dispatcher when the structure is worth it. Use the fast path or plain OpenCo
 
 ## Version History
 
+* **v0.3.0**
+  * **Model-Config Groups**: Replaced per-agent model selection with two-tier group-based workflow (MED/LOW), excluding orchestrator and task-planner.
+
+* **v0.2.11**
+  * **Routing Clarity**: Clarified executor routing as exact, mechanical, low-risk edits rather than file-count-based; clarified planner auto-proceed behavior when no user-facing decisions are introduced.
+  * **Shipper Boundary**: Tightened shipper routing so it only commits and pushes existing intended changes.
+  * **CI Update**: Updated publish workflow to Node 24-compatible GitHub Actions (`actions/checkout@v6`, `actions/setup-node@v6`, `node-version: 24`).
 * **v0.2.10**
   * **Agent Context**: Shipper agent now reads `.ai/context.md` for project-specific conventions (commit format, version bump patterns, auto-publish). Added `read` permission to shipper. Updated `.ai/context.md` with publication and auto-publish conventions. Added CI workflow (`.github/workflows/publish.yml`) to auto-publish on version bump commits.
 * **v0.2.8**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-dispatcher",
-  "version": "0.2.10",
+  "version": "0.3.0",
   "description": "A low-context OpenCode dispatcher workflow with orchestrator agents and task artifacts.",
   "type": "module",
   "bin": {

package/workflow/agents/model-config.md

@@ -21,10 +21,17 @@ Responsibilities:
 
 - Run `opencode models --verbose` to list available models and their variants on the system.
 - Check for an existing opencode config at `opencode.jsonc` or `.opencode/opencode.jsonc` (in that order of preference).
-- Present the user with the list of installed Dispatcher subagents (excluding the orchestrator, whose model is chosen directly by the user) and ask which agents they want to configure.
-- For each selected agent, ask which model to assign (from the available models list).
-- For each assigned model, parse its `variants` field from the verbose output. If the model has variants (non-empty object), present the available variant names and ask the user to pick one or skip. If the model has no variants (empty `{}`), skip silently without prompting. If the user skips, do not write a `variant` field for that agent.
-- Write `agent.<name>.model` and optionally `agent.<name>.variant` entries into the project's opencode config, preserving all existing config content exactly as-is. Use the target format:
+- Determine the set of configurable subagents by excluding **orchestrator** (whose model is chosen directly by the user in OpenCode itself) and **task-planner** (which is intended to use the same model as the orchestrator) from the full list of installed Dispatcher subagents.
+- Group the remaining configurable subagents into two hardcoded tiers:
+
+  | Group | Agents                                                     | Intended model class |
+  |-------|------------------------------------------------------------|-----------------------|
+  | MED   | `validator`, `test-writer`, `documentation`, `init`        | DeepSeek Pro class    |
+  | LOW   | `implementer`, `research`, `executor`, `shipper`, `model-config` | Flash / cheap class   |
+
+- Present both groups to the user with their intended model tiers. Ask the user to pick a model (and optionally a variant) for each group **once** — not per-agent.
+- For the chosen model, parse its `variants` field from the verbose output. If the model has variants (non-empty object), present the available variant names and ask the user to pick one or skip. If the model has no variants (empty `{}`), skip silently without prompting. If the user skips, do not write a `variant` field for that group.
+- Write `agent.<name>.model` and optionally `agent.<name>.variant` entries for every agent in each group into the project's opencode config, preserving all existing config content exactly as-is. Use the target format:
   ```jsonc
   "agent": {
     "orchestrator": {
@@ -33,7 +40,7 @@ Responsibilities:
     }
   }
   ```
-- If no opencode config exists, create one with only the `agent.<name>.model` (and `agent.<name>.variant` where applicable) entries.
+- If no opencode config exists, create one with only the agent entries.
 - Report back to the orchestrator with a summary of what was configured.
 
 Boundaries:

package/workflow/agents/orchestrator.md

@@ -110,10 +110,10 @@ Ask one focused question only when the missing answer would change scope, safety
 Choose the smallest safe path:
 
 - Answer directly when no file changes are needed.
-- Use executor when the edit is exact, low-risk, and unambiguous (file count is irrelevant).
+- Use executor when the requested edit is exact, mechanical, low-risk, and does not need task planning or acceptance criteria.
 - Use research when current facts, external docs, pricing, vendor behaviour, or source-backed confidence matter.
 - Use task-planner when the work is behaviour-changing, risky, unclear, needs acceptance criteria, or benefits from a written plan before implementation.
-- Use shipper only when the user explicitly asks to commit or push.
+- Use shipper only for explicit git commit or push work after the intended file changes already exist.
 - Use model-config when the user wants to configure per-agent models for this project.
 ### Common Requests
 
@@ -123,7 +123,7 @@ Choose the smallest safe path:
 
 Delegate to the specialist that owns the next action.
 
-- executor: tiny single-file edit
+- executor: exact mechanical edit
 - research: source-backed fact finding
 - task-planner: task specs and decomposition
 - test-writer: tests from approved specs
@@ -142,6 +142,7 @@ Execution pipeline for task specs:
 - After the pipeline completes, always spawn `validator` as the final agent.
 - If the `## Execution` section is missing or empty, do not spawn any agents; report the gap to the user.
 - Never assume a default agent sequence — always read the pipeline from the spec.
+- Auto-proceed rule: after task-planner returns a spec, continue automatically into the spec's Execution pipeline when the spec matches the clarified request and introduces no new user-facing decisions. Ask the user only for ambiguity, material scope expansion, risky tradeoffs, conflicting requirements, or required user choices. Multi-unit decomposition still requires explicit user approval before child specs are created.
 
 ### REVIEW
 

package/workflow/agents/shipper.md

@@ -22,6 +22,8 @@ permission:
     "git config*": allow
     "ls": allow
     "ls *": allow
+    "npm run check": allow
+    "npm run check *": allow
     "git reset*": deny
     "git rebase*": deny
     "git clean*": deny
@@ -52,6 +54,7 @@ Hard boundaries:
 - Only commit when orchestrator/user explicitly requests a commit.
 - Only push when orchestrator/user explicitly requests a push.
 - Do not amend, force-push, reset, rebase, clean, tag, or create PRs unless explicitly requested.
+- Do not prepare changes; only commit or push existing intended changes.
 - If branch/upstream ambiguity exists, report back to orchestrator instead of guessing.
 
 Required pre-commit inspection:
@@ -63,6 +66,7 @@ Required pre-commit inspection:
 - If multiple task artifact folders exist, include only the folders that match the current commit scope unless the user explicitly asks to commit everything.
 - Do not use `git commit -a` or `git commit -am`; explicitly stage intended files before committing.
 - Never include secrets, credentials, generated artifacts, or unrelated changes.
+- Run inspection commands separately; do not combine allowed commands with shell operators like &&, ||, or ;.
 - If the intended file set is unclear, stop and report the ambiguity to orchestrator.
 
 Commit message rules:

package/workflow/agents/task-planner.md

@@ -64,8 +64,6 @@ Multi-unit decomposition:
     task-spec.md
 ```
 
-- Write `.ai/tasks/current` pointer file containing the relative path to the first unit (e.g., `tasks/<NNN>-<task-id>/01-unitslug`). The format is a single line with a relative path — no JSON or multi-line structure.
-
 If scope is ambiguous, stop and report the missing decision to orchestrator instead of inventing requirements.
 
 Default report back: