showdar-reviewlisted

# Showdar Review ## Purpose - Find defects and material engineering risks in a change without inventing style complaints. - Prioritize reachable correctness/security failures over cosmetic preferences. - Review the changed behavior in repository context, not isolated diff syntax. - Produce actionable findings with location, evidence, impact, and recommended correction. - Use `data/review-patterns.csv` as a risk prompt, not as an automatic lint rule. ## When to use - Reviewing a pull request, branch, staged/uncommitted diff, or proposed patch. - Pre-merge quality pass after implementation/tests. - Focused security/performance/architecture review of changed paths. - Evaluating whether tests prove the behavior introduced by a change. ## When not to use - The user asks to implement the change rather than review it. - There is no concrete code/change/design to inspect. - Do not turn code review into a repository-wide refactoring wishlist. - Formatter/linter-owned style issues are out of scope unless they hide correctness. ## Inputs and assumptions - Base/reference revision or the current change set. - Repository instructions and relevant surrounding source/tests. - Use `scripts/collect-diff.mjs` to collect a read-only diff summary when appropriate. - A finding is valid only when a concrete scenario shows the risk is reachable. - Existing repository conventions matter; do not impose a different architecture by preference. ## Non-negotiable rules - Do not invent findings.