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