> Core 中立版（Increment 6a 改写，原 deferHard verbatim）。编号与条目结构严格不变（C-2 不变量）；实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
# Pipeline Gate Checklist

跨阶段门控清单。implement、review-code、verify 的 precondition 应引用本清单。
每个阶段启动前必须逐项确认。

## DAG 路由变体（DAG-routed Epic/Feature 及其 Kind/Task 子工单）

DAG 路由（`dag.route` / `dag.task_route`）**不适用**下方 legacy 的
Upstream Artifact Existence 与 Upstream Review Convergence 检查
（各 skill 的 DAG 分支——implement §"DAG-mode input path"、review-code
§"DAG Task Mode"、verify §"DAG branch"——以下列判据替代）：

- [ ] 冻结 DAG 副本存在：wiki page `{epic-slug}/dag` 存在且首行为
      `> DAG 工件状态: frozen`（节点 spec、跨 session 边契约、
      `size_attrs` 均自该副本解析）
- [ ] 单门收敛：`octopus review status --stage review-dag` state 为
      `success`（替代 design-space + iteration-plan 双门；任务工单
      不重跑单门，只核对其已收敛）
- [ ] （仅任务工单）票 body `## 父级 / Parent` 指向 DAG 父级
      （`Kind/Epic` 或 `Kind/Feature`，[org-internal #3061] 阶段 2），
      Step 0 解析到 `dag.task_route`（entry `implement`），不继承
      `dag.route`
- [ ] 跨节点依赖由 DAG 拓扑承担：节点 ready 以其全部跨 session 上游
      处于终态为准（同 session 边不阻塞）；fan-in ≥ 2 里程碑节点由
      verify 里程碑承担 DoD，不建工单、不走本清单

abort 恢复：单门未收敛 → 聚合 agent 重跑 review-artifact skill（target:
review-dag）直至收敛；DAG 副本缺失或未冻结 → 回到 `analyze-dag`
（分解 → 单门 → 冻结）后再重试。

## Upstream Artifact Existence（live — standalone modes）

- [ ] standalone bugfix：repro notes wiki page `{slug}/repro-notes` 存在且含环境快照（via `wiki 读写 API（见 TERMINOLOGY）`）
- [ ] 验收条件可解析：来自请求/工单 body 或节点 AC（等价的验收条件文档，via `wiki 读写 API（见 TERMINOLOGY）` / `工单 API（见 TERMINOLOGY）get`）

> Legacy（[org-internal #3072] phase 3，2026-08-21 归档）：requirements/design/plan baseline
> 页（`{slug}/02-requirements-index` / `{slug}/03-design-index` /
> `{slug}/04-plan-index` / `{slug}/04-plan-05-acceptance-criteria`）与
> design-space / iteration-plan 双门收敛检查随 legacy 管线归档
> （`<instance-root>/archive/`）；历史页面仍可读，DAG 路由由上方 DAG 变体接管。

## Upstream Review Convergence

- [ ] （代码评审阶段）code review 已收敛 — run `octopus review status --stage code` and verify state is `success`

## Upstream Dependency Check

- [ ] 当前节点的所有跨 session 上游依赖节点处于终态（task `done` / milestone `green`，以冻结 DAG 副本 / `## DAG 状态` 表为准）
- [ ] 如果有依赖节点未到终态 → abort，列出阻塞的节点

## Deferred Items Closure

- [ ] 上一迭代的 Carried Items 全部有明确的 Target Iteration 且已在当前迭代处理或重新延期
- [ ] 上一迭代的 Carried Risks 状态已更新（open/closed）
- [ ] verify 阶段：所有 UNVERIFIABLE 项有明确的 reactivation plan 或被标记为 accepted tech debt（有记录）

## Tech Debt Review

- [ ] tech debt 可经 Gitea issue 查询（`工单 API（见 TERMINOLOGY）list(labels="tech-debt")`，如果项目有任何已完成的 chunk/迭代）
- [ ] 回读 open `tech-debt` issues，检查每项的 Reactivation Trigger 是否已满足
- [ ] 到期项（trigger 已满足）已纳入当前迭代工作项或显式延期（更新 trigger）
- [ ] 如果有到期项未处理 → warn 并列出，建议纳入当前迭代
- [ ] 本迭代全部 tech-debt 项均已创建为 `tech-debt` labeled issue；遗漏的项已在 verify 阶段补建或在报告中 flag

## PR 准入（pr-admission）

> 纪律：`core/rules/ticket-lifecycle.md` PR 准入节（TD-678 / [org-internal #3881] / [org-internal #4425]）。

- [ ] PR 标题符合 `[slug][iter-N] type(scope): 描述` 格式
- [ ] PR 正文含变更清单 + 自测结果 + 关联合规（关联 issue 引用，如 `Closes #N`；数字后须接 ASCII 标点或行尾——紧跟全角标点会破坏 Gitea 自动关闭，PR [org-internal #3882] 实例）
- [ ] 交付推送前本地验证已绿：`<harness-package>` 下 `bun run test:changed` 全绿 + `bun typecheck` 0 error（WIP 备份推送不受此门约束——分支裸推零 CI，交付信号是完成回报而非推送）
- [ ] 分支已推送 origin；PR **未**由本会话自行创建（由编排按容量串行开启，一次一张、双绿并入再开下一张）
- [ ] 交付报告已发（branch= 分支名 / 改动文件清单 / 自测结果 / verify 与 risk 回执）
- [ ] 若编排不可达（fail-open）自开了 PR：PR 正文已标注 `uncoordinated`

## Issue Checklist Sync

> 跨阶段门控。source issue 的 checklist 与 `## 当前状态` live-status 表
> 必须在每次对外可见的状态跃迁后就地同步（PR 创建 / 评审收敛 / CI
> 状态跃迁），不得等到技能退出边界。规则：`core/rules/issue-checklist-sync.md`。

- [ ] 若存在 source issue：其 checklist 已按同步点表渐进勾选（DAG 冻结、iteration commit、PR 创建、review PASS、CI 跃迁、verify 终扫），无陈旧 `- [ ]` 项
- [ ] 若为 incident / standalone-bugfix 流程：issue 含 `## 当前状态` live-status 小节，且 PR / review / CI 行已随跃迁更新（[org-internal #1689]）
- [ ] 过程性 AC（如"连续 N 次绿"）的进度注记已更新（带 run 编号）
- [ ] 遗留项（未勾选）均有 `(Deferred: ...)` 或 `(Pending: ...)` 注记
- [ ] verify PASS 时 `## 当前状态` 小节已折叠进 checklist 注记并移除

## Bugfix Pipeline Pre-Design Falsification Gate

> Bugfix 流程特有。必须在进入修复实现前逐项确认。
> 单一事实来源：`core/checklists/bugfix.md` §1 REPRO（条目 1.4-1.6）——
> 环境快照、复现置信度 ≥3/5、根因假设未被证伪、不满足即 abort 的判据
> 以该清单为准，此处不重复列举；逐项核对 bugfix.md §1 后方可进入修复实现。

## Failure Protocol

如果任何检查项不满足：
1. **abort** 当前阶段，不继续执行
2. 列出所有不满足的检查项
3. 指出需要完成的上游工作
4. 告知用户在 upstream 工作完成前无法继续

## Recovery Protocol

abort 后，根据缺失项运行对应的 skill 修复上游工作，然后再重试当前阶段：

| abort 原因 | 恢复动作（运行的 skill） | 修复后重试 |
|-----------|--------------------------|-----------|
| 冻结 DAG 副本缺失或未冻结 | `analyze-dag` — 分解 → `review-artifact` (target: review-dag) 单门 → 冻结 | implement / review-code / verify |
| review-dag 单门未收敛（`octopus review status --stage review-dag` non-`success`） | `review-artifact` (target: review-dag) — 重新运行单门评审直到收敛（聚合 agent） | implement / review-code / verify |
| 上游依赖节点未到终态（task 非 `done` / milestone 非 `green`） | 切换到该依赖节点的工作流，从其当前阶段继续推进，直到其 verify 通过 | implement / verify |
| carried items 未闭环（上一迭代 Carried Items 未处理或无延期记录） | 在当前迭代处理该 carried item，或正式延期到下一迭代并更新其 Target Iteration | verify |
| 验收条件不可解析（节点 AC 缺失或工单 body 无验收条件） | 在 DAG 副本上补齐节点 AC（修订走 oversize 信号流程），或在工单 body 补验收条件 | verify |
| tech debt 到期项未处理（open `tech-debt` issue） | 将到期项纳入当前迭代工作项，或在该 tech-debt issue 中更新 Reactivation Trigger 并说明延期理由 | implement / verify |

### 恢复流程

1. abort 时，列出所有不满足的检查项
2. 对照上表，确定每个缺失项对应的恢复 skill
3. 如果有多个缺失项，按流水线顺序修复（DAG 冻结 → review-dag 单门 → 实现 → code review → verify）
4. 每个恢复 skill 完成后，重新检查对应的 precondition
5. 所有 precondition 满足后，重试原本 abort 的阶段

### 注意

- 恢复上游工作时，不要丢弃已完成的下游工作（如已有代码实现），而是将其作为修复后的验证输入
- 如果上游修复导致下游已完成的工件失效，需要重新运行受影响阶段
- 上游依赖 chunk 未完成时，优先推进依赖 chunk 而非绕过