# 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*