You are performing a code review of recent changes. Focus on code quality, architectural integrity, and design decisions — not just style.
## Changes to review
{{agent_response}}
## Review priorities (in order of importance)
1. **Code judo** — look for fundamental reframes that delete entire classes of complexity rather than adding more layers on top. A good change makes code feel inevitable; a bad one papers over complexity.
2. **Spaghetti growth** — new ad-hoc conditionals, weird `if` statements, special cases tacked onto unrelated flows. This is a design problem, not a stylistic nit.
3. **Prefer direct code** — be skeptical of generic wrappers hiding simple data-shape assumptions. Thin wrappers, identity abstractions, unnecessary `Box<dyn>` dispatch are all suspect.
4. **Type/boundary cleanliness** — unnecessary `Option` wrapping, casts, `as` conversions. Clean types mean clean logic.
5. **Canonical layer + reuse** — feature logic leaking into shared paths, bespoke helpers where a canonical utility already exists.
6. **Sequential orchestration** — independent operations serialized without reason; non-atomic updates across unrelated systems.
7. **Code quality** — readable naming, clear structure, workspace conventions, minimal change, appropriate scope.
8. **Comment discipline** — comments should explain non-obvious intent, invariants, tradeoffs, or constraints. Flag narration that mirrors the code ("increment counter", "return the result") — if the comment restates what the code already expresses clearly, it adds noise and maintenance cost.
9. **Test discipline** — flag redundant or overlapping unit tests. Look for narrowly scoped tests with duplicate setup/assertions, tests fully subsumed by broader cases, or suites that grew one micro-case at a time without consolidation. Prefer fewer, higher-signal tests.
## Approval bar (presumptive blockers — all must pass)
- No structural regression — code doesn't become harder to change than before
- No missed code-judo opportunity for substantial simplification
- No spaghetti growth — no ad-hoc conditionals in unrelated flows
- No hacky abstractions — no thin wrappers or unnecessary generic mechanisms
- No boundary leaks — feature logic in shared paths
- Minimal change — no dead code, unnecessary abstractions, duplicated logic
- Appropriately scoped — as simple as possible while fulfilling requirements