feat(kernel): PR-C — task management

[rtpa25]

Implements the task-list substrate per docs/superpowers/specs/2026-05-14-task-management-design.md.

First of three slices: Tasks (this PR) → Sub-agents (PR-D) → Streaming (PR-E).

What ships

• New per-thread task Drizzle table (5-state enum, cascade with thread + run, $onUpdate on updatedAt).
• manage_tasks tool — single batchable write (ops:[{action:'create',name,description}|{action:'update',id,...patch}]), returns full thread state, cross-thread guard.
• <tasks> context block — pure SQL renderer, status-aware truncation (in_progress full / pending 120 / terminal 80 chars), omitted on empty threads.
• prepareStep wiring — refreshes <tasks> per react-loop step so the model sees fresh state across iterations without busting b2 cache.
• <task_management> system prompt section — when-to-plan decision rule, lifecycle, description quality, discipline, don'ts (~370 tokens, cached in b1).
• Anthropic provider options: toolStreaming, effort: "xhigh", sendReasoning, thinking: { adaptive, summarized }, explicit cacheControl.ttl: "5m" at all 5 marker sites.

Cache topology preserved

The <tasks> block lives after the b2 cache marker (post <current_date>). Per-step refresh costs ~300 tokens; b2 stays hit across all within-turn steps. b4 misses on steps that mutate tasks — acceptable trade vs the ~5–10K rebuild cost if tasks were inside the b2 prefix. See spec §6 worked example.

Smoke checklist — PENDING (8 scenarios)

Deployed to https://agent-os.pandaronit25.workers.dev and *.ronit.one. Migration 0009 (0009_melodic_multiple_man.sql) applies automatically on first DO write per thread.

Interactive smoke when ready to test (from spec §8):

• 1. Empty thread renders no <tasks> block. Fresh thread, ask "what time is it" — no manage_tasks tool_call row.
• 2. Trivial request doesn't trigger planning. "Read README.md" — no manage_tasks call.
• 3. Multi-step request creates 2–3 tasks. "Research bun vs deno, write a short summary, save it to summary.md" — verify rows in task table.
• 4. Mid-turn state visibility (the prepareStep test). Same run — agent should mark a task in_progress in the very next step after creating tasks.
• 5. Persistence across user turns. Send a second message in the same thread; tasks still visible.
• 6. Cross-thread isolation. New thread renders no <tasks> block.
• 7. Inline completion with result. Multi-step turn; agent marks task complete with 1–3 sentence result.
• 8. manage_tasks returns full state. Inspect tool_call.response — contains {tasks:[...]} with all thread tasks.

Cache verification (scenario 10) deferred per memory — wrangler tail doesn't capture DO logs reliably.

Out of scope (PR-D / PR-E)

• spawn_sub_agent tool, sub-agent runtime, parallel execution
• TUI rendering of <tasks> as a sidebar/panel
• 2× result duplication handling (decided: accept; lands in PR-D)
• Nested tasks (parentTaskId), get_task/list_tasks read tools, task templates — YAGNI

Reviews (subagent-driven, opus)

All 6 implementation tasks went through spec-compliance + code-quality review per superpowers:subagent-driven-development. Two iterations during implementation:

• Task 1 code-quality caught $defaultFn only fires on INSERT — fixed with .$onUpdate(() => new Date()) matching thread.updatedAt precedent (commit b7c8946). Spec updated in lockstep.
• Task 2 code-quality caught status union duplication — extracted TASK_STATUS/isTerminalStatus() (commit 0f39944).

Final whole-PR review caught one cross-task seam: stale <roadmap> entry contradicting the new <task_management> block — fixed in d112dd5.

🤖 Generated with Claude Code