pipeline

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pipeline

流水线

Value: Flow -- continuous, gated progression from slice to shipped code eliminates idle coordination overhead and makes quality evidence accumulate automatically.

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

Purpose

用途

Orchestrates the build phase end-to-end: takes vertical slices from the queue, dispatches TDD pairs, runs full-team code review before push, enforces mutation testing and CI gates, and merges or escalates. The pipeline controller handles all operational tasks (running tests, pushing code, managing git) so team member agents focus exclusively on creative work.

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

Practices

实践规范

Slice Queue Management

切片队列管理

The pipeline reads vertical slices from event model output and maintains their state in

.factory/slice-queue.json

. See

references/slice-queue.md

for the full queue schema and operations.

Each slice carries a

context

block with enriched metadata for downstream pipeline stages: boundary annotations on each GWT scenario (so the gate can verify boundary coverage), an event model source path (so the TDD pair can consult the original model), related slice IDs for cross-slice dependency tracking, domain types referenced by the slice (enabling pre-implementation type discovery), and UI components referenced (triggering conditional context gathering when the slice touches the interface layer).

Ordering strategy: Walking skeleton first (the thinnest end-to-end path), then by dependency graph (slices whose predecessors are complete), then by priority. The first slice in any project must always be a walking skeleton.

Slice states: pending, active, blocked, completed, escalated. Only one slice may be active at a time unless running at full autonomy level, where parallel slices operate in isolated git worktrees (one worktree per active slice at

.factory/worktrees/<slice-id>

). See

references/autonomy-levels.md

流水线从事件模型输出中读取垂直切片，并在

.factory/slice-queue.json

中维护其状态。完整的队列 schema 和操作说明请参考

references/slice-queue.md

。

每个切片都带有一个

context

块，包含用于下游流水线阶段的丰富元数据：每个GWT场景的边界注解（以便门禁验证边界覆盖情况）、事件模型源路径（以便TDD配对可以查阅原始模型）、用于跨切片依赖跟踪的相关切片ID、切片引用的领域类型（支持预实现类型发现）以及引用的UI组件（当切片涉及接口层时触发条件上下文收集）。

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

切片状态： 待处理、活跃、阻塞、已完成、已升级。除非运行在完全自主级别，否则同一时间只能有一个切片处于活跃状态；在完全自主级别下，并行切片在独立的git worktree中运行（每个活跃切片的worktree位于

.factory/worktrees/<slice-id>

）。请参考

references/autonomy-levels.md

。

Per-Slice Pipeline

单切片流水线

Each slice flows through a fixed sequence of stages. Every stage has a binary quality gate. A gate failure routes back for rework; it never skips forward.

Decompose -- Invoke
```
task-management
```
to break the slice into leaf tasks with acceptance criteria. Output: task tree in
```
.factory/audit-trail/slices/<slice-id>/decomposition.json
```
.
Implement -- Before dispatching the TDD pair, the pipeline gathers pre-implementation context: architecture docs, glossary, existing domain types matching the slice's referenced types, and event model context from the slice. If the slice touches UI, design system components are included. This context is passed to the TDD orchestrator as
```
project_references
```
and
```
slice_context
```
so every phase agent operates with full domain awareness. The TDD pair then works through red-green-domain-commit cycles without consensus rounds. No team discussion during implementation. Output: passing tests, committed code, cycle evidence in
```
.factory/audit-trail/slices/<slice-id>/tdd-cycles/
```
.
Review -- Before pushing, invoke
```
code-review
```
with the full team for three-stage mob review (spec compliance, code quality, domain integrity). All review findings must be addressed before proceeding. See
```
references/gate-definitions.md
```
for review gate criteria.
Address feedback -- Route review findings back to the TDD pair. The pair fixes via their existing ping-pong process. Re-review scoped to flagged concerns only (unless critical-category feedback).
Mutation test -- Invoke
```
mutation-testing
```
scoped to changed files. Required: 100% kill rate. Survivors route back to the TDD pair.
Push and CI -- Pipeline pushes the branch and waits for CI. On infra failures at standard or full autonomy, auto-retry once. On test failures, route to triage.
Merge or flag -- If all gates pass, merge (auto at full autonomy, manual otherwise). If any gate failed after exhausting rework budget, escalate to human.

