用途：在实现功能或修复缺陷时，按测试驱动开发流程推进，强制“没有失败测试就不写生产代码”。核心原则是：没亲眼看到测试失败，就不知道它是否测对了东西；开始时需声明“I'm using TDD to implement this feature.”。
主要能力：按 RED-GREEN-REFACTOR 循环执行。RED 阶段为单个行为写一个失败测试，并强制运行验证，例如 pnpm test --grep "rejects empty email"，确认测试失败且失败原因符合预期；GREEN 阶段只写让测试通过的最简代码，不添加未测试的错误处理、配置或优化；REFACTOR 阶段在保持绿色前提下清理重复、改进命名、抽取辅助函数。覆盖率目标为新代码 100%，可用 pnpm test --coverage 检查行、分支、函数、语句覆盖率；配置文件、纯类型定义、自动生成代码、第三方集成代码可例外，并需在 coverage 配置中说明。
使用方式：每完成一个行为就重复循环，完成功能前需核对清单：每个函数至少一个测试、实现前都看过测试失败、失败原因符合预期、写了最少代码、全部测试通过、新代码 100% 覆盖、无跳过测试、测试彼此隔离、覆盖错误路径。测试建议使用 Arrange-Act-Assert 结构，对时间、文件系统、网络、外部 API 等边界进行 mock，不要 mock 自己的内部实现。
集成测试要求：单元测试用 mock 是必要但不充分的，数据库模型、迁移、仓储/ORM、缓存、发布订阅、队列等变更还需针对真实服务测试，例如先 docker-compose up -d 启动服务，再运行集成测试并验证 pnpm migrate。文中提到曾因仅靠 mock 导致 ORM 迁移约 80% 失败率，mock 无法捕获 schema 不匹配、约束冲突、迁移失败、连接与事务行为等问题。
适用场景：需要严格回归防护、重构安全与行为验证的功能开发和缺陷修复。限制：资料未提供具体平台支持、安装命令、收费或价格信息；示例以 pnpm、jest、postgres 等为背景，实际适配需结合项目工具链。