Simplify

Perform one finite, read-only maintainability review. Do not change code, tests, documentation, Git state, provider state, or the review target. Keep functional correctness, security, runtime compatibility, behavioral proof, release readiness, and architecture planning outside this review.

1. Fix the candidate

Use the target supplied by the user. Otherwise, use the upstream merge-base diff and include working-tree changes when they belong to the requested candidate.

Pin the base and candidate to commits, trees, or a fixed working-tree digest. If more than one credible boundary exists, ask one focused question and stop.

Review the fixed candidate and the minimum surrounding context needed to verify a finding. Exclude unrelated, generated, and vendored code.

Apply repository instructions and adopted language, framework, architecture, and style standards before general engineering principles. Treat external quality models, design principles, metrics, and thresholds as review heuristics unless the repository adopts them as requirements.

Use an exact-current Irinṣẹ result only to prioritize bounded inspection. Treat metrics and static-analysis output as leads, not maintainability findings, and verify each reported maintenance cost in the candidate.

2. Review the candidate

Report only actionable maintainability findings. For each finding, give the file, line, summary, applicable repository rule or engineering principle, evidence, concrete maintenance cost, and smallest credible correction direction. A principle name or code smell is not evidence. Do not report style preferences.