Zoonk Code Review

Zoonk code review

Review correctness, product intent, architecture, permissions, performance, and the user experience. Automated checks support these judgments; a green suite is not proof that the design or assumptions are correct.

Scope and evidence

Determine the requested comparison: index, unstaged changes, working tree, commit, branch, or PR. Inspect every file in that diff and enough callers and contracts to understand changed behavior. Do not mix unrelated unstaged work into an index review. Use applicable repository instructions already in context; read additional scoped guidance only where the changed paths need it.

Follow the root instructions for fixing confirmed bugs during reviews. An explicitly findings-only or read-only review stays read-only. For authorized fixes, preserve the user's index and complete relevant verification before local review; the skill does not authorize commits or external publication.

Reconstruct the intended behavior independently of the implementation’s explanation. Identify the assumptions required for the design to work, then investigate reachable conditions that could invalidate them. Trace those assumptions across callers, shared state, and component boundaries; individually correct parts do not establish correct composition. A constructed reproduction proves that case occurs under its supplied conditions; verify that those conditions are possible in this product.

A follow-up review must reassess the assumptions and coverage supporting the earlier conclusion. Reuse valid evidence, but investigate what the earlier review did not establish. Review fixes with the same scrutiny as the original change, including their effects on surrounding behavior.

Classify concerns before reporting:

• Real bug: A reachable path violates the established product or repository contract with a concrete consequence.
• Behavior-dependent: The outcome depends on an unverified product rule, caller, environment, or deployment condition. State that condition and keep it separate from confirmed findings.
• Non-bug: Intentional, unreachable, speculative, or preference-only. Explain rejected supplied comments briefly; omit them from findings.

Follow the changed behavior

Choose the relevant areas below rather than running a fixed audit of every subsystem:

• Product and correctness: Trace input through validation, persistence, side effects, caching, and output. Examine retries, cancellation, concurrency, stale state, and partial failure where the changed path permits them. Preserve the product contract and remove leftovers from superseded requirements.
• Architecture and simplicity: Check the core/app boundary, API parity, ownership of shared rules, and whether the added abstraction solves an actual need. Evaluate reused abstractions against the guarantees their callers require. Establish those guarantees from their implementations and actual usage, rather than their names, proximity, or existing adoption. Reject competing sources of truth and unnecessary compatibility layers. Check consumers when moving symbols or changing contracts.
• Permissions and privacy: Check authorization beside protected reads/writes, including resource ownership and publication state. Review cache scope, input handling, and exposure of private data through responses, logs, analytics, or client bundles. UI visibility is not authorization.
• Performance: Preserve independent async work; examine added queries, model calls, unbounded results, or client payloads. Repeated cheap translation calls are expected. Require evidence before proposing performance machinery.
• Data and workflows: Check uniqueness, transactions, retry safety, freshness, and invalidation. Public API changes must preserve the OpenAPI contract; distinguish public product endpoints from the same-origin transport exception in API guidance.
• UI and native behavior: Judge the whole changed flow, including accessibility and recovery states, in the actual application when relevant. Distinguish rendered observations from static inference.
• Coverage: Check whether assertions would catch the real defect and whether fixtures isolate persisted state. Do not request tests that only mirror copy, styles, schemas, or library behavior.