llm-intelligence/reports/openclaw/OPENCLAW_CAPABILITY_BACKLOG.md

OpenClaw Capability Backlog

本文件用于持续沉淀 OpenClaw 在 llm-intelligence 项目推进和自我优化过程中暴露出的能力缺口。

记录原则：

• 只写真实 review 暴露的问题
• 每个问题都要说明影响
• 每个建议都要可执行、可验证

---

当前未修复问题速查表（截至 2026-05-14 15:10）

#	问题	优先级	首次暴露	修复状态	影响次数
1	验证器 rg 依赖误报	P0	05-07 22:50	✅ 已修复（05-10 14:30 确认 grep 替换完成）	10 次
2	验证器退出码设计	P0	05-07 22:50	⚠️ 部分（rg 误报消除，但三级状态仍未实现）	10 次
3	session 历史工具/业务错误区分	P1	05-07 22:50	❌ 未修复	11 次
4	cron 无主动状态报告机制	P1	05-07 22:50	❌ 未修复	11 次
5	subagent spawn 未传递 workspace	P1	05-07 22:50	❌ 未修复	11 次
6	验收脚本无法检测构建	P1	05-08 09:05	❌ 未修复	10 次
7	环境变量/API Key 缺失未自动检测	P1	05-08 09:05	⚠️ 部分（已写入 review 标准步骤，但未固化到 prompt）	10 次
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	❌ 未修复（虽有新 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 文件）	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	❌ 未修复	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	⚠️ 待复核（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，继续是最老化、最真实的系统性风险。**

本次新增发现

• 综合验收当前恢复正常：bash scripts/verify_phase6.sh 返回 SUMMARY pass=14 fail=0 warn=0 与 PHASE_RESULT: PASS，说明主链路当前可运行。
• 上一轮 FAIL 更像瞬时状态，不足以直接定性为结构性回归：至少在本轮时间窗口内，Phase 3/Phase 6 未再失败。
• review 的长期主风险未变：最后 commit 仍停在 ba054f0（2026-05-08），大量 modified/untracked 仍存在，导致“功能已做出但无版本锚点”的风险继续累积。
• CI 证据仍停留在 artifact-present：.github/ 虽存在，但仍未进入 git 历史，也没有本轮可引用的真实 workflow run 结果。

问题 21（P1）：验收脚本瞬时回归缺少稳定性标记（再次确认）

• 09:30 状态：上一轮 review 记录 verify_phase6.sh FAIL，本轮同命令恢复 PASS。
• 影响：
  • 单次 FAIL 容易被 review 写成结构性故障
  • backlog 会积累“本轮失败、下轮恢复”的噪声，降低长期可读性
  • 团队可能误把短时波动当成实现回归，分散精力
• 优化建议：
  1. review prompt 中增加“单次 FAIL 先标记为 transient-suspect，连续复现或稳定复现后再升级为结构性问题”
  2. Phase 验收脚本失败后，若成本允许，自动补跑一次最小复验命令，区分瞬时波动与稳定故障
  3. backlog 条目增加“复现状态”字段，如 single-hit / repeated / reproducible
• 建议验证方法：后续若再次出现单轮 FAIL，要求下一轮或同轮最小复验后再决定是否升级 backlog 严重度

问题 23（P0→待复核）：日报归档路径门禁失配

• 09:30 状态：本轮未复现。bash scripts/verify_phase6.sh 已整体 PASS，说明上一轮的 Phase 3/归档门禁异常当前不是稳定故障。
• 影响：
  • 若未来复现，仍会级联拖累综合验收判断
  • 但在本轮证据下，不应继续把它包装成“当前稳定存在的结构性 P0 故障”
• 优化建议：
  1. 保留条目，但状态降级为“待复核/瞬时问题”
  2. 下次若再触发，必须同时保存失败时的期望路径与实际路径
  3. 在 review 里区分“当前活跃故障”和“历史单次异常”
• 建议验证方法：未来若再次出现 Phase 3 FAIL，立即单独执行 bash scripts/verify_phase3.sh 并采集路径证据；若连续两轮复现，再升回结构性问题

问题 24（P1）：综合验收错误聚合误导根因判断

• 09:30 状态：本轮虽未触发 FAIL，但问题仍未修复，因为顶层脚本的失败聚合可读性并未被专门改进。
• 影响：
  • 下一次综合验收失败时，review 仍可能被顶层压缩输出误导
  • 人工下钻成本高，容易产生二次误报
• 优化建议：
  1. verify_phase6.sh 在调用 verify_pre_phase6.sh 失败时直接输出失败 phase 名称
  2. verify_pre_phase6.sh 增加失败 phase 列表摘要
  3. review prompt 固化“综合门禁 FAIL 必须下钻子 phase”规则
• 建议验证方法：人为制造单个子 phase 失败，确认顶层输出能直接定位到具体失败 phase 与失败项

---

已归档问题（修复后移入）

2026-05-10 14:30 — 问题 1 归档：验证器 rg 依赖误报

• 首次暴露：2026-05-07 22:50
• 修复时间：2026-05-10 14:30 前
• 修复方式：TASKS.md 中 T-1.1 和 T-3.2 的验证命令从 rg -n 替换为 grep -nE
• 验证方法：go run scripts/verification_executor.go 在无 rg 环境下返回 PASS
• 残余注意：验证器本身仍未实现 toolchain readiness check 和三级状态

2026-05-11 14:30 — 问题 17 归档：collection_stats vs collector_stats 表名不一致

• 首次暴露：2026-05-11 09:30（误报）
• 澄清时间：2026-05-11 14:30
• 澄清方式：二次验证 grep -n "collector_stats" scripts/verify_phase2.sh 确认脚本与 schema 一致
• 根因：09:30 review 未实际验证即复制了错误结论
• 教训：review 中的 "不一致" 声称必须二次验证，不能仅凭记忆或旧报告复制

---

Backlog 最后更新：2026-05-14 15:10 Asia/Shanghai