orch: require explicit dispatch execution mode

skills/orch/SKILL.md

@@ -40,9 +40,9 @@ Use the bundled `./assets/orch` CLI to control leader-side orchestration through
 
 - Prefer `orch` over hand-written `inbox send` for normal leader operations.
 - Treat `dispatch` as handoff, not execution. After dispatch, arrange a separate worker runtime or worker agent to claim the mapped inbox thread.
-- For analysis, review, or other read-only tasks, omit worktree flags so dispatch stays thread-only and light.
+- For analysis, review, or other read-only tasks, dispatch with `--execution-mode analysis`.
 - If nothing is actionable, use `wait` instead of manual sleep loops.
-- For code tasks, dispatch from a committed base and allocate a fresh worktree per attempt.
+- For code tasks, dispatch with `--execution-mode code` from a committed base and allocate a fresh worktree per attempt.
 - Use `blocked` and `answer` to resolve worker questions through the active attempt thread.
 - Use `retry` or `reassign` only after checking the latest task and attempt state.
 - Use `inbox` directly only for inspection or manual repair, not routine scheduling.
@@ -64,7 +64,7 @@ Use this when the leader wants durable `orch` state plus a worker sub-agent laun
 1. save the dispatch output:
 
 ```bash
-./assets/orch --db ./coord.db --json dispatch --run RUN_ID --task TASK_ID > TMPDIR/dispatch.json
+./assets/orch --db ./coord.db --json dispatch --run RUN_ID --task TASK_ID --execution-mode analysis > TMPDIR/dispatch.json
 ```
 
 2. render a standardized worker brief:
@@ -92,7 +92,7 @@ See:
 - The worker side should use `skills/inbox/`, not this skill.
 - The leader should pass or preserve the `dispatch` result, especially `attempt.thread_id`, `attempt.assigned_to`, and worktree metadata when present.
 - Code-writing workers should execute inside the assigned worktree path from the task payload or attempt metadata.
-- Read-only or analysis workers can stay on the normal thread-only path with no worktree.
+- Read-only or analysis workers should be dispatched with `--execution-mode analysis` and stay on the normal thread-only path with no worktree.
 
 ## Typical Commands
 
@@ -103,9 +103,9 @@ See:
 ./assets/orch --db ./coord.db --json task add --run blog_mvp_001 --task T2 --title "Summarize flaky tests" --summary "Read logs and report next steps" --default-to qa-worker --acceptance-json '{"kind":"analysis"}'
 ./assets/orch --db ./coord.db --json dep add --run blog_mvp_001 --task T2 --depends-on T1
 ./assets/orch --db ./coord.db --json ready --run blog_mvp_001
-./assets/orch --db ./coord.db --json dispatch --run blog_mvp_001 --task T1 --to foundation-worker --base-ref main --workspace-root .orch/worktrees --strict-worktree --body-file tasks/t1.md > /tmp/t1-dispatch.json
+./assets/orch --db ./coord.db --json dispatch --run blog_mvp_001 --task T1 --execution-mode code --to foundation-worker --base-ref main --workspace-root .orch/worktrees --body-file tasks/t1.md > /tmp/t1-dispatch.json
 ./assets/orch-worker-brief --dispatch-json /tmp/t1-dispatch.json --db ./coord.db > /tmp/t1-worker-brief.txt
-./assets/orch --db ./coord.db --json dispatch --run blog_mvp_001 --task T2 --to qa-worker --body "Read the failing test logs and summarize the root cause." > /tmp/t2-dispatch.json
+./assets/orch --db ./coord.db --json dispatch --run blog_mvp_001 --task T2 --execution-mode analysis --to qa-worker --body "Read the failing test logs and summarize the root cause." > /tmp/t2-dispatch.json
 ./assets/orch-worker-brief --dispatch-json /tmp/t2-dispatch.json --db ./coord.db > /tmp/t2-worker-brief.txt
 ./assets/orch --db ./coord.db --json status --run blog_mvp_001
 ./assets/orch --db ./coord.db --json wait --run blog_mvp_001 --for task_blocked,task_done,task_failed --after-event 0 --timeout-seconds 900
@@ -135,8 +135,8 @@ See:
 
 ## Notes
 
-- `dispatch` supports `--repo-path`, `--workspace-root`, `--strict-worktree`, and `--base-ref` for worktree-backed code execution.
-- When worktree flags are omitted, code-like task metadata can still auto-enable strict worktree mode. Non-code tasks stay on the normal thread-only path.
+- `dispatch` requires `--execution-mode analysis|code`.
+- `dispatch` supports `--repo-path`, `--workspace-root`, and `--base-ref` for `--execution-mode code`.
 - `./assets/orch-worker-brief` is the supported way to turn a saved dispatch JSON response into a stable worker prompt for a spawned sub-agent.
 - `answer` supports `--payload-json` for structured decisions, not just freeform text.
 - `status` is the full run view; `run show` is the lighter aggregate view.