opencode-dispatcher 0.2.11 → 0.3.1

package/README.md

@@ -526,6 +526,11 @@ Use Dispatcher when the structure is worth it. Use the fast path or plain OpenCo
 
 ## Version History
 
+* **v0.3.1**
+  * **Shipper Inspection & Release-Boundary Fixes**: Tightened shipper bash permission whitelist to eliminate pre-commit inspection prompts and fixed release-boundary routing so the shipper only commits and pushes explicitly intended changes.
+* **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.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-dispatcher",
-  "version": "0.2.11",
+  "version": "0.3.1",
   "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/shipper.md

@@ -24,6 +24,14 @@ permission:
     "ls *": allow
     "npm run check": allow
     "npm run check *": allow
+    "grep *": allow
+    "head *": allow
+    "tail *": allow
+    "cat *": allow
+    "wc *": allow
+    "file *": allow
+    "git show*": allow
+    "node -p *": allow
     "git reset*": deny
     "git rebase*": deny
     "git clean*": deny
@@ -55,6 +63,7 @@ Hard boundaries:
 - 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.
+- Version bump preparation, README.md edits, and changelog updates are out of scope for the shipper agent and must be prepared by other agents (implementer, executor, documentation) before shipper is invoked.
 - If branch/upstream ambiguity exists, report back to orchestrator instead of guessing.
 
 Required pre-commit inspection:
@@ -66,6 +75,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 individually; 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

@@ -29,11 +29,7 @@ Single-unit workflow:
 - Make real architectural decisions based on conventions: which patterns to use, where new files go, what to change in existing files.
 - Add decision notes under `.ai/decisions/` only when orchestrator explicitly requests task-related decision documentation.
 - Do not edit implementation files, project docs outside `.ai/`, or source code.
-- Write an `## Execution` section in every task spec. The format is a level-2 heading followed by a bullet list of agent names in execution order. Valid agent names: `test-writer`, `implementer`, `documentation`. Never include `validator` — the orchestrator appends it automatically. Decision logic for choosing the pipeline:
-  - Feature/fix with testable acceptance criteria → `test-writer`, then `implementer`.
-  - Feature/fix with only inspectable acceptance criteria (no tests to write) → `implementer` only.
-  - Documentation task → `documentation` only.
-  - Follow-up documentation (implementation was handled by its own spec's Execution section) → `documentation` only.
+- Write an `## Execution` section in every task spec. The format is a level-2 heading followed by a bullet list of agent names in execution order. Valid agent names: `test-writer`, `implementer`, `documentation`. The `## Execution` section must contain only the agent bullet list — no explanatory orchestration notes.
 
 Multi-unit decomposition:
 
@@ -64,8 +60,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: