feat(tasks): wire the task tools into role_pipeline

Tool availability is a strict per-stage allowlist, so the task doctrine was
inert in role_pipeline — no stage granted the tools. Add them where they fit
each stage's tier and role, and point the stage prompts at the lifecycle:

- analyst (read-only): task_search/task_context to find related or duplicate
  work and ground the analysis.
- implementer: full set — claim before working, submit_for_review once
  verification passes, create one if the work warrants tracking.
- reviewer: task_context to judge against the task's own criteria, task_update
  to complete it on an approved verdict.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-24 10:04:01 +00:00
parent 06c225e3bd
commit afb536f21f
4 changed files with 30 additions and 7 deletions
+5
View File
@@ -29,5 +29,10 @@ Emit your result as the `review_report` artifact (JSON, schema provided):
line), each tied to the requirement or plan step it violates, so the implementer knows
exactly what to fix. If `approved`, briefly state which requirements the patch satisfies.
If the work is tracked as a task, reflect your verdict on it (use `task_context` first if you
need its own acceptance criteria): on `approved`, `task_update action=complete`; on
`changes_requested`, leave it claimed for the implementer — optionally add a `note` summarising
what's needed.
Use `changes_requested` only for real problems — the loop is capped and will escalate to a
human if it runs too long. Be decisive.