用途：在实现非平凡、可观察的行为变更时，按 TDD 方式推进，并把测试当作可执行的行为规格，而不是覆盖率仪式。
主要能力：先界定边界，从仓库的清单、包配置、导入、运行器配置和既有路径中解析真实的生产与测试布局，仅在证据不足时套用对应生态的兜底方案，更具体的仓库说明优先。按可观察行为而非文件划分工作单元。仅当同时满足以下条件才对某单元应用 TDD：变更的是稳定边界上可观察的契约；聚焦测试能在实现前因预期原因失败；该测试能捕获更廉价验证难以清晰捕获的合理回归。配置、接线、schema、fixture 和生成产物等支撑性修改视为行为切片的一部分，不各自要求红绿循环。应测试自定义解析、默认值、校验、优先级或运行时行为，不要只重复静态配置值、标准框架声明或元数据。若不存在有意义的行为契约，跳过 TDD，改用最廉价且相称的检查：解析或 schema 校验、编译或类型检查、lint、聚焦冒烟检查、既有集成测试或仓库门禁。不要仅为让低风险声明式修改可单测而新增生产抽象。
使用方式（循环）：识别应改变的最小可观察行为；在稳定边界添加或更新最窄的测试来证明该行为，控制时间、随机性、网络、存储等外部输入以保证确定性与隔离；运行并确认目标测试执行且因预期原因失败，发现零测试不算红状态，若测试通过则修正或说明为何另一检查才是有效红状态；实现让测试通过的最小改动，不得削弱或删除正确测试；运行聚焦测试，再跑相关集成或端到端覆盖及仓库门禁；仅在测试全绿且不改变行为时重构。修 bug 时尽可能加回归测试；多路径变更按小步可观察增量重复循环，而非先写完整实现。
适用场景与限制：纯格式化、注释、保持行为的重命名、探索性 spike、纯视觉样式以及无自定义行为的声明式修改不在常规 TDD 边界内；需求过于不确定时也可能无法安全编码。当非平凡行为变更无法以失败测试起步时，需说明红状态为何不可行或不可得、改用何种方式验证行为、剩余风险是什么。结束时给出已证明的行为、可得的初始失败证据和通过的检查。不要仅因实现后才补测试就声称用了 TDD。