cowork-flow 2.3.0 → 2.4.1

package/template/.cowork-flow/spec/contracts/context-injection.md

@@ -289,7 +289,8 @@ Verify: npm run test:fast; python3 -m pytest tests/ -q
 - **Gates**: static preview text, identical on all hosts; the delegated
   variant replaces the self-declaration sentence with "scope is inherited
   from the parent task (read-only reference)".
-- **Verify**: `## 验证命令` lines from decision-anchor (first 10, 120 chars
+- **Verify**: `## Verification Commands`/`## 验证命令` lines from
+  decision-anchor (first 10, 120 chars
   each) — the agent's own declared self-checks; omitted when none.
 - **Per-edit warning**: PostToolUse on an edit tool injects at most one
   line when the edited file is outside the task's declared scope —
@@ -326,9 +327,9 @@ Verify: npm run test:fast; python3 -m pytest tests/ -q
   budget/limits come from `.cowork-flow/spec/runtime/scope-rules.json`, the
   single source consumed at runtime; a missing or malformed file degrades to
   embedded defaults that are byte-identical with the shipped file (locked by
-  `tests/test_scope_rules.py`). The file is template-managed
-  (`syncPolicy.safeFiles`): `cwf project sync` refreshes it, so local edits to
-  it do not survive a sync.
+  `tests/test_scope_rules.py`). The file is framework-managed: `cwf project
+  sync` refreshes it as part of the synced `spec/runtime/` tree, so local edits
+  to it do not survive a sync.
 - Absent for `no_task` / `planning` / `completed` states. Block content is
   byte-identical across host lines for the whole fixture matrix
   (`test/fixtures/stage-contract-matrix.json` drives the equality test:

package/template/.cowork-flow/spec/contracts/decision-anchor.md

@@ -8,8 +8,9 @@ the alternatives", which compresses the number of task artifacts.
 
 ## Schema
 
-These section names are literal: the runtime parser matches them exactly, so a
-translated heading would simply stop being read.
+These section names are machine-readable. The runtime parser accepts both the
+Chinese and English heading sets, and new anchors use the language configured in
+`.cowork-flow/config.yaml` (`zh-CN` is the default).
 
 ```markdown
 # Decision Anchor
@@ -38,14 +39,17 @@ translated heading would simply stop being read.
 
 ## Section requirements
 
+Both heading columns below are accepted; the left column is the `zh-CN` output
+and the right column the `en-US` output.
+
 | Section | Required | Why |
 |------|------|------|
-| `## 目标` | required | no goal, no acceptance baseline |
-| `## 验收标准` | required | `task_start` is blocked without acceptance criteria |
-| `## 被拒方案` | optional | required for brainstorming tasks, so a rejected option is not reconsidered during execution |
-| `## 关键假设` | optional | filled in for complex tasks to surface implicit constraints; not read by the runtime parser |
-| `## 范围边界` | optional | prevents scope creep |
-| `## 验证命令` | optional | filled in for complex tasks, as the basis for automated verification; when the changed files are covered by `.cowork-flow/spec/backend/` or `frontend/` rules, it must also carry the spec/gate check for the task's `dev_type` (deciding command, or clause-by-clause `pass` / `not_applicable` with reason) |
+| `## 目标` / `## Goal` | required | no goal, no acceptance baseline |
+| `## 验收标准` / `## Acceptance Criteria` | required | `task_start` is blocked without acceptance criteria |
+| `## 被拒方案` / `## Rejected Options` | optional | required for brainstorming tasks, so a rejected option is not reconsidered during execution |
+| `## 关键假设` / `## Key Assumptions` | optional | filled in for complex tasks to surface implicit constraints; not read by the runtime parser |
+| `## 范围边界` / `## Scope Boundary` | optional | prevents scope creep |
+| `## 验证命令` / `## Verification Commands` | required for strict non-Tiny; optional for legacy/Tiny | filled in for complex tasks, as the basis for automated verification; a strict non-Tiny task also needs the configured-language section and a filled spec/gate check for the task's `dev_type` (deciding command, or clause-by-clause `pass` / `not_applicable` with reason) |
 
 ### Machine-readable line formats (for injection)
 
@@ -55,11 +59,13 @@ fact view (`services/fact_view.parse_decision_anchor`). Line-format conventions:
 - `## 验证命令`: one command per line (an optional `- ` prefix), truncated to 120
   characters, at most 10 lines; the implementing agent runs them itself
   (self-declared, self-checked) and the reviewer verifies the execution evidence.
-  When the changed files are covered by `.cowork-flow/spec/<dev_type>/` rules, the
-  section must also carry the spec/gate check for the task's `dev_type`: a deciding
-  command, or a `规范核对:` line reviewed clause by clause (`pass` /
-  `not_applicable` + reason). This is a strong review reminder, not a `spec-check`
-  hard gate.
+  A strict non-Tiny task must also carry a `规范核对：` line in the configured
+  language's section, with the actual `pass` / `not_applicable` result and a
+  reason. The template placeholder (`<pass / not_applicable + 理由>`) does not
+  satisfy the start gate. This line is a hard start gate for strict non-Tiny
+  tasks, while its content remains self-declared and is reviewed by the check
+  agent. The fact view recognizes the line and does not return it as a shell
+  command.
 - `## 范围边界`: only the first non-empty line is taken, truncated to 160
   characters.
 
@@ -84,15 +90,24 @@ After merging (5 files): `decision-anchor.md` + `implement.jsonl` + `check.jsonl
 ## Lifecycle check coupling
 
 - The preflight for `task next <dir> --run` checks that `decision-anchor.md` is
-  non-empty and requires the `## 目标` and `## 验收标准` sections to be present.
+  non-empty and requires the `## 目标` / `## Goal` and `## 验收标准` /
+  `## Acceptance Criteria` sections to be present.
 - **Gate profile `meta.gateProfile`**: a newly created task is written as
   `"strict"`; an unmarked task is treated as `"legacy"` — existing tasks are not
   retro-fitted with the stricter gate, and the profile is queryable through the
   fact view. On top of the section check, a strict task additionally requires: at
-  least one parseable `- [ ] AC-xxx: ...` row in `## 验收标准`, no duplicate AC ids,
-  no non-AC list rows in that section, and a declared `dev_type` (otherwise
-  `task specs` dev-type dispatch silently comes back shorter).
-- A `## 验收标准` row's checkbox state (`- [ ]` / `- [x]`) and the evidence records
+  least one parseable `- [ ] AC-xxx: ...` row in `## 验收标准` /
+  `## Acceptance Criteria`, no duplicate AC ids, no non-AC list rows in that
+  section, and a declared `dev_type` (otherwise `task specs` dev-type dispatch
+  silently comes back shorter).
+- A strict non-Tiny task also requires the configured-language
+  `## 验证命令` / `## Verification Commands` section with a filled
+  `规范核对：` / `Spec check:` line. A missing section, the other-language
+  heading, or the template placeholder blocks start. Tiny tasks and legacy tasks
+  are exempt. The bound plan's `## 最终验证` / `## Final Verification` section
+  carries the same filled check; plan structure and language are covered by
+  `plan-binding.md`.
+- An acceptance row's checkbox state (`- [ ]` / `- [x]`) and the evidence records
   (the task directory's `evidence.jsonl`) are the fact source of the completion
   gate: completion is blocked when an unchecked AC exists (`LIFECYCLE-AC-001`), a
   declared AC has no evidence (`LIFECYCLE-AC-002`), a strict task cannot read any
@@ -149,4 +164,5 @@ source; if a task directory has only `prd.md` and no `decision-anchor.md`,
 `decision-anchor.md is missing or empty`.
 
 An existing legacy task needs a human to convert the `prd.md` content into
-`decision-anchor.md`, fill in `## 目标` and `## 验收标准`, and only then start.
+`decision-anchor.md`, fill in `## 目标` / `## Goal` and `## 验收标准` /
+`## Acceptance Criteria`, and only then start.

package/template/.cowork-flow/spec/contracts/plan-binding.md

@@ -48,11 +48,32 @@ into `in_progress`:
 - `task.json.meta.planFile` exists.
 - `planFile` is a repo-relative `.cowork-flow/plans/` path.
 - The plan file exists and is non-empty.
-- `decision-anchor.md` contains `## 目标` and `## 验收标准`.
+- `decision-anchor.md` contains `## Goal`/`## 目标` and
+  `## Acceptance Criteria`/`## 验收标准`.
 - `implement.jsonl` passes the existing context validation.
-
-A Tiny task may have no planFile, but must still satisfy the existing anchor and
-implement-scope requirements.
+- For a strict non-Tiny task, the plan title contains the configured-language
+  marker (`实施计划` / `Implementation Plan`).
+- The plan contains the six configured-language `##` template headings in
+  template order: `目标` / `验收标准` / `全局约束` / `文件边界` / `任务` /
+  `最终验证`, or their `en-US` equivalents. Extra custom sections are allowed;
+  fenced code is ignored; a known template heading from the other language is
+  rejected.
+- Any `### 任务` / `### Task` task heading uses the configured-language prefix.
+- `## 最终验证` / `## Final Verification` contains a line starting with
+  `规范核对：` / `Spec check:` and carrying an actual `pass` or
+  `not_applicable` result. The template placeholder (`<pass / not_applicable +
+  理由>` / `<pass / not_applicable + reason>`) does not satisfy the gate.
+- The strict non-Tiny anchor carries the configured-language `## 验证命令` /
+  `## Verification Commands` section with the same filled spec-check result;
+  see `decision-anchor.md`.
+
+Creation and `--from-plan` binding stay permissive: a planning task may create
+and bind a plan before its structure is final. These checks run only at the
+planning → `in_progress` start gate.
+
+A Tiny task may have no planFile and is exempt from the plan-shape and anchor
+spec-check gates. A legacy task (no `meta.gateProfile: "strict"`) keeps the
+historical checks; this contract does not retro-fit either profile.
 
 ## Implementation recovery
 
@@ -78,6 +99,8 @@ The recovery output lists paths only and never expands the plan prose.
 - No Markdown AST or DSL.
 - No comparing AC text against plan task prose.
 - No matching verification commands against evidence records.
+- No semantic validation of the spec-check result or reason; the structural
+  check only requires an actual `pass` / `not_applicable` token.
 - No plan-approval data model.
 
 These capabilities are considered only after warning noise and real payoff have been

package/template/.cowork-flow/spec/index.md

@@ -1,35 +1,35 @@
 # Cowork Flow Spec Index
 
-本目录只存放项目规范、运行时合同和运行时配置 schema。按职责分层：
+This directory holds project specs, runtime contracts, and runtime configuration schemas. Layers by responsibility:
 
-| 目录 | 作用 |
+| Directory | Purpose |
 | --- | --- |
-| `contracts/` | 人读的 workflow、宿主适配器和子代理协议合同。 |
-| `runtime/` | runtime 读取的机器配置，包括 contract registry 和 host asset manifest。 |
-| `schemas/` | runtime 配置和宿主合同的 JSON Schema。 |
-| `backend/` | 后端实现规范；由 review skill 按需读取并逐条审查。 |
-| `frontend/` | 前端实现规范；由 review skill 按需读取并逐条审查。 |
-| `guides/` | brainstorming/task-planning 阶段的编码前思考、跨层设计和复用判断指引。 |
-| `references/` | 按需参考材料（DoD、测试清单、安全清单、协作模式）；不自动加载。加载条件见 contract-registry.json 的 references 数组。 |
-
-流程内核只负责任务状态、文件范围、runtime context、归档一致性等可机器判断的事实。
-动作、阶段指导和专属运行时由各 Skill 的 `manifest.json` 声明；不维护集中式
-Skill registry。
-`backend/`、`frontend/` 中的自然语言规范不注册为 runtime gate；
-`task-review` skill 根据当前 diff 和任务范围读取并逐条审查。
-`guides/` 属于前置澄清与计划参考；选用后的结论应进入 `decision-anchor.md` 或任务计划。
+| `contracts/` | Human-readable contracts for the workflow, host adapters, and subagent protocol. |
+| `runtime/` | Machine configuration read by the runtime, including the contract registry and host asset manifest. |
+| `schemas/` | JSON Schemas for runtime configuration and host contracts. |
+| `backend/` | Backend implementation specs; the review skill reads them on demand and checks each clause. |
+| `frontend/` | Frontend implementation specs; the review skill reads them on demand and checks each clause. |
+| `guides/` | Pre-implementation thinking, cross-layer design, and reuse guidance for brainstorming/task-planning. |
+| `references/` | On-demand reference material (DoD, testing checklist, security checklist, orchestration patterns); never auto-loaded. Load conditions are in the `references` array of contract-registry.json. |
+
+Sync ownership: `contracts/`, `runtime/`, `schemas/`, and this file are framework-maintained and follow `cwf project sync`; `backend/`, `frontend/`, `guides/`, and `references/` are project-maintained, and `sync` never overwrites or deletes files there.
+
+The workflow kernel only owns machine-checkable facts: task state, file scope, runtime context, and archive consistency.
+Actions, stage guidance, and dedicated runtimes are declared by each Skill's `manifest.json`; there is no centralized Skill registry.
+Natural-language specs under `backend/` and `frontend/` are not registered as runtime gates; the `task-review` skill reads them according to the current diff and task scope and checks each clause.
+`guides/` is pre-implementation clarification and planning reference; selected conclusions belong in `decision-anchor.md` or the task plan.
 
 ## references/
 
-> 按需参考材料。**不在主会话中自动加载**——仅当 skill 入口或 agent 判断需要时读取。
+> On-demand reference material. **Never auto-loaded in the main session** — read only when a skill entry or agent judges it necessary.
 
-reference 文件之作用是：
-1. 为 skill 入口提供补充上下文（main skill 是入口，reference 是补充）
-2. 减少每次会话需加载的内容（spec/backend/ 等窄域规范只有实际需要时才加载）
-3. 在 planning、check 或 review 阶段提供快速对照清单
+Reference files:
+1. Provide supplemental context for skill entries (the main skill is the entry point; references supplement it).
+2. Reduce what each session must load (narrow-domain specs such as `spec/backend/` are read only when needed).
+3. Provide quick checklists during planning, check, or review.
 
-加载规则：
-- contract-registry 中 loadWhen 之一被匹配时读取
-- skill 正文中显式引用 reference ID 时读取
-- 用户在主会话请求特定检查时
-- **不**自动加载——这是与 contracts/ 系列的区别
+Loading rules:
+- Read when one of the `loadWhen` conditions in contract-registry matches.
+- Read when a skill body explicitly references a reference ID.
+- Read when the user requests a specific check in the main session.
+- **Never auto-loaded** — that is the difference from `contracts/`.

package/template/.cowork-flow/spec/references/definition-of-done.md

@@ -1,44 +1,44 @@
 # Definition of Done
 
-> 项目级完成门槛。每项变更在被视为"完成"前必须满足。与 per-task AC 互补但不替代。
+> Project-level completion gates. Every change must satisfy these before it is considered "done". They complement per-task ACs; they do not replace them.
 
-## 通用门槛（所有任务）
+## General gates (all tasks)
 
-| # | 检查项 | 验证 |
+| # | Check | Verification |
 |---|---|---|
-| G1 | 代码实现符合 decision-anchor acceptance criteria | AC 全部为 verified |
-| G2 | 行为变更有对应测试或明确验证命令；高风险任务覆盖失败、边界或回归路径 | `./.cowork-flow/run task next <dir> --validate` 与任务验证命令通过 |
-| G3 | check phase 完成，无 unresolved blocker | `task-review` 结论为 pass，completion lifecycle blocker 为 0 |
-| G4 | 无新引入 lint/type/build 警告 | lint / build 命令通过 |
-| G5 | Git status snapshot 仅含任务相关变更，包括 staged、unstaged、untracked | git status --porcelain=v1 -uall |
+| G1 | Implementation satisfies the decision-anchor acceptance criteria | All ACs are verified |
+| G2 | Behavior changes have corresponding tests or an explicit verification command; high-risk tasks cover failure, boundary, or regression paths | `./.cowork-flow/run task next <dir> --validate` and the task verification commands pass |
+| G3 | Check phase is complete with no unresolved blocker | `task-review` verdict is pass, and the completion lifecycle blocker count is 0 |
+| G4 | No newly introduced lint/type/build warnings | lint / build commands pass |
+| G5 | Git status snapshot contains only task-related changes, including staged, unstaged, and untracked | git status --porcelain=v1 -uall |
 
-## L0 专属（docs/format/comments only）
+## L0 only (docs/format/comments only)
 
-| # | 检查项 |
+| # | Check |
 |---|---|
-| L0-1 | 确认变更不涉及行为（docs/format/comments only）|
-| L0-2 | git diff --check 无空白错误 |
+| L0-1 | Change is confirmed non-behavioral (docs/format/comments only) |
+| L0-2 | `git diff --check` reports no whitespace errors |
 
-## L1 专属（单模块行为变更）
+## L1 only (single-module behavior change)
 
-| # | 检查项 |
+| # | Check |
 |---|---|
-| L1-1 | brainstorming 记录存在 |
-| L1-2 | 修改未扩散到无关模块（git diff 范围与 task.scope 一致）|
+| L1-1 | Brainstorming record exists |
+| L1-2 | Changes do not spread into unrelated modules (git diff range matches task.scope) |
 
-## L2 专属（跨层 / 架构 / 迁移）
+## L2 only (cross-layer / architecture / migration)
 
-| # | 检查项 |
+| # | Check |
 |---|---|
-| L2-1 | proposal.md / spec.md / design.md 齐全 |
-| L2-2 | 结构化决策审查已按 Skill 指导完成或明确记录不适用 |
-| L2-3 | readiness gate 全部通过（`task next <dir> --run` 无 blocker）|
-| L2-4 | spec-sync Skill 已确认规格同步或明确记录无需更新 |
+| L2-1 | proposal.md / spec.md / design.md are complete |
+| L2-2 | Structured decision review completed per Skill guidance, or explicitly recorded as not applicable |
+| L2-3 | All readiness gates pass (no blocker from `task next <dir> --run`) |
+| L2-4 | spec-sync Skill confirms spec synchronization, or explicitly records that no update is needed |
 
-## DoD 与 per-task AC 的区别
+## DoD vs per-task AC
 
 | DoD | AC |
 |---|---|
-| 项目级不变量——本次任务不例外 | decision-anchor 特有的完成条件 |
-| 来源：spec/references/definition-of-done | 来源：<task>/decision-anchor.md |
-| 两者都满足 = 任务真正完成 |
+| Project-level invariant — this task is no exception | Completion conditions specific to the decision-anchor |
+| Source: spec/references/definition-of-done | Source: <task>/decision-anchor.md |
+| Satisfying both = the task is truly complete |

package/template/.cowork-flow/spec/references/index.md

@@ -1,20 +1,20 @@
-# References — 按需加载参考材料
+# References — On-Demand Reference Material
 
-> **不自动加载。** 仅当 skill 入口显式引用 reference ID 时、或 agent 判断需要时读取。
+> **Never auto-loaded.** Read only when a skill entry explicitly references a reference ID, or when an agent judges it necessary.
 
-本目录存放窄适用范围的快速参考卡，作为 skill 入口的补充。相较 `spec/contracts/`（契约）和 `spec/backend|frontend/`（域规范），reference 文件之作用是：
-1. 在 check / finish 阶段提供快速对照清单（而非完整规范）
-2. 在分析潜在 prompt injection 时提供防御规则集
-3. 声明性总结 cowork-flow 已实现的协作模式
+This directory holds narrow-scope quick-reference cards that supplement skill entries. Compared with `spec/contracts/` (contracts) and `spec/backend|frontend/` (domain specs), reference files:
+1. Provide quick checklists during check / finish (not full specs).
+2. Provide defensive rule sets for analyzing potential prompt injection.
+3. Declare the collaboration patterns cowork-flow already implements.
 
-加载规则：
-- contract-registry.json 的 `references[*].loadWhen` 之一被匹配时
-- skill 正文中显式引用 reference ID 时
-- 用户在主会话请求特定检查时（如"security checklist"）
-- **不**自动加载——这是与 contracts/ 系列的区别
+Loading rules:
+- Read when one of `contract-registry.json`'s `references[*].loadWhen` conditions matches.
+- Read when a skill body explicitly references a reference ID.
+- Read when the user requests a specific check in the main session (for example, "security checklist").
+- **Never auto-loaded** — that is the difference from `contracts/`.
 
-当前参考：
-- [definition-of-done.md](definition-of-done.md) — DoD：项目级完成门槛（L0/L1/L2 三档）
-- [testing-checklist.md](testing-checklist.md) — 测试结构/深度/反模式快速参考
-- [security-checklist.md](security-checklist.md) — OWASP Top 10 映射 + 快速检查
-- [orchestration-patterns.md](orchestration-patterns.md) — 已实现的协作模式声明性目录
+Current references:
+- [definition-of-done.md](definition-of-done.md) — DoD: project-level completion gates (L0/L1/L2).
+- [testing-checklist.md](testing-checklist.md) — quick reference for test structure, depth, and anti-patterns.
+- [security-checklist.md](security-checklist.md) — OWASP Top 10 mapping plus a quick check.
+- [orchestration-patterns.md](orchestration-patterns.md) — declarative catalog of the collaboration patterns already implemented.

package/template/.cowork-flow/spec/references/orchestration-patterns.md

@@ -1,141 +1,141 @@
 # Orchestration Patterns
 
-> 已实现的协作模式声明性目录。
-> 本文件是 spec/contracts/ 系列的人可读摘要——权威定义以 spec/contracts/ 为准。
+> Declarative catalog of the collaboration patterns already implemented.
+> This file is a human-readable summary of the `spec/contracts/` series — the contracts are authoritative.
 
-## 核心原则
+## Core principle
 
-**主会话是唯一的协调者。固定子代理是叶子执行者。用户是流程的最终决策者。**
+**The main session is the only coordinator. Fixed subagents are leaf executors. The user is the final decision-maker.**
 
 ---
 
-## 模式 1：叶子执行器（已实现）
+## Pattern 1: Leaf executors (implemented)
 
 ```
-主会话 -> cowork-implement（实现）-> 返回 -> 主会话验证
-主会话 -> cowork-check（验证）     -> 返回 -> 主会话确认
-主会话 -> cowork-research（调研）  -> 返回 -> 主会话综合
+main session -> cowork-implement (implement) -> return -> main session verifies
+main session -> cowork-check (verify)        -> return -> main session confirms
+main session -> cowork-research (research)   -> return -> main session synthesizes
 ```
 
-**使用场景**: 计划声明了并行低冲突切片（文件所有权干净、各有独立验证）；需要上下文隔离的调研（cowork-research）；完成前必须的独立复核（cowork-check）。
+**When to use**: the plan declares parallel low-conflict slices (clean file ownership, independent verification); research that needs context isolation (cowork-research); the independent review required before completion (cowork-check).
 
-**约束**:
-- R-AG-001: 子代理不能派发其他子代理
-- R-AG-002: 子代理不修改 spec 文件
-- R-AG-003: 子代理不操作 Git
-- R-AG-004: 子代理不提交/归档
+**Constraints**:
+- R-AG-001: subagents must not dispatch other subagents
+- R-AG-002: subagents must not modify spec files
+- R-AG-003: subagents must not operate Git
+- R-AG-004: subagents must not commit/archive
 
-**验证**: dispatch 前用 `subagent init --role` 创建 runtime context；child 第一个动作必须是 `subagent bind`；parent 检查 `status: bound`。
+**Verification**: create the runtime context with `subagent init --role` before dispatch; the child's first action must be `subagent bind`; the parent checks `status: bound`.
 
 ---
 
-## 模式 2：并行扇出 + 合并（已实现，主会话管理）
+## Pattern 2: Parallel fan-out + merge (implemented, main-session managed)
 
 ```
-主会话 ─┬─> cowork-implement (task-slice-a) ─┐
-        ├─> cowork-implement (task-slice-b) ─┤─> 所有返回 ─> 集成验证 ─> 主会话综合
-        └─> cowork-research (background)    ─┘
+main session ─┬─> cowork-implement (task-slice-a) ─┐
+              ├─> cowork-implement (task-slice-b) ─┤─> all return ─> integrated verification ─> main session synthesizes
+              └─> cowork-research (background)    ─┘
 ```
 
-**使用场景**: 多个低耦合的实现切片可以并行。
+**When to use**: multiple low-coupling implementation slices can run in parallel.
 
-**验证清单**:
-1. 子任务之间无写冲突（不同文件或通过 git worktree 隔离）
-2. 每个子代理产出不同类型的发现
-3. 合并步骤在主 agent 的上下文窗口内可完成
-4. 用户等待时长足够使 parallel wall-clock 收益明显
-5. 收束为单次 cowork-check 复核与单次提交（回执指纹覆盖合并后的变更集）
-6. 同一工作树不能并行两个任务（文件范围门禁读取工作树全量变更）；跨任务并行使用独立 worktree/clone 并经看板依赖边协调
+**Verification checklist**:
+1. No write conflicts between subtasks (different files or isolated through git worktree)
+2. Each subagent produces a different type of finding
+3. The merge step fits within the main agent's context window
+4. The user's wait is long enough for parallel wall-clock gains to matter
+5. Converge on a single cowork-check review and a single commit (the receipt fingerprint covers the merged change set)
+6. Two tasks cannot run in parallel in one worktree (the file-scope gate reads the whole working tree); cross-task parallelism uses separate worktrees/clones and coordinates through board dependency edges
 
-任一答案为否 → 回退为模式 1 顺序执行。
+If any answer is no, fall back to Pattern 1 sequential execution.
 
 ---
 
-## 模式 3：顺序 skill 链（已实现，用户驱动）
+## Pattern 3: Sequential skill chain (implemented, user-driven)
 
 ```
-用户执行: task next --run --title ... -> brainstorming -> task-planning -> task next <dir> --run -> implement -> check -> task next <dir> --run --intent review
+User runs: task next --run --title ... -> brainstorming -> task-planning -> task next <dir> --run -> implement -> check -> task next <dir> --run --intent review
 ```
 
-**使用场景**: 阶段之间有依赖关系，用户在阶段间判断有价值。
+**When to use**: stages depend on each other, and user judgment between stages is valuable.
 
-**为什么不做生命周期编排 agent**:
-- 编排 agent 会在 hand-off 间总结→丢失细微差异
-- 用户在阶段间的检查点能早期发现方向错误
-- 人工检查的成本 < 走错方向的返工成本
+**Why there is no lifecycle-orchestration agent**:
+- An orchestration agent summarizes between hand-offs, losing nuance
+- User checkpoints between stages catch wrong directions early
+- The cost of a human check is lower than the rework cost of going the wrong way
 
 ---
 
-## 模式 4：Party Mode V2 Board（已实现，咨询性质）
+## Pattern 4: Party Mode V2 Board (implemented, advisory)
 
 ```
-主会话 ─> 启动 Discussion（party-v2 runtime board）
-       ─> 子代理通过 board 交流（不直接对话）
-       ─> 主持人监控漂移，不参与决策
-       ─> 产出建议，不改变任务状态
+main session ─> start Discussion (party-v2 runtime board)
+              ─> subagents communicate through the board (never directly)
+              ─> moderator monitors drift and does not decide
+              ─> produces advice and does not change task state
 ```
 
-**约束**:
-- Board 不能推进任务状态
-- 不能替代 Implement/Check formal gates
-- 主持人不能转述、总结、合成子代理意见
+**Constraints**:
+- The board cannot advance task state
+- It cannot replace the Implement/Check formal gates
+- The moderator must not relay, summarize, or synthesize subagent opinions
 
 ---
 
-## 反模式 A：路由人格（禁止）
+## Anti-pattern A: Router persona (forbidden)
 
 ```
-/workflow -> 代理人格("需要什么角色?") -> 子人格 -> 代理人格(重述) -> 用户
+/workflow -> agent persona ("what role do you need?") -> sub-persona -> agent persona (restates) -> user
 ```
 
-**为什么不行**: 纯路由层没有领域价值; 两次重述→信息丢失+~2x token; AGENTS.md 的 workflow-state 路由已覆盖
+**Why not**: a pure routing layer has no domain value; double restatement loses information and costs ~2x tokens; the `<workflow-state>` routing in AGENTS.md already covers this
 
-**替代方案**: 用 `<workflow-state>` 块直接路由，不通过人格。
+**Alternative**: route directly with the `<workflow-state>` block; do not use personas.
 
 ---
 
-## 反模式 B：人格调用人格（禁止）
+## Anti-pattern B: Persona calling persona (forbidden)
 
 ```
-cowork-check("看到安全相关代码") -> cowork-security-audit
+cowork-check("sees security-related code") -> cowork-security-audit
 ```
 
-**为什么不行**: 人格设计为产出单一视角; 链式调用破坏此设计; 调用人格传递的摘要丢失上下文; 失败模式相乘
+**Why not**: personas are designed to produce a single perspective; chaining breaks that design; summaries passed between personas lose context; failure modes multiply
 
-**替代方案**: 当前人格在报告中推荐后续审计；用户或主会话运行第二轮。
+**Alternative**: the current persona recommends a follow-up audit in its report; the user or main session runs the second round.
 
 ---
 
-## 反模式 C：Deep nesting（禁止）
+## Anti-pattern C: Deep nesting (forbidden)
 
 ```
 /ship -> quality-coordinator -> code-reviewer -> security-auditor
 ```
 
-**为什么不行**: 每一层增加延迟和 token 但无决策价值; 深层人格的上下文多次总结后失真
+**Why not**: each layer adds latency and tokens without decision value; deep persona context degrades after repeated summarization
 
-**替代方案**: cowork-flow 当前深度 = 1（主会话 → 叶子子代理）。不引入中间层。
+**Alternative**: cowork-flow's current depth = 1 (main session -> leaf subagent). Do not introduce intermediate layers.
 
 ---
 
-## 决策流
+## Decision flow
 
 ```
-任务是一个视角对一个 artifact？
-├── 是 → 直接调用。停止。
-└── 否 → task 可并列？
-         ├── 否 → 顺序 skill 链（用户驱动）
-         └── 是 → 并行扇-out（主会话协调）
-                  验证清单：
-                  - 子任务无写冲突
-                  - 每 persona 产出不同类型
-                  - 合并步骤 fit in main context
-                  任一不满足 → 回退顺序
+Is the task one perspective on one artifact?
+├── Yes -> call it directly. Stop.
+└── No  -> can the tasks run in parallel?
+          ├── No  -> sequential skill chain (user-driven)
+          └── Yes -> parallel fan-out (main-session coordinated)
+                     Verification checklist:
+                     - subtasks have no write conflicts
+                     - each persona produces a different type
+                     - the merge step fits in the main context
+                     Any failure -> fall back to sequential
 ```
 
-## 参见
+## See also
 
-- `spec/contracts/subagent-dispatch.md` — formal dispatch 协议权威定义
-- `spec/contracts/party-mode-v2-board.md` — Party Mode V2 权威定义
-- `spec/backend/`、`spec/frontend/`、`spec/guides/` — 用户定义规范，由 review skill 按需逐条审查
-- `skills/cowork-flow/SKILL.md` — workflow state 路由
+- `spec/contracts/subagent-dispatch.md` — authoritative formal dispatch protocol
+- `spec/contracts/party-mode-v2-board.md` — authoritative Party Mode V2 definition
+- `spec/backend/`, `spec/frontend/`, `spec/guides/` — user-defined specs, read clause by clause by the review skill
+- `skills/cowork-flow/SKILL.md` — workflow state routing