Analyze the current maintenance/refactoring ticket and evaluate its merit.
This ticket was created by the Maintainer and proposes a code improvement such as refactoring, cleanup, deduplication, or simplification. Your job is to critically evaluate whether the proposed change is genuinely beneficial.
Investigate the claim:
- Validate any claimed lines-of-code savings — search the actual code to confirm the numbers.
- Check whether the refactoring genuinely reduces complexity (cyclomatic, structural, or cognitive).
- Assess whether the change is actually beneficial vs. just adding bloat (more LoC, tests for already working code, redundant comments).
- Scrutinize whether the supposed duplication is real duplication or superficial similarity (same pattern but different intent/logic).
- Examine whether the change could be achieved with a simpler, less invasive approach.
Be skeptical but constructive:
- If the ticket proposes a genuinely good simplification, say so clearly.
- If the ticket is wrong about its benefits or misses real risks, call that out with evidence.
- It is perfectly acceptable to conclude the change is not worth doing if the evidence doesn't support it.
Return a structured research report with:
1. Claim being evaluated (what the ticket proposes and what benefit it claims)
2. Evidence gathered (actual LoC counts, complexity before/after, duplication assessment)
3. Assessment of benefit (does this reduce complexity, eliminate real duplication, or improve clarity?)
4. Risks and trade-offs (what could break, how hard to review, long-term cost)
5. Verdict: list each concern you found with a grade (minor / major / blocker)
- minor: the change is beneficial with small, easily-addressed notes
- major: the change is only borderline beneficial or carries material risk
- blocker: the proposed change is not worth doing / would do real harm