niuniu/llm-intelligence
1
0
Fork 1
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(runtime): sync execution and backlog status

Browse Source 
Update README, execution notes, runtime remediation plan, and OpenClaw backlog to reflect the current pipeline split, CI/Phase 5 status, and latest review findings.

Keep this separate from collector code so operational documentation history remains reviewable.
This commit is contained in:
phamnazage-jpg
2026-05-15 22:43:21 +08:00
parent 0ee181a4a7
commit 42e75e733d
4 changed files with 140 additions and 126 deletions
Download Patch File Download Diff File Expand all files Collapse all files

195
reports/openclaw/OPENCLAW_CAPABILITY_BACKLOG.md
View File

@@ -10,7 +10,7 @@
---
## 当前未修复问题速查表（截至 2026-05-14 15:10）
## 当前未修复问题速查表（截至 2026-05-15 21:31）
| # | 问题 | 优先级 | 首次暴露 | 修复状态 | 影响次数 |
|---|------|--------|----------|----------|----------|
@@ -20,151 +20,122 @@
| 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 次 |
| 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，但工作区长期非干净问题仍在）** | **13 次** |
| 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 文件）** | **8 次** |
| 15 | **CI 配置存在但未验证运行** | **P1** | **05-10 21:30** | **❌ 未修复（且当前已暴露出更前置的 CI 文件缺失）** | **8 次** |
| 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** | **❌ 未修复** | **5 次** |
| 20 | **untracked 文件统计遗漏** | **P1** | **05-11 14:30** | **❌ 未修复** | **4 次** |
| 21 | **验收脚本瞬时回归缺少稳定性标记** | **P1** | **05-12 22:46** | **❌ 未修复（仍缺 transient / repeated / reproducible 标记）** | **4 次** |
| 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 上午与下午均未复现）** | **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 次** |
| 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-14 15:10（第 20 次 review，afternoon-review）
### 2026-05-15 21:31（第 25 次 review，night-review）
> **前置说明**：距上一次 review（05-14 09:31）约 **5 小时 39 分钟**。本轮不是“无 delta”场景：上午 live 结论还是“唯一 blocker 为 CI 文件缺失”，但下午 `verify_phase6.sh` 新增暴露了第二个活跃 FAIL——**最近 7 次采集成功率未达到 95%**。这说明上午结论到下午已老化，必须显式更新 current truth，而不能机械复用旧短句。**
> **前置说明**：距上一次 review（05-15 15:11）约 **6 小时 18 分钟**。本轮没有拿到足够新证据去推翻 afternoon 的主判断：Phase 1~5 当前仍 PASS，但 Phase 6 不能在证据不足的情况下直接改写成 PASS。与此同时，工作区持续堆积 tracked/untracked 变更而最新 commit 未前进，说明版本化收口继续老化。
#### 本次新增发现
- **功能主链路仍可运行**：`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 次样本窗口明细与失败分布。
- **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 默认策略需要更主动地发现这些入口。
#### 问题 26（P1）：Phase 6 稳定性门禁失败缺少样本窗口摘要
#### 问题 28（P1，再次确认）：脚本型 Go 仓库缺少可测试入口发现能力
- **15:10 状态**：`bash scripts/verify_phase6.sh` 当前 FAIL 于 `最近 7 次采集成功率达到 95%`，但顶层输出未直接打印 7 次样本 success/fail 明细，也未显示失败记录的时间点或原因。
- **21:31 状态**：本轮继续确认本仓库的可信入口是 `verify_pre_phase6` / `verify_phase6` / `run_daily.sh` 等项目脚本，而不是通用语言惯性命令。
- **问题影响**：
- review 能知道“没过线”，但不能立刻知道“为什么没过线”
- 人工需要额外补查数据库或脚本，增加定位成本
- 容易把稳定性问题简化成单次瞬时波动，或反过来把单次波动误判成结构性回归
- reviewer 或 agent 若先跑错误入口，会得到假阴性或低价值结果
- review 成本上升，因为需要再次回到仓库声明的真实入口
- 同类脚本型仓库会重复暴露相同问题
- **优化建议**：
1. 在 `verify_phase6.sh` 的成功率门禁失败时，直接追加最近 7 次 `collector_stats` 的时间、success、source、error 摘要
2. 把输出拆成两层：`threshold failed` + `sample window details`
3. 若失败原因为单一 source 或单一时间窗口，输出聚合计数，方便区分系统性问题与单次异常
1. review/verification 默认先搜 `Makefile`、verify 脚本、README 中的“常用命令/门禁入口”
2. 若仓库显式声明入口，优先使用声明入口而不是语言通用命令
3. 将“入口不适配”与“测试失败”分开标注
- **优先级**：P1
- **建议验证方法**：人为制造一条失败采集记录或在测试环境插入样本，确认 `verify_phase6.sh` 失败时能直接打印最近 7 次窗口详情，而不是只给阈值结论
- **建议验证方法**：后续在脚本型 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:10 状态**：上午报告中的“直接阻塞只剩 CI 缺失”到下午已经不成立，因为 afternoon live verifier 新增了稳定性门禁 FAIL。
- **15:11 状态**：同日两次 review 的主 blocker 没变，但严重度已变化；如果 afternoon 不 live 复验，仍会沿用 morning 的 `5/7` 窗口，低估风险老化。
- **问题影响**：
- 若 review 系统不显式提醒“旧结论已老化”，读者容易把上午 snapshot 当成下午 current truth
- 会让 backlog 和日报式 review 低估动态门禁的时效性
- 同日数小时内窗口数字会变化，旧结论若不失效会直接误导风险判断
- backlog 和 follow-up 可能继续引用过时窗口，影响优先级排序
- **优化建议**：
1. 在 review 模板中保留并强化“与上一次 review 的 delta”字段
2. 当 live verifier 结果与上一轮关键短句不一致时，要求显式写出“旧口径已失效”
3. backlog 中对这类问题持续单独计数，不与普通误报混写
1. review 模板在涉及样本窗口时强制写“sample timestamp / sample size / sample freshness”
2. 若当前窗口与上一轮数值不同，必须显式写出 `window changed` 或 `old sample expired`
3. 对同日多次 review 的窗口漂移单独累计，而不是只记泛化的误报传播
- **优先级**：P1
- **建议验证方法**：后续若同日两次 review 间 verifier 结果变化，检查新报告是否明确标出“旧结论已失效/已老化”而非沿用旧摘要
- **建议验证方法**：后续若同日两次 review 的窗口成功率变化，检查新报告是否显式指出窗口已变化，而不是继续复用上一轮数字
#### 问题 24（P1，仍未修复）：综合验收错误聚合误导根因判断
#### 问题 27（P1，再次确认）：Phase 6 稳定性门禁未区分前置条件缺失 vs 真实采集失败
- **15:10 状态**：本轮再次证明顶层 `verify_phase6.sh` 只会聚合出 `Phase 1~5 总门禁通过` FAIL，仍需要继续手工下钻到 `verify_pre_phase6.sh` 才能定位具体失败落在 Phase 5。
- **15:11 状态**：最新 7 条样本中 3 条失败全部来自 `openrouter`，且错误一致为 `严格真实模式下必须提供 API Key`。
- **问题影响**：
- 若 review 停在顶层，会把聚合 FAIL 当成根因
- 一旦叠加其他顶层 FAIL（本轮就是成功率门禁），读者更难区分“生产收口问题”与“运行稳定性问题”
- 稳定性统计继续把环境/调度问题混进 collector 运行失败
- review 读者可能误把 57.14% 成功率解读为采集器代码不稳定
- 修复资源会被错误投向代码层，而不是运行环境/统计口径
- **优化建议**：
1. `verify_phase6.sh` 失败时直接回显 `verify_pre_phase6.sh` 的失败 phase 名称
2. 失败输出按 blocker 分类：`artifact missing`、`runtime instability`、`aggregated dependency fail`
1. 在 `verify_phase6.sh` 或其依赖查询中增加失败分类，至少区分 `precondition-missing`、`collector-runtime-failure`、`external-provider-failure`
2. 对缺 API Key / 缺 DB 权限这类前置条件失败单独统计并显式展示
3. 输出中附最近 N 条失败样本摘要，避免只给一个成功率数字
- **优先级**：P1
- **建议验证方法**：人为保持一个子 phase 失败并再触发一个顶层附加 FAIL，确认输出能直接区分不同 blocker 类别
- **建议验证方法**：制造一条缺 API Key 失败和一条真实采集失败，确认 Phase 6 输出能分别标记类别，并在 review 中直接映射到不同修复路径
---
#### 问题 28（P1）：脚本型 Go 仓库缺少可测试入口发现能力
### 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 会积累“本轮失败、下轮恢复”的噪声，降低长期可读性
- 团队可能误把短时波动当成实现回归，分散精力
- **15:11 状态**：本轮尝试常见 Go 测试入口 `go test ./scripts/...`，结果为 `matched no packages` / `no packages to test`；但仓库真实可执行门禁位于 `Makefile` 和 `scripts/verify_phase*.sh`。
- **问题影响**：
- agent 若按通用语言惯性选命令，会得到假阴性，误判仓库“不可测试”或“测试失败”
- review 成本上升，因为需要人工再纠正到项目自定义验证入口
- 跨项目迁移时，这类误用会持续产生噪声
- **优化建议**：
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*
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 脚本，并把错误类型归为入口不适配