用途：dev-tdd 用于在实现功能或修复缺陷时强制执行测试驱动开发。它把任务重新定义为“先写证明功能可用的测试，再让测试通过”，测试本身是交付物。
主要能力：规定 RED-GREEN-REFACTOR 循环。RED 阶段先写会失败的测试并运行、看到失败输出；GREEN 阶段写最小实现让测试通过；REFACTOR 阶段在保持测试通过的前提下清理代码。要求所有代码使用基于文件的日志，例如 CLI 应用 ./app > /tmp/app.log 2>&1 &，测试运行器 pytest -v > /tmp/test.log 2>&1。运行 E2E 测试或截图前必须依次完成六道执行门：BUILD、LAUNCH（带文件日志）、WAIT、CHECK PROCESS、READ LOGS、VERIFY LOGS。面向用户的功能除单元测试外还要求 E2E 测试，覆盖 API、UI、CLI、用户工作流和视觉变更。
使用方式：在实现前先写测试，运行并确认失败，在 .planning/LEARNINGS.md 记录 RED；再写最小实现，运行并确认通过，记录 GREEN；最后重构并保持绿色。若先写了实现代码，必须删除后从测试重来。
适用场景：需要严格 TDD 的功能开发、缺陷修复回归测试，以及由 dev-implement、dev-debug 调用的实现与调试流程。
限制：资料未提供具体安装命令、收费方式、支持平台或性能数据；测试必须实际执行代码并验证运行时行为，grep、读日志和代码审查不算测试；模拟对象和直接函数调用只验证替身而非生产行为。