用途：当 RLM 需求涉及修复缺陷、排查测试失败或异常行为时，在 Phase 1（AS-IS）与 Phase 2（TO-BE 计划）之间插入 Phase 1.5，先做系统化根因分析，再进入修复计划。核心原则是“未先调查根因，不得动手修复”，症状式修复视为失败。
主要能力：按四步推进——根因调查（细读错误信息与堆栈、稳定复现、检查近期变更、多组件系统加诊断埋点、沿调用栈回溯数据流）、模式分析（找可用示例、完整阅读参考实现、逐项对比差异、理解依赖）、假设与验证（一次只提一个假设、做最小改动验证、失败则重新假设而非叠加修复）、修复总结（先写失败测试用例，再向 Phase 2 交接根因与修复思路）。
使用方式：触发场景包括测试失败、空输入崩溃、API 返回错误数据、性能与集成问题等。流程为锁定 Phase 1、创建状态为 DRAFT 的 01.5-root-cause.md、执行调试、找到根因后锁定该工件，再进入 Phase 3。工件路径为 /.codex/rlm/<run-id>/01.5-root-cause.md，内含错误分析、复现验证、近期变更、证据收集、数据流追踪、模式分析、假设测试、根因总结、可追溯性与覆盖/审批门。
适用场景：时间紧迫、看似“只需一处小改”、此前修复已失败、或尚未完全理解问题时尤其适用；简单问题也不应跳过。
限制：资料未提供具体安装命令、收费、平台支持或效果数据；若连续 3 次以上修复失败，应停下质疑架构而非继续修症状。