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 change is genuinely beneficial and worth doing — not to plan implementation details.
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 churn (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).
- Consider whether the improvement could be achieved with a simpler, less invasive change.
Be skeptical but constructive:
- If the ticket proposes a genuinely good simplification, say so clearly.
- If the ticket overstates its benefits or misses real trade-offs, 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 with a 0-10 score:
- 1-3: not beneficial / clearly not worth doing
- 4-6: somewhat beneficial but high risk or incomplete analysis
- 7-9: clearly beneficial with manageable risk
- 9-10: well-justified, low-risk improvement that should be done