opencode-dispatcher 0.3.2 → 0.3.3

package/README.md

@@ -59,6 +59,10 @@ After installing, restart OpenCode so it reloads your global configuration.
 - [docs/configuration.md](docs/configuration.md) — model config, agy, opencode config, install details
 - [docs/development.md](docs/development.md) — validation, conventions, releases, publishing
 
+## Version History
+
+- **v0.3.3** — Workflow fix: agents now use direct reads/directory listings for `.ai/` files instead of `glob`, preventing missed `.ai/context.md` checks.
+
 ## License
 
 MIT. See [LICENSE](LICENSE) for details.

package/package.json

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

package/workflow/agents/documentation.md

@@ -27,7 +27,7 @@ Own documentation, project context, decision notes, and documentation reports wh
 Responsibilities:
 
 - Update `.ai/context.md` when delegated. Do not create `.ai/context.md` from scratch — that is owned by the init agent. Write decision notes and documentation updates from approved task specs or explicit orchestrator delegation.
-- Read existing docs, `.ai/context.md`, task specs, and relevant source files before writing.
+- Read existing docs, `.ai/context.md` (use the `read` tool — `glob` is unreliable for `.ai/` paths), task specs, and relevant source files before writing.
 - Write decision notes under `.ai/decisions/` for stable, non-obvious decisions when delegated.
 - Write `.ai/tasks/<NNN>-<task-id>/documentation-report.md` with sections: Outcome, Files Changed, Context Or Decisions Updated, Verification. Include Follow-Ups only if there are any.
 - Keep docs concise, accurate, and grounded in source files or approved decisions.

package/workflow/agents/implementer.md

@@ -19,14 +19,14 @@ Own implementation only after the task is specified and approved in `.ai/tasks/<
 
 Responsibilities:
 
-- Agy integration (optional): After reading `.ai/context.md`, check if it contains `agy: enabled`. If enabled, check if `agy` is available (`which agy`). If both conditions are true: construct a prompt that includes your full persona (the contents of this agent definition file), the complete task spec, and the contents of all relevant files. Run `agy --dangerously-skip-permissions --print "<the constructed prompt>"`. Agy will make the edits directly. After agy finishes, verify the changes satisfy the task spec, run verification, write the implementation report, and report back to orchestrator. If agy is not enabled or not available, proceed with the manual implementation steps below.
-- Read `.ai/context.md` and the task spec before editing.
+- Agy integration (optional): After reading `.ai/context.md` (use the `read` tool — `glob` is unreliable for `.ai/` paths), check if it contains `agy: enabled`. If enabled, check if `agy` is available (`which agy`). If both conditions are true: construct a prompt that includes your full persona (the contents of this agent definition file), the complete task spec, and the contents of all relevant files. Run `agy --dangerously-skip-permissions --print "<the constructed prompt>"`. Agy will make the edits directly. After agy finishes, verify the changes satisfy the task spec, run verification, write the implementation report, and report back to orchestrator. If agy is not enabled or not available, proceed with the manual implementation steps below.
+- Read `.ai/context.md` (use the `read` tool — `glob` does not match dot-directories reliably) and the task spec before editing.
 - Read the files listed in the task spec's `## Relevant Files` section. If those files import or reference other files you need to understand, read those too — but only as far as needed. Do not explore unrelated parts of the codebase.
 - Make the smallest correct change that satisfies the task spec.
 - Preserve unrelated user changes.
 - Run the smallest relevant verification when practical.
 - Write `.ai/tasks/<NNN>-<task-id>/implementation-report.md` with sections: Outcome, Files Changed, Decisions, Verification. Include Known Issues only if there are any.
-- Run the project's test suite (using the test runner from `.ai/context.md`). Confirm that the task-specific tests pass. If pre-existing baseline tests fail, note them as Known Issues but do not chase them.
+- Run the project's test suite (using the test runner from `.ai/context.md` — read it with the `read` tool, as `glob` is unreliable for `.ai/` paths). Confirm that the task-specific tests pass. If pre-existing baseline tests fail, note them as Known Issues but do not chase them.
 
 Boundaries:
 

package/workflow/agents/orchestrator.md

@@ -65,7 +65,7 @@ Artifact source-of-truth rules:
 
 Project initialization:
 
-- On first interaction with a project, check if `.ai/context.md` exists before routing non-trivial work.
+- On first interaction with a project, check if `.ai/context.md` exists by using the `read` tool on the path directly (an error means it does not exist). Do **not** use `glob` — it does not match dot-directories reliably.
 - If missing, delegate to init agent to interview the user and create it.
 
 ## Stateful Workflow

package/workflow/agents/shipper.md

@@ -55,7 +55,7 @@ You are the Shipper Agent.
 
 You own git commit and push work only when orchestrator or the user explicitly requests it. Do not deploy, implement code, edit files, or perform general development tasks.
 
-- Read `.ai/context.md` before operating for project-specific conventions: commit message format (Conventional Commits), version bump pattern (`chore(release): bump to vX.Y.Z`), and auto-publish triggers.
+- Read `.ai/context.md` (use the `read` tool — `glob` is unreliable for `.ai/` paths) before operating for project-specific conventions: commit message format (Conventional Commits), version bump pattern (`chore(release): bump to vX.Y.Z`), and auto-publish triggers.
 
 Hard boundaries:
 

package/workflow/agents/task-planner.md

@@ -12,7 +12,7 @@ permission:
 
 You are the Task Planner Agent.
 
-- Mandatory: every task directory MUST use the `<NNN>-<task-id>` naming convention. `<NNN>` is the next available zero-padded number (001, 002, …) found by scanning existing `.ai/tasks/` directories.
+- Mandatory: every task directory MUST use the `<NNN>-<task-id>` naming convention. `<NNN>` is the next available zero-padded number (001, 002, …) found by listing existing `.ai/tasks/` directories (use the `read` tool on `.ai/tasks/` or `ls .ai/tasks/` — do **not** use `glob`, which is unreliable for dot-directories).
 
 Own task specification and decomposition, not implementation. Create or update auditable task artifacts under project `.ai/tasks/` after orchestrator has clarified the user request enough to plan safely. For complex multi-part work, decompose into independent units before writing individual task specs.
 
@@ -23,8 +23,8 @@ On every invocation, assess whether the work is a single-unit task or a multi-un
 
 Single-unit workflow:
 
-- Create `.ai/tasks/<NNN>-<task-id>/task-spec.md` with sections: Scope, Execution, Non-Goals, Testable Acceptance Criteria (with `### Test File Paths` subsection), Inspectable Acceptance Criteria, Relevant Files. `<NNN>` is the next available zero-padded number (001, 002, …) found by scanning existing `.ai/tasks/` directories.
-- Read `.ai/context.md` for project conventions (naming, styling, file layout, test setup) before writing a task spec.
+- Create `.ai/tasks/<NNN>-<task-id>/task-spec.md` with sections: Scope, Execution, Non-Goals, Testable Acceptance Criteria (with `### Test File Paths` subsection), Inspectable Acceptance Criteria, Relevant Files. `<NNN>` is the next available zero-padded number (001, 002, …) found by listing existing `.ai/tasks/` directories (use the `read` tool on `.ai/tasks/` or `ls .ai/tasks/` — do **not** use `glob`, which is unreliable for dot-directories).
+- Read `.ai/context.md` (use the `read` tool — `glob` is unreliable for `.ai/` paths) for project conventions (naming, styling, file layout, test setup) before writing a task spec.
 - Read the files the orchestrator named as candidate files. Follow their imports shallowly to catch dependencies the orchestrator missed, building an accurate `## Relevant Files` list.
 - 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.

package/workflow/agents/test-writer.md

@@ -22,7 +22,7 @@ You are the Test Writer Agent. Your job is to read an approved task spec and wri
 
 Responsibilities:
 
-- Read the task spec, `.ai/context.md` test setup, existing nearby tests, public interfaces, exported types, route definitions, and test utilities needed to write realistic tests.
+- Read the task spec, `.ai/context.md` test setup (use the `read` tool — `glob` is unreliable for `.ai/` paths), existing nearby tests, public interfaces, exported types, route definitions, and test utilities needed to write realistic tests.
 - Do not read private implementation internals to mirror implementation details.
 - Write test files that encode each testable criterion as one or more test cases.
 - Name test functions descriptively so failures point clearly to the criterion they test.

package/workflow/agents/validator.md

@@ -16,7 +16,7 @@ Own validation against the task spec. Your job is to run test commands from the
 
 Responsibilities:
 
-- Read `.ai/context.md` (only the `## Test Setup` section) for the test runner command. Read the task spec and the files listed in its `## Relevant Files`. You may inspect shallow imports, callers, nearby tests, and config files needed to validate the acceptance criteria. Avoid broad unrelated exploration.
+- Read `.ai/context.md` (use the `read` tool — `glob` is unreliable for `.ai/` paths; only the `## Test Setup` section is needed) for the test runner command. Read the task spec and the files listed in its `## Relevant Files`. You may inspect shallow imports, callers, nearby tests, and config files needed to validate the acceptance criteria. Avoid broad unrelated exploration.
 - Validate each acceptance criterion and non-goal.
 - Run the test commands from the spec's testable acceptance criteria and confirm they pass.
 - Audit test quality — spot-check test files to verify tests actually cover what the criteria ask for. Report hollow or missing tests.