feat(tasks): analyst opens the task; freestyle threads it into implementation

Two coupled gaps from tracing a real run:

1. Freestyle implements in phase 2 via stages compiled from the architect's
   execution_plan (ExecutionPlanCompiler sets allowedTools = stage.tools), so the
   static allow-lists never reach it and architect_freestyle.md banned every tool
   but the file four. Teach the architect to thread an analysis-referenced task
   through the plan: implementing stages get task_context/task_update and claim +
   submit_for_review; the final/review stage completes it. No task referenced → no
   task tools, and the plan never creates one.

2. Give the analyst task_create so the work is framed as a tracked item up front
   (role_pipeline + freestyle). "Read-only" for the analyst means it writes no
   files; a task is an event-log entry, not a file write — task_create is T2, so
   opening one is approval-gated. The analyst names the new id in the analysis so
   the implementer claims it and the reviewer completes it; the implementer now
   creates only as a fallback.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-24 15:13:52 +00:00
parent de54be7ecb
commit 12d5b9d7dc
6 changed files with 37 additions and 17 deletions
@@ -57,9 +57,21 @@ Emit a JSON object that validates against the `execution_plan` schema:
llm-emitted kind.
- Declare `needs`: every upstream artifact id the stage's prompt references. Every id in
`needs` must be `produces`d by a strictly earlier stage.
- Include `tools` only for stages that write or edit files:
`["file_read", "file_write", "file_edit", "ShellTool"]`. Do not invent tool names
beyond this set.
- Include `tools` per stage as it needs them, using only names from this set:
`file_read`, `file_write`, `file_edit`, `ShellTool`, `task_context`, `task_update`,
`task_search`. Stages that write or edit files take the file set
(`["file_read", "file_write", "file_edit", "ShellTool"]`). Do not invent names beyond
this set.
- **Task tracking — only if the `analysis` references a task** (an id like `auth-142` that
the analyst found or opened with `task_create`; if none is referenced there is no task to
track). When one is referenced, thread it through the plan so the work stays tracked:
- Give the stage that does the work `task_context` and `task_update`, and have its
`prompt` `task_update action=claim` the task before starting and
`action=submit_for_review` when its output is ready.
- Give the final or review stage `task_context` and `task_update`, and have its `prompt`
`task_update action=complete` the task once the work is accepted.
- If the `analysis` references no task, omit the task tools entirely. Do not create a
new task here — creation is out of scope for the plan.
- Keep stages small and single-responsibility. Prefer more stages over large monolithic
prompts.