# OpenClaw Capability Backlog

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

记录原则：

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

---

## 当前未修复问题速查表（截至 2026-05-13 09:30）

| # | 问题 | 优先级 | 首次暴露 | 修复状态 | 影响次数 |
|---|------|--------|----------|----------|----------|
| 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** | **❌ 未修复（最新仍停留 05-08 commit）** | **12 次** |
| 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 次** |
| 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 次** |
| 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 次** |

---

## Review 日志

### 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-13 09:30 Asia/Shanghai*