w-review

# Review dimensions

Check the dimensions in scope for this change. Skip those that are clearly out of scope and say so.

- [ ] **Correctness**: success, empty, invalid, failure, and concurrency cases relevant to this change.
- [ ] **Callers**: existing call sites, generated clients, and public exports still match the new contract.
- [ ] **Failure paths**: error handling, denied access, and recovery are evidenced, not assumed.
- [ ] **Clarity**: names and control flow expose intent; refactoring removes complexity instead of moving it.
- [ ] **Architecture**: ownership, dependencies, generated sources, and existing shared helpers remain coherent. Generated files were not edited by hand.
- [ ] **Security**: changed input and authorization boundaries, secret exposure, and denied access paths are checked.
- [ ] **Performance**: changed queries, list bounds, repeated work, and client rendering have evidence appropriate to their risk.
- [ ] **Verification**: tests exercise behavior; claimed checks were actually run and cover the change. If a finding implies a new quality or security bar, point at existing testing or security docs instead of inventing policy.
- [ ] **Docs**: matching MDX and nearest README were updated when behavior, commands, or conventions changed.

---
name: w-review
description: Review a change for evidenced defects and risks without editing it.
disable-model-invocation: true
---

Use the specified diff, branch, PR, or working tree and its intended behavior. Remain read-only unless fixes are also requested.

1. Understand the trigger and expected result before judging the implementation. Read tests to learn which claims are actually exercised.
2. Check the in-scope [review dimensions](references/review-dimensions.md), including docs/README when behavior changed. Spawn 2–3 read-only explorers that split those dimensions. Concentrate on changed behavior, callers, and failure paths. Skip dimensions that are out of scope and say so.
3. Validate suspected defects with a concrete execution path, failing case, or source evidence. Do not invent timings or vulnerabilities from appearances.
4. Challenge verification claims. Order findings by impact with file/line, trigger, consequence, and smallest useful remedy. An inspection is not proof that tests passed and is not approval to merge.