pedronauck Refactoring Analysis
Find changes that reduce demonstrated maintenance cost while preserving behavior. Name the code smell, source evidence, and concrete improvement; a textbook category without a practical consequence is not a finding.
- Resolve the scope from the request and active context. For a broad request, map the codebase and prioritize dependencies/hotspots; do not stop for confirmation merely because it exceeds 50 files. Disclose sampled or uninspected areas.
- Read the relevant sections of
references/code-smells-catalog.mdandreferences/refactoring-techniques.mdfor the candidates found. Catalog thresholds are signals, not mandatory edits or a requirement to produce findings in every category. - Trace ownership, coupling, call sites, and public boundaries. Consult
references/solid-ddd-context.mdonly for a domain-model question; ordinary code does not need a SOLID pass. - Rank confirmed opportunities by user/maintenance impact, frequency, risk, and effort. For the highest-impact items, describe the before/after behavior and owning verification. Reuse existing coverage; missing tests do not automatically require a new suite at every layer.
- A requested report defaults to
docs/_refacs/<YYYYMMDD>-<slug>.md. Adaptassets/refactoring-report-template.md; a narrow request can use a concise response. Check material citations and reasoning withchecklists/analysis-checklist.mdas applicable. - If the user requested an audit only, report findings. If they already authorized refactoring, continue the selected work without asking again. Preserve published compatibility and unrelated changes.