Improve orch status reconciliation view

docs/architecture.md

@@ -36,6 +36,7 @@ If `inbox` is reduced to pure chat storage, the scheduler must reconstruct state
 - The leader may use `inbox` directly for inspection or manual repair.
 - Workers should use `inbox` only.
 - Workers should not use `orch`.
+- `orch dispatch` creates handoff state, not execution. Leaders still need a separate worker runtime or worker agent to consume the assigned inbox thread.
 - User-facing discussion stays with the leader.
 - Code-writing workers should run in `orch`-assigned Git worktrees, not in the user's primary checkout.
 
@@ -59,6 +60,7 @@ For code tasks, execution should be isolated from the user's primary checkout.
 - the assigned worktree path should be stored in attempt metadata and inbox task payload
 - the worker runtime should execute inside that worktree
 - strict mode should require a committed base revision
+- non-code tasks may stay on a thread-only dispatch path with no worktree, but they still require a separate worker runtime to claim the inbox thread
 
 See [worktree-execution.md](/home/kurihada/project/ai-workflow-skill/docs/worktree-execution.md) for the full lifecycle.
 
@@ -156,5 +158,5 @@ Do not put these into `orch`:
 The intended skill split mirrors the CLI split.
 
 - `inbox` skill: used when an agent needs to fetch work, claim a thread, send progress, ask blocked questions, reply, or return results through `inbox`
-- `orch` skill: used when the leader needs to create runs, decompose tasks, manage dependencies, dispatch ready work, inspect blocks, answer them, retry failures, or reassign work through `orch`
+- `orch` skill: used when the leader needs to create runs, decompose tasks, manage dependencies, dispatch ready work, inspect blocks, answer them, retry failures, or reassign work through `orch`; it is not itself the worker launcher
 - `council-review` skill: used when the user explicitly wants a structured three-reviewer brainstorm or review with grouped and tallied recommendations