amirfish1 / fleet-verify

/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.