每个切片都要经过固定的阶段序列。每个阶段都有一个二元质量门禁。门禁失败会返回重新处理，绝不会跳过后续阶段。

分解 —— 调用
```
task-management
```
将切片分解为带有验收标准的叶子任务。输出：任务树存储在
```
.factory/audit-trail/slices/<slice-id>/decomposition.json
```
中。
实现 —— 在调度TDD配对之前，流水线会收集预实现上下文：架构文档、术语表、与切片引用类型匹配的现有领域类型，以及来自切片的事件模型上下文。如果切片涉及UI，则包含设计系统组件。该上下文会作为
```
project_references
```
和
```
slice_context
```
传递给TDD编排器，以便每个阶段的Agent都能具备完整的领域认知。然后TDD配对通过红-绿-领域-提交循环进行工作，无需共识回合。实现期间不进行团队讨论。输出：通过的测试、已提交的代码、循环证据存储在
```
.factory/audit-trail/slices/<slice-id>/tdd-cycles/
```
中。
评审 —— 推送前，调用
```
code-review
```
让全团队进行三阶段群体评审（规范合规性、代码质量、领域完整性）。所有评审发现必须在推进前得到解决。评审门禁标准请参考
```
references/gate-definitions.md
```
。
处理反馈 —— 将评审发现返回给TDD配对。配对通过现有的乒乓流程进行修复。仅针对标记的问题重新评审（除非是严重类别的反馈）。
变异测试 —— 调用
```
mutation-testing
```
，范围限定为已更改的文件。要求：100%杀死率。存活的变异体返回给TDD配对。
推送与CI —— 流水线推送分支并等待CI结果。在标准或完全自主级别下，若出现基础设施故障，自动重试一次。若测试失败，则进入分类处理。
合并或标记 —— 如果所有门禁都通过，则合并（完全自主级别下自动合并，否则手动合并）。如果在耗尽重新处理预算后仍有门禁失败，则升级给人工处理。

Quality Gates

质量门禁

Five binary gates. Each requires structured evidence. See

references/gate-definitions.md

for full criteria, evidence schemas, and failure routing.

Gate	Pass Criteria	Failure Route
TDD	Acceptance test passes, all units pass, domain review approved	Back to tdd pair
Review	All three stages PASS	Back to tdd pair with findings
Mutation	100% kill rate on changed files	Back to tdd pair with survivors
CI	Pipeline green	ci-integration triage
Merge	All upstream gates pass, no blocking escalations, branch current	Rebase and re-gate

五个二元门禁。每个都需要结构化证据。完整的标准、证据schema和失败路由请参考

references/gate-definitions.md

。

门禁	通过标准	失败路由
TDD	验收测试通过、所有单元测试通过、领域评审通过	返回给TDD配对
评审	所有三个阶段均通过	携带评审发现返回给TDD配对
变异测试	已更改文件的杀死率达100%	携带存活变异体返回给TDD配对
CI	流水线执行成功	CI集成分类处理
合并	所有上游门禁通过、无阻塞升级、分支为最新状态	变基并重新执行门禁检查

Rework Protocol

重新处理协议

Gate failures route back to the appropriate skill. Each gate allows a maximum of 3 rework cycles per slice. After 3 failures at the same gate, the pipeline halts the slice, compiles full context (all attempts, all evidence), and escalates to the human. See

references/rework-protocol.md

for routing rules and tracking schema.

门禁失败会路由到相应的技能。每个门禁对每个切片最多允许3次重新处理循环。同一门禁失败3次后，流水线会暂停该切片，编译完整上下文（所有尝试、所有证据），并升级给人工处理。路由规则和跟踪schema请参考

references/rework-protocol.md

。

Progressive Autonomy

渐进式自主

The pipeline operates at one of three autonomy levels configured in

.factory/config.yaml

