review-changelisted

<!-- Generated by Agent Profile Compiler. Do not edit by hand. --> # Review Change Use these rules when reviewing a pull request or proposed change. ## Review Focus - Correctness and edge cases. - Security, including input validation and secret handling. - Performance hotspots and obvious complexity regressions. - Unnecessary complexity or premature abstraction. - Consistency with existing project style. - Missing or weakened tests. - Weak typing or unjustified `any`. - Accessibility-affecting behavior in user-facing changes. - Error handling and observability gaps. - Dependency risk and license concerns. - Spec compliance. ## Severity Labels - Blocker: must fix before merge (correctness, security, contract break). - High: must fix before merge unless explicitly deferred. - Medium: should fix before merge or open a tracked follow-up. - Low: nit or polish; safe to defer. ## Output Format - Summary: one paragraph of intent and overall verdict. - Spec Compliance: cite the spec and any deviation. - Findings: grouped by severity, each with file, function, and concrete suggestion. - Tests: list coverage gaps and whether tests were run. - Safety Review: secrets, production access, dependency installs, network access. - Final recommendation: approve, request changes, or block with reason. ## Review Discipline - Skip nitpicks the autoformatter or linter already handles. - Do not propose broad rewrites; keep suggestions actionable. - Reference the specific file, function, or