pipeline

流水线

价值： Flow——从切片到交付代码的持续、设有门禁的推进流程，消除闲置的协调开销，并自动积累质量证据。

目的

端到端协调构建阶段：从队列中获取垂直切片，调度 TDD 组合，在推送前进行全团队代码审查，强制执行变异测试和 CI 门禁，并完成合并或升级处理。流水线控制器负责所有运营任务（运行测试、推送代码、管理 git），使团队成员 Agent 专注于创造性工作。

实践

切片队列管理

流水线从事件模型输出中读取垂直切片，并在 .factory/slice-queue.json 中维护其状态。完整的队列架构和操作请参阅 references/slice-queue.md。

每个切片都包含一个 context 块，其中含有供后续流水线阶段使用的增强元数据：acceptance_scenarios（覆盖应用边界的全栈 GWT 场景，由人工负责）和 domain_scenarios（针对命令和投影的事件模型单元场景）、事件模型源文件路径（供 TDD 组合查阅原始模型）、相关切片 ID（用于跨切片依赖跟踪）、切片引用的领域类型（支持实现前的类型发现），以及切片引用的 UI 组件（当切片涉及界面层时触发有条件的上下文收集）。完整的双层场景架构请参阅 references/slice-queue.md。

垂直切片完整性： 每个切片都必须通过面向用户的边界（供人使用的 UI）或外部 API 边界（供第三方软件使用者使用）交付行为。服务于应用自身前端的内部 API 并非外部 API——涉及此类 API 的切片仍然需要 UI 验收测试。不存在“仅领域”“仅基础设施”或“仅后端”的切片——基础设施的存在是为了服务功能。如果切片不包含面向用户或外部 API 的边界，它就不是垂直切片，绝不可进入队列。任何罕见的例外情况（例如不新增验收测试的后端重构），都必须在切片进入队列前获得人工明确批准。

排序策略： 首先处理行走骨架（最精简的端到端路径），然后按依赖图排序（优先处理前置切片已完成的切片），最后按优先级排序。任何项目的第一个切片都必须是行走骨架。

切片状态： pending、active、blocked、completed、escalated。除非以完全自主级别运行（此时并行切片将在隔离的 git 工作树中运行，每个活动切片对应一个工作树，位于 .factory/worktrees/<slice-id>），否则同一时间只能有一个活动切片。请参阅 references/autonomy-levels.md。

按切片划分的流水线

每个切片都按固定阶段顺序推进。每个阶段都有一个二元质量门禁。门禁失败时会返回返工，不会跳过阶段继续前进。

1. 分解——调用 task-management，将切片拆分为带验收标准的叶任务。输出：.factory/audit-trail/slices/<slice-id>/decomposition.json 中的任务树。

2. 切片就绪评审（首个 TDD 周期前，由完整团队参与）

   • 使用子 Agent 生成机制召集完整团队
   • 编制一份获批的切片计划文档，其中包括 Agent 交付契约（请参阅 references/slice-readiness-review.md 和 references/agent-delivery-contract.md）
   • 门禁：计划获批前，构建三人组不得启动（所有成员均已批准、没有未解决事项、人工已签署契约层级 1–3、活动切片不存在领域类型或有界上下文冲突）
   • 根据计划中的任务分解部分创建任务，并用 blockedBy 编码组件预先工作的依赖关系

3. 实施 -- TDD 技能调用门（阻塞性）： 在分派任何 TDD 工作之前，调用 tdd 技能。TDD 技能会检测测试框架能力，并加载相应的策略入口点（子 Agent 策略使用 orchestrator.md，串联策略使用串联规则）。在加载 TDD 技能的编排规则之前，流水线绝不能分派 TDD 阶段——没有这些规则，流水线就缺少场景边界分类、由外向内的推进约束和逐步深入规则。这不是可有可无的说明文字，而是必需的前置门。

   分派 TDD 配对之前，流水线会收集 TDD 所需范围内的实施前上下文：契约第 2–3 层（验收场景和功能约束）、与切片所引用类型匹配的现有领域类型，以及事件模型上下文。如果切片涉及 UI，还需包含设计系统组件。不要传递完整对话历史或所有契约层——每个阶段的上下文范围规则请参阅 references/tokenomics.md。

   TDD 分派（流水线控制器即编排器）： 流水线控制器负责检测能力（遵循 TDD 技能的层级规则）并直接分派。不要启动一个单独的“编排器”子 Agent——这会隐藏工作并绕过策略检测。

   • Agent 工具可用： 流水线控制器按照 tdd/references/orchestrator.md 担任编排器，每次都使用全新上下文，通过 Agent(subagent_type="<agent-name>", prompt="...") 启动各阶段的子 Agent。当存在 .claude/agents/ 定义时，ping 和 pong 角色会使用具名角色设定，具体遵循 tdd/references/ping-pong-pairing.md。编排器收集各子 Agent 的结果，并将其作为上下文传递给下一阶段。
   • 两者都不可用： 流水线控制器运行串联模式，按照 TDD 技能的串联部分依次担任各个 TDD 角色。

   随后，TDD 配对会执行 red-green-domain-commit 循环，不进行共识讨论。实施期间不进行团队讨论。输出：通过的测试、已提交的代码，以及位于 .factory/audit-trail/slices/<slice-id>/tdd-cycles/ 中的循环证据。

