用途：在写任何测试代码前先做测试规划，确定测试边界并选出首个失败测试，作为 TDD 的 Red 起点。
主要能力与规则：按最直接表达业务目标的边界测试（集成/请求或单元）；覆盖全部主路径、输入边界值与预期错误流；明确首个在当前代码上失败的单一最简断言；测试须与外部网络、日期和共享数据库状态隔离。硬性门槛：未定义测试计划不得写用例；须从最相关边界开始；首个失败测试须在计划中明确；测试数据须为合成数据，不得使用真实生产值或 API 载荷。
使用步骤：1) 确定边界：请求/API 边界验证状态码、头部、查询解析或 JSON 结构；服务/业务边界验证领域不变量、复杂计算或对象协作；单元边界验证底层计算、单对象状态变化或格式化逻辑。2) 列出用例矩阵：正常路径、边界值（零、nil、空串、最大长度、负值）、错误路径（非法输入、数据库失败、外部超时、鉴权失败）。3) 从矩阵中选出当前代码预期失败的最简单用例，作为 Red 起点。4) 规划隔离：识别外部依赖（网络 API、系统时钟、文件系统），用 mock、stub 或测试替身避免不稳定失败。
检查点：向用户提出测试计划提案（目标边界、正常/边界/错误用例列表、首个失败测试），并在实现前先给出首个失败测试的骨架。示例特征为 POST /users，边界选请求/API，首个失败测试为验证 201 与响应含 id。样例使用 pytest + requests 或 Jest + supertest，骨架应直接运行并失败（Red），随后进入 tdd-process。
反模式：只测正常路径的覆盖盲区；为琐碎方法写大量单元测试却无集成覆盖；测试写入共享数据库或文件且不清理。
限制：该流程需要先应用执行契约；具体实现语言、运行环境及版本要求暂未提供。