/fleet-verify

name: fleet-verify
description: Use after a UI or user-visible change and before you claim it works — it spawns ONE CCC verification lane that drives a real browser (gstack browse, or CCC's puppeteer snapshot as fallback) against the running app, checks the specific thing you changed, and reports a visual/behavioral verdict with a screenshot. Independent of your context; catches what a diff read and a unit test cannot.
allowed-tools: Bash

`/code-review` reads the diff. `pair-verify` runs a bug at two refs. Neither opens the app and *looks*. Fleet-verify spawns one CCC lane that drives a headless browser against the running dashboard (or your app), verifies the exact change you describe, captures a screenshot as evidence, and reports a verdict. It pairs CCC's spawn/report_to mechanics (`ccc-orchestration`) with gstack `browse` (headless Chromium QA).

Cost

**1 spawned session.** A real billed session on the kanban — state the count before spawning. Skip it for pure backend/logic changes with no rendered surface (there is nothing to look at); use a test or `pair-verify` instead.

Preconditions — gather these BEFORE spawning

The lane can only check what you can point it at. Have all three:

• **(a) A running, reachable app + URL.** For CCC itself that is

`http://127.0.0.1:8090`. For another app, its dev-server URL. If nothing is running, start it first (or say so in the prompt so the lane starts it).

• **(b) The exact thing to verify** — "the skills chip shows a count and the

status rail lists each subagent", not "check the UI". Name the selector, text, or state you expect.

• **(c) The repo path.**

Setup

CCC_URL="$(cat ~/.claude/command-center/port.txt 2>/dev/null || echo "${CCC_URL:-http://127.0.0.1:8090}")"
curl -sf --max-time 2 "$CCC_URL/api/version" >/dev/null 2>&1 || CCC_URL="http://127.0.0.1:8090"
curl -sf --max-time 2 "$CCC_URL/api/version" >/dev/null 2>&1 || CCC_DOWN=1

• Run every CCC curl with the **network sandbox disabled** (loopback is blocked

in the Bash sandbox and fails spuriously even when CCC is up).

• **URL-encode `repo_path`** in query strings.

Spawning the verifier

curl -s -X POST "$CCC_URL/api/sessions/spawn" -H "Content-Type: application/json" -d @- <<'JSON'
{
  "prompt": "Independent visual verification. Drive a headless browser and confirm a specific change. 1) Use gstack browse (the `browse` skill): `$B goto <url>`, then `$B text`, `$B js \"<expr>\"`, `$B is visible @<ref>` to check state, and `$B screenshot /tmp/fleet-verify-<slug>.png` for evidence. If gstack browse is unavailable, run CCC's `node snapshot.js` first (it writes snapshot.png). Do not substitute chrome-devtools: only use chrome-devtools after `curl -fsS --max-time 2 http://127.0.0.1:<debug-port>/json/version` returns Chrome JSON. 2) Verify EXACTLY this: <the specific thing — selector/text/state you expect>. 3) Report VERDICT (VERIFIED / NOT-VISIBLE / WRONG-STATE / APP-DOWN), the commands you ran, and the screenshot path as evidence. Be literal: report what you actually see, not what the change intended.",
  "repo_path": "/abs/path/to/repo",
  "report_to": "<your-session-id>"
}
JSON

• Omit `"model"` and `"reasoning_effort"` to use the server spawn defaults; if

you pass either, pass `"engine"` too (both are validated per engine, and the effort ladder differs by engine: see `ccc-orchestration` § 2).

• CCC appends the return-address footer (`report_to`), so the verdict injects

back to you when the lane finishes.

Waiting for the report

After spawning, **end your turn.** Tell the user a lane is verifying and give its session id. The verdict arrives by injection — do **not** poll or sleep-loop. If it never arrives, check `GET /api/sessions/spawned` for whether the lane is alive.

Interpreting the verdict

• **VERIFIED** — the change renders/behaves as described, with a screenshot to

prove it. Ship it.

• **NOT-VISIBLE** — the lane could not find what you described. Either the change

did not take, or you pointed it at the wrong place. Investigate before claiming.

• **WRONG-STATE** — it rendered, but not as you expected. Read the evidence.
• **APP-DOWN** — nothing was running to verify. Start the app and re-run.

Dry run

If the arguments contain `dry-run`, print the exact payload — session count (1), the filled-in verifier prompt with URL and the specific check, and the target repo — and POST nothing.

Honest fallbacks

• **CCC down (`CCC_DOWN=1`):** run gstack `browse` (or `node snapshot.js`)

yourself against the running app, and in your claim say verification was **self-run** — you know what the change was meant to do, so you are a weaker skeptic than a fresh lane. Never pretend the spawn ran.

• **No browser tooling at all:** say so plainly and fall back to a functional

check (curl the endpoint, assert the JSON/DOM string). A string assertion is not the same as *seeing* it render — flag the gap.