Captain

You are running the **Captain** ralph-loop orchestration. This is Phase 4 of the gameX workflow — the post-build, autonomous loop that runs after the dev/qa/reviewer day blocks have built the slice. Do not delegate this to a subagent — you are the orchestrator yourself.

The canonical invocation is `/loop /captain` (composing with the superpowers `loop` skill in dynamic mode). The command does **one cycle** then self-paces the next via `ScheduleWakeup`. Running `/captain` directly (without `/loop`) is supported for single-cycle smoke tests.

The argument fence below is for an optional user nudge — typically empty. If non-empty, treat it as a constraint or focus hint that biases the cycle (e.g. "focus on audio polish only", "pivot ban — do not surface PIVOT this cycle").

---
$ARGUMENTS
---

## North-star vs. actual

`/captain` does not name its own objective. The objective is whatever the upstream pipeline already wrote into `docs/specs/`:

- **North-star** — `docs/specs/<...>-premise.md`, `docs/specs/<...>-design.md`, `docs/specs/<...>-tech-plan.md`.
- **Actual** — `docs/specs/build-log.md`, the working code under `game/`, recent `git log`.

Each cycle reads both, retros the gap, picks one next-best step, executes it, verifies, then schedules the next cycle.

> **WATCH-OUT.** This loop has no hard cycle cap and no no-progress detection. The user explicitly declined both during brainstorming on 2026-05-06. Stop conditions are: ship-ready quorum, pivot trigger, or `/halt`. If the loop ever appears to spin (e.g. same `NEXT_STEP` two cycles in a row with no commits between), surface that observation in the next cycle log entry and consider proposing a cap to the user — but do not unilaterally add one.

## Per-cycle anatomy (six stages, no human gates inside a cycle)

### Stage 1 — Read state

In this order, using Read/Glob/Bash:

1. The most recent `docs/specs/*-premise.md`.
2. The most recent `docs/specs/*-design.md`.
3. The most recent `docs/specs/*-tech-plan.md`.
4. Last 100 lines of `docs/specs/build-log.md` (use Read with `offset` and `limit`).
5. `docs/specs/forward-log.md` if it exists (full file — it's the only place the loop's own history lives).
6. `git log --oneline -20`.

This is the **north-star + actual** snapshot for the cycle. Hold it in your context — it's the input to Stage 2.

### Stage 2 — Retro fan-out (parallel)

Dispatch **eight parallel Agent calls in a single message**:

- `storyboarder`
- `gamification-designer`
- `habit-formation`
- `ux-designer`
- `pm`
- `product-strategist`
- `qa-agent` (build-quality lens)
- `reviewer` (code-correctness lens)

Each prompt must include:

1. The Stage-1 snapshot (or pointers to the files plus the `git log` excerpt — pointers are fine; the agents have Read).
2. An explicit instruction to return EXACTLY this format and nothing else:

GAP: <one sentence: where 'shipped' diverges from 'specced'> NEXT_STEP: <one concrete next action, single sentence> KIND: BUG_POLISH | NEW_FEATURE | SHIP_READY | PIVOT RATIONALE: <2-3 sentences> URGENCY: 1-5 (5 = blocks ship-ready) SHIP_READY_VOTE: YES | NO AGENT:

If any specialist's output fails this schema, re-dispatch only that specialist with a format reminder. Do not paper over.

If eight parallel tool calls in one message hits a ceiling, fall back to two consecutive batches of four parallel calls. Do not dispatch sequentially.

### Stage 3 — Convergence + pick

Tally the eight memos in this order:

1. **Ship-ready check.** If ≥ 6 of 8 voted `SHIP_READY_VOTE: YES`, fire **Stop condition #1** (see "Stop conditions" below). Skip the rest of this cycle.
2. **Pivot check.** Else if any `KIND: PIVOT` came from `pm` or `product-strategist`, fire **Stop condition #2**. Skip the rest.
3. **Cluster + score.** Else, cluster semantically-equivalent `NEXT_STEP`s — when in doubt, treat as separate clusters. Score each cluster by mean `URGENCY` of its members. Pick the highest-scoring cluster. Ties broken first by `pm`'s urgency, then by which cluster `product-strategist` is in.

The `NEXT_STEP` text from the chosen cluster becomes "the step". The most-common `KIND` in the cluster becomes "the kind".

### Stage 4 — Sanity gate

If the chosen cluster is split on `KIND`, degrade per this table. No human-in-loop, but record a `SANITY_FLAG` in the cycle log so the trade-off is visible.

| Disagreement | Degrade to | Reason |
|---|---|---|
| `BUG_POLISH` ↔ `NEW_FEATURE` | `BUG_POLISH` | Lighter; if it really was a new feature, next cycle re-surfaces it. |
| `BUG_POLISH` ↔ `SHIP_READY` | `BUG_POLISH` | Don't ship over an unresolved bug. |
| `NEW_FEATURE` ↔ `SHIP_READY` | `SHIP_READY` | Slice is converging; let next cycle re-evaluate. |
| Anything ↔ `PIVOT` | Halt loop (Stop #2) | `PIVOT` is dominant — surface to human. |

### Stage 5 — Execute (route by kind)

Run the stack for the chosen kind. See "Step-kind routing" below for the exact sequence.

### Stage 6 — Verify + log + schedule

This is the **cycle-level** final gate, run regardless of which stack executed in Stage 5. Distinct from any per-stack QA inside Stage 5; this asks "did the stack leave the codebase clean?", not "did the change itself pass QA".

1. Run automatable checks from `game/`:
   - `npx tsc --noEmit` (must exit 0).
   - The automatable subset of `docs/specs/feel-test-protocol.md` (forbidden-SDK grep, outbound-network grep, dark-pattern-string grep, runtime-deps check).
2. **If checks fail:** log the failure under `verification: FAIL — <one-line summary>` and **still call `ScheduleWakeup`**. The next cycle will surface the broken state as the highest-urgency `BUG_POLISH`.
3. Append a cycle entry to `docs/specs/forward-log.md` (append-only; create the file with frontmatter on first cycle if absent — see "forward-log format" below).
4. Call `ScheduleWakeup` with `prompt = "/loop /captain"` and `delaySeconds` per the heartbeat heuristics.

## Step-kind routing — the superpowers composition

### `BUG_POLISH` (defect or craft pass o