Keep your agents’ Work valid.

dispatch start                # watch in the background; your shell returns
dispatch watch                # the live view; leaving it keeps watching
dispatch stop                 # stop watching this project

# Or watch in the foreground until you stop it:
dispatch serve

• dispatch watch shows the project’s Work live. On a terminal it is a table (WORK, AGENT, STATE, VERDICT, CHECKS, TOUCHES), with Work named by its worktree folder or task and Work that needs you listed first; the selected Work’s details say why its verdict is what it is and what to do next. Below 90 columns each Work is a two-line card. Keys act on the selected Work, not a row number: f finishes, a accepts through the same gate as dispatch accept, r rejects after asking, d or Enter reviews. Piped or with --json, it prints one line per Work and only reports.
• Leaving watch does not stop watching. dispatch stop ends watching for this project.
• dispatch serve does the same watching in the foreground, until you stop it. check and status answer on demand either way.
• Watching covers Work Dispatch launched, Work you attached, and sessions whose runtime reports them. It does not scan for agent processes. After a reboot, run dispatch start again.
• Where Work interacts. While it watches, Dispatch compares the Work not yet integrated and says where two pieces already touch: the same declaration or file, overlapping lines, a signature one changes and the other uses, or a file one changes and the other relies on. On a terminal the TOUCHES column names the other Work; piped, a line ends with interacts with <id>. The selected Work’s details, and dispatch status under Concurrent, say how. Exact to the declaration for Rust and Python, to the file elsewhere. It is advisory: Work can be CONTINUE and still interact, and nothing is blocked, reordered or refreshed.
• When Work lands, Dispatch records how its interactions turned out. The documented queries in coherence validation read precision and misses from your own state directory; nothing leaves your machine.
• Running several agents on one repository, the way Dispatch builds its own releases, is set out step by step in the self-hosting guide.

# From your checkout: Dispatch makes an isolated workspace
dispatch attach -- claude -p "add input validation"

# Or observe an agent already working in a separate worktree
dispatch attach --workspace ../feature-wt --agent codex
dispatch finish <run-id>      # you say when it is done

• dispatch attach --workspace <path> observes an agent already working in a separate workspace; dispatch finish freezes the result when you say it is done. Attaching the integration checkout itself this way is refused.
• How much Dispatch can vouch for S0. Full confidence when S0 is the workspace as the Work began (a workspace Dispatch made, or a session start the runtime reported) or a real Git merge base. Partial confidence when Dispatch had to snapshot a directory at attach time, or a session resumed in a worktree it had not seen, since earlier edits are then invisible to the patch.
• A workspace Dispatch made is removed once its Work is applied, and kept otherwise until you run dispatch clean.
• If the project configures checks.verify, attach needs --allow-unsafe-local, because finishing runs those checks on your machine. mid_run: stop does not apply to attached Work.

Every flag and refusal is in the attach reference.

dispatch setup                # → Runtime integrations… → Install Claude Code hooks
dispatch start
claude --worktree             # a session in its own worktree becomes Work

• S0 is the worktree as the session found it, before its first edit. Later sessions in the same worktree join the same Work.
• When Claude Code removes the worktree, Dispatch first keeps its exact changes, then waits for you to finish or reject them.
• If you let this project’s checks run by themselves (step 05), Dispatch runs them on the kept changes instead, and the Work waits for your review.
• Discovered Work is never applied by itself.
• A session working directly in your checkout is told that Dispatch cannot tell its edits from yours, and nothing is tracked.
• No session in its own worktree is lost silently, even on a busy machine. It ends tracked (its Work exists before the hook returns), pending (its starting state is saved and the watcher finishes creating the Work moments later), or not tracked, and the session is told which. Work is never left half-created.
• Codex has no equivalent lifecycle integration in this version. Attach it: dispatch attach -- codex.

dispatch accept          # applies, then records your acceptance
dispatch reject          # records your decision; the source is untouched

# A REFRESH from the analysis alone, when you checked the Work still holds:
dispatch accept --despite-refresh --explanation "<why it still holds>"

Both commands also take repeatable --reason labels and an --explanation, stored verbatim on your machine.

# A run Dispatch launched:
dispatch refresh

# Attached Work: run your agent again on current code and attach it
dispatch reject <run-id>
dispatch attach -- claude

The coherence: block configures the gate: set accept: strict to refuse on any drift, or mid_run: stop so a STOP observed while a native run works cancels it.

# Non-interactive use. The flag acknowledges that the agent runs
# with your OS permissions; local execution is not a security sandbox.
dispatch run "Fix the retry race in the worker" \
  --allow-unsafe-local --json

0

A result is ready for review and verification passed or was not configured

3

A result is ready for review, but configured verification failed

4

The goal is waiting on a human (a durable clarification)

124

The goal-wide deadline expired

1

Execution or orchestration failed, including a mid-run coherence stop

2

Command-line usage error