# 测试驱动开发——多代理编排使用**单独的子代理**来执行测试编写和实施的严格的红-绿-重构周期。核心创新：**测试编写者永远不会看到实现代码，而实施者永远不会看到规范。**这可以防止法学硕士将实现意图泄漏到测试设计中。 ## 何时使用 * 用户请求 TDD、测试优先或红绿重构工作流程 * 用户说“/tdd”并附上功能描述或错误报告 * 用户想要添加一个从一开始就强制执行测试覆盖率的功能 * 用户想要通过首先编写重现测试来修复错误 ## 调用模式调用|行为 ---|--- `/tdd <功能>` |交互模式 - 在切片和每个红色检查点暂停审批 `/tdd --auto <功能>` |自主模式——运行所有切片而不暂停；仅在出现不可恢复的错误时停止 `/tdd --resume` |从项目根目录中的“.tdd-state.json”恢复 `/tdd --dry-run <功能>` |验证模式 — 完全运行阶段 0 + 阶段 1，呈现所有提示，但跳过 `Task()` 调用。没有写代码。在“--auto”模式下，跳过所有“[HUMAN CHECKPOINT]”步骤。改为打印状态行： [自动] 红色切片 1/4：“验证电子邮件格式”- 测试按预期失败 [自动] 绿色切片 1/4：通过（尝试 1） [自动] REFACTOR 切片 1/4：应用 1 个建议，跳过 0 个仅在以下情况下停止并询问用户： * 尝试5次后执行失败 * 3 次尝试后无法自动修复回归 * 脚本错误导致无法继续（缺少二进制文件、权限被拒绝等）在“--dry-run”模式下，验证整个编排管道，无需执行任何子代理或编写任何代码： 1. **第0阶段全面运行**：检测框架、验证基线、提取API、发现文档、创建状态文件 2. **第一阶段全面运行**：分解为切片（仍需要用户批准） 3. **对于每个切片**：使用实际变量呈现所有三个代理提示（测试编写者、实施者、重构者）。将呈现的提示打印给用户并包含字符数。 4. **不进行`Task()`调用**。没有编写测试文件。不生成任何实现代码。 5. **验证** ：检查所有模板变量是否解析（无“{UNRESOLVED}”占位符）、所有脚本执行时没有错误、状态文件格式正确。 6. **报告摘要**：试运行完成：{功能名称} 阶段 0：框架：{框架} 语言：{语言} 基线：{pass|greenfield} API 界面：{line count} 行文档上下文：{行数}行（或“无”）第一阶段：切片：{N}（{层细分}）呈现的提示：{N * 3}（已解析所有变量）测试编写器：{char count} 个字符实施者：{char count} 个字符重构者：{char count} 个字符状态文件：写入.tdd-state.json 没有修改任何代码。此模式适用于： * 验证脚本在项目环境中是否有效 * 在进行完整的 TDD 运行之前查看提示内容 * 测试技能变化无副作用 ## 架构概述管弦乐队（正在阅读此文件的你） ├─ 第 0 阶段：设置 — 检测框架、提取 API、创建状态文件 ├─ 第一阶段：分解为垂直切片→用户批准 │ ├─ 对于每片： │ ├─ 第 2 阶段（红色）：任务（测试编写器）← 仅限规范 + API │ ├─ 第 3 阶段（绿色）：任务（实施者）← 测试失败 + 仅错误 │ └─ 第四阶段（REFACTOR）：任务（Refactorer）←所有代码+绿色结果 │ └─ 总结 ### 上下文边界（关键约束）代理|看到 |没有看到 ---|---|--- **测试编写者** |切片规范、公共 API 签名、框架约定、层约束 |实现代码、其他切片、实现计划 **实施者** |失败的测试代码、测试失败输出、文件树、现有源、层约束 |原始规格、切片描述、未来计划 **重构者** |全部实施+全部测试+绿色结果，层层触及|原始规格、分解原理 ## 工作流程 ### 第 0 阶段：设置（每个会话一次） **第 1 步**：检测框架和测试运行程序。检查：package.json（jest/vitest）、pyproject.toml/pytest.ini（pytest）、 go.mod（go 测试）、Cargo.toml（货物测试）、Gemfile（rspec）、composer.json（phpunit）如果不明确，请询问：“什么命令运行您的测试？（例如，‘npm test’、‘pytest’）” **步骤 2**：从源文件中检测语言（用于代理提示）： TypeScript (.ts/.tsx)、JavaScript (.js/.jsx)、Python (.py)、Go (.go)、Rust (.rs)、Ruby (.rb)、PHP (.php) **步骤 3**：验证绿色基线。 bash ~/.claude/skills/tdd/scripts/run_tests.sh {FRAMEWORK}“{TEST_COMMAND}” 解析 JSON 输出。 * 如果 `status` 是 `"pass"`：继续。 * 如果 `status` 为 `"fail"`：stop — “现有测试失败。TDD 从绿色基线开始。” * 如果 `status` 为 `"error"` 并且 `total` 为 0：**绿地项目** — 尚不存在测试。这很好。继续。 **第 4 步**：提取公共 API 表面。 bash ~/.claude/skills/tdd/scripts/extract_api.sh {SOURCE_DIR} 保存输出 - 这是测试编写者将看到的内容。如果为空（绿地），这是预期的。 **第 5 步**：发现项目文档。 bash ~/.claude/skills/tdd/scripts/discover_docs.sh {PROJECT_ROOT} --lang {LANGUAGE} 这会搜索： * **文档文件**：README、ARCHITECTURE.md、docs/文件夹、DESIGN.md、SPEC 文件、ADR * **API 规范**：OpenAPI/Swagger、GraphQL 模式、.proto 文件 * **源文档字符串** ：JSDoc、Python 文档字符串、Go 文档注释、Rust `///` 注释将输出保存为“{DOC_CONTEXT}”。这会影响到： * **阶段 1** — 因此切片分解由记录的行为和 API 合约通知 * **阶段 2** — 因此测试编写者编写的测试与记录的意图一致，而不仅仅是代码签名如果为空（未找到文档），那很好 - 无需文档上下文即可继续。 **第6步**：在项目根目录中创建状态文件`.tdd-state.json`： { "feature": "用户的特征描述", "framework": "jest|vitest|pytest|go|cargo|rspec|phpunit", "语言": "typescript|javascript|python|go|rust|ruby|php", "test_command": "完整的测试命令", "source_dir": "src/", "doc_context": "discover_docs.sh 的输出（或空字符串）", “自动模式”：假， “干运行”：假， “切片”：[]， “当前切片”：0， “阶段”：“设置”， “图层图”：{}， “文件修改”：[]， “test_files_created”：[] } `slices` 数组中的每个切片都包含一个 `layer` 字段：`"domain"`、`"domain-service"`、`"application"` 或 `"infrastruction"`。有关如何分配层的信息，请参阅阶段 1。 `layer_map` 将目录前缀映射到图层。项目结构第一阶段建成： { “层图”：{ "src/domain/": "域", "src/services/": "域服务", "src/application/": "应用程序", "src/基础设施/": "基础设施", "src/adapters/": "基础设施", “src/controllers/”：“基础设施” } } 如果项目没有明确的目录层映射（平面结构），请将“layer_map”设置为“{}”并跳过基于路径的验证。 **步骤5a**（自动检测layer_map）：如果`layer_map`为空，则扫描源目录中常见的DDD/分层架构目录名称并自动填充：普通目录→图层映射（检查目录是否存在）： */域/→“域” */models/ →“领域”（ORM 模型通常充当领域实体） */实体/→“域” */value_objects/→“域” */services/→“应用程序”（除非明确基础设施） */应用程序/→“应用程序” */use_cases/→“应用程序” */核心/→“应用程序” */基础设施/→“基础设施” */适配器/→“基础设施” */controllers/→“基础设施” */api/→“基础设施” */bot/→“基础设施”（Telegram/Discord 机器人处理程序） */handlers/→“基础设施” */repositories/→“基础设施”（具体的回购实现）仅添加源树中实际存在的目录条目。如果匹配的目录少于 2 个，请将“layer_map”留空（平面项目）。将自动检测到的地图呈现给用户进行确认：从目录结构自动检测图层图： src/models/ → 域 src/services/ → 应用程序 src/core/ → 应用程序 src/bot/ → 基础设施 src/api/ → 基础设施这个映射看起来正确吗？（根据需要调整） **更新状态**：`“阶段”：“设置”`。立即写入状态文件。 ** ** ### 第 1 阶段：规范分解获取用户的功能请求并分解为**有序的垂直切片**。每个切片都是一个可测试的行为。 **使用文档上下文**：分解时，交叉引用阶段 0 步骤 5 中的“{DOC_CONTEXT}”。文档通常描述预期行为、边缘情况和应告知切片边界的 API 契约。如果文档提到特定的错误案例、验证规则或行为要求，请将它们视为切片候选者。 #### 由内而外的切片排序识别所有切片后，**按架构层将它们从里到外排序**。这确保每个切片都可以基于先前切片的真实（非模拟）实现来构建： 1. **领域模型**首先切片——纯逻辑，无依赖，无需模拟 2. **领域服务**切片——使用真实领域对象的跨聚合操作 3. **应用程序服务/用例**切片 - 使用内存中的伪造端口进行编排 4. **基础设施适配器** 最后切片 — 存储库、外部 API、框架适配器为每个切片分配一个“层”标签：“域”、“域服务”、“应用程序”或“基础设施”。使用“references/layer_guide.md”中的启发式进行分类。 **为什么是由内而外？** 域切片会生成稍后切片直接使用的真实对象。这可以最大限度地减少模拟并尽早发现集成问题。它还确保在做出任何基础设施决策之前实施和测试业务规则。对于所有代码都位于一层中的简单项目，所有切片都会获得 `layer: "application"` 并且顺序不会改变 - 指导会优雅地降级。 #### 切片排序中的边缘情况 **仅限基础设施的功能**（例如，“添加电子邮件提供商重试逻辑”、“从 Postgres 切换到 MySQL”）： * 如果某个功能没有域或应用程序行为更改，则所有切片都可能是“基础设施”。这是有效的——完全跳过内层。 * 呈现为：“这是纯粹的基础架构更改。所有切片都是基础架构层。” **缺少端口接口**（域服务需要一个尚不存在的端口）： * 需要端口的第一个切片应创建接口作为其实现的一部分。实施者可以在内层创建文件（域/域服务可以定义自己的端口）。 * 示例：“RegistrationService”的“domain-service”切片创建“domain/ports/UserRepository”接口作为 GREEN 的一部分。 **横切切片**（切片接触多个层）： * 标记其接触的最内层。实施者可以在该层和任何内层中创建文件。 * 示例：还引入新领域事件的用例被标记为“application”，但在“domain/events/”中创建一个文件。呈现给用户：我把它分成 N 个垂直切片（从内到外排序）：域名： 1. [行为]——[测试验证的内容] 领域服务： 2. [行为]——[测试验证的内容] 应用： 3. [行为]——[测试验证的内容] 基础设施： 4. [行为]——[测试验证的内容] 每个切片都遵循“红色”->“绿色”->“重构”，然后再移动到下一个切片。这个分解看起来正确吗？如果所有切片都落在一层中，则跳过层标题并显示为平面列表。 **等待用户批准**（即使在“--auto”模式下 - 切片分解始终需要签核）。 **更新状态** ：写入切片数组（每个切片都有`layer`字段），设置`"phase": "decomposed"`。 ** ** ### 试运行阶段覆盖（阶段 2–4）在 `--dry-run` 模式下，**将每个切片的第 2-4 阶段完全替换为以下内容： 1.刷新API表面（`extract_api.sh`） 2. 渲染 **测试编写器提示**，并填写所有变量。将其打印在“### 测试编写器提示（N 片）”标题下。 3. 使用占位符测试代码渲染 **Implementer 提示**：“{FAILING_TEST_CODE}”为“(dry-run: test code will be generated by Test Writer)”，“{TEST_FAILURE_OUTPUT}”为“(dry-run: no test output)”。 4. 使用占位符值渲染 **重构器提示**：“{GREEN_TEST_OUTPUT}”为“(dry-run: no green output)””，“{ALL_TEST_CODE}”为“(dry-run: code from Test Writer)””，“{ALL_IMPLMENTATION_CODE}”为“(dry-run: code from Implementer)”。 5. 对于每个呈现的提示，验证没有保留任何“{UNRESOLVED_VARIABLE}”模式（正则表达式：“\{[A-Z][A-Z_]+\}”）。将任何未解决的变量报告为错误。 6. 打印每个提示的字符数。 7. 移至下一个切片（无“Task()”调用、无文件写入、无测试运行）。处理完所有切片后，打印试运行摘要并退出。不要清理状态文件——这对于后续的“--resume”很有用。 ** ** ### 第 2 阶段：红色 — 编写一个失败的测试 **第 1 步**：刷新 API 表面（它随着切片的实现而变化）： bash ~/.claude/skills/tdd/scripts/extract_api.sh {SOURCE_DIR} **第 2 步**：从 `references/agent_prompts.md` -> “Test Writer Agent”部分阅读提示模板。通过填写以下内容来构建提示： * `{SLICE_SPEC}`: 当前切片的行为描述 * `{LANGUAGE}`：从阶段 0 检测到的语言 * `{FRAMEWORK}`: 检测到的框架名称 * `{API_SURFACE}`：extract_api.sh 的输出 * `{DOC_CONTEXT}`：discover_docs.sh 的输出（第 0 阶段第 5 步）。仅包含与当前切片相关的部分 - 如果完整输出很大，则按关键字匹配进行过滤。 * `{TEST_FILE_PATH}`：测试应该去哪里（遵循项目约定） * `{EXISTING_TEST_CONTENT}`：测试文件的当前内容（如果存在），或“尚不存在测试文件”。 * `{FRAMEWORK_SKELETON}`: 来自 `references/framework_configs.md` 的相关骨架 * `{LAYER}`：阶段 1 中切片的图层标签 * `{LAYER_TEST_CONSTRAINTS}`：特定于层的测试约束（请参阅agent_prompts.md ->特定于层的约束查找） **步骤 3**：启动测试编写器代理：任务（subagent_type =“通用”，提示= <构造的提示>） **步骤 4**：使用 `agent_prompts.md` 中的 `parse_agent_json` 逻辑解析 JSON 响应： 1. 剥离降价围栏（如果有） 2.尝试直接JSON解析 3. 如果失败，找到第一个“{”和最后一个“}”，尝试该子字符串 4. 如果仍然无效：重试任务调用一次并附加“仅返回 JSON 对象”。 5. 如果仍然失败：从原始响应中手动提取测试代码 **步骤5**：将测试代码写入测试文件。如果文件存在，则附加测试函数（并合并导入）。如果是新的，请使用代理的 `imports_needed` \+ `test_code` 创建。 **步骤 5a**（写入后测试气味扫描）：在运行之前扫描测试代码以查找常见气味：气味|检测|行动 ---|---|--- **断言轮盘赌** |同一测试函数中没有消息的多个裸“assert”语句 (3+) |警告用户（不要阻止）：“测试有 N 个裸断言 - 考虑添加失败消息以便于调试。” **未知测试** |测试名称是通用的：匹配 `test_1`、`test_it`、`test_works`、`test_example`、`test_thing` |重新启动测试编写器并附加：“使用读取为行为规范的描述性测试名称（例如，test_rejects_empty_email）。” **同义反复断言** | `assert True`、`当函数没有 None 返回路径时`断言结果不是 None`、`assert isinstance(result, X)` 作为唯一断言 |重新启动测试编写器并附加：“断言是同义反复 - 测试实际行为/值，而不仅仅是函数返回某些内容。” **步骤 5b**（写入后层 lint）：扫描测试代码以查找层违规模式：层 |测试代码中的禁止模式 ---|--- `域` | `jest.mock(`, `vi.mock(`, `Mock(`, `mock.patch`, `unittest.mock`, `gomock`, `mockery` - 域测试不得使用模拟库 `域服务` |域对象具有相同的模拟模式（模拟端口/存储库是可以的） `应用程序` |没有禁止的模式（预计会出现模拟端口） `基础设施` |没有禁止的图案如果发现禁止模式： 1. 从测试中删除有问题的模拟/模式 2. 重新启动测试编写器，并附加：“不要使用模拟库。这是一个 {LAYER} 层测试。使用真实的域对象。” 3. 如果第二次尝试仍然使用禁止模式，请询问用户 **第 6 步**：运行测试以确认其失败（预计是断言失败，而不是设置错误）： bash ~/.claude/skills/tdd/scripts/run_tests.sh {FRAMEWORK}“{TEST_COMMAND_FOR_SPECIFIC_TEST}” **步骤 7**：通过语义验证评估结果：结果 |行动 ---|--- `状态：“失败”`，断言错误 | **正确的红色** - 测试失败，因为预期的行为尚不存在。继续。 `状态：“失败”`、`ImportError` / `ModuleNotFoundError` | **设置问题，不是正确的红色。**测试甚至无法导入被测模块。修复：创建一个最小的存根（空类/函数），以便导入解析，然后重新运行。现在测试应该在断言上失败。 `状态：“失败”`，缺少方法时出现`AttributeError` |与导入错误类似 - 类存在但方法不存在。如果断言也失败，则这是可接受的红色。继续。 `状态：“通过”` |行为已经存在。日志：“测试通过 - 跳过切片（已实现）。”增加 `current_slice`，移至下一个切片。 `状态：“错误”`、`语法错误` |修复：测试有一个拼写错误。读取`raw_tail`，直接修复测试文件。重新运行。如果尝试修复 2 次后仍然出错，请询问用户。 `状态：“错误”`，编译/框架错误 |修复：导入错误、缺少固定装置或框架配置错误。读取`raw_tail`，直接修复测试文件。重新运行。如果尝试修复 2 次后仍然出错，请询问用户。 **第 8 步**（仅限交互模式 - 跳过 `--auto`）：呈现给用户：红色：测试已编写，但按预期失败。测试：{test_name} 文件：{测试文件路径} 失败：{来自 JSON 的失败消息} 此测试验证：{来自代理响应的test_description} 进入绿色阶段？（或者调整测试？） **在进入绿色之前等待用户批准。** **更新状态**：`"phase": "red"`，将测试文件添加到`test_files_created`。立即写入状态。 ** ** ### 第 3 阶段：绿色 — 最低限度实施 **步骤 1**：读取失败的测试文件和测试失败输出（红色阶段 run_tests.sh 结果中的完整“raw_tail”）。 **第2步**：构建源文件的文件树（不是测试文件，不是node_modules等）：查找 {SOURCE_DIR} -type f \( -name '*.ts' -o -name '*.js' -o -name '*.py' -o -name '*.go' -o -name '*.rs' -o -name '*.rb' -o -name '*.php' \) | grep -v 测试 | grep -v 规范 | grep -v 节点模块 | grep -v __pycache__ | | grep -v __pycache__ | grep -v 供应商 | grep -v 目标 | grep -v 距离 | grep -v 构建 |头-50 **步骤 3**：读取测试导入或引用的现有源文件。 **第 4 步**：从 `references/agent_prompts.md` -> "Implementer Agent" 部分阅读提示模板。填写： * `{LANGUAGE}`: 检测到的语言 * `{FAILING_TEST_CODE}`：完整的测试文件内容 * `{TEST_FAILURE_OUTPUT}`：run_tests.sh JSON 输出中的 `raw_tail` * `{FILE_TREE}`：步骤 2 中的源文件列表 * `{EXISTING_SOURCE}`：相关源文件的内容（如果有的话 - 对于绿地可能为空） * `{LAYER}`：阶段 1 中切片的图层标签 * `{LAYER_DEPENDENCY_CONSTRAINT}`：特定于层的依赖约束（请参阅agent_prompts.md ->特定于层的约束查找）重试时（尝试 > 1），还要填写“{?PREVIOUS_ATTEMPT}”部分： * `{PREVIOUS_ATTEMPT_DESCRIPTION}`：失败尝试的“解释”字段 * `{PREVIOUS_ATTEMPT_ERROR}`：尝试失败后测试运行中的`raw_tail` **关键**：请勿包含切片规范、功能描述或任何未来计划。实施者仅从测试开始工作。 **步骤 5**：启动实施者代理：任务（subagent_type =“通用”，提示= <构造的提示>） **第 6 步**：解析 JSON 响应。 **验证图层边界**，然后应用文件更改。 **步骤 6a** （图层路径验证）：如果 `layer_map` 不为空，则根据当前切片的图层检查响应中的每个文件路径：对于response.files中的每个文件： inferred_layer = 根据layer_map查找file.path（最长前缀匹配）如果 inferred_layer 存在并且 inferred_layer != current_slice.layer: 如果 inferred_layer 相对于 current_slice.layer 是 OUTER：拒绝：“实施者创建/修改了属于 {inferred_layer} 层，但这是一个 {current_slice.layer} 切片。内层不能依赖于外层。” → 重新启动带有附加约束的 Implementer： “请勿在 {inferred_layer} 目录中创建或修改文件。该切片仅限于 {current_slice.layer}。” 如果 inferred_layer 相对于 current_slice.layer 是 INNER：允许：外层可以接触内层文件（例如，添加端口接口） “外部”检查的层顺序：域 < 域服务 < 应用程序 < 基础设施。如果“layer_map”为空（平面项目），则跳过此验证。 **步骤 6b**：应用经过验证的文件更改：对于响应“files”数组中的每个文件： * 如果`action`是`"create"`或`"overwrite"`：使用写入工具创建或覆盖完整内容的文件 * 如果 `action` 是 `"edit"`（用于超过 200 行的现有文件）：使用编辑工具和 `old_string` → `new_string` 来应用更改。实施者仅返回已更改的函数及其周围的上下文 - 识别插入点或被替换的函数，并相应地使用编辑工具。如果编辑目标不明确，请回退到读取完整文件并使用 Write。 * 对于超过 200 行的现有文件，其中实施者无论如何都返回完整内容（操作 =“覆盖”），更喜欢使用编辑工具仅应用差异 - 这可以防止意外重新格式化未触及的代码 **第7步**：运行特定测试： bash ~/.claude/skills/tdd/scripts/run_tests.sh {FRAMEWORK}“{TEST_COMMAND_FOR_SPECIFIC_TEST}” **步骤 8**：重试循环（如果测试仍然失败）：尝试=1 最大尝试次数 = 5 先前的解释 = null 先前的错误 = null 而状态！=“通过”并且尝试<= max_attempts： previous_explanation = 上次实施者响应的解释 previous_error = 上次测试运行的 raw_tail 使用以下命令启动 FRESH 任务（实施者）： - 相同的测试代码+文件树+现有源（重新阅读！） - 新的故障输出 - PREVIOUS_ATTEMPT 部分已填写应用更改（每个文件的写入工具）重新运行测试尝试+= 1 如果在 max_attempts 次之后仍然失败：停止。呈现给用户： “5 次尝试后实施失败。最后一个错误：{raw_tail}” 问：“调整测试，尝试不同的方法，还是手动调试？” 每次重试都是一次 **新鲜** 任务调用，仅包含前一次尝试的解释和错误。这可以防止实施者陷入困境，同时为它提供足够的背景来尝试不同的策略。 **步骤 9**：特定测试通过后，运行完整测试套件： bash ~/.claude/skills/tdd/scripts/run_tests.sh {FRAMEWORK} "{FULL_TEST_COMMAND}" --all **步骤 10**：处理回归：结果 |行动 ---|--- 全部通过|继续进行重构发现回归 |自动修复：启动一个新的实施者并进行回归测试失败。申请。重新运行全套。重复最多 3 次。如果在 3 次回归修复尝试后仍然失败，请停止并呈现给用户。 **第 11 步**（仅限交互模式 - 跳过 `--auto`）：呈现给用户：绿色：以最少的实现即可通过测试。实施：{代理响应的说明} 已更改的文件：{list} 所有测试：{passed} 通过，{failed} 失败继续进入重构阶段吗？（或者调整？） **更新状态**：`"phase": "green"`，更新`files_modified`。立即写入状态。 **步骤 12**（仅限域/域服务切片）：REFACTOR 之前的层纯度检查：对于“domain”或“domain-service”层切片中的每个新/修改的文件： * **导入扫描** ：读取所有导入/要求语句。根据“layer_map”检查每个导入的模块。将来自外层的任何导入标记为违规。 * **构造函数检查** ：验证构造函数不接受从外层输入的参数（无 ORM 会话、HTTP 客户端、框架配置） * **静态调用检查** : 没有静态方法调用外层代码 * 如果发现违规，请在进入 REFACTOR 之前立即修复它们（将依赖项移至端口接口） **步骤 13**：完整存储库导入扫描（所有层，每个切片运行一次）：扫描所有源文件（不仅仅是会话修改的）以查找依赖方向违规： # 对于每个源文件，提取导入并检查 layer_map # 特定于语言的模式： # Python：从 X 导入 Y，导入 X # TypeScript/JS: import ... from 'X', require('X') # Go：导入“X” 对于每个文件： 1. 从`layer_map`中判断其所在图层（不匹配则跳过） 2. 对于每次导入，从`layer_map`确定导入模块的层 3. 如果导入的图层相对于文件图层是 OUTER → 违规在 REFACTOR 之前向用户报告违规行为：层扫描发现 N 个依赖方向违规： -domain/user.py 导入基础设施/db.py（域→基础设施） -domain/services/registration.py 导入adapters/email.py（域服务 → 基础设施）在 `--auto` 模式下：尝试自动修复（用端口接口替换具体导入）。在交互模式下：呈现违规行为并询问用户如何继续。这通过存储库范围的扫描补充了重构器的导入检查（仅查看会话文件）。静态工具会漏掉约 23% 的违规行为（Pruijt et al., 2017）——结合文本+结构检查可以提高覆盖率。 ** ** ### 第 4 阶段：重构 **第 1 步**：收集所有上下文： * 在此会话期间创建/修改的所有测试文件 * 在此会话期间修改的所有源文件 * 绿色测试输出 **第 2 步**：从 `references/agent_prompts.md` -> “Refactorer Agent” 部分阅读提示模板。填写： * `{LANGUAGE}`: 检测到的语言 * `{GREEN_TEST_OUTPUT}`：完整测试输出显示全绿色 * `{ALL_TEST_CODE}`：所有测试文件的内容 * `{ALL_IMPLMENTATION_CODE}`：所有修改过的源文件的内容 * `{SLICE_LAYERS}`：迄今为止完成的所有切片的唯一层的逗号分隔列表 **第 3 步**：启动 Refactorer 代理：任务（subagent_type =“通用”，提示= <构造的提示>） **第 4 步**：解析 JSON 响应。如果“建议”为空，请跳至步骤 6。应用建议**一次一个**，按优先级顺序（高优先）：对于每个建议： 1. 应用代码更改（编辑工具，对每个文件使用 `old_code` -> `new_code`） 2. 运行项目 linter/formatter 检查（从项目配置中检测）： * **Python** : `python -m black --check {文件} && python -m flake8 {文件} && python -m mypy {文件}` * **TypeScript/JS** ：`npx eslint {files}` 或 `npx tsc --noEmit` * **去** : `去兽医吧./...` * **Rust** ：`货物剪辑` * 如果 lint 失败 -> **立即恢复**并跳过此建议（与测试失败相同） 3. 运行完整的测试套件 4. 如果任何测试失败 -> **立即恢复**（重新读取编辑之前的文件并将其写回）并跳过此建议 5. 如果所有测试都通过且 lint 通过 -> 保留更改 **第 5 步**（仅限交互模式 - 跳过 `--auto`）：存在：重构：代码已改进，所有测试仍然通过。已应用：{已接受建议的列表} 跳过：{已恢复建议的列表，如果有的话} 所有测试：{count} 通过 [移动到 M 中的 N 个切片] 或 [所有切片完成] 在 `--auto` 模式下，打印一行： [自动] REFACTOR 切片 N/M：已应用 {applied_count}，已跳过 {skipped_count} **更新状态**：`“阶段”：“重构”`。立即写入状态。 ** ** ### 第 5 阶段：下一个切片或完整如果还有更多切片 -> 增加状态中的“current_slice”，返回到阶段 2。如果所有切片均已完成 -> 显示摘要： TDD 完成：{功能名称} 实施的切片：N 编写的测试：N 创建/修改的文件：{list} 所有测试均通过：是清理：删除 `.tdd-state.json` （在 `--auto` 模式下，静默删除；在交互模式下，询问用户）。 ** ** ## 恢复支持当用户调用“/tdd --resume”时： 1.从项目根目录读取`.tdd-state.json` 2. 报告当前状态：“找到‘{feature}’的 TDD 会话。当前位于切片 {N}/{total}，阶段：{phase}。” 3. 从当前切片的当前阶段继续 4. 如果`auto_mode`在state中为true，则继续在自动模式下 ** ** ## 边缘情况 ### 绿地项目没有源文件，没有测试，没有测试配置。优雅地处理： 1. **阶段 0 步骤 3** : 如果 run_tests.sh 返回 `status: "error"` 且 `total: 0`，请检查是否存在任何测试文件。如果没有，这就是未开发的领域——继续。 2. **阶段 0 步骤 4**：extract_api.sh 将返回空输出。将“（没有现有 API — 这是一个新项目）”传递给测试编写器。 3. **阶段 2**：测试编写者将从头开始创建测试文件。可能需要设置测试框架配置（例如“jest.config.js”、“pytest.ini”）。如果第一次测试运行因框架错误（不是测试失败）而失败，请创建最小框架配置并重试。 ### 错误修复 TDD 1. 编写一个测试来演示该错误（如果失败则表明该错误存在） 2. 确认失败与报告的错误相符——人工检查点 3.修复：使测试通过的最少代码（绿色阶段正常） 4. 验证：无回归 ### 现有代码（特性测试） 1. 为当前行为编写一个测试（应该通过——这是一个特征测试） 2. 修改所需行为的测试（应该失败） 3. 继续进行 GREEN -> 重构 ### 用户提供的测试如果用户提供测试代码： 1.运行确认失败（RED确认） 2. 跳到第 3 阶段（绿色）——用户提供的测试具有权威性 3.未经询问请勿修改 ### 不稳定的测试如果测试有时通过/失败：停止、报告、修复不稳定的测试，然后再继续。 ** ** ## 故障恢复参考失败|相|恢复 ---|---|--- 测试编写器返回无效的 JSON |红色|使用栅栏剥离+子字符串提取进行解析。使用“仅返回 JSON”重试一次。退回到手动提取。测试在应该失败的时候通过了 |红色|记录“已实施”，跳过切片，移至下一个。测试有语法/编译错误 |红色|读取raw_tail，直接修复测试文件。最多重试 2 次。然后询问用户。实施者返回无效的 JSON |绿色|与测试编写器相同的 JSON 恢复。实施后测试仍然失败 |绿色|重试循环：最多 5 个新的 Implementer 调用以及先前尝试的上下文。然后询问用户。全套有回归|绿色|自动修复：出现回归故障的新实施者。最多尝试 3 次。然后询问用户。重构者建议破坏了测试 |重构 |立即恢复，跳过建议，继续下一步。 run_tests.sh 超时 |任何 |增加超时时间。如果持续存在，请询问用户有关测试性能的信息。 run_tests.sh 返回 `"error"` |任何|阅读 raw_tail 来了解原因。脚本错误（缺少二进制文件、错误路径）-> 修复并重试。编译错误 -> 视为实现错误。 extract_api.sh 返回空 |红色|绿地正常。传递“（没有现有 API）”消息。代理回复完全是空的 |任何|重试任务调用一次。如果仍然为空，请询问用户。 ** ** ## 图层参考请参阅“references/layer_guide.md”了解层定义、依赖关系规则、按层测试策略和检测启发式。 ## 要避免的反模式请参阅“references/anti_patterns.md”。关键的： * 切勿修改测试以使其通过（更改实现，而不是测试） * 永远不要在测试之前编写实现 * 切勿一次编写所有测试（垂直切片） * 永远不要测试实现细节 * 切勿跳过红色阶段 * 永远不要让域代码导入基础设施（依赖方向违规） * 永远不要模拟领域对象——而是构造真实的实例 ** ** ## 框架快速参考有关设置详细信息，请参阅“references/framework_configs.md”。框架|运行单个测试 |运行全部|观看模式 ---|---|---|--- 开玩笑| `npx jest --testPathPattern=<文件> -t "<名称>"` | `npx 玩笑` | `npx 玩笑 --watch` 维泰斯特 | `npx vitest run <文件> -t "<名称>"` | `npx vitest 运行` | `npx 维测试` pytest | `pytest <文件>::<测试名称> -v` | `pytest -v` | `pytest-watch` 去 | `go test -run <测试名称> ./...` | `去测试./...` | — 货物| `货物测试 ` | `货物测试` | `cargo watch -x 测试` 规格| `rspec <文件>:<行>` | `rspec` | ‘守卫’ PHPUnit | `phpunit --filter <测试名称>` | `phpunit` | —

时差

包含技能