Octopus/octopus-workflow
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
445940ea63533043153fd4753f34809eb8e71640
octopus-workflow/core/checklists/pipeline-gate.md
T

8.5 KiB
Raw Blame History

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 而非绕过
Reference in New Issue View Git Blame Copy Permalink