用途：recursive-tdd 用于 recursive-mode 第 3 阶段（实现）的所有编码工作，强制测试先行。核心原则是“没有先看到测试失败，就不知道测试是否测对了东西”，铁律为：没有失败测试就不写生产代码。
主要能力：覆盖新功能、缺陷修复、重构与行为变更；要求每个测试只验证一个行为、命名清晰、测试真实代码、断言明确。流程为 RED（写最小失败测试）→ 验证失败（必须执行，如 npm test path/to/test.test.ts，确认失败原因符合预期）→ GREEN（写刚好通过的最小代码，不加额外功能）→ 验证通过 → REFACTOR（去重、改名、提取辅助函数，保持测试通过，不新增行为）。
使用方式：在第 3 阶段工件中记录 TDD 模式、RED/GREEN 证据路径（如 /.recursive/run/<run-id>/evidence/logs/red/<file>.log 与 green 日志）、每个需求的测试、时间戳、命令与结果，并填写覆盖率门与审批门。若使用委派审查或路由实现，需先重读 /.recursive/config/recursive-router.json 与 recursive-router-discovered.json，按路由策略选择 CLI/模型。
适用场景：recursive-mode 第 3 阶段的实现、缺陷修复（先写回归测试复现）、重构与行为变更。
限制：不适用于“简单改动”“时间紧”“事后补测试”等借口；若严格 RED 先行确实不可行，只能走显式例外路径，声明 TDD Mode: pragmatic，记录具体原因与补偿验证证据，视为显式偏离而非静默捷径。出现测试前已写代码、测试立即通过、无法解释失败原因、测试 mock 行为、一个测试含多个行为等红旗时，应删除代码重新开始。资料未提供具体安装命令、收费与平台信息。