implementing

name	implementing
description	writing-plans 完成后激活。逐功能执行 TDD(RED→GREEN→REFACTOR) → subagent 8维审查 → 子功能全量测试 → 全部通过后全场景集成测试。Bug 修复走同流程。刚性技能。

此技能是刚性技能。每个功能必须走完整循环：TDD → 审查 → 子功能全量测试。 跳过任一环节 = 未经验证的代码进入主分支。

如果 writing-plans 已有拆分好的任务组，按任务组逐个执行。 如果是 Bug 修复（无 writing-plans），走 Bug 修复模式。

如果你在想"这个功能太简单了，快速过一下"——读 Red Flags。

Implementing：TDD → 审查 → 测试

技能类型：刚性

严格遵循。每个子功能走完整循环，全部通过后走全场景集成测试。不可跳过。

---

核心哲学

实现 ≠ 写完代码。实现 = 写完代码 + 证明它正确 + 证明它没有破坏其他功能。

一个子功能的完整循环：
  TDD(RED→GREEN→REFACTOR) → subagent 8维审查(P0/P1清零) → 子功能全量测试
                                                                      │
所有子功能通过后：                                                      │
  全场景集成测试（跨功能组合场景）────────────────────────────────────────┘

---

前置检查

#	检查项	说明
1	writing-plans 已产出任务清单？	每任务拆好 RED→GREEN→REFACTOR
2	brainstorming 已产出测试场景？	2 层 × 4 类场景（隔离/边界/并发/异常）
3	roadmap §4 已查阅？	确认无重复造轮子
4	L2 通用经验已搜索？	推荐 subagent 搜索

---

逐功能循环（每个任务组独立执行）

writing-plans 任务清单
       │
       ▼
┌─────────────────────────────────────────────┐
│ 对每个任务组 X：                              │
│                                             │
│ Step 1: TDD                                │
│   X-R  RED：先写测试 → 确认 FAIL             │
│   X-G  GREEN：最小实现 + L4 签名验证 → PASS   │
│   X-F  REFACTOR：清理 → 保持 PASS            │
│                                             │
│ Step 2: Subagent 8 维审查（并行派发）         │
│   → 汇总 → P0/P1 清零 → 记录于 roadmap §5    │
│                                             │
│ Step 3: 子功能全量测试（subagent 并行）        │
│   → 边界/null/并发/异常全覆盖                 │
│   → 全部通过 → 记录于 roadmap §5             │
│                                             │
│ 任一环节不通过 → 修复 → 从失败环节重来         │
└─────────────────────────────────────────────┘
       │
       ▼
所有任务组通过 → 全场景集成测试 → 进入 closing-the-loop

---

Step 1：TDD 循环

RED：先写测试

→ 从 brainstorming 测试场景加载（2 层 × 4 类）
→ 每类 ≥2 个测试方法，共 ≥8 个
→ 方法名表达意图：should_xxx_when_yyy
→ 运行测试 → 确认全部失败（红）
→ 如果某个测试直接通过 → 测试写错了
→ git commit -m "RED: {场景描述}"

GREEN：最小实现

→ 只写让当前测试通过的代码（YAGNI）
→ ★ L4 签名验证：Read 至少 3 个调用的关键方法，确认签名一致
→ 运行测试 → 确认全部通过（绿）
→ git commit -m "GREEN: {实现描述}"

L4 签名验证（必做）：

调用了 UserService.getById(Long id)？
→ Read UserService.java → 返回类型？异常声明？参数顺序？
→ LLM 凭记忆写的方法签名有 ~15% 的概率是错的。30 秒验证 > 30 分钟 debug。

REFACTOR：清理

→ 消除重复（DRY）、改善命名、提取常量
→ 每改一步运行一次测试（保持绿色）
→ git commit -m "REFACTOR: {清理描述}"

Bug 修复的 TDD 模式

bug 报告 → RED（写复现测试，确认失败）→ GREEN（应用修复，测试变绿）
→ 同类搜索（Grep 相同 bug 模式，一并修复）→ REFACTOR

---

Step 2：Subagent 8 维并行审查

TDD REFACTOR 提交后，立即派发 8 个只读审查子代理（并行）。

P0/P1 必须清零才能进入 Step 3。

严重度定义

级别	含义	示例	行动
P0 致命	安全漏洞、数据丢失、必现崩溃	SQL 注入、无条件 NPE、死锁	阻塞
P1 严重	逻辑错误、回归风险、边界缺失	用户A可访问用户B数据、事务边界错误	阻塞
P2 主要	模式偏离、重复代码、命名问题	未复用已有工具类、异常吞掉	应修复
P3 建议	更好的写法、可选优化	Stream 替代 for-loop	可选

8 个 Reviewer 并行派发

全部 8 个 reviewer 同时派发。使用 5 段式 prompt，只读。

#	Reviewer	关注点	严重度范围
1	正确性深挖	每条代码路径逻辑验证、条件覆盖、类型转换	P0-P3
2	空安全/边界	null 传播链、集合边界、数值溢出、字符串边界	P0-P2
3	安全审计	SQL 注入、越权、敏感数据泄露、输入校验	P0-P1
4	并发安全	竞态条件、线程安全、幂等性、锁顺序	P0-P1
5	错误处理	异常覆盖完整性、空 catch、降级、超时	P0-P2
6	性能/资源	N+1 查询、连接泄漏、不必要对象创建	P1-P3
7	回归风险	调用链影响、API 兼容性、数据库迁移	P1-P2
8	契约验证	API 签名/DTO 字段与设计大纲/roadmap §3 一致性	P1-P2

5 段式 Reviewer Prompt 模板

SCOPE: 本次改动的所有源文件（含新增和修改）

GOAL: {从上方 8 个 reviewer 中选择对应的 GOAL}

CONSTRAINTS:
  - 不信任方法名——打开被调用方法的源码验证实际行为
  - 每条问题引用具体文件:行号

DO NOT:
  - 不要修改代码（你是只读审查者）
  - 不要审查非本维度的内容
  - 不要提出"更好但不在审查范围内"的建议

RETURN:
  - 问题列表（文件:行号 + 具体问题 + P0/P1/P2/P3）
  - 无问题时返回："{维度}：通过"

主代理汇总

Step 1: 去重 → 同一问题被多个 reviewer 发现，合并为一条
Step 2: 排序 → P0 > P1 > P2 > P3
Step 3: 决策 → P0+P1 = 0 → 进入 Step 3（子功能全量测试）
              → P0+P1 > 0 → 实施修复 → 仅重审受影响维度（≤3 轮）
Step 4: 记录 → 审查摘要写入 roadmap §5

Review Loop（≤3 轮）

每轮只修 P0/P1，不趁机重构。仅重新派发受影响的 reviewer。第 3 轮仍有 P0/P1 → STOP，主代理介入决策。

---

Step 3：子功能全量测试

P0/P1 清零后，派发测试子代理并行覆盖 4 类场景：

并行派发 4 个测试子代理（Agent 工具）：

Test A — 边界条件:
  空参数、null、空列表、极大/极小值、超长字符串
  RETURN: 通过/失败 + 测试结果

Test B — 隔离/多用户:
  用户 A 的数据 ≠ 用户 B、不同角色的权限边界
  RETURN: 通过/失败 + 测试结果

Test C — 并发/竞态:
  同时操作冲突、重复提交、幂等性
  RETURN: 通过/失败 + 测试结果

Test D — 异常路径:
  依赖服务不可用、超时、非法参数
  RETURN: 通过/失败 + 测试结果

全部通过 → 此子功能完成，记录于 roadmap §5。任一失败 → 修复 → 重新派发该测试子代理。

---

全场景集成测试（所有子功能通过后）

跨功能组合场景测试（并行派发）：

Scenario 1: 完整业务流程（端到端）
Scenario 2: 多用户并发操作不同功能
Scenario 3: 功能间数据传递/状态变更链
Scenario 4: 异常场景组合（A功能失败→B功能降级）

全部场景通过 → 进入 closing-the-loop。

---

Bug 修复模式

当没有 writing-plans 产出时（Bug 修复），走此模式。

必须先走 brainstorming（工作流要求 brainstorming → implementing(Bug模式)）。brainstorming 已将 bug 分析 + 修复大纲写入 roadmap。如果 brainstorming 未执行，implementing 必须在写任何代码前完成以下 mini 版并记录 roadmap：

前置：确认 brainstorming 已完成（bug 分析 + 修复大纲已写入 roadmap §5）
  如未完成 → 先补 mini brainstorming：
    1. 澄清 bug 现象和影响范围
    2. 定位涉及的类/方法（git log 最近变更）
    3. 修复思路（1-3 句话）
    4. ★ 记录于 roadmap §5（日期 + bug 描述 + 涉及文件 + 修复思路）
       ↓ 完成后才能进入 RED

RED（复现测试，确认 bug 存在）
    → GREEN（最小修复，测试变绿）
    → REFACTOR（同类 bug 搜索，一并修复）
    → Subagent 审查（8 维，重点关注回归风险）
    → 子功能全量测试（4 类场景）
    → closing-the-loop

不先写复现测试 = 你不知道是"修好了"还是"恰好不报错了"。 不先写 roadmap = 下次别人遇到同类 bug 还是从零开始。

---

Subagent 使用原则

环节	工具权限	并行数	说明
TDD (RED/GREEN/REFACTOR)	全工具	1	主代理执行或派发 1 implementer
8 维审查	只读	8 并行	独立 reviewer，互不干扰
子功能全量测试	只读	4 并行	4 类场景各一个
全场景集成测试	只读	4 并行	跨功能场景

Git 操作（commit、分支管理等）推荐委派给 subagent 执行。主代理负责 roadmap 编写和架构决策。

---

测试反模式

反模式	正确做法
测试依赖外部服务	Mock 外部依赖
测试之间有顺序依赖	每个测试独立
方法名不表达意图	should_throw_when_email_is_empty()
只测 happy path	覆盖 null、空列表、极大值
为了覆盖率写测试	测试行为，不测试实现细节
写完代码再补测试	先写测试——RED 阶段的设计思考是 TDD 价值的一半

---

Red Flags — 你在跳过质量保证

你的想法	真相
"这个功能太简单，不需要审查"	简单代码也有边界 bug。简单 = 审查更快 = 没有借口。
"我自己审一下就行，不用 8 个 reviewer"	你审自己的代码有盲区。独立 reviewer 不带实现者的假设。
"改动太小，快速过一下"	一行改错花 2 小时排查。小改动也要 8 维审查。
"8 个 reviewer 太多了，3-4 个够了"	你跳过的那 4 个维度就是 bug 逃逸的通道。
"先写实现，测试后补"	后补的测试变成"验证实现"而非"验证行为"。TDD 一半价值在 RED 阶段。
"集成测试手动跑一下就行"	手动测试 = 这次测了下次忘。自动化后每次都能复现。
"reviewer 说有问题但我觉得还行"	不要否决 reviewer。独立判断覆盖了你的盲区。

---

完成标准

每个子功能完成时：

• TDD 三元组完成（RED→GREEN→REFACTOR，各一次 git commit）
• L4 签名验证完成（≥3 个关键方法签名与源码一致）
• 8 维审查完成（P0=0, P1=0）
• 子功能全量测试通过（4 类场景全覆盖）
• 审查结果和测试覆盖已记录 roadmap §5

全部子功能完成后：

• 全场景集成测试通过（4 个跨功能场景）
• 所有测试绿
• 进入 closing-the-loop