# Real subprocess execution for /morning, /dispatch, /consult — deferred to CP-N+

`/api/slash/dispatch` accepts a whitelist of slash commands and emits a `BUS` event acknowledging the dispatch. It does NOT actually launch the underlying subprocess — the engine-side dispatcher that would `Popen` the right Claude Code session, gather output, and stream results back through the BUS does not yet exist for any of the three priority commands. The frontend's command palette (⌘K) is fully wired through to this endpoint; the user can type `/morning` and see the BUS event surface in the events drawer; the loop just terminates there.

The three priority commands and their target dispatchers, when wired:

| Command | Target dispatcher | Target machine | Notes |
|---|---|---|---|
| `/morning` | `~/.claude/skills/morning/SKILL.md` | local (Studio or MBP, whichever fired the request) | Reads vault + cortex + email triage; emits a briefing artifact. Output rides BUS as `severity="info"` frames. |
| `/dispatch` | `~/.claude/skills/dispatch/SKILL.md` | local fires a remote SSH+tmux session on Studio (100.105.59.118) | The dispatch skill itself is the dispatcher — it ssh's to Studio and starts a `claude` session in a named tmux window. The console-v2 endpoint becomes a thin proxy: pass `prompt`, surface tmux session id, attach BUS frames to the started session for live tailing. |
| `/consult` | `~/.claude/skills/consult/SKILL.md` | local | Multi-round Gemini + Opus consultation. Long-running (15-90min). BUS frames carry round-by-round output; final SYNTHESIS.md path returned as a structured frame. |

The audit flagged this in Cluster 5B alongside `/api/chat`: wired-UI, stubbed-engine surfaces where the Console v2 fix scope (truth-restoration, hierarchy, chrome) does not include the engine-side wiring.

Three structural reasons the wiring belongs in a future CP rather than this fix:

1. **Process management is its own concern.** Each dispatcher needs lifecycle handling: start, status-poll, cancel, output-stream, completion-detection. That's a substrate question (probably an `EngineProcess` model layered on top of the existing CP-7 Take primitive), not a per-command implementation.
2. **Auth boundary needs spec.** Today every slash command runs as JT in a fully trusted context. The console-v2 endpoint runs under uvicorn with whatever shell the LaunchAgent gave it. The auth-translation layer (does the LaunchAgent's shell have access to the right anthropic creds, the right ssh keys, the right tmux server?) is not specced.
3. **Output framing varies.** `/morning` finishes in 30-60s and emits a single artifact. `/dispatch` finishes immediately (it returns a tmux session id) but its child runs for hours. `/consult` finishes in 15-90min with structured intermediate frames. A unified frame shape that handles all three needs design — premature without the underlying process model.

The whitelist itself (and the BUS frame the endpoint emits today) is good substrate: the frontend doesn't need to change, the contract doesn't need to change, the wiring CP just replaces the stub body with real `subprocess.Popen` + tmux integration.

Cited: console-v2-audit-2026-05-04 Cluster 5B. See `chat-anthropic-sdk.md` (sibling deferral) and `proposal-execution-glue.md` (sibling deferral). All three share the same wire-is-real, engine-is-stub shape.