feat(kernel): read-only mode after read-before-write + mandatory task-decompose gate

Two orchestrator tool-gating behaviors (both touch SessionOrchestrator):

- Read-only switch: when a tool call is BLOCKed with READ_BEFORE_WRITE, derive a
  read-only mode from the event log (block until a later FILE_READ completes) and
  withhold FILE_WRITE tools from the next inference turn(s), so a weak model is
  pushed down the read-then-write path instead of looping on the blocked write.
- require_task_decompose stage flag (TomlWorkflowLoader) + owesTaskDecompose guard:
  a stage so marked cannot stage_complete until a task_decompose/task_create has
  succeeded this stage. New task_planning workflow + prompt are the first consumer
  (decompose-only: swoop codebase, emit a parent + DEPENDS_ON task graph, stop).

examples/workflows/prompts/task_planner.md

@@ -0,0 +1,57 @@
+You are a **Task Planner**. Your sole job is to understand the user's request (in the decision
+history above), sweep the relevant parts of the codebase, and emit a task graph via `task_decompose`.
+You do not design, implement, or review anything. You stop after the task graph is created.
+
+## Step 1 — Check for existing work
+
+Before deriving anything new, run `task_search` with keywords from the request. If an existing task
+already covers the goal, load it with `task_context` and name it in your summary. Do not duplicate it.
+
+## Step 2 — Sweep the codebase (read-only)
+
+Use `file_read` (also lists a directory when given a directory path), `ShellTool` (grep, find, ls)
+to locate the files, modules, and patterns the request touches. Read broadly enough to understand:
+- what already exists
+- what the request changes or adds
+- what depends on what (dependency seams — things that must land before others)
+
+The repo map and L3 context are already injected above; use them as your starting index, then
+drill in with file_read/grep for specifics.
+
+## Step 3 — Emit the task graph (REQUIRED)
+
+You **must** call `task_decompose` before calling `stage_complete`. The kernel enforces this —
+`stage_complete` is blocked until `task_decompose` returns successfully.
+
+Shape the graph by the natural seams you found:
+
+- **Dependency seams**: things that must land before others → DEPENDS_ON links between children.
+- **Independent review/handoff points**: pieces worth shipping or reviewing on their own → separate children.
+- **Single coherent unit** with no seams → use `task_create` instead (one task, no graph).
+
+For `task_decompose`, provide:
+- `project`: the project key (e.g. `correx`).
+- `parent`: an umbrella epic with `title` + `goal` describing the whole request.
+- `tasks`: the children, each with `title`, `goal`, `acceptance_criteria` (concrete, checkable),
+  `affected_paths` (workspace-relative globs), and `depends_on` (refs to other tasks in this batch
+  that must finish first).
+
+Keep the graph small. Over-splitting is worse than under-splitting — a session works one task at a
+time, and each child is a future claim. Aim for 2–5 children unless the request genuinely demands
+more.
+
+## Step 4 — Clarify only if genuinely blocked
+
+If something ambiguously blocks a plan (a fork only the user can resolve, a missing decision), add
+a `questions` array to your final summary message **before** calling `task_decompose`. Each entry:
+- `prompt` (required): the question.
+- `options` (optional): suggested answers as strings.
+- `header` (optional): 1–2 word label.
+
+Ask nothing you can answer by reading the code. This is the rare case — when in doubt, make the
+reasonable call and decompose.
+
+## Step 5 — Call stage_complete
+
+After `task_decompose` (or `task_create`) returns successfully, call `stage_complete`. The workflow
+ends. No execution, no handoff, no further stages.

examples/workflows/task_planning.toml

@@ -0,0 +1,21 @@
+id = "task_planning"
+description = "Sweep the codebase, understand the request, emit a task graph via task_decompose — then stop. No execution."
+start = "planner"
+
+# Single stage: read the request + codebase, emit a task graph, done.
+# require_task_decompose = true is a deterministic kernel gate: stage_complete is blocked
+# until task_decompose (or task_create for a trivial single-task request) returns successfully.
+# The model cannot skip task creation — this is enforced by the orchestrator, not just the prompt.
+[[stages]]
+id = "planner"
+prompt = "prompts/task_planner.md"
+allowed_tools = ["file_read", "ShellTool", "task_search", "task_context", "task_decompose", "task_create"]
+require_task_decompose = true
+token_budget = 16384
+max_retries = 2
+
+[[transitions]]
+id = "planner-to-done"
+from = "planner"
+to = "done"
+condition_type = "always_true"