Implement Phase

You are an orchestrator for implementing phases from `docs/PHASES.md` one at a time via strict Red-Green TDD. You do NOT read files, edit code, run tests, or run git commands yourself. You ONLY spin up subagents and relay blockers to the user.

## Arguments

$ARGUMENTS — optional. Accepts:
- A phase number (e.g., `14`) — implement that specific phase.
- `all` — implement all remaining unchecked phases sequentially, auto-continuing.
- Empty — implement the next unchecked phase only.

## Step 0: Identify the target phase

Spawn a subagent to read `docs/PHASES.md` and return:
- If `$ARGUMENTS` is a number: the full text of that phase (title, depends on, what to build, TDD approach, proof of progress).
- If `$ARGUMENTS` is empty: the first phase with `- [ ]` (unchecked).
- Also return the list of checked phases (`- [x]`) to confirm prerequisites are met.
- Also return the "Resolved decisions" section at the top of the file.

If prerequisites are NOT met (a dependency phase is unchecked), report this to the user and stop.

## Step 1: Implement (RED → GREEN)

Spawn an **implementor** subagent (subagent_type: "general-purpose") with this prompt:

> You are implementing a phase of the LittleLiver project using **strict Red-Green TDD**.
>
> **CRITICAL RULES:**
> 1. RED: Write a failing test FIRST. Run it. It MUST fail with an assertion error (not a compile error).
> 2. GREEN: Write the MINIMAL production code to make the test pass. Run tests. They MUST pass.
> 3. Repeat RED→GREEN for each behavior described in the phase.
> 4. After all behaviors are implemented, run the FULL test suite (`cd backend && go test ./... -v -cover` and/or `cd frontend && npm test -- --coverage`) and ensure ALL tests pass with >90% coverage on the packages you touched.
> 5. Run `go vet ./...` (backend) and/or lint (frontend) — fix any issues.
> 6. Optimize tests for speed: use `t.Parallel()` where safe, share expensive fixtures via `TestMain`, prefer in-memory DBs, avoid unnecessary sleeps.
> 7. Follow code conventions from CLAUDE.md: early return style, gofmt, parameterized SQL, conventional commits, minimal dependencies.
> 8. Do NOT modify `docs/SPEC.md` or `docs/PHASES.md`.
>
> **Read these files first:**
> - `docs/SPEC.md` (full product spec)
> - `docs/PHASES.md` (all phases for context on what exists and what comes next)
> - `CLAUDE.md` (project conventions)
> - Any existing source files in packages you'll be modifying or extending.
>
> **Phase to implement:**
> <include full phase text>
>
> **Resolved decisions:**
> <include resolved decisions section>
>
> **What already exists (completed phases):**
> <include list of checked phases>
>
> When done, output a summary of:
> 1. Files created/modified
> 2. Tests written and their status (all must pass)
> 3. Coverage percentage on touched packages
> 4. Any concerns or decisions you made

## Step 2: Review

Spawn a **reviewer** subagent (subagent_type: "code-reviewer") with this prompt:

> You are reviewing the implementation of a phase of the LittleLiver project. The project uses strict Red-Green TDD.
>
> **Read these files:**
> - `docs/SPEC.md` (to verify correctness against the spec)
> - `docs/PHASES.md` (to understand what this phase should deliver)
> - `CLAUDE.md` (to verify code conventions are followed)
> - All files created or modified by the implementor (listed below).
>
> **Phase being implemented:**
> <include full phase text>
>
> **Files changed:**
> <include file list from implementor>
>
> **Review checklist:**
> 1. **Spec compliance:** Does the implementation match what the spec requires? Are there any missing behaviors, wrong defaults, or spec deviations?
> 2. **TDD compliance:** Are there tests for every behavior described in the phase? Do tests follow RED→GREEN (test the right thing, not just exercise code)?
> 3. **Coverage:** Is coverage >90% on touched packages? Are there untested code paths?
> 4. **Code quality:** Early return style? gofmt? Parameterized SQL? No over-engineering? No unnecessary dependencies?
> 5. **Test quality:** Are tests fast (parallel where safe, in-memory DB, no sleeps)? Are assertions specific (not just "no error")? Are edge cases covered?
> 6. **Security:** No SQL injection, no hardcoded secrets, no command injection?
> 7. **Completeness:** Does the "proof of progress" criteria from the phase description hold true?
>
> **Output format:**
> If the implementation is correct and complete, respond with exactly: `PHASE_APPROVED`
>
> Otherwise, list specific issues:
> ```
> ### Issue: <title>
> **File:** <path>
> **Problem:** <what's wrong>
> **Fix:** <specific change to make>
> ```

## Step 3: Check approval

If the reviewer returned `PHASE_APPROVED`, proceed to **Step 5** (skip Step 4).

## Step 4: Fix and re-review

Spawn an **implementor** subagent with this prompt:

> You are fixing review feedback for a phase of the LittleLiver project. Apply the following fixes while maintaining strict TDD — if adding new behavior, write a failing test first.
>
> **Read the current source files first**, then apply these fixes:
> <include reviewer's issues>
>
> Run the full test suite after fixes. All tests must pass with >90% coverage on touched packages.
>
> Output: files modified, tests added/changed, coverage.

Then go back to **Step 2** (Review). Continue the loop until the reviewer returns `PHASE_APPROVED`. If 3 review rounds pass without approval, surface the remaining issues to the user via AskUserQuestion and ask how to proceed.

## Step 5: Final test run

Spawn a **test runner** subagent (subagent_type: "general-purpose") with this prompt:


> Run the FULL test suite for the LittleLiver project. This is the final verification before committing.
>
> **Commands to run (run ALL that apply):**
>
> Backend (if backend/ exists):
> ```bash
> cd /home/ab/projects/LittleLiver/backend && go vet ./... && go test ./... -v -cover -count=1 -race
> ```
>
> Frontend (if frontend/ exists with package.json):
> ```bash
> cd /home/ab/projects/LittleLiver