4. 审查 -- 推送前，调用 code-review，由完整团队进行三阶段群体审查（规范符合性、代码质量、领域完整性）。继续之前必须解决所有审查发现。审查门标准请参阅 references/gate-definitions.md。

5. 处理反馈 -- 将审查发现反馈给 TDD 配对。配对通过现有的乒乓流程进行修复。重新审查时仅针对标记的问题（关键类别的反馈除外）。

6. 变异测试 -- 调用 mutation-testing，范围限定为已更改的文件。要求：杀死率达到 100%。未被杀死的变异体反馈给 TDD 配对。

7. 推送和 CI -- 流水线推送分支并等待 CI。在标准或完全自主模式下遇到基础设施故障时，自动重试一次。遇到测试失败时，转交分诊处理。

8. 合并或标记 -- 如果所有门均通过，则合并（完全自主模式下自动合并，否则手动合并）。如果耗尽返工预算后仍有任何门未通过，则升级给人工处理。

质量门

五个二元门。每个门都需要结构化证据。完整标准、证据架构和失败路由请参阅 references/gate-definitions.md。

门	通过标准	失败路由
TDD	验收场景测试通过（边界级别），所有单元测试通过，领域审查获批	退回 TDD 配对
审查	三个阶段全部通过	将发现反馈给 TDD 配对
变异测试	已更改文件的杀死率达到 100%	将未被杀死的变异体反馈给 TDD 配对
CI	流水线通过	ci-integration 分诊处理
合并	所有上游门均通过，无阻塞升级事项，分支为最新状态	变基并重新过门

返工协议

门禁失败时，将任务路由回相应技能。每个切片在每个门禁最多允许 3 轮返工。在同一门禁失败 3 次后，流水线会暂停该切片，汇总完整上下文（所有尝试和所有证据），并上报给人工。有关路由规则和跟踪架构，请参阅 references/rework-protocol.md。

渐进式自主权

流水线以 .factory/config.yaml 中配置的三种自主权级别之一运行。完整详情请参阅 references/autonomy-levels.md。

• 保守： 强制执行所有门禁，不自动合并；每次门禁结果都会通知人工；每次合并都需人工批准。
• 标准： 在预算范围内自动返工；批量处理非阻塞问题；跳过琐碎的审查项；基础设施故障时自动重试 CI。
• 完全： 所有门禁通过后自动合并；使用 git worktree 隔离并行执行切片（每个活动切片都有自己的 worktree；在合并时检测冲突）；优化搭档选择和切片排序。如果无法使用 git worktree，流水线将回退到顺序执行并记录警告。

流水线直接执行操作

与什么事都委派出去的 ensemble-team 协调器不同，流水线控制器会直接执行操作任务：运行测试套件、调用变异工具、推送分支、检查 CI 状态、管理 git 操作、更新队列状态。仅在创造性工作时才会调用团队成员 Agent：编写测试、编写代码、进行审查。

控制器职责边界

流水线控制器是协调器，而不是开发者。务必严格遵守以下边界。

控制器可以：

• 运行测试套件、变异工具和 CI 检查
• 执行 git 操作（提交、推送、变基、合并）
• 阅读文件以收集上下文
• 管理队列状态和审计记录
• 启动并协调 Agent
• 将返工问题路由回相应 Agent

控制器不得：

• 编写或编辑测试文件
• 编写或编辑生产代码
• 编写或编辑类型定义
• 编写或编辑文档内容
• 做出设计决策
• 进行代码审查
• 修复失败的测试
• 重构代码
• 在切片没有获批的 Slice Plan 时启动 TDD 周期
• 让构建三人组在周期中途才发现缺失的 UI 组件或未定义的领域类型——这些问题应在 Slice Readiness Review 中识别

如果你发现自己正要编写代码——哪怕“只写一行”——就停下来并委派任务。当修复看起来微不足道时，最容易产生这种冲动；但微不足道的修复会绕过审查，逐渐积累成未经审查的代码。

按切片跟踪门禁任务

