shiplisted

Shipping end to end. Task: `$ARGUMENTS` This is the full ceremony: plan → implement → gates → browser evidence → independent review → report. No auto-commit; the user reviews the diff and runs `/gitpush`. Each phase has a gate. On a failure, decide between fix-and-retry (cheap and obvious) and stop-and-ask (risky or ambiguous). When in doubt, ask — one question is cheaper than 400 lines in the wrong place. ## Phase 0 — Pre-flight 1. Read `CLAUDE.md`. If the task touches `webview/src/**`, read `docs/TOKENS.md` too. 2. `git status --porcelain` — start from a known state. Uncommitted work from something else means stop and ask, because the final diff will not be yours. 3. Nothing long-running needs to be up. Unlike a web app, this project has no dev server to depend on: `/browser` starts its own harness in Phase 5. If the user happens to be running `bun run dev:webview`, leave it alone. ## Phase 1 — Plan Before writing code, state: - Which files get created or modified, with paths - Which side of the `postMessage` boundary the work lives on — extension host, webview, or both. If both, name the messages that cross - Which existing primitives, tokens and motion presets get reused instead of new ones - What will prove it works: which test, and what the browser harness will show **Gate 1.** Trivial work — a single-file fix, a copy change — proceeds without approval. Anything touching multiple files, the protocol, or the permission path gets the plan shown as