. See

references/autonomy-levels.md

for full details.

Conservative: All gates enforced, no auto-merge, human notified of every gate result, human approves every merge.
Standard: Auto-rework within budget, batch non-blocking findings, skip trivial review items, auto-retry CI on infra failures.
Full: Auto-merge when all gates pass, parallel slice execution using git worktree isolation (each active slice gets its own worktree; conflicts are detected at merge time), pair selection and slice ordering optimization. If
```
git worktree
```
is not available, the pipeline falls back to sequential execution and logs a warning.

流水线在

.factory/config.yaml

配置的三个自主级别之一运行。完整细节请参考

references/autonomy-levels.md

。

保守模式： 强制执行所有门禁，无自动合并，每个门禁结果都会通知人工，每次合并都需要人工批准。
标准模式： 在预算内自动重新处理，批量处理非阻塞发现，跳过琐碎的评审项，基础设施故障时自动重试CI。
完全模式： 所有门禁通过时自动合并，使用git worktree隔离实现并行切片执行（每个活跃切片都有自己的worktree；冲突在合并时检测），优化配对选择和切片排序。如果
```
git worktree
```
不可用，流水线会回退到顺序执行并记录警告。

Pipeline Operates Directly

流水线直接执行

Unlike the ensemble-team coordinator (which delegates everything), the pipeline controller directly executes operational tasks: running test suites, invoking mutation tools, pushing branches, checking CI status, managing git operations, updating queue state. Team member agents are invoked only for creative work: writing tests, writing code, conducting reviews.

与ensemble-team协调器（委托所有任务）不同，流水线控制器直接执行运营任务：运行测试套件、调用变异测试工具、推送分支、检查CI状态、管理git操作、更新队列状态。仅在需要创造性工作时调用团队成员Agent：编写测试、编写代码、进行评审。

Audit Trail

审计追踪

Every pipeline action produces structured evidence in

.factory/audit-trail/

. See

references/audit-trail-schema.md

for the directory layout and JSON schemas. The audit trail enables retrospectives, trend analysis, and reproducible escalation context.

流水线的每个操作都会在

.factory/audit-trail/

中生成结构化证据。目录布局和JSON schema请参考

references/audit-trail-schema.md

。审计追踪支持回顾分析、趋势分析以及可重现的升级上下文。

Enforcement Note

强制说明

The pipeline provides structural enforcement through gating: no stage proceeds without evidence from the prior stage, and gate failures mechanically route to rework. The pipeline cannot prevent an agent from producing low-quality work, but it can prevent low-quality work from reaching the main branch. Rework budgets and human escalation provide a safety net when automated gates are insufficient.

流水线通过门禁提供结构性强制：没有前一阶段的证据，后续阶段无法推进，门禁失败会自动路由到重新处理。流水线无法阻止Agent生成低质量工作，但可以防止低质量工作进入主分支。当自动门禁不足时，重新处理预算和人工升级提供了安全网。

Verification

验证

Dependencies

依赖

This skill requires other skills to function. It orchestrates them; it does not replace them.

tdd: Pair implementation engine. The pipeline dispatches TDD pairs and collects cycle evidence.
code-review: Three-stage review protocol. The pipeline invokes full-team review before every push.
mutation-testing: Quality gate for test effectiveness. The pipeline runs mutation testing scoped to changed files.
task-management: Work decomposition. The pipeline decomposes slices into leaf tasks before implementation.
ci-integration: CI pipeline monitoring. The pipeline pushes and waits for CI results.

Missing a dependency? Install with:

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

此技能需要其他技能才能运行。它仅进行编排，不替代这些技能。

tdd： 配对实现引擎。流水线调度TDD配对并收集循环证据。
code-review： 三阶段评审协议。流水线在每次推送前调用全团队评审。
mutation-testing： 测试有效性的质量门禁。流水线针对已更改文件运行变异测试。
task-management： 工作分解。流水线在实现前将切片分解为叶子任务。
ci-integration： CI流水线监控。流水线推送分支并等待CI结果。

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

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