用途：找出能真正降低维护成本、同时保持行为不变的重构改动。每条发现都要给出坏味道名称、来源证据和具体改进；只有教科书分类而无实际后果的不算发现。
范围：根据请求和当前上下文确定范围。面对宽泛请求时，先绘制代码库地图并优先处理依赖与热点，不因超过 50 个文件就停下等确认；同时要披露被抽样或未检查的区域。
参考：针对候选问题阅读 references/code-smells-catalog.md 和 references/refactoring-techniques.md 的相关章节。目录中的阈值只是信号，不是必须修改项，也不要求每个类别都产出发现。
分析：追踪归属、耦合、调用点与公共边界。仅当涉及领域模型问题时才查阅 references/solid-ddd-context.md，普通代码不需要做 SOLID 检查。按用户/维护影响、频率、风险和投入对确认的机会排序；对影响最高的项，说明改动前后的行为及负责验证方式。复用已有测试覆盖，缺少测试并不自动意味着每层都要新建测试套件。
输出：报告默认写入 docs/_refacs/<YYYYMMDD>-<slug>.md，可改编 assets/refactoring-report-template.md；范围较窄的请求可用简洁回复。必要时用 checklists/analysis-checklist.md 核对材料引用与推理。
限制与边界：若用户只要审计，就只报告发现；若已授权重构，则继续选定工作而不再询问。保持已发布的兼容性和无关改动不变。收费、价格、平台支持等信息暂未提供。