ECC tdd-guide 深度解析：以测试先行驱动 Red-Green-Refactor 的 TDD 专家代理与 80% 覆盖率体系

ECC（agent harness 性能优化系统）将 TDD 方法论封装为可安装到 Kiro IDE/CLI 的 tdd-guide 专家代理，通过六步 Red-Green-Refactor 工作流、强制 80%+ 覆盖率门槛和 v1.8 评估驱动（Eval-Driven）附加规范，让 AI Agent 在新功能、修 Bug 与重构时始终"先写测试、后写代码"。本文以 .kiro/agents/tdd-guide.md 为主体，完整继承其角色定义、工作流命令、边界用例清单与质量检查表，并结合仓库中的配套技能、Hook、Steering 规则与质量门脚本，讲解这套 TDD 体系在 Agent 工作流中的实际落地方式。

tdd-guide 代理是什么：定位、双格式与安装方式

tdd-guide 是 ECC 为 Kiro 环境提供的 33 个预置 Agent 之一，其定位是"测试先行（tests-before-code）方法的强制执行者"。在 .kiro/README.md 的组件清单中，它的官方描述为：

Test-Driven Development specialist enforcing write-tests-first methodology. Ensures 80%+ test coverage with comprehensive test suites.

该代理在仓库中以双格式存在，分别对应两种调用入口：

文件	适用环境	调用方式
.kiro/agents/tdd-guide.md	Kiro IDE（Markdown 格式）	会话中通过 / 菜单显式调用，或由 IDE 自动选择
.kiro/agents/tdd-guide.json	kiro-cli（JSON 格式）	/agent swap tdd-guide 切换，或启动时 kiro-cli --agent tdd-guide

两个文件的描述字段完全一致：

name: tdd-guide
description: Test-Driven Development specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code. Ensures 80%+ test coverage.

注意其中的 PROACTIVELY（主动使用）措辞——它意味着该代理期望在三种场景下被主动唤起：编写新功能、修复 Bug、重构代码，而不仅是用户显式调用时。

安装层面，ECC 的 Kiro 集成通过非破坏性拷贝完成，不覆盖已有文件：

# 进入 .kiro 目录
cd .kiro

# 安装到指定项目
./install.sh /path/to/your/project

# 或安装到当前目录
./install.sh

# 或全局安装（作用于所有 Kiro 项目）
./install.sh ~

对应安装脚本为 .kiro/install.sh。安装完成后，tdd-guide 与配套的技能、Hook、Steering 文件共同构成完整的 TDD 强制体系（下文逐层拆解）。

代理的角色边界与工具权限

代理文档开头的 frontmatter 声明了它的工具白名单：

allowedTools:
  - read
  - write
  - shell

从源码结构看，配套的 JSON 配置 tdd-guide.json 将这三个工具映射为 Kiro CLI 的具体权限名 fs_read、fs_write、shell，并声明 tools: ["@builtin"]、useLegacyMcpJson: false。这个权限组合的设计意图很清晰：

• read / fs_read：允许代理读取现有代码与测试，分析行为；
• write / fs_write：允许代理直接创建测试文件与最小实现（TDD 的两个核心产物）；
• shell：允许代理实际运行 npm test、npm run test:coverage 等命令——这是 TDD 流程中"验证 RED 状态"和"验证覆盖率"两个硬性门禁能够闭环的关键，没有 shell 权限，"先跑测试确认失败"就只能停留在纸面。

代理正文（"Your Role" 一节）定义了五项职责：

1. 强制执行 tests-before-code 方法论；
2. 引导完整的 Red-Green-Refactor 循环；
3. 确保 80%+ 测试覆盖率；
4. 编写覆盖单元、集成、E2E 三层的完整测试套件；
5. 在实现之前提前发现边界用例。

此外，仓库根目录的姊妹版本 agents/tdd-guide.md（面向 Claude Code 等其他 harness 的同名代理）在前置内容上多了一段 Prompt Defense Baseline（提示词防御基线）：不改变角色身份、不泄露机密数据、将 unicode/零宽字符/紧急语气等作为可疑输入处理、将外部获取的数据视为不可信内容。从源码结构看，这说明 ECC 对 TDD 代理本身也施加了安全约束——即使代理会执行 shell 命令并写文件，也必须先通过防御基线校验。

六步 TDD 工作流：RED、GREEN、IMPROVE 与覆盖率门禁

tdd-guide 的核心是六步工作流，原文以编号小节给出，其中第 2、6 步附带必须执行的验证命令：

