feat(runtime): harden daily pipeline audit and verification

Tighten real-ingestion success rules, separate scheduled reports from historical rebuilds, and persist source-level runtime audit across daily pipeline runs.

Also add the Phase 5 CI workflow contract plus verification updates and supporting docs so the full uncommitted change set can be validated together.

reports/openclaw/OPENCLAW_CAPABILITY_BACKLOG.md

@@ -10,7 +10,7 @@
 
 ---
 
-## 当前未修复问题速查表（截至 2026-05-13 09:30）
+## 当前未修复问题速查表（截至 2026-05-14 15:10）
 
 | # | 问题 | 优先级 | 首次暴露 | 修复状态 | 影响次数 |
 |---|------|--------|----------|----------|----------|
@@ -24,25 +24,79 @@
 | 8 | 文件修改后未触发 commit 提示 | P2→P1 | 05-08 09:05 | ❌ 未修复 | 12 次 |
 | 9 | cron review 无 delta 时空转 | P1 | 05-08 09:12 | ❌ 未修复 | 12 次 |
 | 10 | 验证模式伪进展（artifact_present 局限） | P1 | 05-08 14:30 | ❌ 未修复 | 9 次 |
-| 11 | **项目提交停滞（commit stagnation）** | **P0** | **05-08 21:30** | **❌ 未修复（最新仍停留 05-08 commit）** | **12 次** |
+| 11 | **项目提交停滞（commit stagnation）** | **P0** | **05-08 21:30** | **❌ 未修复（虽有新 commit，但工作区长期非干净问题仍在）** | **13 次** |
 | 12 | review 报告未触发修复动作 | P2→P1 | 05-08 21:30 | ❌ 未修复 | 9 次 |
 | 13 | BACKLOG 文件膨胀导致 review 成本递增 | P1 | 05-09 09:30 | ⚠️ 部分（已实施分层归档，但主文件仍在增长） | 7 次 |
-| 14 | **untracked 核心代码未入版本控制** | **P0** | **05-10 21:30** | **❌ 未修复（本轮仍大量 untracked）** | **7 次** |
-| 15 | **CI 配置存在但未验证运行** | **P1** | **05-10 21:30** | **❌ 未修复（仍仅 artifact-present）** | **7 次** |
+| 14 | **untracked 核心代码未入版本控制** | **P0** | **05-10 21:30** | **❌ 未修复（本轮仍有新 untracked 文件）** | **8 次** |
+| 15 | **CI 配置存在但未验证运行** | **P1** | **05-10 21:30** | **❌ 未修复（且当前已暴露出更前置的 CI 文件缺失）** | **8 次** |
 | 16 | **Phase 6+ 范围未定义** | **P1** | **05-10 21:30** | **❌ 未修复** | **5 次** |
 | 17 | collection_stats vs collector_stats 表名不一致 | P2 | 05-11 09:30 | ✅ **已澄清为误报**（05-11 14:30 确认 verify_phase2.sh 与 schema 一致） | 1 次 |
 | 18 | **无 .gitignore 文件** | **P1** | **05-11 14:30** | **❌ 未修复** | **3 次** |
-| 19 | **review 误报传播** | **P1** | **05-11 14:30** | **❌ 未修复** | **4 次** |
-| 20 | **untracked 文件统计遗漏** | **P1** | **05-11 14:30** | **❌ 未修复** | **3 次** |
-| 21 | **验收脚本瞬时回归缺少稳定性标记** | **P1** | **05-12 22:46** | **❌ 未修复（本轮再次证明单次 FAIL 可能下一轮恢复）** | **3 次** |
+| 19 | **review 误报传播** | **P1** | **05-11 14:30** | **❌ 未修复** | **5 次** |
+| 20 | **untracked 文件统计遗漏** | **P1** | **05-11 14:30** | **❌ 未修复** | **4 次** |
+| 21 | **验收脚本瞬时回归缺少稳定性标记** | **P1** | **05-12 22:46** | **❌ 未修复（仍缺 transient / repeated / reproducible 标记）** | **4 次** |
 | 22 | **无 delta 场景缺少老化风险优先策略** | **P2** | **05-12 22:46** | **❌ 未修复** | **3 次** |
-| 23 | **日报归档路径门禁失配** | **P0** | **05-13 00:15** | **⚠️ 待复核（本轮未复现，当前 `verify_phase6.sh` 已 PASS）** | **1 次** |
-| 24 | **综合验收错误聚合误导根因判断** | **P1** | **05-13 00:15** | **❌ 未修复** | **1 次** |
+| 23 | **日报归档路径门禁失配** | **P0** | **05-13 00:15** | **⚠️ 待复核（05-14 上午与下午均未复现）** | **1 次** |
+| 24 | **综合验收错误聚合误导根因判断** | **P1** | **05-13 00:15** | **❌ 未修复** | **2 次** |
+| 25 | **snapshot truth 与 current truth 漂移未被显式提示** | **P1** | **05-14 09:31** | **❌ 未修复** | **2 次** |
+| 26 | **Phase 6 稳定性门禁失败缺少样本窗口摘要** | **P1** | **05-14 15:10** | **❌ 未修复** | **1 次** |
 
 ---
 
 ## Review 日志
 
