mc-refactor-arch

name	mc-refactor-arch
description	审查用户指定范围内的所有文件，列出架构重构计划并执行

任务简介

description: 审查用户指定范围内的所有文件，列出架构重构计划并执行。

重构准则

模块的职责边界必须清晰明确，单一职责原则必须得到遵守。

任务详细流程

先阅读：/docs/PROJECT_CONVENTIONS.md 和 /docs/CODE_CONVENTIONS.md 来了解项目的规范。

然后充分阅读指定范围内的各级readme，确保你充分理解了它们的功能、结构、模块关系、上下游依赖关系、架构组成等。

然后派出8个子代理，它们严格根据重构准则，分别审查：

• 模块之间存在一部分重合、相似的功能与职责，则考虑合并模块，或者将重合的功能抽取到一个新的模块中。
• 模块的功能过于庞杂、过于细碎，导致职责边界不清晰，需要进行拆分或合并。
• 两个模块如果耦合度过高，导致它们无法独立演化，需要进行合并或者调整设计以降低耦合度。
• 模块的命名不合理，无法准确反映模块的职责和功能，需要进行重命名。
• 模块的目录结构不合理，导致模块之间的关系不清晰，需要进行调整。另外我希望一个文件只能包含一个类，除非它们之间有非常紧密的关系。
• 模块内是否有冗余的代码、重复的代码、没被清理掉的旧代码等情况。我有强烈代码洁癖，不允许留任何旧代码旧文件。不允许通过注释等任何手段保留旧代码，不允许以兼容为理由保留旧代码，不允许未经允许的情况下乱加adapter或兼容层来保留旧代码。重构类任务的目标就是把旧代码完全替换掉，留下干净的新实现。
• 封装泄漏、抽象泄漏、在不合适的层次暴露了不应该暴露的细节或使用了本不该在这一层级的逻辑等情况
• 其他你觉得需要重构的情况。

子代理的配置项必须如下： run_in_background: false, model: haiku, isolation: 不要配置

子代理探索完毕之后，如果仍然有你不确定的细节、想了解的实现等，继续派出大量子代理进行探索，直到你完全有把握为止！

然后进入计划模式，调用ask user question工具询问用户做出架构决策，等用户全部回答后才能列出重构计划。你问问题的时候，建议从以下方面询问：

• 重构方案的多个细节：如果有多个重构方案，询问用户更倾向于哪一个方案，或者是否有更好的方案。
• 重构进行的彻底程度：询问用户希望重构进行得彻底一些，还是只进行必要的调整。越彻底的重构带来的架构改进越大，但同时也可能带来更大的工作量和风险。
• 重构的优先级：如果有多个需要重构的地方，询问用户希望优先重构哪个地方。
• 其他你觉得需要询问用户的细节。 ask user question工具只允许一次最多询问四个问题，这肯定不够，所以你需要分多轮来询问用户，直到你觉得你已经收集到了足够的信息，可以做出架构决策为止。

【重要】不要启动plan agent，你必须亲自起草计划！ 【重要】不要启动plan agent，你必须亲自起草计划！ 【重要】不要启动plan agent，你必须亲自起草计划！

计划文件必须非常详细，包含尽可能多的信息，以便交接时顺利。

用户同意计划之后，退出计划模式，开始重构。

最后生成提交信息，提交代码。