feat(tasks): wire the task tools into the remaining code-work workflows

Extend the role_pipeline wiring to the other workflows that act on a code work
item, matching each stage's tier:

- freestyle_planning: analyst (read-only) gets task_search/task_context to find
  related work and ground the analysis; prompt updated to match.
- review_loop: implement gets the full set (claim, submit_for_review, notes),
  review gets task_context/task_update to complete on an approved verdict. Its
  prompt files don't ship, so the doctrine rides the L0 policy + tool descriptions.

Left untouched: research (external-research flow producing a report, not a code
work item), qa_ping (smoke test), and healthcheck (diagnostic) — none track work.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

examples/workflows/freestyle_planning.toml

@@ -1,11 +1,13 @@
 id = "freestyle_planning"
 start = "analyst"
 
+# analyst is read-only, so it gets only the read-only task tools: task_search to find related
+# or duplicate work and task_context to ground the analysis in an existing task.
 [[stages]]
 id = "analyst"
 prompt = "prompts/analyst_freestyle.md"
 produces = [{ name = "analysis", kind = "analysis" }]
-allowed_tools = ["file_read", "ShellTool"]
+allowed_tools = ["file_read", "ShellTool", "task_search", "task_context"]
 token_budget = 16384
 max_retries = 2
 

examples/workflows/prompts/analyst_freestyle.md

@@ -2,6 +2,10 @@ You are the **Analyst** in freestyle mode. Understand the user's goal (in the de
 above) and the code it touches. Read-only: `file_read` (also lists a directory's entries when
 given a directory path), `ls`, `grep`, `cat`, `find`.
 
+Before deriving requirements, check for existing work: `task_search` for related, duplicate, or
+blocking tasks and `task_context` to load any the goal names. Fold what you find into the
+analysis rather than re-deriving it; flag a duplicate instead of restating it.
+
 Emit the `analysis` artifact (JSON, schema provided):
 - `summary`: the goal in your own words.
 - `requirements`: concrete, checkable requirements, one per line.

examples/workflows/review_loop.toml

@@ -14,19 +14,24 @@
 id = "review_loop"
 start = "implement"
 
+# implement owns the work item across the loop: claim before starting, submit_for_review once
+# the patch is ready, add notes (task_create one first if the work warrants tracking).
 [[stages]]
 id = "implement"
 prompt = "prompts/implement.md"
 produces = [{ name = "patch", kind = "file_written" }]
-allowed_tools = ["file_write"]
+allowed_tools = ["file_write", "task_create", "task_update", "task_context", "task_search"]
 token_budget = 8192
 max_retries = 3
 
+# review reads the task's own acceptance criteria (task_context) and completes it on an approved
+# verdict (task_update action=complete); on changes_requested it leaves the task claimed.
 [[stages]]
 id = "review"
 prompt = "prompts/review.md"
 needs = ["patch"]
 produces = [{ name = "review_report", kind = "review_report" }]
+allowed_tools = ["task_context", "task_update"]
 token_budget = 8192
 max_retries = 3