用途：hai-tdd 用测试驱动开发（TDD）来推动真实的行为变更，而不是在实现完成后补测试。它要求先定义目标行为，再按红-绿-重构循环推进，并记录失败（RED）证据、最小实现（GREEN）与重构决策。
主要能力：
- 定义目标行为：选取一个最小行为切片，明确输入、输出、副作用、边界与失败条件。
- RED：先写失败测试，测试名描述行为而非“能工作”，一次只测一个行为，优先使用公共 API、用户可观察行为或稳定边界，避免不必要的 mock。
- 验证 RED：运行最小相关测试命令，确认失败原因是目标行为缺失，而非语法、导入、测试代码或环境问题。
- GREEN：只写刚好让当前测试通过的最小实现，不添加未来功能，不混入无关重构。
- 验证 GREEN：重跑相关测试，并按风险运行目录、模块或全量测试。
- REFACTOR：仅在绿色后重构，改善重复、命名、结构或边界，重构后重跑测试。
- 每个新行为都回到 RED，不把多个行为塞进一个大测试。
使用方式：按工作流逐步执行，并用 references/output-template.md 报告，逐项填写 RED / GREEN / REFACTOR 的真实证据，不要简化为“已测试、通过”。若不存在合法的 RED，使用模板中的“No Legitimate RED”路径。
适用场景：适合需要行为变更、稳定契约与可验证切片的开发工作。
限制与不适用：一次性原型或 spike、纯配置/文案/样式变更、暂时无法自动验证的行为、纯结构性变更（如删除字段、收窄接口、移动类型、重命名符号、移除导出辅助函数、变更包归属）不适合 TDD，应改用编译失败、现有测试、静态检查或事后测试验证。禁止制造假 RED，例如为一次性结构清理添加 AST/正则/反射扫描、检查源码的白盒守卫、重复编译器检查的测试，或针对重命名、包移动、别名、可见性变更的一次性守卫。架构/静态边界测试仅在边界是长期策略、能捕获未来回归且用户明确要求或仓库已有该模式时允许。若工作过宽，可先用 hai-goal 拆分为可验证阶段；涉及模块边界、抽象深度或依赖方向用 hai-architecture；判断功能是否值得做用 hai-idea；命名用 hai-naming。