+### 2026-05-14 15:10（第 20 次 review，afternoon-review）
+
+> **前置说明**：距上一次 review（05-14 09:31）约 **5 小时 39 分钟**。本轮不是“无 delta”场景：上午 live 结论还是“唯一 blocker 为 CI 文件缺失”，但下午 `verify_phase6.sh` 新增暴露了第二个活跃 FAIL——**最近 7 次采集成功率未达到 95%**。这说明上午结论到下午已老化，必须显式更新 current truth，而不能机械复用旧短句。**
+
+#### 本次新增发现
+
+- **功能主链路仍可运行**：`verify_pre_phase6.sh` 中 Phase 1~4 继续 PASS，Go 测试、真实采集、API、前端测试入口仍正常。
+- **生产级总门禁当前有两个真实 blocker**：不仅有 Phase 5 的 `.github/workflows/ci.yml` 缺失，还有 Phase 6 顶层新增的“最近 7 次采集成功率达到 95%” FAIL。
+- **上午 review 结论到下午已过时**：如果继续沿用“只剩 CI 缺失”，会遗漏当前更接近生产稳定性的真实问题。
+- **顶层稳定性门禁缺少失败样本摘要**：当前只能看见阈值未达标，不能直接从输出中看到 7 次样本窗口明细与失败分布。
+
+#### 问题 26（P1）：Phase 6 稳定性门禁失败缺少样本窗口摘要
+
+- **15:10 状态**：`bash scripts/verify_phase6.sh` 当前 FAIL 于 `最近 7 次采集成功率达到 95%`，但顶层输出未直接打印 7 次样本 success/fail 明细，也未显示失败记录的时间点或原因。
+- **问题影响**：
+  - review 能知道“没过线”，但不能立刻知道“为什么没过线”
+  - 人工需要额外补查数据库或脚本，增加定位成本
+  - 容易把稳定性问题简化成单次瞬时波动，或反过来把单次波动误判成结构性回归
+- **优化建议**：
+  1. 在 `verify_phase6.sh` 的成功率门禁失败时，直接追加最近 7 次 `collector_stats` 的时间、success、source、error 摘要
+  2. 把输出拆成两层：`threshold failed` + `sample window details`
+  3. 若失败原因为单一 source 或单一时间窗口，输出聚合计数，方便区分系统性问题与单次异常
+- **优先级**：P1
+- **建议验证方法**：人为制造一条失败采集记录或在测试环境插入样本，确认 `verify_phase6.sh` 失败时能直接打印最近 7 次窗口详情，而不是只给阈值结论
+
+#### 问题 25（P1，再次确认）：snapshot truth 与 current truth 漂移未被显式提示
+
+- **15:10 状态**：上午报告中的“直接阻塞只剩 CI 缺失”到下午已经不成立，因为 afternoon live verifier 新增了稳定性门禁 FAIL。
+- **问题影响**：
+  - 若 review 系统不显式提醒“旧结论已老化”，读者容易把上午 snapshot 当成下午 current truth
+  - 会让 backlog 和日报式 review 低估动态门禁的时效性
+- **优化建议**：
+  1. 在 review 模板中保留并强化“与上一次 review 的 delta”字段
+  2. 当 live verifier 结果与上一轮关键短句不一致时，要求显式写出“旧口径已失效”
+  3. backlog 中对这类问题持续单独计数，不与普通误报混写
+- **优先级**：P1
+- **建议验证方法**：后续若同日两次 review 间 verifier 结果变化，检查新报告是否明确标出“旧结论已失效/已老化”而非沿用旧摘要
+
+#### 问题 24（P1，仍未修复）：综合验收错误聚合误导根因判断
+
+- **15:10 状态**：本轮再次证明顶层 `verify_phase6.sh` 只会聚合出 `Phase 1~5 总门禁通过` FAIL，仍需要继续手工下钻到 `verify_pre_phase6.sh` 才能定位具体失败落在 Phase 5。
+- **问题影响**：
+  - 若 review 停在顶层，会把聚合 FAIL 当成根因
+  - 一旦叠加其他顶层 FAIL（本轮就是成功率门禁），读者更难区分“生产收口问题”与“运行稳定性问题”
+- **优化建议**：
+  1. `verify_phase6.sh` 失败时直接回显 `verify_pre_phase6.sh` 的失败 phase 名称
+  2. 失败输出按 blocker 分类：`artifact missing`、`runtime instability`、`aggregated dependency fail`
+- **优先级**：P1
+- **建议验证方法**：人为保持一个子 phase 失败并再触发一个顶层附加 FAIL，确认输出能直接区分不同 blocker 类别
+
+---
+
 ### 2026-05-13 09:30（第 18 次 review，morning-review）
 
 > **前置说明**：距上一次 review（05-13 00:15）约 **9 小时 15 分钟**。本轮仓库状态的关键 delta 是：上一轮记录为 FAIL 的 `verify_phase6.sh`，本轮实际执行恢复为 **PASS**。这说明上一轮暴露的归档门禁问题当前未复现；与之相对，版本控制停滞与大量 untracked 仍无 delta，继续是最老化、最真实的系统性风险。**
@@ -113,4 +167,4 @@
 
 ---
 
-*Backlog 最后更新：2026-05-13 09:30 Asia/Shanghai*
+*Backlog 最后更新：2026-05-14 15:10 Asia/Shanghai*