review-feature — audit the feature end-to-end against its spec

review-feature asks: "does this feature actually work, for every case someone might hit, in a way that matches what we said we were building?"

It's a logic-and-completeness audit, not a code-style pass and not a UX walkthrough. It traces the data flow from entry to exit (UI → API → service → repository → side effects) and checks each step for:

• Edge cases — empty, null, large, concurrent, out-of-order, partial.
• Error handling — every failure has a defined, surfaced response.
• Loading / pending states — explicit idle, loading, success, error.
• Side effects — analytics, logs, DB writes, jobs, emails, webhooks: intentional, documented, idempotent.
• Spec match — ADR/spec vs. what the code actually does.

Emits findings in the finding-format.md schema. Never edits files, never commits. To act on the findings, call /drive-change (which dispatches fix-applier agents under sensitivity gating).

Phase 0 — Find the spec

The spec is the source of truth. Look for one before reading any code. Search in this order; collect all hits, don't stop at the first: