mc-simplify

name	mc-simplify
description	审查用户指定范围内的文件，在保持逻辑大体不变的情况下，删除、简化不必要的内容，使其更清晰易懂。

任务简介

审查用户指定范围内的文件，在保持逻辑大体不变的情况下，删除、简化不必要的内容，使其更清晰易懂。

任务详细流程

先阅读：/docs/PROJECT_CONVENTIONS.md 和 /docs/CODE_CONVENTIONS.md 来了解项目的规范。所有子代理也必须在prompt中要求它们先阅读这些文档。

然后充分阅读指定范围内的各级readme，确保你充分理解了它们的功能、结构、模块关系、上下游依赖关系、架构组成等。注意，在派出子代理之前，尽量不要直接阅读代码实现细节，先从高层次的文档理解开始，以避免耗尽上下文资源在不必要的细节上。

然后派出4个子代理，它们分别审查：

代理 1：代码复用审查

针对选定范围的代码：

1. 搜索现有的工具函数和辅助函数，看是否能替换新编写的代码。在代码库中查找类似的模式——常见位置包括工具目录、共享模块以及变更文件相邻的文件。
2. 标记任何重复现有功能的新函数。建议改用已有的函数。
3. 标记任何可以使用现有工具的内联逻辑——例如手写字符串处理、手动路径拼接、自定义环境检查、临时的类型守卫等常见模式。

代理 2：代码质量审查

审查同一批变更中的 hack 模式：

1. 冗余状态：与现有状态重复的状态、本可推导的缓存值、本可直接调用的观察者/副作用
2. 参数泛滥：向函数添加新参数，而不是泛化或重构现有参数
3. 复制粘贴的微小变体：应统一为共享抽象的近似重复代码块
4. 抽象泄漏：暴露了本该封装的内部细节，或破坏了现有的抽象边界
5. 字符串式编码：使用了原始字符串，而代码库中已存在常量、枚举（字符串联合）等

代理 3：效率审查

审查同一批变更的效率问题：

1. 不必要的工作：冗余计算、重复文件读取、重复的网络/API 调用、N+1 模式
2. 错失的并发：本可并行执行的独立操作却顺序执行
3. 热路径膨胀：在启动路径或每次请求/每次渲染的热路径中添加了新的阻塞工作
4. 周期性无更新操作：在轮询循环、时间间隔或事件处理程序中的无条件状态/存储更新——添加变更检测守卫，使下游消费者在无变化时不会收到通知。此外：如果包装函数接受更新器/归约器回调，需验证其是否遵从相同引用的返回（或“无变化”信号）——否则调用者的提前返回无操作会被静默破坏
5. 不必要的存在性检查：在操作前预先检查文件/资源是否存在（TOCTOU 反模式）——直接操作并处理错误
6. 内存问题：无界数据结构、缺失的清理、事件监听器泄漏
7. 过于宽泛的操作：读取整个文件而只需部分内容、加载所有项而只需过滤出其中一个

代理 4：孤岛代码、未删干净的兼容性旧代码审查

孤岛代码、未删干净的兼容性旧代码：从未被使用的代码。要么删除，要么找到需要用这段代码的地方并集成它。 我有强烈代码洁癖，不允许留任何旧代码旧文件。不允许通过注释等任何手段保留旧代码，不允许以兼容为理由保留旧代码，不允许未经允许的情况下乱加adapter或兼容层来保留旧代码。重构类任务的目标就是把旧代码完全替换掉，留下干净的新实现。

子代理的配置项必须如下：

run_in_background: false, model: haiku, isolation: 不要配置

等待所有四个代理完成。汇总它们的发现，并直接修复每个问题。如果某个发现是误报或不值得解决，记下并跳过——不要与发现争论，直接跳过。

完成后，简要总结修复了哪些内容（或确认代码已经是干净的）。最后生成提交信息，提交代码。

注意：

• 你被要求审查的文档可能没有上述这些问题，这种情况下你直接放行即可，你不一定必须修改文档内容。
• 不允许进入计划模式