TDD 绿灯：最小实现

红灯之后该写什么

TDD 的绿灯阶段不是「把功能做全」，而是让当前失败的那条测试在改动尽量小的前提下通过。很多团队在红灯刚变绿时就顺手改架构、加抽象或补边界，结果测试虽然绿了，但下一轮红灯又难定位——因为 diff 里混进了与断言无关的代码。

本技能把绿灯当成一条有边界的工程动作：先读失败断言，再写刚好满足测试的实现，并在注释或清单里记下「重构阶段再收」的捷径。

技能如何引导实现

资料用 Django 与 Express 两条线说明同一节奏：

• 第一刀：函数视图或路由内联逻辑，例如 product_list 直接 Product.objects.all() 并 JsonResponse，或 POST /api/users 里就地 push。
• 不在此阶段做的：类视图、ListView、中间件、userService / userController 分层——这些属于重构，应在测试全绿且行为稳定后再做。

操作步骤与 SKILL 一致：

1. 审查失败测试，找出最小修复面（只动失败行为涉及的路径）。
2. 实现能通过下一个测试的最小更改。
3. 每次更改后运行测试，确认进度而非「感觉对了」。
4. 记录重构阶段的捷径或技术债务（例如「列表页先用函数视图，后续再换 ListView」）。

更细的模式与示例见 resources/implementation-playbook.md。

适用边界与安全注意

适合：从红灯进入绿灯、需要刻意保持实现简单、测试驱动下的「先过再优」。

不适合：以设计或性能为目标的重构；测试已通过却要加新需求；需要完整架构重设计——这些应新开一轮 TDD 或单独的重构任务。

安全上两条硬约束：禁止为通过测试而绕过断言（假数据、跳过用例、改测试迁就实现）；禁止把改动扩散到与当前失败无关的模块。绿灯阶段的胜利标准是测试诚实通过，而不是 diff 看起来「更专业」。