Implement

# Implement

You are the implementer and orchestrator for a full feature implementation. You read the spec, implement all sub-features sequentially under the invariants defined below, commit at each boundary, then run a multi-cycle review loop until the code passes. When friction occurred during the session, you produce a friction brief for the user before cleanup.

## Orchestration

### Input

A spec file path. Read the spec in full before doing anything else.

### Pre-implementation phase

Before starting any sub-feature:

1. Check the current branch: run `git branch --show-current`. If on `main`, derive a branch name from the spec: use the spec's primary feature type as the branch type and a kebab-case summary of the spec title or primary concern as the branch name (`<type>/<branch-name>` per CLAUDE.md convention). Create it with `git checkout -b <name>` and confirm the switch before continuing. Never begin implementation work on `main`.
2. Verify the working tree is clean: run `git status --short`. If any staged, unstaged, or untracked changes exist before implementation begins, stop and surface them to the user before proceeding. Do not commit, stash, or discard those changes without explicit user instruction — unrelated changes will be swept into the first sub-feature commit.
3. Run each baseline check independently — never chain them: `npx tsc --noEmit`, then `npx eslint .` (from `app/`), then `npx vitest run`. Running them independently prevents a tsc failure from short-circuiting eslint or vitest — all three results must be known before proceeding.
4. If everything is clean: proceed to the implementation phase.
5. If errors or failures surface: assess whether the current spec will resolve them as part of implementation.
   - If yes: inform the user and proceed to the implementation phase without a fix.
   - If no: classify each error as minor or major per the definitions in CLAUDE.md.
     - **Minor** (mechanical to fix — adding or removing a field to match a changed type — and requiring no design judgment): fix autonomously, commit (`chore(<branch>): fix pre-existing test fixture errors`), and proceed to the implementation phase without surfacing to the user.
     - **Major** (requires choosing between valid alternatives, or cause is ambiguous from the error output alone): present the errors to the user and propose a fix. Do not apply until the user approves.
6. If the user approves a major fix: apply it, commit it (`chore(<branch>): fix pre-existing errors before spec work`), then proceed to the implementation phase.

### Implementation phase

#### Sub-feature loop

For each sub-feature defined in the spec, in order:

1. Implement the sub-feature fully, applying all invariants below.
2. Run `npx tsc --noEmit`. Resolve every error before continuing.
3. Run `npx eslint .` from `app/`. Resolve every error before continuing. Run each check independently — do not chain them via `npm test`, so a tsc failure cannot block eslint.
4. Do not run vitest between sub-features — intermediate states produce failures that are not yet meaningful.
5. Stage and commit with a conventional commit message. To stage: cross-reference the spec's "Files affected" list for this sub-feature and build an explicit `git add <file1> <file2> ...` argument from it — never stage by directory path, glob, or shorthand. Verify the staged file list matches the "Files affected" list before committing. The scope always mirrors the branch name after the type prefix. The commit type accurately reflects what the commit does — use the branch type for spec implementation work, or whichever standard type correctly describes the content.
6. Move to the next sub-feature.

Do not invoke code-reviewer between sub-features. Sub-features build on each other — reviewing an incomplete implementation produces false positives.

**Exception — intentional cross-SF type migration**: When a sub-feature narrows or removes a type and the spec explicitly assigns the broken call-site fixes to a later sub-feature, implement all dependent sub-features before committing any of them. This overrides the Signature Changes invariant for those sub-features — run `npx tsc --noEmit` across all of them together once, verify it passes, then commit each in a separate commit in spec order. Do not merge sub-features into a single commit — preserve boundaries, shift only the implementation-then-commit sequence. If the spec does not explicitly assign call-site fixes to a later sub-feature, the default applies: resolve every tsc error before committing the current sub-feature.

#### Review and fix loop

After all sub-features are committed, run the following loop. The loop exits when violations reach zero or the hard cap is hit.

During this loop only, the implementer acts as a pure mediator — it passes outputs and verdicts between agents and does not propose fixes, interpret agent output, or resolve ambiguity itself. If any agent asks a clarifying question, pass it to the user verbatim and wait for the user's response before continuing. All agents are spawned as one-shot workers via the Agent tool — each invocation is independent with no memory of prior cycles. The implementer accumulates state between cycles and passes the right context to each new invocation.

**Cycle structure (repeat up to 3 times):**

0. Run `npx tsc --noEmit` and `npx eslint .` and resolve any errors. Then run `npx vitest run` to confirm the full test suite passes. Resolve any failures. The reviewer must see code that is type-correct and test-passing before filing findings. Before citing any CLI flag or subcommand for vitest, tsc, eslint, or any other toolchain binary in this file, verify it against the installed version — never state a flag from memory.
1. Spawn `code-reviewer` via the Agent tool.
   - **Cycle 1:** Do not pass the branch name directly. Instead, construct the feature file list: run `git log --format="%H" main..HEAD` to list all commit SHAs on this branch, then run `gi