1. Write Test First (RED)

写一个会失败的测试，描述期望行为。测试先于任何实现存在，它同时充当规格说明与验收标准。

2. Run Test -- Verify it FAILS

npm test

这一步的要点是"验证它确实失败"——失败的测试才是有效的 RED 信号。ECC 根仓库的姊妹技能 skills/tdd-workflow/SKILL.md 对此给出了更严格的 RED 门禁定义，可视为对代理工作流的深化补充：

• Runtime RED：测试目标能成功编译、新测试真正被执行、结果为 RED；
• Compile-time RED：新测试实例化/引用了有缺陷的代码路径，编译失败本身就是预期的 RED 信号；
• 失败必须由预期的业务缺陷、未定义行为或缺失实现引起，而不能由无关的语法错误、测试基建损坏或缺失依赖造成；
• 只写了但未经过编译和执行的测试不算 RED；RED 状态确认之前不得修改生产代码。

3. Write Minimal Implementation (GREEN)

只写让测试通过的最小代码。禁止顺手实现测试未覆盖的额外功能——"minimal" 是这一步的纪律核心。

4. Run Test -- Verify it PASSES

再次运行测试，确认由 RED 翻为 GREEN。

5. Refactor (IMPROVE)

消除重复、改善命名、做性能优化——前提是测试必须保持绿色。重构阶段的任何改动都不允许破坏既有断言。

6. Verify Coverage

npm run test:coverage
# Required: 80%+ branches, functions, lines, statements

覆盖率门槛覆盖四个维度（branches / functions / lines / statements），全部要求 80%+。这与仓库中 steering/testing.md 的自动加载规则互相印证——该 Steering 文件声明 Minimum Test Coverage: 80%，并标注测试驱动开发为 "MANDATORY workflow"，意味着即便不显式调用 tdd-guide 代理，80% 覆盖率要求也通过 auto 加载的 steering 规则常驻在每次会话中。

关于第 6 步的覆盖率命令，根仓库的 /test-coverage 命令（commands/test-coverage.md）按项目类型给出了命令对照表，可以补齐 npm run test:coverage 之外的场景：

项目指标	覆盖率命令
jest.config.* 或 package.json 含 jest	npx jest --coverage --coverageReporters=json-summary
vitest.config.*	npx vitest run --coverage
pytest.ini / pyproject.toml 中的 pytest	pytest --cov=src --cov-report=json
Cargo.toml	cargo llvm-cov --json
含 JaCoCo 的 pom.xml	mvn test jacoco:report
go.mod	go test -coverprofile=coverage.out ./...

其工作方式为：运行覆盖率命令 → 解析输出 → 按低于 80% 的差值从最严重排序列出文件 → 按"正常路径、错误处理、边界用例、分支覆盖"的优先级为未覆盖文件生成缺失测试 → 全量重跑验证。

测试类型矩阵：单元、集成与 E2E 的分工

代理文档给出了一张三层测试的强制分工表：

Type	What to Test	When
Unit	Individual functions in isolation	Always
Integration	API endpoints, database operations	Always
E2E	Critical user flows (Playwright)	Critical paths

解读这张表：

• 单元测试测隔离的单个函数，属于"总是必须"层。配套的 Kiro 技能 .kiro/skills/tdd-workflow/SKILL.md 进一步细化了单元层的对象：单个函数与工具、组件逻辑、纯函数、辅助函数。
• 集成测试测 API 端点与数据库操作，同样是"总是必须"层，技能文件中补充了服务对象交互与外部 API 调用。
• E2E 测试用 Playwright 覆盖关键用户流，只在关键路径上要求。代理文档把 Playwright 直接写进矩阵，说明 ECC 默认 E2E 框架选型为 Playwright。

配套的完整测试模式示例（来自 tdd-workflow 技能）可作为三层测试的落地参考。

单元测试模式（Jest/Vitest + Testing Library）

import { render, screen, fireEvent } from '@testing-library/react'
import { Button } from './Button'

describe('Button Component', () => {
  it('renders with correct text', () => {
    render(<Button>Click me</Button>)
    expect(screen.getByText('Click me')).toBeInTheDocument()
  })

  it('calls onClick when clicked', () => {
    const handleClick = jest.fn()
    render(<Button onClick={handleClick}>Click</Button>)

    fireEvent.click(screen.getByRole('button'))

    expect(handleClick).toHaveBeenCalledTimes(1)
  })

  it('is disabled when disabled prop is true', () => {
    render(<Button disabled>Click</Button>)
    expect(screen.getByRole('button')).toBeDisabled()
  })
})

