amirfish1/claude-command-center/fleet-lane-dispatch

Fleet-lane dispatch is the pattern for running several independent, autonomous CCC sessions ("lanes") against separate mission briefs, then collecting and verifying their completion reports. It builds directly on the spawn/report_to mechanics in the ccc-orchestration skill — read that first for the full Spawn/Inject/Ask API. This skill covers the two things that skill doesn't: how to structure a lane's return trip, and how a dispatcher checks a report is true before believing it.

1. Dispatcher: spawning a lane

Each lane is a normal /api/sessions/spawn call with report_to set to your own session id (see ccc-orchestration § 2 for the full payload). The prompt should point at a self-contained mission brief — a file the lane can read independently, not a paraphrase — plus the return-address block:

curl -s -X POST "$CCC_URL/api/sessions/spawn" -H "Content-Type: application/json" -d @- <<'JSON'
{
  "prompt": "Read the mission brief at /abs/path/to/brief.md and execute it completely and autonomously. Do not stop to ask questions. Report back when done (see below).",
  "repo_path": "/abs/path/to/repo",
  "report_to": "<your-session-id>"
}
JSON

CCC appends the return-address footer for you (the _wrap_prompt_with_return_address behavior documented in ccc-orchestration) — you don't need to hand-write the /api/inject-input instructions yourself, but writing them explicitly (as below) makes the brief self-contained if it's ever read outside CCC.

2. Lane: sending the completion report

One report, sent once, at the very end — not progress updates mid-task:

curl -s --max-time 30 -X POST "http://127.0.0.1:8090/api/inject-input" \
  -H "Content-Type: application/json" \
  -d '{"session_id": "<dispatcher-session-id>", "announced_from": "<your session name or id>", "text": "<report>"}'

Run this curl with the network sandbox disabled (loopback IPC) — see ccc-orchestration § 1.2. The text must contain, in this order:

• STATUS: SUCCEEDED or STATUS: FAILED
• SUMMARY: 1-3 sentences of what was done
• FILES: paths touched/created, or none
• REASON: only if FAILED — what blocked you

JSON-escape text (quotes, newlines) so the payload parses.

3. Dispatcher: verifying a report before trusting it

A lane's own SUCCEEDED claim is not evidence — it's a claim. The lane wrote its own report; it did not have an adversary checking its work. Before marking a lane done, cross-check the FILES field against the actual repo state in the lane's repo_path:

# Do the claimed files actually exist / were they actually touched?
git -C /abs/path/to/repo log --oneline -n 10 -- <claimed-path>
git -C /abs/path/to/repo diff --stat HEAD~5..HEAD -- <claimed-path>
ls -la /abs/path/to/repo/<claimed-path>

Red flags that mean the report should not be trusted as-is:

• STATUS: SUCCEEDED but git log shows no recent commit touching the

claimed files, and ls shows nothing new either — the work described didn't land.

• FILES: none on a lane whose mission brief required a code or doc change —

likely means the lane didn't actually do the work, or did it but forgot to commit (git status in that repo will show uncommitted changes if so).

• A report that never arrives — check wt workers / /api/sessions/spawned

for whether the lane's session is still alive before assuming it finished silently.

If a lane reports FAILED, read its REASON and decide whether to re-dispatch with a narrower brief, fix the blocker yourself, or escalate to the user — don't silently retry the identical prompt and hope for a different result.

What this is not

This skill doesn't cover the spawn/inject/ask HTTP contract itself (see ccc-orchestration), and it isn't a task queue — for a durable, resumable queue of tickets across a fleet of workers, that's WatchTower (wt), not CCC.