# OpenClaw Capability Backlog

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

记录原则：

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

---

## 当前未修复问题速查表（截至 2026-05-15 21:31）

| # | 问题 | 优先级 | 首次暴露 | 修复状态 | 影响次数 |
|---|------|--------|----------|----------|----------|
| 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） | 11 次 |
| 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，但工作区长期非干净问题仍在）** | **14 次** |
| 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 文件）** | **10 次** |
| 15 | **CI 配置存在但未验证运行** | **P1** | **05-10 21:30** | **✅ 已修复（05-14 16:23 已补齐 `.github/workflows/ci.yml` 且 `verify_phase5.sh` PASS）** | **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** | **❌ 未修复** | **7 次** |
| 20 | **untracked 文件统计遗漏** | **P1** | **05-11 14:30** | **❌ 未修复** | **5 次** |
| 21 | **验收脚本瞬时回归缺少稳定性标记** | **P1** | **05-12 22:46** | **❌ 未修复（仍缺 transient / repeated / reproducible 标记）** | **5 次** |
| 22 | **无 delta 场景缺少老化风险优先策略** | **P2** | **05-12 22:46** | **❌ 未修复** | **3 次** |
| 23 | **日报归档路径门禁失配** | **P0** | **05-13 00:15** | **✅ 已复核（05-14 16:23 再验证未复现，`verify_phase3.sh` PASS）** | **1 次** |
| 24 | **综合验收错误聚合误导根因判断** | **P1** | **05-13 00:15** | **❌ 未修复** | **3 次** |
| 25 | **snapshot truth 与 current truth 漂移未被显式提示** | **P1** | **05-14 09:31** | **❌ 未修复** | **5 次** |
| 26 | **Phase 6 稳定性门禁失败缺少样本窗口摘要** | **P1** | **05-14 15:10** | **❌ 未修复** | **4 次** |
| 27 | **Phase 6 稳定性门禁未区分前置条件缺失 vs 真实采集失败** | **P1** | **05-14 21:30** | **❌ 未修复** | **3 次** |
| 28 | **脚本型 Go 仓库缺少可测试入口发现能力** | **P1** | **05-15 15:11** | **❌ 未修复** | **2 次** |
| 29 | **长命令部分回传时缺少保守结论模板** | **P1** | **05-15 21:31** | **❌ 未修复** | **1 次** |

---

## Review 日志

### 2026-05-15 21:31（第 25 次 review，night-review）

> **前置说明**：距上一次 review（05-15 15:11）约 **6 小时 18 分钟**。本轮没有拿到足够新证据去推翻 afternoon 的主判断：Phase 1~5 当前仍 PASS，但 Phase 6 不能在证据不足的情况下直接改写成 PASS。与此同时，工作区持续堆积 tracked/untracked 变更而最新 commit 未前进，说明版本化收口继续老化。

#### 本次新增发现

- **Phase 1~5 当前继续 PASS**：`verify_pre_phase6.sh` 本轮再次完整通过。
- **night 时点无证据证明主 blocker 已消失**：`verify_phase6.sh` 本轮只回传到前半段 PASS，未拿到完整结束输出，因此不能把历史活跃 blocker 直接宣告解除。
- **工作区非干净风险继续老化**：tracked 修改和 untracked 新文件仍然很多，但最近提交未前进。
- **仓库已明确给出推荐验证入口**：`Makefile`、`README.md`、`scripts/verify_phase*.sh` 都提供了更可信入口，说明 agent 默认策略需要更主动地发现这些入口。

#### 问题 28（P1，再次确认）：脚本型 Go 仓库缺少可测试入口发现能力

- **21:31 状态**：本轮继续确认本仓库的可信入口是 `verify_pre_phase6` / `verify_phase6` / `run_daily.sh` 等项目脚本，而不是通用语言惯性命令。
- **问题影响**：
  - reviewer 或 agent 若先跑错误入口，会得到假阴性或低价值结果
  - review 成本上升，因为需要再次回到仓库声明的真实入口
  - 同类脚本型仓库会重复暴露相同问题
- **优化建议**：
  1. review/verification 默认先搜 `Makefile`、verify 脚本、README 中的“常用命令/门禁入口”
  2. 若仓库显式声明入口，优先使用声明入口而不是语言通用命令
  3. 将“入口不适配”与“测试失败”分开标注
- **优先级**：P1
- **建议验证方法**：后续在脚本型 Go 仓库中，先读取 `Makefile`/README，再检查 agent 是否直接选择仓库声明入口，而不是默认 `go test ./...`

#### 问题 29（P1）：长命令部分回传时缺少保守结论模板

- **21:31 状态**：本轮 `verify_phase6.sh` 已回传多条 PASS，但未在当前对话拿到完整结束输出；如果没有明确模板，review 很容易在“部分好消息”下过度乐观，或反过来因为等待完整输出而卡死。
- **问题影响**：
  - 容易把“部分通过”错误表述为“全部通过”
  - 也可能因为追求完整输出导致 cron review 超时
  - 对低频 review 任务尤其危险，因为一轮结论可能被后续长期复用
