coding-agent-harness 1.0.0

package/templates-zh-CN/reference/execution-workflow-standard.md

@@ -0,0 +1,81 @@
+# 执行工作流标准
+
+## 职责
+
+本标准规定非平凡任务从开始、执行到收口的固定路径。它把 task plan、Delivery SSoT、worktree、review、testing、Regression SSoT、walkthrough 和 Harness Ledger 串成一条可检查的交付链。
+
+## 开始任务前
+
+1. 读取 AGENTS.md 和与本任务相关的 reference 标准。
+2. 读取功能 SSoT 或 Delivery SSoT，确认任务状态、owner 和依赖。
+3. 读取 `task_plan.md`，确认目标、范围、证据、stop condition 和允许修改的路径。
+4. 读取 `delivery-operating-model-standard.md`，判断本轮是 solo、team、split-repo、program、waterfall 还是 kanban 交付形态。
+5. 多人、多 agent、多仓、共享文件或阶段交付任务必须更新 `docs/09-PLANNING/Delivery-SSoT.md`。
+6. 判断是否属于长程任务；如属于，按 `long-running-task-standard.md` 补齐合同。
+7. 判断是否需要对抗性审查；如需要，按 `adversarial-review-standard.md` 创建或更新 `review.md`。
+8. planned task 默认需要 closeout review；先读取 `review-routing-standard.md`。
+9. 触及 PR、branch protection、required checks、CI/CD 或 release 时，读取 `repo-governance-standard.md` 和 `ci-cd-standard.md`。
+10. 按运行模型确认是否需要 worktree、feature branch、contract branch 或 release branch。
+11. 如需调用可写 subagent worker，先分配独立 worktree / branch、任务目录、write scope 和必跑 checks。
+
+## 执行过程中
+
+1. 每完成一个阶段，更新 `progress.md`。
+2. 调查事实、约束和异常写入 `findings.md`，不要只留在聊天记录。
+3. 长程任务每轮执行 evidence loop 和 review loop。
+4. reviewer 或 subagent 审查结果写入任务目录的 `review.md`。
+5. 可写 worker 必须在自己的 worktree 内实现、验证、提交，并 handoff branch、commit SHA、checks、residual。
+6. 遇到共享文件冲突，由 coordinator 或人工决定串行顺序。
+7. 遇到目标失效、权限阻塞、高风险决策或 stop condition 不适用，立即暂停并记录。
+8. 有意义地提交中间成果；commit message 应说明变更类型和范围。
+
+## 完成任务后
+
+1. 按 `testing-standard.md` 和 Regression SSoT 运行对应检查。
+2. 确认 repo governance、CI/CD required checks 已执行、更新或 residualized。
+3. 更新功能 SSoT；多人、多仓、多模块任务同时更新 Delivery SSoT 或 Module Registry。
+4. 更新 Regression SSoT 和 Cadence Ledger（如适用）。
+5. 确认 `review.md` 没有 open P0/P1 finding；material P2 已修复或写为 `accepted-risk` 并路由。
+6. planned task 必须完成 closeout review，或写明 `skipped-with-reason`。
+7. 写 walkthrough，引用 task plan、review、证据、residual、Regression SSoT 和 commit。
+8. 执行 Lessons 检查：有可复用经验则写 lesson 详情并更新 Lessons SSoT；没有也记录 `checked-none: <reason>`。
+9. 最后更新 Harness Ledger，因为它记录本轮上下文维护的最终状态。
+10. 完成 commit / PR / release note，并确认本任务工作区没有未解释的遗留改动。
+11. 如使用 worker，coordinator 集成 worker commit 后运行最终 gates，并记录 integration evidence。
+12. 如使用 worktree，按 `worktree-standard.md` 清理或记录保留原因。
+
+## 提交规范
+
+推荐格式：
+
+```text
+<type>(<scope>): <description>
+```
+
+常用类型：
+
+- `feat`：新功能。
+- `fix`：缺陷修复。
+- `refactor`：重构。
+- `test`：测试相关。
+- `docs`：文档。
+- `chore`：构建、工具、配置或维护。
+
+## PR 与合并规范
+
+PR 描述必须包含：
+
+- 改了什么，为什么改。
+- 关联 task plan、SSoT、review 或 issue。
+- 实际运行的检查和证据。
+- residual、owner 和不阻塞理由。
+- required checks、reviewer、merge method 是否满足 `repo-governance-standard.md`。
+
+## 禁止事项
+
+- 非平凡任务跳过 task plan 直接实现。
+- 把 task plan、progress、review 等过程文件放在项目根目录。
+- 需要对抗性审查时只在聊天里讨论，不写 `review.md`。
+- 让多个可写 worker 在 coordinator 当前 checkout 混合未提交改动。
+- 把 `designed` 或 `implemented` 的 CI/CD、branch protection 说成 `verified`。
+- merge 后不跑回归、不写 walkthrough、不更新 Harness Ledger。

package/templates-zh-CN/reference/harness-ledger-standard.md

@@ -0,0 +1,91 @@
+# 工程总账标准
+
+## 职责
+
+Harness Ledger 是 `docs/` 骨架的全局上下文维护总账，固定位置为：
+
+```text
+docs/Harness-Ledger.md
+```
+
+它记录每个非平凡任务是否完成了 task plan、progress、review、功能 SSoT、Delivery SSoT、Regression SSoT、Lessons SSoT、walkthrough、Closeout SSoT、reference/template 和 CI/CD 治理回写。它不复制业务事实，只记录上下文维护是否合规。
+
+## 必须更新的场景
+
+- 完成一个非平凡 task、wave、feature 或 release。
+- bootstrap、同步或升级 coding-agent-harness。
+- 新增或修改 AGENTS.md、CLAUDE.md、reference、template、checker 或 dashboard。
+- coordinator pass 汇总模块任务、worker handoff、review、closeout 或 regression 结果。
+- 创建或更新 required review。
+- 修改功能 SSoT、Delivery SSoT、Regression SSoT、Lessons SSoT、Closeout SSoT 任一文件。
+- 创建 walkthrough 或接受受控跳过。
+- Lessons approved 后合入正式 reference。
+
+## 通常不需要更新的场景
+
+- 单个错别字或排版小修。
+- 单次 `progress.md` 过程性追加。
+- 普通测试输出粘贴，且不改变 gate 状态。
+- 只读分析，没有产生 repo 内上下文变化。
+- routine regression batch 只更新“上次验证”，且没有 residual 或 evidence depth 变化。
+
+## 写入规则
+
+1. 每行对应一个任务级或治理级上下文维护事件。
+2. 不复制 Feature、Regression、Lessons 的业务细节；只链接源文件。
+3. 不记录逐行 diff；逐行变化由 git history 负责。
+4. 状态值使用固定词，避免自由文本失控。
+5. 任务收口时最后更新 Harness Ledger。
+6. `closed` 行必须有 Lessons 检查结果。
+7. `checked-created` 必须引用 lesson ID 和详情文档。
+8. 如果 closeout、review 或 regression 被跳过，必须写 `skipped-with-reason`。
+
+## 固定状态词
+
+- `required`
+- `updated`
+- `created`
+- `checked-none`
+- `checked-created`
+- `n/a`
+- `skipped-with-reason`
+- `missing`
+- `pending-coordinator-pass`
+
+## 收口检查
+
+任务完成前确认：
+
+- [ ] `task_plan.md`、`progress.md` 已更新到当前事实。
+- [ ] 启用模块并行时，worker 已更新 `module_plan.md` 并完成 handoff。
+- [ ] coordinator pass 已同步 `Module-Registry.md`、Delivery SSoT 和 Harness Ledger，或记录 `pending-coordinator-pass`。
+- [ ] `review.md` 已创建/更新，或标记 `n/a` / `skipped-with-reason`。
+- [ ] closeout reviewer 已执行，或跳过原因受控。
+- [ ] repo governance、CI/CD required checks 已验证、更新或 residualized。
+- [ ] 功能 SSoT 或 Delivery SSoT 已更新，或标记 `n/a`。
+- [ ] Regression SSoT / Cadence Ledger 已更新，或标记 `n/a`。
+- [ ] walkthrough 已创建，或 Closeout SSoT 写明受控跳过原因。
+- [ ] walkthrough 包含 Lessons 反思。
+- [ ] Lessons 检查结果为 `checked-none: <reason>` 或 `checked-created: L-YYYY-MM-DD-NNN`。
+- [ ] Harness Ledger 行已收口，或 residual 已写明 owner 和后续路径。
+
+## 框架更新检查清单
+
+更新已有 harness 时确认：
+
+- [ ] 已读取最新版 coding-agent-harness Skill、reference、template 和 checker。
+- [ ] 已列出 delta plan。
+- [ ] 只补齐新增标准和缺失结构，没有覆盖历史 walkthrough、task progress、SSoT 事实。
+- [ ] 新增 reference / template 已写入入口索引。
+- [ ] checker 或 dashboard 的新增要求已有验证。
+- [ ] Harness Ledger 记录本次 delta merge、证据和 residual。
+
+## 归档
+
+活跃表保留最近 50 条。更早的 `closed` 或 `superseded` 条目按季度归档：
+
+```text
+docs/01-GOVERNANCE/_archive/Harness-Ledger-archive-YYYY-QN.md
+```
+
+归档后，活跃表必须留下归档位置说明。

package/templates-zh-CN/reference/long-running-task-standard.md

@@ -0,0 +1,156 @@
+# 长程任务标准
+
+## 目的
+
+本标准定义长程自主执行任务的任务合同、review loop、证据要求、暂停条件和停止条件。它回答的是：什么样的任务定义，才能支持 agent 在较少人工干预下连续推进，同时不丢失边界、证据和收口判断。
+
+本标准负责“任务怎么设计”；`execution-workflow-standard.md` 负责“任务开始后怎么跑”。
+
+## 适用场景
+
+使用本标准：
+
+- 多轮复杂修复、重构、迁移、交付收口。
+- 预计持续 2 小时以上。
+- 需要 reviewer agent、subagent、外部 agent 或人工审查。
+- 需要多轮 evidence loop 或 live smoke。
+- 用户授权 agent 连续执行，直到满足 stop condition 再汇报。
+
+通常不需要：
+
+- 单文件小修。
+- 一次性命令。
+- 纯只读分析。
+- 没有客观验收口径的轻量讨论。
+
+## 任务合同字段
+
+### 目标
+
+- 只定义本轮要收掉的主问题。
+- 避免“整体优化”“尽量改好”“看情况处理”这类不可验收目标。
+
+### 范围
+
+- 写明允许修改的目录、模块、接口、文档和配置。
+- 写明 out of scope。
+- 标出共享文件、跨仓契约和冲突风险。
+- 当前工作树有他人改动时，必须说明如何避开或协同。
+
+### 主要调用者和入口
+
+明确本轮覆盖哪些 primary caller / entry：
+
+- CLI / local agent
+- UI / human user
+- API / service
+- automation / scheduler
+- integration / adapter
+- CI/CD / release workflow
+
+### 执行权限
+
+写清：
+
+- 是否允许连续执行，不用每轮确认。
+- 是否允许自动进入下一轮 review / fix / test。
+- 是否允许启动 reviewer、subagent 或外部 agent。
+- 哪些动作必须暂停等人确认，例如生产数据、权限、安全、费用、发布。
+
+### 审查循环
+
+每轮闭环至少包含：
+
+1. 实现当前切片。
+2. 本地运行或启动对应目标。
+3. 执行测试、冒烟检查或人工检查。
+4. 用 `Confidence Challenge` 做自审。
+5. 触发 reviewer / subagent review（如适用，并更新 `review.md`）。
+6. 修复重要发现。
+7. 重新收集证据。
+8. 重跑 `Confidence Challenge`，直到没有 open 重要发现。
+
+如使用 reviewer 或 subagent，必须写清：
+
+- 只读审查还是可改代码。
+- 负责的文件、模块或问题域。
+- 输出格式和落点。
+- no-finding 的判断口径。
+- 是否必须回答 100% 信心挑战。
+
+可写 subagent worker 必须走 worker 合同：
+
+- 独立 worktree / branch。
+- 明确 task directory 和 write scope。
+- 自己运行 required checks。
+- 提交自己的改动。
+- handoff 包含 branch、commit SHA、checks、residual。
+- coordinator 合并 worker commit 后运行最终 gates。
+
+### 证据
+
+列出本轮要求的证据：
+
+- lint / typecheck / build
+- unit / integration / e2e tests
+- 本地冒烟
+- 浏览器或 UI 检查
+- 线上环境冒烟
+- 日志、截图、trace
+- 审查者发现
+- `review.md` 中的重要发现状态与残余路由
+- PR 检查或 workflow 运行记录
+- walkthrough 和 Harness Ledger 更新
+
+### 停止条件
+
+stop condition 必须可判断：
+
+- 关键路径通过。
+- 目标 tests / regression gates 通过。
+- runtime、console、request errors 清零，或有明确 residual。
+- reviewer 无 open material findings。
+- `review.md` 已完成，且无 open P0/P1 finding。
+- residual 已记录 owner、后续路径和不阻塞理由。
+
+### 交付物
+
+- code
+- tests / regression evidence
+- docs updates
+- `progress.md` / `findings.md`
+- `review.md`（如适用）
+- worker branch / commit SHA / integration evidence（如使用 worker）
+- walkthrough
+- Harness Ledger
+- PR / commit / release note
+- residual summary
+
+## 暂停条件
+
+即使已授权连续执行，出现以下情况也必须暂停并汇报：
+
+- 目标、范围或 stop condition 失效。
+- 需要高风险产品、架构、安全、数据或发布决策。
+- 与未知未提交改动冲突。
+- 权限、配额、外部依赖、环境阻塞。
+- reviewer finding 改变了任务方向。
+- required evidence 无法获得，且没有可接受替代证据。
+
+## 反模式
+
+- “你先看看，能改多少改多少。”
+- “整体优化一下。”
+- “差不多就行。”
+- “不用测。”
+- “你自己把握什么时候完成。”
+
+长程任务的原则是：开放执行，封闭验收；多轮证据，不靠感觉。
+
+## 项目落地要求
+
+- 开始任务前必须判断是否属于长程任务。
+- 任务模板应包含 long-running task contract 和 `review.md` 模板。
+- reviewer 报告按 `adversarial-review-standard.md` 写。
+- 回归和测试标准必须提供可复查证据。
+- Harness Ledger 必须记录长程任务是否完成必要上下文回写。

package/templates-zh-CN/reference/regression-ssot-governance.md

@@ -0,0 +1,82 @@
+# 回归单一事实源治理标准
+
+## 职责
+
+Regression SSoT 是项目回归控制塔，管理所有 regression surface 的 gate、证据深度、最后验证时间、失败状态和 residual。它管正确性，不管功能排期；功能进度由功能 SSoT 或 Delivery SSoT 管。
+
+默认位置：
+
+```text
+docs/05-TEST-QA/Regression-SSoT.md
+```
+
+## 维护时机
+
+必须更新 Regression SSoT：
+
+- 新增、修改或废弃 regression gate。
+- gate 的 evidence depth 提升或降低。
+- gate 状态变化，例如 pass、fail、blocked、paused。
+- 新增、解决或接受 residual。
+- shared regression batch 执行后产生状态、证据或 residual 变化。
+- release、重大 merge、架构改动、关键 UI/API surface 改动后。
+
+如果 routine batch 只更新“上次验证”，且没有 residual 或 evidence depth 变化，不强制写 Harness Ledger；但 Regression SSoT 本身仍应保持当前。
+
+## 负责人
+
+- 执行回归的 agent 更新 gate 状态和 last verified。
+- 发现 residual 的 agent 添加 residual item。
+- 修复 residual 的 agent 标记解决，并链接证据。
+- coordinator 负责 shared batch 的完整性和最终汇总。
+
+## 回归门禁字段
+
+| 字段 | 说明 |
+| --- | --- |
+| Gate ID | 唯一 ID，例如 `RG-001`。 |
+| Surface | 被保护的功能面、接口、页面、流程或平台。 |
+| Primary entrypoint | 主要入口，例如 URL、命令、API、job、用户路径。 |
+| Evidence depth | 证据层级，例如 unit、integration、local_smoke、browser、live。 |
+| Current status | 当前状态，例如 pass、fail、blocked、paused。 |
+| Last verified | 最近一次有效验证日期。 |
+| Required trigger | 哪些改动会触发此 gate。 |
+| Evidence | 命令、日志、截图、trace、CI run 或 walkthrough 链接。 |
+| Residual | 未解决风险、owner 和后续路径。 |
+
+## 新增回归门禁
+
+1. 在活跃 gate 表中添加新行。
+2. 分配递增 ID。
+3. 写明 surface、primary entrypoint、initial evidence depth 和 trigger。
+4. 同步更新 Cadence Ledger 的触发规则。
+5. 在当前任务的 walkthrough 和 Harness Ledger 记录 `Regression=updated`。
+
+## 提升证据深度
+
+1. 实现更高层级的测试或检查，例如从本地冒烟提升到浏览器检查或线上验证。
+2. 验证通过后更新 evidence depth。
+3. 在 walkthrough 中说明为什么证据深度提升。
+4. 如果替代旧检查，说明旧检查是否保留、降级或废弃。
+
+## 废弃回归门禁
+
+1. 将 gate 移入 `docs/05-TEST-QA/_archive/Regression-SSoT-archive-YYYY-QN.md`。
+2. 写明废弃原因、替代 gate 和最后状态。
+3. 同步更新 Cadence Ledger。
+4. 在 walkthrough 和 Harness Ledger 记录本次治理变化。
+
+## 共享批次执行规范
+
+- 每轮 shared batch 必须覆盖所有 active gate，除非明确写明跳过原因。
+- 执行结果记录到 Cadence Ledger 的批次日志。
+- 失败 gate 必须创建 residual。
+- 下一轮 batch 的 checkpoint 条件必须明确。
+- batch 不能只写“已跑”，必须有 evidence。
+
+## 与其他文件的关系
+
+- 功能 SSoT 管进度，Regression SSoT 管正确性。
+- Cadence Ledger 管什么时候跑，Regression SSoT 管 gate 当前事实。
+- walkthrough 记录本轮验证结论，Regression SSoT 保留当前回归控制面。
+- Harness Ledger 记录本轮是否完成回归上下文回写。

package/templates-zh-CN/reference/repo-governance-standard.md

@@ -0,0 +1,84 @@
+# 仓库治理标准
+
+## 职责
+
+本标准定义仓库平台、分支模型、PR 策略、required checks、branch protection、worktree 并发和 merge 规则。它用于避免 agent 在没有仓库治理边界的情况下直接提交、跳过审查或把未验证状态当成已验证。
+
+## 仓库画像
+
+| 项 | 项目约定 |
+| --- | --- |
+| 平台 | GitHub / GitLab / local-only / 其他 |
+| Remote | `owner/repo` 或 URL |
+| 默认分支 | `main` / `master` / 其他 |
+| 仓库类型 | single app / monorepo / multi-repo / library / service |
+| agent 是否有管理权限 | yes / no / unknown |
+| 受保护分支 | 默认分支、release branch 或其他 |
+
+## 分支模型
+
+| 分支类型 | 命名规则 | 用途 | merge 规则 |
+| --- | --- | --- | --- |
+| feature branch | 例如 `feat/<name>` 或 `codex/<name>` | 常规功能和修复 | PR 或项目约定流程 |
+| fix branch | 例如 `fix/<name>` | 缺陷修复 | 跑 required checks 后合入 |
+| release branch | 例如 `release/<version>` | 发布稳定线 | release owner 管理 |
+| hotfix branch | 例如 `hotfix/<name>` | 生产紧急修复 | 必须记录验证和回滚路径 |
+| worker branch | coordinator 指定 | subagent worker 独立交付 | 通过 commit / branch handoff 集成 |
+
+直接推送策略必须写清：哪些分支禁止 direct push，哪些例外需要 owner 批准。
+
+## PR 策略
+
+| 项 | 项目约定 |
+| --- | --- |
+| 是否必须 PR | yes / no / local-only |
+| PR 标题格式 | 通常与 commit 规范一致 |
+| PR 描述要求 | 改动、原因、验证、residual、关联 task / SSoT / review |
+| 必需审查者 | reviewer、外部 agent、人类 owner 或代码 owner |
+| 必需审查类型 | self-review、subagent review、human review、security review |
+| merge method | merge commit、squash、rebase、fast-forward |
+| merge order owner | coordinator、maintainer、release owner |
+
+## 必需检查
+
+| 检查 | 命令或 workflow | 是否必需 | 证据 | residual 规则 |
+| --- | --- | --- | --- | --- |
+| lint | 项目命令或 CI job | yes/no | 日志或 workflow run | 失败需修复或 owner 接受 |
+| typecheck | 项目命令或 CI job | yes/no | 日志或 workflow run | 不适用需说明 |
+| build | 项目命令或 CI job | yes/no | 日志或 workflow run | 发布前必须明确 |
+| test | 项目命令或 CI job | yes/no | 测试结果 | flaky 需记录 |
+| smoke | 本地、browser 或 live smoke | yes/no | 截图、日志、trace | residual 路由到 Regression SSoT |
+
+## 分支保护
+
+| 项 | 项目约定 |
+| --- | --- |
+| 状态 | `designed` / `implemented` / `verified` / `blocked-with-owner` |
+| 必需状态检查 | required status checks 列表 |
+| 必需 PR 审查数量 | 数量和角色 |
+| Dismiss stale reviews | yes / no |
+| Require branches up to date | yes / no |
+| Block force push | yes / no |
+| Block deletion | yes / no |
+| Bypass actors | 明确角色，不写个人密钥 |
+| 验证命令 | `gh`、平台 UI 证据或 API 查询 |
+| Manual setup residual | 不能自动配置时的 owner 和原因 |
+
+## 工作树并发治理
+
+| 项 | 项目约定 |
+| --- | --- |
+| 最大活跃 worktree 数 | 项目上限 |
+| worktree 命名 | 目录模式 |
+| branch 命名 | 分支模式 |
+| owner 规则 | 谁创建、谁清理、谁集成 |
+| subagent worker 规则 | 每个可写 worker 使用独立 worktree / branch，并 handoff commit SHA |
+| merge 顺序 | coordinator 或 release owner 决定 |
+| 清理规则 | merge 后删除，保留需写原因 |
+
+## 收口要求
+
+- 非平凡任务的 PR 或 walkthrough 必须说明 required checks 的执行结果。
+- branch protection 未 verified 时，不能声称仓库已受保护；只能写 `designed`、`implemented` 或 `blocked-with-owner`。
+- worker 结果只能通过 commit / branch 集成，不能混入 coordinator 未提交改动。
+- repo governance 变化必须同步 CI/CD 标准、worktree 标准和 Harness Ledger。

package/templates-zh-CN/reference/review-routing-standard.md

@@ -0,0 +1,82 @@
+# 审查路由标准
+
+## 职责
+
+本标准定义 planned task、wave、feature 或 release 在收口前如何触发 self-review、subagent review、外部 agent review 或人工审查。`adversarial-review-standard.md` 规定 `review.md` 怎么写；本文件规定谁来写、什么时候必须写、什么时候可以跳过。
+
+## 默认规则
+
+每个 planned task / wave / feature 收口前默认执行 closeout review：
+
+1. 主 agent 完成 self-review。
+2. 主 agent 调用 reviewer 或只读 subagent 做外部视角审查。
+3. reviewer 按 `adversarial-review-standard.md` 写入或补全 `review.md`。
+4. 主 agent 修复或路由 material findings。
+5. 重跑对应证据。
+6. 再次执行 `Confidence Challenge`，直到没有 open material findings。
+
+当前环境无法调用 subagent 时，必须在 `review.md`、`progress.md` 或 walkthrough 写 `skipped-with-reason`，说明替代审查方式。
+
+## 审查者层级
+
+| 层级 | 审查者 | 适用场景 | 要求 |
+| --- | --- | --- | --- |
+| L0 | Self-review | 微小变更、只读分析、小文档修正 | 记录在 `progress.md` 或 `review.md`。 |
+| L1 | Subagent reviewer | 默认非平凡任务 | 必须写 `review.md`。 |
+| L2 | External agent reviewer | 用户或项目要求，例如 Claude Code、Gemini、Codex 另一实例 | 必须写 `review.md`，并记录 `Reviewer Identity`。 |
+| L3 | Human reviewer | 高风险产品、架构、安全、数据、发布判断 | agent 完成内部审查后，明确请求人工判断。 |
+
+## 可写执行者与只读审查者的区别
+
+审查路由默认把 subagent 当只读 reviewer。只要 subagent 被要求直接改代码、测试、产品文档或 harness 文档，它就不再是 reviewer，而是 worker。
+
+Worker 必须走 `worktree-standard.md`：
+
+- coordinator 先分配独立 worktree / branch、任务目录和 write scope。
+- worker 在自己的 worktree 内实现、验证并提交。
+- worker handoff 写明 branch、commit SHA、checks、residual。
+- coordinator 负责 merge、冲突处理、最终 gates 和 integration evidence。
+
+禁止把多个 worker 的未提交改动混在 coordinator 当前 checkout，再由 coordinator 一次性提交。
+
+## 项目级外部审查策略
+
+如果项目长期使用 Claude Code、Gemini、Codex 另一实例或人工 reviewer，必须在本文件记录：
+
+- 默认 reviewer。
+- 触发条件。
+- reviewer 是否只读。
+- reviewer 输出写入位置。
+- 主 agent 如何处理分歧。
+- 哪些 finding 必须暂停并询问用户。
+- 哪些检查必须由 reviewer 亲自看过，不能只听主 agent 摘要。
+
+## 校准流程
+
+引入新外部 reviewer 时，先做一次 calibration：
+
+1. 主 agent 写出任务目标、scope、证据、当前策略和 residual。
+2. 外部 reviewer 用 `Confidence Challenge` 挑战策略。
+3. 双方对 severity、accepted-risk、stop condition 和 required checks 口径达成一致。
+4. 将共识写入项目级 `review-routing-standard.md`。
+
+## 可跳过审查的条件
+
+只有以下情况可以跳过 L1 以上审查：
+
+- 纯只读分析，没有修改仓库。
+- 明确的小 typo 或格式修正。
+- 用户明确要求不做外部审查。
+- 当前环境确实没有可用 reviewer，且已记录替代 self-review 和 residual。
+
+跳过必须写 `skipped-with-reason`，不能留空。
+
+## 收口检查
+
+- [ ] `review.md` 存在，或有明确 `skipped-with-reason`。
+- [ ] L1 以上审查已执行，或环境限制已记录。
+- [ ] `Reviewer Identity`、`Evidence Checked`、`Confidence Challenge`、`Final Confidence Basis` 已填写。
+- [ ] open P0/P1 findings 为 0。
+- [ ] material P2 已修复或 `accepted-risk` 并路由。
+- [ ] 如使用 worker，已记录 branch、commit SHA、checks、residual 和 integration evidence。
+- [ ] walkthrough、Closeout SSoT、Harness Ledger 引用了审查报告或跳过原因。

