寻找简化候选

把“帮我找可以简化的地方”变成有证据的候选清单：少而扎实，胜过一堆“看起来复杂”的猜测。默认只读，不修改代码；用户要求实施时再单独计划。

先读上下文

读 AGENTS.md 的 Implementation Principles 与 Boundary Rules，以及要审计的包对应的 docs/ 功能文档。先弄清哪些设计是有意保留的，再判断。

默认保护，不当作简化目标

codexhost 已发布，下面这些通常有兼容或语义负担，除非用户明确要求或有强证据，不提议删除：

• 按 Codex Desktop 版本区分的 Renderer 绑定和探测（版本化适配本身就是产品约束）。
• 各 Harness 的原生语义分别放在各自 Adapter 中，不因“看起来重复”而合并成统一抽象。
• harness-adapter 的公共插件契约、插件清单、mapping-store 的持久化格式与读取兼容路径。
• 对官方流量的原样转发路径。
• docs/archive/ 下的历史归档。

强候选

• 公共方法、事件、配置项、导出或辅助函数没有生产调用方，只被测试或文档引用，且所钉住的行为并非承重。
• 同一事实有两份互相镜像的表示。
• 接口里每个实现都必须提供、却没有任何消费者使用的方法。
• 为没有产品负责人的“以后可能需要”设计的通用性：未使用的选项、注册表、插件点。
• 只为保护一个未被使用的 API 而存在的校验、回滚路径或特例测试。
• 对同进程、已类型化的调用做的防御性拷贝、冻结、校验，且来源与所有权说明不了它存在的理由。
• 手写实现了成熟依赖或 Node 内置（在 engines 下限已有）已经提供的能力，替换后能删除实现及其专用测试。
• 行为略有差异，但新行为仍然合理、更易解释。

不是候选：只修一个笔误、未经调用方证明的“这里看起来复杂”、被有意保留的设计。

证明或驳回

对每个符号或行为，先分类调用方：

• 生产语料：packages/*/src、crates/*/src、scripts/release、装载与配置路径。
• 非生产语料：测试、文档、快照、fixtures、reference/、注释。
• 模糊语料：tools/ 下的 Gate、探测脚本，可能是产品烟测路径，先读用法再分类。

用 rg 搜精确符号、事件名、配置键、.name( 与 name( 两种形式、线协议字符串，再读调用点。LSP 或 TypeScript 工具可辅助，不能替代对动态名称、测试、文档和插件装载路径的理解。

驳回或降级：存在生产调用方（那是功能决策而非清理）；被已记录的设计或防御性理由保护且新证据不足以推翻；会引发无关改动却没有真正缩小公共 API；想法正确但很小（建议用带稳定标签的 TODO(tag) 即可）。

删除前再核对四件事：是否触及持久化数据或配置格式、是否是对外契约（插件、CLI、协议）、是否有 Codex Desktop 版本兼容原因、是否有跨平台原因。

输出

对每个候选给出：

1. 对象与位置（文件、符号）。
2. 调用方证据：生产与非生产分开列，附搜索方式。
3. 建议动作：删除、合并、降级或改用依赖，以及要同步清理的测试、文档、导出。
4. 放弃什么：最强的反对理由。
5. 风险与兼容性：持久化、公共契约、版本兼容。

最后列出被排除的“看似可简化”项及原因。是否落成 docs/ 提案由用户决定，不自动新建文档体系。