Ticket Work

Ticket work

In a fresh worktree, run bun run setup before anything else, because without node_modules, src/routeTree.gen.ts and worker-configuration.d.ts the pre-push bun run check fails even on a docs-only ticket. It also runs lefthook install, which writes the hooks every worktree shares with the main checkout. Before the first bun run dev there, run bun run db:push:local, because the local D1 under .wrangler/state starts empty. bun run dev runs through portless, which assigns the dev server a free port and the URL https://<last segment of the branch name>.my-app.localhost (no prefix on main, and two branches that share a last segment share a URL), and Better Auth takes its base URL from the request, so login redirects return to that URL. Google accepts a redirect URI only on a public-suffix TLD or on localhost itself, so check Google login with PORTLESS=0 bun run dev, which serves http://localhost:5173 without the proxy in one checkout at a time. Everything short of Google login is checkable on any worktree's URL.

1. Clarify. Resolve ambiguous acceptance criteria or constraints from the codebase, the assets, or git history. If that fails, a session with the user present hands back the ambiguity that blocks the most work, shaped as AGENTS.md's Decide what the work needs and act on it paragraph says. A dispatched worker states the assumption it took in the PR body and proceeds.
2. Judge the design. Creative or architectural work (new UI, a new pattern, a choice between credible alternatives) is proposed with its alternatives. A session with the user present implements after they approve. A dispatched worker implements the alternative it recommends and writes the others into the PR body.
3. Plan. One sentence of goal, the files to create or edit with one line each, the acceptance criteria, and the verification commands (bun run check / bun run test / build / manual smoke test, as applicable). Enter plan mode when the user asked for a plan.
4. Check the interaction, when it is complex. Wizards and multi-step forms, auth or session flows, async guards, permission branching: lay out the states, the initial one, the actions as guarded transitions, the invariants that must hold, and the flows that must never happen. Then attack it. Hunt a path whose every guard holds and that still breaks one of them, and a sequence of individually-allowed actions whose combination reaches an effect the design would refuse if asked for it directly: a required step skipped, one action replayed for a second effect, a privileged state entered by a route nobody weighed, an authority kept after it was revoked. The moves that find these: back, reload, cancel, retry, double-submit, a second tab, and a session or permission change mid-flow. An action you cannot place is a gap in the design, not licence to assume one. Fix the design before implementing.
5. Implement. The parent implements directly, and delegates only to keep an investigation's raw output out of its context, to run independent units at once, or to hand mechanical implementation to the Codex CLI under the codex-delegation skill. The tests that go with what you add follow AGENTS.md's Testing section. When debugging, reproduce the failure and check what changed recently before forming a hypothesis, then test that hypothesis with the smallest possible change. Never try changes to see which one sticks. Before adding a flag, an override, or a shim to keep a failing mechanism working, remove the mechanism and run the tests; where nothing fails, the mechanism goes rather than the workaround.
6. Self-check. Read the full diff. Run bun run check and bun run test, fixing every error. Confirm step 3's acceptance criteria, reading the diff yourself for anything a subagent implemented rather than its summary.
7. Review, then commit. Dispatch the code-reviewer agent on the uncommitted diff as the ticket's whole review, telling it what changed and why, what is out of scope, and what you are least sure of. Apply the fix each finding returns. Where a finding needs a decision, write the finding, the change it asks for, and your reason into the PR body, and continue. A code-reviewer that returned no report, whether it died or hit a rate limit, is dispatched again. Split the commits as AGENTS.md's Commits & Pull Requests says. gh pr create --draft opened the PR after the first commit, so mark it ready once bun run check and bun run test pass on the branch and every finding a review returned has been answered. Then poll the CI check in one foreground Bash call: until gh pr checks <number> --json name,bucket --jq '.[] | select(.name=="build") | .bucket' | grep -qx pass; do sleep 30; done. A background watch ends the turn before the check reports, and --watch waits on the third-party checks too, one that never reports holding it forever. build is the one job .github/workflows/ci.yaml defines, so select(.name=="build") covers all of this repository's CI, and a second job added to that file goes into the loop as well. --json prints each object's fields in alphabetical order, {"bucket":"pass","name":"build"}, so a grep for "name":"build","bucket":"pass" matches nothing. Where gh pr view --json mergeStateStatus says BEHIND, run gh pr update-branch so the check runs on the merged result, git pull before committing on the branch again, and poll once more. Then gh pr merge --squash and git push origin --delete <branch>, because --delete-branch checks main out locally and fails in a worktree.