package/templates-zh-CN/reference/testing-standard.md

@@ -0,0 +1,72 @@
+# 测试标准
+
+## 职责
+
+本标准定义完成任务前最低验证要求。测试不是为了证明“改过了”，而是为了证明本轮目标、关键路径、回归面和 residual 判断有证据支撑。
+
+## 测试体系画像
+
+| 项 | 项目约定 |
+| --- | --- |
+| 单元测试 | 框架、命令、目录 |
+| 集成测试 | 框架、命令、外部依赖处理 |
+| 端到端测试 | Playwright / Cypress / 其他 |
+| 浏览器检查 | 本地 URL、截图、console、network、交互路径 |
+| live smoke | 环境、账号、权限、日志和回滚边界 |
+| 测试数据 | fixture、factory、seed、脱敏数据 |
+| 覆盖率目标 | 核心模块、工具函数、adapter、UI 关键路径 |
+
+## 目录和命名
+
+- 测试目录遵循项目现有结构，不为单次任务新建割裂风格。
+- 测试文件使用项目约定，例如 `*.test.ts`、`*.spec.ts`、`test_*.py`。
+- 测试用例名描述行为和条件，例如“当用户未登录时拒绝访问私有接口”。
+- fixture、mock、snapshot 要有清晰边界；不要把内部实现细节固定成脆弱快照。
+
+## 分层验证
+
+| 层级 | 用途 | 适用场景 |
+| --- | --- | --- |
+| unit | 验证纯逻辑、边界条件、错误处理 | 工具函数、核心算法、纯业务规则 |
+| integration | 验证模块协作、数据库、外部 client 封装 | 服务层、adapter、schema 变更 |
+| e2e | 验证用户路径或跨层流程 | UI、API、关键业务流 |
+| 本地冒烟 | 验证本地运行入口 | CLI、服务启动、页面打开 |
+| 浏览器检查 | 验证真实浏览器渲染、交互、console、network | 前端、可视化、登录流程 |
+| 线上冒烟 | 验证真实环境和部署链路 | 发布、反向代理、第三方集成 |
+
+## 回归触发
+
+以下情况必须查看 Regression SSoT 和 Cadence Ledger：
+
+- merge 到主干前。
+- 修改关键 surface、共享组件、schema、路由、权限、数据迁移。
+- 修复线上或用户可见缺陷。
+- release、hotfix、CI/CD、部署配置变更。
+- reviewer finding 要求重跑证据。
+
+## 证据要求
+
+验证结果必须写明：
+
+- 命令或检查名称。
+- 运行位置和时间。
+- 通过 / 失败 / skipped。
+- 失败时的错误摘要。
+- 证据路径：日志、截图、trace、CI run、Regression SSoT、walkthrough 或 PR。
+- skipped 时的 residual、owner 和不阻塞理由。
+
+## 测试编写原则
+
+1. 每个测试验证一个清晰行为。
+2. 测试之间互相独立，不依赖执行顺序。
+3. 外部依赖通过 fixture、mock server、test container 或明确的 live smoke 处理。
+4. mock 外部边界，不 mock 被测内部实现。
+5. 错误信息要能帮助定位问题。
+6. 复杂回归优先沉淀成可重复命令，而不是一次性手工步骤。
+
+## 收口要求
+
+- 非平凡代码改动至少提供一种自动化测试或明确说明为什么只能 smoke。
+- 前端可视化或交互改动需要 browser inspection，除非有明确不适用原因。
+- 发布和部署改动需要 CI/CD 证据、live smoke 或受控 residual。
+- 测试失败不能直接收口；必须修复、写为 `accepted-risk` 并路由，或暂停并交给 owner。