- **优化建议**：
  1. 当长命令只返回部分输出时，模板强制要求写明 `partial runtime evidence` 与 `old blocker not disproven`
  2. 为 review 类 cron 任务增加“最小证据阈值”：超过阈值就允许先落保守结论，不必无限等待
  3. 在 backlog / review 模板中增加“完整结束输出是否已获得”字段
- **优先级**：P1
- **建议验证方法**：在长命令故意延迟或只部分回传的场景下，检查 agent 是否能稳定写出“部分通过、旧 blocker 未证伪”的保守结论，而不是误报 PASS 或无期限阻塞

### 2026-05-15 15:11（第 24 次 review，afternoon-review）

> **前置说明**：距上一次 review（05-15 09:30）约 **5 小时 41 分钟**。本轮没有出现新的主 blocker，但稳定性窗口比 morning 更差：最新 7 条 `collector_stats` 中仅 **4 条成功、3 条失败**，成功率约 **57.14%**。3 条失败全部是 **严格真实模式缺 API Key**，说明 Phase 6 仍在被前置条件缺失污染，而且问题在老化。

#### 本次新增发现

- **Phase 1~5 当前继续 PASS**：`verify_pre_phase6.sh` 仍全绿，说明主链路与前置门禁未回退。
- **Phase 6 唯一 live blocker 仍是稳定性门禁**：`verify_phase6.sh` 继续表现为 `pass=15 fail=1`。
- **稳定性窗口较 morning 进一步恶化**：从 `5/7` 成功下降到 `4/7` 成功，不能再沿用上午窗口数字。
- **失败样本仍全部指向前置条件缺失**：最近 3 条失败都为 `严格真实模式下必须提供 API Key`。
- **通用 `go test ./scripts/...` 在本仓库给出假阴性**：命令返回 `matched no packages` / `no packages to test`，但仓库声明的 `verify_phase*.sh` 却能提供有效验证结果。

#### 问题 25（P1，再次确认）：snapshot truth 与 current truth 漂移未被显式提示

- **15:11 状态**：同日两次 review 的主 blocker 没变，但严重度已变化；如果 afternoon 不 live 复验，仍会沿用 morning 的 `5/7` 窗口，低估风险老化。
- **问题影响**：
  - 同日数小时内窗口数字会变化，旧结论若不失效会直接误导风险判断
  - backlog 和 follow-up 可能继续引用过时窗口，影响优先级排序
- **优化建议**：
  1. review 模板在涉及样本窗口时强制写“sample timestamp / sample size / sample freshness”
  2. 若当前窗口与上一轮数值不同，必须显式写出 `window changed` 或 `old sample expired`
  3. 对同日多次 review 的窗口漂移单独累计，而不是只记泛化的误报传播
- **优先级**：P1
- **建议验证方法**：后续若同日两次 review 的窗口成功率变化，检查新报告是否显式指出窗口已变化，而不是继续复用上一轮数字

#### 问题 27（P1，再次确认）：Phase 6 稳定性门禁未区分前置条件缺失 vs 真实采集失败

- **15:11 状态**：最新 7 条样本中 3 条失败全部来自 `openrouter`，且错误一致为 `严格真实模式下必须提供 API Key`。
- **问题影响**：
  - 稳定性统计继续把环境/调度问题混进 collector 运行失败
  - review 读者可能误把 57.14% 成功率解读为采集器代码不稳定
  - 修复资源会被错误投向代码层，而不是运行环境/统计口径
- **优化建议**：
  1. 在 `verify_phase6.sh` 或其依赖查询中增加失败分类，至少区分 `precondition-missing`、`collector-runtime-failure`、`external-provider-failure`
  2. 对缺 API Key / 缺 DB 权限这类前置条件失败单独统计并显式展示
  3. 输出中附最近 N 条失败样本摘要，避免只给一个成功率数字
- **优先级**：P1
- **建议验证方法**：制造一条缺 API Key 失败和一条真实采集失败，确认 Phase 6 输出能分别标记类别，并在 review 中直接映射到不同修复路径

#### 问题 28（P1）：脚本型 Go 仓库缺少可测试入口发现能力

- **15:11 状态**：本轮尝试常见 Go 测试入口 `go test ./scripts/...`，结果为 `matched no packages` / `no packages to test`；但仓库真实可执行门禁位于 `Makefile` 和 `scripts/verify_phase*.sh`。
- **问题影响**：
  - agent 若按通用语言惯性选命令，会得到假阴性，误判仓库“不可测试”或“测试失败”
  - review 成本上升，因为需要人工再纠正到项目自定义验证入口
  - 跨项目迁移时，这类误用会持续产生噪声
- **优化建议**：
  1. 在 OpenClaw review/verification 流程中优先发现并使用 `Makefile`、`package.json scripts`、仓库显式 verify 脚本，而不是默认语言通用命令
  2. 若检测到 `go test ./...` 或其子路径返回 `no packages to test`，应把它标记为“入口不适配”而非“测试失败”
  3. 在 review 模板中增加一条“验证入口发现结果”，明确当前仓库推荐的最小可信命令
- **优先级**：P1
- **建议验证方法**：在至少一个脚本型 Go 仓库中复现 `no packages to test`，确认 agent 最终能回退到项目声明的 verify 脚本，并把错误类型归为入口不适配