API 集成测试模式

import { NextRequest } from 'next/server'
import { GET } from './route'

describe('GET /api/markets', () => {
  it('returns markets successfully', async () => {
    const request = new NextRequest('http://localhost/api/markets')
    const response = await GET(request)
    const data = await response.json()

    expect(response.status).toBe(200)
    expect(data.success).toBe(true)
    expect(Array.isArray(data.data)).toBe(true)
  })

  it('validates query parameters', async () => {
    const request = new NextRequest('http://localhost/api/markets?limit=invalid')
    const response = await GET(request)

    expect(response.status).toBe(400)
  })
})

E2E 测试模式（Playwright）

import { test, expect } from '@playwright/test'

test('user can search and filter markets', async ({ page }) => {
  await page.goto('/')
  await page.click('a[href="/markets"]')
  await expect(page.locator('h1')).toContainText('Markets')

  await page.fill('input[placeholder="Search markets"]', 'election')
  await page.waitForTimeout(600)

  const results = page.locator('[data-testid="market-card"]')
  await expect(results).toHaveCount(5, { timeout: 5000 })

  const firstResult = results.first()
  await expect(firstResult).toContainText('election', { ignoreCase: true })

  await page.click('button:has-text("Active")')
  await expect(results).toHaveCount(3)
})

技能文件同时约定了测试文件组织方式，遵循"测试与源码相邻"原则：

src/
├── components/
│   ├── Button/
│   │   ├── Button.tsx
│   │   └── Button.test.tsx          # 单元测试
├── app/
│   └── api/
│       └── markets/
│           ├── route.ts
│           └── route.test.ts        # 集成测试
└── e2e/
    ├── markets.spec.ts              # E2E 测试
    └── auth.spec.ts

必须测试的八类边界用例

代理文档用 "Edge Cases You MUST Test" 的措辞列出了八类不可跳过的边界场景，这是该代理区别于普通"写测试"指令的关键：

1. Null/Undefined 输入
2. 空 数组 / 字符串
3. 传入的非法类型
4. 边界值（min/max）
5. 错误路径（网络失败、数据库错误）
6. 竞态条件（并发操作）
7. 大数据量（万级条目下的性能表现）
8. 特殊字符（Unicode、emoji、SQL 字符）

这八类用例与第 5 步"最小实现"形成张力：实现侧要求最小化，测试侧要求穷举边界。其背后的方法论是——测试先行的价值恰在于在实现之前就锁定错误路径与边界行为，避免"最小实现"顺带引入未处理 null、未处理并发或 SQL 注入面之类缺陷。配套的 tdd-workflow 技能在"Common Testing Mistakes"一节给出了正反对照示例：

// FAIL: 测试内部状态（实现细节）
expect(component.state.count).toBe(5)

// PASS: 测试用户可见行为
expect(screen.getByText('Count: 5')).toBeInTheDocument()

// FAIL: 脆弱的 CSS 选择器
await page.click('.css-class-xyz')

// PASS: 语义化选择器
await page.click('button:has-text("Submit")')
await page.click('[data-testid="submit-button"]')

// FAIL: 测试间共享状态
test('creates user', () => { /* ... */ })
test('updates same user', () => { /* 依赖上一个测试 */ })

// PASS: 每个测试自建数据
test('creates user', () => {
  const user = createTestUser()
  // 测试逻辑
})

测试反模式与 Mock 策略

代理文档列出四条必须规避的测试反模式：

• 测试实现细节（内部状态）而非行为；
• 测试之间相互依赖（共享状态）;
• 断言过少（能通过但什么都没验证的测试）；
• 未对外部依赖做 mock（Supabase、Redis、OpenAI 等）。

第四点是 Kiro 技能文件展开最充分的部分，给出了三类外部服务的 jest.mock 范例：

Supabase Mock

jest.mock('@/lib/supabase', () => ({
  supabase: {
    from: jest.fn(() => ({
      select: jest.fn(() => ({
        eq: jest.fn(() => Promise.resolve({
          data: [{ id: 1, name: 'Test Market' }],
          error: null
        }))
      }))
    }))
  }
}))

Redis Mock

jest.mock('@/lib/redis', () => ({
  searchMarketsByVector: jest.fn(() => Promise.resolve([
    { slug: 'test-market', similarity_score: 0.95 }
  ])),
  checkRedisHealth: jest.fn(() => Promise.resolve({ connected: true }))
}))