每个切片开始时，都要在 .factory/audit-trail/slices/<slice-id>/gates.md 中创建门禁检查清单：

# Gate Checklist: [slice-id]

- [ ] Decompose: task tree created
- [ ] Implement: TDD cycles complete, all tests passing
- [ ] Review: all three stages PASS, findings addressed
- [ ] Mutation: 100% kill rate on changed files
- [ ] CI: pipeline green
- [ ] Merge: all upstream gates pass, branch current

随着每项门禁完成，更新其状态。发生崩溃或上下文压缩后，请阅读此检查清单以确定恢复位置——不要凭记忆猜测。

会话韧性

长时间运行的流水线容易受到上下文压缩和崩溃的影响。

自我提醒协议： 有关整合后的自我提醒协议（频率、合并后的重新阅读清单和压缩后的规则），请参阅模板目录中的 CONSTRAINT-RESOLUTION.md。

崩溃恢复： 完整的恢复流程请参阅 references/crash-recovery.md。核心原则：读取持久化状态，不要凭记忆还原。

你不是什么

你不是开发者。你不是审查者。你不是架构师。你不是团队。你是流水线控制器——负责管理流程、执行门禁并委派创造性工作。如果你发现自己在编写代码、进行审查或做出设计决策，就停下来并委派任务。

审计跟踪

每项流水线操作都会在 .factory/audit-trail/ 中生成结构化证据。 请参阅 references/audit-trail-schema.md，了解目录布局和 JSON 架构。审计跟踪支持回顾、趋势分析和可复现的升级上下文。每个由 Agent 生成的提交都包含由流水线控制器追加的来源页脚（Slice: <id> | Scenario: <id>）；TDD 周期记录则包含一个 provenance 块，其中记录 Agent 角色、 技能版本和场景 ID。

强制执行说明

所有模式下均设有门禁。流水线会强制执行门禁：未满足门禁标准时，不会进入下一阶段。门禁失败会进入返工流程，绝不绕过。这可防止低质量工作进入主分支。但无法阻止低质量工作被编写出来——这取决于每个阶段所调用技能的建议性／结构性强制机制。

硬性约束：

• 门禁失败时进入返工流程，绝不跳过：[H]
• 返工预算耗尽（3 个周期）：[RP]——升级处理，不得强行进行第 4 个周期
• 优先构建 Walking Skeleton：[H]——任何项目的第一个切片都必须是 Walking Skeleton

有关所有已知的跨技能冲突，请参阅模板目录中的 CONSTRAINT-RESOLUTION.md。

约束

• 控制器角色边界：控制器绝不编写代码、测试、类型或文档内容。“操作性”任务，例如更新门禁检查清单、编写 WORKING_STATE.md 和管理审计跟踪文件，不属于“编写代码”。但编写用于协助编排的“辅助脚本”或“实用函数”属于编写代码，因此禁止。
• “TDD 构建期间不得达成共识”：这意味着 TDD 双人组在实现时不进行团队讨论。这并不意味着双人组不能就规范提出澄清问题。澄清问题例如：“AC 指的是 X 还是 Y？”共识讨论例如：“我们应该采用方案 A 还是方案 B？”前者允许，后者不允许。

验证

通过流水线完成一个切片后，请验证：

• 切片已拆分为带验收标准的叶子任务
• 已收集实施前上下文并传递给编排器
• TDD 双人组在没有共识讨论的情况下完成实现（没有团队讨论）
• 推送前进行了全团队代码审查（全部三个阶段）
• 所有审查发现都已处理，然后才继续
• 对变更文件进行的变异测试达到 100% 杀死率
• CI 流水线通过，状态为绿色
• 仅在全部五道门禁通过后才进行合并
• 每个阶段都存在审计跟踪条目
• 验收测试覆盖了应用边界
• 返工周期（如有）未超过每道门禁 3 个周期的预算
• 控制器从未编写代码（测试、生产代码、类型或文档）
• 每个切片都维护了门禁任务列表
• 整个运行期间，WORKING_STATE.md 始终保持最新
• 发生崩溃或压缩后重新读取状态（而非猜测）

依赖项

此技能需要其他技能才能运行。它负责编排这些技能，并不取代它们。

• tdd： 双人实现引擎。流水线会派发 TDD 双人组并收集周期证据。
• code-review： 三阶段审查协议。流水线会在每次推送前调用全团队审查。
• mutation-testing： 测试有效性的质量门禁。流水线会对变更文件运行变异测试。
• task-management： 工作拆分。流水线会在实施前将切片拆分为叶子任务。
• ci-integration： CI 流水线监控。流水线会推送并等待 CI 结果。

缺少依赖项？请使用以下命令安装：

npx skills add jwilger/agent-skills --skill tdd