Initial publish v0.1.0: standalone workflow core (corpus + examples + guards)
This commit is contained in:
octopus
@@ -0,0 +1,146 @@
|
||||
> Core 中立版（Increment 6a 改写，原 deferHard verbatim）。编号与条目结构严格不变（C-2 不变量）；实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
|
||||
# 迭代验证检查清单
|
||||
|
||||
> 迭代级质量门禁。在所有工作项通过代码评审后执行。
|
||||
> 确保集成正确、非功能达标、无回归。
|
||||
|
||||
> **维度命名空间（dimension namespace）**: 本清单中的维度代码（如 TST/BEH/GATE/REG）是**清单局部（checklist-local）**标识符，仅在本文档内唯一；其他清单可能对相同字母串绑定不同概念（如 code-review.md 的 TST=Test Quality、verification.md 的 TST=Test Suite Completeness、port.md 的 TST=Test Porting）。跨清单引用时必须带清单限定（如 code-review.md TST 5.8），不得使用裸代码。
|
||||
|
||||
---
|
||||
|
||||
## 使用说明
|
||||
|
||||
1. 在当前迭代所有工作项通过代码评审后执行；
|
||||
2. 逐项检查，判定为"通过"或"不通过"；
|
||||
3. "不通过"项注明具体指标和差距；
|
||||
4. 全部通过后迭代正式 Done；
|
||||
5. DoD 行判定词汇 PASS/FAIL/UNVERIFIABLE 为 verify 阶段专用：UNVERIFIABLE＝
|
||||
"无自动化验证手段（缺测试/缺工具/缺基线）"，与评审维度的 verdict 枚举
|
||||
PASS/WARN/FAIL/UNRESOLVED 有意区分（WARN＝评审软通过，UNRESOLVED＝评审员
|
||||
崩溃/超时），勿混用。
|
||||
6. **DAG 路由产物解析**：DAG 运行不存在 legacy `{slug}/04-plan-*` /
|
||||
`{slug}/03-design-*` 页面，条目 1.5 引用的验收条件页
|
||||
`{slug}/04-plan-05-acceptance-criteria` 按 DAG-route read map 解析：
|
||||
→ 节点 `acceptance_criteria`（`{epic-slug}/dag`，含
|
||||
`{epic-slug}/dag-nodes/{node-id}` 下沉子页）或节点工单正文显式标注；
|
||||
standalone 模式以请求本身为规格。
|
||||
|
||||
---
|
||||
|
||||
## 1. DoD 矩阵完整性检查（DOD — Definition of Done Matrix）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | ---------------------------------------------------------------------- | ---- | ------ | ---- |
|
||||
| 1.1 | DoD 矩阵中每一条验收条件有明确判定（PASS/FAIL/UNVERIFIABLE） | ☐ | ☐ | |
|
||||
| 1.2 | 每个 PASS 判定有可验证的证据（测试名称、命令输出、测量值） | ☐ | ☐ | |
|
||||
| 1.3 | 每个 FAIL 判定注明了具体差距（期望值 vs 实测值） | ☐ | ☐ | |
|
||||
| 1.4 | UNVERIFIABLE 项标记了原因（缺测试/缺工具/缺基线）并标注了重新激活路径（目标 chunk+iteration）。不可仅标注"未来处理"（wishlist） | ☐ | ☐ | |
|
||||
| 1.5 | DoD 矩阵覆盖本迭代的全部需求（与 wiki page `{slug}/04-plan-05-acceptance-criteria` 对照） | ☐ | ☐ | |
|
||||
| 1.6 | DoD 表中声明的每个测试用例 ID 在代码库中存在、本轮已运行且通过；缺失或未通过项记为 FAIL 并注明差距（期望断言 vs 实际）。`MANUAL`/`BENCH` 条目须附人工记录或基准输出 | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 2. 测试完备性检查（TST — Test Suite Completeness）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | ----------------------------------------------- | ---- | ------ | ---- |
|
||||
| 2.1 | `bun run test:parallel` 全部通过（或项目等同命令）。单次执行：同一棵树只跑一次，结果同时用于 DoD 判定与回归分类（5.1），仅当代码在验证中途变更时重跑 | ☐ | ☐ | |
|
||||
| 2.2 | 单元测试 + 集成测试均已运行（若项目有分离命令） | ☐ | ☐ | |
|
||||
| 2.3 | 所有测试输出已捕获，失败用例有详细记录 | ☐ | ☐ | |
|
||||
| 2.4 | 对于使用 `git worktree add/remove` 的模块，`test:parallel` 可能因 git 内部文件锁定而挂起。接受隔离/串行测试结果（`bun test <file> --timeout 120000`）并通过，并注明 TST-GIT-CONTENTION | ☐ | ☐ | |
|
||||
| 2.5 | 已统计本轮 flaky test（间歇性失败/跳过）数量并与基线对比；新增 flaky test 需追溯根因并路由回 Developer；本轮未修复的 flaky test 已在 Phase 5.56 登记为 `flaky-test` labeled issue（FT-NNN） | ☐ | ☐ | |
|
||||
| 2.6 | E2E 浏览器可用性已检查（`npx playwright install --dry-run` 或等效命令）。若浏览器未安装，E2E 相关 DoD 条目预标记为 `⚠️ UNVERIFIABLE — Playwright browsers not installed`，并在 reactivation trigger 中注明安装命令。禁止在无浏览器环境中对 E2E 条目标记 PASS | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 3. 构建与类型检查（BLD — Build & Typecheck）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | ----------------------------------------- | ---- | ------ | ---- |
|
||||
| 3.1 | `bun typecheck` 无错误（或项目等同命令） | ☐ | ☐ | |
|
||||
| 3.2 | `bun lint` 无错误（警告可记录但非阻断） | ☐ | ☐ | |
|
||||
| 3.3 | 构建产物可正常生成（如项目有 build 步骤） | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 4. 非功能需求验证（NFR — Non-Functional Requirements）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | ----------------------------------------------------------- | ---- | ------ | ---- |
|
||||
| 4.1 | 本迭代覆盖的每个性能指标已测量（P50/P95/P99、吞吐量） | ☐ | ☐ | |
|
||||
| 4.2 | 性能指标与设计阈值和基线（前次迭代）双重对比 | ☐ | ☐ | |
|
||||
| 4.3 | 性能超出阈值的指标有差距分析和 profiling 热点 | ☐ | ☐ | |
|
||||
| 4.4 | 安全扫描已执行，无新高危漏洞引入 | ☐ | ☐ | |
|
||||
| 4.5 | 如无自动性能/安全测试，已标注为 UNVERIFIABLE 并建议具体工具 | ☐ | ☐ | |
|
||||
| 4.6 | 前端：Lighthouse / Core Web Vitals 性能评分未下降（FCP/LCP/TBT/CLS 均在阈值内） | ☐ | ☐ | |
|
||||
| 4.7 | 前端：bundle 体积分析已运行，无预期外增长（新增 chunk > 50KB 需说明理由） | ☐ | ☐ | |
|
||||
| 4.8 | 前端：axe-core / Lighthouse a11y 扫描无新增违规项 | ☐ | ☐ | |
|
||||
| 4.9 | 前端：可访问性（键盘导航、屏幕阅读器、对比度）已验证通过 | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 5. 回归检查（REG — Regression）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | ---------------------------------------------- | ---- | ------ | ---- |
|
||||
| 5.1 | 之前迭代通过的测试全部继续通过（零回归）——复用 2.1 同一次全量运行的结果判定，不重复执行 | ☐ | ☐ | |
|
||||
| 5.2 | 任何回归有失败单元测试名和可能原因分析 | ☐ | ☐ | |
|
||||
| 5.3 | 如无之前迭代的测试基线，首次迭代此项标记为 N/A | ☐ | ☐ | |
|
||||
| 5.4 | 用引用缺失/空 `{file:...}` 令牌的可选配置启动 TUI/CLI，确认启动不崩溃。回归测试位于 `<harness-package>/test/config/config-content-substitution.test.ts` | ☐ | ☐ | |
|
||||
| 5.5 | 每个失败用例已在 base 分支/最近绿色 commit 上单独复跑并分类：base 上也失败 → 预先存在（BF，Phase 5.55 登记）；base 通过本分支失败 → 回归（阻塞并路由 Developer）。禁止把预先存在失败当作"别人的问题"丢弃 | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 6. 报告完整性检查（RPT — Report Completeness）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | --------------------------------------------------------------------- | ---- | ------ | ---- |
|
||||
| 6.1 | 验证报告写入 wiki `{slug}/05-verify-iteration-{N}`（via `wiki 读写 API（见 TERMINOLOGY）`） | ☐ | ☐ | |
|
||||
| 6.2 | 报告包含 DoD 矩阵汇总（PASS/FAIL/UNVERIFIABLE 计数） | ☐ | ☐ | |
|
||||
| 6.3 | 报告包含 NFR 验证结果 | ☐ | ☐ | |
|
||||
| 6.4 | 报告包含回归检查状态 | ☐ | ☐ | |
|
||||
| 6.5 | 报告包含 FAIL 项的处理路径（路由回 Developer 或标记为已知） | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 7. 上下文卫生验证（CTX — Context Hygiene）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| ---- | ----------------------------------------------------------------------------------------------- | ---- | ------ | ---- |
|
||||
| 7.1 | 迭代执行中每个 stage 边界执行了压缩，或确认上下文未超限无需压缩 | ☐ | ☐ | |
|
||||
| 7.2 | 每次压缩后重读了 wiki `{slug}/` 页面恢复当前 slug/stage（非仅依赖压缩摘要）；读取模式见 `_shared/gitea-read-patterns.md`（deprecated: `.artifacts/{slug}/`） | ☐ | ☐ | |
|
||||
| 7.3 | 多轮 review 的 round 边界压缩遵循（round ≥ 2 时 compact + 重读 synthesis comment 与 commit status（`octopus review status --stage ...`）） | ☐ | ☐ | |
|
||||
| 7.4 | 未在 stage 中途（tool-call 循环 / sub-agent 派发过程中）执行压缩 | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 8. 技术债务登记检查（TD-LOCAL — Tech Debt Local Registration）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | --------------------------------------------------------------------- | ---- | ------ | ---- |
|
||||
| 8.1 | 本迭代全部 UNVERIFIABLE / ACCEPTED_RISK / `[OPEN]` 项均已登记为源票 `## TD 登记` 评论中的行（registry-first，`ticket-lifecycle.md`；`filing.sprint-mode: true` 期间禁止升格独立票） | ☐ | ☐ | |
|
||||
| 8.2 | 每行含 `TD-NNN`、type、Severity、origin、一句话摘要与可客观验证的 Reactivation Trigger；TD-NNN 为注册期分配——经 `script/td-alloc.sh` 从号段台账（TD allocation ledger，常设 tracker）取号，任何分配必须先落台账 td-alloc 评论（[org-internal #3322] 互斥） | ☐ | ☐ | |
|
||||
| 8.3 | 两处登记的 `TD-NNN` 标识一致，且每项都有可客观验证的 Reactivation Trigger | ☐ | ☐ | |
|
||||
| 8.4 | 邻近配额复核（[org-internal #3002] G3）：报告含本迭代触碰区域的登记册带走情况（consumed/applicable，或 `0 applicable`）；与本 run 的债务配额记录一致（legacy roadmap 状态追踪表已归档，[org-internal #3072] phase 3） | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 9. 基线失败登记检查（BF-LOCAL — Baseline-Failure Registration）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| --- | --------------------------------------------------------------------- | ---- | ------ | ---- |
|
||||
| 9.1 | 本迭代全部预先存在失败（Phase 2.6 分类为 pre-existing）均已创建为 Gitea issue（label `baseline-failure`，via `工单 API（见 TERMINOLOGY）list(labels="baseline-failure")` 可查） | ☐ | ☐ | |
|
||||
| 9.2 | 每个 baseline-failure issue 含 `BF-NNN`（标题）、Test 标识、Severity（Priority label）、`## Parent` 交叉链接、可在 base commit 复现的 Reproduction 步骤 | ☐ | ☐ | |
|
||||
| 9.3 | 已对存量 `baseline-failure` issue 去重（按 failure signature 匹配——错误/断言形状 + 受影响表面，同一根因家族可跨多个测试，与 verify Phase 5.55 及 `core/rules/ticket-lifecycle.md` BF 家族伞口径一致），未重复登记已知失败；若本迭代修复了既有 BF，已关闭对应 issue 并引用修复 commit（编号/去重规则见 `core/rules/testing.md`） | ☐ | ☐ | |
|
||||
| 9.4 | 验证报告 "Baseline Failures (Pre-existing)" 段落记录了 `BF-NNN → #NNNN` 映射（无则记 "0 baseline failures"）；未登记任何失败时本节为空方为通过 | ☐ | ☐ | |
|
||||
|
||||
---
|
||||
|
||||
## 10. Flaky Test 登记检查（FT-LOCAL — Flaky-Test Registration）
|
||||
|
||||
| # | 检查项 | 通过 | 不通过 | 备注 |
|
||||
| ---- | --------------------------------------------------------------------- | ---- | ------ | ---- |
|
||||
| 10.1 | 本迭代全部未修复 flaky test 均已创建为 Gitea issue（label `flaky-test`，via `工单 API（见 TERMINOLOGY）list(labels="flaky-test")` 可查） | ☐ | ☐ | |
|
||||
| 10.2 | 每个 flaky-test issue 含 `FT-NNN`（标题）、Test 标识、Severity（Priority label）、Failure rate、`## Parent` 交叉链接、复现步骤（多次重跑） | ☐ | ☐ | |
|
||||
| 10.3 | 已对存量 `flaky-test` issue 去重（按 failure signature 匹配——错误/断言形状 + 受影响表面，与 verify Phase 5.56 及 `core/rules/ticket-lifecycle.md` FT 家族伞口径一致）；未重复登记已知 flaky；已稳定的 flaky 已关闭并引用修复 commit（编号/去重规则见 `core/rules/testing.md`） | ☐ | ☐ | |
|
||||
| 10.4 | 验证报告 "Flaky Tests (Intermittent)" 段落记录了 `FT-NNN → #NNNN` 映射（无则记 "0 flaky tests"） | ☐ | ☐ | |
|
||||
Reference in New Issue
Block a user