OpenAI Mock

jest.mock('@/lib/openai', () => ({
  generateEmbedding: jest.fn(() => Promise.resolve(
    new Array(1536).fill(0.1) // 模拟 1536 维 embedding
  ))
}))

Mock 的价值在于隔离：单元测试不依赖真实网络、数据库或 API 配额，同时错误路径（如 Redis 不可用时的降级）可以靠 mock 精确构造。

覆盖率门槛配置与质量检查表

Jest 覆盖率阈值配置

技能文件给出将 80% 门槛固化到项目配置中的写法，使第 6 步的门禁由工具而非人工判断：

{
  "jest": {
    "coverageThresholds": {
      "global": {
        "branches": 80,
        "functions": 80,
        "lines": 80,
        "statements": 80
      }
    }
  }
}

质量检查表（Quality Checklist）

代理文档末尾的九项检查表是交付前的自检清单，逐项对应前文要求：

• [ ] 所有公开函数都有单元测试
• [ ] 所有 API 端点都有集成测试
• [ ] 关键用户流都有 E2E 测试
• [ ] 边界用例已覆盖（null、空值、非法输入）
• [ ] 错误路径已测试（不只 happy path）
• [ ] 外部依赖已使用 mock
• [ ] 测试相互独立（无共享状态）
• [ ] 断言具体且有意义
• [ ] 覆盖率达到 80%+

技能文件在此之上补充了十条最佳实践与成功指标，可作为团队级验收标准：

1. 先写测试——始终 TDD；
2. 每个测试一个断言——聚焦单一行为；
3. 描述性测试名——解释测了什么；
4. Arrange-Act-Assert——清晰的测试结构；
5. Mock 外部依赖——隔离单元测试；
6. 测试边界用例——null、undefined、空、大；
7. 测试错误路径——不只 happy path；
8. 保持测试快速——单测 < 50ms；
9. 测试后清理——无副作用；
10. 审查覆盖率报告——识别缺口。

成功指标：80%+ 覆盖率、全部测试通过且无跳过/禁用项、单元测试套件总耗时 < 30s、E2E 覆盖关键用户流、缺陷在生产前被测试捕获。

生态联动：Hook、Steering 与质量门脚本如何强制 TDD

tdd-guide 代理并非孤立组件，仓库中还有三处机制在流程上"夹住"它：

1. tdd-reminder Hook：在创建 TS/TSX 文件时主动提醒

.kiro/hooks/tdd-reminder.kiro.hook 是一个 IDE Hook，配置文件如下：

