tdd-engine

TDD引擎 (tdd-engine)

能力边界

• 能做: 指导orchestrator编排TDD三阶段子代理(RED/GREEN/REFACTOR)、light-dispatch/light-inline/standard 档位路由、prototype 主线程内联实现、同 sprint_group 独立任务并行调度、定义子代理prompt模板
• 不做: 需求分析、架构设计、文档生成、集成测试 / E2E 测试（由 testing skill 负责，本 skill 限单元测试粒度的 RED/GREEN/REFACTOR）

架构说明

orchestrator作为主线程Agent，在Phase 5逐任务执行时调用本skill。每个TDD阶段作为独立子代理启动，拥有独立上下文窗口，避免阶段间上下文污染。

orchestrator (主线程)
  ├─ 通过调度接口启动 → RED SubAgent (test-writer) — 独立上下文
  ├─ 收集RED产出 → 通过调度接口启动 → GREEN SubAgent (implementer) — 独立上下文
  ├─ implementer self-report `refactor_needed=true` 或 `tdd_refactor: required` → REFACTOR SubAgent (refactorer)
  └─ 汇总产出 → 更新dev-plan任务状态

四档执行模式（触发条件唯一定义在 §执行流程 任务路由分支）：

档	执行位置
standard	RED + GREEN + REFACTOR(条件) 三次 dispatch
light-dispatch	implementer 一次 dispatch（合并 RED+GREEN）
light-inline	orchestrator 主线程内联 implementer 行为，零子代理 boot
prototype-inline	同 light-inline，强制跳过 REFACTOR

Mid-Progress Drop Contract

避免子代理在末尾 finalize 集中产出导致 task-notification truncation（征兆：100+ tools / 100K+ tokens / 5min+ 被打断；<agent-result> 不返回但 artifact 已部分落地）。触发（任一命中）：loc_estimate > MID_PROGRESS_LOC（缺字段取 len(AC) × 30）或 len(tdd_acceptance) > 6。命中时 implementer dispatch prompt 强制注入：

Mid-progress 落盘：

1. 先 Write 全部目标文件的空骨架（import + export stub + describe(...) / 函数签名占位），按依赖序落盘——被导入文件先于引用它的文件（写盘纪律见 SUB-AGENT-PROTOCOLS §并行/多文件写盘纪律）
2. 逐 AC 迭代填充实现 + 测试
3. 每完成一条 AC 立刻运行 {test_command_fast}（按需附 file 过滤）验证
4. 禁止末尾一次 Edit 堆所有 AC 实现 + 全套断言

适用：standard Step 3 GREEN ✅；light-dispatch ✅；light-inline / prototype-inline ❌（主线程产出，token 由主线程窗口管理，不需此契约）。契约失效（仍 truncation）→ ORCHESTRATOR-RECOVERY-PROTOCOLS §Sub-Agent Truncation Recovery Protocol 主线程接管。

TDD 子代理共享约束

以下约束适用于所有 TDD 子代理，通过 AGENT.md 的 disallowedTools 和本节定义：

• 各 Step 的 dispatch 块：角色定义 / 返回格式 / 异常处理由对应 AGENT.md 经 subagent_type 自动加载，prompt 仅内联任务上下文，各 Step 不再重述
• AskUserQuestion 不可用。如需用户输入，返回 blocked 并在 <questions> 描述问题，orchestrator 以 continuation 重启
• 返回 <agent-result> 格式（详见 dispatch-prompt.md §COMMON-SECTIONS）
• blocked 时可追加 <questions> 字段