用途：以红-绿-重构循环进行测试驱动开发，适用于构建功能、修复 bug、集成测试或测试先行开发。
核心原则：测试应通过公共接口验证行为，而非实现细节。好测试是集成风格的，通过公共 API 走真实代码路径，读起来像规格说明，能在重构中存活；坏测试与实现耦合，mock 内部协作者、测试私有方法或绕过接口验证，重构时行为未变却失败。
反模式：不要先写所有测试再写所有实现（水平切片），这会产生测试想象行为、只测数据结构与签名、对真实变化不敏感的问题。正确做法是垂直切片：一个测试→一个实现→重复。
工作流：
- 规划：探索代码库时使用项目领域词汇表，尊重相关 ADR；写代码前与用户确认接口变更、要测试的行为（排优先级）、识别深层模块机会、为可测试性设计接口、列出行为而非实现步骤，并获取批准。不能测试一切，聚焦关键路径与复杂逻辑。
- 曳光弹：写一个测试确认系统的一件事，RED 失败，GREEN 用最少代码通过，证明路径端到端可行。
- 增量循环：对每个剩余行为，一次一个测试，只写当前测试通过所需最少代码，不预判未来测试，保持测试专注可观察行为。
- 重构：所有测试通过后，提取重复、深化模块、在自然处应用 SOLID、考虑新代码揭示的现有代码问题，每步后运行测试。永远不要在 RED 时重构，先达到 GREEN。
每周期检查：测试描述行为而非实现、仅用公共接口、能在内部重构中存活、代码对该测试最少、未添加投机性功能。
限制：资料未提供具体安装命令、平台支持、收费信息或代码示例；示例见 tests.md，mock 指南见 mocking.md。