opencode-dispatcher 0.2.10 → 0.2.11

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,10 @@ Use Dispatcher when the structure is worth it. Use the fast path or plain OpenCo
 
 ## Version History
 
+* **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.2.11",
   "description": "A low-context OpenCode dispatcher workflow with orchestrator agents and task artifacts.",
   "type": "module",
   "bin": {

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: