From 42e75e733dd53970ddc6ccfbe2cba42cf8e9c62b Mon Sep 17 00:00:00 2001 From: phamnazage-jpg Date: Fri, 15 May 2026 22:43:21 +0800 Subject: [PATCH] docs(runtime): sync execution and backlog status 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. --- OPENCLAW_EXECUTION.md | 26 ++- README.md | 35 +++- ...5-14-runtime-trust-gap-remediation-plan.md | 10 +- .../openclaw/OPENCLAW_CAPABILITY_BACKLOG.md | 195 ++++++++---------- 4 files changed, 140 insertions(+), 126 deletions(-) diff --git a/OPENCLAW_EXECUTION.md b/OPENCLAW_EXECUTION.md index 0bb6996..71380d8 100644 --- a/OPENCLAW_EXECUTION.md +++ b/OPENCLAW_EXECUTION.md @@ -2,7 +2,7 @@ > 本文档说明宰相（AI Agent）如何在本项目内执行、验证与回收任务。 > 版本：v1.0 -> 日期：2026-05-11 +> 日期：2026-05-14 > 状态：与当前代码状态对齐 --- @@ -23,8 +23,9 @@ | 前端脚手架 | ✅ | `frontend/src/pages/Explorer.tsx` + 数据文件 | | 项目内任务管理 | ✅ | `GOALS.md` / `TASKS.md` / `AGENTS.md` | | 项目内记忆入口 | ✅ | `SESSION-STATE.md` / `MEMORY.md` / `memory/README.md` | -| 验证器 | ✅ | `scripts/verification_executor.go` + 4 个 verify 脚本 | -| OpenClaw Review | ✅ | `reports/openclaw/` 已有 13 份 review + backlog | +| 验证器 | ✅ | `scripts/verification_executor.go` + 6 个 verify 脚本 | +| CI 工作流 | ✅ | `.github/workflows/ci.yml` | +| OpenClaw Review | ✅ | `reports/openclaw/` 已有 review + backlog | **技术栈确认**：Go 1.22.2 + PostgreSQL + Vanilla JS/React（前端） @@ -66,15 +67,24 @@ [✅] 3. Explorer / Dashboard 最小可用前端落地 [✅] 4. 项目内 TASKS / GOALS / verification / execution 闭环落地 [✅] 5. 自动采集 + 日报调度闭环落地 -[✅] 6. Phase 6 综合验收通过（`verify_phase6.sh` PASS） +[✅] 6. Phase 5 CI 工作流与 Phase 3/Phase 5 验收门禁补齐 [🟡] 7. OpenClaw review / cron / verifier 质量治理持续优化 -[🟡] 8. Phase 2 多数据源扩展待规划 +[🟡] 8. Phase 6 稳定性门禁与 backlog 降噪仍在收口 ``` **下一步优先**： -1. 提高 review / cron / verifier 的真实性与降噪质量 -2. 推进 Phase 2 数据源扩展与真实验证入口 -3. 收口工程纪律：提交、CI、回写边界、报告一致性 +1. 收口 review / cron / verifier 的真实性与降噪质量 +2. 继续压缩 Phase 6 稳定性门禁、样本窗口摘要和误报传播 +3. 维持正式日报与历史重建的运行语义边界 + +### 当前运行真相 + +当前可直接引用的事实是： + +- `bash scripts/verify_phase3.sh` 已通过，`run_daily.sh` 的正式调度链已收紧真实采集判定并写入来源级运行审计 +- `bash scripts/verify_phase5.sh` 已通过，仓库已补齐 `.github/workflows/ci.yml` +- 正式日报、历史重建和手工真实复跑已分流到不同运行语义 +- `fetchLatestReport` 默认只展示正式日报，不会把历史重建当成最新正式产出 --- diff --git a/README.md b/README.md index ba3765f..d0b21a8 100644 --- a/README.md +++ b/README.md @@ -8,6 +8,15 @@ - Vite + React 前端：提供 Dashboard / Explorer 两个只读页面 - Shell 运维脚本：迁移、调度、备份、恢复、验收与性能门禁 +## 两大模块 + +项目现在按运行职责拆成两大模块： + +1. `情报采集与信号沉淀模块` + 负责真实采集、官方补录、套餐导入、目录核验，以及把“新模型 / 价格变化 / 官方发布 / 活动窗口”等关键信号物化到 `daily_signal_snapshot`。 +2. `日报与下游表达模块` + 负责消费 `models`、`region_pricing`、`subscription_plan`、`daily_signal_snapshot` 等结构化事实，生成 HTML / Markdown 日报；后续视频、卡片流、推送等形态也应挂在这一层。 + ## 当前能力边界 - 真实生产主链路是“采集/导入脚本 + PostgreSQL + 日报生成器 + API Server + Nginx” @@ -68,6 +77,21 @@ npm run dev ## 生产运行主链路 +### 第一模块独立运行 + +```bash +bash scripts/run_intel_pipeline.sh +``` + +该入口只执行第一模块： + +1. 真实采集与多源补充 +2. 官方模型价格与套餐导入 +3. 平台目录核验 +4. 每日关键信号物化到 `daily_signal_snapshot` + +它不会生成日报，适合先把“数据与信号层”单独跑通。 + ### 正式日报调度 ```bash @@ -79,11 +103,12 @@ bash scripts/run_daily.sh 1. OpenRouter 真实采集 2. 多源补充同步 3. 官方导入脚本执行 -4. 数据质量检查 -5. Markdown / HTML 日报生成 -6. 日报归档 -7. `daily_report` / `report_runs` 审计写入 -8. 失败时降级复制昨日报告并可选飞书告警 +4. 每日关键信号物化 +5. 数据质量检查 +6. Markdown / HTML 日报生成 +7. 日报归档 +8. `daily_report` / `report_runs` 审计写入 +9. 失败时降级复制昨日报告并可选飞书告警 ### 手工真实复跑 diff --git a/docs/plans/2026-05-14-runtime-trust-gap-remediation-plan.md b/docs/plans/2026-05-14-runtime-trust-gap-remediation-plan.md index 0510c0c..39d5271 100644 --- a/docs/plans/2026-05-14-runtime-trust-gap-remediation-plan.md +++ b/docs/plans/2026-05-14-runtime-trust-gap-remediation-plan.md @@ -1,6 +1,8 @@ # Runtime Trust Gap Remediation Plan > **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. +> **状态更新（2026-05-14 16:23 CST）**：三阶段已按顺序完成并落到仓库；对应提交为 `a8999ab`。 +> **最新验证**：`go test ./...`、`npm run build`（`frontend/`）、`bash scripts/verify_phase3.sh`、`bash scripts/verify_phase5.sh` 均已通过。 **Goal:** 系统性修复日报与采集链路中影响真实性和长期可信度的 3 个缺口，确保“每日定时产出”的结果来自真实采集、可审计运行、并覆盖多源数据链路。 @@ -8,6 +10,13 @@ **Tech Stack:** Bash、Go 1.22、PostgreSQL、cron、html/template +## 实施结果摘要 + +- 阶段 1：`fetch_openrouter.go` 已支持严格真实模式，正式调度不再把 mock、仅写 JSON 或旧数据误判为成功。 +- 阶段 2：日报写入已统一携带 `run_kind`、`trigger_source`、`is_official_daily`，正式日报与历史重建已分流。 +- 阶段 3：`fetch_multi_source.go` 已纳入每日调度链，并把 `selected_source_keys` / `failed_source_keys` 写入运行审计摘要。 +- Phase 5 基线文档已补齐 `.github/workflows/ci.yml`，Phase 5 门禁不再卡在 CI 文件缺失。 + --- ### Task 1: 收紧“采集成功”判定，避免 mock / 写库失败被伪装成成功 @@ -186,4 +195,3 @@ git commit -m "feat(runtime): fold multi-source sync into daily pipeline" 3. `bash scripts/verify_phase3.sh` 4. `bash scripts/verify_phase5.sh` 5. `go test ./...` - diff --git a/reports/openclaw/OPENCLAW_CAPABILITY_BACKLOG.md b/reports/openclaw/OPENCLAW_CAPABILITY_BACKLOG.md index 17460bc..57a827c 100644 --- a/reports/openclaw/OPENCLAW_CAPABILITY_BACKLOG.md +++ b/reports/openclaw/OPENCLAW_CAPABILITY_BACKLOG.md @@ -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 脚本，并把错误类型归为入口不适配