# Leader Dispatch-And-Launch Checklist

Use this checklist when the leader wants durable `orch` scheduling plus a Codex sub-agent worker.

## Goal

Keep `orch` as the control plane and use a leader-side bridge to launch a worker sub-agent only after `dispatch` succeeds.

## Recommended Flow

1. initialize the shared DB once through `skills/inbox/assets/inbox --db PATH --json init`
2. create the run and tasks with `run init`, `task add`, and `dep add`
3. find dispatchable work with `ready`
4. save the dispatch response:

```bash
./assets/orch --db ./coord.db --json dispatch --run RUN_ID --task TASK_ID --execution-mode analysis > TMPDIR/dispatch.json
```

5. render a standardized worker brief:

```bash
./assets/orch-worker-brief --dispatch-json TMPDIR/dispatch.json --db ./coord.db > TMPDIR/worker-brief.txt
```

6. spawn one worker sub-agent with:
   - injected `skills/inbox/`
   - the generated worker brief
   - the repository defaults from `AGENTS.md`
     - model: `gpt-5.4`
     - reasoning effort: `xhigh`
     - `fork_context: true` first
7. while the worker runs, keep the leader on:
   - `orch wait`
   - `orch status`
   - `orch blocked`
   - `orch answer`
   - `orch retry`
   - `orch reassign`

## Worker Launch Rules

- the worker should use `skills/inbox/`, not `skills/orch/`
- the worker should claim only the exact `thread_id` from the dispatch result
- if `worktree_path` exists, the worker should do all repository writes only inside that worktree
- the worker should send progress, blocked questions, success, and failure through `inbox`

## Why This Layer Exists

- `orch` remains portable and durable
- worker launch stays outside the core CLI
- the same dispatch contract can later support Codex sub-agents, `codex exec`, daemons, or operator UI launchers