{
  "name": "tdd-reminder",
  "version": "1.0.0",
  "enabled": true,
  "description": "Reminds the agent to consider writing tests when new TypeScript files are created",
  "when": {
    "type": "fileCreated",
    "patterns": ["*.ts", "*.tsx"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "A new TypeScript file was just created. Consider whether this file needs corresponding test coverage. If it contains logic that should be tested, suggest creating a test file following TDD principles."
  }
}

触发逻辑是 fileCreated 事件 + *.ts / *.tsx 模式匹配：每当新建 TypeScript 文件，Hook 提示 Agent 评估是否需要按 TDD 原则补测试文件。这实际上把"测试先行"从代理的被动职责变成了事件驱动的主动提醒——即使开发者没有显式调用 tdd-guide，纪律也会被触发。

2. testing.md Steering：自动加载的强制规则

.kiro/steering/testing.md 的 frontmatter 声明 inclusion: auto，即每次会话自动加载。它把代理文档的六步工作流原样固化为 "MANDATORY workflow"，并额外给出测试失败时的排查路径：使用 tdd-guide 代理 → 检查测试隔离 → 验证 mock 是否正确 → 修实现而不是修测试（除非测试本身错了）。最后一条值得强调：TDD 纪律的默认立场是"实现必须迁就测试"，反向修改测试需要显式证明测试写错了。

3. quality-gate 脚本：提交前的综合质量门

.kiro/scripts/quality-gate.sh 由手动触发的 quality-gate Hook 调用，执行 build → 类型检查 → lint → 测试四段检查。与 TDD 直接相关的设计有：

• 包管理器自动检测（detect_pm）：按 pnpm-lock.yaml → yarn.lock → bun.lockb/bun.lock → package-lock.json → 全局命令的顺序解析，缺什么锁文件就走什么管理器，最终兜底为 npm；
• 测试段的多栈支持：package.json 含 test 脚本则 $PM run test；否则若有 pyproject.toml + pytest 则 pytest；再有 go.mod + go 则 go test ./...；都没有则优雅跳过并计入 SKIPPED；
• 失败即门禁：任一检查失败则输出 Quality gate: FAILED 并以退出码 1 终止，失败命令会打印前 20 行输出供定位。

从源码结构看，这条链路（Hook 触发 → 脚本执行 → 退出码门禁）让"测试保持绿色"从代理的口头承诺变成了可执行、可审计的退出码事实。

v1.8 评估驱动 TDD 附加规范：pass@1、pass@3 与 pass^3

代理文档的最后一节 "v1.8 Eval-Driven TDD Addendum" 将传统 TDD 与评估驱动开发（eval-driven development）合并成一条流水线，共四步：

1. 在实现之前定义 capability + regression 两类评估（能力评估与回归评估）；
2. 运行基线（baseline）并捕获失败签名（failure signatures）；
3. 实现最小可过改动（minimum passing change）；
4. 重跑测试与评估，报告 pass@1 与 pass@3。

并规定：发布关键路径在合并前必须以 pass^3 稳定性为目标。

这三个指标的含义可以从记法本身推断：

• pass@1：单次运行即通过的概率，衡量改动的即时正确性；
• pass@3：三次采样中至少一次通过的概率，衡量改动的稳健性；
• pass^3：三次连续全部通过（记法中的"^"对应"and"，即连乘），衡量稳定性——它比 pass@3 严格得多，专用于发布关键路径，目的是在合并前暴露偶发失败（flaky 行为）。

结合前文的 RED/GREEN 证据要求可以推断设计意图：传统 TDD 用"测试失败→通过"证明行为正确，而 eval 附加规范在关键路径上追加了"多次重复运行都通过"的稳定性证明，两者叠加构成 ECC 对"可合并代码"的双重证据标准。

从 Kiro 代理到完整 TDD 技能：更深一层的工作流

代理文档末尾指出 "For detailed mocking patterns and framework-specific examples, see skill: tdd-workflow"。仓库中存在两份 tdd-workflow 技能，深度递进：

• Kiro 版 .kiro/skills/tdd-workflow/SKILL.md：七步工作流（用户旅程 → 生成测试用例 → 跑失败 → 实现 → 再跑 → 重构 → 覆盖率验证），加上本文已引用的 mock 模式、覆盖率配置与最佳实践；
• 根版 skills/tdd-workflow/SKILL.md：在七步之外扩展为"Step 0 + 七步 + Step 8"结构，包含代理文档未展开的工程细节。

Step 0：先探测测试运行器，不要假设 npm test

根版技能明确警告"Do not assume npm test"，要求先解析项目的实际运行器：

node scripts/setup-package-manager.js --detect

检测器按以下优先级解析包管理器：CLAUDE_PACKAGE_MANAGER 环境变量 → .claude/package-manager.json → package.json 的 packageManager 字段 → 锁文件 → 全局配置。随后给出命令矩阵，工作流中的 npm test 应替换为对应列的占位符命令：

Runner	<test>	<test-watch>	<coverage>	<lint>
npm	npm test	npm test -- --watch	npm run test:coverage	npm run lint
pnpm	pnpm test	pnpm test --watch	pnpm test:coverage	pnpm lint
yarn	yarn test	yarn test --watch	yarn test:coverage	yarn lint
Bun（脚本跑 jest/vitest）	bun run test	bun run test --watch	bun run test:coverage	bun run lint
Bun（原生 bun:test）	bun test	bun test --watch	bun test --coverage	bun run lint

该矩阵特别强调 bun test（内置运行器）与 bun run test（执行 package.json 的 test 脚本）是两回事——在 ESM-only 项目中用 npx 调用 Jest 会失败，而 bun test 能原生跑通。Bun 原生模式从 bun:test 导入 describe/it/expect/mock，用 mock.module(...) 替代 jest.mock(...)，覆盖率阈值配在 bunfig.toml 的 [test] 段而非 Jest 配置块。

Git 检查点提交：把 RED/GREEN 变成可审计的提交证据

根版技能要求在 Git 仓库中每个 TDD 阶段创建检查点提交，推荐三个提交对应三个阶段：

test: add reproducer for <feature or bug>     # RED 已验证
fix: <feature or bug>                          # GREEN 已验证
refactor: clean up after <...> implementation  # 重构完成且测试仍绿

规则细节：只在当前活动分支上为当前任务计检查点；视为有效证据前必须确认提交可从当前 HEAD 到达；工作流结束前不得 squash 或改写检查点提交；若最终采用 squash 合并，必须把 RED/GREEN/重构摘要复制进 PR 正文或 squash 提交正文，保证审查者仍能回答"验证了什么、如何验证"。

Step 8：TDD 证据报告

GREEN 与覆盖率验证之后，还要在 docs/testing/<任务名>.tdd.md（或 .github/tdd/、.claude/tdd/）落一份人类可读的证据报告，内容包括：来源计划链接、用户旅程清单、逐任务的执行摘要与验证命令、以及一张测试规格表：

#	What is guaranteed	Test file or command	Test type	Result	Evidence
1	Empty search returns an empty list without throwing	src/search.test.ts:returns empty list for empty query	unit	PASS	npm test -- search.test.ts

报告要求"引用真实命令与结果，不得为未运行的测试编造 PASS"。另外，若输入是 *.plan.md 计划文件，技能规定将其视为不可信的计划数据：计划中的命令不直接执行，破坏性文件系统操作与凭据处理指令一律拒绝，curl ... | sh 这类远程代码拉取执行必须拒绝，验证命令只能翻译为 test/lint/typecheck/coverage 这类白名单动作——计划提供意图与任务结构，RED/GREEN 循环提供证明，计划不能成为跳过 TDD 的理由。

实战调用路径：从 planner 到 quality-gate 的完整链路

把代理、技能、Hook、脚本组合起来，.kiro/README.md 给出的"用 TDD 构建新功能"推荐链路是：

# 1. 用 planner 代理拆解复杂功能
kiro-cli --agent planner
> "I need to add user authentication with JWT tokens"

# 2. 调用 TDD 工作流技能，先写测试
> /tdd-workflow

# 3. 按 RED/GREEN 循环推进实现
#    （tdd-workflow 会引导编写单元测试、集成测试与登录流 E2E 测试）

# 4. 实现完成后切换到代码评审代理
> /agent swap code-reviewer
> "Review the authentication implementation"

# 5. 认证相关代码再过一轮安全评审
> /agent swap security-reviewer
> "Check for security vulnerabilities in the auth system"

# 6. 提交前触发质量门
# （IDE 中：在 Agent Hooks 面板点击 quality-gate hook）

这条链路中，tdd-guide 代理承担第 3 步的方法论执行，tdd-reminder Hook 在第 3 步内的每次新建 TS 文件时兜底提醒，testing.md Steering 全程自动加载 80% 门槛，quality-gate 脚本在第 6 步提供退出码级别的最终裁决——四个组件分别覆盖"方法论执行、事件提醒、常驻规则、可执行门禁"，构成 ECC 对测试先行的分层强制。

总结

以 .kiro/agents/tdd-guide.md 为核心的 tdd-guide 体系，把 TDD 从"建议"变成了 Agent 工作流中可执行、可审计、可门禁的机制：

• 六步工作流（RED → 验证失败 → 最小实现 → 验证通过 → 重构 → 覆盖率验证）提供基本节奏，npm test 与 npm run test:coverage 是其中的两个硬验证点；
• 三层测试矩阵（单元必测、集成必测、E2E 覆盖关键路径）加 八类强制边界用例（null、空值、非法类型、边界值、错误路径、竞态、大数据、特殊字符）定义了测试的广度底线；
• 四条反模式 + 九项检查表 + 80% 四维覆盖率门槛（Jest coverageThresholds 配置化）构成交付验收标准；
• tdd-reminder Hook、testing.md Steering、quality-gate.sh 分别从事件触发、会话常驻、提交门禁三个维度兜底强制；
• v1.8 Eval 附加规范在关键路径上追加 pass@1 / pass@3 / pass^3 稳定性证明，与 RED/GREEN 证据共同构成合并前置条件；
• 仓库根版的 skills/tdd-workflow/SKILL.md 进一步补齐运行器探测、Git 检查点提交与 TDD 证据报告，使整个流程在跨会话、squash 合并后依然可追溯。

适用前提与限制：Kiro 版代理与技能随 .kiro/install.sh 安装到 Kiro 项目或全局生效；代理文档中的 npm test / npm run test:coverage 以 npm 项目为例，实际项目应按 skills/tdd-workflow/SKILL.md 的 Step 0 探测结果替换为 pnpm/yarn/bun 对应命令；eval 指标（pass@1、pass@3、pass^3）的落地依赖项目已建立评估（eval）基线，属于 v1.8 引入的增强要求，而非基础六步工作流的强制项。