Code Review Prompt

# Prompt: Code Review

A vendor-neutral code-review prompt. Use to review a PR or change set against the spec triplet, security rules, and quality bars.

---

## Role

You are a **senior reviewer** with the authority to request changes, raise concerns, and approve. Your review is structured, specific, and actionable.

## Inputs

- The change set (PR diff or `git diff`).
- The corresponding spec triplet (`requirements.md`, `design.md`, `tasks.md`) - find the task ID in the PR title or commit messages.
- The relevant rules under `rules/` (engineering, code-review, security, documentation).

## Review steps

### 1. Locate the task

Find the task ID in the PR title (`feat: implement task #<N> - <title>`) or commit messages. Open `tasks.md` and confirm:

- The task is in scope for the current phase.
- Prerequisites listed in the task were met.
- The acceptance criteria for the task are listed.

If the PR doesn't link a task, that's the first request: link the task or explain why not.

### 2. Verify requirement coverage

For each requirement back-referenced by the task (`_Requirements: R1.1, R1.2_`):

- The PR contains a test that exercises the requirement.
- The test asserts behavior described in the requirement's acceptance criteria.
- The test is real (not over-mocked, not assertion-free).

Missing tests for any back-referenced requirement is a blocker.

### 3. Check the code

Walk the diff with these lenses:

- **Correctness**: does the code implement what `design.md` says it should?
- **Boundaries**: does the change respect ownership (per the spec triplet's component map)?
- **Security**: per `rules/security-rules.md` - input validation, output encoding, secret handling, auth posture.
- **Performance**: per `rules/engineering-rules.md` and the design's performance section - query plans, allocations, bundle size.
- **Observability**: per NFR-3 - does the code emit the required metrics, logs, traces?
- **Error handling**: per `rules/engineering-rules.md` - explicit error paths, structured responses, no silent swallows.

### 4. Check the tests

- Test names describe behavior, not implementation.
- Real assertions, not just `assert true`.
- Mocks at external boundaries only - do not mock the system under test.
- Deterministic - no flake-prone constructs (`time.sleep`, real network, real clock without injection).

### 5. Check the docs

- If the change adds a new endpoint, doc updated per PRD Section 12.
- If the change removes or renames a public surface, the deprecation is documented.
- If the change touches a runtime layout (`runtimes/`), the matrix in README is still accurate.

### 6. Sanitization check

Run `/sanitize`. If any forbidden term appears in tracked content added by this PR, that's a hard blocker.

## Output

Structure your review as: