critic-gated-buildlisted

# Critic-Gated Build Run an entire build — intake → spec → TDD implementation → deploy → independent critique — as one autonomous loop whose "done" is decided by a **fresh-context, third-party LLM critic**, not by the builder. Proven end-to-end on schmug/shelflife (idea → live multiplayer game, ship gate met at critic cycle 5 of 12). ## Phase 0 — Intake (user present) Use AskUserQuestion in 2–3 batched rounds for only the load-bearing decisions; recommend a default in each: 1. Stack/hosting, data layer, identity model. 2. **Critic provider** — prefer a genuinely third-party CLI already authenticated on the machine (probe: `which codex gemini` and `ls ~/.codex/auth.json`; smoke-test `codex exec --skip-git-repo-check --sandbox read-only "Reply CRITIC_ONLINE" < /dev/null`). Fallback: fresh-context subagent of the building model (disclose the reduced independence). 3. **Done bar** — default: every rubric category ≥ 8/10 on **two consecutive cycles**. 4. **Cycle cap** — default 12; on cap, stop and report gaps instead of thrashing. 5. Deploy target, repo name/visibility, check-in points (default: first deploy + completion only). Then: spec (committed to the repo), implementation plan, explicit user approval of the design. You are operating autonomously from this point: the user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to…?' or 'Shall I…?' will block the work. The exceptions are exactly the check-ins already named above and below: t