# CLAUDE.md — openclaw-model-bridge 项目背景

> 每次新会话开始时自动读取。当前版本：v37.9.143 / 0.37.9.70（2026-06-12）

---

## 项目简介

将任意大模型（当前：Qwen3-235B + Qwen2.5-VL-72B）接入 OpenClaw（WhatsApp AI助手框架）的双层中间件，支持多模态（图片理解）。
运行于 Mac Mini (macOS)，用户：bisdom。

## 系统架构总览

```
┌─────────────────────────────────────────────────────────────────────┐
│                 用户层 (WhatsApp + Discord 双通道)                    │
└────────────────────────────┬────────────────────────────────────────┘
                             │
┌────────────────────────────▼────────────────────────────────────────┐
│  ① 核心数据通路（实时对话 + 多模态）                                  │
│                                                                     │
│  WhatsApp ←┐                                                        │
│  Discord  ←┼→ Gateway (:18789) ←→ Tool Proxy (:5002) ←→ Adapter (:5001) ←→ LLM (7 Providers) │
│  notify.sh ┘  [launchd管理]        [策略过滤+监控]       [认证+VL路由]     [Qwen3/GPT-4o/     │
│               [媒体存储]           [图片base64注入]      [Fallback降级]     Gemini/Claude/     │
│               [双通道推送]         [自定义工具注入]                         Kimi/MiniMax/GLM]  │
│                  │                [自定义工具注入]          │                               │
│                  │                    │                    │                               │
│                  │               /health ──→ /health       │                               │
│                  │               /stats (token监控)        │                               │
│                  │               /data_clean/* (REST)      │                               │
│                                                                     │
│  图片流程：Gateway存储jpg → Proxy检测<media:image> → base64注入       │
│           → Adapter检测image_url → 路由到Qwen2.5-VL → 图片理解回复    │
│  数据清洗：Gateway存储文件 → LLM调用data_clean工具 → Proxy拦截执行     │
│           → data_clean.py本地处理 → 格式化结果返回 → WhatsApp展示      │
└──────────────────┼────────────────────┼────────────────────┼────────────────────────┘
                   │                    │                    │
┌──────────────────▼────────────────────▼────────────────────▼────────────────────────┐
│  ② 定时任务层（system crontab，不经过 LLM 链路）                                     │
│                                                                                     │
│  每3h    ArXiv论文监控 ──→ KB写入 + WhatsApp+Discord推送                              │
│  每3h    HN热帖抓取 ──→ KB写入 + WhatsApp+Discord推送                                 │
│  每天×3  货代Watcher ──→ LLM分析(直接curl) + KB写入 + WhatsApp+Discord推送             │
│  每天    OpenClaw Releases ──→ LLM富摘要 + KB写入 + WhatsApp+Discord推送              │
│  每小时  Issues监控 ──→ KB写入 + WhatsApp+Discord推送                                 │
│  每天    KB晚间整理                                                                  │
│  每天    KB每日摘要 ──→ ~/.kb/daily_digest.md（LLM对话时可查）                          │
│  每周    KB跨笔记回顾 ──→ LLM深度分析 + WhatsApp+Discord推送                            │
│  每周    健康周报 ──→ WhatsApp+Discord推送                                             │
└─────────────────────────────────────────────────────────────────────────────────────┘
                                       │
┌──────────────────────────────────────▼──────────────────────────────────────────────┐
│  ③ 监控层（多级自动告警）                                                            │
│                                                                                     │
│  每30min  wa_keepalive ──→ 真实发送零宽字符 ──→ 失败则记录日志                         │
│  每小时   job_watchdog ──→ 检查所有job状态文件 + 日志扫描 ──→ 超时/失败→WhatsApp+Discord告警│
│  实时     proxy_stats ──→ token用量 + 连续错误计数 ──→ 阈值告警                       │
│  /health  三层健康端点：Gateway(:18789) → Proxy(:5002) → Adapter(:5001)              │
└─────────────────────────────────────────────────────────────────────────────────────┘
                                       │
┌──────────────────────────────────────▼──────────────────────────────────────────────┐
│  ④ DevOps层（自动部署 + 体检）                                                       │
│                                                                                     │
│  GitHub (main) ──→ auto_deploy.sh (每2min轮询)                                      │
│                     ├─ git fetch + pull                                              │
│                     ├─ 单测验证（proxy_filters变更时）                                 │
│                     ├─ 文件同步（仓库→运行时，31个文件映射）                            │
│                     ├─ 每小时漂移检测（md5全量比对）                                   │
│                     ├─ 按需restart（核心服务文件变更时）                                │
│                     └─ preflight_check.sh --full（部署后自动体检 11项）                │
│                         ├─ 单元测试 (proxy_filters + registry)                       │
│                         ├─ 注册表校验                                                │
│                         ├─ 文档漂移检测                                              │
│                         ├─ 脚本语法 + 权限检查                                       │
│                         ├─ Python语法检查                                            │
│                         ├─ 部署文件一致性（仓库 vs 运行时）                            │
│                         ├─ 环境变量检查（bash -lc 模拟cron）                          │
│                         ├─ 服务连通性（5001/5002/18789）                              │
│                         └─ 安全扫描（API key + 手机号泄漏）                           │
│                                                                                     │
│  开发流程：Claude Code → claude/分支 → GitHub PR → main → auto_deploy → Mac Mini     │
└─────────────────────────────────────────────────────────────────────────────────────┘
                                       │
┌──────────────────────────────────────▼──────────────────────────────────────────────┐
│  ⑤ 三方共享状态层（实时同步）                                                         │
│                                                                                     │
│  ┌──────────┐     ┌─────────────────────┐     ┌──────────────┐                      │
│  │ 用户      │     │ ~/.kb/status.json   │     │ Claude Code  │                      │
│  │ (WhatsApp)│────→│  priorities[]       │←────│ 开工: 读全部   │                      │
│  │ 反馈+决策 │ PA  │  feedback[]         │     │ 收工: 写变更   │                      │
│  │          │写入  │  recent_changes[]   │     │ 更新优先级     │                      │
│  └──────────┘     │  health{}           │     └──────────────┘                      │
│                   │  focus              │                                            │
│                   └────────┬────────────┘                                            │
│                            │                                                         │
│                   ┌────────┴────────────┐                                            │
│                   │ Cron 脚本自动更新     │                                            │
│                   │ auto_deploy → deploy │                                            │
│                   │ preflight → health   │                                            │
│                   │ kb_trend → trend     │                                            │
│                   └─────────────────────┘                                            │
│                                                                                     │
│  宪法：用户提供专业深度 + Claude Code 提供高效设计部署 + OpenClaw 提供数据复利            │
│        三者合一成为有生命的闭环系统                                                     │
└─────────────────────────────────────────────────────────────────────────────────────┘
```

### 核心组件详情

| 组件 | 端口 | 文件 | 功能 | 进程管理 |
|------|------|------|------|----------|
| OpenClaw Gateway | 18789 | npm全局安装 | WhatsApp接入、**媒体存储**、工具执行、会话管理 | launchd (KeepAlive) |
| Tool Proxy | 5002 | `tool_proxy.py` + `proxy_filters.py` | 工具过滤(24→12)、**图片base64注入**、**自定义工具注入+拦截执行**（data_clean、search_kb）、Schema简化、SSE转换、截断、token监控、`/data_clean/*` REST端点 | launchd plist |
| Adapter | 5001 | `adapter.py` | 多Provider转发、认证、**多模态路由**（文本→Qwen3，图片→Qwen2.5-VL）、Fallback降级 | launchd plist |
| LLM Providers (7) | — | `providers.py` | **7 Provider**：Qwen3-235B + VL-72B（主力）/ GPT-4o / Gemini 2.5 / Claude / Kimi / MiniMax / GLM | 外部服务 |

## 关键文件（本仓库）

| 文件 | 用途 |
|------|------|
| `tool_proxy.py` | HTTP 层（收发请求、日志、**自定义工具拦截执行**（data_clean本地执行+search_kb混合检索+followup LLM调用）、`/data_clean/*` REST端点） |
| `proxy_filters.py` | **V27新增→V37.4.3扩展** 策略层（过滤、修复、截断、SSE转换、**自定义工具注入**（data_clean+search_kb）、**V37.4.3 新增 `SYSTEM_ALERT_MARKER` + `filter_system_alerts()` 告警剥离函数**），纯函数无网络依赖 |
| `data_clean.py` | **V30.3新增** 数据清洗 CLI 工具（profile/execute/validate/history，7种操作，支持CSV/TSV/JSON/JSONL/Excel） |
| `test_data_clean.py` | **V30.3新增** 数据清洗单测（80个用例：格式检测/读写/操作/端到端/多格式） |
| `docs/archive/data_clean_poc/` | **V30.3新增→V35归档** Phase 0 验证材料（3个脏数据样本+LLM判断力测试脚本） |
| `SOUL.md` | **V30.4新增→V37.4.3升级** OpenClaw 最高优先级 system prompt（PA身份Wei、三方宪法、行为指令、**规则9批判性思考（反迎合+禁模糊关联+保存验证）**、**规则10告警消息不跟进（2026-04-11 血案规则，主题对齐硬规则+macOS FDA 幻觉防线）**、项目状态实时快照，每小时自动刷新） |
| `ops_soul.md` | **V31新增** Ops Agent 运维助手 SOUL.md（系统健康检查/日志排查/cron诊断/维护操作，部署到 `~/.openclaw/SOUL.md`） |
| `ops_health.sh` | **V31新增** Ops Agent 健康检查包装脚本（Qwen3 拒绝直接 curl localhost，通过脚本包装绕过） |
| `status.json` | **V30.4新增（仓库副本）** 三方共享意识锚点（priorities/feedback/incidents/quality/operating_rules/session_context），Mac Mini 每小时 git push 同步 |
| `providers.py` | **V34新增→V35+扩展** Provider Compatibility Layer（BaseProvider 抽象 + **7 个实现**（Qwen/GPT-4o/Gemini/Claude/Kimi/MiniMax/GLM）+ ProviderRegistry 动态注册 + 能力声明 + CLI 兼容性矩阵输出） |
| `test_providers.py` | **V34新增** providers.py 单测（48个用例：能力声明/模型查找/认证头/注册表/向后兼容/CLI输出） |
| `adapter.py` | API适配层（认证 `$REMOTE_API_KEY`，Fallback降级 `$FALLBACK_PROVIDER`）。V34: 从 `providers.py` 导入 PROVIDERS |
| `docs/strategic_review_20260403.md` | **V34新增** 导师战略复盘文档（Stage判断/主战场定位/V1-V3路标/三个高价值模块/话语权输出/三块差距） |
| `docs/paper/silent_failures_taxonomy/` | **V37.9.139新增** ArXiv 论文 *When Errors Become Narratives: A Longitudinal Taxonomy of Silent Failures in a Production LLM Agent Runtime*（Stage 2→3 话语权 unfinished #5 启动）：`draft.md` ~490 行英文完整第一稿（5 类 taxonomy + 6 cross-cutting findings + **fail-plausible** 概念贡献 + Defense Framework 5 支柱 + 接缝论点）+ `data_inventory.md` 论文每个数字→仓库溯源表（投稿前对表清单）+ `DECISIONS_NEEDED.md` 7 项用户决策（标题/署名 AI 披露/venue 推荐 arXiv 直发/匿名度/LaTeX 时机/内容取舍/figures） |
| `docs/compatibility_matrix.md` | **V34新增→V37.9.143 漂移防护机器化** Provider 兼容性矩阵（**8 providers 含 Doubao** + **验证四档诚实标注** declared/smoke_tested/feature_verified/production_observed + gemini geo-block 退役现状 + fallback 链 V37.9.129 现实 + 插件优先接入指南）。**V37.9.143**：两张机器表（支持的 Provider + 能力矩阵）由 `gen_compat_matrix.py --check` 在 full_regression doc-drift 层守卫，人工段落（验证档位/Fallback 路径/工具模式验证）不参与比对 |
| `gen_compat_matrix.py` | **V37.9.143新增** compatibility_matrix 漂移防护（外部评审2 P0(b)）：`--check` 比对 providers.py 直出两张表 vs doc 表格段（exit 1 = drift）+ `--fix` 一键重写（人工段落绝不触碰）。镜像 gen_jobs_doc --check 模式。**首跑即抓真漂移**（V37.9.142 手动刷新漏 doubao json_mode=True 手写为 —） |
| `test_gen_compat_matrix.py` | **V37.9.143新增** 漂移防护 27 单测 / 7 类：providers 两张表直出纯函数 + verifiable_features 分母修复守卫（"5/4 verified" 超界 bug → Qwen 5/5 + Doubao 5/6 诚实语义）+ extract/check/fix 三件套 + 人工段落保护契约 + 真仓库端到端 + 反向 sabotage（分母回退 2 fail / doc 表行篡改 check exit 1） |
| `slo_benchmark.py` | **V35新增→V37.9.143 四态/双窗口/阈值正文** SLO Benchmark 报告生成器（读取 proxy_stats.json 真实数据→Markdown/JSON 报告：延迟p50/p95/p99、成功率、错误分类、降级率、恢复率）。**V37.9.99** 三态 OBSERVING 样本门槛；**V37.9.143**（外部评审2 P0(a) dev 侧）：四态 verdict（tool_calls=0 → `N_A_NO_TOOL_CALLS` 不参与汇总，镜像 slo_dashboard V37.9.79 N/A）+ 24h/7d 双窗口趋势段（复用 slo_dashboard 历史快照 MR-8，无历史显提示行）+ Threshold Rationale 正文段（config.yaml V37.9.79 注释升级为报告正文 + 阈值恢复后文案自适应）+ Methodology 阈值行动态读 config（修 V37.9.79 后硬编码 "≤30s" 漂移） |
| `test_slo_benchmark.py` | **V35新增** SLO Benchmark 单测（17个用例：全通过/各类违规/零请求/格式化/文件读取） |
| `quickstart.sh` | **V35新增** 一键 Quick Start（4阶段：前置检查→启动服务→健康验证→Golden Test Trace，10分钟跑通全栈） |
| `docs/golden_trace.json` | **V35新增** Golden Test Trace（quickstart.sh 生成的真实请求/响应/延迟记录，可复现证据） |
| `docs/slo_benchmark_report.md` | **V35新增** 首份 SLO Benchmark 实验报告（5/5 PASS，p95=459ms） |
| `openclaw_backup.sh` | **V29.1新增** 每日Gateway state备份到外挂SSD（保留7天） |
| `jobs_registry.yaml` | **V27新增** 统一任务注册表（system + openclaw 双 cron） |
| `check_registry.py` | **V27新增** 注册表校验脚本 |
| `ROLLBACK.md` | **V27新增** 回滚指南（30秒恢复到V26） |
| `upgrade_openclaw.sh` | Gateway升级SOP脚本（必须SSH直连执行，禁止WhatsApp触发） |
| `restart.sh` | 一键重启 Proxy + Adapter + Gateway（含 PATH 修复，可在 cron 环境使用）。**V37.9.13 架构清理**：Adapter + Proxy 改用 `launchctl kickstart -k` 走 launchd 管理，消除 V37.9.12.1 双管理血案；plist 缺失时 fallback 到 nohup；V37.8.13 Gateway 健康验证模式扩展到 adapter/proxy（5×2s curl /health 探测）；**V37.9.140 日落法**：#48703 listeners-Map 自动补丁段退役（上游 2026.3.23 修复 + Gateway 已升 v2026.4.27，移除本脚本唯一 sudo 依赖；上游回归监控由 preflight 12/19 保留承担） |
| `health_check.sh` | **V27→V37.9.78 重构** 每周一 09:00 健康周报（v2.0 "系统证据周报"）— 9 段证据：🖥服务+🤖模型+📊SLO+🛡安全+🏛治理+🛟MOVESPEED+🐦X监控+📚KB+💾SSD。MR-8 single-source-of-truth 全部走外部工具 (slo_dashboard/security_score/.audit_metrics.jsonl/movespeed_incident_monitor)，safe_call helper 三层 FAIL-OPEN，推送优先 notify.sh --topic daily（重试+队列）fallback openclaw 直推 |
| `test_health_check_v37_9_78.py` | **V37.9.78新增** health_check v2.0 单测（32 个用例 / 5 类）：TestSourceGuards(15 含 V37.9.78 marker / safe_call helper / 9 段 emoji / SLO 字段名校对 / notify.sh 优先 / v1.1 反模式移除) + TestSafeCallHelper(5 含 timeout / fallback / set -e 安全) + TestRuntimeBehavior(3 含 dev 全 8 段 + FAIL-OPEN 不抛 Traceback + JSON schema) + TestReverseValidation(4 sabotage 字面量/段移除/字段名/helper 真有效) + TestGovernanceLineage(6 V36/V30.2/V37.1/V37.9.27/V37.8.4/V37.8.13 引用) |
| `kb_write.sh` | KB写入脚本（含目录锁+原子写） |
| `kb_review.sh` | **V29升级→V37.5 重写** KB跨笔记回顾 thin wrapper（调用 kb_review_collect.py，fail-fast + [SYSTEM_ALERT]，不再机械 fallback） |
| `kb_review_collect.py` | **V37.5新增** KB 周度回顾数据采集器 + LLM 调用（纯 Python 模块：load_sources_from_registry 从 jobs_registry.yaml 读源 + extract_recent_sections H2 drill-down + call_llm 80-char 最小内容阈值 + run() 接受 llm_caller 注入可单测） |
| `test_kb_review.py` | **V37.5新增** kb_review_collect 单测（44 个用例：registry 发现 / H2 parser 边界 / collect_notes 时间过滤 / call_llm 空短失败 / run() 失败不伪装成功 / 输出契约 / shell 源文件锁） |
| `kb_deep_dive.py` | **V37.9.16新增→V37.9.17 picker tier-aware fallback** 每日深度分析 collector（纯 Python 模块：`import kb_review_collect as rc` 复用 load_sources_from_registry + extract_recent_sections + call_llm；picker 算法 ⭐≥4 门槛 + TOPIC_WEIGHTS 主题加权 + 摘要长度 tie-breaker + **V37.9.17 方案 C tier-aware fallback**（TIER 1/2 优先于 TIER 3，避免 X tweet ⭐5 挤掉 arxiv ⭐4 走 abstract_only）；三档 fetch：一档 arxiv/acl/hf/pwc/s2/dblp PDF（pdfplumber lazy import + References/Acknowledgments 切割 + 图表 caption 去噪 + 30K 截断）/ 二档 rss_blogs/ontology_sources/github_trending HTML（bs4 lazy import + article/main 标签优先）/ 三档 degrade；双 prompt 分支 build_full_text_prompt（论证链+实验对比+局限性）vs build_abstract_only_prompt（禁推测+摘要级标注），两者都含 GROUNDING_CONSTRAINT；fail-fast run() 返回 status: ok/no_candidates/llm_failed/collector_failed） |
| `kb_deep_dive.sh` | **V37.9.16新增** 每日深度分析 thin wrapper（镜像 kb_review.sh V37.5.1 env-var heredoc 模式）：set -euo pipefail + notify.sh source + `--topic deep_dive` 双通道推送（WhatsApp 简版 + Discord #daily 完整版，内容不同）+ `[SYSTEM_ALERT]` fail-fast + last_run_deep_dive.json status 写入 + rsync 备份带事故取证（V37.9.14 INV-BACKUP-001 契约）+ no_candidates 告警但不 exit 1（允许明日再试） |
| `test_kb_deep_dive.py` | **V37.9.16新增→V37.9.17 +6 tier fallback** kb_deep_dive 单测（61 个用例 / 11 类）：TestClassifyTier(7) + TestParseEntriesFromSection(6) + TestScoreEntry(6) + **TestPickTopTierFallback(6) — V37.9.17 方案 C 守卫含 `test_v37_9_16_blood_lesson_scenario` 直接复现 X tweet ⭐5 + arxiv ⭐4 必选 arxiv** + TestPdfUrlDerivation(5) + TestPreprocessPdfText(5) + TestFetchDegrade(3) + TestPromptBuilders(4) + TestOutputBuilders(5) + TestRunOrchestrator(5 端到端：no_candidates/ok full_text/llm_failed 不产出 artifacts/degrade abstract_only/collector_failed) + TestKbDeepDiveShellGuards(9 源码级守卫：[SYSTEM_ALERT]/env-var heredoc 反模式/notify.sh 引用/set -euo pipefail/last_run/deep_dive topic/rsync forensics/fail-fast 顺序锁) |
| `cross_source_signal_aggregator.py` | **V37.9.46新增** Opportunity Radar Stage 1 PoC — 跨 source 弱信号聚合器（纯 Python，6 核心函数：scan_today_notes/embed_notes/cluster_dbscan/filter_cross_source/rank_signals/emit_radar_json + run/main CLI）。**算法管道**：扫今日 ~/.kb/notes/*.md → sentence-transformer 384 维 embedding（lazy import local_embed + numpy）→ DBSCAN 聚类（min_samples=3 / eps=0.35 / metric=cosine, lazy import sklearn）→ filter_cross_source（unique_sources≥2 跨源契约）→ rank_signals（score=source_count×2+note_count+avg_intra_similarity×5, top 10）→ emit ~/.kb/radar/daily_signals_{date}.json。**FAIL-OPEN 契约**（V37.4 同款 lazy import）：dev 无 numpy/sklearn/sentence-transformers 时模块仍可 import + 测试可跑（mock 隔离），run() 缺依赖 → status=fail_open_no_deps + 写空 signals 不阻塞下游。**Cache 策略**：content_hash 16 字符 cache key（V37.4 mtime-stable 同款），命中跳过 sentence-transformer 重算。**MR-11 兑现**：log() 写 stderr 防 $(...) 命令替换污染。**suggested_topic Stage 1 简化版**：cluster 内 titles 最高频关键词（中英文 regex），Stage 4 升级 LLM 一句话总结。**设计文档** docs/opportunity_radar_design.md 第三节锁定常量与算法。 |
| `kb_trend_acceleration.py` | **V37.9.48新增** Opportunity Radar Stage 3 — 趋势加速检测（设计文档 5 节）。5 函数：extract_keywords_per_week (复用 kb_trend.py extract_period_text + extract_keywords, lazy import + FAIL-OPEN)、compute_acceleration (输入 dict {1: w1_kw, 2: w2_kw, 3: w3_kw} 输出加速度 metrics — 用各周占比 pct 而非原始 freq 防总数差距失真 + w2=0 新词 skip + min_freq_pct=0.005 小基数门槛过滤噪声)、classify (5 档锁定 — 🚀 strong: a1≥1.5 AND a2≥1.5 / ⚰️ obs: a1<0.5 AND a2<0.5 / 📈 mild: a1≥1.5 / 💧 decel: a1<0.7 / 📊 stable: 其他 / 顺序锁定 strong > obs > mild > decel > stable / 非数字输入安全降级 STABLE)、rank_signals (按 archetype priority 分桶 + 同桶按 \|a1-1\| desc 排 / top_strong=10 strong+mild 共 / top_stable=5 / top_obs=3 / 总 max 18 signals)、emit_radar_json (~/.kb/radar/weekly_trends_{week}.json + archetype_summary 计数). **不集成 kb_dream/kb_evening** (Stage 4 才集成). **向后兼容**: kb_trend.py 旧接口完全不动. **设计文档 11.2 风险表登记**: 趋势加速度噪声大 (小基数) → MIN_FREQ_PCT 门槛防 0.5% 占比以下噪声参与计算. CLI: `--kb-dir X --output-dir Y --json`. |
| `test_kb_trend_acceleration.py` | **V37.9.48新增** Stage 3 PoC 28 单测（7 测试类）：TestExtractKeywordsPerWeek(4 含 invalid week_offset / dict 类型契约 / FAIL-OPEN 缺 kb_trend / 日期范围注入) + TestComputeAcceleration(5 含 3 周历史正常 / w2=0 新词 skip / w3=0 → accel_2w=None / min_freq_pct 噪声门槛 / 空输入安全) + TestClassify(6 含 strong 必须 a1+a2 / obs 必须 a1+a2 / mild 仅要 a1 / decel 仅要 a1 / stable 中间区 / 非数字 fallback STABLE) + TestRankSignals(4 含 archetype 优先级 strong>mild>decel>obs>stable / top_k 截断 per bucket / 空输入 / 桶内 \|a1-1\| desc) + TestEmitJson(3 含 JSON 完整性 + archetype_summary / weekly_trends_{week}.json 路径 / 嵌套自动 mkdir) + TestBackwardCompat(3 含 kb_trend.extract_period_text/tokenize/extract_keywords 旧接口仍 callable 不 break) + TestSourceLevelGuards(3 V37.9.48 marker / 5 档阈值锁定 1.5/0.7/0.5 + 5 archetype 常量 + 5 emoji / log() file=sys.stderr MR-11). **反向验证守卫真有效**: sed `ACCEL_STRONG_THRESHOLD = 1.5` → `0.5` → test_design_locked_thresholds 立即 AssertionError. 还原后 28/28 全过. |
| `project_alignment_scorer.py` | **V37.9.47新增** Opportunity Radar Stage 2 — 项目对齐度评分 rule_check 验证层（设计文档 4 节）。7 函数：load_project_concepts (lazy YAML parse + 行尾注释剥离 V37.9.47 修)、count_keyword_hits (大小写不敏感 + 中英 substring + dedup + excluded_topics weight × -2 强降权)、compute_expected_range (5 档锁定: <0/0/1-2/3-4/5+ → ⭐1-2/2-3/3-4/4-5)、validate_alignment_score (LLM ⭐ 数 vs rule keyword 一致性 + 偏高/偏低 reason 解释)、parse_6field_output (MR-8 与 hf_papers.sh inline 行为一致 — 仅 📌 字段 inline 提取, 其他字段 LLM 多行格式)、extract_star_count (取最大连续 ⭐ 段)、format_validation_marker (validated=False 时返回 ⚠️ <reason>)。**集成 hf_papers.sh emit-stage**: lazy import + load_project_concepts 一次, 每 paper alignment 段后调 validate_alignment_score(title+tldr+abstract, llm_stars), 不一致时推送加 ⚠️ 标记前缀给用户. **FAIL-OPEN**: project_alignment_scorer 缺失 → log WARN 跳过 rule_check 不阻塞 hf_papers cron. CLI: `--content X --llm-score N --json`. |
| `test_project_alignment_scorer.py` | **V37.9.47新增** Stage 2 PoC 31 单测（7 测试类）：TestProjectConceptsYaml(5 含 yaml schema / weight 范围 [-5,5] / keywords 非空 / FAIL-OPEN 缺文件 → 默认 dict) + TestKeywordHitCounting(6 含多关键词 / 大小写不敏感 / 中英混合 substring / excluded × -2 降权 / 同 keyword dedup / 空内容) + TestExpectedScoreRange(4 含 0/5/边界 1-4/负数命中) + TestValidateAlignmentScore(4 含血案场景 LLM=5+0 命中 fail / LLM in range pass / LLM 偏低 / invalid score type) + TestPromptInjection(3 hf_papers.sh prompt 含 🎚️ + 5 档评分指南 + 一句话原因 ≤30 字) + TestParse6FieldOutput(5 完整 6 字段 / 缺字段 / 顺序乱序 / 空 / **MR-8 grep hf_papers inline 守卫**) + TestSourceLevelGuards(4 V37.9.47 marker / _SCORE_RANGES 5 档锁定 / FAIL-OPEN 注释 / log stderr MR-11). **反向验证已确认守卫真有效**: sed `(5, 999, 4, 5)` → `(5, 999, 1, 2)` → test_high_hits_high_stars 立即 fail. 还原后 31/31 全过. |
| `test_cross_source_signal_aggregator.py` | **V37.9.46新增** Stage 1 PoC 33 单测（8 测试类）：TestScanTodayNotes(5 含 YYYYMMDD 日期过滤 + frontmatter parse + tags 单值/list 双格式 + 缺字段 default unknown + 无效 date) + TestEmbedNotes(4 含 cache hit os.path.isfile mock + force_recompute bypass + 文本截断 ≤500 chars + empty 输入 numpy.zeros (0,384)) + TestClusterDbscan(5 含 lazy import sklearn ImportError + N<min_samples short-circuit 在 import 之前 + 多 cluster + noise -1 + DBSCAN 参数 design-locked 验证) + TestFilterCrossSource(4 含单 source 拒绝 + 跨 2 源保留 + 跨 4 源高信号 + noise label 排除) + TestRankSignals(3 含公式正确性 + top_k 截断 + 空输入) + TestEmitRadarJson(3 含 JSON 字段完整性 + daily_signals_{date}.json 路径 + 自动 mkdir 嵌套目录) + TestFailOpenContract(4 含 no_notes 状态 + numpy 缺失 fail_open + sklearn 缺失 fail_open + 单笔记 OSError 不致命) + TestSourceLevelGuards(5 V37.9.46 marker / DBSCAN_MIN_SAMPLES=3 + DBSCAN_EPS=0.35 设计锁定值 / FAIL-OPEN 契约文档 / lazy import 反 module-top-import 守卫前 60 行禁 numpy/sklearn/sentence_transformers/local_embed / log() 写 stderr MR-11)。**反向验证已确认守卫真有效**: sed 把 `DBSCAN_MIN_SAMPLES = 3` → `1` → test_design_locked_constants 立即 AssertionError; 模块顶部加 `import numpy` → ModuleNotFoundError 立即触发（dev 无 numpy 强证守卫）。还原后 33/33 全过。 |
| `project_concepts.yaml` | **V37.9.45新增** Opportunity Radar #2 PoC 项目本体清单（V37.9.46 Stage 1 复用即将由 project_alignment_scorer.py 完整 Stage 2 消费）：3 core_planes (control/capability/memory plane keywords + weights 5/4/5) + 3 active_research_directions (ontology/agent_reliability/data_compounding) + 2 excluded_topics (pure_finetuning/pure_hardware weight=-2 命中扣分) + scoring_guide 5 档评分指南（⭐⭐⭐⭐⭐=control plane/agent runtime/ontology 直接相关）+ meta_rules（收工时同步本周新增概念）。version=0.1-poc。 |
| `hallucination_guards.py` | **V37.9.57新增** 公共反幻觉守卫 5 档模板 (MR-8 single-source-of-truth, 替代 9 task 各自 inline 守卫). 5 档累积式严格度: **LEVEL_1_MINIMAL** (kb_harvest_chat 闭环数据, 仅"严禁虚构") / **LEVEL_2_STANDARD** (freight/finance/ontology 单源新闻, + 来源标签校验) / **LEVEL_3_STRICT** (kb_review/kb_deep_dive 跨域回顾, + 反链式推论 "X 段提到 Y → 推论 Z" 模式禁止) / **LEVEL_4_PROJECT_AWARE** (8 ALIGNED jobs per-paper alignment 评分, + V37.9.56-hotfix3 6 个血案精确字眼 "OpenClaw 社区发布"/"v26"/"v26/v27/v37 版本更新"/"项目里程碑"/"开源 X 上线"/"[openclaw]") / **LEVEL_5_RADAR_AWARE** (kb_dream Reduce + kb_evening, + Opportunity Radar 三件套信号源契约 + Top 5/cross_source/trend 显式声明"跨多天累积非今日事件"). **公开 API**: `get_guard(level)` / `list_levels()` / `get_blocked_phrases()` / `get_radar_signal_types()`. 未知 level fallback LEVEL_3_STRICT 安全中位数. CLI `python3 hallucination_guards.py --list/--blocked-phrases/--level X`. 纯 stdlib 零外部依赖. |
| `test_hallucination_guards.py` | **V37.9.57新增** 38 单测 / 7 类: TestGuardLevels(8 含 5 档累积式 + V37.9.57 marker + LEVEL_N 不含 LEVEL_(N-1) 之外特性) + TestGetGuardAPI(6 默认/未知/None/非string fallback 全过) + TestBloodLessonBlockedPhrases(5 V37.9.56-hotfix3 5 个核心字眼必须在 LEVEL_4+) + TestRadarSignalTypes(3 三件套 #1/#2/#3 必须在 LEVEL_5 + 不在 LEVEL_4) + TestCliInterface(4 subprocess --list/--blocked-phrases/--level) + TestSourceLevelGuards(9 V37.9.57 marker / V37.9.56-hotfix3 lineage / GUARDS dict 5 key locked / _DEFAULT_FALLBACK 锁 LEVEL_3 / MR-8 documented) + TestV37957Contracts(2 模块顶部 import / 无外部依赖). **反向验证已确认守卫真有效**: sabotage _LEVEL_4 整段赋空 → 4 failures; sabotage _DEFAULT_FALLBACK 改 LEVEL_5 → 1 failure; sabotage _LEVEL_5 整段赋空 → 4 failures. 还原后 38/38 全过. |
| `source_credibility.py` | **V37.9.98新增** 来源可信度评级（observer 5/28 LLM critique proposal #2 兑现，与 hallucination_guards.py 互补：HG 守"内容真实性 + 跨域推论可信度"，credibility 守"出处权威性"）。纯 stdlib 零外部依赖。**5 档 tier**（按"引用断言无需独立验证的可信程度"递减）：🥇 学术同行评审 (rank1: S2/DBLP/ACL/ontology_sources 已发表有DOI) / 🥈 会议预印本 (rank2: arxiv/hf_papers 公开可引未评审) / 🥉 工业实践 (rank3: github_trending/openclaw_run 官方代码可验证) / 📝 博客 (rank4: rss_blogs/**chaspark observer 点名的非主流源**) / 💬 社媒 (rank5: ai_leaders_x/hn/freight/finance 时效强可靠性参差)。**SOURCE_CREDIBILITY** 14 源映射 = MR-8 单一真理源（test drift guard 守 ↔ jobs_registry 14 内容源 id+label 双匹配）。**公开 API**: `get_credibility(source_id)` (FAIL-OPEN 未知源→社媒最低档+reason=未分类来源) / `format_credibility_block()` (prompt 注入块, source 列表动态生成) / `list_tiers()` / `list_sources()`. CLI `--list/--sources/--block/--source X`. |
| `test_source_credibility.py` | **V37.9.98新增** 56 单测 / 10 类: TestCredibilityTiers(6 含 5 档 + rank 1-5 唯一 + list_tiers rank 升序 + _DEFAULT_TIER=社媒最保守) + TestGetCredibility(7 含已知学术/预印本/chaspark博客 + 未知→社媒FAIL-OPEN + 非string + 字段完整 + label 匹配) + **TestSourceCoverage(7 MR-8 drift guard — registry 14 源 + 每源有 credibility + 无 orphan + label 匹配 + tier 有效)** + TestChasparkFlagged(4 observer proposal #2 锚点 — chaspark=博客 + block 含"非主流学术源"+"需独立验证"+"proposal #2") + TestFormatBlock(9 \\n\\n 开头 + ⚠️ + V37.9.98 + 5 tier + 14 label + [可信度:<等级>] 标注指令 + 未分类默认规则) + TestCli(5 subprocess) + TestDreamWiring(6 含 5 注入点 + import + 反 inline 守卫) + TestEveningWiring(5 含 build_evening_prompt 渲染 + 位置在今日笔记 section 之前) + TestAutoDeployFileMap(2) + TestSourceLevelGuards(7 V37.9.98 marker + MR-7/MR-8 + FAIL-OPEN + chaspark tier 锁定). **反向验证已确认守卫真有效**: sabotage chaspark→学术同行评审 → 4 failures; 删 ontology_sources 源 → drift guard fail. 还原后 56/56 全过. |
| `top_alignment_picker.py` | **V37.9.56新增** Opportunity Radar Sub-Stage 4c Top 5 高对齐推送 picker（设计文档第 7 节 Stage 4c 兑现）。纯 Python 模块 8 个核心函数：scan_source_results / parse_alignment_from_content / collect_all_picks / rank_picks / format_top_picks_block / pick_top_aligned + log()(MR-11 stderr) + main CLI（--json/--block-only/--repo-root/--min-stars/--top-n）。**ALIGNED_SOURCES** **V37.9.112 → 10 个 source** (hf_papers prio 1 / s2 prio 2 / arxiv+dblp prio 3 / github_trending prio 4 / rss_blogs+ai_leaders_blogs prio 5 博客档 / ai_leaders_x+**ai_leaders_bsky** prio 6 社媒档 / hn prio 7, **V37.9.108 +ai_leaders_blogs 大神长文 / V37.9.112 +ai_leaders_bsky 大神实时短帖**) 来自 V37.9.45/50/51 全量迁移 6 字段 + 🎚️ 项目对齐度评分 + V37.9.108/112 ai_leaders 双渠道大神观点. **解析**: lazy import project_alignment_scorer.extract_star_count → _fallback_extract_star_count (clamp [0,5]) → key-based 6-field parser 复用 hf_papers/V37.9.51 同款 (📌/🔑/💡/🎯/⭐/🎚️ 字段头识别 + 🎚 fallback no variation selector)。**排序契约**: ⭐ 数 desc + source_priority asc + cn_title 长度 desc 三档 tie-break。**FAIL-OPEN 契约 (V37.9.46 同款 lazy import 模式)**: cache dir/file 缺失 → 该 source 0 picks 不阻塞其他 source / llm_results.jsonl 损坏行 → skip 继续 / failed=True 跳过 / alignment scorer 缺失 → fallback regex / 无 picks → block="" 调用方静默不推送 / 任何异常 → pick_top_aligned 顶层 try/except 返回 no_picks。**默认配置**: DEFAULT_MIN_STARS=4 / DEFAULT_TOP_N=5 (V37.9.51 收工承诺锁定)。**集成路径** kb_dream.sh Phase 1.5+ + kb_evening_collect.py build_evening_prompt 双处。 |
| `test_top_alignment_picker.py` | **V37.9.56新增** Sub-Stage 4c 55 单测 / 8 类 + 反向验证三层守卫真有效 (sabotage DEFAULT_MIN_STARS=3 / 删 🎚 fallback / log 写 stdout 都立即多 fail，还原后全过). TestParseAlignmentFromContent(11 含 6 字段完整 / ⭐≥4 vs ⭐3 阈值 / 🎚 emoji fallback / 中文标题 / 5 字段向后兼容 / 空内容 / 非 string / ⭐ clamp 到 5 / rating vs alignment 不污染 / reason truncate 60 字) + TestFallbackExtractStarCount(5 含多段取最长 / 空输入 / clamp) + TestScanSourceResults(6 含 missing dir + corrupted JSON skip + failed entries skip + empty content skip) + TestCollectAllPicks(3 含 dev 空环境 / min_stars 过滤 / source metadata 注入) + TestRankPicks(6 含 stars desc / priority tie-break / title len tie-break / top_n truncate / 空输入 / 缺字段安全) + TestFormatTopPicksBlock(6 含空输入 / 一行一 pick / 标题 40 字截断 / 无 reason 不加分隔符 / ⭐ clamp) + TestPickTopAlignedOrchestrator(3 含端到端 dev no_picks / ok with picks / multi-source 排序) + TestCliInterface(3 subprocess 真跑 CLI --json + --block-only) + TestSourceLevelGuards(10 V37.9.56 marker / 8 source 全部注册 / DEFAULT_MIN_STARS=4 锁定 / DEFAULT_TOP_N=5 锁定 / log 写 stderr MR-11 / FAIL-OPEN 文档 / 🎚️ + 🎚 双 emoji 兼容 / priority 论文优先 / 反向验证守卫 / 模块顶部反 lazy import 守卫) + TestV9_56IntegrationContracts(2 picks JSON 可序列化 + bash 注入安全契约). |
| `kb_search.sh` | **V29新增** KB按需查询工具（关键词/标签/来源/统计概览） |
| `kb_inject.sh` | **V29新增→V29.4升级** 每日KB摘要+运维知识精华注入workspace CLAUDE.md；文档按需查阅路径 `~/.kb/docs/` |
| `mm_index.py` | **V29.1新增** Multimodal Memory 索引器（Gemini Embedding 2，支持图片/音频/视频/PDF） |
| `mm_search.py` | **V29.1新增** Multimodal Memory 语义搜索（文本查询→cosine similarity→匹配媒体） |
| `mm_index_cron.sh` | **V29.1新增** MM 索引定时任务包装脚本（每2小时） |
| `local_embed.py` | **V29.3新增** 本地 Embedding 引擎（sentence-transformers，中英双语，零API调用） |
| `kb_embed.py` | **V29.3新增** KB 文本向量索引器（notes+sources 分块→本地 embedding→~/.kb/text_index/） |
| `kb_rag.py` | **V29.3新增** KB RAG 语义搜索（--context LLM注入 / --json 脚本调用） |
| `kb_trend.py` | **V29.5新增** KB周趋势报告（本周vs上周关键词+LLM分析+WhatsApp推送） |
| `status_update.py` | **V29.5新增** 三方共享项目状态工具（原子读写 ~/.kb/status.json，Claude Code + PA + cron 共用） |
| `kb_save_arxiv.sh` | ArXiv监控结果写入KB + rsync备份 |
| `auto_deploy.sh` | **V27.1新增** 仓库→部署自动同步 + 漂移检测（md5全量比对+WhatsApp+Discord告警） |
| `test_tool_proxy.py` | proxy_filters 单测（118个用例，含自定义工具注入 + **V37.4.3 新增 21 个告警隔离回归：TestFilterSystemAlerts(14) + TestNotifyShAlertMarker(5) + TestToolProxyImportsAlertFilter(2)**） |
| `test_check_registry.py` | **V28新增** check_registry.py 单测（18个用例） |
| `gen_jobs_doc.py` | **V28新增** 从 registry 自动生成任务文档 + 漂移检测 |
| `smoke_test.sh` | **V28新增** 端到端 smoke test（单测+注册表+连通性） |
| `wa_keepalive.sh` | **V28新增** WhatsApp session 保活（每30分钟真实发送验证） |
| `preflight_check.sh` | **V28新增→V30.3升级** 收工前全面体检（16项检查：单测+注册表+语法+部署一致性+环境变量+连通性+安全扫描+数据流+货代监控+crontab路径一致性+推送通道E2E） |
| `job_smoke_test.sh` | **V30.3新增** 全量 job smoke test（20个启用任务×6维度：脚本存在/crontab注册/运行时路径/日志活跃/状态文件/锁文件+KB完整性+crontab条目数） |
| `docs/config.md` | 完整系统配置文档（含所有历史变更） |
| `docs/GUIDE.md` | 完整中英文集成指南 |
| `docs/openclaw_architecture.md` | **V28.2新增** OpenClaw 开源架构完整参考（每日开工自动刷新） |
| `cron_doctor.sh` | **V30新增** 定时任务全面诊断工具（7项检查：crontab/锁文件/心跳/服务/环境/时效/系统） |
| `cron_canary.sh` | **V30新增** Cron 心跳金丝雀（每10分钟，零依赖，原子写入） |
| `crontab_safe.sh` | **V30新增** 安全 crontab 操作（自动备份+条目数验证+回滚保护） |
| `test_cron_health.py` | **V30新增** 定时任务健康检测单测（94个用例：锁/心跳/告警/原子写入/损坏恢复/daemon检测/完整性/状态刷新） |
| `kb_status_refresh.sh` | **V30.1新增** 每小时刷新 status.json 系统健康字段（三层服务/模型ID/KB统计/过期job），补齐三方宪法实时同步 |
| `kb_integrity.py` | **V30.1新增** KB 文件完整性校验器（SHA256 指纹比对、目录文件数监控、权限检查、status.json 结构验证） |
| `test_status_update.py` | **V30.1新增** status_update.py 全量单测（33个用例：原子读写/嵌套字段/数组操作/优先级CRUD/CLI接口） |
| `test_adapter.py` | **V30.1新增** adapter.py 全量单测（36个用例：Provider注册表/认证头/多模态路由/Fallback/智能路由/健康端点） |
| `test_kb_business.py` | **V30.1新增** KB全业务逻辑单测（44个用例：kb_embed/kb_rag/kb_trend/mm_index/mm_search/kb_integrity/安全模式） |
| `full_regression.sh` | **V30.1新增** 全量回归测试一键运行器（四层：单元测试+注册表文档+安全扫描+代码质量，393个用例，100%通过才允许推送） |
| `audit_log.py` | **V30.2新增** 链式哈希审计日志（JSONL append-only，SHA256 链式校验，篡改/删除可检测） |
| `test_audit_log.py` | **V30.2新增** 审计日志单测（19个用例：写入/链式哈希/篡改检测/删除检测/统计） |
| `governance_audit_cron.sh` | **V37.1新增** 每日定时治理审计（governance_checker --full + engine --check，失败推送 alerts），ontology 从被动验证升级为主动监控 |
| `security_score.py` | **V30.2新增** 系统安全评分（7维度100分：密钥/测试/完整性/部署/传输/审计/可用性） |
| `reliability_bench.py` | **V36新增** Agent Reliability Bench（7场景47检查：Provider宕机/工具超时/畸形参数/超大请求/KB未命中/Cron漂移/状态损坏，mock-based可在dev运行） |
| `test_reliability_bench.py` | **V36新增** Reliability Bench 单测（36个用例：7场景×独立验证+报告格式+CLI） |
| `docs/reliability_bench_report.md` | **V36新增** 首份 Reliability Bench 实验报告（7/7 PASS，47/47 checks） |
| `memory_plane.py` | **V36新增** Memory Plane v1 统一接口（4层：KB语义/多媒体/偏好/状态，统一 query/context/stats） |
| `test_memory_plane.py` | **V36新增** Memory Plane 单测（45个用例：4层×可用性/搜索/统计+统一查询+优雅降级+CLI） |
| `docs/memory_plane.md` | **V36新增** Memory Plane 架构文档（分层设计/API/数据流/CLI） |
| `docs/security_boundaries.md` | **V36新增** 安全边界文档（8节：认证/网络/输入验证/数据保护/LLM安全/运维/评分/已知风险+Checklist） |
| `docs/resilience_report.md` | **V36新增** 运维韧性实验报告（7场景故障注入+Recovery Time+GameDay对比+改进建议） |
| `docs/ontology/` | **V36新增** Ontology KB — 本体论驱动的企业智能架构知识库（16文件：三角架构论述/核心概念/AI治理/OpenClaw本体审视/文献/人物/README/流派对比/供应链本体） |
| `ontology/` | **V36.1新增→V37.9.15 Phase 4 P3 三阶段门控 shadow wiring** Ontology 独立子项目 — Tool Engine（81条声明式规则+推理引擎+**classify_tool_call语义分类**）+ **Governance Ontology v3.32**（**61不变式**+**297 可执行检查**+**16元规则**+**MR-6 critical-invariants-need-depth 从警告升级为 hard-enforcing via INV-LAYER-001**+MR-7 治理自观察+MR-8 copy-paste-is-a-bug-class+MR-9 state-writes-go-through-helper+**INV-GOV-001 summary 不吞 error**+**INV-DREAM-001/002 + INV-CACHE-002 Dream Map 预算+缓存契约**+**INV-PA-001/002 告警污染+SOUL.md 规则 10 双防线**+**INV-LAYER-001 治理深度自我强制**+**INV-GATE-001 三阶段门控 wiring observability (V37.9.15)**+验证深度三层模型+Phase 0元规则自主发现）+ governance_checker.py 执行引擎 + 宪法6条 + **Phase 2 shadow模式**(off→shadow→on) + 立场文章(EN+ZH) + **V37.9.12 engine.py 3 个 Phase 4 P1 纯函数** (`load_domain_ontology()` / `find_by_domain(domain)` / `evaluate_policy(policy_id, context)`) + `proxy_filters.py::filter_tools` 切换读 policy.max-tools-per-agent.limit + **V37.9.13 Phase 4 P2 context evaluator** (6 matcher + `_CONTEXT_EVALUATORS` dispatch + `evaluate_policy()` 三档扩展) + 第二条 policy `_resolve_max_tool_calls_per_task_limit()` 镜像 5 档 safe-fallback + **V37.9.15 Phase 4 P3 `ontology/three_gate.py` 三阶段门控 shadow wiring**：`pre_check/runtime_gate/post_verify` 三纯函数 + `GateFinding` namedtuple + `ONTOLOGY_GATES_MODE` env (off/shadow/on 默认 shadow) + 静态 policy signal 比对（tool_count/tool_call_count/body_bytes vs limit 产 pass/flag verdict） + 与 `ONTOLOGY_MODE` 解耦 + FAIL-OPEN 契约（engine 异常不冒泡，fall back to pass+reason=engine_unavailable）。tool_proxy.py lazy-load three_gate + `_run_gate` 帮助函数（Exception 兜底 + log [gate:*]）+ do_POST 两处调用点（raw 后 pre_check+runtime_gate / rj 后 post_verify 必须在 fix_tool_args 之前）|
| `ontology/domain_ontology.yaml` | **V37.9.9新增（骨架）→V37.9.12 P1 wiring 依据** Phase 4 Layer 1 领域模型 — 六域概念 Actor/Tool/Resource/Task/Provider/Memory + 域间关系模板 + Phase 4 实施路径 P1/P2/P3。V37.9.12: `find_by_domain()` 纯函数读此文件, Actor 6/Resource 7/Task 6/Memory 4 层/Provider 4 type 可查。|
| `ontology/policy_ontology.yaml` | **V37.9.9新增（骨架）→V37.9.15 Phase 4 P3 gates 接入** Phase 4 Layer 2 策略声明 — 10 条 policy 按 static/temporal/contextual 三类分。**V37.9.15 meta 升级** version 0.2-p2-partial → 0.3-p3-partial，status → gates_wired_shadow_mode，新增 `policies_observed_by_three_gate` 清单（pre_check 2 / runtime_gate 3 / post_verify 1）+ `gates_feature_flag` 声明（env_var=ONTOLOGY_GATES_MODE / values=["off","shadow","on"] / default=shadow / decoupled_from=ONTOLOGY_MODE）+ `next_step` 指向 P3.1 (shadow→on 一周观察) / P3.2 (第三条 policy) / P4 (真正 enforcement 路径)。|
| `ontology/three_gate.py` | **V37.9.15新增** Phase 4 P3 三阶段门控纯函数模块（~280 行，零 I/O 零状态）— `pre_check(context)` 评估 alert-context-isolation + quiet-hours-00-07；`runtime_gate(context)` 评估 max-tools-per-agent + max-tool-calls-per-task + max-request-body-size（静态 policy 提取 signal 与 limit 数值比对产 pass/flag verdict）；`post_verify(context, response)` 扫 LLM 响应检测 [SYSTEM_ALERT] echo。`GateFinding` namedtuple (gate/policy_id/verdict/action/reason/enforced)。`ONTOLOGY_GATES_MODE` env 三档 off/shadow/on（默认 shadow，未知值 fall back shadow 观察优先）+ `_VALID_GATE_MODES = ("off", "shadow", "on")` 常量。与 `ONTOLOGY_MODE` 解耦（允许 ONTOLOGY_MODE=on 但 gates=off 的灰度组合）。FAIL-OPEN 契约: `_safe_evaluate_policy` 捕获 engine 所有异常返回 None → gate 降级为 verdict=pass + reason="engine_unavailable"，绝不冒泡到 tool_proxy。`format_findings_for_log()` 产出 `[gate:pre_check] N findings: policy_id=verdict(reason) ...` 单行便于 `grep [gate:]` 运维排查。|
| `ontology/tests/test_three_gate.py` | **V37.9.15新增** three_gate 契约守卫（57 单测）：TestGatesMode(7 含默认 shadow + case-insensitive + whitespace + 未知 fall back shadow)、TestGateFinding(3 含 immutable + 字段顺序稳定)、TestOffModeShortCircuit(4 含 off 模式不调 engine)、TestShadowModeNeverEnforces(2 反证 on 模式会 enforced=True)、TestPreCheck(8 含 alert 检测 + quiet-hours 上下文全分支)、TestRuntimeGate(6 含 signal≤limit boundary 合规 / signal>limit flag / 缺信号 tolerant)、TestPostVerify(5 含 assistant [SYSTEM_ALERT] 回声检测 + malformed response tolerant)、TestFailOpen(4 monkey-patch engine.evaluate_policy 抛异常契约)、TestExtractSignal(7 含 bool 排除于 int) + TestExtractAssistantText(6) + TestFormatFindingsForLog(3) + TestModuleIntegration(2 公开 API + gate name 稳定性) |
| `test_phase4_ontology_skeleton.py` | **V37.9.9新增→V37.9.12扩展** Phase 4 骨架守卫（17 单测）：六域声明/description 长度/Actor 核心实例/source_of_truth 对齐/Memory 四层匹配 memory_plane/policy 三类分类/policy 必填字段/hard_limit 仅 static/alert-isolation ordering_constraint/跨 ontology 引用一致性 + **V37.9.12 hard_limit 必须有 `limit` 字段 + max-tools-per-agent.limit == 12 横向守卫** |
| `ontology/tests/test_engine_phase4.py` | **V37.9.12新增** Phase 4 P1 wiring 契约（38 单测）：`load_domain_ontology()` 加载 + path 参数 + 缺文件抛错；`find_by_domain()` Actor/Resource/Task/Memory 归一化 + Provider.types 字符串包装 + Tool 主动返回 []（source_of_truth=tool_ontology）+ 未知域返回 [] + 预加载 ontology 注入 + 纯函数不改输入；`evaluate_policy()` 返回 12-key 稳定结构 + unknown found=False + static applicable=True + contextual/temporal applicable=None+reason=needs_context_evaluator + load_failed 不抛异 + context 参数兼容 + pre-loaded policy_data 注入；**max-tools-per-agent 契约**: limit=12, hard_limit=True, type=static, governance_invariant=INV-TOOL-001, 横向一致 config_loader.MAX_TOOLS; **_parse_limit_from_rule**: ≤/<=/< 提取 + 下划线千位分隔 + None 回退 |
| `ontology/tests/test_governance_cron_matcher.py` | **V37.2+新增** INV-CRON-003/004 匹配器回归测试（18 单测）：① endswith+word-boundary 精确匹配 ② Map-Reduce split 不误报 ③ prefix-subset entries 不混淆 ④ exec() 作用域陷阱正向对照 ⑤ YAML-matcher in-sync guard |
| `ontology/tests/test_governance_summary.py` | **V37.3新增** INV-GOV-001 silent error bug 回归测试（7 单测）：① error 状态注入→汇总不说"所有不变式成立" ② error 状态 exit_code≠0 ③ error 汇总用 💥 ④ pure fail 仍用 ❌ ⑤ all-pass 仍说✅ ⑥ mixed fail+error 各自计数 ⑦ 源码级 grep 守卫 `r["status"] in ("fail","error")` |
| `ontology/docs/cases/governance_silent_error_case.md` | **V37.3新增** Governance 自身三层嵌套盲区案例（子串匹配→exec 作用域→silent error summary）— 观察者的自我盲区 + MR-7 提案 + INV-GOV-001 提案 |
| `ontology/docs/cases/dream_map_budget_overflow_case.md` | **V37.4新增** Dream Map 预算溢出 + cache key 漂移案例（workload 增长 × cache key 对 mtime/sort 敏感 × Reduce 不相信缓存 → 连续超时，Reduce 从未执行）完整因果链架构图 + 三层根因 + 预算/契约/稳定三层修复 |
| `ontology/docs/cases/pa_alert_contamination_case.md` | **V37.4.3新增** PA 告警污染血案案例（系统告警经 Gateway sessions.json 污染对话上下文 × Proxy truncate 无语义理解 × Qwen3 attention 跨主题错误关联 × LLM 编造 macOS FDA 指令）六层根因深挖 + 完整因果链架构图 + 六条件组合爆炸分析 + 结构+行为双防线修复论证 |
| `ontology/docs/cases/heartbeat_md_pa_self_silencing_case.md` | **V37.8.16新增** PA 自残 HEARTBEAT.md 血案案例（2026-04-19 09:09 PA 把"任务完成"写进 OpenClaw 保留文件 HEARTBEAT.md → 13h 潜伏 → OpenClaw heartbeat 机制激活让 LLM 对所有用户消息回 HEARTBEAT_OK → Gateway stripTokenAtEdges 剥离 → 13h 完全静默）完整时间线 + 三层根因 + 六条件组合爆炸分析 + MR-15 元规则提炼 + 4/19 深夜原则 #28 违规复盘（Bad MAC 错归因让用户 auth reset）+ 6 轮假说错五轮的教训 |
| `ontology/tests/test_dream_cache_stability.py` | **V37.4新增→V37.4.2扩展** Dream Fix A+B+C+retry 回归测试（32 单测）：① Fix A cache-only fast path + SKIP_MAP_LOOPS 三处门控 ② Fix B 批次阈值 30/24000 ③ Fix C per-note content_hash 缓存 + 跨平台 md5 fallback + signal dedup ④ 动态 DREAM_TIMEOUT_SEC 预算 ⑤ flush_pending_batch 辅助函数语义 ⑥ Sources 缓存键保持不变 ⑦ **V37.4.1 Retry fallback**：MIN_DREAM_CHARS=3000 / MIN_ACCEPTABLE_CHARS=1500 / BEST_RESULT 追踪 / 温度单调递减 / 致命错误门槛用 MIN_ACCEPTABLE_CHARS ⑧ **V37.4.2 结构+变体**：UNIQ_NOTE_SIG_BLOCKS 数组 / 覆盖统计 header / 编号 cluster header / bland header 已移除 / retry 2+ 变体 prompt / llm_call 引用 \$cur_prompt |
| `test_kb_dream_helpers.py` | **V37.9.68新增→V37.9.68-hotfix +12** Dream 三阶推送 helper + shell 集成 **80 单测 / 11 类** (V37.9.68 68 + V37.9.68-hotfix +12): TestSplitDreamIntoChunks(8 V37.9.68-hotfix 新类 — empty/非string/血案场景回归 4 段必产 4 chunks/header 合并/超大段内部切/无 ## 段单 chunk/max_chunk 防御/空段跳过 + 5/15 真实 layout 模拟) + TestKbDreamShellGuards(12 → V37.9.68-hotfix +4: helper import 守卫 + 真调用 + **反向消除旧合并算法**`if len(current) + len(piece) + 1 <= max_chunk:` python_assert + V37.9.68-hotfix marker) + 其他 9 类 V37.9.68 原有 60 单测保留. **反向验证两层守卫真有效**: sabotage helper while 循环 → 1 fail / sabotage 回退到旧合并算法 → 5 fail (含血案场景回归 + 5/15 真实 layout). 接近真实数据模拟 (DEEP 含 ### 三子段 + WIDE 1700 + RADAR 900 + 总览 350) → V37.9.68-hotfix 后产 4 chunks: [1/4] DEEP+header 2132 chars / [2/4] WIDE 1417 / [3/4] RADAR 615 / [4/4] 总览 141 完美匹配 V37.9.68 设计预期。：TestNormalizeThemeKeywords(8 含 stopword 过滤 / 小写化 / 中文 2-gram+3-gram / 多层 prefix strip) + TestThemesOverlap(5 含 anchor 单独命中 / ≥2 共同 / ≥50% 短主题 / 空集) + TestExtractRecentThemes(7 含 14 天默认 / 日期降序 / 缺目录返回空 / 非法文件名跳过 / 缺主题行跳过) + TestFormatBannedThemesBlock(3 含血案 marker 字眼) + TestExtractDeepThemeFromChunk(6 含 V37.9.68 新格式 + V37.4 老格式兼容) + TestSplitWideRadarOutput(6 含 emoji 变体识别) + TestBuildOverviewBlock(5 含 H2 header 守卫 - 依赖 V37.9.21 分窗机制) + TestExtractSectionTitles(7) + TestBloodLessonQwenBimRegression(2 端到端复现 14 天 ban-list 阻止 Qwen-BIM 变体 + Memory Plane 新主题不被错误拦截) + **TestKbDreamShellGuards(12)** kb_dream.sh 源码级守卫: V37.9.68 marker / 14 天窗口字面量 / BANNED_THEMES_BLOCK 注入 / 2 LLM 调用不 3 chunks / DEEP fail-fast 顺序锁 / WIDE+RADAR 独立 [DEGRADED] / 总览段 helper 调用 / status.json schema 升级 / 4 段拼接 / MIN_DEEP_CHARS=1200 阈值 / V37.8.6 反污染守卫在 DEEP+WIDE_RADAR 两 system prompt 都保留 + TestSourceLevelGuards(5 含 V37.9.68 marker + 默认 14 days + overlap ≥2 阈值 + 血案注释 + overview H2 header 守卫) + TestCli(2 含 --show-recent-themes / help)。 |
| `kb_dream.sh` | **V36新增→V37.8.6→V37.9.68→V37.9.68-hotfix 多窗口 4 段独立** Agent Dream v2 MapReduce 全量 KB 探索引擎（Phase1 Map 14源+293笔记逐一提取信号 → Phase2 V37.9.68 三阶推送 (DEEP+WIDE+RADAR+总览) 跨域分析+推送 4 个独立 WhatsApp/Discord 窗口）。**V37.9.68 设计**（用户视角原则 #13 兑现）：(a) PREV_THEMES 3 → **14 天** + Python helper 提取归一化主题关键词作 ban-list 防 Qwen-BIM 类连续几周重复 (b) Phase 2 拆 V37.8.3 chunked 3 段 → **2 LLM 调用**：DEEP_SYSTEM 单主题深挖 (1500 字 + 14 天 ban-list 硬规则 + fail-fast 顺序锁) / WIDE_RADAR_SYSTEM 单调用产 2 段（WIDE 5 跨领域鲜人知 × 200 字 + RADAR 5 准期信号 × 300 字） (c) **总览段**用 build_overview_block() 规则提取不调 LLM (d) **失败降级**：DEEP 必过 (MIN_DEEP_CHARS=1200 不及格 exit 1) / WIDE+RADAR 独立 [DEGRADED] 不阻塞 (e) **status.json schema 升级** multitheme:true + deep_chars + wide_status + radar_status 段独立可观测 (f) **4 段 ## header** 自然复用 V37.9.21 多窗口分片，推送 4 个独立 WhatsApp 窗口。**V37.4 Fix A+B+C** / **V37.4.1 retry** / **V37.4.2 结构+变体**（见下方 changelog）。**V37.8.6 自引用幻觉防御保留**（log→stderr / heredoc _sanitize / file errors='replace' / DEEP_SYSTEM + WIDE_RADAR_SYSTEM 双 system prompt 反污染守卫）|
| `kb_dream_helpers.py` | **V37.9.68新增→V37.9.68-hotfix +9 公开函数** Dream 三阶推送辅助纯函数模块（~470 行，零 I/O at import，9 公开函数）：(1) `normalize_theme_keywords(text)` — 主题归一化为关键词集合（剥 markdown header + 中文 2-gram+3-gram 滑动窗口 + 英文 token 小写+停用词过滤）(2) `themes_overlap(a, b)` — 三层判定（anchor 长 token 单独命中 / ≥2 共同 / ≥50% 短主题），anchor 阈值实测调优：英文复合标识符 (含 hyphen/digit) ≥4 字 / 英文纯字母 ≥8 字 / 中文 ≥3 字 — 避开 "plane" 类 5 字纯字母 false positive (3) `extract_recent_themes(dream_dir, days=14)` — 扫 dream 目录提取最近 N 天主题（含日期降序 + 关键词归一化）(4) `format_banned_themes_block(themes)` — DEEP prompt ban-list 段渲染（含硬规则文字 + "违反整份输出作废"）(5) `extract_deep_theme_from_chunk(chunk)` — 从 DEEP LLM 输出抓主题标题（兼容 V37.9.68 新格式 + V37.4 老格式）(6) `split_wide_radar_output(content)` — 单 LLM 调用 WIDE+RADAR 拆分为两段（识别 🌐/📡 emoji header）(7) `build_overview_block(deep_theme, wide_themes, radar_themes, kb_stats)` — 总览段规则提取（不调 LLM，含明日关注规则模板）(8) `extract_section_titles(section_md, max_n)` — 从 WIDE/RADAR 段抽各子主题标题供总览段 (9) **`split_dream_into_chunks(text, max_chunk=4000)` (V37.9.68-hotfix)** — WhatsApp 多窗口分片纯函数：每个 ## header 段独立成 chunk (不合并小段) + header 段合并到第一个 ## 段作 prefix + 单段超 max_chunk 时按 \\n 内部切分 + 空段静默跳过. **修复 V37.9.68 设计假设错配** (V37.9.66 类别 B): V37.9.68 changelog 说"4 段 ## header 自然复用 V37.9.21 多窗口分片", 但 V37.9.21 实际是"current+piece <= max_chunk 就合并"算法. V37.9.68 4 段大小不均匀 (DEEP ~5000 / WIDE ~1700 / RADAR ~900 / 总览 ~400) 让 WIDE+RADAR (~2600) 被合并成 1 chunk. Mac Mini 5/15 03:00 cron 实测确认: 用户收到 [3/3] 而非 [4/4]. CLI `--show-recent-themes DREAM_DIR` 运维查询。 |
| `gameday.sh` | **V33新增** GameDay 故障演练（5场景：GPU超时/断路器/快照/SLO/Watchdog，`bash gameday.sh --all`） |
| `jobs/dblp/run_dblp.sh` | **V30.5新增** DBLP CS论文监控（多关键词搜索、免费API、每日12:00推送+KB写入） |
| `jobs/hf_papers/run_hf_papers.sh` | **V30.5新增** HuggingFace Daily Papers 监控（热门AI论文、每日10:00推送+KB写入） |
| `jobs/semantic_scholar/run_semantic_scholar.sh` | **V30.5新增** Semantic Scholar 论文监控（引用量排序、每日11:00推送+KB写入） |
| `jobs/acl_anthology/run_acl_anthology.sh` | **V30.5新增** ACL Anthology NLP论文监控（顶会论文、每日09:30推送+KB写入） |
| `jobs/pwc/run_pwc.sh` | **V31新增** Papers with Code 论文+代码监控（免费API、每日13:00推送+KB写入，核心价值：论文+代码仓库关联） |
| ~~`jobs/openreview/`~~ | **V35 已移除**（API 403 post-security-incident，S2 已覆盖顶会论文） |
| `preference_learner.py` | **V30.4新增** 用户偏好自动学习器（从对话历史推断偏好，写入 status.json） |
| `activate_openclaw_features.py` | **V30.5新增** OpenClaw 功能激活脚本（检查+启用 agent 工具配置） |
| `notify.sh` | **V33新增→V35+升级** 统一消息推送（WhatsApp + Discord 双通道 + **自动重试3次指数退避** + **失败队列持久化+自动重放**，`source notify.sh && notify "msg"`） |
| `kb_harvest_chat.py` | **V37新增→V37.1升级→V37.9.130 层级 Reduce** 对话精华提炼器 MapReduce 版（从 proxy 捕获的每日对话中 LLM 分段提取+去重合并，零数据丢失，每日 06:00 cron）。**V37.9.130 Reduce 超时血案修复**：层级分批 Reduce（`_reduce_hierarchical` 每批 ≤REDUCE_BATCH_SIZE=4 段多轮归并 9→3→1，替代单次 ~40K 大请求）+ REDUCE_TIMEOUT=300s（镜像 V37.9.129 doubao）+ `_llm_call_with_retry`（Map/Reduce 失败重试 1 次）+ `_mechanical_dedup` fail-soft（LLM 失败机械行级去重兜底零丢失，KB 标 `[REDUCE_DEGRADED]`）+ 轮级熔断（整轮全失败不再下一轮）+ Map 全失败返回 None 不伪装"无关键内容"（原 bug 会 mark_processed 永久丢数据）+ `--days` 默认 1→3（失败日自动补提炼，is_processed 幂等）+ last_run 加 degraded/map_failed 可观测字段（status 枚举不变守 V37.9.72 watchdog 契约） |
| `test_harvest_chat.py` | **V37.1新增→V37.9.130扩展** 对话精华提炼器单测（57 个用例 / 9 类：chunk 分块 8 + prompt 3 + MapReduce 5 + process_date 4 + 加载 4 + 语法 4 + **V37.9.130 新增 29**：TestMechanicalDedup(5 含零丢失契约+全段头 fallback) + TestLlmCallWithRetry(3) + TestHierarchicalReduce(6 含 9 段血案场景 3 次小请求 / batch≤4 守卫 / 单批失败 fail-soft / 全失败轮级熔断零丢失) + TestExtractKeyPointsMetaV130(4 含 Map 全失败≠无关键内容 MR-4 修复) + TestProcessDateDegradedV130(3 含 degraded KB 标记+error 不标记已处理) + TestV379130SourceGuards(8 常量锁定+--days=3+status 枚举契约+旧单次 Reduce 已退役)。**反向验证三层守卫真有效**：sabotage Map 全失败旧行为 → 2 fail；删轮级熔断 → 1 fail；--days 回退 1 → 1 fail。还原后 57/57 全过。**V37.9.130 同时补登历史 debt**：V37.1 起该测试从未注册 full_regression，本次接入 |
| `jobs/ontology_sources/run_ontology_sources.sh` | **V37.1新增** Ontology 专属信息源监控（4 RSS: W3C/JWS/DKE/KBS + 两层关键词过滤 + LLM 中文摘要+要点+价值 + Discord #ontology 推送 + KB 归档，cron 10:00/20:00） |
| `jobs/finance_news/run_finance_news.sh` | **V37.8.2新增→V37.8.5→V37.9.103 冻结≠死亡** 全球财经/政策新闻每日汇总（双通道：8 RSS 直连 + X/Twitter Syndication API，72h 窗口覆盖周末，LLM 结构化分析+价值评级+国内外对比+投资建议+风险提示，cron 07:30）。V37.8.5：僵尸检测导入 `finance_news_zombie.classify_zombie` 模块。**V37.9.103**：parser 捕捉 `newest_age_days`，frozen（快照冻结活账号）分流到 `degraded_${DAY}.txt` 仅 🧊 可观测日志不告警（避免错杀 + 接受退化），ZOMBIE_FILE 只收 stub+dead（真可移除），3 天告警措辞 僵尸→可移除 + 澄清 frozen 不在此列 |
| `jobs/finance_news/finance_news_zombie.py` | **V37.8.5新增→V37.9.103「冻结≠死亡」四档重构** Syndication 僵尸检测纯函数模块。**V37.9.103**：V37.9.102 复盘揭示 Syndication 平台级退化把天天发推的活账号（XHNews/CGTN）快照冻结 6-10 月前，V37.8.5 的 "stale=可移除" 在退化下错杀活账号。新增 `newest_age_days` 用最新推文年龄拆四档：**stub**（0 推文 embed-disabled，Syndication 永久无用→可移除）/ **dead**（newest ≥ DEAD_AGE_DAYS=730 天真死/改名→可移除）/ **frozen**（newest<730 或无法判定 = 快照冻结/低频活账号→**绝不移除**，血案核心）/ **alive**。is_zombie_suspect = stub OR dead，frozen 永远 False。DEAD_AGE_DAYS 与 ai_leaders_rotation.py ZOMBIE_DEAD_DAYS 跨模块一致（test 守卫） |
| `jobs/ai_leaders_x/ai_leaders_rotation.py` | **V37.9.101新增→V37.9.103 frozen/dead 拆分** 账号轮换 + 健康分类纯函数模块。`select_batch`（轮换+环绕，11/run 3 run 覆盖 31，防 429）+ `classify_account` **V37.9.103 五态**（rate_limited 瞬态不误杀 / stub embed-disabled / **frozen 7d<newest<730d 冻结活账号勿移除** / dead ≥730d 真死可移除 / alive）+ is_zombie_suspect（仅 stub+dead）。预防 #18 zombie loop-wiring 将来错杀 karpathy 类冻结活账号 |
| `jobs/ai_leaders_blogs/run_ai_leaders_blogs.sh` | **V37.9.108新增→V37.9.108-hotfix 首跑剪枝** ai_leaders 从 X (429+快照冻结退化) 转向**博客/Substack RSS** 非 X 渠道，收集 AI 大神长文观点（13:30 HKT 1x/天）。11 策展大神 feed 偏重"不同意见"（Marcus on AI/AI Snake Oil 怀疑派 + Import AI/Ahead of AI/Interconnects/Eugene Yan/Karpathy/The Gradient/One Useful Thing/Don't Worry About the Vase/HF），不与 rss_blogs 4 源重叠。紧贴 rss_blogs 已验证管道（RSS + LLM 6 字段 + 🎚️ project_alignment_scorer 项目对齐评分 + hallucination_guards LEVEL_4 + 双通道「🧠 AI 大神观点」+ KB + 多窗口 + 每 feed FAIL-OPEN）。prompt 适配"学者立场/不同意见"。**V37.9.108-hotfix（2026-06-04 Mac Mini 首跑验证）**：9/11 feed 活，fast.ai（Quarto 迁移 RSS 坏）+ Anthropic News（无公开 RSS）404→换高置信 Substack One Useful Thing（Ethan Mollick）+ Don't Worry About the Vase（Zvi）。首跑 45 篇全解析成功 + **🎚️ 高对齐 25/45（⭐≥4）= 发现机会点引擎生效**。替代退化的 ai_leaders_x（后者保持 enabled 避免禁用级联 6 依赖，真停用留 follow-up） |
| `jobs/ai_leaders_bsky/run_ai_leaders_bsky.sh` | **V37.9.111新增→V37.9.111-hotfix 首跑剪枝** ai_leaders 加 **Bluesky 实时短观点维度**（17:00 HKT 1x/天）。**V37.9.111-hotfix（2026-06-05 Mac Mini 首跑）**：7/10 handle 活，3 个 HTTP 400=「Profile not found」handle 漂移（高粉大神迁自定义域名）→ `ylecun`→`yann-lecun.bsky.social`（验证可用）/ `timnitgebru`→`timnitgebru.blacksky.app`（searchActors 确认）/ `fchollet` 停用→剪枝。10→9 账号。首跑 17 帖全解析 + 推 4 窗口 + 🎚️ 高对齐 1 = 管道工作。，补足 blogs 长文（V37.9.108）+ ai_leaders_x（X 429+冻结退化产 ~0）的实时短帖维度。Bluesky 公开 AppView `getAuthorFeed` JSON API **无需认证 + 带缓存**（docs.bsky.app 确认），30 万学者 2023-2025 已迁入（arXiv 2505.24801 + Science）。**仅抓取层**从 RSS XML 换为 getAuthorFeed JSON（`filter=posts_no_replies` + skip reasonRepost + MIN_POST_CHARS=50 过短过滤 + MAX_PER_ACCOUNT=3 + at:// URI→`bsky.app/profile/{handle}/post/{rkey}` web URL + 外链 embed 捕获），**下游全复用 blogs 管道**（call_llm_single_with_retry + parse_6field_output + project_alignment_scorer rule_check + hallucination_guards LEVEL_4 + 双通道「🦋 AI 大神实时观点」+ KB + 多窗口 + per-account FAIL-OPEN + fail-fast）= MR-8。10 大神 contrarian 为主（8 confirmed handles：ylecun/fchollet/melaniemitchell/rao2z/randomwalker/timnitgebru/mmitchell/howard.fm + Gary Marcus/Emily Bender 候选，跨 7+ 流派：世界模型/复杂系统怀疑/LLM 推理怀疑/炒作祛魅/伦理/开源派）。prompt 适配短帖防过度膨胀（V37.9.40 ai_leaders_x 过度分析教训）。handle 可达性待 Mac Mini 首跑验证（原则 #33 + 反馈 #1，per-account FAIL-OPEN 死 handle WARN+跳过+剪枝） |
| `test_finance_news_zombie.py` | **V37.8.5新增→V37.9.103扩** 僵尸检测 32 单测：四档 tier（stub/dead/frozen/alive）+ frozen 血案守卫（XHNews/CGTN 99/99 newest<730→frozen 绝不移除）+ dead 730 边界 + 跨模块 DEAD_AGE_DAYS 一致性 + shell 集成（newest_age_days 捕捉 / degraded_file 分流 / 可移除-冻结前缀）+ 反向验证（frozen→suspect sabotage 立即 fail）|
| `test_wa_gateway_resilience.py` | **V37.8.13新增** Gateway 宕机韧性三层修复 21 单测：TestQuietAlertDiscordAlways(4) quiet_alert 静默期 Discord 穿透 + TestWaKeepaliveEscalation(9) 连续 WARN 升级 + TestRestartGatewayVerification(5) post-bootstrap 健康验证 + TestCrossFileGuards(3) 跨文件一致性 |
| `test_restart_launchd.py` | **V37.9.13新增** restart.sh 架构清理 20 单测：TestRestartVialaunchdHelper(6) helper 函数契约（kickstart -k / bootstrap fallback / 5×2s 健康验证 / return 2 / launchctl 可用性检测）+ TestAdapterViaLaunchd(3) + TestProxyViaLaunchd(2) + TestSingleManagerInvariant(5) V37.9.12.1 双管理血案防线（nohup 必在 fallback 分支 + V37.8.13 Gateway 逻辑保留 + #48703 hotfix 保留）+ TestShellExecutability(3) + TestRuntimeHelperBehavior(1) subprocess 实跑 helper 验证 return 2 |
| `providers.d/` | **V37新增** Provider Plugin 目录（YAML/Python 插件自动发现，`_example.yaml` + `_example_provider.py` 示例） |
| `docs/provider_plugin_guide.md` | **V37新增** Provider Plugin Extension Guide（60秒添加新 Provider，合约验证，YAML/Python 双模式） |
| `examples/minimal_consumer/` | **V37.9.104新增→V37.9.107 chunk-3a +convergence** ontology-engine 包化第一个真消费方 demo（虚构 WeatherBot Agent Runtime，工具/域/策略/不变式全部不同于 bridge）。`weatherbot.py`（被审计代码）+ **`weatherbot_state.json`（V37.9.107 convergence 源文件）** + `run_demo.sh`/`run_demo.py`（设 ONTOLOGY_CONFIG_DIR+ONTOLOGY_PROJECT_ROOT，练习 ToolOntology/find_by_domain/evaluate_policy/governance run_all **+ V37.9.107 convergence** 五能力，端到端验证 config-injection）+ `ontology/` Layer 2 YAML（tool/domain/policy/governance **+ V37.9.107 convergence_ontology.yaml**）+ `README.md`。引擎的"Doubao 时刻"（真消费方接入才证明可扩展）。 |
| `docs/ontology_engine_extension_guide.md` | **V37.9.104新增→V37.9.107 chunk-3a 更新** Ontology Engine Extension Guide（60秒接入：pip install → 写自己 YAML → export 双 env → openclaw-ontology-query/audit）。镜像 provider_plugin_guide.md。含 5 种 check_type 参考 + YAML 正则转义陷阱 + **"Config-injected phases"（三阶段 invariant/MRD/convergence 全 config-injected，含写 convergence spec 指南）+ chunk-3b follow-up（MRD 文件名模式参数化）诚实登记**（chunk 3a 已修 convergence 路径耦合）。 |
| `test_ontology_extension_demo.py` | **V37.9.104新增→V37.9.107 +3** chunk 4/3a 端到端守卫（**15 单测 7 类**）：run_demo.sh 真 subprocess + 注入加载 demo 配置非 bridge + **反向验证（不注入 → 引擎读 bridge，证明 demo 通过依赖注入）** + demo↔bridge 工具集相异 + governance run_all 审计 demo 全过 + **TestConvergenceConfigInjectionDemo(3 V37.9.107：注入读 WeatherBot convergence spec 非 bridge / 反向验证不注入读 bridge 5 specs / verify_convergence 零 drift 源文件经 PROJECT_ROOT)** + 源码守卫。 |
| `ontology/docs/architecture/industrial_ai_paradigm.md` | **V37新增** 工业AI范式文档（三平面架构+五项工业需求+范式对比，切断 Dream→PA 链式幻觉） |
| `ontology/docs/architecture/target_architecture.md` | **V37.1新增** Ontology 终态架构（四层设计+六域概念模型+策略引擎+三阶段门控+迁移路径 Phase 3-5） |
| `ontology/docs/cases/pa_echo_chamber_case.md` | **V37.1新增** PA 迎合性回复案例分析（三环反馈陷阱根因+SOUL.md 批判性规则修复+Phase 4 结构性修复路径） |
| `ontology/docs/cases/dream_quota_blast_radius_case.md` | **V37.2新增** Dream MapReduce 配额耗尽跨 Job 爆炸链案例（30+ LLM 调用 × Qwen3 宕机 → Gemini 配额耗尽 → HN 垃圾推送，三层修复+2 新不变式） |

## 版本变更历史

> 完整变更记录见 `docs/changelog.md`，按需 read 查阅。

| 版本 | 日期 | 关键变更 |
|------|------|----------|
| V37.9.143 | 2026-06-12 | **外部评审2 P0 双兑现 — compatibility_matrix 漂移防护机器化 (b 完结) + slo_benchmark 四态/双窗口/阈值正文 dev 侧增强 (a 的 dev 部分)** — ① **触发**: status.json focus 指明下一 session 优先评审 P0。ArXiv 仍卡 endorsement（背书状态待用户确认）。② **(b) 矩阵漂移防护完结**: (i) providers.py 抽 `matrix_table_lines()` / 新增 `capability_table_lines()` 两张表直出纯函数（print_matrix 改为 delegate, 单一真理源）+ `--capability-matrix` CLI (ii) **顺手修 "5/4 verified" 分母超界 bug** — Verification Status 旧分母只数 modalities+tool+streaming (4) 但分子 verified_features 含 fallback/reasoning (6 维度)，新增 `ProviderCapabilities.verifiable_features()` 同口径分母（fallback 恒可验证不依赖声明）→ Qwen 5/5 + **Doubao 5/6**（verified_fallback=False 守 V37.9.55 诚实语义）(iii) **新建 `gen_compat_matrix.py`**（镜像 gen_jobs_doc 模式）: `--check` 比对 doc 两个表格段 vs providers.py 直出（exit 1 = drift + 逐行 diff 摘要）/ `--fix` 重写表格段（人工段落"验证档位/Fallback 路径/工具模式验证"绝不触碰，#25(b) 比对范围契约）/ MR-11 诊断走 stderr (iv) **首跑即抓真漂移**: V37.9.142 手动刷新自身漏掉 doubao json_mode=True（plugin 声明）被手写为 — + display_name 短名漂移 — 工具上线第一天就证明"手动刷新必漂移"，--fix 一键修复 (v) full_regression doc-drift 层接入（gen_readme_badges 之后第 4 个 drift 检测）+ suite 注册。③ **(a) slo_benchmark dev 侧增强**（Mac Mini 报告重生成留用户执行）: (i) **四态 verdict** — `tool_calls_total==0 → "N_A_NO_TOOL_CALLS"`（无此类流量不可评判，区别于 OBSERVING 有流量但样本不足；镜像 slo_dashboard V37.9.79 N/A 三档），汇总判定跳过 N_A（不 block ALL PASS 也不掩盖 FAIL）+ report 加 na_count (ii) **24h/7d 双窗口** — `build_trend_windows()` 复用 slo_dashboard load_history/filter_history/compute_trends（MR-8 零 copy-paste），数据源 ~/.kb/slo_history.jsonl（V37.9.79 slo_snapshot 每小时累积），无历史/模块缺失/损坏 → None + 报告显提示行（FAIL-OPEN）(iii) **Threshold Rationale 正文段** — config.yaml V37.9.79 注释升级为报告正文（Mac Mini 实测 p95=37.5s baseline + backend 29.7s 证据 + "调阈值是承认真实性能不是掩盖问题" + 恢复 30000ms 条件），**阈值恢复后文案自适应**（target≤30000 时切换为"已恢复 V36 原始目标"不留谎言）(iv) **修 Methodology 硬编码漂移** — "latency p95 ≤30s" 行 V37.9.79 改 config 后停留 30s 近一个月，改为动态读 report targets + 四态说明行。④ **顺手修日期敏感测试 bug**: test_kb_dream_helpers TestCli 硬编码 dream 文件名 "2026-05-13.md" 在今日 (6/12) 恰好滑出 --days 30 窗口致 full_regression 首跑 fail（昨天还绿）— 改相对日期 (now-3d) 永不出窗。非本次改动引入（原则 #28 三问全过，时间流逝触发）。⑤ **40 新单测**: test_gen_compat_matrix.py 27（providers 表直出 / 分母守卫 / extract/check/fix / 人工段保护 / 真仓库 e2e / V37.9.143 marker）+ test_slo_benchmark.py +13（TestV379143FourStateAndTrends: N_A 不 block ALL PASS / N_A 不掩盖 FAIL / tool=1 边界仍 OBSERVING / 双窗口渲染 / rationale 自适应双向 / Methodology 动态 / build_trend_windows mock 双路径 / 源码守卫反硬编码回退）。**反向验证三轮守卫真有效**: sabotage 分母回退旧口径 → 2 fail；sabotage doc 表行 → check exit 1；sabotage 四态回退 V37.9.99 行为 → 2 fail。还原后全过。⑥ **验证**: 123 suites（124 含条件跳过）/ 4304→**4344 tests (+40)** / 0 fail / 治理 90/90 / 828 checks / 安全 95/100 / **VERSION 0.37.9.70 不变**（证据工具/守卫扩展零业务语义，同 V37.9.140-142 惯例）。⑦ **Mac Mini 待用户**: git fetch+reset 同步 → `python3 slo_benchmark.py --save` 真实数据重生成报告（首次含四态+双窗口+rationale，预期 verdict 诚实显示 OBSERVING 或真实 PASS/FAIL 而非旧 samples=1 ALL PASS）→ commit 报告入库即 #25(a) 完整闭环。⑧ **元价值**: 外部评审2 P0 从"登记"到"机器化"——(b) 把 V37.9.142 "手动刷新"升级为 CI 守卫且首跑即抓手动刷新自身的遗漏（手动同步必漂移的最快实证）；(a) 把"报告会说谎"的三个根源（0 样本标 PASS / 无趋势上下文 / 阈值原因藏在 config 注释）全部正文化。修复方式延续"接入既有机器"（matrix 用 providers.py 真理源 / 双窗口用 slo_dashboard 历史 / 徽章用 badges spec），零新状态源（日落法 #34）。 |
| V37.9.142 | 2026-06-11 | **外部评审2 吸收（7.8/10, 同日第四段收尾）— 3 个 P0 quick win 当晚完成 + P0/P1/P2 三档整合登记** — ① **评审核心**: 综合 7.8/10（定位/完整性/事故学习 9 分 / 可迁移性 6.5 / 文档一致性 6 / 复杂度控制 6）。核心指令与日落法北极星共振: 下一阶段从"加功能"切换到**证据刷新与一致性收敛 + 降组合复杂度 + 核心框架与个人 PA 拆层**。② **当晚完成 (评审 7 动作中 3 个)**: (a) **docs/compatibility_matrix.md 刷新** — 停在 2026-04-05 七 provider 的最大漂移点修复: 8 providers 含 Doubao（verified 5/5）+ **验证四档诚实标注**（production_observed: qwen/doubao + gemini 已退役 / declared: openai/claude/kimi/minimax/glm 0/N）+ gemini geo-block 退役现状（V37.9.129 exclude_providers）+ fallback 链现实（Qwen3 300s → doubao 300s, gemini 不在链中）+ 插件优先接入指南（providers.d/ 60 秒路径替代改 providers.py） (b) **FEATURES 正文测试行接自动同步** — 评审抓到正文 `118 套单测/4099 用例` vs 头部 4286 内部漂移（恰是 unfinished #19 doc-stat-sync V2 登记的 gap）: gen_readme_badges `_doc_header_specs` 加第 4 个 spec（FEATURES `\| **测试** \|` 正文行 anchor + 套单测/用例双 token），从"手动改数字"升级为机器同步; spec 清单守卫 3→4 + 新增 `test_features_body_test_row_spec_v37_9_141`（真仓库行与权威值一致断言） (c) **preflight push test 真因闭环** — V37.9.141 修复后用户重跑全部通过, check 16 真实失败原因首次可见 = V37.9.138 已知 4.27 plugin 按需 staging 良性场景（baileys/jimp 3 deps 安装 4956ms 后自愈）, unfinished 销项。③ **评审时点滞后 2 项澄清（带证据, 不照单全收）**: 单一事实源建议（project_facts.json）**已存在** — status.json quality + audit_metadata + gen_readme_badges 三件套（V37.9.99/125）, 真 gap 是覆盖面（正文行/矩阵未接入）; ontology dogfood 建议的 WeatherBot **已存在** — examples/minimal_consumer（V37.9.104/107）+ PyPI 已发布（V37.9.137）, 真 gap 是仓库外独立 dogfood。SLO OBSERVING 判定 V37.9.99 已实现, gap 仅是入库报告未重生成。④ **三档整合登记（替代旧 5/14 评审项, 避免重复累积）**: P0 = SLO 报告 Mac Mini 真数据重生成 + 矩阵漂移防护接入 full_regression doc-drift 层; P1 = 三层产品边界拆层叙事（Core Runtime / Governance-Ontology / Personal-PA-Example）+ examples/minimal_runtime + requirements 依赖边界澄清（core 零依赖 vs ontology 需 PyYAML, 评审者环境 7 用例即因此失败）+ three-gate 对外叙事区分观测/强制; P2 = Provider 验证四档字段化（verification_tier 进数据模型矩阵自动产）+ Reliability Bench 10 场景扩展 + 仓库外 dogfood + complexity budget 评估（注意与日落法张力: 勿为预算加新机器）+ 话语权续篇文章。⑤ **验证**: 122 suites / 4304 tests (+1) / 0 fail / 治理 90/90 / 828 checks / 安全 95/100 / VERSION 0.37.9.70 不变（文档刷新 + doc-sync 机器扩展, 零业务语义）。⑥ **元价值**: 两次外部评审（4/17 + 6/11）对照显示战略跃迁被外部确认（bridge→control plane 9 分）, 而两次都点中同一软肋（文档/证据漂移 + 个人耦合）— 印证 #19/#34 已登记方向正确, 评审价值在把"已知 gap"升级为"外部可见的可信度成本"。修复方式全部走"接入既有机器"而非手动改数字（日落法: matrix 用 providers.py 真理源 / FEATURES 行用 badges spec）。 |
| V37.9.141 | 2026-06-11 | **preflight check 16 崩溃血案修复 — bash 3.2 未 brace 变量紧贴全角字符 quirk 第 2 次演出 scanner 化（V37.9.43-hotfix2 候选元规则兑现, Mac Mini 实测驱动）** — ① **触发**: 用户合并 V37.9.140 后 Mac Mini 跑 `preflight_check.sh --full` 验证, check 16/19 推送通道 smoke test 崩溃 `line 868: PUSH_RC?: unbound variable`, check 17-19 未跑。② **三问 (原则 #28)**: Q1 潜伏 bug ✓ — line 868 `fail "...（退出码 $PUSH_RC）..."` 仅在 push test **真失败**时执行; 今晨 12:50 preflight 推送成功走 pass 分支未触发, 今晚速率限制窗口过期后推送真失败首次走 fail 分支 / Q2 非今日引入 (preflight 最后改动 V37.9.123) / Q3 最小修复 = `${VAR}` 显式 brace (V37.9.43-hotfix2 同款)。**根因**: macOS bash 3.2 在 UTF-8 locale 下把紧贴变量名的全角字符（`）` U+FF09）的 UTF-8 字节并入变量名 → `set -u` 触发 unbound variable 整脚本崩溃。**locale 依赖是隐蔽点**: cron 环境 (LANG 未设, C locale) 不触发 — 12 处同款在 cron 跑数月无恙, 用户交互终端 (UTF-8) 立即崩。**连带后果**: 崩溃吞掉真实推送失败的退出码/stderr (真失败原因待用户同步后重跑可见)。③ **全仓扫描 14 处潜伏实例批量修复** (原则 #31 全量同步): preflight_check.sh ×2 (`$PUSH_RC）`/`$DC_RC）` 崩溃点) + job_smoke_test.sh ×4 + arxiv ×3 + hf_papers ×2 + gameday/finance_news/github_trending 各 1 — 全部 `${VAR}` brace, 行级修复跳过注释, bash -n 7 文件全过。.py 文件 0 命中。④ **scanner 第 7 quirk pattern (两次演出达门槛, V37.9.134 同款三步跃迁)**: cross_os_quirk_scanner.py 新增 `detect_unbraced_var_adjacent_cjk` — regex `\$[A-Za-z_]\w*[CJK表意/全角形式/CJK标点]`, `$1`/`$?` 特殊参数天然豁免 (regex 要求字母开头), 注释行豁免, `${VAR}` brace 即合规。**候选元规则 shell-string-with-cjk-must-brace-vars (V37.9.43-hotfix2 登记) 经日落法 MR-22 决策不立独立 MR** — scanner pattern + INV-CROSS-OS-001 扩展已机器化 (与 V37.9.134 Quirk 6 同款 sunset 决策, 0 新 MR / 0 新 INV / +1 check)。CLAUDE.md 原则 #35 同族 quirk 家族 (zsh # 注释 / 全角括号 glob)。⑤ **10 新单测** test_cross_os_quirk_scanner 40→50 (TestQuirkUnbracedVarCjk): 双血案场景字面量 (preflight L868 + wa_e2e CHUNK_COUNT) / 全角开括号 / CJK 表意 / brace 合规 / ASCII 相邻不误报 / 注释豁免 / 特殊参数豁免 / **7 个修复后真实文件 0 findings 防回退** / CLI sabotage exit 1。连带: checker 注册守卫扩 7 函数 + CLI 列表扩 7 quirk + 血案引用扩 8 版本。⑥ **INV-CROSS-OS-001 扩展** (meta_rule=MR-7 不变, 8→9 checks): declaration 谱系 7→8 血案 + Quirk 7 完整语义说明 (含 locale 依赖隐蔽性) + sunset 决策登记 + 新 check `def detect_unbraced_var_adjacent_cjk` + 血案元组 6→8。RUNTIME 双 check (scan 0 violations + 单测全过) 自动覆盖新 pattern。⑦ **反向验证守卫真有效**: sabotage 还原 preflight L868 未 brace 形式 → scanner 精确定位 `L868 [unbraced_var_adjacent_cjk]`; CLI sabotage 测试断言 exit 1。还原后 0 violations + 治理 90/90 exit 0。⑧ **验证**: 122 suites / 4293→4303 tests (+10) / 0 fail / 治理 90/90 不变 (INV-CROSS-OS-001 内涵扩展非新增) / 827→828 checks (+1) / 23 MR 不变 (sunset 决策不立新 MR) / 安全 95/100 / VERSION 0.37.9.70 不变 (quirk 修复 + scanner/治理扩展零业务语义, 同 V37.9.134 惯例)。⑨ **Mac Mini 待用户**: git fetch+reset 同步 (preflight/job_smoke/gameday + 4 个 jobs 脚本走 FILE_MAP/auto_deploy 同步) → **重跑 `bash preflight_check.sh --full`** — check 16 不再崩溃, 如 push test 仍失败将首次显示真实退出码+stderr (候选原因: V37.9.138 已知 4.27 plugin 按需 staging 窗口 timeout 或 transient)。⑩ **元价值**: V37.9.43-hotfix2 (修 2 处 + 登记候选) → **V37.9.141 (第 2 次演出 + 全仓 14 处清零 + scanner 化)** — 第 7 个 quirk pattern 延续"每次血案转化为下次免疫力"。同时是用户视角/Mac Mini 实测三层验证不可替代的第 N 次硬实证: dev 单测+治理+badges 全绿, 生产 preflight 交互执行才暴露 locale 依赖 quirk。 |
| V37.9.140 | 2026-06-11 | **双小修同 session（同日第三 session, 纯 dev 待办清场）— #27 suites 计数抖动假阳性根治 + #25 #48703 hotfix 日落法退役** — ① **#27 (full_regression suites 121/122 抖动)**: 对抗审计 layer 3.5 按 git 工作树洁净度条件执行（不干净跳过），旧回写 `--set quality.test_suites "$PASS"` 让 suites 在 121（dirty）/122（clean）间抖动 → gen_readme_badges doc-drift 守卫在 doc/权威值错配窗口偶发假阳性（2026-06-11 V37.9.139 收工实测命中）。**修复（unfinished #27 选项 a — 根因层）**: 新增 `SUITES_SKIPPED_COUNTED` 计数器，对抗层跳过执行时 +1（跳过 ≠ suite 不存在，suite 清单数是确定值），回写改 `SUITES_TOTAL=$((PASS + SUITES_SKIPPED_COUNTED))`；**PASS/控制台汇总语义不变**（只数真执行通过的 suite, 不谎报 — MR-4 诚实约束）。弃选 (b) 容忍区间（弱化守卫掩真漂移）+ (c) max() 取大（真删 suite 时计数卡死旧值）。② **#25 (#48703 hotfix 退役, 日落法 MR-22)**: restart.sh 内 listeners-Map sed 自动补丁段移除 — 上游 2026.3.23 已修复 + Gateway 6/11 已升 v2026.4.27（V37.9.138 登记 follow-up 兑现），该段在 4.27 下永为 no-op 且是 restart.sh **唯一 sudo 依赖**（退役顺带消除 cron 场景 sudo 风险）。**退役"自动修补"不退役"监控"**: preflight 12/19 #48703 检查保留（grep unpatched 模式, 未来 Gateway 升/降级若回归立即 fail）+ 新增跨文件守卫 `test_48703_upstream_watchdog_preserved_in_preflight` 防未来日落法清理误删监控。连带: restart.sh Gateway 段补标准 `# ── Gateway (:18789)` 段头 + test_restart_launchd `_proxy_section` 边界 regex 从 `# ── #48703` 改 `\n# ──`；`test_48703_hotfix_preserved` 反转为 `test_48703_hotfix_retired_v37_9_140`（assertNotRegex `^\s*sudo\s` 命令级守卫, 注释提及 sudo 字样豁免）。③ **7 新单测**: test_v37_9_69.py +6（TestV379140SuitesCountStability — marker/计数器初始化/dirty 分支递增/回写 PASS+SKIPPED/反模式旧写法消除守卫/**行为级 bash 真跑算术行断言 dirty(121+1) 与 clean(122+0) 两路径同值 122 = 抖动消除证明**, 与 V37.9.69 C 项同 bug 家族聚合 MR-8）+ test_restart_launchd.py 净 +1（退役守卫 + 跨文件 preflight 监控守卫, 替换原保留守卫）。**反向验证三轮守卫真有效**: sabotage 回退抖动写法 → 3 fail；restart.sh 重引入 sudo sed → 1 fail；preflight 删 #48703 监控 → 1 fail。还原后全过。④ **验证**: **122 suites**（#27 修复后 suites 首次稳定为含对抗层的清单确定值 122, 旧 121/122 抖动消除）/ 4293 tests (+7) / 0 fail / 治理 90/90 不变（无新 INV — 测试层守卫已覆盖, 两修复均零业务语义）/ 安全 95/100 / **VERSION 0.37.9.70 不变**（守卫修复 + 配置退役, 同 V37.9.134 惯例）。⑤ **Mac Mini 待用户**: git fetch+reset 同步（restart.sh 在 FILE_MAP 自动同步到 $HOME；下次手动 `bash ~/restart.sh` 不再扫描/补丁 dist, 输出少一段 hotfix 日志属预期）。⑥ **元价值**: 两修复都是日落法纪律的小步兑现 — #27 消除"执行条件泄漏进清单计数"的接缝（一物一形: suite 清单数单一确定值），#25 退役上游已修复的防御层（防御本身是事故面: sudo sed 改 node_modules 是本脚本风险最高操作）。同时验证 V37.9.138 升级决策的"配套清理"承诺在 24h 内兑现, 不留长尾。 |
| V37.9.139 | 2026-06-11 | **ArXiv 论文第一稿交付 — *When Errors Become Narratives: A Longitudinal Taxonomy of Silent Failures in a Production LLM Agent Runtime*（Stage 2→3 话语权输出 unfinished #5 全力启动兑现）** — ① **触发**: V37.9.136-138 三任务清场 + PyPI 发布 + Gateway 升级完成后，本周焦点指定"全部日期门控障碍已清, ArXiv 论文下次 session 全力启动"。投稿时机条件（"ontology-engine pip 包就位后投稿, 有可分发 artifact 配套"）已由 V37.9.137 满足。② **交付三件套** `docs/paper/silent_failures_taxonomy/`: (a) **draft.md ~490 行完整英文第一稿** — Abstract / Intro 5 贡献 / Related Work（gray failure 谱系 + LLM agent failure 研究 + hallucination 系统视角）/ Methodology（postmortem 协议 = 异常分析宪法英文化 + 机制导向分类法构建）/ 5 类 taxonomy（A 环境 quirk / B 假设错配 / C 吞噬稀释 / D 链式幻觉 / E 运维取证, 每类代表案例叙事）/ 6 个 cross-cutting findings（潜伏期∝观察距离 + 发现渠道 ~70% 用户视角 + trigger-amplifier-concealer + MR-4 ≥28 次演出 = bug 类非 bug + 三步跃迁 point fix→meta-rule→scanner + audit 0% 预防 87% 回归）/ Defense Framework 5 支柱（含 sabotage validation "test the test"）/ Discussion（接缝论点"复杂关乎部件, 意外关乎接缝" + 日落法 + AI 协作下的可靠性工程一节）/ Threats to Validity（诚实: 无独立标注者 / 右截尾潜伏期 / AI 共写披露）/ Conclusion / Artifact（PyPI 包 + 22 case docs 公开）。(b) **data_inventory.md** — 论文每个数字→仓库溯源表（MR-8 精神 + 投稿前对表清单）。(c) **DECISIONS_NEEDED.md** — 7 项用户决策（标题三选一 / 署名与 AI 贡献披露 (a)+(b) 建议 / venue 推荐 arXiv 直发 cs.SE / 匿名度 / LaTeX 时机 / §7 取舍 / 5 张 figures 计划）。③ **概念贡献 "fail-plausible"**: Class D 定位为 gray failure differential observability 的 LLM 时代升级 — 系统不仅不报告失败, 还把错误加工成流畅可信的叙事推送给人（"观察者不只失明, 而是被失败本身说服"）。差异化定位: MAST（横向 benchmark traces）/ provider incidents（横向 156 incidents）vs 本文单系统纵向 8 周 22 完整 postmortem + 防御演进 + 潜伏期/发现渠道数据 — 互补关系显式论证。④ **文献全部真实验证**（原则 #23 适用于论文写作, 绝不编造引用）: Gray Failure HotOS'17 + Fail-Slow FAST'18 + MAST arXiv:2503.13657 全验证; 4 篇 2025-26 agent 可靠性论文（2511.07424 inference incidents / 2508.07935 SHIELDA / 2602.11749 AIR / 2603.05637 MCP faults）作者 snippet 级核实（dev WebFetch arxiv 403, abs 页终核留投稿前）; 顺带发现 2 篇高相关（2508.14231 Incident Analysis for AI Agents 待并入 §2.2 + 2606.05339 MCP runtime faults 已入）。⑤ **数字自查修正 2 处**: 反幻觉守卫 five→**six**-level（V37.9.89 LEVEL_6 后是 6 档）+ import 缺漏重演 catalog "8 天"是笔误（8 = jobs 数）→ 实证 **2 天**（V37.9.50-hotfix 5/10 → V37.9.58-hotfix 5/12), 已在 data_inventory 登记防回灌。⑥ **验证**: 121 suites / 4286 tests / 0 fail + 治理 90/90 + 安全 95/100 + 安全扫描零泄漏（论文不含 key/手机号/内网 IP）。**VERSION 0.37.9.70 不变**（纯文档交付, V37.9.99-docs 同款惯例）。⑦ **下一步**: 用户决策 DECISIONS_NEEDED 7 项（核心: venue — Claude 推荐 arXiv 直发, 实名 + artifact 链接齐全, 后续视反响投会议版）→ 决策后 Claude 自主推进第二轮（TBV 终核 + 3 类补充引用 + 正文打磨）→ LaTeX + figures 在 venue 定后（~半天, Fig.3 D1 幻觉链 causal chain 是传播力最强一张）。⑧ **元价值**: Stage 2（6 篇立场文章 + 治理证据链）→ Stage 3（可公开 cite 的方法论原作者）的第一个实质交付物。论文本身践行项目纪律: 每个数字可溯源（data_inventory = 论文的 convergence spec）+ 引用全验证（反幻觉）+ 诚实 threats 段（MR-7 自观察精神 — 论文披露自己的方法论弱点）。 |
| V37.9.138 | 2026-06-11 | **🎉 OpenClaw Gateway 升级 2026.3.13-1 → v2026.4.27 完成（三个月 hold 终结，提前 9 天于原 6/20 计划，用户 SSH 执行 + Claude 在线实时协助）** — ① **决策**: V37.9.136 前置验证当日 GO 后用户问"能否现在升级"——评估: 等待的技术理由已不存在（6/15 检查点完成 + G3/G4 对 4.27 路径 N/A）+ 原第七节 SOP 前置条件即"工作日白天快速回滚"（6/20 周六是后加保守层, 周末补救价值在 30 秒回滚面前有限）+ 当日升级有 Claude 在线协助优势 → GO。② **执行（12:27-12:50 HKT 23 分钟）**: 备份 → npm install -g openclaw@**2026.4.27**（显式版本, 不用 upgrade_openclaw.sh 的 @latest——发现该脚本会拉 2026.6.x 隐患）→ doctor --fix（legacy config 迁移 web.search→brave plugin + discord.streaming→mode / **12 bundled plugin deps 自动安装 baileys 7.0.0-rc.9 等** / sessions canonicalize + 10 orphan transcripts 可逆归档 / plugin registry 71/116 indexed **0 errors**）→ restart.sh（V37.9.13 kickstart + V37.8.13 健康验证全过）。③ **验证全绿**: channels status WhatsApp **linked+connected（15.2 验证项 1 通过: manifest-first 自动加载, auth 完整保留无需扫码）**+ Discord connected / 双通道推送 ✓（WhatsApp 首次 send timeout 10s = plugin 按需 staging baileys+jimp 窗口, 4.27 新机制, 10s 后重试即通——非 bug）/ **真人 E2E: PA 回复完整可见, #59265 未复现, 最大残留风险解除** / preflight **85/0 失败** + **SLO 全部达标**（p95 67s 警告随窗口冲刷自愈, V37.9.126/131 预测兑现）。回滚未触发。④ **配套更新**: check_upgrade.sh CURRENT→2026.4.27 / **upgrade_openclaw.sh @latest 隐患修复**（强制显式版本参数, `${1:?用法}`）/ SOUL.md + status.json operating_rules Gateway 行 / config.md 头部行重写 + 35.3 历史升级表加行 / eval doc 15.4 升级实录（完整时间线表）。⑤ **操作教训**: (a) zsh 不吃 # 注释行（粘贴命令需去注释, V37.9.56-hotfix2 同源 quirk）(b) `doctor \| tail` 管道吞交互提示看似挂起——doctor 必须裸跑 (c) 升级脚本禁止隐式 @latest。⑥ **观察项（非阻塞, 登记）**: Discord groupPolicy allowlist 新警告（不收群组入站无影响）/ #48703 hotfix 在 4.27 已冗余（上游 3.23 修复, sed 幂等无害, 移除留 follow-up）/ openclaw_config_to_runtime convergence spec 下次 --full 如报 version drift 属预期（doctor 重写 openclaw.json）。⑦ **元价值**: 三个月 hold（五次评估 + tripwire 框架 + 前置验证）的纪律没有变成僵化——前置条件满足当天即执行, "保守"与"敏捷"由数据切换而非日历。血案 #93（WhatsApp 自杀悖论）+ #98（上游修复≠本地修复）双教训全程遵守: 用户 SSH 执行禁 AI、显式版本锁定。VERSION 0.37.9.70 不变（Gateway 升级是系统环境变化, bridge 代码零改动）。 |
| V37.9.137 | 2026-06-11 | **🎉 openclaw-ontology-engine 0.1.0 正式发布到 PyPI — 项目终极目标 `pip install ontology-engine` 达成（V3 路标"别人会扩展"终极交付物公开可装）** — ① **发布路径**: 用户创建 account-scoped API token → dev 容器 twine upload 被网络 allowlist 拦截（`Host not in allowlist`, upload.pypi.org 不在出站白名单 — 非 token/包问题, verbose 实证）→ 用户 Mac Mini 按 packaging.md §7.2 runbook 4 条命令执行: build（macOS 侧重新构建 sdist 334KB + wheel 321KB）+ twine check 双 PASSED + upload 成功 → `https://pypi.org/project/openclaw-ontology-engine/0.1.0/`。② **发布后三层冒烟（dev 容器从真 PyPI 验证）**: (a) JSON API 200 — name/version 0.1.0/MIT/summary/2 files/requires_python>=3.9 全正确 (b) 干净 venv `pip install openclaw-ontology-engine` 真实安装 → `import ontology_engine` + engine/governance_checker/convergence 全子模块 + bundled 16 tools + openclaw-ontology-audit/query 双 console scripts 注册 (c) **WeatherBot config-injection 端到端**: ONTOLOGY_CONFIG_DIR + ONTOLOGY_PROJECT_ROOT 注入消费方 YAML, 经 PyPI 安装的 `openclaw-ontology-audit` 真跑 WeatherBot 治理审计 **exit=0 + convergence spec 零 drift** — `pip install` → 两个 env → 审计自己的项目, 终极闭环这次是**公开 PyPI 包**而非本地 wheel。③ **安全收尾**: 发布用 account-scoped token 已要求用户立即撤销（token 经对话传输, 用完即弃）; 未来发版建 project-scoped token。④ **登记低优 follow-up**: setuptools 警告 `project.license` TOML table 形式 2027-02 deprecated（届时改 SPDX 字符串）。⑤ **文档**: packaging.md §7.2 标记已发布 + 三层冒烟记录 + 未来发版流程; unfinished #14/#27 销项（chunk 4 记录 + publish-ready 记录均闭环）。⑥ **元价值（V3 路标终极里程碑）**: V37.9.99-pkg (6/2) chunk 1 config-injection keystone → V37.9.133 (6/11 晨) publish-ready → **V37.9.137 (6/11 晚) 公开发布**, 9 天从包化起步到 PyPI 上线。导师 V3 路标"别人会扩展"的终极交付物从承诺变为公开事实: 任何 Agent Runtime 项目现在 `pip install openclaw-ontology-engine` + 自己的 YAML 即获工具治理+语义查询+governance 审计+convergence 框架。Stage 2 话语权资产新增一个公开锚点（PyPI 页面 = PACKAGE_README 英文门面）。VERSION 0.37.9.70 不变（发布动作零代码改动; 包版本 0.1.0 独立轨道）。 |
| V37.9.136 | 2026-06-11 | **三任务清场（为 ArXiv 论文 session 扫清全部障碍，用户指示"全部逐个执行"）— ① OpenClaw 6/15 前置验证提前完成 ② assertion:→code: 数据层迁移 ③ PyPI 上传准备到只欠 token** — **① OpenClaw 前置验证（eval doc 新增第十五节，LAST_EVAL_DATE → 6/11）**: 结论 **GO（v2026.4.27, 6/20 周六 10:00-12:00 HKT 窗口维持）**。实证数据: tripwire 0/6 / #59265 GitHub API 再确认仍 closed 无 PR 无 fix（G2 → 目标维持 4.27 + 升级后强制 WhatsApp E2E）/ npm registry 确认 4.27 未 deprecated 43 天稳定 + 邻近版本全健康 / WebFetch 4.27 release notes **确认含 #73358 fix** 字面量 / 6.x 仍动荡（SQLite migration 在 6.6-beta 反复 deferred，6 月仅 2 stable vs 5 月 15）→ 避开正确 / G3 (tools.exec 4.29) + G4 (plugin manifest 5.2) 对 4.27 路径 N/A / rotateBytes deprecated 经 grep 确认配置未使用。**notes 复核新发现 2 个升级日验证项**（登记 15.2 节）: (a) 4.27 plugin manifest-first 重构（activation.onStartup 显式声明 + implicit sidecar loading deprecated）→ WhatsApp plugin（4/10 自动装 sidecar 形态）升级后必须验证仍自动加载，不行则加 activation.onStartup 声明，仍不行立即回滚 (b) Discord 回复默认 private 变更 — 我们显式 message send 不受影响，升级后观察首次推送确认。**② INV-GOV-FIELD-001 数据层迁移（unfinished #10 一周观察期后兑现，日落法一物一形）**: 55 个 `assertion: \|` 字段全迁 `code: \|`（V37.9.100 时 67 个，后续版本部分已退役）。**byte-identical 验证**: governance --json 迁移前后除 audit-of-audit timing（非确定性）外完全一致 = 语义零变化。前置安全检查: 55/55 全是字段名位置（前 3 行内有 check_type/name）+ 零测试依赖 assertion 字段提取（grep get(\"assertion\") 仅 governance_checker._check_code 一处）。执行器 `_check_code` 双字段兼容**保留**（belt-and-suspenders: 未来误写 assertion: 也不 vacuous），数据层新增**防回退守卫** check（拼接构造 pattern 防自匹配）— 执行器宽容 + 数据层严格 = 一物一形且零 silent-fail 风险。**反向验证**: sabotage 新增 assertion: 字段 → 守卫精确抓 L8880 + exit 1，还原 exit 0。INV-GOV-FIELD-001 4→5 checks，826→827 total。**③ PyPI 上传准备（runbook 写入 packaging.md §7.2）**: `python3 -m build` 重新构建（sdist 326KB + wheel 313KB）+ **twine check 双 PASSED** + **分发名 openclaw-ontology-engine 实证可用**（pypi JSON API 404；对照 ontology-engine 200 已被占）。**真障碍发现并解决**: 系统 packaging < 24.2 时 twine check 误报 `unrecognized field 'license-file'`（Metadata-Version 2.4 License-File 需 packaging ≥ 24.2 解析，dev debian packaging 24.0 复现假阳性）→ runbook 强制 venv twine。上传命令完整写入 runbook，用户拿 token 后任意机器 ~30 秒可传（可选 TestPyPI 演练）。**④ 验证**: 121 suites / 4286 tests / 0 fail / governance 90 inv / 827 checks / 安全 95/100 / VERSION 0.37.9.70 不变（前置验证 + 治理迁移 + 发布准备，零业务语义）。**⑤ Mac Mini 待用户**: git fetch+reset 同步。6/20 升级窗口按第七节 SOP（用户 SSH 执行，禁 AI）+ 15.2 节 2 个新验证项。**⑥ 元价值**: 一个 session 内三类障碍全清 — 日期门控（前置验证提前 4 天完成且数据比 6/15 当天做更新鲜不了多少，GO 结论锁定）+ 治理债（一周观察期满即兑现迁移）+ 发布阻塞（twine 环境陷阱提前踩平）。ArXiv 论文 session 现在可全力启动，无杂项分心。 |
| V37.9.135 | 2026-06-11 | **S2 关键词 6→12 恢复（unfinished #30 兑现）+ stale 待办销项** — ① **触发**: V37.9.134 收工后用户指示"下一个待办事项", 审视 unfinished 列表过滤出纯 dev 可自主执行项, 选 #30 (小工作量 + 真实产品价值 + 前提已满足: 2026-06-11 Mac Mini log 核实 S2_API_KEY 认证模式 6/8 起每天 11:00 稳定零 429, 5/28 匿名池 429 已根治). ② **恢复设计**: git 浅克隆 (历史仅到 6/3) 无法恢复 V37.8.13 前原始 12 关键词 → 用 **jobs/dblp/run_dblp.sh 同源 12 关键词集对齐** (S2/DBLP V30.5 同期上线 copy-paste 起源 + V37.1 同时加 ontology 方向, DBLP 未被砍保留完整集). 现有 6 个核心 AI 关键词保留 + 补回 6 个 ontology/KR 方向 (neuro-symbolic reasoning / enterprise ontology / formal ontology information systems / description logic OWL / semantic web linked data / knowledge representation reasoning) — V37.1 "DBLP/S2 加 ontology 关键词"设计意图完整恢复. ③ **预算核算**: 认证模式 12 关键词 × 2s = ~24s (S2 邮件限额 1 RPS 阈值以下); 无 key FAIL-OPEN 30s × 12 = 6min (V37.8.13 前老版本同款). ④ **5 新守卫单测** test_v37_9_98_s2_api_key 12→17 (TestV379135KeywordRestore): 12 关键词恢复 / 原 6 个不得丢失向后兼容 / 6 个 ontology/KR 必须恢复 / **与 DBLP 同源集逐字对齐守卫 (MR-8 精神, 防两侧再漂移)** / V37.9.135 marker. **反向验证**: sabotage 删 1 关键词 → 3 守卫同时 fail, 备份副本还原全过 (V37.9.134 操作教训兑现: 不用 git checkout). ⑤ **顺手销 stale 待办 [18]**: "auto_deploy 双行复发根因调查"已被 V37.9.116 (根因: governance real-apply + entry 格式错配) → V37.9.120 (根治: 退役 HOME 副本) → 6/11 Mac Mini 清理 (INV-CRON-004 转绿) 三阶段完整闭环, 确凿 stale. unfinished 31→29 (含 #30 销项). ⑥ **验证**: 121 suites / 4281→4286 tests (+5) / 0 fail / governance 90 inv 不变 / 826 checks 不变 (source 配置改动无新 INV) / 安全 95/100 / VERSION 0.37.9.70 不变 (source 配置扩展, 同 V37.9.108-112 惯例). ⑦ **Mac Mini 待用户**: git fetch+reset 同步 (run_semantic_scholar.sh 在 FILE_MAP, auto_deploy 2min 轮询同步到 ~/.openclaw/jobs/). **生效路径**: 明日 11:00 S2 cron 首次以 12 关键词跑认证模式 — 观察 log 应显示 12 次查询零 429 + 推送论文覆盖面扩大 (ontology/KR 方向论文回归). 若意外再 429 → FAIL-OPEN 已兜底 (单关键词失败不阻塞 + FETCH_ERRORS 全失败才告警). ⑧ **元价值**: V37.8.13 (429 防御性砍半) → V37.9.98 (API key 集成) → V37.9.99 (间隔调优) → **V37.9.135 (覆盖恢复)** 四阶段闭环 — "防御性降级"在根因解除后主动恢复, 而不是永久接受降级 (日落法反向应用: 退役不再需要的防御性限制). |
| V37.9.134 | 2026-06-11 | **cross_os_quirk_scanner 第 6 pattern — subshell errtrace 机器化检测（V37.9.131 候选元规则兑现，用户选）** — ① **触发**: V37.9.131 登记候选元规则 subshell-inherits-errtrace-under-bash32（V37.9.105-hotfix governance_audit ×2 + V37.9.131 watchdog SLO = 2 实例 3 处达门槛，"留 V37.9.132+ 评估 scanner 化"）。用户开工选 scanner 第 6 pattern（vs OpenClaw 6/15 前置验证 / PyPI 上传 / ArXiv 论文）。② **quirk 语义精确化（两轮口径校准防误报 churn）**: 初版宽口径（errtrace+trap ERR 文件中所有 `$(python...)`）扫出 40 行 → 加 `\|\|` 豁免仍 28 行 — 但这 28 行全是"JSON 二次 parse"类（失败概率极低 + 失败时 trap fire 是**真告警**非误报）。真毒模式 = **被调命令把非零 exit 当正常 API**（governance_checker exit 1 = 发现违规 / slo_checker --alert exit 2 = SLO 违规），周期性非零 → 周期性假 FATAL。且 `\|\|` 捕获**防不了**子 shell 内 trap fire（V37.9.105 铁证: GOV_RC 已正确捕获仍推假 "FATAL abort line=64"），唯一豁免 = `set +E` 包裹。③ **检测设计**: 文件级前提（同时含 `set -E`/-eE* errtrace + `trap ... ERR`，缺任一 quirk 不成立）+ 行级 `VAR=$(...python...)` 命中 **basename 清单**（governance_checker.py / slo_checker）OR **审计类 flag 启发**（--alert/--check/--validate/--full — flag 启发必要因 V37.9.131 watchdog 行内是 `"$SLO_SCRIPT"` 变量看不到文件名）+ **set +E 状态机**（`set +E` 进豁免区 / `set -E*` 出豁免区）。新口径 repo scan **0 violations**（3 个历史点 governance_checker --full / engine --check / slo_checker --alert 全在 set +E 区间被正确豁免）且 3 点 pattern 全命中 = 未来任何人删 set +E 包裹 scanner 立即抓。④ **候选元规则 sunset 决策（日落法 MR-22）**: **不立独立 MR** — scanner pattern + INV-CROSS-OS-001 扩展已把它机器化，立 MR 是治理层增殖（复用 MR-7 治理自观察），决策登记在 INV declaration。⑤ **13 新单测** test_cross_os_quirk_scanner 27→40（TestQuirkSubshellErrtrace 12: basename 清单命中 / flag 启发含 `"$SLO_SCRIPT"` 变量形态 / **`\|\| RC=$?` 不豁免血案核心守卫** / set +E 三件套豁免 / 无 errtrace 前提不成立 / 无 trap ERR 前提不成立 / json-parse 误报口径守卫 / 注释豁免 / set -E 重开检测状态机 / engine --check 第 3 实证点 / 真实 watchdog+governance_audit 双脚本 clean / **sabotage 删真实 set +E 必抓** + TestSourceLevelGuards +1 `\|\|` 不豁免文档化守卫），test_all_quirk_checkers_registered 扩 6 函数 + 血案引用扩 6 版本 + CLI 列表扩 6 quirk。⑥ **INV-CROSS-OS-001 扩展**（meta_rule=MR-7 不变，7→8 checks）: declaration 谱系 5→7 血案 + Quirk 6 完整语义说明 + sunset 决策登记 + 新 check `def detect_subshell_errtrace_designed_nonzero` + 血案元组 4→6（V37.9.105-hotfix + V37.9.131）+ RUNTIME check 名 "21 单测" 去硬编码计数（V37.9.121/131 教训: 硬编码 count = 递归接缝）。⑦ **反向验证两层守卫真有效**: sabotage 1 真删 job_watchdog.sh set +E 包裹 → scanner exit 1 精确定位 L735 `--alert` 行；sabotage 2 检测函数瘫痪 → 6 测试立即 fail。还原后 40/40 + 0 violations + governance 90/90 exit 0。**操作教训**: 未提交文件的 sabotage 还原必须用备份副本不能 `git checkout`（本次误还原 scanner 修改重新应用）。⑧ **验证**: 121 suites / 4268→4281 tests (+13) / 0 fail / governance 90 inv 不变（INV-CROSS-OS-001 内涵扩展非新增）/ 825→826 checks (+1) / 23 MR 不变（sunset 决策不立新 MR）/ 安全 95/100 / VERSION 0.37.9.70 不变（scanner/治理扩展零业务语义，同 V37.9.131 惯例）。⑨ **Mac Mini 待用户**: git fetch+reset 同步（scanner 是 dev/CI tool 不在 FILE_MAP，governance audit cron 从 repo dir 跑自动用新 pattern）。⑩ **元价值**: V37.9.105-hotfix（修 2 处）→ V37.9.131（修第 3 处 + 登记候选）→ **V37.9.134（scanner 化）** 三阶段闭环 — bash 3.2 subshell errtrace quirk 从"横向漏扫靠记忆"（原则 #31 两次演出）升级为机器化检测。第 6 个 quirk pattern 延续"每次血案转化为下次免疫力"路径，同时日落法纪律兑现: 机器化但不增殖治理层（0 新 MR / 0 新 INV / +1 check）。 |
| V37.9.133 | 2026-06-11 | **双交付（1+2 捆绑，用户选）— services flip 真激活 + chunk 5 PyPI 包化收尾（终极目标 publish-ready）** — ① **任务 2 services_to_launchd flip**（过期门控项 #6 闭环，原窗口 ~6/8）: `dry_run_default: true → false` 真激活 machine_sync — V37.9.97 (6/1) 起步 dry-run，6/1-6/11 十天观察期 3 服务全程健康零 would-bootstrap 异常 → 切关（镜像 V37.9.58 jobs/kb）。**convergence 5 specs 中 3 个 machine_sync 现全激活**（jobs_to_crontab / kb_sources_to_index / services_to_launchd），meta version `0.9 → 1.0-all-machine-sync-activated`。**关键语义澄清**: V37.9.116 后 07:00 governance audit cron 带 `CONVERGENCE_DRY_RUN=1`（env 显式优先于 spec default），故真 launchctl bootstrap 仅在 operator **手动跑** governance（无 env）时发生 — 与 jobs/kb 语义一致：machine_sync 自愈是显式刻意动作非审计副作用。**e2e 测试按 V37.9.113 隔离纪律重写**（显式 CONVERGENCE_DRY_RUN=1 验证 dry-run 路径 + finally 补 env 泄漏清理；real-apply 语义由纯函数测试覆盖零 launchctl 副作用 — governance runtime 会在 Mac Mini subprocess 跑 test_convergence，real-apply e2e 会真改生产状态）。连带修 3 处 meta version 守卫只认 `0.x` 不认 `1.0`（2 个测试 regex 升级 semver-tuple 比较 + 2 个 governance file_contains pattern 升级 `(?:0\.[2-9]|[1-9]\.[0-9])`）。② **任务 1 chunk 5 PyPI 包化收尾**（roadmap 主线，chunk 1/2-lite/3a/3b/3b.2/4/5 全部完成）: (a) **`python3 -m build` 首次真实构建成功** — sdist 325KB + wheel 312KB，wheel 内容验证（ontology_engine/ 包名映射 + 5 YAML + CONSTITUTION.md 随包 + LICENSE 进 dist-info/licenses/ + METADATA markdown README）(b) **真消费方场景三层冒烟**: /tmp venv 从 wheel 隔离安装 → import ontology_engine + engine/governance_checker/convergence 全子模块 + bundled 默认 16 tools ✓；WeatherBot config-injection（ONTOLOGY_CONFIG_DIR + ONTOLOGY_PROJECT_ROOT 注入消费方 YAML）2 tools 零 bridge 泄漏 ✓；venv `bin/openclaw-ontology-audit` 真跑 WeatherBot 治理审计 exit=0（含 convergence spec 零 drift）✓ — **`pip install` → 两个 env → 审计自己的项目，终极目标技术闭环** (c) **发布就绪三件套**: pyproject 补 `license = {file = "LICENSE"}`（MIT，LICENSE 文件已在仓库 — packaging.md "未声明 license" 已过时）+ `readme = "PACKAGE_README.md"`（**新建英文包级 README** — 两层架构表 + quick start + 5 capabilities + WeatherBot 链接，PyPI 门面 = Stage 2 话语权资产延伸）+ classifiers (Alpha/Python 3) (d) `.gitignore` 加 dist/ + *.egg-info/（build 产物不入库）(e) packaging.md §6.1 chunk 5 标 ✅ + §7 开放决策 3/4 更新（license/readme 已定，剩余唯一开放决策 = 实际 PyPI 上传：用户提供账号 token 后 `twine upload dist/*` + 上传时确认分发名 openclaw-ontology-engine 可用性）。③ **12 新守卫测试**: TestChunk5PublishReady(6 — license 字段+文件 MIT / readme 字段+文件 / PACKAGE_README 7 关键 token / classifiers / .gitignore 产物排除 / publish-ready 决策登记) + services flip 连带更新 4 处（assertFalse dry_run_default / yaml 字面量 false / e2e 隔离重写 / 纯函数改名 real_apply）+ 2 处 meta version regex 升级。**反向验证**: sabotage pyproject 删 license 字段 → 守卫立即 fail，还原全过。④ **验证**: 121 suites / 4262→**4268 tests**（+6）/ 0 fail / governance exit=0（INV-CONVERGENCE-SERVICES-001 守卫升级 + 2 pattern 升级）/ 90/90 inv / 安全 95/100 / VERSION 0.37.9.70 不变（services flip 是配置激活 + chunk 5 是包化收尾，零业务语义改动，同 chunk 1-4 惯例）。⑤ **Mac Mini 待用户**: git fetch+reset 同步（yaml + 测试走 FILE_MAP/symlink 自动生效；包化产物 dist/ 不入库不同步）。services flip 生效路径: operator 下次手动跑 `python3 ontology/governance_checker.py --full`（无 env）时若某 service 真宕 → launchctl bootstrap 真自愈；07:00 cron 行为不变（dry-run 观察）。⑥ **元价值**: 终极目标 `pip install ontology-engine` 从 V37.9.99-pkg (6/2) chunk 1 起步到 V37.9.133 (6/11) publish-ready，9 天 7 个 chunk 全部完成 — Layer 1（项目无关引擎）+ Layer 2（消费方 YAML）二层架构经真实 build + 真实安装 + 真实消费方（WeatherBot）注入验证。V3 路标"别人会扩展"的终极交付物只差一次 `twine upload`（用户账号决策）。同时 convergence framework 三个 machine_sync spec 全激活 = Plan B 渐进路径（alert_only → dry-run → 真激活）在第三个 spec 上完整复现，framework 状态语义统一。 |
| V37.9.132 | 2026-06-11 | **deep_dive 76% 摘要级结构 gap 修复 — dblp/hf/S2 写 KB arxiv 直链优先（方案 A，用户视角发现 + 用户选）** — ① **触发**: 用户视角发现"最近每日深度都是摘要级，与设计假设（大部分对原文深入分析）不符"，Mac Mini 数据证实 **34/45 (76%) deep_dive 为摘要级**。② **根因（结构性，V37.9.16 上线即埋）**: `kb_deep_dive.fetch_pdf_text` 只能从 arxiv/aclanthology/.pdf URL 派生 PDF，但 TIER_1 六源中**只有 2 个真能走全文**: arxiv_monitor/acl_anthology ✓；**dblp**（line 552 doi 优先压过 ee 字段里的 arxiv 链接）/ **hf_papers**（hf.co/papers 页面 URL）/ **semantic_scholar 无 arxiv 论文**（S2 页面 URL）/ pwc（已 disabled）全部无法派生 → 被 picker 选中必然降级。**最讽刺**: S2 早就提取了 arxiv_id（S2 推送链接已 arxiv 优先 — 用户看到的那篇是真无 arxiv 版本的期刊论文），dblp ee 字段就含 arxiv URL，hf paper_id 本身就是 arxiv id — **数据一直都在，只是链接构造没用它**。kb_deep_dive.py:57 注释"S2 常链 arxiv 走 PDF 路径"的假设从未对 dblp/hf 兑现。**MR-4 变种**: "优雅降级 + 摘要级标注"把结构性失败伪装成正常降级 — 每篇都诚实标注，看起来系统正常，但设计期待（多数全文）与现实（76% 摘要）的 gap 只有用户读内容才感知（原则 #13 第 N 次兑现）。③ **方案 A（写入层修链接，deep_dive 零改动）**: (1) **dblp** `link = doi.org if doi else url` → **arxiv (ee 含 arxiv.org) > doi > url** 三档 (2) **hf_papers** `hf.co/papers/{paper_id}` → **arxiv.org/abs/{paper_id}**（HF daily papers 按 arxiv id 索引）+ **格式守卫** `re.match(NNNN.NNNNN(vN)?)` 不匹配时保留 hf.co（防 HF 未来收录非 arxiv 论文；test_v37_9_45 的 hf.co 字面量守卫兼容保留）(3) **S2 增强** FIELDS +`openAccessPdf` + parse 段 None-安全提取 oa_pdf + emit 链接链 **arxiv > OA PDF（.pdf 结尾才用，保证 deep_dive endswith('.pdf') 可抓 + 用户点开即 PDF）> S2 页面** — 把"无 arxiv 但开放获取"的期刊论文（如血案那篇癌症 KG 类医学论文）也捞回全文路径 (4) kb_deep_dive.py TIER_1 注释更新为 V37.9.132 准确状态。④ **26 新单测** test_v37_9_132_arxiv_first_links.py（4 类）: **literal-as-guard 模式** — 测试中的逻辑块 literal 必须与脚本源码逐字一致（drift 时守卫先 fail），再 exec literal 验证行为（MR-8 单一真理源，规避 heredoc 内嵌逻辑难测问题）。TestDblpArxivFirstLink(6 含血案核心场景 arxiv+doi 并存 arxiv 胜 + 旧 doi-优先反模式消除守卫) + TestHfArxivFirstLink(7 含 versioned id / 非 arxiv 格式 fallback hf.co / 空 id / **emit heredoc import re 守卫** V37.9.58-hotfix 教训) + TestS2OaPdfChain(9 含 FIELDS 守卫 / None-安全 / 三档行为 / 非 .pdf OA 保留 S2 页面) + TestDeepDiveCompat(3 集成语义: 新链接满足 arxiv_url_to_pdf 派生 + endswith('.pdf') 分支对齐)。**反向验证**: sabotage dblp 退回 doi 优先 → 2 守卫立即 fail，还原全过。7 个相关现有套件零破坏（hf/s2 V37.9.39/45/50/51 + dblp V37.9.40 + deep_dive + heredoc_import）。⑤ **验证**: 121→**121 suites**（含新 suite v37_9_132）/ 4236→**4262 tests**（+26）/ 0 fail / governance 90/90 不变（无新 INV — source 输出格式改动，链接正确性由 literal-as-guard 测试守卫）/ 安全 95/100 / VERSION 0.37.9.70 不变（source 配置/输出格式改动，同 V37.9.108-112 惯例）。⑥ **Mac Mini 待用户**: git fetch+reset 同步（3 个 job 脚本走 auto_deploy FILE_MAP 同步到 ~/.openclaw/jobs/）。**生效路径**: 明日 10:00 hf / 11:00 s2 / 12:00 dblp cron 起新 KB 条目用 arxiv 优先链接 → 明晚 22:30 deep_dive 选中这些源时首次走全文 PDF 分析。历史 KB 条目不变。**诚实预期**: 修的是"有 arxiv/OA PDF 的论文"，纯付费墙期刊论文仍只能摘要级（数据现实非 bug）— 摘要级占比应从 76% 显著下降但不会到 0。**观察指标**（一周后）: `grep -L "基于摘要的分析" ~/.kb/deep_dives/*.md` 新增文件多数应为全文级。⑦ **元价值**: V37.9.16 设计假设（"S2 常链 arxiv"）从未被验证兑现，直到用户读推送内容才暴露 — 再次证明"优雅降级会掩盖结构性失败"，degrade 路径的**触发频率**本身必须可观测（deep_dive 的 mode 字段在 status 里有但从未被聚合复盘 — observer 已有 deep_dive 产出监控，摘要级占比纳入 observer 是候选增强）。 |
| V37.9.131 | 2026-06-10 | **watchdog SLO 子 shell ERR trap 误报修复 — V37.9.105-hotfix 同款 bash 3.2 quirk 第 3 处演出（横向漏扫 watchdog）** — ① **触发**: 2026-06-10 20:30 用户收到 `[SYSTEM_ALERT] watchdog FATAL abort exit=2 line=728`。数据驱动诊断（原则 #28，Mac Mini log + slo_checker rc + canary 三件取证）: **watchdog 主体未死** — FATAL 行之后完整告警汇总（52 项检查）照常推送 + canary last_completed 20:30:33 正常 = V37.9.105-hotfix governance_audit "两条告警同源一次 run" 同款铁证。② **因果链**: 第一次（旧代码）harvest 重跑的 ~10 个大 LLM 请求拉高 proxy_stats 滚动窗口 p95=62704ms > 50000ms 阈值 → slo_checker --alert **设计性 exit 2**（violation + 告警文本）→ line 728 `if SLO_ALERT=$(python3 ...)` 命令替换子 shell 在 **macOS bash 3.2 + set -E (errtrace) 下继承 ERR trap** → python 非零退出在子 shell 内误触发 fatal_handler 推送 FATAL → 主脚本 if 豁免正常走 else 分支继续。SLO 违规本身随窗口冲刷自愈（用户实测 rc=0 + preflight 达标）。③ **根因层级**: V37.9.66-hotfix 当时把 `cmd && X || Y` 改成 if-then-else 修的是**外层 condition** 的 trap 误触发；但 if 豁免救不了**子 shell 内部**继承的 trap — 这是另一个独立 quirk（V37.9.105-hotfix 在 governance_audit 实证过同款并修了 2 处，**当时横向漏扫 watchdog** = 原则 #31 跨消费者同步 gap 又一次演出）。dev bash 5.x 不能复现此 quirk（行为已变），只能靠 Mac Mini 实证 + lineage 推理。④ **修复**: line 728 改 governance_audit line 79-81 同款模式 — `SLO_RC=0` + `set +E` + `SLO_ALERT=$(python3 ...) \|\| SLO_RC=$?` + `set -E`（set +E 关 errtrace 子 shell 不继承；\|\| 捕获让 set -e 安全）。横向扫 7 个 governed scripts: 仅 watchdog line 728 一处漏网（其余 inline python 有 except 兜底 / `\|\| echo` 兜底 / heredoc 模式）。⑤ **6 新单测** TestV379131SloSubshellErrtrace (test_watchdog_self_monitoring 31→37): set +E 包裹守卫 / \|\| 捕获守卫 / SLO_RC=0 初始化顺序锁 / **旧 if 形式退役守卫**（防回退）/ marker+lineage / **行为级 subprocess 真跑** fake slo_checker exit 2 → rc=2 捕获 + 告警收集 + 主脚本继续 + trap 不触发。**反向验证**: sabotage 移除 set +E → 守卫立即 fail，还原全过。连带 alternation 2 处: test_cron_monitor_scanner V37.9.66 守卫升级接受 if 形式 OR set +E 形式 + test_v37_9_69 硬编码 "Ran 31 test" 改 baseline ≥31（V37.9.121 同款教训: 硬编码 count = 递归接缝）。cross_os_quirk_scanner 复扫 0 violations（新写法单 \|\| 非 && \|\| 链不触发）。⑥ **验证**: 120 suites / 4230→4236 tests (+6) / 0 fail / governance 90/90 不变（INV-WATCHDOG-SELF-001 runtime 跑全套自动覆盖新守卫）/ 安全 95/100 / VERSION 0.37.9.70 不变（watchdog 内部 quirk 修复零业务语义，同 V37.9.72 惯例）。⑦ **候选元规则登记**: subshell-inherits-errtrace-under-bash32 — `$(...)` 调用"设计性非零退出"命令时必须 set +E 包裹或 \|\| 兜底，cross_os_quirk_scanner 第 6 种 pattern 候选（V37.9.105-hotfix + V37.9.131 两实例已达门槛，留 V37.9.132+ 评估 scanner 化）。⑧ **同日 20:30 告警汇总其余 12 条定性**: 对话精华 error（重跑后已 ok 自愈）/ Dream llm_failed（V37.9.129 已修待 adapter 重启生效）/ 治理审计 fail（待 Mac Mini 重跑确认，可能 stale 代码）/ SLO p95（已自愈 rc=0）/ dblp 500 + ai_leaders 429 + acl/chaspark 502 等外部 API 波动（已知噪声类）。 |
| V37.9.130 | 2026-06-10 | **kb_harvest Reduce 超时血案修复 — 层级分批 Reduce + fail-soft 机械去重 + --days 3 自动补提炼（follow-up #22 闭环，用户选）** — ① **触发**: unfinished #22 登记的真实生产 bug — 6/3、6/4 连续两天大对话日（163 轮 / 37.7 万字 / 9 chunks）Map 全成功但 Reduce 合并 9 段 LLM 超时失败，对话精华断流。② **三问（原则 #28）**: Q1 之前存在 ✓ — V37.1 (4/9) MapReduce 上线起的设计容量假设（Reduce 单次合并所有 Map 段 + timeout 120s），大对话日才触发 / Q2 非新回归 — Qwen3 大请求 p95 60s+（V37.9.129 数据），9 段拼接 ~40K chars 输入 + 2000 max_tokens 输出在退化期撞 120s / Q3 最小修复 = 4 件套（超时 + 分批 + fail-soft + 自动重试），同时发现 **2 个隐藏 MR-4 silent failure 一并修**: (a) Map 全失败被当"无关键内容"→ mark_processed → 数据永久丢失伪装成功 (b) 失败日期默认 `--days 1` 永不自动重试（明天的 cron 只处理"明天的昨天"）。③ **修复 4+2 件套** (kb_harvest_chat.py): (1) `REDUCE_TIMEOUT=300`（120→300s，镜像 V37.9.129 doubao fallback 同值同理由：大请求给足时间不降 max_tokens 不牺牲质量）(2) **`_reduce_hierarchical` 层级分批 Reduce**: 每批 ≤`REDUCE_BATCH_SIZE=4` 段，多轮归并 9→3→1（共 3 次 ~18K 小请求替代原 1 次 ~40K 大请求）；尾批单段 passthrough 不调 LLM (3) **`_mechanical_dedup` fail-soft**: 单批 LLM 失败（含 retry）→ 该批机械行级去重（剥 `===` 段头 + exact-line dedup 保序 + 全段头极端兜底返回原拼接绝不空），不阻塞其他批；**轮级熔断** — 整轮 LLM 批全失败 = 系统性故障，机械合并剩余段直接返回不再下一轮（防 cron 拖长无意义重试）；degraded 时 KB 内容标 `[REDUCE_DEGRADED 机械去重未经LLM合并]`（诚实可观测，下游 dream/evening 消费时知情）— 零数据丢失契约（MR-4: 宁可重复不可丢失）(4) `_llm_call_with_retry`（`LLM_RETRY=1`，Map/Reduce/单 chunk 全路径，镜像 V37.9.74/75 dream retry）(5) **Map 全失败语义修复**: `map_failed>0 且无结果 → 返回 None`（error 不 mark_processed）而非"无关键内容"（旧 bug 伪装成功永久丢数据）；Map 段失败 retry 后仍失败 → stderr WARN "segment lost" 可观测（原版静默丢段）(6) **`--days` 默认 1→3**: 失败日下次 cron 自动补提炼（is_processed 幂等跳过已完成日期，成功日零额外 LLM 调用；cron 不传参用 default，零 crontab 改动）。④ **接口演进**: `extract_key_points`/`process_date` 返回 `(result, meta)` tuple，meta={chunks/mode/map_failed/reduce_degraded}；last_run_harvest_chat.json 加 `degraded` + `map_failed` 独立新字段 — **status 枚举保持 ok|error|empty 不变**（V37.9.72 watchdog 契约教训：不引入 ok_degraded 之类新状态值，watchdog 只认 ok|unknown 为正常）。旧 `_reduce_key_points` 单次大请求函数退役（日落法 #34：替换而非堆叠），prompt 提为 `_build_reduce_prompt` 纯函数。⑤ **29 新单测** test_harvest_chat.py 28→57（6 新类）: TestMechanicalDedup(5 含跨段零丢失契约 + 全段头 fallback) + TestLlmCallWithRetry(3) + TestHierarchicalReduce(6 含 **9 段血案场景** 2 轮 3 次调用 / batch≤4 prompt 段数守卫 / 单批失败 fail-soft 其他批不受影响 / 全失败轮级熔断 4 次调用后零 r2 调用 + 9 段独特内容全存活 / 恰好 4 段单批) + TestExtractKeyPointsMetaV130(4 含 Map 全失败 ≠ 无关键内容 MR-4 修复 + 部分失败计数 + degraded 透传 + tuple 契约) + TestProcessDateDegradedV130(3 含 degraded KB 标记 + 仍 ok + error 不标记已处理 = --days 3 重试前提) + TestV379130SourceGuards(8 常量锁定 300/4/1 + marker + --days=3 + status 枚举契约防回归 + degraded/map_failed 字段 + timeout=REDUCE_TIMEOUT 防硬编码回退 + 旧单次 Reduce 已退役)。现有 9 个测试 alternation 更新到 tuple 签名。**反向验证三层守卫真有效**: sabotage Map 全失败退回旧行为 → 2 fail（行为级+源码级双层）；删轮级熔断 → 1 fail；--days 回退 1 → 1 fail。还原后 57/57 全过。⑥ **HOME 隔离端到端真跑**（V37.9.110 测试污染生产教训，fake HOME 不碰真实 ~/.kb）: 300 turns 3 chunks 真跑 CLI — MapReduce mode 触发 ✓ / Map retry WARN 逐段可观测 ✓ / 全失败 status=error 不伪装 ✓ / .processed 不创建（重试前提）✓ / last_run schema {status:error, degraded:0, map_failed:3} ✓。⑦ **历史 debt 顺手补登**: test_harvest_chat.py **V37.1 起从未注册 full_regression**（同 V37.9.99 发现 slo_benchmark 未注册的 gap 家族），本次接入 suite "harvest_chat"。⑧ **governance**: INV-JOB-HARVEST-001 既有 3 checks 零破坏（MapReduce/kb_write 字面量 + AST 函数名守卫，新函数 `_reduce_hierarchical`/`_mechanical_dedup` 反而增强命中）。本次不立新 INV（修复 + 测试守卫已covers，镜像 V37.9.74/75 dream retry 同款不立 INV 惯例）。⑨ **验证**: 119→**120 suites**（+1 harvest_chat 历史 debt 补登）/ 4173→**4230 tests**（+57: 28 旧测试首次进回归 + 29 新增）/ 0 fail / governance 90/90 invariants 不变 / 安全 95/100 / **VERSION 0.37.9.69→0.37.9.70**（reliability 改动 + CLI 默认行为变更，同 V37.9.129 bump 惯例）。⑩ **Mac Mini 待用户**: git fetch+reset 同步（kb_harvest_chat.py 在 FILE_MAP，auto_deploy 2min 轮询同步到 $HOME）。下次 06:00 cron 自动用新逻辑：3 天窗口 + 层级 Reduce；**6/3、6/4 两个失败日已超 3 天窗口**，待用户手动补提炼: `python3 ~/kb_harvest_chat.py --date 20260603 && python3 ~/kb_harvest_chat.py --date 20260604`（原始数据还在 ~/.kb/conversations/，提炼后进 KB）。⑪ **元价值**: 对话数据是最高质量信号源（原则 #25），Reduce 断流 = 数据复利断流。本次把"大对话日必然超时"的容量假设升级为"输入规模无关的层级归并"，并给 LLM 全挂场景三层防御（retry → 机械兜底 → 跨日自动重试），对话精华提炼从"脆弱单点"升级为"零数据丢失管道"。 |
| V37.9.129 | 2026-06-10 | **gemini 香港 geo-block 退役 + doubao 超时调优 — Dream DEEP 失败 SYSTEM_ALERT 数据驱动诊断揭示 fallback 链无真正第二张网（用户指示退役 gemini + 加大超时不降 max_tokens）** — ① **触发**: 2026-06-10 03:00 cron `[SYSTEM_ALERT] Agent Dream 失败: V37.9.68 DEEP 段失败 (1 chars < 1200, retry 未触发因 LLM 完全空)`。系统按 V37.9.68/V37.9.75 设计正确 fail-LOUD（MR-4 silent-failure 反面），非 kb_dream 代码 bug。② **因果链锁定（原则 #26/#28，不盲改）**: DEEP llm_call（5000 token / 300s timeout，全 Dream 最大请求）内部 4 次重试全空 → DEEP_RESULT=""（`echo "" \| wc -c` = 1 chars 真相）→ V37.9.75 retry 跳过（`[ -n "${DEEP_RESULT// }" ]` = FALSE，完全空设计如此）→ fail-fast 告警跳 WIDE+RADAR。③ **Mac Mini 数据驱动诊断（反馈 #1，读不到 Mac Mini log 故给诊断命令）**: ① kb_dream.log DEEP 现场 4 次全 `primary: circuit open; doubao: read timed out; gemini: HTTP 400` ② /health circuit_breaker=half-open fallback=doubao ③ /stats p50=43s p95=61s。**三后端全挂三种性质**: Qwen3 521→circuit open（**transient** 恢复中，无需改）/ doubao read timeout（**半持续**: 60s fallback 超时被 5000-token DEEP 撞穿）/ gemini HTTP 400（**持续 bug**）。④ **gemini 400 铁证（直连看 body，adapter 吞了 body）**: `{"error":{"code":400,"message":"User location is not supported for the API use.","status":"FAILED_PRECONDITION"}}` = **Google Gemini API 香港永久 geo-block**，key 有效（39 位 AIzaSy）但地区封锁。gemini 从 doubao 加入前就是死链，平时 qwen+doubao 够用没人发现，**直到三个全挂才浮现 = fallback 链没有真正的第二张网**（V37.9.126 "Qwen3 退化 doubao 顶着"再深一层）。⑤ **退役 gemini（用户指示，config 版本控制化非删 plist key）**: INV-PLIST-ENV-001 + preflight 都要求 GEMINI_API_KEY 在 plist（删 key 破坏治理）→ 退役方式 = 保留 key + `config.yaml fallback.remote_gpu.exclude_providers: [gemini]` + `adapter._FALLBACK_EXCLUDE = set(_FALLBACK_CFG.get("exclude_providers"))` 在 `_build_fallback_chain` 两路径（explicit + auto）过滤。`available`（有 key）≠ `working`（地理可达），`require_available` 只查 key 不查可达性。⑥ **doubao 调优（用户指示：一定不降 max_token，最大化加大超时像 Qwen3）**: `fallback_timeout_ms: 60000 → 300000`（= primary timeout，给 doubao 大请求足够时间，**不降 DEEP max_tokens 5000** — 不牺牲输出质量，第 0 号宪法精神）。直接修 03:00 doubao 60s 超时（circuit-open 时 adapter 直接走 doubao，5x 更多时间）。`config.yaml fallback: gemini → doubao`（纯文档性，doubao 是真实第一 fallback）。⑦ **观察性修复 DEFER**: adapter 吞 upstream error body（这次诊断难的原因，MR-13/INV-OBSERVABILITY-001 候选）—— gemini 退役后其 400 body moot + doubao timeout 无 informative body + 会引入 adapter→proxy_filters 耦合（日落法 #34 防御本身是事故面），登记 follow-up 不今天做（原则 #28 最小修复）。⑧ **INV-FALLBACK-EXCLUDE-001 新增**（geo-blocked-provider-excluded-from-fallback-chain, meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime], **7 checks**）: 6 declaration（config.yaml exclude_providers gemini + fallback_timeout_ms 300000 / adapter _FALLBACK_EXCLUDE 定义 + auto 路径 cp.name 过滤 + explicit 路径过滤 / V37.9.129 marker）+ 1 runtime python_assert（subprocess 跑 3 个 V37.9.129 test_adapter 测试，mock 路径 env-independent）。**只有 governance INV 检查真实 config.yaml 才能抓 config 回归**（test_adapter 用 mock，删 exclude_providers → gemini 复活，单测抓不到）。⑨ **3 新单测 test_adapter.TestHotReloadFunctional**: auto-discover 路径排除 gemini → 链只剩 doubao / explicit FALLBACK_PROVIDER 也受约束 / **反向验证不排除时 gemini 仍在链（证明排除才是移除原因非别的）** + _exec_build 注入 _FALLBACK_EXCLUDE + mock registry。⑩ **验证**: 119 suites 不变 / 4170→4173 tests (+3) / 0 fail / governance v3.55→v3.56 / 89→90 invariants (+1) / 818→825 checks (+7) / 23 meta rules 不变（复用 MR-4）/ 安全 95/100 / **VERSION 0.37.9.68→0.37.9.69**（reliability/routing 改动，同 V37.9.74 RADAR retry bump）。⑪ **Mac Mini 待用户**: git fetch+reset 同步（config.yaml + adapter.py 在 FILE_MAP，auto_deploy 2min 轮询同步）+ **`bash ~/restart.sh` 重启 adapter** 让新 fallback 链（排除 gemini）+ 300s fallback 超时生效。重启后 `/health` 应显示 `version: 0.37.9.69` + `fallback_chain: [doubao]`（gemini 已排除）。下次 03:00 Dream 若 Qwen3 再 hiccup，doubao 有 300s 时间扛 DEEP 大请求不超时。⑫ **元价值**: SYSTEM_ALERT 数据驱动诊断（直连 gemini 看 body 铁证 geo-block）推翻"纯 transient"初判，揭示 fallback 链长期只有一个真 fallback（gemini 装饰、doubao 唯一）。退役死链 + 加大唯一真 fallback 超时 = "缩小接缝"非"加机器"（日落法 #34 对齐：fallback 链 CLAIMS 3 provider 实际 1.x 工作）。原则 #28 严格执行：直连看 body 定根因（geo-block 非请求 bug）才动手，没盲改。 |
| V37.9.128 | 2026-06-09 | **ontology-engine 包化 chunk-2-lite — import 名去泛化 ontology→ontology_engine 经 pyproject package-dir 映射 (零目录 rename / 零内部 churn / 零 Mac Mini symlink 变动, 用户在我 surface 全量 rename 真实代价后选低风险方案)** — ① **触发**: V37.9.127 chunk 3b.2 收工后用户选"chunk 2 (import 名 ontology→ontology_engine 去泛化, 破坏性 rename) 请立即执行". 开工先 survey 全量 rename 真实 scope: `ontology` 作为目录名 + import 名 + 概念词 (tool_ontology/domain_ontology/governance_ontology/ONTOLOGY_CONFIG_DIR/ontology-native 等) 散落 50+ 文件, 真改目录名 = 动 proxy_filters lazy-load 路径 + Mac Mini `~/ontology` symlink (V37.9.12.1) + governance_audit_cron + 全部 from-ontology-import + 文档. **surface 给用户全量 rename 高 blast radius (违反日落法 #34 防御本身是事故面 + #28 最小修复), 用户选低风险 pyproject 映射 (推荐)**. ② **chunk-2-lite 机制 (原则 #28/#34)**: 仅改 `pyproject.toml` — `[tool.setuptools]` 加 `package-dir = {ontology_engine = \"ontology\"}` (import 名 `ontology_engine` 映射磁盘 `ontology/` 目录, **零目录 rename**) + `packages = [\"ontology_engine\"]` + console_scripts 改 `ontology_engine.governance_checker:main` / `ontology_engine.engine:main` + package-data key `ontology_engine`. **关键依据 (为何 lite 可行)**: 内部 `from ontology import X` 已是双模式 flat fallback (`try: from ontology import X except ImportError: sys.path.insert + import X`), package-name-agnostic — 消费方 `pip install` 装成 `ontology_engine` 仍工作, bridge 内部 `import ontology` (本地目录) 行为完全不变. dev 双名共存 (本地 ontology + 经映射 ontology_engine), 消费方 (无本地 ontology/ 目录) 只见 ontology_engine = 去泛化达成. ③ **零 Mac Mini symlink 变动 (lite 核心优势)**: 全量 rename 必须改 `~/ontology` symlink + proxy lazy-load 路径, lite **完全不动** — proxy_filters/adapter/governance_audit_cron/Mac Mini symlink 全部行为字节级不变, Mac Mini 仅需 git fetch+reset (无需重建 symlink / 无需 pip install). ④ **真消费方场景验证 (/tmp 隔离)**: `pip install -e .` → `import ontology_engine` 解析到 ontology/__init__.py + 子模块 (engine/governance_checker/convergence) 可 import + 2 console scripts 注册到 bin + 从 /tmp 跑 `openclaw-ontology-audit` 确认 convergence flat fallback 工作 + 卸载干净. ⑤ **4 测试改 + 3 行为级 skip-if-not-installed** (test_ontology_packaging 23→27): test_packages_only_ontology→_ontology_engine (断言 `[\"ontology_engine\"]`) + test_package_dir_maps_engine_to_ontology_dir (新) + console scripts 断言改 `ontology_engine.X:main` + package-data key + **TestChunk2LiteImportName 3 测 (skip-if-not-installed: ontology_engine 映射到 ontology 目录 / 子模块可 import / 本地 ontology 仍工作)**. TestEntryPointsResolve 保留本地 `import ontology.engine` (dev proxy). ⑥ **文档同步**: extension_guide pip install 注释 `import ontology_engine` + API 表 `ontology.X`→`ontology_engine.X` + chunk-3b follow-up→done; packaging.md chunk 2 roadmap 标 chunk-2-lite done. ⑦ **验证**: 119 suites 不变 (test_ontology_packaging 已注册) / 4166→4170 tests (+4) / 0 fail / governance 89 inv 818 checks 不变 (无新 INV/MR) / 安全 95/100 / VERSION 0.37.9.68 不变 (包化 import 名映射零业务语义, 同 chunk 1/3a/3b/4). ⑧ **元价值 (日落法 #34 + 终极目标双兑现)**: 用户原指令"破坏性 rename"被我 surface 真实代价 (50+ 文件 + symlink + 概念词重载) 后降级为低风险 lite — **honors 用户去泛化意图 (消费方只见 ontology_engine) + honors 日落法 (零目录 rename 零接缝新增零 symlink 变动)**. pip install ontology-engine 终极目标的 import 名去泛化达成, 破坏性 rename (真改目录名) 留作 chunk-2-full 不做 (lite 已满足消费方去泛化需求, full 是纯 churn 高风险). 下次候选: chunk 5 (sdist/wheel build + pip install 冒烟) / ArXiv 论文 (Stage 2→3) / OpenClaw 6/20 升级窗口. |
| V37.9.127 | 2026-06-09 | **ontology-engine 包化 chunk 3b.2 — per-scanner glob 形状 + push-route 白名单 Layer 2 config-injection (chunk 3b 续完结, MRD 扫描器全部项目无关化)** — ① **触发**: V37.9.126 chunk 3b (单文件名) 收工后用户选"执行 chunk 3b.2 (glob 形状参数化)". 这是 V37.9.126 登记的 follow-up — 把 governance_checker.py 14 个 `_discover_*` MRD 扫描器的 **per-scanner glob 形状**从硬编码移到 Layer 2 config (chunk 3b 只做了单文件名 registry/notify/preflight). ② **范围**: 7 个 glob-set 键 (`topic_scan_globs` `**/*.sh` / `channel_source_globs` `[jobs/*/run_*.sh, *.sh]` / `repo_shell_globs` `[*.sh, jobs/**/*.sh]` / `alert_monitor_globs` `[wa_*.sh, *keepalive*.sh, *watchdog*.sh]` / `llm_caller_globs` / `llm_caller_py_globs` `[jobs/**/*.py]` / `py_scan_globs` `[**/*.py]`) + `push_route_whitelist` (23 条) 移到 `mrd_scan_patterns`. **各扫描器是不同扫描集** (`**/*.sh` 含 docs/ontology vs `[*.sh, jobs/**/*.sh]` 只 top+jobs) 不可合并 → 各自配置键. ③ **机制**: `_mrd_globs(key)` helper 返回 `_MRD[key]` join `_PROJECT_ROOT` 后的模式列表 (按列表保序), **统一 `recursive=True`** — Python glob 对非 `**` 模式 recursive 是 no-op 对 `**` 必需, 故安全统一. `_load_mrd_patterns()` 泛化 (遍历 `_MRD_DEFAULTS` 所有键: str 非空 override / list 非空 override, 防误配). `_PUSH_ROUTE_WHITELIST = set(_MRD["push_route_whitelist"])` 派生. 9 个扫描器 glob 构造重构 (保留各自 `set/extend/sorted` 累积语义 → 字节级一致). ④ **byte-identical 验证 (核心)**: 重构前后 governance --json 逐项比对 — **12 个 glob-依赖计数全不变** (MRD-LOG-STDERR 48 shell/11 豁免 / MRD-PUSH-ROUTE 3 rogue+41 non-whitelist / MRD-SILENT-EXCEPT 72 .py / MRD-LLM-PARSER 46 / MRD-NOTIFY-001 5 topics / MRD-ERROR-001 82 / MRD-ALERT 2 monitor / MRD-NOTIFY-002 6 channels), 唯 AUDIT-PERF timing + governance_checker 自身违规行号位移. 89/89 inv exit 0. ⑤ **16 新单测** (24→40): glob defaults + _mrd_globs helper + glob override + yaml drift guard + **行为级反向验证 (override py_scan_globs→单文件 扫 1 个 / override alert_monitor→不匹配 0 个 监控脚本, 证明 glob 真驱动扫描)** + 源码守卫 (扫描器用 _mrd_globs + 反向硬编码 glob 块消除守卫) + demo glob 端到端 (WeatherBot py_scan_globs `skills/**/*.py`). **反向验证守卫真有效**: sabotage 退回硬编码 glob → 守卫 fail; sabotage yaml glob 值改坏 → drift guard fail. 还原 40/40 全过. ⑥ **demo**: WeatherBot governance_ontology.yaml mrd_scan_patterns 加 `py_scan_globs: [weatherbot.py, skills/**/*.py]` + `push_route_whitelist`, 证明真消费方用自己的项目结构 glob (非 bridge jobs/**/*.py). ⑦ **验证**: 119 suites 不变 (test_mrd_config_injection 已注册) / 4150→4166 tests (+16) / 0 fail / governance 89 inv 818 checks 不变 (无新 INV/MR) / 安全 95/100 / VERSION 0.37.9.68 不变. Mac Mini 待 git fetch+reset (默认行为不变). ⑧ **元价值 (终极目标 MRD 扫描器全部项目无关化)**: chunk 3b (单文件名) + chunk 3b.2 (glob 形状 + 白名单) = **governance_checker.py 的 MRD 扫描器全部项目特定模式已 config-inject**. 任何消费方项目只需写自己的 `mrd_scan_patterns` (文件名 + 项目结构 glob) 即获 MRD silent-failure 扫描 (silent-except/log-stderr/push-route/llm-parser/alert-path 等血案防护), 无需理解扫描器内部. pip install ontology-engine 的"MRD 框架项目无关"粒度达成. 下次候选: chunk 2 (import 名去泛化破坏性 rename) / chunk 5 (sdist build) / ArXiv 论文. |
| V37.9.126 | 2026-06-09 | **ontology-engine 包化 chunk 3b — MRD 扫描单文件名 Layer 2 config-injection (终极目标推进, 用户选; SLO 退化诊断闭环为前置)** — ① **触发**: V37.9.125 收工后用户问"下一个遗留事项". 先**数据驱动诊断 Mac Mini preflight #19 SLO 退化** (p95=81s/timeout 14.7%): /stats total_req=71 + adapter /health `fallback=doubao` + `circuit_breaker=half-open` + 最近 backend 6-12s → **结论 Qwen3 主力 backend 退化, doubao fallback 顶着, 81s 是 200-滚动窗口含退化期 (LATENCY_WINDOW=200 但 71 req 全在窗口), 监控工作正常非 code bug** (slo_checker 门槛 5 vs slo_benchmark 200 是 alerting vs reporting 设计差异不该改 — 抬门槛会压真信号). 操作: 观察 Qwen3 恢复 / 可选 restart.sh 清窗口. 无 code 改 (原则 #28 理解了答案是观察). 用户转选 chunk 3b. ② **chunk 3b 范围 (原则 #28/#34)**: governance_checker.py 的 14 个 `_discover_*` MRD 扫描器硬编码项目特定文件名. 根已 `_PROJECT_ROOT` 注入 (chunk 3a), 但文件名本项目特定 → 消费方无法配置. **仅参数化高价值低风险的单文件引用** (`registry_file`/`notify_file`/`preflight_file` 跨 5 use-site + 诊断白名单); per-scanner glob 形状 (`**/*.sh` vs `[*.sh, jobs/**/*.sh]` 各异泛型改动风险高) + push-route 白名单 **登记 chunk 3b.2 follow-up** (低价值高回归风险). ③ **机制 (镜像 chunk 3a convergence config-injection)**: `_MRD_DEFAULTS` (确切 bridge 值) + `_load_mrd_patterns()` 读 `governance_ontology.yaml::mrd_scan_patterns` merge over 默认 (FAIL-OPEN **observable** — except 写 stderr 非裸 pass, MR-7 治理自观察: 治理工具自己遵守 MRD-SILENT-EXCEPT-001) + `_MRD` 模块常量. `_LOG_STDERR_EXEMPT_BASENAMES = set(_MRD["diagnostic_whitelist"])` 派生. 5 use-site (`_load_registry`×2/`_discover_uncovered_api_keys`/`_discover_uncovered_topics`/whitelist) 改读 `_MRD`. yaml 新 `mrd_scan_patterns` 段值 == 默认. **不铸新 INV** (镜像 chunk 3a/4 用 test 守卫). ④ **byte-identical 验证 (核心)**: 重构前后 governance --json 逐项比对 — discovery 14 项 status/计数/违规文件集**完全一致** (5 uncovered job / 12 api_key / 14 silent-except 文件集 adapter/daily_observer/kb_trend/governance_checker), 唯 MRD-AUDIT-PERF timing 数字变 (非确定性) + governance_checker.py 自身已有违规行号位移 (我加 38 行代码). 89/89 inv 全 pass / exit 0. ⑤ **24 新单测 7 类**: TestMrdDefaults(3) + TestLoadMrdPatterns(7 含 full/partial override + FAIL-OPEN observable + 副本不污染默认) + TestMrdInjectionWired(3 含白名单派生 + 行为级 registry_file override→[]) + TestYamlSectionDriftGuard(2 yaml 值 == 默认 = 字节级一致守卫) + TestSourceGuards(6 含 chunk 3b marker + 反向硬编码消除守卫 + except observable) + **TestDemoConfigInjection(3 端到端: ONTOLOGY_CONFIG_DIR=demo → 引擎读 WeatherBot `weatherbot_jobs.yaml` + 反向不注入读 bridge `jobs_registry.yaml`)**. **反向验证守卫真有效**: sabotage 退回硬编码 → 源码守卫 fail; sabotage yaml 改坏值 → drift guard fail. 还原 24/24 全过. ⑥ **demo 端到端**: examples/minimal_consumer/ontology/governance_ontology.yaml 加 `mrd_scan_patterns` (WeatherBot `weatherbot_jobs.yaml`/`weather_alert.sh`), 证明真消费方经 config-injection 读自己的 MRD 模式. ⑦ **验证**: 118→119 suites (+1 mrd_config_injection) / 4126→4150 tests (+24) / 0 fail / governance 89 inv 818 checks 不变 (无新 INV/MR) / 安全 95/100 / VERSION 0.37.9.68 不变 (包化 config-injection 零业务语义, 同 chunk 1/3a/4). ⑧ **Mac Mini 待用户**: git fetch+reset 同步 (config-injection 默认行为不变, governance audit cron 行为与改前一致). ⑨ **元价值 (终极目标 pip install ontology-engine 推进)**: chunk 4 (demo) → chunk 3a (convergence config-inject) → **chunk 3b (MRD 单文件名 config-inject)** — MRD 扫描器从"硬编码 bridge 文件名"升级为"消费方可配置". WeatherBot demo 真读自己的 `weatherbot_jobs.yaml` 证明可扩展. 下次候选: chunk 3b.2 (glob 形状) / chunk 2 (import 名去泛化破坏性 rename) / chunk 5 (sdist build) / ArXiv 论文. |
| V37.9.125 | 2026-06-09 | **日落法 root-cause — doc-header 统计自动同步 (gen_readme_badges 扩展) + 顺手修 full_regression governance 回写静默失败 (同款 stat-drift 家族, 用户选 doc-stat-sync 方向)** — ① **触发**: 周二开工无日期门控强候选 (OpenClaw hold 到 6/20). 用户从 3 方向 (doc-stat-sync / chunk 2 / ArXiv 论文) 选 **日落法 doc-stat-sync (推荐)** — 纯 dev/低风险/直接兑现北极星 #34. **问题**: docs/FEATURES.md / config.md / ontology_engine_packaging.md 的 header 摘要行统计 (tests/suites/inv/MR/checks/MRD/providers/cases/security/governance 版本) 仍手维护, 2026-06-08 "GitHub 全面文档刷新" 就是手动改这些 drift 数字 — 与 README 徽章 (V37.9.99 gen_readme_badges 已自动同步) 形成"一半自动一半手动"的递归维护负担. ② **设计 (原则 #28/#34 一物一形)**: **扩展现有 gen_readme_badges.py 不新建文件不改名** (rename 会动 full_regression×2 + test import + 历史引用 = 制造新接缝, 违反"防御本身是事故面"). compute_facts 加 6 新权威源事实 (test_suites←status.json / governance_checks+version←audit_metadata / security_score←status.json / mrd_scanners←meta_rule_discovery 条目数 / cases←ontology/docs/cases/*.md 文件数, 全 FAIL-OPEN 取不到返 None 不管理对应 token). `_doc_header_specs` 三 doc 摘要行 token 替换 (anchor 匹配整摘要行, token bound 到该行防未来 body 碰撞; 已核验每统计在摘要行内恰好 1 次). FEATURES/packaging 的 point-in-time 标记 (chunk 完成版本) **有意不同步** (历史快照非当前统计). **不铸新 governance INV** (镜像 V37.9.99: 靠 `--check` + full_regression line 254 doc-drift 层 + test 守卫, 原则 #34 不增治理). ③ **顺手修真 MR-4 静默故障 (同款 stat-drift 家族, 北极星对齐)**: 开工核查发现 status.json `quality.governance_invariants`/`governance_checks` 陈旧 (85/790 vs 权威 89/818). 深查根因: full_regression L517 governance 回写解析器**一直静默失败** — 旧 `depth` 字符计数器撞 governance_checker stdout 的 `[SYSTEM_ALERT]` 行 (某 check 触发 reserved-file 检测打印) + V37.3 起 --json 附带 combined object + 字符串内括号让 depth 误判 → GOV_STATS 空 → `if [-n]` 跳过 → status.json governance 字段长期 stale. 改鲁棒: 跳所有 log 前缀行 ([proxy]/[SYSTEM_ALERT]/[gate:] 任意 [WORD]/[word:]) + `json.JSONDecoder().raw_decode` 解析第一段 legacy 不变式数组 (正确处理字符串内括号 + 忽略尾部 combined object). 修复后 GOV_STATS=89/89/724/738 (运行时不变式级 check, 与 docs 的 818 声明操作总数是不同度量, 都合法). **MR-10 三问全过**: 之前存在 (非我引入, 长期潜伏) / 同 stat-drift 家族 / 最小修复 = 鲁棒 parser. **低 blast radius** (只影响 status.json 信息字段回写, 不影响测试 pass/fail). ④ **27 新单测** test_gen_readme_badges 21→48 (7 类): TestComputeFactsExtended(7 新事实+与 audit_metadata 一致) + TestDocHeaderSpecs(3 含 FAIL-OPEN 跳 None) + TestApplyOneDoc(3 含 body 不被碰守卫) + TestApplyDocHeadersRealRepo(2 真仓库已同步幂等) + TestDocHeaderReverseValidation(3 机器化破坏真 doc 统计 → 修回权威值) + TestFullRegressionGovParse(4 含 fixture 复现 [SYSTEM_ALERT]+字符串内括号+尾部 object + real-repo 锚定结构 + raw_decode 源码守卫). **反向验证守卫真有效**: 手动破坏 3 doc 统计 → --check exit 1 抓到 → --write 修回 → git diff 零净改动; sabotage gen_readme 删 config spec → test 立即 fail; sabotage full_regression raw_decode 代码 → 守卫 fail (首版守卫只查 "raw_decode" 字串被注释自引用误过 → 强化查 `json.JSONDecoder().raw_decode` 代码调用, V37.9.110 自引用教训). ⑤ **dogfood**: 本 session 版本 bump (v37.9.124→125 + tests 4099→4126) 的 doc-drift 由新扩展的 gen_readme_badges --write 一键同步 (README + 3 doc header), 自证工具有效. ⑥ **验证**: 118 suites 不变 (gen_readme_badges 已注册套件, 加 test 非加套件) / 4099→4126 tests (+27) / 0 fail / governance 89 inv / 818 checks 不变 (无新 INV/MR) / 安全 95/100 / VERSION 0.37.9.68 不变 (doc-sync 工具 + parser bugfix, 零业务语义). ⑦ **Mac Mini 待用户**: git fetch+reset 同步. 下次 full_regression 跑 governance 回写 status.json 字段将首次正确更新 (89/89 inv + 724/738 checks, 不再 stale 85/790). ⑧ **元价值 (日落法 root-cause 兑现)**: 把 doc-header 统计从"靠记忆手动同步 (每 session drift)" 升级为"机器自动同步 + --check CI 守卫" — 缩 doc-drift 接缝, 一物一形 (统计单一真理源). 顺手修的 full_regression parser bug 是同款"脆弱解析 → 静默 stale"接缝, 同 session 一并杀. 下次候选: 文档 last-updated 行 / 40 jobs/5 SLO/19 preflight 等更静态统计纳入 (V2 follow-up) / OpenClaw 6/20 / ArXiv 论文. |
| V37.9.124 | 2026-06-08 | **日落法 #29 — INV-OBSERVER-001 runtime check 收窄到契约核心类 (缩 dev-production env-dependency 接缝, V37.9.121-hotfix2 血案根因) + 3-engine-merge 先评估后 DEFER** — ① **触发**: 用户在 V37.9.122/123 (#27 闭合) 后选 #29 (INV runtime check 收窄). 先评估 3-engine-merge → DEFER (cosmetic 收益换高 blast radius, 详见前 commit). ② **#29 问题 (V37.9.121-hotfix2 血案根因)**: governance INV runtime check 跑全测试套件 = dev-production 接缝 — INV-OBSERVER-001 跑全 test_daily_observer (166 测试), 套件里任一 env-dependent test 让 INV 在 Mac Mini 误报 (test_missing_last_run 泄漏真实 last_run, _MAC_MINI_JOBS_DIR fallback 读真实 ~/.openclaw/jobs). V37.9.121-hotfix2 修了单 test 隔离, #29 是更深的接缝缩窄. ③ **调查 (原则 #28 + #18 补证据非补功能)**: 扫 ~13 个全套件 runtime check, env-dependency 信号分类 — 唯一【已证明】env-dependent 是 test_daily_observer (16 信号). 其他 (router/scanner/health 等) env-independent: test_v37_9_76_router 16 信号全是 patch 隔离 + relative-to-HOME expanduser 一致 (dev/Mac Mini 同值, INV-ROUTER false-fail 是 stale code 非套件 env-dependency); scanner 扫 repo 文件 env-independent. **只收窄 INV-OBSERVER-001, 不动其他 (churn, 原则 #34 防御本身是事故面)**. ④ **好模式参照**: INV-DREAM-CROSS-DOMAIN runtime 跑特定类 `test_hallucination_guards.TestV37_9_89_Level6CrossDomain` (非全文件). ⑤ **收窄实施**: INV-OBSERVER-001 runtime 从 `subprocess.run([sys.executable, _test])` (全 166 测试) → **动态正则发现契约核心类** `TestV37_9_(?:87|88|92|93)_*` (single-call/registry/status/sampling, 16 类/93 测试) + `-m unittest` 跑. 排除 general 类 (TestResolveLastRunPath/TestScanJobStatuses 触碰 _MAC_MINI_JOBS_DIR env-dependent). **动态正则防类名 drift** (新加 TestV37_9_88/92/93 类自动含); ≥12 sanity 门槛防契约类异常缺失; **for-loop 非 comprehension (V37.3 exec 作用域陷阱)**. 契约行为已被 INV 上方 inline check 直接验证 (env-independent); full_regression (dev) 仍跑全套件 catch 一切. **验证契约类 env-independent**: V37_9_92 触碰 Mac Mini 路径的类 触碰_MAC_MINI=False + 有隔离机制 (mock/patch). ⑥ **#29 收窄约定 (给未来 INV 立)**: 当 INV runtime 跑的套件含 env-dependent 测试 (读 repo 外真实系统状态), INV 跑契约核心类非全套件; 纯逻辑套件跑全套件 OK 不强制 (避 churn). ⑦ **7 新单测 test_v37_9_124**: runtime 用契约类非全文件 (反 [sys.executable, _test] 反模式 + V37.9.121-hotfix2 血案引用) + for-loop 非 comprehension + 契约类可发现 ≥12 + 收窄后真跑通 (behavioral) + general 类被排除 + 反向 general 类有 env 信号证排除有意义 + 契约类不泄漏真实 _MAC_MINI_JOBS_DIR + marker. **反向验证守卫真有效**: sabotage 改回全文件 → 守卫立即 FAIL, 还原 7/7 全过. ⑧ **验证**: 117→118 suites (+1) / 4092→4099 tests (+7) / 0 fail / governance 89 inv 不变 (INV-OBSERVER-001 runtime 内涵收窄非新增) / exit 0 / 安全 95/100 / README 徽章同步 4099 / VERSION 0.37.9.68 不变 (日落法零业务语义). ⑨ **Mac Mini 待用户**: git fetch+reset 同步. 下次 07:00 governance audit cron 跑 INV-OBSERVER-001 runtime 只跑契约核心 93 测试 (非全 166), 即使未来 test_daily_observer 加 env-dependent test 也不误报 INV. ⑩ **元价值 (日落法缩接缝非加治理)**: V37.9.117 北极星"缩小 dev-production 接缝非加治理"兑现 — INV runtime 跑全套件是 governance 在 dev 验证 dev 自己但事故住在 Mac Mini 接缝 (V37.9.110 写污染/V37.9.113 test_convergence/V37.9.121-hotfix2 读泄漏同款). 收窄到契约核心类让 Mac Mini governance audit 只验证 INV 真正守的契约, 不被无关 env-dependent test 误报. 数据驱动只收窄已证明案例 (1/13), 拒绝投机收窄其他 12 (补证据非补功能). 日落法退役: V37.9.118/119/120/122/123/124. 下次候选: OpenClaw ~6/15 / ArXiv 论文 (Stage 2→3). |
| V37.9.123 | 2026-06-08 | **日落法 #27 概念 B — status.json 内容漂移豁免 bash 收敛 (用户选, V37.9.122 同 session follow-up 兑现) + INV-DEPLOY-003 升级守新 pattern** — ① **触发**: V37.9.122 收敛概念 A (RUNS_FROM_REPO_CLONE FILE_MAP 成员豁免) 后登记概念 B 为 follow-up. 用户合并 PR #662 同步 Mac Mini 后明确选"概念 B status.json 内容漂移 bash 收敛". ② **MR-15 接缝先排查 (原则 #28 + 反馈 #1)**: 核实概念 A 不引入新 seam bug — `path_consistency_scanner.py`/`check_registry.py` 不在 FILE_MAP (从 repo 跑), `preflight_check.sh` 在 FILE_MAP (部署 $HOME), 但 **preflight line 8-16 V37.8.3 机制**当从 $HOME 跑时自动解析 $SCRIPT_DIR→repo + cd 过去 → import path_consistency_scanner 永远从 repo 找到. 概念 A 安全 ✓. ③ **真一物二形**: status.json 内容漂移豁免 (文件在 FILE_MAP 但内容仓库快照 vs 运行时刷新合法分叉, md5 比对无意义) 散落 2 处 bash 硬编码 `if [[ "$SRC" == "status.json" ]]`: preflight check 6 (V37.8.1) + auto_deploy drift loop (V37.8.11). 与概念 A 是**不同 concern** (内容 vs 成员). ④ **收敛 (单一真理源)**: path_consistency_scanner 加 `CONTENT_DRIFT_EXEMPT` dict (status.json + reason) + `_EXEMPT_CATEGORIES` 三类映射 + `--print-exempt {content-drift,repo-clone,non-standard-dst}` CLI (早退不依赖 yaml, robust). bash 经 `--print-exempt content-drift` 查询 + `printf \| grep -qxF "$SRC"` 全行成员检查. ⑤ **不同 FAIL 方向是设计 (非 bug)**: auto_deploy drift loop = **FAIL-SAFE** (查询失败/空 → 安全网退回 status.json, 绝不静默 overwrite runtime status.json 防 V37.8.11 每小时覆盖血案; 安全网赋值非豁免规则硬编码, 规则在 path_consistency_scanner) / preflight check 6 = **FAIL-OPEN** (查询失败 → md5 比对 → 可见 fail 无害). 关键路径 auto_deploy (set -eEuo, 2-min cron) 用 `\|\| true` 守 + CWD 已 cd $REPO_DIR. ⑥ **INV-DEPLOY-003 升级 (而非新增)**: V37.8.11 不变式硬检查旧 `if SRC == status.json` 字面量, 收敛后 full_regression 立即 ❌ 抓到 (证明它在守 V37.8.11 防线). 更新 checks 验证新 pattern (CONTENT_DRIFT_EXEMPT 单一源含 status.json + 两侧查询 + 成员检查 + auto_deploy FAIL-SAFE 安全网) + runtime python_assert for-loop (V37.3 exec 作用域) + design_decision/blood_lessons 记 V37.9.123. 契约不变 (status.json 两侧豁免 + 保留 FILE_MAP new-commit 路径). ⑦ **21 新单测 7 类 test_v37_9_123**: SingleSourceContract(4 含概念 A/B 不同 concern) + PrintExemptCli(4 含 yaml-independent robust) + AutoDeployConvergence(4 含**FAIL-SAFE 安全网行为: 空查询→status.json 退回仍豁免 / 真查询→豁免无安全网 / 空+adapter.py→不豁免**) + PreflightCheck6Convergence(3) + MembershipPattern(4 grep -qxF 全行匹配 partial 不误命中) + ReverseValidation(1 fake 空 CONTENT_DRIFT_EXEMPT → CLI 打印空) + Marker(1). **反向验证两层守卫真有效**: sabotage auto_deploy/preflight 改回 `== status.json` 字面量 → 源码守卫立即 FAIL, 还原 21/21 全过. ⑧ **验证**: 116→117 suites (+1) / 4071→4092 tests (+21) / 0 fail / governance 89 inv 不变 (INV-DEPLOY-003 升级非新增) / exit 0 / 安全 95/100 / README 徽章同步 4092 / VERSION 0.37.9.68 不变 (日落法零业务语义). ⑨ **Mac Mini 待用户**: git fetch+reset 同步. 下次 auto_deploy 2-min cron / preflight --full 经 CONTENT_DRIFT_EXEMPT 单一源豁免 status.json (drift 告警不变, 内部收敛). 加新内容漂移豁免现只需改 path_consistency_scanner 一行. ⑩ **元价值 (日落法 #27 完整闭合 + 原则 #34 trade-off 诚实登记)**: 概念 A (V37.9.122 FILE_MAP 成员) + 概念 B (V37.9.123 内容漂移) = #27 两个不同 concern 的豁免都收敛到 path_consistency_scanner 单一源. **诚实登记 原则 #34 trade-off**: 概念 B 加了 CLI + 2 subprocess query + 安全网 + 守卫来收敛 2 个稳定 bash 字面量 — 净机器更多, 但换"加新内容漂移豁免只改一处"+ 闭合 V37.8.1/V37.8.11 一物二形. INV-DEPLOY-003 升级是好信号 (它在守 V37.8.11 防线, 收敛立即被抓 → 更新而非删). 下次候选: OpenClaw ~6/15 / 3-engine-merge (高风险 deferred) / ArXiv 论文. |
| V37.9.122 | 2026-06-08 | **日落法退役第四步 — FILE_MAP 豁免一物多形收敛 (#27) + 修 V37.9.120 漏同步 check_registry 潜伏 bug (原则 #31 反复血案类闭合, 用户选日落法北极星方向)** — ① **触发**: 周一开工无日期门控强候选 (OpenClaw ~6/15 未到 / #32 用户观察需 Mac Mini dev 做不了 / 现状全绿 4062 tests). 完整 unfinished 列表识别强日落法候选 #27 (FILE_MAP 豁免一物多形). 用户选 #27 (推荐) — 纯 dev + 修反复 bug 类 + 直接执行北极星 (原则 #34 日落法 MR-22 + 原则 #31). ② **真一物多形确认 (原则 #28 理解再动手, 非死工作)**: `RUNS_FROM_REPO_CLONE`={auto_deploy.sh} 豁免散落 3 个 Python 消费者各自硬编码 'auto_deploy.sh' 字面量 — (a) `path_consistency_scanner.py:83` RUNS_FROM_REPO_CLONE (较权威源) (b) `preflight_check.sh` check 15 ×3 (743 V37.8.13 forward + 757/786 V37.9.121-hotfix reverse/registry) (c) `check_registry.check_filemap_completeness:258` **漏豁免**. ③ **发现真潜伏 bug (#27 活样本)**: `check_registry.py --check-crontab` 实跑揭示 `ERROR: [auto_deploy] 'auto_deploy.sh' 存在于仓库但不在 FILE_MAP` — V37.9.120 退役 auto_deploy 出 FILE_MAP 时更新了 path_consistency_scanner + preflight + jobs_registry 注释 (注释说"check_registry 满足"指 check_crontab 函数), 但**漏了 check_filemap_completeness 另一个函数**. 潜伏 (preflight check 2 只 grep '间隔漂移'/'未找到' 不消费此 error / full_regression 用不带 --check-crontab 的基本校验 → 双重掩护). 是 V37.8.11/V37.8.13/V37.9.120/V37.9.121-hotfix 反复"跨消费者豁免漏同步"血案类的活样本. ④ **收敛 (原则 #28 最小修复, 单一真理源)**: path_consistency_scanner.RUNS_FROM_REPO_CLONE = 唯一权威源 (加自文档化注释列 3 消费者). (a) check_registry.check_filemap_completeness `from path_consistency_scanner import RUNS_FROM_REPO_CLONE` (FAIL-OPEN 缺失则空集+warning 让 auto_deploy 重被 flag = 可见信号) + line 258 加 `and not in _runs_from_repo_clone` → 修潜伏 bug. (b) preflight check 15 inline Python import 同款 + 3 处 `== 'auto_deploy.sh'` → `in RUNS_FROM_REPO_CLONE`. 加新 RUNS_FROM_REPO_CLONE 豁免现只需改 path_consistency_scanner 一行. **范围控制 (原则 #28)**: 概念 B (status.json 内容漂移豁免, preflight check 6 + auto_deploy drift loop 2 处 bash 字面量) 是不同 concern (内容 vs 成员) + 稳定无近期复发 + bash-only (auto_deploy 关键路径风险) → 登记 follow-up 不本 session. job_smoke_test 实际无 FILE_MAP 豁免 (#27 登记略不准). ⑤ **9 新单测 5 类 test_v37_9_122**: TestSingleSourceContract(2 含每条豁免有 reason) + TestCheckRegistryConvergence(3 含**潜伏 bug 行为修复** + **反向验证空豁免则 flag 证豁免真做活** + 源码守卫无字面量) + TestPreflightCheck15Convergence(3 含源码守卫 3 处 in RUNS_FROM_REPO_CLONE + **行为 forward fake crontab auto_deploy 不 flag** + **行为反向 fake 空 path_consistency_scanner → auto_deploy flag 证 import 真做活**) + Marker(1). **反向验证两层守卫真有效**: sabotage 移除 check_registry 豁免子句 → 行为守卫立即 FAIL (抓潜伏 bug 回归); sabotage 改回 preflight 字面量 → 源码守卫立即 FAIL (抓重新散落). 还原后 9/9 全过. ⑥ **验证**: 115→116 suites (+1) / 4062→4071 tests (+9) / 0 fail / governance 89 inv 不变 (无新 INV, 复用现有守卫) / 823 checks pass / 安全 95/100 / README 徽章同步 4071 / VERSION 0.37.9.68 不变 (日落法收敛零业务语义, 同 V37.9.118-121). ⑦ **Mac Mini 待用户**: git fetch+reset 同步. `check_registry.py --check-crontab` FILE_MAP 完整性不再误报 auto_deploy (潜伏 bug 修). 下次 preflight --full check 15 / 任何 check_registry --check-crontab 调用都从单一真理源读豁免. ⑧ **元价值 (日落法退役第四步 + 原则 #31 反复血案类闭合)**: V37.9.118 (governance abspath→getcwd) → V37.9.119 (engine.py realpath) → V37.9.120 (auto_deploy 双副本) → **V37.9.122 (FILE_MAP 豁免单一真理源)** 日落法退役四步. 真一物多形退役 (3 消费者各自硬编码 → 1 源) + 顺手修 V37.9.120 自己漏的潜伏 bug (退役动作暴露同款血案类). 闭合 V37.8.11/V37.8.13/V37.9.120/V37.9.121-hotfix 4 次"跨消费者豁免漏同步"反复 — 未来加 RUNS_FROM_REPO_CLONE 豁免不会再漏同步 (单一源 + 守卫). 下次候选: 概念 B status.json 内容漂移 bash 收敛 (需 CLI/generated-file, auto_deploy 关键路径谨慎) / OpenClaw 升级 ~6/15 / 日落法 3-engine-merge (高风险 deferred) / ArXiv 论文. |
| V37.9.121-hotfix2 | 2026-06-08 | **INV-OBSERVER-001 runtime test Mac Mini 隔离 bug 修复 — test_missing_last_run 泄漏真实 last_run (07:00 governance cron 实测发现, MR-15 dev-production 接缝)** — ① **触发**: 用户贴 07:00 governance audit cron + 08:30 watchdog 告警, 报 INV-OBSERVER-001 + INV-ROUTER-001 + INV-CRON-004 失败。**数据驱动诊断 (原则 #28/#26, 不盲改)**: 07:00 显示"不变式 87"= **pre-V37.9.121 stale 代码** (用户同步是 16:58+)。用户同步后重跑 governance: **INV-ROUTER-001 + INV-CRON-004 自愈** (router 07:00 stale 代码 V37.9.105 同款 + crontab auto_deploy 重复经 V37.9.116 CONVERGENCE_DRY_RUN 修复, `uniq -d` 无重复), 对话精华 error = 已知 kb_harvest Reduce 超时 (#26), dblp 503 = 外部 API。**但 INV-OBSERVER-001 仍 ❌** (723/724) — 真 Mac Mini env-dependency, 我 dev 724/724 全过。② **根因**: INV-OBSERVER-001 runtime check 跑 `test_daily_observer.py` 全 166 单测, `test_missing_last_run` 在 Mac Mini 失败。`_resolve_last_run_path` 第二候选 `_MAC_MINI_JOBS_DIR = ~/.openclaw/jobs` (V37.9.56-hotfix 加的真实 fallback 让 observer 在 Mac Mini 找真 last_run) **泄漏真实 Mac Mini 状态进空 temp dir 测试**: test 给空 temp → temp 候选 not found → fallback 到真实 `~/.openclaw/jobs/<job>/cache/last_run.json` (Mac Mini 上 hf_papers 等真 job 存在) → found=True → `assertTrue(all not found)` 失败。dev 无此路径 → 全 found=False → 通过 (MR-15 dev-production 接缝)。③ **最小修复**: TestScanJobStatuses 加 setUp/tearDown 隔离 `_MAC_MINI_JOBS_DIR` (save/restore 到 nonexistent 路径), **镜像 TestResolveLastRunPath 已有的同款隔离 (line ~47-55) — 同款隔离漏了一个 test 类 (原则 #31 同类)**。生产代码 fallback 不动 (Mac Mini 找真 last_run 是对的, 测试需隔离)。④ **原则 #31 全量核实**: TestV37_9_88_ScanJobStatusesIntegration 也调 scan_job_statuses 但 robust (monkey-patch JOBS_SUBDIRS 小列表 + 给每 job 建 temp 文件, temp 候选优先 → Mac Mini 巧过是设计稳健非巧合, 无需修); test_returns_none_when_all_missing 用 "nonexistent_job" 真实路径无此 job → robust。⑤ **反向验证守卫真有效**: 模拟 Mac Mini (设 `_MAC_MINI_JOBS_DIR=fake` 含真 last_run) — **BUG 复现** (无隔离 scan 空 temp 泄漏 `['hf_papers']` found=True) + **FIX 验证** (我的 setUp 隔离后 test_missing_last_run PASS)。dev 166 测试仍过 + governance INV-OBSERVER-001 ✅ 724/724 + full_regression 115/4062/0。⑥ **Mac Mini 待用户 (合并后)**: git fetch+reset 同步 → 重跑 `python3 ontology/governance_checker.py` 应 INV-OBSERVER-001 ✅ 724/724。下次 07:00 governance cron 不再误报。⑦ **元价值 (governance 跑测试套件的 dev-production 接缝, V37.9.110/113 同款但读泄漏非写污染)**: 我 V37.9.121 INV runtime 跑全 166 测试套件, 暴露 MR-15 接缝 — 全套件里任一 env-dependent test 都让 INV 在 Mac Mini 失败。本次是**读泄漏** (false fail, 危害小于 V37.9.110 写污染)。修复是隔离 test (根因, 测试隔离 bug)。**日落法接缝候选 (登记)**: 评估 INV runtime 收窄到契约核心 test 类 (镜像 INV-DREAM-CROSS-DOMAIN 跑特定类) vs 跑全套件, 减少未来 env-dependency 脆弱性。本 hotfix 最小修复未收窄 (test 隔离已让全套件 env-robust)。 |
| V37.9.121-hotfix | 2026-06-08 | **preflight check 15 auto_deploy 豁免漏同步修复 — V37.9.120 日落法退役 auto_deploy 出 FILE_MAP 的原则 #31 不完整跨消费者同步 (Mac Mini 部署 V37.9.121 时 preflight --full 实测发现)** — ① **触发**: 用户合并 V37.9.121 后 Mac Mini `git fetch+reset` 同步 + 跑 `preflight_check.sh --full` 验证部署, **check 15/19 (Crontab↔FILE_MAP 双向一致性) 2 项失败**: `auto_deploy.sh: crontab 引用但不在 FILE_MAP 中` + `Registry job auto_deploy: auto_deploy.sh 不在 FILE_MAP 中`。**非 V37.9.121 引入** — 是 V37.9.120 日落法退役 auto_deploy 出 FILE_MAP 时的**不完整跨消费者豁免同步 (原则 #31)**。② **根因 (原则 #28 三问)**: V37.9.120 把 auto_deploy 从 FILE_MAP 退役 (从 repo clone 跑, 无独立 bootstrap 价值), 并在 `path_consistency_scanner.py` 加 RUNS_FROM_REPO_CLONE 豁免 + check_registry 满足, **但漏了 `preflight_check.sh` check 15 的两个错误路径**: (a) 反向检查 (line 759 `crontab 引用但不在 FILE_MAP`) — V37.8.13 的 auto_deploy 豁免只在 `script_name in file_map` 正向分支, 退役后走 else 分支报错 (b) Registry↔FILE_MAP 检查 (line 781 `entry_script not in file_map_srcs`) — auto_deploy registry entry 不再在 file_map_srcs。check 15 **只在 Mac Mini --full 跑** (需真 crontab), dev full_regression 测不到 → V37.9.120 部署后才暴露 (MR-15 dev-production 接缝)。③ **最小修复 (镜像 V37.9.120 RUNS_FROM_REPO_CLONE)**: preflight check 15 两处 else 分支加 `if script_name/entry_script == 'auto_deploy.sh': skip` 豁免, 与 path_consistency_scanner + check_registry 豁免同步。④ **原则 #31 全量同步核实**: job_smoke_test.sh 检 crontab 注册 + 运行时脚本存在性 (不检 FILE_MAP 成员) → auto_deploy repo 路径脚本存在通过, **无需修**。preflight check 6 (部署文件一致性) 只迭代 FILE_MAP 内文件 → auto_deploy 移出后不迭代 → 不报错。⑤ **验证**: bash -n 语法正确 + mock crontab (含 auto_deploy repo 路径行) 真跑 check 15 Python 逻辑两路径都正确豁免 (errors 无) + full_regression 115 suites/4062 tests/0 fail 不变 (preflight 是 bash heredoc 不在单测层, 改动不影响测试)。VERSION/inv/checks 不变 (hotfix 纯 bash 豁免)。⑥ **Mac Mini 待用户 (合并后)**: git fetch+reset 同步 → 重跑 `preflight_check.sh --full` 应 check 15 全绿 (88/0)。**另**: V37.9.120 登记的 Mac Mini 残留清理仍待做 — `bash ~/crontab_safe.sh remove "bash ~/auto_deploy.sh >> "` (删 HOME 路径 line 54) + `rm ~/auto_deploy.sh` (删 HOME 副本), 之后 ONE crontab 行 + ONE 副本。⑦ **元价值 (原则 #31 第 N 次演出 + 日落法接缝)**: V37.8.11/V37.8.13/V37.9.120 同款"跨 FILE_MAP 消费者豁免漏同步"反复出现 — 真一物多形是**多个 FILE_MAP 消费者 (path_consistency_scanner/preflight check 6/check 15/job_smoke_test) 各自独立 parse FILE_MAP + 各自维护豁免**。日落法候选 (登记): 把 FILE_MAP 豁免逻辑收敛到单一源 (如 path_consistency_scanner 作权威, 其他消费者复用其豁免清单), 消除"每加豁免改 N 处"递归接缝。本 hotfix 是最小修复未做此收敛 (urgent 解阻塞)。 |
| V37.9.121 | 2026-06-08 | **日期门控治理 INV 立案 — INV-OBSERVER-001 (合并 sampling 候选, 日落法 MR-22 一物一形) + INV-SOURCE-CREDIBILITY-001 (关闭 daily_observer Phase 0 缺 INV 缺口 + 守 V37.9.92/93/98 一周观察期稳定功能契约)** — ① **触发**: 周一开工无强候选触发 (#32 用户视角观察需 Mac Mini/WhatsApp dev 做不了 / OpenClaw 升级 ~6/15 未到 / 日落法易退役已做完 V37.9.118-120 剩 3-engine-merge 高风险 deferred)。识别真实战略张力: 日落法北极星 (#34) "缩小接缝非加治理" vs 多个日期门控 INV 候选 ~6/8 到期 (加治理)。用户选**日期门控治理 INV**。② **日落法 MR-22 应用 (在加治理任务内 honors 北极星)**: 候选登记两个 daily_observer INV (INV-OBSERVER-001 + INV-OBSERVER-SAMPLING-001) **合并成一个 INV-OBSERVER-001** — 两 INV 守同一个 daily_observer.py 是治理层一物多形, 合并避免增殖 (净 +2 INV 而非 +3)。honors 用户选择 (做日期门控治理) + honors 北极星 (不增殖 INV)。③ **INV-OBSERVER-001** (daily-observer-contract-must-hold, MR-7 治理自观察, high, declaration+runtime, **9 checks**): 守 daily_observer 全契约 — V37.9.87 single-call (daily_observer.sh 单次 `$OBSERVER_PY` + `--json` 含 report_markdown 防 BUG#1 双写 score_history) + V37.9.88 registry filter (scan_job_statuses 应用 `_filter_enabled_jobs`, MR-8 SoT 排除 disabled 防 pwc stale 误报 2 月) + V37.9.92 `_resolve_registry_path` Mac Mini canonical 路径 (MR-15 deployment-layout) + `_write_observer_to_status` helper (quality.observer schema + FAIL-OPEN except ImportError/Exception + save_status 原子写 + run() 顺序锁 write 晚于 append_score_history) + V37.9.93 smart sampling (`_read_file_sample` head+marker+tail **行为级守卫**: 构造长文件必产 omission marker 非 content[:max_chars] + 常量 1400/500 + CRITIQUE_SYSTEM 采样说明段) + FILE_MAP 部署 + runtime 真跑 test_daily_observer.py 166 单测。**关闭 governance "7 个 enabled job 未被不变式覆盖" 之 daily_observer** (7→5)。④ **INV-SOURCE-CREDIBILITY-001** (source-credibility-contract-must-hold, MR-8 SoT, high, declaration+runtime, **8 checks**): 守 source_credibility 全契约 — 5 档 tier + `_DEFAULT_TIER` 社媒 + get_credibility FAIL-OPEN (未知源/非 string→社媒+未分类来源 永不抛异 绝不阻塞 dream/evening cron) + chaspark=博客 tier (observer proposal #2 锚点, 华为茶思屋非主流源须标注需独立验证 不与 ArXiv 等同) + kb_dream 5 注入点 + kb_evening import + FILE_MAP + runtime 真跑 test_source_credibility.py 56 单测 (含 TestSourceCoverage SOURCE_CREDIBILITY↔jobs_registry drift guard)。⑤ **反向验证守卫真有效**: sabotage chaspark 博客→学术同行评审 → INV-SOURCE-CREDIBILITY-001 ❌; sabotage `_read_file_sample` 退回 content[:max_chars] (复现 V37.9.84 regression) → INV-OBSERVER-001 ❌ (719/724, 5 check 多层捕获)。还原后 724/724 全过。⑥ **践行日落法 MR-22 (lean + 顺手退役一物多形)**: **零新测试文件** — INV runtime check 复用现有 166+56 单测直接跑, 不为加 INV 而造新测试。**顺手退役 test_v37_9_96 的 `test_audit_metadata_total_invariants_87`** (硬编码 expected=87 脆弱守卫, 每次加 INV 必手改 V37.9.96→85/V37.9.100→87/本会→89 = 递归接缝), 它严格冗余于同 class 的动态守卫 `test_actual_invariant_count_matches_metadata` (grep == metadata, V37.9.96 本意就是防漂移加的) → 一物一形, 退役后动态守卫真能抓漂移 (sed metadata→99 验证 FAILED)。version-bump 连带: test_convergence.py audit_metadata version alternation 加 "3.55"。⑦ **验证**: 115 suites / **4062 tests** (-1 退役硬编码 count 守卫 日落法 MR-22) / 0 fail / governance v3.54→v3.55 / **87→89 invariants** (+2) / **801→818 checks** (+17: 9+8) / 23 meta rules 不变 (复用 MR-7+MR-8) / 安全 95/100 / README 徽章同步 invariants 89 tests 4062 / VERSION 0.37.9.68 不变 (governance 立案零业务语义, 同 V37.9.117-120)。⑧ **Mac Mini 待用户**: git fetch+reset 同步。下次 governance audit cron 07:00 跑两个新 INV (runtime 真跑 test_daily_observer + test_source_credibility), daily_observer 不再是未覆盖 job。⑨ **元价值**: 在"加治理"任务内仍践行日落法 — 把候选登记的 3 个 INV 合并成 2 个 (一物一形), 复用现有测试不造新机器 (lean)。关闭 Phase 0 自主发现的 daily_observer 缺 INV 缺口 + 把 V37.9.92/93/98 一周观察期已稳定的功能从"靠记忆"升级为 governance 主动守。下次候选: 6/9 起 INV-OBSERVER-SAMPLING 已并入本 INV 无需单独立; OpenClaw 升级 ~6/15; 日落法 3-engine-merge (高风险 deferred) / ~/ontology symlink 评估。 |
| V37.9.120 | 2026-06-08 | **日落法退役第三步 — auto_deploy 双副本一物多形根治 (3 次复发 V37.9.106/111/116 都"删了拉倒", V37.9.120 退役 HOME 副本根治) + 纠正 V37.9.116 两处错误前提** — ① **触发**: 用户选继续 auto_deploy #32 真日落法根治 (高价值, 需 Mac Mini 确认真实 crontab 行)。② **纠正 V37.9.116 两处错误前提 (原则 #28 深查)**: **(1) auto_deploy 不在 FILE_MAP 是错的** — FILE_MAP line 335 仍有 `auto_deploy.sh|$HOME/auto_deploy.sh`, 自复制守卫 `$REPO_DIR/$SRC == $DST` 对 auto_deploy 是 `~/openclaw-model-bridge/auto_deploy.sh ≠ ~/auto_deploy.sh` → **不跳过 → 真部署 HOME 副本** (V37.8.12 只移除自复制映射非此条)。所以 auto_deploy.sh 有**两个物理副本** (HOME via FILE_MAP + repo clone via git), crontab 引用两个 = 真一物多形。**(2) 直接改 entry: openclaw-model-bridge/auto_deploy.sh 会 break check_registry** — check_registry 按 `repo_root/entry` 校验, 该值 = `repo_root/openclaw-model-bridge/auto_deploy.sh` (双路径) 不存在 → 报错。auto_deploy 是特例 (从 repo clone 跑非部署副本), entry 约定无法表达。③ **Mac Mini 诊断数据确认** (用户跑): crontab line 5 `bash -lc 'bash ~/openclaw-model-bridge/auto_deploy.sh >> ...'` (repo, canonical, 真在跑) + line 54 `bash -lc 'bash ~/auto_deploy.sh >> ...'` (HOME, **逐字 = `_format_cron_line(auto_deploy.sh)` 输出 → 确认 convergence 生成**) 都在; `~/auto_deploy.sh` (28341B 非 exec) + `~/openclaw-model-bridge/auto_deploy.sh` (28341B exec) 都存在同 size; 版本 V37.9.117 已含 V37.9.116 dry-run + line_contains parser。**谜团自愈**: line_contains 纯子串匹配 line 5 含 `auto_deploy.sh` → 不再判 missing → line 54 是 stale 残留 (V37.9.116 原子实验跑在 pre-line_contains stale 代码上)。④ **真退役 (Option 1a, 非 no-op)**: (a) **FILE_MAP 移除** `auto_deploy.sh|$HOME/auto_deploy.sh` + 加入"有意不在 FILE_MAP"排除清单 — auto_deploy 从 repo clone 跑必须 cd $REPO_DIR git pull, HOME 副本**无独立 bootstrap 价值** (两副本都需 repo) 纯冗余。(b) **entry 保持裸名** `auto_deploy.sh` (check_registry 满足 repo_root/auto_deploy.sh 存在 + line_contains 匹配 line 5 子串 → 永不判 missing → 不重加) + 加注释说明特例。(c) **path_consistency_scanner.py 加 RUNS_FROM_REPO_CLONE 豁免** (免疫系统开火: INV-PATH-CONSISTENCY-001 断言每 job entry 在 FILE_MAP, auto_deploy 移出后报 MISSING_FILE_MAP → 加合法豁免显式 reason, 与现有 ALLOWED_NON_STANDARD_DST 同款机制)。⑤ **残留 dormant quirk (文档化)**: `_format_cron_line(auto_deploy)` 仍生成 HOME 路径 (line_contains 下不触发, 已在 registry 注释登记; 若未来切 cron_lines_set_diff parser 需特殊处理 auto_deploy repo 路径, V37.9.66 已 defer)。⑥ **践行日落法 (MR-22)**: 零新 INV / 零新 test (复用 path_consistency_scanner 33 既有 + check_registry); scanner 豁免是更新既有守卫认识合法例外非新机器。VERSION 0.37.9.68 不变 (部署配置 + scanner 豁免, 零业务语义)。⑦ **验证**: 115 suites / 4063 tests / 0 fail / governance 87 inv 805 checks / 安全 95/100 / check_registry 46 jobs validated / path_consistency 0 findings (auto_deploy 豁免)。⑧ **Mac Mini 待用户 (同步后清理)**: git fetch+reset 同步 (新 auto_deploy.sh 无 FILE_MAP 自部署条目) → 然后清理 2 副本残留: `bash ~/crontab_safe.sh remove "bash ~/auto_deploy.sh >> "` (删 line 54, grep -F 只命中 HOME 路径行不碰 line 5 的 `openclaw-model-bridge/`) + `rm ~/auto_deploy.sh` (删 HOME 副本)。之后: ONE crontab 行 (line 5 repo) + ONE 副本 (repo clone)。⑨ **元价值 (真退役 + 3 次复发根治)**: 闭合 auto_deploy 双行 3 次复发 (V37.9.106/111/116 都 crontab remove "删了拉倒"从不找根, V37.9.120 退役 HOME 副本 + 谜团自愈双管齐下根治)。这是真一物多形退役 (2 副本→1 + 2 crontab 行→1), 非 V37.9.119 收尾调查的 proxy/three_gate no-op/cosmetic。免疫系统今日两次开火 (V37.9.119 7064 anti-hang 守卫 + V37.9.120 path_consistency) 都被正确识别 (一个 REVERT 一个加合法豁免)。日落法退役三步: V37.9.118 (17 chdir check os.getcwd) → V37.9.119 (engine.py realpath) → V37.9.120 (auto_deploy 双副本)。下次候选: 3 engine 实例合并 (proxy×2+three_gate×1 更大 refactor) / ~/ontology symlink 评估 / convergence cron_lines_set_diff 切换时 auto_deploy 特殊处理。 |
| V37.9.119 | 2026-06-08 | **日落法退役第二步 — engine.py abspath→realpath 收敛 + 7064 守卫开火纠正过度收敛 (真一物一形是'按 concern 分'非'单一 os.getcwd()', 免疫系统价值实证, 零新机器)** — ① **触发**: V37.9.118 收工后用户选"继续日落法退役: 7064 realpath + engine.py/test_providers.py abspath 完全收敛 (低风险纯 dev 达成完全一物一形)"。② **纠正我 offer 的两处不精确 (原则 #28 理解再动手)**: (a) `os.getcwd()` **只在 `_exec_python_assert` 的 chdir 上下文**等于仓库根; engine.py 是模块级常量 (从任意 cwd 调用), 改 os.getcwd() 会**破坏它** — engine.py 正确收敛是 **abspath→realpath** (与 governance_checker._resolve_project_root V37.9.115 同款 symlink-safe), 不是 os.getcwd()。(b) test_providers.py 780/807/830 行是 `self._write_py("myprovider.py", """...""")` **写进临时插件文件的 fixture 内容** (模拟真实插件如何找 providers 模块), 非 test_providers.py 自己的 resolution; 临时插件在任意 tempdir, os.getcwd()/realpath 都不'正确' → **完全出 scope**。line 1364 是模块相对 `dirname(__file__)` 正确。③ **engine.py line 19 + 45 abspath→realpath**: line 19 `_PROJECT_ROOT` (仅用于 sys.path.insert 让 import proxy_filters 等) + line 45 `_resolve_config_dir` 兜底。**两处一起改保持一致** — test_ontology_packaging.py line 113 不变量 `_PROJECT_ROOT == dirname(_ONTOLOGY_DIR)` 要求二者同源。dev/直连路径 realpath==abspath **零回归** (与 V37.9.115 governance_checker 同款); symlink 下 import 从真实仓库根而非靠 `$HOME` FILE_MAP 巧合。line 44 env override 的 abspath 不动 (非 __file__)。④ **7064 块决策: 守卫开火 → REVERT 回 realpath (关键认知)**: 尝试把 7064 anti-hang 块也改 os.getcwd() → full_regression `test_auto_inject_guard.test_v37_9_114_uses_realpath_not_bare_abspath_for_repo_root` **失败** (V37.9.114 守卫专门 pin 此块 realpath, 因它**挂死 Mac Mini 两次** V37.9.114/115)。**守卫开火 = 免疫系统正确工作** (日落法反思原话'很多意外是免疫系统开火')。**决策 REVERT 回 realpath** — 不是因为 os.getcwd() 技术上不安全 (chdir'd check + os.walk(followlinks=False) 不变仍防挂死), 而是**纠正了我的过度收敛假设**: 真正的一物一形**按 concern 分类**而非'单一形式': (i) `__file__`-resolution (governance_checker._resolve_project_root + 7064 anti-hang os.walk 块 + engine.py) **统一 realpath** (ii) chdir'd check 的 subprocess-cwd (V37.9.118 的 17 块) **统一 os.getcwd()**。把 7064 改 os.getcwd() 反而**制造新一物多形** (7064 getcwd vs governance_checker/engine.py realpath)。保留 realpath 才是更纯的一物一形 + 尊重 anti-hang 守卫 + 风险不对称 (touch 挂死两次的代码代价 > 边际收益)。⑤ **顺手修 V37.9.118 漏的 README 漂移**: V37.9.118 commit 改 CLAUDE.md→v37.9.118 但漏同步 README version 徽章 (仍 v37.9.117); full_regression 徽章 check 安全网**捕获真 drift + 自动修**成 v37.9.118 (本提交含此修 + 升 v37.9.119)。⑥ **proxy_filters.py L450/1461 + three_gate.py L180 的 abspath (定位 engine.py) 出 scope** (独立文件, proxy_filters 不经 symlink / three_gate 经但 works), 登记未来候选不扩 scope (原则 #28 最小修复)。⑦ **践行日落法 (MR-22)**: 零新 INV / 零新 test / 零新机器 (复用既有 test_ontology_packaging line 113 + test_auto_inject_guard V37.9.114 守卫, 后者正是开火纠正我的那个)。⑧ **验证**: 115 suites 不变 / 4063 tests 不变 / 0 fail / governance 87 inv 707/707 checks / 安全 95/100 / engine.py import OK + `_PROJECT_ROOT==dirname(_ONTOLOGY_DIR)` True / test_ontology_packaging 23 + test_providers 128 + test_ontology_extension_demo 15 全过。VERSION 0.37.9.68 不变 (治理 check + 模块路径解析重构, 零业务语义)。⑨ **Mac Mini 待用户**: git fetch+reset 同步。同步后 engine.py 经 `~/ontology` symlink 调用时 sys.path 从真实仓库根注入 (而非 $HOME), import 走仓库版本 (与 $HOME FILE_MAP 副本一致, 更 canonical)。⑩ **元价值 (免疫系统价值实证)**: 日落法退役第二步的最大收获不是 engine.py realpath, 而是**'完全一物一形 to os.getcwd()' 是错误目标的认知** — 守卫开火让我发现真正一物一形是'按 concern 分' (chdir'd→getcwd / __file__-resolution→realpath), 强行单一形式会制造新一物多形。这印证日落法反思的'免疫系统开火'价值: V37.9.114 anti-hang 守卫不是阻碍, 是纠正过度收敛的信号。realpath 现统一所有 __file__-resolution (governance_checker + 7064 + engine.py) = 真退役一个一物多形。下次日落法候选: auto_deploy 两路径统一 (#32, 需 Mac Mini) / **proxy_filters/three_gate abspath 本次调查确认不做** (proxy realpath 是 no-op 不经 symlink / three_gate cosmetic 同文件经 canonical path / 是'定位 sibling engine.py'不同 concern 非 repo-root realpath 家族 / 三处 spec_from_file_location 用不同 module 名 `_onto_engine`+`ontology_engine`+`_three_gate_engine_lazy` 已 3 独立 engine 实例 path 无关 — 我的双加载担忧不成立; '加之前先问能否退役'调查阻止一次 no-op churn) / 真一物多形候选: 3 engine 实例合并 (proxy×2+three_gate×1) 但更大 refactor 每 load 有目的高风险 / ~/ontology symlink 评估。 |
| V37.9.118 | 2026-06-08 | **日落法首个实操退役 — governance_ontology.yaml 17 个 check repo_root 从 abspath+ternary 收敛到单一源 os.getcwd() (一物多形→一物一形, 修 #30 symlink false-fail, 零新机器践行 MR-22)** — ① **触发**: V37.9.117 日落法北极星 (原则 #34) 立后第一个 session。周一开工无日期门控强候选触发 (OpenClaw 升级 ~6/15 / INV-OBSERVER ~6/8 但属"加治理"与北极星张力)。用户选 yaml abspath→os.getcwd 减表示 (V37.9.116 follow-up (c) + #30 登记, 最干净的日落法首个退役)。② **一物多形真相 (五根因之"地图≠领土"实例)**: governance_ontology.yaml 里 17 个 python_assert check 各自用脆弱 `repo_root = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) if "ontology" in os.path.abspath(__file__) else os.path.dirname(os.path.abspath(__file__))` 三行 ternary 重算 repo_root, 而**48 个 check 已用单一权威源 `os.getcwd()`** — `_exec_python_assert` 在 exec 前已 `os.chdir(_PROJECT_ROOT)` (V37.9.115 realpath 解析后的仓库根) 保证 `os.getcwd()` == _PROJECT_ROOT。17 掉队块是同一逻辑事物 (repo 根) 的多余物理表示。③ **症状 = dev pass / Mac Mini symlink false-fail (#30)**: 经 V37.9.12.1 `~/ontology` symlink 调用 `python3 ~/ontology/governance_checker.py` 时, abspath(__file__) 不解析 symlink → 这 17 个 check 误得 $HOME 误根 → subprocess `cwd=repo_root` 跑测试找不到文件 false-fail (非挂死, 因不用 recursive glob)。dev 从仓库跑 abspath==正确根故从不暴露 — 正是日落法"地图≠领土"接缝。④ **修复 (count-asserted 脚本, 原则 #28 最小修复)**: 17 块 (repo_root×10 / repo×2 / _repo×5) 收敛到 `os.getcwd()` + provenance 注释。断言恰好 17 处替换 + abspath(__file__) 53→2 (剩 2 处均非代码: 7064 V37.9.114 注释 + 7610 INV-CROSS-ENV-PATH scanner 搜索 pattern 描述, 绝不动) + realpath 1→1 (7064 块未动) + getcwd 48→65。⑤ **风险不对称保留 7064 realpath 块**: 它是 V37.9.114/115 刚硬化过的防挂死代码 (os.walk followlinks=False), abspath 块只 false-fail 永不挂死, #30 scope 明确只 abspath。converge 它的边际一物一形收益 < 重新引入 Mac Mini 挂死代价 → 保留 + 登记未来候选。engine.py/test_providers.py 自身 abspath 出 #30 scope 同样登记未来候选。⑥ **践行日落法本身 (MR-22 兑现)**: **零新 INV / 零新 test / 零新机器** — 纯减表示, 复用既有 governance 守卫 (无任何测试 grep abspath pattern 故零破坏)。镜像 V37.9.117 日落法刻意不铸新不变式模式。VERSION 0.37.9.68 不变 (治理 check 内部 repo_root 计算重构, 零业务语义零新 capability)。⑦ **验证**: 115 suites 不变 / 4063 tests 不变 / 0 fail / governance 87 inv 不变 / 707/707 checks pass dev (805 full) / 安全 95/100 / README 徽章漂移检测 ✅ (计数全不变)。git diff 17 insertions / 51 deletions 纯净。⑧ **Mac Mini 待用户**: git fetch+reset 同步。同步后经 `~/ontology` symlink 路径跑 governance 这 17 个 check 不再 false-fail (os.getcwd() 不受 symlink 影响)。⑨ **元价值**: 日落法北极星 (V37.9.117) 立后第一个**真退役动作** — 不加防御不加治理, 纯缩接缝。移除 dev-production 一物多形 (五根因之"地图≠领土"的一处), 17→0 abspath 掉队块全收敛到 65 个已有 os.getcwd() 单一源。证明日落法可操作: 项目从"always adding"转向"持续退役复杂度"的第一步落地。下次候选 (按日落法): auto_deploy 两路径统一 (#32, 需 Mac Mini 配合) / 7064 realpath + engine.py/test_providers.py abspath 完全收敛 / ~/ontology symlink 评估。 |
| V37.9.117 | 2026-06-05 | **日落法立为北极星 — 深度反思 codify (case doc) + MR-22 (sunset-over-accretion) + MR-23 (audit-observes-never-mutates) + 原则 #34 (用户: 未来发展以降复杂度为目标)** — ① **触发**: 用户在一天五版 (V37.9.112-116) 意外频发后问"请深刻反思为什么会发生这么多意外？仅仅因为系统变复杂？还是其他原因？" + 明确指示"反思+MR 都需要因为太重要, 未来后续发展将以日落法为目标降低系统复杂度". ② **核心论断**: 意外频发真因**不是"系统复杂"(部件难懂), 是"系统组合"(简单正确的部件交互面积超线性增长超过测试覆盖)**. 复杂关乎部件, 意外关乎接缝. 今天每个意外都是简单正确部件的新组合 (symlink+abspath+调用路径=挂死 / machine_sync+裸名entry+格式错配+审计不dry-run=三次复发, 缺一不爆). ③ **五层根因**: (1) 一物多形 — 同一逻辑事物多物理表示漂移, bug 住缝里 (auto_deploy 两文件两路径 / ~/ontology symlink vs repo) (2) 地图≠领土 — 4063 测试全在 dev 跑, 事故全在 production 接缝 (真 crontab/symlink/macOS BSD 工具/网络/时间), dev mock missing=空 Mac Mini 真 apply (3) 观察者改被观察者 — 07:00 审计 real-apply 改它审计的 crontab + 我诊断命令 via symlink 本身是 30min 挂死源 (4) 不完整修复伪装完整 — V37.9.114 修单 check 过全部测试根在 _resolve_project_root / V37.9.106/111 删 line 54 三次从不找根 (5) 潜伏条件累积 — 局部正确旧决策 (symlink V37.9.12.1 / dry-run 切关 V37.9.58) 组合成新事故. ④ **元层洞察**: 治理验证'代码符合规则'验证不了'规则符合现实/部署符合假设', 87 不变式全在仓库内层验证仓库自己, 事故住在仓库-真实 Mac Mini 接缝里 (无测试覆盖). **每加一层防御就多一个事故面** (原则 #8 在规模上): convergence 为关闭声明-运行时缺口而建却用 machine_sync 改生产成新事故类 — 药参与病. ⑤ **平衡视角**: 很多'意外'是免疫系统开火 (watchdog 抓重复/反向验证抓我不完整守卫/原子实验证根), 零意外可能只是免疫系统瞎了 (MOVESPEED 潜伏 60 天). 今天看得狠暴露债多是好运维卫生非退步. ⑥ **诚实记录我的责任**: 两次 30min 挂死直接触发是我用错 symlink 调用路径 + 一度归因成 07:00 cron (部分违反原则 #28). 操作者也是事故源. ⑦ **交付**: (a) case doc `ontology/docs/cases/why_so_many_incidents_2026_06_05_reflection.md` (反思型/立场型, TL;DR + 五根因 + 元层 + 免疫系统平衡 + 日落法前进方向 4 方向) (b) **MR-22 sunset-over-accretion** (日落法北极星, 3 操作规则: 加之前先问能否退役 / 一物一形 / 防御本身是事故面, lineage MR-8/MR-15/原则#8) (c) **MR-23 audit-observes-never-mutates** (审计只读, 泛化 MR-9, lineage MR-7/MR-9/MR-17, blood_lessons MR-9 三次演出 V37.9.110→113→116) (d) **原则 #34 日落法北极星** (CLAUDE.md 每次必查 33→34 条 + #8 标注战略升级) (e) **践行日落法本身**: 两 MR 刻意**不铸新不变式**, 复用既有 test_v37_9_116 + test_convergence 隔离守卫, 元规则 21→23 不变式 87 不变. ⑧ **前进方向 4 缩小接缝** (非加治理): 减少一物多形 (一条路径) / 缩小 dev-production 接缝 (一部分测试真在 Mac Mini 跑) / 让观察者只读 (V37.9.116 已做) / 加之前先退役. ⑨ **验证**: 115 suites 不变 / 4063 tests 不变 (test_convergence audit_metadata 3.54 alternation 是既有 test 加分支非新 test — 日落法不加机器) / 0 fail / governance v3.53→v3.54 / 87 inv 不变 (日落法! 无新 INV) / 801 checks 不变 / 21→23 meta rules / 安全 95/100 / README MR 徽章 23 (gen_readme_badges --check 守 MR count 漂移, 删 MR 会被 CI 抓) / VERSION 0.37.9.68 不变 (治理思想层固化 + 战略原则, 零业务语义). ⑩ **元价值**: 项目从 V1→V37.9.116 一路堆叠 (always adding) 的演进史首次确立**反向北极星** — 未来以"变小"为目标. 这不是又一条治理规则, 是承认"靠把意外转成规则无法穷尽组合面 (规则本身也是新部件新接缝)", 必须从"加防御"转向"缩接缝". V3 路标 pip install ontology-engine 的可包化粒度也将受益于持续退役复杂度. | |
| V37.9.116 | 2026-06-05 | **INV-CRON-004 auto_deploy 双行 3 次复发根治 — governance_audit 生产审计 CONVERGENCE_DRY_RUN=1 (V37.9.115 收尾诊断, MR-9 测试污染生产 bug 类扩到生产审计)** — ① **触发**: V37.9.115 推送后用户合并前用仓库相对路径验证 governance, 发现 `❌ INV-CRON-004 auto_deploy x2` (用户今天第 3 次遇到, V37.9.106/111 同款). 之前 (含我自己) 都是 `crontab_safe.sh remove` line 54 删了拉倒, 从未找真根因. ② **数据驱动诊断 (原则 #28 + Mac Mini 原子实验铁证)**: 用户那两行 `crontab -l | grep auto_deploy`: line 5 `bash ~/openclaw-model-bridge/auto_deploy.sh` (repo 路径, canonical) + line 54 `bash ~/auto_deploy.sh` (HOME 裸名). **line 54 逐字等于 convergence `_format_cron_line(auto_deploy)` 输出** (唯一产此字符串的源). 原子实验 `bash -c '删 line54 → 确认 0 → 跑 no-dry-run governance --full → 再查'`: **删除后=0 → 跑完 gov=1**, 零歧义证明 no-dry-run governance 重加 line 54. ③ **真根因**: V37.9.58 切关 convergence dry-run 默认 (machine_sync 真激活自愈). `governance_audit_cron.sh` line 70 跑 `governance_checker.py --full` 时**不设** CONVERGENCE_DRY_RUN → jobs_to_crontab spec **real-apply**. auto_deploy registry `entry: auto_deploy.sh` (裸名) 让 `_format_cron_line` 生成 `~/auto_deploy.sh` (HOME) ≠ canonical line 5 `~/openclaw-model-bridge/auto_deploy.sh` (repo) **格式错配** → convergence 判 auto_deploy missing → 07:00 审计每次 real-apply 重加 line 54 → 用户删了下次审计又加 → **无限复发**. (dev mock 判 missing=空 但 Mac Mini 真加, 生产 crontab 有 dev 复现不到的 parser 边界因素, 但修复不依赖搞清这个). ④ **修复 (MR-9 + V37.9.113 扩到生产审计)**: governance_audit_cron.sh line 70 加 `CONVERGENCE_DRY_RUN=1` → 07:00 生产审计**只检测+告警 drift, 不静默 mutate crontab**. 核心原则: 治理"审计"是观察者, 不应静默改被审计的系统状态 (V37.9.113 给测试隔离的同款原则, 扩到生产审计层 — 都是 MR-9 governance-run-mutates-production bug 类). machine_sync 自愈应是 operator 显式刻意动作 (手动跑无此 env 即 real-apply), 不是审计副作用. drift 仍被 governance 检测 (报 ⚠️/❌), 只是不自动 apply. ⑤ **6 新单测** test_v37_9_116.py (TestV37_9_116_GovAuditDryRun 4 源码守卫: full 调用前置 CONVERGENCE_DRY_RUN=1 + env 在 python3 之前 + V37.9.116 marker + 血案引用 + **engine.py --check 不被误加 dry-run 防过度修复** / TestV37_9_116_DryRunEnvSemantics 1 行为级: CONVERGENCE_DRY_RUN=1 真让 `convergence._is_dry_run()` True + 未设默认 False 反例证根因 / TestV37_9_116_ShellSyntax 1 bash -n). **反向验证守卫真有效**: sed 移除 env → test 立即 FAIL, 还原零 violation. ⑥ **验证**: 114→115 suites (+1 test_v37_9_116) / 4057→4063 tests (+6) / 0 fail / 安全 95/100 / README 同步 4063 / VERSION 0.37.9.68 不变 (cron env tweak + 守卫, 无 capability/无新 INV, 镜像 V37.9.113 同款 fix+守卫不立 INV 模式). ⑦ **Mac Mini 待用户**: git fetch+reset 同步. 同步后下次 07:00 governance audit cron 跑 `--full` 走 dry-run, 即使 auto_deploy 格式错配也只告警不重加 line 54. **用户当下删 line 54 即转绿** (line 5 满足 INV-CRON-004), 同步前手动跑 governance 仍会重加 (该命令无 env) — 同步后才根治. ⑧ **元价值 (3 次复发终于钉死 + MR-9 第 3 次演出)**: V37.9.106 (删) → V37.9.111 (删) → V37.9.116 (找根治). MR-9 "governance-run 不应 mutate 生产" bug 类第 3 次演出: V37.9.110 (test_movespeed 写真 incidents) → V37.9.113 (test_convergence 真改 crontab) → V37.9.116 (生产审计 real-apply crontab). 前两次是测试污染, 这次是**生产审计本身**静默改它审计的系统 — 同根 bug 类最深演出. 原则 #28 严格执行: 用户原子实验铁证 (删除后 0 → gov 后 1) 锁死才动手, 没"删了拉倒"第 4 次. ⑨ **残留 follow-up (登记)**: (a) dev/Mac Mini parser 判定差异 (为何 dev mock missing=空 Mac Mini 真加) — 修复后 moot, 但值得查 (b) registry entry auto_deploy.sh 裸名 vs canonical repo 路径格式错配根 (deliberate apply 时仍会加错路径, 但审计 dry-run 后不触发) (c) governance_ontology.yaml ~7 处 abspath check 经 symlink false-fail (V37.9.115 登记). | |
| V37.9.115 | 2026-06-05 | **governance _resolve_project_root realpath 根因修复 — V37.9.114 不完整 (只修 1 个 yaml check, 根在 _PROJECT_ROOT)** — ① **触发**: V37.9.114 合并 (PR#649) 用户同步后用 symlink 路径 `python3 ~/ontology/governance_checker.py --full` 验证 → **仍挂 10+ 分钟**. dev grep 揭示 governance_ontology.yaml 有 10+ 个 check 用 `abspath(__file__)` 算 repo_root + 3 个 `os.walk(".")` + governance_checker.py line 446/477 `glob(_PROJECT_ROOT/**/*.sh, recursive=True)`. V37.9.114 只修了 INV-AUTO-INJECT-001 一个. ② **真正根因**: `governance_checker.py::_resolve_project_root()` (line 46) 用 `os.path.abspath(__file__)`. 经 ~/ontology symlink (V37.9.12.1) 调用时 abspath 不解析 symlink → `_PROJECT_ROOT=$HOME` → `os.chdir($HOME)` (line 97) → 所有 `os.walk(".")` 走家目录 + `glob(_PROJECT_ROOT/**/*.sh, recursive=True)` 跟随 symlink 遍历整个家目录 (venv/.openclaw/.kb) 100% CPU 挂死. ③ **修复**: `_resolve_project_root()` + `_resolve_ontology_dir()` 用 `os.path.realpath(__file__)` 替代 abspath — 解析 symlink → 仓库根. **零回归 (MR-15 部署 layout 安全)**: 仓库相对调用 (cron `cd $REPO_DIR && ontology/...` + dev) 路径无 symlink → realpath==abspath 字节级相同 → _PROJECT_ROOT 不变; 只 symlink 调用下 realpath 才解析到仓库. ④ **行为级验证**: dev 造 tempdir symlink → repo/ontology, 经 symlink 真跑 governance **completed exit=1 (不再挂死, timeout 90s 内完成)**; realpath 解析 _PROJECT_ROOT=仓库 (abspath 误得 symlink 父目录). ⑤ **4 新守卫** test_auto_inject_guard.py 15→19 (TestV37_9_115_ProjectRootRealpathFix): 源码守卫 (_resolve_project_root + _resolve_ontology_dir 用 realpath + marker) + 行为级反向验证 (symlink 解析得仓库根非 symlink 父目录). ⑥ **验证**: 114 suites 不变 / 4053→4057 tests (+4) / 0 fail / governance exit 0 (仓库相对零回归) / 安全 95/100 / VERSION 不变. ⑦ **剩余 (follow-up 非紧急)**: yaml ~7 个 check 独立用 `abspath(__file__)` 算 repo_root, symlink 路径下仍误得 $HOME → 产**假失败 (非 hang)** — 应统一改用 `os.getcwd()` (=_PROJECT_ROOT after chdir). cron 用仓库相对路径不受影响故非紧急. ⑧ **元价值**: V37.9.114→115 是 MR-15 deployment-layout 教训递进闭环 — V37.9.114 修单点, 用户 Mac Mini symlink 路径实测暴露根在 _PROJECT_ROOT, V37.9.115 修根. 候选元规则 `path-resolution-must-use-realpath-under-symlink-deployment`. 操作教训: governance 应始终用仓库相对路径跑 (cron 同款), symlink 路径有 abspath 隐患. |
| V37.9.114 | 2026-06-05 | **governance check glob symlink hang 修复 — INV-AUTO-INJECT-001 repo_root 误解析 $HOME + recursive glob 跟随 symlink 挂死 (12:30 watchdog 告警诊断副产物)** — ① **触发**: 用户贴 12:30 watchdog [SYSTEM_ALERT] (治理审计 fail + ArXiv 28h + 对话精华 error + arxiv/dblp/ai_leaders 429/500). 数据驱动诊断 (原则 #28 零盲改): 5 项已定性 (arxiv 429 + dblp 500 + ai_leaders 429 = 三外部 API 不稳定 / arxiv 28h 是 429 后果 / 对话精华 = 已登记 #29 Reduce 超时). 诊断第 6 项治理审计 fail 时, 我的诊断命令用 `python3 ~/ontology/governance_checker.py --full` (经 V37.9.12.1 $HOME/ontology symlink) 触发 **30 分钟挂死 ×2**. ② **根因 (sample 抓栈 CPU=100% 死循环 + SIGINT traceback 精确定位)**: governance --json 子进程死循环 → traceback 定位 INV-AUTO-INJECT-001 runtime check (line 6968 "inject_*.py/migrate_*.py 必须含 scanner 集成") `glob(repo_root + "/**/inject_*.py", recursive=True)` 卡在 glob `_iterdir`. 双重 bug: (a) `repo_root = dirname(dirname(os.path.abspath(__file__)))` — 经 symlink 调 `~/ontology/governance_checker.py` 时 abspath 不解析 symlink → repo_root 误得 **$HOME** (b) `glob('$HOME/**', recursive=True)` 遍历整个家目录 (venv 109M/.openclaw/.kb) + Python 3.9 `**` 跟随 symlink 遇环无限遍历 100% CPU. dev 从仓库跑 repo_root=仓库 (有界) 故从不暴露. ③ **关键澄清**: 07:00 cron 用 `cd $REPO_DIR && python3 ontology/governance_checker.py --full` (仓库相对) → repo_root=仓库 → 不挂. **那两次 30min hang 是我诊断命令用错路径 (~/ontology symlink) 的副产物, 不是真实 07:00 cron 问题**, 但歪打正着发现真 bug (任何人跑 `python3 ~/ontology/governance_checker.py` 都挂). ④ **修复**: (a) `os.path.realpath(__file__)` 替代 abspath — 解析 symlink → 仓库根 (无论经 symlink 还是仓库相对调用) (b) `os.walk(repo_root, followlinks=False)` 替代 `glob('**', recursive=True)` — 不跟随 symlink 无环风险 + 跳过 .git/venv/.openclaw/.kb 大目录有界 (c) **全 plain for-loop 不用 comprehension** — exec() 作用域陷阱 (V37.3/V37.9.100): 第一版 `[_d for _d in _dns if _d not in _skip_dirs]` comprehension 在 exec'd 代码新作用域看不到 exec-local `_skip_dirs`/`patterns` → `NameError` 💥 (dev 测试当场抓到), 改全 for-loop. ⑤ **5 新守卫单测** test_auto_inject_guard.py 10→15 (TestV37_9_114_GovGlobSymlinkHangFix): 源码守卫 (realpath / 禁 recursive=True 实际调用 逐行剥注释 / os.walk followlinks=False + skip_dirs / marker) + **行为级反向验证** (tempdir 造 symlink 环 td/sub/loop→td, os.walk(followlinks=False) 终止且找到 inject_demo.py, signal.alarm(10) 安全网 fix 失效死循环则 10s 中断 fail). ⑥ **验证**: 114 suites 不变 / 4048→4053 tests (+5) / 0 fail / governance exit 0 (INV-AUTO-INJECT-001 ✅ 修复后通过) / 安全 95/100 / VERSION 0.37.9.68 不变 (governance check bug 修复). ⑦ **Mac Mini 待用户**: git fetch+reset 同步 (修复后 `python3 ~/ontology/governance_checker.py` 不再挂). **真实 07:00 "治理审计 fail" 仍需正确路径诊断** (`cd ~/openclaw-model-bridge && python3 ontology/governance_checker.py --full \| grep ❌💥`), 独立于本 glob 修复 (可能 stale 代码 / 真不变式失败). ⑧ **元价值**: (a) MR-15 deployment-layout 新形态: symlink 让 `abspath(__file__)` 在不同调用路径解析出不同 repo_root, realpath 才稳健 — 候选元规则 `path-resolution-must-use-realpath-under-symlink-deployment` (b) exec 作用域陷阱第 N 次演出, dev 测试当场抓 NameError 防又一个 silent governance 💥 (c) 数据驱动诊断: sample (CPU 100%) → SIGINT traceback (精确行) → 多轮取证零盲改, 同时识别"我的诊断命令本身是 hang 源"避免误改 07:00 cron. |
| V37.9.113 | 2026-06-05 | **test_convergence 测试隔离 — governance-runtime-tests-must-isolate-production-state (MR-9, follow-up #27 HIGH 专门 session, V37.9.110 测试污染生产同 bug 类闭环)** — ① **触发/地雷确认**: V37.9.111-hotfix 登记 follow-up #27 HIGH — test_convergence.py 真 spec 测试无 CONVERGENCE_DRY_RUN 守卫. 今天 governance 独立审计实锤 `⚠️ [jobs_to_crontab] apply[real]=40` — 真 spec 测试在 real-apply 路径是活的. 根因: governance INV-CONVERGENCE-CRON-001 的 runtime python_assert `subprocess.run([python, test_convergence.py], cwd=repo_root)` 跑整个文件 (含调真 jobs_to_crontab/kb_sources_to_index machine_sync spec 的测试), 不传 CONVERGENCE_DRY_RUN. V37.9.58 切关后 `_is_dry_run()` 默认 False = real apply → Mac Mini 上 governance audit cron (07:00) 跑这些测试会真调 crontab_safe.sh add 改 crontab / 真跑 kb_embed.py (与 V37.9.110 测试污染 incidents.jsonl 同 MR-9 bug 类, 那次造成真实 watchdog 告警). 当前 missing=0 无活跃污染但 latent landmine. ② **AST 完整盘点**: 5 类调危险真 spec (jobs_to_crontab/kb_sources_to_index machine_sync 真 apply) — TestRealJobsToCrontabSpec / TestVerifyConvergenceMachineSyncIntegration (已有 dry-run setUp ✅) / TestV37958DryRunActivation 2 个 e2e (故意 pop env 测默认 real apply, 核心地雷) / TestVerifyKbSourcesToIndexIntegration / TestKbSourcesToIndexCommandRuntime. 2 个 services 类 dry_run_default=true 已安全 (V37.9.97). real-apply 行为已被 mock 覆盖 (TestApplyMachineSyncReal mock subprocess + TestApplyKbEmbedIncremental) → 真 spec 测试不需真 apply 即可保覆盖. ③ **隔离修复 (4 类加 setUp + 2 e2e 重写)**: (a) TestRealJobsToCrontabSpec + TestVerifyKbSourcesToIndexIntegration + TestKbSourcesToIndexCommandRuntime 加 setUp/tearDown `CONVERGENCE_DRY_RUN=1` 强制 dry-run apply, TestRealJobsToCrontabSpec 断言从 real-apply (apply_dry_run=False) 重写为 dry-run (镜像 TestVerifyConvergenceMachineSyncIntegration 已证 dry-run 断言). (b) TestV37958 的 2 个 e2e (故意 pop env 测默认 real apply) 改用纯函数 `_resolve_dry_run_for_spec(spec)` 验证 flip (它正是 V37.9.97 起 verify_convergence 里决定 apply_dry_run 的函数) — 零 apply 副作用不调 verify_convergence. ④ **Layer B belt-and-suspenders**: governance check `subprocess.run([python, test_convergence.py])` 加 `env={**os.environ, "CONVERGENCE_DRY_RUN": "1"}` — governance 跑全文默认 dry-run (与测试类 setUp 双层防护). 双环境验证 (env=1 + env 未设) 各 318 全过. ⑤ **TestV37_9_113_ConvergenceTestIsolation 守卫类 (6 单测, framework 化 #26)**: (1) **AST 反回归守卫** 扫每个 verify_convergence(danger_spec) 无 specs= 调用必在有 dry-run setUp 的类里 (未来新增未隔离立即抓) (2) **行为级正向证明** dry-run 模式 `_apply_jobs_to_crontab_per_entry` 不调 fake crontab_safe.sh (sentinel 不存在, continue 在 subprocess 之前) (3) **行为级负对照** real 模式确实调 (sentinel 存在, 证明隔离有意义非测试桩失效, 镜像 V37.9.110 反向验证) (4) Layer B env 源码守卫 (5) AST 守卫 2 个 resolver e2e 不调 verify_convergence (6) marker. **反向验证已确认守卫真有效**: sabotage TestRealJobsToCrontabSpec setUp (`"1"`→`"0"`) → AST 守卫立即抓 `TestRealJobsToCrontabSpec:L507`, 还原零 violation. ⑥ **验证**: 114 suites 不变 / 4042→4048 tests (+6 守卫类) / 0 fail / governance exit 0 (test_convergence 全套 check 现 Layer B env 跑不真 apply) / 安全 95/100 / README 徽章同步 4048 / VERSION 0.37.9.68 不变 (测试隔离 + governance check tweak, 无 capability/无新 INV, 镜像 V37.9.110 同款 fix+守卫类不立 INV 模式). ⑦ **Mac Mini 待用户**: git fetch+reset 同步. 下次 governance audit cron 07:00 跑 INV-CONVERGENCE-CRON-001 的 test_convergence 全套 check, 即使有 crontab/kb_index drift 也走 dry-run 不真改 crontab/不真跑 kb_embed (地雷拆除). ⑧ **下次候选**: (a) **MR-22 + generic MRD scanner (follow-up #26 升级)**: 立元规则 governance-runtime-tests-must-isolate-production-state + MRD scanner 扫所有 governance runtime python_assert 跑的测试 (INV-RETRY-001 test_movespeed / INV-CONVERGENCE test_convergence 等) 是否写生产 state — V37.9.110+V37.9.113 共 2 实例已达立元规则门槛, generic scanner 跨多测试文件是专门 session (b) kb_harvest Reduce 超时 (#29) (c) 日期门控 ~6/8+. ⑨ **元价值 (MR-9 测试污染生产 bug 类第 2 次演出 + V37.9.110 follow-up 兑现)**: V37.9.110 (test_movespeed 写真 incidents.jsonl 灌爆假告警) 第 1 次 → V37.9.113 (test_convergence 真改 crontab/真跑 kb_embed) 第 2 次, 同 MR-9 bug 类不同表现. 本次未等真告警 (V37.9.110 是收工后 watchdog 真告警驱动) 而是主动拆雷 — V37.9.111-hotfix 登记 + 今天 governance apply[real]=40 实锤驱动. 行为级正/负对照 + AST 反回归守卫让此 bug 类从"靠记忆"升级为"机器化检测". |
| V37.9.112 | 2026-06-05 | **ai_leaders_bsky 接入 Opportunity Radar #2 — 大神实时短观点成为发现机会点一等信号源 (V37.9.110/111 Bluesky 上线自然收口, 用户选)** — ① **触发**: 周五日期门控候选未到 (INV-OBSERVER/services flip ~6/8 / 源可信度 ~6/9 / OpenClaw ~6/15), 用户从 3 个纯 dev 方向 (test_convergence 隔离 / Bluesky Radar #2 / kb_harvest Reduce 超时) 选 Bluesky 接入 Radar #2 (follow-up #112). V37.9.111-hotfix 已验证 ai_leaders_bsky 首跑产真数据 (7/10 handle 活 + 17 帖全解析 + 🎚️ 高对齐 1) → 数据已产可 wire (避免未验证源 0 picks)。② **集成 (仅 1 处显式改 + 3 消费方自动 + 2 docstring 修)**: `top_alignment_picker.py` ALIGNED_SOURCES 9→10 加 ai_leaders_bsky (**社媒档 priority 6** 实时短帖同 ai_leaders_x tweet 类 > 博客 5; cache_paths dev `jobs/ai_leaders_bsky/cache` + Mac Mini `~/.openclaw/jobs/ai_leaders_bsky/cache` 双 layout V37.9.57-hotfix 同款)。**#2 项目高对齐** 显式接入; **#1 跨源共振** (cross_source_signal_aggregator 扫所有 KB notes 源无关) + **#3 趋势加速** (kb_trend KB 关键词) 经 ai-leaders-bsky KB notes 自动含无需改 (焦点已确认)。③ **3 消费方自动生效零改**: kb_dream.sh Phase 1.5 (ALIGNMENT_PICKER) / kb_radar_collect.py (tap.pick_top_aligned) / kb_evening_collect.py (collect_top_alignment_picks_for_evening) 全部经 `pick_top_aligned()` 迭代 ALIGNED_SOURCES — grep 确认无消费方硬编码 source 列表 (picker 单一真理源 MR-8) → 加 1 条自动 flow 到 Top 5 机会点雷达。④ **下游 100% 复用 blogs 管道**: ai_leaders_bsky llm_results.jsonl 写 `{idx/content/failed/fail_reason}` 与 ai_leaders_blogs **逐字一致** + 启动 `> RESULTS_FILE` 截断 (cache 总反映最近 run 无 stale 累积) → picker scan_source_results 零改 (MR-8 零重造)。⑤ **smoke test 验证**: 构造 ai_leaders_bsky ⭐5 alignment pick → pick_top_aligned 正确产 `- ⭐⭐⭐⭐⭐ [大神实时] LeCun 论世界模型 ... / 直接对应 control plane 终极目标` 进 Top 5 block, ⭐3 被 min_stars=4 阈值过滤。⑥ **2 新单测** test_top_alignment_picker.py 68→69: test_10_aligned_sources_registered (9→10 含 ai_leaders_bsky) + test_ai_leaders_bsky_is_social_tier_priority_6 (社媒档 prio 6 + ai_leaders_bsky/cache + Mac Mini layout 守卫, 反向验证 sabotage priority → fail). **3 docstring 修复漂移**: picker header "8 ALIGNED sources" → 10 (补漏 V37.9.109 ai_leaders_blogs 未更新 + 加 ai_leaders_bsky 全列表) + kb_evening_collect "9 ALIGNED source" → 10 + 类 docstring 9→10。⑦ **验证**: 114 suites 不变 (无新 suite, top_alignment_picker + ai_leaders_bsky 已在 full_regression) / 4041→4042 tests (+1) / 0 fail / governance 804 checks pass / 安全 95/100 / README 徽章同步 4042 / VERSION 0.37.9.68 不变 (source 配置扩展非 capability)。⑧ **Mac Mini 待用户**: git fetch+reset 同步 (top_alignment_picker.py 走 FILE_MAP 部署到 $HOME)。下次 kb_radar 06:00 / kb_dream 03:00 / kb_evening 22:00 cron 触发时, ai_leaders_bsky 的 ⭐≥4 大神实时短观点 (V37.9.111 首跑高对齐 1 实测) 进 Top 5 机会点雷达 + 跨源共振 + 趋势加速。⑨ **元价值 (ai_leaders 三段式机会点引擎全维度闭环)**: X (V27 起, 现 429+冻结退化产 ~0) → 博客长文 (V37.9.108 收集 → Radar #2 V37.9.109 高对齐 Top 5) → **Bluesky 实时短帖 (V37.9.110/111 收集 → Radar #2 V37.9.112)**。用户"收集大神不同意见 + 结合项目发现机会点"目标从单一退化渠道升级为"长文深度 + 实时短帖"双维度互补且都接入机会点雷达。复用 blogs 管道零重造轮子 (MR-8), 仅 ALIGNED_SOURCES 1 条目改 + 镜像 V37.9.109 同款模式。⑩ **下次候选**: (a) **test_convergence 隔离** (follow-up #27 HIGH 专门 session: ~6 处真 spec verify_convergence 无 dry-run 守卫, Mac Mini real apply 风险, MR-9 测试污染生产同 V37.9.110 bug 类) (b) kb_harvest_chat Reduce 超时 (#29: 大对话日 9 chunks Reduce 失败, chunked/retry) (c) 日期门控 ~6/8+ (INV-OBSERVER/services flip/源可信度 INV) (d) 补可达 contrarian handle (fchollet 替代) + Bluesky app-password 认证读 login-required 账号。 |
| V37.9.111-hotfix | 2026-06-05 | **Bluesky 首跑 handle 漂移修复 + 生产告警诊断闭环 (Mac Mini 首跑验证, 用户合并 PR #645 后)** — ① **🦋 首跑成功**: 7/10 handle 活 → 17 帖 LLM 全解析 (degraded 0) → 推 4 窗口 (27335 字) → KB 写入 + 🎚️ 高对齐 1 条 (Opportunity Radar #2 评分生效)。端到端管道工作。② **3 个 HTTP 400 = "Profile not found" (handle 漂移非隐私, curl body 实证)**: 高粉大神迁自定义域名释放 .bsky.social → 旧 handle 404。修法 (searchActors 端点查现 handle): `ylecun`→**`yann-lecun.bsky.social`** (验证可用) / `timnitgebru`→**`timnitgebru.blacksky.app`** (迁 blacksky 社区域名) / `fchollet` 停用 (searchActors 搜不到 François Chollet 现 handle) → **剪枝**。10→9 账号, contrarian 覆盖仍强 (yann-lecun/melaniemitchell/rao2z/randomwalker/garymarcus/emilymbender/timnitgebru)。脚本注释加 handle 漂移教训 + searchActors 维护工具。test_ai_leaders_bsky +1 守卫 (旧错 handle 移除防回退 + 现 handle 在 + Chollet 剪枝), _CONTRARIAN_HANDLES 更新。③ **生产告警诊断 (数据驱动, 原则 #28 不盲改)**: 用户贴 07:00 治理 [SYSTEM_ALERT] 3 失败 + 08:30 watchdog。逐项铁证: **INV-MOVESPEED-TCC-001** = caller.sh 测试桩污染 (procs 显示 test_movespeed_rsync_helper.py + env path /tmp/rsync_helper_fail_*, 最新 23:03 6/4 同步前) → 用户 grep -v 清理 + main V37.9.110 隔离修复生效 → **绿** (caller.sh=0); **INV-ROUTER-001** = 07:00 stale 代码 (45/45 同步后自愈, V37.9.105 同款) → **绿**; **2 convergence 💥** = transient (test_convergence 单跑 318/318 OK, 治理重跑 720/721 无 💥) → 自愈; **INV-CRON-004** = auto_deploy.sh **双行** (repo 路径 + HOME 路径都每 2min, V37.9.106 同款复发, endswith matcher 检测同脚本双调用) → 用户 `crontab_safe.sh remove 'bash ~/auto_deploy.sh >> '` 删 HOME 行 → 721/721。④ **关键发现 (登记 follow-up, 不捆本 hotfix)**: test_convergence.py ~10 处 `verify_convergence("jobs_to_crontab"/"kb_sources_to_index")` **无 CONVERGENCE_DRY_RUN 守卫** → Mac Mini real apply 真改 crontab / 真跑 kb_embed (V37.9.110 test 污染生产同 bug 类, MR-9, V37.9.110 登记的 governance-runtime-tests-must-isolate-production-state follow-up)。当前 missing=0 无活跃污染但是 latent landmine → 专门 session 隔离 (多处 V37.9.58 real-apply 断言重写, 风险高值得聚焦)。⑤ **验证**: 114 suites 不变 / 4040→4041 tests (+1 hotfix 守卫) / 0 fail / 安全 95/100 / VERSION 0.37.9.68 不变 (hotfix 不 bump)。⑥ **下次候选**: (a) **test_convergence 隔离** (专门 session, V37.9.110 follow-up 兑现 + 评估 MRD scanner framework 化此 bug 类) (b) auto_deploy 双行**复发根因** (V37.9.106 删过又回, 查 crontab 重建/backup 恢复源, 或加 framework 防重复守卫) (c) kb_harvest_chat LLM Reduce 超时 (37.7 万字 9 chunks Reduce 失败, chunked Reduce 或 retry) (d) V37.9.112 ai_leaders_bsky 接入 Opportunity Radar #2 (现已真产数据可 wire) (e) 补可达 contrarian handle (fchollet 替代) + 评估 Bluesky app-password 认证读 login-required 账号。⑦ **元价值**: 单 session 从 Bluesky 接入 → 首跑验证 → handle 漂移修复 → 三告警数据驱动诊断 (推翻"全是 bug"初判: MOVESPEED/ROUTER/convergence 都自愈或清理, 只 INV-CRON-004 真需手动 + 1 个 latent test 污染 follow-up) 完整闭环。原则 #28 严格执行: 每个告警先取证定性再动手, 零盲改/盲清。原则 #33+反馈 #1 兑现: dev 403 不定论, Mac Mini curl body 实证 handle 漂移。 |
| V37.9.111 | 2026-06-05 | **ai_leaders 加 Bluesky 实时短观点维度 — AI 大神不同意见的实时渠道 (用户选, #32 反馈"更多大神观点"延续 + ai_leaders 三渠道闭环)** — ① **触发**: 周五开工多数日期门控候选未到 (INV-OBSERVER/services flip ~6/8 / 源可信度 INV ~6/9 / OpenClaw ~6/15), 用户从 3 个纯 dev 方向 (Ontology chunk 3b / Bluesky / Ontology chunk 2) 选 Bluesky 实时短观点接入。直接服务 #32 反馈"更多 AI 大神不同观点", ai_leaders 线自然延伸 (V37.9.108 blogs 长文 → V37.9.109 Opportunity Radar wiring → V37.9.111 Bluesky 实时短观点)。② **WebSearch 双核实 (原则 #33 + 反馈 #1)**: (a) Bluesky 公开 AppView `getAuthorFeed` JSON API **无需认证 + 带缓存** (docs.bsky.app 官方确认 public.api.bsky.app) (b) 30 万学者 2023-2025 迁入 (arXiv 2505.24801《Why Academics Are Leaving Twitter for Bluesky》+ Science.org, 2 万+ 有影响力科学家, "像老 Twitter")。WebFetch API 端点 dev 返回 403 (sandbox 网络受限, 同 chaspark/V37.9.52) **不代表 API 死** → Mac Mini 验证。③ **设计决策 (MR-8 复用 + 原则 #28 最小修复)**: 新 job `jobs/ai_leaders_bsky/run_ai_leaders_bsky.sh` (17:00 HKT 1x/天, 捕获前一整个美国白天的帖子, 避开 16:30 watchdog/13:30 blogs)。**仅抓取层**从 RSS XML 换为 getAuthorFeed JSON, **下游 100% 复用 ai_leaders_blogs/rss_blogs 已验证管道** (call_llm_single_with_retry 5/10/20s + parse_6field_output + project_alignment_scorer rule_check + hallucination_guards LEVEL_4 + 双通道「🦋 AI 大神实时观点」+ KB「ai-leaders-bsky」+ 多窗口分片 + per-account FAIL-OPEN + fail-fast + movespeed_rsync_helper)。④ **抓取层 (Bluesky-specific)**: `filter=posts_no_replies` + skip `reasonRepost` (只要原创) + MIN_POST_CHARS=50 过短过滤 + MAX_PER_ACCOUNT=3 + `at://did/app.bsky.feed.post/rkey` → `bsky.app/profile/{handle}/post/{rkey}` web URL + 外链 embed 捕获 (大神分享论文时给 LLM 上下文) + seen_urls dedup。**prompt 适配短帖** (V37.9.40 ai_leaders_x 过度分析教训): "Bluesky 帖子通常简短, 评级和洞察长度应与帖子实际信息量匹配, 单句观点给 ⭐⭐⭐ + 简短洞察, 不要为短帖编造长篇分析"。⑤ **10 大神 contrarian 为主** (用户核心诉求"不同意见"): 8 confirmed via WebSearch (ylecun 世界模型/反LLM-AGI / fchollet ARC-AGI/反scale-is-all / melaniemitchell AI理解怀疑/复杂系统 / rao2z LLM推理规划怀疑 / randomwalker 炒作祛魅 / timnitgebru 伦理批判 / mmitchell HF治理 / howard.fm 开源派) + Gary Marcus/Emily Bender 候选, 跨 7+ 流派。⑥ **dev parser 行为验证** (Bluesky JSON 确定性无网络, 可测): 真跑抽取 parser 喂 fixture — skip 转发✓ + skip 过短✓ + URI→URL✓ + 外链捕获✓ + dedup✓ + 损坏 JSON FAIL-OPEN exit 0✓。⑦ **3 个 MR-8 漂移守卫合理修** (V37.9.108 同款): source_credibility 15→16 (ai_leaders_bsky 社媒 tier, Bluesky 短帖同 X 推文; label 与 registry kb_source_label 精确匹配) / test_movespeed EXPECTED_RSYNC_SITES 23→24 (用 helper 合规) + governance narrative 同步 / docs/config.md gen_jobs_doc --fix。⑧ **40 新单测** test_ai_leaders_bsky.py 9 类 (脚本存在+bash -n / 账号≥8+well-formed+含 contrarian+无重复 handle / 抓取层 public.api.bsky.app+getAuthorFeed+posts_no_replies+skip repost+MIN_POST_CHARS+URI→URL / 身份🦋无 blogs/rss 残留 / 复用共享基础设施 / FAIL-OPEN per-account+fail-fast+无占位符 / registry+enabled+17:00+FILE_MAP / source_credibility 社媒 tier+label 匹配 / **runtime parser 行为 5 测真跑 fixture**)。⑨ **验证**: 113→114 suites (+1) / 4000→4040 tests (+40, 在 main V37.9.110 incidents.jsonl 修复的 4000 基线上) / 0 fail / governance exit 0 所有不变式成立 + 805 checks / 安全 95/100 / VERSION 0.37.9.68 不变 (source 配置扩展非 capability)。⑩ **Mac Mini 待用户**: (a) git fetch+reset 同步 + auto_deploy 2min 轮询同步 run_ai_leaders_bsky.sh 到 ~/.openclaw/jobs/ (b) **注册 cron** `bash ~/crontab_safe.sh add '0 17 * * * bash -lc "bash ~/.openclaw/jobs/ai_leaders_bsky/run_ai_leaders_bsky.sh >> ~/.openclaw/logs/jobs/ai_leaders_bsky.log 2>&1"'` (c) 17:00 cron 首跑或手动触发 **验证 10 handle 可达性** (log `WARN: X Bluesky 抓取失败，跳过` 死链剪枝, 尤其 howard.fm 自定义域名 + garymarcus/emilymbender 候选待验) + 收到「🦋 AI 大神实时观点」推送验证短帖 6 字段分析 + 🎚️ 项目对齐评分。⑪ **下次候选 (follow-up)**: (a) Mac Mini handle 验证后剪死链 + 补可达大神 handle (b) **V37.9.112 ai_leaders_bsky 接入 Opportunity Radar #2** (top_alignment_picker ALIGNED_SOURCES 9→10, 镜像 V37.9.109 blogs 模式 — 但需先 Mac Mini 验证 handle 可达产真数据再 wire, 避免未验证源 0 picks; 注意今天的 KB notes 已自动喂 Radar #1 跨源 + #3 趋势, 仅 #2 显式 wiring 是 follow-up) (c) 2x/天评估 (实时短观点频率, 若有价值) (d) 真停用退化 ai_leaders_x (同步 6 依赖)。⑫ **元价值**: ai_leaders 三渠道闭环 — X (V27, 现 429+冻结退化) → 博客长文 (V37.9.108, 深度) → **Bluesky 实时短观点 (V37.9.111, 实时维度)**。用户"收集大神不同意见"目标从单一退化渠道升级为"长文深度 + 实时短帖"双维度互补。复用 blogs 管道零重造轮子 (MR-8), 仅抓取层 ~80 行 Bluesky-specific 代码。原则 #33+反馈 #1 兑现: dev 403 不定论, Mac Mini 验证 handle 可达性。 |
| V37.9.110 | 2026-06-04 | **测试污染生产 incidents.jsonl 血案 — 假 CORE governance fail + 假 MOVESPEED 告警根因修复 (收工后 16:30 watchdog 真告警驱动, MR-9 + MR-7 治理自观察最深演出)** — ① **触发**: 收工后 16:30 watchdog [SYSTEM_ALERT] 报 🔴 CORE「治理审计 fail」+「MOVESPEED 24h 72 次 rsync 失败」。用户贴 `movespeed_incident_analyzer --window 24h` 输出。② **数据驱动诊断 (原则 #26/#28, dev 看不到 Mac Mini runtime 故给诊断命令由数据定论)**: analyzer 铁证 **72/72 caller="caller.sh"**(测试桩名, 真 cron 是 run_X.sh 永不含) + 时间窗 6/4 07:00-11:38 HKT 匹配今天 governance/full_regression 跑测试时段 → **测试污染真实 ~/.kb/movespeed_incidents.jsonl**, 非真 SSD 故障。③ **完整因果链**: governance INV-RETRY-001 runtime check 跑 `test_movespeed_rsync_helper.py` → 15 个失败路径测试 + `_run_helper` 零隔离 (`MOVESPEED_INCIDENT_FILE` 设置 **0 次**) → helper 失败调 incident_capture 写真实 ~/.kb (caller=测试桩) → 灌爆 INV-MOVESPEED-TCC-001 (24h>2) 假 fail + watchdog (24h≥5) 假告警。**每次 audit (07:00 daily + 今天手动多次) 重新污染 → 永不"老化转绿"** (推翻 V37.9.106 收工"待 24h 转绿"假设) + **腐蚀真实 MOVESPEED 取证** (V37.9.106 的"36 incidents"分析可能部分同款污染, 待重评)。④ **MR-9 类 (测试写生产状态) + MR-7 最深演出**: 治理审计运行的测试污染了治理审计检查的数据 (audit 自伤)。⑤ **修复**: `_run_helper` `env.setdefault("MOVESPEED_INCIDENT_FILE", _ISOLATED_INCIDENT_FILE)` (/tmp throwaway 隔离全部 _run_helper 调用) + 2 个绕过 _run_helper 的 inline subprocess env (test_caller_with_set_e + TestCaptureHelperWired) 加隔离。⑥ **4 新守卫 TestV37_9_110_IncidentFileIsolation**: gettempdir 非 ~/.kb + `_run_helper` 函数体含 setdefault + 2 inline 函数体含隔离 + **行为级反向验证 (跑失败 helper 后真实 ~/.kb/movespeed_incidents.jsonl 不增长, Mac Mini 真激活则隔离移除立即 fail)**。⑦ **反向验证抓到我的守卫缺陷 (reverse-validation 真价值)**: 第一版守卫 `assertIn(literal, self.src)` 自引用陷阱 (self.src 含守卫自己的断言串) → sabotage 后仍过 → 改 **inspect.getsource() 只查目标函数体** → sabotage (setdefault key 改坏) 真 fail, 还原 39/39 过。⑧ **验证**: 113 suites 不变 / 3996→4000 tests (+4) / 0 fail / governance 87 inv 805 checks (INV-RETRY-001 跑此测试现已隔离不污染) / 安全 95 / README 同步 4000 / VERSION 0.37.9.68 不变。⑨ **Mac Mini 即时补救 (清现存 72 条污染)**: `cp ~/.kb/movespeed_incidents.jsonl{,.bak}; grep -v 'caller\.sh' ~/.kb/movespeed_incidents.jsonl.bak > ~/.kb/movespeed_incidents.jsonl` → INV-MOVESPEED-TCC-001 + MOVESPEED 告警立即转绿 (或 git 同步修复后等 24h 老化, 因新污染已止)。⑩ **下次候选 (登记)**: MRD scanner `governance-runtime-tests-must-isolate-production-state` (扫所有 governance runtime check 跑的测试是否写生产 state 文件, framework 化此 bug 类) + 重评 V37.9.106 MOVESPEED "36 incidents" 数据真实性 (剔除 caller.sh 污染后看真 TM 争用还剩多少)。⑪ **元价值**: 收工后真 watchdog 告警驱动发现真 bug — 不是噪声 (我先初判"大多外部噪声"但 analyzer 数据揭示 CORE+MOVESPEED 是真 bug 同源)。MR-10 understand-before-fix: 先 analyzer 取证定性 (caller.sh = 测试桩) 再动手, 没盲清/盲修。MR-7 治理自观察最深演出: governance audit 运行的测试腐蚀 governance audit 审计的数据, 自我永续假告警。 |
| V37.9.109 | 2026-06-04 | **ai_leaders_blogs 接入 Opportunity Radar #2 — 大神观点成为发现机会点一等信号源 (V37.9.108 自然收口, 用户选)** — ① **触发**: V37.9.108 ai_leaders_blogs 上线后用户选"接入 Opportunity Radar"(放大今天关心的"发现机会点")。② **集成 (仅 1 处显式改 + 2 处自动)**: `top_alignment_picker.py` ALIGNED_SOURCES 8→9, 加 ai_leaders_blogs (博客档 priority 5 同 rss_blogs, > tweet 类 6; cache_paths dev+Mac Mini 双 layout V37.9.57-hotfix 同款)。**#2 项目高对齐** 显式接入; **#1 跨源共振** (cross_source_signal_aggregator 扫所有 KB notes 源无关) + **#3 趋势加速** (kb_trend KB 关键词) 经 ai-leaders-blogs KB notes 自动含, 无需改。③ **3 消费方自动生效**: kb_radar/kb_dream/kb_evening 全部经 `pick_top_aligned()` 迭代 ALIGNED_SOURCES → 加 1 条自动 flow 到 Top 5 机会点雷达, 零消费方改。④ **每源 cron 启动 `> llm_results.jsonl` 截断** → cache 总反映最近 run 无 stale 累积; ai_leaders_x 退化产 0 → cache 空 scan 返回 [] 无误贡献 (安全)。⑤ **smoke test 验证**: 构造 ai_leaders_blogs ⭐5 alignment pick → pick_top_aligned 正确产出 `- ⭐⭐⭐⭐⭐ [大神观点] ... / 直接对应 control plane` 进 Top 5 block。⑥ **2 新单测** test_top_alignment_picker.py 67→68: test_9_aligned_sources_registered (8→9 含 ai_leaders_blogs) + test_ai_leaders_blogs_is_blog_tier_priority_5 (priority 5 + Mac Mini layout 守卫)。kb_evening docstring 8→9。⑦ **验证**: 113 suites 不变 / 3995→3996 tests (+1) / 0 fail / governance 87 inv 805 checks / 安全 95 / README 同步 3996 / VERSION 0.37.9.68 不变 (source 配置扩展)。⑧ **Mac Mini 待用户**: git fetch+reset 同步 (top_alignment_picker.py 走 FILE_MAP 部署到 $HOME)。下次 kb_radar 06:00 / kb_dream 03:00 / kb_evening 22:00 cron 触发时, ai_leaders_blogs 的 ⭐≥4 学者观点 (实测每轮 25-27 条) 进 Top 5 机会点雷达 + 跨源共振 + 趋势加速。⑨ **元价值**: ai_leaders 从 X (429 退化) → 博客长文 (V37.9.108) → 机会点引擎信号源 (V37.9.109) 完整闭环。用户"收集大神不同意见 + 结合项目发现机会点"目标三段式兑现: 收集 (blog RSS) → 深度分析 (LLM 6 字段) → 机会点雷达 (Opportunity Radar #2 高对齐 Top 5)。下次候选: Bluesky 实时短观点 / 真停用 ai_leaders_x / Ontology chunk 2 import 去泛化。 |
| V37.9.108 | 2026-06-04 | **ai_leaders X→博客/Substack RSS 转向 — 收集 AI 大神长文观点 (用户主任务: X Syndication 429+冻结退化的非 X 渠道解法)** — ① **触发**: 用户主任务"ai_leaders 因 429 很多不可用, 能否通过其他途径解决? 目的: 收集 AI 领域顶尖学者专家的不同意见 + 结合项目深度分析发现机会点"。② **V37.9.102 评估盲区**: 该报告只评估"保留 X 渠道"的替代 (TwitterAPI.io/官方API/Nitter/RSSHub 全是 X 衍生, 推荐付费 TwitterAPI.io ~$2/月)。但用户真实目标是"AI 学者意见"——意见不只活在 X 上。③ **WebSearch 2026 调研确认非 X 渠道真实可用**: (a) Bluesky 免费无认证公开 API (public.api.bsky.app/xrpc/...getAuthorFeed), 学术界大规模迁入 (arXiv 2505.24801《Why Academics Are Leaving Twitter for Bluesky》+ Science.org, ~40k 科学家, 18% 学者 2023→2025 迁移) (b) AI 大神在 blog/Substack 发长文观点 (Gary Marcus/Jack Clark Import AI/Sebastian Raschka/Nathan Lambert/AI Snake Oil), 长文远优于 280 字推文更适合深度分析。④ **用户决策 🥇 博客/Substack RSS 转向**。⑤ **实施**: 新 job `jobs/ai_leaders_blogs/run_ai_leaders_blogs.sh` (13:30 HKT 1x/天), 紧贴 rss_blogs 已验证管道 (RSS + LLM 6 字段 + 🎚️ 项目对齐评分 project_alignment_scorer + 反幻觉 hallucination_guards LEVEL_4 + 双通道 + KB + 多窗口 + FAIL-OPEN), 推送 framing「🧠 AI 大神观点」, prompt 适配"学者立场/不同意见"。feed 12 个策展大神 (不与 rss_blogs 4 源重叠, 偏重 contrarian: Marcus on AI/AI Snake Oil/Import AI/Ahead of AI/Interconnects/Eugene Yan/Karpathy/The Gradient/fast.ai/HF/Anthropic), 每 feed FAIL-OPEN。⑥ **原则 #33 + 反馈 #1 (chaspark 教训)**: dev sandbox 网络对外 RSS 普遍 403 (CDN bot 拦 + 受限网络), **不代表 feed 死** — feed 可达性必须 Mac Mini 首跑验证, 死链 log WARN+跳过 (FAIL-OPEN), 之后剪枝。⑦ **ai_leaders_x 处理 (原则 #28 最小修复)**: 初版禁用触发 6 个依赖级联失败 (kb_review/source_credibility/INV-REVIEW-001/INV-BACKUP-001/config/wa 期望此源), 回退保持 enabled + 注释标记被 ai_leaders_blogs 取代, 真停用留 follow-up (需同步更新 6 依赖 + Mac Mini crontab remove)。⑧ **新内容源触发 3 个 MR-8 漂移守卫 (守卫正确工作, 合理修复)**: source_credibility +ai_leaders_blogs (博客 tier, 14→15 源 id+label 双匹配) / INV-BACKUP-001 EXPECTED_RSYNC_SITES +ai_leaders_blogs (用 movespeed_rsync_helper 合规) / docs/config.md gen_jobs_doc --fix 同步。⑨ **27 新单测** test_ai_leaders_blogs.py 8 类 (脚本存在+可执行+bash -n / feed 结构 ≥10+well-formed+含 contrarian+不重叠 rss_blogs 4 源+反向 rss_blogs 未动 / 身份切换 🧠 framing 无 📖/rss 残留 / 复用共享基础设施 hallucination_guards+project_alignment_scorer+parse_6field+call_llm_retry+notify+kb_append+rsync_helper / FAIL-OPEN per-feed + fail-fast exit 1 + 无占位符 / registry 注册+enabled+ai_leaders_x 取代注释 + FILE_MAP + Mac Mini 验证注释)。⑩ **验证**: 112→113 suites (+1) / 3968→3995 tests (+27) / 0 fail / governance 87 inv 805 checks / 安全 95/100 / README 同步 3995 / VERSION 0.37.9.68 不变 (source 配置扩展, 非 capability 升级)。⑪ **Mac Mini 待用户**: (a) git fetch+reset 同步 + auto_deploy 2min 轮询同步 ai_leaders_blogs.sh 到 ~/.openclaw/jobs/ (b) 13:30 cron 首跑或手动 `bash ~/.openclaw/jobs/ai_leaders_blogs/run_ai_leaders_blogs.sh` **验证 feed 可达性** (log `WARN: X RSS 抓取失败，跳过` 的死链剪枝, 尤其 Anthropic/Karpathy URL 待验) (c) 收到「🧠 AI 大神观点」推送验证长文深度分析 + 🎚️ 项目对齐评分。⑫ **下次候选**: (a) Mac Mini feed 验证后剪死链 + 补可达大神 feed (b) V37.9.109+ Bluesky 免费 API 加实时短观点维度 (学者已迁入) (c) 验证稳定后真停用 ai_leaders_x (同步 6 依赖 + crontab remove) (d) ai_leaders_blogs 接入 Opportunity Radar 三件套 (跨源共振 #1 / 项目对齐 #2 / 趋势加速 #3) 作为高质量信号源。⑬ **元价值**: V37.9.102 评估盲区 (只看 X 内替代→付费) 经用户目标 reframe (意见≠X) 突破——非 X 博客长文是免费+可靠+更适合深度分析的渠道, 复用 rss_blogs 管道零重造轮子 (MR-8)。原则 #28 兑现: 禁用 ai_leaders_x 级联 6 失败后回退保留, 最小修复只 ADD 新源。原则 #33+反馈 #1 兑现: dev 403 不定论, Mac Mini 验证。 |
| V37.9.107 | 2026-06-04 | **ontology-engine 包化 chunk 3a — convergence config-injection (chunk-4 demo 暴露的真 bug 闭环, 终极目标 pip install ontology-engine 推进)** — ① **触发**: 周四 6/4 多数候选日期门控 (INV-OBSERVER/services flip ~6/8, 源可信度 INV ~6/9, OpenClaw 升级 ~6/15) + MOVESPEED INV 需 Mac Mini 24h 数据, 纯 dev 可推进且对齐 active 终极目标的最强选择 = ontology-engine chunk 3. 用户开工选 chunk 3a (路径参数化, 推荐 — 中风险纯 dev de-risk chunk 2). ② **chunk-4 demo 真实暴露的耦合 (packaging.md §5 row 3)**: convergence 是 demo 唯一规避的阶段 (run_demo.py 只跑 invariant 因 convergence 报 false drift). `convergence.py::_DEFAULT_SPEC_PATH` (spec 位置) + 6 处 `Path(__file__).resolve().parent.parent / src` (被评估源文件如 jobs_registry.yaml 的项目根) + 2 处 sys.path (check_registry/providers import) + 1 处 json_file_paths 全硬编码不读 env → 消费方跑 openclaw-ontology-audit 时 convergence 阶段用 bridge 的 5 spec 对消费方项目根求值报 drift. ③ **修复 (镜像 engine.py / governance_checker.py config-injection)**: convergence.py 加 `_resolve_config_dir()` (ONTOLOGY_CONFIG_DIR → spec 目录) + `_resolve_project_root()` (ONTOLOGY_PROJECT_ROOT → 源文件根) + `_CONFIG_DIR`/`_PROJECT_ROOT` 模块常量. `_DEFAULT_SPEC_PATH = _CONFIG_DIR / convergence_ontology.yaml`; 9 处源文件/sys.path 解析改 `_PROJECT_ROOT`. **安全契约 (MR-15 部署 layout 教训)**: 无 env 时默认分支保持 V37.9.19 `.resolve()` 语义字节级不变 → Mac Mini symlink ($HOME/ontology→repo) / dev / cron 零回归 (engine/governance 用非 resolving abspath, convergence 故意保留自身历史 .resolve() 语义因二者经 symlink 指向同一文件且 .resolve() 更安全 — convergence 由 governance_audit_cron cd repo 真实路径加载非 symlink, parent.parent=repo 正确). ④ **demo 端到端验证 (镜像 chunk 4 模式)**: 新增 `examples/minimal_consumer/ontology/convergence_ontology.yaml` (WeatherBot spec weatherbot-allowed-units-active, json_file_paths extractor + line_contains_identifier parser 零 drift) + `weatherbot_state.json` (declared 源文件经 PROJECT_ROOT 注入). run_demo.py 加 section 5: cv.list_spec_ids() 返回 WeatherBot spec 非 bridge + verify_convergence 零 drift. run_demo.sh/README 结尾 note 从 "convergence 未注入 scheduled chunk 2/3" → "已 config-injected". ⑤ **17 新单测**: test_convergence.py +14 (TestConvergenceConfigInjection 9 含 resolver 存在/默认字节级不变/env 覆盖/expanduser/空白回退/端到端注入 alt spec/端到端源文件经 PROJECT_ROOT 解析 + TestConvergenceConfigInjectionSourceGuards 5 含读双 env/resolver 定义/_DEFAULT_SPEC_PATH 经 _CONFIG_DIR/**反向 sabotage Path(__file__).resolve().parent.parent count≤1**/V37.9.107 marker); test_ontology_extension_demo.py +3 (TestConvergenceConfigInjectionDemo: 注入读 WeatherBot spec / 反向验证不注入读 bridge 5 specs / verify_convergence 零 drift). **反向 sabotage 真有效**: revert 1 个 extractor 到硬编码 parent.parent → count=2 守卫立即 fail (2 not ≤ 1), 还原后 5/5 过. ⑥ **不立新 governance INV** (镜像 chunk 1/4 约定: config-injection 扩展靠 test 守卫 + 反向验证, INV 留 chunk 2 import 名稳定后). MRD 模式参数化 (jobs_registry/notify.sh 文件名) 登记为 chunk-3b 聚焦 session — 根已 _PROJECT_ROOT 注入, 仅文件名模式硬编码且已优雅 no-op (非 correctness bug), ~10 个 MR-4 血案防护扫描器不与 3a 捆绑. ⑦ **文档**: packaging.md §5 row 3 标 ✅ + §6 roadmap 拆 3a (✅)/3b (待) + §6.1 推荐顺序调整 chunk 4→3a→2→3b→5 (3a 提前因 de-risk chunk 2); extension_guide.md "Known limitation" → "Config-injected phases" (三阶段全注入 + 写 convergence spec 指南 + chunk-3b follow-up); demo README 4→5 capabilities. ⑧ **验证**: 112 suites 不变 (test_convergence/extension_demo 已注册) / 3951→3968 tests (+17) / 0 fail / governance 87 inv 不变 / 804 checks pass / 安全 95/100 / README 徽章同步 3968 / VERSION 0.37.9.68 不变 (config-injection 零业务语义). 生产治理零回归 (bridge 5 specs 正确加载 jobs declared=38/kb=13/services=3, demo end-to-end exit 0). ⑨ **Mac Mini 待用户**: git fetch+reset 同步 (config-injection 默认行为不变, 无需 pip install, governance audit cron 跑 convergence 行为与改前一致). ⑩ **元价值 (de-risk chunk 2 + chunk-4 demo 驱动)**: chunk-4 demo (真消费方) 暴露真实耦合 → chunk-3a 闭环, 印证 "真消费方驱动" 工程智慧 (Provider Plugin 由 Doubao 驱动同款). config-injecting convergence 让 chunk 2 (import 名去泛化破坏性 rename) 更干净 (更少东西硬编码到 ontology/ 目录). 下次候选: chunk 2 (破坏性 rename, 需定包名 + Mac Mini symlink + 全宪法验证) / chunk 3b (MRD 模式参数化) / chunk 5 (sdist build). |
| V37.9.106 | 2026-06-04 | **MOVESPEED rsync TM 备份争用根治 + INV-CRON-004 历史重复闭环 (用户数据驱动诊断收尾, 周报刷屏血案 session 延伸)** — ① **触发**: V37.9.105 周报刷屏根因确认后, 用户同步重跑 governance --full 浮现 3 个 pre-existing Mac Mini 问题, 逐一数据驱动定位. ② **INV-CRON-004 (crontab 重复) 根因 = 历史遗留 auto_deploy.sh 双行 (非 convergence 污染)**: 用户 `crontab -l | grep -oE 脚本名 | uniq -c` 显示 `3 kb_dream.sh`(合法 Map-Reduce 三阶段 --map-sources/--map-notes/Reduce 参数不同 INV-CRON-004 不误报) + `2 auto_deploy.sh`(真重复). 实际两行: `~/openclaw-model-bridge/auto_deploy.sh`(repo) + `~/auto_deploy.sh`(HOME FILE_MAP 部署), 都 `*/2 * * * *` 每 2min, `_cron_cmd_invokes` 两行都 endswith auto_deploy.sh → 同 entry 调 2 次报警. **治理审计没污染 crontab** (我先前怀疑 convergence machine_sync apply 加近重复行被证伪 — 用户诊断只有这 1 个真重复且是路径变体非 convergence 格式). 修: 用户 `crontab_safe.sh remove 'bash ~/auto_deploy.sh >> ...'` (grep -F 只命中 HOME 路径行不碰 repo 路径) 40→39 条, auto_deploy 恢复每 2min 一遍. ③ **INV-MOVESPEED-TCC-001 (24h incidents=18>2) 根因 = Time Machine 备份争用 (非 FDA/TCC, 推翻 V37.9.80 假设)**: 用户 `log show Sandbox MOVESPEED` 显示 deny 来自 **macOS 系统守护进程** (mobileassetd/AssetCache/managedcorespotlightd 做 Spotlight 索引) **非 cron/rsync** (排除 FDA); `movespeed_incident_analyzer --window 24h`: 36 incidents, **ownership 正确 501:20** (非 V37.9.29 noowners), **analyzer 自己结论 "主导失败模式 EOF + Time Machine backupd 高频, 建议 helper rsync 前检测 tmutil status 备份中跳过/延迟 (非 retry, TM backup 跨度远超 30s)"**. ④ **修复 = movespeed_rsync_helper.sh Phase 0 TM 预检 (analyzer 推荐方案)**: 新增 Phase 0 (在 Phase 1 jitter 之前): `command -v tmutil` 守卫 (跨平台 FAIL-OPEN, 非 macOS/缺 tmutil 照常 rsync, V37.9.78-hotfix 教训) + `tmutil status` grep `Running = 1` → TM 备份中**直接跳过 rsync exit 0 不 retry 不算 incident** (KB 数据不丢只延迟一个 cron 周期). `MOVESPEED_RSYNC_SKIP_TMUTIL_CHECK=1` 测试逃生口. ⑤ **10 新单测 2 类** test_movespeed_rsync_helper.py 25→35: TestTmutilPreCheck(4 注入 fake tmutil — Running=1 跳过 rsync / Running=0 继续 / SKIP env 绕过 / 无 tmutil FAIL-OPEN) + TestTmutilSourceGuards(6 V37.9.106 marker / Phase 0 在 Phase 1 前 / command -v tmutil 跨平台 / SKIP env / Running=1 pattern / 跳过分支 exit 0). ⑥ **累计**: 112 suites 不变 / 3941→3951 tests (+10) / 0 fail / governance 87 inv / 安全 95/100 / README 同步 3951 / VERSION 0.37.9.68 不变 (helper 增强 + crontab 运维, 非业务语义). ⑦ **Mac Mini 待用户**: (a) git fetch+reset 同步 + auto_deploy 同步 movespeed_rsync_helper.sh (b) **下次 24h 内 TM 备份时 KB rsync 应跳过** (log `Time Machine 备份进行中, 跳过 rsync` 而非 EOF incident) → incidents.jsonl 旧 36 条老化出 24h 窗口后 INV-MOVESPEED-TCC-001 自动转绿 (c) INV-CRON-004 已修 (用户删重复 auto_deploy). ⑧ **session 全景 (V37.9.104→106)**: ontology-engine chunk 4 demo → 用户视角发现周报刷屏 → 数据驱动诊断推翻 4 个假设 (notify 队列/crontab 漂移/超时/FDA) → 找到全部 6 个根因 (手动调试/errtrace 误报/test 环境依赖/stale 4-spec/历史 auto_deploy 双行/TM 争用) → 全部修复或给运维命令. 严格原则 #28 (理解再动手) + 反馈 #1 (dev 受限先让用户验证): 每个根因都先 Mac Mini 取证再动手, 零盲改. 治理审计从 715/721 (6 失败) → 预期 721/721 全绿. |
| V37.9.105 | 2026-06-04 | **health_check 周报连续重复推送 5-6 次血案修复 — 推送幂等性速率限制 (用户视角原则 #13/#32 兑现 + 原则 #28 数据驱动诊断, 推翻 2 个假设)** — ① **触发**: 用户 WhatsApp 收到 `📊 OpenClaw 系统证据周报 2026-06-04` **连续重复 5-6 个**, 报告内容相同. 用户视角发现 (原则 #13 定期像用户用 + #32 周观察). ② **严格按原则 #28 (理解再动手) + 反馈 #1 (不在受限环境下定论)**: dev 看不到 Mac Mini 运行时, 先调查不盲改. **核实 V37.9.104 (今天 chunk 4) 未碰 health_check/notify/cron** (纯新增 examples/+docs+test). ③ **两轮 Mac Mini 诊断推翻 2 个假设**: **假设 A (notify 重试/队列重放) 排除** — notify 队列**空** (total 0), 日志**无任何** WARN 发送失败/QUEUED/REPLAY; **假设 B (crontab 漂移/重复) 排除** — crontab 单条正确 `0 9 * * 1` (周一), 无重复无漂移, 无 launchd/root cron 第二调度源. ④ **决定性证据**: `DATE=$(date)` 实时生成 → 报告显示今天 06-04 (周四) 证明今天真跑非重放旧报告; `~/health_check.log` 完美每周一份 (03-16…06-01), 日志最后修改 Jun 1 09:00 (上周一), **今天的 06-04 报告不在日志里** (新数据 85 inv/100 分/1103 KB vs 06-01 的 83 inv/70 分/1063 KB). → **真根因**: health_check.sh 在单条周一 cron 之外被反复调用 (最可能手动 `bash ~/health_check.sh` 测试 / 部署重跑, 不带 `>> log` 重定向故不进日志), 每次无条件推送一份. **不是 cron bug, 不是 notify bug, 不是我引入的**. ⑤ **最小修复 = 推送幂等性速率限制** (镜像 V37.8.15 给 preflight push-test 加的"每小时速率限制"同款模式, 不依赖知道"谁调用的"): health_check.sh 推送段前加 `_health_push_allowed()` 守卫 + `HEALTH_PUSH_MARKER` (~/.kb/cache/health_report_last_push) + `HEALTH_PUSH_MIN_INTERVAL_SEC` (默认 72000s=20h: 周报 168h 恒过, 当日重跑被去重). 推送前 touch marker (一窗口最多一次推送尝试, 真失败由 notify.sh 自身队列重试). 报告仍每次生成+echo+写 health_status.json (调试/契约可见), 仅 user-visible PUSH 受限. `HEALTH_PUSH_MIN_INTERVAL_SEC=0` 手动强制刷新逃生口. ⑥ **跨平台 stat 陷阱 (dev 测试当场抓到, V37.9.78-hotfix 教训再演)**: 初版 `stat -f %m \|\| stat -c %Y` 在 Linux 上 `stat -f` 是文件系统状态 (非 mtime) 且 **exit 0** → 吞掉 \|\| fallback 返回垃圾 → 算术 syntax error. 改 **GNU `stat -c %Y` 在前** (Linux/dev 命中; macOS BSD 不识别 -c → 干净失败 fallback 到 `-f %m` Mac Mini 命中). ⑦ **13 新单测** test_health_check_v37_9_78.py 32→45 (TestV37_9_105_PushRateLimit): 7 源码守卫 (V37.9.105 marker / _health_push_allowed 定义 / 默认 72000 / marker 路径 / 跨平台 stat 双串 / 推送块包在守卫内顺序锁 / touch 在推送前顺序锁) + 6 运行时 (隔离 _health_push_allowed 真跑: 无 marker→允许 / 新 marker→跳过 / 旧 marker (30h 前)→允许 / interval=0→总允许). ⑧ **累计**: 112 suites 不变 / 3923→3934 tests (+11 net: health_check suite 32→45 +13, full_regression 计数变差 -2) / 0 fail / governance 87 inv 不变 / 安全 95/100 / README 徽章同步 3934 / VERSION 0.37.9.68 不变 (推送去重 hotfix, 非业务语义). ⑨ **Mac Mini 待用户**: git fetch+reset 同步 + auto_deploy 同步 health_check.sh → 下次任何 health_check.sh 调用 (cron 或手动) 一个 20h 窗口内只推一次, 重复调用 log `推送速率限制: ... 跳过本次推送 (周报已生成+记录, 防重复刷屏 V37.9.105)`. 残留调查 (非紧急): 找出今天 06-04 谁在 cron 外反复调了 health_check (但速率限制已让 user-visible 症状消失, 与根因解耦). ⑩ **元价值**: 用户视角发现 (单测/治理/preflight 全绿但用户 WhatsApp 实际收到刷屏才暴露) → 数据驱动诊断 (两轮 Mac Mini 取证推翻 2 个假设, 决定性证据 log+date 锁定真因) → 镜像 V37.8.15 已证明模式做幂等性结构修复. 原则 #28 "理解再动手" 严格执行: 没盲目加去重就改 notify/cron, 先查清是 health_check 被多次调用. 反馈 #1 兑现: dev 受限时先让用户在部署环境验证. ⑪ **根因终极确认 (shell history smoking gun)**: 用户 `~/.zsh_history` 实锤 — 今天 08:24 多条 `bash ~/health_check.sh 2>&1 \| head -N` (调试 SLO 段), 完整运行/`\| head -80` 读够输出时触发末尾 `notify --topic daily` 真推送 (`\| head` 只截断终端显示不阻止推送). **唯一调用源 = 周一 cron + 手动调试, 无隐藏 launchd/wrapper** (item #2 列的 job_watchdog/slo_snapshot/auto_deploy 只含字串不运行). V37.9.105 速率限制正好根除. ⑫ **附带修 governance_audit FATAL line=64 误报 (V37.9.105-hotfix)**: 用户同 07:00 收到 `[SYSTEM_ALERT] governance_audit FATAL abort exit=1 line=64` + 真 "Governance Audit 失败" 两条告警. 真因: `set -eEuo pipefail` 的 `-E` errtrace 让 `$(...python3...)` 子 shell 继承 ERR trap, governance_checker 退出 1 (真发现 3 不变式失败) 时**子 shell 内误触发 FATAL**, 外层 `\|\| GOV_RC=$?` 已捕获脚本继续 (两条告警同源一次 run = 没真 abort 的铁证). 修复 `set +E` 包裹 line 64 + 81 两处命令替换 (line 67-70 已对 grep\|head 修过同款 V37.9.60-hotfix bash quirk, python3 漏了). 7 新单测 (含运行时复现 set +E 抑制子 shell trap). ⑬ **3 个真不变式失败根因确认 + 修复 (Mac Mini `time python3 test_convergence.py` 数据)**: **不是超时** (304 tests 3.6s 很快), 是**环境依赖测试 bug**: `test_invalid_timeout_falls_back_to_default` 断言 `_observe_http_endpoint` 抛 RuntimeError (注释"Will fail with connection refused on dev"), 用默认 URL `http://localhost:5001/health` — dev 无服务→连接拒绝→通过, **Mac Mini adapter 真在 5001 跑→GET 成功→不抛→失败**. 修: 改用保证不可达 `http://localhost:1/should_not_exist` (同 test_connection_refused 模式), 环境无关. 这修 INV-CONVERGENCE-CRON-001 + PROVIDERS-001 (其 runtime check subprocess test_convergence.py). **INV-ROUTER-001 疑 07:00 stale 代码** (用户 08:24 才 git reset 同步, 07:00 时 router_decide.py/adapter.py 旧版让 source check 失败; 两个 router 测试用 patch.dict 防护 API key, find_best_provider 读 live env, 静态无环境依赖). 待用户同步后重跑 governance audit 确认 INV-ROUTER-001 自愈. ⑭ **同步后重跑确认 (V37.9.105-hotfix2 生效 + hotfix3)**: 用户同步后重跑 `governance_checker --full` — **INV-CONVERGENCE-CRON-001/PROVIDERS-001/ROUTER-001 全部 ✅ 自愈** (convergence 测试修 + ROUTER 确认是 07:00 stale 代码). 检查数 715→718. 浮现 3 个 pre-existing Mac Mini 问题 (07:00 也在失败, 被 `grep ❌ \| head -5` 截断未显示): **(a) INV-CONVERGENCE-INTEGRATION-001 stale 自检 (V37.9.105-hotfix3 已修)** — runtime check 写死 `assert len(specs) == 4`, 但 V37.9.25 加第 5 spec services_to_launchd, `requires_full: true` 让它在 dev 跳过 (dev 全过假象) 只在 Mac Mini --full 跑 → 4≠5 失败. 修: 4→5 + 加 services_to_launchd 到 spec_ids 列表 + check 名字 4→5 spec. MR-8 单一真理源漂移. dev --full 验证 ✅. **(b) INV-CRON-004 crontab 重复条目** — 真 Mac Mini 状态, 待用户 `crontab -l \| sort \| uniq -d` 查重复 (疑 convergence machine_sync apply 或手动 slo_snapshot add 引入). **(c) INV-MOVESPEED-TCC-001 24h incidents=18 > 2** — 真 MOVESPEED SSD/FDA 问题 (V37.9.80 TCC sandbox saga), 待用户重查 /usr/sbin/cron FDA 权限. (b)(c) 非代码 bug 非我引入, 需 Mac Mini 运维动作. |
| V37.9.104 | 2026-06-04 | **ontology-engine 包化 chunk 4 — 第一个真消费方 demo (WeatherBot) + Extension Guide (引擎的「Doubao 时刻」, 终极目标 pip install ontology-engine 推进)** — ① **触发**: status.json 焦点登记的「终极目标 Ontology Engine 产品化」(active 优先级) + V37.9.99-pkg chunk 1 (config-injection keystone) 收工承诺 + `docs/ontology_engine_packaging.md` §6.1 专业推进顺序「chunk 4 → 2 → 3 → 5, 先做 chunk 4: 风险最低纯新增, 价值最直观」. 今天 (6/4) 多数候选日期门控 (OpenClaw 升级 ~6/15, INV-OBSERVER/services flip ~6/8, 源可信度 INV ~6/9), chunk 4 是纯 dev 可推进且对齐 active 终极目标的最强选择. ② **核心交付 — `examples/minimal_consumer/` WeatherBot 真消费方项目** (第一次有「第二个项目」真用引擎, 端到端验证 config-injection): (a) `weatherbot.py` 一个**故意不同于 bridge** 的虚构 Agent Runtime (工具 get_forecast/get_current_temp/save_favorite_city, 非 bridge 的 data_clean/web_fetch; 含 MAX_CITIES_PER_QUERY=3 + ALLOWED_UNITS 白名单供自己的不变式审计) (b) `ontology/` 4 个 Layer 2 YAML 全部消费方自己写 (tool_ontology WeatherBot 工具 / domain_ontology WeatherBot actors+providers / policy_ontology max-cities-per-query+units-whitelist / governance_ontology audit_metadata 0.1-demo + 2 个 INV-WEATHER-* 不变式只审计 weatherbot.py) (c) `run_demo.py` 练习 **4 大 config-injectable 能力**: ToolOntology.allowed_tools 查询 + find_by_domain('Actor') + evaluate_policy('max-cities-per-query') + governance run_all 审计消费方不变式 (d) `run_demo.sh` thin wrapper 设 `ONTOLOGY_CONFIG_DIR=demo/ontology` + `ONTOLOGY_PROJECT_ROOT=demo` + `PYTHONPATH=repo` (真消费方用 pip install, dev 用 PYTHONPATH 等价) → **同一份引擎代码治理一个完全不同的项目, 零引擎改动**. dev 实测端到端跑通: `🎉 WeatherBot audited clean by the *injected* engine`. ③ **`docs/ontology_engine_extension_guide.md`** (镜像 provider_plugin_guide.md 的 60 秒接入指南): Overview + Quick Start 4 步 (pip install → 写自己的 YAML → export 双 env → openclaw-ontology-query/audit) + 两个 env 表 + 5 种 check_type 参考 (含字段名陷阱 `check_type` 非 `type` + YAML 单/双引号正则转义陷阱) + WeatherBot worked example + **诚实登记 convergence 路径耦合** + API 参考. ④ **`test_ontology_extension_demo.py` 12 端到端单测 6 类**: TestEndToEndDemo(2 run_demo.sh/py 真 subprocess exit 0 + 4 能力段都出现) + TestConfigInjectionLoadsDemoConfig(2 注入后加载 WeatherBot 工具非 bridge) + **TestReverseValidationInjectionMatters(1 不注入 env → 引擎读 bridge 自带配置, 证明 demo 通过依赖注入非巧合)** + TestDemoIsGenuinelyDifferent(2 demo↔bridge 工具集相异 + demo 不变式只引用 demo 文件不引用 proxy_filters) + TestGovernanceAuditDemoPasses(1 run_all 经注入审计 demo 2 不变式全过) + TestSourceLevelGuards(4 文件齐 + run_demo.sh 设双 env + Extension Guide 存在引用 demo + demo YAML 非 bridge 副本). 真 subprocess + env 注入镜像真消费方调用方式. ⑤ **demo 自然暴露真实耦合 (印证 §6.1 ③ 预期「demo 会自然暴露哪些 MRD 模式是本项目硬编码的」)**: `convergence.py::_DEFAULT_SPEC_PATH = Path(__file__).parent / convergence_ontology.yaml` **不读 ONTOLOGY_CONFIG_DIR** → 消费方跑 openclaw-ontology-audit 时 convergence 阶段用 bridge 的 5 spec 对消费方项目根求值报 drift. invariant + MRD 阶段不受影响 (已 config-injected). 登记到 `docs/ontology_engine_packaging.md` §5 已知耦合 + §6 roadmap (chunk 3 一并参数化). demo 的 run_demo.py 用 run_all 只跑 invariant 阶段规避 noise. ⑥ **文档更新**: packaging.md §6 roadmap (chunk 4 标 ✅ V37.9.104, sdist/wheel build 移到 chunk 5) + §6.1 ① 标完成 + §5 新登记 convergence 耦合 + header 加 chunk 4. ⑦ **修一个 demo bug (dev 实测发现)**: INV-WEATHER-UNITS 初版用单引号 YAML + 双反斜杠 `\\s` (单引号 YAML 不处理转义 → 正则匹配字面反斜杠) → 改单反斜杠. 印证 Extension Guide 登记的「YAML 单/双引号正则转义陷阱」是真实坑. ⑧ **修测试 bug (反向验证暴露真细节)**: `data_clean/search_kb` 是 bridge 的 **custom tools 不在 allowed_tools** (builtin/prefix 集), bridge allowed_tools 实际是 web_fetch/sessions_spawn 等 16 个 → 反向验证改用真实 bridge builtin 工具标志. ⑨ **接入 full_regression.sh** suite `ontology_extension_demo` 紧随 ontology_packaging. ⑩ **累计**: 111→112 suites (+1) / 3911→3923 tests (+12) / 0 fail / governance 87 inv 不变 (chunk 4 纯新增不立新 INV, 候选 INV-EXTENSION-DEMO-001 留 chunk 2 import 名去泛化稳定后) / 805 checks pass / 安全 95/100 / VERSION 0.37.9.68 不变 (包化 demo + 文档, 零业务语义改动). ⑪ **下次候选**: (a) chunk 2 (import 名 ontology→ontology_engine 去泛化, 破坏性需全宪法验证 — demo 已证明价值, rename 退化为有明确目标的机械重构) (b) chunk 3 (MRD/convergence 路径参数化, demo 已暴露具体耦合点 convergence._DEFAULT_SPEC_PATH) (c) chunk 5 (真 sdist/wheel build + pip install 冒烟 + 发布决策). ⑫ **元价值 (Provider Plugin → Ontology Engine 同款「真消费方驱动」)**: Provider Plugin 直到 Doubao (第 8 provider V37.9.52) 真接入才被证明可扩展; ontology-engine 同样需要一个真实消费方 demo 来证明抽象正确. 这是「先证明价值再做破坏性投入」工程智慧 (原则 #18 补证据而非补功能) 的兑现 — chunk 4 纯新增风险最低, 让 chunk 2 破坏性 rename 在抽象已验证的前提下退化为机械重构. V3 路标「别人会扩展」从理论升级为「有第二个项目真用引擎」的硬证据. |
| V37.9.103 | 2026-06-03 | **「冻结≠死亡」血案修复 — finance_news + ai_leaders 两 job clean+reduce (V37.9.102 换源决策续, 用户选差异化→改 clean+reduce 不花钱接受 X 退化)** — ① **触发**: V37.9.102 评估报告留 ai_leaders 换源决策待用户定 + finance_news 同用 Syndication 待评估 (#19/#20). 用户先选「差异化」(ai_leaders TwitterAPI.io + finance clean+reduce) 后改「clean+reduce 不花钱接受 X 渠道退化」→ 两 job 统一 clean+reduce, 无需注册付费 API + 纯 dev 可测. ② **finance_news 评估发现 (开工先带数据进决策, 原则 #28)**: finance X 渠道 10 账号无轮换 + 72h 窗口 + classify_zombie 三层 + 3 天连续 → [SYSTEM_ALERT]「建议移除」. **结构脆弱性 = V37.9.102 同根因**: 72h 窗口的 "stale"(≥90% 超窗口) 无法区分「真死(年久)」「快照冻结但活着」「慢但活着」. **🔴 关键发现**: V37.8.14 移除的 ReutersBiz 100/100、XHNews 97/97、CGTNOfficial 99/99、globaltimesnews 98/98 都是真实 Twitter 天天发几十条的活机构 — V37.9.102 证明 Syndication 把天天发推账号快照冻结 6-10 月前, **这些是快照冻结的活账号被 72h 窗口错杀了** (血案在 ai_leaders 诊断揭示真因之前先发演出). ③ **血案精确归因 (核心)**: 被错杀的是 **total>0 的 frozen**(有老推文快照冻结), 不是 stub(0 推文); 血案只关于 frozen. stub(embed-disabled, Syndication 永久拿不到) + dead(年久真死) 是真正可移除的. ④ **finance_news_zombie.py 四档重构**: parser 捕捉 `newest_age_days` (max 推文日期距今天数) → classify_zombie 拆 stub/dead(newest≥730天)/frozen(newest<730 或无法判定)/alive. **is_zombie_suspect = stub OR dead, frozen 永远 False** (Syndication 拿不到有老推文的活账号 ≠ 死亡). DEAD_AGE_DAYS=730 (~2 年) 远超实测冻结范围(6-10 月). ⑤ **run_finance_news.sh wiring**: frozen 分流 `degraded_${DAY}.txt` + 🧊 可观测汇总日志**不告警** (用户接受退化, 避免原则 #32 告警疲劳); ZOMBIE_FILE 只收 stub+dead → 3 天告警措辞 僵尸→可移除 + 澄清「frozen 冻结活账号 XHNews/CGTN 类已不在此列」. ⑥ **ai_leaders_rotation.py classify_account 拆 frozen/dead** (预防 #18 zombie loop-wiring 将来错杀): 原 STATUS_STALE(newest>7d=真僵尸)会让 Syndication 冻结的 karpathy/LeCun/Hinton 全判僵尸 → 拆 STATUS_FROZEN(7d<newest<730d 活账号勿移除) vs STATUS_DEAD(≥730d 真死). is_zombie_suspect 仅 stub+dead. classify_account **尚未 wire 进 run 脚本** (#18 deferred), 修它是预防. **ZOMBIE_DEAD_DAYS=730 跨模块与 finance DEAD_AGE_DAYS 一致** (test 守卫防漂移). ⑦ **降频**: ai_leaders jobs_registry `0 9,21`→`0 9` (2→1/天, 接受退化 + 减半 Syndication 请求防 429); job_watchdog 阈值 50400(14h)→180000(50h) 对齐 1/天 (与 finance_news 同款). finance 已是 1/天, N/A. ⑧ **测试**: finance 24→32 单测 (四档 + frozen 血案守卫 + 730 边界 + 跨模块一致 + degraded 分流 + 反向验证) + ai_leaders 34→47 单测 (frozen/dead 拆分 + frozen 绝不判僵尸血案守卫 + 跨模块一致 + CLI). **反向验证两层守卫真有效**: finance frozen→可移除 sabotage → 6 fail; ai_leaders is_zombie_suspect 加 FROZEN sabotage → 4 fail, 还原后全过. ⑨ **governance INV-X-001 扩展** (covers finance + ai_leaders): declaration 升四档 + 防错杀层 (7) + runtime python_assert 改四档 + 跨模块 DEAD 一致 + ai_leaders frozen 不判僵尸 + 7 新 declaration checks (newest_age/degraded 分流/frozen False/DEAD_AGE_DAYS=730/ai_leaders STATUS_FROZEN/is_zombie_suspect 仅 stub+dead) + 措辞 僵尸→可移除. blood_lessons +1 (V37.9.103 MR-10 第三层演出: V37.8.5 修复在 Syndication 退化下成新 bug). ⑩ **累计**: 111 suites 不变 / 3892→3911 tests (+19) / 0 fail / governance 87 inv 不变 (INV-X-001 内涵扩展) / 805 checks pass / 安全 95/100 / VERSION 0.37.9.68 不变 (检测逻辑 + source 配置改, 非 capability). ⑪ **Mac Mini 待用户**: (a) git fetch+reset 同步 + auto_deploy 2min 轮询同步 finance_news_zombie.py / run_finance_news.sh / ai_leaders_rotation.py / jobs_registry.yaml / job_watchdog.sh (b) **下次 07:30 finance cron** 应首次出现 🧊 X 渠道退化日志 (frozen 账号零产出, 不再 [SYSTEM_ALERT] 建议移除活账号) (c) **下次 09:00 ai_leaders cron** 1/天生效 (d) crontab 更新 ai_leaders 频率: `crontab_safe.sh` 或手动改 `0 9,21`→`0 9`. ⑫ **元价值 (MR-10 understand-before-fix 第三层 + V37.9.102 血案 codify)**: V37.9.102 揭示 Syndication 平台退化真因 → V37.9.103 把「冻结≠死亡」codify 进两个分类器, 防止 finance 继续错杀 + 预防 ai_leaders #18 wiring 将来错杀. 同根因一次性修两 job, frozen 永不判僵尸成为跨模块硬契约 (INV-X-001 + 跨模块 DEAD_AGE_DAYS 一致 + 反向验证守卫). 用户「clean+reduce 接受退化」决策让方案纯 dev 可测无外部依赖. |
| V37.9.102 | 2026-06-03 | **ai_leaders_x 替代数据源评估报告 (Syndication API 退化战略调研 — V37.9.101 复盘续, 用户选"调研替代源")** — ① **触发**: V37.9.101 轮换修复 429 后 Mac Mini 实测续诊断揭示更深真相 — fetch 成功了但仍产 0 推文. 全 31 账号最新推文年份分布 **2026=6 / 2025=17 / 0推文=6 / no_data(429)=2**: 多数账号 (karpathy/ylecun/Hinton/Dario 天天发推) Syndication 快照**冻结在 2025-09~11** (6-10 月前) = X 停止刷新这些账号缓存; 只 PalantirTech(4d) 在 14 天 cutoff 内; 6 账号 200 但 0 本人推文 (embed-disabled 真死). **三层真因链全揭开: ~~僵尸~~ → 429(已修) → Syndication API 退化 (产 ~0)**. ② **karpathy "2023" 误判纠正**: 单账号 `ts[0]` 取了置顶推 (2023 老推), 全量取 max 才是真最新 2025-11-13 — 不是全冻结 2023, 是各账号冻结在不同时间. ③ **WebSearch 调研 2026-06 当前真实状态** (4 源): X 自 2023 持续收紧非认证访问 (封 guest account + 冻结 Syndication 刷新) 是行业大趋势. ④ **新文档 `docs/ai_leaders_source_alternatives.md`** 决策导向评估 5 方案: (a) 🥇 **TwitterAPI.io 等第三方 REST** $0.15/1000 推 + 免费起始额度 + 无需官方认证 → 我们用量 ~$0.84-6/月, 比官方便宜 96%+ (b) 🥈 官方 X API 2026-02 起 pay-per-use $0.005/读 → ~$100-200/月太贵, 免费层已取消 (c) 🥉 自托管 Nitter (Docker) — 2026 原项目休眠公共实例死, 自托管需自备凭证频繁换号维护成本高 (d) ❌ RSSHub/RSS Bridge — 底层仍 Syndication/Nitter 同病 (e) ⚠️ 保持现状 — 免费但产 ~0. **含真实成本测算 + 决策矩阵 (看重便宜可靠→TwitterAPI.io / 不花钱接受退化→清死账号降频 / job 已无价值→disable) + TwitterAPI.io 迁移路径 (V37.9.103+: API key→plist env 遵 INV-PLIST-ENV-001→重写 fetch REST→保留 V37.9.101 轮换+健康分类→免费额度先试一周)**. ⑤ **关键判断登记给用户**: ai_leaders_x 独特价值 = "AI 大神 X 即时观点" (vs arxiv/hf 论文 / rss/hn 文章), 是否值 ~$2/月 → 值则 TwitterAPI.io / 否则 disable. ⑥ **元价值 (外部依赖死亡典型案例)**: X Syndication 是 V27 起 ai_leaders/finance_news 基石 (原则 #27 "X 是高质量实时数据第一选择"), 如今进入退化期. 教训: **关键数据源不能长期依赖未文档化免费端点** — 要么接受退化要么转付费/合规. **finance_news 同用 Syndication 同面临此风险 (待评估, V37.9.103+ 候选)**. ⑦ **累计**: 111 suites / 3892 tests / 0 fail 不变 (纯文档调研, 零代码) / governance 87 inv / 安全 95/100 / VERSION 0.37.9.68 不变. **待用户决策换源方向** (调研报告交付, 实施留 V37.9.103+). |
| V37.9.101 | 2026-06-03 | **ai_leaders_x 轮换抓取防 429 — 12 账号复盘揭示真问题非僵尸而是 X Syndication API 限流瘫痪 (用户视角原则 #13 + V37.9.99 误诊纠正)** — ① **触发**: 用户选"ai_leaders 12 账号活跃度复盘" (V37.9.95 6/1 新增 12 账号跨 12 派别, 2 天 cron 后查僵尸 newest_tweet>7d 清理). ② **复盘诊断揭示真问题 (非僵尸)**: 自包含诊断扫 Mac Mini cache raw HTML 按最新推文年龄分类 → **31/31 全 no_data** (无 __NEXT_DATA__). 实时 fetch karpathy (铁定活跃) → `HTTP:429 SIZE:20` → **X Syndication API 限流了 Mac Mini IP**, 返回 20 字节错误 stub. **连单条隔离请求都 429** (距 09:00 cron 约 2h) → IP 持续被标记. **ai_leaders_x 当前产 0 推文** — 不是账号死了是限流. ③ **V37.9.99 误诊纠正**: V37.9.99 #14 复盘当时把"所有 ok 账号 0 新推文"读成 seen-dedup 正常, **实际一直是 no_data (限流)**. V37.8.4 ZOMBIE detection 若 naive promote 会把 429 期间全 31 no_data 误杀成僵尸 (盲区). ④ **真根因**: V37.9.95 把账号 19→31 翻倍, 每次 cron 31 个 X Syndication 请求超限流阈值. V37.9.99 5s inter-account 节流对单 run 内有帮助但请求总量仍超. ⑤ **用户决策"建轮换抓取修复"**. **新模块 `jobs/ai_leaders_x/ai_leaders_rotation.py`** (纯函数零 I/O, 镜像 finance_news_zombie 模式): `select_batch(num, idx, batch=11)` 轮换+环绕 (每 run 只抓 ~11 子集, ceil(31/11)=3 run 全覆盖, 单 run 请求 31→11 降到阈值下 + 5s 节流=55s 摊开, 状态文件 rotation_idx 每 run 递增鲁棒于漏跑) + `classify_account(http_ok, has_next_data, count, newest_age)` 四态健康分类 (rate_limited/stub/stale/alive) + `is_zombie_suspect`. **核心适配 (vs finance_news 高频老化比例判据)**: research 账号低频用 newest-age>7d 判 stale; **rate_limited (429/no_data) 绝不判僵尸** — 限流期间不误杀活账号 (V37.8.4 promote 盲区填补). ⑥ **wire 进 run_ai_leaders_x.sh**: 循环前读 rotation_idx + 调模块 select 选子集 (`for sel in $SELECTED_IDX; leader_entry="${LEADERS[$sel]}"`), 循环后递增 idx. **FAIL-OPEN**: 模块缺失/异常 → 抓全部保旧行为 + log WARN; `set -eo pipefail` 下 python 调用加 `|| true` 防杀脚本. ⑦ **34 单测 test_ai_leaders_rotation.py 6 类**: TestSelectBatch(12 含 3 run 全覆盖 + 环绕 + batch≥num 退化 + 边界) + TestClassifyAccount(9 含 7d/8d 边界 + http_fail→rate_limited + no_next_data→rate_limited) + TestIsZombieSuspect(4) + **TestBloodLessonRateLimitedNeverZombie(1 复现 2026-06-03 全 31 429 → 0 误判僵尸)** + TestCli(6 subprocess) + TestSourceGuards(2). + 端到端 `set -eo pipefail` 真跑验证 (3 run 11+11+9 覆盖全 31 + 环绕 + idx 递增 + FAIL-OPEN 缺模块抓全部). ⑧ **"promote ZOMBIE detection" 交付边界 (原则 #28 最小修复)**: classify 模块已建+测+CLI 可用于复盘诊断 (检测逻辑 promoted); **完整 loop 自动 stale 检测 (parser 发 newest_age + per-account 分类 + 3 天连续告警) 留 21:00 验证 rotation 工作后做** — fetches 当前 429 没真数据可检测, 不为还不存在的数据投机 wiring. ⑨ **auto_deploy FILE_MAP + full_regression 接入**. **累计**: 110→111 suites (+1) / 3858→3892 tests (+34) / 0 fail / governance 87 inv 不变 / 安全 95/100 / VERSION 0.37.9.68 不变 (source 配置 + 抓取策略改, 不涉及 capability 升级). ⑩ **Mac Mini 待用户**: (a) git fetch+reset 同步 + auto_deploy 2min 轮询同步 ai_leaders_rotation.py 到 ~/.openclaw/jobs/ai_leaders_x/ (b) **21:00 cron 真激活验证轮换** — 应 log `V37.9.101 轮换: idx=N batch=11 → 本 run 抓 11/31 账号` + fetch 成功率大升 (11 请求 vs 31). 若 11 请求仍 429 → IP 被硬标记, V37.9.102+ 转换策略 (降 batch / 认证版 API / 替代源). (c) rotation 工作后重跑复盘诊断 → 真僵尸 (stale>7d) 移除 + 完整检测 loop-wiring. ⑪ **元价值 (用户视角原则 #13 第 N 次正向兑现 + 数据驱动诊断)**: task 从"清僵尸"数据驱动 pivot 到"修 429 限流" — 诊断揭示真问题非预设框架 (V37.9.99 misdiagnosis 纠正). 没有这次复盘诊断, ai_leaders_x 会继续静默产 0 推文 (被误读成 dedup). MR-10 understand-before-fix: 先诊断 (实时 fetch 定性 429 vs 格式变化) 再动手, 没盲目清僵尸. |
| V37.9.100 | 2026-06-03 | **INV-DREAM-CROSS-DOMAIN-001 立案 + 治理执行器 assertion 字段空跑血案修复 (67 check / 21 INV vacuous pass) + INV-GOV-FIELD-001 meta-guard (MR-4 silent-failure + MR-7 治理自观察盲区最深演出 — 一个 MR-7 INV 暴露治理执行器自身 MR-7 盲区)** — ① **触发 (用户选"今天立案")**: V37.9.89 LEVEL_6_DREAM_CROSS_DOMAIN_AWARE 反链式幻觉守卫经 5 天观察期 (5/30-6/3) verdict PASS — 多跳因果链行 4.75→0.4/天 (↓92%) / 因此句式 3.0→1.4 (↓53%) / [强证据]+[弱关联] tag 0→9.4/天. 立案 governance INV 守 dream 用 LEVEL_6 防回退. ② **INV-DREAM-CROSS-DOMAIN-001** (meta_rule=MR-7, severity=high, verification_layer=[declaration, runtime], **7 checks**): 3 file_contains (kb_dream.sh DREAM_HG_GUARD 用 LEVEL_6 / hallucination_guards.py 含 _LEVEL_6 / yaml marker) + 防回退 python_assert (正则提取 DREAM_HG_GUARD get_guard 级别必须 == LEVEL_6_DREAM_CROSS_DOMAIN_AWARE) + LEVEL_6 内容 python_assert ×2 (tag 模板+必然句式禁令+📭 fallback / 累积继承 LEVEL_5 Radar) + runtime (TestV37_9_89_Level6CrossDomain 守卫测试全过). 与 INV-HALLUCINATION-001 (守 5 档公共模板) 互补. ③ **反向验证暴露治理执行器血案**: sabotage LEVEL_6→LEVEL_5 时防回退 check **本应抓却 ✅ 通过** — 调查发现 `governance_checker._exec_python_assert` (line 84) 只读 `check.get("code")`, 但 YAML 里 **67 个 python_assert 写成 `assertion:` 字段 (跨 21 INV)** → 拿到空字符串 → `exec("")` 无异常 → **永远 vacuous pass**. 治理报"✅ 所有不变式成立"但 67 个 check 从未真执行 (含 2 critical: INV-DREAM-003 dream 反污染 / INV-WATCHDOG-SELF-001 watchdog 自监控). **教科书级 MR-4 silent-failure + MR-7 治理自观察盲区 — 讽刺: 立案一个 MR-7 INV 的反向验证暴露了治理执行器自身的 MR-7 盲区** (≈数月潜伏: `assertion:` 字段名 MR-8 copy-paste 从某版本扩散). ④ **根因修复 (MR-8 单一真理源)**: 新 `_check_code(check)` helper = `check.get("code") or check.get("assertion", "")`, 执行器 + MRD 覆盖率收集 + meta-discovery 三处统一读, 前向兼容两种字段名. ⑤ **triage 14 个真执行后翻车 (5 类, 守卫属性大多还在只是 assertion 自身问题)**: (a) **sabotage 残留** — job_watchdog.sh ERR trap + LC_ALL=C 被 triage 过程中反向验证 test 乱序跑留下的 sabotage (空跑 check 数月没抓到任何 watchdog 真退化), git checkout HEAD 还原 → INV-WATCHDOG-SELF-001 + INV-CRON-MONITOR-001 恢复 (b) **路径 bug** — INV-HALLUCINATION-001/INV-LLMCRON-AUDIT-001 用 `os.path.dirname(__file__)` 在 exec 环境 __file__=governance_checker.py → repo=ontology/ → glob/subprocess 路径错 → 改 cwd 相对 (exec 已 chdir _PROJECT_ROOT) (c) **阈值太紧** — INV-DREAM-MULTITHEME-001 DEEP fail-fast 500→800 (V37.9.75 加 deep_retried 字段撑长 status 行, exit 1 在 604) / INV-ROUTER-001 router_decide 500→1200 (V37.9.77 ROUTER_ENFORCE 逻辑撑长, 在 924 前) (d) **stale 契约** — INV-RSSBLOGS-001 3 check 验旧 V37.9.36 立即-exit 模型, V37.9.37 改 per-paper retry + 6 字段 (parse_5field→parse_6field / LLM返回空内容→empty_content / per-error-exit→all-failed exit 1) → 重写当前契约 (e) **exec 作用域陷阱 (V37.3 教训)** — INV-MOVESPEED-TCC-001 case doc 列表推导 `[k for k in _required if k not in _content]` 在 exec 创建新作用域看不到 exec locals → NameError → 改 for-loop; incidents.jsonl `return` 在 module 级 → SyntaxError → 改 if 嵌套 + _io_ok 标志 + requires_full gate (dev 有 4.4MB test fixture) (f) **递归** — INV-CONVERGENCE-INTEGRATION-001 2 check 跑 subprocess governance_checker, 执行器修好后子进程会再跑 → 无限递归 → requires_full (子进程无 --full skip 终止递归) + test_convergence.py version alternation 加 3.53. ⑥ **INV-GOV-FIELD-001 meta-guard** (meta_rule=MR-7, severity=critical, **4 checks**): 守 (1) 执行器 _check_code 读双字段不退回 code-only (file_contains + python_assert) (2) 无 vacuous python_assert (yaml 扫每个 code+assertion 非空) (3) marker. **本可一开始就抓住整个 bug 类**. ⑦ **反向验证两 INV 真有效**: INV-DREAM sabotage LEVEL_6→LEVEL_5 → 防回退 check 精确抓 `❌ 实际用 LEVEL_5_RADAR_AWARE`; INV-GOV-FIELD sabotage 执行器退 code-only → file_contains check 立即抓双字段模式缺失. 还原后全过. ⑧ **关键认知**: 反向验证 test (test_cron_monitor_scanner/test_watchdog_self_monitoring) sabotage tracked 文件后用 finally/tearDown 自还原 — 单跑 (governance 调用形式 python3 test_X.py) rc=0 且 0 脏文件, 但 triage 过程中乱序/中断会留脏; 干净起点的 governance 跑完零脏文件 (实测确认). ⑨ **累计**: 110 suites / 3858 tests / 0 fail / governance v3.52→v3.53 / **85→87 invariants** (+2 INV-DREAM-CROSS-DOMAIN-001 + INV-GOV-FIELD-001) / **790→801 checks** (+7+4) / 21 meta rules 不变 (复用 MR-7) / 安全 95/100 / VERSION 0.37.9.68 不变 (治理层固化 + 执行器 bug 修复, 零业务语义改动) / README invariants 徽章 85→87 (gen_readme_badges 同步). ⑩ **Mac Mini 待用户 git fetch+reset 同步** (治理修复, governance audit cron 07:00 下次跑将首次真执行 67 个此前空跑的 check — 若 Mac Mini 上 job_watchdog/其他守护脚本有真退化将立即被抓, dev 已验证当前全绿). ⑪ **元价值 (V37.9.84 observer → V37.9.89 LEVEL_6 → V37.9.100 立案 三阶段闭环 + 治理自观察最深演出)**: 立案 LEVEL_6 INV 的过程暴露了治理执行器自身数月潜伏盲区 (67 check / 21 INV vacuous pass, 含 2 critical 守卫). 印证用户"今天一并修"决策价值 — 空跑 check 不仅是统计问题, 还藏着真问题 (watchdog ERR trap 若真退化无法被抓). MR-4 silent-failure (静默故障是 bug) + MR-7 治理自观察 (观察者必须可被观察) 两元规则在治理执行器层的最深演出: 治理工具用一个 INV 的反向验证发现自己 67 个 check 从未执行. INV-GOV-FIELD-001 把这个 bug 类从"靠记忆"升级为"机器化守卫". |
| V37.9.99-pkg | 2026-06-02 | **ontology-engine pip 包化第一块 (Phase 5 chunk 1 — 终极目标奠基)** — ① **目标**: `pip install <engine>` + 项目级 YAML → 任何 Agent Runtime 项目获工具治理 + 语义查询 + governance 审计, 无需理解引擎内部 (V3 路标"别人会扩展"终极交付物). ② **二层架构确立**: Layer 1 (项目无关引擎: ToolOntology/evaluate_policy/find_by_domain + 5 check executor + MRD 框架 + convergence + three_gate) = 本 pip 包; Layer 2 (项目特定 YAML: tool/governance/domain/policy/convergence_ontology.yaml) = 消费方. ③ **keystone = config-injection**: engine.py 加 `_resolve_config_dir()` + `ONTOLOGY_CONFIG_DIR` env; governance_checker.py 加 `_resolve_project_root()`/`_resolve_ontology_dir()` + `ONTOLOGY_PROJECT_ROOT`/`ONTOLOGY_CONFIG_DIR` env — 让 pip 装的引擎指向消费方 YAML 而非引擎自带. **向后兼容**: 无 env → 默认引擎同目录 (Mac Mini/dev/cron 行为不变). 核心 API 本就接受 path 参数 (ToolOntology(path)/evaluate_policy(...path=None)), 只补模块级默认的 env 兜底. ④ **governance_checker `__main__` 抽 `main()`** (行为不变, cron/full_regression 仍走 `__main__ → sys.exit(main())`) 供 console 入口. ⑤ **pyproject.toml**: `openclaw-ontology-engine` 0.1.0 (公共 PyPI `ontology-engine` 已被占用), `packages=["ontology"]` (不打包顶层应用模块), `package-data` 含 YAML+CONSTITUTION.md, console_scripts `openclaw-ontology-audit`/`openclaw-ontology-query`. **真装证明**: `pip install -e . --no-build-isolation` → Successfully installed + `import ontology.engine/governance_checker` OK + 两 console 命令真注册到 bin + 卸载干净. ⑥ **docs/ontology_engine_packaging.md** 设计文档: 二层架构 + config-injection 契约 + 已知耦合诚实登记 (engine.py main() 的 `from proxy_filters import` lazy+try-guarded CLI-only / MRD 项目特定模式留 chunk-3 参数化) + 迁移路标 (chunk2 import 名去泛化破坏性变更 / chunk3 MRD 参数化 / chunk4 sdist+Extension Guide / chunk5 发布决策) + 开放决策 (import 名/分发名/license/readme). ⑦ **test_ontology_packaging.py 23 单测 7 类**: config 注入 (engine env override + 端到端真加载 alt YAML) + governance 注入 + pyproject 有效性 + console 入口可解析 + 宪法删除安全源码守卫 + 反向 sabotage. **反向 sabotage 真有效**: engine.py 退回硬编码 `_ONTOLOGY_DIR = os.path.dirname(...)` → test_no_hardcoded + test_env_override 立即 fail, 还原后 23/23 全过. ⑧ **验证全绿**: full_regression 109→**110 suites** / 3835→**3858 tests** / 0 fail + governance 789 checks + **宪法第一条 Ontology 项目隔离验证 ✅ proxy_filters 不依赖 ontology** (删除 ontology 后 FAIL-OPEN 回退 config) + gen_readme_badges 同步 3858 无漂移. VERSION 0.37.9.68 不变 (包结构 + 注入 keystone, 零业务语义改动, chunk-1 不发布). ⑨ **元价值**: 把"引擎绑定自己目录 YAML"解耦为"config 由消费方注入", 是 `pip install ontology-engine` 终极目标第一块地基. chunk 1 刻意低风险 (向后兼容 + 不动 import 名 + 不动 proxy lazy-load), 破坏性的 import 名去泛化留 chunk 2 专门做 + 全宪法验证. Mac Mini 待 git fetch+reset 同步 (注入 keystone 默认行为不变, 无需 pip install). |
| V37.9.99-docs | 2026-06-02 | **failure_modes_catalog 单一权威版整合 (MR-8 兑现 + 外部评审 doc-drift 回应)** — ① **触发/发现**: 用户 6/2 选"失败模式库 + 话语权"方向; 开工核实发现 catalog 已存在但**两份分叉副本** — `docs/failure_modes_catalog.md` (V37.9.86, 32 案例, 按失败**机制**分类) + `ontology/docs/failure_modes_catalog.md` (V37.9.81, 21 案例, 按发生**位置**分类), 分类法不兼容 + 都 stale + 这本身就是 MR-8 copy-paste + 外部评审点名的 doc drift (**记录失败模式的文档自己是失败模式**). 第三个相关分类源 `reflections/2026-05-13_complexity_bug_taxonomy.md`. ② **方案 (用户选单一权威版+删副本, 按宪法删前 surface 取得确认)**: 以 ontology/docs/ 为唯一 canonical (被 governance/scanner/CLAUDE.md 引用 + 内容最全 + 紧邻 case docs), 重写为**机制导向** 5 类分类法 (A 环境Quirk / B 设计假设错配 / C 错误吞噬稀释 / D 链式幻觉编造 / E 运维遗漏取证盲区), 22 真案例 (24 文件 − openclaw_as_ontology 架构 − cron_line_audit 决策) + 新增 v37_9_92_observer_path (Class B), 更新到 V37.9.99 (85 INV/21 MR/15 MRD/790 checks/v3.52); 删除 docs/ 分叉副本. ③ **史料修正**: 旧 catalog 误记 "MR-16 候选=macos-cron-fda" — 实际 MR-16=security-dimensions-governed-by-invariants (V37.9), macos-fda 从未获编号仍候选. ④ **话语权增强 (ArXiv "Silent Failures Taxonomy" 论文前置)**: 新增横向洞察 — 潜伏期分布 (60天 TCC/13h HEARTBEAT/7天 watchdog/5天 observer path) + 发现渠道分布 (用户视角~70% > Mac Mini真跑 > Observer自观察 > 单测) + 三层根因模式 (触发器/放大器/掩护者) + 防御演进三步跃迁 (单点修复→元规则→MRD扫描器) + MR-4 ~28次演出完整时间线. ⑤ **README 4 处 stale 同步**: v3.47→v3.52 / 80→85 INV / 19→21 MR / 14→15 MRD / 731→790 checks / 21→22 案例 + 链接文字 docs/→ontology/docs/. ⑥ **验证**: full_regression 109 suites/3835 tests/0 fail + governance 693/693 checks 所有不变式成立 + path_consistency 0 violations + gen_readme_badges 无漂移 + 无断引用 (CLAUDE.md 6 处引用均在 changelog 叙事/裸名非 file-path check, 安全). VERSION 0.37.9.68 不变 (doc 整合, 零代码/零新 INV/MR). ⑦ **元价值**: 把"记录失败模式的文档"本身从 doc-drift 失败模式修复为 MR-8 单一真理源 (catalog practices what it preaches), 同时产出 Stage 2→3 话语权资产 + ArXiv 论文证据基础. Mac Mini 待用户 git fetch+reset 同步. |
| V37.9.99 | 2026-06-02 | **"全部执行"批次 — 🧹 清理重复 unfinished + #7 SLO 样本门槛 + #7 README 徽章自动生成 + #5 Opportunity Radar Stage 5 kb_radar（同 V37.9.98 session, 用户"全部执行清除所有能处理的待办"指令）** — 周二 6/2 多数候选 (INV-OBSERVER/services flip/INV-SOURCE-CREDIBILITY) 日期硬卡 ~6/8-6/9, LEVEL_6 完整判定 6/4, 用户选清掉今天能做的. ① **🧹 清理**: INV-OBSERVER-001 三条重复 (V37.9.90/93/95 累积) 合并成 1 条 + 移除 #8 (全行 crontab 扫描已被今天 #3 审计否决) + 确认 INV-CROSS-ENV-PATH-001 已 V37.9.94 完成 + 发现并剥离 status.json #11 外部评审项里 6679 字符 pip install ontology-engine 日志污染 (误把 V3 路标句子劈开, 未执行; PyPI ontology-engine 0.1.0 已被他人占用命名撞车登记). unfinished 19→16. ② **#7 SLO 样本门槛 (外部评审 P0)**: slo_benchmark.py 加 MIN_SAMPLE_THRESHOLD=200 + `_verdict()` 三态 helper (样本<门槛→**OBSERVING** 观察中, 不报 PASS 也不报 FAIL) 修 V35 golden trace samples=1 标 ALL PASS 统计无意义. 每 check 用各自样本基数 (latency.count/total/tool_total/failure_streaks), overall 三态优先级 FAIL>OBSERVING>PASS. config.yaml slo.min_sample_count 可调. test 17→25 (+8 含血案 samples=1/三态 helper/可配门槛) + 补进 full_regression (此前从未注册 gap). dev CLI 实测现报 OBSERVING (诚实). ③ **#7 README 徽章自动生成 (外部评审 P0 — 事实单一来源)**: gen_readme_badges.py 从权威源生成 4 徽章 (tests←status.json quality.test_count / governance←audit_metadata / version←CLAUDE.md+VERSION / providers←providers.py --json) + `--check` 漂移守卫 (exit 1) + `--write` 同步, 接入 full_regression doc-drift 层 = CI 级 pre-commit 等价物. 立即修真漂移 (README tests 徽章停 3739 实际 3751). 删脆弱散文扫描 (python3 providers 误报). 21 新单测 + 反向验证. ④ **#5 Opportunity Radar Stage 5 kb_radar (设计文档 6.1)**: 新 kb_radar_collect.py (纯 Python collector) + kb_radar.sh (06:00 cron thin wrapper) 消费三件套 (#1 跨源共振 daily_signals / #2 项目高对齐 top_alignment_picker / #3 趋势加速 weekly_trends) → 规则化件套交集分 红/黄/蓝三档: 🚨红=三件套交集 (跨源∩高对齐⭐≥4∩趋势加速) / ⚠️黄=二件套 / 📈蓝=单件套趋势观察 (加速+减速). **关键设计 (原则 #28/#18)**: 红黄蓝是规则化交集非 LLM (三件套各自已做 LLM 分析), 规则更鲁棒 (确定性+无 06:00 LLM fail-fast 吵醒+零 token), LLM prose 润色留 V+1. 复用 kb_dream_helpers.themes_overlap (主题跨源匹配, 修 themes_overlap 接受 set 非 str bug + 跨语言子串 fallback) + top_alignment_picker (MR-8 不 copy-paste). **推送决策**: 仅 red+yellow>0 (可操作机会点) 才双通道推送, 否则只归档 KB (原则 #32 低噪声); radar 无信号=no_actionable 非故障不报 [SYSTEM_ALERT]; collector_failed→真故障 fail-fast. 30 新单测 (read FAIL-OPEN/topic match/红黄蓝交集/briefing/orchestrator/shell 守卫) + 反向验证 (sabotage 退回 str→跨件套交集失效). jobs_registry kb_radar (0 6, needs_api_key=false) + auto_deploy FILE_MAP×2 + docs/config.md + full_regression. dev 端到端 no_actionable 只归档 exit0. ⑤ **#2 LEVEL_6 dream 3 天预览 (Mac Mini 数据)**: V37.9.89 修复显著生效 — 因此句式 4→1 (↓70%) / 为X提供 ~2.5→~1 / [强证据]+[弱关联] tag 0→9-12/天 / 定性 6/1 每条隐藏关联正确分级. 完整 5 天判定 6/4 后立 INV-DREAM-CROSS-DOMAIN-001. ⑥ **#3 convergence cron 行审计 (决定不切换)**: Mac Mini 真 crontab declared=37 observed=38 missing=17 extra=18 全是功能等价格式变体 0 脚本缺失, 切换会 false-drift 风暴+machine_sync 搞坏 crontab. 数据驱动决策保持 line_contains_identifier. case doc cron_line_full_comparison_audit_2026_06_02.md + spec 注释. ⑦ **#4 Semantic Scholar API key 集成 (FAIL-OPEN)**: run_semantic_scholar.sh 加 x-api-key header + 条件间隔 (有 key 1s/无 key 30s), 规避匿名池 429. 12 新单测. WebSearch 核实修正 "100 req/sec"→"独占 1 RPS" + "即时发放"→"审核制约几天" 事实错误. ⑦b **#14 ai_leaders 复盘 + 429 节流修复 (用户拉 Mac Mini fetch log)**: 关键发现非僵尸问题 — V37.9.95 账号 19→31 翻倍撞 X Syndication HTTP 429 (~16/31 fail 且失败账号两次 run 轮换=账号活着). 真因旧 inter-account sleep 3 仅成功路径 (失败 continue 跳过) → 限流后 rapid-fire. 修复: 节流移循环顶部 FETCH_IDX 守卫默认 5s 对成功+失败都生效, 删旧成功路径 sleep 3, 不回退 31 账号. 8 新单测 + 反向验证. 次要观察 (待后续, 不盲改): 所有 ok 账号 0 条新推文 (可能 seen-dedup 正常). ⑧ **累计 (V37.9.98+V37.9.99 全 session)**: 102→**109 suites** / 3683→**3835 tests** / 0 fail / governance v3.52 不变 (无新 INV, 全是 PoC/observability/审计/清理/bugfix) / 85 invariants / 790 checks / 21 meta rules / 安全 95/100 / VERSION 0.37.9.68 不变. ⑨ **Mac Mini 待用户**: (a) git fetch+reset 同步 (b) kb_radar cron 注册 `bash ~/crontab_safe.sh add '0 6 * * * bash -lc "bash ~/kb_radar.sh >> ~/.openclaw/logs/jobs/kb_radar.log 2>&1"'` (c) S2 key 申请到后加 S2_API_KEY env (d) ai_leaders 429 节流修复部署后下次 09:00/21:00 cron 验证 fail 率大降. ⑩ **元价值**: 单 session 清掉 8 个能处理的待办 (5 dev 含 #14 429 节流 + 清理 + 2 P0 外部评审吸收), 验证"全部执行"批次纪律 — 每项 tests+反向验证+full_regression+0 fail, 日期/数据硬卡项 (INV-OBSERVER/services flip ~6/8, LEVEL_6 6/4, OpenClaw 6/15) 诚实跳过不假装. Opportunity Radar 三件套 (#1+#2+#3) 经 Stage 5 kb_radar 真正收口成"早晨机会点雷达". #14 用户视角原则 #13 兑现 — 数据揭示真问题 (429 节流) 非预设框架 (清僵尸). |
| V37.9.98 | 2026-06-02 | **来源可信度评级 source_credibility.py — observer 5/28 proposal #2 兑现 (MR-7 治理自观察延伸 + V37.9.83 AI Partnership 闭环: observer 自己提议 → Claude 实施)**（周二开工: 多数 INV-OBSERVER/services flip 候选要 ~6/8 满一周观察硬卡; LEVEL_6/ai_leaders 观察窗口需 Mac Mini 生产数据; 用户选 #1 源可信度评级 — 设计就绪+纯 dev 可做可测）— ① **触发**: V37.9.84 daily_observer 5/28 LLM critique 主动提议 "所有非主流学术源 (如 chaspark 华为茶思屋) 在首次引用时需附带来源可信度评级 — 是否同行评审 / 是否有 DOI / 是否可公开验证". 这是 MR-7 治理自观察延伸 — observer 不仅发现 dream 链式幻觉 (→ V37.9.89 LEVEL_6 解决"跨域推论可信度"=关联强度)，还识别"来源可信度盲区": dream/evening LLM 把 chaspark 社区文章 (无评审/无 DOI/难验证) 与 ArXiv 论文等同引用，用户无法区分"已发表学术结论"和"社区博客断言". 本模块解决"出处权威性"=互补可信度轴. ② **新模块 source_credibility.py** (~230 行纯 stdlib 零依赖，镜像 V37.9.57 hallucination_guards.py PoC 模式): **5 档 tier** (按"引用断言无需独立验证可信程度"递减): 🥇 学术同行评审 rank1 (S2/DBLP/ACL/ontology_sources 已发表有DOI可作学术结论引用) / 🥈 会议预印本 rank2 (arxiv/hf_papers 公开可引未评审结论可被推翻) / 🥉 工业实践 rank3 (github_trending/openclaw_run 官方代码可验证非学术结论) / 📝 博客 rank4 (rss_blogs/**chaspark 即 observer 点名非主流源** 个人社区撰写无评审) / 💬 社媒 rank5 (ai_leaders_x/run_hn_fixed/freight/finance 推文论坛新闻聚合时效强可靠性参差，首次引用必标注). **SOURCE_CREDIBILITY** 14 源映射 = MR-8 单一真理源 (key=jobs_registry job id + label). **公开 API**: get_credibility(source_id) (FAIL-OPEN 未知/非string → 社媒最低档 + reason=未分类来源不抛异) / format_credibility_block() (prompt 注入块, source 列表从 SOURCE_CREDIBILITY 动态生成改映射无需改函数) / list_tiers()/list_sources() + CLI --list/--sources/--block/--source. ③ **wire 进 dream + evening (同 DREAM_HG_GUARD/get_guard 既有模式)**: kb_dream.sh 加 DREAM_CREDIBILITY 变量 (lazy import + FAIL-OPEN，同款 5 注入点 REDUCE/DEEP/DEEP_RETRY/WIDE_RADAR/WIDE_RADAR_RETRY system prompt 末尾 append ${DREAM_HG_GUARD}${DREAM_CREDIBILITY}) + kb_evening_collect.py `from source_credibility import format_credibility_block` + build_evening_prompt 注入 (在 get_guard LEVEL_5 之后/今日笔记 section 之前). 互补设计: HG 守内容真实性+跨域推论可信度，credibility 守出处权威性. ④ **设计取舍**: 设计 (unfinished #1) 枚举 [学术同行评审/工业实践/会议预印本/博客/社媒]，本模块 5 个 tier 名严格遵循但 rank 按"引用断言可信度"重排为 学术(1)>预印本(2)>工业(3)>博客(4)>社媒(5)，理由预印本是学术可引内容. freight/finance 新闻聚合归 💬 社媒档 (无 DOI/时效强). ⑤ **56 新单测 10 类** test_source_credibility.py: TestCredibilityTiers(6) + TestGetCredibility(7) + **TestSourceCoverage(7 MR-8 drift guard — SOURCE_CREDIBILITY ↔ jobs_registry 14 内容源 id+label 双匹配 + 无 orphan)** + TestChasparkFlagged(4 observer proposal #2 锚点) + TestFormatBlock(9) + TestCli(5) + TestDreamWiring(6 含 5 注入点 + 反 inline 守卫) + TestEveningWiring(5 含位置守卫) + TestAutoDeployFileMap(2) + TestSourceLevelGuards(7). **反向验证已确认守卫真有效**: sabotage chaspark→学术同行评审 → 4 failures; 删 ontology_sources 源 → drift guard fail. 还原后 56/56 全过. ⑥ **不立 INV** (PoC 阶段，镜像 V37.9.57 hallucination_guards 同款 — 56 source-level 测试作守卫，INV-SOURCE-CREDIBILITY-001 留 Mac Mini 部署一周观察后立). auto_deploy FILE_MAP + full_regression 接入. ⑦ **累计**: 102→**103 suites (+1)** / 3683→**3739 tests (+56)** / 0 fail / governance v3.52 不变 (无新 INV) / 85 invariants / 790 checks 不变 / 21 meta rules / 安全 95/100 / VERSION 0.37.9.68 不变 (PoC 观察性功能不 bump). ⑧ **Mac Mini 部署后预期**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 (b) auto_deploy 2min 轮询同步 source_credibility.py 到 $HOME (c) 下次 22:00 kb_evening + 03:00 kb_dream cron 触发时推送应**首次出现** [可信度: <等级>] 标注，尤其 🏠 华为茶思屋科技 引用带"博客级，需独立验证"提示 — 用户视角验证 observer proposal #2 真生效. ⑨ **元价值 (MR-7 + V37.9.83 AI Partnership 闭环延续)**: V37.9.84 observer 上线 → 5/28 自己发现 dream 链式幻觉 + 来源可信度盲区双提议 → V37.9.89 实施 LEVEL_6 (跨域推论) → **V37.9.98 实施 proposal #2 (来源可信度)**. observer 从"被动评分"升级为"主动提议产品改进"，Claude 落地 = "系统自我成长 = 用户视角机器化"第二原理硬实证. 与 hallucination_guards (内容真实性) 构成双可信度轴框架. 下次候选: 6/8 后 services flip (V37.9.99+) / INV-OBSERVER-001 / INV-SOURCE-CREDIBILITY-001 (本模块一周观察后) / LEVEL_6 dream + ai_leaders 观察 (需 Mac Mini 数据). |
| V37.9.97 | 2026-06-01 | **services_to_launchd Plan B 升级 machine_sync — convergence framework 最后一个 alert_only spec 收尾 + per-spec dry-run (dry_run_default 字段功能化) + INV-CONVERGENCE-SERVICES-001 扩 +9 checks**（V37.9.96 合并后用户问"下一个遗留任务" → 选 #8）— ① **触发**: services_to_launchd (V37.9.25 第 5 spec) 是 5 个 convergence spec 中唯一未升 machine_sync 的 (jobs_to_crontab + kb_sources_to_index 已在 V37.9.58 Plan B 终态). 自 5/4 起 alert_only 4 周观察 (5/4-6/1) zero drift, Mac Mini 6/1 实测 `declared=3 observed=3 no drift` 基线干净. ② **核心 framework 增强 — per-spec dry-run (dry_run_default 字段从"纯文档性"升级"功能性")**: 真问题 = V37.9.58 切关后全局 `_is_dry_run()` 默认 real-apply, spec 的 `dry_run_default` 字段 apply 路径根本不读 (verify_convergence 传 dry_run=None → 全局 env). 但 services bootstrap blast-radius 高于 crontab/kb_embed, Plan B 应先 dry-run 观察一周. 新 `_resolve_dry_run_for_spec(spec)` 三档优先级: (1) CONVERGENCE_DRY_RUN env 显式设 → operator override 胜 (2) spec convergence_method.dry_run_default → per-spec 默认 (3) framework 默认 False. verify_convergence 改传 `dry_run=_resolve_dry_run_for_spec(spec)`. **效果**: services (dry_run_default: true) 先 dry-run, jobs/kb (dry_run_default: false) 保持 real-apply, 全部无需 env var. **向后兼容**: jobs/kb 行为不变 (实测 apply_dry_run=False). dry_run_default 从死字段升级为可让 spec 独立 staging 的活字段 (Plan B 渐进路径正需要). ③ **新 apply 函数 `_apply_services_launchctl_bootstrap`** (per-service, 镜像 `_apply_jobs_to_crontab_per_entry` NOT one-shot): 对每个 missing label 查 services_registry 的 plist (新 helper `_load_services_registry_index` label→service 映射), real 模式跑 `launchctl bootstrap gui/<uid> ~/Library/LaunchAgents/<plist>` (镜像 restart.sh V37.9.13 bootstrap fallback), dry-run 发 "DRY-RUN would bootstrap: ...". 注册到 `_APPLY_FUNCTIONS` (V37.9.24 named-dispatch 第 3 个 apply 函数). **只 bootstrap missing labels** (已加载 service 不碰 — convergence 只传 not-in-list, 自动满足 V37.9.25 "先检查是否已 list 中" 设计). **不做 bootout** (移除运行 service 是 operator 决策, 与 bootstrap 不对称, 非安全 auto-sync). FAIL-OPEN per-service (缺 plist 字段 / plist 文件不存在 / subprocess timeout / 非零 exit 全 → 单条 error, 其他 service 继续). ④ **convergence_ontology.yaml services spec**: drift_action alert_only → machine_sync + convergence_method planned → implemented + apply_function: services_launchctl_bootstrap + dry_run_default: true. meta version 0.8 → 0.9-services-machine-sync-dry-run, status → three_machine_sync_services_dry_run_first. ⑤ **26 新单测 test_convergence.py 3 类**: TestResolveDryRunForSpec(8 三档优先级 + env override 胜 + jobs/kb 向后兼容 + services per-spec dry-run) + TestApplyServicesLaunchctlBootstrap(10 含 dry-run would-bootstrap / 真 mock launchctl 成功 + 非零 exit + 缺 plist 文件 + 未知 label + 端到端 verify_convergence dry-run) + TestV37997ServicesSourceGuards(7 含 _apply/_load/_resolve 定义 + dispatch 注册 + bootstrap 命令形态 + 反 bootout 守卫). 反向: mock subprocess 验证 fail-loud/pass/dev-safe. dev 实测 services verify_convergence → drift_action=machine_sync + apply_dry_run=True + 3 条 "DRY-RUN would bootstrap" + 0 errors. ⑥ **INV-CONVERGENCE-SERVICES-001 扩 +9 declaration checks** (V37.9.96 INV-PROXY-PLIST-ENV-001 同 session 后的第 2 个治理交付): apply_function / dry_run_default / 3 个新函数定义 / _APPLY_FUNCTIONS 注册 / verify_convergence per-spec dry-run / bootstrap 命令形态 / v37_9_97_changelog 段. runtime python_assert 加跑 3 个 V37.9.97 测试类. governance v3.51→v3.52. ⑦ **累计**: 102 suites 不变 (test_convergence 已注册) / 3657→**3683 tests (+26)** / 0 fail / governance v3.51→v3.52 / 85 invariants 不变 (INV-CONVERGENCE-SERVICES-001 扩展非新增) / 781→**790 checks (+9)** / 21 meta rules 不变 (MR-17 复用) / 安全 95/100 / VERSION 0.37.9.68 不变. ⑧ **Mac Mini 部署后预期**: (a) git fetch+reset 同步 (b) governance audit cron 07:00 跑 services_to_launchd — 因 dry_run_default: true 走 **dry-run** (declared=3 observed=3 no drift 时零动作; 若某 service 真宕/未 bootstrap → log "DRY-RUN would bootstrap: launchctl bootstrap gui/<uid> .../X.plist" 但**不真执行**, 观察一周确认动作正确) (c) **V37.9.98+ 候选**: services dry-run 一周观察后 flip dry_run_default: false 真激活 (镜像 V37.9.58 jobs/kb 切关), 此后 5 spec 中 3 个 machine_sync 真激活 (providers/openclaw 留 alert_only 因 API key/version 无法 machine provision). ⑨ **元价值 (convergence framework 收尾 + V3 路标)**: V37.9.19 起 5 个 convergence spec 历经 V37.9.20/22/24/25/58/97 演进, V37.9.97 让最后一个 alert_only spec 进入 machine_sync, framework 从"机器可检测"全面升级"机器可同步". per-spec dry-run 增强让 Plan B 渐进路径 (alert_only → machine_sync+dry-run → real) 可按 spec blast-radius 独立 staging — V3 路标 `pip install ontology-engine` declarative convergence 的核心能力. 同日 V37.9.96 (proxy plist INV) + V37.9.97 (services Plan B) 双治理交付. 下次候选: 6/2-6/3 LEVEL_6 dream + ai_leaders 新账号观察窗口 ready / services dry-run 一周观察后 V37.9.98 flip / INV-OBSERVER-001 (V37.9.84 一周后). |
| V37.9.96 | 2026-06-01 | **INV-PROXY-PLIST-ENV-001 立 governance — proxy plist ARK env 守卫 (V37.9.91 Doubao expert_escalate 真生产缺口闭环, 镜像 V37.9.54 adapter plist 模式) + audit_metadata 计数漂移修 + 自洽守卫**（周一开工选 #19，观察窗口型硬卡 LEVEL_6/ai_leaders 新账号要等 6/2-6/3）— ① **触发**: V37.9.91 Doubao expert_escalate 真生产闭环时实测发现 proxy plist 缺 ARK env，手动从 adapter plist 复制 ARK_API_KEY + ARK_ENDPOINT_ID + bootout/bootstrap 才生效。V37.9.91/92 收工已登记 INV-PROXY-PLIST-ENV-001 为候选（Doubao 自己在 escalate 响应中识别风险 "proxy plist drift: periodic auto-deploy may overwrite manually injected ARK_API_KEY"）。**真缺口**: V37.9.54 INV-PLIST-ENV-001 只守 adapter plist；proxy daemon (com.openclaw.proxy.plist) 跑 tool_proxy.py，其 expert_escalate 自定义工具分支 (V37.9.91 wiring) lazy-import expert_escalation.py 经 Volcengine Ark 调 Doubao 用 ARK_API_KEY (DOUBAO_API_KEY_ENV) + ARK_ENDPOINT_ID (DOUBAO_ENDPOINT_ID_ENV)。若 Mac Mini 重装 / auto_deploy 覆盖 plist → proxy ARK env 静默丢失 → expert_escalate 返回 "ARK_API_KEY not set" silent failure (用户感知不到 PA 没真调 Doubao)。**注意 ARK_ENDPOINT_ID 不是任何 provider 的 api_key_env (是 endpoint ID 不是 key)，INV-PLIST-ENV-001 的 api_key_env 集合检查覆盖不到它 → 本 INV 填补真缺口**。② **INV-PROXY-PLIST-ENV-001** (id=proxy-plist-env-must-contain-ark-expert-escalate-keys, meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime], **7 checks**): 5 file_contains (tool_proxy.py `name == "expert_escalate"` 分支 / expert_escalation.py `DOUBAO_API_KEY_ENV = "ARK_API_KEY"` + `DOUBAO_ENDPOINT_ID_ENV = "ARK_ENDPOINT_ID"` 双绑定 / fail-loud 指引 "configure in plist EnvironmentVariables" / V37.9.96 marker) + 2 python_assert (declaration 依赖链可解析 proxy→expert_escalation→ARK env / **runtime --full mode 真读 ~/Library/LaunchAgents/com.openclaw.proxy.plist via plistlib，dev 无 plist silent pass / Mac Mini 缺 ARK env fail-loud**，镜像 V37.9.54 dev-safe 模式)。③ **22 新单测 5 类** test_v37_9_96_proxy_plist_env.py: TestProxyPlistEnvGovernance(8 yaml 字面量守卫: INV declared / MR-4+high+双层 / plistlib+com.openclaw.proxy.plist / ARK 双 env / dev-safe plist_path.exists() / blood_lessons V37.9.91 + launchd 不继承 / 7 checks / V37.9.96 marker) + **TestProxyPlistEnvRuntimeBehavior(5 直接从 yaml 提取真 runtime check code 用 exec + patched HOME + 假 plist 验证, 零 drift)**: 缺 ARK_ENDPOINT_ID → fail-loud / 无 ARK env → fail-loud / 完整 → pass / 无 plist → dev-safe silent pass / 空 EnvironmentVariables → fail-loud + TestProxyPlistEnvDeclarationCheck(1 真 exec declaration 对真仓库) + TestProxyPlistEnvDependencyChain(5 生产依赖链 tool_proxy expert_escalate → expert_escalation ARK env + fail-loud 指引) + TestV37996Marker(3 标记 + **test_actual_invariant_count_matches_metadata 自洽守卫**)。④ **顺手修 audit_metadata 计数漂移 (开工健康检查发现)**: total_invariants 83 → 85 — V37.9.94 +1 INV-CROSS-ENV-PATH-001 从未记入 yaml audit_metadata changelog 留下 stale -1 (真实 grep `- id: INV-` = 84，+1 mine = 85)；total_checks 755 → 781 — 对齐 governance_checker 运行时权威计数 ("781 checks pass"，修 V37.9.86 起多版本累积漂移)。**新增 test_actual_invariant_count_matches_metadata 自洽守卫**让 audit_metadata.total_invariants 永不再脱离真实 grep 计数 (MR-7 治理自观察 framework 级改进)。⑤ **反向验证已确认守卫真有效**: 构造假 proxy plist 缺 ARK_ENDPOINT_ID → runtime check 正确 AssertionError fail-loud；完整 ARK env → pass；无 plist → silent pass。runtime check 真能抓 V37.9.91 silent-failure 场景。⑥ **接入 full_regression.sh** `v37_9_96_proxy_plist_env` suite 紧随 V37.9.95 ai_leaders。test_convergence.py `test_audit_metadata_version_v3_36_or_later` alternation 列表加 `version: "3.51"` (version bump 正常连带)。⑦ **累计**: 102 suites (full_regression 实测 +1 net) / 3635→**3657 tests (+22)** / 0 fail / governance v3.50→v3.51 / 84→**85 invariants** (+1 INV-PROXY-PLIST-ENV-001，含修 V37.9.94 漏记 +1) / **781 checks** (audit_metadata 对齐运行时权威计数) / 21 meta rules 不变 (MR-4 复用) / 安全 95/100 / VERSION 0.37.9.68 不变 (governance 工作不 bump)。⑧ **Mac Mini 部署后预期**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 (b) governance audit cron 07:00 跑 INV-PROXY-PLIST-ENV-001 — dev 无 plist 时 silent pass，**Mac Mini --full mode 真读 com.openclaw.proxy.plist 验证 ARK_API_KEY + ARK_ENDPOINT_ID 都在** (c) **未来若 auto_deploy 覆盖 proxy plist 丢失 ARK env / Mac Mini 重装漏注入 → governance audit 立即 fail-loud + Discord #alerts 告警**，不再等用户发现 PA 不会真调 Doubao。⑨ **元价值 (MR-4 silent-failure 上游预防 + V37.9.91/92 候选兑现)**: V37.9.13 (launchd 双管理) → V37.9.53 (adapter plist 缺 ARK) → V37.9.54 (INV-PLIST-ENV-001 守 adapter) → V37.9.91 (proxy plist 缺 ARK 手动修) → **V37.9.96 (INV-PROXY-PLIST-ENV-001 守 proxy)** — 同款 launchd plist env silent failure 第 N 次浮现后把 proxy plist 的 ARK env 持有从"手动加 + 靠记忆"升级为 governance 可监控。**Doubao 自己 V37.9.91 提议 → Claude 实施** 是 V37.9.83 AI Partnership Framework "expert backend 复杂判断 → 落地" 的闭环延续。同时 audit_metadata 自洽守卫消除了"计数靠人记得同步"的 MR-7 盲区。下次候选: 周一 #32 持续制度化 / 6/2-6/3 LEVEL_6 dream + ai_leaders 新账号活跃度观察窗口 ready / INV-OBSERVER-001 (V37.9.84 一周观察后) / 外部评审 #12 check 口径深度 reconciliation (688 grep vs 781 runtime 语义统一)。 |
| V37.9.95 | 2026-06-01 | **ai_leaders_x 多元化扩展 19→31 跨 12 派别 (周一 #32 用户视角反馈第一次正向兑现, V37.9.92/93/94 后同 session 第 4 阶段)** — ① **触发**: V37.9.94 完成后用户做周一原则 #32 用户视角观察 30min, 反馈 "系统已经比较稳定了, 建议后续可以加入更多 ai_leaders_x 的观点, 尤其是更多 AI 大神的不同观点". **#32 制度第一次产生 actionable 产品反馈** (V37.8.11 立 #32 后首次), 验证 framework 演进 "用户视角观察" 真有效. ② **现状 audit**: ai_leaders_x 当前 19 accounts 偏 OpenAI 主流 (8/19) + Palantir/Ontology 集中 (7/19), 缺 AI Safety 派 (Yudkowsky/Hinton) / Anthropic 派 (Dario/Jack Clark/Olah) / DeepMind 派 (Hassabis) / 开源派 (Soumith/HF) / Robotics (Abbeel) / 学术伦理派 (Fei-Fei Li) / 非美企背景架构创新 (Yi Tay). 视角偏 → 推送内容也偏. ③ **scope (用户选 A 加全部 12 候选)**: LEADERS 列表 19 → 31 accounts 跨 **12 派别**: (a) OpenAI 主流派 5 (+drfeifei 移入) (b) Meta/开源派 3 (+soumithchintala+ClementDelangue 新) (c) NVIDIA/Hardware 1 (DrJimFan) (d) **Anthropic/Safety 派 3 (DarioAmodei+jackclarkSF+ch402 全新)** (e) **DeepMind 1 (demishassabis 新)** (f) **AI Safety 极致悲观派 1 (ESYudkowsky 新)** (g) **元老派 1 (geoffreyhinton 新, 2024 Nobel)** (h) **学术应用派 1 (AndrewYNg 新)** (i) **Robotics 1 (pabbeel 新)** (j) 评测+抽象 2 (fchollet+swyx) (k) Agent 工具 1 (hwchase17) (l) Symbolic 1 (GaryMarcus) (m) **架构创新派 1 (YiTayML 新, Reka, 非美企)** (n) Graph/KG 2 (Leskovec+Witbrock) (o) 企业 Ontology 派 3 (PalantirTech+AlexKarp+ShyamSankar) (p) 形式本体论奠基 4 (BarrySmith46+gaborguizzardi+pascal_hitzler+IanHorrocks). ④ **MAX 调整**: MAX_PER_PERSON 5→3 (更多人, 每人少, 多元化优先) + MAX_TOTAL 30→40 (raw capacity 96 → top 40 LLM input, 真过滤 vs always-min). ⑤ **V37.8.4 INV-X-001 (X 账号健康) 兼容设计**: ai_leaders_x 已有 `[ai_leaders] WARN: $handle 解析异常` 容错路径, 僵尸账号 fetch 0 条会自动 log WARN 不崩 (vs finance_news 需要 ZOMBIE 显式检测). 新增 12 账号若有僵尸将通过此机制自动暴露, V37.9.96+ 候选评估 promote 同款 ZOMBIE detection 到 ai_leaders_x. ⑥ **14 新单测 5 类** test_v37_9_95_ai_leaders.py: TestV37_9_95_LeadersExpansion(6 含 ≥31 守 / 无重复 / V37.9.95 marker / 原 19 全保留向后兼容 / 新 12 全在 / 14 派别字符串可见) + TestV37_9_95_LimitAdjustments(3 MPP=3 + MT=40 + budget 数学健全 raw>2×MT) + TestV37_9_95_BashSyntaxAndZombieTolerance(2 bash -n + WARN 路径保留) + TestV37_9_95_SourceLevelGuards(3 原则 #32 + AI 大神 + V37.8.4 INV-X-001 + 12 派别 header). **反向 sabotage subprocess 真跑**: 移除 demishassabis 单 entry → 2 failures, 还原 0. ⑦ **接入 full_regression.sh** `v37_9_95_ai_leaders` suite 紧随 V37.9.94 cross_env_path_scanner. ⑧ **累计**: 100→101 suites (+1) / 3621→**3635 tests (+14)** / 0 fail / governance 81 invariants 不变 (V37.9.95 是数据扩展不立新 INV) / 771 checks 不变 / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.95 是 source 配置扩展, 不涉及 capability 升级). ⑨ **Mac Mini 部署后预期**: (a) auto_deploy 2min 轮询同步 jobs/ai_leaders_x/run_ai_leaders_x.sh (b) 下次 09:00 或 21:00 cron 触发应**首次**抓 31 accounts (12 新含 Hassabis/Dario/Yudkowsky/Hinton/Fei-Fei/etc) (c) 若某些新账号是僵尸 (V37.8.4 教训) → log `[ai_leaders] WARN: $handle 解析异常` + fetch_stats 含 0 条 → 操作者评估是否从列表移除 (d) 推送 WhatsApp/Discord "🧠 AI Leaders 技术洞察" 应**首次含跨派别观点对比** — 用户视角原则 #13 第 N 次硬实证空间. ⑩ **元价值 — 原则 #32 制度第一次正向兑现**: V37.8.11 立 #32 (周一用户视角观察 30min) 时担心"会不会成为形式主义". V37.9.95 是该制度上线后**第一次产生 actionable product feedback** — 用户观察"AI 大神不同观点不足"→ Claude 实施 12 账号扩展 + 多元化设计. **#32 不是负担, 是 framework 演进的"用户视角机器化"的实操路径**. 与 V37.9.83 第二原理"系统自我成长 = 用户视角机器化"形成完整闭环: V37.9.84 Observer 自动机器化用户视角 + V37.9.92-94 Observer 自我演化 + V37.9.95 用户视角观察驱动产品多元化 = framework 三层成长链路全打通. 同日 V37.9.92/93/94/95 四阶段同 session 是 framework 健康演进节奏的硬实证. 下次候选: V37.9.96 Mac Mini 部署后 1-2 天观察新账号活跃度 + 评估 ZOMBIE detection promote / 周一 #32 持续制度化. |
| V37.9.94 | 2026-06-01 | **MR-15 framework 化 INV-CROSS-ENV-PATH-001 + V37.9.92 血案文档 (V37.9.92→93→94 三阶段同 session 闭环, scanner 首扫即抓 V37.9.91 隐藏 5th near-miss)** — ① **触发**: V37.9.93 完成后用户选方向 D "B + C 一同做" — B = MR-15 第 4 次演出 (V37.9.56h/76h/78h/92) 已达门槛, 立 framework 级 scanner 防 5th occurrence. C = 写 V37.9.92 血案案例文档. 同 session 双交付. ② **B — cross_env_path_scanner.py + INV-CROSS-ENV-PATH-001** (~250 行 AST scanner + 39 单测 + 9 governance checks): scanner 用 ast.walk 扫所有 `_resolve_*_path` 函数 + 任何含 `os.path.expanduser("~/<config>.yaml|.yml|.json|.md")` + script-adjacent fallback (`os.path.dirname(os.path.abspath(__file__))`) 模式但缺 `os.path.expanduser("~/openclaw-model-bridge/<same_file>")` canonical 的函数. **FAIL-CLOSE**: 任一 violation → exit 1. EXCLUDED_FILES 排除 scanner 自身 + V37.9.67 sister scanner (cross_os_quirk_scanner.py). test_*.py 自动排除. config 文件 suffix 守 yaml/yml/json/md, 跳过 .log/.py/.sh 和 ~/.kb/~/.openclaw/ 等运行时路径 (不需 canonical). ③ **首扫即抓 V37.9.91 expert_escalation.load_status 隐藏第 5 次 near-miss**: `load_status` 3 candidates `$kb_dir/X + $HOME/X + script-adj/X`, 后两个在 Mac Mini 当 expert_escalation.py deployed 到 $HOME 时**重合** (V37.9.76-hotfix 同款 PATH 重合 bug). 真生产位置 `$HOME/openclaw-model-bridge/status.json` 漏. 顺手修 — 加 4th candidate canonical, V37.9.92 同款修复模式. ④ **INV-CROSS-ENV-PATH-001** (meta_rule=MR-15, severity=high, verification_layer=[declaration, runtime], **9 checks**): 5 declaration (scanner V37.9.94 marker + FAIL-CLOSE + MR-15 引用 + 4 血案版本 python_assert + EXCLUDED_FILES 守 sister scanner + CONFIG_FILE_SUFFIXES 4 类) + 2 runtime python_assert (subprocess 跑 scanner --scan 0 violations + 39 单测全过). 全部 ✅. ⑤ **39 新单测 7 类** test_cross_env_path_scanner.py: TestIsConfigPath(9 含 yaml/yml/json/md ✓ + log/py/sh/hidden/canonical-itself ✗) + TestHasScriptAdjacentPattern(4) + TestScanFunctionBodyViolations(7 含 compliant 不报警 + 缺 canonical 必报 + 非 resolver 不误报 + 仅 .log skip + .kb skip + 多 config 各自检查 + partial canonical 仅 unclear 报) + TestScanFileIntegration(3 含 clean / violating / SyntaxError silent skip) + TestScanRepoEndToEnd(4 含**当前 repo 0 violations**) + TestCliBehavior(3 clean 0 / file missing 2) + TestReverseValidation(2 **sabotage daily_observer 真 resolver 抓住**, 还原 0) + TestV37_9_94_SourceLevelGuards(8). **反向 sabotage subprocess 真跑**: 移除 daily_observer canonical 候选 → exit 1 + "1 violation caught", 还原 → exit 0. ⑥ **C — `ontology/docs/cases/v37_9_92_observer_path_blood_case.md`** (~370 行 综合 case doc): 含 TL;DR / 影响 / 最小修复 (V37.9.92 + V37.9.93 + V37.9.94 三阶段) / 时间线还原 / 完整因果链架构图 (ASCII 100+ 行覆盖 V37.9.84 上线 → V37.9.88 引入 → 5 天潜伏 → 6/1 复盘 → V37.9.92/93/94 三阶段闭环) / 三层根因 (触发器 V37.9.88 path / 放大器 双 silent 协同 / 掩护者 设计承诺无 INV 守) / 多条件组合分析 / 元教训 5 条 (MR-15 第 4 次硬实证 / MR-7 最高境界 / 设计承诺 vs 生产现实 5 天潜伏 / MR-4 双重 silent 新形态 / 三阶段同 session 闭环节奏) / 相关 INV+MR 关系表 / 防御链路总览 / 历史经验链对照 (8 个其他案例) / 反思方法论 "谁来观察观察者" 元元层洞察. V3 路标"话语权输出"素材, 类似 audit_is_regression_not_prevention.md 立场型 + 实证型. ⑦ **接入 full_regression.sh** `cross_env_path_scanner` suite 紧随 V37.9.67 cross_os_quirk_scanner. ⑧ **累计**: 99→100 suites (+1: cross_env_path_scanner) / 3582→**3621 tests (+39)** / 0 fail / governance v3.50→v3.50 (内涵扩) / 80→81 invariants (+1 INV-CROSS-ENV-PATH-001) / 762→771 checks (+9) / 19 meta rules 不变 (V37.9.94 复用 MR-15) / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.94 是 framework 化 + 文档化, 不涉及 capability semantics 升级). ⑨ **Mac Mini 部署后预期**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 (b) auto_deploy 2min 轮询同步 cross_env_path_scanner.py + expert_escalation.py 到 $HOME (c) `python3 ~/cross_env_path_scanner.py` 应输出 `✅ all resolver functions include Mac Mini canonical path (MR-15 5th occurrence prevented)`. (d) governance audit cron 07:00 跑 INV-CROSS-ENV-PATH-001 应全 9 checks ✓ (e) **未来任何新 _resolve_*_path 函数漏 canonical → scanner 立即抓 + governance audit fail + CI 阻塞 PR**. ⑩ **元价值 (MR-15 framework 化 + V3 路标"反思转化为机制" 关键里程碑)**: MR-15 已 4 次演出 (V37.9.56h/76h/78h/92) 单点修复堆积, V37.9.94 立 framework 把模式预防机器化. 首扫立即抓出 V37.9.91 expert_escalation 第 5 次 near-miss 修复 — **framework 价值在 commit 第一天就已硬实证, 不是空头承诺**. 同 session V37.9.92 (修真问题) → V37.9.93 (Observer 自我修复) → V37.9.94 (framework 化 + 文档化) 是 V3 路标"反思转化为机制" 完整三阶段 — 每个版本基于上一个版本暴露的新问题, 整体闭环把 5 天潜伏血案转化为永久预防 + 永久记录. **"修血案 → 立 framework → 写案例" 三件套同 session 完成**, 这是项目演进 framework 化的健康节奏硬证据. 未来 V37.9.95+ 候选自动: INV-OBSERVER-001 (一周观察 V37.9.92 + V37.9.93 稳定后立 — 守 Observer 全契约) + INV-OBSERVER-SAMPLING-001 (一周观察 V37.9.93 smart sampling 后立) + INV-PROXY-PLIST-ENV-001 (Doubao 提议, V37.9.91 闭环时已登记). |
| V37.9.93 | 2026-06-01 | **Observer 采样 false-positive 修复 — Smart head+tail sampling + CRITIQUE_SYSTEM 明示采样 (V37.9.92 后用户视角"下一个遗留问题"驱动, V37.9.84 Observer 自我限制发现 + 修复双闭环)** — ① **触发**: V37.9.92 完成后用户问"下一个遗留问题?" 选方向 A "Dream truncation 调查". 5/31 Observer LLM critique 报 `[MED] dream 输出截断 (末尾为 'AgentScope 1')`. 取证发现 5/31 dream 文件实际 14750 bytes / 6782 chars **完整 4 段 + `*Generated by kb_dream.sh v2 ...*` footer**, 5/30 + 6/1 同款完整. **Dream 没 bug — Observer 在误报**. ② **真根因 (MR-4 silent-failure 新变种)**: `daily_observer._read_file_sample` `MAX_SAMPLE_CHARS=2000` 只截前 2000 chars 给 LLM 看 (`return content[:max_chars], len(content)`). 6782 chars dream 第 2000 个字符位置恰好在 🔗 隐藏关联第 2 条 "MMKU-Bench 与 AgentScope 1.0" 中间, LLM 看到自己输入末尾停在 "AgentScope 1" 合理推断 "文件被截断" → 报 false positive. **Observer 不告诉 LLM "这是采样"**, LLM 唯一能看到的就是截断点 → 误判. ③ **元层洞察**: V37.9.84 Observer 设计目标"用户视角机器化 → 系统自我成长" **意外验证自己** — Observer 太尽职尽责 (V37.9.92 5 天内首次 surface 真问题), 连**自己的输入采样限制**都暴露了. 这是 MR-7 治理自观察的新形态 — 治理工具用自己 critique 自己暴露自己 bug. ④ **结构修复 双层防御**: (Part 1 Smart Sampling) `_read_file_sample` 改为 head + 中间 marker + tail 模式: 文件 ≤ MAX_SAMPLE_CHARS 返回完整 (V37.9.84 行为保留) / 文件 > MAX 返回 `content[:SMART_SAMPLE_HEAD_CHARS=1400] + marker + content[-SMART_SAMPLE_TAIL_CHARS=500]` 三段拼接 ≤ MAX_SAMPLE_CHARS 总预算. Marker 文字 `[...N chars omitted from middle — this is sampling for LLM evaluation, NOT file truncation. File is complete; head + tail shown below.]` 极度明示. LLM 能看到文件**开头 + 结尾 (含 `*Generated by kb_dream.sh v2 ...*` footer)** 通过 footer presence 验证文件完整性. 防御边界: `len(sample) > max_chars` 时 trim head 保证总不超 budget. (Part 2 Critique Prompt 明示) `CRITIQUE_SYSTEM` 末尾新增 "⚠️ 采样说明 (V37.9.93)" 段 (~250 chars), 显式告知 LLM: (i) 超长输出会以 head+marker+tail 采样形式呈现 (ii) 见到 `sampling for LLM evaluation` marker 时**不要**误判为文件截断 (iii) 真截断判定双条件: footer 缺失/末尾中断 OR 文件长度低于 DEEP≥1500/WIDE+RADAR≥2500/Overview≥300 最低阈值. ⑤ **18 新单测 3 类 + 反向验证守卫真有效**: `TestV37_9_93_SmartSampling` (7 含短文件返回完整 / boundary MAX_SAMPLE 不采样 / 长文件 head+marker+tail 守卫 / marker omitted count 精确 / sample 大小 ≤ MAX 不变量 / **5/31 dream 血案场景复现守卫 footer 必可见** / missing file 兼容) + `TestV37_9_93_CritiqueSystemSamplingClarification` (4 V37.9.93 marker / 采样字 / NOT file truncation 字面 / footer 验证引导 + DEEP/WIDE+RADAR 阈值) + `TestV37_9_93_SourceLevelGuards` (7 V37.9.93 marker / 3 常量定义 / marker 文本明示 / `_read_file_sample` 用 head+marker+tail concat / CRITIQUE_SYSTEM V37.9.93 段 / 血案引用 AgentScope+V37.9.92 / 常量 sum ≤ MAX 不变量). **反向 sabotage 2 处**: (1) 退回 `content[:max_chars]` → 4 failures (2) 移除 CRITIQUE_SYSTEM 采样说明段 → 2 failures. 还原后 166/166 全过. ⑥ **不立 INV** (V37.9.93 PoC 阶段, V37.9.94+ 一周观察 Mac Mini 真激活后立 INV-OBSERVER-SAMPLING-001 守 smart sampling 必须激活). ⑦ **累计**: 99 suites 不变 / 3564 → **3582 tests (+18 V37.9.93)** / 0 fail / governance 762 checks 不变 / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.93 是 Observer 自我限制 false positive 修复, 不涉及业务语义升级). ⑧ **Mac Mini 部署后预期行为**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 (b) auto_deploy 同步 daily_observer.py 到 `$HOME` (c) 下次 06:30 cron 触发 LLM critique 看 dream 时**首次**能看到 footer `*Generated by kb_dream.sh v2 ...* every signal counts.*` → 不再误报 truncation (d) 用户在 daily_critique markdown 中**不再**看到 `[MED] dream 输出截断` false positive. ⑨ **元价值 (MR-7 治理自观察新粒度 + V37.9.84 Observer 自我修复闭环)**: V37.9.84 设计承诺"系统自我成长 = 用户视角机器化" — V37.9.93 是 Observer **自己发现自己的限制** 然后被修复. 这是 MR-7 governance-execution-is-self-observable 的最高境界 — 治理工具不只治理别人, 还能发现自身 bug 推动自身改进. **闭环时间 < 2h 从用户视角原则 #28 取证 → 真根因发现 → 双层防御实施 → 18 新单测 + 反向验证 → push**. 这是 V37.9.83 第二原理"系统自我成长"的硬实证. V37.9.92 同 session 的 V37.9.84 闭环让 Observer 可见, V37.9.93 同 session 让 Observer 自我改进 — 三阶段 (V37.9.84 上线 → V37.9.92 闭环承诺 → V37.9.93 自我修复) 在 1 个 session 内连环兑现, framework 演进的"反思转化为机制"硬证据. |
| V37.9.92 | 2026-06-01 | **V37.9.88 Mac Mini 路径修复 + V37.9.84 status.json 闭环 (周一 Observer 数据驱动复盘 → 同 session 双 bug 闭环)** — ① **触发**: 2026-06-01 周一开工选 Observer 数据驱动复盘 (V37.9.84 上线 5 天数据), 通过 Mac Mini 取证发现两个真问题: (a) V37.9.88 LAYER 1 registry filter 在 Mac Mini 真生产**降级了** — `~/daily_observer.log` 连续 5 天 (5/29-6/1) `WARN: V37.9.88 registry filter fallback — jobs_registry.yaml not loadable, using full JOBS_SUBDIRS`. V37.9.88 三档 candidates 全 miss 因为 auto_deploy FILE_MAP 不把 `jobs_registry.yaml` 拷到 `$HOME`, 真实位置是 `$HOME/openclaw-model-bridge/jobs_registry.yaml`. (b) V37.9.84 设计承诺 `quality.observer` **三方共享意识锚点**写入 status.json, 但 5 天累计 `quality.observer = {}` 空字典 — daily_observer.py 从未写入 status.json, observer 分数对 PA/kb_status_refresh/health_check 完全不可见. ② **MR-4 silent-failure 双重演出**: 单测/治理/preflight 全过 + observer log 显示 `[observer] critique complete (score=5)` 成功 + daily_critique markdown 正常生成 + score_history.jsonl 正常 append, 但**生产 LAYER 1 失效用户看不见 (只有 stderr WARN)** + **status.json 闭环承诺零兑现用户看不见 (PA 无法读 observer 分数)**. 都是"设计承诺与生产现实之间 5 天潜伏 gap". ③ **MR-15 (deployment-layout-must-be-tested-on-target) 第 4 次演出**: V37.9.56-hotfix (top_alignment_picker `~/.openclaw/jobs/` vs FILE_MAP `~/jobs/`) → V37.9.76-hotfix (router_decide 同款 PATH+FALLBACK 重合) → V37.9.78-hotfix (health_check timeout 命令在 macOS BSD 缺失) → **V37.9.92 (daily_observer `_resolve_registry_path` 三档全 miss Mac Mini 真实位置)**. 每次都是 dev 全绿 + Mac Mini 实测才暴露. ④ **结构修复 (按原则 #28 三问最小修复)**: (Part 1 — path) `_resolve_registry_path()` candidates 列表 `[$HOME/jobs_registry.yaml, script-adjacent]` → `[$HOME/jobs_registry.yaml, **$HOME/openclaw-model-bridge/jobs_registry.yaml (V37.9.92 新)**, script-adjacent]`. 顺序: env override 最高 → $HOME root (向后兼容) → Mac Mini canonical (V37.9.92 新, 真生产路径) → script-adjacent (dev fallback). docstring 完整记录 V37.9.92 由来 + V37.9.56-hotfix 同款血案. (Part 2 — status.json closure) 新增 `_write_observer_to_status(kb_dir, target_date, overall_score, anomalies, status, job_statuses) -> bool` 纯函数 helper (~50 行): lazy import `status_update.load_status/save_status` (FAIL-OPEN ImportError 不阻塞) + 计算 anomalies_high/med + jobs_ok + 写 `quality.observer = {score, status, anomalies_high, anomalies_med, jobs_ok, jobs_total, last_run_date, last_updated_at, v37_9_92: True}` + 调 `save_status(updated_by="daily_observer", audit_action="observer_score_update", ...)` 走原子 tmpfile+os.replace (MR-9 helper compliant). 顶层 try/except Exception → FAIL-OPEN log WARN + 返回 False 不冒泡. `run()` 在 `append_score_history` 之后调一次 helper (顺序锁: V37.9.92 source-level test 守 `_write_observer_to_status` 必须晚于 `append_score_history`). ⑤ **read-only 契约修正**: V37.9.84 顶部 docstring 从 "READ-ONLY: 只读取 ~/.kb/ ... 零写入生产文件" 升级为 "READ-ONLY for production code/config: 不修改任何 job 脚本/部署/配置 ... 观察结果发布到 score_history.jsonl + daily_critique_*.md + status.json quality.observer". status.json 是 V30.4 起就是三方共享意识锚点的合法写入对象 (PA 写 feedback / cron 写 health / Claude Code 写 recent_changes), `quality.observer` 是同款机制非违反 read-only. ⑥ **27 新单测 4 类 + 反向验证守卫真有效**: `TestV37_9_92_MacMiniCanonicalPath` (6 含 Mac Mini canonical 独立检测 / $HOME root 优先 / canonical 优先于 script-adjacent / env var 最高优先 / fallback 到 script-adj / V37.9.88 paths 保留) + `TestV37_9_92_StatusJsonClosure` (8 含 helper 函数存在 / payload 完整字段 / audit_action 记录 / FAIL-OPEN ImportError / FAIL-OPEN save_status 异常 / 保留 existing quality.* 字段不 clobber / run() 调一次 / append_score_history 之前后顺序锁) + `TestV37_9_92_SourceLevelGuards` (10 含 V37.9.92 marker / Mac Mini 路径 in candidates / helper 函数定义 / run() 调用 + 顺序锁 / lazy import 在 helper 内非 module top / quality.observer key / FAIL-OPEN 模式 / MR-15 + V37.9.88 引用 / docstring 升级 / candidates 顺序锁) + `TestV37_9_92_ReverseValidation` (1 文档). **反向验证 (subprocess sabotage 真实生效)**: sabotage 1 (移除 4th candidate) → 3 failures / sabotage 2 (移除 run() write 调用) → 3 failures. 还原后 148/148 全过. ⑦ **不立 INV** (V37.9.92 Tier 2 scope 不含 governance): V37.9.84 已稳定 5 天满足"一周观察期"前置门槛, 但 V37.9.92 候选 INV-OBSERVER-001 留 V37.9.93+ (Mac Mini 部署生效 7 天后再立, 镜像 V37.9.86 reactive→preventive 路径). ⑧ **累计**: 99 suites 不变 / 3537 → **3564 tests (+27)** / 0 fail / governance 762 checks 不变 (无新 INV) / VERSION 0.37.9.68 不变 (V37.9.92 是 bug fix + design closure, 无 capability semantics 升级). ⑨ **Mac Mini 部署后预期行为**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 (b) auto_deploy 2min 轮询自动同步 daily_observer.py 到 `$HOME` (c) 下次 06:30 cron 触发应**首次**日志: `[observer] V37.9.88 registry filter: excluded 3 disabled job(s) from scan: pwc,karpathy_x,openclaw_official` + `jobs: 12 scanned` (不再是 fallback warn + 15 scanned) (d) 同时 `cat ~/.kb/status.json \| jq .quality.observer` 应**首次**含 `{score, status, anomalies_high, anomalies_med, jobs_ok, jobs_total, last_run_date, last_updated_at, v37_9_92: True}` 而非 `{}` (e) 用户在 WhatsApp 通过 PA 现在能问"今日 observer 评分多少" → PA 通过 status.json 直接读 quality.observer 答复. ⑩ **元价值 (MR-15 第 4 次演出 + V37.9.84 真正闭环)**: V37.9.84 上线 5 天后才发现两个潜伏 bug, 都是"代码层全过 + 真生产降级"模式. V37.9.92 同时闭环 V37.9.88 path bug (MR-15 框架级问题) + V37.9.84 status.json 设计承诺 (V37.9.83 三大第一性原理 方向 1 "用户视角机器化" 兑现新粒度). MR-15 候选 INV-CROSS-ENV-PATH-001 (V37.9.67 候选已登记) 当真有效 — 4 次同款血案已达立案门槛, V37.9.93+ 候选. **同时验证 V37.9.84 Observer 设计的核心价值** — 5/31 LLM critique 主动发现 "Dream 输出截断" + "stale 告警埋底" + "deep_dive 字段冗余" 三个真问题, 这正是"系统自我成长 = 用户视角机器化"的硬实证. 没有 Observer 这次 5/31 critique 在前, 我们不会有动机主动来 6/1 周一开工查 Observer. Observer 在 silent 着, 但它在 silent 中说了真话. |
| V37.9.91 | 2026-05-29 | **Expert Escalation wiring 落地 — V37.9.90-r1 部署 checklist 兑现 (代码就绪 → 真生产可用)** — ① **触发**: V37.9.90-r1 收工承诺 4 步部署 checklist (tool_proxy 加 expert_escalate 工具注入 / FILE_MAP 加 expert_escalation.py / ARK_API_KEY plist 验证 / 第一次真生产调用). 用户开工选方向 A (V37.9.90-r1 部署 checklist) 推进. 严格按原则 #28 三问: Q1 wiring 之前不存在 ✓ / Q2 V37.9.91 新引入 ✓ / Q3 最小修复 = 三处 wiring + ontology yaml + 守卫单测, 不动 expert_escalation.py 本体 (V37.9.90-r1 已完整). ② **三处 wiring** (顺序保留 V37.9.15 three_gate 同款 lazy import 模式): **(A) proxy_filters.py CUSTOM_TOOLS + TOOL_PARAMS**: 第 3 个 custom tool entry, schema 含 `question` (required string) + `backend` (optional enum [doubao, claude_pending]), description 含 6 个 SOUL 规则 12 触发词关键短语 + Doubao + PA caller / `TOOL_PARAMS["expert_escalate"] = {"question", "backend"}` 让 fix_tool_args 识别合法参数. **(B) tool_proxy.py `_execute_custom_tool` 新增 `if name == "expert_escalate":` 分支** (~80 行): 与 V37.9.15 three_gate 同款 `importlib.util.spec_from_file_location` lazy import 模式 + 双路径 fallback (脚本同目录 dev → `$HOME/expert_escalation.py` FILE_MAP 部署位置). FAIL-CLOSED 三档: ①缺 question/非 string → `{"status":"no_context"}` ②非法 backend → `{"status":"unknown_backend"}` ③模块未部署/加载失败/escalate 抛异常 → `{"status":"api_unavailable"}` 不静默崩溃. **MR-11 兑现**: `log()` 写 stderr 防 `$(...)` 命令替换污染. `ensure_ascii=False` 保留中文 (PA Qwen3 中文输出). **(C) auto_deploy.sh FILE_MAP 新增** `expert_escalation.py|$HOME/expert_escalation.py` 部署条目 (`data_clean.py` 之后, 含 V37.9.91 注释 marker 追溯). **(D) ontology/tool_ontology.yaml `custom.expert_escalate` 段** (V37.9.85 INV-AUTO-INJECT-001 守卫的"必经路径"): category=ai_consultation / resource_type=ExternalLLM / side_effects=false (read-only contract) / parameters question required + backend optional enum, 确保 `ONTOLOGY_MODE=on` (Mac Mini 生产默认) 路径下 ontology engine 也注册 expert_escalate 到 CUSTOM_TOOLS. 验证: `ONTOLOGY_MODE` ∈ {off, on, shadow} 三种模式下 expert_escalate 都正确出现在 `CUSTOM_TOOL_NAMES` / `CUSTOM_TOOLS` / `TOOL_PARAMS`. ③ **32 新单测 7 测试类** `test_v37_9_91_expert_escalate_wiring.py`: TestProxyFiltersWiring(6 含 CUSTOM_TOOL_NAMES 含 / schema 完整性 / backend enum doubao+claude_pending / TOOL_PARAMS / description 必含 Doubao+PA+至少 2 触发词) + TestToolProxyBranchGuards(9 含 V37.9.91 marker + branch 存在 + importlib.util lazy import + 双路径 fallback (script_dir then HOME) + no_context/unknown_backend/api_unavailable 三状态码 + ensure_ascii=False) + TestAutoDeployFileMap(3 含 V37.9.91 注释 marker + data_clean 回归不破坏) + TestOntologyToolSchema(6 含 yaml 声明 + side_effects=false + resource_type=ExternalLLM + question required / backend optional + **runtime subprocess 真跑 `ONTOLOGY_MODE=on` 加载 proxy_filters 断言 expert_escalate ∈ CUSTOM_TOOL_NAMES**) + TestSoulRule12Anchor(3 含 expert_escalate 工具名 + Doubao backend 标注 + 4 关键触发词 "让 Claude 看看"/"深度判断"/"帮我决定"/"拿不准") + **TestEndToEndDryRun(3 真 subprocess 跑 escalate dry_run 路径)**: question="should we adopt Doubao for production?" backend=doubao → 必须 status=dry_run + proposal 含"[DRY RUN]" + audit log JSONL append 1 行 / question="claude pending test" backend=claude_pending → 立即返回 stub 不真调 Doubao + error 含"Claude" + TestDocumentationAnchors(2 含 V37.9.91 marker in proxy_filters + design doc exists). **反向验证已确认三层守卫真有效**: sed 3 处 sabotage (`"name": "expert_escalate"` → `"EXPERT_REMOVED"` / `if name == "expert_escalate":` → `if name == "EXPERT_REMOVED_BRANCH":` / yaml `expert_escalate:` → `SABOTAGED_EXPERT:`) 一并触发 → 5 failures + 13 errors = **18 处守卫立即抓到**, 还原后 32/32 全过. ④ **接入 full_regression.sh** suite `v37_9_91_expert_escalate_wiring` 紧随 V37.9.90-r1 `expert_escalation` 之后. ⑤ **不引入 governance INV** (按 V37.9.90-r1 收工承诺"V37.9.92+ 一周观察期后立 INV-EXPERT-ESCALATION-001"). ⑥ **Mac Mini 部署后用户验证步骤**: (1) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.91 (2) auto_deploy 2min 轮询自动 cp expert_escalation.py 到 $HOME (3) `bash ~/restart.sh` 重启 proxy 让新 CUSTOM_TOOLS 生效 (4) `curl http://localhost:5002/health` 应仍正常 (5) `echo "$ARK_API_KEY"` 确认 V37.9.54 INV-PLIST-ENV-001 守卫的 env var 已注入 proxy 进程 (6) WhatsApp 第一次真生产调用: 发"让 Claude 看看 V37.9.85 INV-AUTO-INJECT-001 设计有什么风险" 给 PA → PA 应识别"让 Claude 看看"触发词 → 调 expert_escalate → 路由 Doubao → 返回 proposal + rationale + confidence + refs + PA 转发标注"(来自 Doubao Seed 2.0 Pro，V37.9.55 verified reasoning model)" (7) `cat ~/.kb/audit/expert_escalations.jsonl \| tail -1 \| jq` 验证 audit record 完整 (含 backend / status / confidence / usage.prompt_tokens_details.cached_tokens). ⑦ **CLAUDE.md 路径风险登记 V37.9.92+ 候选**: expert_escalation.py 部署到 $HOME 后 `repo_root = os.path.dirname(__file__) = $HOME/`, 但 CLAUDE.md 实际位于 `$HOME/openclaw-model-bridge/CLAUDE.md` — `load_changelog_window` 可能返回空 (status.json 在 ~/.kb 通过 DEFAULT_KB_DIR 工作 / cases_dir 通过 V37.9.12.1 ontology symlink 工作 / 仅 CLAUDE.md 路径可能错配). 若 escalate 报"no_context" → V37.9.92+ 给 expert_escalation.py 加 CLAUDE.md 三档 fallback ($HOME/CLAUDE.md → $HOME/openclaw-model-bridge/CLAUDE.md → empty), 当前 V37.9.91 不动 (最小修复). ⑧ **元价值 (V37.9.83 三阶段 framework 真闭环)**: Stage 1 V37.9.84 Daily Observer (方向 1) → Stage 2 V37.9.90-r1 Expert Escalation 代码就绪 (方向 2) → **V37.9.91 wiring 让方向 2 真生产可用 (PA 一次 WhatsApp 调用即触发 Doubao 深度判断)**. AI Partnership Framework 从"思想升华文档"升级为"PA 复杂判断时真有可调用的 expert backend". V3 路标 `pip install ontology-engine` 终极目标的关键证据 — capability framework 不只接入 provider, 还能让 provider 在 PA 复杂判断时真路由. ⑨ **累计**: 99 suites (status.json quality.test_suites 含 L1+L2+L3 全部 ✅, V37.9.91 加 v37_9_91_expert_escalate_wiring +1 但 status 显示 99 不变是历史漂移已知, 收工二次全量回归后升至 100) / 3505→3537 tests (+32 V37.9.91 守卫) / 0 fail / governance 762 checks pass (V37.9.85+ 累积升级到 762, V37.9.91 无新 INV) / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.91 是 wiring 落地, 不涉及 capability semantics 升级). ⑩ **Mac Mini 真生产 + WhatsApp 真用户调用双重闭环铁证 (同 session 14:00 → 17:30 < 4h)**: (a) **Mac Mini 直调 escalate.py**: PR #609 合并 → auto_deploy FILE_MAP 同步 expert_escalation.py + 三处 wiring → 发现 V37.9.91 隐藏 bug (proxy plist 没 ARK env, V37.9.54 INV-PLIST-ENV-001 只守 adapter plist) → 手动从 adapter plist 复制 ARK_API_KEY+ARK_ENDPOINT_ID 到 com.openclaw.proxy.plist + launchctl bootout/bootstrap 让 launchd 真重读 (V37.9.54 教训 kickstart -k 不重读 plist EnvironmentVariables) → env 注入模拟 proxy 进程环境真调 Doubao: **status=ok / input_tokens=37524 / output_tokens=2060 / reasoning_chars=6923 / cache_read=0 (首调预期) / context_chars=80040 (含 changelog 67452)**. Doubao proposal 准确识别 wiring 6 个验证点 + refs 引用 5 个真实文件 (V37.9.90-r1/V37.9.91/auto_deploy.sh/proxy_filters.py/tool_proxy.py) + rationale 引用 INV-PLIST-ENV-001/V37.9.76-hotfix/28+ MR-4 silent failures (CLAUDE.md changelog 真理解非编造). Doubao 主动识别 V37.9.92 候选风险: "proxy plist drift: periodic auto-deploy runs may overwrite the manually injected ARK_API_KEY entry". (b) **WhatsApp 真用户调用端到端**: 用户发深度判断请求 → PA 真识别 SOUL 规则 12 触发词 → 真调 expert_escalate(question=用户原话, backend=doubao) → tool_proxy `_execute_custom_tool` 拦截 (V37.9.91 wiring) → lazy import escalate → Doubao 真返回 → PA 转发. 真实 audit record: **status=ok / input=37461 / output=1360 / cache_read=0 (首调) / reasoning=3852 chars**. Doubao proposal 准确提出 V37.9.92 4 步执行路径 (review FILE_MAP / 检查 auto_deploy 日志 / 加 INV 守 ARK env 持有 / 备份当前 working plist) + rationale 引用 MR-4/MR-15/V37.9.76-hotfix. **五段端到端全通: SOUL 规则 12 触发词识别 → PA 自主调用 → proxy 拦截 → escalate → Doubao → PA 转发**. (c) **V37.9.92+ CLAUDE.md 路径错配候选证伪**: Mac Mini 上 `/Users/bisdom/CLAUDE.md` 真存在 (FILE_MAP 部署 CLAUDE.md 到 $HOME), changelog 真 load 67452 chars. 之前担心的 `repo_root=$HOME` 让 `claude_md_path=$HOME/CLAUDE.md` 错配, 实际不存在 — FILE_MAP 已把 CLAUDE.md 同步到 $HOME 让 repo_root 假设命中. 关闭 V37.9.92+ 该候选, 不需修. (d) **V37.9.92 新候选 (Doubao + 我同款判断)**: INV-PROXY-PLIST-ENV-001 立 governance — 守 com.openclaw.proxy.plist EnvironmentVariables 必含 ARK_API_KEY + ARK_ENDPOINT_ID (镜像 V37.9.54 INV-PLIST-ENV-001 守 adapter plist 模式) + runtime python_assert 真读 plist (dev silent pass / Mac Mini fail-loud) + Doubao 提议 4 步执行 (audit FILE_MAP 是否含 plist / 7 天 auto_deploy 日志 / 加 INV 守 / 备份当前 working plist) 全 codify 入 V37.9.92 收工承诺. ⑪ **元价值 (V37.9.83 AI Partnership Framework 真闭环硬证据)**: Stage 1 V37.9.84 Daily Observer 已上线 (方向 1) → Stage 2 V37.9.90-r1 Expert Escalation 代码就绪 (方向 2) → **V37.9.91 wiring + Mac Mini 部署 + Doubao 真调 + WhatsApp 真用户端到端调用 = 方向 2 真生产闭环**. AI Partnership Framework 从 "思想升华文档" 升级为 "PA 复杂判断时真有可调用的 expert backend 且 PA 真识别 + 真转发". V3 路标 `pip install ontology-engine` 终极目标的关键证据 — capability framework 不只接入 provider, 还能让 provider 在 PA 复杂判断时真路由真返回真转发. **同 session < 4h 完成 V37.9.91 wiring 设计 → 实施 → 32 单测 + 反向验证 → push → PR 合并 → Mac Mini 部署 → 发现 proxy plist env 缺失 → 手动修复 → 真调 Doubao → WhatsApp 真用户调用 = 完整闭环**, 这是项目演进 framework 化 + 用户视角原则 #13/#15 双兑现.
| V37.9.90-r1 | 2026-05-29 | **Expert Escalation Capability 重设计 — Doubao backend (Claude pending) / 同 session 用户 push back 触发 redesign** — ① **触发**：V37.9.90 v1 (Anthropic SDK 路径) 推送后用户立即指示 "把 Claude API 替换成系统中已经运行的 Doubao，Claude 暂时 pending"。**架构没问题，选错了 backend** — Claude 待集成 / 待装包 / 待付费 / 待网络验证；而 Doubao 已经在生产跑了一周（V37.9.52 接入 + V37.9.55 verified 5/5 capabilities + ARK_API_KEY 已在 plist V37.9.54 INV-PLIST-ENV-001 守卫）。② **替换路径** (3 文件 git mv 保留历史)：`claude_escalation.py → expert_escalation.py`（~470→520 行重写 + DoubaoTransport class）/ `test_claude_escalation.py → test_expert_escalation.py`（72→89 单测 / 12→13 类）/ `claude_escalation_design.md → expert_escalation_design.md`（重写设计文档含 v1 vs r1 对比表 + 13 维度差异）。③ **DoubaoTransport (核心)**：stdlib urllib.request 转 OpenAI Chat Completions 兼容请求 — POST `https://ark.cn-beijing.volces.com/api/v3/chat/completions` + Bearer `${ARK_API_KEY}` + payload `{model: ${ARK_ENDPOINT_ID}, messages: [system(SYSTEM_PROMPT+context_md), user(question)], max_tokens: 4000, temperature: 0.3}`。`is_configured()` 检 API key 存在；`call()` 返回 (ok, text, usage, err) tuple；mockable 通过 `subclass override _post()`。**关键**：system_prompt + context_md 合成**单条 system message**（Doubao 不支持 Anthropic 多 block + cache_control 模式，但 Volcengine Context Cache **按字节级 prefix 匹配自动生效**，无需 cache_control）。④ **Usage 解析**：`usage.prompt_tokens_details.cached_tokens` 捕获 Volcengine cache hit；`message.reasoning_content` 长度记录 reasoning_chars（Doubao seed reasoning model 的 thinking 字段）。⑤ **Backend selector**：`BACKEND_DOUBAO="doubao"` (默认) / `BACKEND_CLAUDE_PENDING="claude_pending"` → 返回 `status=claude_pending` stub，future-flip 机制保留。**新 status 类型**：`claude_pending` + `unknown_backend`，加入 escalate() 9 类 status 体系。⑥ **成本对比 v1**：Doubao 单次首调 ~$0.009 / cache hit ~$0.005 → daily quota 30 ≈ ~$0.30/day cap（vs v1 Claude $1/day）— **30x 更便宜**。Daily quota 10→30。`temperature=0.3` 显式（Doubao 支持，Claude 4.7/4.8 移除）。⑦ **89 单测 13 类 + 19 source-level 守卫**：TestDoubaoTransport(11) 含 OpenAI payload shape + cached_tokens 解析 + reasoning_chars 捕获 + 错误传播；TestEscalateOrchestratorDoubao(11) 7 status 分支端到端；TestBackendSelector(4) doubao 默认 / claude_pending stub / unknown 拒绝 / claude_pending 短路 quota check；TestV37990R1SourceGuards(19) 含 **反向守卫** no_anthropic_import + no_openai_import + no_requests_import + uses_urllib + Volcengine URL 字面 + temperature 0.3 + quota 30 + DoubaoTransport class + audit filename 改名 + Context Cache 文档化 + no cache_control/thinking/output_config in call()。⑧ **SOUL.md 规则 12 更新**：tool 名 `claude_escalate → expert_escalate`，行为契约加 claude_pending 分支处理，PA 标注模型来源改为"Doubao Seed 2.0 Pro V37.9.55 verified reasoning model"（用户视角可仍说"让 Claude 看看"）。⑨ **Mac Mini 部署 checklist 简化**（V37.9.91+ 候选）：~~pip install anthropic~~（删除）/ ~~ANTHROPIC_API_KEY 申请~~（删除）→ 仅需 (1) tool_proxy.py 加 expert_escalate 自定义工具注入 (2) auto_deploy FILE_MAP 加 expert_escalation.py (3) 验证 ARK_API_KEY 已在 plist (`echo $ARK_API_KEY` 确认) (4) 第一次真生产调用。⑩ **元价值 (V37.9.83 boundaries-over-trust 延伸)**：r1 redesign 不是"承认 v1 错"而是 boundaries 原则到工程务实层的延伸 — **先用已经付费、已经 verified、已经稳定运行的工具完成 PoC**，避免 over-engineering，等真有需求再激活新工具。同样架构 / 不同 backend / 30x 成本降低 / 零新依赖 / 零 Mac Mini 配置步骤。**未来 N 个 Claude session 看到这次 r1 时应立刻明白：架构选对了，backend 选错了。Doubao 一直就在那里等着用**。⑪ **累计**: 99 suites 不变 (rename 不增 suite) / 3416→3505 tests (净 +89: v1 删 72 + r1 加 89, 实际是 rename 后 89 全新) / 0 fail / governance v3.50 不变 (无新 INV — V37.9.92+ 立 INV-EXPERT-ESCALATION-001 一周观察后) / 安全 95/100 / VERSION 0.37.9.68 不变。 |
| V37.9.90 | 2026-05-29 | **(v1 路径 — 当日 redesigned 为 V37.9.90-r1) Claude Escalation Capability PoC (Direction 2)** — V37.9.83 战略沉淀方向 2 兑现。初版用 Anthropic SDK (Opus 4.7 + Sonnet 4.6 fallback)。用户 push back 后**同 session 重设计为 V37.9.90-r1 (Doubao backend, Claude pending)**。v1 commit `df6e57b` 保留在 git history 作为设计演进记录。① **设计目标 (不变)**: PA (Qwen3-235B Mac Mini) 检测复杂判断触发词 → 调一个 custom tool → 一次 LLM 调用喂入 status.json + 14d CLAUDE.md changelog + 相关 case docs → 返回 read-only JSON proposal → PA 转发用户。② **v1 backend (已废)**: Anthropic SDK (opus-4.7 + sonnet-4.6 fallback) / cache_control ephemeral / adaptive thinking / effort=high / daily quota 10 / ~$0.47 首调 + ~$0.06 cached / pip install anthropic 依赖 / ANTHROPIC_API_KEY 待申请。③ **设计契约保留到 r1**: read-only 输出 contract (4 类 shell 模式 FAIL-CLOSE) / daily quota / audit log / mockable transport / FAIL-CLOSE on missing API key / dry-run mode for dev。④ **r1 替换详见上方 V37.9.90-r1 entry** — 文件 rename + DoubaoTransport class + backend selector + 30x cost reduction。⑤ **同 session 双版本说明**: v1 commit (`df6e57b` Anthropic SDK) → 用户反馈 → r1 commit (`ea35787` Doubao) 全部在 branch `claude/trusting-gauss-4cpb9` 上保留。v1 的 71 单测 / 设计文档已被 r1 89 单测 / 重写设计文档替代。**git mv 而非删除新建**让 file history 连续可追溯。⑥ **历史价值**: v1 暴露的真实问题不是架构错，是 backend 选型未充分利用系统现状 (V37.9.52 已接 Doubao plugin, V37.9.55 已 verified)。同 session redesign 是 V37.9.83 "用户视角机器化" 在协作层的兑现 — 用户 push back 不是"否决工作"，是把"系统现状信息"机器化补充给 Claude 让设计自我迭代。 |
| V37.9.89 | 2026-05-29 | **LEVEL_6_DREAM_CROSS_DOMAIN_AWARE — Dream 反链式幻觉手术 (V37.9.84 observer 自发现 + 同日闭环)** — ① **触发**：今日 V37.9.84 observer 趋势复盘 (3 天数据 + 5/28 LLM critique) 揭示 dream 中 "光子计算架构可能为心理导航提供物理实现路径" 必然推论链幻觉。**MR-4 silent-failure 新形态**：不是完全编造 (V37.4.3 macOS FDA) 也不是事件名编造 (V37.9.56-h3 v26)，而是基于弱信号的"创造性跨域桥接" — LLM 把两个真存在的 chaspark 信号 (软光子学 + 心理导航) 用"必然推论链"硬连。**2026-05-29 dream 实测复现**：4 个 🔗 隐藏关联全部 `A → B → 因此 C` 模式。② **V37.9.57 LEVEL_5 没拦住**: LEVEL_5 含 "严禁推测/合理化任何不能从输入直接推导的'必然推论'"，但 Qwen3 把"推测"狭隘解读为"完全伪造内容"，对 cross-domain "隐藏关联" 网开一面。③ **修复 LEVEL_6** (`hallucination_guards.py` +94 行 `_LEVEL_6_DREAM_CROSS_DOMAIN_AWARE`)：累积式继承 LEVEL_5 全部 + 三层新约束：(a) **每条🔗强制 tag** — `[强证据] **A→B**: 引用源段落` / `[弱关联] **A与B共享[具体方法]**: 共享术语` / `[推测]` 禁止 (b) **必然推论句式禁令** — "因此/必然/为X提供路径/暗示存在因果/X直接对抗Y/X通过Y打破Z" 除非紧接 [强证据]+源段落 (c) **多跳因果链禁令** `A → B → C` 形式禁止 (d) **📭 fallback** 无足够信号时输出 "今日跨域信号不足" (e) **LLM 自检 checklist** [ ] markdown checkbox。④ **scope**：仅升级 `kb_dream.sh DREAM_HG_GUARD: LEVEL_5 → LEVEL_6`。kb_evening 不动 (evening 无 cross-domain 段位)。LEVEL_5 完全不动 (向后兼容)。⑤ **测试** +15 (TestV37_9_89_Level6CrossDomain 10: tag 守卫 + ≥3 句式禁令 + 多跳禁令 + 📭 fallback + checklist + V37.9.89 marker + 血案引用 + LEVEL_5 不改 / TestV37_9_89_KbDreamIntegration 4: kb_dream 用 LEVEL_6 + 反 LEVEL_5 退回 + 双 marker 保留 / 2 CLI test 升 6 档)。**52/52 hallucination_guards + 121/121 daily_observer + 3416 全套 全过**。⑥ **元价值 (Stage 3 兑现)**：V37.9.84 observer "用户视角机器化 → 系统自我成长" 思想升华文档第二原理**今日真实兑现** — observer 在 5/28 自发现 dream 幻觉 → 5/29 我读到报告 → 同日 V37.9.89 手术修复。从"用户在 WhatsApp 反复反馈" → "observer 主动报告" 是观察阶层的真升级。⑦ **下次 V37.9.90+ 候选**: (a) **主硬卡**: Mac Mini 5/30 03:00 cron 真激活验证 LEVEL_6 效果 — 5 天后比对句式频次降幅 + tag 出现率 (b) INV-DREAM-CROSS-DOMAIN-001 立 governance (稳定一周后) (c) observer proposal #2 源可信度评级 (区分本案的关联可信度) (d) Stage 2→3 ArXiv 论文 *Silent Failures Taxonomy* 候选素材新增此案 (类 D 链式幻觉新形态)。⑧ **累计**: 96→**98 suites (+2)** / 3338→**3416 tests (+78: V37.9.87 +11 + V37.9.88 +37 + V37.9.89 +15 + alternation 等 +15)** / 0 fail / governance v3.50 不变 / 安全 95/100 / VERSION 0.37.9.68 不变。三阶段同分支 P0+P1a+P1b 完整闭环。 |
| V37.9.88 | 2026-05-29 | **observer registry-driven enabled filter + stale last_run 检测 (V37.9.84 trend review 二级发现, MR-8 SoT 兑现)** — ① **触发**：V37.9.84 observer 3 天数据复盘揭示 5/28 anomalies_high=2 包含 1 假警 (`pwc fetch_failed`)。**深挖**: `daily_observer.py:JOBS_SUBDIRS` 硬编码与 `jobs_registry.yaml` drift 3 方向 — (1) 2 disabled jobs 仍扫 (`pwc` V31 (2026-03) disabled + V37.8.13 脚本删, `karpathy_x` V34 合并 ai_leaders_x) (2) 1 ID 不一致 (`openclaw_official` registry 实是 `openclaw_run`/`run_discussions` 各 disabled V37.9.50-h2/3) (3) 25 enabled jobs NOT in 硬编码 (部分 by-design 排除 infra job)。**核心 bug**：observer 读 `pwc:last_run.json` (timestamp 2026-03-31, status=fetch_failed) 当作今日异常**误报 2 个月**。② **MR-8 反例兑现**：observer 维护与 registry 并行的硬编码 list, 当 V31/V34/V37.9.50-h 停用 job 只改 registry 不改 observer, 漂移累积 N 个月不被发现。③ **修复 LAYER 1 — registry-driven filter (MR-8 SoT)**：(a) `_load_enabled_job_ids_from_registry(path)` 纯函数最小解析 (no PyYAML, 模仿 `kb_review_collect`), 行内注释剥离 + 引号兼容, 返回 `set[str]` 或 None on parse fail (b) `_filter_enabled_jobs(subdirs, registry_path)` 返回 `subdirs ∩ enabled_ids` + FAIL-OPEN registry 不可读 → fallback subdirs + log WARN (c) `_resolve_registry_path()` 三档: `OBSERVER_REGISTRY_PATH` env (测试) → `$HOME/jobs_registry.yaml` → script 同目录 (d) `scan_job_statuses(jobs_dir, target_date, registry_path=None)` 启动期应用 filter。④ **修复 LAYER 2 — stale last_run 检测**：(a) `_parse_lr_time(time_str)` 4 格式 (空格分隔 s2/pwc 风格 / ISO T / ISO Z / date-only) (b) `_is_stale_last_run` 用 calendar-date 减法 (e.g. "Mar 31 → May 28" 读为 58 天与人类直觉一致) + 7 天阈值 (8d+ stale, 7d 边界 fresh) (c) `scan_job_statuses` 每 entry 加 `{stale, stale_days}` 字段 (d) `detect_anomalies` 发 MED `stale_job` 并 **SUPPRESS HIGH `job_failure`** for stale entries (status data 本身不可信)。⑤ **行为变化 (Mac Mini 部署后)**：observer 扫 **12 enabled** (15-3), 5/28 风格 anomalies_high 从 2 → 1 (仅 s2 真异常) + 1 MED stale。**注**: S2 真因独立 — 上游 Semantic Scholar HTTP 429 throttling (unauthenticated tier = 1 req/5sec), 5/26 OK → 5/27 5/6 关键词 429 仍出 7 篇 → 5/28 6/6 全 429 ERROR。修复路径 = 申请免费 S2 API key (V37.9.90+ 候选)。⑥ **+37 单测 7 类**: TestV37_9_88_LoadEnabledJobIds(6 含真 registry 锁定 pwc 排除契约) + TestV37_9_88_FilterEnabledJobs(4) + TestV37_9_88_ParseLrTime(8) + TestV37_9_88_IsStaleLastRun(7 含 7d/8d 边界 + **血案 pwc 58d**) + TestV37_9_88_DetectAnomalies(4 含 MED stale + HIGH suppression + 5/28 真实拆分) + TestV37_9_88_ScanJobStatusesIntegration(2 端到端 mock registry) + TestV37_9_88_SourceLevelGuards(6 V37.9.88 marker + 函数定义 + 反 inline 反模式 + 血案引用)。⑦ **元价值**：MR-8 SoT 反例 (硬编码 list 与 registry 漂移) 转化为正面案例 (registry 成为 observer scan 唯一真理源)。Stage 3 第二原理"系统自我成长" 延伸到 framework 层：**observer 不仅观察其他系统, 还自我观察并自我修正**。V3 路标 `pip install ontology-engine` 终态"任何项目只需 yaml 配置"的关键中间证据。 |
| V37.9.87 | 2026-05-29 | **daily_observer single-call architecture (P0 双写血案修)** — ① **触发**：V37.9.84 上线 5/26 后, 今日 (5/29) 用户视角实测复盘发现 `score_history.jsonl` 数据严重污染：5/26 4 行 / 5/27 2 行 / 5/28 2 行，且 5/28 两次记录分数 ⭐5 + ⭐4 不一致。同时 `last_run.json overall_score=5` vs `score_history` 5/28 最新 = 4 — 运维拿到两个矛盾数字。② **BUG #1**：`daily_observer.sh` 每 cron 调 Python **两次** — `OBSERVER_OUTPUT=$(python3 daily_observer.py --json ...)` 解析字段 + `python3 daily_observer.py ... > "$REPORT_FILE"` 写 markdown。两次都进 `run()` → `append_score_history()` → 2 行/天。③ **BUG #2**：LLM stochasticity 让两次产出不同 `overall_score`。`last_run.json` 写第 1 次跑分, `score_history` 最新 = 第 2 次跑分 → 报告"Trend"读 history 显示 ⭐4, 但 `last_run.json` 说 ⭐5。④ **修复 (single-call 架构)**：(a) `daily_observer.py::main()` `--json` 分支去掉 `report_markdown` 过滤 — 输出含完整 markdown (b) `daily_observer.sh` 删第二次 Python 调用 — inline Python 通过 `REPORT_FILE` env 接收路径, 单 fork 解析 JSON + 写报告 + 输出短字段。**invariant**: 1 cron = 1 LLM call = 1 score_history append; `last_run.json` 与 `score_history` 同源。⑤ **副作用**：LLM 成本 -50% (observer 部分), 未来 cron 不再污染 history。**不修历史污染** (旧 8 条记录保留作 forensic 证据, `load_score_history` 按日 dedup 在读取时去重)。⑥ **+11 新单测 TestV37_9_87_SingleCallArchitecture**: V37.9.87 双 marker + `--json` 含 report_markdown + source-level guard wrapper invoke OBSERVER_PY 恰好 1 次 (反 V37.9.84 双调用) + `REPORT_FILE` env 传递 + inline Python 写 report_markdown + 反 pre-V37.9.87 buggy pattern `> "$REPORT_FILE"` 第二次调用反退回守卫 + CLI `--json` 端到端含 `report_markdown` + `1 run() = 1 history row` 行为不变量 + 反向 sabotage 文档。⑦ **MR-7 兑现 (V37.9.84 observer 的二阶价值)**: V37.9.84 观察自己 — BUG #1+#2 都是 V37.9.84 自身设计缺陷, observer 通过 3 天数据揭示。这是"观察者必须可被观察"meta 元规则在 framework 层第一次正面兑现。V37.9.83 思想升华文档第二原理"系统自我成长 = 用户视角机器化"在 framework 层落地。⑧ **下次 V37.9.88 候选**: 同 session 续推, 已实施 — observer registry-driven enabled filter (闭环 pwc/karpathy 假警) + stale last_run 检测。 |
| V37.9.83 | 2026-05-20 | **AI Partnership 战略沉淀 — 三大第一性原理 + 思想升华文档 + 三方向登记 deferred (Stage 2 → Stage 3 拐点, 今日不动代码)** — ① **触发**：上一 session 留下三战略方向 (问题1 嵌入 Claude 判断力 / 问题2 系统自我成长 / 问题3 multi-agent 自我博弈) + 我对 "100% 权限" 假设的根本反挑战 (不是信任问题, 是边界问题). 用户明确指示 "先不执行了, 保存好今天讨论的星辰大海和第一性原理讨论, 做一次思想升华, 保存今天所有的结论 + 里程碑的进展, 然后结束今天的工作". ② **主交付** `docs/articles/ai_partnership_first_principles_zh.md` (Stage 2 第 6 篇立场文章, ~600 行 / 21 KB): **三大第一性原理** — (1) **协作本质是边界不是信任** (boundaries > trust): 100% 权限假设的根本反挑战 — 风险不来自 AI 意图, 来自 LLM emergent misalignment (reward hacking / distributional shift / Goodhart's law / compounding errors 四力学不消失). MR-4 silent-failure 28+ 次演出全是好意图+边界不清晰组合的硬实证. V3 路标 `pip install ontology-engine` 真正卖点 = control plane 让任何 LLM 都安全运行, 而不是"最强 LLM". (2) **系统自我成长 = 用户视角机器化**: 5 个月数据 70% 真问题来自用户 WhatsApp 一句反馈 (V37.9.36 占位符 / V37.9.68 主题重复 / V37.9.58-hotfix3 watchdog silent / V37.8.11 噪声告警 / V37.9.18 cron 未注册). 用户感知是价值判断 (LLM 擅长 reader-as-judge), 不是数值阈值. daily LLM observer 输出 read-only proposal 是最直接路径. (3) **LLM 判断三层** (价值递减): 工作记忆已通过 CLAUDE.md/status.json/case docs 解决 / 判断模式真正 gap 可部分蒸馏 (governance 19 meta_rules + 21 case docs) / 协作惯性几乎不可持久化每 session 重建. ③ **三战略方向 deferred 登记** (status.json.session_context.unfinished 新增 3 项, 待用户决策启动): **方向 1 (Recommended) Daily Self-Critique** — daily_observer.py cron 每日 LLM 扫前日推送给第三方评分输出 read-only proposal 永不直接改代码 / 风险最低 ROI 最高 / PoC 3-5 天 / 失败成本: 一个 cron + 一份 markdown. **方向 2 Claude Escalation Capability** — 双层 agent stack PA 检测复杂判断时调 Claude API (SDK 非新 session) 拿 status.json+case docs+14 天 changelog 作 context / 解决 Claude 不在场时系统判断力不够 / 中等风险 PoC 3-7 天. **方向 3 Red Team Sandbox** — red/blue/judge multi-agent dev sandbox / PoC 价值高生产价值低 (输入空间开放无 ground truth 评分函数) 短期不启动 / 子能力 `red_team_audit.py` 有价值是 V37.9 adversarial_chaos_audit (16/16) 延伸. ④ **Stage 2 → Stage 3 拐点正式确立**: Stage 1 (V1-V35) 系统构建者 → Stage 2 (V35-V37.9.82) 被社区认可的系统作者 (6 篇立场文章 + 治理证据链 + Provider/Memory/Reliability Plane) → **Stage 3 (V37.9.83+) AI Partnership Framework** — 不只是工具系统, 是 "AI 合伙人 + 人类伙伴" 协同的工程范式. 旗舰叙事升级: *An Agent Runtime where AI can be a partner — because the boundary system is machine-executable, not memory-dependent*. ⑤ **里程碑认定**: 95 suites / 3247 tests / 0 fail / 81 inv / 740 checks / **19 MR / 19 MRD scanner** / 安全 95/100 / 对抗审计 16/16 (100%) / 21 case docs / VERSION 0.37.9.68 不变 (V37.9.83 是治理思想层固化, 不涉及业务语义改动). ⑥ **元价值**: CLAUDE.md 原则 #20 (话语权输出是一等公民) 的内部应用 — 话语权不止对外, 也对未来的自己. 让未来 N 个 Claude session 看到这份文档时, 能在 5 分钟内对齐到同一战略坐标系. ⑦ **下次 V37.9.84+ 候选** (用户启动信号触发): (a) 启动方向 1 Daily Self-Critique (Recommended) — design doc + PoC (b) 启动方向 2 Claude Escalation Capability (c) 继续 Stage 2 收尾 (status.json this_week 5 候选: V37.9.78 v2.0 周报观察 / V37.9.82 scanner MR-18 立 / mm_index 历史路径迁移 / run_hn_fixed 重命名 / scanner runtime check 扩 crontab 真扫). ⑧ **结束今日工作前的最后一句**: 5 个月 + 3247 个测试 + 19 条元规则——**这不是 chatbot 的成就, 是工程的成就**. 把 AI 当合伙人, 但保持工程纪律. 星辰大海方向都可追求, 但纪律不变: 每一步都先 PoC、先观察、先 sandbox. |
| V37.9.81 | 2026-05-19 | **MOVESPEED FDA 真生效 24h 数据回归闭环 + V37.9.30 取证盲区根因修复 (A + B 同 PR)** — ① **触发**：V37.9.80 (5/18) 终结 60 天 MOVESPEED EPERM 血案后, 收工承诺 24h 后跑 `python3 ~/movespeed_incident_analyzer.py --window 24h` 验证 incident 数 ~13 → ≤2。② **V37.9.81 (5/19) Mac Mini 真实数据回归 (FDA 真生效铁证)**: 12h 窗口 = **0 incidents** / FDA 后 ~19h 累积 0 incidents / `log show --last 12h --predicate 'MOVESPEED + Sandbox'` 过去 12h **0 条** kernel sandbox deny — 三层证据互相印证, V37.9.80 判定窗口 ≤ 2 兑现 (实际 = 0). 同时数据再次铁证 V37.9.30 取证盲区真存在: acl_top="total 0" / lsof="" 仍出现, 实为采集器自身被 sandbox 拒绝 (V37.9.80 已揭示但未根治). ③ **A 部分 — 24h 数据回归 + 机器化判定守卫**: INV-MOVESPEED-TCC-001 加新 runtime python_assert `RUNTIME: incidents.jsonl 24h ≤ 2 (V37.9.80 FDA 修复机器化判定)` 真扫 `~/.kb/movespeed_incidents.jsonl` ISO 8601 timestamp + 24h rolling window count + assert ≤ 2. **三层 FAIL-OPEN 契约**: dev 无 jsonl 文件 silent pass (governance dev 不应误报缺生产数据) + 文件损坏单行 skip 不阻塞 (V37.9.18 mtime-stable 同款) + 文件 IO 失败 silent pass. **价值**: 把 V37.9.80 "24h ≤ 2" 判定标准从"靠 Claude Code 周期性记忆"升级为"governance audit cron 每日 07:00 主动检查"。未来回退场景立即被 audit 抓到: (a) macOS 升级 reset TCC profile (b) FDA 被手动移除 (c) 其他外置卷 sandbox 问题. ④ **B 部分 — V37.9.30 取证盲区根因修复 (四层防御)**: V37.9.30 用 `2>/dev/null` 吞 stderr 让"采集失败"和"真空"无法区分 6 周潜伏被误判为 normal/empty. (1) **capture.sh 4 处采集命令 stderr 重定向到独立 _err 文件**: `ls -le@ /Volumes/MOVESPEED/ 2> "$_TMP/acl_top_err"` (acl_top/acl_kb/lsof/snapshots 各加独立 stderr 文件). (2) **Python heredoc 加 read_file_with_stderr helper**: 检测 stderr 含 `operation not permitted`/`permission denied`/`sandbox` 关键字 → 字段值前加 `[sandbox_denied] ` 前缀; 检测 `command not found`/`no such file or directory` → `[tool_unavailable] ` 前缀; 空 stderr 走旧路径 (向后兼容 462 条历史 records 不带 marker → 旧桶分类). (3) **analyzer.py classify_acl_anomaly / classify_handle_holders / classify_snapshot_count 三个函数顶部加 marker 检测分支**, 优先于内容分类; priority dict 加 `sandbox_denied: 6` (最高优先级超过 `acl_deny: 4`) — sandbox-deny 是 V37.9.80 真因的直接 EPERM 证据, 比 acl_deny 假说更可信. (4) **format_text_report 三个 explain dict 加 sandbox_denied / tool_unavailable 说明 + 新增 V37.9.81 B 决策提示段** "🚨 Sandbox 拒绝警告 (V37.9.81 B)" 含 V37.9.80 同款 `/usr/sbin/cron` FDA 修复路径. ⑤ **19 新单测 2 测试类** `test_movespeed_incident_analyzer.py`: TestV37981BCaptureSandboxStderr(6 含 4 stderr file 字面量 + helper 函数定义 + V37.9.81 B marker 含 V37.9.30/V37.9.80 lineage + priority 顺序锁 sandbox 优先于 tool_unavailable) + TestV37981BAnalyzerSandboxBuckets(13 含 3 个 classify 函数 sandbox/tool_unavailable marker 识别 + 向后兼容老桶 + analyze priority dict sandbox 胜 acl_deny 端到端 + 决策提示文本含 `/usr/sbin/cron` + 无 sandbox 时不误报). ⑥ **V37.9.30 守卫单测升级 alternation** (MR-8 单一真理源): `test_capture_script_rec_dict_includes_v37_9_30_fields` 接受 V37.9.30 旧 `read_file("acl_top"` OR V37.9.81 B 新 `read_file_with_stderr("acl_top"` 字面量。**102/102 test 全过** (V37.9.30 83 + V37.9.81 B 19). ⑦ **反向 sabotage 两层守卫真有效**: (a) 改 capture.sh `2> "$_TMP/acl_top_err"` 回 `2>/dev/null` → governance audit 立即抓 `❌ V37.9.81 B: capture.sh acl_top stderr 捕获到 file (非 /dev/null)` (b) 删 `def read_file_with_stderr` 函数定义 → 单测立即 2 fail. 还原后 645/645 governance + 102/102 单测全过. ⑧ **INV-MOVESPEED-TCC-001 升级 hard 守卫** (V37.9.80 7 declaration + 1 runtime → V37.9.81 13 declaration + 3 runtime, +7 checks): 6 新 declaration (capture.sh 4 stderr file + helper 定义 + sandbox_denied marker + V37.9.81 B marker / analyzer.py sandbox_denied 桶) + 1 新 runtime python_assert 真跑 classify_* + priority dict 顺序锁 (sandbox 必须胜 acl_deny). ⑨ **audit_metadata 漂移修复**: V37.9.80 加 INV-MOVESPEED-TCC-001 但 meta 未同步, V37.9.81 一并修齐 79→80 inv / 715→731 checks / 19 MR 不变. v3.46→v3.47 changelog 完整记录 A+B 两部分. ⑩ **元价值 (60 天血案真正闭环)**: V37.9.80 真因发现 (1 day) + V37.9.81 A FDA 守卫 + V37.9.81 B 取证盲区根因修复 = **不仅修 1 个 bug, 还把发现 (TCC sandbox) + 工程教训 (stderr 必须独立捕获不能吞) 作为 framework 级永久记录入治理体系**. V3 路标 framework "反思转化机制" + MR-7 治理自观察 + MR-10 understand-before-fix 三元规则同时硬实证. 未来同款 macOS sandbox 问题 → V37.9.81 B 第一次采集就识别 + 立即报警, 不再 6 周潜伏. ⑪ **同日 V37.9.68 / V37.9.78 / V37.9.79 生产稳定验证**: dream 已 4 段 (V37.9.68-hotfix 多窗口分片 + 4 段独立) 质量不错 / daily_ops OK (V37.9.79 SLO snapshot cron 注册待用户手动) / 周报等 09:00 后验证. ⑫ **累计**: 92→93 suites (V37.9.80 已 93, V37.9.81 仅扩 test_movespeed_incident_analyzer.py 类不增 suite) / 3203→3222 tests (+19 V37.9.81 B) / 0 fail / governance v3.46→v3.47 / 79→80 invariants / 715→731 checks (+16: V37.9.80 +8 + V37.9.81 A +1 + V37.9.81 B +7) / 19 MR 不变 / 安全 95/100 / VERSION 0.37.9.68 不变 (治理层固化 + 取证盲区根因修复, 不涉及业务语义). ⑬ **下次 V37.9.82+ 候选**: (a) **主硬卡**: Mac Mini 部署 V37.9.81 后等 24-48h, 跑 `python3 ~/movespeed_incident_analyzer.py --window 24h` 看 (i) governance audit incidents.jsonl runtime check 真激活生产环境通过 (ii) 即使 FDA 已加 sandbox_denied 桶若仍出现 → lsof/tmutil 自身需独立 FDA (b) MR-16 候选 `macos-cron-derived-processes-need-fda` 元规则 (一周观察 FDA 效果稳定后立) (c) 同款 audit 扩展 — 其他可能 60 天潜伏的 macOS 系统层问题 / 跨平台采集器 stderr 吞掉模式扫描. |
| V37.9.80 | 2026-05-18 | **MOVESPEED EPERM 60 天血案真因终结 — macOS TCC Sandbox 拒绝 cron 派生进程访问外置卷** — ① **触发**: V37.9.79 完成后用户推进 #3 MOVESPEED EPERM (长期未解真问题). V37.9.30 incident_analyzer 累积 110 条 incident / 7d 一周数据回归. ② **数据驱动诊断 — 6 个假说全证伪**: (a) APFS exfat fskit (V37.9.4) — 60 天前 APFS 重建仍 fail ❌ (b) noowners + UID 错位 (V37.9.29) — 110/110 ownership=501:20 100% 正确 ❌ (c) ACL deny / xattr (V37.9.30) — 110/110 acl_top=`total 0` 无 ACL ❌ (d) macOS daemon 抢占 (V37.9.30) — 100% 5 daemon 共现是巧合 ❌ (e) TM 本地快照锁 (V37.9.30) — 110/110 snap_0 无快照 ❌ (f) SSD 物理 unmount (我刚才假说) — mount 字段铁证 `/dev/disk5s1 on /Volumes/MOVESPEED (apfs, local, journaled)` SSD 真在线 ❌. ③ **铁证 — macOS 系统日志 (V37.9.80 首次跑 log show)**: 用户跑 `log show --last 6h --predicate 'eventMessage CONTAINS "MOVESPEED" OR eventMessage CONTAINS "Sandbox"'` 立即抓到 `kernel (Sandbox) System Policy: rsync(92664) deny(1) file-read-data /Volumes/MOVESPEED/KB` + `kernel (Sandbox) System Policy: touch(92697) deny(1) file-write-create /Volumes/MOVESPEED/.incident_probe_top` + `kernel (Sandbox) System Policy: ls(92694) deny(1) file-read-data /Volumes/MOVESPEED` — **kernel + Sandbox + deny + file-read-data + /Volumes/MOVESPEED** 五字面量同行出现是 TCC sandbox 拒绝的唯一指纹. ④ **真根因**: macOS Big Sur+ TCC (Transparency, Consent, Control) 默认拒绝所有进程访问"受保护"位置 (Desktop / Documents / Downloads / 外置卷). `cron` daemon 作为 launchd 子进程**默认无 FDA 权限**, 其派生进程 (rsync/ls/touch/lsof) 访问 /Volumes/X 全部被 kernel sandbox 拒绝. ⑤ **V37.4.3 案例认知反而错了 — 修正**: CLAUDE.md V37.4.3 当时写"PA 编造 FDA 指令...launchd 管理的 cron 从不需要 FDA". V37.9.80 数据反驳: cron 派生进程真被 TCC Sandbox 拒绝, FDA 真是修复方向. PA 当时**场景错配** (看到无关告警乱回复 FDA), 但**FDA 修复方向本身正确**, 只是当时套到错误场景. 修正 `pa_alert_contamination_case.md` 加 V37.9.80 备注 + 引用新 case doc. ⑥ **V37.9.30 取证维度盲区**: lsof / ACL / snapshot 三个新维度采集**自身被 sandbox 拒绝** — V37.9.30 capture.sh 内调 lsof/ls 命令本身被沙箱拒返回 `lsof: len=0 / acl_top: total 0` 这种**看似正常**字面量, 让 V37.9.30 误以为"110/110 normal/empty"是"无异常", 实际是采集失败. V37.9.81+ 候选: capture.sh 显式区分"未采集"vs"采集到空". ⑦ **修复路径 (用户手动 GUI)**: 系统设置 → 隐私与安全性 → 完全磁盘访问权限 → 点 + → Shift+Cmd+G → 输入 /usr/sbin/cron → 选中添加 → 重启 cron 或 Mac Mini. ⑧ **验证 (24h 后)**: `python3 ~/movespeed_incident_analyzer.py --window 24h` 预期 incidents 从 ~13/24h → 0 或 ≤2/24h. ⑨ **新案例文档** `ontology/docs/cases/movespeed_tcc_sandbox_blood_case.md` (~220 行): TL;DR + 决定性铁证字面量 + 60 天 6 假说证伪表 + 完整因果链架构图 (V37.9.4 起 60 天潜伏 → 9 轮诊断错 → V37.9.80 首跑 log show 终结) + 三层根因 + 修复路径 + 5 条元教训 (MR-16 候选 / MR-10 反向第 5 次教训 / 取证维度盲区 / V37.4.3 修正 / 用户视角 #13 第 N+5 次). ⑩ **INV-MOVESPEED-TCC-001** 新增 (meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime], **8 checks**): 7 declaration file_contains (case doc 真因/铁证/6假说/取证盲区/修复路径 + V37.4.3 修正 + 引用新 doc) + 1 runtime python_assert 真读 case doc 验证 6 核心字面量同时存在 (macOS TCC Sandbox / kernel (Sandbox) / 60 天 / /usr/sbin/cron / V37.4.3 案例 / MR-10). ⑪ **累计**: 93 suites 不变 (V37.9.80 主交付是案例文档 + governance INV, 不增代码套件) / 3203 tests 不变 / 0 fail / governance 79→80 invariants (+1 INV-MOVESPEED-TCC-001) / 715→723 checks (+8) / 19 MR 不变 / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.80 是发现 + 案例 + 修正认知, 修复在 macOS GUI 不在代码). ⑫ **Mac Mini 用户验证状态**: 用户在 session 内已尝试 `sudo launchctl bootout system/com.vix.cron + bootstrap` 重启 cron, 但 bootstrap 命令需 plist 路径完整版 (V37.9.80 提示完整命令 `sudo launchctl bootstrap system /System/Library/LaunchDaemons/com.vix.cron.plist`). FDA 添加成功后 cron 下次自动用新 TCC profile 不一定需要立即 reload. ⑬ **下次 V37.9.81+ 候选**: (a) **主硬卡**: 5/19 后 24h 跑 incident_analyzer 验证 FDA 修复有效 (incidents 应大幅下降 ≤2/24h) (b) capture.sh V37.9.81 显式区分"未采集"vs"采集到空" (lsof/ACL 字段空值时标 `sandbox_denied` 不标 `empty/normal`) (c) MR-16 候选立 `macos-cron-derived-processes-need-fda` 元规则 (一周观察 FDA 效果稳定后立) (d) V37.9.82+ 其他 60 天潜伏问题 audit (问"什么其他错误可能 60 天隐藏在 macOS 系统日志中?"). ⑭ **元教训 (5 条全列)**: (i) MR-16 候选 macos-cron-derived-processes-need-fda — macOS Big Sur+ TCC sandbox 是新元规则 (ii) MR-10 understand-before-fix 反向第 5 次教训 — 60 天 6 假说全错, 因为从未跑 `log show --predicate` macOS 系统日志 (iii) 取证维度盲区 — V37.9.30 采集器自身被沙箱, 返回 "normal/empty" 误导 (iv) V37.4.3 案例错误判定纠正 — PA 表面错乱 + 局部真值时不能因表面错乱否定局部真值 (v) 用户视角原则 #13 第 N+5 次 — V37.9.78/79/79-hotfix/80 同 session 四阶段闭环全部数据驱动. ⑮ **元价值 (V3 路标 framework 关键拐点)**: 60 天血案真因终结 + 修正历史认知 + 立 INV 守 + 启发新元规则 — framework 演进的"反思转化机制"硬实证. V37.9.x 系列 7 个 hotfix 系列 (V37.9.4→27→29→30→80) 终于在 V37.9.80 闭环 — 不只是修一个 bug, 而是把"60 天诊断盲区"作为永久记录入治理体系, 让任何 macOS 外置卷+EPERM 类问题第一时间想到 TCC sandbox + log show 取证. |
| V37.9.79 | 2026-05-18 | **SLO 三项修复（数据驱动诊断 9 轮，未盲改一次）— V37.9.78 周报暴露的 3 个用户感知问题闭环** — ① **触发**: V37.9.78-hotfix Mac Mini 真激活后周报显示 `📊 SLO: p95=37570ms (24h均 ?ms) | 成功=100.0% | 工具=0.0% | VIOLATIONS` — 三个矛盾数据 (成功 100% + 工具 0% + overall VIOLATIONS)。② **数据驱动诊断 9 轮无盲改** (V37.9.28 4 轮诊断错 / V37.9.29 6 轮假说错五教训): 用户跑 5 项取证 → 真因清晰 → 跑 minimal repro 验证 eval vs bash -c → 假设 `bash 3.2 inline` 问题被 D/E 测试**证伪** → 最终发现真因是 macOS BSD 无 timeout 命令 (V37.9.78-hotfix 闭环) + Python `tool_calls_total=0` 时 0/0 算 0% FAIL → 误报 VIOLATIONS。③ **修 #1 真 bug — slo_dashboard.py tool_success verdict 三档**: `extract_snapshot` 加 `tool_calls_total` 字段 (V36 设计只有 tool_success_pct 无法区分 0/0 vs 真失败) + verdict 改三档 PASS/FAIL/N/A: `tool_calls_total==0` 时 verdict=N/A 不算 FAIL (`slo_checker.py:71` 已正确 `tool_total==0` 豁免, 这里对齐) + `overall` 计算时 N/A 跳过不算 FAIL (全 N/A 时 overall=N/A, 含 N/A+其他全 PASS 时 overall=ALL PASS)。④ **修 #2 阈值调整 — latency_p95_ms 30000 → 50000ms (config.yaml)**: 不是掩盖问题, 是**承认真实 baseline**. 注释明记 Mac Mini 实测 proxy_stats.json `slo.latency.p95=37570ms` (p50=26s/p95=37s/p99=53s 整体而非 outlier) + proxy.log 直接证据 `Backend: 200 5001b 29687ms` 单次 backend 29.7 秒 + 长期目标"待 multi-provider routing (V37.9.55+ doubao 试水) 或 faster LLM 稳定后恢复 30000 (V37.9.80+ 候选)". 短期 50000 减告警噪声。⑤ **修 #3 设计 debt — slo_snapshot cron 注册**: V36 设计 `slo_dashboard.py --snapshot` 写 `~/.kb/slo_history.jsonl` 但从未注册 cron → 2026-05-18 Mac Mini 实测 `History: 0 snapshots`. 修复: jobs_registry.yaml 新 `slo_snapshot` job (每小时 :05 错开 kb_status_refresh 整点) + 新 wrapper `slo_snapshot.sh` (kb_status_refresh.sh 同款 .sh 包装规避 `_format_cron_line` 假设 bash exec 与 .py shebang 不兼容) + `auto_deploy.sh FILE_MAP` 加 `slo_snapshot.sh` + 顺便补 `slo_dashboard.py` (V36 历史 debt 一直未在 FILE_MAP) + `docs/config.md` 漂移修补 + 一周观察后能看真 SLO 趋势。⑥ **16 新单测 4 类** test_v37_9_79_slo.py: TestV37979ToolSuccessNAFix(6 含 extract_snapshot 加字段守卫 / verdict N/A 当 tool_calls=0 / overall 跳过 N/A / 真失败仍 FAIL / 真成功 PASS / source-level grep 用 tool_calls_total==0 不用 requests<5) + TestV37979LatencyThresholdAdjusted(2 含 50000 active 值 + 注释充分性 Mac Mini/37570/multi-provider 三大证据词) + TestV37979SloSnapshotJob(5 含 jobs_registry 新 entry / slo_snapshot.sh 文件+可执行+FAIL-OPEN / bash -n 语法 / FILE_MAP 双 entry / runtime 真跑 fail-open exit 0 即使无 proxy_stats.json) + TestV37979ReverseValidation(3 sabotage tool_calls_total 字段移除 → fail / 阈值改回 30000 → fail / 删 slo_snapshot job → fail). ⑦ **修两个 regression**: `test_slo_dashboard.test_latency_violation` p95 input 50000 → 60000ms (V37.9.79 阈值改后 p95==50000 正好等于阈值 PASS, 改 60000 才触发 FAIL) + docs/config.md 加 slo-snapshot 行 (gen_jobs_doc --check 漂移检测抓到)。⑧ **累计**: 91→92 suites (+1) / 3158→3174 tests (+16) / 0 fail / governance 79 inv / 715 checks 不变 / 安全 95/100 / VERSION 0.37.9.68 不变。⑨ **Mac Mini 部署后行为** (5/19 周一上午 cron 触发 + 用户手动 sync 后): (a) 下次 `bash ~/health_check.sh` 应**首次看到** SLO 段 verdict 改为 ALL PASS (不再 VIOLATIONS 因 tool=N/A 不算 FAIL) (b) 每小时 :05 `slo_snapshot.sh` 写 `~/.kb/slo_history.jsonl` 累积 (用户需 `bash ~/crontab_safe.sh add '5 * * * * bash -lc "bash ~/slo_snapshot.sh >> ~/slo_snapshot.log 2>&1"'` 手动注册) (c) 一周后 (5/25) cat ~/.kb/slo_history.jsonl 应有 ~168 条快照 → trend_24h/trend_7d 真有数据驱动决策 (d) 长期 V37.9.80+ 候选: 趋势数据反馈调阈值 50000 → 30000 / multi-provider 试水让 p95 真下降。⑩ **元价值 — 数据驱动诊断方法论硬实证**: 全程 9 轮取证 + 0 次盲改 (对比 V37.9.28 4 轮诊断错 / V37.9.29 6 轮假说错五的反面教训). 每次假设都用 minimal repro 验证 (eval vs bash -c / inline vs 变量 / 中文 vs ASCII / fallback 字段). MR-10 understand-before-fix 第 N 次正向兑现. 原则 #28 "理解再动手" 一字不漏严格执行. 用户视角原则 #13 第 N+4 次正向兑现 — 用户看到周报中 3 个矛盾数据 1 分钟提出, 9 轮诊断 + 实施 + 单测 + 反向验证 + 文档 < 2 小时同 session 内闭环。⑪ **下次 V37.9.80+ 候选**: (a) **主硬卡**: Mac Mini 5/19 周一上午 09:00 cron 真激活 V37.9.79 后验证 SLO 段 verdict=ALL PASS (b) 5/25 一周后看 `~/.kb/slo_history.jsonl` 168 快照真趋势数据 (c) MOVESPEED EPERM #3 真根因调查 (V37.9.30 取证维度 8/9 数据回归一周) (d) latency 阈值数据驱动决策 (50000 → 30000 待 doubao 试水稳定后) (e) V37.9.77 ROUTER_ENFORCE=on 试水 (Mac Mini operator 决策时机). |
| V37.9.78-hotfix | 2026-05-18 | **safe_call helper macOS BSD timeout 命令兼容性修复 — Mac Mini 实测同 session 30 分钟闭环** — ① **触发**: V37.9.78 主交付合并到 main (PR #574) 用户 Mac Mini 立即同步 + 跑 `bash ~/health_check.sh` 实测, 输出显示 **SLO/安全评分/治理审计 3 段全部显示"工具不可用"**, 而 MOVESPEED 24h (13 incidents)/X 监控/KB/SSD 等段全正常. ② **真根因**: macOS BSD 默认**不带 `timeout` 命令** (GNU coreutils 才有, 需要 `brew install coreutils` 装 gtimeout). V37.9.78 safe_call helper `result=$(timeout 30 bash -c "$cmd" 2>/dev/null) || result=""` 在 macOS 上 timeout 命令 not found → exit 非 0 → result="" → 触发 fallback "工具不可用". MOVESPEED 段没走 safe_call (用 `if [ -f "$INCIDENT_MONITOR" ]` 直接判断 + 直接 python3 调用) 所以正常工作 13 incidents — 这个对照实证铁证 timeout 缺失是根因. ③ **MR-4 silent-failure 新形态**: V37.9.78 dev linux 全跑通 (linux 自带 timeout), 单测 + governance + preflight 全绿, **只有 Mac Mini 真实部署才暴露**. 类比 MR-15 deployment-layout-must-be-tested-on-target (V37.9.56-hotfix / V37.9.76-hotfix 同款血案兄弟). 原则 #28 三问全过: Q1 之前不存在 (V37.9.78 引入 safe_call helper 时才有 timeout 依赖) / Q2 我引入 ✓ (V37.9.78 safe_call 设计假设 timeout 跨平台可用) / Q3 最小修复 = command -v 检测后三档 fallback. ④ **修复 (V37.9.78-hotfix)**: safe_call 升级为三档 fallback chain — (1) `command -v timeout` 检测 → 有则用 `timeout 30 bash -c "$cmd"` (linux 主路径) (2) `command -v gtimeout` 检测 → 有则用 `gtimeout 30 bash -c "$cmd"` (macOS Homebrew coreutils) (3) 都没有 → 直接 `bash -c "$cmd"` (macOS BSD 默认环境, 依赖 cmd 自身超时机制 — 周报每周一次极少挂). ⑤ **2 新单测 (32→34)**: TestSourceGuards.test_v37_9_78_hotfix_timeout_fallback_chain (5 字面量守卫: V37.9.78-hotfix marker / command -v timeout 检测 / command -v gtimeout 检测 / macOS BSD 注释 / 函数体 ≥3 timeout 引用反退化守卫) + TestSafeCallHelper.test_v37_9_78_hotfix_command_v_timeout_detection_runtime (dev linux subprocess 真跑 safe_call 冒烟). ⑥ **dev 验证**: env -i PATH=/tmp 真模拟 macOS 无 timeout 场景 — `command -v timeout` 返回 1 → safe_call 走第三档 fallback → bash 内置 echo 仍可用 → 返回 "HELLO_FROM_BASH_BUILTIN" 正确. **铁证三档 fallback 工作**. ⑦ **累计**: 91 suites 不变 / 3156→3158 tests (+2) / 0 fail / governance v3.46 不变 (INV-HEALTHCHECK-001 内涵扩 17 checks 不变) / 79 inv 不变 / 715 checks 不变 / 19 MR / 安全 95/100 / VERSION 0.37.9.68 不变 (hotfix 不 bump). ⑧ **Mac Mini 部署后预期**: 同步 hotfix 后再跑 `bash ~/health_check.sh` 应**首次看到** 📊 SLO p95 真数据 + 🛡 95/100 评分 + 🏛 79 不变式 pass=79 (而不是"工具不可用"). 5/19 周一 09:00 cron 真激活时用户 WhatsApp + Discord #日报 收到完整 9 段证据周报. ⑨ **元教训 — MR-15 (deployment-layout-must-be-tested-on-target) 第 N+2 次正向兑现**: V37.9.78 主交付 dev linux 真跑 9 段全通过 + 32 单测 + governance 全绿, 我做了我能做的所有 dev 验证 — **仍漏了 macOS BSD timeout 缺失这个跨平台陷阱**, 只有 Mac Mini 真激活才能抓到. 这次"同 session 内闭环"(用户 10 分钟内反馈 → 我 5 分钟根因 + 实施 + 单测 + commit + push) 是用户视角原则 #13 + MR-15 元规则 + 原则 #14 (主动给同步指令) 三者协同的硬实证. ⑩ **下次 V37.9.79+ 候选**: (a) **主硬卡**: Mac Mini 5/19 09:00 cron 真激活 V37.9.78-hotfix 后验证 9 段全数据 (b) 立 INV-CROSS-PLATFORM-001 守卫 "shell helpers 必须考虑 macOS BSD 工具差异" (扩展 INV-CROSS-OS-001) 作为 MR-15 framework 化路径 (c) 其他用 `timeout` 命令的脚本 audit 是否有同款 macOS 兼容性 debt (grep 全仓库 `^timeout 30` / `^timeout [0-9]`) (d) 同款 audit 扩展到其他 GNU-specific 命令 (sed -i 大括号差异 / readlink -f / xargs -I 大括号 / 等). |
| V37.9.78 | 2026-05-18 | **health_check.sh 周报重定位 v1.1 → v2.0 "系统证据周报" — 用户视角原则 #13 第 N+2 次正向兑现 + INV-HEALTHCHECK-001 立** — ① **触发**: 用户开工后 WhatsApp 主动报告"📊 OpenClaw 周报 ... 这个任务太单薄了, 要不删除要不进一步增强优化"。审视当前 health_check.sh (132 行 v1.1, 每周一 09:00 cron) 输出: 服务状态 + 模型ID + 任务统计 + KB 条数 + SSD + Session 历史 — **大部分内容是"看看就好"的数字, 不指向任何决策**。② **三方案对比 + 用户决策方案 A** (重定位为"系统证据周报", 非删除/轻量增强): (a) 与现有任务对齐分析: 任务统计 与 daily_ops_report (每日 08:15) 重叠 / 服务状态 与 wa_keepalive + job_watchdog 实时告警重叠 / KB 新增条数 与 kb_review (周深度回顾) + kb_trend (周趋势) 重叠 (b) 真正盲区识别: SLO 趋势 (V36 slo_dashboard 已有未接入周报) / 治理审计 + 安全评分趋势 (每日跑但没汇总) / MOVESPEED incident 24h 计数 (V37.9.27 取证机制 operator 不主动看) / X 监控质量 (V37.8.4 INV-X-001 立但僵尸账号检测从未汇总). ③ **v2.0 设计契约** (5 项, INV-HEALTHCHECK-001 严格守): (1) **9 段证据 emoji marker**: 🖥服务 + 🤖模型 + 📊SLO + 🛡安全评分 + 🏛治理审计 + 🛟MOVESPEED + 🐦X监控 + 📚知识库 + 💾SSD (2) **MR-8 single-source-of-truth**: 所有数据走外部工具 (slo_dashboard.py / security_score.py / .audit_metrics.jsonl / movespeed_incident_monitor.py) 不内嵌采集逻辑 — 字段/接口变化只需改一处 (3) **safe_call helper 三层 FAIL-OPEN**: 工具不存在 / timeout / parse 失败都降级显示"暂无/不可用"不阻塞推送 (周报型 auxiliary tier fail-open, 与 kb_review V37.5 fail-fast 区分) (4) **推送优先 notify.sh --topic daily** (V35+ 重试+队列), fallback openclaw 直推保留 (双通道独立, V37.8.13 教训告警链不依赖失效主体自身) (5) **health_status.json 机器可读契约保留** (HEALTH_JSON_PATH env, version=v37.9.78, services/model/kb/ssd 五字段). ④ **实施 (4 commits 全在 1 个 PR)**: (a) **health_check.sh 重写 224 行**: 顶部 safe_call() 函数 (timeout 30 + fallback) + 9 段并行采集 + REPORT 拼装 + JSONEOF 机器可读输出 + 优先 notify.sh / fallback $OPENCLAW (b) **测试 test_health_check_v37_9_78.py 32 单测 5 类**: TestSourceGuards(15 V37.9.78 marker / safe_call / 9 段 emoji / SLO 字段名 current.p95_ms 校对 / security/governance/incident/zombie 集成 / notify.sh 优先 / v1.1 反模式移除三项) + TestSafeCallHelper(5 subprocess 真跑 success/false-cmd/empty/not-found/set-e-safe) + TestRuntimeBehavior(3 真 subprocess + dev 全 9 段输出 + FAIL-OPEN 不抛 Traceback + JSON schema v37.9.78) + TestReverseValidation(4 sabotage marker/SLO 段/字段名/safe_call 守卫真有效) + TestGovernanceLineage(6 V36 slo_dashboard / V30.2 security_score / V37.1 audit_metrics / V37.9.27 incident_capture / V37.8.4 INV-X-001 / V37.8.13 alert-independence) (c) **INV-HEALTHCHECK-001 新增** (meta_rule=MR-8, severity=high, verification_layer=[declaration, runtime], **17 checks**): 16 declaration file_contains/file_not_contains (V37.9.78 marker / 系统证据周报文案 / safe_call 函数定义 escape regex / 7 段 emoji / 4 外部工具 single-source-of-truth / --topic daily / 3 项 v1.1 反模式 file_not_contains) + 1 runtime python_assert subprocess 真跑 32 单测全过 (180s timeout). (d) **接入 full_regression.sh** suite `health_check_v37_9_78`. ⑤ **dev 环境真跑验证 9 段 FAIL-OPEN 行为**: 🖥服务 (dev 都 🔴 正确) / 🤖模型 (❓ 检查不可用 — API + 配置文件缺) / 📊 SLO: 暂无历史快照 (proxy 未活跃, dev OK) / 🛡 安全评分: 95/100 (95.0%) | 弱项: 传输安全 (真实数据) / 🏛 治理审计: 🟢 78 不变式 / pass=78 fail=0 error=0 / 5230ms (.audit_metrics.jsonl 真读) / 🛟 MOVESPEED 24h: 🟢 0 incidents (无取证累积, dev 缺 jsonl 降级文案) / 🐦 X 监控质量: ❓ (工作目录不存在, dev 缺 ~/.openclaw/jobs/finance_news/cache) / 📚 知识库: 本周 +0 / 共 0 条 (dev OK) / 💾 外挂 SSD: 🟡 未挂载 (dev OK). **9 段全部输出无 Traceback, 三层 FAIL-OPEN 工作正常**. ⑥ **关键 bug 修复 — SLO 段字段名错配 + CLI 调用方式**: 实施过程中 dev 实跑发现"📊 SLO: 解析失败 (JSONDecodeError)", 根因双重: (1) `slo_dashboard.py --json` 单参数 CLI **不输出任何内容** (需 `--dashboard --json` 组合, slo_dashboard main() 设计 do_snapshot/do_dashboard 都=False) (2) JSON 真实字段是 `current.p95_ms` / `current.success_pct` / `trend_24h.avg_p95_ms` / `overall` (不是 health_check 第一版假设的 `current_metrics.p95_latency_ms` / `success_rate_pct` / `trend.X` / `history_count`). 修正后 ✅ "暂无历史快照 (proxy 未活跃)". 测试加 `test_slo_uses_dashboard_json_correct_cli` + `test_slo_field_names_correct` 防回归. ⑦ **累计**: 90→91 suites (+1: health_check_v37_9_78) / 3124→3156 tests (+32) / 0 fail / governance v3.46 内涵扩 / 78→79 invariants (+1 INV-HEALTHCHECK-001) / 698→715 checks (+17) / 19 meta rules 不变 (V37.9.78 复用 MR-8 single-source-of-truth, 不立新元规则) / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.78 重构现有 cron 任务不增功能不 bump). ⑧ **从 _PUSH_ROUTE_WHITELIST 角度看影响**: health_check.sh 仍在白名单 (V37.8.18 加的"周报直推"豁免) — V37.9.78 fallback 路径仍走 `$OPENCLAW message send` 直推 (保留 v1.1 契约), 但**优先路径**已切到 notify.sh, 让用户 WhatsApp/Discord 享受 V35+ 的 retry + 队列 + 失败重放机制. 一周观察后可考虑从白名单移除 (V37.9.79 候选). ⑨ **Mac Mini 部署后预期行为** (5/19 周一上午 09:00 cron 触发): (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 (b) 09:00 cron 自动触发 → 新 9 段证据周报推送到 WhatsApp + Discord #日报 (c) 用户对比 v1.1 单薄推送 vs v2.0 证据周报 — 应**首次看到**: 📊 SLO p95 实时数据 / 🛡 95/100 评分 / 🏛 79 不变式 78 pass / 🛟 MOVESPEED 真实 24h incident 计数 / 🐦 X 监控本周僵尸账号数. ⑩ **元价值 (用户视角原则 #13 第 N+2 次正向兑现)**: 单测/治理/preflight 全过但用户实际收到推送觉得"太单薄"才暴露 — 类比 V37.8.11 drift 噪声告警 (用户半天 WhatsApp 观察才发现治理债) / V37.9.68 Qwen-BIM 连续几周重复 (用户视角对内容质量的判断不可被组件级测试替代). **V2 路标"别人敢用 = 证据密度"兑现**: 不只是有 SLO/governance/security score 数据 (V35-V37 都有), 还要把这些数据**汇总成可决策的周度证据流** — 让用户每周一上午 9 点收到一条消息就能判断"本周系统真实健康度", 这是数据复利从"采集"升级为"消费"的关键拐点. V3 路标 `pip install ontology-engine` 终极目标的可观测性周报标杆 — 任何项目把多个 V35-V37 工具拼装成 v2.0 风格证据周报是可机械化的, 这是 framework 真正"别人会扩展"的硬证据. ⑪ **下次 V37.9.79+ 候选**: (a) **主硬卡**: Mac Mini 5/19 09:00 cron 真激活验证用户视角对 v2.0 周报的质量评价 (b) 从 _PUSH_ROUTE_WHITELIST 移除 health_check (已走 notify.sh, 不再需要白名单豁免) (c) 其他 cron 周报型任务同款审视: kb_trend (每周六 09:00) / kb_review (每周五 21:00) 是否也需要 v2.0 风格升级 (d) V37.9.77 ROUTER_ENFORCE=on 试水 (Mac Mini operator 决策时机, 1-3 天观察) (e) tool_proxy:5002 透传 ?provider= 让 hf_papers 经 proxy 也能用 enforcement (V37.9.77+ 候选). |
| V37.9.77 | 2026-05-18 | **Capability Router enforcement (?provider=X query param + ROUTER_ENFORCE env feature flag) — V37.9.76 PoC shadow → enforcement 框架就位** — ① **触发**: V37.9.76 + V37.9.76-hotfix Mac Mini 真激活 chosen=doubao 成功后用户决策"继续 V37.9.77 enforcement", 把 shadow logging 升级为真路由切换框架. 用户跳过原一周观察期, 接受 feature flag 默认 off 设计 (PoC 安全网). ② **adapter.py `?provider=X` query param 支持**: 新增 `_resolve_primary_provider(self)` 方法返回 5 元组 (base_url/model_id/auth_style/api_key/provider_name). ROUTER_ENFORCE=off (默认) → 返回默认 PROVIDER_NAME 不解析 query / ROUTER_ENFORCE=on + ?provider=X 有效 → 用 override / ROUTER_ENFORCE=on + ?provider=unknown 或缺 API key → silent fallback default (FAIL-OPEN). `do_POST` 用 `urlparse(self.path).path` strip query 拼 forward URL (provider API 不识别 ?provider=). use_model 加 override 分支 (VL 路由仅默认 provider 用). FAST_ROUTE 也加 override 检查 (尊重 router 选择). primary_auth 用 `_make_auth_headers(primary_auth_style, primary_api_key)` (override 时 doubao auth, 默认时 qwen auth). ③ **adapter.py server startup 重构**: `with ThreadedServer(...).serve_forever()` 从模块 top-level 移到 `if __name__ == "__main__":` 块. 让 `import adapter` 不再 bind port, 单测可正常运行 (V37.9.77 PoC blast radius 副产物 — 修了多年的可测性 debt). ④ **kb_dream.sh llm_call 6th 参数 + RADAR retry 集成**: `llm_call` 函数签名 `local provider_override="${6:-}"` 接受可选 ?provider= override + `effective_url=$LLM_URL` (或 `${LLM_URL}?provider=${provider_override}` 当 override 非空时). curl 用 `$effective_url` 替代 `$LLM_URL` 常量. RADAR retry 调用前加 `ROUTER_ENFORCE` 门控 — 默认 off 时 `EFFECTIVE_PROVIDER=""` 行为同 V37.9.76 shadow, on 时 `EFFECTIVE_PROVIDER=$ROUTER_CHOICE` 真传给 llm_call. ROUTER_CHOICE 过滤 sentinel 值 (`unknown` / `no_router_profile` / `no_matching_provider`) 防止误传给 adapter. ⑤ **router_decide.py `_resolve_mode()` 函数**: 读 `ROUTER_ENFORCE` env 决定 `mode` 字段 ("shadow" / "on" 两态), JSONL record `mode` 字段动态化跟随 env. 大小写不敏感 + 未知值 fallback shadow (FAIL-CLOSED 安全默认). decide() record dict `"mode": _resolve_mode()` 替代 V37.9.76 硬编码 `_MODE_DEFAULT`. ⑥ **关键安全设计 — ROUTER_ENFORCE=off 默认**: 三方契约 (adapter + kb_dream + router_decide) 都用 `os.environ.get("ROUTER_ENFORCE", "off")` / `${ROUTER_ENFORCE:-off}` 默认 off. V37.9.77 commit 落地框架不破坏现有行为 — Mac Mini operator 可单独 flip env var 试水观察 1-3 天再决定是否永久 on. **避免 blast radius**: PR 合并即生效 enforcement 反模式被禁止. ⑦ **三方契约一致性**: 三处 V37.9.77 marker (adapter / kb_dream / router_decide) + 三处 ROUTER_ENFORCE 字面量统一 + 三处默认 off — TestV37977EndToEndShellGuards 锁定. ⑧ **三阶 FAIL-OPEN 防御**: (1) ROUTER_ENFORCE=off → 跳过 query 解析直接 default (2) ?provider=X 但 X 不在 PROVIDERS 注册表 → silent fallback default (3) ?provider=X 但 X 缺 API key (ovr_api_key=="") → silent fallback default. 三层防御让 caller 误传任何错误 provider 名都不会破坏 LLM 真调用. ⑨ **27 新单测 test_v37_9_77_enforcement.py 5 测试类**: TestAdapterResolvePrimaryProvider(8 含 no_override/enforce_off_ignores/enforce_on_valid/missing_api_key_fallback/unknown_provider_fallback/empty_provider/malformed_query) + TestKbDreamShellEnforcementIntegration(6 含 llm_call 6th 参数 + effective_url + curl 用 effective_url + ROUTER_ENFORCE 门控 + sentinel 过滤 + 默认 shadow 兼容) + TestRouterDecideModeReflectsRouterEnforce(4 含 _resolve_mode 大小写不敏感 + 未知值 fallback shadow + record mode 字段动态化) + TestAdapterSourceLevelGuards(7 含 _resolve_primary_provider 定义 + ROUTER_ENFORCE feature flag + parse_qs import + strip query + FAIL-OPEN return + override 禁 FAST_ROUTE + override log) + TestV37977EndToEndShellGuards(3 含 ROUTER_ENFORCE 三方一致 + default off 三方一致 + V37.9.77 marker 三方齐). **反向 sabotage 三轮守卫真有效**: (a) adapter 改 `enforce=True` 硬编码 → test_router_enforce_off_ignores_override 立即 fail (b) kb_dream 删 ROUTER_ENFORCE 门控 → 1 fail (c) curl 仍用 $LLM_URL → 1 fail. 还原后 27/27 全过. **关键修测**: test_router_enforce_off_ignores_override 加 `with patch.dict(ARK_API_KEY=...)` 隔离测试 — 否则第二层 API key 检查同时阻止让 sabotage 守卫失效 (mock 强度提升). ⑩ **集成 full_regression.sh** +1 suite v37_9_77_enforcement. **V37.9.76 历史 test 扩窗 500→1000**: test_router_decide_called_before_radar_retry_llm_call 因 V37.9.77 ROUTER_ENFORCE 块插入推开 router_decide 到 llm_call 距离 (合法演进, 语义不变). ⑪ **INV-ROUTER-001 +7 V37.9.77 checks**: _resolve_primary_provider 方法定义 + ROUTER_ENFORCE 三方一致默认 off (python_assert 跨三文件) + strip query 守卫 + llm_call provider_override 6th 参数 + curl effective_url + _resolve_mode 函数 + 27 单测全过 runtime. audit_metadata 691→698 checks. ⑫ **V37.9.77 副产物副红利**: adapter.py 长期可测性 debt 修复 — `if __name__ == "__main__":` 让 `import adapter` 不再 bind port, V37.9.77 之后所有 adapter 相关单测可直接 import 不需 subprocess. dev 环境意外发现 lingering pid 5695 (V37.9.77 早期 import 实验留下) — 已 kill, convergence test 恢复 baseline. ⑬ **累计**: 89→90 suites (+1) / 3097→3124 tests (+27) / 0 fail / governance v3.46 不变 (INV-ROUTER-001 内涵扩) / 78 invariants 不变 / 691→698 checks (+7) / 19 meta rules 不变 / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.77 enforcement opt-in framework, ROUTER_ENFORCE=on 才真激活, 不 bump VERSION). ⑭ **Mac Mini 部署后行为 (默认 ROUTER_ENFORCE=off)**: (a) auto_deploy 同步 V37.9.77 adapter.py + kb_dream.sh + router_decide.py 到 ~/ (b) **行为不变** — kb_dream cron 触发时 ROUTER_ENFORCE=off → EFFECTIVE_PROVIDER 留空 → llm_call 不传 ?provider= → adapter 用默认 PROVIDER_NAME (V37.9.76 shadow 行为完全保留) (c) router_decisions.jsonl 字段 mode 仍是 "shadow" (d) operator 想试水时 `export ROUTER_ENFORCE=on` 加到 crontab cron 任务环境 OR `bash ~/.bash_profile` (e) 验证 enforcement 真激活: 跑 `ROUTER_ENFORCE=on python3 ~/router_decide.py --job-id kb_dream --task test --json | jq .mode` 应输出 "on". ⑮ **V37.9.78+ 候选**: (a) **主硬卡**: ROUTER_ENFORCE=on 试水 1-3 天 (Mac Mini operator 决策时机), 观察 chosen=doubao 真激活情况 + LLM 调用成功率 (b) tool_proxy:5002 透传 ?provider= 让 hf_papers 经 proxy 也能用 enforcement (V37.9.78 主交付候选) (c) 一周观察数据后评估默认 ROUTER_ENFORCE=on (Plan B 渐进路径 shadow → on 终态) (d) 扩展 capability profile 到更多 ALIGNED job (arxiv_monitor / dblp / acl_anthology / semantic_scholar 等 V37.9.51 11 个) (e) router_decisions.jsonl 周报自动化 (cat | jq | sort | uniq -c). ⑯ **元价值 (V3 路标 declarative capability framework enforcement 阶段)**: V37.9.76 shadow → V37.9.77 enforcement opt-in (feature flag + 三层 FAIL-OPEN) = framework 渐进 Plan B 路径完整推进. 同日 5 件套交付 (V37.9.75 DEEP retry + V37.9.74 RADAR retry 首次激活 + V37.9.76 PoC shadow + V37.9.76-hotfix layout + V37.9.77 enforcement framework). |
| V37.9.76-hotfix | 2026-05-18 | **router_decide.py deployment-layout 修复 — Mac Mini 首跑发现 PATH+FALLBACK 重合 silent fail** — ① **触发**: 2026-05-18 09:29 Mac Mini 真激活 V37.9.76 smoke test 输出 `WARN: jobs_registry.yaml not found in ['/Users/bisdom/jobs_registry.yaml', '/Users/bisdom/jobs_registry.yaml']` — 两候选完全相同, chosen=null + reason=no_router_profile silent fail. ② **根因**: V37.9.76 设计了 PATH 和 FALLBACK 两候选, 但 FALLBACK = `os.path.dirname(os.path.abspath(__file__))/jobs_registry.yaml`. Mac Mini 部署 router_decide.py 到 `$HOME/router_decide.py` 后 `dirname(__file__) = $HOME`, 让 FALLBACK 等同 PATH. 真正的 canonical yaml 在 `$HOME/openclaw-model-bridge/jobs_registry.yaml` (auto_deploy 同步源) 不被搜索. ③ **修复**: 加 `JOBS_REGISTRY_MAC_MINI = os.path.expanduser("~/openclaw-model-bridge/jobs_registry.yaml")` 作第二候选, candidates 列表顺序 `[PATH, MAC_MINI, FALLBACK]`. ④ **测试**: +2 V37.9.76-hotfix 守卫单测 (MAC_MINI 常量存在 + candidates 列表三档顺序锁), 既有 FAIL-OPEN 测试 patch 三候选确保 yaml 缺失场景仍工作. 反向 sabotage 验证: 移除 MAC_MINI 候选 → 1 fail. 还原 45/45 OK. ⑤ **governance INV-ROUTER-001 +1 check** (Mac Mini canonical 路径 + candidates 列表字面量 python_assert). audit_metadata 690→691 checks. ⑥ **MR-15 (deployment-layout-must-be-tested-on-target) 第 N+1 次正向兑现**: dev 单测 43/43 + Mac Mini preflight 全过, 但只有 Mac Mini 真激活 router 才暴露路径假设错配. ⑦ **原则 #28 三问全过**: Q1 V37.9.76 引入 / Q2 router_decide.py FALLBACK 假设 / Q3 最小修复 = 加 MAC_MINI 候选不动 PATH/FALLBACK 向后兼容. 累计 89 suites 不变 / 3095→3097 tests (+2) / 0 fail / governance 690→691 checks (+1) / 78 inv 不变 / 19 MR 不变 / 安全 95/100 / VERSION 0.37.9.68 不变. **Mac Mini 部署后预期**: `python3 ~/router_decide.py --job-id kb_dream --task radar_retry` 应输出 `chosen=doubao` (从 ~/openclaw-model-bridge/jobs_registry.yaml 读 kb_dream profile = required_capabilities=[text]+prefer=[reasoning]+cost_tier=low → router 选 doubao cap_score=16). |
| V37.9.76 | 2026-05-18 | **Capability-Based Dynamic Router PoC (shadow mode) — V3 路标 declarative capability framework 落地** — ① **触发**: 5/18 早 V37.9.75 DEEP retry hotfix + V37.9.74 RADAR retry 首次生产激活成功 (08:50 用户手动 kb_dream.sh 验证 RADAR drift 自动恢复 4949 chars retry-recovered 4/4 完整推送, V37.9.74 主硬卡 < 24h 闭环) 双双闭环后, 用户决策启动原 V37.9.75 capability router PoC (因版本号已被 5/18 hotfix 占用改 V37.9.76 续推进). 4 步同 PR 全做 4-6h 路径. ② **Step 1 jobs_registry.yaml schema 扩展** (无破坏性): kb_dream + hf_papers 两个试水 job 加 3 可选字段 `required_capabilities: [text]` + `prefer: [reasoning]` (仅 kb_dream) + `cost_tier: low`. 其他 38 jobs 暂不声明, fall-back 当前行为. check_registry 通过 40 jobs validated. ③ **Step 2 providers.py find_best_provider** (70 行纯函数): 接受 required (dict 硬过滤 — 必须 ALL 匹配, 不存在 capability → None) + prefer (list 每命中 +10 加权 tie-breaker) + exclude (排除指定 provider names) + require_available (True 时只考虑 API key 已配置). 内部走 _capability_score (V37.9.53+ 含 reasoning 维度) 排序. 验证: kb_dream 配置 → doubao (cap_score=16, V37.9.55+ doubao 试水承诺自然兑现 — task 声明 reasoning+cost_tier=low → router 自动选 doubao, 不硬编码). ④ **Step 3 新文件 router_decide.py shadow 模式 CLI** (~280 行 stdlib only): `decide(job_id, task, exclude, profile_override, require_available)` 主入口返回 dict record (13 字段稳定 schema: ts/task/job_id/required/prefer/cost_tier/exclude/chosen/chosen_cap_score/alternatives/mode/reason/v37_9_76). `_load_yaml_job_profile()` lazy import yaml + 双路径 fallback ($HOME/jobs_registry.yaml + SCRIPT_DIR/jobs_registry.yaml). `_call_find_best_provider()` lazy import providers + 顶层 try/except → FAIL-OPEN 返回 (None, [], None). `append_jsonl()` mkdir -p + UTF-8 + readonly path 不抛异常返回 False. CLI 默认 stdout=chosen name (caller $() 命令替换可捕获), --json 完整 record, --no-log 跳过 JSONL, --require-available 默认 False (shadow 模式允许 dev 无 key 仍记录). **MR-11 兑现**: log() 显式 file=sys.stderr 防污染 caller stdout. **FAIL-OPEN 契约**: registry/providers/yaml 任一缺失或异常都返回 reason="no_router_profile" / "no_matching_provider" + exit 0 不阻塞 caller LLM 调用. ⑤ **Step 4 observability ~/.kb/router_decisions.jsonl** append-only JSONL (V37.9.18 audit_log 同款 mtime-stable 风格): 每次 router_decide 调用追加 1 行 JSON, caller (kb_dream/hf_papers) 命令替换捕获 chosen 但**不实际改 LLM 路由** (adapter PROVIDER_NAME 默认主路径). 一周观察期数据 `cat ~/.kb/router_decisions.jsonl \| jq .chosen \| sort \| uniq -c` 看 router 对不同 task 的偏好分布. ⑥ **集成入 kb_dream.sh RADAR retry + jobs/hf_papers/run_hf_papers.sh per_paper LLM 调用前** (Shadow mode — 决策记录不改路由): 5 行 shell 调用 (双路径 $HOME + SCRIPT_DIR fallback + 2>/dev/null + \|\| true FAIL-OPEN), ROUTER_CHOICE 变量捕获 chosen, log 显式标 "V37.9.76 router (shadow): chosen=X (decision logged, not enforced — adapter PROVIDER_NAME 真实路由不变)". ⑦ **关键设计决策**: shadow mode 不强制路由 — 镜像 V37.9.19 → V37.9.23 → V37.9.58 Plan B 同款渐进策略路径 (declarative → shadow → on), 一周观察期数据反馈调 cap_score, V37.9.77+ 评估 enforcement (adapter ?provider= 支持, V37.9.55+ 候选 B 继续). **避免 blast radius**: 即使 router 决策错误 (如选了 quota 满的 provider), LLM 真实调用走 adapter 默认 fallback chain (Qwen3 primary → doubao+gemini fallback), 不受影响. ⑧ **auto_deploy FILE_MAP** 加 `router_decide.py\|$HOME/router_decide.py` (V37.9.76 marker 部署 Mac Mini 后立即生效). ⑨ **43 新单测 test_v37_9_76_router.py 8 测试类**: TestFindBestProvider(10 含 required/exclude/prefer/require_available + empty dict 等同 None + exclude all → None) + TestRouterDecideModule(8 含 decide known/unknown job + profile_override + record schema 稳定性 + append_jsonl mkdir+fail-open + load_profile missing yaml) + TestRouterDecideCli(5 含 subprocess 真跑 basic/json/fail-open + MR-11 stderr 守卫 + exclude param) + TestJobsRegistrySchemaExtension(3 含 kb_dream/hf_papers 双 profile + arxiv_monitor 暂不声明 V37.9.77+ 扩展守卫) + TestKbDreamShadowIntegration(5 含 router 在 llm_call 前 + job_id+task 正确 + FAIL-OPEN + 双路径 fallback + shadow 显式 log) + TestHfPapersShadowIntegration(3) + TestAutoDeployFileMap(1) + TestV37976SourceLevelGuards(7 含 V37.9.76 marker / shadow 默认 / MR-11 stderr / lazy import yaml+providers / JSONL 路径锁定). **反向 sabotage 三轮守卫真有效**: (a) 移除 find_best_provider 函数 → 18 failures+errors (Step 2 守卫 + 全部依赖测试 fail) (b) 删 kb_dream router 整段调用 → 1 fail (test_shadow_mode_explicit_in_log) (c) router_decide log 改写 sys.stdout (MR-11 violation) → 1 fail. 还原后 43/43 OK. ⑩ **集成入 full_regression.sh**: +1 suite v37_9_76_router. ⑪ **INV-ROUTER-001** 新增 (meta_rule=MR-7, severity=high, verification_layer=[declaration, runtime], **12 checks**): 11 declaration (find_best_provider 函数 + 签名 3 参数 / router_decide.py 存在 + V37.9.76 marker / _MODE_DEFAULT="shadow" / file=sys.stderr / JSONL 路径 / kb_dream profile / hf_papers profile / kb_dream RADAR retry 集成 / hf_papers 集成 / auto_deploy FILE_MAP) + 1 runtime python_assert (subprocess 跑 test_v37_9_76_router.py 43 单测全过). ⑫ **累计**: 88→89 suites (+1) / 3052→3095 tests (+43) / 0 fail / governance v3.45→v3.46 / 77→78 invariants (+1 INV-ROUTER-001) / 678→690 checks (+12) / 19 meta rules 不变 (V37.9.76 是 PoC shadow 阶段, 不立新元规则) / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.76 是 V37 capability framework shadow PoC, 不 bump version). ⑬ **Mac Mini 部署后预期**: (a) auto_deploy 2min 轮询自动同步 router_decide.py + jobs_registry.yaml + kb_dream.sh + hf_papers 到 ~/ (b) 下次 kb_dream cron (5/19 03:00) 触发 RADAR retry 时如 LLM drift → 第一次 router_decide shadow 记录追加到 ~/.kb/router_decisions.jsonl (含 chosen=doubao + alternatives 5 + cap_score=16 + mode=shadow + reason=ok) (c) 下次 hf_papers cron (5/19 10:00) 触发时每 paper LLM 调用前都记录决策 (~10 条/天) (d) **关键不变**: LLM 真实路由走 adapter PROVIDER_NAME 默认主路径, router_decide.py 是观察者不是 enforcer (e) 一周观察 (5/25) 后 cat ~/.kb/router_decisions.jsonl 数据分析 chosen 分布 + reason 分布反馈调 cap_score. ⑭ **元价值 (V3 路标 declarative capability framework 关键里程碑)**: V37.9.55+ doubao 试水承诺从 "硬编码 doubao 路径" 升级为 "task 声明 capability requirements → router 自动选择" **声明式 framework**. V3 路标 pip install ontology-engine 终极目标的核心交付方向 — declarative capability framework 真正能做到 "task 声明 → router 选择 → observability 反馈" 完整闭环, 这与 V37.9.19+ Convergence Framework (declared→runtime 同步) 是 framework 双胞胎 (前者治理状态同步, 后者治理 LLM provider 选择). ⑮ **下次 V37.9.77+ 候选**: (a) **主硬卡**: Mac Mini 部署后 1-2 天验证 router_decide.py shadow 模式真激活 (`cat ~/.kb/router_decisions.jsonl` 看真数据) (b) 一周观察 (5/25) 后数据分析: chosen 分布 / cap_score 趋势 / 是否需要新 prefer 维度 (c) V37.9.77+ enforcement 评估: adapter.py 加 `?provider=X` query 参数支持 (V37.9.55+ 候选 B 真兑现) + caller pass chosen → adapter 真路由切换 + mode 从 "shadow" 升级 "on" (d) 扩展 capability profile 到更多 job (arxiv_monitor / dblp / acl_anthology 等 V37.9.51 ALIGNED jobs 自然候选). |
| V37.9.75 | 2026-05-18 | **kb_dream DEEP LLM partial content 修复 — DEEP retry 兜底（镜像 V37.9.74 RADAR retry 同款模式，用户决策 Option B）** — ① **触发**: 2026-05-18 03:02 Mac Mini cron [SYSTEM_ALERT] "Agent Dream 失败: V37.9.68 DEEP 段失败 (823 chars < 1200) — fail-fast，跳过 WIDE+RADAR" 用户用户视角发现"昨天dream没有正常输出答案"。Mac Mini 日志取证决定性证据: 5/15-17 三天 DEEP 稳定 6314-7125 chars / 100-113s, 5/18 突然 823 chars / 214s = **LLM 用 2x 时间产 1/8 内容** + head 显示 header 完整但 "### 发现过程" 章节刚开头就截断, 强烈暗示 LLM provider 端 stream 异常截断 (partial content). ② **完整因果链架构图** (原则 #26 异常分析宪法): LLM provider 5/18 03:02-03:06 partial 返回 → llm_call jq 提取 content 非空 return 0 (0 retry, llm_call 不检最低字数) → DEEP_CHARS 823 < MIN_DEEP_CHARS 1200 → status_file llm_failed → dream_fail_alert → exit 1 跳 WIDE+RADAR → 用户零内容. ③ **三层根因**: 触发器 (LLM provider 偶发 partial) + 放大器 (`llm_call` 只检非空不检最低字数, 0 次 retry) + 掩护者 (V37.9.68 fail-fast 设计跳过 WIDE+RADAR → 用户零内容). MR-4 silent-failure 第 N 次演出新形态: llm_call 把"客观异常 partial"当"正常短答"返回. ④ **用户决策 Option B**: DEEP 加 retry 兜底, 镜像 V37.9.74 RADAR retry 模式 (vs Option A 仅观察 / Option C fail-fast 改 fail-soft / Option D 综合). 多层防御 (prompt 严 + retry 一次 + fail-fast 兜底). ⑤ **kb_dream.sh 实施 (53 行 retry block + MIN_DEEP_CHARS 提前 + status.json schema 升级)**: (a) **触发条件** `[ -n "${DEEP_RESULT// }" ] && [ "$DEEP_CHARS" -lt "$MIN_DEEP_CHARS" ]` — 仅 partial 非空时 retry, 完全空 skip 避免浪费 token (llm_call 内已 retry 过) (b) **DEEP_RETRY_SYSTEM 严格度不降** — 明确告知 LLM "上次 partial chars" + 保留 V37.9.68 主题去重硬规则 + V37.8.6 反污染守卫 + DREAM_HG_GUARD (c) **DEEP_RETRY_PROMPT 三章节模板** — 含 BANNED_THEMES_BLOCK + REDUCE_MULTI_MATERIAL + 引用上次 DEEP_CHARS 让 LLM 重视 + V37.9.74 同款 5 项输出自检 checklist (`"## 🌙 今日深度:" 开头` / 三章节齐 / 合计 ≥1400 字 / ban-list 不重叠 / 没截断) (d) **双重验证** `DEEP_RETRY_CHARS >= MIN_DEEP_CHARS` AND `## 🌙 今日深度` header 字面量 (防 LLM 产 1400 字垃圾漏 header) (e) **成功路径** `DEEP_RESULT="$DEEP_RETRY_RESULT"` + `DEEP_CHARS=$DEEP_RETRY_CHARS` + 继续 WIDE+RADAR (用户拿到完整梦境) (f) **失败路径** fall-through V37.9.68 fail-fast exit 1 (DEEP 必过原则不破). ⑥ **status.json schema +deep_retried +deep_retry_chars 双字段** (运维监控 LLM partial content 频率): 通过 `cat ~/.kb/cache/last_run.json \| jq .deep_retried` 统计真激活率, 若 >30% runs → V37.9.76+ 评估 doubao 试水或方案 D (DEEP fail-soft). ⑦ **fail-fast 告警分支区分 retry 已尝试 vs 未触发**: DEEP_RETRIED=true → "V37.9.75 DEEP 段双失败 (原始 N chars + retry M chars 都 < MIN)" / false → "V37.9.68 DEEP 段失败 (..., retry 未触发因 LLM 完全空)". 运维可立即判别问题类型. ⑧ **16 新单测 1 类** TestV37975DeepRetryFallback: V37.9.75 marker / 血案数据溯源 (2026-05-18 + 823 + 5/15-17 字面量) / retry 触发条件 / retry block 存在 / 双重验证 chars+header / retry 成功路径 (用 retry 结果 + 更新 DEEP_CHARS) / retry 失败 fall-through (排除注释行 exit 1) / retry prompt 引用上次 partial chars / retry prompt 保留 ban-list / 输出自检 checklist (shell escape 形式) / fail-fast status_file schema / fail-fast 告警区分 retry vs not / 成功路径 schema / DEEP_RETRIED 初始化顺序锁 / MIN_DEEP_CHARS 提前定义 / V37.9.76+ doubao 候选登记. **反向 sabotage 三轮守卫真有效**: (a) 移除 retry 触发条件 → 1 fail (b) 移除 has_header 双验证 → 1 fail (c) 移除 DEEP_RETRIED=false 初始化 → 1 fail. 还原后 16/16 OK. ⑨ **V37.9.68 历史测试 fail-fast 顺序锁扩窗 500→1000**: test_deep_must_pass_fail_fast 检查 status:llm_failed 后 X chars 内必含 exit 1, V37.9.75 加 retry vs not-retry 告警双分支后 exit 1 距离从 ~300 → ~570 chars, 扩窗 1000 容纳合法演进, 语义不变. ⑩ **governance INV-DREAM-MULTITHEME-001 扩展 670→678 checks (+8 V37.9.75)**: V37.9.75 marker + DEEP_RETRY_SYSTEM 变量定义 + DEEP_RETRY_PROMPT 变量定义 + retry 触发条件 python_assert + retry 双重验证 python_assert + retry 成功路径 python_assert + deep_retried schema + deep_retry_chars schema. ⑪ **累计**: 88 suites 不变 / 3036→3052 tests (+16) / 0 fail / governance v3.44→v3.45 / 77 invariants 不变 (INV-DREAM-MULTITHEME-001 内涵扩) / 670→678 checks (+8) / 19 meta rules 不变 (V37.9.75 是 V37.9.68 DEEP 设计的 retry 兜底扩展, 不立新元规则) / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.75 仍是 V37.9.68 系列 hotfix). ⑫ **Mac Mini 部署后预期行为**: (a) 下次 LLM partial content 触发时 (5/19 或之后) → V37.9.75 retry 主动调一次 LLM → 用户拿到完整 DEEP+WIDE+RADAR (而非 [SYSTEM_ALERT] + 零内容) (b) `last_run.json` 含 `"deep_retried":true,"deep_retry_chars":NNN` 字段 — 运维通过统计真激活率监测 LLM partial 频率 (c) 当 LLM 正常输出 6000+ chars 时 → 不触发 retry, 零额外 LLM 调用 (V37.9.75 仅 partial 时激活兜底). ⑬ **元价值**: V37.9.74 RADAR retry → V37.9.75 DEEP retry = 同款模式横向扩展, 三层防御 (prompt 严 + retry 一次 + fail-fast 兜底) 在 Dream 三阶推送 (DEEP/WIDE/RADAR) 全部段位完整覆盖. **MR-4 silent-failure 新形态闭环** (llm_call 把"客观异常 partial"当"正常短答"返回, 不知道短到不合格) — V37.9.75 retry 在 DEEP 层做最低字数检查 + 主动恢复. 原则 #28 三问全过: Q1 之前不存在 (5/15-17 三天稳定 6000+) / Q2 5/18 LLM 异常引入 / Q3 最小修复 = retry block (不破 V37.9.68 fail-fast 设计原则). 用户视角原则 #13 第 N+1 次正向兑现: 单测/治理/preflight 全过, 用户 WhatsApp 凌晨 [SYSTEM_ALERT] + 上午开工反馈才暴露生产故障 → 同 session 内闭环 (用户提需求 → 完整因果链分析 → 用户决策 Option B → 实施 + 单测 + 反向验证 + 文档 + 推送 < 1h). ⑭ **下次 V37.9.76+ 候选**: (a) **主硬卡**: Mac Mini 部署后等下次 LLM partial 真激活验证 retry 工作 (通过 last_run.json `deep_retried` 字段确认) (b) V37.9.76+ doubao 试水路径 (V37.9.74 同款候选 B 继续推进, adapter `?provider=X` + retry env var) (c) 原 focus V37.9.75 capability router PoC 推迟到 V37.9.76+ 启动 (5/18 血案打断, 路径锁定不变) (d) 反思文档行动 2 INV-PATH-CONSISTENCY-001 (e) SLO p95 严重超阈值数字调查 (f) failure_modes_catalog.md 失败模式库. |
| V37.9.74 | 2026-05-17 | **kb_dream RADAR LLM drift 修复 — 方案 2 prompt 强化 + 方案 3 retry 兜底（用户决策 A 路径，B 路径 doubao 试水登记 V37.9.75）** — ① **触发**: 同日 V37.9.73 修了 chunk 切分 bug 但用户深问"为什么连续两天 chars<600?" — 真根因是 LLM 单次 WIDE+RADAR 调用偶尔漏 `## 📡 RADAR header` 导致 split_wide_radar_output 返回 `radar_section=""`，RADAR_BLOCK_CHARS=1 (`echo ""\|wc -c`) < MIN_SECTION_CHARS=600 → DEGRADED 占位符。今天 12:05 V37.9.73 真激活那次 LLM 正确产了 2 段（WIDE 3714 + RADAR 4058）= drift 随机性铁证。② **drift 触发因子**（按概率排）: 温度 0.8 偏高（用户决策保留为创造性来源）/ 单次调用产 2 段架构脆弱（WIDE 太长后 LLM 自然停止）/ /no_think 副作用 / 30K 素材稀释 prompt / 排除 DEEP 主题指令副作用。③ **3 个修复路径**（用户决策选 A）: A. retry 走默认 primary (Qwen3) — V37.9.74 / B. retry 加 adapter `?provider=X` 路由 + doubao 试水 — V37.9.75 / C. retry 绕 adapter 直调 Volcengine Ark — 不推荐失去 fallback 兜底。④ **方案 2 prompt 强化**（WIDE_RADAR_SYSTEM + WIDE_RADAR_PROMPT）: (a) 加 "必须输出完整 2 段, 不允许写完 WIDE 就结束" 硬约束 (b) 加 "第一段开头**必须**是字面量行 `## 🌐 跨领域鲜人知 × 5`" + "第二段开头**必须**是字面量行 `## 📡 准期信号 × 5`" 双字面量约束 (c) 加 "写完 WIDE 第 5 条后, **必须立即换行接 RADAR header**, 不允许直接收尾" 防 drift 提前收尾 (d) prompt 末尾加 5 项输出自检 checklist (LLM 提交前对照) (e) 硬性要求段告知"V37.9.74 会自动 retry RADAR 一次" 让 LLM 知道 retry 机制存在。⑤ **方案 3 RADAR retry 兜底**（V37.9.73 split 之后, V37.9.73 DEGRADED 之前）: (a) **触发条件**: `[ "$RADAR_STATUS" = "degraded" ] && [ "$WIDE_STATUS" = "ok" ]` — 仅 WIDE ok 时 retry RADAR (防 WIDE 也失败时连环 retry 浪费 LLM quota) (b) **retry-only prompt** 聚焦: 不含 30K 素材 (节省 token), 只含 DEEP 主题排除 + WIDE_BLOCK 已覆盖主题 (防重复) + RADAR 选材标准 + 5 条目结构模板 (c) **走默认 primary** (Qwen3, 同 llm_call 函数 + 温度 0.8 + max_tokens 3000) (d) **双重验证**: `RADAR_RETRY_CHARS >= MIN_SECTION_CHARS` AND `grep -q '## 📡' $RADAR_RETRY_RESULT` — 防 LLM 产 1500 字垃圾但仍漏 header corner case (e) **retry 成功** → RADAR_BLOCK 覆盖 + RADAR_STATUS="ok" (下游零改动) + 日志"retry-recovered" (f) **retry 失败** → fall-through 到 V37.9.73 DEGRADED 兜底, **不 exit** 不阻塞 DEEP 推送. ⑥ **status.json schema +radar_retried +radar_retry_chars 两字段** (运维可观测 LLM drift 频率): 未来 Mac Mini 通过 `cat ~/.kb/cache/last_run.json \| jq .radar_retried` 统计真激活情况, 若 retry 频繁触发 (>30% runs) → 推进 V37.9.75 doubao 试水或方案 4 拆 3 LLM 调用。⑦ **11 新单测 1 类** `TestV37974RadarRetryAndPromptHardening`: V37.9.74 marker / WIDE_RADAR_SYSTEM 必须 2 段约束 / prompt 自检 checklist / 硬性要求提示 retry / retry 触发条件 / retry 双重验证 chars+header / retry 成功设 status=ok 下游兼容 / retry 失败 fall-through (无 exit 1) / retry prompt 排除 DEEP+WIDE / status.json schema 字段 / RADAR_RETRIED 初始化顺序锁 / V37.9.75 doubao 候选登记守卫. **反向 sabotage 验证守卫真有效**: 删整个 retry block (2339 chars) → 7 个 V37.9.74 测试立即 fail, 还原后 98/98 OK。⑧ **修同款 V37.9.73 escaped quotes regex 兼容**: WIDE_RADAR_SYSTEM 内含 `\"## 🌐 ...\"` 字面量让旧 `[^"]*` regex 提前终止, governance INV-DREAM-003 `WIDE_RADAR_SYSTEM 含 V37.8.6 反污染` check 从 file_contains regex 改为 python_assert 找未转义 `"` 边界 (`_extract_var_block` helper)。test_dream_surrogate_sanitize.py 同款修复。⑨ **governance INV-DREAM-MULTITHEME-001 扩展 22→29 checks** (+7 V37.9.74): V37.9.74 marker + WIDE_RADAR_SYSTEM `**必须**输出完整 2 段` 字面量 + RADAR_RETRY_SYSTEM 变量定义 + retry 触发条件 + retry 双重验证 (chars + header) + status.json schema radar_retried 字段 + V37.9.75 候选 B doubao 登记守卫. audit_metadata.total_checks 663 → 670 (+7)。⑩ **多层防御不依赖任一层 100%**: (1) prompt 强化 = 预防层 (LLM 大概率服从但非 100%) (2) retry 兜底 = 恢复层 (LLM drift 时主动重试) (3) DEGRADED 占位符 = 最后兜底 (retry 也失败仍不阻塞 DEEP 推送). 三层任一失败都有下层接住。⑪ **V37.9.75 候选 B 详细登记**（status.json unfinished 已加 + 代码注释引用）: doubao 试水路径需 (1) adapter.py 加 `?provider=X` query 参数支持 + 单测 (~1.5h) (2) kb_dream.sh retry 加 `DREAM_RADAR_PROVIDER=doubao` env var 可配 (~30min) (3) Mac Mini 部署 + adapter 重启 + 3-7 天试水观察. 收益: doubao reasoning_content 特性观察 + 真实 fallback 试水 + V37.9.55 verified_fallback flip 数据 + V37.9.55 收工承诺真兑现. 总工作量 2-3h, 单独 PR 隔离风险。⑫ **累计**: 88 suites 不变 / 3024→3036 tests (+12 V37.9.74 + 1 INV-DREAM-003 修复回归) / 0 fail / governance 663→670 checks (+7) / 77 invariants 不变 (INV-DREAM-MULTITHEME-001 + INV-DREAM-003 内涵扩展) / 19 meta rules / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.74 仍是 V37.9.68 系列 hotfix)。⑬ **Mac Mini 部署后预期行为**: (a) 下次 LLM RADAR drift 发生时 → retry 主动调一次 LLM 只产 RADAR → 用户仍收到 [4/4] 4 个独立完整窗口 (RADAR 段是真内容不是 DEGRADED 占位) (b) `last_run.json` 含 `"radar_retried":true,"radar_retry_chars":NNN` 字段 — 运维通过统计 retry 真激活率监测 LLM drift 频率 (c) 当 LLM 正常输出 2 段时 → 不触发 retry, 零额外 LLM 调用 (V37.9.74 仅在 drift 时激活兜底)。⑭ **MR-10 understand-before-fix 兑现**: 用户问"为什么 chars<600" → 我先分析根因 + 列 3 路径让用户决策 + 暂停代码 edit 等决策 → 决策后才动手实施。同时 MR-4 silent-failure 在第 28 次演出 (V37.9.73) 之后 V37.9.74 多层防御真正闭环 LLM drift 问题 — 不是简单"加重试"而是"prompt 预防 + retry 恢复 + DEGRADED 兜底 + 运维可观测"四层完整防御。⑮ **下次 V37.9.75+ 候选**: (a) **主硬卡**: Mac Mini 部署后等下次 LLM RADAR drift 真激活验证 retry 工作 (通过 last_run.json `radar_retried` 字段确认) (b) V37.9.75 主交付: doubao 试水 (adapter ?provider= + retry env var 切换 + V37.9.55 verified_fallback flip 数据) (c) 反思文档行动 2 INV-PATH-CONSISTENCY-001 (d) SLO p95 33-72s 严重超阈值调查 (e) failure_modes_catalog.md 失败模式库. |
| V37.9.73 | 2026-05-17 | **kb_dream split_dream_into_chunks 生产 caller 形态修复 — V37.9.68-hotfix 测试盲区闭环（MR-4 silent-failure 第 28 次演出 + V37.9.66 类别 B 第 N+1 次演出 + 用户视角原则 #13 第 21 次正向兑现）** — ① **触发**: 2026-05-17 开工用户主动报告"连续两天 dream 任务只生成 3 窗口，且后面两个窗口 char<600" — Mac Mini 5/16 + 5/17 cron 实测 [3/3] 而非 [4/4]，RADAR 段 1 chars < 600 DEGRADED，总览段显示"WIDE 主题 (1)"而非 (5). V37.9.68-hotfix 5/15 部署后即潜伏 bug 2 天才被用户视角发现. ② **完整因果链架构图**: (a) LLM 调用 2 (WIDE+RADAR) 偶尔 LLM 漏 `## 📡 RADAR header` → split_wide_radar_output 返回 (wide=完整输出, radar="") → RADAR_BLOCK_CHARS=1 (echo "" 加换行) < 600 → DEGRADED 占位符. WIDE 段产 1 主题 ~700 chars 通过 600 阈值. (b) kb_dream.sh:1479 拼接 DREAM_RESULT = `"## DEEP\n\n## WIDE\n\n## RADAR\n\n## OVERVIEW"` — **开头直接 `## `，没有 `# Agent Dream` header！** (c) kb_dream.sh:1557 `<<< $DREAM_RESULT` 推 split_dream_into_chunks. (d) split_dream_into_chunks: `sections = text.split("\n## ")` → `sections[0] = "## 🌙 今日深度: ..."` (DEEP 段本身), 但 V37.9.68-hotfix 代码 `header_part = sections[0].rstrip()` **误把 DEEP 当 "header"** → `ordered_sections[0] = header_part + "\n\n" + ordered_sections[0]` **合并 DEEP+WIDE!** → 最终 chunks = [DEEP+WIDE, RADAR_DEGRADED, OVERVIEW] = 3 chunks. ③ **三层根因**: (触发器) LLM 输出 drift 漏 `## 📡` emoji header → RADAR 段空 / (放大器) split_dream_into_chunks `header_part = sections[0]` 假设 text 开头有 `# Agent Dream` header，但生产 caller `<<< $DREAM_RESULT` 真实形态直接以 `## ` 开头 → DEEP 被误当 header_part 与 WIDE 合并 / (掩护者) V37.9.68-hotfix 12 单测全部用 `text = "# 🌙 Agent Dream — DATE\n\n> 模式:...\n\n## DEEP"` 形态作 input, **完全没覆盖生产 caller `<<< $DREAM_RESULT` 真实形态** → dev/治理/preflight 全绿但生产连续 2 天 [3/3]. ④ **MR-4 silent-failure 第 28 次演出新形态**: 前 27 次 silent 都是"错误被吞 / 错误被稀释 / 错误推送编造 / 涌现行为 / 设计假设错配". 第 28 次是**"修复了一个类别 B 错配（旧合并算法）却引入另一个类别 B 错配（header_part 假设 vs 真实 caller 形态）"** + **"测试 input 设计与生产 caller input 形态不一致"** — V37.9.68-hotfix 的反讽性循环演出. ⑤ **最小修复 (MR-10 三问严格执行)**: Q1 之前存在 ✓ (V37.9.68-hotfix 引入即潜伏) / Q2 我引入 ✓ (V37.9.68-hotfix `header_part = sections[0]` 假设错配) / Q3 最小修复 = `split_dream_into_chunks` 主动判断 `first_is_h2 = sections[0].lstrip().startswith("## ")`, 分两路径处理: (a) `first_is_h2=True` (生产场景: text 以 `## ` 开头) → `sections[0]` 保留 `## ` 前缀作第一段，无 header_part 合并 (b) `first_is_h2=False` (测试/dream-file 场景: text 以 `# Agent Dream` header 开头) → 保留 V37.9.68-hotfix 原逻辑. ⑥ **6 新单测 1 类** `TestSplitDreamProductionCallerFormat`: test_v37_9_73_blood_lesson_no_header_4_chunks (镜像 kb_dream.sh:1479 拼接形态 4 chunks 守卫) + test_v37_9_73_starts_with_double_hash_no_metadata + test_v37_9_73_backward_compat_with_header_preserved (V37.9.68-hotfix 测试场景仍工作) + test_v37_9_73_production_layout_5_16_5_17_real_sizes (5/17 真实段大小 DEEP ~2400 / WIDE ~700 / RADAR ~78 / 总览 ~70) + test_v37_9_73_first_is_h2_detection (lstrip 容错前导空白) + test_v37_9_73_sabotage_revert_to_pre_fix_fails_loud (源码守卫 first_is_h2 + V37.9.73 marker 字面量). **反向验证守卫真有效**: sed `first_is_h2 = sections[0].lstrip().startswith("## ")` → `first_is_h2 = False` → **4 个 V37.9.73 测试立即 fail** (含血案 4 chunks + 5/17 真实 layout + ## 开头无 metadata + first_is_h2_detection), 还原后 86/86 OK. ⑦ **governance INV-DREAM-MULTITHEME-001 扩展 19→22 checks** (+3 V37.9.73): file_contains first_is_h2 字面量 + file_contains V37.9.73 marker + 1 runtime python_assert 端到端构造生产 caller 形态 (4 个 ## 段, 无 header) 必须产 4 chunks. audit_metadata.total_checks 660 → 663 (+3). ⑧ **MR-6 critical-invariants-need-depth 兑现**: INV-DREAM-MULTITHEME-001 升级到 22 checks 三档守卫 (declaration + runtime python_assert 含 5/15 + 5/17 双血案场景), 任何回退到 V37.9.68-hotfix 错配会立即被 governance audit 抓到. ⑨ **MR-15 测试三层第三层不可替代第 N 次硬实证**: 单测 80/80 + 治理 660/660 + Mac Mini 5/15 [4/4] 验证 (巧合 — DEEP 段长度恰好让 split 产 4) — 三层都过，**仍连续 2 天用户视角发现 [3/3]**. V37.9.73 加入"覆盖生产 caller 真实 input 形态"测试后, 未来同款盲区会在 dev 单测层被立即抓到. ⑩ **累计**: 88 suites 不变 / 3018 → 3024 tests (+6 V37.9.73 新单测) / 0 fail / governance 660→663 checks (+3) / 77 invariants 不变 (内涵扩展非新增) / 19 meta rules / 安全 95/100 / VERSION 0.37.9.68 不变 (V37.9.73 是 V37.9.68 系列 hotfix 不 bump). ⑪ **Mac Mini 部署后预期行为**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.73 (b) 下次 cron 触发 (5/18 03:00) WhatsApp 应**首次**收到 4 个独立窗口: [1/4] DEEP / [2/4] WIDE / [3/4] RADAR (即使 LLM 漏 `## 📡` header 仍独立成 chunk 显示 DEGRADED 占位) / [4/4] 总览. **关键**: V37.9.73 不修 RADAR DEGRADED 本身 (那是 LLM 输出 drift 另一问题), 只修 chunk 切分让 4 段独立 — 用户至少能看到 DEEP/WIDE 各自完整内容不被合并. ⑫ **元价值**: V37.9.68-hotfix → V37.9.73 是同款 V37.9.66 类别 B 错配的**连续两次演出**, 证明"测试 input 设计必须镜像生产 caller 真实形态" 是不可替代的工程纪律. V37.9.73 不只是修 bug, 还是把"测试三层第三层"在 dev 单测层兑现 — 未来 split_dream_into_chunks 任何 caller 形态变化都被守卫覆盖. 同时验证用户视角原则 #13 第 21 次正向兑现 — 单测全绿 + 治理全绿 + 用户主动开工报告才能发现连续 2 天潜伏问题. **闭环时间 < 1.5 小时 从用户报告到 commit + push** (vs V37.9.4 → V37.9.29 同款 60 天潜伏对比硬实证, framework "用户视角是一等可观测信号"持续兑现). ⑬ **下次 V37.9.74+ 候选**: (a) Mac Mini 5/18 03:00 cron 真激活验证 [4/4] (V37.9.68-hotfix → V37.9.73 同款承诺路径) (b) RADAR LLM drift 修复 (WIDE_RADAR_PROMPT 强化让 LLM 必产 `## 📡` header, 或失败时主动 retry 一次只 RADAR) (c) 反思文档行动 2 INV-PATH-CONSISTENCY-001 (d) SLO p95 71958ms 调查 (e) 反思文档行动 3 failure_modes_catalog.md (含 V37.9.73 第 28 次 MR-4 演出案例). |
| V37.9.72 | 2026-05-15 | **(i) CORE 项调查闭环 — 治理审计契约对齐 + auto_deploy 阈值修 V37.9.59 设计错配** — 触发: 2026-05-15 08:30 watchdog [SYSTEM_ALERT] 2 个 CORE 项告警 (🔴 治理审计: 异常状态 (pass) / 🔴 自动部署 log 29m 未更新 阈值 10m). 按原则 #28 三问严格执行: 先调查再动手不盲改. **项 1 真根因 = 跨脚本契约不一致 (governance_audit ↔ watchdog)**: `governance_audit_cron.sh:87 OVERALL="pass"` 写入 last_run.json `status:"pass"`, `watchdog line 280` 期望 `"ok\|unknown"` 作正常状态 → default 分支 line 297 误报 "异常状态 (pass)". 7+ 其他 ALIGNED jobs (V37.5/V37.8.10/V37.9.16/V37.9.39/40/41/43/44/45/50/51/62) 都用 "ok". `governance_checker.py` 内部 "pass" 是 check 状态真理源 (8+ 处), 与 last_run.json 外部契约**解耦不动**. **修复 1**: `OVERALL="pass" → "ok"` 单字符串改动. fail 不动 (维持 watchdog default 分支告警目的, gov_violations / engine_failed 真失败时仍正确告警). **项 2 真根因 = V37.9.59 阈值与 V37.9.8 心跳设计错配**: auto_deploy V37.9.8 写心跳策略 = 仅整点 (minute<2) 写 1 行 = 24 行/天 (低噪声 + 60min 静默上限), watchdog V37.9.59 LOG_FRESHNESS_JOBS 阈值 600s = 10min → 非整点 watchdog 跑时 log mtime 必然 10-60min 超阈值. 今早 8:30 watchdog 跑 + auto_deploy 8:00 心跳 = 29min 超阈值, 完美匹配告警时间. **修复 2**: `job_watchdog.sh:192` 阈值 `600 → 4200` (60min 心跳间隔 + 10min slack), 与 V37.9.8 原意对齐. 其他 LOG_FRESHNESS_JOBS 阈值不动 (wa_keepalive 5400 等 V37.9.59 原值正确). **新文件 `test_v37_9_72.py` (12 单测 / 3 类 + 反向验证守卫真有效)**: TestV37972ProjItemOneGovAuditContract(5) + TestV37972ProjItemTwoAutoDeployThreshold(5) + TestV37972IntegrationContracts(2). 反向验证: 项 1 sed `OVERALL=ok → pass` → 2 failures, 还原 12/12 OK; 项 2 sed `4200 → 600` → 2 failures, 还原 12/12 OK. **接入 full_regression**: +1 suite `v37_9_72`. 累计 87→88 suites (+1) / 3006→3018 tests (+12) / 0 fail / 安全 95/100. **元价值**: CORE 项调查证明 watchdog 系统告警**有真问题但都是 framework 内部契约错配**, 不是生产 bug, 不影响业务. 跨脚本契约不一致是 framework 演进过程中典型问题 (V37.9.59 引入 LOG_FRESHNESS_JOBS 时未对齐 V37.9.8 心跳设计 + governance_audit 写 last_run.json 时未对齐其他 ALIGNED jobs 契约). 原则 #28 一次完整诊疗循环兑现 (调查→三问→最小修复→守卫→反向验证). VERSION 0.37.9.68 不变 (V37.9.72 仅契约对齐, 不涉及业务语义). |
| V37.9.71 | 2026-05-15 | **(g) README 其他 badge 数字漂移修复 — long-term doc rot 清零** — 触发: V37.9.70 (e) 推送后用户继续推进 (g) 候选. 按原则 #28 严格 scope 控制. **15 处 doc rot 修复** (累积 V37.9.x 多版本): badge 漂移 2 处 (line 8 tests-2515→3006 / line 10 invariants-71/71+16 MR→77/77+19 MR) + governance 元数据 7 处 (line 127 yaml v3.31→v3.42 / line 128 60不变式+273检查+15元规则+13 MRD→77+662+19+14 / line 129 MR-4 演出 15→27 / line 365 governance_audit_cron V37.1→V37.9.13→V37.9.68 / line 407 governance_checker V36.3→V37.9.22→V37.9.68 / line 408 governance_ontology V37.9.44 v3.34→V37.9.68 v3.42 / line 438 Ontology Plane v3.31 60+15+13→v3.42 77+19+14) + ALIGNED_SCRIPTS 2 处 (line 26 cross-job V37.9.44 10→V37.9.62 17 6 字段含 🎚️ / line 409 llm_cron_audit V37.9.62 17 aligned + 4 by-design 排除) + 案例统计 2 处 (line 413 15→21 + V37.9.68 Qwen-BIM 涌现行为防御 / line 632 17→21) + full_regression 数字 1 处 (line 569 V37.9.44 64/2253→V37.9.69 87/3006) + Capability Plane 1 处 (V37.9.70 修过的 8-provider 不动). **line 634 历史快照保留**: "15 blood lessons (V37.9.1)" 是 V37.9.1 时刻历史快照非 doc rot. **验证**: 2 轮 grep 完全 0 残留 + 全量回归 87/3006/0 fail. 外部评审 P0 (V37.9.70 e 8 providers) + long-term doc rot (V37.9.71 g) 双闭环. README 现在准确反映项目实际状态 (87 suites / 3006 tests / 77 inv / 19 MR / 14 MRD / 662 checks / 21 case studies / 27 MR-4 演出 / 17 ALIGNED_SCRIPTS / 8 providers / v3.42). VERSION 0.37.9.68 不变 (仅文档刷新). |
| V37.9.70 | 2026-05-15 | **(e) README 8 providers 漂移修 — V37.9.52 doubao 加入但 README 未刷新外部评审 P0 兑现** — 触发: status.json focus 段登记 V37.9.69+ 候选 (e) 外部评审吸收 P0 (2026-04-17 评审反馈). 严格按原则 #28 三问: Q1 ✓ V37.9.52 加 doubao 时未同步 README / Q2 ✗ V37.9.70 不引入 / Q3 最小修复 = grep + 精确 edit 不全局 sed. **dev scan 抓 10 处 (status.json 估 6 处低估)**: line 3 页头摘要 + line 9 badge + line 48 architecture diagram + line 158 + line 163 含 provider 列表 + line 244 + line 272 + line 273 + line 420 + line 436 + line 590. **修复**: 9 处 `7 provider* → 8 provider*` 字面量精确替换 + line 163 provider 列表加 `**Doubao Seed 2.0 Pro** (Volcengine, V37.9.52)` 8 个 provider 完整列出 + line 273 加 `(7 built-in + Doubao plugin)` 注释清晰区分内置 + 插件. **验证**: grep 后 0 处 7 provider* 残留 + 10 处 8 provider* 全显示. **governance 安全**: governance_ontology.yaml 不引用 README provider 数字, 无守卫破坏风险. **全量回归**: 87/3006/0 fail 无副作用. **scope 严格控制**: 不顺带改其他 README badge 漂移 (留 V37.9.71 (g)). 外部代码级评审 P0 任务 (2026-04-17 反馈) 在 V37.9.70 内闭环. VERSION 0.37.9.68 不变 (V37.9.70 仅文档修, 不涉及代码). |
| V37.9.69 | 2026-05-15 | **B+C 双修闭环 — V37.9.69+ 候选 (b)(c) 兑现, 历史遗留测试漂移 + bash 计数 bug 短工作量低风险双修** — ① **触发**: V37.9.68-hotfix Mac Mini 5/15 03:00 真激活完美兑现 [4/4] 后, 用户开工选 B+C 短工作量推进路径 (vs D/E/F 框架型). 严格按原则 #28 三问执行: Q1 之前存在 ✓ (B 项 V37.9.63 抽 helper 时遗留 / C 项历史 bug) / Q2 我引入 ✗ (非 V37.9.68 引入) / Q3 最小修复 = alternation 守卫 + tail -n1 取末行. ② **B 项 (test_watchdog_self_monitoring.py 5 个测试漂移修)**: V37.9.63 抽 cron_monitor_fatal_handler.sh helper 后, watchdog.sh 改用 `trap '_cron_monitor_fatal_handler $LINENO' ERR` + `CRON_FATAL_LABEL="watchdog"` 配置, 替代 V37.9.58-hotfix3 inline `_watchdog_fatal_handler()` 函数. 5 个测试守卫漂移 fail: test_fatal_handler_function_defined / test_err_trap_registered / test_fatal_handler_pushes_system_alert / test_trap_err_after_set_e / test_audit_metadata_v3_38. **修复**: (a) 加 `_watchdog_uses_v37_9_63_helper(src)` 判定函数 (检查 source helper + CRON_FATAL_LABEL="watchdog" + _cron_monitor_fatal_handler 三契约) (b) 加 `_read_helper_src()` 读 helper 文件内容 (c) 5 测试加 alternation 分支接受 V37.9.63 helper OR V37.9.58-hotfix3 inline 任一形式 (d) test_audit_metadata_v3_38 改用 semver-style ≥3.38 baseline (yaml 持续演进至 3.42+ 允许版本上升不锁死 v3.38) (e) test_sabotage_remove_err_trap_caught 也升级用 alternation 选 sabotage target. ③ **C 项 (full_regression.sh line 30 bash 计数 bug)**: 旧 `count=$(echo "$output" \| grep -oE 'Ran [0-9]+ test' \| grep -oE '[0-9]+' \|\| echo "0")` 多匹配场景下 count 多行 → `$((TOTAL_TESTS + count))` syntax error → TOTAL_TESTS 计数失真 (bash 算术不接受多行). **修复**: `tail -n1` 取末行 (unittest summary 永远在 stdout 末尾) + `head -n1` 防护 + `${count:-0}` 算术兜底防空串. dev 实测 input 含 3 行 Ran X test → 旧模式抛 `syntax error in expression` 新模式正确取末行 count=5 + TOTAL_TESTS=5. ④ **新文件 test_v37_9_69.py** (13 单测 / 3 类 + 反向验证两层守卫真有效): TestWatchdogTestAlternationGuards(6 含 _watchdog_uses_v37_9_63_helper 函数定义 / _read_helper_src 引用 / V37.9.69 marker / 3 测试用 alternation / audit_metadata semver baseline / **行为层 31/31 OK 集成验证 subprocess 真跑**) + TestFullRegressionCountFix(6 含 V37.9.69 fix C marker / tail -n1 字面量 / ${count:-0} 兜底 / 反 buggy 模式守卫 (count= 行必须含 tail) / **行为层 subprocess 真跑 multi-line input 必须不抛 syntax error + count=5 + TOTAL_TESTS=5 三契约** / **反向验证 legacy buggy 模式 subprocess 真跑断言 stderr 含 'syntax error' 证明 fix 必要性**) + TestV37969Integration(1 bash -n full_regression.sh). ⑤ **反向验证守卫真有效**: B 项 sed `_cron_monitor_fatal_handler` → `_SABOTAGED_HANDLER` → 4 failures + 1 skip (test_fatal_handler_function_defined / test_err_trap_registered / test_fatal_handler_pushes_system_alert / test_trap_err_after_set_e 全 fail), 还原后 31/31 OK 0 skip / C 项 test_legacy_buggy_pattern_demonstrably_fails subprocess 真跑 legacy buggy bash 模式确认 stderr 含 'syntax error in expression'. ⑥ **接入**: full_regression.sh +1 suite `v37_9_69`. **累计**: 86→87 suites (+1) / 2962→3006 tests (+44, V37.9.69 13 + watchdog test 5 fail → pass + 其他 alternation 升级回归) / 0 fail / 安全 95/100 / governance 662 checks pass / VERSION 0.37.9.68 不变 (V37.9.69 仅测试守卫层修, 不涉及生产代码语义). ⑦ **MR-8 single-source-of-truth 兑现**: helper 模式让 fatal_handler 行为只在 cron_monitor_fatal_handler.sh 一处定义, 7 个 governed scripts (job_watchdog/governance_audit/daily_ops/auto_deploy/kb_deep_dive/kb_evening/kb_review) 共享同款契约自动 propagate. V37.9.63 抽 helper 价值再次实证 (V37.9.69 让测试也对齐 helper 模式). ⑧ **元价值**: V37.9.69 是治理债主动清零 - 测试漂移和 bash bug 都是技术债, 不修不会立即出 bug 但会让未来类似场景 (新增 subprocess unittest / count 多匹配) 时无声失败. 同日 V37.9.68-hotfix Mac Mini 真激活 + V37.9.69 历史遗留清零 = 短 session 完整闭环展示 framework 演进的"边修血案边清债"健康节奏. **下次 V37.9.70+ 候选**: (a) Mac Mini 同步 + 下次 cron 整点 (16:00 03:00) 验证不引入回归 (b) **反思文档行动 2**: INV-PATH-CONSISTENCY-001 路径一致性 audit (~/jobs/X/ vs ~/.openclaw/jobs/X/ 防 V37.9.56-hotfix 同款路径假设错配) (c) **外部评审 P0**: README 6 处 "7 providers" → 8 providers 漂移 (V37.9.52 doubao 加入但 README 未刷新) (d) **反思文档行动 3**: failure_modes_catalog.md 失败模式库 (27 次 MR-4 silent-failure 演出 + 案例库类别 A/B 整理) (e) **CORE 项调查**: 治理审计"异常状态 (pass)" 真实异常类型 + 自动部署 log 29m 真实原因 (V37.9.59 LOG_FRESHNESS 阈值过严还是 auto_deploy 进程 stale). |
| V37.9.68-hotfix | 2026-05-15 | **Mac Mini 5/15 03:00 cron 真激活验证发现 4 段被合并成 3 chunks 血案修复（V37.9.66 类别 B 设计假设错配 + 用户视角原则 #13 第 20 次正向兑现）** — ① **触发**: V37.9.68 部署 Mac Mini 后用户开工立即报告 5/15 03:00 cron 真激活, **WhatsApp 收到 [3/3] 而非 [4/4]** — 总览段是第 3/3 而不是第 4/4. 主题质量 OK (新颖, 14 天 ban-list 阻止 Qwen-BIM 类重复). 单测/治理/preflight 全过. ② **根因 (代码层 + 数据层确认)**: V37.9.68 changelog 说"4 段 ## header 自然复用 V37.9.21 多窗口分片，推送 4 个独立 WhatsApp 窗口", 但 V37.9.21 实际是 `if len(current) + len(piece) + 1 <= max_chunk: 合并` 算法 (kb_dream.sh:1545). V37.9.68 4 段大小不均匀 (DEEP ~5000 / WIDE ~1700 / RADAR ~900 / 总览 ~400) 让 WIDE+RADAR (~2600) 被合并成 1 chunk. **V37.9.66 案例库 类别 B "设计假设错配"** 第 N 次演出 — 设计文档说 4 段独立但代码无强制保证. ③ **MR-4 silent-failure 第 27 次新形态**: 前 26 次都是错误被吞 / 错误被稀释 / 错误推送编造 / 涌现行为. 第 27 次是**设计假设与算法实现不一致 + 单测全过 + 治理全过 + 用户视角才暴露**. 比 V37.9.66 类别 B 一般"设计假设错配"更深: 不是组件接口假设错配, 而是"语义文档 vs 代码契约"假设错配. ④ **MR-10 三问全过**: (Q1) 之前存在 ✓ V37.9.21 合并算法一直在但段大小均匀没暴露 / (Q2) 我引入 ✓ V37.9.68 设计假设"4 段自然产 4 chunks" 未保证 / (Q3) 最小修复 = 抽 split helper + 改算法"每段独立". ⑤ **结构修复 (MR-8 single-source-of-truth)**: (a) `kb_dream_helpers.py` 加 `split_dream_into_chunks(text, max_chunk=4000) -> list[str]` 纯函数 — 每个 ## header 段独立成 chunk + header 段 (首个 ## 之前) 合并到第一个 ## 段作 prefix + 单段超 max_chunk 时按 \\n 内部切分 + 空段静默跳过 + max_chunk < 100 防御 fallback 4000. 函数 docstring 详记 V37.9.66 类别 B 血案历史. (b) `kb_dream.sh` 替换 line 1531-1565 内嵌 35 行 Python 为 7 行调用 helper (含 sys.path.insert + try/except ImportError + FATAL 早退). 加 V37.9.68-hotfix marker 注释. ⑥ **12 新单测** test_kb_dream_helpers.py 80 → 92 (V37.9.68 68 + V37.9.68-hotfix 12): TestSplitDreamIntoChunks(8 — empty/非string/血案场景回归 4 段每段 < max_chunk 必产 4 chunks/header 合并到第一段/超大段内部切+其他段独立/无 ## 段单 chunk/max_chunk 防御/空段跳过 + 5/15 真实 layout 模拟产 4 chunks) + TestKbDreamShellGuards(+4: helper import 守卫 / 真调用守卫 / **反向消除旧合并算法** `if len(current) + len(piece) + 1 <= max_chunk:` python_assert / V37.9.68-hotfix marker grep). **反向验证两层守卫真有效**: (a) sabotage helper while 循环 (`while False:`) → test_oversized_section_internal_split 立即 1 fail (b) sabotage 回退到旧合并算法 → 5 个测试立即 fail (含 test_v37_9_68_blood_lesson_four_section_independent_chunks + test_real_2026_05_15_layout_produces_4_chunks 等血案场景回归), 还原后 80/80 全过. ⑦ **INV-DREAM-MULTITHEME-001 内涵扩展含 5 新 V37.9.68-hotfix check**: helper 函数定义 + helper import 守卫 + 真调用守卫 + V37.9.68-hotfix marker + **反向反合并算法 python_assert** (kb_dream.sh 必须不含 `if len(current) + len(piece) + 1 <= max_chunk:` 字面量). ⑧ **接近真实数据模拟验证** (DEEP 含 ### 三子段: 发现过程 + 隐藏关联 + 行动建议) → V37.9.68-hotfix 后产 [1/4] DEEP+header 2132 chars / [2/4] WIDE 1417 / [3/4] RADAR 615 / [4/4] 总览 141 = **4 chunks 完美匹配设计预期**. ⑨ **累计**: 86 suites 不变 / 2950→2962 tests (+12) / 0 fail / governance v3.43→v3.44 / 77 inv 不变 (内涵扩展非新增) / 655→660 checks (+5) / 19 meta rules / 安全 95/100 / VERSION 0.37.9.68 不变 (hotfix 不 bump). ⑩ **Mac Mini 部署后预期** (用户视角验证): 5/16 03:00 cron 自动触发应**首次**产 4 个独立 WhatsApp 窗口: [1/4] = DEEP (含 # 🌙 Agent Dream header + 模式 + 覆盖 + 生成时间 元数据 + ## 🌙 今日深度 段) / [2/4] = WIDE (## 🌐 跨领域 × 5) / [3/4] = RADAR (## 📡 准期信号 × 5) / [4/4] = 总览 (## 📋 今日连动 + 明日关注). DEEP 段超 4000 时仍按 \\n 内部切分但不影响其他 3 段独立性. 用户视角原则 #13 第 20 次硬实证. ⑪ **元价值**: V37.9.21 多窗口分片机制经 4 个版本 (V37.9.21 单大段切 → V37.9.35 客户端折叠 → V37.9.68 多段假设独立 → V37.9.68-hotfix 多段强制独立) 演进, 验证**原则 #15 测试三层第三层不可替代** — 单测全绿+治理全绿+用户实际收到 [3/3] 才暴露 V37.9.68 设计假设错配. **同时验证用户视角原则 #13 第 20 次正向兑现** — 没有用户开工立即报告"3 个窗口", 这个 V37.9.68 的设计-代码不一致可能潜伏数周才被发现 (V37.9.4 → V37.9.29 同款 60 天潜伏血案教训). ⑫ **下次 V37.9.69+ 候选**: (a) **主硬卡**: Mac Mini 5/16 03:00 cron 真激活验证 [4/4] 推送, 如真激活 → 立 INV-DREAM-CHUNK-INDEPENDENT-001 守卫 (b) test_watchdog_self_monitoring.py 5 个测试漂移修 (V37.9.63 抽 helper 后留下, 非 V37.9.68 引入, 历史问题) (c) full_regression.sh line 30 bash 计数 bug (count 含多行数字时 `$((TOTAL + count))` 报错但 PASS+1 仍执行让 fail 被吞) (d) 反思文档行动 2: INV-PATH-CONSISTENCY-001 路径一致性 audit (e) 外部评审吸收 P0: README 6 处 7 providers → 8 providers 漂移 (f) 反思文档行动 3: failure_modes_catalog.md 失败模式库. |
| V37.9.68 | 2026-05-14 | **Agent Dream 三阶推送重设计 — Qwen-BIM 连续几周血案闭环 + 6 因子涌现行为防御（MR-4 第 26 次演出新形态）** — ① **触发**：用户开工 WhatsApp 实测发现"连续几周 Dream 都是 Qwen-BIM"，明确指令"重新设计 Dream 任务，可以帮助我极大开拓视野，坚决不能将就或凑合"。提供两个关键洞察：(a) 数据重复源于系统性聚类——信号簇 3-9（20260228-20260309）反复出现"Qwen-BIM 14B 参数性能媲美 671B"，被用户连续标⭐⭐⭐⭐⭐ (b) V37.9.35 后 WhatsApp 4000 字 budget + V37.9.21 多窗口分片已就位，单窗口限制解锁，其他任务可生成 5+ 窗口。② **根因 6 因子叠加（涌现非单点）**：(1) 用户主动 ⭐⭐⭐⭐⭐ 反复保存同主题笔记 (2) Phase 1b prompt 偏好"重复出现 = 持续关注"放大同一信号 (3) content-stable cache (V37.3 fix C) 锁定 signals 永远不变 (4) mtime 倒序处理 + user notes 静态 → 反复参与 (5) NOTES_SIGNALS 按 signal-hash dedup 但**不按主题层**去重 (6) PREV_THEMES 只看 **3 天** + prompt 留后门"同主题新角度可深挖"。每因子单看合理，组合后产生意外行为。**MR-4 silent-failure 第 26 次演出**：前 25 次都是错误被吞或编造，第 26 次是"推送内容字面合规 + 单测/治理/preflight 全绿，但用户视角看到连续重复 = 信息无价值"。③ **用户 4 决策（AskUserQuestion）**：Q1 LLM 调用 = **2 次** (DEEP 独立 + WIDE+RADAR 合一) — 平衡成本+质量 / Q2 主题防衰减 = **14 天** / Q3 数量 = **WIDE 5 + RADAR 5** — RADAR 多视野 / Q4 失败降级 = **DEEP 必过 + WIDE+RADAR 独立降级**。④ **新文件 `kb_dream_helpers.py`** (~395 行纯函数模块，零 I/O at import, 8 公开函数)：`normalize_theme_keywords` (中文 2-gram+3-gram 滑动窗口 + 英文 token + 停用词) / `themes_overlap` (三层判定: anchor 单独命中 / ≥2 共同 / ≥50% 短主题, anchor 阈值实测调优避 false positive: 英文复合标识符含 hyphen/digit ≥4 字 / 英文纯字母 ≥8 字 / 中文 ≥3 字, "qwen-bim"/"ontology" ✓ "plane"/"control" ✗) / `extract_recent_themes(dream_dir, days=14)` / `format_banned_themes_block` / `extract_deep_theme_from_chunk` / `split_wide_radar_output` (单 LLM 调用 WIDE+RADAR 拆 2 段) / `build_overview_block` (规则提取不调 LLM) / `extract_section_titles`. CLI `--show-recent-themes` 运维查询。⑤ **kb_dream.sh 改造**：(a) PREV_THEMES 3 → 14 天 + 调 helper 提取归一化 ban-list (b) Phase 2 替换 V37.8.3 chunked 3 段 (161 行) → V37.9.68 三阶推送 (260 行): DEEP_PROMPT 含 `${BANNED_THEMES_BLOCK}` 硬规则 + MIN_DEEP_CHARS=1200 fail-fast 顺序锁 / WIDE_RADAR_PROMPT 单 LLM 调用产 2 段 (排除 DEEP_THEME) / 总览段调 helper 规则提取 / 4 段 ## header 自然复用 V37.9.21 多窗口分片机制 (c) status.json schema 升级含 multitheme:true / deep_chars / wide_status / wide_chars / radar_status / radar_chars 段独立可观测 (d) V37.8.6 反污染守卫保留在 DEEP_SYSTEM 和 WIDE_RADAR_SYSTEM 双 prompt 中。⑥ **`auto_deploy.sh` FILE_MAP** 加 kb_dream_helpers.py 部署到 `$HOME/kb_dream_helpers.py`。⑦ **INV-DREAM-MULTITHEME-001** 新增 (meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime], **19 checks**): 17 declaration (kb_dream_helpers 6 个函数定义 + kb_dream.sh days=14 字面量 + BANNED_THEMES_BLOCK / DEEP_RESULT / WIDE_RADAR_RESULT / MIN_DEEP_CHARS=1200 / V37.9.68 marker + 反 CHUNK1_RESULT / CHUNK3_RESULT 守卫 + status.json multitheme:true + deep_chars + auto_deploy FILE_MAP) + 2 runtime python_assert (DEEP fail-fast 顺序锁源码级位置守卫 + 端到端真跑 68 helper 单测全过). **INV-DREAM-003 升级**（V37.9.68 架构迁移）：CHUNK1/2/3_SYSTEM 守卫 → DEEP_SYSTEM / WIDE_RADAR_SYSTEM 守卫，V37.8.6 反污染语义保留。⑧ **68 单测 / 10 类** test_kb_dream_helpers.py 含血案场景回归 (TestBloodLessonQwenBimRegression 端到端复现 14 天 ban-list 阻止 Qwen-BIM 变体 + Memory Plane 新主题不被错误拦截) + shell 层 source-level 守卫 12 个 + Mac Mini layout 真实场景 + 反向验证守卫. **反向验证已确认守卫真有效**: sed `days=14 → days=3` 立即 5+ 单测 fail (含 14 天默认默 守卫 + 血案场景回归), 还原后 68/68 全过. ⑨ **累计**: 85 suites (+1: kb_dream_helpers) / 2944 tests (+68) / 0 fail / governance v3.42→v3.43 / 76→77 invariants (+1 INV-DREAM-MULTITHEME-001) / 636→655 checks (+19) / 19 meta rules 不变 / 安全 95/100 / VERSION 0.37.9.67 → 0.37.9.68. ⑩ **Mac Mini 部署后预期**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.68 (b) `bash ~/kb_dream.sh` 手动触发立即验证 — 应**首次**产出 4 段独立 WhatsApp 窗口 (🌙 DEEP / 🌐 WIDE 5 主题 × 200 字 / 📡 RADAR 5 信号 × 300 字 / 📋 总览), 14 天 ban-list 应阻止 Qwen-BIM 类历史主题重复 (c) 下次 5/15 03:00 cron 自动用新设计. ⑪ **元价值**: V37.9.68 是 V37.9.x 系列**第一次涌现行为防御**——前 25+ 次 MR-4 演出都是单点 bug，V37.9.68 是多因子叠加涌现行为，必须用 framework 级守卫(14 天历史 + 主题归一化 + 三阶推送 + DEEP fail-fast)防御。用户视角原则 #13 第 19 次正向兑现 — 单测/治理/preflight 全绿但只有用户在 WhatsApp 看到连续重复才能感知。⑫ **下次 V37.9.69+ 候选**: (a) Mac Mini 部署后 5/15 03:00 cron 真激活验证 14 天 ban-list 生产效果 + 用户视角观察 (b) DEEP 主题归一化效果调优（如出现新的 anchor 误判 / 漏判可调阈值）(c) WIDE/RADAR 5 主题数量观察是否合适 (d) 反思文档行动 2: INV-PATH-CONSISTENCY-001 路径一致性 audit (e) 反思文档行动 3: failure_modes_catalog.md 失败模式库. |
| V37.9.67 | 2026-05-13 | **P0 行动 1 兑现 — INV-CROSS-OS-001 跨 OS quirk scanner (反思文档行动 1) + 16 violations 修齐** — ① **触发**: 同日 V37.9.66-hotfix watchdog:721 bash quirk false-positive FATAL 实证暴露反思文档"类别 A OS quirk 第 N+1 次演出". 用户用剩余 token 立即推进 P0 行动 1. ② **新文件 `cross_os_quirk_scanner.py`** (~230 行, FAIL-CLOSE): 4 个已实证 quirk pattern 主动检测 — (a) `cmd && X || Y` + set -eE + ERR trap false-positive FATAL (V37.9.66-hotfix) (b) `grep | head` + pipefail + set -eE 无 `\|\| true` 兜底 (V37.9.60-hotfix) (c) awk 处理 log 缺 `LC_ALL=C` (V37.9.58-hotfix3 macOS bsd multibyte) (d) zsh-specific 语法 (typeset -A / setopt) in .sh (V37.9.56-hotfix2). 豁免: 注释行 / test_*.py / docs/ / scanner 自身 / `\|\| true` 或 `\|\| echo` 或 `\|\| :` 兜底. ③ **dev scan 立即抓出 16 violations 跨 6 文件**: preflight_check (4 cmd_and_or + 5 grep_head) / gameday (2 cmd_and_or) / smoke_test (1) / check_upgrade (2 grep_head) / job_smoke_test (1 grep_head) / kb_dream (1 grep_head 已有 \|\| echo "" 兜底误报 → 升级 scanner 接受 \|\| echo). ④ **批量修齐 16 处**: cmd_and_or → if-then-else 形式 (bash 文档豁免 set -e + ERR trap) / grep_head → 末尾 `\|\| true` 兜底. scanner 重扫 0 violations. ⑤ **test_cross_os_quirk_scanner.py 21 单测 6 类**: TestQuirkCmdAndOrChain(4) + TestQuirkGrepHeadNoOrTrue(4) + TestQuirkAwkLogNoLCAll(3) + TestQuirkZshSpecific(3) + TestRepoIntegration(3 含 0 violations 端到端 + CLI + 反向验证 sabotage 真有效) + TestSourceLevelGuards(4 V37.9.67 marker + FAIL-CLOSE + 4 quirk checker + 4 血案版本引用). ⑥ **INV-CROSS-OS-001** 新增 (meta_rule=MR-7 治理自观察, severity=high, verification_layer=[declaration, runtime], 7 checks): 5 declaration (scanner 文件 / FAIL-CLOSE / INV 引用 / 4 quirk 函数 / 4 血案版本 python_assert) + 2 runtime python_assert (scanner --scan 0 violations + 21 单测全过). ⑦ **接入 full_regression.sh** suite `cross_os_quirk_scanner`. ⑧ **累计**: 83→84 suites (+1) / 2855→2876 tests (+21) / 0 fail / governance v3.42→v3.42 (无 yaml meta version bump) / **75→76 invariants (+1 INV-CROSS-OS-001)** / **629→636 checks (+7)** / 19 meta rules / 安全 95/100 / VERSION 0.37.9.66 → 0.37.9.67. ⑨ **元价值**: V37.9.67 是 P0 行动 1 真兑现 (反思文档行动 1 — 防 macOS bsd 工具 quirk). 同日内: V37.9.66-hotfix 暴露 watchdog quirk → 反思文档登记 5 行动 → 立即执行 P0 行动 1 → INV 上线 + scanner 主动监控. **闭环时间 < 4h 从血案到 framework 级机器化预防**. 未来同款 quirk 引入 → governance audit 立即抓, 不再等"血案级"暴露. V3 路标 pip install ontology-engine 终极目标的核心交付 — "每次血案转化为下次免疫力" 迭代机制实证. |
| V37.9.66 | 2026-05-13 | **convergence framework 双向 sync primitives + `_format_cron_line` path bug 修复 (V37.9.65 用户实测发现 framework 单向 gap + 潜伏 path bug)** — ① **触发**: V37.9.65 用户 Mac Mini 真激活后实测发现两个真 bug: (a) 改 yaml interval `0 14 * * *` 后 framework 报零漂移, 但真 cron 行仍是 `0 8,14,20` — `line_contains_identifier` parser 只检 entry 字符串包含不检 interval/log, 单向 sync 漏 extra detection (b) `_format_cron_line` 拼 `~/jobs/...` 但 Mac Mini 真 cron 用 `~/.openclaw/jobs/...` (auto_deploy FILE_MAP 部署约定), 潜伏 path bug. ② **5 层修复**: (1) `_format_cron_line` jobs/ 开头 entry 加 `.openclaw/` 前缀; 老 V27 脚本不变 (2) `ConvergenceResult` 加 `extra_in_runtime: frozenset` 字段 (默认 frozenset(), 向后兼容) (3) 新 extractor `_extract_jobs_to_full_cron_lines` 注册 `_DECLARED_EXTRACTORS` (4) 新 parser `_parse_cron_lines_set_diff` 注册 `_IDENTIFIER_PARSERS` — 不与 declared 求交保留 observed extras (5) `_apply_machine_sync` + `_apply_jobs_to_crontab_per_entry` 加 `extra_entries` 参数调 V37.9.65 `crontab_safe.sh remove` helper. ③ **关键设计决策**: spec yaml `jobs_to_crontab` 暂不切换 parser (避免 34 job 路径一致性 audit false drift 风暴, 老 V27 脚本 entry=`script.sh` vs 新 V30+ entry=`jobs/X/run_X.sh`). V37.9.67+ 候选才真切换. ④ **20 新单测 5 测试类** + **反向验证守卫真有效**: sabotage path fix 还原 → 4 failures / sabotage 删 extra_in_runtime 字段 → 5 failures + 30 errors. 还原后 278/278 OK. ⑤ **INV-CONVERGENCE-CRON-001 扩 +10 checks** (9 declaration + 1 runtime python_assert 跑 V37.9.66 5 测试类). ⑥ **累计**: 83 suites 不变 / 2831→2853 tests (+22) / 0 fail / governance v3.41→v3.42 / 75 invariants 不变 / 619→629 checks / 安全 95/100 / VERSION 0.37.9.65→0.37.9.66. ⑦ **Mac Mini 部署后预期**: governance audit 报零漂移 (parser 不变), 但隐藏改善 — 未来真激活 add 拼路径正确不再加错路径行. ⑧ **V37.9.67+ 候选**: spec yaml 切 cron_lines_set_diff 真激活双向 sync + 34 job 路径一致性 audit. ⑨ **元价值**: V37.9.65 用户实测 → V37.9.66 framework 升级根治 — 用户视角原则 #13 第 N+2 次正向兑现, framework 演进从靠 Claude Code 记忆升级为靠用户实测驱动. |
| V37.9.65 | 2026-05-13 | **crontab_safe.sh 加 `remove` command — V37.9.64 用户痛点闭环 (不需 vim) + convergence framework 双向 sync 下半截** — ① **触发**: V37.9.64 改 freight 一天 1 次 14:00 后, 用户反馈"不需要使用 VIM" — V37.9.64 推荐 `crontab -e` 手动删 2 行需用户进 vim 编辑器, 用户视角不友好。同时这是 V37.9.64 收工承诺登记的 V37.9.65 候选 (convergence machine_sync 加 remove_extra 双向 sync 能力的下半截)。② **设计 cmd_remove 镜像 cmd_add 安全机制**: backup + 严格 count 验证 (count_after = count_before - matched, V37.9.18 cmd_add 同款契约防 35→35 谎报 ✅) + 拒绝全清空操作 (pattern 匹配所有活跃行时拒绝, V30 教训) + 失败自动 cmd_restore 回滚. **接口**: `bash crontab_safe.sh remove "<grep -F 固定字符串 pattern>"` — pattern 用 grep -F 匹配 (不是正则), 出现在行内任何位置都被删除. ③ **修一个 V37.9.65 引入的 bug** (开发期发现): `grep -cF -- "$pattern" \|\| echo 0` 在 grep 无匹配时输出"0\n0" (grep -c 已输出 0 + `\|\|` 触发 echo 0), 导致 matched_count = "0\n0" 整数比较失败. 修: `\|\| true` 仅安抚 pipefail 不再额外 echo. ④ **test_crontab_safe_remove.py 16 单测 4 类**: TestRemoveBasic(5 含真 fake-crontab shim 注入 PATH 隔离 + 单 pattern 单行 + 0 匹配 silent skip + 拒绝全清空 + 空 pattern 用法提示) + TestRemoveMultipleMatches(1 单 pattern 多行严格 count 验证) + TestCliInterface(2 help 含 remove + V37.9.65 marker) + TestSourceLevelGuards(8 V37.9.65 marker / cmd_remove() 函数定义 / remove case 分支 / grep -F 固定字符串 / -ne 严格相等 / 拒绝全清空保护 / cmd_restore 自动回滚 / do_backup 修改前). **反向验证守卫真有效**: sabotage cmd_remove 函数整段删除 → 9 failures + 2 errors, 还原后 16/16 OK. ⑤ **MR-9 正向兑现** (state-writes-go-through-helper-not-raw-redirect): 用户操作 crontab remove 现在走 helper 不再 vim 直编辑, 同 add 模式接到机器化安全机制. ⑥ **V37.9.64 Mac Mini 操作升级** (用户体验改善): 旧"crontab -e 进 vim 删 2 行"→ 新"`bash ~/crontab_safe.sh remove "<pattern>"` 一行命令 + 同款删 20:00", 自动 backup + count 验证 + 失败回滚, 不需 vim. ⑦ **累计**: 82→83 suites (+1 crontab_safe_remove) / 2815→2831 tests (+16) / 0 fail / 安全 95/100 / VERSION 0.37.9.64 → 0.37.9.65. ⑧ **元价值**: 用户视角原则 #13 第 N+1 次正向兑现 — 单测/治理全过, 用户实际操作流程 (vim 体验差) 立即触发改进. 同时把 V37.9.65 候选从"V3 路标 framework 双向 sync 增强"具体化为 "crontab_safe.sh remove 已上线", convergence framework 调用此 helper 即可实现 remove_extra (V37.9.66+ 候选). MR-9 (state-writes-go-through-helper) 在用户操作层兑现, 把"用户改 crontab 走 helper"从纪律建议升级为可用工具. |
| V37.9.64 | 2026-05-13 | **货代 Watcher 推送频率 3次/天 → 1次/天 (用户视角原则 #13 + #32 减少告警疲劳)** — ① **触发**: 用户开工后立即提出"货代商机速报及货代客户画像任务一天有几个？建议一天一次即可 没必要一天几次"。审计现状: freight_watcher 是唯一货代相关 job, 但产出三层 (📊 经济晴雨表 / 🏢 运营信号 / 🚢 商机条目) + 客户画像 deep_dive — 用户看到的"商机速报"+"客户画像"是同一脚本的不同输出段非两个 job。当前 interval `0 8,14,20 * * *` 每天 3 次 (V37.9.33 起)，watchdog 阈值 50400 (14h). ② **原则 #28 三问全过**: Q1 之前存在 ✓ (V37.9.33 起 3 次) / Q2 我引入 ✗ (历史配置) / Q3 最小修复 = 改 interval + 同步阈值 + Mac Mini 手动删多余 crontab 行。③ **用户决策时段**: 14:00 (中午业务空隙看, 与 finance_news 07:30 + 22:00 kb_evening 错开)。④ **改动 3 文件**: (a) jobs_registry.yaml: `0 8,14,20 * * *` → `0 14 * * *` + V37.9.64 注释 (b) job_watchdog.sh: freight 阈值 50400 (14h) → 180000 (50h, 24h max gap + 26h slack) (c) test_cron_health.py: dict 内 `freight_watcher: 50400` → `180000` 同步守卫。⑤ **convergence framework 单向 sync 限制 (新发现)**: V37.9.58 起 jobs_to_crontab spec 真激活 machine_sync, 但实现是单向 (declared missing → add via crontab_safe.sh add), 不删 extra (runtime 有但 declared 没)。**意味着改 yaml 一行后 framework 不会自动删多余的 2 行 cron** — 因 framework 用 `line_contains_identifier` 匹配 entry, 3 个 cron 行都含同一 entry → missing=0 → 不动。用户必须手动 `crontab -e` 删除 freight_watcher 的 08:00 和 20:00 两行。⑥ **未来 framework 增强候选 V37.9.65+** (登记 status.json unfinished): convergence machine_sync 加 `remove_extra` 支持 — declared 缺 + runtime 多 双向 sync, crontab_safe.sh 加 remove command, 让 freight 这类配置变更自动落地不需用户手动操作。⑦ **累计**: 82 suites / 2815 tests / 0 fail / 安全 95/100 / VERSION 0.37.9.63 → 0.37.9.64. ⑧ **Mac Mini 部署后用户操作 (必须手动)**: (1) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 yaml (2) **`crontab -e` 删除 freight_watcher 的 08:00 和 20:00 两行** (保留 14:00 行) (3) `crontab -l \| grep freight` 验证只剩 1 行 (4) 下次 governance audit cron (07:00) 跑应报告 jobs_to_crontab declared=1 observed=1 missing=0 零漂移. ⑨ **元价值**: 用户视角原则 #13 (定期像用户用) + #32 (周一观察制度) 第 N 次正向兑现 — 单测/治理全绿但只有用户在 WhatsApp 反复看到 freight 推送才能感知"3 次过频"。同时 V37.9.65 候选揭示 convergence framework 真实 gap (单向 sync), 把"配置变更落地"从靠用户记忆升级为机器化框架功能 — V3 路标 `pip install ontology-engine` 双向 sync 能力候选. |
| V37.9.63 | 2026-05-13 | **MR-8 抽公共 fatal_handler helper — MR-19 framework 化推广后第一次 MR-8 正向兑现 + 顺势修 V37.9.60 6 个 fatal_handler 第二层 FAIL-OPEN CLI 参数 bug** — ① **触发**: V37.9.61 收工承诺登记 V37.9.63+ 候选 "MR-8 抽 cron_monitor_fatal_handler.sh 公共 helper, V37.9.60+V37.9.61 7 governed scripts copy-paste". 用户开工选 MR-8 路径 (vs by design 排除重评估 / docs/config.md 同步 / 用户视角观察). ② **audit 7 个 inline _\<script\>_fatal_handler 真实代码**: 99% 同款 (三层 FAIL-OPEN: stderr 写错误 / 本地 .openclaw_alerts.log 追加 / notify→openclaw 直发) + 6 处差异 (caller name / reason 文案 / log path / bash_x hint / OPENCLAW 变量名 OPENCLAW vs OPENCLAW_BIN / auto_deploy CLI 参数风格 1/7 异端). ③ **意外发现 V37.9.60 6 个 fatal_handler 第二层 FAIL-OPEN CLI 参数 bug**: 用了 `--channel-id` + `--content` 但 canonical CLI (notify.sh / auto_deploy 主告警 / watchdog 主告警 / health_check / diagnose 同款) 是 `--target` + `--message` + `--json`. 6 个 fatal_handler 第二层 FAIL-OPEN 在 notify 不可用时**实际是死代码**. 顺势统一到 canonical CLI. ④ **新文件 cron_monitor_fatal_handler.sh** (~80 行 helper, sentinel `CRON_MONITOR_FATAL_HANDLER_LOADED="V37.9.63"`): 单函数 `_cron_monitor_fatal_handler()` 读 4 个 caller 变量 (`CRON_FATAL_LABEL` / `CRON_FATAL_LOG` / `CRON_FATAL_BASH_X` / `CRON_FATAL_REASON`) + 三层 FAIL-OPEN 同款 + canonical CLI + 三档 OPENCLAW 变量 fallback (`${OPENCLAW_BIN:-${OPENCLAW:-/opt/homebrew/bin/openclaw}}`). ⑤ **7 个 governed scripts 迁移**: 每个删除 ~20 行 inline `_<script>_fatal_handler` 函数 + 加 7 行 (source helper + 4 个 CRON_FATAL_* 变量 + trap '_cron_monitor_fatal_handler $LINENO' ERR), 净减少 ~13 行 × 7 = **~90 行 copy-paste 消除**. watchdog 保留 `_watchdog_exit_handler` (canary heartbeat) 不动 — 它不是 fatal handler. ⑥ **test_cron_monitor_fatal_handler.py 30 单测 7 类** + 反向验证守卫真有效: TestHelperSyntaxAndStructure(6) + TestHelperCanonicalCli(2 含反 V37.9.60 buggy CLI 守卫) + TestHelperRuntimeBehavior(5 含 subprocess 真跑 set -e caller + handler 自身不冒泡契约) + TestSevenScriptsIntegration(7 含 LABEL 唯一性 + helper source 命令真实性) + TestInlineHandlersRemoved(2 含 watchdog 保 EXIT trap) + TestReverseVerificationSabotage(3 含 sabotage helper → 13 failures / sabotage script source → integration 守卫立即抓) + TestV37963SourceLevelMarkers(5 含 FILE_MAP 部署 + MR-8 引用 + 7 scripts 计数锁定). **反向验证已确认守卫真有效**: sabotage helper → 13 failures (含 layer1/layer2/integration/sabotage 自身的元层验证), 还原后 30/30 OK. ⑦ **cron_monitor_scanner.py 升级**: 新增 `uses_shared_fatal_handler_helper()` 纯函数 (检测 source helper + trap helper 函数双条件 + 跳过注释行), scan_script 加 alternation — [SYSTEM_ALERT] marker OR V37.9.63 helper 模式 任一满足即合规. 防止 V37.9.63 抽 helper 后 daily_ops_report (V37.9.63 后无 [SYSTEM_ALERT] inline) 被误判. ⑧ **test_cron_monitor_scanner.py V37.9.61 守卫升级 alternation**: `test_v37_9_61_llm_task_scripts_have_fatal_handler` 接受 inline trap `'_<script>_fatal_handler' $LINENO' ERR` (legacy V37.9.61) OR helper 模式 (source + trap `'_cron_monitor_fatal_handler'`). 52/52 仍全过. ⑨ **INV-CRON-MONITOR-001 扩 +10 checks** (V37.9.63 helper 段): helper 文件存在 + V37.9.63 marker + 公共函数定义 + canonical CLI (`--target/--message/--json` 各 1 check) + MR-8 引用 + scanner V37.9.63 helper 模式 alternation 守卫 (`uses_shared_fatal_handler_helper`) + auto_deploy FILE_MAP 部署守卫 + 1 runtime python_assert subprocess 跑 test_cron_monitor_fatal_handler.py 30 单测全过. ⑩ **INV-WATCHDOG-SELF-001 升级 alternation** (V37.9.63 后 watchdog inline handler 已移除): 2 个原字面量守卫 (`watchdog ERR trap 注册` + `ERR trap 推送 [SYSTEM_ALERT]`) 升级为 `python_assert` 双路径 — 接受 inline 模式 (legacy V37.9.58-hotfix3 watchdog 自身含 `[SYSTEM_ALERT] watchdog FATAL`) OR V37.9.63 helper 模式 (source helper + helper 自身含 `[SYSTEM_ALERT]`). ⑪ **auto_deploy.sh FILE_MAP 补齐**: 加 `cron_monitor_fatal_handler.sh\|$HOME/cron_monitor_fatal_handler.sh` 部署到 Mac Mini ~/. ⑫ **MR-8 single-source-of-truth 兑现** — 修改 fatal_handler 行为现在只需改 helper 一处, 7 个 governed scripts 自动 propagate. 未来加新 governed cron 类聚合监控只需 source helper + 4 变量 + trap, 不再 copy-paste. ⑬ **累计**: 81→82 suites (+1: cron_monitor_fatal_handler) / 2785→2815 tests (+30) / 0 fail / governance v3.40→v3.41 / 75 invariants 不变 (INV-CRON-MONITOR-001 内涵扩) / 609→619 checks (+10) / 19 meta rules 不变 (V37.9.63 是 MR-8 正向兑现, 不立新元规则) / 安全 95/100 / VERSION 0.37.9.62 → 0.37.9.63. ⑭ **Mac Mini 部署后预期行为**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.63 (b) auto_deploy 2min 轮询自动同步 cron_monitor_fatal_handler.sh 到 ~/ (c) 下次任一 governed cron 触发 ERR trap 时 (job_watchdog 4h/governance_audit 07:00/daily_ops 08:15/auto_deploy 2min/kb_deep_dive 22:30/kb_evening 22:00/kb_review 周日 21:00) 走 helper 路径, Discord #alerts 推送行为不变, 但 fatal_msg 内容含 caller-provided REASON + LOG path + bash_x hint (与 V37.9.60+V37.9.61 inline 时代等价). ⑮ **元价值**: V37.9.58-hotfix3 单点 MR-19 (watchdog 合规) → V37.9.59 watchdog 覆盖率扩展 (LOG_FRESHNESS) → V37.9.60 MR-19 framework 化推广 (4 cron) → V37.9.61 LLM-task 扩展 (3 LLM-task = 7 总) → **V37.9.63 MR-8 抽公共** — silent monitor 防御 framework 四阶段完整闭环. 同时用 audit 工作意外发现 V37.9.60 隐藏 CLI 参数 bug 顺势统一. 原则 #18 "补证据而非补功能" 兑现 — 不增加 cron 数量, 但 framework 边界更清晰 + 死代码消除 + 治理负担降低 + V3 路标 `pip install ontology-engine` 终极目标的可包化粒度进一步聚焦. ⑯ **下次 V37.9.64+ 候选**: (a) Mac Mini 用户视角观察 V37.9.62 6 脚本真激活推送质量 (V37.9.62 收工承诺登记 candidate a) (b) finance_news/freight/kb_dream/kb_inject 4 个 by design 排除评估 (V37.9.62 candidate b) (c) docs/config.md 头部漂移修复 (停在 v37.9.57, V37.9.58→V37.9.63 累积 6 版本未同步) (d) 一周观察期后立 INV-CRON-MONITOR-HELPER-001 严格守卫"未来新 governed script 必须用 helper 而非 inline" (e) V37.9.30 24-48h ACL/lsof/snapshot 数据回归 + V37.9.35 推送质量观察. |
| V37.9.62 | 2026-05-13 | **6 脚本 batch 升级 6 字段 — 用户视角 100% 彻底处理 (Sub-Stage 4b 续完结, ALIGNED_SCRIPTS 11→17 = 81% LLM cron 候选)** — ① **触发**: 用户视角发现 ACL Anthology 推送只有浅 3 字段, 要求按 S2 (V37.9.39+) 6 字段格式 + "100% 彻底 check 还有哪些任务请一并处理, 不要有遗漏". audit 报告 10 unaligned 中 6 个适合升级 (4 P1 机械迁移 + 2 P2 含定制). ② **batch 6 脚本** (并行 6 agents + 主线 audit + 测试 alternation): (a) `jobs/acl_anthology/run_acl_anthology.sh` (391→728 行) 机械迁移 V37.9.51 dblp papers 模板, ACL 有 abstract (rule_content = title + abstract + venue) (b) `jobs/karpathy_x/run_karpathy_x.sh` (420→773 行) 机械迁移 ai_leaders_x V37.9.51 tweets 模板 (单账号, rule_content = author + text) (c) `jobs/openclaw_official/run.sh` (214→683 行) 机械迁移 rss_blogs V37.9.51 blogs 模板, GitHub releases (rule_content = title + body) (d) `jobs/openclaw_official/run_discussions.sh` (179→728 行) 机械迁移 hn V37.9.51 threads 模板, GitHub Issues+Discussions (rule_content = title + body) (e) `jobs/ontology_sources/run_ontology_sources.sh` (449→678 行) + `ontology_parser.py` 扩, 机械迁移 V37.9.51 但 V37.8.7 separator 切块设计完整保留 + parse_6field_output 扩展, 4 RSS source / 关键词过滤 / Discord #ontology 路由全保留 (f) `jobs/chaspark/run_chaspark.sh` (267→772 行) **混合定制设计** Phase A per-article 6 字段 (V37.9.51 rss_blogs 同款) + Phase B 跨域分析 (V37.9.33 freight 三层启发, 保留 chaspark 跨文章关联洞察特色), API 抓取 + 去重 + KB 归档全保留. ③ **ALIGNED_SCRIPTS 11→17** (audit 报告 21 候选 - 4 by design 排除 = 17 应对齐). by design 排除: finance_news (V37.8.5 定制 Syndication API 多通道) / freight_watcher (V37.9.33 三层结构客户画像) / kb_dream (V36.1 KB 内部 MapReduce 不推送) / kb_inject (KB 内部摘要不推送). ④ **测试 alternation 修**: test_ontology_parser (V37.8.7 24 tests 兼容 6 字段) + test_llm_cron_audit (alignment 计数) + governance INV-ONTOLOGY-001 pattern 升级. ⑤ **累计**: 82 suites 不变 / 2785 tests 不变 (alternation 修, 没新增 batch 测试) / 0 fail / governance v3.40 不变 (无新 INV, alternation 升级) / 75 invariants 不变 / 609 checks 不变 / 19 meta rules 不变 / 安全 95/100 / VERSION 0.37.9.61 → 0.37.9.62. ⑥ **元价值**: V37.9.45 (hf_papers PoC) → V37.9.50 (S2 PoC) → V37.9.51 batch (6 脚本) → **V37.9.62 batch (6 脚本)** = Sub-Stage 4b 完整闭环. 21 LLM cron 候选 17 已对齐 (81%), 其余 4 by design 排除. 用户视角 "100% 彻底处理不遗漏" 兑现. ⑦ **Mac Mini 部署后预期 (用户视角验证)**: ACL Anthology 下次周三 09:30 cron 触发推送应**首次出现** 📌中文标题/🔑核心贡献/💡关键方法/🎯实践启发/⭐评级/🎚️项目对齐度 6 字段 + 高对齐统计 (取代浅 3 字段血案). karpathy_x 09:00,21:00 / openclaw_official 同款 / ontology_sources 10:00,20:00 / chaspark 11:00 都升级. ⑧ **下次 V37.9.63+ 候选**: (a) 全部 6 脚本 Mac Mini 真激活验证用户视角推送质量 (b) finance/freight/kb_dream/kb_inject 4 个 by design 排除评估 (c) MR-8 抽 cron_monitor_fatal_handler.sh 公共 helper (V37.9.61 7 governed scripts copy-paste). |
| V37.9.61 | 2026-05-13 | **MR-19 扩到 LLM-task 类 — V37.9.60-hotfix3 揭露的 framework gap 闭环 (3 LLM-task 脚本合规 + cron_monitor_scanner 监管范围 4→7)** — ① **触发**: V37.9.60-hotfix3 同日早用数据驱动诊断 (fallback_chain + log + bash -x + deep_dives 5 文件 + crontab 5 维度) 定位 V37.9.21 我引入的 silent abort 真因 (send_wa_parts && sleep 短路 → set -e 杀 caller → kb_deep_dive 5/8-5/12 5 天 last_run 不更新). 揭露 V37.9.60 framework scope 设计缺口: SCRIPTS_REQUIRING_ERR_TRAP 只覆盖 cron 聚合监控类 (4 个), 遗漏 LLM-task 类 (kb_deep_dive/kb_dream/kb_evening/kb_review) — 这些脚本同款 set -euo + 推 [SYSTEM_ALERT] + 缺 trap ERR 风险. ② **V37.9.61 framework 化扩展** (严格 #28 最小修复): (a) 修 3 LLM-task 脚本 (kb_deep_dive / kb_evening / kb_review): set -euo → set -eEuo (加 -E errtrace, V37.9.58-hotfix4 教训) + 各加 inline `_<script>_fatal_handler` 函数推 [SYSTEM_ALERT] + 三层 FAIL-OPEN (notify.sh → openclaw 直发 → 本地 .openclaw_alerts.log) + `trap '_<script>_fatal_handler $LINENO' ERR` 注册. (b) cron_monitor_scanner.py SCRIPTS_REQUIRING_ERR_TRAP 4→7 (新增 kb_deep_dive.sh / kb_evening.sh / kb_review.sh). kb_dream.sh 不加 (V37.4.x retry/fallback 已含复杂 fail-fast 自身). ③ **测试**: test_cron_monitor_scanner.py 46 单测 alternation 兼容 SCRIPTS 4→7 + 反向验证 sabotage 3 LLM-task 立即抓 violation. ④ **累计**: 82 suites 不变 / 2785 tests 不变 (alternation 修, 没新增 batch 测试) / 0 fail / governance v3.40 (INV-CRON-MONITOR-001 监管范围 4→7) / VERSION 0.37.9.60 → 0.37.9.61. ⑤ **元价值**: V37.9.60 cron 聚合监控类 MR-19 合规 → V37.9.61 LLM-task 类 MR-19 合规. framework "MR-19 一个契约 (err_trap_handler) 覆盖 cron 类 + LLM-task 类共 7 脚本" 完整闭环. ⑥ **下次 V37.9.62+ 候选**: (a) Mac Mini 部署后 3 个 LLM-task ERR trap 真激活验证 (b) MR-8 抽 cron_monitor_fatal_handler.sh 公共 helper (7 个脚本 copy-paste 已构成 MR-8 反例信号). |
| V37.9.60 | 2026-05-13 | **MR-19 err_trap_handler 契约横向推广 — V37.9.58-hotfix3 立 MR-19 后第一次 framework 化扩展** — ① **触发**: V37.9.58-hotfix3 (2026-05-12) 立 MR-19 (monitor-must-self-alarm-on-silent-abort) 时只把 job_watchdog.sh 升级为合规, 收工候选明确登记 "扫所有 cron 监控脚本是否满足 MR-19 三契约". 用户 5/13 开工选 "MR-19 三契约扫描" 路径 (vs 元监控 cron_canary 外部检测 / 监控覆盖率 100% / 用户视角观察 Mac Mini 真激活). ② **scope 收敛**: V37.9.60 = err_trap_handler **一个契约** 横向推广 (awk_safe 仅适用处理 log 的 awk pipe / canary_writer 仅适用 watchdog 类聚合监控, 都是 watchdog-specific 不普适). MR-19 治理对象 4 个: job_watchdog.sh (V37.9.58-hotfix3 已合规) / governance_audit_cron.sh / daily_ops_report.sh / auto_deploy.sh. **MR-19 不适用** 4 个: wa_keepalive (V37.9.59 LOG_FRESHNESS_JOBS 已通过 log mtime 监控) / cron_canary (本身是 heartbeat writer) / health_check (周报无 set -e) / preflight_check (user-interactive 诊断, fail-fast 给用户看是预期). ③ **新文件 `cron_monitor_scanner.py`** (~200 行纯 Python, 启发式 scanner 不依赖 AST): `SCRIPTS_REQUIRING_ERR_TRAP` 4 个 governed 脚本 + 3 个纯函数 `has_set_e_strict` (regex `^\s*set\s+-[a-zA-Z]*e[a-zA-Z]*`) / `has_err_trap` (单行内 trap 后任意位置出现 ERR 词边界 + 跳过注释行) / `has_system_alert_marker` (整脚本 `[SYSTEM_ALERT]` 字面量出现, 简化检查) + `scan_script` / `scan_repo` / `main` CLI (`--list` / `--file` / 默认全量). **FAIL-CLOSE 契约**: 任一 violation 必须 exit 1. **dev scan 立即抓出 3 个真违反** — governance_audit_cron.sh / daily_ops_report.sh / auto_deploy.sh 都是 `set -e*` + 无 trap ERR, V37.9.58-hotfix3 同款盲点. ④ **3 个脚本修复 (inline 模式, V37.9.60 PoC 选择)**: 每个加 (a) set -e* → set -eE* (加 -E errtrace 让 function 内 fail 也触发 ERR trap, V37.9.58-hotfix4 教训) (b) 定义 `_<script>_fatal_handler` 函数推 [SYSTEM_ALERT] 内含 exit_code / line_no / 排查提示 + 三层 FAIL-OPEN: notify.sh → openclaw 直发 → 本地 ~/.openclaw_alerts.log 写入 (c) `trap '_<script>_fatal_handler $LINENO' ERR` 注册. MR-8 single-source-of-truth 讨论: V37.9.60 PoC 4 个脚本 copy-paste handler 可接受; 未来扩展到 N 个监控时考虑抽 helper (V37.9.61+ 候选). ⑤ **INV-CRON-MONITOR-001** 新增 (meta_rule=MR-19, severity=high, verification_layer=[declaration, runtime], **18 checks**): 16 declaration (scanner V37.9.60 marker / FAIL-CLOSE / MR-19 引用 / 4 个 governed 脚本字面量 + 3 个修复脚本各 3 守卫: fatal_handler 名 + V37.9.60 marker + set -eE*) + 2 runtime python_assert (subprocess 跑 scanner 0 violations + subprocess 跑 46 单测全过). ⑥ **test_cron_monitor_scanner.py 46 单测 8 类** + **反向验证 4 类**: TestHasSetEStrict(11 含 set -e/eo/euo/eEo/eEuo/ex + set -u 单独无 e 不算) + TestHasErrTrap(9 含 trap '' ERR / 含 EXIT 不算 / 多信号 ERR / 注释行豁免) + TestHasSystemAlertMarker(4) + TestScanScript(5 含合规无 findings / missing trap / trap 无 alert / 无 set -e 不强制 / 文件不存在) + TestScanRepoIntegration(2 含 V37.9.60 修复后全合规 + SCRIPTS list 锁定) + **TestReverseVerificationGuardsAreReal(4 反向验证)** sabotage 4 个 governed 脚本立即触发 violation + 还原后再次合规 (job_watchdog/governance_audit/daily_ops/auto_deploy 各一) + TestCliBehavior(3) + TestSourceLevelGuards(8 V37.9.60 marker / MR-19 引用 / FAIL-CLOSE 契约 / SCRIPTS 锁 / V37.9.58-hotfix3 lineage / 3 脚本 V37.9.60 marker + handler 名 + -E errtrace). 反向验证已确认守卫真有效: sabotage governance_audit_cron 删 trap ERR → test 立即抓 missing_err_trap, 还原后合规. ⑦ **接入**: full_regression.sh +1 suite `cron_monitor_scanner` 紧随 V37.9.59 watchdog_coverage. test_convergence.py audit_metadata version alternation 加 `version: "3.39"`. **不加 FILE_MAP**: scanner 是 dev/CI tool, governance_audit_cron 从 repo dir 跑 (`cd $REPO_DIR && python3 ontology/governance_checker.py --full`), scanner 在仓库根目录即可访问 (V37.9.58-hotfix2 heredoc_import_scanner 同款模式). ⑧ **累计**: 81→82 suites (+1: cron_monitor_scanner) / 2757→2803 tests (+46) / 0 fail / governance v3.38→v3.39 / 74→75 invariants (+1 INV-CRON-MONITOR-001) / 582→600 checks (+18) / 19 meta rules 不变 (MR-19 在 V37.9.58-hotfix3 立案) / 安全 95/100 / VERSION 0.37.9.59 → 0.37.9.60. ⑨ **Mac Mini 部署后预期**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.60 (b) **3 个修复脚本立即生效**: 下次 governance_audit_cron (每日 07:00) / daily_ops_report (每日 08:15) / auto_deploy (每 2min) 触发时如有 set -e abort, ERR trap 主动推 [SYSTEM_ALERT] 到 Discord (不再 silent), 用户立即可见 (c) governance audit cron 同时跑 INV-CRON-MONITOR-001 runtime check, 任一 governed 脚本未来回退到 silent 模式立即被 audit 抓到. ⑩ **下次 V37.9.61+ 候选**: (a) 一周观察 3 个新 trap ERR 真激活效果 (Discord 应看到首条 FATAL alert if 任一脚本 silent abort) (b) MR-8 single-source-of-truth: 若未来扩展到 N 个监控考虑抽 `cron_monitor_fatal_handler.sh` 公共 helper (c) MR-21 候选 `monitor-coverage-must-track-registry` (V37.9.59 立案准备, baseline 5/12 + 7d = 5/19 一周观察后立 INV-WATCHDOG-COVERAGE-001) (d) 元监控 cron_canary 外部检测 watchdog_canary.json (chicken-and-egg 真闭环) (e) V37.9.30 EPERM 24h 数据回归 + V37.9.35 推送质量观察. ⑪ **元价值**: V37.9.58-hotfix3 立 MR-19 (watchdog 单点合规) + V37.9.59 watchdog 覆盖率扩展 (LOG_FRESHNESS) + **V37.9.60 MR-19 框架化推广** (4 个脚本批量合规 + scanner 主动监控) = 三阶段闭环 silent monitor 防御 framework. 未来新增 cron 类聚合监控只需注册到 SCRIPTS_REQUIRING_ERR_TRAP 即被 governance audit 强制 enforce, V3 路标 `pip install ontology-engine` 核心交付方向 — declarative monitor governance 用机器化契约取代记忆维护成本. mirror V37.9.58-hotfix2 heredoc_import_scanner 同款 framework 化模式 (MR-18 立案后 framework scanner 落地). |
| V37.9.59 | 2026-05-12 | **watchdog 监控覆盖率扩展 47%→74%+** — 用户 5/12 17:30 询问 "watchdog 是否监控所有任务" 驱动. job_watchdog.sh JOBS 数组 +4 jobs (`kb_deep_dive` / `kb_dream` / `chaspark` / `governance_audit`, 都有 last_run.json 写入). 新加 `LOG_FRESHNESS_JOBS` 数组 +11 jobs (`auto_deploy` / `wa_keepalive` / `cron_canary` / `kb_embed` / `kb_trend` / `kb_status_refresh` / `mm_index` / `daily_ops_report` / `openclaw_backup` / `preference_learner` / `health_check`) — 用 log mtime 替代 last_run, 粗粒度但比完全不监控好. `check_log_freshness()` 函数实现 stat -f %m + tier 分级 + ALERTS 追加. STALE_LOCK_DIRS 补 kb_dream + chaspark (18→20). **Watchdog 自监控** (V37.9.58-hotfix3 元监控盲区上游): 检查 `~/watchdog_canary.json` mtime > 12h 触发 [SYSTEM_ALERT] 通过 alerts 频道. **22 单测** test_watchdog_coverage.py 6 类 (JOBS expansion / LOG_FRESHNESS / self-monitor / STALE_LOCK / 覆盖率 ≥25 / source-level marker). 反向验证: V37.9.58-hotfix3 sabotage 测试改 replace 所有出现 (V37.9.59 加重复字面量后单点 replace 失效). 累计 80→81 suites (+1) / 2735→2757 tests (+22) / 0 fail / governance v3.38 不变 (V37.9.60+ 立 INV-WATCHDOG-COVERAGE-001 PoC 阶段) / 安全 95/100 / VERSION 0.37.9.58→0.37.9.59. **元价值**: V37.9.58 五件套主要修 watchdog 自身 silent abort, V37.9.59 治理 watchdog 监控盲区. V37.9.58 + V37.9.59 共同闭环今日用户两个深问 (为什么不告警 + 是否监控所有任务). **下次 V37.9.60+ 候选**: (a) 监控覆盖率达 100% (剩 4 个: openclaw_official/discussions 已 disable / hn_watcher 已含 / 等) (b) 立 INV-WATCHDOG-COVERAGE-001 + MR-21 candidate `monitor-coverage-must-track-registry` (一周观察后) (c) 元监控 cron_canary 外部检测 watchdog_canary.json 真正 chicken-and-egg 防御. |
| V37.9.58-hotfix5 | 2026-05-12 | **V37.9.27 rsync 输出可观察性补丁 — 用户视角发现 watchdog 告警 "(时间戳缺失)" 8 个 jobs 噪声驱动** — ① **触发**: V37.9.58-hotfix4 Mac Mini 真激活后用户 WhatsApp 收到 17 条累积告警, 敏锐发现 8 个 jobs 告警全显示 "(时间戳缺失) → rsync(N): error: unexpected end of file", 反问 "时间戳却是？？？". ② **真因**: V37.9.27 movespeed_rsync_helper.sh line 99 `rsync "$@" 2>&1` 直接转发 rsync 自身错误格式 (e.g. "rsync(47596): error: ..."), **不带时间戳前缀**. 进 caller log 后 V37.9.28 F1 watchdog scan_logs err_ts 提取 `[YYYY-MM-DD HH:MM]` 模式失败 → 告警显示 "(时间戳缺失)". ③ **三问全过 (原则 #28)**: Q1 之前存在 ✓ (V37.9.27 helper 引入时就这样, 4 周前) / Q2 我引入 ✗ (设计漏洞非 hotfix4 引入) / Q3 最小修复 = helper rsync 输出加 awk pipe timestamp prefix + PIPESTATUS[0] 保 rsync exit code. ④ **修复 (2 行)**: `RSYNC_TS="$(date '+%Y-%m-%d %H:%M:%S')"` + `rsync "$@" 2>&1 \| awk -v ts="$RSYNC_TS" '{print "[" ts "] " $0}'` + `EXIT_CODE=${PIPESTATUS[0]}` (rsync exit, 不是 awk). ⑤ **意外验证已通过**: 用户 5/12 17:02 误把示例代码块复制到 zsh 直接执行 (没 args 给 rsync), rsync 输出 usage 30 行, awk 给每行加 `[2026-05-12 17:02:06]` prefix — V37.9.58-hotfix5 awk timestamp pipe **实测工作**. ⑥ **下次 watchdog 告警预期对比**: 旧"(时间戳缺失) → rsync(N): error: ..." → 新"(最早 X, 最新 Y) → [HH:MM:SS] rsync(N): error: ...". ⑦ **接入**: 全量回归 80 suites / 2735 tests / 0 fail (V37.9.27 25 单测全兼容). 不动 governance INV-RETRY-001 (helper 行为契约不变, 只是输出格式改进) + 不立新 MR. ⑧ **今日 V37.9.58 六件套完整闭环**: dc1131d 主 / a4f71a5 hotfix / 69bd3cd hotfix2 / ae84298 hotfix3 / 46bf5a4 hotfix4 / 068eec3 hotfix5 — 一天内连续 6 commits 把 silent failure 从业务层 → 治理层 → 监控层 → 落地兜底 → 可观察性补丁五层逐层闭环. ⑨ **元教训**: 没有用户 5/12 两次深问 ("为什么静默失败不提前告警" + "时间戳却是？？？") → 六件套至少要拖 2-3 天分多次 session 才完成. 用户视角第 N 次正向兑现. |
| V37.9.58-hotfix4 | 2026-05-12 | **修 V37.9.58-hotfix3 两个落地漏洞 — set -E + caller || ALERT (Mac Mini 实测才暴露)** — ① **触发**: V37.9.58-hotfix3 部署 Mac Mini 后用户验证, watchdog 仍 exit 1 + canary 文件未写, **ERR trap 没触发 [SYSTEM_ALERT]** — V37.9.58-hotfix3 设计正确但落地漏点. ② **真因 (按原则 #28 三问)**: 漏洞 1: `set -eo pipefail` 缺 `-E` (errtrace) — bash 默认 `set -e` 在 function 内 fail **不传播 ERR trap** → fatal_handler 不调用 → 仍 silent abort. 漏洞 2: scan_logs 内 V37.9.28 F1 加的 `err_ts=$(... \| grep -iE ... \| grep -oE ... \| sort -u)` 缺 `\|\| true` 容错, recent_window 无错误行时 grep 无匹配 exit 1 + pipefail + set -e → 整 watchdog abort. ③ **三项修复**: (1) `set -eo pipefail` → `set -eEo pipefail` (加 -E errtrace 让 ERR trap 在 function 内生效) (2) err_ts pipe + last_err pipe 加 `2>/dev/null \|\| true` 容错 (3) `for entry in HOME_LOGS: scan_logs ... \|\| ALERTS+=("$job_name: scan_logs internal 异常")` — 让 scan_logs internal fail 可观察但**不让整 watchdog abort**, 让后续 7 维度都能跑. ④ **dev 验证 V37.9.58-hotfix4 真激活**: exit 0 (V37.9.58-hotfix3 是 1) / 56 行输出 (V37.9.58-hotfix3 是 1) / 跑完整 8 维度 / ALERT 真推送 (含 MOVESPEED 48 次 / Qwen context 90% / 多 last_run 不存在等). ⑤ **Mac Mini 实测 17:00 真激活成功**: watchdog exit 0 + 33 行 + canary 文件创建 (checks=22 alerts=17) + WhatsApp 收到 [SYSTEM_ALERT] 17 条 7 天累积告警 (SLO p95 59.5s / MOVESPEED 14 次 / RSS 46h / ai_leaders 46 错误 / 等). 5/5 16:30 起 silent 7 天血案完整闭环. ⑥ **接入**: 31 单测 test_watchdog_self_monitoring (V37.9.58-hotfix3 29 + V37.9.58-hotfix4 2 新守卫: test_set_E_errtrace_present + test_scan_logs_caller_has_alert_fallback) + alternation 接受 set -eEo / set -eo. governance v3.38 不变 (V37.9.58-hotfix4 不新增 INV/MR, 是 hotfix3 落地修复). 累计 80 suites / 2735 tests / 0 fail. ⑦ **副产物 noise**: SLO 检查 line 591 `SLO_ALERT=$(...) && X \|\| Y` idiom 在 set -eE 下产生 false FATAL alert (bash quirk: `&& \|\|` 连接不杀脚本但 ERR trap 仍触发) — V37.9.58-hotfix5+ 候选, 不影响功能只是 noise. ⑧ **元教训 (反思转化为机制)**: V37.9.58-hotfix3 dev 29 单测全过 + 反向验证守卫真有效, **不能替代 Mac Mini 真生产环境实测** — bash 3.2 quirk (set -e + function 内 fail 不传播 ERR trap) 只有真跑才暴露. 原则 #15 测试三层 (单测/dev/Mac Mini E2E) + 用户视角第 N 次正向兑现. MR-20 候选 `framework-level fix must validate in target environment, not dev` 一周观察后立 (MR-15 deployment-layout 同款血案兄弟). |
| V37.9.58-hotfix3 | 2026-05-12 | **治本 watchdog silent abort 7 天血案 — MR-19 立案 + INV-WATCHDOG-SELF-001 framework 级监控自观察 (用户深问"为什么静默失败不提前告警"驱动)** — ① **触发**: V37.9.58-hotfix2 commit 后用户反馈"今天定时任务推送只收到 HN+HF, 其他 5 个没有"+ 深问"这是静默错误为什么不提前告警". 按原则 #28 三问严格诊断: Mac Mini `cat ~/.openclaw/jobs/*/cache/last_run.json` + `ls /tmp/*.lockdir` + `tail ~/job_watchdog.log` 揭示 4 lockdir 残留 (hf_papers/s2/rss_blogs/github_trending, 残留 5h-45h) + watchdog log 从 5/5 16:30 起**只有 heartbeat 没有 ALERT** (累积 28 次 cron 跑全部 silent). 手动跑 `bash ~/job_watchdog.sh` 立即暴露真因: `awk: towc: multibyte conversion failure on: '?'` exit 1 + `set -eo pipefail` + 无 ERR trap = watchdog 整脚本 abort exit 2. ② **完整因果链 (silent 7 天)**: 5/5 16:30 某 log 写入含无效 UTF-8 字节 (V37.8.6 surrogate 类 / X tweet 特殊字符) → macOS bsd awk `tail -200 \| awk` 处理时 `towc multibyte` exit 1 → `pipefail` 让 pipe exit 1 → `set -e` 让 watchdog 整脚本 abort exit 2 → 仅 heartbeat 一行 + awk error stderr 写到 log → 没 ERR trap 主动告警 → cron 不发邮件 → **用户视角 7 天未感知**. 累积影响: 4 lockdir 残留 (没人清), MOVESPEED 24h 21 次 rsync 失败累积告警 (没推送), SLO p95 54s 严重超阈值 (没推送), KB 摘要 29h 未更新 (没推送) — **全部 silent**. ③ **V37.9.58-hotfix3 治本三层 + 框架级 5 项扩展**: **Step A** (核心修): `line 264` awk pipe 加 `LC_ALL=C` 前缀 + `2>/dev/null \|\| true` 容错防 set -e abort. **Step B** (主动告警): 顶部装 `_watchdog_fatal_handler($LINENO)` ERR trap handler 推 `[SYSTEM_ALERT] watchdog FATAL exit=N line=N — 监控自身死亡! 5/5-5/12 silent 7 天血案防回归` 到 Discord. **三层 FAIL-OPEN fallback**: notify 函数 → openclaw 直发 → 本地 .openclaw_alerts.log 写入. **Step C** (元监控): `_watchdog_exit_handler()` 合并 rmdir + canary heartbeat — 正常完成时写 `~/watchdog_canary.json` (含 last_completed/checks/alerts) + ALERTS=0 时推 `✅ [watchdog alive @ HH:MM]` 到 Discord. 让 watchdog 自身死活可被外部检测 (12h 没收到 alert 也没收到 canary → watchdog 死了). **Step D** (监控覆盖补齐): STALE_LOCK_DIRS 加 5 个 jobs (`rss_blogs / github_trending / ai_leaders_x / finance_news / ontology_sources`) — 5/12 诊断发现 rss_blogs.lockdir 残留 45h 实证不在监控列表. **Step E**: `governance INV-WATCHDOG-SELF-001` (meta_rule=MR-19, severity=critical, layer=[declaration, runtime], **12 checks**): 11 declaration (awk LC_ALL=C / 容错 `|| true` / _watchdog_fatal_handler / trap ERR / [SYSTEM_ALERT] / watchdog_canary.json / 'watchdog alive' / rss/gh/ai_leaders STALE 补齐 / V37.9.58-hotfix3 marker) + 1 runtime (subprocess 跑 test_watchdog_self_monitoring 全套). **Step F**: 立 **MR-19** `monitor-must-self-alarm-on-silent-abort` (governance_ontology.yaml meta_rules 段): 任何 silent failure 监控工具必须三契约 — awk_safe + err_trap_handler + canary_writer. 关联 MR-4 (silent-failure 元层) + MR-7 (治理自观察) + MR-17. derivative_invariants=[INV-WATCHDOG-SELF-001]. blood_lessons 详记 V37.9.58-hotfix3 完整因果链 + Q1/Q2/Q3 三问. ④ **test_watchdog_self_monitoring.py (29 单测 / 7 测试类)**: TestStepAAwkMultibyteSafety(3 含 LC_ALL=C 字面量 + `|| true` regex + V37.9.58-hotfix3 注释) + TestStepBErrTrapSilentAbortBecomesLoud(5 含 handler 函数定义 + trap ERR 注册 + [SYSTEM_ALERT] 推送 + 三层 FAIL-OPEN fallback + 血案引用) + TestStepCCanaryHeartbeat(6 含 _watchdog_exit_handler + trap EXIT + canary 文件 + alive 推送 + exit=0 守卫 + JSON 字段完整性) + TestStepDStaleLockListCompleteness(5 含 rss_blogs/github_trending/ai_leaders_x/finance_news/ontology_sources 字面量) + TestWatchdogSyntaxAndIntegration(3 含 bash -n + set -eo pipefail 保留 + trap ERR 必须在 set -e 之后) + **TestReverseVerificationGuardsAreReal(3 反向验证)**: sabotage 移除 LC_ALL=C → 守卫立即 fail / sabotage 移除 trap ERR → 守卫立即 fail / sabotage 移除 canary → 守卫立即 fail (subprocess 真跑各测试类). 还原后全过. + TestGovernanceLinkage(4 含 MR-19 立案 + INV-WATCHDOG-SELF-001 立案 + meta_rule 引用 + audit_metadata v3.38). ⑤ **接入 + audit_metadata**: full_regression.sh +1 suite `watchdog_self_monitoring` 紧随 V37.9.58-hotfix2. audit_metadata version 3.37→3.38 + total_invariants 73→74 (+1 INV-WATCHDOG-SELF-001) + total_checks 570→582 (+12) + meta_rules 18→19 (+1 MR-19). ⑥ **累计**: 79→80 suites (+1) / 2704→2733 tests (+29) / 0 fail / governance v3.37→v3.38 / 73→74 invariants / 570→582 checks (+12) / 18→19 meta rules / 安全 95/100 / VERSION 0.37.9.58 不变 (hotfix 不 bump). ⑦ **元价值 — 今日四件套闭环 (一日内 V37.9.58 主+hotfix+hotfix2+hotfix3 四个版本)**: 每个版本都把 silent failure 向上一层抽象修. **V37.9.58 主交付**: machine_sync 真激活 (业务自动同步). **V37.9.58-hotfix**: 业务层 silent (8 jobs NameError 不推送). **V37.9.58-hotfix2**: 治理层 silent (MR-18 + scanner framework 预防). **V37.9.58-hotfix3 (本)**: 监控层 silent (MR-19 + watchdog 自观察). 最深层 — **监控自身死活监控**. V3 路标 `pip install ontology-engine` 终极目标的核心交付之一. MR-19 让"watchdog 自身死亡 7 天无人发现"从靠运维记忆升级为机器化主动告警 + canary 双层防御. ⑧ **Mac Mini 部署后预期行为**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.58-hotfix3 (b) **手动清 4 个残留 lockdir** (rss_blogs/github_trending/hf_papers/semantic_scholar) — V37.9.58-hotfix3 部署后下次 watchdog cron (16:30/20:30) 真激活 STALE 检测时会自动清, 但用户可立即手动清让今晚 18:00+ cron 能跑 (c) 下次 watchdog cron (16:30) 应跑全 8 维度 + 推大量累积告警 (MOVESPEED/SLO/KB 摘要等) (d) 推送 ALERT 后 ALERTS 重置, 之后每次正常 cron 推 canary 'alive' 到 Discord (e) 如未来 watchdog 再因新 silent bug abort → ERR trap 主动推 [SYSTEM_ALERT] 立即可见. ⑨ **下次 V37.9.59+ 候选**: (a) **观察期**: 今晚 16:30 / 20:30 / 明早 08:30 watchdog cron 真激活效果 (推送 canary alive + 累积告警) (b) **`ontology/docs/cases/watchdog_silent_abort_case.md`** 完整四维度因果链案例文档 (V37.9.58-hotfix3 立案后补) (c) **扫所有 cron 类监控脚本** (preflight_check.sh / governance_audit_cron.sh / wa_keepalive.sh) 是否都满足 MR-19 三契约 (d) **trap unlock 8 ALIGNED jobs 普遍不执行 bug** (V37.9.58-hotfix3 候选未修, hf_papers 10:00 推送成功但 lockdir 仍在的现象) — 候选方案 A mkdir 失败时 mtime ≥ 1h 自动清+重试 (e) **ai_leaders X HTTP 429 全部 19 账号** — 5/12 09:00 实测, IP/UA/时间窗口级 ban 调查 + UA 轮换 + backoff (V37.9.59 候选). |
| V37.9.58-hotfix2 | 2026-05-12 | **治理债清零 — MR-18 立案 + INV-HEREDOC-IMPORT-001 framework 级 import 一致性 scanner (V37.9.58-hotfix 反思转化为机制)** — ① **触发**: 用户问"为什么本次错误不应该发生" — V37.9.50-hotfix → V37.9.58-hotfix 同款 import 缺漏 8 天间隔重演证明"单点修复 + 不立元规则 + 不加 framework 守卫" = 必然 MR-4 第 N 次演出. 反思路径：单点 hotfix 是治标，立 framework 级预防才是治本. ② **新文件 heredoc_import_scanner.py** (~280 行纯 Python AST scanner, 零外部依赖): `extract_heredocs` 提取所有 .sh 中 `<< 'PYEOF' ... PYEOF` heredoc body + 行号 + `collect_imported_names` (ast.Import / ast.ImportFrom 含 alias / 子模块 binding `import os.path` → os) + `collect_locally_defined_names` (FunctionDef/AsyncFunctionDef/ClassDef + 函数参数/lambda 参数/Assign/AugAssign/AnnAssign/For/AsyncFor/With/AsyncWith/ExceptHandler/NamedExpr 海象/comprehension/Global/Nonlocal) + `collect_referenced_names` (Name Load + Attribute root chain) + `scan_heredoc_imports` (referenced - imported - defined - builtins = missing) + `scan_repo` 整 repo scan + main CLI `--scan-all` / `--file` / FAIL-CLOSE exit 1 on violation. **FAIL-CLOSE 契约**: 找到任一 violation 必须 exit 1, scanner 自身无法 AST 解析 silently skip 不算 violation 但 verbose 日志 (避免 false positive). ③ **dev scan 立即真有效证据 — 抓出 V37.9.58-hotfix 遗漏的 2 个 LEVEL_2 jobs**: `finance_news/run_finance_news.sh:631` + `ontology_sources/run_ontology_sources.sh:236` 同款 V37.9.57 LEVEL_2 注入 `prompt += os.environ.get('HG_GUARD_TEXT')` 但 heredoc 顶部 `import sys, json, re` 缺 os. scanner 立即抓到 + 修复 + 复扫 0 violations. 还 1 个 false positive (`__import__` builtin 漏豁免) 同时修, 加入 `_PYTHON_BUILTINS` 集合. ④ **MR-18 立案** `auto-batch-injection-must-validate-runtime-semantics` (governance_ontology.yaml meta_rules 段): 任何自动批量改多文件工具必须满足三层契约 — (a) 注入前 dry-run AST 解析 (b) 注入后 semantic validation (c) 失败整批 rollback. 核心论断 "自动批量工具是 bug 放大器" — 单点设计错误立即传播到 N 文件, `bash -n` 永远查不到 Python heredoc 内部 NameError. 元规则关联 MR-4 (silent-failure 上游预防) + MR-6 (critical 需 ≥2 层) + MR-8 (copy-paste-is-a-bug-class 自动版本) + MR-10 (understand-before-fix). 实施路径 Step 1 (V37.9.58-hotfix2) heredoc_import_scanner / Step 2 (V37.9.59+) inject 工具自治化 / Step 3 (V3 路标) ontology-engine pip 包暴露 batch_injection_validator. derivative_invariants=[INV-HEREDOC-IMPORT-001]. blood_lessons 详记 V37.9.50/58-hotfix 谱系. ⑤ **INV-HEREDOC-IMPORT-001** `heredoc-python-imports-must-cover-all-referenced-modules` (meta_rule=MR-18, severity=critical, verification_layer=[declaration, runtime], **5 checks**): declaration 4 (scanner 函数定义 + FAIL-CLOSE 契约 + V37.9.50-hotfix 血案引用 + 单测 TestRepoScanIntegration 类) + runtime 1 (python_assert subprocess 跑 scanner --scan-all 必须 exit 0 = 0 violations). ⑥ **test_heredoc_import_scanner.py** (33 单测 / 6 测试类): TestExtractHeredocs(4 含 unclosed/non-PYEOF skip) + TestCollectImportedNames(4) + TestCollectLocallyDefinedNames(5) + TestCollectReferencedNames(2) + TestScanHeredocImports(7 含 **V37.9.50 + V37.9.58-hotfix 双血案重现** + builtin / 本地定义 / __import__ dynamic / AST parse error 豁免) + **TestRepoScanIntegration(3 含端到端 0 violations + 反向验证 sabotage run_hn_fixed.sh 移除 import os → scanner 立即抓到 missing ['os'] 含 stderr 含 file path 还原 4/4 全过)** + TestCliBehavior(3 含 --help / --file clean / --file violation) + TestSourceLevelGuards(5 V37.9.58-hotfix2 marker + V37.9.50-hotfix lineage + MR-18 引用 + FAIL-CLOSE 契约 + INV-HEREDOC-IMPORT-001 引用). ⑦ **接入**: full_regression.sh +1 suite `heredoc_import_scanner` 紧随 V37.9.58-hotfix 后. audit_metadata 升级 version 3.36→3.37 + total_invariants 72→73 (+1) + total_checks 565→570 (+5) + meta_rules 16→18 (修 V37.9.19 立 MR-17 时漏更新 + 加 MR-18). ⑧ **累计**: 78→79 suites (+1) / 2671→2704 tests (+33) / 0 fail / governance v3.36→v3.37 / 72→73 invariants / 565→570 checks (+5) / 17→18 meta rules / 安全 95/100 / VERSION 0.37.9.58 不变 (hotfix 不 bump). ⑨ **元价值 (反思转化为机制)**: V37.9.58-hotfix 是治标 (单 session 修 8 jobs broken push), V37.9.58-hotfix2 是治本 (立 framework 级预防 + 主动监控). 用户的"为什么本次错误不应该发生"质问驱动: (1) V37.9.50-hotfix 教训没转化为 framework 预防 → V37.9.58-hotfix 重演 (2) 自动批量工具是新 bug 类 → 立 MR-18 (3) scanner 必须 FAIL-CLOSE 主动监控而非 FAIL-OPEN 被动等下次血案. 这是 V3 路标 `pip install ontology-engine` 核心交付 — declarative governance framework 真正进化方向是"用机器化契约取代记忆维护成本". ⑩ **Mac Mini 部署后预期**: (a) git fetch + reset 同步 V37.9.58-hotfix2 (b) 下次 governance_audit_cron (每日 07:00) 自动跑 INV-HEREDOC-IMPORT-001 runtime check, 整 repo 0 violations 则零告警 (c) 任何未来 ALIGNED jobs 或新增 heredoc 引入 import 缺漏 → governance audit 立即抓到 + Discord #alerts 告警, 不再等用户视角发现 (d) inject_level_4_to_aligned_jobs.py 等批量工具下次使用前应先调 scanner --file dry-run (V37.9.59 候选: 自治化). ⑪ **下次 V37.9.59 候选**: (a) inject_level_4_to_aligned_jobs.py 自治化 (注入前后内嵌 scanner check + 失败整批 rollback) (b) 同款 audit 扩展: 扫所有 jobs 是否还有其他批量注入跨多 jobs 但漏 import 的盲点 (c) governance audit cron 集成 INV-HEREDOC-IMPORT-001 主动告警 (Mac Mini 真生效一周后立 INV-AUTO-INJECT-001 上游守卫) (d) Mac Mini V37.9.58 + V37.9.58-hotfix + V37.9.58-hotfix2 全量真激活验证 (一周观察期). |
| V37.9.58-hotfix | 2026-05-12 | **V37.9.57 自动注入工具盲点 — 8 ALIGNED jobs HG_LEVEL_4_TEXT 注入未补 import os 系统性 NameError 血案修复 (与 V37.9.50-hotfix 同款 fix 但 V37.9.57 引入第二处缺漏)** — ① **用户视角发现 (原则 #13 第 18 次正向兑现)**: 用户 WhatsApp 收到 HN 14:45 cron 推送格式异常 — 5 条都是仅 `*英文标题*` + `链接: ...` + `---`, 完全无 V37.9.51 的 6 字段 (📌中文标题/🔑核心要点/💡技术深度/🎯实践启发/⭐评级/🎚️项目对齐度) + 末尾`高对齐 0/5 条`虚假 0 统计. 立即反馈"格式不对"启动诊断. ② **取证 (原则 #28 三问严格执行)**: Mac Mini `tail ~/.openclaw/logs/jobs/hn_watcher.log` 揭示 `Traceback ... NameError: name 'os' is not defined line 70 in <stdin>` × 5 次 (5 条 LLM 调用全部炸) + `[hn] LLM 调用完成: 成功 5/5` 误报 (retry 把 NameError 当成空 content 返回成功) + `[hn] 消息组装: 5 条 (LLM 解析成功 0, degraded 0, 高对齐 0, sent 5)` (parse_6field_output("") 全空 → fallback 用原 title). ③ **真因**: V37.9.57 `inject_level_4_to_aligned_jobs.py` 自动给 8 个 ALIGNED jobs 的 LLM call heredoc (prompt-generation 段, run_hn_fixed.sh line 282 起) 末尾加了 `prompt += os.environ.get('HG_LEVEL_4_TEXT', '')` 但**没补 `import os`**. V37.9.50-hotfix 修过另一处 emit heredoc (line ~388) 补 os, 但 V37.9.57 在 prompt-generation heredoc (line ~282 在 emit 之前) 引入第二处 os 调用未同步补齐. 7/8 jobs 都有同款 bug (只 HN-specific run_hn_fixed.sh 因 V37.9.51 prompt heredoc 起点已含 re 字段巧合不同, 但 V37.9.57 注入后同样缺 os). ④ **三问全过**: Q1 之前存在? ✗ (V37.9.57 之前 prompt heredoc 不调 os.environ) / Q2 我引入? ✓ (V37.9.57 inject 工具系统性) / Q3 最小修复 = 7 个 jobs heredoc 顶部 `import sys, json` → `import sys, json, os` (V37.9.50-hotfix 同款一字不差). ⑤ **批量修复 + 验证**: Python 自动定位每个 jobs 含 `prompt += os.environ.get('HG_LEVEL_4_TEXT'` 的 prompt-generation heredoc, 验证 import line `startswith("import sys, json")` 后插入 `, os` + 行尾 V37.9.58-hotfix marker 注释. 7/7 修复 + 8/8 全部含 os 验证 + bash -n 语法全过. **修复清单**: run_hn_fixed.sh:283 (此前手动 fix) + hf_papers:373 + arxiv:342 + semantic_scholar:328 + dblp:335 + github_trending:328 + rss_blogs:322 + ai_leaders_x:347. ⑥ **`test_v37_9_58_hotfix.py` 4 tests source-level 守卫** (机器化检测 V37.9.57 注入工具盲点): TestV37958HotfixOsImport.(test_v37_9_57_injection_present_in_all_8_jobs 8 jobs 都含 HG_INJECTION 字面量 / test_every_hg_injection_heredoc_has_os_import_at_top 核心守卫 — 每个含 HG 注入的 heredoc 顶部必须含 `import os` (无论组合形式, regex `\bos\b` 在 code 部分检查跳过注释) / test_hn_specific_fix_at_line_283 锁定 HN line 283 / test_v37_9_58_hotfix_marker_in_at_least_one_fix 至少一个修复点含 marker). **反向验证已确认守卫真有效**: sabotage run_hn_fixed.sh line 283 移除 os → test_every_hg_injection_heredoc_has_os_import_at_top 立即 fail + 错误信息精确定位"run_hn_fixed.sh: heredoc@line 282 import line 283 = 'import sys, json, re'", 还原后 4/4 全过. ⑦ **接入**: full_regression.sh +1 suite `v37_9_58_hotfix` 紧随 V37.9.57 hallucination_guards 之后. ⑧ **累计**: 77→78 suites (+1) / 2667→2671 tests (+4) / 0 fail / governance v3.36 不变 / VERSION 0.37.9.58 不变 (hotfix 惯例不 bump) / 安全 95/100. ⑨ **Mac Mini 部署后预期** (用户视角验证): (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.58-hotfix (b) 下次 cron 触发 (HN 20:45 / hf_papers 20:00 / arxiv 每 3h / s2/dblp 明日) 推送应**首次出现** 6 字段格式 (📌中文标题 + 🔑核心要点 + 💡技术深度解读 + 🎯实践启发 + ⭐评级 + 🎚️项目对齐度) + 末尾`本轮高对齐 X/Y 条`真统计 (不再是虚假 0). (c) 用户视角原则 #13 第 18 次正向兑现的硬实证. ⑩ **元教训 — MR-4 silent-failure 第 N 次演出新形态**: 自动批量注入工具引入跨多 jobs 系统性 bug — 单次 fix HN 但需要 source-level 守卫 7 个其他 jobs 才真闭环. V37.9.50-hotfix (修一个) → V37.9.58-hotfix (8 个同款 batch 修复 + 守卫). V37.9.57 自动注入工具是 framework 进化方向但 lint check 缺失 → 引入新 bug 类. **MR-10 understand-before-fix 兑现**: 不只修 HN 一个症状, 取证 → 扫所有同 pattern → 批量修复 + 加守卫防回归. ⑪ **下次 V37.9.58-hotfix2 候选 (a) 部署观察验证 cron 真生效 (b) inject_level_4_to_aligned_jobs.py 加 lint check (注入 os.environ 前先检 heredoc 顶部是否含 import os, 没有则拒绝注入) — 让自动注入工具自治 (c) INV-V37958-HOTFIX-001 governance 一周观察后立 (d) 同款 audit: V37.9.57 是否还有其他 batch 注入跨多 jobs 但漏 import 的盲点 (扫所有 jobs heredoc 内调用的库 vs heredoc 顶部 import 一致性). |
| V37.9.58 | 2026-05-12 | **Plan B 渐进 escalation 终态兑现 — machine_sync 真激活 (5/3-5/11 一周观察期零漂移, V37.9.23/24 收工承诺兑现)** — ① **触发**: V37.9.23 (5/3) jobs_to_crontab drift_action alert_only → machine_sync + 默认 dry-run 上线; V37.9.24 (5/4) named-dispatch 重构 + kb_sources_to_index 同款升级. yaml meta 收工承诺明确登记 "V37.9.24+ (一周后): 切关 CONVERGENCE_DRY_RUN 默认 → 真激活 machine_sync". 一周累积观察期 (5/3-5/11) 数据: jobs_to_crontab declared=36 observed=36 / kb_sources_to_index declared=14 observed=14, 双 spec 全周零漂移零误报零告警, 兑现 Plan B 渐进路径终态. ② **scope (用户决策"立即激活")**: V37.9.58 = `convergence.py::_is_dry_run()` 默认值反转 + yaml 两 spec `dry_run_default: true → false` + meta version 0.7 → 0.8-machine-sync-activated + governance INV-CONVERGENCE-CRON-001 守卫 V37.9.58 升级 + 测试 alternation + 新单测类反向验证. **不引入新功能** — V37.9.23/24 已铺好路径, V37.9.58 仅是 default flip. ③ **convergence.py `_is_dry_run()` 默认值反转** (核心改动 1 行): 旧 `os.environ.get(_DRY_RUN_ENV_VAR, "1") != "0"` (默认 True / 任何非 "0" 字面量都 dry-run, typo→保守) → 新 `os.environ.get(_DRY_RUN_ENV_VAR, "0") == "1"` (默认 False / 仅 "1" 字面量 dry-run, typo→兑现 escalation). **typo-safe direction 反转**: 旧 V37.9.23 默认行为最保守 (任何错误都不动 crontab), 新 V37.9.58 默认行为兑现承诺 (escalation 已经过一周观察期). docstring 升级解释 escalation 兑现 + V37.9.23 历史引用. ④ **yaml 配置同步** (`ontology/convergence_ontology.yaml`): (1) jobs_to_crontab spec `dry_run_default: true → false` + 注释 "V37.9.58 切关 escalation 兑现 (5/3-5/11 一周观察期零漂移, 5/12 切关)" (2) kb_sources_to_index spec 同款 (3) meta version `0.7-fifth-spec-services-to-launchd → 0.8-machine-sync-activated` + status `framework_*_dry_run → framework_*_activated_dry_run_default_off` (4) **加 v37_9_58_changelog 段** 记录完整 Plan B 三阶段时间线 (V37.9.19 alert_only → V37.9.23/24 machine_sync+dry_run → V37.9.58 切关 dry_run 默认) + 一周观察期数据 + typo-safe 反转分析 + MR-17 真正兑现 + Mac Mini 部署预期行为 + 30 秒回滚预案 (cron 加 `export CONVERGENCE_DRY_RUN=1` 或 git revert). ⑤ **governance INV-CONVERGENCE-CRON-001 守卫升级** (3 新 declaration checks): (1) yaml `dry_run_default: false` 字面量守卫 (替代旧 `: true`) (2) convergence.py `_is_dry_run()` 默认值 regex 守卫 `os.environ.get\(_DRY_RUN_ENV_VAR, "0"\) == "1"` (3) v37_9_58_changelog 段守卫 (4) meta version 0.8 守卫. 另外升级 INV-CONVERGENCE-KB-001 + INV-CONVERGENCE-SERVICES-001 的 meta version alternation 接受 0.8. audit_metadata version 3.35 → 3.36 + v3.35→v3.36 changelog 记录终态兑现. ⑥ **测试反转 + alternation** (`test_convergence.py`): (1) TestIsDryRun 5 个测试 (`test_unset/test_value_zero/test_value_true/test_empty_string` 反转为 real apply, 仅 `test_value_one_keeps_dry_run` 保留) — 反映 typo-safe 反转 (2) `TestRealJobsToCrontabSpec::test_real_spec_completes_without_raising` 期望 `apply_dry_run=False` (默认 real apply) + action 前缀接受 `applied:` (real apply) 或 `DRY-RUN would apply:` (显式 dry-run) alternation (3) 3 处 yaml `dry_run_default: true → false` 字面量守卫反转 (4) 2 处 meta version `0.6-0.7` alternation 扩展加入 `0.8-machine-sync-activated`. ⑦ **新单测类 TestV37958DryRunActivation** (14 tests, 7 分类): (1) 3 个源码字面量守卫 (V37.9.58 marker / escalation docstring / `os.environ.get(..., "0") == "1"` 字面量) (2) 1 个反向验证守卫 (防回退 V37.9.23 旧默认 `!= "0"` 反模式) (3) 2 个 yaml `dry_run_default: false` 守卫 (jobs_to_crontab + kb_sources_to_index 两 spec) (4) 4 个 yaml meta 守卫 (version 0.8 + status activated + v37_9_58_changelog 段存在 + 段内含 escalation/5/3/5/11/零漂移/MR-17 关键字) (5) 2 个 governance INV 守卫 (INV-CONVERGENCE-CRON-001 V37.9.58 markers + audit_metadata v3.36) (6) 3 个端到端 (默认无 env → apply_dry_run=False 真激活 / 显式 CONVERGENCE_DRY_RUN=1 → 仍可回到 dry-run / kb_sources_to_index 同款默认 real apply). **反向验证已确认守卫真有效**: sed 把 `os.environ.get(_DRY_RUN_ENV_VAR, "0") == "1"` 改回 `!= "0"` → 4 个 V37.9.58 测试立即失败 (含 test_is_dry_run_default_reversed_to_v37_9_58 字面量守卫 + 3 个 e2e 真激活契约), 还原后 256/256 全过. ⑧ **MR-17 真正兑现** (declared-state-must-converge-to-runtime-via-machine-not-memory): V37.9.19 起步 alert_only (机器**可检测**) → V37.9.23/24 machine_sync + 默认 dry-run (机器**可同步**但不默认同步) → **V37.9.58 切关 dry-run 默认 (机器可同步且默认同步)** ← 终态. Plan B 三阶段路径完整闭环, 从"声明→运行时同步靠 Claude Code 记忆"升级为"机器自动同步", 这是 V3 路标 `pip install ontology-engine` 终极目标的关键里程碑兑现. ⑨ **Mac Mini 部署后预期行为**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.58 (b) 下次 governance audit cron 跑 (`python3 ~/ontology/governance_checker.py --full` 每日 07:00 + 任何手动触发): 若 jobs_to_crontab missing=0 / kb_sources_to_index missing=0 → 零操作 (符合一周观察期数据预期), framework 仅日志记录 "DRIFT action=machine_sync missing=0 apply=0"; 任一 spec 漂移 → 立即真同步, 不再 dry-run 等待 (c) crontab_safe.sh add (V37.9.18 加固后 idempotent + safe) 真调用; kb_embed.py 默认增量 (mtime diff) 真调用 (d) operator 可显式 `CONVERGENCE_DRY_RUN=1` 临时回到 dry-run 观察模式. ⑩ **回滚预案 30 秒**: governance_audit_cron.sh 头部加 `export CONVERGENCE_DRY_RUN=1` 恢复 dry-run / git revert V37.9.58 commit 完全回退. crontab 已用 V37.9.18 加固后的 idempotent helper, 无需 crontab 恢复操作. ⑪ **累计**: 77 suites 不变 / 2651 → 2667 tests (+16: TestV37958DryRunActivation 14 + 2 V37.9.23/24 alternation alignment) / 0 fail / governance v3.35 → v3.36 / 72 invariants 不变 (INV-CONVERGENCE-CRON-001 内涵升级非新增) / 562 → 565 checks (+3 V37.9.58 markers) / 17 meta rules / 安全 95/100 / VERSION 0.37.9.57 → 0.37.9.58. ⑫ **元价值**: V37.9.58 不是新功能, 而是 Plan B 渐进 escalation 路径的**终态兑现**. 三个 V37.9.x 版本 (V37.9.19 alert_only 起步 / V37.9.23 machine_sync+dry_run / V37.9.58 切关 dry_run 默认) 形成完整闭环, 证明"通过 dry-run 阶段验证 + 一周观察期 + 数据驱动决策 + 用户授权后真激活"是高 blast-radius 操作的可靠路径。下次 V37.9.59+ 候选: (a) Mac Mini 部署后下次 governance audit 真激活效果观察 (b) 一周真激活后立 INV-CONVERGENCE-ACTIVATED-001 守卫 "default real apply 不可回退" 锁定终态 (c) services_to_launchd (V37.9.25 alert_only) 是否进入 Plan B 升级路径评估 (d) SLO p95 严重超阈值调查 (V37.9.58 候选已登记 → V37.9.59) (e) LEVEL_6 反幻觉守卫 sub-agent / multi-agent dispatch 场景. |
| V37.9.57 | 2026-05-12 | **架构级公共反幻觉守卫模板 + 9 task 全量接入 — MR-8 single-source-of-truth + MR-7 治理自观察兑现 (V37.9.56-hotfix3 血案的真正结构性修复)** — ① **触发**: V37.9.56-hotfix3 修了 kb_evening "OpenClaw 社区发布 v26" 幻觉血案 (原则 #23 链式幻觉典型实证), 但全面审计 9 task 风险矩阵 (Explore agent 完成) 发现同款风险存在于 kb_dream Reduce / 8 ALIGNED jobs (hf/s2/dblp/arxiv/gh/rss/ai_leaders/hn) / kb_review / kb_deep_dive / freight / finance / ontology_sources. 单点修复 evening 等于把同一反幻觉 bug fix 留给每个 task 各自维护 (MR-8 反例 copy-paste-is-a-bug-class). ② **scope (用户决策 "一次性 batch 全量接入 9 task")**: V37.9.57 立公共反幻觉守卫模板 + 9 task 全量集成. 不是"加 1 个 hotfix4"而是"立架构契约 + 横向部署". ③ **新文件 `hallucination_guards.py`** (~250 行, 纯 stdlib 零外部依赖): 5 档严格度模板按场景累积式设计 — (a) **LEVEL_1_MINIMAL**: 仅"严禁虚构" (kb_harvest_chat 闭环数据) (b) **LEVEL_2_STANDARD**: + 来源标签校验 (freight/finance/ontology 单源新闻) (c) **LEVEL_3_STRICT**: + 反链式推论 "X 段提到 Y → 推论 Z" 模式禁止 (kb_review 跨域回顾 + kb_deep_dive 单 paper 全文) (d) **LEVEL_4_PROJECT_AWARE**: + V37.9.56-hotfix3 具体血案字面禁令 (8 ALIGNED jobs 含"OpenClaw 社区发布"/"v26"/"v26/v27/v37 版本更新"/"项目里程碑"/"开源 X 上线"/"[openclaw]" 6 个精确字眼) (e) **LEVEL_5_RADAR_AWARE**: + Opportunity Radar 三件套信号源契约 (kb_dream Reduce + kb_evening, Top 5/cross_source/trend 显式声明"跨多天累积非今日事件" + 反链式 "paper 提到 OpenClaw → 本项目必有相关动态"). **公开 API**: `get_guard(level)` 返回守卫文本块, `list_levels()` / `get_blocked_phrases()` / `get_radar_signal_types()` 辅助查询. **未知 level fallback LEVEL_3_STRICT** 安全中位数. **CLI**: `python3 hallucination_guards.py --list` / `--blocked-phrases` / `--level LEVEL_X` 调试. ④ **`test_hallucination_guards.py`** (38 单测 / 7 类): TestGuardLevels(8 含 5 档累积式 + V37.9.57 marker + LEVEL_N 不含 LEVEL_(N-1) 之外特性) + TestGetGuardAPI(6 默认/未知/None/非string fallback) + TestBloodLessonBlockedPhrases(5 V37.9.56-hotfix3 5 个核心字眼必须在 LEVEL_4+) + TestRadarSignalTypes(3 三件套必须在 LEVEL_5 + 不在 LEVEL_4) + TestCliInterface(4 subprocess --list/--blocked-phrases/--level) + TestSourceLevelGuards(9 V37.9.57 marker / V37.9.56-hotfix3 lineage / GUARDS dict 5 key locked / _DEFAULT_FALLBACK 锁 LEVEL_3 / MR-8 documented) + TestV37957Contracts(2 模块顶部 import / 无外部依赖). **反向验证两层守卫真有效**: (a) sabotage `_LEVEL_4_PROJECT_AWARE = """..."""` 整段赋空 → 4 failures (test_blocked_phrases_in_level_4 + test_level_4_contains_level_3_core + 等) (b) sabotage `_DEFAULT_FALLBACK_LEVEL = "LEVEL_3_STRICT"` 改 LEVEL_5 → test_default_fallback_is_level_3 立即 fail (c) sabotage LEVEL_5 整段赋空 → 4 failures, 还原后 38/38 全过. ⑤ **9 task 全量集成**: **kb_evening_collect.py** (LEVEL_5) 替换 V37.9.56-hotfix3 inline 反幻觉守卫为 `from hallucination_guards import get_guard` + `{get_guard("LEVEL_5_RADAR_AWARE")}` f-string interpolation. V37.9.56-hotfix3 测试 2 处升级接受 V37.9.57 LEVEL_5 wording (语义等价, 字面迁移). **kb_dream.sh** (LEVEL_5) Reduce prompt 头部 `DREAM_HG_GUARD=$(python3 -c "...sys.path...; import hallucination_guards as hg; print(hg.get_guard('LEVEL_5_RADAR_AWARE'))" 2>/dev/null)` + REDUCE_SYSTEM 末尾 append `${DREAM_HG_GUARD}`, 与 V37.8.6 反污染守卫互补 (互补层: V37.8.6 防错误日志被当外部信号 / V37.9.57 防项目动态 + Radar 信号源混淆). **8 ALIGNED jobs** (LEVEL_4 — hf_papers/s2/dblp/arxiv/github_trending/rss_blogs/ai_leaders_x/hn) 用 inject_level_4_to_aligned_jobs.py 批量注入: shell 顶部 `HG_LEVEL_4_TEXT=$(python3 -c "..." 2>/dev/null) + export` + Python heredoc prompt 末尾 `prompt += os.environ.get('HG_LEVEL_4_TEXT', '')`. run_hn_fixed.sh 自动检测插入点失败手动补全 (NOTIFY_SH 加载块之后插入). **freight + finance + ontology jobs** (LEVEL_2) 用 inject_levels_batch.py 批量, freight 因 prompt 走 PROMPT="..." stdin 模式手动补 `${HG_GUARD_TEXT}` interpolation 到 PROMPT 末尾. **kb_review_collect.py + kb_deep_dive.py** (LEVEL_3) 顶部 `from hallucination_guards import get_guard` + 三个 build_*_prompt 函数末尾 `{get_guard("LEVEL_3_STRICT")}` (build_prompt / build_full_text_prompt / build_abstract_only_prompt). ⑥ **集成验证**: 8 ALIGNED jobs `bash -n` 全过 syntax check + HG_LEVEL_4_TEXT shell var 注入 + Python heredoc `prompt += os.environ.get` 注入。kb_evening build_evening_prompt 真渲染输出含 LEVEL_5 守卫 + "OpenClaw 社区发布" 血案字眼 + "Opportunity Radar" 信号源契约. ⑦ **接入**: auto_deploy.sh FILE_MAP 加 `hallucination_guards.py|$HOME/...` (跨 9 task 部署到 Mac Mini) + full_regression.sh 加 `hallucination_guards (V37.9.57 公共反幻觉守卫 5 档模板)` suite. ⑧ **MR-8 single-source-of-truth 兑现**: 公共守卫模板, 不同 task 共享同款守卫文本, 无 copy-paste 漂移. 未来加新 LLM task 只需 `from hallucination_guards import get_guard` + 调 `get_guard(LEVEL_X)`, 自动获得最新反幻觉守卫. 修改守卫文本一处, 9 task 自动 propagate. ⑨ **MR-7 治理自观察兑现**: V37.9.56-hotfix3 评论"测试三层契约 + 用户视角观察是 framework 价值的硬实证"延续 — V37.9.57 把"反幻觉守卫覆盖"从"靠记忆维护"升级为"机器化检查" (TestSourceLevelGuards 9 个守卫 + V37.9.57 marker + V37.9.56-hotfix3 lineage 可追). ⑩ **累计**: 76→77 suites (+1: hallucination_guards) / 2613→2651 tests (+38 hallucination_guards 单测) / 0 fail / VERSION 0.37.9.56 → 0.37.9.57 / 安全 95/100. ⑪ **Mac Mini 部署后预期行为**: (a) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` 同步 V37.9.57 (b) `bash ~/restart.sh` 不需要 (hallucination_guards.py 是模块, 9 task 在 next cron 触发时自动加载) (c) 22:00 kb_evening cron 推送 `evening_20260513.md` 不再含 V37.9.56-hotfix3 血案字眼编造 + Top 5 段语义重定位为"近期高对齐参考阅读 Top 5 (V37.9.56 #2, ⭐≥4 项目对齐度, 跨多天累积)" + LLM 看到 LEVEL_5 守卫含明确字面禁令 ("OpenClaw 社区发布"/"[openclaw]"等) 立即识别为禁止输出字眼. (d) 03:00 kb_dream Reduce cron 推送的"梦境"段保留 V37.8.6 反污染守卫 + 加 V37.9.57 LEVEL_5 反项目动态编造 + Radar 信号源契约 = 双层防御覆盖. (e) 10:00/20:00 hf_papers + 11:00 s2 + 12:00 dblp + 14:00 github_trending + 09:00/21:00 ai_leaders_x + 18:00 rss_blogs + 每 3h:45 hn + 每 3h arxiv 8 ALIGNED jobs cron 触发后, 每 paper alignment 评分段的"一句话原因 ≤30 字"输出不再含"对 OpenClaw v37 control plane 有启发"等间接项目动态推论 (LEVEL_4 守卫"严禁基于'项目方向词' 推断本项目存在某个未公开发布的功能"). (f) freight/finance/ontology 每日 cron 推送来源标签校验 (LEVEL_2 守卫"严禁创造未在数据源列表中出现的标签"). ⑫ **元价值 (V3 路标 framework 突破)**: V37.9.57 是 V37.9.56-hotfix3 血案的**真正结构性修复** — hotfix3 是单点 prompt 加禁令, V37.9.57 是 framework 级"反幻觉守卫覆盖率"从"靠 prompt 各自记忆"升级为"声明式 5 档模板 + 机器化部署". V3 路标 `pip install opportunity-radar` / `pip install ontology-engine` 终极目标的核心交付闭合 — 任何新 LLM-calling task 引入时, 只需声明所属严格度档位 (LEVEL_1~5) 即可获得全部反幻觉守卫, 零 prompt 复制粘贴, 零血案记忆维护成本. 这是 V37.9.56 PoC pattern (Top 5 alignment 注入) → V37.9.56-hotfix3 (single-task hotfix) → **V37.9.57 (architectural-level fix)** 的三跳升级, 完整闭环原则 #23 链式幻觉防范 + 原则 #18 补证据而非补功能 + MR-8 copy-paste-is-a-bug-class. ⑬ **下次 V37.9.58+ 候选**: (a) **Mac Mini 5/13 22:00 evening + 5/13 03:00 dream 真跑验证 V37.9.57 LEVEL_5 守卫生产效果** (用户视角观察推送内容是否仍含血案字眼) (b) **INV-HALLUCINATION-001 立 governance** (守卫每个 LLM-calling task 必须 import get_guard, 反 inline 反模式) — 当前 V37.9.57 是 PoC 阶段 (与 V37.9.46/47/48 同款 pattern), 一周观察期后立 INV (c) **LEVEL_6 候选** for sub-agent / multi-agent dispatch 场景 (Phase 4 P5 续推进) (d) **5/11 决策窗口续**: V37.9.23/24/25 jobs_to_crontab + kb_sources_to_index + services_to_launchd machine_sync dry-run → 真激活 (一周累积观察期到达). |
| V37.9.56-hotfix3 | 2026-05-12 | **kb_evening LLM 编造 "OpenClaw 社区发布 v26" 幻觉血案闭环 — V37.9.56 链式幻觉副作用修复 (原则 #23 典型实证)** — ① **触发**: V37.9.56-hotfix Mac Mini 部署后 9:41 evening 推送 evening_20260512.md 第 4 条要闻 + 整个明日关注 + 健康度评分理由都是 LLM 编造。具体编造内容: "OpenClaw 社区发布新版本 v26，验证货代Watcher上线及SSH远程部署流程，修复 --thinking 参数问题 [openclaw]"。**用户视角发现** (原则 #13 兑现) — sources_used 只有"🚢 货代动态"+"🔥 HackerNews 热帖"两个，**没有 [openclaw] 源**，"v26"是项目内部 changelog 编号不是 OpenClaw 社区版本。② **因果链 (原则 #23 链式幻觉)**: V37.9.56-hotfix 部署后 picker 找到 31 picks Top 5 注入 evening prompt → LLM 看 Top 5 提到 "OpenClaw 三平面对齐 (control/memory/ontology)" + 今日笔记少 + sources_used.count=2 → 训练倾向 (合理化 + 连接相关概念) 下推断 "用户在做 OpenClaw 项目 + Top 5 必引用 + 必有项目动态" → 编造 "OpenClaw v26 发布" + 自造 [openclaw] 来源标签。原 V37.9.56 alignment_block 指令"在'今日要闻'段优先引用 Top 5"在 LLM 训练倾向下**反向触发幻觉而非引用真 paper**。9:05 evening (V37.9.56-hotfix 前 picker 0 picks) 没编造 v26 → 9:41 (hotfix 后 31 picks) 才编造 v26 = 因果铁证。③ **三层结构修复 (方向 A)**: (a) **alignment_block 软化注入**: 段头 "今日高对齐 Top 5" → "近期高对齐参考阅读 Top 5 (V37.9.56 #2, ⭐≥4 项目对齐度, **跨多天累积**)"; 注入语 "在'今日要闻'段优先引用" → "你**绝不应**在'今日要闻'/'明日关注'段硬性引用上述条目, 除非今日笔记/来源中**实际出现**对应内容. Top 5 仅作为'背景知识参考', 不作为'新闻事件'." 显式说明 Top 5 = 外部累积非今日事件 (b) **prompt 模板加反幻觉具体字面禁令** (即使无 Top 5 也注入, 防 LLM 任何场景下编造项目动态): 禁字面 "OpenClaw 社区发布"/"OpenClaw v26"/"v26/v27/v37 版本更新"/"项目里程碑"/"开源 X 上线"; 禁来源标签 [openclaw]/[OpenClaw]/[社区] 除非 sources_used 真实出现; 禁链式推论"基于 Top 5 推断本项目状态"/"基于 paper 推断 OpenClaw 版本" (c) **源码注释引用具体血案精确字眼便于运维 grep** (kb_evening_collect.py V37.9.56-hotfix3 注释含 "OpenClaw 社区发布 v26" 真实编造字眼). ④ **6 新单测 1 类** TestV9_56Hotfix3AntiHallucinationGuards: test_anti_hallucination_block_in_template (模板级) + test_alignment_block_uses_soft_injection_not_hard_quote_instruction (反模式守卫) + test_alignment_block_new_header_and_semantic_repositioning (新段头 + 跨多天累积说明) + test_blood_lesson_blocked_phrases_must_be_listed (5 个血案精确字眼显式列出) + test_chain_inference_banned (链式推论禁令显式) + test_v9_56_hotfix3_marker_in_source (源码 marker + 血案精确字眼可 grep). 修复同时 3 个老测试 (TestEveningTopAlignmentInjection backward_compat / empty_alignment / coexist) 适应 V37.9.56-hotfix3 新段头. ⑤ **反向验证守卫真有效**: sabotage 删反幻觉字面禁令立即 3 failures (test_anti_hallucination/test_blood_lesson_blocked/test_chain_inference 全 fail), 还原后 54/54 全过. ⑥ **累计**: 76 suites 不变 / 2607→2613 tests (+6) / 0 fail / VERSION 0.37.9.56 不变 (hotfix 不 bump) / 安全 95/100. ⑦ **原则 #23 (链式幻觉) 典型实证案例**: V37.9.56-hotfix3 是 CLAUDE.md 原则 #23 "LLM 链路中每一跳都会放大幻觉" 的教科书级案例 — V37.9.56 让 Top 5 paper 进入 evening prompt 看似"补全 LLM 输入", 实际让 LLM "Top 5 提到项目 + 今日笔记少 + 训练倾向合理化 = 编造项目动态" 三跳幻觉. 防范方法兑现 ③(a)(b): 段头加"跨多天累积" + 显式声明"不是今日事件" + 加具体字面禁令 (告诉 LLM 哪些字眼绝对不能输出). ⑧ **MR-15 候选元规则强化**: V37.9.56 (deployment-layout-must-be-tested-on-target) + V37.9.56-hotfix3 (llm-prompt-injection-must-anticipate-hallucination-vector) 共同提炼: **任何向 LLM prompt 注入新上下文都必须 (i) 显式语义定位 (ii) 配套反幻觉具体字面禁令 (iii) 在生产环境 user-view 实测验证**, 不能假设"补全数据 = 不会幻觉". 是 V3 路标 declarative capability framework 走向"declarative-with-anti-hallucination-contracts" 升级方向. ⑨ **Mac Mini 部署后预期**: 下次 22:00 kb_evening cron 推送 evening_20260513.md 不再含 "OpenClaw 社区发布" 等编造字眼. 用户可继续手动 `bash ~/kb_evening.sh 1` 验证. ⑩ **元教训** (一日 V37.9.56 → hotfix → hotfix2 → hotfix3 四连发 session): 测试三层契约 + 用户视角观察 (原则 #13/#15) 是 framework 价值的硬实证 — dev 单测全过 + Mac Mini 自动测试全过都不能替代"用户真实阅读推送内容". 是 Stage 2 "audit is regression not prevention" 立场文章的下一篇候选素材 — *"LLM prompt 注入即幻觉注入: 当'补全数据'反向触发链式推论"*. |
| V37.9.56-hotfix2 | 2026-05-12 | **kb_evening.sh DAYS 数字校验防御 (V37.9.56 诊断暴露的 zsh # 注释坑 root-cause fix)** — ① **触发**: V37.9.56 部署诊断时用户执行 `bash ~/kb_evening.sh   # 22:00 同款...` 失败，traceback line 413 `int("#")` ValueError. 真因: zsh `interactive_comments` 默认 OFF, `#` 被当 $1 传给 bash → `DAYS="${1:-1}"` 拿到 "#" (非空通过 `:-` 默认) → collector `int(os.environ.get("DAYS"))` 抛 ValueError. ② **原则 #28 root-cause fix**: 不是 V37.9.56 引入但 V37.9.56 诊断暴露 (Q1 之前存在 ✓ V37.7 起 / Q2 我引入 ✗ / Q3 最小修复 = kb_evening.sh 加 regex 数字校验). ③ **修复** (kb_evening.sh log() 定义后, line 47 附近): `if ! [[ "$DAYS" =~ ^[0-9]+$ ]]; then log "WARN: DAYS arg '$DAYS' non-numeric, falling back to 1"; DAYS=1; fi`. 非数字 fallback 1 + WARN 日志含原始值便于运维 grep. 让 cron 继续跑而不是炸 traceback. ④ **5 新单测 1 类** TestV9_57Hotfix2DaysNumericValidation: regex 字面量守卫 + V37.9.57-hotfix2 marker + fallback DAYS=1 顺序锁 + WARN 日志关键字 (non-numeric, DAYS arg) + **runtime subprocess 真跑验证血案场景** (DAYS="#" → fallback 1 + log WARN / DAYS=2 → 正常通过 / 空串 → fallback 1). ⑤ **反向验证两层守卫真有效** (sabotage 删校验块立即 4 failures / sabotage regex 改 ^.+$ 立即 2 failures, 还原后 48/48 全过). ⑥ **累计**: 76 suites 不变 / 2602→2607 tests (+5) / 0 fail / VERSION 0.37.9.56 不变 (hotfix 不 bump, V37.9.43-hotfix/V37.9.50-hotfix2/V37.9.50-hotfix3 同款惯例) / 安全 95/100. ⑦ **元教训**: V37.9.56 部署诊断的 zsh # 坑暴露了一个独立小 bug — 修复成本 10 分钟但消除了未来 caller (含 cron / 第三方 / 误操作) 传非数字 DAYS 的 silent failure 类. 原则 #28 三问严格执行: 不是 V37.9.56 引入但症状暴露窗口在同一诊断中, 同 session 修最高效 (避免下次 session 重新拉起上下文). |
| V37.9.56-hotfix | 2026-05-12 | **V37.9.56 picker cache_paths 多 layout 修复 (Mac Mini 实测 0 picks 死局, MR-10 understand-before-fix 兑现)** — ① **触发**: V37.9.56 部署 Mac Mini 后用户跑 `python3 ~/top_alignment_picker.py` 输出 `no picks (scanned 8 sources)` 而 kb_evening 同时段 sources_used=[HN+货代] 证明 HN 今日 cache 有数据. 单测 + dev 全过, **生产 0 picks**. 按原则 #28 三问诊断: (Q1) 之前不存在 ✓ V37.9.56 引入 (Q2) 我哪个改动: picker 默认 `repo_root = os.path.dirname(__file__) = $HOME`, `cache_dir_rel="jobs/X/cache"` → 找 `~/jobs/X/cache` (Q3) 真根因: **Mac Mini auto_deploy FILE_MAP 真实部署路径是 `~/.openclaw/jobs/X/` 不是 `~/jobs/X/` 也不是 `~/openclaw-model-bridge/jobs/X/`** + HN 例外子目录 `hn_watcher` (FILE_MAP line 164: `run_hn_fixed.sh|$HOME/.openclaw/jobs/hn_watcher/run_hn_fixed.sh`). dev 单测全部用 tempdir 自构造 `jobs/X/cache` layout 不暴露此 bug. ② **最小修复**: ALIGNED_SOURCES schema `cache_dir_rel` (单路径) → `cache_paths` (list 候选, 顺序优先 try). 8 个 source 每个含 dev + Mac Mini 2 候选; HN cache_paths = `["cache", "~/.openclaw/jobs/hn_watcher/cache"]` 处理子目录差异. 新增 `_resolve_cache_dir(repo_root, src)` 纯函数 (~/  展开 + abs 直用 + rel 拼 repo_root + 全空 FAIL-OPEN 返回首个候选). `collect_all_picks` 改用 helper 替代 `os.path.join(repo_root, src["cache_dir_rel"])`. ③ **12 新单测 2 类** TestV9_57MacMiniLayout(6 含 dev layout 解析 + Mac Mini layout 解析 + HN hn_watcher 子目录解析 + FAIL-OPEN 全空返回首个候选 + cache_paths 缺失/空安全 + 端到端 Mac Mini layout picks 真收集) + TestV9_57SchemaGuards(6 含 8 source 全部 cache_paths 字段 + 必须 list + 必须 ≥2 候选 + 禁止残留 cache_dir_rel 反模式 + Mac Mini 路径 `~/.openclaw/jobs/` pattern 必存 + HN 必须 hn_watcher 子目录 + helper 函数定义 + collect_all_picks 调 helper + V37.9.57 marker). **反向验证两层守卫真有效**: sabotage 删 hf_papers Mac Mini path 立即 1 fail / sabotage 改 hn_watcher → hn 立即 1 fail, 还原后 67/67 全过. ④ **MR-10 understand-before-fix 兑现**: 先让 user 跑诊断 `ls ~/openclaw-model-bridge/jobs/hf_papers/cache/llm_results.jsonl` 全 missing → 发现 jobs 不在那里 → 查 auto_deploy FILE_MAP 看真实部署路径 = `~/.openclaw/jobs/X/` 才动代码. **没盲改**, 数据驱动诊断. ⑤ **MR-15 候选元规则反例**: V37.9.56 当 PoC 阶段引入 deployment-specific assumption 但单测全用 tempdir 隔离, 没在 Mac Mini 真实 layout 上 smoke test. 候选元规则 *deployment-layout-must-be-tested-on-target-not-tempdir* — 部署路径假设要在真实部署环境验证 (V37.9.58+ 立). ⑥ **累计**: 76 suites 不变 / 2590→2602 tests (+12 V37.9.57 layout coverage) / 0 fail / governance v3.35 不变 / VERSION 0.37.9.56 不变 (hotfix 不 bump, V37.9.43-hotfix 同款惯例) / 安全 95/100. ⑦ **Mac Mini 部署后预期**: `python3 ~/top_alignment_picker.py` 应找到 HN 今日 cache 输出 picks (如有 ⭐≥4); kb_evening 22:00 cron 推送 Top 5 段含 ⭐≥4 paper/repo/blog. ⑧ **元教训**: 同一 session 内的 V37.9.56 部署 + V37.9.56-hotfix 闭环展示**测试三层契约** (原则 #15) — 单测覆盖逻辑正确 + dev 环境 syntax/structure 正确 + **Mac Mini 真实部署是不可替代的第三层验证**, 否则 deployment-specific 假设错配会让"看似完整"的功能在生产端 0 输出. 这是 V37.9.56 PoC pattern 的延伸 — 不只是写代码, 还要在 target environment 验证 path 假设. |
| V37.9.56 | 2026-05-12 | **Sub-Stage 4c Top 5 高对齐推送 picker 完整兑现 — Opportunity Radar #2 三件套全量集成 (kb_dream + kb_evening 双路注入)** — ① **触发**：V37.9.51 收工承诺 Sub-Stage 4c 是"audit P1/P2 完整批次后聚合高对齐 paper/repo/blog/tweet 到推送顶端", 让用户每日 WhatsApp/Discord 推送一眼看到"今日真正值得读的 5 条". V37.9.46/47/48 PoC + V37.9.49 Sub-Stage 4a 集成 (#1 跨源 + #3 趋势) 已就位, V37.9.56 闭环 #2 项目对齐度 picker. 严格按原则 #28 三问 (Q1 之前不存在 ✓ / Q2 新功能 ✓ / Q3 最小修复 = 新模块 + 双处集成, 不动 8 个上游 ALIGNED 脚本本身). ② **新文件 `top_alignment_picker.py`** (~340 行纯 Python, 零 I/O at import, FAIL-OPEN 契约 V37.9.46 同款 lazy import 模式): 6 个公开纯函数 — `scan_source_results(cache_dir)` 读 llm_results.jsonl 跳 failed/空内容/损坏 JSON 行 + `parse_alignment_from_content(content)` lazy import project_alignment_scorer.extract_star_count → _fallback_extract_star_count (clamp [0,5]) → key-based 6-field state-machine 复用 hf_papers/V37.9.51 同款 (📌/🔑/💡/🎯/⭐/🎚️ 字段头识别 + 🎚 fallback no variation selector + ⭐ 评级与 🎚️ alignment 不污染) + `collect_all_picks(repo_root, min_stars)` 扫 8 ALIGNED source + `rank_picks(picks, top_n)` 三档排序 (⭐ 数 desc + source_priority asc + cn_title 长度 desc) + `format_top_picks_block(picks)` markdown 单行格式 `- ⭐⭐⭐⭐⭐ [HF精选] 标题 / 一句话原因` 标题 40 字截断 + `pick_top_aligned(repo_root, min_stars, top_n)` 端到端 orchestrator 返回 12-key dict (status/picks_total/picks_top/block) 顶层 try/except FAIL-OPEN 返回 no_picks. **常量锁定**: `DEFAULT_MIN_STARS=4` + `DEFAULT_TOP_N=5` (V37.9.51 收工承诺) + `ALIGNED_SOURCES` 8 个 source registry (hf_papers prio 1 / s2 prio 2 / arxiv+dblp prio 3 / github_trending prio 4 / rss_blogs prio 5 / ai_leaders_x prio 6 / hn prio 7) + `RESULTS_FILENAME="llm_results.jsonl"`. **CLI**: `--json` / `--block-only` (适合 bash `BLOCK=$(...)` 注入) / `--repo-root` / `--min-stars` / `--top-n` / 默认 human-readable + log() 写 stderr (MR-11 V37.8.6 stdout 污染血案防御). ③ **kb_dream.sh Phase 1.5 集成** (V37.9.49 Sub-Stage 4a 模式扩展): 新增 `TOP_ALIGNMENT_BLOCK=""` + `ALIGNMENT_PICKER` 路径自发现 ($HOME 或 dirname $0) + 调 `python3 ALIGNMENT_PICKER --block-only` 取 markdown 段 + 注入 REDUCE_DATA 作为 `═══ Opportunity Radar #2 (今日高对齐 Top 5, ⭐≥4) ═══`. 整段在 #1 cross_source + #3 趋势加速度之间, 不破坏 V37.9.49 现有逻辑顺序. ④ **kb_evening_collect.py 集成**: 新增 `collect_top_alignment_picks_for_evening(repo_root, min_stars, top_n)` helper (镜像 V37.9.49 `collect_trend_signals_for_evening`) + `build_evening_prompt` 新增 `top_alignment_picks=None` 可选参数 (向后兼容 V37.9.49) + prompt 末尾注入 `═══ 今日高对齐 Top 5 (V37.9.56 #2, ⭐≥4 项目对齐度) ═══` 段 (在 trend_block 之前) + 提示 LLM 在"今日要闻"段优先引用 + `.strip()` 守卫防 whitespace-only 字符串误注入空 block + run() orchestrator 调 helper 注入 prompt. ⑤ **60 新单测 / 2 文件**: test_top_alignment_picker.py 55 单测 / 8 类 + 反向验证三层守卫真有效 (sabotage DEFAULT_MIN_STARS=3 立即 fail / 删 🎚 fallback 立即 fail / log 写 stdout 立即 fail, 还原后 55/55 全过): TestParseAlignmentFromContent(11) + TestFallbackExtractStarCount(5) + TestScanSourceResults(6) + TestCollectAllPicks(3) + TestRankPicks(6 含 stars desc / priority tie-break / title len tie-break / top_n truncate) + TestFormatTopPicksBlock(6 含 ⭐ clamp / 标题 40 字截断 / 无 reason 不加分隔符) + TestPickTopAlignedOrchestrator(3 含端到端 dev no_picks / ok / multi-source 排序) + TestCliInterface(3 subprocess 真跑 --json + --block-only) + TestSourceLevelGuards(10 含 V37.9.56 marker / 8 source 全部注册 / 默认阈值锁定 / MR-11 stderr / FAIL-OPEN 文档 / 双 emoji 兼容 / 反 lazy import 守卫) + TestV9_56IntegrationContracts(2 JSON 可序列化 + bash 注入安全). test_kb_evening.py 新增 5 测试 TestEveningTopAlignmentInjection(向后兼容无注入 + 提供时注入 + 空白字符串不注入 + 与 trend_signals 共存 + collect helper FAIL-OPEN 返回 str). ⑥ **接入**: auto_deploy.sh FILE_MAP 加 `top_alignment_picker.py|$HOME/top_alignment_picker.py` + full_regression.sh 加新 suite `top_alignment_picker`. ⑦ **设计决策 (按 PoC 阶段惯例)**: 不立 governance INV (V37.9.46/47/48/49 同款 PoC pattern, 设计文档 INV-RADAR-001 留 Stage 6 三件套全量在生产真跑稳定后立). 同时不动 8 个上游 ALIGNED 脚本本身 — V37.9.56 只新建 picker + 集成, 上游 V37.9.45/50/51 已迁移完毕的 cache schema 直接复用. ⑧ **累计**: 75→76 suites (+1: top_alignment_picker) / 2530→2590 tests (+60: 55 picker + 5 evening V37.9.56 integration) / 0 fail / governance v3.35 不变 / 72 invariants 不变 / 562 checks 不变 / VERSION 0.37.9.55→0.37.9.56 / 安全 95/100. ⑨ **Mac Mini 部署效果**: 部署 V37.9.56 后下次 cron 自动生效: (1) 22:00 kb_evening 推送在"今日要闻"段之前**首次出现** "═══ 今日高对齐 Top 5 ═══" 段 + 5 条 ⭐≥4 paper/repo/blog/tweet 简明 listing + LLM 在主分析中优先引用. (2) 03:00 kb_dream Phase 1.5 把 #1+#2+#3 三件套完整注入 Reduce LLM prompt, "梦境"段首次以"今日真正值得读"作为锚点而非 paper 海洋抽样. (3) 用户在 WhatsApp 第一眼看到"今日值得读 5 条"前置位置, 决定是否点开 13 个其他 cron 推送源. ⑩ **元价值**: V37.9.56 是 Opportunity Radar 三件套从"独立组件"(#1+#2+#3 V37.9.46/47/48 各自 PoC) → "信号入推送链"(V37.9.49 #1+#3 集成) → **"完整三件套全量集成"** 的真正闭环. 数据复利路线从"14 source × 50 entries/day 信息洪流"升级为"⭐≥4 高对齐 + 跨源共振 + 趋势加速度 三档过滤后的高价值早期信号 Top 5". 这是 V3 路标 `pip install opportunity-radar` 终极目标的核心交付闭合 — declarative source registry + capability framework + 推送通道三层解耦, 任何新 source 只需迁移到 6 字段 + 加入 ALIGNED_SOURCES 即可参与 Top 5 评选, 零上游脚本侵入. ⑪ **下次 V37.9.57+ 候选**: (a) Mac Mini E2E 验证 — 跑 22:00 kb_evening 看推送中 Top 5 段真实数据 + 03:00 kb_dream Reduce 看 #1+#2+#3 三件套全量信号融合效果 (b) Sub-Stage 4b 续推剩余 P2/P3 audit 脚本 (acl_anthology / openclaw_official / kb_inject / freight_watcher / finance_news 等还未对齐 6 字段) — 完成后 ALIGNED_SOURCES 数从 8 增到 12+ (c) Stage 5 kb_radar.sh 06:00 cron 综合分析 (#1+#2+#3 早间一篇推送) (d) Stage 6 INV-RADAR-001 立 governance 守 (e) 5/11 决策窗口处理 (jobs_to_crontab + kb_sources_to_index machine_sync dry-run 真激活, 需 Mac Mini 一周漂移数据). |
| V37.9.55 | 2026-05-11 | **doubao flip verified_tool_calling + verified_streaming — Mac Mini E2E 双 capability 实测通过 + framework 视角 doubao 超越 Qwen3** — ① **触发**: 用户战略询问 "doubao 性能更好, 后续建议为主". 我推 4 个未验证 capability 风险表 (tool_calling/streaming/fallback/业务一致性) + 推荐渐进切换路径 (V37.9.55 先完成能力实测 → V37.9.56 单 cron 试水 → V37.9.57+ 切 primary). 用户决策路径 = 节奏选 "V37.9.55 完成能力实测 (不切 primary)" + Quota=明确充裕. ② **Mac Mini E2E 双测通过**: (a) **tool_calling**: curl 带 OpenAI tools schema (get_weather function) → 响应 `finish_reason="tool_calls"` + `message.tool_calls=[{id, function:{name:"get_weather", arguments:'{"city": "北京"}'}}]` + reasoning_content 显思考过程. 100% OpenAI Chat Completions tool_calling schema 兼容. (b) **streaming**: curl 带 `stream:true` → 多行 `data: {chat.completion.chunk}` SSE + `delta.content` + `delta.reasoning_content` 双字段流式 (reasoning model 流式 reasoning 字逐字). 100% OpenAI streaming schema 兼容. ③ **flip 2 个 verified flags** in doubao_provider.py: `verified_tool_calling=True` + `verified_streaming=True`. 剩 `verified_fallback=False` 守诚实语义留 V37.9.56+ 生产真 fire 后才能 flip (不能人为造 fallback 触发场景). ④ **cap_score framework 效果**: V37.9.54: 6 base + 3 verified*2 = 12. V37.9.55: 6 base + 5 verified*2 = **16**. **doubao cap_score 16 > Qwen3 cap_score 14** (Qwen3: 4 base + 5 verified*2). **framework 视角 doubao 是 registry 最强 provider**. 但 primary 仍是 Qwen3 (adapter PROVIDER_NAME env=qwen 不动), V37.9.56+ 用户决定是否单 cron 试水或全切. ⑤ **15 新单测 6 类** test_v37_9_55_doubao_more_verified.py: TestVerifiedToolCallingFlagsV9_55(2 含 verified_tool_calling=True + verified_features 含 tool_calling) + TestVerifiedStreamingFlagsV9_55(2 含 verified_streaming=True + verified_features 含 streaming) + TestVerifiedFeaturesV9_55Complete(1 锁定 5 项集合 {text,vision,tool_calling,streaming,reasoning}) + TestCapScoreV9_55(2 含锁定 16 + 必须 > Qwen3 cap_score) + TestRemainingUnverified(2 verified_fallback 守 False + 不在 features) + TestPluginSourceV9_55(5 plugin source: verified_tool_calling=True + verified_streaming=True + verified_fallback=False + V37.9.55 marker + tool_calls/SSE 字面量证据) + TestV37955VersionMarker(1 VERSION 0.37.9.55). ⑥ **修适 V37.9.52/53/54 cascading lock** (V37.9.55 flip 引发 4 个测试文件升级): V37.9.54 3 处 (cap_score 12→16 / verified_features 集合扩 5 项 / VERSION 不等式断言接受 V37.9.55+ 后续版本) + V37.9.53 4 处 (cap_score 12→16 / verified_features {text,vision,reasoning}→5 项 / unverified flags 只剩 verified_fallback / plugin 反验证守卫只剩 verified_fallback) + V37.9.52 1 处 (test_verified_state_evolution 只剩 verified_fallback). ⑦ **额外观察 — doubao reasoning streaming 特性**: streaming 测试发现 doubao 流式输出同时流送 `delta.reasoning_content` (思考过程逐字) + `delta.content` (最终答复) 双字段. 这对 adapter -> OpenClaw -> WhatsApp 路径有产品决策影响: V37.9.56+ 可能需要选择是否 expose reasoning_content 给 OpenClaw (类似 OpenAI o1 隐藏 reasoning vs DeepSeek-R1 显示). 当前 V37 adapter 不处理 reasoning_content, 流式输出会自动 strip 它 (delta.content 才被传到 OpenClaw 显示). ⑧ **累计**: 74→75 suites (+1: v37_9_55_doubao_more_verified) / 2515→2530 tests (+15) / 0 fail / governance v3.35 不变 (V37.9.55 仅 verified flag flip 无新 INV) / 72 invariants 不变 / 562 checks 不变 / VERSION 0.37.9.54 → 0.37.9.55 / 安全 95/100. ⑨ **V37.9.56+ 候选路径** (用户切 primary 决策): (a) **单 cron 试水**: 让 1 个低优先级 cron (如 hf_papers 或 rss_blogs) 显式走 doubao (通过 capability_routing 或 FALLBACK_PROVIDER env), 观察 3-7 天推送质量 + Volcengine quota 消耗. (b) **全切 primary**: adapter PROVIDER_NAME env qwen→doubao + plist 同步 + 重启 adapter. Qwen3 自动退为第 1 fallback (V37 capability routing 推导). (c) **doubao reasoning_content 决策**: 是否 expose 给 OpenClaw / WhatsApp 给用户看 (产品决策, 不是技术问题). (d) **真 fallback fire 等待**: Qwen3 quota 满或宕机时, doubao 自动接管 → 自然 flip verified_fallback=True (诚实语义). ⑩ **元价值**: V37.9.55 是 V37 capability routing framework 的**真实压力测试** — V37.9.52 接入 doubao 起 cap_score=5, V37.9.53 加 reasoning capability 升 10, V37.9.54 加 verified_vision 升 12, V37.9.55 加 verified_tool_calling + verified_streaming 升 16. **每次升级都让 fallback chain 自动重排**, framework 通过 capability 数据驱动而不是 if-then-else 硬编码. doubao 在 4 个 session 内从"未知能力 plugin"演进到"registry 最强 provider", 整个过程零 adapter.py routing 改动 / 零 FALLBACK_PROVIDER 硬指定. V3 路标 "pip install ontology-engine" 终极目标的核心证据之一 — declarative capability framework 真的工作. |
| V37.9.54 | 2026-05-11 | **ABC 三件套同 PR — A restart.sh marker-based plist reload + B doubao verified_vision flip + C INV-PLIST-ENV-001 治理 plist EnvironmentVariables 同步** — ① **触发**: V37.9.53 Mac Mini 实测发现 launchctl kickstart -k 不重读 plist (V37.9.13 后第二次踩同款坑), 需要手动 bootout/bootstrap 才让 ARK_API_KEY 真到 daemon 让 doubao 进 fallback chain. 用户 doubao vision E2E (curl image_url) 200 + 完整中文图片描述 + reasoning_content 同步通过, 路径 A 完全可行. 用户指示 ABC 全部执行: A restart.sh 修, B verified_vision flip, C plist env 治理. ② **A: restart.sh marker-based plist reload** — 新 `PLIST_LOAD_MARKER_DIR=$HOME/.openclaw/restart_markers` + helper 内 `stat -f %m` 比较 plist mtime vs `${label}.loaded` marker mtime. plist 比 marker 新 (含无 marker = 首次启动) → 强制 bootout + sleep 1 + bootstrap 重读 plist 含 EnvironmentVariables; plist 不比 marker 新 → kickstart -k 快路径 (V37.9.13 性能). 加载成功且 HTTP 200 健康验证通过后才 `touch "$marker"` (顺序锁守 daemon 启动失败时不误更新 marker → 下次 restart 跳过 plist reload). ③ **B: doubao verified_vision=True** — Mac Mini curl 实测 image_url + text content 混合 content list 工作: HTTP 200 + finish_reason=stop + 完整中文图片描述 + reasoning_content. plugin 注释加 V37.9.54 章节说明 image_url schema 形式. cap_score 升至 12 (6 base + 3 verified*2: text+vision+reasoning), 仍排 fallback chain 第 1 位. 未测 flags 仍 False: tool_calling/streaming/fallback (留 V37.9.55+). ④ **C: INV-PLIST-ENV-001** 新治理不变式 (meta_rule=MR-4 silent-failure, severity=high, verification_layer=[declaration, runtime]): 守 adapter plist EnvironmentVariables 包含所有 providers.py + providers.d/*.py 声明的 `api_key_env`. 5 checks: providers.py 含 api_key_env 字段定义 + doubao plugin 含 ARK_API_KEY 声明 + V37.9.54 marker + python_assert declared api_key_env 集合 ⊇ V37.9.54 baseline (REMOTE/OPENAI/GEMINI/ANTHROPIC/MOONSHOT/MINIMAX/GLM/ARK 8 个) + **runtime python_assert** Mac Mini --full mode 真读 `~/Library/LaunchAgents/com.openclaw.adapter.plist` 用 `plistlib.load()` 解析 EnvironmentVariables, 比对 critical envs {REMOTE_API_KEY, GEMINI_API_KEY, ARK_API_KEY} 必须全在 plist (dev 环境 plist 不存在时静默通过). ⑤ **INV-RESTART-001 扩展 5 个 V37.9.54 marker reload checks**: PLIST_LOAD_MARKER_DIR 常量定义 + helper plist_mtime 比较 + touch marker 字面量 (regex `touch\s+"\$marker"` escape `$`) + need_full_reload 标识 + runtime python_assert 守 touch marker 必须在 HTTP 200 / healthy 字样之后 (400 chars 内). ⑥ **27 新单测 5 类** test_v37_9_54_abc.py: TestRestartShMarkerLogic(8 含 PLIST_LOAD_MARKER_DIR 定义 / mkdir -p / plist_mtime+marker_mtime stat -f %m / need_full_reload=1 默认 safe / touch marker 顺序锁 / kickstart -k 路径保留 / V37.9.54 + V37.9.13 双 marker) + TestRestartShShellBehavior(2 bash -n 语法 + mkdir -p idempotent) + TestDoubaoVerifiedVision(5 verified_vision=True / verified_features 含 vision / V37.9.54 set [text, vision, reasoning] / 未测 flags 仍 False / plugin 注释含 image_url) + TestDoubaoCapScoreUpRanking(2 cap_score 10→12 / fallback chain 第 1 位仍 doubao) + TestPlistEnvGovernance(6 INV-PLIST-ENV-001 声明 / MR-4 严重性 / plistlib + adapter.plist / critical envs baseline / dev 安全 fallback / V37.9.53 血案引用) + TestV37954VersionMarker(4 VERSION 0.37.9.54 / restart.sh + plugin + governance 全含 V37.9.54). ⑦ **修适 V37.9.53 + V37.9.52 cascading lock**: V37.9.53 4 处 (cap_score 锁 10→12, verified_features 锁 {text,reasoning}→{text,vision,reasoning}, unverified flags 删 verified_vision, plugin 反验证守卫从 4 个→3 个) + V37.9.52 1 处 (test_verified_state_evolution 删 verified_vision 行). 8 ⑧ **累计**: 73→74 suites (+1: v37_9_54_abc) / 2488→2515 tests (+27) / 0 fail / governance v3.34→v3.35 / 71→72 invariants (+1 INV-PLIST-ENV-001) / 552→562 checks (+10: INV-RESTART-001 +5 + INV-PLIST-ENV-001 +5) / VERSION 0.37.9.53→0.37.9.54 / 安全 95/100. ⑨ **Mac Mini 部署后用户验证**: (1) `bash ~/auto_deploy.sh` 同步新 restart.sh + plugin + governance yaml (2) **首次 `bash ~/restart.sh`** marker 不存在 → 默认走 bootout+bootstrap 路径 (慢 ~1s 但保证 plist 最新), `/health` 仍正常 fallback_chain=[doubao, gemini]. (3) **第二次 `bash ~/restart.sh`** marker 已存在且 plist 未变 → 自动走 kickstart -k 快路径. (4) **用户改 plist** (PlistBuddy 加新 env) 后跑 `bash ~/restart.sh` → marker mtime < plist mtime → 自动 bootout+bootstrap 重读, env 自动生效 (不再需要手动 bootout). (5) `python3 ~/ontology/governance_checker.py --full` 跑 governance 应 INV-PLIST-ENV-001 ✅, runtime check 真读 plist 验证 critical envs 都在. ⑩ **元价值**: V37.9.13 双管理修复 + V37.9.53 plist env 缺失 + V37.9.54 ABC 同 PR 修 — 同款 launchd silent failure 第三次浮现后转化为治理. V37.9.54 让"plist 改了 daemon 没重读"从程序员记忆问题升级为 (a) restart.sh 自动检测+修复 (A) (b) governance 静态守 marker 逻辑 (INV-RESTART-001 扩展) (c) governance --full 真读 plist 验证内容 (INV-PLIST-ENV-001). 三层防御覆盖运维盲区, 未来加新 provider 时 plist 同步成为机器化 check 不再靠人记得. MR-4 silent-failure 元规则在 plist 场域的完整闭环. |
| V37.9.53 | 2026-05-11 | **Doubao flip verified_text + reasoning capability 落地 — Mac Mini E2E 实测通过后 framework 升级** — ① **触发**: V37.9.52 接入 doubao 后 Mac Mini 实测: `curl /chat/completions` → **HTTP 200 + 标准 OpenAI Chat Completions 兼容 JSON** + `finish_reason=stop` + 完整 `content` "你好呀😊!我是豆包..." + **额外发现 `reasoning_content` 字段** (doubao seed 2.0 是 reasoning model 类似 o1/DeepSeek-R1)。零 translator 需要, V37.9.52 选择的路径 A (OpenAI Chat Completions 兼容) 完全可行。② **framework 扩展 — ProviderCapabilities 新增 reasoning 维度**: providers.py 加 `reasoning: bool = False` + `verified_reasoning: bool = False` 字段 (默认 False 向后兼容 7 个 built-in)。`verified_features()` 追加 `if self.verified_reasoning: features.append("reasoning")`。`_capability_score()` 加分维度从 7 升 8 (text/vision/audio/video/tool_calling/streaming/json_mode/**reasoning**) + verified 维度从 5 升 6 (加 verified_reasoning)。`_capability_overlap` + 公开 `capability_overlap` 同步扩展 8 维度。③ **doubao plugin verified flags flip**: verified_text=True (Mac Mini 实测) + reasoning=True (响应 reasoning_content 实证) + verified_reasoning=True (同次实测确认). 保持 verified_vision=False / verified_tool_calling=False / verified_streaming=False / verified_fallback=False (V37.9.53 仅基于本次实测项 flip, 未测项守 False 等 V37.9.54+ vision E2E + 生产真 fallback fire)。④ **fallback chain 排名自动前移 — 通过 framework 自然推导达成"与 Qwen3 同级"**: doubao cap_score 升至 10 (6 base + 2 verified*2, 含 reasoning), gemini 9 (5 base + 2 verified*2). build_fallback_chain(qwen) 输出 doubao **第 1 位** (取代 gemini), gemini 退第 2 位。这是用户"和 Qwen3 同级别 LLM"诉求的兑现 — **零 adapter.py 改动 + 零硬编码**, V37 capability routing framework 已具备的自动排序根据真实能力数据自动得出。⑤ **25 新单测 6 类** test_v37_9_53_doubao_verified.py: TestReasoningCapabilityField(3 含 reasoning/verified_reasoning 默认 False + 7 个 built-in 向后兼容) + TestDoubaoVerifiedFlagsV9_53(4 verified_text=True / reasoning=True / verified_reasoning=True / 未测 flags 仍 False 守护) + TestDoubaoCapScoreRanking(3 含 doubao>gemini 必须 + cap_score 锁定 10 + gemini 不变 9) + TestVerifiedFeaturesIncludesReasoning(3 doubao 含 [text, reasoning] / 其他 7 不含 reasoning) + TestFallbackChainDoubaoFirst(2 chain[0]=doubao + chain[1]=gemini) + TestSourceLevelGuardsV9_53(10 含 providers.py reasoning 字段 / V37.9.53 marker / _capability_score 改动 / verified_features 改动 + plugin verified_text=True / reasoning=True / verified_reasoning=True / V37.9.53 marker + Mac Mini E2E 注释 / 未 flip flags 守 False)。⑥ **修适 V37.9.52 test_no_verified_features_yet → test_verified_state_evolution**: 旧 test 锁定全 False, V37.9.53 后无效。改为锁定 unverified flags (vision/tool_calling/streaming/fallback) 仍 False + 注释指引详细 V37.9.53 状态见新文件 test_v37_9_53_doubao_verified.py。⑦ **修 test_providers.py test_overlap_has_all_capability_fields**: expected_keys 从 7 维度集合扩到 8 维度集合 (加 reasoning)。⑧ **重要观察**: adapter.py 的 `_build_fallback_chain()` 已经从 V37 起**全自动**调用 `ProviderRegistry.build_fallback_chain(require_available=True)`, V37.9.53 升级 doubao 排名后 Mac Mini **重启 adapter 即生效** (或等 ADAPTER_HOT_RELOAD=true 配置下的热重载)。完全零 adapter.py 改动 + 零 FALLBACK_PROVIDER env 硬指定。⑨ **累计**: 72→73 suites (+1: v37_9_53_doubao_verified) / 2463→2488 tests (+25) / 0 fail / providers 仍 8 (V37.9.52 已加) / VERSION 0.37.9.52 → 0.37.9.53 / 安全 95/100。⑩ **Mac Mini 部署后行为变化** (用户验证): (a) `python3 ~/providers.py --fallback-chain qwen` 输出 doubao 第 1 位 + Available=yes (env 已配齐) (b) `bash ~/restart.sh` 重启 adapter, `/health` 输出的 fallback_chain 含 doubao 在第 1 位 (c) WhatsApp 测 vision (发图 + "看见了什么") 若触发 fallback (qwen2.5-VL quota 紧张时) 会路由到 doubao — 但 V37.9.54+ 才能真 flip verified_vision=True (需要 image_url content 实测)。⑪ **元价值**: V37.9.53 是 V37 Provider Compatibility Layer 设计的真实压力测试 — 用户 demo 揭示 doubao 是 reasoning model 后, framework 通过新增一个 capability 维度 (reasoning + verified_reasoning) **自动**让 fallback chain 重新排序, 不需要任何 if-then-else 硬编码 "doubao 优先". 这是 V3 路标"pip install ontology-engine"愿景的核心证据 — capability 声明 + 评分函数 + 排序算法的解耦让新 provider 类型 (reasoning model) 接入零改动其他 provider。原则 #18 "补证据而非补功能" 兑现 — 不写"if provider==doubao then rank=1"的硬规则, 只声明"我有 reasoning capability + 我已 verified", 自然进入第 1 位。 |
| V37.9.52 | 2026-05-11 | **Doubao Seed 2.0 Pro 接入第 8 个 provider (主力级 LLM, 与 Qwen3 同级) + V37 Provider Plugin Interface 首个真实插件触发 module 重入 bug 闭环** — ① **触发**: 用户提供 Volcengine Ark 凭证 (API key + endpoint ID `ep-20260511174451-dlhm8` + 模型 ID `doubao-seed-2-0-pro-260215`) 要求接入。doubao seed 2.0 是火山引擎主力 LLM, 用户明确"和 Qwen3 同级别 LLM"。② **API 路径决策**: 用户 demo 用 `client.responses.create()` (Volcengine Ark Responses API, input_image/input_text content type)。当前 7 个 provider 全部 OpenAI Chat Completions 兼容。**选 OpenAI Chat Completions 兼容路径优先** (零 adapter.py 改动, YAML/Python plugin 即可), 失败再走 Responses API translator (V37.9.53+ 候选)。**已 dev 测试无法直接调外网** (`Host not in allowlist` 拦截), 真验证留 Mac Mini。③ **新文件 `providers.d/doubao_provider.py`** (Python plugin, ~60 行): `DoubaoSeedProvider(BaseProvider)` + `name="doubao"` / `base_url="https://ark.cn-beijing.volces.com/api/v3"` / `api_key_env="ARK_API_KEY"` / `auth_style="bearer"`。**__init__ 从 `ARK_ENDPOINT_ID` env 读 endpoint ID 注入 model_id**, 缺 env / 空字符串 / 空白 → fallback 公开标识符 `doubao-seed-2-0-pro` (合约通过 + dev 环境无害)。能力声明: text+vision+tool_calling+streaming+json_mode 全开, **verified_*=False** (V37.9.52 未实战, 待 Mac Mini 实测后 V37.9.53+ flip)。**安全底线**: API key 严格走 env 绝不入代码 + 用户专属 endpoint ID 也走 env (即便用户豁免也守 public repo `bisdom-cell/openclaw-model-bridge` 公开可见安全底线)。④ **V37 Provider Plugin Interface 隐藏 bug 首次暴露**: `python3 providers.py` 直接执行 (__name__='__main__') 时, plugin 内 `from providers import BaseProvider` 触发 providers 模块**二次加载** (Python 视 __main__ 与 providers 为不同 module) → 产生两份独立的 BaseProvider 类对象 (id_a vs id_b) → plugin 子类 issubclass 检查永远失败 "No BaseProvider subclass found"。**之前未暴露原因**: `providers.d/` 目录只有 `_example.*` (下划线前缀自动跳过), 从未加载过真插件; V37.9.52 doubao 是首个真插件触发。**最小修复**: providers.py 顶部加 `if __name__ == "__main__" and "providers" not in sys.modules: sys.modules["providers"] = sys.modules[__name__]` 让 __main__ 模式下 alias 指向同一 module 避免重入。⑤ **32 新单测 5 类** test_v37_9_52_doubao_provider.py: TestDoubaoProviderRegistration(6 plugin 文件存在 / 注册到 default registry / 7+1=8 provider count / 无 plugin_errors / 合约验证 / metadata) + TestDoubaoEndpointIdHandling(4 dev 无 env → fallback / env 注入真实 ID / 空字符串 → fallback / 空白 → fallback) + TestDoubaoCapabilities(9 text/vision/tool_calling/streaming/json_mode + 无 audio/video + 256K context + verified_*=False 守卫 + default model 含 vision) + TestDoubaoInFallbackChain(2 build_fallback_chain(qwen) 含 doubao + 自 fallback 排除自身) + **TestModuleReentryGuard(3 V37.9.52 关键 fix 回归)**: `python3 providers.py --validate` exit 0 + 含 "OK doubao" / 直接执行列 8 providers / 源码守卫 sys.modules alias 行存在 + V37.9.52 注释存在 + TestSourceLevelGuards(8 V37.9.52 marker / base_url Volcengine 字面量 / ARK_API_KEY env / ARK_ENDPOINT_ID env / fallback 必须公开 + 用户专属 endpoint ID 不得硬编码 + API key 任何形式不得硬编码 (regex `ark-[a-f0-9]{8}-` 守卫) + Bearer 字面量禁止 + exactly one BaseProvider subclass + from providers import BaseProvider 契约)。⑥ **反向验证守卫真有效**: (a) sabotage 移除 providers.py sys.modules alias → `test_providers_py_has_sys_modules_alias_fix` 立即 AssertionError; (b) sabotage 把用户 endpoint ID `ep-20260511174451-dlhm8` 写入 plugin → `test_fallback_model_id_is_public_identifier` 立即 fail。还原后 32/32 全过。⑦ **接入**: auto_deploy.sh FILE_MAP 加 `providers.d/doubao_provider.py|$HOME/providers.d/doubao_provider.py` (auto_deploy line 374 已有 `mkdir -p $(dirname $DST)`, 部署到 `$HOME/providers.d/` 时目录自动创建) + full_regression.sh 加 suite `v37_9_52_doubao_provider`。**V37 deployment debt 闭环**: V37 Provider Plugin Interface 上线时 `providers.d/` 目录从未在 FILE_MAP, plugin 加载从未在 Mac Mini 真激活, V37.9.52 doubao 首次暴露并修复。⑧ **fallback chain 状态**: `python3 providers.py --fallback-chain qwen` 输出 doubao 在第 6 位 (cap_score=5 与其他后注册 provider 同, 按 registration order 落后)。用户要求"与 Qwen3 同级"暗示 verified_* flag 应 flip 后排名前移, 但 V37.9.52 守 verified=False 因为还没真测过 (不可在等价证明前提升优先级 — V35 原则)。⑨ **累计**: 71→72 suites (+1: v37_9_52_doubao_provider) / 2431→2463 tests (+32) / 0 fail / governance v3.34 不变 (本次无新 INV — 候选 INV-PROVIDER-PLUGIN-REENTRY-001 守卫 sys.modules alias 留 V37.9.53+ 一周观察后立) / 71 invariants / 552 checks / 16 meta rules / 安全 95/100 / VERSION 0.37.9.51 → 0.37.9.52 / **providers 总数 7→8**。⑩ **Mac Mini 部署后用户验证步骤**: (1) `export ARK_API_KEY="ark-..."` + `export ARK_ENDPOINT_ID="ep-20260511174451-dlhm8"` 到 ~/.zshrc (2) `cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main` (3) `python3 ~/providers.py --validate` 应显示 `OK doubao` (4) `python3 ~/providers.py --fallback-chain qwen` 应看到 doubao + `Available: yes` (api key 配齐) (5) `curl -sS https://ark.cn-beijing.volces.com/api/v3/chat/completions -H "Authorization: Bearer $ARK_API_KEY" -H "Content-Type: application/json" -d '{"model":"'"$ARK_ENDPOINT_ID"'","messages":[{"role":"user","content":"你好"}]}' \| head -c 500` 真探测 Chat Completions 端点。**预期路径 A 成功** → 推送 V37.9.53 flip verified_text=True + 加入生产 fallback chain。**若 404/415**: 进入 V37.9.53 Responses API translator 工作量 3-4h。⑪ **元价值**: V37.9.52 是 **V37 Provider Plugin Interface 第一次产生新插件 + 第一次暴露 module 重入 bug + 第一次填补 providers.d/ FILE_MAP debt** — 三个"第一次"在同 session 解决, 让 V3 路标 "pip install ontology-engine" 终极目标的 Plugin 系统从"理论可行"升级为"真插件验证"。MR-7 兑现 — 治理框架的真实压力测试由用户提的"第 8 个 provider" 引爆, 而不是由我自检发现。 |
| V37.9.51 | 2026-05-11 | **Sub-Stage 4b 续 batch: 6 论文/repo/tweet 类脚本批量 5→6 字段 + rule_check 机械迁移 (V37.9.45 hf_papers / V37.9.50 semantic_scholar PoC 模板横向应用)** — ① **触发**: V37.9.50 PoC 收工后 ALIGNED_SCRIPTS 标记 11/21, 用户开工选 "Sub-Stage 4b 续 batch" 路径 (vs 决策窗口主硬卡 / 用户视角观察). 单 session 完成 6 脚本机械迁移 + 28 新单测 + 5 老测 alternation 更新 + governance 守卫升级 + 反向验证. ② **6 脚本迁移**: (1) `rss_blogs` (blog 场景, rule_content=title+description); (2) `dblp` (论文无 abstract, rule_content=title+venue 元数据兜底); (3) `arxiv_monitor` (论文有 abstract, rule_content=title+abstract); (4) `github_trending` (repo 场景, rule_content=full_name+description+topics); (5) `ai_leaders_x` (tweet 场景, rule_content=author+text); (6) `hn` (HN 帖子场景, rule_content=title+desc 清 HTML). 每个脚本统一改动 8 处: prompt 5 字段 → 6 字段 (加 🎚️ 项目对齐度 + OpenClaw 5 档评分指南 + 反幻觉守卫 "而非泛泛 AI 相关") / emit heredoc imports 加 `os` (V37.9.50-hotfix 防 NameError 同款) / `parse_5field_output` → `parse_6field_output` (加 alignment 字段 + 🎚️/🎚 双 emoji fallback) / lazy import project_alignment_scorer (4 helper + FAIL-OPEN try/except + 独立 log prefix `[rss]/[dblp]/[arxiv]/[gh_trending]/[ai_leaders]/[hn]`) / per-paper rule_check (LLM ⭐ vs keyword 一致性, validation invalid → format_validation_marker → ⚠️ marker 加入推送) / `high_alignment_count` 计数器 (⭐≥4 才累加) / 末尾"本轮高对齐 ⭐≥4: N/M" 统计行. ③ **新增 test_v37_9_51_sub_stage_4b_batch.py (28 单测 / 3 类)**: TestV37951SharedGuards(17 含 V37.9.51 marker / 🎚️ 字段定义 / 5 档评分指南 / 反幻觉守卫 / 6 字段声明替换 5 字段 / parse_6field_output 函数 + 老函数清除 / alignment 字段 + 🎚 fallback / emit 调 parse_6field + 显示 🎚️ + high_alignment_count / 4 helper lazy import / V37.9.50-hotfix emit heredoc os import 守卫 / rule_check 4 helper 守卫 + try/except / 评分门槛 llm_stars>=4 顺序锁 / V37.9.36 占位符严禁) + TestV37951PerScriptRuleContent(7 每脚本特有 rule_content 拼接 + total_<domain> 变量名约定) + TestV37951AlignedScriptsAudit(4 ALIGNED_SCRIPTS V37.9.51 锚点 + count ≥11 + 6 脚本路径都映射 V37.9.51 + audit_script aligned=True). **反向验证已确认守卫真有效**: sabotage rss_blogs 全局替换 V37.9.51 → V_BROKEN_ 立即 3 个 FAIL (rule_check 缺失 / emit os 缺 / marker 缺), 还原后 28/28 全过. ④ **ontology/llm_cron_audit.py ALIGNED_SCRIPTS**: 6 个脚本统一从 V37.9.36-37/V37.9.40/V37.9.41/V37.9.43/V37.9.44 升级到 V37.9.51, 总 11 条 (V37.5/V37.8.10/V37.9.16/V37.9.45/V37.9.50/V37.9.51×6) + 每条 comment 明确 Sub-Stage 4b 序号 (1/6, 2/6 等). ⑤ **5 老测试 alternation 更新 (MR-8 单一真理源, V37.9.50 同款模式)**: test_llm_cron_audit.py (V37.9.36-37 或 V37.9.51) / test_v37_9_40_dblp_ailead.py (V37.9.40 或 V37.9.51, 含 DBLP + AI Leaders X 双脚本) / test_v37_9_41_hn.py (V37.9.41 或 V37.9.51) / test_v37_9_43_arxiv.py (V37.9.43 或 V37.9.51) / test_v37_9_43_hotfix.py ("V37.9.43" 或 "V37.9.51" 字面量) / test_v37_9_44_github_trending.py (V37.9.44 或 V37.9.51). 不删老测试 (向后兼容防御作用), 改为 `self.assertIn(version, ("V37.9.X", "V37.9.51"))` alternation. ⑥ **governance INV-LLMCRON-AUDIT-001 守卫升级**: 合并 V37.9.36-37/V37.9.40/V37.9.41/V37.9.43/V37.9.44 5 个老锚点为 1 个 V37.9.51 file_contains + 1 个 V37.9.51 python_assert 端到端验证 (subprocess 跑 importlib 加载 ALIGNED_SCRIPTS 校验 6 路径 + 版本). audit_metadata.total_checks 555 → 552 (净 -3, 8 entries 替换 5 entries). ⑦ **累计**: 70→71 suites (+1: v37_9_51_sub_stage_4b_batch) / 2403→2431 tests (+28) / 0 fail / governance v3.34 不变 / 71 invariants 不变 (内涵升级非新增) / 555→552 checks (-3 合并老锚点) / 16 meta rules / 安全 95/100 / VERSION 0.37.9.50 → 0.37.9.51. ⑧ **Mac Mini 部署效果**: 部署 V37.9.51 后 6 脚本下次 cron 触发自动用新 6 字段格式: rss_blogs 18:00 / dblp 12:00 / arxiv 每 3h:00 (8 次/天) / github_trending 14:00 / ai_leaders_x 09:00+21:00 / hn 每 3h:45 (6 次/天). 用户 WhatsApp 应**首次看到 🎚️ 项目对齐度 + ⚠️ rule_check marker + 末尾"高对齐 ⭐≥4: N/M" 统计**横向覆盖所有论文/repo/tweet 类推送 (V37.9.45 hf_papers 单点 PoC → V37.9.50 semantic_scholar 双 PoC → V37.9.51 全量 8/21 ALIGNED 覆盖 audit P1+P2 路径). ⑨ **下次 (V37.9.52+) 候选**: (a) Sub-Stage 4c Top 5 高对齐推送段 (聚合所有今日 ⭐≥4 alignment 推 Dream/Radar/Evening 综合段) (b) Stage 5 kb_radar.sh 06:00 cron 综合分析 LLM prompt + 红/黄/蓝三档机会点推送 (c) 决策窗口续: Mac Mini 验证零漂移后激活 machine_sync (用户今日保留 dry-run 默认让 Mac Mini 实测可控) (d) SLO p95 50380ms 调查 (V37.9.50 候选). ⑩ **元价值**: V37.9.51 是 V37.9.36 (rss_blogs 血案 PoC) → V37.9.39 (S2 第 1 PoC) → V37.9.40-44 (5 字段批量) → V37.9.45 (hf_papers 6 字段 PoC) → V37.9.50 (semantic_scholar 续 PoC) → **V37.9.51 (6 脚本批量横向覆盖)** 的连环 16 commits 兑现, ALIGNED_SCRIPTS 4→5→7→8→9→10→11→**11** (V37.9.51 数量不变但 6 个脚本升级到 V37.9.51 同款 6 字段模板, 是真正的"加深"非"加宽"). MR-8 copy-paste-is-a-bug-class 兑现 — V37.9.45 hf_papers / V37.9.50 semantic_scholar 双 PoC 模板已机械化, V37.9.51 6 脚本约 30min/脚本完成. 原则 #18 "补证据而非补功能" 兑现 — 不增 cron job 数量, 但每个 paper/repo/tweet 推送的信息密度跃升一个数量级 (5 字段 → 6 字段 + rule_check 防 hallucination + 高对齐统计 = 真正可用的"信号过滤" framework). |
| V37.9.50-hotfix | 2026-05-10 | **emit heredoc 缺 `os` import 导致 rule_check FAIL-OPEN 跳过 (Mac Mini 实测发现, 高对齐统计虚假为 0)** — ① **触发**: V37.9.50 部署 Mac Mini 后用户手动跑 `bash jobs/semantic_scholar/run_semantic_scholar.sh` (12:21 触发), 看到 stderr `[s2] V37.9.50 project_alignment_scorer 缺失或失败: name 'os' is not defined (rule_check 跳过, FAIL-OPEN)` + `(LLM 解析成功 10, degraded 0, 高对齐 0)`. WhatsApp/Discord 推送 6 字段 + 🎚️ 项目对齐度内容**完美**(3 篇 ⭐⭐⭐⭐⭐ 全部 alignment 评分准确), **但**末尾"高对齐 0"统计是虚假值——LLM 输出 alignment 字段正确但 rule_check 完全没跑因 os not defined. ② **真根因**: emit heredoc (line 419 `python3 - "$PAPERS_FILE" "$RESULTS_FILE" "$DAY" "$MSG_FILE" << 'PYEOF'`) 顶部 `import sys, json, re` **缺 `os`**. V37.9.50 加的 lazy import `sys.path.insert(0, os.environ.get('HOME', os.path.expanduser('~')))` 调用 `os.environ` 时模块未导入 → NameError. try/except 捕获走 FAIL-OPEN 路径 → rule_check 完全跳过. ③ **MR-4 silent-failure 第 N 次演出新形态**: V37.9.50 自动化测试 + dev 环境 21/21 全过 + Mac Mini Preflight 80/0/2/1 全过, 但**实跑生产时 stderr WARN 才暴露真问题**. 这是原则 #15 "测试三层 (单测/preflight/真业务验证)" 的第 N 次正向兑现 — dev import 解析时不会触发 lazy import 块的 NameError, 只有真跑到 try/except 内部才会暴露. ④ **最小修复 (按 MR-10 三问)**: Q1 之前存在 ✓ V37.9.50 部署即有 / Q2 我引入 ✓ V37.9.50 lazy import 时 emit heredoc imports 没同步加 os / Q3 = emit heredoc line 420 `import sys, json, re` → `import sys, json, re, os` + 注释解释 V37.9.50-hotfix 用途. ⑤ **1 新单测** test_v37_9_50_semantic_scholar.TestV37950ShellGuards.test_v37_9_50_hotfix_emit_heredoc_imports_os: 找 emit heredoc 起点 + 检查后续 200 字符内 import 行必须含 os (regex `^import\s+[\w,\s]+` 多行模式 + alternation 兼容 `import os` / `import sys, json, re, os` / `import os, sys, ...` 等格式). 反向验证: 改回 `import sys, json, re` 立即 test fail. ⑥ **累计**: 70 suites 不变 / 2402→2403 tests (+1) / 0 fail / governance 555 checks 不变 / 71 invariants / 16 meta rules / 安全 95/100 / VERSION 0.37.9.50 不变 (hotfix 不 bump). ⑦ **Mac Mini 部署后预期行为**: 5/11 08:00 HKT 下次 S2 cron 触发后, **首次真正看到 V37.9.50 完整效果** — rule_check 真跑 + LLM ⭐ 评分与 keyword 不一致时显示 ⚠️ <reason> + 末尾"高对齐论文 ⭐≥4: N/M 篇"统计**真实**(非虚假 0). ⑧ **元价值**: V37.9.50 hotfix 验证用户视角观察原则 #13 第 17 次正向兑现 — 用户实跑 stderr 立即抓到 dev 单测漏掉的 NameError. 单测改进路径: 静态 grep import 行只能查 import 字面量, 真要防回归需要 mock `_concepts/_validate_alignment_score` 都成功 + run() 端到端跑 emit heredoc 真验证 high_alignment_count 计数, 但工程量高于本次 hotfix 必要性. |
| V37.9.50 | 2026-05-10 | **Sub-Stage 4b 1 脚本 PoC: semantic_scholar 5→6 字段升级 + rule_check 集成 (V37.9.45 hf_papers PoC 横向迁移)** — ① **触发**: V37.9.49 Sub-Stage 4a (#1 + #3 信号入推送链) 完成后用户选 "Sub-Stage 4b 续推进 (11 脚本)" 路径. 按 MR-10 三问"最小修复方案"严格执行 — V37.9.45 hf_papers 单脚本 488 insertions / 638 行变化数据揭示: 一次性 7 脚本 batch ≈ 3500+ 行 / 5-10h 超出剩余 session 时间. 用户 push back 决策选 "1-2 脚本 PoC 验证" 路径. ② **scope V37.9.50 = 1 脚本 PoC (semantic_scholar)**: V37.9.39 5 字段 → V37.9.50 6 字段 + rule_check, V37.9.45 hf_papers 同款模板横向迁移. 选 semantic_scholar 因 (a) 论文类与 hf_papers 结构最近 (b) daily cron (08:00 HKT) 真实推送数据多用户能立即感知效果 (c) 已 V37.9.39 fail-fast 对齐成熟. ③ **prompt 升级 (line 327-364)**: 顶部声明 "5 字段中文分析" → "6 字段中文分析 + OpenClaw 项目对齐评估师" / 加 🎚️ 项目对齐度 第 6 字段 + 评分指南 5 档锁定 (⭐⭐⭐⭐⭐ 直接相关 control plane / agent runtime / ontology / governance / convergence framework / fail-fast / memory plane / multimodal routing / opportunity radar / ⭐⭐⭐⭐ 间接相关 tool plugin / KB RAG / semantic search / drift detection / declarative policy / agent reliability / ⭐⭐⭐ 一般 AI/ML 趋势 / ⭐⭐ 无明显关联 / ⭐ 完全无关) + 反幻觉守卫 "项目对齐度评分必须基于'是否能为 OpenClaw 控制平面 / 记忆平面 / ontology engine 提供有价值的借鉴', 而非泛泛 AI 相关" + 输出格式举例新增 "🎚️ 项目对齐度: ⭐⭐⭐ / <一句话原因, ≤ 30 字>" 行. ④ **parse_5field_output → parse_6field_output (line 433-513)**: 函数定义重命名 + fields dict 加 'alignment' 键 + 字段头识别加 🎚️ 分支 (含 🎚 fallback 不依赖 variation selector U+FE0F) + state machine current_field='alignment' 处理 + regex `r'.*🎚️?\s*(?:项目)?对齐度?\s*[:：]?\s*(.*)'` 兼容多种 LLM prefix 变体. 5 字段函数体内的 cn_title / highlights / insight / practice / rating 字段全部保留 (V37.9.50 不删字段, 只加第 6 个). ⑤ **emit alignment + rule_check (line 519-580)**: msg_lines.append `🎚️ 项目对齐度: {fields['alignment']}` 行 + lazy import project_alignment_scorer (4 helper: load_project_concepts / validate_alignment_score / extract_star_count / format_validation_marker) + try/except FAIL-OPEN (模块缺失 / yaml 缺失 → 跳过 rule_check 不阻塞 cron + log 提示) + per-paper rule_check 调用 (extract_star_count(fields['alignment']) → llm_stars; validate_alignment_score(rule_content=title+tldr/abstract, llm_stars, _concepts); validation invalid → format_validation_marker → ⚠️ <reason> 行加入 msg_lines) + high_alignment_count 统计 (llm_stars ≥ 4 计数). 末尾追加 "本轮高对齐论文 (项目对齐度 ⭐≥4): N/M 篇" 统计行. ⑥ **21 新单测 3 测试类** test_v37_9_50_semantic_scholar.py: TestV37950ShellGuards(15 含 V37.9.50 marker / 🎚️ 字段定义 / 5 档评分指南 / 反幻觉守卫 "而非泛泛 AI 相关" / 6 字段声明 + 老 5 字段清除 / parse_6field_output 函数 + 老 parse_5field 清除 / 'alignment' 字段定义 / 🎚 fallback / parse_6field_output 调用 / 🎚️ 项目对齐度 emit / high_alignment_count + 高对齐论文统计 / lazy import + 4 helper / rule_check 调用 + try/except + rule_content 拼接 / format_validation_marker → ⚠️ marker / V37.9.36 占位符反模式守卫 line-by-line 跳过注释) + TestV37950LlmDegradedFallback(3 含 [LLM_DEGRADED] 保留 + tldr 优先 abstract 兜底 + **顺序锁** high_alignment_count += 1 必须在 if llm_stars >= 4 守卫之后 + 必须在 LLM_DEGRADED 块之后 防止误计 degraded 路径) + TestV37950InAuditAligned(3 含 ALIGNED_SCRIPTS V37.9.50 锚点 + count ≥11 + audit_script(s2) returns aligned=True+version=V37.9.50+findings=0 端到端验证). ⑦ **ontology/llm_cron_audit.py ALIGNED_SCRIPTS 升级**: jobs/semantic_scholar/run_semantic_scholar.sh V37.9.39 → V37.9.50 (6 字段 + alignment + rule_check, V37.9.45 hf_papers PoC 横向 Sub-Stage 4b 模板验证). ⑧ **governance INV-LLMCRON-AUDIT-001 守卫升级**: ALIGNED_SCRIPTS 含 V37.9.39 semantic_scholar 锚点 → V37.9.50 锚点 (升级守卫匹配 semantic_scholar 新版本号). ⑨ **V37.9.39 老 test 套兼容 (alternation)**: test_run_semantic_scholar_v37_9_39.py 4 失败测试 (parse_5field_output 函数定义 / parse 返回 dict 5 keys / S2 ALIGNED_SCRIPTS 字面量 / audit_script aligned_version) 升级为 V37.9.50 alternation 模式 (接受 parse_5field_output 或 parse_6field_output / V37.9.39 或 V37.9.50 字符串). MR-8 单一真理源兑现 — 老 test 不删除, 而是升级为兼容老/新两种实现. ⑩ **接入**: full_regression.sh +1 suite (auto_deploy FILE_MAP 不动 — semantic_scholar 已在 FILE_MAP). ⑪ **累计**: 69→70 suites (+1) / 2381→2402 tests (+21) / 0 fail / governance 555 checks 不变 (INV-LLMCRON-AUDIT-001 V37.9.39 守卫升级为 V37.9.50 字面量, 守卫数不变) / 71 invariants / 16 meta rules / 安全 95/100 / VERSION 0.37.9.49→0.37.9.50. ⑫ **下次 (V37.9.51+) 候选**: (a) **Sub-Stage 4b 续 batch** — 用 V37.9.50 semantic_scholar 验证模板成功后批量推剩 6 个论文/repo/tweet 类脚本 (rss_blogs / dblp / arxiv_monitor / github_trending / ai_leaders_x / hn). 每脚本同款迁移工作 30-45min, 总 3-5h. (b) **Sub-Stage 4c** — Top 5 高对齐推送段 (聚合所有今日 ⭐≥4 alignment 推到 Dream/Radar/Evening). 中工作量 1-2h. (c) **Stage 5 V37.9.52** — kb_radar.sh 06:00 cron + 综合分析 LLM prompt + 红/黄/蓝三档机会点推送. (d) **Mac Mini 验证 (硬卡)**: 装 sklearn + 5/11 决策窗口 + V37.9.49 部署后 03:00 kb_dream + 22:00 kb_evening cron 看 Radar 信号注入推送效果 + V37.9.50 部署后 08:00 semantic_scholar cron 看 6 字段 + ⚠️ rule_check marker 推送效果. ⑬ **Mac Mini 部署效果**: V37.9.50 部署后下次 cron (5/11 08:00 HKT) 推送 S2 高引论文时**首次出现** 🎚️ 项目对齐度 字段 + 末尾"本轮高对齐论文 ⭐≥4: N/10 篇"统计 + LLM 评分与 rule_check keyword 不一致时显示 ⚠️ 标记 (V37.9.45 hf_papers 同款 user-visible 验证模式). ⑭ **元价值**: V37.9.45 hf_papers PoC → V37.9.50 semantic_scholar PoC 横向迁移完整闭环 — 验证 V37.9.45 同款 6 字段 + rule_check 模板可机械迁移到论文类同结构脚本. **下次 V37.9.51+ batch 6 个脚本时不需要重新设计模板**, 直接复用 + 适配各脚本特定结构 (如 dblp 无 abstract / hn RSS desc / github_trending repo metadata / ai_leaders_x tweet 上下文 / arxiv_monitor abstract 兜底 / rss_blogs description 兜底). 用户视角原则 #13 第 16 次正向兑现 — V37.9.49 Sub-Stage 4a 部署后立即 Sub-Stage 4b 推进, 单 session 内闭环 4a (#1+#3 信号入推送链) + 4b PoC (单脚本模板验证) 双交付. |
| V37.9.49 | 2026-05-10 | **Stage 4a 三件套 cascade 集成: #1 + #3 接入 kb_dream/evening 推送链 (信号入推送链)** — ① **触发**: V37.9.48 Stage 3 收工后用户选 "Stage 4 三件套集成 (cascade)" 路径. 设计文档 7.1 节 Stage 4 范围 = 三件套协同集成 (kb_dream Phase 1.5 + kb_dream/evening 加速主题段 + 11 脚本批量 6 字段 + Top 5 段). 按 MR-10 三问"最小修复方案"严格执行不一次性大爆炸, 拆 4a/4b/4c 子阶段. ② **scope V37.9.49 = Sub-Stage 4a only**: (a) kb_dream.sh Phase 1.5 集成 #1 cross_source + #3 trend_acceleration → REDUCE_DATA 注入 "Opportunity Radar #1/#3" 双段 (b) kb_evening_collect.py 集成 #3 trend_acceleration → build_evening_prompt 加 trend_signals 参数 + collect_trend_signals_for_evening helper. **不做** (Sub-Stage 4b/4c): 11 脚本批量 6 字段 / Top 5 高对齐推送段 / kb_dream Phase 1.5 升级到 LLM-driven topic summary. ③ **kb_dream.sh Phase 1.5 (~80 行新增 line 869-955)**: 在 Phase 2 Reduce 之前调 `python3 cross_source_signal_aggregator.py --json` + `python3 kb_trend_acceleration.py --json` 输出 daily/weekly JSON, 解析 top 5 共振 + 各 archetype top 3 加速度信号格式化为 RADAR_SIGNALS_BLOCK / TREND_SIGNALS_BLOCK bash 变量. **FAIL-OPEN 契约**: scorer 文件不存在 → 跳过 / python3 调用失败 → 信号设空 / JSON 解析失败 → 信号设空 / 任何环节失败不阻塞 Reduce. RADAR_SCORER / TREND_SCORER 双路径查找 ($HOME 优先 fallback dirname $0). REDUCE_DATA 注入双 section header "═══ Opportunity Radar #1/#3 ═══" + 注意提示 "标 🚨 早期机会点但只有今日笔记/sources 有具体支持才能展开" 防 LLM 把 Radar 信号无中生有. ④ **kb_evening_collect.py 集成 #3** (~70 行新增): (a) `collect_trend_signals_for_evening(radar_dir, max_strong=3, max_decel=2)` helper — 读最新 weekly_trends_*.json (lazy + FAIL-OPEN 缺文件返空) + 按 archetype 分组 (strong+mild / decel+obs) + 格式化 "加速主题/减速主题" 双段. (b) `build_evening_prompt` 加 `trend_signals=None` 可选参数 (向后兼容 V37.6/7 调用) + trend_block 注入 "本周趋势加速度" 段在 prompt 末尾 + 注意提示 "辅助'明日关注'段判断方向, 不能直接当今日要闻输出". (c) run() orchestrator 调 collect_trend_signals_for_evening + 注入 build_evening_prompt. ⑤ **9 新单测 2 测试类** test_v37_9_49_radar_integration.py: TestEveningCollectTrendIntegration(4 含 missing radar_dir / no weekly_trends files / real data 双段格式化 / build_evening_prompt with trend_signals + 向后兼容 None) + TestKbDreamPhase15ShellGuards(5 源码守卫 V37.9.49 Sub-Stage 4a marker / Phase 1.5 块 / RADAR_SCORER + RADAR_SIGNALS_BLOCK / TREND_SCORER + TREND_SIGNALS_BLOCK / Opportunity Radar #1+#3 双 section header + 早期机会点提示 / FAIL-OPEN 契约 + scorer 存在性检查). ⑥ **接入**: full_regression.sh +1 suite (auto_deploy FILE_MAP 不动 — kb_dream/kb_evening_collect 已在 FILE_MAP). ⑦ **累计**: 68→69 suites (+1) / 2372→2381 tests (+9) / 0 fail / governance 555 checks 不变 / 71 invariants / 16 meta rules / 安全 95/100 / VERSION 0.37.9.48→0.37.9.49. ⑧ **下次 (V37.9.50+) 候选**: (a) **Sub-Stage 4b** — 11 脚本批量 5→6 字段 + 集成 rule_check (acl_anthology / karpathy_x / openclaw_official×2 / dblp / arxiv / s2 / github_trending / hn / rss_blogs 同款 V37.9.45 hf_papers 模式机械迁移). 每脚本 ~30-60min, 总 5-10h 大工作量. (b) **Sub-Stage 4c** — Top 5 高对齐推送段 (聚合所有今日 ⭐≥4 alignment 推到 Dream/Radar/Evening). 中工作量 1-2h. (c) **Stage 5 V37.9.51** — kb_radar.sh 06:00 cron + 综合分析 LLM prompt + 红/黄/蓝三档机会点推送. (d) **Mac Mini 验证 (硬卡)**: 装 sklearn + 5/11 决策窗口 jobs_to_crontab + kb_sources_to_index machine_sync 真激活 + V37.9.49 部署后下一次 03:00 kb_dream + 22:00 kb_evening cron 看 Radar 信号注入推送效果. ⑨ **Mac Mini 部署效果**: V37.9.49 部署后下次 cron 触发: (1) 03:00 kb_dream Phase 1.5 自动调 cross_source/kb_trend_acceleration 生成 JSON → 注入 Reduce LLM prompt → 用户在 03:00 推送的 "梦境" 中**首次出现**"Opportunity Radar #1/#3" 双段 (含 top 5 共振信号 + 加速主题). (2) 22:00 kb_evening 自动读 weekly_trends_*.json 注入 evening prompt → 用户在 22:00 推送的"晚间整理"中**首次出现** "明日关注"段含本周加速主题判断方向. ⑩ **元价值**: V37.9.46-49 四阶段 PoC + 集成完结的 Stage 4a — Opportunity Radar 三件套从"独立模块"升级到"信号入推送链"的关键拐点. **下一阶段 4b 是机械迁移工作 (11 脚本)**, 4c 是简单聚合, Stage 5 是新 cron job — 都是 Sub-Stage 4a 这个 cascade 链路打通后的延伸. 用户可在 V37.9.49 Mac Mini cron 真跑数据验证后再决定继续 4b/4c 节奏 (按 MR-10 三问"先验证再 cascade" 谨慎推进). |
| V37.9.48 | 2026-05-10 | **Opportunity Radar Stage 3 — 趋势加速检测 (4 周历史关键词加速度 + 5 档分类)** — ① **触发**：V37.9.47 Stage 2 收工后用户选 "Stage 3 续推进 (#3 趋势加速)" 路径. 设计文档 docs/opportunity_radar_design.md 5 节锁定: #3 趋势加速度 = kb_trend.py 仅算"本周 vs 上周"频率变化, 加速度是二阶导数, 反映动态 (是否连续多周加速). 三件套第三维度补全 = 时间维度. ② **scope (MR-10 三问)**: Q1 ✓ V37.9.46-47 Stage 1+2 同款渐进路径 (#1 + #2 已就位, #3 是补全缺失维度) / Q2 ✗ Stage 3 是规划路径 / Q3 = kb_trend_acceleration.py + 28 单测 + 不集成下游 (Stage 4 才集成 kb_dream/kb_evening, MR-10 三问严格执行不 cascade). ③ **新文件 kb_trend_acceleration.py (~390 行纯 Python, 5 函数 + run/main CLI)**: (a) `extract_keywords_per_week(week_offset, kb_dir, today)` — 复用 kb_trend.py extract_period_text + extract_keywords (lazy import, FAIL-OPEN 缺模块 → 空 dict). week_offset=1 → 今天-7~今天-1 (上周), week_offset=2 → 今天-14~今天-8 (上上周), etc. (b) `compute_acceleration(week_keywords, min_freq_pct=0.005)` — 输入 dict {1: w1_kw, 2: w2_kw, 3: w3_kw}, 用各周占比 pct 而非原始 freq 防总数差距失真. **关键契约**: w2=0 (新词) → skip (无 baseline) / w3=0 → accel_2w=None (但 accel_1w 仍计) / freq < min_freq_pct → skip 小基数门槛 (设计文档 11.2 风险表). 输出 dict {kw: {freq_w1/w2/w3, pct_w1/w2/w3, accel_1w (=pct_w1/pct_w2), accel_2w (=pct_w1/pct_w3 或 None), classification}} (c) `classify(accel_1w, accel_2w=None)` — **5 档锁定** (设计文档 5.1): 🚀 strong: a1≥1.5 AND a2≥1.5 (连续 2 周加速 = 高信号) / ⚰️ obsolescence: a1<0.5 AND a2<0.5 (连续 2 周衰退) / 📈 mild: a1≥1.5 (本周加速 / a2 弱或 None) / 💧 deceleration: a1<0.7 (本周减速) / 📊 stable: 其他 (0.7≤a1<1.5). 顺序锁定 strong > obs > mild > decel > stable. 非数字输入安全降级 STABLE. (d) `rank_signals(metrics, top_strong=10, top_stable=5, top_obs=3)` — 按 archetype priority 分桶 (high_priority=strong+mild / stable / decel_obs) + 同桶按 |a1-1| desc 排 (偏离 1 越远越显著) + 各桶截断. 总 max 18 signals. (e) `emit_radar_json(signals, week, output_dir)` — ~/.kb/radar/weekly_trends_{week}.json + archetype_summary 计数 + tmp+os.replace 原子写. (f) CLI: `--kb-dir X --output-dir Y --json`. ④ **FAIL-OPEN 契约 (V37.9.46/47 同款 lazy import)**: 模块顶部只 stdlib (os/sys/json/glob/datetime/Counter/timedelta), kb_trend lazy import 包 try/except. 任何环节失败 → emit_radar_json([]) 不阻塞. **MR-11 兑现**: log() file=sys.stderr 防 $(...) 命令替换污染. ⑤ **28 新单测 7 测试类** test_kb_trend_acceleration.py: TestExtractKeywordsPerWeek(4 含 invalid week_offset / dict 类型契约 / FAIL-OPEN 缺 kb_trend / 日期范围 today 注入) + TestComputeAcceleration(5 含 3 周历史正常 ontology 强加速 / w2=0 新词 skip / w3=0 → accel_2w=None / min_freq_pct 噪声门槛 / 空输入安全) + TestClassify(6 含 strong 必须 a1+a2 / obs 必须 a1+a2 / mild 仅要 a1 / decel 仅要 a1 / stable 中间区 0.7≤a1<1.5 / 非数字 fallback STABLE) + TestRankSignals(4 含 archetype 优先级 strong>mild>decel>obs>stable / top_k 截断 per bucket 18 max / 空输入 / 桶内 |a1-1| desc 同档内排序) + TestEmitJson(3 含 JSON 完整性 + archetype_summary / weekly_trends_{week}.json 路径 / 嵌套自动 mkdir) + TestBackwardCompat(3 含 kb_trend.extract_period_text/tokenize/extract_keywords 旧接口仍 callable 不 break, V29.5 现有功能完全兼容) + TestSourceLevelGuards(3 V37.9.48 marker / 5 档阈值锁定 1.5/0.7/0.5 + 5 archetype 常量 + 5 emoji 🚀📈⚰️💧📊 / log() file=sys.stderr MR-11). **反向验证守卫真有效**: sed `ACCEL_STRONG_THRESHOLD = 1.5` → `0.5` → test_design_locked_thresholds 立即 AssertionError. 还原后 28/28 全过. ⑥ **Smoke test E2E**: 构造 4 keyword 测试集 (cot pruning 加速 1.92x/3.54x → strong / speculative decoding 1.54x/1.77x → strong / agent 0.92x → stable / kernel cuda 0.32x/0.20x → obsolescence) — 全部按设计文档 5.1 节预期分类工作. ⑦ **接入**: auto_deploy.sh FILE_MAP +1 entry (`kb_trend_acceleration.py|$HOME/...`) + full_regression.sh +1 suite. ⑧ **累计**: 67→68 suites (+1) / 2344→2372 tests (+28) / 0 fail / governance 555 checks 不变 (本次无新 INV — 设计文档 9 节 INV-RADAR-001 留 Stage 6 三件套全部就位后立) / 71 invariants / 16 meta rules / 安全 95/100 / VERSION 0.37.9.47→0.37.9.48. ⑨ **下次 (V37.9.49+) 候选** (按设计文档 7.1 节 Stage 4-6): (a) **Stage 4 V37.9.49** — 三件套协同集成: #1 cross_source 集成 kb_dream Phase 1.5 (Reduce LLM prompt 加"今日跨 source 共振信号"段) + #3 trend_acceleration 集成 kb_dream/kb_evening 推送加"加速主题/减速主题"段 + #2 批量推 6 字段到所有 11 已对齐脚本 + 集成 rule_check 全脚本 + 推送加"高对齐 Top 5"段 (b) **Stage 5 V37.9.50** — kb_radar.sh 06:00 cron 新 job + 综合分析 LLM prompt 设计 + 红/黄/蓝三档机会点推送 + Mac Mini cron 注册 (c) **Stage 6 V37.9.51** — 数据可视化 (kb_concept_map.py + 周生成 HTML) + governance INV-RADAR-001 立 + 路线图收工文档 (d) **Mac Mini 验证**: 装 scikit-learn (sentence-transformers V29.3 已装) → 跑 cross_source_signal_aggregator + V37.9.45+ hf_papers cron 看真实 alignment + ⚠️ 标记效果 + V37.9.48 kb_trend_acceleration 跑出真实 4 周历史关键词加速度 (e) **5/11 决策窗口 (明天)**: jobs_to_crontab + kb_sources_to_index machine_sync dry-run 真激活. ⑩ **Mac Mini 部署效果**: V37.9.48 部署后 kb_trend_acceleration.py 可手动触发 `python3 ~/kb_trend_acceleration.py --json` 看 4 周真实 KB 数据加速度. cron 注册留给 Stage 5 kb_radar.sh 06:00 (设计文档 6.1 节). ⑪ **元价值**: V37.9.48 完成三件套 #1+#2+#3 PoC 三维度全部就位. **下一阶段 Stage 4 集成 = "广度 14 sources × 290 notes/day → 深度 #1 跨源共振 ∩ #2 项目对齐 ∩ #3 趋势加速 = 高价值早期信号"完整链路** — 这是 V3 路标 `pip install opportunity-radar` 终极目标的算法基础全部就位. 但 V37.9.48 严格按 MR-10 三问"最小修复方案"执行不 cascade — Stage 4 集成留给下次 session, 当前 PoC 阶段不引入下游耦合让单独验证三件套独立性. |
| V37.9.47 | 2026-05-10 | **Opportunity Radar Stage 2 — 项目对齐度 rule_check 验证层 + hf_papers 集成** — ① **触发**：V37.9.46 Stage 1 收工后用户选 "Stage 2 续推进 (#2)" 路径. 设计文档 docs/opportunity_radar_design.md 4 节锁定 = #2 项目对齐度评分 = LLM 主观 ⭐ 数 + 离线 keyword-based rule_check 双层验证, 防 V37.9.45 hf_papers PoC 单 LLM 评分的 hallucination. ② **scope (MR-10 三问)**: Q1 ✓ (V37.9.45 inline parser + LLM prompt 已加 🎚️ 字段, 但**没有 rule_check 验证层**) / Q2 ✗ (Stage 2 是 V37.9.45 PoC 后规划的下一步, 设计就位) / Q3 = project_alignment_scorer.py + 31 单测 + hf_papers.sh emit-stage 集成 (灰度 1 个脚本 — 设计文档 7.1 节 Stage 2 范围, **不**批量推 11 脚本 / **不**加 Dream/Radar Top 5 段, 这些留 Stage 4). MR-10 三问严格执行 — 不 cascade. ③ **新文件 project_alignment_scorer.py (~430 行纯 Python, 7 函数)**: (a) `load_project_concepts(path)` — 轻 YAML parse (kb_review_collect 同款 fallback 模式避新增 PyYAML 依赖) + V37.9.47 修 bug: 行尾注释 `weight: 5  # 最高优先级` 让 int() 抛 ValueError 退化为 0, 修复用 `val.split("#",1)[0].strip()` 剥离注释. FAIL-OPEN 缺文件 → 默认 dict (b) `count_keyword_hits(content, concepts)` — 大小写不敏感 + 中英 substring (in 操作不分词) + 同 keyword dedup (set semantics) + excluded_topics weight × -2 强降权; total_score = positive - 2 × negative (c) `compute_expected_range(score)` — 5 档锁定 (设计文档 4.2): score<0 → ⭐1-2 / score=0 → ⭐1-2 / 1-2 → ⭐2-3 / 3-4 → ⭐3-4 / 5+ → ⭐4-5 (d) `validate_alignment_score(content, llm_score, concepts)` — LLM ⭐ 数 vs expected_range 一致性: in_range → validated=True / 偏高 → reason "LLM 评 ⭐{N} 偏高 (rule 预期 ⭐{min}-{max}, 仅命中 {N} 关键词)" / 偏低 → reason "LLM 评 ⭐{N} 偏低 (rule 预期 ⭐{min}-{max}, 命中 {N} 关键词暗示更高对齐)" / invalid llm_score (非 1-5 int) → validated=False + reason 解释 (e) `parse_6field_output(content)` — **MR-8 单一真理源**: 行为与 hf_papers.sh inline parse_6field_output 完全一致 (仅 📌 字段做 inline 提取, 其他字段必须 LLM 多行格式). 测试 `test_module_parser_matches_hf_papers_inline_behavior` grep hf_papers.sh 守卫两侧不漂移 (f) `extract_star_count(text)` — 取最大连续 ⭐ 段 (如 "⭐⭐⭐⭐ / 直接相关" → 4) (g) `format_validation_marker(validation)` — validated=False 时返回 "⚠️ <reason>" 给推送显示, validated=True 返回空. ④ **hf_papers.sh emit-stage 集成 (line 466-480 + 633-650)**: (1) Python heredoc 顶部 lazy import project_alignment_scorer + load_project_concepts (一次, FAIL-OPEN 缺模块 → log WARN 跳过) (2) 每 paper alignment 段展示后调 extract_star_count(fields['alignment']) → validate_alignment_score(title+tldr+abstract, llm_stars, concepts) → format_validation_marker → 不一致时 msg_lines.append(marker). 用户在 WhatsApp 看 hf_papers 推送时, alignment 行下面**直接出现** ⚠️ 标记 + reason — 立即识别 LLM hallucination. ⑤ **31 新单测 7 测试类** test_project_alignment_scorer.py: TestProjectConceptsYaml(5 含真 yaml 加载 / 三 section 结构 / weight 范围验证 / keywords 非空 / FAIL-OPEN 缺文件) + TestKeywordHitCounting(6 含多关键词 / 大小写不敏感 / 中英混合 / excluded × -2 降权 / dedup / 空内容) + TestExpectedScoreRange(4 含 0/5+/边界/负数) + **TestValidateAlignmentScore(4 含 V37.9.47 关键血案场景**: LLM=5 + 0 命中 → not validated + "LLM 评 ⭐5 偏高 仅命中 0 关键词" / LLM in range → validated / LLM 偏低 / invalid score (0/6/99/-1/None/3.5) 各种类型) + TestPromptInjection(3 hf_papers.sh prompt 含 🎚️ + 评分指南 + 一句话原因 30 字) + TestParse6FieldOutput(5 完整 / 缺字段 / 顺序乱序 / 空 / **MR-8 grep hf_papers inline 守卫**: assertIn `def parse_6field_output(content):` + 6 字段 keys + 6 emoji 字段头) + TestSourceLevelGuards(4 V37.9.47 marker / _SCORE_RANGES 5 档锁定 (`(0, 0, 1, 2)` + `(5, 999, 4, 5)` + `(-999, -1, 1, 2)`) / FAIL-OPEN 注释 / log() file=sys.stderr MR-11). **反向验证两层守卫真有效**: (a) sed `(5, 999, 4, 5)` → `(5, 999, 1, 2)` → test_high_hits_high_stars 立即 AssertionError; (b) test_module_parser_matches_hf_papers_inline_behavior grep hf_papers.sh 6 emoji 字段头 + 6 字段 keys 确保 MR-8 单一真理源不漂移. 还原后 31/31 全过. ⑥ **Smoke test E2E**: 构造 paper 1 (高对齐 content + LLM=5 → validated=True 无 marker) + paper 2 (低对齐 content "ImageNet ResNet" + LLM=5 → validated=False + marker `⚠️ LLM 评 ⭐5 偏高 (rule 预期 ⭐1-2, 仅命中 0 关键词)`) — 两个 case 全部按设计文档 4.2 节预期工作. ⑦ **接入**: auto_deploy.sh FILE_MAP +1 entry (`project_alignment_scorer.py|$HOME/...`) + full_regression.sh +1 suite. ⑧ **累计**: 66→67 suites (+1) / 2313→2344 tests (+31) / 0 fail / governance 555 checks 不变 (本次无新 INV — 设计文档 9.2 MR-18 候选"opportunity-radar-must-cross-validate-llm-vs-rule"待 Stage 2 多日实例积累后立) / 71 invariants / 16 meta rules / 安全 95/100 / VERSION 0.37.9.46→0.37.9.47. ⑨ **下次 (V37.9.48+) 候选** (按设计文档 7.1 节 Stage 4-6): (a) Stage 4 — 三件套协同集成: #1 cross_source 集成 kb_dream Phase 1.5 (Reduce LLM prompt 加"今日跨 source 共振信号"段) + #2 批量推 6 字段到所有 11 已对齐脚本 (acl_anthology / karpathy_x / openclaw_official×2 / dblp / arxiv / s2 / github_trending / hn / rss_blogs) + 集成 rule_check 全脚本 + 推送加"高对齐 Top 5"段 (b) Stage 3 V37.9.48 — kb_trend_acceleration.py 28 单测 (4 周历史关键词加速度 + 5 档分类: 🚀 strong 1.5x×2w / 📈 mild 1.5x×1w / 💧 deceleration / ⚰️ obsolescence / 📊 stable) (c) Stage 5 — kb_radar.sh 06:00 cron + 综合分析 LLM prompt + 红/黄/蓝三档机会点推送 (d) Mac Mini 验证: 装 scikit-learn (sentence-transformers V29.3 已装) → 跑 cross_source_signal_aggregator + V37.9.45+ hf_papers cron (10:00/20:00 HKT) 看真实 alignment + ⚠️ 标记效果 (e) **5/11 决策窗口 (明天)**: jobs_to_crontab + kb_sources_to_index machine_sync dry-run 真激活. ⑩ **Mac Mini 部署效果**: V37.9.47 部署后 hf_papers 下次 cron (5/10 20:00 HKT) 推送时, alignment 段下方**首次出现** ⚠️ 标记 (如 LLM 评分与 rule 不一致). 用户在 WhatsApp 第一时间识别 LLM hallucination, 验证 #2 PoC 完整价值. ⑪ **元价值**: V37.9.47 是 V37.9.45-46 PoC 三件套的关键拐点 — V37.9.45 立 #2 LLM 主观评分, V37.9.46 立 #1 跨源 weak signal, **V37.9.47 立 #2 rule_check 验证层让主观评分可被机器交叉验证**. 三层"LLM 主观 + 工程量化 + 跨 source 共振"协同 = "高价值早期信号"识别 framework 雏形, 是 V3 路标 `pip install opportunity-radar` 的核心算法基础. MR-10 三问严格执行不 cascade — Stage 4 集成 / 批量推 / Top 5 推送等留给后续 session. |
| V37.9.46 | 2026-05-10 | **Opportunity Radar Stage 1 PoC — 跨 source 弱信号聚合器（V37.9.45 收工承诺"下次 session 干净启动 Stage 1"兑现）** — ① **触发**：V37.9.45 收工时本周焦点明确登记 "下次 session 干净启动 Opportunity Radar Stage 1 (#1 跨 source 弱信号聚合, 33 单测, sentence-transformer + DBSCAN)". 用户开工选 Stage 1 路径 (vs audit P2 续 / 观察期等待 / 其他方向). ② **scope (设计文档 docs/opportunity_radar_design.md 第 7.1 节锁定)**: V37.9.46 = Stage 1 PoC 仅交付独立模块 + 33 单测，**不集成下游** (kb_dream Phase 1.5 集成留 Stage 4 / project_alignment_scorer rule_check 留 Stage 2 / kb_radar.sh 06:00 cron 留 Stage 5 / kb_concept_map 可视化留 Stage 6). MR-10 三问严格执行 — 不 cascade. ③ **新文件 cross_source_signal_aggregator.py (~410 行纯 Python, 6 核心函数 + run/main CLI)**: (a) `scan_today_notes(date, kb_dir)` — 扫 ~/.kb/notes/{YYYYMMDD}*.md, 解析 frontmatter (kb_write.sh 同款格式: date/tags/source/type), tags[0] 作 source_name (向后兼容 kb_save_arxiv 写入的"arxiv-ai-models"/"hf-papers"等 tag)+ extract title (第一行 #) + abstract (后续段落 ≤500 chars, skip ## 子标题) (b) `embed_notes(notes, cache_dir)` — lazy import numpy + local_embed.embed_texts (sentence-transformer 384d), content_hash 16-char cache key (V37.4 mtime-stable 同款), cache 命中跳过 sentence-transformer 重算 (c) `cluster_dbscan(embeddings, min_samples=3, eps=0.35)` — short-circuit N<min_samples 在 lazy import sklearn **之前** (避免 dev 无 sklearn 时小输入也抛 ImportError), DBSCAN(metric=cosine) (d) `filter_cross_source(labels, notes, embeddings)` — unique_sources>=2 跨源契约, _avg_intra_similarity 用 numpy 矩阵 dot (cosine since L2-normalized), _suggest_topic_keyword 中英文 regex 抽 cluster 内最高频 top-3 keywords (Stage 4 升级 LLM 一句话总结) (e) `rank_signals(signals, top_k=10)` — score=source_count×2+note_count+avg_intra_similarity×5 (f) `emit_radar_json(signals, date)` — 写 ~/.kb/radar/daily_signals_{date}.json + tmp+os.replace 原子写, 简化 notes 字段防大对象. ④ **FAIL-OPEN 契约 (V37.4 同款 lazy import 模式)**: 模块顶部只 import stdlib (os/sys/json/glob/re/hashlib/datetime/Counter), 任何重依赖 (numpy/sklearn/sentence_transformers/local_embed) 都 lazy import 包 try/except, 失败 raise ImportError. run() orchestrator 顶层 try/except ImportError → status='fail_open_no_deps' + emit_radar_json([]) 不阻塞下游. 单笔记 OSError → log WARN 跳过, 其他笔记继续. CLI exit 0 for ok/no_notes/fail_open_no_deps (FAIL-OPEN 不阻塞), exit 1 仅 unexpected failure. ⑤ **MR-11 兑现**: log() `print(..., file=sys.stderr)` 防 $(...) 命令替换污染 (V37.8.6 Dream 自引用幻觉血案教训扩展). source-level guard 在 TestSourceLevelGuards.test_log_writes_to_stderr_mr11 验证 log() 函数体含 `file=sys.stderr`. ⑥ **33 新单测 8 测试类** test_cross_source_signal_aggregator.py: TestScanTodayNotes(5 含 YYYYMMDD 日期过滤 / frontmatter 完整解析 / 缺字段 default unknown / tags 单值 OR list 双格式 / 无效 date 安全返回空) + TestEmbedNotes(4 含 empty 输入 numpy.zeros (0,384) / 文本截断 ≤500 / cache hit os.path.isfile mock 模拟 / force_recompute bypass) + TestClusterDbscan(5 含 empty 返回空 / N<min_samples short-circuit 在 sklearn import 之前 (V37.9.46 顺序锁) / lazy import sklearn ImportError / 单 cluster / 多 cluster + DBSCAN 参数 design-locked 验证 metric=cosine) + TestFilterCrossSource(4 含单 source 拒绝 / 跨 2 源保留 / 跨 4 源高信号 + suggested_topic 含 agent/runtime / noise label -1 排除) + TestRankSignals(3 含公式正确性 / top_k 截断 / 空输入) + TestEmitRadarJson(3 含 JSON 字段完整性 / daily_signals_{date}.json 路径 / 自动 mkdir 嵌套目录) + TestFailOpenContract(4 含 no_notes status / numpy 缺失 fail_open / sklearn 缺失 fail_open (用 builtins.__import__ patch 真抛 ImportError) / 单笔记 OSError 不致命 mock builtins.open). + TestSourceLevelGuards(5 V37.9.46 marker / DBSCAN_MIN_SAMPLES=3 + DBSCAN_EPS=0.35 设计锁定 / FAIL-OPEN 契约文档 / 反 module-top-import 守卫前 60 行禁 numpy/sklearn/sentence_transformers/local_embed / log() stderr MR-11). **反向验证守卫真有效**: sed `DBSCAN_MIN_SAMPLES = 3` → `1` → test_design_locked_constants 立即 AssertionError; 模块顶部加 `import numpy` → ModuleNotFoundError 在 import 时立即触发 (dev 无 numpy 强证守卫 — 即使没跑测试也防住). 还原后 33/33 全过. ⑦ **接入**: auto_deploy.sh FILE_MAP 加 `cross_source_signal_aggregator.py|$HOME/...` (project_concepts.yaml 已在 V37.9.45 加) + full_regression.sh 加 suite. ⑧ **设计文档 docs/opportunity_radar_design.md** 第三节锁定常量 (DBSCAN_MIN_SAMPLES=3 / DBSCAN_EPS=0.35 sentence-transformer all-MiniLM-L6-v2 同主题阈值经验值 / MIN_UNIQUE_SOURCES=2 跨源契约 / TOP_K_SIGNALS=10 / TEXT_TRUNCATE_CHARS=500). ⑨ **累计**: 65→66 suites (+1: cross_source_signal_aggregator) / 2280→2313 tests (+33) / 0 fail / governance 555 checks 不变 (本次无新 INV — 设计文档 9.1 Stage 6 立 INV-RADAR-001, V37.9.46 PoC 阶段不立) / 71 invariants 不变 / 16 meta rules / 安全 95/100 / VERSION 0.37.9.45→0.37.9.46. ⑩ **下次 (V37.9.47+) 候选**: (a) **Stage 1 完成验证**: Mac Mini 装 scikit-learn (`pip3 install scikit-learn`, sentence-transformers 已装 V29.3) + 用户合并后 cd ~/openclaw-model-bridge git fetch+reset → 跑 `python3 ~/cross_source_signal_aggregator.py --date today` 看真实数据 (~290 notes/14 sources) 出 ≥3 跨源共振信号即 Stage 1 成功定义达标 (b) **Stage 2 V37.9.46-Stage2 候选**: 完整 #2 项目对齐度评分 — project_alignment_scorer.py rule_check 验证层 + 批量推 6 字段到所有 11 已对齐脚本 + Dream/Radar 推送的"高对齐 Top 5"段 (c) **Stage 3 V37.9.47**: kb_trend_acceleration.py + 28 单测 + 集成 kb_dream/kb_evening 推送 (d) **5/11 决策窗口** (明天): jobs_to_crontab + kb_sources_to_index machine_sync dry-run 真激活 (V37.9.23/V37.9.24/V37.9.25 累积观察期到达). ⑪ **Mac Mini 部署效果**: V37.9.46 PoC 阶段 cross_source_signal_aggregator.py 部署后**不会自动触发**（无 cron 注册）, 必须用户手动跑 `python3 ~/cross_source_signal_aggregator.py --date $(date +%Y%m%d) --json` 验证. cron 注册留给 Stage 5 kb_radar.sh 06:00 (设计文档 6.1 节). ⑫ **元价值**: V37.9.46 是数据复利路线 (V37 起累积 26000+ chunks / 14 sources / 290 notes/day) 从"广度收集"升级为"深度合成"的关键拐点. **不是再加 1 个 cron**, 而是把已有数据用 sentence-transformer + DBSCAN 算法做横向 weak-signal 检测 — 让用户在每天 14 sources 50 条独立推送中识别"今日 ≥2 source 同时关注的早期信号". 配合 Stage 2 #2 (项目对齐度) + Stage 3 #3 (趋势加速度) 三件套交集 = "高价值早期机会点雷达". MR-10 三问"最小修复方案"严格执行 — 不 cascade 不引入 Stage 2-6 复杂度. |
| V37.9.45 | 2026-05-09 | **hf_papers 6 字段深度迁移（audit P1 完结 + Opportunity Radar #2 PoC 单点验证, ALIGNED_SCRIPTS 10→11）** — ① **触发**：用户 V37.9.44 收工后明确指令"audit P1 续做 hf_papers V37.9.45 机械迁移（同步加 #2 6 字段一并推进）现在就开始做不留尾巴, 下次 session 开始执行 Stage 1"。同 session 双交付: audit P1 最后一个未对齐脚本 + Opportunity Radar Stage 2 #2 单点 PoC（先验证 6 字段设计模式可行性, V37.9.46 Stage 2 再批量推到所有脚本 + 加 rule_check 验证层）。② **scope (MR-10 三问)**: Q1 ✓（audit P1 已识别 hf_papers 是剩余唯一 0/6 score / 3 placeholder findings）/ Q2 ✗（历史 V37.8 copy-paste from arxiv 老版本）/ Q3 = V37.9.43 arxiv 同款机械迁移 + 加 #2 第 6 字段 PoC（不含 rule_check 验证层, 留给 Stage 2）。③ **新文件**: `project_concepts.yaml`（Stage 2 设计文档 4.1 节 schema, version 0.1-poc, 含 3 core_planes 各 weight 5/4/5 + 3 active_research_directions 各 weight 5/4/5 + 2 excluded_topics weight -2 + scoring_guide 5 档评分指南 + meta_rules）。④ **Write 全量重写 hf_papers (433→771 行 +78%)**: (A) 头部 V37.9.45 marker + NOTIFY_SH + send_alert helper（同款）(B) **保留 Step 2.5 GitHub repo enrichment**（HF 独有, 通过 ArXiv ID 搜 GitHub 仓库, github_url/github_stars/github_lang 字段不动）(C) call_llm_single_with_retry helper（V37.9.39 同款 5/10/20s × 3 + 三层检测）+ per-paper 主循环 (D) **6 字段深度 prompt** (V37.9.39 5 字段 + V37.9.45 新增第 6 字段 🎚️ 项目对齐度): 📌 中文标题 / 🔑 核心贡献 / 💡 关键方法 / 🎯 实践启发 / ⭐ 评级 + 推荐场景 / **🎚️ 项目对齐度 ⭐×N + 一句话原因 (≤30 字)** + 5 档评分指南 (⭐⭐⭐⭐⭐ control plane / agent runtime / ontology 直接相关 → ⭐ 完全无关) + V37.8.6 同款反幻觉守卫 + 严禁项目对齐评分泛泛 AI 相关必须基于"是否能为 OpenClaw 控制平面 / 记忆平面 / ontology engine 提供有价值借鉴" (E) **parse_5field_output → parse_6field_output**: 新增 alignment 字段, key-based parser 含 🎚️ 字段头识别 (含 fallback `🎚️` 或 `🎚`) + emit 显示 `🎚️ 项目对齐度: <内容>` + 末尾"本轮高对齐论文 (项目对齐度 ⭐≥4): N/M 篇"统计 (V37.9.45 PoC 简化版, Stage 2 加专门 Top 5 段) (F) LLM_DEGRADED 用 abstract 兜底 (与 V37.9.43 arxiv 同款) + emit 显示 GitHub repo metadata (HF-specific 保留) (G) 多窗口切片 (>8000 字 + sleep 1s + [i/N] + 续段, V37.9.21 同款) + 三档 status (ok/partial_degraded/llm_failed). ⑤ **27 新单测 4 类** test_v37_9_45_hf_papers.py: TestHfPapersV9_45ShellGuards(15 含 V37.9.45 marker / source notify / send_alert / [SYSTEM_ALERT] hf_papers / __LLM_HTTP_ERROR__ / __LLM_PARSE_FAIL__ / call_llm_single_with_retry / backoffs=(5 10 20) / 主循环 per-paper / 三档 status / [LLM_DEGRADED] / **6 字段 emoji 全套含 🎚️** / 严禁虚构 / 评级动态长度 / 多窗口阈值 8000+4000+sleep 1s+续 / 全部失败 500 字符内 exit 1 顺序锁 / V37.9.36 占位符严禁 / V37.8 老 3 字段 emit 已清除 / **HF-specific Step 2.5 GitHub enrichment 必须保留**) + TestHfPapersLlmDegradedFallback(3 含 abstract 兜底 + 无 abstract 显式说明 + HF paper URL 格式) + TestHfPapersInAuditAligned(3 含 ALIGNED_SCRIPTS V37.9.45 锚点 + count ≥11 + audit_script aligned=True+version=V37.9.45+findings=0) + **TestProjectAlignmentField(5 — V37.9.45 PoC 新类)**: project_concepts.yaml 文件存在 + schema 完整 (project/core_planes/active_research/excluded_topics/scoring_guide/control_plane/memory_plane/ontology) / prompt 含 🎚️ 字段定义 + 5 档评分指南 + OpenClaw 项目方向词 / emit 含 parse_6field_output + alignment 字段初始化 + 🎚️ 显示 / emit 末尾含 high_alignment_count 统计. **反向验证两层守卫真有效**: sed 把 LLM_DEGRADED 改回 `贡献：AI领域相关研究` → test_no_placeholder_fallback_text 立即 fail / Python 全局替换 `🎚️ 项目对齐度` → `_REMOVED_alignment` → test_prompt_has_alignment_field 立即 fail, 还原后 27/27 全过. ⑥ **INV-LLMCRON-AUDIT-001 扩展 18→19 checks**: 新增 ALIGNED_SCRIPTS 含 V37.9.45 hf_papers 锚点 file_contains 守卫. ⑦ **audit 报告刷新**: 21 候选 / 10→11 已对齐 / 11→10 未对齐 / placeholder findings 7→4 (hf_papers 移除 3). **audit P1 路径完结** (剩 P2: acl_anthology / karpathy_x / openclaw_official×2 各 1 finding + P3 8 个无 placeholder finding 但缺 fail-fast 标志). ⑧ **累计**: 64→65 suites (+1) / 2253→2280 tests (+27) / 0 fail / governance 554→555 checks (+1) / 71 invariants 不变 / 16 meta rules / 安全 95/100 / VERSION 0.37.9.44→0.37.9.45. ⑨ **Opportunity Radar Stage 2 PoC 关键设计决策**: V37.9.45 单点验证模式 — 仅 hf_papers 加 6 字段, 暂不加 project_alignment_scorer.py rule_check 验证层 (Stage 2 真正 PoC 时实现) + 暂不批量推到所有脚本 (Stage 2 完整时一并). 这样 V37.9.45 是"机械迁移 + 设计验证", 风险最小. 如 V37.9.45 6 字段在生产环境 (HF cron 10:00/20:00 HKT) 表现良好 → V37.9.46 Stage 2 信心十足全量推. ⑩ **MR-10 三问严格执行**: V37.9.45 不引入 project_alignment_scorer.py rule_check (Stage 2 责任) + 不批量改其他脚本 (Stage 2 责任) + 不加 Dream/Radar 推送的"高对齐 Top 5"段 (Stage 2 责任) — V37.9.45 = audit P1 续 + #2 PoC 单点验证, 不 cascade. ⑪ **元价值**: V37.9.36 audit 立 → V37.9.39 S2 → V37.9.40 DBLP+AI Leaders X → V37.9.41 HN → V37.9.43 arxiv → V37.9.44 github_trending → **V37.9.45 hf_papers = 48h 内七阶段 audit P1+P2 续机械迁移连环兑现完结**, ALIGNED_SCRIPTS **4→5→7→8→9→10→11**. **同时 V37.9.45 是 Opportunity Radar #2 PoC 单点验证起点**, Stage 2 (V37.9.46) 全量推 + rule_check, Stage 1 (V37.9.46+ 跨 source 弱信号聚合) 下次 session 单独干净启动. ⑫ **Mac Mini 部署效果**: hf_papers cron 每天 10:00/20:00 HKT (2 次/天). 部署 V37.9.45 后下次 cron 自动用新 6 字段格式. 用户在 WhatsApp 看到 hf_papers 推送时**首次出现 🎚️ 项目对齐度评分** + 末尾"本轮高对齐论文" 统计 — 验证 PoC 模式可观察性. |
| V37.9.44 | 2026-05-09 | **github_trending 5 字段深度迁移（用户视角原则 #13 第 15 次兑现 — WhatsApp 收到旧 4 字段浅表 GitHub 推送后立即提"按 S2 同款格式优化"）** — ① **触发**：用户 V37.9.43-hotfix2 收工后立即在 WhatsApp 收到 14:00 cron 推送的"GitHub 热门 AI/ML 仓库"老 V37.8 4 字段格式（标签/亮点/推荐⭐⭐⭐⭐），明确要求"请把这个任务也升级成 S2 相同格式的任务 深入分析"。**audit 报告中 github_trending 是 P3 1/6 score**（无 placeholder finding 但缺 fail-fast 标志），但用户视角 = 用户感知缺口优先于 audit 优先级。② **scope (MR-10 三问)**: Q1 ✓（audit P3 已识别 1/6 score）/ Q2 ✗（历史 V37.8 copy-paste from arxiv pattern）/ Q3 = 完整 V37.9.39 / V37.9.43 同款机械迁移（5 字段 + LLM_DEGRADED + fail-fast entangled）。③ **3 阶段迁移（423→677 行 +60%, 用 Write 全量重写避开 Edit 工具对大块 emoji+CJK 替换的诡异行为）**：(A) 头部加 V37.9.44 marker + NOTIFY_SH 自发现 + send_alert helper（[SYSTEM_ALERT] github_trending LLM 失败 走 Discord #alerts）(B) 替换 line 203-394（192 行 → 386 行 V37.9.39 同款代码）：call_llm_single_with_retry helper（5/10/20s × 3 + V37.9.36 三层检测）+ per-repo 主循环 + 5 字段深度 prompt 适配 GitHub 项目场景：📌 中文项目名 / 🔑 核心功能（3-5 条 bullet）/ 💡 技术亮点（按评级 ⭐⭐⭐→100-150 / ⭐⭐⭐⭐→250-400 / ⭐⭐⭐⭐⭐→500-800 字）/ 🎯 实践启发（fork/集成/学习架构建议）/ ⭐ 评级 + 推荐场景 + V37.8.6 反幻觉守卫（严禁虚构 / 严禁推断仓库内部实现 / 严禁把错误日志当外部信号）(C) parse_5field_output emit + LLM_DEGRADED 用 GitHub repo description 兜底（替代 V37.9.36 占位符反模式 `亮点：AI/ML相关项目`+`推荐：⭐⭐⭐`）+ 多窗口切片 ≤8000 单段直发 / >8000 mktemp + sleep 1s + `[i/N]` + `(续)` 续段 + 三档 status（ok / partial_degraded / llm_failed → exit 1 fail-fast 顺序锁）。④ **github_trending-specific 适配**：URL 用 `html_url`（GitHub API 返回，已是 `https://github.com/{owner}/{repo}` 完整格式）/ MAX_REPOS=10 保留 / GitHub API 完整 description → LLM_DEGRADED fallback 用 `description[:300]`（vs S2 用 tldr+abstract / DBLP 用 title+venue / arxiv 用 abstract / HN 用 RSS desc）/ Discord 频道 `DISCORD_CH_TECH`（vs S2/arxiv 用 PAPERS — 技术 vs 论文场景区分）/ Repo metadata badge 显示 `⭐ stars \| 主语言 \| 创建于YYYY-MM-DD` / 保留 NEW_IDS_FILE → SEEN_FILE 推送成功后才标记 invariant。⑤ **23 新单测 3 类** test_v37_9_44_github_trending.py: TestGhTrendingV9_44ShellGuards(15 含 V37.9.44 marker / source notify / send_alert / [SYSTEM_ALERT] github_trending / __LLM_HTTP_ERROR__ / __LLM_PARSE_FAIL__ / call_llm_single_with_retry / backoffs=(5 10 20) / for attempt in 0 1 2 / 主循环 per-repo / status:llm_failed / status:partial_degraded / all_failed_ / [LLM_DEGRADED] / 5 字段 emoji 全套 / 严禁虚构 / 评级动态长度 / 多窗口阈值 8000 + 4000 + sleep 1s + [i/N] + 续 / 全部失败分支 500 字符内 exit 1 顺序锁 / V37.9.36 占位符 line-by-line 跳过注释 / V37.8 老 3 字段 emit `msg_lines.append(rec_stars)` 已清除 / Discord 用 TECH 不用 PAPERS) + TestGhTrendingLlmDegradedFallback(4 含 description 兜底 + 无 description 显式说明 + html_url 保留 + repo metadata 显示) + TestGhTrendingInAuditAligned(3 含 ALIGNED_SCRIPTS V37.9.44 锚点 + count ≥10 + audit_script aligned=True+version=V37.9.44+findings=0). **反向验证已确认守卫真有效**：sed 把 LLM_DEGRADED 改回 `亮点：AI/ML相关项目` → `test_no_placeholder_fallback_text` 立即在 L518 报失败 + 行号定位精确, 还原后 23/23 全过. ⑥ **INV-LLMCRON-AUDIT-001 扩展 17→18 checks**: 新增 `ALIGNED_SCRIPTS 含 V37.9.44 github_trending 锚点` file_contains 守卫. ⑦ **audit 报告刷新**: 21 候选 / 9→10 已对齐 / 12→11 未对齐 / placeholder findings 7 不变 (github_trending 之前就 0 findings, 这次升级是补 fail-fast 标志 1/6→6/6). ⑧ **累计**: 63→64 suites (+1: v37_9_44_github_trending) / 2230→2253 tests (+23) / 0 fail / governance 553→554 checks (+1: V37.9.44 ALIGNED_SCRIPTS 锚点) / 71 invariants 不变 / 16 meta rules / 安全 95/100 / VERSION 0.37.9.43→0.37.9.44. ⑨ **元价值**: V37.9.36 audit 立 → V37.9.39 S2 → V37.9.40 DBLP+AI Leaders X → V37.9.41 HN → V37.9.43 arxiv_monitor → **V37.9.44 github_trending = 48h 内六阶段连环兑现**, ALIGNED_SCRIPTS **4→5→7→8→9→10** 是机器化进度证据 vs"靠记忆". MR-8 跨 job 同步 fail-fast 兑现. 用户视角原则 #13 第 15 次正向兑现 — V37.9.43-hotfix2 刚部署用户立即在 WhatsApp 看到下一个浅表推送, 单 session 内闭环 (用户提需求 → 完整迁移 + 单测 + 反向验证 + audit 刷新 + 推送 < 30 分钟). ⑩ **Mac Mini 部署效果**: github_trending cron 每天 14:00 HKT (1 次/天). 部署 V37.9.44 后下次 cron (5/10 14:00) 自动用新 5 字段格式. 如 LLM 故障 → 推 [SYSTEM_ALERT] + status:llm_failed + exit 1 (与 S2/DBLP/AI Leaders X/HN/arxiv/rss_blogs 同款行为). ⑪ **下次 V37.9.45+ 候选** (按 audit 路线图剩余优先级): (a) **P1 续 (3 findings)**: hf_papers — 与 V37.9.39 S2 / V37.9.43 arxiv 同款机械迁移 (b) **P2 (1 finding)**: acl_anthology / karpathy_x / openclaw_official×2 (c) **P3 (0 findings 但缺 fail-fast 标志)**: chaspark / ontology_sources / kb_inject / kb_dream / freight_watcher / finance_news. |
| V37.9.43-hotfix2 | 2026-05-09 | **wa_e2e_test.sh macOS bash 3.2 全角括号变量解析 bug（V37.9.43-hotfix W3 部署后 Mac Mini 实测苏醒，PR #458 沉睡）** — Mac Mini 部署 wa_e2e_test.sh 后首次运行报 `line 140: CHUNK_COUNT�: unbound variable` exit 1。**真根因**: L140 `pass "KB 索引可用（$CHUNK_COUNT）"` + L146 `skip "KB 索引检查跳过（$KB_RESULT）"` 全角 `）` (U+FF09) 紧贴变量, macOS bash 3.2 把 UTF-8 字节当作变量名一部分, `set -u` 触发 unbound variable. **历史溯源**: 自 PR #458 即存在但因脚本长期未部署 (V37.9.43-hotfix W3 修复 FILE_MAP 缺失才首次部署), 从未在 Mac Mini 真跑过 — "长期沉睡的真 bug 在新部署时苏醒"典型案例, **部署是验证不是终点**. **修复**: `${VAR}` 显式 brace 定界变量名 (`${CHUNK_COUNT}` / `${KB_RESULT}`), 防 bash 跨 ASCII/UTF-8 边界混淆. **4 新单测** TestW4WaE2eBashCjkVarParsing: test_no_unbraced_var_adjacent_to_fullwidth_paren (regex 全局扫禁止 `$VAR` 紧贴 `[U+4E00-U+9FFF]\|[U+FF00-U+FFFF]`) + test_v37_9_43_hotfix2_marker_present + test_chunk_count_uses_brace + test_kb_result_uses_brace. **反向验证守卫真有效**: sed `${CHUNK_COUNT}` → `$CHUNK_COUNT` → test_chunk_count_uses_brace 立即 fail, 还原后 16/16 全过. **MR-10 三问严格执行**: Q1 ✓ (PR #458 起即存在) / Q2 ✗ (V37.9.43-hotfix2 未改脚本内容) / Q3 = `${VAR}` 显式 brace, 不引入新概念. **累计**: 63 suites / 2226→2230 tests (+4) / 0 fail / 安全 95/100 / VERSION 0.37.9.43 不变. **Mac Mini 部署后 preflight 79/0/3/1**: W4 ✅ E2E 测试通过 (7 项验证), W1 货代等 20:00 freight cron 自愈, W2 KB lag 结构性自愈, W5 SLO p95 46s long-term unfinished 登记. **元教训**: MR-15 候选元规则 *"shell-string-with-cjk-must-brace-vars"* — 任何 shell 字符串里 `$VAR` 紧贴 CJK / 全角字符必须 `${VAR}` brace, 防 macOS bash 3.2 UTF-8 字节边界混淆. 用户视角原则 #13 第 14 次兑现 (单测 + governance + dev preflight 全绿但 Mac Mini set -u 实跑才暴露). |
| V37.9.43-hotfix | 2026-05-09 | **Mac Mini preflight 81/0/3 三警告闭环（W1 freight schema + W3 wa_e2e FILE_MAP, W2 KB lag 不修）** — V37.9.43 部署 Mac Mini 后 preflight 81/0/3, 3 warnings 按原则 #28 三问审视: W1 货代 deep_dive=skipped (V37.9.31 漏改 Step 9 条件分支, 真 bug 但非 V37.9.43 引入) / W2 KB 索引 98% (结构性 lag, kb_embed cron 自愈, 不修) / W3 wa_e2e_test.sh 未部署 (PR #458 即存在但 FILE_MAP 缺 entry, 长期漏部署观察项). **W1 修复**: jobs/freight_watcher/run_freight.sh line 639 generic `DEEP_DIVE_STATUS="skipped"` → `"skipped_no_high_star"` (语义不变, Step 9 by-design 不进入 = 无 ⭐≥4 高星条目, 合法跳过) + preflight_check.sh 加新 case `skipped_no_high_star) → pass` (V37.9.31 三档 status 之前补齐). **W3 修复**: auto_deploy.sh FILE_MAP 加 `wa_e2e_test.sh|$HOME/wa_e2e_test.sh` (原则 #15 测试三层第三层 WhatsApp E2E 业务验证脚本本体). **12 新单测 3 类** test_v37_9_43_hotfix.py: TestW1FreightSkippedSchemaFix(7 含源码守卫禁止 generic skipped / 用 skipped_no_high_star / V37.9.43-hotfix marker / preflight pass case / 顺序锁 在 V37.9.31 三档之前 / 必须 pass 不能 warn) + TestW3WaE2eTestDeployment(3 含 FILE_MAP entry / 文件存在 / 周围 V37.9.43-hotfix 注释溯源) + TestHotfixDoesNotBreakV37943Main(2 含 V37.9.43 主交付 arxiv_monitor 仍正常 / ALIGNED_SCRIPTS 仍含 V37.9.43). **反向验证守卫真有效**: W1 sabotage `skipped_no_high_star → 'skipped'` → test_freight_no_generic_skipped_status 立即 L639 fail / W3 完整删除 FILE_MAP 行 → test_wa_e2e_test_in_file_map 立即 fail, 还原后 12/12 全过. **V37.9.31 测试同步更新**: test_freight_schema_v9_31.test_step_9_status_values_complete 断言 `skipped` → `skipped_no_high_star` + 顶部 docstring 同步说明 V37.9.43-hotfix 重命名. **MR-10 三问严格执行**: 都是历史真 bug 非 V37.9.43 引入, 同 session 全修 (用户选项 1) — 测试守卫 + 反向验证 + 单一 commit, 不引入 cascade. **累计**: 62→63 suites (+1) / 2214→2226 tests (+12) / 0 fail / 安全 95/100 / VERSION 0.37.9.43 不变 (hotfix 不 bump). **后续 V37.9.43-hotfix2** 修 W4 wa_e2e bash CJK 解析 bug 完成 W3 真 E2E 闭环. |
| V37.9.43 | 2026-05-09 | **arxiv_monitor 5 字段深度迁移 (V37.9.41 audit P1 续 — 机械迁移 V37.9.39 S2 / V37.9.40 DBLP+AI Leaders X / V37.9.41 HN 同款模式, ALIGNED_SCRIPTS 8→9)** — ① **触发**: V37.9.42 收工 audit 报告 P1 剩 hf_papers + arxiv_monitor (各 3 placeholder findings, daily cron 高频用户可见). 用户开工选 arxiv_monitor 优先 (vs hf_papers 顺序对调) — V37.9.41 同款机械迁移路径已成熟. ② **scope (MR-10 三问)**: Q1 ✓ (audit P1 已识别 0/6 score) / Q2 ✗ (历史 V37.8 copy-paste from S2 老版本) / Q3 = 完整 V37.9.39 模式 (5 字段 + LLM_DEGRADED + fail-fast entangled). ③ **3 阶段迁移 (443→704 行 +59%)**: (A) 头部加 V37.9.43 marker + NOTIFY_SH 自发现 + send_alert helper (`[SYSTEM_ALERT] arxiv_monitor LLM 失败` 走 Discord #alerts) (B) **替换 line 216-393 (217 行 → 330 行)**: call_llm_single_with_retry helper (5/10/20s × 3 + V37.9.36 三层检测 `__LLM_HTTP_ERROR__:` / `__LLM_PARSE_FAIL__:bad_json:` / `__LLM_PARSE_FAIL__:no_choices:` / empty content) + per-paper 主循环 `for ((i=0; i<TOTAL_NEW; i++))` + 5 字段深度 prompt 适配论文 metadata `📌 中文标题 / 🔑 核心贡献 / 💡 关键方法 / 🎯 实践启发 / ⭐ 评级` + 按评级动态长度 ⭐⭐⭐→100-150 / ⭐⭐⭐⭐→250-400 / ⭐⭐⭐⭐⭐→500-800 字 + V37.8.6 同款反幻觉守卫 (严禁虚构 / 严禁推断平台状态 / 严禁把错误日志当外部信号) (C) parse_5field_output emit + LLM_DEGRADED 用 arxiv abstract 兜底 (替代 V37.9.36 占位符反模式 `贡献：AI领域相关研究`+`价值：⭐⭐⭐`) + 多窗口切片 ≤8000 单段直发 / >8000 mktemp + sleep 1s + `[i/N]` + `(续)` 续段 + 三档 status (ok / partial_degraded / llm_failed → exit 1 fail-fast 顺序锁) + L2 解析率<0.5 检查废弃 (partial_degraded 替代). ④ **arxiv-specific 适配**: URL 格式 `https://arxiv.org/abs/{arxiv_id}` 保留 / MAX_PAPERS=10 保留 (vs HN 5) / arxiv API 完整 abstract → LLM_DEGRADED fallback 用 `abstract[:300]` (S2 用 tldr+abstract / DBLP 用 title+venue 元数据 / HN 用 description) / 保留 ontology_filter Discord #ontology 单独推送 (line 622+ 不动, 它读 PAPERS_FILE 不读 LLM 输出) / 保留 KB write source name 'arxiv-ai-models' / 保留 NEW_IDS_FILE → SEEN_FILE 推送成功后才标记 invariant. ⑤ **22 新单测 3 类** test_v37_9_43_arxiv.py: TestArxivV9_43ShellGuards(17 含 V37.9.43 marker / source notify / send_alert / [SYSTEM_ALERT] arxiv_monitor / __LLM_HTTP_ERROR__ / __LLM_PARSE_FAIL__ / call_llm_single_with_retry / backoffs=(5 10 20) / for attempt in 0 1 2 / 主循环 per-paper / status:llm_failed / status:partial_degraded / all_failed_ / [LLM_DEGRADED] / 5 字段 emoji 全套 / 严禁虚构 / 评级动态长度 / 多窗口阈值 8000 + 4000 + sleep 1s + [i/N] + 续 / 全部失败分支 500 字符内 exit 1 顺序锁 / V37.9.36 占位符 line-by-line 跳过注释 / V37.8 老 3 字段 emit `msg_lines.append(stars)` 已清除 / 老 L2 `parse_quality_low` status 废弃) + TestArxivLlmDegradedFallback(3 含 abstract 兜底 + 无 abstract 显式说明 + arxiv URL 格式保留) + TestArxivInAuditAligned(3 含 ALIGNED_SCRIPTS V37.9.43 锚点 + count ≥9 + audit_script aligned=True+version=V37.9.43+findings=0). **反向验证已确认守卫真有效**: sed 把 `⚠️ [LLM_DEGRADED] 深度分析失败...` 改回 `贡献：AI领域相关研究` → `test_no_placeholder_fallback_text` 立即在 L519 报失败 + 行号定位精确, 还原后 22/22 全过. ⑥ **INV-LLMCRON-AUDIT-001 扩展 16→17 checks**: 新增 `ALIGNED_SCRIPTS 含 V37.9.43 arxiv_monitor 锚点` file_contains 守卫. ⑦ **audit 报告刷新**: 21 候选 / 8→9 已对齐 / 13→12 未对齐 / 10→**7 placeholder findings** (arxiv 移除 3). 下次 V37.9.44+ 候选: hf_papers (P1 剩唯一 / 3 findings, 同款机械迁移) → P2 acl_anthology / karpathy_x / openclaw_official×2. ⑧ **累计**: 61→62 suites (+1: v37_9_43_arxiv) / 2192→2214 tests (+22) / 0 fail / governance 552→553 checks (+1: V37.9.43 ALIGNED_SCRIPTS 锚点) / 71 invariants 不变 / 16 meta rules / 安全 95/100 / VERSION 0.37.9.42→0.37.9.43. ⑨ **元价值**: V37.9.36 audit 立 → V37.9.39 S2 → V37.9.40 DBLP+AI Leaders X → V37.9.41 HN → V37.9.43 arxiv_monitor = **48h 内五阶段连环兑现**, ALIGNED_SCRIPTS **4→5→7→8→9** 是机器化进度证据 vs"靠记忆". MR-8 跨 job 同步 fail-fast 兑现 — V37.9.36/37/38/39/40/41 的工作让 V37.9.43 不需要重新设计 fail-fast 模式, 直接复用 + arxiv-specific 适配 (abstract fallback / URL 格式 / 保留 ontology_filter). 用户视角原则 #13 第 13 次正向兑现. ⑩ **Mac Mini 部署效果**: arxiv_monitor cron 每 3h 整点 HKT (8 次/天). 部署 V37.9.43 后下次 cron 自动用新 5 字段格式. 如 LLM 故障 → 推 [SYSTEM_ALERT] + status:llm_failed + exit 1 (与 S2/DBLP/AI Leaders/HN/rss_blogs 同款行为). |
| V37.9.42 | 2026-05-09 | **HN V37.9.41 三个 bash 整数处理 hotfix（Mac Mini 实测发现）** — V37.9.41 部署后 23:51 用户手动跑 HN 报 (a) `调用 LLM 分析条 1/       1` (BSD wc -l 含前导空格) (b) `Traceback IndexError list index out of range line 13` (dedup `print('\n'.join([]))` 输出 '\n' 让 wc -l=1 但实际无 JSON, 后续 prompt Python `items[0]` 越界) (c) `已推送 0\n0 条` (grep -c 无匹配 exit 1 → `\|\| echo 0` 双输出). 三处最小修复: line 151 `wc -l` 改 `tr -d '[:space:]'` + 新增 `NEW_JSON_COUNT=$(grep -c '^{' "$NEW_FILE")` 精确计数 valid JSON 行 + early-exit 守卫防 `print('\n'.join([]))` 空行陷阱; line 481 `SENT_COUNT=$(grep -c ...) \|\| SENT_COUNT=0` 替代 `\|\| echo 0` 单 stdout. **MR-10 三问严格执行**: Q1 部分历史问题 (BSD wc, grep exit code) 但 V37.9.41 per-paper iteration 让其首次实际触发 / Q2 V37.9.41 引入了主要血案路径 / Q3 最小修复 = 3 处 + early-exit, 不引入新概念. **bash -n + full_regression 61/0/2192 通过**. 上游 LLM 502 (Qwen3+gemini 双故障 5/8 23:51 复发, 同 V37.9.36 / 5/7 18:00 / 5/8 07:30 同款 — 这是上游 infra 问题非 V37.9.41 代码 bug, fail-fast 正确触发). 累计: 61 suites / 2192 tests / 0 fail / 552 checks / 71 inv / 安全 95/100 / VERSION 0.37.9.41 → 0.37.9.42.|
| V37.9.41 | 2026-05-08 | **HN 5 字段深度迁移 (V37.9.40 同款扩展, ALIGNED_SCRIPTS 7→8)** — 用户视角原则 #13 第 12 次正向兑现 — V37.9.40 部署后用户立即看 HN 推送也是浅 4 字段格式（zh_title/链接/要点/价值⭐⭐⭐），明确要求"HN 也参照 S2 详细分析"。① **触发**: HN 老 V38 batch 单调 LLM 调用 + 4 字段输出 + `stars='⭐⭐⭐'` silent fallback (V37.9.36 反模式 audit 没抓到的特殊形态 — pattern 是 `'⭐⭐⭐'` 字面量不带"价值："前缀, 不在 PLACEHOLDER_PATTERNS). ② **scope 决策**: 完整 V37.9.40 同款 fail-fast + 5 字段, 但 HN-specific 适配 (RSS fetch/dedup/inbox 全部保留, 替换 LLM 调用 + emit + push 段, 大型 Python heredoc 重写). MR-10 三问严格执行: 之前存在 ✓ (audit P3 score 3/6) / 我引入 ✗ (历史 V38) / 最小修复 = 完整 V37.9.40 模式 (5 字段 + LLM_DEGRADED + 多窗口 + send_alert helper entangled). ③ **3 阶段迁移 (385→578 行 +50%)**: (A) 头部 NOTIFY_SH + send_alert helper (与 S2/DBLP 同款) (B) **替换 line 131-298 大块 Python heredoc**: call_llm_single_with_retry helper (V37.9.40 同款 5/10/20s × 3 + 三层检测) + per-tweet 主循环 + 5 字段 prompt 适配 HN posts (📌中文标题/🔑核心要点/💡技术深度解读/🎯实践启发/⭐评级 + "(基于标题与摘要推断)" caveat 类似 DBLP 因 HN 摘要常缺失) + V37.9.36 同款反幻觉守卫 + Qwen3 <think>/ANSI 清理保留 (HN 早期 输出兼容) (C) 替换 emit (parse_5field_output + LLM_DEGRADED 用 HN description 兜底替代老 stars='⭐⭐⭐' 占位符 + 多窗口 [i/N] (续) 触发 >8000 字 + sleep 1s 防乱序 + KB source line 用 rating 而非旧 4 字段). ④ **HN-specific 适配**: max 5 items/run (HN limit) + RSS hnrss.org/frontpage 不变 + KEYWORDS 60+ AI/tech 关键词不变 + Python dedup + inbox 写入提前 (Fix1 V23) 不变 + 老 ERR_MSG ('HN Watcher LLM调用失败') 替换为 send_alert helper ([SYSTEM_ALERT] hn_watcher LLM 失败). ⑤ **21 新单测 3 类** test_v37_9_41_hn.py: TestHnV9_41ShellGuards(15 含 V37.9.41 marker / source notify / send_alert / [SYSTEM_ALERT] / __LLM_HTTP_ERROR__ / __LLM_PARSE_FAIL__ / call_llm_single_with_retry / backoffs=(5 10 20) / for attempt in 0 1 2 / per-item 主循环 / 三档 status / all_failed_ / [LLM_DEGRADED] / 5 字段 emoji 全套 / 严禁虚构 / HN-specific (基于标题与摘要推断) caveat / 评级动态长度 / 多窗口 8000+4000+sleep 1s+(续)+[i/N] / V37.9.36 占位符 stars='⭐⭐⭐' 严禁 + point=title[:40] 严禁 / V37.8 老 4 字段 emit 已清除) + TestHnLlmDegradedFallback(2 含 desc 兜底 + 无 desc 显式说明) + TestHnInAuditAligned(3 含 ALIGNED_SCRIPTS V37.9.41 锚点 + count ≥8 + audit_script aligned=True+version=V37.9.41+findings=0). ⑥ **V37.4.3 历史 test 兼容**: test_tool_proxy.TestNotifyShAlertMarker.test_hn_err_path_has_marker 放宽断言接受 V37.9.41 send_alert helper 字面量 ("hn_watcher LLM 失败") 或 V37.4.3 旧 inline ("HN Watcher LLM调用失败"), 维持向后兼容. ⑦ **governance INV 修复 LLM_FAILED legacy pattern**: 旧 INV-QUOTA-001 用 file_contains pattern: "LLM_FAILED" 检 V38 老 __LLM_FAILED__ marker, V37.9.41 替换为 V37.9.36 三层 markers, pattern 升级为 regex `(?:__LLM_HTTP_ERROR__|__LLM_PARSE_FAIL__|"status":"llm_failed")` 接受 V37.9.41 任一标志. ⑧ **INV-LLMCRON-AUDIT-001 扩展 16→17 checks**: 新增 ALIGNED_SCRIPTS 含 V37.9.41 锚点守卫. ⑨ **audit 报告刷新**: 21 候选 / 7→8 已对齐 / 14→13 未对齐 / 10 placeholder findings 不变 (HN 之前 audit 0 findings 因 pattern miss). ⑩ **累计**: 60→61 suites (+1: v37_9_41_hn) / 2171→2192 tests (+21) / 0 fail / governance 551→552 checks (+1) / 71 invariants 不变 / 17 meta rules / 安全 95/100 / VERSION 0.37.9.40→0.37.9.41. ⑪ **下次 V37.9.42+ 候选** (按 audit 报告剩余优先级): (a) **P1 续 (3 findings each)**: hf_papers / arxiv_monitor — 与 V37.9.39 S2 完全同款 copy-paste 模式机械迁移 (b) **P2 (1 finding)**: acl_anthology / karpathy_x / openclaw_official×2 (c) **P3 (0 findings 但缺 fail-fast 标志)**: chaspark / github_trending / ontology_sources / kb_inject / kb_dream / freight_watcher / finance_news (d) **auto_deploy cp 原子化** (V37.9.41+ P1 timing race 实证修复, today commit `9715256` 候选已登记) (e) **运行时验证**: 5/9 早 V37.9.30 EPERM 数据回归 + 5/11 决策窗口. ⑫ **Mac Mini 部署效果**: HN cron 每 3h:45 (8:45/11:45/14:45/17:45/20:45/23:45 HKT 6 次/天). 部署 V37.9.41 后下次 cron 自动用新 5 字段格式. 如 LLM 故障 → 推 [SYSTEM_ALERT] + status:llm_failed + exit 1 (与 S2/DBLP/AI Leaders/rss_blogs 同款). ⑬ **元价值**: 同日 V37.9.38 audit 立 → V37.9.39 S2 → V37.9.40 DBLP+AI Leaders → V37.9.41 HN = **24h 内四阶段连环兑现**, ALIGNED_SCRIPTS **4→5→7→8** 是机器化进度证据 vs"靠记忆"。MR-8 跨 job 同步 fail-fast 兑现 — V37.9.36/37/38/39/40 的工作让 V37.9.41 不需要重新设计 fail-fast 模式, 直接复用 + HN-specific 适配 (基于标题与摘要推断 caveat 因 HN 摘要常缺失). audit 模块从"视野工具"升级为"驱动器"持续兑现 — 每次 PoC fix 推 ALIGNED_SCRIPTS 数, 每次都有 user feedback 立即兑现。|
| V37.9.40 | 2026-05-08 | **DBLP + AI Leaders X 双脚本批次 5 字段深度迁移 (V37.9.39 同款 V37.9.36-37 模式横向扩展, 用户视角原则 #13 第 11 次正向兑现)** — ① **触发**: V37.9.39 部署 + S2 真实推送验证后用户立即提"DBLP CS论文精选 和 AI Leaders 技术洞察 也按 S2 格式优化". ② **scope 决策**: 双脚本批次 (V37.9.39 单脚本 PoC 已验证 + 同款机械迁移 + 用户明确双脚本要求 + 单 commit + Mac Mini E2E 一次验证两个脚本). 按 MR-10 三问严格执行: Q1 之前存在 ✓ (audit P2 已识别) / Q2 我引入 ✗ (历史 copy-paste) / Q3 最小修复 = 完整 V37.9.36-37 模式横向迁移 (5 字段 + LLM_DEGRADED + fail-fast entangled, 不能拆开). ③ **DBLP 迁移 (3 阶段 edit, 451→657 行 +46%)**: (A) 头部 NOTIFY_SH 自发现 + send_alert helper (B) call_llm_single_with_retry helper (5/10/20s × 3) + per-paper 主循环 + V37.9.36 三层检测 + 5 字段 prompt 适配无 abstract (DBLP 数据库无 abstract, prompt 加显式"基于标题推断"caveat + 推断时必须显式标注 + 严禁虚构论文中的具体数据/实验结果) (C) parse_5field_output emit + LLM_DEGRADED 用 标题+venue 元数据兜底 (DBLP 无 abstract 时是最低保障 + 用户至少看到论文 metadata + 链接) + 多窗口切片 [i/N] (续). ④ **AI Leaders X 迁移 (3 阶段 edit, 454→665 行 +46%)**: (A) 头部 NOTIFY_SH + send_alert (与 DBLP/S2 同款) (B) per-tweet retry helper + 5 字段 prompt 适配 tweet 上下文: 📌 中文主题 (≤15 字, twitter 上下文短) / 🔑 核心观点 (推文作者论点) / 💡 技术深度解读 (按评级动态长度: 揭示作者立场+技术背景+为什么重要+与已有讨论关联+局限性) / 🎯 系统启示 (对 Agent Runtime/Control Plane/Memory 的启示, 1-3 条) / ⭐ 评级 + 推荐场景. 替代老 V37.8 文字 prefix (主题/深度分析/系统启示/行动建议/价值) batch 调用 (C) emit 重写: parse_5field_output 适配 ⭐ tweet header (━━━ [author] title ━━━) + LLM_DEGRADED 用推文原文 (text_preview 200 chars) 兜底 + 多窗口 [i/N]. ⑤ **17 新单测 3 类** test_v37_9_40_dblp_ailead.py: TestDblpV9_40Guards(6 含 V37.9.40 共用守卫 + 占位符严禁 + 基于标题推断 caveat + 元数据兜底 + DOI 链接优先 + 📚 emoji + 多窗口 header) + TestAiLeadersV9_40Guards(6 含共用守卫 + 占位符严禁 + 老 5 行格式清除 + tweet metadata 保留 + 推文原文兜底 + 🧠 emoji + 多窗口 header) + TestV9_40InAuditAlignedScripts(5 含 ALIGNED_SCRIPTS ≥7 + DBLP V37.9.40 锚点 + AI Leaders X V37.9.40 锚点 + audit_script DBLP aligned + audit_script AI Leaders X aligned). 共用 _common_v37_9_40_guards() helper 测两脚本 fail-fast 模式 (V37.9.40 marker / source notify / send_alert / [SYSTEM_ALERT] / __LLM_HTTP_ERROR__ / __LLM_PARSE_FAIL__ / call_llm_single_with_retry / backoffs=(5 10 20) / for attempt in 0 1 2 / per-item 主循环 / status:llm_failed / status:partial_degraded / all_failed_ / [LLM_DEGRADED] / 5 字段 emoji 全套 / 严禁虚构 / 多窗口阈值 8000+4000+sleep 1s+续 / 全部失败 500 字符内 exit 1 顺序锁 / 老 3 字段 prompt 已清除). ⑥ **INV-LLMCRON-AUDIT-001 扩展 15→16 checks**: 新增 ALIGNED_SCRIPTS 含 V37.9.40 锚点 file_contains 守卫. ⑦ **audit 报告刷新**: 21 候选 / 5→7 已对齐 / 16→14 未对齐 / 12→10 placeholder findings (DBLP -3 + AI Leaders X -1 = -4 但 audit 之前在 AI Leaders X 已 silent fail 模式所以净 -2 真实). ⑧ **累计**: 59→60 suites (+1 v37_9_40_dblp_ailead) / 2154→2171 tests (+17) / 0 fail / governance 550→551 checks (+1 V37.9.40 ALIGNED_SCRIPTS 锚点) / 71 invariants 不变 / 17 meta rules / 安全 95/100 / VERSION 0.37.9.39→0.37.9.40. ⑨ **下次 V37.9.41+ 候选** (按 audit 报告剩余优先级): (a) **P1 续 (3 findings each)**: hf_papers / arxiv_monitor — 与 V37.9.39 S2 完全同款 copy-paste 模式, 机械迁移 (b) **P2 (1 finding)**: acl_anthology / karpathy_x / openclaw_official×2 (c) **P3 (0 findings 但缺 fail-fast 标志)**: chaspark / github_trending / ontology_sources / kb_inject / kb_dream / freight_watcher / finance_news / run_hn_fixed (d) **运行时验证**: 5/9 早 V37.9.30 EPERM 24h 数据回归 + 5/11 决策窗口 jobs_to_crontab + kb_sources_to_index machine_sync 真激活. ⑩ **Mac Mini 部署效果**: DBLP cron 12:00 HKT (今日已跑) + AI Leaders X cron 09:00/21:00 HKT. 部署 V37.9.40 后下一次 cron 自动用新 5 字段格式. 如 LLM 故障 → 推 [SYSTEM_ALERT] + status:llm_failed + exit 1 (与 S2/rss_blogs 同款行为). ⑪ **元价值**: 同日内 V37.9.38 audit 立 → V37.9.39 第一 PoC fix → V37.9.40 双脚本批次扩展 = 24h 内三阶段连环兑现 framework 价值. **audit 模块从"视野工具"升级为"驱动器"**, 每次 PoC fix 推 ALIGNED_SCRIPTS 数 (4→5→7) 是机器化进度证据 vs"靠记忆"。MR-8 跨 job 同步 fail-fast 兑现 — V37.9.36/37/38/39 的工作让 V37.9.40 不需要重新设计 fail-fast 模式, 直接复用 + 适配 (DBLP 无 abstract caveat / AI Leaders X tweet metadata). ⑫ **下次 V37.9.41+ 用户视角观察项**: (a) DBLP 5 字段在无 abstract 限制下深度是否够用 (caveat "基于标题推断" LLM 是否真的标注) (b) AI Leaders X 5 字段在 tweet 短文本上下文是否过度膨胀 (推文 280 字符 → 5 字段输出 800-2000 字, 比例 5-10x) (c) S2 V37.9.39 + DBLP/AI Leaders V37.9.40 三 task 多日推送质量 (LLM variance / 缺字段 / prompt 字面量泄漏) 收敛模式. |
| V37.9.39 | 2026-05-08 | **V37.9.38 audit 工具识别 P1 第一个 PoC fix — semantic_scholar 5 字段深度迁移（V37.9.36-37 rss_blogs 模式横向扩展, 用户视角原则 #13 第 10 次正向兑现）** — ① **触发**：V37.9.38 audit 工具部署到 Mac Mini 后, 同日下午用户在 WhatsApp 看到当日 S2 高引论文推送内容浅薄（标题+作者+引用+一句话贡献+`价值：⭐⭐⭐⭐`）, 直接反馈"这个分析的也比较浅，请按照昨天 rss_blogs 任务格式继续优化"。② **scope 决策（按 MR-10 三问）**：Q1 之前存在? ✓（audit 报告中 S2 是 P1, 3 placeholder findings + 0/6 score） / Q2 是否新引入? ✗（历史 copy-paste from arxiv_monitor pattern） / Q3 最小修复? = **完整 V37.9.36-37 rss_blogs 模式横向迁移**（不只是改 prompt 加深度, 因为 5 字段 + LLM_DEGRADED + fail-fast 是 entangled — 不加 fail-fast 意味着 LLM partial parse 失败时 placeholder 仍会回归, 不加 LLM_DEGRADED 意味着失败篇没有用户可读 fallback）。③ **5 阶段迁移（incremental edit, bash -n 验证 + audit 工具实时验证）**：(A) 头部加 NOTIFY_SH 自发现 + send_alert helper（含 `[SYSTEM_ALERT]` 前缀, V37.4.3 PA 上下文隔离 + V37.9.36 同款模式）(B) 替换 LLM 调用 (line 179-249 → V37.9.37 同款 call_llm_single_with_retry helper, 5/10/20s 指数退避 × 3 + V37.9.36 三层检测 `__LLM_HTTP_ERROR__:` / `__LLM_PARSE_FAIL__:bad_json:` / `__LLM_PARSE_FAIL__:no_choices:` / empty content + per-paper 主循环 `for ((i=0; i<TOTAL_NEW; i++))` + 5 字段深度 prompt 适配论文 metadata `📌 中文标题 / 🔑 核心贡献 / 💡 关键方法 / 🎯 实践启发 / ⭐ 评级` + 按评级动态长度 ⭐⭐⭐→100-150 / ⭐⭐⭐⭐→250-400 / ⭐⭐⭐⭐⭐→500-800 字 + V37.8.6 同款反幻觉守卫 严禁虚构 + 严禁推断平台状态 + 严禁把错误日志当外部信号）(C) 替换 emit (line 251-373 → 5 字段 key-based parser `parse_5field_output()` 容忍字段顺序错乱/单字段缺失/prefix 变体 + LLM_DEGRADED fallback 含 `[LLM_DEGRADED] 深度分析失败, 论文摘要供参考:` + tldr/abstract 兜底 替代 V37.9.36 `贡献：AI领域相关研究`+`价值：⭐⭐⭐` 占位符反模式) (D) 多窗口切片 (≤8000 单段直发 / >8000 触发 mktemp + sleep 1s 防 WhatsApp 乱序 + `[i/N]` 标识 + `(续)` 续段) (E) status_file schema 升级 三档 `ok` / `partial_degraded` (失败篇 ≥1 但 <N 全部) / `llm_failed` (全部失败 → exit 1)。④ **S2 特定适配**：保留引用次数（论文 metadata 不变）+ 优先 arxiv 链接 + tldr 优先 abstract（S2 native TLDR 更简洁）+ first_author 字段 + 保留 ontology_filter Discord #ontology 单独推送（line 375-393 不动, 它读 PAPERS_FILE 不读 LLM 输出）。⑤ **37 单测 4 类** test_run_semantic_scholar_v37_9_39.py: TestS2ShellGuardsV9_39(28 含 V37.9.39 marker / source notify.sh / send_alert / [SYSTEM_ALERT] / __LLM_HTTP_ERROR__ / __LLM_PARSE_FAIL__ / call_llm_single_with_retry / backoffs=(5 10 20) / for attempt in 0 1 2 / 主循环 per-paper / status:llm_failed / status:partial_degraded / all_failed_ prefix / [LLM_DEGRADED] / 5 字段 emoji 全套 / 严禁虚构 / 评级动态长度 / 多窗口阈值 8000 + 4000 + sleep 1s + [i/N] + 续 / 全部失败分支 500 字符内 exit 1 顺序锁 / V37.9.36 占位符 line-by-line 跳过注释 / V37.8 老 3 字段 prompt 已清除) + TestEmit5FieldParser(2 parse_5field_output 函数 + 5 key dict 完整性) + TestActualBloodLessonScenarioRegression(2 V37.9.36 反模式三个变体严格清除 + LLM_DEGRADED + tldr/abstract 兜底逻辑) + TestS2InAuditAlignedScripts(3 ALIGNED_SCRIPTS 含 S2 V37.9.39 + count ≥5 + audit_script(S2) returns aligned=True+version=V37.9.39+findings=0). **反向验证已确认守卫真有效**：sed 把 `贡献：AI领域相关研究` 注入回 LLM_DEGRADED 块 → `test_no_placeholder_fallback_text` 立即 L511 抓到 + `test_v37_9_39_fallback_uses_explicit_degraded_marker` 立即报失败, 还原后 37/37 全过。⑥ **INV-LLMCRON-AUDIT-001 扩展守卫 14→15 checks**：新增 `ALIGNED_SCRIPTS 含 V37.9.39 锚点` file_contains 守卫防止未来 V37.9.40+ 误删 S2 entry。⑦ **audit 报告刷新**：21 候选 / 4 已对齐→**5 已对齐** / 17 未对齐→**16 未对齐** / 15 placeholder findings→**12** (S2 移除 3)。下次 V37.9.40+ 候选按报告 P1: hf_papers / arxiv_monitor 各 3 findings (与 S2 同款 pattern 应用机械迁移)。⑧ **累计**：58→59 suites (+1: run_semantic_scholar_v9_39) / 2117→2154 tests (+37) / 0 fail / governance 549→550 checks (+1: V37.9.39 ALIGNED_SCRIPTS 锚点守卫) / 71 invariants 不变 / 17 meta rules / 安全 95/100 / VERSION 0.37.9.38 → 0.37.9.39。⑨ **元价值**：V37.9.38 audit 工具部署后 < 6 小时即驱动 V37.9.39 第一个 PoC fix — 验证"audit + 视野 + 路线图"三件套不是空头, 而是真实驱动产品质量提升的 framework。原则 #13 第 10 次正向兑现 — 用户在 WhatsApp 实际收到当日推送 → 立即识别质量缺口 → 立即对齐已建立模式（rss_blogs reference）→ 单 session 完整闭环（migrate + 守卫 + 反向验证 + commit）。MR-8 跨 job 同步 fail-fast 兑现 — V37.9.36/37/38 的工作让 V37.9.39 不需要重新设计 fail-fast 模式, 直接复用。⑩ **下次 V37.9.40+ 候选**：(a) **P1 续**: hf_papers / arxiv_monitor (各 3 findings, 与 S2 完全同款 copy-paste 模式, 机械迁移即可) (b) **P2**: dblp / acl_anthology / ai_leaders_x / karpathy_x / openclaw_official×2 (1 finding each, 同款适配) (c) **P3**: 8 个无 finding 但缺 fail-fast 标志脚本 (d) **运行时验证**: V37.9.30 EPERM 24h 数据回归 (5/9 早 截止, 还剩 1 天) + V37.9.35 推送质量观察 + 5/11 决策窗口 jobs_to_crontab + kb_sources_to_index machine_sync 真激活。⑪ **Mac Mini 部署效果**：S2 cron 每天 11:00 HKT 触发, 部署 V37.9.39 后立即生效。下次（明天 5/9 11:00）用户应在 WhatsApp 看到 5 字段深度分析的 S2 推送（10 篇旗舰可能触发多窗口分片为 2 段）。如 LLM 故障 → 推 [SYSTEM_ALERT] + status:llm_failed + exit 1（与 rss_blogs V37.9.36 同款）。|
| V37.9.38 | 2026-05-08 | **双交付：① status_update.py 双路径 bug 闭环 (V37.9.36 候选) + ② LLM cron fail-fast audit 视野+预防+路线图三件套 (V37.9.36 教训横向扩展)** — ① **P1 status_update 双路径 bug**（V37.9.36 候选登记的开工/收工闭环 bug）：实测 `data["unfinished"]` (顶层 32 项) vs `data["session_context"]["unfinished"]` (13 项 schema 真理源) 长期分叉 45 项。`--add unfinished <item>` 写顶层但 `--read --human` 读 session_context → 收工 add 的 todo 开工读不到（V37.9.35→V37.9.36 实证）。**最小修复**：(a) 新增 `_resolve_array_target(data, name)` 把 unfinished 重定向到 session_context（其他数组照常顶层）(b) 新增 `_migrate_top_level_unfinished(data)` 在 `load_status` 时合并去重 + 删顶层（in-memory，下次 save 持久化为单一路径）(c) `args.add/pop/clear` 三处统一走 helper（V37.9.36 反模式禁止）(d) `format_human` 把 unfinished list 逐项展开（≤220 字符截断 + "还有 N 项"）(e) 历史字符串 session_context.unfinished 自动转 list（DEFAULT_STATUS legacy）。**26 新单测 4 类 + 反向验证守卫真有效**（sabotage --add 回退到 data[array_name] → TestSourceLevelGuards 立即失败 + TestEndToEndAddUnfinishedSubprocess 真 subprocess 跑也立即失败）：TestResolveArrayTargetSpecialCase(6) + TestMigrationFromTopLevel(8) + TestEndToEndAddUnfinishedSubprocess(4 含**血案场景复现** 收工 add 3 项 → 开工 read 必含 3 项 + 计数) + TestSourceLevelGuards(8)。② **P2 V37.9.38 LLM cron audit 三件套**（V37.9.37 收工 73b2248 已登记 → V37.9.36 教训"扫所有调 LLM 的 cron job 是否对齐 fail-fast 模式" + MR-8 跨 job 不同步是 copy-paste-is-a-bug-class 兑现）：发现 5 个 Tier-A 脚本（hf_papers/arxiv_monitor/finance_news/run_hn_fixed/openclaw_official）共享同款 V37.9.36 反模式（占位符 fallback `价值：⭐⭐⭐` + `贡献：AI领域相关研究` + `要点：技术深度文章`）。今日交付：(a) **`ontology/llm_cron_audit.py` 扫描器**（pure Python 行级启发式 + prompt 模板豁免 + 三种字面量上下文 quoted_inline / shell_multiline_close / py_assignment_open）扫 21 候选脚本 → 4 已对齐（V37.5 kb_review / V37.8.10 kb_evening / V37.9.16 kb_deep_dive / V37.9.36-37 rss_blogs）+ 17 未对齐含 15 placeholder findings (b) **`docs/llm_cron_fail_fast_audit.md`** 完整报告（21 候选 P1/P2/P3 三档优先级 + V37.9.39+ 修复路线图） (c) **INV-LLMCRON-AUDIT-001 守卫**（meta_rule=MR-8, severity=high, verification_layer=[declaration, runtime], **13 checks**）：11 declaration file_contains/python_assert（audit 模块 V37.9.38 标记 / 4 个公开 API 函数定义 / ALIGNED_SCRIPTS 含 4 个版本锚点 / PLACEHOLDER_PATTERNS 含 V37.9.36 血案 3 个核心字符串 / audit 报告 21 候选 + V37.9.38+ 路线图 / test 文件 V37.9.38 标记）+ 2 runtime python_assert（subprocess 真跑 audit --report 验证 4 个 ALIGNED 版本被识别 / subprocess 跑 26 单测全过）(d) **26 新单测 6 类**：TestPlaceholderPatterns(2) + TestFindPlaceholderFindings(9 含 prompt 模板豁免 / shell 多行字符串闭合 / Python 三引号块豁免 / 注释豁免 / quote 包裹三种上下文) + TestAuditScript(3) + TestAlignedScriptsRecognition(3 含 endswith 路径归一化让绝对路径也能匹配) + TestMarkdownReport(1) + TestCliCheckMode(3) + TestSourceLevelGuards(5)。③ **arxiv_monitor PoC fix 推迟 V37.9.39+**（MR-10 三问严格执行）：Q1 之前存在 ✓ / Q2 非新引入 ✓ / Q3 最小修复 = **不引入新 bug** — 350+ 行脚本一次性大改风险高（V37.9.34 cascade hotfix 教训），audit + 防御 + 路线图已是完整 V37.9.38 deliverable，PoC 留给 V37.9.39 新 session 全力投入 + Mac Mini E2E 真跑数据回归。④ **MR-8 兑现**：未来 V37.9.39+ 每次升级 N 个 LLM cron 时，`python3 ontology/llm_cron_audit.py --report` 立即知道剩余多少不合规 + 风险分级，从"靠记忆"升级为"机器化 visibility"。⑤ **累计**：56→58 suites (+2) / 2065→2117 tests (+52: status_update_v9_38 26 + llm_cron_audit 26) / 0 fail / governance 535→549 checks (+14: INV-LLMCRON-AUDIT-001) / 70→71 invariants (+1) / 17 meta rules / **MRD-LAYER-002 41/41 high 全部 ≥2 层** / 安全 95/100 / VERSION 0.37.9.37 → 0.37.9.38. ⑥ **下次 V37.9.39+ 候选**（按 audit 报告优先级）：(a) **P1 (≥2 findings)**: arxiv_monitor / hf_papers / semantic_scholar 各 3 findings — 最高优先级，daily cron 高频 (b) **P2 (1 finding)**: dblp / acl_anthology / ai_leaders_x / karpathy_x / openclaw_official×2 (c) **P3 (0 findings 但缺 fail-fast 标志)**: chaspark / github_trending / ontology_sources / kb_inject / kb_dream / freight_watcher / finance_news / run_hn_fixed (d) **运行时验证**: V37.9.30 EPERM 24h 数据回归 (5/9 早 截止) + V37.9.35 推送质量 24-48h 观察 + 5/11 决策窗口 jobs_to_crontab + kb_sources_to_index machine_sync 真激活。⑦ **元价值**: 一日内同时收敛"开工/收工流程内部 bug" (P1) + "跨 job 系统性 silent failure 视野" (P2) — 验证 V37.9.36 fail-fast 模式不只是 rss_blogs 单点修复, 而是项目级架构契约。原则 #18 "补证据而非补功能" 兑现 — 不增 cron 不增功能, 但每次 LLM cron 升级现在有了"机器化 visibility". 原则 #28 "理解再动手" 严格执行 — PoC 推迟避免 V37.9.34 cascade 教训复现。|
| V37.9.37 | 2026-05-07 | **rss_blogs 深度分析升级（用户反馈"博客精选都是值得读的好文章, 不能只是题目摘要"）+ V37.9.36 fail-fast 契约保留** — ① **触发**: V37.9.36 闭环后用户立即提产品深度需求 — "请把生成的内容和分析的内容尽量多一些 不能仅仅是题目或摘要", 同时强调 V37.9.35 已把 WhatsApp budget 升到 4000 + 多窗口能力具备, 可以放开手脚生成长内容. 用户视角原则 #13 第 9 次正向兑现 (V37.9.36 闭环后立即触发产品升级). ② **设计选择 (用户决策)**: 深度档位 = "混合 5 字段 + 按评级动态调长度" (⭐⭐⭐→100-150字 / ⭐⭐⭐⭐→250-400字 / ⭐⭐⭐⭐⭐→500-800字 旗舰级充分展开); LLM 失败行为 = "每篇独立 retry, 部分失败用 RSS description fallback 标 [LLM_DEGRADED]". ③ **5 字段 prompt 重写** (line 217-282): 📌 中文标题 (信达雅翻译 ≤25字) / 🔑 核心要点 (3-5 条 bullet 每条 ≤60字) / 💡 关键洞察 (按评级动态长度, 揭示作者立场+方法论+行业趋势关联+与已有工作对比+局限性) / 🎯 实践启发 (1-3 条对 AI 工程师/创业者/架构师的具体行动建议) / ⭐ 评级 + 推荐场景 (谁应该读 / 何时读 / 配什么场景). 含 V37.8.6 同款反幻觉守卫 ("严禁虚构作者未提及的事实/数据/链接 / 严禁推断 Hugging Face/OpenAI/GitHub 等平台的具体内部状态除非原文提及 / 严禁把 HTTP 错误码/Python 异常/错误日志当外部信号"). 原文摘要长度从 300 → 600 字给 LLM 更多上下文. ④ **LLM 调用策略重写**: V37.9.36 单次调用全部 N 篇 → V37.9.37 每篇独立调用 + 独立 retry (5s/10s/20s 指数退避). 新 helper `call_llm_single_with_retry()` 函数封装单篇 LLM 调用 + 三层失败检测 (V37.9.36 contract 复用) + 3 attempts. 主循环 `for ((i=0; i<TOTAL_NEW; i++))` 调用 helper, 收集结果到 `$RESULTS_FILE` (jsonl: idx/content/failed/fail_reason). max_tokens 从 4096 → 2500 (单篇够用 + 节省 token). ⑤ **失败语义细化**: V37.9.36 任一失败 → fail-fast → V37.9.37 三档 status: (a) 全部成功 → `status:ok` (b) 部分失败 → `status:partial_degraded` + `failed:N` 字段 + `[SYSTEM_ALERT]` 通知 + 仍推送其余成功篇 (c) 全部失败 → `status:llm_failed` + `reason:all_failed_<原因>` + `[SYSTEM_ALERT]` + `exit 1` (V37.9.36 fail-fast 契约保留, 但仅当 ALL 失败才触发). ⑥ **emit 端 5 字段 key-based parser** (V37.8.7 ontology_parser 同款模式): `parse_5field_output()` 容忍字段顺序错乱 / 单字段缺失 / prefix 变体 (识别 📌/🔑/💡/🎯/⭐ emoji marker 作为字段头, state-machine 累积内容到 flush). 失败篇用 `[LLM_DEGRADED] 深度分析失败, 原文摘要供参考:` + RSS description 前 300 字兜底, 让用户至少知道有什么文章值得点链接看 (替代 V37.9.36 "（本篇 LLM 摘要缺失）"的更弱信号). 严禁占位符回归 (V37.9.36 反模式硬规则保留). ⑦ **多窗口分片复用 V37.9.21 同款** (>8000 字才触发, 否则单段直发利用 V37.9.35 客户端折叠机制): 总长 ≤4000 单段不折叠 / 4000-8000 单段客户端自动折叠 2 气泡 / >8000 多窗口切片每段 ≤4000 + `mktemp -d` + sleep 1s 防 WhatsApp 消息乱序 + 段间 header 含 `[i/N]` + `(续)` 标识让用户知道是连续的. ⑧ **44 单测 6 类** (V37.9.36 27 → V37.9.37 +17 = 44): TestRssBlogsShellGuards(24 含 V37.9.37 marker / V37.9.36 [SYSTEM_ALERT] / send_alert / source notify.sh / __LLM_HTTP_ERROR__ / __LLM_PARSE_FAIL__ / call_llm_single_with_retry helper 定义 / backoffs=(5 10 20) / for attempt in 0 1 2 / TOTAL_NEW 主循环 / status:partial_degraded / all_failed_ prefix / [LLM_DEGRADED] 标记 / [LLM_DEGRADED] 深度分析失败 完整字串 / 5 字段 emoji marker / 严禁虚构 反幻觉 / ⭐⭐⭐⭐⭐→500-800字 评级长度 / TOTAL_LEN -le 8000 阈值 / MAX_CHUNK = 4000 / 多窗口分支 sleep 1s / [i/N] header 标识 / 全部失败分支 exit 1 顺序锁 / 占位符 line-by-line 扫描跳过注释) + TestLlmResponseDetection(5 V37.9.36 detection snippet 在 retry helper 内复用语义不变) + TestEmit5Field(8 含 5 字段完整解析 / 部分失败 LLM_DEGRADED + RSS description / 全部失败标 LLM_DEGRADED / RSS description 空时提示点链接 / 5 字段容忍单字段缺失 / 字段顺序错乱不影响解析 / 任何 LLM 输入下严禁占位符回归) + TestStatusSchema(2 partial_degraded + all_failed_) + TestMultiWindowSplit(4 短消息单 chunk / 多篇 ≤4000 单 chunk / 每篇 1500x3 必触发切片 / [i/N] 标识) + TestActualBloodLessonScenario(2 502 触发 fail-fast marker + 实际 articles 部分失败用 LLM_DEGRADED 不写占位符). **反向验证已确认守卫真有效**: sed 把 emit Python 内 `[LLM_DEGRADED] 深度分析失败` 改回 `要点：技术深度文章` → `test_no_placeholder_fallback_text` 立即在 line 488 抓到 "要点：技术深度文章 unexpectedly found", 还原后 44/44 全过. ⑨ **INV-RSSBLOGS-001 扩展 14→28 checks**: V37.9.36 declaration 9 + V37.9.37 declaration 11 (V37.9.37 marker / call_llm_single_with_retry helper / backoffs=(5 10 20) / status:partial_degraded / all_failed_ prefix / [LLM_DEGRADED] 标记 / 5 字段 emoji 全套 / 严禁虚构 / 评级动态长度 / 多窗口阈值 8000 + 4000 / 多窗口 sleep 1s) + V37.9.36 python_assert 3 + V37.9.37 python_assert 2 + V37.9.36 runtime 2 + V37.9.37 runtime 2 + V37.9.36 旧 `LLM 摘要缺失` declaration 1 删除 (被 V37.9.37 [LLM_DEGRADED] 等效替代) + V37.9.36 RUNTIME emit python_assert 升级为 V37.9.37 5 字段 + LLM_DEGRADED 端到端验证 (read RESULTS_FILE marker / parse_5field_output 函数存在 / 端到端 2 篇全失败 → 两篇都标 [LLM_DEGRADED] + RSS desc fallback / 占位符严禁回归). ⑩ **累计**: 56 suites 不变 / 2048→2065 tests (+17) / 0 fail / governance 523→535 checks (+12 INV-RSSBLOGS-001 V37.9.37 守卫) / 70 invariants 不变 (扩展非新增) / 17 meta rules / 安全 95/100 / VERSION 0.37.9.36 → 0.37.9.37. ⑪ **典型预期推送长度**: 3 篇混合 (⭐⭐⭐ ~400 字 + ⭐⭐⭐⭐ ~800 字 + ⭐⭐⭐⭐⭐ ~1500 字) ≈ 2700 字, 单段直发 WhatsApp 不折叠. 3 篇都旗舰 ⭐⭐⭐⭐⭐ ≈ 4500 字, 触发多窗口分片 2 段. ⑫ **元价值**: V37.9.36 闭环 fail-fast 修复, V37.9.37 闭环产品深度升级 — 同日内"用户视角发现质量缺口 → 立即修复 + 立即升级" double 兑现, 验证 V37.9.35 budget 升级 + V37.9.21 多窗口框架的真实价值 (没有这两个底层框架就无法承载本次深度内容升级). 原则 #18 "补证据而非补功能" 兑现 — 不增加 cron 数量, 但 rss_blogs 单 job 产出价值从"标题+一句话+⭐⭐⭐"升级为"标题+核心要点+关键洞察+实践启发+评级", 信息密度跃升一个数量级. |
| V37.9.36 | 2026-05-07 | **rss_blogs LLM fail-fast 闭环（MR-4 silent-failure 第 26 次演出 + 用户视角 #13 第 8 次正向兑现）** — ① **触发**: V37.9.35 budget 升级当晚 (周四) 用户在 WhatsApp 发现 18:00 cron 推送的"📖 博客精选"3 篇文章全部显示 `要点：技术深度文章 / 价值：⭐⭐⭐` 占位符 + 来源含括号注释 `Simon Willison(LLM工具/实践)`. 单测 / 治理 / preflight 全过, 但用户视角推送质量为零. ② **Mac Mini 取证 (原则 #28 第三问"最小修复"前先看真实数据)**: `cat ~/.openclaw/jobs/rss_blogs/cache/llm_*.txt + last_run.json` 揭示 (a) `llm_raw_last.txt = '{"error":"HTTP Error 502: Bad Gateway \| upstream: primary: HTTP Error 301 Moved Permanently 无限重定向; gemini: HTTP Error 503 Service Unavailable"}'` (b) `llm_content.txt = 1 byte` (空) (c) `rss_message.txt 全部 3 篇 fallback "技术深度文章 ⭐⭐⭐"` (d) `last_run.json {"status":"ok","sent":true}` ← **谎报成功**. 真因 = Qwen3 主+gemini fallback 双 provider 同时故障 + run_rss_blogs.sh 三层宽容 (`except pass` 吞 KeyError → `log WARN 不 exit` → emit 硬编码 `要点：技术深度文章 + 价值：⭐⭐⭐` 占位符) + last_run.json 谎报 status:ok + 零 [SYSTEM_ALERT] 推送. ③ **MR-4 silent-failure 第 26 次演出新形态**: 错误日志完整保留在 llm_raw_last.txt 里 (可见层有记录), 但每一层都拒绝把它升格为告警, 最后用户成了告警链. rss_blogs 是 V36 之前老代码, V37.5 (kb_review) / V37.8.10 (kb_evening) / V37.9.16 (kb_deep_dive) 三次 fail-fast 升级时都没同步扫描 rss_blogs — MR-8 反例提醒 (跨 job 没及时同步 fail-fast 升级也是 copy-paste-is-a-bug-class). ④ **结构修复 (与 V37.5/V37.8.10/V37.9.16 同款 fail-fast 模式对齐)**: (1) `run_rss_blogs.sh` 头部加 source notify.sh + `send_alert()` helper (走统一 `[SYSTEM_ALERT]` 通道 / topic alerts → Discord #alerts) (2) LLM 调用后三层检测 (替换 line 224-236 宽容处理): **层 1** HTTP 错误响应 (`isinstance(d, dict) and 'error' in d` → `__LLM_HTTP_ERROR__:` marker) **层 2** JSON 解析失败 (KeyError/IndexError/TypeError → `__LLM_PARSE_FAIL__:no_choices:`) + bad JSON (JSONDecodeError → `__LLM_PARSE_FAIL__:bad_json:`) **层 3** 空 content. 任一触发 → `send_alert "..."` + `printf '{"status":"llm_failed","reason":"%s"}' > "$STATUS_FILE"` + `exit 1` (3) emit 端 (line 304-306) 删除 `要点：技术深度文章` + `价值：⭐⭐⭐` 占位符 fallback, 改为 `（本篇 LLM 摘要缺失，参见原文链接）` 显式标记 — 让用户感知层不被欺骗 (4) error 消息 `\n` squash 为空格防止破坏 marker 行 / truncated 500 chars 防 logspam. ⑤ **27 新单测** test_run_rss_blogs.py 4 类: TestRssBlogsShellGuards(15 含 V37.9.36 marker / [SYSTEM_ALERT] / send_alert / source notify.sh / __LLM_HTTP_ERROR__ / __LLM_PARSE_FAIL__ / status:llm_failed / "LLM 摘要缺失" / 不含"使用原始标题推送" / 不含"要点：技术深度文章" 占位符 line-by-line 跳过注释 / HTTP error 分支 500 字符内 exit 1 顺序锁 / 空 content 分支 500 字符内 exit 1 顺序锁 / emit 端显式缺失标记) + TestLlmResponseDetection(9 端到端 subprocess 真跑提取的 detection snippet 含**血案场景复现** `test_actual_502_blood_lesson_response` 输入 2026-05-07 18:00 实际 LLM_RESP 断言 stderr 含 `__LLM_HTTP_ERROR__` + primary 301 + gemini 503 / no choices / bad json / empty / 正常 / choices 空 list IndexError / choices 非 list / 多行 error 消息 squash / 500 char truncation) + TestEmitParser(4 含 full parse / partial parse 显式缺失 / 空 LLM content 全部缺失 / 任何 LLM 输入下严禁占位符) + TestActualBloodLessonScenario(2 复现完整链路: 502 触发 fail-fast 检测 + 实际 articles + 空 content → 不写占位符). **反向验证已确认守卫真有效**: sed 把 `（本篇 LLM 摘要缺失）` 改回 `要点：技术深度文章` → `test_no_placeholder_fallback_text` 立即报失败 + 行号定位, 还原后 27/27 全过. ⑥ **INV-RSSBLOGS-001 新增** (meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime], 15 checks): 9 个 declaration file_contains/file_not_contains 守卫 (V37.9.36 marker / [SYSTEM_ALERT] / send_alert / source notify.sh / `__LLM_HTTP_ERROR__` / `__LLM_PARSE_FAIL__` / status:llm_failed / "LLM 摘要缺失" / 不含 "使用原始标题推送") + 3 个 declaration python_assert (line-by-line 占位符扫描跳过注释 / HTTP error 分支顺序锁 / 空 content 分支顺序锁) + 3 个 runtime python_assert (subprocess 真跑 detection snippet 复现 502 血案 / subprocess 真跑 emit code 验证空 content 输出含 "LLM 摘要缺失" 不含占位符 / subprocess 跑 27 单测端到端). ⑦ **auto_deploy.sh FILE_MAP** 已含 `jobs/rss_blogs/run_rss_blogs.sh` (无需补齐). full_regression.sh 接入 `run_rss_blogs` suite. ⑧ **累计**: 55→56 suites (+1) / 2021→2048 tests (+27) / 0 fail / governance 506→523 checks (+17: INV-RSSBLOGS-001 15 + 2 audit-of-audit metric 漂移自适应) / 69→70 invariants (+1) / 17 meta rules / **MRD-LAYER-002 40/40 high 全部 ≥2 层** / 安全 95/100 / VERSION 0.37.9.35 → 0.37.9.36. ⑨ **Mac Mini 部署后预期行为**: 下次 LLM 双 provider 双故障时 → 18:00 cron 立即推 `[SYSTEM_ALERT] rss_blogs LLM 失败 / 原因: HTTP Error 502 \| upstream: primary 301; gemini 503 / 降级处理: 今日未推送博客精选 (避免占位符污染) / 建议: 查 Adapter/Proxy 状态 + llm_raw_last.txt` 到 Discord #alerts + WhatsApp, **不再静默推送占位符消息**. last_run.json 写 `{"status":"llm_failed","reason":"HTTP Error 502 ..."}` 让 watchdog/preflight 能识别真实失败. ⑩ **元教训**: V37.5 / V37.8.10 / V37.9.16 三次 fail-fast 升级时都应做"扫所有 LLM 调用 job 检查同款反模式"的 audit, 而不是单点修复. MR-8 copy-paste-is-a-bug-class 不只跨文件重复造 bug, **跨 job 没及时同步架构升级也是 bug**. 候选 V37.9.37 audit: 扫所有调 LLM 的 cron job (~10 个) 是否都对齐 fail-fast 模式 (检测项: 含 [SYSTEM_ALERT] / 不含 silent fallback 占位符 / status_file 不谎报 ok). |
| V37.9.35 | 2026-05-07 | **WhatsApp 客户端显示折叠架构发现 → budget 1400→4000 (Path A 保守路径)** — ① **触发**: V37.9.33 freight 三层 LLM 输出产生 **8131 字符**单条消息, 用户观察 WhatsApp 出现"两个窗口"+ **时间戳完全相同 (都是 12:26)**. ② **5 层切片排查 (原则 #28 不凭推测)**: (a) OpenClaw `auth-profiles-*.js` 主 bundle grep `splitMessage/chunkMessage/maxLength` 全部空命中 (b) `runtime-whatsapp-outbound.runtime-*.js` lazy loader 实现 grep 空 (c) `~/.openclaw/openclaw.json` channels.whatsapp 无 maxTextLength 字段 (d) Baileys 7.0.0-rc.9 已知不分片 (单条 65,536 上限) (e) **WhatsApp 手机客户端 ~4000-5000 字符自动分气泡显示** ✅ 真切片层. ③ **关键证据**: 时间戳相同 = 单条消息 (协议层若真切片两次 API 调用至少差 1 秒); 8131÷2≈4065 字/气泡 = 折叠阈值约 4000-4500 (与 Telegram 4096 限制接近). ④ **Path A 保守路径实施 (用户决策)**: budget 1400→4000 在 3 source + 3 test 文件 — `kb_review_collect.py:518` `body[:1400]→[:4000]` / `kb_evening_collect.py:182` 同 / `kb_deep_dive.py:596` `_WA_BUDGET_PER_PART = 1400→4000` + line 601 `_WA_BODY_BUDGET_PER_PART = 1200→3800` (header 200 buffer 保留). 测试 5 处 assertion + 输入长度调整 (`x*5000→8000`, `段落内容。x500→1500` 触发新 budget multi-part) + 1 处 test_body_truncated_at_1400 重命名 _at_4000. **保留**手动分屏代码作为防御 fallback (V37.9.21 `_split_text_into_chunks` + kb_dream max_chunk=4000 不动) — 极长内容 (>8000) 仍触发 + 跨平台一致性保险 (WhatsApp Web/Desktop 折叠阈值可能不同) + MR-7 治理不删除已验证安全边界. ⑤ **影响矩阵**: kb_review/kb_evening/kb_deep_dive 信息密度立即提升 **2.86x** (1400→4000); freight 已无 budget 不变; kb_dream max_chunk=4000 已合理不变; 论文监控 task 无 1400 截断不变 — 实际只 3 task 受益, 证明 1400 是 V37.9.21 单点假设非全局. ⑥ **完整案例文档** `ontology/docs/cases/whatsapp_client_display_folding_case.md` (TL;DR + 完整发现链路 + 5 层排查矩阵 + V37.9.21 假设来源 + Path A 实施 + 跨任务影响 + 4 条元教训 + 与其他案例关系). ⑦ **元教训**: (a) 字符数限制要看真实生产数据不是 documented limit — V37.9.21 1400 是没实测的"安全值" (b) 用户视角观察是不可替代的最终验证层 — 同日 V37.9.31/32/34/35 四次同源教训 (c) 保守路径 (Path A) 边际效用 > 激进路径 (Path C) — 信息密度 2.86x 已足够 + 跨平台保险 (d) 不删除已工作的防御代码即便上层假设修正后部分失效. ⑧ **累计**: 55 suites 不变 / 2021 tests 不变 (源码改 + 测试 input 调整, net 0) / 0 fail / governance 506 checks / 17 meta rules / 安全 95/100 / VERSION 0.37.9.34 → 0.37.9.35. ⑨ **Mac Mini 部署**: 5 文件 cp (kb_review_collect.py + kb_evening_collect.py + kb_deep_dive.py + VERSION + CLAUDE.md). 下次 22:00 kb_evening / 22:30 kb_deep_dive cron 自动用新 budget. 周日 kb_review 同样. ⑩ **下次 (V37.9.36+) 候选**: (a) 24-48h V37.9.35 推送质量观察 — kb_evening / kb_deep_dive 是否产生更深度内容 (b) 跨平台一致性测试 (WhatsApp Web/Desktop/旧版手机) (c) 如跨平台都一致 → 评估 Path B 移除 kb_deep_dive 手动分屏 (d) V37.9.30 24-48h ACL/lsof/snapshot 真实数据回归 (仍是 EPERM 真根因调查的硬卡).|
| V37.9.34 | 2026-05-07 | **V37.9.33 hotfix: PROMPT 内嵌 ASCII 双引号导致 bash 字符串提前终止 (Mac Mini 实测发现, MR-4 silent-failure 第 25 次演出)** — ① **触发**: V37.9.33 部署后用户立即跑 `bash run_freight.sh` 验证三层输出, 终端报 `line 222: 本期无显著经济晴雨表信号）... No such file or directory`. RSS 抓取成功 15 条但 LLM 调用从未发生 (脚本中段崩). ② **真根因**: V37.9.33 LLM prompt 内嵌入两处 ASCII 双引号 `输出"📊 本期无显著经济晴雨表信号"` (line 222) + `输出"🏢 本期无显著运营信号"` (line 229). bash 在 `PROMPT="..."` 内部解析时, 把这些 ASCII `"` 当成 PROMPT 字符串的关闭符, 导致字符串提前终止 → 后续中文段落被当成 shell 命令解析 → "No such file or directory". V25 原 prompt 用单引号 `'行业信号 — 描述'` 没此 bug, V37.9.33 引入双引号导致回归. ③ **MR-4 silent-failure 第 25 次演出新形态**: V37.9.33 的 26 个单测全过 + dev 环境 `bash -n` 语法检查通过, 但实际 `bash` 运行才暴露问题. **`bash -n` 只检查语法不检查变量展开/字符串嵌套**, 实际运行时的 PROMPT="..." 内部嵌套引号问题在静态语法检查中**不可见**. 这是 V37.9.31/32 同款"自动化测试全过 + 真用户跑才暴露 bug"模式的第三次演出. ④ **最小修复 (原则 #28 三问全过)**: line 222 + 229 把 `输出"📊 X"` 改为 `输出\"📊 X\"` (反斜杠转义双引号). bash 在 `"..."` 内看到 `\"` 当作字面量 `"` 字符传给 LLM, 不再把它当字符串关闭符. ⑤ **2 新 source-level 守卫单测** TestV37934BashQuoteEscaping: `test_no_unescaped_double_quote_after_chu` 用负向回顾正则 `(?<!\\\\)输出"` 扫源码禁止任何未转义的 `输出"` 字面量 + `test_section_empty_signals_use_escape` 验证三层 "本期无显著X信号" 短语周边必须有 `\"` / 单引号 / 全角引号包围 (5 字符上下文检查). 防 V37.9.34 hotfix 后未来重构再次回退到 ASCII 双引号反模式. ⑥ **元教训**: bash 字符串嵌套是**运行时语义层级**问题, 不是语法层级问题. `bash -n` 看不到, source-level grep 在 V37.9.33 没设计这个守卫. 这是测试三层"WhatsApp 业务验证" + "用户视角观察" (原则 #13/#15) 的第 6 次正向兑现 — 自动化测试 + dev 环境 `bash -n` 都过, 用户 Mac Mini 实跑 stderr 才告诉我们真问题. ⑦ **累计**: 55 suites 不变 / 2019→2021 tests (+2) / 0 fail / governance 506 checks 不变 / 17 meta rules / 安全 95/100 / VERSION 0.37.9.33 → 0.37.9.34. ⑧ **Mac Mini 部署**: 仅 cp 1 文件 (run_freight.sh), 立即重跑 freight 应看到完整三层输出 + 客户画像生成正常.|
| V37.9.33 | 2026-05-07 | **货代任务深度优化：Tier 1/2 权威源扩展 + LLM 三层深度分析（"全球发货是经济晴雨表"用户论点兑现）** — ① **触发**: 用户论点 — 全球发货信息（海运/陆运/空运）是经济**领先指标**（运价 1-3 个月领先 GDP），比咨询机构或专家智囊事后判断更值得信赖。V37 freight_watcher 仅用 Tier 3 行业新闻 RSS + Google News 通用检索，权威 Tier 1/2 数据源（运价指数 / 班轮公告 / 港口吞吐 / 海关数据）完全没接入。用户明确"不新增任务，直接优化货代"。② **设计选择**: Tier 1/2 直连权威源（Drewry / 上海航交所 / Marine Traffic / 海关总署）面临反爬 + GeoIP 限制，V37.9.31/32 stealth 升级仍不保证全部可达。改用 **Google News RSS 精确搜索 indexed 内容**（100% 可达，间接覆盖权威源被引用的内容），代价是延迟 1-2 天但保证可靠性。③ **SOURCES 扩展 12 → 27**: (a) 集装箱运价指数 4 (SCFI/CCFI/Drewry WCI/FBX Freightos Baltic) — 周更经济温度计 (b) 散货 1 (BDI Baltic Dry) — 大宗商品全球晴雨表 (c) 空运 1 (TAC Index/IATA CASS) — 周更 (d) 班轮公司动态 3 (MAERSK / CMA CGM+MSC+Hapag-Lloyd / COSCO+Evergreen+Yang Ming) — 缩舱/空班/路线调整领先 1-2 个月反映需求 (e) 港口吞吐 3 (LA+Long Beach / Shanghai+Ningbo / 全球 congestion+TEU) (f) 海关 2 (China exports+trade balance / US imports+trade deficit Census Bureau)。④ **关键词集 +4**: INDEX_KW (16 词中英双语) / CARRIER_KW (14 词，10 班轮 + 4 中文) / PORT_KW (14 词) / CUSTOMS_KW (10 词)。⑤ **抓取上限 10→15**: 给新增 Tier 1/2 留空间，防 Tier 3 行业新闻挤占运价指数（这些源每周才出 1 条但价值最高）。⑥ **LLM prompt 三层结构化升级** (V25 单层 → V37.9.33 三层): **📊 第一层：经济晴雨表** (用 `指数：` 前缀，输出指数名+方向+经济解读+评级) **🏢 第二层：运营信号** (用 `动作：` 前缀，输出公司/港口动作+影响+评级) **🚢 第三层：商机条目** (V25 原 `企业信号：` 前缀**完整保留**，Step 8 ImportYeti 提取 regex 仍工作)。每段最多 5 条防 WhatsApp 超长。LLM prompt 含反幻觉守卫"严禁虚构具体数字（运价/港口吞吐量）必须来自原文"。⑦ **MSG_FILE 三段式 passthrough**: 新增 section-aware regex `(?=\\n📊\|\\n🏢\|\\n🚢\|\\n\\d+\\.)` 切块，`current_section` 跟踪当前段（`index`/`ops`/`business`），ImportYeti link **仅在 `current_section == "business"` + ⭐≥4 + 含 `企业信号：`** 三条件全满足时附加。📊 段含 SCFI 数字 / 🏢 段含 MAERSK 公司名都不会误触发 ImportYeti。⑧ **末尾追加完整新闻链接段** "📚 本期数据来源 (15 条权威信源)"，让 KB 归档可追溯到原始权威源（Drewry/MAERSK/上海航交所等）。⑨ **Step 8 ImportYeti 向后兼容守卫**: line 451-452 regex `re.search(r'企业信号：(.+?)[\\s]*[—–\\-]', block)` 完全保留 V25 格式 — 实测 simulated 3-section input 仅提取 🚢 段企业（"Acme Corp"），📊 段 "SCFI" 数字 + 🏢 段 "MAERSK" 公司名都被自动过滤。⑩ **26 新单测 6 类** test_freight_v9_33.py: TestV37933SourcesExpanded(7 验证 12 新源 + total ≥25) + TestV37933KeywordSets(5 验证 4 新 KW + 中英双语) + TestV37933CapBumped(1 cap=15 + 守卫 V37 旧 cap=10 不残留) + TestV37933LLMPromptThreeLayer(6 三段 emoji + 各段独立前缀 `指数:`/`动作:`/`企业信号:` + 反幻觉守卫 + 每段 5 条限制) + TestV37933MsgFileAssembly(5 section-aware 切块 + current_section 跟踪 + ImportYeti scoping + 数据源 footer + extract_company V25 兼容) + TestV37933Step8BackwardCompat(2 含 source-level grep 守卫 Step 8 不能匹配 `指数:`/`动作:` + simulated 3-section 输入仅提取 🚢 段企业)。⑪ **累计**: 54→55 suites (+1) / 1993→2019 tests (+26) / 0 fail / governance 506 checks 不变 / 17 meta rules / 安全 95/100 / VERSION 0.37.9.32 → 0.37.9.33。⑫ **Mac Mini 部署**: 仅需 cp run_freight.sh + VERSION + CLAUDE.md（无新增 cron / 无新依赖 / 无 ImportYeti scraper 改动）。下次 8:00/14:00/20:00 cron 自动用新源。⑬ **下次 (V37.9.34+) 候选**: (a) 24-48h 后看 freight 推送质量（经济晴雨表段是否有 SCFI/BDI 实数据 vs 空段）(b) Marine Traffic / Vessel Finder AIS 直连（V37.9.32 stealth 实战，需 API key 评估）(c) 海关总署 / Census Bureau 月度数据直连（RSS 可能可达）(d) 增加分行业指数（汽车 freight / 电子产品 freight / 服装 freight）。⑭ **元价值**: V37.9.33 是 V3 路标"别人会扩展"的方法论体现 — 不创建新 cron 而是**深化现有 job** + LLM prompt 工程让单一 job 输出多层结构化分析。用户视角看到"货代速报"从单层"商机条目"升级为三层"经济晴雨表+运营信号+商机条目"，信息密度大幅提升。原则 #18 "补证据而非补功能"兑现 — 没增加新 job 数量，但 freight 这个 job 的产出价值翻倍。|
| V37.9.32 | 2026-05-07 | **playwright-stealth 1.x → 2.x API 兼容修复（V37.9.31 Mac Mini 实测发现）** — ① **触发**: 用户合并 V37.9.31 后 Mac Mini 手动跑 freight 验证全链路成功 (`"deep_dive":"ok"` 历史性首次出现 — 5/4 之后第一次), 但 scraper 输出 `WARN: playwright-stealth 未安装 ... 使用 manual stealth fallback`. 实际 `pip3 install playwright-stealth` 显示 `Requirement already satisfied (2.0.2)`, 矛盾根因 = V37.9.31 代码用 `from playwright_stealth import stealth_sync` (1.x API), 但 2.x 改为 `Stealth` class. ② **API 变化考证**: `pip install playwright-stealth==2.0.3` + `python3 -c "from playwright_stealth import stealth_sync"` → ImportError; `from playwright_stealth import Stealth` → OK; `Stealth().apply_stealth_sync(page)` 是 2.x 推荐入口 (返回 None, in-place patch). ③ **修复**: importyeti_scraper.py main() 函数内 import 时三档 fallback chain — 先 try 2.x `from playwright_stealth import Stealth` + `_stealth_apply = lambda page: Stealth().apply_stealth_sync(page)` (`stealth_api_version = "2.x"`), ImportError 则 try 1.x `from playwright_stealth import stealth_sync` + `_stealth_apply = lambda page: stealth_sync(page)` (`"1.x"`), 都失败则 `_stealth_apply = None` + `"none"` + manual STEALTH_JS fallback. 调用点从 `stealth_sync(page)` → `_stealth_apply(page)` (API 版本无关). 启动日志加 `stealth_lib={api_version}` 可观测哪个分支生效. ④ **3 新单测 source-level 守卫** TestSourceLevelGuards 扩展: `test_v37_9_32_uses_2x_api_first` (Stealth import 必先于 stealth_sync) + `test_v37_9_32_uses_apply_stealth_sync_method` (必含 `apply_stealth_sync(page)`) + `test_v37_9_32_call_site_uses_api_agnostic_helper` (regex 锁定 `if stealth_available:` 块内调 `_stealth_apply` 而非 `stealth_sync`). 防止未来重构回退到 1.x-only API. ⑤ **Mac Mini E2E 数据点 (V37.9.31 同时验证)**: ✅ `last_run.json` 含 `"deep_dive":"ok"` (历史性首次, 5/4 之后第一次) ✅ Step 8-10 全跑完 (高星 OMI → ImportYeti 查询 → 客户画像) ✅ rsync helper 错峰 sleep 178s + 36s 后脚本继续 (V37.9.31 fail-open 真生效) ✅ Preflight 通过 82 / 失败 0 (历史新高, 之前 4 deployment fail 全消) ✅ WhatsApp 推送收到 OMI 客户画像 (Changzhou Zweal Office Equipment 供应商 + 上海港→洛杉矶港路径 + USD 2,500-4,000 月预算). ⑥ **累计**: 54 suites 不变 / 1990→1993 tests (+3) / 0 fail / governance 506 checks 不变 / 17 meta rules / 安全 95/100 / VERSION 0.37.9.31 → 0.37.9.32. ⑦ **下次 (V37.9.33+) 候选**: (a) Mac Mini 重跑 freight 应输出 `stealth_lib=2.x (on)` 而非 manual fallback warn (b) V37.9.30 24-48h ACL/lsof/snapshot 数据回归 (c) 5/11 决策窗口 jobs_to_crontab + kb_sources_to_index machine_sync dry-run 真激活. ⑧ **元教训**: 用户视角观察 (原则 #13) 第 5 次正向兑现 — V37.9.31 自动化测试单测全过 + Mac Mini Preflight 0 failure, 但用户实际跑 freight 看 stderr 才暴露 import 路径错配. dev 环境跑测试时 `pip install playwright-stealth` 装的是最新 2.x, 但 V37.9.31 代码 grep 仅守卫 `playwright_stealth` 字面量出现 (没守卫 `Stealth` 或 `stealth_sync` 哪个函数被 import), 所以 source-level test 全过. 实际生产数据告知真问题. 这是原则 #15 测试三层 "WhatsApp 业务验证" 的进一步兑现.|
| V37.9.31 | 2026-05-07 | **V37.9.27 rsync_helper 回归修复 (fail-open exit 0) + 货代 schema 完整 + ImportYeti 反爬升级 (MR-4 第 24 次演出: 修复引入更深 silent failure)** — ① **触发**: 用户 5/7 preflight 报告"货代 deep_dive: last_run.json 无 deep_dive 字段（旧版本脚本？）"+ 明确要求"彻底解决包括反爬". 真实数据揭示 Mac Mini Step 8-10 文件 mtime 卡在 5/4 14:00 (今天 8:00 run 没到达). ② **真根因 (非反爬)**: V37.9.27 movespeed_rsync_helper.sh line 116 `exit "$EXIT_CODE"` 透传 rsync 失败码. run_freight.sh line 9 `set -eo pipefail` 启用 errexit. V37.9.30 EPERM 100% 持平后, 每次 rsync_helper 都失败 exit 非 0 → 20 个 set -e caller 每天被杀 mid-script (freight Step 8-10 / kb_dream Reduce / kb_evening / kb_inject 等等). last_run.json 在 Step 5 写了 status=ok+sent=true 但**无 deep_dive 字段**, preflight 误报 "missing 旧脚本". ③ **MR-4 silent-failure 第 24 次演出新形态**: 前 23 次都是错误处理失败, 第 24 次是**修复 (V37.9.27 retry helper) 引入更深的 silent failure** — 每天 ~20 caller step 8+ 全部静默丢失. V37.9.27 之前的 inline pattern `rsync ... 2>&1 \|\| echo WARN` 用 `\|\|` 保证 exit 0 给 caller, V37.9.27 helper 破坏了这个 invariant. ④ **F1 (核心修复) movespeed_rsync_helper.sh fail-open exit 0**: line 116 `exit "$EXIT_CODE"` → `exit 0` + 详细注释解释 set -e contract + V37.9.4-V37.9.26 invariant 恢复. fail-loud 仍通过 (1) stderr "WARN: SSD" 字面量 (INV-BACKUP-001) (2) JSONL forensic record (3) V37.9.26 watchdog 24h ≥5 alert. 影响 20 callers 的 set -e 安全 — 它们想要的是 best-effort backup 不杀脚本, 这才是 V37.9.4 之前的 invariant. ⑤ **F2 run_freight.sh 4 exit path 都写 deep_dive**: NEW_COUNT=0 → `skipped_no_news` / LLM 失败 exit 1 → `skipped_llm_failed` / 解析率<50% exit 2 → `skipped_parse_low` / Step 5 推送成功 → `pending` (Step 9 后续覆盖为 `ok`/`no_data`/`skipped`) / Step 5 推送失败 → `pending`. 永不再有 missing 字段. ⑥ **F3 preflight_check.sh 容忍 V37.9.31 新 status**: skipped_no_news → pass / skipped_llm_failed → warn (含告警链路) / skipped_parse_low → warn / pending → warn (含 V37.9.31 上下文指向 set -e 修复) / missing → 升级为 fail (V37.9.31 后是真异常). ⑦ **F4 importyeti_scraper.py 反爬升级 (用户选 playwright-stealth 专业库方案)**: USER_AGENTS 4 modern Chrome (130/131 macOS+Windows+Edge 跨平台轮换) / VIEWPORTS 5 真实尺寸随机化 (1280-1920 × 720-1080) / EXTRA_HEADERS 完整 sec-ch-ua / sec-fetch-* / accept-language q-value / Cloudflare 检测 _detect_cloudflare_challenge() 纯函数 (Just a moment / challenge / cf-chl / verifying you are human / block page <500 chars 启发) / 重试 backoff [30,60,120]s 替代 V3 fixed 10s / 公司间 delay 5-12s 随机替代 V3 fixed 3s / playwright-stealth 50+ patches 自动 fallback 到 manual STEALTH_JS (扩展 hardwareConcurrency/deviceMemory/platform/chrome[runtime,loadTimes,csi]). Mac Mini 需 `pip3 install playwright-stealth` (用户已确认). IMPORTYETI_TEST_MODE=1 跳过 sleep 用于确定性测试. ⑧ **F5 53 新单测**: TestRsyncAllRetriesFail 重写 (test_all_fail_emits_warn_ssd_and_exits_zero_v37_9_31 + test_caller_with_set_e_survives_rsync_failure_v37_9_31 真 subprocess 跑 set -e caller + helper 验证 POST_RSYNC_REACHED 字面量) / test_freight_schema_v9_31.py 13 单测 2 类 (TestFreightStatusFileSchemaV9_31 8 + TestPreflightStatusToleranceV9_31 5) / test_importyeti_scraper_anti_crawl.py 39 单测 9 类 (TestUserAgentRotation 4 + TestViewportRandomization 4 + TestSecChUaHeaders 5 + TestCloudflareDetection 8 + TestCloudflareBackoff 4 + TestInterCompanyDelay 3 + TestTestModeBehavior 2 + TestEmptyResultHelper 1 + TestFormatResult 2 + TestSourceLevelGuards 6). 全部禁止 V3 反模式字面量 (3s sleep / 10s backoff / fixed 1280x720). full_regression.sh +2 suites 接入. ⑨ **governance INV-RETRY-001 扩展**: declaration 段加 V37.9.31 fail-open contract 修正叙事 (引用 V37.9.30 EPERM 100% 持平证据) + 2 新 declaration check (`V37.9.31: fail-open exit 0` + `set -e contract` 字面量). MR-4 演出史更新到 24 次. ⑩ **累计**: 52→54 suites (+2) / 1937→1990 tests (+53) / 0 fail / governance 504→506 checks (+2 V37.9.31 fail-open + set -e contract) / 17 meta rules 不变 / 安全 95/100 / VERSION 0.37.9.30 → 0.37.9.31. ⑪ **下次 (V37.9.32+) 候选**: (a) **主硬卡**: Mac Mini `pip3 install playwright-stealth` 安装 + 等明日 8:00 freight cron 真跑观察 stealth 效果 + 检查 last_run.json 是否含 `"deep_dive":"ok"` (V37.9.31 全链路真闭环) (b) 同时观察 V37.9.30 24-48h ACL/lsof/snapshot 真实数据回归 (c) 5/11 决策窗口三 spec 同步切关 dry-run (V37.9.23/24/25 累积观察期到达). ⑫ **元教训**: V37.9.31 是 **MR-4 第 24 次演出** — 修复引入更深 silent failure. 与 V37.9.27 同源 (修复假设错), 但 V37.9.27 是"修非主因" (UID 错位是真 bug 但非 EPERM 主因), V37.9.31 是"修复破坏 invariant" (helper exit 行为改变破坏 caller 的 set -e 假设). 数据驱动诊断方法论第 7 步: 每次"修复成功"必须验证**所有 caller 行为契约**未被破坏. 原则 #28 第三问"最小修复方案"反向兑现 = 不要让修复成为下个 silent failure 的源头.|
| V37.9.30 | 2026-05-07 | **V37.9.29 假说部分证伪 → 取证扩展第 9-11 维度 (ACL/xattr + lsof handles + TM snapshots) + 35 新单测** — ① **触发**: 5/7 早 8:00 HKT 24h 验证窗口截止, Mac Mini `incident_analyzer --window 24h` 输出: 21 incidents (>15 R1 阈值) / **19/21 records 显示 ownership=501:20 bisdom:staff** (chown 真生效) / EPERM **100% 持平 V37.9.28** / 5 daemon (Spotlight/backupd/fseventsd/mds/mds_stores) **100% 共现**. **关键解读**: V37.9.29 path D' chown 修复了真存在的 UID 错位 bug (V37.9.4 引入, 60 天潜伏), 但 **UID 错位不是 EPERM 的根因 (或不是唯一根因)** — chown 后 EPERM 完全不降. ② **决策**: 用户选 Path C (不回滚, 进入新诊断) 而非严格 R1 — 理由 (a) chown 修了真 bug 没引入副作用 (rsync 67MB 0 EPERM 验证通过) (b) 历史数据证明 noowners + disableOwnership 不会让 EPERM 减少 (V37.9.4-V37.9.28 都是 ~19/24h) (c) R1 会失去 V37.9.29 b ownership 诊断字段. **预定 R1 规则原意是"修复有副作用让情况变糟立即恢复"**, 实际是"修复无副作用 + 没解决主问题" — 严格执行 R1 是僵化, Path C 更符合规则原意. ③ **3 类新取证字段 capture.sh +30 行**: (1) `acl_top` / `acl_kb` 用 `ls -le@` 抓 macOS ACL + xattr (chown 改 owner 但 ACL/xattr 留下, 这是 chown 不能清的强阻塞模式) (2) `lsof` 用 `lsof /Volumes/MOVESPEED 2>/dev/null \| head -50` 抓开放文件句柄 (head -50 双重保护: 防 lsof macOS hang + 限输出体积) (3) `snapshots` 用 `tmutil listlocalsnapshots / 2>/dev/null \| head -20` 抓 TM 本地快照 (即使 TM exclude 也可能有快照锁 metadata). 全部 best-effort, 缺工具 / 非 macOS = 空字段, 永不阻塞 caller. ④ **3 个新分类纯函数 analyzer.py +90 行**: `classify_acl_anomaly(acl_str)` 优先级排序 acl_deny > acl_present > xattr_only > normal > empty (基于 macOS `ls -le@` 输出格式: `0: group:everyone deny ...` / 制表符前缀的 xattr 行 / 普通 ls -l 行) / `classify_handle_holders(lsof_str)` 区分 daemon_dominated / user_only / mixed / empty (LSOF_DAEMON_KEYWORDS 含 mds_stores/backupd/fseventsd/Spotlight/mds/mdworker 注意顺序: 长字符串先 防 mds 子串误命中 mds_stores) / `classify_snapshot_count(snap_str)` 三档桶 snap_0 / snap_1_5 / snap_6_plus / empty (基于 `com.apple.TimeMachine.YYYY-MM-DD-HHMMSS.local` 字面量行计数). ⑤ **3 个新 analyzer 维度** (8→11): `by_acl_anomaly` 取 top+kb 强信号 (priority 字典选 max) + `by_handle_pattern` + `by_snapshot_bucket`. ⑥ **3 个新决策提示分支** (text 报告): (a) **🛡️ ACL deny 警告** 当任一 incident 有 ACL deny → 提示 `sudo chmod -RN /Volumes/MOVESPEED` 清除所有 ACL (这是 V37.9.29 假说证伪后的强候选根因) (b) **📂 句柄持有警告** 当 daemon_dominated ≥3 且 > user_only → 验证 daemon contention 假说 + 提示 path B 调度避峰 (12:00 UTC = HKT 20:00 是峰值, 移开避峰时段) (c) **📸 Snapshot 警告** 当 snap_6_plus > 0 → 提示 `sudo tmutil deletelocalsnapshots /` + `sudo tmutil disablelocal`. ⑦ **35 新单测** test_movespeed_incident_analyzer.py 5 类 (镜像 V37.9.29 b TestV37929B* 模式): TestV37930ClassifyAclAnomaly(7 含 empty/whitespace/非 string 健壮性 / 显式 deny / xattr only / normal / acl_present 无 deny) + TestV37930ClassifyHandleHolders(6 含 empty / 仅 header 行不计 / 仅 daemon / 仅 user / mixed / mds 子串不误判 md5sum) + TestV37930ClassifySnapshotCount(6 含 empty / 0 / 1 / 5 boundary / 6 boundary / 非 TM 行忽略) + TestV37930ForensicAnalysisIntegration(10 含 backward compat 缺字段 → empty 桶 / acl_deny 计数 / daemon_dominated 计数 / snap_6_plus 计数 / 文本报告含 3 新段 + V37.9.30 marker / ACL deny 警告 fire + chmod -RN 字面量 / daemon dominated 阈值 ≥3 fire path B / 阈值不达不 fire / snapshot 警告 fire + deletelocalsnapshots 字面量 / 全 clean 不 fire 任何警告) + TestV37930CaptureScriptIntegrity(6 含 4 capture 字面量守卫 + lsof head -50 守卫 + rec_dict 4 字段 + V37.9.30 marker + partially falsified attribution). _make_record helper 加 4 新可选 kwargs (acl_top/acl_kb/lsof/snapshots) 保持向后兼容. ⑧ **V37.9.29 假说被证伪后的新假说候选** (待 24-48h 真实数据验证): (a) **ACL deny 假说** — chown 不清 ACL 是 macOS 机制硬规则, 是最合理候选 (b) **APFS 内部锁/快照假说** — exfat→APFS 转换可能未稳定, 内部 metadata 锁 (c) **kernel ACL/xattr ACL 假说** — chown 改 owner 但内核 ACL 仍按旧规则做检查. **关键**: 让 24-48h 的新数据告诉我们哪个假说成立, 不再凭推测改代码 (原则 #28 兑现 + V37.9.27 retry 实战破证为 F2 数据驱动诊断 同款方法论). ⑨ **MR-4 silent-failure 第 23 次演出新形态**: V37.9.29 是"修复确实生效但修错了 bug"——前 22 次 silent 都是"错误被吞 / 错误被稀释 / 错误推送编造", 第 23 次是 **"修复成功 + 验证生效 + 但目标问题没改善"** — 完全合规的修复路径 + 数据自我证伪. 这正是 V3 路标 framework "数据从不撒谎"的硬实证场景. ⑩ **累计**: 52 suites 不变 (test_movespeed_incident_analyzer.py 内继续扩展) / 1902→1937 tests (+35) / 0 fail / governance 69 inv / 423 checks 不变 (V37.9.30 选择测试层守卫优先, 镜像 V37.9.29 b 节奏, 候选 INV-FORENSIC-001 待 24-48h 真实数据后再考虑) / 17 meta rules / 安全 95/100 / VERSION 0.37.9.29 → 0.37.9.30. ⑪ **下次 (V37.9.31+) 候选**: (a) **主硬卡**: 24-48h 后用户跑 `python3 ~/movespeed_incident_analyzer.py --window 24h` 把 V37.9.30 新维度数据贴回, 基于真实 ACL/lsof/snapshot 模式做精确根因判定 (b) 若 ACL deny 警告 fire → 立 INV-ACL-001 + 加 chmod -RN 修复路径文档 (c) 若 daemon_dominated 主导 → 实施 path B 调度避峰 (d) 5/11 决策窗口三 spec 同步切关 dry-run 真激活 machine_sync (V37.9.23/V37.9.24/V37.9.25 累积观察期到达). ⑫ **元价值**: V37.9.30 是 V37.9.x 系列"数据驱动诊断"方法论的进一步加固 — V37.9.14 取证 → V37.9.26 主动告警 → V37.9.27 主动修复 → V37.9.28 数据驱动诊断工具 → V37.9.29 ownership 维度 → V37.9.30 ACL/handle/snapshot 维度. **每次假说被证伪都不靠盲改代码而靠扩取证维度**, 这是与"看到失败就改代码"反模式的本质区别. 原则 #28 (理解再动手) 第三问 "最小修复方案" 兑现到 framework 层级.|
| V37.9.29 | 2026-05-06 | **MOVESPEED EPERM 60 天 silent failure 真因终于触底 — noowners + UID 错位 (path D' chown + enableOwnership + remount 闭环) + V37.9.29 (a) incident_capture mount 截断 bug + 24h 验证窗口至 5/7 早 8:00** — ① **触发**: V37.9.28 收工时承诺 5/6 24h 数据决定 EPERM 真因。开工跑 `incident_analyzer --window 24h` 揭示 macOS 修复 (Spotlight off + TM exclude) **完全无效** — 24h 仍 21 incidents (vs 之前 ~19/24h), 100% EPERM (Operation not permitted, errno 1), 100% 5 daemon 共现 (mds_stores/backupd/mds/Spotlight/fseventsd), 23:30 兜底 cron 也 EPERM 失败。**Spotlight 真 disabled** (mdutil -s) **TM 真 excluded** (tmutil), 但 daemon 进程仍跑 → 排除 V37.9.28 假说。② **Path A 4 轮诊断锁定真凶**: (a) 第 1 轮 mdutil/tmutil 状态 (排除"修复未生效") (b) 第 2 轮 diskutil info APFS Read-Write + tmutil snapshots 空 + **mount flag 含 noowners** ⚠️ (c) 第 3 轮 probe_top_err = "Operation not permitted" errno 1 (排除 EAGAIN/EACCES, 锁定 ACL 拒绝) (d) 第 4 轮 stat -f %Su:%Sg → **/Volumes/MOVESPEED = root:wheel (0:0) / KB = _unknown:_unknown (99:99)**, bisdom 是 UID 501 → **完全错位**！noowners flag 让所有 file 显示成 bisdom 完全掩盖 UID 错位 (8 天潜伏期), macOS daemon (mds_stores UID 89, backupd UID 200) metadata access 触发跨 UID ACL 拒绝 → 内核 inode lock → bisdom cron 同时段 rsync 命中 EPERM。③ **Path D' 第一次错序 (第 6 次诊断错误)**: 顺序 chown(noowners 模式) → enableOwnership → mount owners → ❌ touch test "Permission denied" — bisdom 完全失访 ~10 分钟。**根因**: macOS APFS 隐含规则 — **noowners 模式下 sudo chown 被静默吃掉** (教科书 "sudo bypass" 假设错), chown 没改 UID 但 ownership 被启用让 mount 走 owners path, bisdom UID 501 ≠ root 0 / UID 99 → 立即失访。④ **R2 抢救 (正确顺序)**: 现在 ownership 已启用, 重跑 chown → 真生效, UID 全变 bisdom:staff (501:20), touch test 成功, rsync 真运行 67MB sent 0 EPERM ✅。**关键发现**: macOS APFS chown 操作顺序硬规则 = enableOwnership → mount owners → chown (反过来 chown 在 noowners 模式下 silent no-op)。⑤ **V37.9.29 (a) incident_capture mount 字段截断 bug 修复 (parallel 独立工作)**: 昨日 V37.9.28 发现 incident_analyzer 报 21/21 "other_or_unmounted" 实是 read_file 400 char 截断 — `grep -i -e MOVESPEED -e Volumes` 同时匹配 /System/Volumes/Data 等无关行撑爆 400 char 窗口。修复: line 63 `grep -i MOVESPEED` (移除 `-e Volumes` 通用上下文) + line 120 limit 400→800 defense-in-depth。**4 新单测** TestV37929MountFieldFix 3 source-level + 1 fake-mount behavior。analyzer.py 不动 (其逻辑正确, bug 只在 capture 端)。30/30 test_movespeed_incident_capture.py 通过。Mac Mini 部署后未来 incident 数据准确, 不再被截断系统性误读为 unmount (V37.9.28 4 次诊断错误链第 4 环根除)。⑥ **完整案例文档** `ontology/docs/cases/movespeed_noowners_uid_mismatch_case.md` (~520 行): 四维度因果链架构图 (60 天潜伏 → 7 轮诊断 → V37.9.29 闭环) + 三层根因 (触发器 V37.9.4 APFS 默认 noowners / 放大器 root + UID 99 ownership 错位 / 掩护者 macOS daemon ACL 拒绝) + 时间线还原表 + 6 条件组合分析 + chown 操作顺序 macOS APFS 隐含规则记录 + MR-4 第 22 次演出 (架构假设级 silent failure 60 天) + 5 条元教训。⑦ **可证伪 24h 验证窗口至 2026-05-07 早 8:00 HKT**: incidents < 5 = ✅ 假说正确 立 INV-OWNERSHIP-001 / 5-10 = ⚠️ 部分缓解观察一周 / 15+ = ❌ 立即 R1 回滚 (`sudo mount -u -o noowners + sudo diskutil disableOwnership`) + 进 path B 调度避峰。回滚保障 `/tmp/movespeed_before_v37_9_29d.txt` 已备份原始 diskutil info。⑧ **元教训 (一日内 6 次诊断错误)**: V37.9.28 错误 #1-#4 + V37.9.29 错误 #5 (chown 顺序假设) + #6 (sudo chown noowners 假设) — 每次都因为"凭推测脱离数据"。终结诊断错误的是 stat -f 直接看 UID 数据。MR-10 understand-before-fix 反向兑现 6 次. **真正修复需要数据驱动质疑假设而不是修单点 bug**: V37.9.4 整团队基于"APFS 重建解决 EPERM"假设运作 60 天, 比单个错误更难发现。这是 V3 路标 framework "数据从不撒谎"的硬实证 — V37.9.14 INV-INCIDENT-001 取证 + V37.9.26 INV-INCIDENT-CONSUMPTION-001 主动告警 + V37.9.27 INV-RETRY-001 retry helper + V37.9.29 数据驱动诊断 = 完整自我修正闭环。⑨ **V37.9.29 (b) incident_capture 加 ownership 字段（同日加固，让明日 24h 验证数据自带 UID 维度）**: capture.sh 加 `stat -f "%u:%g" /Volumes/MOVESPEED` + `/KB` 两个真实 UID:GID 收集（不受 noowners 显示掩码影响，能直接暴露 ownership 错位）+ Python rec dict 加 `ownership_top` / `ownership_kb` 两字段 (limit 50 chars 各)。analyzer.py `analyze()` 加第 8 维度 `by_ownership` (`ownership_pair_counter` 统计 `top=X kb=Y` pair 分布，向后兼容旧 records 归入 `empty (pre-V37.9.29(b) records)` 桶) + `format_text_report()` 加 🔐 Ownership 分布段 + 决策提示新增 ownership misalignment 警告（检测到 `top=0:0` / `kb=0:0` / `top=99:99` / `kb=99:99` 任一 → 提示"V37.9.29 path D' 修复后理应仅看 cron user，仍有此 pattern 立即 R1 回滚 + 具体命令"）。**14 新单测** TestV37929BOwnershipAnalysis(10) + TestV37929BCaptureScriptIntegrity(4)：包括 backward compat (pre-V37.9.29 b records → empty bucket) / 错位 pair 计数 (top=0:0 kb=99:99) / 一致 pair 计数 (top=501:20 kb=501:20) / partial field handling / non-string field 健壮性 / 8th dimension display / 警告触发场景 / 仅 kb 错位也警告 / capture.sh source-level guards。**意义**: 让未来类似 ownership 错位问题在 1 天内发现而不是 60 天 (V37.9.4→V37.9.29 silent failure 长度)，这是 V3 路标 framework "数据从不撒谎"在诊断粒度的进一步加固。⑩ **累计**: 52 suites 不变 / 1884→1902 tests (+18, V37.9.29 (a) 4 + V37.9.29 (b) 14) / 0 fail / governance 69 invariants 不变 (INV-OWNERSHIP-001 等 24h 验证后立) / 423 checks 不变 / 17 meta rules / 安全 95/100 / VERSION 0.37.9.28 → 0.37.9.29。⑪ **下次 (V37.9.30+) 候选**: (a) **主硬卡**: 5/7 早 8:00 24h 验证窗口跑 incident_analyzer (现已含 V37.9.29 b 第 8 维度 ownership 真实 UID:GID 显示) 决定 INV-OWNERSHIP-001 是否立案或 R1 回滚 (b) MR-18 候选 `mount-flag-must-not-mask-actual-ownership` 立元规则 (c) 立场文章第 6 篇 *"我以为闭环了" — 60 天 silent failure 的架构假设级教训* (V37.9.4 → V37.9.26 → V37.9.27 → V37.9.28 → V37.9.29 完整时间线案例素材已齐) (d) 5/11 决策窗口三 spec 同步切关 dry-run 真激活 machine_sync。|
| V37.9.28 | 2026-05-05 | **周一用户视角观察 (周二补做) 5 finding 单日全闭环 + V37.9.27 helper 实战破证为 F2 数据驱动诊断 + V37.9.22 Tripwire 框架首次复评** — ① **触发**：原则 #32 周一用户视角观察制度 (V37.8.11 教训立的元规则)，今日 (周二) 补做 30min。用户体感 3/5 分，单条 watchdog WhatsApp 告警截图同时露出 5 类问题。同时执行 V37.9.22 Tripwire 框架首次"复评"实践——上游 v2026.4.26→v2026.5.3-1 一周 5 个新 stable + 主版本号跳 5.x。② **Tripwire 0/6 触发自动 hold + 实证 WebFetch 关键发现**：(a) #73358 codex/gpt-5.5 silent default V37.9.22 三次评估硬阻塞 dealbreaker **已在 v2026.4.27 release notes 显式修复** (`require explicit skills.entries.coding-agent.enabled`) — V37.9.22 hold 主因解除 (b) v2026.4.29 新增 `tools.exec`/`tools.fs` restrictive profile 收紧 (中风险) (c) v2026.5.2 强制 plugin manifest `contracts.tools` ownership (中风险) (d) #59265 仍无 verified fix (e) 5.x 是日历版本号 (年.月.patch) **非** semver major bump。**战略局面变化**: 4/29 hold indefinitely → 5/5 hold tactically (路径已开)。**推荐方案 C**: 等 4-8 周 (~2026-06-15) 让 5.x 沉淀后阶梯升 v2026.4.27。文档刷新 5 文件 (eval doc 第十三节 + 13.9 时间表 / check_upgrade.sh LAST_EVAL_DATE 4/29→5/5 / config.md / SOUL.md / status.json)。③ **5 finding 单日修复**：**F1** [V37.9.28 commit 4aa9aa0] job_watchdog.sh `scan_logs()` 告警子条目暴露错误时间戳分布 — 旧只显示 "12条错误 → last_err"，新加 `(最早 X, 最新 Y)` / `(@ X)` / `(时间戳缺失)` 三档格式。最小修复 = 仅扩 ALERTS+= 拼接，不动 awk filter (V37.9.6 INV-WATCHDOG-FRESHNESS-001 互补)。9 单测 (TestF1AlertFormatTimestampRange 5 含血案场景 + TestF1AlertFormatShellGuards 4 源码守卫)。**F2** [commit 7d19abe] V37.9.27 helper 实战破证 (24h 仍 20 次, 错误模式 EPERM→EOF, MR-4 silent-failure 第 19 次演出新形态)。按原则 #28 第三问"最小修复方案"目前未知 → 构建数据驱动诊断工具 `movespeed_incident_analyzer.py` (~330 行, 7 维度: 时间覆盖/caller/exit_code/probe 矩阵分类/并发进程/小时分布/mount 状态 + 决策提示自动生成)。34 单测 9 类 + auto_deploy FILE_MAP + full_regression 集成。让 Mac Mini 端 JSONL 数据决定 helper 修复策略 (e.g. EOF 不重试 / 检测 tmutil status / 增长 backoff)，**不再凭推测**。**F3** [commit 0666885] HN watchdog 阈值 7h→14h 对齐 schedule (V37.8.7 ACL 同款 schedule-vs-threshold drift)。注释错写"每3小时→7h"实际 jobs_registry.yaml 是 `45 8,14,20 * * *` 每天 3 次最大 gap 12h，7h 阈值导致 overnight 必报警。改 25200→50400 (12h max gap + 2h slack)，与 freight_watcher 同款 8/14/20 schedule 对齐。1 单测守卫。**F4** [commit e21813e] slo_checker.py format_alert direction 显式声明 (修 3/5 metric 显示反向)。旧 line 120-122 三层 if-else 推断 direction 互相矛盾: latency_p95 显示 ">" 应 "<" / tool_success_rate 显示 "<" 应 ">" / auto_recovery_rate 显示 "<" 应 ">"。新方案: 每个 metric 在 check_slo 创建 result dict 时显式写 `"direction": "<" or ">"` 字段, format_alert 直接读 `v["direction"]` 不再推断。17 单测 3 类 (TestDirectionField 6 metric 方向 / TestFormatAlertUsesDirection 7 含血案场景反向断言 + 向后兼容缺字段 / TestSourceLevelGuards 4 旧推断 pattern 禁止)。**F5** [本提交] F1 修复后自动解决 — 用户登记的"ai_leaders 4 天前 429 仍显示"是 F1 symptom: F1 grep `[YYYY-MM-DD HH:MM]` 正确提取 ai_leaders 时间戳，alert 现显示 `(最早 2026-05-04 09:00, 最新 ...)` 让用户立刻判断是同时段突发还是持续。1 集成测试 `test_f5_ai_leaders_format_user_5_5_observation` 锁定 ai_leaders 实际格式被 F1 grep 正确识别。④ **因果链发现**: F1 (timestamp 显示) + F2 (V37.9.27 破证) **互锁** — 不修 F1 看不见 F2 真相。先修 F1 让用户能看清错误时间分布，才能基于证据决定 F2 helper 修复策略。⑤ **元价值**: 周一用户视角观察发现"系统监控产出降级到无法判断真伪"，比单点修复重要。原则 #32 兑现 — 单测/治理全绿但用户实际使用才暴露 UX 缺口。MR-7 (用户视角观察→24h 闭环) 第 4 次正向兑现 (V37.9.16 → V37.9.17 → V37.9.21 → V37.9.28)。⑥ **下次 V37.9.29+ 候选**: (a) **主硬卡**: Mac Mini 同步后用户跑 `python3 ~/movespeed_incident_analyzer.py --window 24h` 把输出贴回，基于真实 incident 模式做 F2 helper 修复 (e.g. EOF 不重试 / 检测 tmutil status / 增长 backoff) (b) F4 follow-up: Mac Mini 真实 proxy_stats.json p95 是否真 54s 严重超阈值，还是 stale data 调查 (c) 5/11 决策窗口三 spec 同步切关 dry-run 真激活 machine_sync (V37.9.23/V37.9.24 jobs_to_crontab + kb_sources_to_index + V37.9.25 services_to_launchd) (d) 立场文章第 6 篇候选: *"我以为闭环了" — 60 天 silent failure 的架构假设级教训* (V37.9.4 → V37.9.26 → V37.9.27 → V37.9.28 时间线全栈)。⑦ **累计**: 50→52 suites (+2) / 1822→1883 tests (+61, F1 9 + F2 34 + F3 1 + F4 17 + F5 1, 部分单测含 source-level 守卫) / 0 fail / governance 69 invariants 不变 (本次无新 INV, 候选 INV-WATCHDOG-THRESHOLD-001 守卫 schedule-vs-threshold 一致性留 V37.9.29+) / 423 checks 不变 / 17 meta rules / 安全 95/100 / VERSION 0.37.9.27 → 0.37.9.28。⑧ **MR-7 用户视角→24h 闭环正向兑现** (第 4 次)：原则 #32 周一观察制度作为元规则建立的工程价值首次实证 — 30min 用户观察发现 5 类问题同日修 4 个根因 + 1 个 F1-symptom 自愈。这是 framework "用户感知 = 一等可观测信号" 的硬证据。|
| V37.9.27 | 2026-05-04 | **B 问题真正修复 — movespeed_rsync_helper.sh (jitter+retry+fail-loud+capture wrapper) 替代 20 个 inline rsync site / V37.9.26 主动告警立即抓真问题 / V37.9.4 闭环假设失败的 60 天 silent failure 终结** — ① **触发**：V37.9.26 收工后 user 跑 `python3 movespeed_incident_monitor.py` 立即抓到 **24h 19 条 incident** (远超阈值 5)，5 个生产 cron 受影响 (run_hn_fixed/run_freight/run_discussions/run_arxiv/run_rss_blogs). 深度审计 incidents.jsonl 历史数据 (212 条总量, 分析时间分布) 揭示**架构假设级 silent failure**: V37.9.4 APFS 重建只解决文件系统层 fskit EPERM, 但 OS 调度层 SSD I/O 竞争仍每天 ~19 次 transient 失败影响 11 个 KB cron jobs (60 天潜伏期, MR-4 第 18 次演出新形态). 错误时段集中: 00-06 (8 条/8h) + 12 + 19 整点尖峰 = macOS 日级维护 (Time Machine / Spotlight / mds_stores) 抢占 SSD I/O 总线. ② **三层主动修复设计**: Phase 1 错峰 30-180s 抖动 (避多 cron 同秒触发抢 SSD I/O 总线 — 避开整点尖峰) / Phase 2 retry 3 次 10s/20s 指数退避 (transient EPERM 通常 30s 内自愈) / Phase 3 全部失败才 fail-loud + 调 movespeed_incident_capture.sh (V37.9.4/V37.9.14 契约保留). **设计权衡**: 起步设计 5-15min jitter 太长导致 cron 推迟严重, 改为 30-180s 错开多 cron 同秒触发同时保持 cron 漂移可接受. 预期 incident 从 ~19/24h 降到 <1/24h (95%+ 减少). ③ **新文件 movespeed_rsync_helper.sh** (~115 行, 6 行接口): 接口 `bash $HOME/movespeed_rsync_helper.sh <caller> -- <rsync args>` (用 `--` 分隔避免与 rsync args 混淆). 4 个 env 覆盖 (NO_SLEEP / NO_RETRY / MAX_ATTEMPTS / BACKOFF_BASE) 让单测可确定性. 防御 clamp MAX_ATTEMPTS 到 [1, 10] 避免 env typo 导致 runaway loop. MR-11 兑现: 所有 diagnostics 写 stderr (避 `$(...)` 命令替换污染). ④ **批量替换 20 个 site** (Python regex automation): 18 个 site 自动替换成功 (含 freight 2 处, 共 19 处) + kb_save_arxiv.sh 字面量 caller `[kb_save_arxiv]` 模式不同手动替换 1 处. 旧模式 `rsync ... 2>&1 || { _rc=$?; echo "WARN..."; capture; }` (1 长行) → 新模式 `bash "$HOME/movespeed_rsync_helper.sh" "$0" -- <args>` (1 清爽行). 验证: 旧模式残留 0 个 (`grep` 无输出), 新 helper 调用 20 个 (1:1 替换). ⑤ **24 新单测** test_movespeed_rsync_helper.py 7 测试类: TestUsageErrors(3 含缺参/缺 -- 分隔符 → exit 2) + TestEnvOverrides(5 含 NO_SLEEP / NO_RETRY 严格 1 次 / MAX_ATTEMPTS=2 严格 2 次 / 999 clamp 到 10 / 非数字 fallback 3) + TestRsyncSuccess(1 第一次成功 0 retry) + TestRsyncRetryRecovers(2 第 2/3 次恢复, 含 'recovered on attempt N' 字面量) + TestRsyncAllRetriesFail(1 含 WARN: SSD + exit 23 propagation) + TestCaptureHelperWired(1 端到端 mock SCRIPT_DIR + capture stub + 验证 marker 写入) + TestSitesMigrationGuard(2 全部 20 site 用 helper + 0 legacy pattern 残留) + TestSourceLevelGuards(9 helper 字面量守卫: V37.9.27 标记 / jitter 30-180s 公式 / MAX_ATTEMPTS=3 / BACKOFF_BASE=10 / clamp 10 / WARN: SSD / capture / stderr 写入 / 可执行权限). **fake rsync 注入策略**: tempfile + PATH 注入 fake bash script 模拟各种 rsync 行为 (always success / always fail / fail-then-success / count attempts), 实证 helper 内部行为不依赖真实 rsync 是否安装. ⑥ **INV-RETRY-001 新增** (meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime], **10 checks**): 8 declaration helper 字面量 + auto_deploy FILE_MAP 部署 + 1 runtime python_assert 跑 24 单测端到端. 与 INV-BACKUP-001 + INV-INCIDENT-001 形成**三阶段防御链**: 失败时取证 (V37.9.4 fail-loud) → 累积时告警 (V37.9.26 watchdog 主动) → 主动修复减少失败 (V37.9.27 jitter+retry). 三 INV 一起覆盖 detection → forensic → alert → recovery 完整链路. ⑦ **INV-BACKUP-001 检测器扩展豁免** (V37.9.27 兼容): 含 `movespeed_rsync_helper.sh` 字面量的 site 自动豁免 `WARN: SSD` 直接字面量检查 + `incident_capture` 直接调用检查 (MR-8 单一真理源: site 通过 helper 间接获得 capture wiring 视为合规). 同步更新 governance yaml 检测器 + test_movespeed_incident_capture.py 单测 + test_kb_deep_dive.py 单测. **不破坏 V37.9.4 检测目的** (生产 rsync 站点必须有 capture wiring), 只改"如何获得 wiring"的接受形式 (直接 OR 通过 helper). ⑧ **MR-4 silent-failure 第 18 次演出新形态**: 前 17 次都在代码层 (单点 silent), V37.9.27 是**架构假设级** silent failure — V37.9.4 整个团队基于"B 问题闭环"假设继续 60 天, 直到 V37.9.26 watchdog 主动告警识破. **原则 #28 反向兑现**: 修复前必答三问"这问题之前存在吗" — 之前**以为**不存在, 实际**一直存在** (V37.9.14 数据从不撒谎). 跳过这一步 = 半年时间被浪费. ⑨ **生产 governance audit 输出对比** (V37.9.26 → V37.9.27): V37.9.26 (1 跑就抓): `19|1|run_github_trending.sh/run_freight.sh/run_hn_fixed.sh/run_rss_blogs.sh/run_arxiv.sh` (24h 19 条触发阈值). V37.9.27 修复后预期一周观察: `<1|0|` (95%+ 减少). 真实修复效果待 5/11 决策窗口前一周 Mac Mini 数据验证. ⑩ **累计**: 49→50 suites (+1) / 1798→1822 tests (+24, V37.9.27 24 单测) / 0 fail / governance 68→69 invariants (+1 INV-RETRY-001) / 413→423 checks (+10) / 17 meta rules / 安全 95/100 / VERSION 0.37.9.26 → 0.37.9.27. ⑪ **下次 V37.9.28+ 候选**: (a) **主硬卡**: 5/11 决策窗口三 spec 切关 dry-run 真激活 machine_sync (jobs_to_crontab + kb_sources_to_index + services_to_launchd). 同时观察 V37.9.27 retry 实战效果 (24h incident 数应 < 1). (b) 立场文章第 6 篇候选: *"我以为闭环了" — 60 天 silent failure 的架构假设级教训* (V37.9.4 → V37.9.26 → V37.9.27 时间线 + 监控发现真相 + 三阶段防御链, Stage 2 第 6 篇资产). (c) V37.9.15 候选剩余: kb_status_refresh.sh 写 24h incident 计数到 status.json. ⑫ **元价值**: V37.9.27 闭环 V37.9.26 立即抓出的真问题, **整个 V37.9.x 系列形成完整自我修正闭环**: V37.9.14 取证 → V37.9.26 主动告警 → V37.9.27 主动修复. 这不是"加监控"故事, 是 framework 自我治理的硬证据 — declared (helper 设计契约) → runtime (24h incident <1) 的 convergence framework 同款模式应用到运维层.|
| V37.9.26 | 2026-05-04 | **watchdog 主动告警升级 — 24h 窗口 ≥5 条 MOVESPEED incident 推 [SYSTEM_ALERT]（V37.9.15 候选闭环 watchdog 部分 + 从被动证据收集升级为主动告警链）** — ① **触发**：V37.9.14 已落地 20 处 rsync fail-loud + JSONL 取证, 但 incidents.jsonl 仅被动累积 (operator 不会主动 cat 看). V37.9.26 升级让 watchdog 每小时 cron 主动消费 incidents.jsonl, 24h 窗口 ≥5 条 → 推 [SYSTEM_ALERT] 含计数 + 最近 5 个 caller basename. 阈值 5 来自 V37.9.4 案例数据 (一周 18 次 = 24h 平均 ~3 次为噪声基线; ≥5 = 噪声 +2σ 异常爆发). ② **新文件 movespeed_incident_monitor.py** (~140 行纯 Python): `parse_iso_to_epoch(ts)` 时间戳解析 (Z suffix / 含 offset / naive UTC fallback) + `extract_caller_basename(path)` basename 提取 + `count_recent_incidents(file, now_epoch, window_seconds=86400) -> (count, callers, parse_errors)` 24h 窗口纯函数 + `format_watchdog_output(count, threshold, callers) -> "{count}|{hit}|{callers}"` pipe 分隔输出 + CLI `python3 movespeed_incident_monitor.py <file> <now_epoch> <threshold>`. **FAIL-OPEN 契约**: 文件 IO 失败 → 输出 `0|0|file_read_error` exit 0 让 watchdog 降级; 损坏 JSON 行 silent skip + parse_errors 计数; 缺 timestamp_iso 字段 silent skip. ③ **MR-8 单一真理源**: 不内嵌 watchdog heredoc, 抽到独立 Python 模块, 单测可直接 import 函数 (不需 subprocess 跑 watchdog), 防漂移. job_watchdog.sh 调 `python3 movespeed_incident_monitor.py "$INCIDENT_FILE" "$NOW_EPOCH" "$INCIDENT_24H_THRESHOLD"` 替代旧 heredoc 模式. ④ **job_watchdog.sh 第 9 维度集成**: 从 8 大维度扩展到 9 (新增 MOVESPEED incidents 累积监控). 双层文件存在性守卫 (`[ -f "$INCIDENT_FILE" ] && [ -f "$INCIDENT_MONITOR" ]`) 确保 dev 环境 / 部署不完整时静默通过. 阈值常量 `INCIDENT_24H_THRESHOLD=5` 明确定义. 触发时 `ALERTS+=("MOVESPEED 24h 内 N 次 rsync 失败...")` 推入 watchdog 标准告警链路 (统一 notify.sh 双通道推送). ⑤ **INV-INCIDENT-001 新增** (meta_rule=MR-4 silent-failure 反向变种延续 V37.9.6 的"过度报"修到 V37.9.26 "升级为主动报", severity=high, verification_layer=[declaration, runtime], **10 checks**): 4 monitor.py declaration (count_recent_incidents / parse_iso_to_epoch / extract_caller_basename / format_watchdog_output 函数定义) + 5 watchdog.sh declaration (调 monitor.py 不内嵌 / 阈值常量 5 / 双层文件存在性 / ALERTS 推送字面量) + 1 auto_deploy FILE_MAP 部署守卫 + 1 runtime python_assert subprocess 跑 36 单测端到端. **与 INV-BACKUP-001 是 sibling**: 前者守证据收集 (V37.9.4/14 fail-loud + JSONL), 后者守证据被消费产告警. 两 INV 一起覆盖 declared → runtime → alert 完整链路. ⑥ **36 新单测** test_movespeed_incident_monitor.py 7 测试类: TestParseIsoToEpoch(7 含 Z suffix / explicit offset / naive UTC / 等价性 / 空字符串 raise / 非字符串 raise / 损坏 raise) + TestExtractCallerBasename(5 含绝对路径 / 相对路径 / 空字符串→? / 嵌套路径 / trailing slash 边界) + TestCountRecentIncidents(7 含空文件 / 24h 窗口边界 1min before/after / 损坏 JSON 行不阻塞 / 缺 timestamp 字段 silent skip / 顶层非 object 计 parse_error / 空白行忽略) + TestFormatWatchdogOutput(4 含阈值命中/不命中 / 0 count 无 callers / caller 截断 5 个) + TestCliBehavior(5 端到端 subprocess 含 happy path / 阈值不命中 / 缺参 exit 2 / invalid epoch exit 2 / FAIL-OPEN file_read_error exit 0) + TestThresholdBoundary(3 反向验证: 恰好 5 触发 / 恰好 4 不触发 / 100 条不崩溃) + TestWatchdogIntegrationGuards(5 源码守卫: watchdog 调 monitor.py / 阈值 5 字面量 / 文件存在性双 guard / **反 inline heredoc 守卫** `parse_iso_to_epoch` 不在 watchdog / `window_24h_start = now_epoch - 86400` 历史 inline 痕迹清除 / monitor.py 文件存在). ⑦ **INV-BACKUP-001 检测器豁免 watchdog (V37.9.26 同款修复)**: V37.9.4 INV-BACKUP-001 检测器扫所有 .sh 含 "rsync" + "MOVESPEED" 字样视为 rsync 站点, V37.9.26 watchdog 加告警消息 "MOVESPEED 24h 内 N 次 rsync 失败" 引入字样导致误判. 按原则 #28 最小修复 = 给检测器加 "monitor consumer 豁免": (a) `test_movespeed_incident_capture.py::test_no_extra_undeclared_sites` 加 `if rel == "job_watchdog.sh": continue` (b) governance INV-BACKUP-001 yaml 内嵌检测器 2 处同款豁免 (WARN log 检查 + forensic capture 检查). 不破坏 V37.9.14 的检测目的 (生产 rsync 站点) 且语义清晰 (watchdog 是消费者不是生产者). ⑧ **auto_deploy.sh FILE_MAP 加 movespeed_incident_monitor.py** + **full_regression.sh 接入** test_movespeed_incident_monitor.py suite. ⑨ **累计**: 48→49 suites (+1) / 1762→1798 tests (+36, V37.9.26 36 单测) / 0 fail / governance 67→68 invariants (+1 INV-INCIDENT-001) / 403→413 checks (+10) / 17 meta rules / 安全 95/100 / VERSION 0.37.9.25 → 0.37.9.26. ⑩ **Mac Mini 部署后预期行为**: dev 环境无 incidents.jsonl → 整段 if [ -f ... ] 跳过, watchdog 8 大维度照常 (新增第 9 维度静默). 生产环境如有 incidents 累积: 24h 内 ≥5 条触发推送 "MOVESPEED 24h 内 N 次 rsync 失败 (≥5 阈值, B 问题连续性复发) callers: run_freight.sh/kb_dream.sh/...". 这是 MR-4 silent-failure 反向变种延续 — V37.9.6 修"过度报", V37.9.26 升级"被动报变主动报". ⑪ **MR-8 单一真理源正向兑现**: monitor.py 是独立纯函数模块, 单测可直接 `from movespeed_incident_monitor import count_recent_incidents` 测试, 不需要 subprocess 跑 watchdog. **5 个反 inline heredoc 守卫** (TestWatchdogIntegrationGuards) 防止未来 watchdog 内嵌副本 → 漂移 → bug. ⑫ **下次 V37.9.27+ 候选** (V37.9.15 候选剩余部分): kb_status_refresh.sh 也消费 movespeed_incidents.jsonl, 把 24h 计数写进 status.json 让三方共享状态可见. 工作量 ~30min, 不阻塞 5/11 决策窗口. 当前阶段重点仍是 5/11 三 spec 同步切关 dry-run.|
| V37.9.25 | 2026-05-04 | **第 5 个 convergence spec services_to_launchd — V37.9.13 候选 launchd plist 持久化方向闭环 + framework 第 5 次扩展验证** — ① **触发**: V37.9.13 status.json unfinished 长期登记 "Mac Mini 重装 / plist 误删后 V37.9.12.1 给 proxy plist 加的 ONTOLOGY_MODE=on env 会丢失" 候选, 等待数版后 V37.9.25 决定不直接守 plist 入仓 (敏感 env vars handling 是更大 deployment 工作), 而是守"声明的 service 是否真在 launchd 注册"上游事实层 — convergence framework 完美适配场景. ② **新文件 services_registry.yaml** (与 jobs_registry.yaml 平行的独立 declared source): 3 个 service 初始声明 (com.openclaw.adapter port 5001 / com.openclaw.proxy port 5002 / ai.openclaw.gateway port 18789) + label/port/plist/description 字段. **设计决策**: 不扩 jobs_registry.yaml schema 因 jobs (scheduled run-and-exit cron) 与 services (persistent supervised launchd) 是不同概念, 独立 source 让 schema 校验 + 文档 + 操作语义清晰分离, 也是 minimal-extension 路径第 5 次实证 (V37.9.20 named-dispatch 第 5 次承诺兑现). ③ **convergence.py 扩展** (零 framework 改动): 新增 `_extract_services_from_registry(spec)` 纯函数读 `data.get("services") or []` → 提取每个 entry 的 `label` 字段作 set[str] 返回 (skip 空 label 防御); 注册到 `_DECLARED_EXTRACTORS["services_from_registry"]` (5 个 extractor: registry_enabled_system_jobs / registry_kb_source_files / providers_from_registry / json_file_paths / services_from_registry). 复用 V37.9.19 `_observe_shell_command` (`launchctl list`) + V37.9.19 `_parse_line_contains_identifier` — 零新 observer + 零新 parser. ④ **convergence_ontology.yaml** spec `services_to_launchd`: declaration.source=services_registry.yaml + extractor=services_from_registry + identifier_field=label / runtime_observable.method=shell_command + command="launchctl list" + parser=line_contains_identifier / drift_action=alert_only (V37.9.19 同款保守路线) / convergence_method.planned=machine_sync_via_helper (V37.9.26+ 升级路径已设计: bash $HOME/restart.sh launchctl kickstart -k 模式 + per-service plist 解析). meta version 0.6-named-dispatch-apply-functions → 0.7-fifth-spec-services-to-launchd, related_invariants 升级到 5 个 INV. v37_9_25_changelog 段记录第 5 spec 上线 + V37.9.13 闭环理由. ⑤ **INV-CONVERGENCE-SERVICES-001** 新增 (meta_rule=MR-17, severity=high, verification_layer=[declaration, runtime], **16 checks**): 4 services_registry.yaml structural 守卫 (services 段 / 3 个 label 字面量) + 2 convergence.py declaration (extractor 注册 + 函数定义) + 8 convergence_ontology.yaml structural 守卫 (spec id / governance_invariant 引用 / extractor / observer / parser / meta version / related_invariants / changelog) + 1 governance_ontology.yaml MR-17 derivative_invariants 引用 + 1 runtime python_assert subprocess 跑 V37.9.25 3 测试类端到端. MR-17 derivative_invariants 终态 [CRON, PROVIDERS, OPENCLAW, KB, INTEGRATION, SERVICES]. ⑥ **23 新单测 3 类**: TestExtractServicesFromRegistry(4 含 真 yaml 解析 / set[str] 类型 / 空 label 跳过 / default source 指向 services_registry.yaml) + TestVerifyServicesToLaunchdIntegration(6 含 dev 不崩溃 / drift_action=alert_only / extractor 名 / command="launchctl list" / parser / dispatch table 注册) + TestServicesSpecSourceGuards(13 含 services_registry 文件存在 / 3 个 service / label 字段计数 / extractor 注册 / 函数定义 / 函数体读 services 段 + label 字段 / yaml spec 声明 / meta version 升级 / related_invariants 5 个 / v37_9_25_changelog / drift_action 块内 alert_only / command 字面量 / governance INV 引用). **反向验证已确认守卫真有效**: 故意 yaml label 改坏 (`com.openclaw.adapter → com.openclaw.adapter_RENAMED`) → `test_extracts_service_labels_from_registry` 立即失败, 还原后 23/23 全绿. ⑦ **auto_deploy.sh FILE_MAP 加 `services_registry.yaml|$HOME/services_registry.yaml`** 部署到 Mac Mini ~/. dev 环境跑通: `declared=3 (com.openclaw.adapter/proxy/gateway), observer_failed (launchctl 不存在), missing=3 alert_only` 输出. ⑧ **Mac Mini 部署后预期输出**: 如 launchd 已 load 3 个 service → `✅ [services_to_launchd] declared=3 observed=3 (no drift)` 第 5 个 spec zero drift baseline; 任一 service 漂移 (plist 误删 / bootstrap 失败) → `⚠️ [services_to_launchd] declared=3 observed=N missing=M (drift_action=alert_only)` 触发告警让 operator 决定是否手动修. ⑨ **累计**: 47→48 suites 不变 (test_convergence.py 内继续扩展类) / 1739→1762 tests (+23) / 0 fail / governance 66→67 invariants (+1 INV-CONVERGENCE-SERVICES-001) / 387→403 checks (+16) / 17 meta rules / 安全 95/100 / VERSION 0.37.9.24 → 0.37.9.25 / **convergence specs 4→5**. ⑩ **下次 (V37.9.26) 候选**: (a) **主硬卡**: services_to_launchd 一周观察期 (5/4 baseline → 5/11 决策窗口) 收集 declared vs observed 数据, 如零漂移升级 drift_action: alert_only → machine_sync + 注册 `_apply_services_launchctl_bootstrap` 到 `_APPLY_FUNCTIONS` dict (per-service launchctl bootstrap "gui/$(id -u)" "<plist_path>", 复用 V37.9.13 restart.sh kickstart -k 模式), Plan B 渐进 dry-run 安全网保留 (b) jobs_to_crontab + kb_sources_to_index 同款 5/11 决策窗口切关 dry-run 真激活 machine_sync (从 V37.9.23/V37.9.24 累积观察期到达) (c) 第 6 个 spec 候选 (X 监控账号声明 / launchd plist 文件 mtime 监控). ⑪ **元价值**: V37.9.25 是 V37.9.20 named-dispatch 设计承诺的**第 5 次实证** (V37.9.20 第 1 / V37.9.22 第 2+3 / V37.9.24 第 4 / V37.9.25 第 5) — 添加新 spec 类型零 framework 改动这条承诺已被 5 个独立 spec + 多种扩展粒度 (full 三件套 / mid-extension 抽 helper / minimal 1 件 / named-dispatch refactor / 独立 source minimal-extension) 实测验证, V3 路标 `pip install ontology-engine` 终极目标的扩展性论证已是硬证据非空头. 同时本 spec 闭环 V37.9.13 长期登记的 plist 持久化候选, 把候选项从 backlog 转为 production audit 主动消费.|
| V37.9.24 | 2026-05-04 | **三件套并行：kb_sources_to_index machine_sync 升级 (named-dispatch 重构) + openclaw_config_to_runtime mock 化加固 + 立场文章 Why Control Plane = Convergence Engine** — ① **任务 B (中优先级 - 主交付)**: kb_sources_to_index spec drift_action `alert_only → machine_sync` (Plan B 渐进 dry-run 同款 V37.9.23). 引入 named-dispatch 重构: 把 V37.9.23 的 `_apply_machine_sync` 重构为顶层 dispatcher, 按 spec yaml `convergence_method.apply_function` 字段路由, 镜像 V37.9.20 `_DECLARED_EXTRACTORS` / V37.9.13 `_CONTEXT_EVALUATORS` 同款模式. **新增 `_APPLY_FUNCTIONS` dict** = `{"jobs_to_crontab_per_entry": _apply_jobs_to_crontab_per_entry, "kb_embed_incremental": _apply_kb_embed_incremental}`. **新增 `_apply_kb_embed_incremental` (one-shot pattern)**: 单次 `python3 ~/openclaw-model-bridge/kb_embed.py` subprocess call 覆盖所有 missing sources (与 jobs_to_crontab 的 per-entry crontab_safe.sh add 模式不同 — kb_embed 启动加载 embedding 模型 ~3s 不应 amortize per-entry, 内部 mtime-diff 已是 batch 处理逻辑, V37.8 锁机制保证 idempotent). 新增 `_KB_EMBED_TIMEOUT_SEC=300` (5min, kb_embed LLM 调用密集). **闭环 V37.9.22 blocker**: V37.9.22 误以为 kb_embed.py 是全量重建, V37.9.24 实证默认无参 = 增量 (mtime diff + 只重 embed 变化文件), 不需新增 CLI args. **V37.9.23 jobs_to_crontab 路径迁移**: `_apply_machine_sync` 主体逻辑移到 `_apply_jobs_to_crontab_per_entry`, 顶层成为 dispatcher; legacy spec.id-based fallback 保 V37.9.23 spec 向后兼容(spec yaml 缺 apply_function 字段时按 spec.id="jobs_to_crontab" 路由). spec yaml 同步: jobs_to_crontab 加 `apply_function: jobs_to_crontab_per_entry` + apply_path `_apply_machine_sync → _apply_jobs_to_crontab_per_entry`; kb_sources_to_index `drift_action: machine_sync` + `apply_function: kb_embed_incremental` + `implemented: machine_sync_via_helper` + `dry_run_default: true`. yaml meta `version: 0.5-machine-sync-dry-run → 0.6-named-dispatch-apply-functions`. 新增 v37_9_24_changelog 段记录三件套. ② **任务 C (低优先级 - 加固)**: openclaw_config_to_runtime spec 同款 V37.9.22 hotfix 教训横向扩展. **新增 `TestOpenclawConfigToRuntimeMockRuntime` 6 单测**: mock `~/.openclaw/openclaw.json` (含 version 字面量 + 不应被读的嵌套字段) + monkey-patch HOME → tempdir + 真跑 `verify_convergence("openclaw_config_to_runtime")` 子进程, 字面量字段名 (V37.9.24 = "version") 一旦未来改成 "release_version" / "schema_version" 单测立即失败. 同时加 `test_yaml_json_paths_field_name_guard` 锁定 declaration / runtime_observable json_paths 字面一致性 (set-diff 前提). ③ **任务 A (中优先级 - 话语权)**: `docs/articles/why_control_plane_is_convergence_engine.md` 304 行立场文章 (Stage 2 第 5 篇资产). 结构: TL;DR + 2 错觉 (Control Plane = Policy Engine / 写更多 audit 就稳) + 3 工程证据 (V37.9.19~24 演进时间线) + 实证 governance audit 输出 + drift_action 4 档洞察 (alert_only / alert_only_permanent / machine_sync / block_until_human) + OPA/Kyverno 对比表 + V3 路标 `pip install ontology-engine` + 5 条可落地原则 + 一句话总结. 核心论点: Control Plane 不只是 policy engine, **必须是 convergence engine** — 声明态与运行时态之间的差距由机器同步而不是由人的记忆同步 (MR-17 立案延伸). ④ **6 个新测试类 27 单测 + 反向验证**: `TestOpenclawConfigToRuntimeMockRuntime(6)` (mock + 字段名守卫 + corrupt JSON + missing file + missing key + non-object) + `TestApplyKbEmbedIncremental(7)` (空 missing / one-shot summary / 截断显示 / mock subprocess success + failure + timeout + missing helper) + `TestApplyMachineSyncNamedDispatch(4)` (路由 kb_sources_to_index 走 one-shot / 路由 jobs_to_crontab 走 per-entry / 未知 apply_function → apply_errors / V37.9.23 legacy id fallback) + `TestV37924SourceLevelGuards(8)` (字面量 grep: `_apply_jobs_to_crontab_per_entry` / `_apply_kb_embed_incremental` / `_APPLY_FUNCTIONS = {` / `_KB_EMBED_TIMEOUT_SEC = 300` / `method.get("apply_function")` / yaml apply_function 字段 / yaml v37_9_24_changelog) + 同步更新 `TestVerifyKbSourcesToIndexIntegration::test_spec_drift_action_machine_sync_v37_9_24` (V37.9.22 alert_only → V37.9.24 machine_sync) + `TestKbSpecSourceGuards::test_yaml_kb_spec_drift_action_machine_sync_v37_9_24` + `test_yaml_kb_spec_apply_function_kb_embed_incremental` + 在 `TestV37923SourceLevelGuards::test_yaml_jobs_to_crontab_implements_machine_sync` 加 V37.9.24 alternation (apply_path 接受新旧两种字面量) + 新加 `test_yaml_jobs_to_crontab_apply_function_named_dispatch_v37_9_24` 守卫 jobs_to_crontab apply_function 字段. **反向验证已确认两层守卫真有效**: (a) yaml `apply_function: kb_embed_incremental` 改成 `bogus_function_name` → `test_yaml_kb_sources_to_index_apply_function` 立即失败, 还原后 217/217 全绿 (b) yaml `json_paths: ["version"]` 改成 `["release_version"]` (V37.9.23 任务 C) → `test_mock_openclaw_json_extracts_version_field` 立即失败, 还原后全绿. ⑤ **governance INV-CONVERGENCE-KB-001 加固**: 删除 V37.9.22 时期 `drift_action: alert_only` 字面量守卫 (已升级 machine_sync), 新增 7 个 declaration 守卫 V37.9.24 helpers/常量/yaml 字面量 (`_apply_kb_embed_incremental` 函数 / `_APPLY_FUNCTIONS = {` / `kb_embed_incremental` 注册条目 / `_KB_EMBED_TIMEOUT_SEC = 300` / `method.get("apply_function")` dispatcher / `apply_function: kb_embed_incremental` yaml / `v37_9_24_changelog` yaml). yaml meta version 守卫 alternation 加 `0.6-named-dispatch-apply-functions`. runtime python_assert v9_22_kb_classes 加 4 个 V37.9.24 测试类 (TestApplyKbEmbedIncremental / TestApplyMachineSyncNamedDispatch / TestV37924SourceLevelGuards / TestOpenclawConfigToRuntimeMockRuntime). ⑥ **生产 governance audit 输出对比**: V37.9.23 → V37.9.24 — `jobs_to_crontab declared=36 observed=0 missing=36 (drift_action=machine_sync) apply[dry-run]=36 apply_errors=0` (per-entry 36 行) + **V37.9.24 新增** `kb_sources_to_index declared=14 observed=0 missing=14 (drift_action=machine_sync) apply[dry-run]=1 apply_errors=0` (one-shot 1 行) — named-dispatch 实证两种 apply 模式并存. machine_sync spec 数 1→2. ⑦ **累计**: 48 suites 不变 (test_convergence.py 内继续扩展类) / 1712 → 1739 tests (+27, V37.9.24 三件套 27 单测) / 0 fail / governance 66 invariants 不变 (INV-CONVERGENCE-KB-001 内涵扩展非新增) / 380 → 387 checks (+7) / 17 meta rules / 安全 95/100 / VERSION 0.37.9.23 → 0.37.9.24 / machine_sync spec 1→2. ⑧ **下次 (V37.9.25) 候选**: (a) **主硬卡**: 一周 dry-run 观察期 (5/4 baseline → 5/11 决策窗口) 收集两个 machine_sync spec 的 apply 字面量, jobs_to_crontab 验证 cron line 拼接结果与生产真实行字面一致, kb_sources_to_index 验证 kb_embed.py 增量调用产 'applied: kb_embed.py incremental (N missing sources)' 真同步成功, 都符合预期后修改 `_is_dry_run()` 默认值让 `CONVERGENCE_DRY_RUN=1` 才 dry-run, 真激活两个 spec 的 machine_sync. (b) 第 5 个 spec 候选 (e.g. launchd plist 持久化或 X 监控账号声明). (c) 立场文章中文版翻译 (why_control_plane_is_convergence_engine_zh.md) 投知乎 / 国内技术社区. ⑨ **元价值**: V37.9.24 三件套并行展现 framework 演进的三个维度 — (B) **可扩展性**: named-dispatch 真扩展, 新 spec 类型 + 新 apply 模式零 framework 改动 (4 个 spec 之后还有 N 个) (C) **可加固性**: 同款 V37.9.22 hotfix 教训横向扩展到第三 spec, dev 单测覆盖 declared + observer command 实际执行的语义层 (A) **话语权输出**: 把 framework 演进升级为对外可复述叙事, V3 路标 `pip install ontology-engine` 的说服力素材. 这是 V3 路标关键里程碑, machine_sync 路径从"概念"升级为"两个真实生产 spec 同时运行"的硬证据.|
| V37.9.23 | 2026-05-04 | **`jobs_to_crontab` → `machine_sync` 升级 (Plan B 渐进 dry-run) + spec yaml command 字段读取层 mock 化加固 (V37.9.22 hotfix 教训闭环)** — ① **触发**：2026-05-03 (V37.9.19 baseline 4-26 + 7d) 是 jobs_to_crontab → machine_sync 决策窗口到达日。一周观察期内 declared=36 observed=36 零漂移零误报，V37.9.19 设定的 alert_only "等一周" 谨慎策略已兑现。同时 V37.9.22 收工注释中登记 V37.9.23 加固候选: spec yaml command 字段读取语义层 mock 化测试（4/29 hotfix 9d60dd3 教训 — dev 单测全过 + governance 全过 + Mac Mini preflight 全过 但 framework 实测才暴露字段名 source_file → file 假设错）。② **任务 1: jobs_to_crontab → machine_sync 升级（Plan B 渐进 dry-run）**：用户在三个方案（A 保守 manual `--apply` / B 渐进 dry-run / C 激进直切）中选 B。**convergence.py 核心扩展**：(a) 新增 `_format_cron_line(job)` 纯函数 — 从 jobs_registry job dict (interval/entry/log) 拼 cron 行字符串，匹配 V37.9.18 INV-CRON-003 `_cron_cmd_invokes` 模式 (`<interval> bash -lc 'bash ~/<entry> >> <log> 2>&1'`)，validates 5-field interval + 非空 entry/log + 拒绝 shell metacharacter (`'` / `` ` `` / `$(` / `;` / `&` / `|`) defense-in-depth (b) 新增 `_apply_machine_sync(spec, missing_entries, dry_run=None)` orchestrator — 通过 `crontab_safe.sh add` helper 真同步 cron line，FAIL-OPEN 收集 `(applied_actions, apply_errors, dry_run)` 三元组 (c) 新增 `_is_dry_run()` env reader — `CONVERGENCE_DRY_RUN` env var (任何非 "0" 值都视为 dry-run 安全默认) (d) 新增 `_MACHINE_SYNC_TIMEOUT_SEC=15` subprocess timeout 常量 (e) 新增 `_load_jobs_registry_index(spec)` helper — id→job 字典 O(1) 查找用于 missing entry → cron line 拼接 (f) `verify_convergence` 加 `drift_action == "machine_sync"` 分支调用 `_apply_machine_sync`，FAIL-OPEN 包装 (g) `format_result_for_log` 追加 apply 信息 — `apply[dry-run]=N apply_errors=M` 字面量可观测。**ConvergenceResult namedtuple 末尾追加 3 字段**（用 `defaults=((), True, ())` Python 3.7+ namedtuple defaults 向后兼容）：`applied_actions: tuple[str]` / `apply_dry_run: bool` / `apply_errors: tuple[str]`。所有现有 ConvergenceResult kwargs 构造点零改动（默认值生效）。③ **convergence_ontology.yaml 切换**：jobs_to_crontab spec `drift_action: alert_only → machine_sync`，新增 `convergence_method.implemented` (替代 V37.9.19 `planned`) + `dry_run_default: true` + `apply_path: convergence._apply_machine_sync` + `dry_run_env_var: CONVERGENCE_DRY_RUN`。meta 升级 `version: 0.4-fourth-spec → 0.5-machine-sync-dry-run` + `status: framework_jobs_to_crontab_machine_sync_dry_run_one_week_observation`。新增 `v37_9_23_changelog` meta 段记录 Plan B 三阶段路径 (V37.9.19 alert_only → V37.9.23 machine_sync+dry-run → V37.9.24+ dry-run 切关) + 安全契约。④ **6 个新测试类 42 单测 + 反向验证**：`TestFormatCronLine(11)` happy path / V37.9.18 INV-CRON-003 模式守卫 / 5-field interval 校验 / shell metachar 拒绝 / 非 dict raise / 空 interval 边界 / log 路径前缀变体 + `TestIsDryRun(5)` env var 各种值 (unset/0/1/true/empty) + `TestApplyMachineSyncDryRun(5)` 空 missing / 真实 entry dry-run / 未知 entry apply_error / 排序 / 显式 dry_run 覆盖 env + `TestApplyMachineSyncReal(4)` mock subprocess.run 三种结果 (success/failure/timeout/helper missing) + `TestVerifyConvergenceMachineSyncIntegration(5)` 端到端 36 dry-run 行 / alert_only spec 三新字段默认 / format_result_for_log apply 信息 / yaml 字面量守卫 + `TestV37923SourceLevelGuards(10)` convergence.py + yaml 字面量 grep 守卫。**反向验证已确认两层守卫真有效**: (a) 故意 yaml 改回 `drift_action: alert_only` → 4 个 V37.9.23 升级守卫立即失败（`test_yaml_first_spec_drift_action_machine_sync_escalation_v37_9_23` / `test_real_spec_completes_without_raising` / `test_machine_sync_spec_dry_runs_in_dev` / `test_jobs_to_crontab_real_yaml_says_machine_sync`），还原后全绿 (b) V37.9.22 任务 5 加固反向验证 (yaml `c.get('file') → c.get('source_file')`) 同款。⑤ **任务 5: kb_sources_to_index spec yaml command 字段读取层 mock 化加固**：`TestKbSourcesToIndexCommandRuntime(6)` 构造 mock `~/.kb/text_index/meta.json` + monkey-patch HOME → tempdir + 真跑 verify_convergence subprocess（V37.9.22 dev 单测只测 declared extractor 逻辑层，没测 observer command 实际执行路径 + JSON 字段读取语义层）。覆盖：核心 mock + 反例 source_file 字段污染 / 字面量守卫 yaml command 必须读 `file` 不能读 `source_file` / 空 chunks / declared 外 basename / 异常 schema / 空字符串 file。⑥ **governance INV-CONVERGENCE-CRON-001 加固**：删除 V37.9.19 的 `drift_action: alert_only` 字面量 grep 守卫（语义已改 + file_contains 不能限定到 jobs_to_crontab 块），新增 8 个 declaration 守卫 V37.9.23 helpers 字面量（`_format_cron_line` / `_apply_machine_sync` / `_is_dry_run` 函数 / `CONVERGENCE_DRY_RUN` env / `_MACHINE_SYNC_TIMEOUT_SEC = 15` / `drift_action == "machine_sync"` wiring 分支 / `implemented: machine_sync_via_helper` yaml / `dry_run_default: true` yaml / `v37_9_23_changelog` yaml）。declaration 段 + lesson 段 + design_decision 段重写记录 V37.9.23 升级语义 + Plan B 三阶段路径 + 为何选 B 而非 A/C。INV-CONVERGENCE-KB-001 runtime python_assert v9_22_kb_classes 加 `TestKbSourcesToIndexCommandRuntime`。⑦ **governance_checker.py print_convergence_results 升级**：`run_convergence_specs()` 输出 dict 加 3 新字段 `applied_count/apply_dry_run/apply_errors_count`，`print_convergence_results` 在 drift_detected + machine_sync 分支追加 `apply[dry-run]=N apply_errors=M` 字面量可观测。⑧ **生产 governance audit 输出**: `⚠️ [jobs_to_crontab] — declared=36 observed=0 missing=36 (drift_action=machine_sync) apply[dry-run]=36 apply_errors=0` ✓ — 36 个 missing entries 全部 dry-run apply 产 36 行 "DRY-RUN would apply: 30 22 * * * bash -lc 'bash ~/X >> Y 2>&1'" 字面量，0 errors。Mac Mini 同步后可看真实 cron line 拼接结果验证一周。⑨ **累计**: 47 suites 不变 (V37.9.22 任务 5 加固 + V37.9.23 任务 1 都在 test_convergence.py 内扩展类) / 1670 → 1712 tests (+42, V37.9.23 plan B 11+5+5+4+5+10+1+1=42) / 0 fail / governance 66 invariants 不变 (INV-CONVERGENCE-CRON-001 内涵扩展非新增) / 372 → 380 checks (+8) / 17 meta rules / 安全 95/100 / VERSION 0.37.9.22 → 0.37.9.23。⑩ **下次 (V37.9.24) 候选**: (a) **主硬卡**: 一周 dry-run 观察期 (5/4 baseline → 5/11 决策窗口) 收集 cron line 拼接结果，验证 `_format_cron_line` 输出与 Mac Mini 真实 crontab 行字面一致后切关 `CONVERGENCE_DRY_RUN` env 默认值真激活 machine_sync — 修改 `_is_dry_run()` 让 `CONVERGENCE_DRY_RUN=1` 才 dry-run，未设/=0 都激活 (b) `kb_sources_to_index` machine_sync 升级 (kb_embed.py 增量 re-index 路径) (c) 立场文章 *Why Control Plane = Convergence Engine* (4 spec + framework + integration + machine_sync 全栈案例素材已齐) (d) `openclaw_config_to_runtime` spec mock 化加固 (V37.9.23 同款模式 — 它也用 yaml 内嵌 json_paths 引用 openclaw.json 字段名)。⑪ **元价值**: V37.9.23 是 MR-17 (declared-state-must-converge-to-runtime-via-machine-not-memory) 的真正兑现 — V37.9.19 立 MR-17 时承诺"机器同步替代记忆同步"，但前 4 个 V37.9.x 版本都停留在"机器可检测"alert_only 阶段。V37.9.23 把 jobs_to_crontab 升级到"机器可同步"，Plan B 渐进路径 (drift_action+dry-run+observation+激活) 在保留安全网的前提下实现这个升级。这是 V3 路标 `pip install ontology-engine` 终极目标的关键里程碑 — 对外输出的 framework 不仅有"声明→检测"还有"声明→同步"完整闭环。|
| V37.9.22 | 2026-04-29 | **OpenClaw 升级 tripwire 决策框架 + 双小迭代 + Phase 4 Layer 5 闭合 (一日 5 commits)** — ① **OpenClaw 升级第三次评估（实证版）**：用户授权 WebFetch 实证查 #59265 → closed at 4/25 但 issue page 显示 "No branches or pull requests" + v2026.4.26 完整 changelog 无任何引用 → closed 状态变化但 NO PR 无 verified fix evidence。同时发现 v2026.4.26 新硬阻塞 #73358 (silent OpenAI codex/gpt-5.5 default — 我们无 OpenAI key 升级即业务中断)。**结论：继续 hold，理由比早上推断版本更强**。② **引入 Tripwire 决策框架** 替代"看到新版本就评估"模式：6 条触发器（时间上限180天/版本差距50个 stable/EOL信号/WhatsApp破坏性变更/CVE人工标记/业务痛点人工标记），0/6 触发时自动 hold，任一触发启动正式评估。`check_upgrade.sh` 重写 88→248 行（dev 环境降级模式 + 全部状态可见 V37.3 INV-GOV-001 同款不静默吞）。`docs/gateway_upgrade_eval_v2026.4.md` 新增第十一节实证版 + 第十二节 Tripwire 框架。③ **#6 kb_deep_dive wa_parts WARN**（小迭代）：V37.9.21 跨文件部署不一致期 silent fail 教训（MR-4 第 17 次新形态）闭合 — heredoc 加 `"wa_parts" not in data` 检测 → `file=sys.stderr` WARN 不污染 `$(...)` 命令替换。6 新单测含 4 个 behavior-level subprocess 真跑 heredoc 验证 stderr 含 WARN/stdout 仅含 count。④ **#2 第三个 convergence spec `openclaw_config_to_runtime`**：V37.9.20 named-dispatch 第二次扩展验证 — 新增 `_extract_json_file_paths` 通用 JSON 文件 extractor + 抽出 `_walk_json_paths_to_set` 共用 helper（V37.9.20 `_parse_json_set_union` 改用之，MR-8 单一真理源），spec 默认观察 `~/.openclaw/openclaw.json` 顶层 `version` 字段 vs Gateway `:18789/health` 同字段。drift_action=alert_only_permanent。FAIL-OPEN: dev 无文件 → `set()`。INV-CONVERGENCE-OPENCLAW-001 (13 checks) + 38 新单测 4 类。⑤ **#3 第四个 convergence spec `kb_sources_to_index`**（minimal extension 路径首次验证）：只新加 1 个 extractor `_extract_registry_kb_source_files`（registry-specific）零新 observer/parser — 复用 V37.9.19 shell_command + line_contains_identifier。证明 framework 多种扩展粒度。spec 验证 jobs_registry kb_source_file 字段（14 declared）vs `~/.kb/text_index/meta.json` chunks[].source_file basename。INV-CONVERGENCE-KB-001 (13 checks) + 20 新单测 3 类。Sibling 关系 vs V37.9.5 INV-KB-COVERAGE-001（前者守源码逻辑，后者守运行时事实，互补不替代）。⑥ **#4 governance_checker 集成 verify_convergence**（Phase 4 Layer 5 闭合）：framework 跨过"unit tested" → "production deployed" 门槛 — `governance_checker.py` 新增 `run_convergence_specs()` + `print_convergence_results()` 函数，`__main__` 流程加 convergence phase 在 invariants/MRD 之后，JSON combined dict 加 `convergence` 键。drift_detected 是 informational (drift_action=alert_only) **不影响 exit code**（与 V37.9.19 framework "drift_action 不是 enforcement" 一致）。FAIL-OPEN: framework 异常单条 error 结果不阻塞主 audit。INV-CONVERGENCE-INTEGRATION-001 (9 checks) 含 2 runtime python_assert subprocess 真跑 `--json` 验证 4 spec + dev exit 0。MR-17 derivative_invariants 终态 [CRON, PROVIDERS, OPENCLAW, KB, INTEGRATION]。⑦ **累计 (今日 5 commits)**: 47→48 suites (+1) / 1600→1664 tests (+64) / 0 fail / governance 63→66 invariants (+3) / 337→372 checks (+35) / 16 meta rules / 安全 95/100 / VERSION 0.37.9.21 → 0.37.9.22 / convergence specs 2→4 (+2)。⑧ **元价值**：V37.9.22 是 V37.9.19 framework 设计正确性的**第三次实测**（V37.9.20 第一次, V37.9.22 第二次+第三次同日双扩展 + 集成入主 audit），proves named-dispatch 不是空头承诺：(a) 添加新 spec 类型零 framework 改动 (b) 多种扩展粒度（full 三件套 / 抽 helper / minimal 1 件） (c) framework 真集成入生产 audit 流程。V3 路标 `pip install ontology-engine` 终极目标的**关键拐点** — 从"测试时被调用"升级为"每日 audit 主动消费"。⑨ **下次 V37.9.23 候选**：(a) [主硬卡] jobs_to_crontab → machine_sync 决策窗口 2026-05-03 (4-29 进度 3/7) (b) 立场文章 *Why Control Plane = Convergence Engine*（4 spec + framework + integration 全栈案例素材已齐）(c) machine_sync 实施路径设计（cron 行模板从 jobs_registry interval+entry+log_path 字段生成）。|
| V37.9.21 | 2026-04-27 | **kb_deep_dive WhatsApp 多窗口分片（Dream-style）— 用户视角发现 → 同日闭环（原则 #13 兑现）** — ① **触发**：用户 V37.9.20 收工后反馈 kb_deep_dive 推送内容超 WhatsApp 单窗口可视范围（截断后看不全），明确要求"类似 dream 的长内容，使用 1/2 和 2/2 两个连续的窗口"。原则 #13 (定期像用户用) 正向兑现 — 单测/治理全绿但用户实际使用才暴露 UX 缺口。② **3 个设计决策（修复前先确认 #28 理解再动手）**：(1) **分片范围**：只 WA 分片 / Discord 保持 1900 字单条 + KB 链接（Discord 频道天然适合点链接看完整 markdown，WA 是手机阅读必须当场看完）(2) **单段预算**：1400 字（与 V37.9.16 原 budget 一致避免破坏其他假设）(3) **每段 header**：每段都带精简 header `🔬 每日深度 [i/N] {date}{mode_tag}\n{title}\n⭐{stars} \| {source_label}`（用户切换聊天来回时仍能看到上下文，Dream 同款）+ link 仅在 Part 1（节省字数留给正文）。③ **新增 `_split_text_into_chunks(text, max_chunk)` 纯函数**（kb_deep_dive.py +56 行）：四级 boundary fallback — (a) 段落边界 `\n\n`（最优，deep_dive 内容天然有 论证链/实验对比/局限性/启发 4 节）(b) 行边界 `\n`(c) 中英文句号 `。/！/？/. /! /? `(d) 硬切。`rfind` 在 `[max*0.5, max]` 窗口找边界避免切得太短，找不到则 fallback 到下一级。镜像 kb_dream.sh:1263-1290 同款模式但加段落优先层。④ **新增 `build_deep_dive_wa_parts(entry, mode, llm_content, date_str) -> list[str]`**（+78 行）：单段时省略 `[i/N]` 标识更干净，多段时每段独立 header + 仅 Part 1 含 link + body 经 splitter 切到 `_WA_BODY_BUDGET_PER_PART=1200` 字内（header 留 ~200 字 buffer，总不超 `_WA_BUDGET_PER_PART=1400`）。⑤ **`run()` 返回新增 `wa_parts: list[str]` 字段** + **保留 `wa_message: str` 向后兼容**（= `wa_parts[0]`），任何未迁移的 consumer 仍可读旧字段。⑥ **`build_deep_dive_wa(...)` 改为 thin wrapper** 调用 `build_deep_dive_wa_parts` 取 `parts[0]`，保留所有现有测试 + 调用点零改动。⑦ **kb_deep_dive.sh +63 行**（V37.5.1 env-var heredoc 反模式防御保留）：`mktemp -d` 创建 `WA_CHUNK_DIR` + `trap 'rm -rf "$WA_CHUNK_DIR"' EXIT` 自动清理 + Python heredoc 写每段到 `000.txt/001.txt/...` + 双路径循环（`send_wa_parts_via_notify` 走 notify.sh / `send_wa_parts_via_openclaw` fallback 走 openclaw 直发）+ `for chunk_file in "$WA_CHUNK_DIR"/*.txt` 遍历 + 段间 `sleep 1` 避免 WhatsApp 消息乱序（Dream 同款契约）+ `WA_SEND_OK/$WA_PARTS_TOTAL` 进度可观测 + 失败逐段独立 log WARN。Discord 路径不变（单条 1900 字）。⑧ **23 新单测** test_kb_deep_dive.py 61→84 tests (+23) 4 类：(a) `TestSplitTextIntoChunks(7)`：short_text/empty/paragraph_boundary/line_boundary/no_boundary_hard_cut/preserves_full_content/chinese_punctuation_boundary (b) `TestBuildDeepDiveWaParts(9)`：short_single_part/long_multi_part/each_part_has_indexed_header/link_only_on_first_part/each_part_within_budget/abstract_mode_tag_on_each_part/empty_returns_empty_list/full_content_preserved_across_parts (核心 — 50 个 distinctive markers 跨段全部保留断言无内容丢失)/backward_compat_returns_first_part (c) `TestRunOrchestrator.test_ok_path_returns_wa_parts_list(1)`：run() 长 LLM 内容产 list[str] + wa_message==wa_parts[0] (d) `TestKbDeepDiveShellGuards(6)`：V37.9.21 marker / env-var heredoc 反模式 / mktemp+trap 清理 / `for chunk_file ... sleep 1` 循环 / WA+Discord 独立 send / `WA_SEND_OK/$WA_PARTS_TOTAL` 可观测 log。⑨ **smoke test 实测**：构造 ~3500 字深度分析（4 sections × ~600 字段落），splitter 产 4 段 (1304/694/1131/1086 字)，每段都有 `[i/4]` indicator，Part 1 带 link，Parts 2-4 无 link 节省字数 — 边界全选中段落 (`## ` heading 前的 `\n\n`)，没有句子被切成两段。⑩ **累计**: 48 suites (不变) / 1577→1600 tests (+23) / 0 fail / 安全 95/100 / VERSION 0.37.9.20 → 0.37.9.21。**无新 governance INV** — V37.9.16 决策（INV-DEEP-001 shadow 一周后再考虑）仍生效，多窗口分片是 UX 增量非安全边界，23 个 source-level + behavior-level test 已是充分守卫。⑪ **MR-7 (用户视角观察→24h 闭环) 第 3 次正向兑现** — V37.9.16 上线 kb_deep_dive → V37.9.17 picker tier-aware fallback (用户首跑发现选错论文等级) → V37.9.21 多窗口分片 (用户日常使用发现内容截断)。每次都是用户视角缺口被同日闭环。⑫ **下次 V37.9.22 候选**（V37.9.21 把原 V37.9.21 计划项推到 V37.9.22+）：(a) [主仍硬卡] jobs_to_crontab → machine_sync 决策窗口 2026-05-03 (今天 4-27 进度 1/7) (b) 第三个 spec `openclaw_config_to_runtime` (c) `kb_sources_to_index` 第四 spec (d) governance_checker 集成 `verify_convergence` (e) 立场文章 *Why Control Plane = Convergence Engine*。⑬ **Mac Mini 部署路径**：kb_deep_dive.py + kb_deep_dive.sh 都在 auto_deploy.sh FILE_MAP 内 (V37.9.16 已配置)，next 22:30 cron 自动用新版。如要立即测试: `bash ~/kb_deep_dive.sh` 手动触发观察 WhatsApp 多段 + Discord 单条。|
| V37.9.20 | 2026-04-27 | **第二个 convergence spec providers_to_adapter — V37.9.19 named-dispatch 扩展性首次兑现 (MR-8 正向案例 + Phase 4 Layer 5 从单 spec demo 升级为可扩展抽象)** — ① **触发**：V37.9.19 framework 上线时承诺 named-dispatch 三表 (`_DECLARED_EXTRACTORS` / `_RUNTIME_OBSERVERS` / `_IDENTIFIER_PARSERS`) 镜像 V37.9.13 `_CONTEXT_EVALUATORS` / V37.9.15 `_STATIC_SIGNAL_KEYS` 模式让"添加新 spec 类型只需 yaml 声明 + 注册新函数零 framework 改动"。V37.9.20 首次实测兑现：核心 `verify_convergence` orchestrator 改动 = **0 行**，全部扩展通过新 dispatch 函数 + 新 spec yaml 完成。② **新增 3 个 dispatch 函数**（convergence.py +144 行，全部纯函数零 I/O at import）：(a) `_extract_providers_from_registry(spec)` 读 `providers.ProviderRegistry.list_names()`（含 7 built-in qwen/openai/gemini/claude/kimi/minimax/glm + auto-discovered providers.d/ YAML/Python 插件），late import 避开模块加载期硬依赖，FAIL-OPEN 包装 ImportError/registry 异常为 RuntimeError 让 framework 转 extractor_failed (b) `_observe_http_endpoint(spec)` 用 stdlib `urllib.request` GET，**`_HTTP_OBSERVER_TIMEOUT_SEC=5` 常量**保护 governance audit cron 不挂 + FAIL-OPEN 包装所有 HTTPError/URLError/socket.timeout/connection_refused 为 RuntimeError 让 framework 转 observer_failed + 显式 UTF-8 解码 errors='replace'（V37.8.6 surrogate 血案防御复用）(c) `_parse_json_set_union(spec, raw, declared)` 走 `spec.json_paths` 配置（`field` 标量 / `field[]` list 后缀两种语法）取 union 后**与 declared 求交**保持 V37.9.19 line 248 "observed ⊆ declared 框架契约" + 防御 list 路径上非 list 值 raise / scalar 路径上 dict/list 值 silent skip。三表新增条目 `"providers_from_registry": _extract_providers_from_registry / "http_endpoint": _observe_http_endpoint / "json_set_union": _parse_json_set_union`。③ **convergence_ontology.yaml v0.1-skeleton → v0.2-second-spec**：新增 `providers_to_adapter` spec 节点 (declaration.source=providers.py / extractor=providers_from_registry / runtime_observable.method=http_endpoint url=`http://localhost:5001/health` timeout_sec=5 parser=json_set_union json_paths=[provider, fallback, fallback_chain[]] / drift_action=alert_only / **convergence_method.planned=alert_only_permanent** 永久结构性决策因 API key 无法 machine 自动 provision（与 V37.9.19 jobs_to_crontab `planned=machine_sync_via_helper` 形成对照），meta `related_invariants` 升级 [INV-CONVERGENCE-CRON-001] → [..., INV-CONVERGENCE-PROVIDERS-001]，meta `next_step` 更新指向 V37.9.21 候选（jobs_to_crontab→machine_sync escalation / openclaw_config_to_runtime / kb_sources_to_index / governance_checker 集成 verify_convergence）。④ **INV-CONVERGENCE-PROVIDERS-001** 新增（meta_rule=MR-17, severity=high, verification_layer=[declaration, runtime], **14 checks**）：5 个 dispatch registration 守卫 (extractor/observer/parser 三个 dict 条目 + `_HTTP_OBSERVER_TIMEOUT_SEC=5` 常量 + http_endpoint failed 错误前缀字面量) + 8 个 yaml structural 守卫 (spec id / governance_invariant 引用 / method=http_endpoint / parser=json_set_union / convergence_method=alert_only_permanent / meta version 0.2-second-spec / 双 INV 引用 / blood lesson link kb_evening_fallback_quota_chain_case.md V37.8.10) + 1 个 runtime python_assert subprocess 跑 `unittest -v` 5 个 V37.9.20 测试类 (`TestExtractProvidersFromRegistry / TestObserveHttpEndpoint / TestParseJsonSetUnion / TestVerifyProvidersToAdapterIntegration / TestProvidersSpecSourceGuards`) 端到端覆盖 35 单测。MR-17 derivative_invariants 升级 [INV-CONVERGENCE-CRON-001] → [..., INV-CONVERGENCE-PROVIDERS-001]。⑤ **35 新单测** test_convergence.py 49→84 tests (+35) 5 类：TestExtractProvidersFromRegistry(3 含 set+string 类型 / builtin 7 ≥4 floor / 空名过滤) + TestObserveHttpEndpoint(6 含 missing_url ValueError / invalid_timeout 容错 / connection_refused RuntimeError 不冒 URLError / 短 timeout TEST-NET-2 RFC5737 IP 不可达 RuntimeError / mock urlopen 200 happy path / mock 500 status 错误) + TestParseJsonSetUnion(12 含 basic 三路径 union / observed⊆declared 契约 / 缺 key 跳过 / 空 raw 空集 / 非 JSON ValueError / 顶级非 object ValueError / 缺 paths config ValueError / 空 paths list ValueError / list_path 非 list 值 ValueError / scalar_path dict 值 silent skip / null list 元素 skip / 非 string path skip) + TestVerifyProvidersToAdapterIntegration(3 真 spec dev 不崩溃 / happy path mock /health 3 visible / full visibility 7/7 zero drift) + TestProvidersSpecSourceGuards(11 含 alert_only_permanent **永久守卫** + machine_sync 字面量禁止 + meta version bump + 双 INV 引用 + 双 blood lesson link)。⑥ **MR-8 正向兑现** (copy-paste-is-a-bug-class)：核心 `verify_convergence` orchestrator **零修改** — V37.9.19 line 305-383 的 5 步骤 (load_spec / extract_declared / observe_runtime / parse_observed / compute_drift) 完全不动，仅扩 dispatch 表。对比 V37.9.13 `_resolve_max_tools_limit` 与 `_resolve_max_tool_calls_per_task_limit` 故意写两份独立函数（独立日志/告警目的）— 这里复用是因为 framework 行为对称（同一 spec 类型只是数据不同）。MR-7 兑现：Phase 4 Layer 5 Convergence Framework 从"单 spec demo"升级为"可扩展 control plane 抽象"，proves declarative spec design 不是空话。⑦ **dev 环境 FAIL-OPEN 行为验证**：`python3 ontology/convergence.py --spec providers_to_adapter` 输出 `error=observer_failed: http_endpoint url_error: [Errno 111] Connection refused declared=7 observed=0` exit=2 — adapter 不在 dev 跑是预期，与 V37.9.19 dev 无 crontab 时 jobs_to_crontab 行为对称（observer_failed → declared 全报 missing 给 ops 可见性）。⑧ **累计**: 47→48 suites (+1, test_convergence.py 49→84 tests 主要扩展) / 1542→1577 tests (+35) / 0 fail / governance v3.33→v3.34 / 62→63 invariants (+1 INV-CONVERGENCE-PROVIDERS-001) / 311→337 checks (+14: 5 declaration dispatch + 8 declaration yaml + 1 runtime) / 17 meta rules 不变 (MR-17 已立 V37.9.19) / 安全 95/100 / VERSION 0.37.9.19 → 0.37.9.20。⑨ **Mac Mini 部署路径**：ontology/ 走 V37.9.12.1 symlink 机制（`$HOME/ontology` → `$HOME/openclaw-model-bridge/ontology`）convergence.py + convergence_ontology.yaml 自动生效。手动验证 Mac Mini: `python3 ~/openclaw-model-bridge/ontology/convergence.py --spec providers_to_adapter` 应输出形如 `[convergence:providers_to_adapter] DRIFT action=alert_only missing=N [openai,kimi,minimax,...]`（大概率 4-5 个 provider 缺 API key），exit 1。也可 `--all` 同时跑 jobs_to_crontab + providers_to_adapter 两 spec。⑩ **下次 (V37.9.21) 候选**：(a) jobs_to_crontab drift_action 从 alert_only 升级 machine_sync — 一周观察期 baseline 2026-04-26 → 决策窗口 2026-05-03（V37.9.20 与本任务并行的硬卡点）(b) 第三个 spec `openclaw_config_to_runtime`（监听 ~/.openclaw/openclaw.json 声明 vs 实际 OpenClaw runtime — 镜像 V37.9.16 #48703 hotfix 部署 vs 本地 OpenClaw 版本类血案）(c) 第四个 spec `kb_sources_to_index`（subsume V37.9.5 INV-KB-COVERAGE-001 入统一 framework）(d) governance_checker 集成调 `verify_convergence` — 让每日 governance audit cron 主动跑所有启用 spec (e) 立场文章 "Why Control Plane = Convergence Engine"（OPA 只做声明→决策 vs OpenClaw 做声明→运行时事实闭环的差异化定位）。⑪ **元价值**：V37.9.19 ontology 子项目升级为 control plane 核心抽象后，V37.9.20 是**第一次实测**这个抽象是否真的可扩展。结果 = 144 行新 dispatch 函数 + 30 行 yaml + 14 governance check + 35 单测 + zero verify_convergence 改动。这是 V3 路标 `pip install ontology-engine` 终极目标的**必备前提条件**——如果 V37.9.19 framework 是空头承诺，连第二 spec 都需要改 verify_convergence，那 pip 包化无望。V37.9.20 是 framework 设计正确性的硬证据。|
| V37.9.19 | 2026-04-26 | **Phase 4 Layer 5 上线 — Convergence Framework + MR-17 + 第一个 spec jobs_to_crontab（declared→runtime 同步从"靠记忆"升级为"机器化"）** — ① **触发**：V37.9.18 反思暴露根本盲区 — 1478 单测 + 309 governance check + 81 preflight 项**全在仓库内层**，但运行时事实在仓库外（cron/process/http/filesystem）。SOUL.md/CLAUDE.md 是**建议**（靠下次 session 读到），governance/preflight 是**约束**（机器强制）。本次升级"声明→运行时同步"从纪律问题为架构硬规则。② **MR-17 立案** `declared-state-must-converge-to-runtime-via-machine-not-memory`（governance_ontology.yaml meta_rules 段 +56 行，severity-implicit critical，derivative_invariants=[INV-CONVERGENCE-CRON-001]）：阐述 5 类典型声明态/运行时态对应（jobs_registry↔crontab / openclaw.json↔OpenClaw runtime / providers.d↔adapter fallback chain / KB sources↔text_index / launchd plist↔launchctl list）+ 与 MR-1/MR-3/MR-4/MR-9 关系澄清（MR-17 是 MR-4 silent-failure 的上游预防层）+ 实施路径 V37.9.19→V3 路标。③ **新文件 `ontology/convergence.py`** (~330 行纯函数 framework, 零 I/O at import)：`ConvergenceResult` namedtuple (7 字段 spec_id/declared/observed/missing_in_runtime/drift_detected/drift_action/error 字段顺序稳定 immutable) + `_VALID_DRIFT_ACTIONS=("alert_only","machine_sync","block_until_human")` 三档 + `_DEFAULT_DRIFT_ACTION="alert_only"` + `_SHELL_COMMAND_TIMEOUT_SEC=10` + Named-dispatch 三表（`_DECLARED_EXTRACTORS={"registry_enabled_system_jobs":...}` / `_RUNTIME_OBSERVERS={"shell_command":...}` / `_IDENTIFIER_PARSERS={"line_contains_identifier":..., "line_contains_word_boundary":...}` 添加新 spec 类型只需 yaml 声明+注册新函数零 framework 改动 — 镜像 V37.9.13 `_CONTEXT_EVALUATORS` / V37.9.15 `_STATIC_SIGNAL_KEYS` 同款 dispatch 模式）。**FAIL-OPEN 契约**：`verify_convergence(spec_id)` 无论 spec_not_found / extractor_failed / observer_failed / parser_failed / invalid_drift_action / spec_disabled 全部返回 `result.error` 字段填充的合法 namedtuple，**绝不 raise**；observer 失败时 `missing_in_runtime=declared_fs` 让 ops 仍能看到"如果 observe 成功这些会缺失"。`_observe_shell_command` 特殊处理 `crontab -l` 无 crontab 用户场景（exit≠0 + empty stdout → 视为"empty observed"非 hard error）。④ **新文件 `ontology/convergence_ontology.yaml`** (Phase 4 Layer 5 spec 声明)：meta 0.1-skeleton 引用 MR-17 + V37.9.20/21 next_step 路标 + 第一个 spec `jobs_to_crontab`（declaration.source=jobs_registry.yaml extractor=registry_enabled_system_jobs identifier_field=entry / runtime_observable.method=shell_command command="crontab -l" parser=line_contains_identifier / drift_action=alert_only + drift_action_rationale 阐述为何 V37.9.19 不直接 machine_sync / convergence_method.planned=machine_sync_via_helper + planned_blocker 说明 V37.9.20 才能模板化 cron 行 / governance_invariant=INV-CONVERGENCE-CRON-001 / blood_lesson_link 引用 case doc）。⑤ **INV-CONVERGENCE-CRON-001** `jobs-registry-converges-to-crontab`（meta_rule=MR-17, severity=high, verification_layer=[declaration, runtime], 14 checks）：12 declaration check 守卫 convergence.py 关键 API + namedtuple + dispatch 表 + drift_actions 常量 + convergence_ontology.yaml jobs_to_crontab spec + drift_action=alert_only + governance_invariant 引用 + meta MR-17 引用 + governance_ontology.yaml MR-17 立案；1 declaration check 守卫 MR-17 文本存在；1 **runtime python_assert** subprocess 跑 `test_convergence.py` 49 单测端到端覆盖（OPENCLAW_REPO_ROOT env 兼容多环境 + 60s timeout）。⑥ **49 新单测** `test_convergence.py` 14 类：TestConvergenceResult(3 namedtuple 字段顺序+immutable+empty_result 默认) + TestLoadSpecs(3 含 missing file raises) + TestSpecLookup(5 含 FAIL-OPEN missing→[]) + TestExtractRegistryEnabledSystemJobs(3 含 enabled+system 双过滤+空 entry 跳过+空 registry 返回 set()) + TestObserveShellCommand(4 含成功/缺 command/exit≠0+empty stdout→"" / exit≠0+stdout→raise) + TestIdentifierParsers(5 含 word_boundary 避免 kb_dream.sh 匹配 kb_dream_helper.sh + 真 cron 行引号场景) + TestVerifyConvergenceHappyPath(1 declared==observed) + **TestVerifyConvergenceDriftDetected(2 含 V37.9.18 血案场景复现 — kb_deep_dive 缺失 / 全空 crontab 全部缺失)** + TestVerifyConvergenceFailOpen(6 含 spec_not_found/extractor_failed/unknown extractor/unknown observer/unknown parser/observer 失败时 missing=declared) + TestVerifyConvergenceDriftActionValidation(2 invalid 回退 alert_only) + TestVerifyConvergenceDisabledSpec(1) + TestFormatResultForLog(3 ok/drift/error 三种格式) + TestRealJobsToCrontabSpec(2 真 spec 加载 + 真 extractor 找到 kb_deep_dive.sh) + TestSourceLevelGuards(9 V37.9.19 标记 / MR-17 引用 / FAIL-OPEN 文档 / drift_actions 常量精确 / dispatch 三表 / yaml meta + 第一个 spec drift_action=alert_only 且 **禁止** machine_sync 字面量 / blood lesson link)。⑦ **MR-8 兑现**：framework 设计为 named-dispatch 模式 — V37.9.20 添加新 spec 类型只需在 convergence_ontology.yaml 加 spec 节点 + 在 convergence.py 三个 dispatch dict 之一注册新函数，不改 framework 代码。第二个 spec `providers_to_adapter` 只需新增 `_observe_http_endpoint` observer 函数 + 一个 yaml spec，零 framework 改动。⑧ **累计**：47→48 suites (+1) / 1493→1542 tests (+49) / 0 fail / governance v3.32→v3.33 / 61→62 invariants (+1 INV-CONVERGENCE-CRON-001) / 297→311 checks (+14) / 16→17 meta rules (+1 MR-17) / 安全 95/100 / VERSION 0.37.9.18 → 0.37.9.19。⑨ **Mac Mini 部署路径**：ontology/ 走 V37.9.12.1 symlink 机制（`$HOME/ontology` → `$HOME/openclaw-model-bridge/ontology`）无需 FILE_MAP — convergence.py + convergence_ontology.yaml 部署即生效。手动验证：`python3 ~/openclaw-model-bridge/ontology/convergence.py --spec jobs_to_crontab`，预期"DRIFT"输出 0 个 missing（如 V37.9.18 已注册 kb_deep_dive cron 后），exit 0。⑩ **下次 (V37.9.20) 候选**：(a) `jobs_to_crontab` 一周观察后升级 drift_action=machine_sync — 需要先实现 cron 行模板（从 jobs_registry 的 interval+entry+log_path 字段生成 `30 22 * * * bash -lc 'bash ~/X.sh >> ~/X.log 2>&1'`）+ 调用 crontab_safe.sh add (b) 第二个 spec `providers_to_adapter`（method=http_endpoint, command="curl localhost:5001/health \| jq .fallback_chain"，需要新增 _observe_http_endpoint observer 函数）(c) governance_checker 集成调 verify_convergence — 让 governance 审计同时跑 convergence 检查 (d) 立场文章 `Why Control Plane = Convergence Engine` 阐述 OPA 只做"声明 → 决策"而 OpenClaw 做"声明 → 运行时事实闭环"的差异化定位。⑪ **元价值**：本案是 ontology 子项目从"治理 81 工具规则 + 61 不变式"升级为**整个 control plane 核心抽象**的关键拐点 — 完成 Phase 4 Layer 5（终极目标 `pip install ontology-engine` 路径上的关键支柱）。下一阶段 ontology 不只是"治理别人的代码"，而是"治理整个声明→运行时融合系统"。|
| V37.9.18 | 2026-04-26 | **kb_deep_dive cron 未注册血案修复（MR-4 silent-failure 第 16 次演出 — 三层 silent 协同掩护简单运维遗漏 2 天）** — ① **触发**：用户察觉"昨天没收到深度分析"，调查发现 V37.9.16 (2026-04-24) 上线时 jobs_registry.yaml + auto_deploy FILE_MAP + notify.sh 全部正确部署，但**没人手动 `crontab_safe.sh add`**，4/24 + 4/25 两次预期 22:30 触发完全静默 → 用户 4/26 上午察觉浮现。② **三层 silent 协同**：(a) **触发器**：V37.9.16 收工运维步骤遗漏（`jobs_registry.yaml` 是声明，不会自动同步到 crontab）(b) **放大器 1**：`preflight_check.sh:63` 只 grep `间隔漂移`，吞掉 `check_registry.py:188` 输出的 `registry 已启用但 crontab 中未找到` warning，让 V37.9.17 收工 preflight `--full` 假绿通过 (c) **放大器 2**：`crontab_safe.sh:cmd_add` 不检查 `crontab "$tmp_file"` 退出码 + count 用 `<` 比较，导致用户首次试 `add '<占位符>'` 时 crontab 拒绝（"bad minute"）但 35→35 仍打 ✅ "已添加"谎报。③ **三层修复**：(Fix 1) preflight 加第二个 grep 模式 + `DRIFT_FAILED` 标志统一两类 warning 都触发 fail (Fix 2) crontab_safe 改为 `if ! crontab "$tmp_file"` 检查退出码 + count 用 `-ne $((count_before+1))` 严格相等 + 失败路径 exit 1 + 错误信息含 "crontab 安装失败" (Fix 3) Mac Mini 用户已注册 `30 22 * * * bash -lc 'bash ~/kb_deep_dive.sh >> ~/kb_deep_dive.log 2>&1'` + 立即手动跑产出 `2026-04-26.md`（"潜在去噪增强大模型视觉对齐"）补今日推送。④ **15 新单测** `test_v37_9_18_cron_strict_checks.py`：TestPreflightDualWarningCheck(6 源码守卫两个 grep 模式 + DRIFT_FAILED + V37.9.18 注释 + 旧"零漂移"措辞被消除) + TestCrontabSafeStrictExitCheck(6 源码守卫 `if ! crontab` + `-ne` 严格相等 + `expected=count_before+1` + 失败路径 exit 1 + 错误信息) + TestCrontabSafeRejectedInputBehavior(3 行为层 fake-crontab shim 真 subprocess: 拒绝输入必须 exit 非 0 + 不打 ✅ + 打印失败原因)。加入 full_regression。⑤ **累计**：46→47 suites (+1) / 1478→1493 tests (+15) / 0 fail / governance 61/61 invariants 不变（INV-CRON-005/006 + MR-17 元规则候选登记 V37.9.19 一并立案，按原则 #28 最小修复本次只在测试层覆盖）/ 安全 95/100 / VERSION 0.37.9.17 → 0.37.9.18。⑥ **MR-4 silent-failure 第 16 次演出新形态**：前 15 次都是单点 silent，第 16 次是**三层独立 silent bug 协同掩护一个简单运维遗漏**——每一层单独都能拦住，但三层都因各自 bug 同时失效。⑦ **MR-17 元规则候选立案** `declared-state-must-converge-to-runtime-via-machine-not-memory`：来自反思——已有 1478 单测 + 309 governance check + 81 preflight 项，但全部在仓库内层运作，"声明态(yaml/registry) → 运行时态(crontab/process)"同步**靠人记忆**就是结构盲区。**真正修复方向**(V37.9.19 候选)：`auto_deploy.sh` 轮询时对比 `jobs_registry enabled` vs Mac Mini `crontab -l`，缺失即自动 `crontab_safe.sh add`，让"crontab add"从人步骤升级为机器步骤。⑧ **元教训**：复杂工程系统不是被复杂问题打败，是被简单遗漏打败。1478 单测防复杂逻辑漏洞，"crontab add 一行"靠 Claude Code 记忆——记忆是最弱可靠性机制。SOUL.md/CLAUDE.md 是**建议**（靠下次 session 读到），governance/preflight 是**约束**（机器强制）。本案教训：**关键运维流程必须从建议升级为约束**。⑨ **案例文档** `ontology/docs/cases/kb_deep_dive_cron_unregistered_case.md`（完整四维度因果链架构图 + 三层根因 + 时间线 + 5 条件组合 + MR-4 演出史更新到第 16 次 + INV-CRON-005/006 + MR-17 候选立案）。|
| V37.9.17 | 2026-04-24 | **kb_deep_dive picker tier-aware fallback（方案 C）— V37.9.16 首跑用户感知问题闭环** — ① **触发**：V37.9.16 Mac Mini 首跑 22:30 之前手动触发，picker 选中 `ai_leaders_x` Palantir tweet ⭐⭐⭐⭐⭐"国家AI动员与地缘安全"，但 ai_leaders_x 在 TIER 3 必然走 abstract_only 路径 → LLM 输出 800 字摘要分析（非预期的 1200 字论证链拆解）。score 公式 tier-blind：X tweet ⭐5+Palantir 加权 ≈ 65 分胜过 arxiv ⭐4+ontology 加权 ≈ 60 分。用户视角原则 #13 兑现 — dev 单测全绿但生产质量低于预期。用户决策 **方案 C**：TIER 1/2 优先，TIER 3 fallback。② **最小修复**（原则 #28 三问通过 — 设计选择不是 bug，仅改 `pick_top` 函数）：`kb_deep_dive.py::pick_top()` 从 `return candidates[0]` 改为先按 `classify_tier(c["source_id"]) in (1, 2)` 过滤 → 有 TIER 1/2 候选则 return tier_12[0] / 否则回退 candidates[0]。每个桶内仍按 V37.9.16 score 排序（star + topic + length tie-breaker 公式不变）。③ **行为契约**：(a) 当今日有 ⭐≥4 的 arxiv/hf/acl/pwc/s2/dblp/rss_blogs/ontology_sources/github_trending 候选时，绝不会被 X tweet/HN 帖子挤掉 (b) 当今日纯无论文/博客（周末/节假日 source 静默期）才回退 X tweet 摘要分析 — 保留 V37.9.16 "今日推送不空缺"承诺 (c) `score_entry` 不动 — TIER bonus 不混入分数避免双重影响（先 score 再 filter 比 score+bonus 更可解释）。④ **6 新单测** `TestPickTopTierFallback`：empty 返回 None / **`test_v37_9_16_blood_lesson_scenario`** 直接复现首跑场景断言"X tweet ⭐5 + arxiv ⭐4 + hf ⭐4 → 必选 arxiv 或 hf 不选 X" / tier1 胜 tier3 / tier2 胜 tier3 / tier1+2 同桶按 score 排序（不区分 1 vs 2，因为有些场景 tier2 博客比 tier1 半篇 paper 更有内容）/ 仅 TIER 3 候选时正常 fallback 保证不空缺。⑤ **累计**: 61 tests (+6) / VERSION 0.37.9.16 → 0.37.9.17 / **核心逻辑改动 5 行**（pick_top 函数体）+ **35 行新单测** + 文档同步。governance 不变（INV-DEEP-001 仍按 V37.9.16 计划 shadow 一周后再加，本次修复属于 picker 内部调优，可观测行为符合方案 C 后再考虑加守卫不变式）。⑥ **下次观察**：22:30 cron 自动触发 + 等本周内多日 run 看 mode 分布 — 期望 TIER 1/2 比例显著上升 (V37.9.16 抽样 1 次 100% TIER 3，方案 C 后预期 80%+ TIER 1/2)。如观察到反常（连续多日 no_candidates 因 TIER 1/2 stars 都 <4）→ V37.9.18 候选放宽 MIN_STARS 或扩展候选窗口到 2 天。⑦ **MR-7 再次正向兑现**（用户视角发现 → 24h 内闭环）：V37.9.16 部署后 1 小时内用户首跑发现质量问题 → 立即提出选项 → 用户决策方案 C → 写代码 + 单测 + 文档 + 推送 < 30 分钟，符合"用户视角观察 → 立即修复"的健康闭环节奏。⑧ **元教训**：V37.9.16 方案设计时确定的 picker 算法字面上正确（star + topic + tie-breaker），但**忽略了"score 高未必抓得到全文"的隐含交互**。tier-blind 在论文/X tweet 混合场景下产生意外行为。这是原则 #15 测试三层"WhatsApp 业务验证"的典型作用 — 单测覆盖 picker 行为正确，但只有真实生产数据才暴露 score 高的候选被 fetch 限制吃掉的语义鸿沟。|
| V37.9.16 | 2026-04-24 | **每日深度分析（kb_deep_dive）全新上线 — 从"周度覆盖"升级为"每日纵深"** — ① **触发**：V37.9.15 收工时确认 Phase 4 P3 shadow wiring 已完整提交进入一周观察期，status.json unfinished 登记"kb_deep_dive 每日深度分析功能 — 方案已全部和用户确认，直接进入写代码状态"。用户决策 12 项全部 OK（时间 22:30 HKT / 推送 Option A 双通道齐发 / pdfplumber+bs4 依赖 / 一档+二档抓取+三档 degrade / fail→degrade 不 block）。② **新增文件三件**：(1) `kb_deep_dive.py` (~700 行纯 Python) — `import kb_review_collect as rc` 复用 load_sources_from_registry + extract_recent_sections + call_llm；`TIER_1_SOURCES={arxiv_monitor/hf_papers/acl_anthology/pwc/semantic_scholar/dblp}` / `TIER_2_SOURCES={rss_blogs/ontology_sources/github_trending}` / 其余三档；`parse_entries_from_section` 按 `*title*` 块边界 + 链接/星级/摘要行识别（state machine，V37.8.7 ontology_parser 同款模式）；`score_entry` 星级×10 + TOPIC_WEIGHTS 主题加权（ontology/本体/knowledge graph/agent runtime/llm infra/control plane 各 +10 分等）+ 摘要长度 tie-breaker（封顶 +10）；`fetch_pdf_text` arxiv/acl URL 派生 PDF URL + pdfplumber lazy import + `_urlopen` 加 UA header 突破 403 + `preprocess_pdf_text` 切 References/Acknowledgments/参考文献/致谢（中英文）+ Figure/Table caption 正则去噪 + 30K 截断；`fetch_html_text` bs4 lazy import + charset 探测 + article/main 标签优先 + 清 script/style/nav/footer/header/aside；`fetch_full_text` 分档 dispatch + 任何失败都 degrade 到 abstract_only 不 raise；`build_full_text_prompt`（论证链+实验对比+局限性+对本项目启发五结构）vs `build_abstract_only_prompt`（禁推测方法细节+明确"基于摘要的分析"标注），两者共享 GROUNDING_CONSTRAINT（违反即作废）；`run()` orchestrator 返回 status: ok/no_candidates/llm_failed/collector_failed，llm_failed 路径**不产出** markdown/wa_message/discord_message 成功-only 字段（MR-8 "silent-failure-is-a-bug" 契约）。(2) `kb_deep_dive.sh` (~150 行 thin wrapper) — 镜像 kb_review.sh V37.5.1 env-var heredoc 模式（禁 `echo \| python3 -` pipe+heredoc 冲突，V37.5.1 血案防御）；set -euo pipefail + notify.sh source + double-push（WhatsApp 简版 + Discord 完整版，**内容不同**）通过 `--channel whatsapp --topic deep_dive` + `--channel discord --topic deep_dive` 两次独立调用；no_candidates 推 [SYSTEM_ALERT] 但 exit 0（明日再试契约）+ llm_failed/collector_failed 推告警并 exit 1（fail-fast）；`last_run_deep_dive.json` status 写入 + rsync 备份带 V37.9.14 `movespeed_incident_capture.sh` 事故取证钩子。(3) `test_kb_deep_dive.py` (55 单测 / 10 类) — TestClassifyTier(7) + TestParseEntriesFromSection(6 含 multiple_entries/empty/no_stars/fallback_url/abstract_accumulates) + TestScoreEntry(6 含 low_stars_negative / 多主题加权叠加 / tie_breaker 封顶) + TestPdfUrlDerivation(5 含 arxiv abs→pdf 变体 + acl URL) + TestPreprocessPdfText(5 含切英文+中文 References/截断/Figure caption) + TestFetchDegrade(3 含 tier3/无 link/HTTP 失败 degrade 契约，真 monkey-patch `_urlopen` 抛 URLError) + TestPromptBuilders(4 含 grounding 约束守卫) + TestOutputBuilders(5 含 WA 长度<=1450 + Discord markdown + abstract_mode 推送标记) + TestRunOrchestrator(5 端到端：no_candidates 不产 artifacts / ok full_text 产全套 / llm_failed 不产 markdown-wa-discord / degrade abstract_only mode + degrade_reason 透传 / collector_failed on missing registry) + TestKbDeepDiveShellGuards(9 源码级：脚本存在 / [SYSTEM_ALERT] 前缀 / 禁 `\| python3 -` 反模式 / source notify.sh / set -euo pipefail / last_run_deep_dive.json / --topic deep_dive / rsync+movespeed_incident_capture / llm_failed 分支 500 字符内 exit 1 顺序锁)。③ **配置面三处改动**：(a) `jobs_registry.yaml` 新 job `kb_deep_dive`（scheduler=system / interval="30 22 * * *" HKT / tier=auxiliary / needs_api_key=true），check_registry 通过 40 jobs validated。(b) `auto_deploy.sh` FILE_MAP 双文件补齐 `kb_deep_dive.sh|$HOME/kb_deep_dive.sh` + `kb_deep_dive.py|$HOME/kb_deep_dive.py`（置于 kb_review/kb_evening 行相邻位置，保持群组一致）。(c) `notify.sh` `_notify_discord_target_for_topic()` 加入 `deep_dive) echo "${DISCORD_CH_DAILY:-}" ;;`（V37.9.16 复用 #daily 频道，语义独立便于未来分离）+ header 注释块登记新 topic。(d) `full_regression.sh` 加 `run_suite "kb_deep_dive ..." "python3 test_kb_deep_dive.py"` 置于 kb_evening 之后。④ **时间窗设计**：22:00 kb_evening → 22:30 kb_deep_dive → 00:40 Dream Map，三者零撞车；22:30 选择理由：数据最完整（全天 32 jobs 已跑）+ LLM 相对空闲（凌晨前窗口）+ 不撞 Phase 4 P3 quiet-hours-00-07 policy + 不与 22:00 kb_evening 并发争 LLM。⑤ **失败策略四种 status 分流**：(a) **no_candidates** — 无 ⭐≥4 候选（今日论文不够好）→ 推 [SYSTEM_ALERT] 提示但 exit 0，明日自动再试 (b) **PDF/HTML 抓取失败** — degrade 到 abstract_only + `build_abstract_only_prompt` 明示禁推测 + 推送内容前缀"（摘要级分析）"用户可见 + **不 block 不单独告警** (c) **LLM 失败** — [SYSTEM_ALERT] + exit 1 fail-fast（V37.5 血案防御）(d) **collector_failed** — 部署/注册表缺失 → 同 LLM 失败路径。⑥ **设计亮点**：(a) **依赖 lazy import** 让 dev 环境可跑单测（pdfplumber 和 bs4 不必装），Mac Mini 需 `pip3 install pdfplumber beautifulsoup4`。(b) **MR-8 兑现** — `import kb_review_collect as rc` 复用 5 个原语零 copy-paste，与 V37.6 kb_evening_collect.py 同款"单一真理源"模式。(c) **双通道内容差异**：WhatsApp 简版 1400 字（手机阅读优先）vs Discord 完整版 1900 字（Discord 频道归档优先），通过两次独立 notify 调用。(d) **V37.5.1 env-var heredoc 血案防御**：测试有 source 级守卫 `test_script_uses_env_var_heredoc_pattern` grep 禁止 `\| python3 -` 反模式。⑦ **累计**: 45→46 suites (+1) / 1411→1466 tests (+55) / 0 fail / governance v3.32 不变（本次无新不变式，V37.9.16 首批上线后 shadow 观察一周再考虑加 INV-DEEP-001，与 V37.9.15 three_gate 同款渐进路径）/ 安全 95/100 / VERSION 0.37.9.15 → 0.37.9.16。⑧ **Mac Mini 部署路径**：auto_deploy 2min 轮询同步 kb_deep_dive.{sh,py}，22:30 首次触发产出 `~/.kb/deep_dives/2026-04-24.md` + WhatsApp + Discord #daily 推送。首次运行预期：22:30:00 读 sources → picker 选出 ⭐≥4 候选 → 如属 arxiv/hf/acl/pwc 尝试 PDF 抓取（若 pdfplumber 未装 degrade 到 abstract）→ LLM 分析 → 3 通道产出。⑨ **下次 (V37.9.17) 候选**：(a) Mac Mini `pip3 install pdfplumber beautifulsoup4` 安装观察首批 PDF 抓取成功率（dev 环境 fetch 路径单测覆盖完整但生产 URL 多样性未验证）(b) INV-DEEP-001 `daily-deep-dive-fails-loud-not-silent`（shadow 观察一周后加 meta_rule=MR-8/MR-9 的治理不变式，同 INV-EVENING-001 / INV-REVIEW-001 模式）(c) picker 调优：观察一周选出的 topic 分布，调整 TOPIC_WEIGHTS (d) 如 no_candidates 告警过频 → 放宽 MIN_STARS=4 至 3 或扩展候选池到最近 2 天 (e) Phase 4 P3 shadow→on 推进（V37.9.15 延续观察）。|
| V37.9.15 | 2026-04-24 | **Phase 4 P3 三阶段门控 shadow wiring — policy 引擎从"可查询"升级为"在请求路径上被调用并产可观测 log"** — ① **触发**：V37.9.12 Phase 4 P1 (`evaluate_policy()` 三纯函数 + max-tools-per-agent 首切换) + V37.9.13 Phase 4 P2 (6 个 context evaluator + max-tool-calls-per-task 第二切换) 只在启动期解析 static policy 阈值缓存到模块常量；contextual/temporal policy 的 6 个 evaluator 已注册但**生产环境零调用**—只被单测覆盖。下次 session focus 明确登记 "[首选] Phase 4 P3 三阶段门控"。② **新文件 `ontology/three_gate.py`**（~280 行，零 I/O 零状态纯函数模块）：`GateFinding` namedtuple (gate/policy_id/verdict/action/reason/enforced) + 3 个 gate 函数 `pre_check/runtime_gate/post_verify` + `_collect_findings()` 共享 helper 遍历 policy_pairs → `_safe_evaluate_policy()` 捕获 engine 异常 → 提取 static policy signal 与 limit 比对（`_STATIC_SIGNAL_KEYS` 映射 tool_count/tool_call_count/body_bytes 三指标）→ 产出 pass/flag verdict。`ONTOLOGY_GATES_MODE` env 三档 off/shadow/on（默认 `shadow`，未知值 fall back shadow 观察优先），`_VALID_GATE_MODES = ("off", "shadow", "on")` 常量。与 `ONTOLOGY_MODE` 解耦（允许 ONTOLOGY_MODE=on 但 gates=off 的灰度组合）。`format_findings_for_log()` 产 `[gate:pre_check] N findings: policy_id=verdict(reason) ...` 单行便于 `grep [gate:]` 运维排查。**FAIL-OPEN 契约**：engine 异常经 `_safe_evaluate_policy` 吃掉返回 None → gate 降级 verdict=pass + reason="engine_unavailable"，绝不冒泡到 tool_proxy。③ **三 gate policy 分配**：pre_check→{alert-context-isolation, quiet-hours-00-07} / runtime_gate→{max-tools-per-agent, max-tool-calls-per-task, max-request-body-size} / post_verify→{alert-context-isolation (扫响应检测 [SYSTEM_ALERT] echo)}。④ **`tool_proxy.py` wiring**（最小入侵，两处调用点）：(a) `importlib.util.spec_from_file_location` lazy-load three_gate（ontology/ 缺失时 log WARN 不崩 + _three_gate = None 哨兵）(b) `_run_gate(gate_fn_name, context, rid, response=None)` 帮助函数：None 哨兵检查 + getattr(fn) + try/except Exception + log `[{rid}] {findings_line}` / `WARN: gate X raised` (c) do_POST 第一处：`raw = json.dumps(body).encode()` 后构造 context {messages, tool_count=len(body.tools), body_bytes=len(raw), hour=datetime.now().hour} 调 `_run_gate("pre_check", ...)` + `_run_gate("runtime_gate", ...)` (d) do_POST 第二处：`rj = json.loads(resp_body)` 后 `_run_gate("post_verify", {"messages": body.messages}, rid, response=rj)` 必须在 fix_tool_args 之前（V37.9.15 顺序锁，观察 LLM 原始响应未被 alias 修复改写）。⑤ **`policy_ontology.yaml::meta` 升级**：version 0.2-p2-partial → 0.3-p3-partial，status → gates_wired_shadow_mode，新增 `policies_observed_by_three_gate` 分 gate 清单 + `gates_feature_flag` 声明（`values: ["off", "shadow", "on"]` 引号避 YAML 1.1 bool 陷阱 + decoupled_from ONTOLOGY_MODE）+ `next_step` 指向 P3.1 (shadow→on 一周观察) / P3.2 (第三条 policy 切换) / P4 (真正 enforcement 路径)。⑥ **`INV-GATE-001 three-gate-wiring-observability`**（meta_rule=MR-7, severity=high, verification_layer=[declaration, runtime], **14 checks**）：7 declaration 守卫 three_gate.py（Phase 4 P3 头注释 / `def pre_check(context)` / `def runtime_gate(context)` / `def post_verify(context, response=None)` / `_DEFAULT_GATE_MODE = "shadow"` / `_VALID_GATE_MODES = ("off", "shadow", "on")` / `def _safe_evaluate_policy`）+ 5 declaration 守卫 tool_proxy.py（`spec_from_file_location("_three_gate"` / `def _run_gate(` / `_run_gate("pre_check"` / `_run_gate("runtime_gate"` / `response=rj`）+ 1 declaration 守卫 policy_ontology.yaml P3 meta + **1 runtime python_assert** subprocess 跑 `unittest ontology.tests.test_three_gate test_tool_proxy.TestThreeGateWiring` 覆盖 66 场景端到端。⑦ **66 新单测**：`ontology/tests/test_three_gate.py` 57 tests (TestGatesMode×7 含默认 shadow + case-insensitive + whitespace + 未知 fall back shadow + TestGateFinding×3 含 immutable + 字段顺序稳定 + TestOffModeShortCircuit×4 含 off 不调 engine + TestShadowModeNeverEnforces×2 反证 on 模式 enforced=True + TestPreCheck×8 含 alert 检测 + quiet-hours 上下文全分支 + missing hour→verdict pass + None context tolerant + TestRuntimeGate×6 含 signal≤limit boundary 合规 / signal>limit flag / 缺信号 tolerant + TestPostVerify×5 含 assistant [SYSTEM_ALERT] 回声检测 + malformed response tolerant + TestFailOpen×4 真 monkey-patch engine.evaluate_policy 抛异常 + TestExtractSignal×7 含 bool 排除于 int + TestExtractAssistantText×6 + TestFormatFindingsForLog×3 + TestModuleIntegration×2 公开 API + gate name 稳定性) + `test_tool_proxy.TestThreeGateWiring` 9 tests（lazy-load importlib.util 模式 / `_run_gate` 定义 + fail-open / 三处调用点 + context 字段 / post_verify 顺序锁 source 级位置比较 / Phase 4 P3 日志标记 / 默认 shadow / shadow 不 enforce）。**全量回归 45 suites / 1411 tests (+66) / 0 fail**。⑧ **MR-8 正面兑现**：`_collect_findings` 共享 helper 让三 gate 复用同一遍历逻辑，policy 列表通过 `_PRE_CHECK_POLICIES / _RUNTIME_GATE_POLICIES / _POST_VERIFY_POLICIES` 数据驱动 — 不 copy-paste 三份遍历循环 (对比 V37.9.12/13 的 `_resolve_max_tools_limit` 与 `_resolve_max_tool_calls_per_task_limit` 故意写两份是因为需要独立 policy-specific 启动日志，这里复用是因为三 gate 行为对称)。⑨ **MR-7 兑现**：policy 引擎从"可查询但不在请求路径"升级为"被请求路径调用并产 `[gate:*]` 可观测 log"。每请求 stdout 将出现形如 `[proxy] ... [rid] [gate:pre_check] 2 findings: alert-context-isolation=pass(applicable=False) quiet-hours-00-07=pass(context_missing_hour)` 的 runtime 观察数据。⑩ **累计**: 44→45 suites (+1) / 1345→1411 tests (+66) / 0 fail / governance v3.31→v3.32 / 60→61 invariants (+1 INV-GATE-001) / 273→297 checks (+14 INV-GATE-001 + 10 audit_metadata 漂移回填) / 15→16 meta rules (MR-16 计入) / 安全 95/100 / VERSION 0.37.9.14 → 0.37.9.15。⑪ **Mac Mini 部署路径**：`ontology/three_gate.py` 走 V37.9.12.1 发现的 symlink 机制（`$HOME/ontology` → `$HOME/openclaw-model-bridge/ontology`）无需 FILE_MAP。`tool_proxy.py` 在 FILE_MAP 里下次 auto_deploy 2min 轮询自动同步。同步后 proxy 启动日志将出现 `[proxy] three_gate loaded (mode=shadow) (Phase 4 P3 shadow wiring active)`，每次 `/v1/chat/completions` 请求末尾出现三行 `[gate:*]` findings 供 Mac Mini 运维层 `grep [gate:]` 观察一周。⑫ **下次 (V37.9.16) 候选**：(a) shadow → on 推进（基于一周生产观察），需要 enforcement 行为定义（flag verdict 时 proxy 做什么 — reject request / truncate further / 只 alert 不阻塞？） (b) 第三条 policy 切换 max-request-body-size 或 alert-context-isolation 从 proxy_filters.filter_system_alerts 等现有 enforcement 点**查询**而非**硬编码** (c) Phase 4 P4 四耦合点（Pre→Runtime→Post 加入 audit_log 带 policy_evaluated + rule_chain）。|
| V37.9.14 | 2026-04-23 | **MOVESPEED SSD rsync 失败取证埋点（证据导向修复，不盲猜根因）** — ① **触发**：V37.9.4 APFS 重建理论上闭环 exfat fskit EPERM，但 2026-04-22 ACL cron 日志再次出现 `Operation not permitted`，顶层 `/Volumes/MOVESPEED/KB/` 权限 OK 但 rsync 子操作失败 — V37.9.4 假说被证伪，但根因不明（可能 cron FDA / APFS mount option / USB 节能 / Time Machine 并发等多种假设）。② **方法论选择**：按原则 #28 理解再动手 + 原则 #26 异常分析宪法，在证据不足时**拒绝盲目修复**。transient EPERM 一旦自愈就抓不到现场（V37.9.4 的 4/21 11:40 手动 rsync 立即成功即是证据），所以选"埋取证点"而非"猜根因修"。③ **新 helper `movespeed_incident_capture.sh`**（bash 3.2 兼容 macOS 默认，never-fail 契约，~130 行）：rsync 失败时追加一行 JSONL 到 `~/.kb/movespeed_incidents.jsonl`，字段含 timestamp / caller basename / exit_code / `mount` 输出 / `diskutil info` 摘要 / `ls -la` 顶层和 KB 子目录 / `df -h` / **顶层和 KB 子目录独立 touch 权限探测**（区分"全盘 EPERM"vs"部分子目录 EPERM"—— V37.9.4 血案之后真正需要的那块证据）/ `rsync/backupd/mds/fseventsd/tmutil/Spotlight` 进程快照（并发竞争诊断）/ `sw_vers` + env 摘要。Python3 argv 参数传递避开 shell 转义坑，所有诊断命令 `2>/dev/null` + 缺失字段为空串，`mktemp -d` 失败走 last-ditch minimal record 分支。10MB 自动 rotation 到 `.1`。④ **20 处 rsync fail-loud 站点批量升级**（18 文件 20 处，freight 2 处）：旧 `rsync ... 2>&1 \|\| echo "WARN: SSD ... (exit=$?)" >&2` → 新 `rsync ... 2>&1 \|\| { _rc=$?; echo "WARN: SSD ... (exit=$_rc)" >&2; "$HOME/movespeed_incident_capture.sh" "$_rc" "$0"; }`。关键 `_rc=$?` 必须在 echo 之前捕获（echo 执行后 $? 变成 0）。脚本 `set -e` 安全（helper 契约 never-fail exit 0）。覆盖 kb_save_arxiv/kb_dream/kb_evening/kb_inject/kb_review/run_hn_fixed + jobs/{hf_papers,semantic_scholar,dblp,ontology_sources,karpathy_x,rss_blogs,arxiv_monitor,freight_watcher×2,acl_anthology,github_trending,ai_leaders_x,openclaw_official×2}。⑤ **INV-BACKUP-001 扩展 check 4 + check 5**（meta_rule 从 MR-4 继承，添加 MR-9 正面兑现维度）：(a) declaration python_assert 全局扫 rsync+MOVESPEED 的 .sh 必须调用 `movespeed_incident_capture.sh`（helper 自身无 rsync 自动豁免，避开 V37.3 exec scope trap 用 iterative loop） (b) runtime python_assert 端到端 subprocess 跑 mock caller → rsync 失败 → 断言 caller exit 0 + WARN 在 stderr + JSONL 行写入 + JSON 解析成功 + caller basename 正确。⑥ **MR-9 正面兑现扩展**：V37.9.13 把 MR-9 应用到进程管理层（launchctl 单一 manager），V37.9.14 把 MR-9 应用到取证层（事故现场捕获必须走单一 helper，20 处不再各自 inline 自己的取证逻辑）—— 从 MR-8 copy-paste-is-a-bug-class 反例升级为 MR-9 正面兑现。⑦ **26 新单测** `test_movespeed_incident_capture.py` 加入 full_regression：TestHelperExists(4) + TestHelperContract(8: 无 args 不崩 / shell metachar 不执行 / tmpdir 坏不挂 / JSONL 有效 / append 语义 / basename 抽取 / ISO8601 UTC) + TestRotation(2: MAX_SIZE 触发 + 小文件不触发) + TestBashCompat(6: 禁 ${var@Q} / ${^^} / declare -A / mapfile + WARN: SSD 字样合规 + 反模式不自伤，注释行智能豁免) + TestInvariantCoverage(4: 20 个预期站点存在 + 都调用 helper + helper 在 fail-loud 分支内 + 无未声明新增站点) + TestFileMapCoverage(1: auto_deploy FILE_MAP 含 helper) + TestGovernanceExtension(1: governance_ontology.yaml 引用 helper)。⑧ **auto_deploy.sh FILE_MAP 补齐**：`movespeed_incident_capture.sh | $HOME/movespeed_incident_capture.sh`。注意 comment wording 避免"rsync"+"MOVESPEED"co-occur 误触 INV-BACKUP-001 discovery scan。⑨ **accumulated**: 43 → **44 suites (+1)** / 1319 → **1345 tests (+26)** / 0 fail / governance 60 invariants（不变，INV-BACKUP-001 扩展 2 checks）/ 安全 95/100 / VERSION 0.37.9.13 → 0.37.9.14。⑩ **下次 transient EPERM 复发**（可能 1 天也可能数周）：`cat ~/.kb/movespeed_incidents.jsonl` 将给出完整现场数据 — 顶层 probe exit 码 vs KB probe exit 码的差异即可立即判定是"全盘 EPERM"还是"子目录特定 EPERM"，`procs` 字段显示并发 Time Machine/Spotlight 证据，`mount` 输出显示当时是否 readonly remount，`df` 显示是否空间耗尽。有这份数据后，V37.9.15 可以精确修根因而非继续猜。⑪ **原则 #28 正向兑现**：本次修复严格遵守"修复前必答三问"——(1) 这问题之前存在吗？V37.9.4 已修过部分，4/22 复发证明假说不完整（回答：是，但 V37.9.4 的修复不完整） (2) 我的哪个改动引入的？不是我的改动，是底层环境 transient 问题（回答：非代码引入） (3) 最小修复是什么？埋取证点而非盲修（回答：收证据层，不改行为层）。禁止了"看到报错就改代码"的反模式。⑫ **备份监控延伸**：该 JSONL 未来可被 `job_watchdog.sh` 或 `kb_status_refresh.sh` 消费 — 如累积 ≥ 5 条 incident 在 24h 内即触发连续性告警（登记为 V37.9.15 候选）。|
| V37.9.13+arch-cleanup | 2026-04-23 | **restart.sh 架构清理 — 单一 manager 契约（消除 nohup + launchd 双管理血案）** — ① **触发**：V37.9.12.1 Mac Mini 实测发现 `com.openclaw.adapter.plist` + `com.openclaw.proxy.plist` KeepAlive 管理的 launchd 进程，与 `restart.sh nohup python3 adapter.py/tool_proxy.py` 启动的 manual 进程同时抢占 :5001 / :5002 端口，launchd 侧持续显示 crash-loop（两路进程 ExitCode ≠ 0 反复重启）。status.json unfinished 登记 "V37.9.13 候选 (架构清理): restart.sh 改用 launchctl kickstart 替代 nohup python 启动 adapter/proxy"。② **修复方案**：restart.sh 新增 `restart_via_launchd <label> <port> <plist> <display>` helper 函数（返回 0=成功 / 1=launchd 失败 / 2=launchctl 或 plist 不可用，signal to caller to fallback），主路径用 `launchctl kickstart -k gui/$(id -u)/<label>` 触发 launchd 内部重启（modern idempotent API），首次加载时 `bootout + bootstrap` 兜底。③ **健康验证扩展**：V37.8.13 Gateway 的 5×3s 健康验证循环从 Gateway-only 扩展到 adapter/proxy — helper 内置 `for _attempt in 1 2 3 4 5; sleep 2; curl http://localhost:$port/health` 循环，HTTP 200 判定健康。Gateway 的验证逻辑完整保留（`V37.8.13 Post-bootstrap health verification` 注释 + `GATEWAY_HEALTHY=false` + 5×3s curl 循环 + 失败不 exit 1）。④ **向后兼容 fallback**：plist 缺失（dev 环境 / 未装 plist / 恢复场景）时 helper 返回 2，调用方用 `_ad_rc=$?` / `_px_rc=$?` 捕获并走 `nohup python3 adapter.py` 原路径；set -e 下用 `|| _ad_rc=$?` 安全捕获避免脚本整个退出。⑤ **#48703 hotfix 段完整保留**：V37.9.13 重构与该段无关，不得误删 `const listeners = /* @__PURE__ */ new Map()` 的 sed 补丁逻辑。⑥ **INV-RESTART-001 新增**（meta_rule=MR-9 state-writes-go-through-helper，severity=high，verification_layer=[declaration, runtime]）8 checks：restart_via_launchd helper 定义 + kickstart -k 源码模式 + adapter/proxy 调用参数精确匹配（`"com.openclaw.adapter" 5001` / `"com.openclaw.proxy" 5002`）+ V37.9.13 注释存在 + **2 个 runtime python_assert**：regex 扫所有 `nohup python3 ...adapter.py` / `...tool_proxy.py` 出现位置，前 300 字符内必须含 `plist not found` 或 `_ad_rc`/`_px_rc` 字样（证明在 fallback 分支内，V37.9.12.1 双管理血案的源码级防线）+ **set -e 安全模式守卫** `restart_via_launchd "com.openclaw.adapter" \|\| _ad_rc=$?` 必须用 `\|\|` 捕获返回码。⑦ **20 新单测** `test_restart_launchd.py`：TestRestartVialaunchdHelper(6 测试 kickstart -k / bootstrap fallback / 健康验证循环 / return 2 契约 / launchctl 可用性检测) + TestAdapterViaLaunchd(3) + TestProxyViaLaunchd(2) + TestSingleManagerInvariant(5 测试 nohup adapter/proxy 必在 fallback 分支 + V37.9.13 注释 + V37.8.13 Gateway 逻辑保留 + #48703 hotfix 保留) + TestShellExecutability(3 bash -n + set -euo pipefail + `\|\|` 模式) + **TestRuntimeHelperBehavior(1)** 实际 subprocess 跑 helper，用 awk 提取函数体 eval 后调用空 plist 场景，断言返回 2 不崩溃（用环境变量 `RESTART_SH` 注入路径避免 Python `.format()` 与 awk `/^}/` 花括号冲突）。⑧ **full_regression.sh 接入** `restart_launchd` suite。⑨ **accumulated**: 42 → **43 suites (+1)** / 1299 → **1319 tests (+20)** / 0 fail / governance 59→60 invariants / 安全 95/100 / VERSION 保持 0.37.9.13（同日累积改动）。⑩ **MR-9 正面兑现**：本次清理是 MR-9 state-writes-go-through-helper 的扩展 — 原 MR-9 针对 KB sources 写入（14 个 cron 走 `kb_append_source.sh` 不直 `>>` 重定向），V37.9.13 把"单一 manager"原则应用到进程管理层 — 进程启停必须走 launchd 唯一管理通道，不允许脚本同时用两种机制管理同一服务。⑪ **下次 Mac Mini 验证**：用户合并本 PR 后在 Mac Mini 同步 + `bash ~/restart.sh`，应看到 `[restart] Adapter: launchctl kickstart -k gui/501/com.openclaw.adapter` 日志 + `[restart] Adapter healthy (HTTP 200 after Nx2s)`；`launchctl list \| grep openclaw` 应显示 com.openclaw.adapter / proxy 的 PID 稳定不再 crash-loop。|
| V37.9.13 | 2026-04-23 | **Phase 4 P2 context evaluator + 第二条 policy 切换（max-tool-calls-per-task）** — ① **触发**：V37.9.12 Phase 4 P1 完成后 status.json 焦点明确登记两项 P2 任务 (context evaluator + 第二条 policy 切换)，验证 V37.9.12 wiring 模式可扩展而非一次性 hack。② **engine.py 扩展**：新增 6 个 context 匹配器纯函数 — `_eval_quiet_hours`（temporal：`context.hour ∈ [0,7)` 或 `context.now.hour`，含 int 类型转换 / 范围 [0,23] 校验 / 半开区间 7 点严格判否）/ `_eval_task_match`（temporal：`task==expected`）/ `_eval_has_alert`（contextual：messages 中任一 content 含 `[SYSTEM_ALERT]`，支持 str content 和 OpenAI content blocks 双格式）/ `_eval_has_image`（contextual：优先 `has_image` flag，否则扫 messages 里的 `image_url`/`image` 类型 block）/ `_eval_need_fallback`（contextual：显式 `need_fallback` flag）/ `_eval_data_clean_keywords`（contextual：10 个中英文关键词大小写不敏感）。③ **`_CONTEXT_EVALUATORS` dispatch table** 把 6 条 policy 映射到 matcher：quiet-hours-00-07 / dream-map-budget / alert-context-isolation / multimodal-routing / fallback-chain-capability / data-clean-tool-injection。未注册 policy 走 `reason="no_context_evaluator_registered"`——P2 承诺是"可扩展路径"不是"全部做完"。④ **`evaluate_policy()` 三档扩展**：static 仍 applicable=True；temporal/contextual 分三档 — context=None → `needs_context_evaluator`（向后兼容 P1）/ evaluator 未注册 → `no_context_evaluator_registered` / evaluator 抛异常 → `evaluator_error: <type>` 不冒泡。每个 evaluator 缺字段都有具体 reason（`context_missing_hour` / `context_hour_invalid_type` / `context_messages_must_be_list` 等）便于运维调试。⑤ **第二条 policy wiring**：`config_loader.py` 加 `MAX_TOOL_CALLS_PER_TASK`（读 config.yaml 已声明但从未加载的 `max_tool_calls_per_task: 2`）；`proxy_filters.py` 新增 `_resolve_max_tool_calls_per_task_limit()` 纯镜像 V37.9.12 5 档 safe-fallback 模式（off / load_failed / policy_miss / shadow / on+valid）+ `_MAX_TOOL_CALLS_PER_TASK_RESOLVED` 启动期一次性计算常量。启动日志 `[proxy] max-tool-calls-per-task: using ontology limit=2 (Phase 4 P2 wiring active)` 与 P1 日志配对。⑥ **enforcement 与 wiring 解耦**：当前 Python 尚无 tool_call 计数 enforcement 点（config.yaml 声明但未落实），P2 只做"阈值 wiring"不做"新 enforcement"——有意设计让 wiring 模式先稳定再考虑 enforce 何时何地。⑦ **policy_ontology.yaml::meta 升级**：version 0.1-skeleton → 0.2-p2-partial，status → wired_static_and_registered_contextual，新增 policies_with_context_evaluator 6 条 + policies_wired_via_proxy_filters 2 条清单，next_step 指向 Phase 4 P3 三阶段门控。⑧ **47 新单测**：test_engine_phase4.py +37（TestContextEvaluatorQuietHours×9 含 7 点 boundary + datetime 解析 + 类型/越界 reason / TestContextEvaluatorAlertIsolation×5 含 content blocks 双格式 / TestContextEvaluatorMultimodal×5 / TestContextEvaluatorDreamBudget×3 / TestContextEvaluatorDataCleanKeywords×4 / TestContextEvaluatorFallbackChain×3 / TestContextEvaluatorUnregistered×1 契约"未注册 policy 不崩溃" / TestContextEvaluatorExceptionSafe×1 契约"evaluator 抛异常不冒泡" / TestMaxToolCallsPolicyWiring×6）+ test_tool_proxy.py +9（TestPolicyDrivenMaxToolCallsPerTask 5 档 safe-fallback 各自 monkey-patch + 契约"查询正确 policy_id" + **MR-8 copy-paste 防御源码守卫** `assertNotIn("max-tools-per-agent", src)` 防止 P2 resolver 意外指向 P1 policy）+ test_phase4_ontology_skeleton.py +1（`test_max_tool_calls_per_task_is_2` 横向一致性）。⑨ **accumulated**: 42 suites / 1252 → **1299 tests (+47)** / 0 fail / 安全 95/100 / VERSION 0.37.9.12 → 0.37.9.13。⑩ **MR-8 正面案例兑现**：`_resolve_max_tool_calls_per_task_limit` 与 `_resolve_max_tools_limit` 95% 逻辑相同，但写两份独立函数 + 源码级 grep 守卫优于泛化 `_resolve(policy_id, default)` —— 每条 policy 启动期日志要独立字符串便于运维 grep、未来可能为特定 policy 加自定义日志/告警/指标、5 档 fallback 分支抛出的 WARN 要追溯到具体 policy 名字。⑪ **Phase 4 P3 候选**：(a) 三阶段门控（pre-check → runtime-gate → post-verify）把 `evaluate_policy(policy_id, context)` 接入请求管线 (b) 第三条 policy 切换候选 `max-request-body-size`（已有 explicit limit）或 `alert-context-isolation`（已有 ordering_constraint）(c) MR-7 兑现：为每个 context evaluator 添加 governance_ontology.yaml 对应 INV-* 让 wiring 本身被治理监控。|
| V37.9.12 | 2026-04-22 | **Phase 4 P1 wiring 落地 — engine.py 三纯函数 API + max-tools-per-agent policy 首切换** — ① **触发**：V37.9.9 完成 Phase 4 骨架（domain_ontology.yaml + policy_ontology.yaml + 15 单测）但 `engine.py` 未实现 wiring API，两个 YAML 停留在声明层没有消费者，status.json unfinished 登记 "Phase 4 P1+ wiring: engine.py 新增 load_domain_ontology() + find_by_domain() + evaluate_policy() 三个纯函数 API"。② **三纯函数 API 实现**（engine.py 第 650~800 行）: (a) `load_domain_ontology(path=None) -> dict` 加载 YAML 无缓存 (b) `find_by_domain(domain_name, ontology=None, path=None) -> list` 六域归一化: Actor→instances / Resource→categories / Task→taxonomy / Memory→layers / Provider.types 字符串包装成 `{"id":s}` / Tool 主动返回 [] 因 source_of_truth=tool_ontology.yaml / 未知域返回 [] 不抛 (c) `evaluate_policy(policy_id, context=None, policy_data=None, path=None) -> dict` 12-key 稳定返回: policy_id / found / type / hard_limit / limit / applicable / rule / rationale / enforcement_site / governance_invariant / scope / reason；Phase 4 P1 覆盖 static 策略（applicable=True），contextual/temporal 返回 applicable=None+reason=needs_context_evaluator 留给 Phase 4 P2；load 失败返回 found=False+reason=load_failed 不抛异。(d) `_parse_limit_from_rule()` helper 从 rule 文本提取 ≤/<=/< 数值（下划线千位分隔支持）作为 YAML 未显式声明 `limit` 字段时的回退。③ **policy_ontology.yaml 3 条 hard_limit policy 加 `limit` 字段**：max-tools-per-agent=12 / max-tool-calls-per-task=2 / max-request-body-size=200000，作为机器可读阈值，`evaluate_policy().limit` 优先读此字段>`value`>regex-parse rule。④ **proxy_filters.py 首切换**: filter_tools 的硬性截断阈值从 `_CFG_MAX_TOOLS` 改为 `_MAX_TOOLS_RESOLVED`（模块启动时由 `_resolve_max_tools_limit()` 解析）。Safe-fallback 5 档: (i) ONTOLOGY_MODE=off → config (ii) _onto_mod 未加载 → config+log warn (iii) policy not found / limit=None → config+log warn (iv) shadow mode → config 但 log observe ontology vs config 差异 (v) on mode + valid limit → ontology limit+log drift if any。启动日志: `[proxy] max-tools-per-agent: using ontology limit=12 (Phase 4 P1 wiring active)`。改 12 只需改 policy_ontology.yaml 一处（Phase 4 终态部分兑现）。⑤ **38 新单测** `ontology/tests/test_engine_phase4.py`: TestLoadDomainOntology(4)/TestLoadPolicyOntology(1)/TestFindByDomain(9)/TestEvaluatePolicyContract(7)/TestMaxToolsPolicyWiring(6)/TestParseLimitFromRuleFallback(7)/TestEvaluatePolicyLimitFallbackChain(4)。**11 新单测** `test_tool_proxy.TestPolicyDrivenMaxTools`: 5 档回退路径每档独立 monkey-patch 测试 + filter_tools 截断/custom tools 保留 + 源码守卫 `>\s*_CFG_MAX_TOOLS` 禁止回退模式。**2 扩展单测** `test_phase4_ontology_skeleton.py`: hard_limit 必须有 `limit` 字段 + max-tools-per-agent.limit==12 横向一致。⑥ **full_regression.sh 接入** `engine_phase4` suite。⑦ **accumulated**: 41→42 suites / 1201→**1252 tests (+51)** / 0 fail / 38/38 invariants / 安全 95/100 / VERSION 0.37.9.11 → 0.37.9.12。⑧ **部署策略（Mac Mini 实测结果修正 V37.9.12.1）**：`$HOME/ontology` 是 **symlink → `$HOME/openclaw-model-bridge/ontology`**，`ontology/` 未入 FILE_MAP 但通过 symlink 跨越——`$HOME/proxy_filters.py` 能直接找到 `$HOME/ontology/engine.py`。**Phase 4 P1 wiring 在 Mac Mini 真实生效**（不是 safe-fallback），`/health` 返回 `version: 0.37.9.12`，日志确认 `[proxy] max-tools-per-agent: using ontology limit=12 (Phase 4 P1 wiring active)`。宪法"删除后原系统正常"仍成立（只需删 symlink，系统走 config fallback）。**同时发现 launchd plist 配置债**：`com.openclaw.proxy.plist` 无 `ONTOLOGY_MODE` env 但 launchd 进程仍使用 shadow 模式（来源未追到，疑似 bytecode cache 或系统 env 继承），通过 `PlistBuddy Add :EnvironmentVariables:ONTOLOGY_MODE string on` 显式覆盖已修复；launchd 进程 PID 73456 Python 3.9 现以 on 模式 serve（Phase 4 wiring active 日志生效）。附带发现 adapter plist 同款双管理冲突（restart.sh manual 进程 + launchd KeepAlive 抢端口），登记 V37.9.13 架构清理。⑨ **元价值**: Phase 4 P1 是 V37.9.9 骨架到 V3 路标"pip install ontology-engine"终极目标的关键桥梁 — 从"本体只描述"升级为"本体可查询"。Phase 4 P2 下次推进: (a) contextual/temporal policy 的 context evaluator 实现（hour_of_day / request context matcher）(b) 选第二条 policy 做切换（max-tool-calls-per-task 最相似路径）(c) `evaluate_policy().applicable` 真值覆盖到 100% 策略。|
| V37.9.11 | 2026-04-22 | **MRD-RESERVED-FILES-001 闭环：BOOTSTRAP.md + SKILL.md 加入保留文件列表** — ① **触发**：V37.9.9 Mac Mini governance --full 扫 OpenClaw dist/*.js 639 个 JS 文件，发现 3 个 runtime 保留文件模式（`f.name === "X.md"`），但 `proxy_filters.RESERVED_FILE_BASENAMES` 只登记了 HEARTBEAT.md，漏掉 BOOTSTRAP.md + SKILL.md。MRD 连续 warn 提示未闭环。② **同类风险**：BOOTSTRAP.md / SKILL.md 虽未发生血案，但 MRD 源码扫描证实它们与 HEARTBEAT.md 同属 OpenClaw runtime 保留文件 —— LLM 写入会触发 runtime bootstrap/skill 机制，同款 13h 静默风险。③ **四层扩展**：(a) `proxy_filters.py::RESERVED_FILE_BASENAMES` 从 1 个扩到 3 个 basename (b) `RESERVED_FILE_SAFE_CONTENT` 从 HEARTBEAT-specific 改为通用 comment-only 骨架（首行从 `# HEARTBEAT.md` 改为 `# OpenClaw runtime reserved file — comments-only safe placeholder`，3 文件共享同一安全占位） (c) `SOUL.md 规则 11` 从单文件扩展到 3 文件条款，加入 basename 明细表 + 更新禁止行为 (d) **INV-HB-001 扩展 4 checks**：2 个 file_contains（BOOTSTRAP.md / SKILL.md 字面量存在）+ 1 个 runtime python_assert（for-loop 遍历 2×basename × 3×path_prefix = 6 场景 + edit 工具同款覆盖，避开 V37.3 exec scope trap）。④ **8 新 test_tool_proxy 单测** `TestReservedFileWriteBlock` 扩展：basename 常量守卫 ×2 / 精确集合契约（禁止漂移必须走 MRD） / BOOTSTRAP workspace 路径拦截 / SKILL home 路径拦截 / 2 文件 edit 工具拦截 / fix_tool_args BOOTSTRAP 恶意内容（`exec('rm -rf /')`）完全清除 / SAFE_CONTENT 文件无关性（首行不硬编码特定文件名）。⑤ **累计**: governance 59 inv / 283→287 checks (+4) / 41 suites / **1201 tests (+8)** / 0 fail / 安全 95/100 (Mac Mini 应保持 100/100). ⑥ **元价值**: MR-15 从"血案后 post-hoc 响应"进化为"源码扫描 pre-emptive 覆盖"— MRD-RESERVED-FILES-001 主动发现 OpenClaw 新增的 runtime 保留文件而不是等血案。此次闭环是 MR-7 (governance-execution-is-self-observable) 的生产级兑现：治理工具主动告警 → 人类修复 → 治理自证闭环。|
| V37.9.10 | 2026-04-22 | **audit_log 原子导出 + fsync 持久化加固（数据完整性 13→15 满分）** — ① **触发**：V37.9.9 Mac Mini 生产验证 security_score 跃升 93→98/100（bandit 已装 + 32 test suites），但 `数据完整性 13/15` 仍是唯一未满分项（`atomic_count=2` 因 audit_log.py 使用 append-only JSONL 未含 `os.replace`）。② **有意义的修复（非凑分数）**：(a) `audit()` 写入后加 `f.flush() + os.fsync(f.fileno())` + try/except OSError 兜底 tmpfs 不支持 fsync —— 防止 cron 环境进程崩溃时内核缓冲区尾部记录丢失 (b) 新增 `snapshot(dest_path)` 函数 — 用 `tmp + os.replace` 真原子模式导出审计日志快照到目标路径，保证"完整有效 JSONL 或根本不修改"，适用于备份/跨主机同步 (c) 新增 `--snapshot DEST` CLI 模式。③ **7 新单测 TestSnapshot**：缺审计文件返回 ok=False（非抛异常）/ snapshot 字节级一致副本 / 不留 .tmp 残余（atomic pattern 契约）/ 自动创建目标目录 / 覆盖已存在目标（os.replace 语义）/ 源码级守卫 os.replace + def snapshot / 源码级守卫 os.fsync。④ **累计**: security_score 数据完整性 13→15 / 总分 93→95（dev）/ 98→100（Mac Mini 预期）/ 41 suites / **1193 tests (+7)** / 0 fail / VERSION 0.37.9.9 → 0.37.9.10。⑤ **元价值**: 原则 #18 "补证据而非补功能"的正向兑现 — 每个改动对应真实运维场景（fsync=durability / snapshot=backup），不是为了让 grep 检查通过。|
| V37.9.9 | 2026-04-22 | **路线 C Step 4: security_score library 直调 + Ontology Phase 4 骨架** — ① **任务 A（Mac Mini V37.9.8 验证）**：ACL cron 今日 HKT 9:30:00 准时触发 + 10 篇论文推送成功（4/15 失败的任务复活；V37.9.8 调宽 28d 阈值策略生效）；auto_deploy heartbeat 每小时整点完美出行（`Wed Apr 22 06:00:06 ~ 10:00:06 HKT heartbeat: no change`）；watchdog 真实日志名为 `gateway_watchdog.log`（非 job_watchdog，对清单做修正）；**新发现 MOVESPEED rsync Operation not permitted 间歇性复发**（V37.9.4 APFS 重建后理论闭环但又报错，顶层权限 OK 但 rsync 子操作失败，登记观察）。② **任务 C（security_score 库化）**：INV-SEC-001 check 2 从 `subprocess.run(["python3","security_score.py"])` + 中文正则 parse `"安全评分：(\d+)/100"` 升级为 `from security_score import compute_score` 直调 + 从 `security_config.total_threshold` 读阈值。三问题一并解决：(a) 消除 ~200ms fork 开销每次 audit (b) 消除正则 parse 失败静默 pass 的塌陷盲区 (c) 消除硬编码 90 与 YAML 阈值漂移风险。三个 INV-SEC-001 runtime check 现全部 library + YAML 真理源统一。**3 新 regression test** `TestInvSec001UsesLibraryDirectCall`：(1) `test_no_subprocess_call_*` 锁定 active code 禁止 subprocess 反模式（智能跳过注释/文档块） (2) `test_inv_sec_001_imports_security_score_library` 契约 (3) `test_inv_sec_001_reads_total_threshold_from_yaml` 禁硬编码 90。③ **任务 B（Phase 4 骨架）**：新增 `ontology/domain_ontology.yaml`（六域概念模型 Actor/Tool/Resource/Task/Provider/Memory + 域间关系 + 实施路径 Phase 4 P1/P2/P3 清单）+ `ontology/policy_ontology.yaml`（10 条声明式策略 = 3 static + 2 temporal + 3 contextual + INV-PA-001 ordering_constraint + 元规则 MR-7/8/16 + 策略冲突检测 stub）+ `test_phase4_ontology_skeleton.py`（15 单测：六域声明/description 长度/Actor 核心实例/source_of_truth 对齐/Memory 四层匹配 memory_plane/policy 三类分类/policy 必填字段/hard_limit 仅 static/alert-isolation ordering_constraint/跨 ontology 引用一致性）。**状态**: declaration_only，未 wiring。下次 B 推进从 `engine.py::load_domain_ontology()` + `evaluate_policy()` 开始。④ **governance v3.30 → v3.31**: 58 inv / 272→273 checks。⑤ **全量回归**: 41 suites / **1186 tests** / 0 fail / 安全 93/100。⑥ **元价值**: 本次 C 是 MR-16（security-governance 双轨统一）的终态 — security_config YAML 真正成为 security_score.py + governance_checker 共同读的唯一数据源，观察者盲区彻底闭合。|
| V37.9.6 | 2026-04-21 | **告警噪声治理 + watchdog 行级时间戳过滤 (MR-4 反向变种修复)** — ① **触发**：12:30 watchdog 推送 12 项告警，**6 项是陈旧错误** (kb_evening 4/14-15 已 V37.8.10 闭环 / openclaw_discussions 4/8 推送失败 / kb_inject gateway 1006 / 等)。**告警疲劳是真实成本**——用户每天看到一半"幽灵告警"会逐渐麻木真告警。② **MR-4 反向变种**：前 14 次 silent-failure 都是"漏报"，第 15 次是"过度报"——同样违反"告警必须信号化"原则。③ **根因**：`job_watchdog.sh:scan_logs()` 只过滤文件 mtime（24h 内文件才扫），但 `tail -50 grep` 扫到的行内可能含 13 天前错误（持续更新的日志文件历史尾部）。④ **修复 awk 行级时间戳过滤**：解析 `[YYYY-MM-DD ...]` 前缀，仅保留 24h 内行；`in_recent` 状态机让 Python Traceback 多行延续跟随上一时间戳行状态（旧 Traceback 自动丢弃）。⑤ **失效源清理**：(a) `rss_blogs.sh` 注释掉 LangChain RSS（持续 9 次 HTTP 404 死链） (b) `job_watchdog.sh` ACL Anthology 阈值 8d → 14d（ACL 学术源更新频率本就低，4/8 后真无新内容不应报噪）。⑥ **INV-WATCHDOG-FRESHNESS-001 新增**（meta_rule=MR-4, severity=high, layer=[declaration, runtime]）7 checks：6 declaration scan watchdog 源码（V37.9.6 标记/cutoff_date/in_recent/recent_window grep/1209600 ACL 阈值/LangChain 注释）+ 1 runtime subprocess 调外部 `test_watchdog_freshness.py` 12 单测。⑦ **12 个新单测**：TestTimestampFilter(7) 锁定今日/昨日保留 + 13d 前过滤 + 旧 Traceback 多行延续过滤 + 新 Traceback 保留 + state 切换正确 + TestWatchdogShellInvariants(4) 源码守卫 + TestRssBlogsCleanup(1) LangChain 死链清理。⑧ **关键澄清**：08:28 端口冲突初判为 silent failure 实为**误读**——incident_snapshot.py `_tail_file` 读 proxy.log **历史尾部 100 行**含 traceback，proxy_stats.last_success_time=08:15:16 证明 8:15 后 proxy 正常运行。watchdog 在 8:30:03 因 11 alerts 触发 incident 写入。**告警通道工作正常**，问题在告警内容质量。⑨ **累计**：governance v3.29→v3.30 (57→58 inv +1 INV-WATCHDOG-FRESHNESS-001 / 265→272 checks +7) / 40 suites / 1159 tests (+12) / 0 fail / 安全 93/100 / VERSION 0.37.9.5 → 0.37.9.6。|
| V37.9.5 | 2026-04-21 | **数据全景审计 + workspace .md 接入 KB 索引（接缝盲区闭合）** — ① **数据全景审计**：用户直觉"~/.kb 67M 数月业务积累太少"驱动深度审计。发现：(a) ~/.kb 67M 含 text_index 44M 派生 → 真业务 23M；(b) ~/.openclaw/workspace 109M 中 109M 几乎全是 venv 53M+venv_pptx 56M（Python 包不是业务），真业务 .md ~50KB；(c) ~/.openclaw/logs 105M 中 90M 是 gateway.err.log 噪声，真业务 ~11M；(d) ~/.openclaw/media 41M 由 mm_index 单独管。**真业务总数 ~75MB**——精炼模式合理，但发现 workspace 顶层 PA 自主 .md（AGENTS.md / IDENTITY.md / SOUL.md / OPENCLAW_*_SUMMARY 等）从未接入 text_index。② **kb_harvest 压缩比验证**：4/20 提炼 78 条对话 84KB，合理无需修改。③ **任务 3 实施**（`kb_embed.py:scan_kb_files`）：扩展从只索引 `MEMORY.md` 单文件到扫描整个 `~/.openclaw/workspace/*.md`（顶层）。新增 `WORKSPACE_EXCLUDE_BASENAMES = {"MEMORY.md", "HEARTBEAT.md"}` —— MEMORY.md 已单独索引为 `source_type=memory`（向后兼容），HEARTBEAT.md 严格排除（V37.8.16 INV-HB-001 OpenClaw 控制文件不得当业务知识，避免下个血案）。`.bak` / `~` 排除（备份/临时文件）。其他 .md 用新 `source_type=workspace`。④ **INV-KB-COVERAGE-001 新增**（meta_rule=MR-4, severity=high, layer=[declaration, runtime]）4 checks：3 declaration scan kb_embed.py（含 workspace_dir 扫描 + HEARTBEAT.md 排除 + .bak 过滤）+ 1 runtime subprocess 调外部 `test_kb_embed_workspace.py` 单测（避开 V37.3 exec scope trap 的 YAML 内嵌闭包陷阱）。⑤ **10 个新单测** `test_kb_embed_workspace.py`：TestWorkspaceIndexing(7) + TestExclusionList(3) 锁定 AGENTS/IDENTITY 被索引 + HEARTBEAT.md/.bak 排除 + MEMORY.md `source_type=memory` 向后兼容 + 其他 .md `source_type=workspace` + 目录不存在不崩溃 + 常量 + V37.8.16 注释引用。⑥ **MR-4 silent-failure 第 15 次演出**：本次新形态 = 数据接缝盲区——~50KB workspace .md 数月以来 PA 自己搜不到自己写的内容，因 kb_embed.py 范围限定遗漏。每次新增类似 PA 文档源都需要回扫——INV-KB-COVERAGE-001 守卫的就是这个。⑦ **累计**：governance v3.28→v3.29 (56→57 inv +1 INV-KB-COVERAGE-001 / 261→265 checks +4) / 39 suites / 1147 tests (+10) / 0 fail / 安全 93/100 / VERSION 0.37.9.4 → 0.37.9.5。|
| V37.9.4 | 2026-04-21 | **B 问题闭环 + MR-4 silent-failure 第 14 次演出系统化预防** — ① **MOVESPEED exfat → APFS 转换**（SSH 远程 `diskutil eraseDisk APFS MOVESPEED disk6`，新挂载 `/dev/disk4s1 (apfs, journaled)`，POSIX 3/3 通过 mkdir/chmod/touch）解决 6 天 cron rsync 静默失败盲区。② **20 处 cron rsync 反模式批量修复**：旧 `rsync ... 2>/dev/null \|\| true` → 新 `rsync ... 2>&1 \|\| echo "[XXX] WARN: SSD rsync failed (exit=$?)" >&2`。覆盖 5 个根目录脚本（kb_dream/kb_save_arxiv/kb_evening/kb_inject/kb_review）+ run_hn_fixed.sh + 13 个 jobs/ 脚本（含 freight 2 处）= 共 18 文件 20 处。设计：失败时 stderr 出 WARN 进 cron log（可见+可 grep），exit 0 保留（不杀 cron 主流程），写 `>&2` 避免污染命令替换（顺势 MR-11）。③ **INV-BACKUP-001 新增**（meta_rule=MR-4, severity=high, layer=[declaration, runtime]）3 checks: declaration 全局扫 .sh 禁止 `2>/dev/null \|\| true` 反模式 + 任何含 rsync MOVESPEED 必须有 "WARN: SSD" 字样 + runtime 真跑模拟 rsync 失败断言 stderr 含 WARN + stdout 不含。**部署即时验证**：第 1 次跑就抓出第 20 个漏网（run_hn_fixed.sh），声明层守卫真有效。④ **案例文档** `ontology/docs/cases/movespeed_exfat_silent_backup_failure_case.md`：完整四维度因果链架构图 + 三层根因（exfat fskit transient EPERM 触发 / 18 处复制粘贴反模式放大 / 监控盲区掩护）+ 时间线还原 + 6 条件组合分析 + MR-4 14 次演出对照表 + MR-8 copy-paste-is-a-bug-class 反例兑现 + 6 条元教训。⑤ **元洞察**：本次是 MR-4 silent-failure 的**新形态**——前 13 次都是单点静默，第 14 次是**多脚本统一反模式协同沉默 6 天**。修复证明 MR-8 反例：复制粘贴 18 次的反模式 = 系统性 bug 类，需要工具发现（INV-BACKUP-001 全局 scan）而非靠程序员记忆。⑥ **累计**：governance v3.27→v3.28 (56 inv (+1 INV-BACKUP-001) / 261 checks (+3) / 15 meta rules / 13 MRD scanners) / 38 suites / 1137 tests / 0 fail / 安全 93/100 / 对抗审计 16/16 / VERSION 0.37.9.3 → 0.37.9.4。|
| V37.9.3 | 2026-04-21 | **四项顺序推进：X 僵尸告警可观测性 + MR-6 9 项 high 补齐 + audit-of-audit 4 维度扩展 + 路线 C Step 3 终态** — ① **#1 X 僵尸告警路径诊断**（`jobs/finance_news/run_finance_news.sh`）：4/20 07:30 三天连续命中但 WhatsApp+Discord #alerts 零到达。Mac Mini 日志证实执行到 `notify` 调用但静默，手动测试证明 notify+前缀+topic 路径正常工作 → 定性为 Gateway 瞬时故障（已自愈）。最小修复：(a) DAY/TS 去掉显式 `TZ=Asia/Hong_Kong`，与 YESTERDAY/DAY_BEFORE 统一用系统默认 TZ，消除时区不一致漏洞 (b) 告警路径每个分支加诊断 log（5 种跳过原因识别：日期解析失败/昨-前日文件不存在/文件为空/交集为空/NOTIFY_LOADED=false）(c) `notify` 调用加 `\|\| log "exit=$?"` 捕获失败 exit code。下次再发故障能留下决定性证据。② **#2 MR-6 9 个单层 high 全部补齐** — MRD-LAYER-002 从 ⚠️ 9 个 warn 转为 ✅ pass。分三批：Batch A 纯 metadata 修正（`INV-TOOL-003 / INV-CRON-002 / INV-NOTIFY-003` 已有 python_assert 性质为 runtime，只标签错）；Batch B 真缺 runtime（`INV-NOTIFY-002 / INV-HEALTH-001 / INV-NOTIFY-004 / INV-JOB-GOVAUDIT-001 / INV-JOB-HARVEST-001` 各加一个 subprocess 或 AST 级 runtime python_assert，notify 空 channel stderr ERROR / 空 channel token 捕获 / AST MapReduce 函数存在 / governance_audit_cron 因果链 + alerts topic 路由）；Batch C 缺 declaration（`INV-CRON-004` 加 YAML 源码 `_cron_cmd_invokes` + `cmd.endswith(entry)` 守卫，与 INV-CRON-003 共享策略）。25 个 high 不变式全部 ≥2 层验证。③ **#3 audit-of-audit 从 1 维扩展到 4 维**（`ontology/governance_checker.py`）— 原 `MRD-AUDIT-PERF-001` 仅 `wall_time_ms`，扩展为：`wall_time_ms`（保留 1.3x+300ms）+ `peak_memory_mb`（新，1.5x+10MB，跨平台 `resource.ru_maxrss`）+ `bootstrap_ms`（新，2.0x+500ms，SESSION_START 到第一个 check 的启动开销）+ `skip_rate_pct`（新，绝对 +20pct 突增）。`_AUDIT_FIRST_CHECK_TIME` 全局变量在 `run_all` 第一次 iteration 时 stamp。老 history 缺字段时 median=0 自动跳过该维度判定（向后兼容）。新增 14 单测 `ontology/tests/test_audit_perf_dimensions.py`：4 维度独立阈值边界 + 向后兼容 + 跨平台内存转换 + 3 new fields 写入完整性。④ **#4 路线 C Step 3 数据源统一到 ontology** — V37.9 Step 1 `INV-SEC-001` 总分 ≥ 90 / V37.9.1 Step 2 per-dimension MIN_THRESHOLDS 硬编码在 YAML python_assert / V37.9.3 Step 3 阈值上升到 `governance_ontology.yaml` 顶层 `security_config.dimensions` 作为**唯一真理源**。INV-SEC-001 从 `security_config` 读阈值（不再硬编码），新增"ontology 维度名 vs security_score.py 实际输出对齐"守卫（防改名漂移）。`security_score.py` 新增 `load_ontology_thresholds()` 纯函数 + `check_ontology_thresholds(data)` 纯函数 + `--check-ontology-thresholds` CLI 模式（读 YAML 对比 exit 0/1）。新增 12 单测 `test_security_ontology_alignment.py`：YAML 段存在 + 7 维度声明 + 名字跨源对齐 + 阈值 ≤ 满分 + INV-SEC-001 不得重新硬编码 + CLI 模式 + 纯函数 pass/fail 三场景。⑤ **累计**: governance v3.26→v3.27 (55 inv / 258 checks / 15 meta rules / 13 MRD scanners, 新增 security_config 顶层段) / 38 suites / 1137 tests (+26) / 0 fail / 安全 93/100 / 对抗审计 16/16 (100%) / VERSION 0.37.9.2 → 0.37.9.3 / Opus 4.7。|
| V37.9 / V37.9.1 / V37.9.2 | 2026-04-20 | **Stage 2 验证者阶段四轮交付：路线 A 血案回填 + 路线 B 对抗审计 + V37.8.18 盲区修复 + V37.9 结构加固 + V37.9.1 安全统一 + V37.9.2 MR-6 深度补齐** — 从"修血案"进入"建制度"。① **路线 A 实证交付** `ontology/docs/audit_coverage_retrospective.md` (618 行): 15 个真实血案逐一回填 Q1/Q2/Q3 三问 → **0% 预防率 + 87% 回归率 + 80% 空白类别**。② **路线 B 对抗审计** `ontology/docs/adversarial_audit_report.md` (177 行) + `ontology/tests/adversarial_chaos_audit.py` (572 行, 16 场景): Cat A 10/10 (已知血案回归 100% 防御) + Cat B 6/6 (探测盲区全部闭合，V37.8.17 前 0/6 → 今日 6/6)。③ **V37.8.17 MR-14/MR-15 MRD 三步跃迁** (单点修复 → 元规则 → MRD 扫描器): MRD-ALERT-INDEPENDENCE-001 + MRD-RESERVED-FILES-001。④ **V37.8.18 P1+P2 修复 5/6 盲区**: C14 INV-KB-001 扩展 dict 防御 / C11 MRD-SILENT-EXCEPT-001 新增 / C15 MRD-PUSH-ROUTE-001 新增 / C12 INV-COST-001 retry 上限 / C13 INV-OBSERVABILITY-001 扩展 last_run 一致性。改进 adversarial counter 从 boolean → 按 "N 处" 数字解析 (工具自身递归 MR-7 自观察)。⑤ **V37.9 四项结构加固**: (a) adversarial Cat A 集成 full_regression layer 3.5 (每 PR 前跑防御力回归) (b) MRD-LAYER-002 渐进 warn severity=high 12 项技术债 (c) MRD-AUDIT-PERF-001 audit-of-audit (SESSION_START 实时 wall + 中位数双阈值 1.3x+300ms, C16 对抗 sleep 0.5→1.5s UNEXPECTED catch) (d) MR-16 + INV-SEC-001 security+governance 双轨统一 (score ≥ 90 守卫)。⑥ **V37.9.1 路线 C Step 2**: INV-SEC-001 按 7 维度 MIN_THRESHOLDS 细化 (密钥 15/测试 13/数据 10/部署 15/传输 9/审计 15/可用 8), 防"单维度塌陷但总分被其他拉高"。⑦ **V37.9.1 Stage 2 话语权** `docs/articles/audit_is_regression_not_prevention.md`: 立场型文章（第 4 份公开资产）论证 "audit 不是 prevention 是 regression engine"，6 条可落地原则。⑧ **V37.9.2 MR-6 深度补齐** (12→9 单层 high): INV-PA-002 runtime 解析规则 10 完整块 / INV-DREAM-001 runtime 解析 DREAM_TIMEOUT_SEC 动态映射 / INV-DEPLOY-003 runtime 扫双侧 status.json 邻近 continue。全部避开 V37.3 exec scope trap 用 iterative for。⑨ **原则 #30 升级 Opus 4.7**: 合法模型家族 = Opus (4.6/4.7/更新)，升级不是降级。⑩ **今日 X 僵尸清理**: ForeignPolicy/Carnegie_Endow/PDChina/CNS1952/SingTaoDaily 5 账号 4/18-19-20 三天连续命中从 FINANCE_X_ACCOUNTS 移除 + 6 个 file_not_contains 守卫。⑪ **KB 数据闭环验证**: chaspark.md 35 chunks + finance_daily.md 116 chunks 全部进入 text_index，kb_dream 今日提及 4 次，数据复利正向循环确认。⑫ **累计数字**: governance v3.19→v3.26 (55 inv / 256 checks / 15 meta rules / 13 MRD scanners) / 37 suites / 1111 tests / 安全 93/100 / 对抗审计 16/16 (100%) / VERSION 0.37.8.15 → 0.37.9.2 / 今日 30+ commits (e21d086 → 10a8492)。|
| V37.8.16 | 2026-04-20 | **PA 自残 HEARTBEAT.md 血案闭环（MR-4 silent-failure 第 12 次演出 + MR-15 新元规则立案）** — ① **血案**：2026-04-19 09:09 PA (Wei) 处理 HN 告警对话时调用 write 工具把"[SYSTEM_ALERT] HN热帖抓取已恢复 / 任务完成 / 下一步监控"三行写进 `~/.openclaw/workspace/HEARTBEAT.md`（把它当普通 TODO 文件名用）。13 小时潜伏期后（4/19 22:09）用户开始发 WhatsApp 消息，OpenClaw heartbeat 机制 (`auth-profiles-*.js:48796 isHeartbeatContentEffectivelyEmpty=false`) 激活 `runKind="heartbeat"` 模式，system prompt 变成默认 "Read HEARTBEAT.md if it exists. Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK." → Qwen3 严格执行 + 看到 HEARTBEAT.md 里"任务完成"判定无需关注 → 对每条用户消息都回 "HEARTBEAT_OK"（12 字符）→ Gateway `stripTokenAtEdges` 剥离 12 字符 → outbound 空 → 用户完全看不到 PA 回复 13 小时直到人肉察觉。② **六条件组合爆炸**：(1) WhatsApp plugin 4/10 14:53 被 OpenClaw 自动安装（WhatsApp routing 从 core 改为 plugin）(2) PA 有 write 工具 + workspace 访问（一直有）(3) HEARTBEAT.md 是 OpenClaw 保留文件（一直是）(4) PA 不知道它有特殊语义（一直不知道）(5) `agents.defaults.heartbeat.prompt` 未配置 → fallback 默认 prompt（一直未配置）(6) HEARTBEAT.md 非空非注释 ← **4/19 09:09 PA 自写触发第 6 项，前 5 项长期潜伏**。③ **反面教训 (原则 #28 违规记录)**：4/19 深夜我（Claude Code）初诊时看到 proxy /stats 502 + p99 126s → 先猜 primary/fallback 问题；看到 Gateway auth 日志 "Bad MAC" → 立刻联想 auth corruption → 让用户 `rm -rf auth` + QR 扫码重新登录。**这是不可逆操作**，幸好用户回滚无损失。正确路径是今天早上走的：读 status.json 焦点 → 查 git log 排除自己改动 → 读 OpenClaw 源码 `resolveHeartbeatPrompt` → diff 4/3 vs 4/10 openclaw.json → 读 HEARTBEAT.md 实际内容（锁定 PA 自写）— **六轮假说错五轮才到达根因**。④ **最小修复**：`cat > ~/.openclaw/workspace/HEARTBEAT.md` 置为只含注释（3 行 # 开头），`isHeartbeatContentEffectivelyEmpty()` 立即返回 true → heartbeat 不再激活。2026-04-20 09:16 WhatsApp E2E 实测"早上好 你在吗" → PA 5 秒延迟回复"早上好，我在。系统状态正常" ✅。⑤ **MR-15 新元规则立案** `reserved-files-must-not-be-writable-by-llm`：任何被底层 runtime（OpenClaw/Gateway/Proxy/Adapter）赋予特殊语义的文件路径，不得暴露给 LLM 的 write/edit 工具作无约束写入目标。典型违反 = HEARTBEAT.md。合规做法四层联合防御：(1) 声明层 `RESERVED_FILES` 明细表 (2) 行为层 SOUL.md 规则 11 + 血案注释 (3) Proxy 拦截层 `detect_reserved_file_write()` 纯函数 + `fix_tool_args` 集成改写 `args.content` 为 `RESERVED_FILE_SAFE_CONTENT`（只含 # 注释行）(4) 测试层单测覆盖每条保留路径 + 每种 path alias。**MR-15 与 MR-4 关系**：MR-4 是问题分类（静默故障是 bug），MR-15 是上游预防层（别让 LLM 碰能制造静默故障的 runtime 文件）。⑥ **INV-HB-001 新增** `heartbeat-md-reserved-file-not-llm-writable`（meta_rule=MR-15, severity=critical, verification_layer=[declaration, runtime]）12 checks：proxy_filters.py `RESERVED_FILE_BASENAMES`/`RESERVED_FILE_SAFE_CONTENT`/`detect_reserved_file_write`/`fix_tool_args` 调用 + SOUL.md 规则 11 三个 grep 守卫（"禁止写 OpenClaw 保留文件"/"2026-04-19 血案规则"/"MR-15"）+ runtime python_assert 真跑血案场景（构造 PA 写入 HEARTBEAT.md 的 tool_call JSON 断言 content 被改写为 SAFE_CONTENT、原"任务完成"字样消失、SAFE_CONTENT 所有非空行以 # 开头）。⑦ **SOUL.md 规则 11 新增**（位置：规则 10 "告警消息不跟进"之后，`## 我的性格` 之前，避开 `## 当前项目状态` 自动刷新区）：禁止路径列表、识别规则（精确名 HEARTBEAT.md）、禁止行为（write/edit 任何内容）、替代方案（kb_write.sh / status_update.py）、血案时间与字符串锚点、四层结构修复引用。⑧ **16 新单测** `TestReservedFileWriteBlock`：纯函数 detect_reserved_file_write 11 测（blocked/allowed/case-sensitive/alias/trailing-slash/非 dict 参数/空字符串/非字符串 path 等）+ fix_tool_args 集成 3 测（write content 被改写 / edit new_text 被改写 / 正常 write 不受影响）+ 常量守卫 2 测（RESERVED_FILE_BASENAMES 含 HEARTBEAT.md / SAFE_CONTENT 只含 # 注释）。⑨ **governance v3.19 → v3.20**：52→53 不变式，236→248 checks，14→15 meta rules。**全量回归 36 suites / 1111 tests / 0 fail / 53/53 invariants / 234/234 checks / 15/15 meta rules / 安全评分 93/100**。⑩ **案例文档** `ontology/docs/cases/heartbeat_md_pa_self_silencing_case.md`（完整四维度因果链架构图 + 三层根因 + 时间线还原 + 六条件组合爆炸 + MR-15 元规则提炼 + 4/19 深夜原则 #28 违规复盘 + 6 轮假说错五轮的教训）。⑪ **未解决项登记到 unfinished**：WhatsApp 入站自 4/10 起路由到 research agent 而非 main（main/sessions.json mtime 停留在 Mar 30），但 HEARTBEAT.md 修复后 research agent 正常响应，不致命；长期应考虑 `channels.whatsapp.agent` 显式配置或 `agents.list` 顺序调整。⑫ **元教训**：MR-4 silent-failure 第 12 次演出的新形态——不是错误被吞、不是错误被稀释、不是告警路径失效，是 **LLM 正确响应系统 prompt + Gateway 正确剥离 ack token + 但 LLM 误读了 system prompt 的适用范围**。整条链路每一环都"按设计工作"，但设计本身有语义 gap：HEARTBEAT.md 作为 runtime 控制文件 vs LLM 视为普通 TODO 文件 —— 这个 gap 没被任何一层填补。**MR-15 正是填补这种 gap**：把 runtime 边界的保留语义显式声明给所有可能触碰的层。|
| V37.8.15 | 2026-04-17 | **preflight push test 垃圾消息修复 + Mac Mini 分支错位修复 + GitHub 全面刷新 + 外部评审吸收** — ① **触发**：用户报告每 2 分钟收到 `🔧 preflight push test` WhatsApp 消息（22 分钟内 12 条）。② **双层根因**：(a) Mac Mini repo 在 `claude/start-daily-work-Mql3p` 分支（非 main），`git fetch origin claude/...` 拿到旧 tip，与 HEAD（merge commit）永远不等 → `HAS_NEW_COMMITS=true` 无限循环 (b) `preflight_check.sh` step 16 push test 无速率限制，每次 `--full` 都发 WhatsApp。③ **三层修复**：Fix A Mac Mini `git checkout main` 切回正确分支（根因）/ Fix B `auto_deploy.sh` 传 `SKIP_PUSH_TEST=1` 给 preflight（auto_deploy 有自己的 quiet_alert）/ Fix C `preflight_check.sh` push test 加每小时速率限制（defense-in-depth）。④ **GitHub 全面刷新**：README v37.8.15（治理 52 inv / 35 jobs / Phase 3 ontology / 81 FILE_MAP / 15 案例）+ Issue #132 进度更新（393→1093 tests 增长表）。⑤ **OpenClaw 升级评估**：上游 v2026.4.15（+6 版本），#59265 经 14 版本仍 OPEN，继续 hold。⑥ **外部代码级评审吸收**：六优势（控制平面意识/Provider 抽象/韧性/阈值/门禁/战略）+ 五劣势（脚本特征/环境耦合/PyYAML/Memory 接口/文档过载）。录入 4 项 P0/P1 优先级：可迁移性闭环 + 证据链产品化 + 插件生态接口 + 可观测闭环。核心三字诀：**标准化 + 可比较 + 生态协议**。⑦ **Nikkei Asia 遗留关闭**：X Syndication 17/21 条正常，非僵尸。⑧ **全量回归**：36 suites / **1095 tests** / 0 fail / 52/52 inv / 安全 93/100。|
| V37.8.13 | 2026-04-16 | **Gateway 宕 9h 静默血案闭环 + auto_deploy FILE_MAP 自复制修复 + status.json 形状修复（MR-4 第 11 次演出）** — ① **触发**：2026-04-16 00:30 HKT Gateway 进程死亡（restart.sh bootstrap 后 21 秒崩溃 → launchd rapid-crash jettison），WhatsApp 全断 9 小时。② **三层放大器全失**：(a) auto_deploy `quiet_alert` 凌晨静默期 **同时跳过 WhatsApp 和 Discord**，3 次 CRITICAL preflight 失败全被 `[QUIET]` 吞（主谋）(b) `wa_keepalive` 每 30min 写 WARN 到日志**但不推送任何告警**（18 次 WARN 沉默 9h）(c) `restart.sh` 报 "Done!" 但不验证 Gateway 是否真活。③ **三层修复**：Fix A `quiet_alert` 静默期仅跳过 WhatsApp、Discord 始终推送 / Fix B `wa_keepalive` 连续 2 次 WARN 自动升级 Discord #alerts（告警链不依赖失效主体自身——Gateway 宕则 WhatsApp 不通，必须走 Discord）/ Fix C `restart.sh` post-bootstrap 5×3s 健康验证循环。④ **INV-WA-001**（meta_rule=MR-4, severity=critical, verification_layer=[declaration, runtime]）7 checks + **INV-QUIET-001** 4 checks。⑤ **V37.8.12 修复**：auto_deploy FILE_MAP 自复制行移除 + 双循环自复制守卫（`$REPO_DIR/$SRC == $DST` 跳过，防 macOS cp 非零 + set -e 杀脚本）。⑥ **status.json 形状修复**：`format_human` 防崩（非 dict 条目防御） + 数据修正（`session_context.unfinished` str→list、扁平 key 清理、`recent_changes` 损坏条目重建）。⑦ **21 单测** `test_wa_gateway_resilience.py`：TestQuietAlertDiscordAlways(4) + TestWaKeepaliveEscalation(9) + TestRestartGatewayVerification(5) + TestCrossFileGuards(3)。⑧ **governance v3.17→v3.18**：40→42 不变式，199→210 checks，12/12 MR。⑨ **全量回归**：37 suites / **1092 tests** / 0 fail / 42/42 inv / 196/207 checks / 安全 93/100。⑩ **案例文档** `whatsapp_silent_death_case.md`：完整四维度因果链 + MR-4 第 11 次演出叙事 + 元教训"告警链不得依赖失效主体自身"。⑪ **MR-14 候选**：`alert-path-must-not-depend-on-failing-subject`（本案核心教训升级为元规则）。|
| V37.8.11 | 2026-04-15 | **auto_deploy 每小时漂移告警噪声闭环（MR-4 第 10 次演出：expected-behavior 被错分类为 error）** — ① **触发**：用户反馈"几乎每小时都收到 `[SYSTEM_ALERT] 漂移检测: 修复 1 个部署文件不一致，已自动覆盖`"。用户确认**问题存在很久了，只是没注意**——V37.4.3 `[SYSTEM_ALERT]` 前缀让长期潜伏的告警在 WhatsApp 显性化。② **根因**：V37.8.1 曾给 preflight_check.sh drift 循环加过 `if SRC == status.json then continue` 豁免（因为仓库 status.json 是 Claude Code 快照，runtime `~/.kb/status.json` 被 kb_status_refresh cron 每小时重写 health/quality 字段，两侧设计上永远不一致），但 **auto_deploy.sh 的等价 drift 循环没有同步加豁免**——遗漏至今。每小时整点（minute<2）auto_deploy 轮询 → md5 比对发现不一致 → `cp` 覆盖 runtime（清空 runtime 数据） → `quiet_alert` 推送 [SYSTEM_ALERT] → 下个整点 kb_status_refresh 重写 runtime → 恶性循环。③ **MR-4 第 10 次演出新形态**：前 9 次 silent-failure 都是"错误发生了但不可见/被稀释"。第 10 次是**expected-behavior 被系统错分类为 error，然后产出噪声告警**——不是错误被吞，是**正常行为被当错误**。④ **结构修复**：auto_deploy.sh drift 循环（line 317 起）镜像 preflight 同款豁免 `if [[ "$SRC" == "status.json" ]]; then continue; fi`，保留 **new-commit 同步路径**（上方 CHANGED_FILES 循环）继续把 Claude Code 的 priorities/unfinished/recent_changes intent 单向下传。契约："one-way intent flow (repo → runtime via new-commit) + exempt from two-way drift detection"。⑤ **INV-DEPLOY-003 新增**（meta_rule=MR-4, severity=high, verification_layer=[declaration]）5 checks：preflight 豁免守卫×2 + auto_deploy 豁免关键字 + V37.8.11 注释标记 + FILE_MAP 仍含 status.json（intent 通道不能丢）。⑥ **案例扩展**：`kb_evening_fallback_quota_chain_case.md` 新增 V37.8.11 章节登记此血案类（"告警噪声也是 observability 问题"）。⑦ **governance v3.16 → v3.17**：39→40 不变式，194→199 checks。⑧ **全量回归**：36 suites / **1071 tests** / 0 fail / 40/40 invariants / 185/196 checks / 12/12 MR / 安全 93/100。⑨ **Mac Mini E2E**：下一个整点（2026-04-16 00:00 HKT）drift 告警应不再触发（只要 auto_deploy 已通过 git pull 拉到 V37.8.11）。⑩ **关键原则反思**：本案印证 **原则 #15 "定期像用户一样使用系统"**——这个 bug 如果我们自己用 WhatsApp 实际观察日常推送，半天就能发现，而不是等用户受够了主动上报。观察盲区的体现：**开发环境所有单测/治理/preflight 全绿，但生产环境用户每天被 24 条噪声告警折磨**。⑪ **元教训**：每当一个类别的 check 被加豁免（如 V37.8.1 的 preflight），应该**系统性扫描**同类 drift 检测脚本是否都需要同款豁免——auto_deploy 和 preflight 是两份独立的 FILE_MAP 消费者，V37.8.1 只修了一半。|
| V37.8.10 | 2026-04-15 | **kb_evening 连续 2 天 22:00 告警"HTTP 502: Bad Gateway"血案闭环 — LLM 错误链三层稀释（MR-4 第 9 次演出）** — ① **触发**：2026-04-14 首次 + 2026-04-15 再次，用户同一时段收到 `[SYSTEM_ALERT] kb_evening 失败 原因: LLM 晚间整理失败: HTTP 502: Bad Gateway`。连续 2 天定性为结构性。② **三层根因**：(a) **触发器**：2026-04-14 某时刻起 primary Qwen3 (hkagentx.hkopenlab.com) 开始不稳定，`adapter._CircuitBreaker.consecutive_errors` 累积到阈值 → breaker OPEN（22:00 kb_evening 请求到达时直接 skip primary，2026-04-15 23:53 primary last_success_time 证实时好时坏非宕机） (b) **放大器**：`FALLBACK_CHAIN = ["gemini"]` **只配 1 个 fallback**。gemini 2.5-flash 免费层 daily/rate quota 被白天 ~20 个 LLM cron (kb_inject/finance_news/arxiv/daily_ops/ai_leaders_x/hf_papers/ontology_sources/s2/dblp/pwc/github_trending/rss_blogs/freight…) 持续磨耗 → 22:00 gemini 也 429，整条链路死亡 (c) **掩护者（本血案核心）**：**三层错误链稀释**——adapter `_send_json(502, {"error": "ALL 1 FALLBACKS FAILED: gemini 429"})` → proxy `except Exception as e: str(e)` 只拿"HTTP Error 502: Bad Gateway"，**从未调 `e.read()`** → client `rc.call_llm` HTTPError `f"HTTP {e.code}: {e.reason}"`，body 再次丢弃。真实原因"gemini 429 quota 耗尽"经 3 跳稀释完全不可见。③ **结构修复**（两侧缺一不可）：(1) `proxy_filters.py` 新增 `compose_backend_error_str(exc)` 纯函数 + `MAX_UPSTREAM_BODY_CHARS=500` 常量，对 HTTPError 读 `e.read()` body + JSON `error` 字段提取 + 截断 + fail-open try/except（observability 增强绝不能成为新故障源）(2) `tool_proxy.py except Exception` 分支 import 并调 `compose_backend_error_str(e)` 替代 `str(e)` (3) `kb_review_collect.py` 镜像 helper `_compose_http_reason(http_error)` + `MAX_UPSTREAM_BODY_CHARS=400` + `call_llm` HTTPError 分支 `return False, "", _compose_http_reason(e)` (4) **架构契约 MR-8 正向兑现**：helper 放在 `proxy_filters.py`（纯函数无网络依赖，符合文件表架构）而非 `tool_proxy.py`（import 即启动 HTTP server 不可测），让 `test_tool_proxy` 可直接导入测试。④ **INV-OBSERVABILITY-001 新增**（meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime]）12 checks：proxy 侧 4 check（helper 定义 / MAX 常量 / read body / fail-open return base）+ tool_proxy 侧 3 check（import compose_backend_error_str / 不重新定义 helper 守卫×2）+ client 侧 3 check（helper 定义 / MAX 常量 / HTTPError 分支调 helper）+ 2 runtime python_assert 真跑血案场景（proxy helper 拼 upstream body 含"gemini 429" + kb_review helper fail-open on e.read 抛异常）。⑤ **21 新单测** `test_kb_review.TestComposeHttpReason`(10) + `test_tool_proxy.TestComposeBackendErrorStr`(11)：JSON error 提取 / 血案实际场景复现 / 非 JSON raw text fallback / empty body 向后兼容 / 超长 body 截断 / utf8 decode errors 替换 / e.read 抛异常 fail-open / 端到端 call_llm integration / tool_proxy.py import guard 禁止重新定义 helper。⑥ **Fix D 配套**：Mac Mini adapter 进程自 V36 (0.36.0) 起**首次重启**到 0.37.8.9——`bash ~/restart.sh` 后 `/health version: "0.37.8.9"` 生效（之前 V37.1~V37.4 三次 adapter.py commit 一直未在运行时）。但 `fallback_chain` 仍只显示 `["gemini"]`，说明 V3 capability routing 真跑但 `providers.d/` 下其他 provider 缺 API key env var → **Fix B 扩展 fallback 是独立的运维决策**，登记为 V37.8.11 候选。⑦ **MR-4 silent-failure 第 9 次演出（新形态）**：前 8 次都是"错误发生了但没被发现"。第 9 次是**错误被发现了但原因不可见**——用户看到告警，误以为观察机制工作正常，实际信息密度已经是零。这是更隐蔽的变种。⑧ **governance v3.15 → v3.16**：38→39 不变式，168+12→194 checks，meta rules 12/12 不变。⑨ **全量回归**：36 suites / **1071 tests** / 0 fail / 39/39 invariants / 180/180 checks (11 skip runtime-only) / 12/12 meta rules / 安全 93/100。⑩ **登记未解决项（不和本血案捆绑）**：(a) 扩展 fallback_chain 到 ≥2 provider — 需用户决策 API key (b) 其他 17+ LLM cron 加 `last_run_*.json` — 统一 observability 入口 (c) proxy_stats `auto_recovery_rate_pct=194.1%` bug（>100% 数学错误）(d) MR-13 候选元规则 `error-chain-must-preserve-upstream-cause-across-layers` — 把本血案教训升级为元规则 (e) gemini quota 消耗审计：白天 ~20 cron 哪些可降频。⑪ **案例文档** `ontology/docs/cases/kb_evening_fallback_quota_chain_case.md`（TL;DR + 完整因果链架构图 + 三层根因 + 时间线还原 + 七条件组合分析 + MR-4 演出史更新 + 5 条结构教训）。⑫ **Mac Mini E2E 待观察**：明日 2026-04-16 22:00 下次 kb_evening 告警（若再失败）应显示完整 upstream chain，形如"HTTP 502: Bad Gateway \| upstream: ... \| upstream: ALL 1 FALLBACKS FAILED: gemini HTTP 429"。|
| V37.8.9 | 2026-04-15 | **MR-11 / MR-12 运行时检测落地 — 元规则从"声明层"升级为"CI 可检测层"** — ① **触发**：V37.8.8 完成 MR-11 + MR-12 立案但两条元规则停留在 governance_ontology.yaml 的 `meta_rules:` 段声明层，无运行时扫描器，未来任何新代码违反不会被 CI 捕获。用户要求"#4 + #5 MRD 落地"把两条元规则从**被动声明**升级为**主动检测**。② **MRD-LOG-STDERR-001 实现**：`_discover_log_stderr_violations()` 在 governance_checker.py 扫所有 shell 文件（`*.sh` + `jobs/**/*.sh`）查找 log/debug/status/warn/info/notice/err/err_log 等诊断函数定义，识别单行 `log() { echo ...; }` + 多行 `log() {\\n ... echo ... \\n}` 两种形态。`_is_echo_to_stdout()` 纯函数判定：echo 行有 `>&2` 或 `1>&2` = stderr 合规；`>> file` 或 `> file` = 重定向到文件（不污染 stdout）；其余 = 违规。**白名单豁免 11 个用户交互诊断工具**（`cron_doctor/preflight_check/job_smoke_test/full_regression/daily_ops_report/health_check/smoke_test/quickstart/gameday/governance_audit_cron/kb_status_refresh`）因为它们 stdout 是用户终端的合法输出目标，不会被命令替换捕获。③ **MRD-LLM-PARSER-POSITIONAL-001 实现**：`_discover_llm_parser_positional_violations()` 扫 LLM 调用脚本集合（`jobs/*/run_*.sh` + `kb_*.{py,sh}` + `run_hn_fixed.sh` + `jobs/**/*.py` 共 37 个）检测三种反模式：`lines\[i+N\]` (任何 N≥1) / `i += N` (N≥2, 排除合法 while 遍历的 `i += 1`) / `(content\|text\|response\|result\|output\|raw\|llm_content).split()[N]`（白名单变量名避免误报）。**跨行 docstring 状态机豁免**（V37.8.9 edge case）：进入 `"""` 或 `'''` 块后跳过所有行直到遇到配对关闭符，这样历史血案注释里提到的 `lines[i+1] / lines[i+2]` 字样（V37.8.7 case doc）不被误判。**test_\*.py 文件豁免**、**assertNotIn/assertRaises 行豁免**、**注释行豁免**。④ **批量修复 19 个 job 脚本 log() 写 stderr**：用 sed 把 `log() { echo "..."; }` 替换为 `log() { echo "..." >&2; }` 覆盖 jobs/（acl_anthology/ai_leaders_x/arxiv_monitor/dblp/finance_news/freight_watcher/github_trending/hf_papers/karpathy_x/ontology_sources/openclaw_official×2/pwc/rss_blogs/semantic_scholar） + 主仓库（kb_evening/kb_inject/kb_review/run_hn_fixed）。格式统一的单行 log 定义使批量修复安全可行。修复后重新 scan：`所有 38 个 shell 文件的 log/debug/status/warn 函数均写 stderr（11 个诊断工具豁免）`。⑤ **governance_checker.py mr_used 计数器扩展**：原实现只从 `results` (invariants) 收集 meta_rule，V37.8.9 新增同时收集 `meta_rule_discovery` 引用的元规则——从 `元规则: 10/12` 升到 **`12/12`** 覆盖率。未来 MR-13/MR-14 加入后，只要任一 invariant 或 MRD 引用它们就会进入 used 集合。⑥ **32 单测** `test_governance_mrd_v8_9.py` 加入 full_regression：TestIsEchoToStdout(6) + TestScanShellLogFunctions(7) + TestDiscoverLogStderr(3) + TestPositionalPatterns(9) + TestDiscoverLlmParser(2) + TestMRDDeclarationInYaml(4) + 1 集成。关键边界：`i += 1` 豁免（合法 while 遍历）、`i += 2/3/4+` 捕获（跳多行即 MR-12 违反）、`echo ... >> file` 不报（重定向到文件）、多行函数体整体 `} >&2` 后置重定向合规、跨行 docstring 内的反模式字样豁免（避免血案注释被误判）。⑦ **governance v3.14 → v3.15**，38 不变式不变（MR 是元规则不是 invariant），168 checks 不变；两个新 MRD 加入 `meta_rule_discovery:` 段作为 Phase 0 可执行元规则发现。⑧ **全量回归**：35 suites / **1050 tests** / 0 fail / 38/38 invariants / 168/179 checks / **12/12 元规则**（从 V37.8.8 的 10/12 升满） / 安全 93/100。⑨ **未来保障**：任何新增 shell 脚本的 log/debug 函数写 stdout 会被 MRD-LOG-STDERR-001 自动 warn；任何新增 LLM 调用脚本用 `lines[i+N]` 或 `i += N` (N≥2) 解析会被 MRD-LLM-PARSER-POSITIONAL-001 自动 warn。两条元规则从**依赖人类记忆**的纪律问题变成了**CI 自动 enforce** 的架构约束，V37.8.6 和 V37.8.7 类血案未来不会再发生。|
| V37.8.8 | 2026-04-15 | **双元规则正式立案：MR-11 (log→stderr) + MR-12 (LLM-output-key-based)** — ① **触发**：V37.8.6 (Dream) + V37.8.7 (ontology_sources) 同日双血案都是 MR-4 silent-failure 的演出，但两个血案的**防御机制**是独立的跨领域架构规则，不该靠个别 INV 级别 check 一事一议。用户要求"立即立案"把两条元规则从"案例教训"正式升级为 ontology 治理体系的硬规则。② **MR-11 shell-function-output-must-go-to-stderr-if-not-returned-value**：shell 函数内的诊断/日志/状态输出（log / debug / status / warn）必须写到 stderr（`>&2`），不得写 stdout。原因：调用方常用 `RESULT=$(func ...)` 命令替换捕获 stdout 作为"返回值"，如果 log 也写 stdout 会污染 RESULT → 被当作业务数据向下游传递 → cache → 下游 LLM 幻觉。血案教训来自 V37.8.6：kb_dream.sh `log() { echo ...; }` 写 stdout 让 llm_call 失败时的错误日志被 `signals=$(llm_call ...)` 捕获 → cache 污染 → LLM 编造"Hugging Face 危机"。**一个 `>&2` 阻断整条幻觉链**，证明 MR-11 不是纪律问题而是架构硬规则。③ **MR-12 llm-output-parser-must-be-key-based-not-positional**：解析 LLM 文本输出的代码不得用严格位置索引（`lines[i] / lines[i+1] / lines[i+2] / i += N / content.split()[0/1/2]`）。允许模式按推荐度：(1) JSON/YAML schema 校验 (2) key-based prefix dict (3) 语义 state-machine + pending_* + 特征字符块边界 (4) 正则直接提取。强制要求：每个字段缺失有 sentinel 默认值 + 输出层有兜底（如 `cn_title = paper['title']`） + 块相互独立无级联。血案教训来自 V37.8.7：ontology_sources `i += 3` 步进 + 无 fallback → 级联错位 → 用户 WhatsApp 看到 `*---*` 作 cn_title。④ **V37.8.7 MR-12 扫描结果**：扫完 15 个 LLM 输出解析器，除已修的 kb_dream/ontology_sources，其他都合规：7 个论文类 job（arxiv/semantic_scholar/hf_papers/dblp/pwc/acl_anthology/github_trending/rss_blogs）共享 state-machine + key-based + 三重 fallback 模式（`pending_title` / `'⭐' in line` 块边界 / `paper['title']` 兜底），ai_leaders_x 用 pure dict key-based，run_hn_fixed 用 JSON+regex fallback。**无紧急修复任务**。⑤ **违反模式正则**（为未来 CI 扫描预埋）：MR-11 扫 `^\s*(log\|debug\|status\|warn\|info)\(\)\s*\{\s*echo\s+.*[^&]2?`；MR-12 扫 `lines\[i\s*[+]\s*[0-9]+\]` / `^\s*i\s*\+=\s*[0-9]+\s*$` / `content\.split\([^)]*\)\[[0-9]+\]`。⑥ **audit_metadata.meta_rules 10→12**（MR-1~MR-12，新增 MR-11/MR-12 作为 MR-4 silent-failure 的上游预防层）。governance_checker 自动跟随 audit_metadata 动态计数，显示 `元规则: 10/12`（12 条声明 / 10 条被现存 INV 引用）— MR-11/MR-12 暂无 invariant 关联，等 V37.8.9 迭代新增 MRD 扫描器落地运行时检测。⑦ **governance v3.13 → v3.14**：38 不变式不变（MR 是元规则不是 invariant），168 checks 不变。⑧ **全量回归**：34 suites / **1018 tests** / 0 fail / 38/38 invariants / 168/179 checks / 安全 93/100。⑨ **遗留登记（V37.8.9 候选）**：(a) MRD-LOG-STDERR-001：扫所有 shell 函数定义确认 log/debug/status 用 >&2 (b) MRD-LLM-PARSER-POSITIONAL-001：扫所有 Python heredoc 识别 `lines[i+N] / i+=N` 反模式 (c) 这两个 MRD 一旦落地就把 MR-11/MR-12 从"声明层"升级为"CI 可检测层"，符合 MR-6 ≥2 层验证深度要求。|
| V37.8.7 | 2026-04-15 | **ontology_sources 推送格式错位血案闭环（MR-4 第 8 次演出，同日双血案）** — ① **触发**：用户 WhatsApp 收到 ontology_sources 推送出现严重错位 — 第 2 篇 cn_title 显示为 `*---*`（分隔符被当成中文标题）、中文标题串到 highlight 槽、第 3 篇 cn_title 显示为 `*价值：⭐⭐⭐⭐*`（前一篇的"价值"行错位上来）。同一天 V37.8.6 修了 Dream 血案，下午又遇 ontology_sources 血案 — 双血案同源 MR-4 silent-failure。② **三层根因**：(a) **触发器**：LLM 偶尔漏一行（如第 2 篇缺"要点"）— Qwen3 的指令遵循训练让它倾向"提供有用输出"而非严格遵循三行格式 (b) **放大器**：原解析器 `run_ontology_sources.sh:300-313` 用严格位置 `lines[i], lines[i+1], lines[i+2]` + `i += 3` 步进 — LLM 漏一行后所有后续条目的 (cn_title, highlight, stars) 全部右移一格**级联污染** (c) **掩护者**：emit 端 `*{cn_title}*` 直接照 parse 结果输出，没有任何字段语义校验（如"cn_title 不应是 ---"、"cn_title 不应以'价值：'开头"）— 错位输出毫无 degraded 标记直接推送给用户。③ **结构修复**：(1) 抽到独立模块 `jobs/ontology_sources/ontology_parser.py`（纯函数 `parse_llm_blocks(content) -> list[(cn,hl,stars)]` 可单测，避开 V37.5 heredoc-only 不可测血案）。 (2) **separator 切块**：用 `re.split(r'(?:^\|\n)\s*[-=*_]{3,}\s*(?:\n\|$)', cleaned)` 按 `---/===/***` 等分隔符切块，单块缺行不影响其他块。 (3) **块内 key-based 解析**：按前缀（"中文标题：" / "标题：" / "要点：" / 含 "⭐"）识别字段而非依赖位置；缺字段留空字符串。 (4) **shell `export ONTOLOGY_JOBS_DIR=$JOB_DIR`** + heredoc `from ontology_parser import parse_llm_blocks`（heredoc 走 `python3 - <<EOF` stdin 不带脚本目录到 sys.path，需主动注入）。 (5) auto_deploy FILE_MAP 补齐 `ontology_parser.py`。④ **INV-ONTOLOGY-001 新增**（meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime]）7 checks：parse_llm_blocks 函数定义 + `_SEPARATOR_RE.split` 用法 + 块内 startswith('中文标题') key-based 识别 + shell `export ONTOLOGY_JOBS_DIR` + shell `from ontology_parser import parse_llm_blocks` + auto_deploy FILE_MAP 部署 + **runtime python_assert** 真跑用户 2026-04-15 实际看到的污染场景：构造"3 篇但第 2 篇缺要点"输入，断言 (a) 解析出 3 个 block (b) block 0 完整 (c) block 1 highlight 为空但其他正确 (d) block 2 完全不被 block 1 缺行影响 (e) 任何 cn_title 不含 `---` 或"价值"字样。⑤ **24 单测** `test_ontology_parser.py` 加入 full_regression：TestNormalCases(4) + **TestBloodLessonRegression(5)**（第 2 篇缺要点不级联 / 缺价值 / 缺标题 / 超额空行 / 连续分隔符）+ TestSeparatorVariants(5) + TestLLMOutputVariants(5) + TestShellScriptIntegration(4) + TestActualBloodLessonScenario(1) 端到端复现用户血案场景。⑥ **MR-4 第 8 次演出**：演出史 V37.3 → V37.4 → V37.4.3 → V37.5 → V37.6 → V37.7 → V37.8.6 → **V37.8.7 ontology_sources 位置解析**（同日双血案，证明 silent failure 在系统中持续以不同形态出现）。⑦ **元洞察**：V37.8.6 (Dream) + V37.8.7 (ontology_sources) 同日双血案揭示——**LLM 输出永远不能假设格式严格遵守**，所有 LLM 输出解析必须 (a) 容忍单条缺/多/重排 (b) 用语义键（如前缀/特征字符）而非位置定位 (c) 字段独立提取，不级联 (d) emit 前做最小语义校验（如"cn_title 不应是分隔符"）。⑧ **governance v3.12 → v3.13**：37→38 不变式（+INV-ONTOLOGY-001），175→182 检查。⑨ **全量回归**：34 suites / **1018 tests** / 0 fail / 38/38 invariants / 168/179 checks / 10/10 meta rules / 安全 93/100。⑩ **遗留登记**：(a) emit 端字段语义校验（"cn_title 不应是分隔符 / 不应以已知前缀开头"）作为 V37.8.8 候选 (b) 同模式审查其他 LLM 输出解析器（finance_news/dblp/hf_papers/semantic_scholar/freight_watcher 是否有类似位置解析）。|
| V37.8.6 | 2026-04-15 | **Dream 自引用幻觉血案闭环（MR-4 第 7 次演出 + 原则 #23 链式幻觉典型实证）** — ① **触发**：V37.8.5 Mac Mini E2E 同步后用户察觉 2026-04-15 03:00 Dream run 推送的"Hugging Face 平台危机"分析存在违和 — 信号一是"Papers with Code 沉默"但行动一却是"监控 Hugging Face"，主题断裂。日志里同时出现 4 次 `adapter.py:386 send_error(400, "Bad JSON")` 但 Dream 仍产出完整 6 章节推送。② **三层根因深挖**：(a) **触发器**：某个 source/note 抓取内容含 U+D800-U+DFFF 孤立 UTF-16 代理码点（smoke_test 已报 UnicodeEncodeError × 8）→ `llm_call` 内 `python3 -c` heredoc 的 `json.dump(body, f, ensure_ascii=False)` + 文件默认 utf-8 编码 → 孤立代理写入时 UnicodeEncodeError → body_file 截断为不完整 JSON → curl 上传破损 JSON 到 adapter :5001 → `adapter.py:383` json.loads 炸 JSONDecodeError → 返回 456 bytes HTML 错误页 "Bad JSON 400"。(b) **放大器（本次血案核心）**：`kb_dream.sh:109` 的 `log() { echo ...; }` 用 plain echo 写 stdout，而 Map 循环用 `signals=$(llm_call "$prompt" ... || true)` 命令替换捕获 stdout → log() 发出的 "LLM raw response: <HTML>Error code: 400 Bad JSON..." 错误日志全部被捕获进 `$signals` 变量 → `if [ -n "${signals// }" ]` 非空检查通过 → `echo "$signals" > "$cache_file"` 把错误日志写入 cache file。(c) **掩护者**：Reduce cache-only fast path (V37.4 Fix A) 读 `$MAP_DIR/2026-04-15_*.txt` 把错误日志作为"信号"注入 REDUCE_MATERIAL → LLM 看到 "Bad JSON 400" 字样后基于训练数据里"平台报错 + 用户在讨论分析"的分布，自动编造"某平台出了问题"的叙事 → 最高概率的 AI 平台 = Hugging Face → 输出虚假的"Hugging Face 平台危机"分析并经 WhatsApp+Discord 推送给用户 = 原则 #23 链式幻觉三跳累积（第 0 跳 adapter 错误 → 第 1 跳污染 cache → 第 2 跳 LLM 编造 → 第 3 跳推送用户）。③ **四层结构修复（defense-in-depth）**：(1) **log() 改写 stderr**：`log() { echo ... >&2; }` 阻断 stdout 污染 `$(...)` 命令替换的通道，四层中最根本的一层，一个 `>&2` 直接阻断整条幻觉链。(2) **heredoc 内嵌 `_sanitize(s)`**：U+D800-U+DFFF 孤立代理 → U+FFFD 替换字符，保持字符边界与 token 对齐，同时应用于 `prompt` 和 `system_msg`，防 json.dump 触发 UnicodeEncodeError。(3) **file open 双属性**：`open(..., encoding='utf-8', errors='replace')` 作为第二防线，万一 sanitize 漏网其他无效字节也能 replace 不炸裂。(4) **REDUCE/CHUNK1/2/3 system prompt 反污染守卫**：明示禁止把 HTTP 错误码/Python 异常/错误页 HTML/U+FFFD 连续片段/工具链名(curl/jq/grep) 当作外部信号，禁止基于这些字样推断 Hugging Face/GitHub/npm 等平台状态，禁止在行动建议中针对"平台错误"给建议。即使前三层全失效，LLM 也被明示约束。④ **INV-DREAM-003 新增**（meta_rule=MR-4, severity=critical, verification_layer=[declaration, runtime]，**首次登记即符合 MR-6 hard-enforcing ≥2 层要求**）16 checks：log() 源码模式 + V37.8.6 血案注释 + _sanitize 函数定义 + U+D800-U+DFFF 范围 + U+FFFD 替换 + 双字段应用 + errors='replace' + encoding='utf-8' + REDUCE_SYSTEM 反污染守卫 + Bad JSON 禁令 + Hugging Face/GitHub/npm 举例 + CHUNK1/2/3 各自反污染 + runtime python_assert 真跑 sanitize 五场景（孤立高位/低位代理/正常串/代理范围边界/sanitize 后 json+utf-8 编码不炸）。⑤ **19 单测** `test_dream_surrogate_sanitize.py` 加入 full_regression.sh 第一层：TestLogGoesToStderr(2) + TestSanitizeSurrogates(7) + TestShellSanitizeImplementation(5) + TestAntiPollutionSystemPrompt(3) + TestShellScriptIntegrity(1) + 含 negative-control "raw surrogate would crash json dump" 证明问题真实存在。⑥ **MR-4 第 7 次演出**（silent-failure-is-a-bug）：演出史 V37.3 governance summary 吞 error → V37.4 Dream Map budget → V37.4.3 PA 告警污染 → V37.5 kb_review 空 prompt → V37.6 KB dedup → V37.7 双跑审计 → **V37.8.6 Dream 自引用幻觉（迄今最隐蔽：错误不仅被掩盖，还被 LLM 加工成看似合理的业务分析再推送给用户）**。⑦ **原则 #23 典型实证**：本案例成为 CLAUDE.md 原则 #23 "LLM 链路中每一跳都会放大幻觉"的教科书级案例，未来引用可指向 `ontology/docs/cases/dream_self_referential_hallucination_case.md`（详细四维度因果链 + 三层根因 + LLM 合理化本能分析 + 四层防御逻辑 + 7 次 MR-4 演出对照表）。⑧ **潜伏态血案元洞察**：V37.1+ 四个条件（surrogate 累积 + log→stdout + `$(cmd)` 捕获 + cache 非空检查）一直存在，Dream 可能已经静默输出幻觉内容数天或数周而无人察觉，只有条件 5"LLM 编造被用户发现"首次触发才让血案浮现。⑨ **governance v3.11 → v3.12**：36→37 不变式（+INV-DREAM-003），159→175 检查。⑩ **全量回归**：33 suites / **994 tests** / 0 fail / 37/37 invariants / 161/172 checks / 10/10 meta rules / 安全 93/100。⑪ **遗留登记（下次迭代）**：(a) MR-11 候选 `shell-function-output-must-go-to-stderr-if-not-returned-value`（扫所有 shell 函数的 log/debug/status 输出）(b) 系统化 surrogate 清洗（爬虫/KB 写入源头先清洗，不只 LLM 边界）(c) LLM 输出 grounding allow-list（平台名/公司名必须在信号里出现才能提）(d) Dream 失败率可观测（Map 批次失败 > 阈值 → `[DEGRADED]` 标记或跳过推送）(e) 审计今日 pwc_daily / 其他 source 文件是否真的有 surrogate 字符。|
| V37.8.5 | 2026-04-15 | **僵尸检测边缘盲区闭合（V37.8.4 修复的修复，MR-10 第 2 次演出）** — ① **触发**：V37.8.4 收工 Mac Mini E2E 用户主动验证 finance_news 时，系统独立发现 SCMPNews 95/95 超窗口成功标记，但用户肉眼比对时发现同一 run 有两个边缘账号被漏标：**CNS1952 98/99 超窗口 + 1 过短**（严格 `old == total` 放过 99% 老化率）+ **SingTaoDaily 0-tweet stub**（`total > 0` 前置门槛直接排除空 HTML 骨架）。V37.8.4 作为"登记 unfinished"延后处理。② **MR-10 第 2 次演出**：V37.8.4 引入的检测器**本身**是 bug 源——第三问"最小修复"被浅化为"严格相等 + total>0 就够了"，但严格相等是所有 `old/total >= X` 的最窄特例，0-tweet stub 完全不在 `total > 0` 的论域。③ **结构修复**：(1) 把 heredoc 内嵌逻辑提炼为独立纯函数模块 `jobs/finance_news/finance_news_zombie.py`，签名 `classify_zombie(diag, count) -> (bool, tier)`，返回 `stub`/`stale`/`alive` 可区分 (2) Tier 1 "stub"：`no_data == 0 and total == 0` 闭合 SingTaoDaily (3) Tier 2+3 "stale"：`count == 0 and total > 0 and old * 10 >= total * 9`，整数比较避免浮点，阈值 9/10 编码为常量 `ZOMBIE_STALE_NUM/DEN`，CNS1952 98/99 触发 (4) `count == 0` 守卫防止"99% 老化但还产出 1 条新鲜"的低频活跃账号误报 (5) heredoc 改为 `from finance_news_zombie import classify_zombie`，禁止 inline fallback。④ **治理升级**：INV-X-001 `verification_layer` 从 `[declaration]` → `[declaration, runtime]`（主动遵循 MR-6 建议，即使 severity=high 不强制），新增 `python_assert` runtime check 真跑 5 个 tier 场景（Tier 1 stub / Tier 2 V37.8.4 原始 / Tier 3 CNS1952 / count 守卫 / no_data=1 false positive）。13 check → 20 check 净增 7（-1 旧严格谓词，+8 新检查含 import/call-with-count/env-export/模块存在/Tier 1/Tier 2+3/auto_deploy/runtime）。⑤ **24 单测** `test_finance_news_zombie.py` 加入 full_regression.sh 第一层：TestTier1Stub(3) + TestTier2Stale100(2) + TestTier3NearZombie(4) + TestCountGuard(3) + TestAliveAccounts(3) + TestConstants(2) + TestShellScriptIntegration(6) + TestAutoDeployMapping(1)。⑥ **MR-8 兑现**：`test_script_has_no_inline_zombie_fallback` 单测 grep shell 源码禁止 `def classify_zombie` 内嵌（防模块缺失时静默退回 V37.8.4 行为 = copy-paste-is-a-bug-class 反面）。⑦ **诊断可观测**：`⚠️ ZOMBIE嫌疑[stub]` / `⚠️ ZOMBIE嫌疑[stale]` 日志前缀 tier 可区分。⑧ **案例文档** `ontology/docs/cases/zombie_detection_edge_case_closure.md`（四维度因果链 + 三层根因 + 时间线 + 五条件组合分析 + MR-10/MR-6/MR-8/MR-4 四元规则兑现 + 本体喂养清单）。⑨ **auto_deploy FILE_MAP** 补齐 `jobs/finance_news/finance_news_zombie.py` 部署映射。⑩ **governance v3.10 → v3.11**：36 不变式不变（INV-X-001 升级非新增），152 → 159 检查。⑪ **全量回归**：32 suites / **975 tests** / 0 fail / 36/36 invariants / 145/156 checks（11 skip 运行时层）/ 10/10 meta rules / 安全 93/100。⑫ **VERSION** 文件 0.37.5 → 0.37.8.5（V37.5 后未同步的 rot 修复）。⑬ **元洞察**：血案二次演出证明"修复会埋坑"；登记 unfinished 是人类 TODO 不是 CI——原则 #28 理解再动手 + #29 收工零遗漏 两者缺一不可。|
| V37.8.4 | 2026-04-14 | **finance_news X 僵尸账号血案闭环 + INV-X-001 + 原则 #27 升级** — ① **触发**：V37.8.3 修改 3 个 X handle（CaixinGlobal→caixin, YicaiGlobal→yicaichina, STcom→straits_times）**上线第二天（V37.8.4 开工验证）发现三个改名后的 handle 全是僵尸账号**，Syndication API 返回最新推文分别是 2227/3364/420 天前。② **全量审计 22 账号** 7 个僵尸（~32% 污染率）：caixin 2227d/yicaichina 3364d/straits_times 420d/Reuters 253d/BrookingsInst 585d/WorldBank 2KB stub/ChannelNewsAsia 2955d。③ **Path C 最小修复 + 全量审计**：删 7 僵尸 → 剩 15 handle（IMFNews/business/WSJ/ReutersBiz/TheEconomist/XHNews/PDChina/CGTNOfficial/ChinaDaily/globaltimesnews/CNS1952/SCMPNews/NikkeiAsia/SingTaoDaily/asahi），依赖生产 cron 每天自然暴露剩余 14 个（429 限流绕过）。④ **静默失败检测**：`is_zombie_suspect = (diag["total"] > 0 and diag["old"] == diag["total"])` 写入 `cache/zombies_${DAY}.txt` + `⚠️ ZOMBIE嫌疑` 诊断前缀 + 3 天连续命中告警（macOS `date -v-Nd` / Linux `date -d 'N days ago'` 兼容 fallback）。⑤ **INV-X-001 新增**（meta_rule=MR-10, severity=high, verification_layer=[declaration]）13 checks：ZOMBIE_FILE 声明 + is_zombie_suspect 解析 + zombie_file append + ⚠️ 前缀 + `comm -12 - <\(sort -u "\$Y_FILE"\)` 3 天匹配 + 7 个 file_not_contains 守卫（禁止 Reuters/WorldBank/BrookingsInst/caixin/yicaichina/ChannelNewsAsia/straits_times 任一 handle 回归）+ CLAUDE.md "账号健康 ≠ HTTP 200" 声明。⑥ **CLAUDE.md 原则 #27 升级**：标题从"X/Twitter 是高质量实时数据的第一选择"变为"**X/Twitter 是高质量实时数据的第一选择（但账号健康 ≠ HTTP 200）**"，强制条款："账号健康必须通过最新推文时间戳验证（newest_tweet_dt > now - N 天），新增账号前必须先抽查最新推文时间，生产脚本必须对"抓到内容但 0 条过时间窗"的账号打 ZOMBIE 嫌疑标记，连续多天命中触发告警"。⑦ **MR-10 正向兑现**：V37.8.3 引入 MR-10 understand-before-fix 后**第二天就被违反**（第三问"最小修复"被浅层化为"改到字面上正确的 handle"而不是"改到可用信源"），V37.8.4 把违规事件本身固化为 case doc + INV-X-001 让下次改 X handle 必须先验证最新推文时间。⑧ **元洞察**：协议层绿灯 ≠ 内容层健康（本项目第 3 次：V37.4 Dream reduce cache bland 重复 → V37.5 kb_review 空 prompt → V37.8.4 X Syndication 僵尸快照）。⑨ **Mac Mini E2E 验证**：finance_news 手动运行 27 篇推送，系统自主发现 **SCMPNews** 为第 8 个僵尸嫌疑（95/95 条超 72h，ZOMBIE 嫌疑标记生效），zombies_2026-04-14.txt 写入 SCMPNews，等 3 天连续命中（2026-04-16 决策窗口）。⑩ **案例文档** `ontology/docs/cases/finance_news_syndication_zombie_case.md`（TL;DR + 完整因果链架构图 + 三层根因 + 时间线 + 五条件组合爆炸分析 + MR-10 正向兑现叙事）。⑪ **governance v3.9 → v3.10**：35→36 不变式，139→152 checks。⑫ **遗留登记**（3 项）：SCMPNews 3 天连续观察 / CNS1952 近僵尸检测阈值差距（98/99 被 strict equality 放过，需 ≥90% 阈值）/ SingTaoDaily 0 推文 stub 检测路径缺失（total=0 绕过 total>0 阈值）。⑬ **全量回归**：31 suites / 951 tests / 0 fail / 36/36 invariants / 138/149 checks / 10 meta rules / 安全 93/100。|
| V37.8.3 | 2026-04-13 | **连锁修复血案教训 + 方法论升级 + 运维修复** — ① **preflight 连锁修复闭环**：原始问题是 `~/auto_deploy.sh` HOME 副本未同步（只需 `cp`），被误诊为"缺少 FILE_MAP 配置"，触发 5 轮连锁修复（加 FILE_MAP 条目→双目标部署→SCRIPT_DIR HOME 检测→dict→list 解析器→job_smoke_test 同 fix），最终 preflight 77/0/4 + job_smoke_test 34/182/0/16 全部通过 ② **MR-10 understand-before-fix 新元规则**：修复前必答三问（之前存在吗/哪个改动引入的/最小修复是什么），连锁修复是最危险的系统破坏模式，governance v3.9→v3.10（10 元规则）③ **原则 #28 理解再动手**：禁止条件反射式修复 ④ **原则 #29 开工收工零遗漏**：清单逐项执行不允许"差不多就行" ⑤ **第 0 号宪法**：最强模型不降配不降速不妥协 ⑥ **finance_news X 账号修复**：CaixinGlobal→caixin, YicaiGlobal→yicaichina, STcom→straits_times ⑦ **Dream MIN_ACCEPTABLE_CHARS** 1500→3000 bytes + BEST_CHARS 未定义变量修复 ⑧ **kb_evening E2E 测试时区闪烁修复** ⑨ **案例文档** `ontology/docs/cases/preflight_cascading_fix_case.md` ⑩ **全量回归**：951 tests / 35/35 invariants / 125/125 checks / 10 meta rules / 安全 93/100 |
| V37.8.2 | 2026-04-12 | **finance_news 全球财经/政策新闻 job 上线 + 反幻觉修复 + 运维巩固** — ① **preflight 三修复**：(1) status.json 仓库 vs 运行时合法分叉豁免（仓库快照 vs cron 每小时刷新）(2) KB 索引阈值从 count-based（<=5 stale）改为 percentage-based（>=90% 覆盖率 = WARN，<90% = FAIL），33 cron 日产 15 新 notes + 21 modified sources 导致假 FAIL (3) MRD-NOTIFY-002 activity 层假阳性根治：`_discover_silent_channels()` 重写为 TOPIC_JOB_MAP 映射 + registry-driven job log mtime 检测，替代原 grep `--topic` 字符串（28/32 job bypass notify.sh 永不产生该字符串）② **kb_evening/kb_review LLM 反幻觉约束**：两个 prompt builder 加入 `⚠️ 严格约束（违反则整份输出作废）`——只使用明确出现的信息 / 每条标注来源标签 / 严禁虚构发布公告+开源事件+人物言论 / 无数据跳过不编造。触发：evening digest 编造"OpenClaw 开源发布 openclaw-model-bridge"（私有仓库从未公开发布）③ **finance_news 全新 job**：双通道 8 RSS 直连（Fed/NBER/FT/ECB/BIS/Yahoo/SCMP/36Kr）+ 21 X/Twitter Syndication API（7 国际：Reuters/IMFNews/WorldBank/BrookingsInst/Bloomberg/WSJ/ReutersBiz + 14 亚太：XHNews/PDChina/CGTNOfficial/ChinaDaily/globaltimesnews/CNS1952/CaixinGlobal/YicaiGlobal/SCMPNews/NikkeiAsia/SingTaoDaily/ChannelNewsAsia/STcom/asahi）。72h 时间窗口覆盖周末 + 按天自动重置 seen 缓存 + LLM 结构化分析（价值⭐评级/国内外对比/投资建议/风险提示）+ KB 归档 + Discord+WhatsApp 推送。诊断模式：0 条账号打印过滤原因（纯RT/过短/已见/超窗口/无数据）。Mac Mini 验证：32 篇（16 国际 + 16 国内），0 源失败 ④ **CLAUDE.md 原则 #27**：X/Twitter 是高质量实时数据的第一选择——Syndication API 无需认证/零成本/100% 成功率 vs RSSHub 公共实例 100% 失败率 ⑤ **auto_deploy FILE_MAP** 补齐 finance_news 部署映射 ⑥ **全量回归**：930 tests / 35/35 invariants / 125/125 checks / 9/9 meta rules / 安全评分 93/100 |
| V37.8 | 2026-04-11 | **MR-6 深度补齐 + MRD-NOTIFY-002 语义修复（治理自观察第二轮：治理深度从"建议"升级为"硬强制"）** — ① **触发**：V37.7 双跑审计后 `governance_checker --full` 的 Phase 0 MRD 段持续报 4 个 warning，其中 `MRD-LAYER-001` 发现 **7 个 critical 不变式只有单层验证**（MR-6 "critical-invariants-need-depth" 被静默违反），`MRD-NOTIFY-002` 报 6 个 Discord 频道有 4 个"7 天无活动"但 Mac Mini 实际每天都在推送 — 即**检测器假阳性 + 治理元规则未被强制**双重漏洞。② **MR-6 深度补齐 7 个 critical 单层不变式**：(1) **INV-TOOL-001 tool-count-limit**：原 python_assert 实际跑 filter_tools() 是运行时，但 verification_layer 错标 `[declaration]` — 新增 `file_contains` 声明层 check (proxy_filters.py 静态引用 MAX_TOOLS) + 修正标签为 `[declaration, runtime]` (2) **INV-TOOL-002 max-tools-config-imported**：已有 file_contains + python_assert 双层但 verification_layer 错标 — 纯元数据修复 (3) **INV-DEPLOY-002 auto-deploy-never-modifies-crontab**：原单层静态文本扫描 — 新增 `shlex.shlex(posix=True)` AST-tokenize 运行时 check 遍历 auto_deploy.sh 拆出 token 序列检测 `crontab -e/-i/-r/-` 或 `crontab_safe.sh add/remove/set/replace` 危险组合 (4) **INV-CRON-003 bash-lc-enforcement**：原单层运行时 (--full 模式 crontab -l 解析) 在 dev 环境完全 skip — 新增 `file_contains` 声明层守卫 V37.2+ 的 `_cron_cmd_invokes` 精确匹配器 + `cmd.endswith(entry)` 词边界模式，防止未来重构回退到子串匹配 (5) **INV-ENV-002 cron-env-smoke-test**：原单层运行时 (bash -lc 读 OPENCLAW_PHONE) dev 环境 skip — 新增声明层 2 个 check：preflight_check.sh `REQUIRED_VARS=(...)` 数组必含 `OPENCLAW_PHONE` (regex 提取数组字面量) + YAML 源码必须保留占位号 `+85200000000` 字面量作为 runtime 比较的反例守卫 (6) **INV-DREAM-002 reduce-path-must-not-re-run-map-loops**：原三 file_contains 声明层可证 `SKIP_MAP_LOOPS=true` 字面量和门控存在，但无法证明**门控在循环之前生效** — 新增运行时顺序锁 python_assert 读 kb_dream.sh 行号断言 `SKIP_MAP_LOOPS=true` 赋值 `assign_line < gate_1a_line` 且 `< gate_1b_line`，防止重构把赋值移到循环之后的回归 (7) **INV-CACHE-002 notes-cache-key-stable-under-mtime-drift**：原四 file_contains 只能证明字面量存在，无法证明"同内容不同 mtime 真的产生相同 hash" — 新增运行时 python_assert 用 `tempfile.TemporaryDirectory` 构造 3 个文件 (p1/p2 同内容不同 mtime, p3 不同内容)，`os.utime` 人为分离时间戳模拟 mm_index/kb_embed 触碰，inline `hashlib.md5(content).hexdigest()[:12]` 断言 `h1==h2` 且 `h1!=h3`。**注意**：`hashlib.md5` 调用必须 inline，**不能** 包成 `def _content_hash(s): ...` 嵌套函数——exec() 作用域陷阱下嵌套 def 看不到 exec locals 的 import（第一次运行因此 NameError）。③ **INV-LAYER-001 新增 (自我强制 meta-invariant)**：`critical-invariants-have-two-layers`, meta_rule=MR-6, severity=critical, verification_layer=[declaration, runtime]，把 MRD-LAYER-001 的 `severity_when_missing: warn` 升级为 fail-stopping hard invariant —— python_assert 遍历自身 YAML，任何 `severity=="critical"` 但 `len(verification_layer) < 2` 的不变式都让 governance_checker 直接 `exit 1`，未来任何新增 critical 不变式只要少于 2 层就被 CI 拦截。④ **MRD-NOTIFY-002 检测器重写 (根治假阳性)**：原 `_discover_silent_channels()` 只 grep `~/*.log` 里的 `--topic X` 字符串，但 32 个 job 中**只有 4 个用 notify.sh** (arxiv/dblp/semantic_scholar/ontology_sources)，其余 28 个直接 `openclaw message send --channel-id "$DISCORD_CH_X"` bypass notify.sh 永不产生 `--topic` 字样 → ontology/tech/freight 等频道误报 silent。重写为两层检测：**source layer** (dev + full 都跑，扫 `jobs/*/run_*.sh` + `*.sh`，每个 topic 的 caller 可以是 `--topic T` 或 `DISCORD_CH_<T_upper>` 任一形式) + **activity layer** (仅 --full 且 `~/.kb` 存在，用 `notify_queue/*.json` 和 `jobs/*/cache/*.log` 的 **mtime** 而非字符串 grep；只对"源码有 caller 但运行时静默"的 topic 报警)。⑤ **governance_ontology.yaml v3.8 → v3.9**：34→35 不变式 (+INV-LAYER-001)，126→139 检查 (+10: TOOL-001/DEPLOY-002/DREAM-002/CACHE-002 各 +1, CRON-003/ENV-002 各 +2, LAYER-001 +2)，9 meta rules 不变。⑥ **全量回归**：31 suites / **927 tests** / 0 fail / 35/35 invariants / 125/125 checks in dev (136 total, 11 skip runtime-only) / **9/9 meta rules** (从 V37.7 的 8/9 提升) / MRD-LAYER-001 **✅ "所有 15 个 critical 不变式都有 ≥2 层验证深度"** / MRD-NOTIFY-002 **✅ "所有 6 个频道均有 source-layer caller"** / 安全评分 93/100。⑦ **血案元规则兑现**：V37.8 是 MR-7 (governance-execution-is-self-observable) 的第二轮兑现 — V37.3 MR-7 首次引入 + INV-GOV-001 修复 summary 吞 error；V37.8 把 MR-6 从"警告层"提升为"强制层"，同时修复检测器本身的假阳性 (MRD-NOTIFY-002)。治理系统真正做到"不仅治理别人，也治理自己"。 |
| V37.7 | 2026-04-11 | **双跑审计闭环 — 三合一修复 + MR-8/MR-9 元规则形式化（MR-4 第 4/5 次演出 + 元规则预防层首次加入）** — ① **Bucket 1 (P0) `run_discussions.sh` V37.6 第 16 处漏网** (`jobs/openclaw_official/run_discussions.sh:104`)：V37.6 migration 14 个 cron 到 `kb_append_source.sh` helper 时漏掉 discussions（4×/天 08:15/12:15/16:15/20:15 的直接 `>> "$KB_SRC"` append），MR-4 silent-failure 第 5 次演出。修复删除 loop 内直写 + post-loop 走 helper + **`SLOT_TAG="$(date +%H:%M)"`** 区分同日多 run 避免 H2 section dedup 误吞第二次。② **Bucket 2A `audit_log.verify_chain` JSON parse error prev_hash 级联 bug**：V37.6 verify_chain 在 JSON parse 失败时**未更新 `prev_hash`** → 单行损坏后所有下游有效行都被误报为 prev-mismatch。修复改 `prev_hash: "str \| None"`，parse error 时置 None + 下行跳过 prev 指针检查（仍独立验证自身 hash），首个有效 hash 后重新续链。③ **Bucket 2B `kb_dedup.find_duplicate_notes` dangling index refs 假重复**：V37.6 find_duplicate_notes 把"index 有 entry 但磁盘无文件"的孤儿条目当作正常 entry → 按 summary 分组 → 和健在兄弟被误判为重复 → `--apply` 时删掉**活着**的兄弟文件（因为 dangling 排第一个被 kept，健在文件被 removed），MR-4 第 4 次演出。修复 (a) 新增 `find_dangling_index_entries(index)` 独立 reporter (b) `find_duplicate_notes` 内部 V37.7 pre-filter 用 `os.path.exists()` 剔除 dangling refs 后再分组 (c) `main()` 在 `--apply` 时把 dangling 从 `index.entries` 直接移除（**不**动磁盘文件），dry-run 时打印 warning。④ **Bucket 2C `kb_evening_collect` label semantics 修复**：V37.6 WA header `今日笔记 298 篇` 把 `note_count`（`rc.read_index_stats` 返回的**历史累计**笔记总数）错标为"今日"——evening 报告整个定位就是"今日"但数字是 298 天累计。修复新增 `import glob` + `count_today_notes(kb_dir, today)` 扫 `notes/` 前缀匹配 `YYYYMMDD` 的 .md 文件 + `build_evening_prompt/markdown/wa_message` 全部加 `today_note_count` 参数（分列"笔记总数 298"和"今日新增 5"），evening.sh wrapper 同步提取 `TODAY_NOTE_COUNT` 并打印到日志。⑤ **Bucket 3A MR-8 `copy-paste-is-a-bug-class` 从 candidate 正式形式化**：V37.6 changelog 提过 MR-8 candidate 但从未进入 `meta_rules:` 段——V37.7 正式加入，description 阐述"跨模块复制相似逻辑 = 引入 bug 类"+ "正确做法是提取公共原语为 import 模块 + 差异注入扩展"+ "正向兑现 = V37.6 `kb_evening_collect` 通过 `import kb_review_collect as rc` 复用 5 个原语 + 只覆写 evening-specific 行为"，INV-EVENING-001 从 MR-4 重归属到 MR-8。⑥ **Bucket 3B MR-9 `state-writes-go-through-helper-not-raw-redirect` 新增元规则**：把"shell `>>` 直写持久化 state 文件必须走 helper"从"14 个 caller 都要记得"的纪律问题升级为"ontology 架构硬规则"，包含 enforcement (INV-SRC-001 声明 scan + 运行时 15 job 校验) + derivative_invariants [INV-SRC-001, INV-DEDUP-001, INV-DEDUP-002] + blood_lessons（438 行 sources 污染 + run_discussions 第 16 处漏网），MR-9 是 MR-4 silent-failure 的**上游预防层**——让 CI/governance 自动拦截而不是靠程序员记忆。INV-SRC-001 从 MR-4 重归属到 MR-9。⑦ **INV-GOV-001 check 2 去 global mutation 重构**：V37.6 把 `governance_checker.JSON_MODE` 全局变量 save/mutate/restore 来注入 fake 状态测 summary——MR-8 的反面例子"靠 global state 做 dependency injection"。修复 `print_results(results, json_mode=None)` 加显式参数（None 时 fallback 到 module-level global 保持向后兼容），INV-GOV-001 check 2 改为 `print_results(fake_results, json_mode=False)` 直接注入。⑧ **INV-SRC-001 catch-all scan 加固 (Bucket 1)**：新增 2 个运行时 check — `V37.7 全量扫描 jobs/**/*.sh 不得有任何 >> "$KB_SRC" 直写`（catches 任何位置，不限 loop-tail）+ `V37.7 catch-all 任何 >> .*sources/.*\\.md 路径必须通过 helper`（路径级 regex，future-proof 对抗新增 sources 变量名）+ job_sites 列表扩到 15 job（加入 run_discussions.sh 的 1 处写入点）。⑨ **INV-DEDUP-002 新增不变式** `kb-dedup-pre-filters-dangling-index-entries`（meta_rule=MR-4, verification_layer=[declaration, runtime], severity=high）4 个 check：声明层 grep `def find_dangling_index_entries` + `V37.7` 注释标记；运行时层 2 个 python_assert 用 tempfile 隔离 KB_BASE/NOTES_DIR/SOURCES_DIR/INDEX_FILE/REPORT_JSON — (a) 构造 2 entries 同 summary 一死一活，assert exact_dupes=0 + dangling=1 (b) 端到端 main `--apply` 路径测 monkey-patched `sys.argv`，assert dangling 从 index 移除且健在文件仍存在。⑩ **governance_checker.py meta_rules counter 动态化**：原硬编码 `元规则: {len(mr_used)}/6`，V37.7 改为 `_load().get("audit_metadata",{}).get("meta_rules", len(mr_used))`，跟随 audit_metadata 自动刷新。⑪ **governance_ontology.yaml v3.7 → v3.8**：33→34 不变式，119→126 checks，7→9 meta rules，v3.8 changelog 记录 8 项闭环。⑫ **新增 12 单测**：test_kb_dedup.py `TestDanglingIndexRefs` 4 测试 (find_dangling / no-dangling when all exist / dangling not reported as duplicate / apply cleans dangling from index) + test_audit_log.py `test_json_parse_error_does_not_cascade` 1 测试（parse error 1 行，line 3 不被 prev-mismatch 误报）+ test_kb_evening.py 更新 `TestBuildEveningPrompt/Markdown/WaMessage` 3 类测试到新签名 + 新增 `TestCountTodayNotes` 3 测试 + `test_markdown_distinguishes_total_vs_today_counts` + `test_header_distinguishes_total_vs_today`。⑬ **`full_regression.sh` 接入 test_kb_evening.py**（V37.6 新增但从未登记）。⑭ **全量回归**：31 suites / **927 tests** / 0 fail / 34/34 invariants / 115/126 checks / 8/9 meta rules / 安全评分 93/100 |
| V37.6 | 2026-04-11 | **数据层 P0 三合一修复 + P1 kb_evening 架构对齐（MR-4 第三次演出 + MR-8 正向兑现）** — ① **P0-1 Content-blocks repr bug**：`proxy_filters.extract_user_text()` 把 OpenAI content blocks 列表直接 `str()` 成 `[{'type': 'text', 'text': '...'}]` 字面量被当"用户输入"写进 KB，发现于 kb_dedup dry-run 报告。引入 `flatten_content(content)` 只提取 text 字段，tool_proxy.py 对话捕获路径同步调用。② **P0-2 sources H2 repeat-append**：14 个 RSS/cron 抓取 job 各自独立 `>> sources/*.md` 把同一天数据追加多次，滚动窗口同条目在 `## $DAY` 下重复出现 N 次。新增 `kb_append_source.sh` helper（`$SLOT_TAG` 支持多 run/day 如 ontology_sources 10:00/20:00），14 个 job 全部迁移。③ **P0-3 kb_dedup.py 二次演出**：(a) file-level `seen` 集合把跨 H2 section 的合法日期复现误判为 duplicate 并在 `--apply` 时删除历史 (b) `find_duplicate_notes` 只扫 `index.json`，漏掉未索引的 `notes/` 孤儿。修复：`seen` 在每个 `## ` H2 边界重置；find_duplicate_notes 改为扫 NOTES_DIR 目录。④ **P1 kb_evening 架构对齐**：原 kb_evening.sh 用"文件名前 80 字"作假摘要 + 硬编码 7 源枚举 + 零 LLM 智能 + 无 fail-fast。新建 `kb_evening_collect.py` via `import kb_review_collect as rc` **复用**所有采集原语（load_sources_from_registry/extract_recent_sections H2 drill-down/collect_notes/collect_sources/call_llm），只覆写三件事：①DAYS 默认 1（今日窗口）②build_evening_prompt 改为"今日要闻/一条行动/明日关注/健康度"行动导向结构 ③build_evening_wa_message 🌙 emoji。kb_evening.sh 重写为 thin wrapper 遵循 V37.5 kb_review.sh 同款模式（fail-fast + [SYSTEM_ALERT] + env var heredoc 无 stdin 冲突 + 保留 kb_dedup 健康附注拼接 + 日志轮转）。⑤ **auto_deploy FILE_MAP 补齐 V37.5 部署缺口**：kb_review_collect.py 在 V37.5 发布时**从未被加入 FILE_MAP**（能跑纯靠 auto_deploy 的 git pull + kb_review.sh 的 $HOME/openclaw-model-bridge/ fallback 路径），V37.6 一并补齐 `kb_dedup.py` / `kb_review_collect.py` / `kb_evening_collect.py` 三个 Python 模块。⑥ **INV-EVENING-001** `kb-evening-fails-loud-not-silent`（meta_rule=MR-4, severity=high, verification_layer=[declaration, runtime]）17 个 check：reuse 契约（import kb_review_collect + 禁止 load_sources_from_registry/extract_recent_sections/call_llm 重定义）+ thin wrapper 契约（V37.6 标记/[SYSTEM_ALERT]/不含 review_${DATE}.md 粒度错配）+ FILE_MAP 部署契约 + 反模式 python_assert 行扫 `\| python3 -`（regex 精确区分 `python3 -c 'inline'` 安全形式）+ fail-fast 顺序锁（llm_failed 分支 500 字符内必须 exit 1）+ 运行时 DAYS=1 过滤验证（直接调 `rc.collect_notes` 避免 V37.2+ exec() 闭包陷阱）+ mock_fail 不伪造产物契约。⑦ **新增 31 单测** `test_kb_evening.py`（8 类）：TestReusesKbReviewHelpers(3) + TestOneDayWindow(2) + TestBuildEveningPrompt(4) + TestBuildEveningMarkdown(4) + TestBuildEveningWaMessage(3) + TestRunOrchestrator(4) + TestKbEveningShellGuards(10) + TestKbEveningShellRuntime(1，真 subprocess + stub collector E2E）。⑧ **test_kb_dedup.py 陈旧测试同步**：原测试把跨 H2 section 的同一行视为 duplicate，V37.6 H2-scoped 后这是合法的滚动窗口复现，更新 2 个 test case（test_duplicate_lines/test_apply_source_dedup）改为 section 内重复。⑨ **governance v3.5.1 → v3.7**：32→33 不变式，102→119 checks（新增 INV-KB-001/INV-SRC-001/INV-DEDUP-001/INV-EVENING-001 四个不变式 17 checks）。⑩ **案例文档** `ontology/docs/cases/kb_content_and_sources_dedup_case.md` 记录 MR-4 第三次演出（P0）+ MR-8 候选"copy-paste-is-a-bug-class"正向兑现（P1 via import reuse）。⑪ **全量回归**：30 suites / **886 tests** / 0 fail / 33/33 invariants / 108/119 checks / 安全评分 93/100 |
| V37.5.1 | 2026-04-11 | **kb_review.sh `pipe+heredoc` stdin 冲突热修复（V37.5 第一次 Mac Mini E2E 即触发的子血案）** — ① **触发**：V37.5 commit db6136f 推送后 Mac Mini 首次 `bash ~/kb_review.sh` 即崩溃 → `File "<stdin>", line 3, in <module>` → `json.JSONDecodeError: Expecting value: line 1 column 1 (char 0)`（stdin 读到空串） ② **根因**（经典 shell 反模式）：`echo "$COLLECTOR_OUTPUT" \| python3 - "$REVIEW_FILE" << 'PYEOF' ... json.load(sys.stdin) ... PYEOF` — pipe 把 JSON 喂进 `python3` 的 stdin，heredoc **同时**把代码喂进同一 stdin；`python3 -` 优先消费 heredoc 作为代码源，pipe 的 JSON 被丢弃，`json.load(sys.stdin)` 读到空串直接炸 ③ **为什么 V37.5 的 44 单测 + 14 governance checks 全过却漏掉**：测试全部是声明层 grep guard（文件包含 `fail-fast`、包含 `[SYSTEM_ALERT]`、包含 H2 parser 函数…），**从未真正 `subprocess.run()` 跑一次 shell 脚本** → 直接喂养 **MR-6 (grep 守卫不足，验证深度必须包含运行时层)** ④ **三层修复**：(1) **代码层** `kb_review.sh:154-163`：删除 `echo ... \| python3 - << PYEOF` 反模式，改用 `COLLECTOR_OUTPUT="$COLLECTOR_OUTPUT" REVIEW_FILE="$REVIEW_FILE" python3 << 'PYEOF'` 环境变量模式 — heredoc 只承载代码，零 stdin 竞争 (2) **治理层** `INV-REVIEW-001` +2 checks：`V37.5.1 反模式` python_assert 行扫禁止 `\| python3 -`（跳过 `#` 注释以允许文档引用反模式）+ `V37.5.1 runtime` python_assert **真实 `subprocess.run()`** 跑 kb_review.sh（mock collector 喂 canned JSON，断言 review 文件落盘 + stderr 不含 `JSONDecodeError`）(3) **测试层** `test_kb_review.py` +4 单测（44→48）：`test_no_pipe_heredoc_stdin_collision`（静态守卫）+ `TestKbReviewShellRuntime` 新类 3 测试：`test_env_var_heredoc_pattern_writes_file`（正向隔离验证）+ `test_pipe_heredoc_antipattern_actually_fails`（负向反证 JSONDecodeError）+ `test_kb_review_sh_end_to_end_mock_collector`（真 E2E subprocess + 临时目录 + mock collector） ⑤ **Mac Mini 生产 E2E 验证通过**：`bash ~/kb_review.sh` → `开始 LLM 深度分析（7 天回顾，from registry）... 回顾文件已生成: /Users/bisdom/.kb/daily/review_20260411.md ... 回顾已推送（WhatsApp + Discord #daily） ... 知识回顾 20260411 \| 覆盖 12 源 \| 本期笔记 299 篇 \| LLM: ✓` — 验证了 (a) registry-driven 发现 12 源（governance 断言 `>=12` ✓）(b) H2 drill-down 从 7 天窗口提取 299 notes (c) LLM 调用成功未触发 fail-fast (d) V37.5.1 env var 模式写入 review 文件零 JSONDecodeError (e) notify.sh 双通道推送 WhatsApp + Discord #daily 成功 ⑥ **governance_ontology.yaml v3.5 → v3.5.1**（29 不变式不变，81→83 checks）⑦ **血案元认知**：同一个 MR-4 血案类三天内第二次演出（V37.5 主血案 → V37.5.1 子血案），子血案证明**主血案修复本身也可能埋坑**，`test_kb_review.py::TestKbReviewShellGuards` 全部 grep 通过但从未运行脚本 → MR-6 不再是"建议"而是"基础假设" |
| V37.5 | 2026-04-11 | **kb_review 6-issue silent degradation 血案闭环修复（fail-fast + registry-driven + H2 drill-down）** — ① **血案类归属**：与 V37.4.3 PA 告警污染同属 MR-4 (silent failure is a bug) 效果层静默降级血案类——声明层检查全过、status.json 全绿，但端到端效果完全失效 ② **6 个相互掩护的 bug**：(1) shell `export NOTES_CONTENT` 在 `python3 -c` 子进程调用**之后**才写入 → subprocess fork 时 env 快照已定型，`os.environ.get()` 永远拿空字符串 → LLM 收到空壳 prompt (2) 硬编码源枚举 7 项，漏掉 V37 新增 `ai_leaders_x` + V37.1 新增 `ontology_sources` (3) LLM 失败后**机械 fallback** 把"行级日期匹配"的容器标题残渣（例如 `## 今日arXiv精选(2026-04-10)`）直接写入 review 文件伪装成功 (4) `status.json` 永远硬写 `"llm": true`，不区分 ok/failed (5) 行级日期匹配只保留含日期的单行，把整个 H2 section 的论文 body 全部过滤掉 — 结构化 markdown 粒度错配 (6) 悬空承诺"回复任何话题可深入讨论"但 LLM 从未真正看过回顾内容 ③ **结构性修复**：(1) **全 Python 化** `kb_review_collect.py` 作为纯模块（load_sources_from_registry + extract_recent_sections H2 drill-down + call_llm 80-char 最小阈值 + run(llm_caller=...) 可注入 mock），消除 shell scope bug class (2) **jobs_registry.yaml 扩展 `kb_source_file` + `kb_source_label` 字段到 12 个 enabled source-producing job**（arxiv/hf_papers/semantic_scholar/dblp/acl_anthology/github_trending/rss_blogs/ai_leaders_x/freight/openclaw_run/hn/ontology_sources），registry-driven 消除硬编码漂移 (3) **kb_review.sh 重写为 thin wrapper**：调用 collector 后按 status 分派 — `ok` 写 review 文件 + 推送 daily topic，`llm_failed`/`collector_failed`/`send_failed` 均推送 `[SYSTEM_ALERT]` + `exit 1` fail-fast (4) status.json 诚实字段 `llm_status: ok\|failed\|unknown`，不再永远写 true (5) 移除悬空 follow-up 承诺 ④ **INV-REVIEW-001** `kb-review-fails-loud-not-silent`（severity=critical, verification_layer=[declaration, runtime]）：14 个 check 覆盖声明层（V37.5 版本标记/`[SYSTEM_ALERT]` 存在/不含机械 fallback/不含悬空承诺/三个核心函数定义/jobs_registry.yaml kb_source_file 字段/**fail-fast 顺序锁 python_assert**（llm_failed 分支 500 字符内必须 exit 1））+ 运行时层（**registry 真实发现 >=12 源含 ai_leaders_x + ontology_sources**/**H2 parser drill-down 过滤正确性**（窗口内 Paper A 保留 + 窗口外 Paper B 剔除 + 今日 Paper C 保留）/**mock LLM 失败契约**（status=llm_failed 不伪装 ok + 不产出 review_markdown/wa_message 伪造产物）/call_llm 最小内容阈值声明） ⑤ **新增 44 单测** `test_kb_review.py`：TestLoadSourcesFromRegistry(7) + TestExtractRecentSections(8) + TestCollectNotes(4) + TestCallLlm(6, urlopen mock) + TestRunOrchestrator(6, llm_caller 注入) + TestBuildOutputs(4) + TestCollectSources(1) + TestKbReviewShellGuards(8) ⑥ **案例文档** `ontology/docs/cases/kb_review_silent_degradation_case.md`（四维度完整因果链架构图 + 三层根因 + 时间线还原 + 6-bug 条件组合分析 + V37.4.3 血案类对照表 + MR-4 持续扩展 + 元规则 MR-8 候选"跨文件枚举必须声明单一真理源"） ⑦ **governance_ontology.yaml v3.4 → v3.5**（28→29 不变式，67→81 checks） ⑧ 接入 full_regression.sh 第一层 |
| V37.4.3 | 2026-04-11 | **PA 告警污染血案闭环修复（A+C 双防线）** — ① **事件**：13:06 用户问"AI Agent 终极架构：本体×随机×贝叶斯"，PA 回复"已收到系统告警跟进任务，请打开系统偏好设置添加 /usr/sbin/cron 到完全磁盘访问权限"——完全答非所问 + 编造错误的 macOS FDA 指令（launchd 管理的 cron 从不需要 FDA）② **根因六层深挖**：(a) 12:30 job_watchdog 通过 `notify.sh --topic alerts` 推送 WARNING (b) Gateway 把推送写入 `sessions.json` 作为 `assistant` role 消息——**不区分"PA 主动回答"和"系统告警推送"** (c) Proxy `truncate_messages()` 保留"最近 N 条"，36 min 内的告警仍在窗口内 (d) Qwen3 attention 读到 assistant 告警中的 "排查建议" + "cron_doctor.sh"，把它当"PA 自己说过的话" (e) 用户新问题被跨主题错误关联为"告警跟进响应" (f) LLM 编造 macOS FDA 指令（training data 模板填空）③ **Path A 结构性隔离**（主防线）：(1) 推送侧注入标记——`notify.sh` 在 `topic=alerts` 分支、`auto_deploy.sh` 在 `quiet_alert()`、`run_hn_fixed.sh`/`jobs/openclaw_official/run.sh`/`run_discussions.sh` 的直接 send 路径，统一在告警消息首行加 `[SYSTEM_ALERT]`  (2) 消费侧剥离——`proxy_filters.py` 新增 `SYSTEM_ALERT_MARKER = "[SYSTEM_ALERT]"` 常量、`filter_system_alerts(messages, log_fn)` 函数（str content + OpenAI content blocks 双格式支持，system role 保留例外，`_message_starts_with_alert_marker` 只在首行匹配避免误伤）(3) **顺序硬约束**——`tool_proxy.py` 在 `truncate_messages()` **之前**调用 `filter_system_alerts()`（单测 `test_integration_with_truncate` + INV-PA-001 的 python_assert 检查源码中位置 `filter_idx < trunc_idx`，双重锁定）④ **Path C 治理+行为双防线**：(1) **SOUL.md 规则 10 "告警消息不跟进（2026-04-11 血案规则）"**——最高优先级的问答对齐规则，包含：识别标志（`[SYSTEM_ALERT]` + 告警模式）、禁止行为（已收到跟进/系统偏好指令/编造 macOS FDA）、**主题对齐硬规则**（回复必须与用户最新消息主题直接对齐）、幻觉防线（launchd 不需要 FDA）、13:06 案例警示原文 (2) **INV-PA-001** `alert-does-not-pollute-chat-context`（severity=critical, verification_layer=[declaration, runtime]）：10 个 check 覆盖 SYSTEM_ALERT_MARKER 定义 + filter_system_alerts 函数 + tool_proxy 导入 + **顺序锁 python_assert**（filter_idx < trunc_idx）+ 5 个推送脚本标记注入 + **运行时 python_assert**（真实告警消息注入 → filter 正确剥离，4 个 sub-assertion：普通 assistant 告警剥离/system role 保留/OpenAI content blocks/标记只在开头匹配不误伤）(3) **INV-PA-002** `soul-rule-10-present`（severity=high, verification_layer=[declaration]）：5 个 check 确保 SOUL.md 包含规则 10 核心声明（"告警消息不跟进" / "2026-04-11 血案规则" / "主题对齐" / "完全磁盘访问权限" / `[SYSTEM_ALERT]`）⑤ **案例文档** `ontology/docs/cases/pa_alert_contamination_case.md`（六层根因深挖 + 完整因果链架构图 + 时间线 + **六条件组合爆炸分析**：告警频率/时间差/可执行触发词/话题跳变/SOUL 无隔离规则/Proxy 无剥离——六个条件同时出现才爆炸 + 纵深防御论证）⑥ **新增 21 单测**：`TestFilterSystemAlerts`（14 个：marker 常量/assistant 剥离/user 剥离/system 保留/content blocks/leading whitespace/空消息/缺失 content/log_fn 调用/truncate 集成/多告警全剥离等）+ `TestNotifyShAlertMarker`（5 个：notify.sh/auto_deploy/run_hn_fixed/run_discussions/run.sh grep）+ `TestToolProxyImportsAlertFilter`（2 个：import + 顺序）⑦ **governance_ontology.yaml v3.3 → v3.4**（26→28 不变式，52→67 checks）⑧ **全量回归**：29 suites / **807 tests** / 0 fail / 28/28 invariants / 56/67 checks / 安全评分 93/100 |
| V37.4.2 | 2026-04-11 | **Dream Reduce 短输出 bug 二段闭环修复** — ① 触发：V37.4.1 Mac Mini 14:01 run 三次重试全是 876/876/927 chars，完全一致的失败输出 → 定位根因是 Qwen3 server-side prompt caching + 缓存读取路径 bland 重复 header 让 LLM 陷入"简短总结"收敛模式 ② **结构化修复**（cache-only 读取路径 line 414-465）：用 bash 数组 `UNIQ_NOTE_SIG_BLOCKS=()` 收集去重后的 signal blocks → 拼接带覆盖统计的 meta header（`> 覆盖 N 条用户笔记，提取出 M 个独立信号簇`）→ 每簇编号 `### 笔记信号簇 i / N` 赋予独立身份；Phase 1b cache-hit header 同步改为 `## 用户笔记缓存命中: $name`（用文件名区分）③ **重试变体修复**（line 1011-1024）：retry=1 用原 `REDUCE_PROMPT`，retry≥2 prepend `【第 N 次尝试 — 上一次响应过短，不合格】` + 显式硬性要求"6 章节全覆盖 + 不少于 2500 汉字"，变体 prompt prefix 改变 hash 直接绕过任何 server cache + 显式长度约束顶破收敛 ④ 新增 6 单测 `TestV37_4_2_CacheReadStructureAndRetryVariation`（UNIQ_NOTE_SIG_BLOCKS 数组/覆盖 meta header/编号簇/bland header 移除/变体 prompt/llm_call 用 $cur_prompt）⑤ **Mac Mini 15:02 生产验证**：retry 1 = 1402 chars 短仍被 server cache 命中（证据确凿）→ retry 2 变体 prompt = **21871 chars / 7000 汉字**，6 章节完整展开，9m24s 总耗时，3/3 WhatsApp+Discord 推送成功，内容识别出"本体+LLM+Agent 深度融合"主题并给出可执行建议 ⑥ 32 suites / 32 Dream 单测 / 0 fail |
| V37.4.1 | 2026-04-11 | **Dream Reduce 重试降级机制 第一次尝试** — ① 触发：V37.4 Mac Mini Run 1 (c957075) Fix A cache-only fast path 生效（11s 缓存加载），但 Phase 2 Reduce retry 1 = 3967 chars → retry 2 = 906 chars 直接砸穿，用户反馈"已经超过5min 触发LLM重试" ② **重试降级修复**（line 975-1045）：引入 `BEST_RESULT` 跟踪历次最长结果 + 温度衰减数组 `REDUCE_TEMPS=(0.85 0.6 0.4)` + 双阈值 `MIN_DREAM_CHARS=3000`（目标 ≈1000 汉字）/ `MIN_ACCEPTABLE_CHARS=1500`（真正失败底线）+ fallback `DREAM_RESULT=$BEST_RESULT` 保留最佳尝试 + fatal exit 用 MIN_ACCEPTABLE_CHARS 而非 MIN_DREAM_CHARS 以避免可接受输出被错误丢弃 ③ 新增 6 单测 `TestReduceRetryFallback`（MIN_DREAM_CHARS 阈值/REDUCE_TEMPS 衰减/BEST_RESULT 跟踪/fallback 赋值/fatal 底线阈值/retry 循环结构）④ **验证失败**：Mac Mini Run 2 (8dd0260) 三次重试 876/876/927 chars 完全一致 → 暴露"简单重试无法突破 server-side prompt caching"这一更深层根因，为 V37.4.2 铺路 |
| V37.4 | 2026-04-11 | **Dream Map 预算溢出 + cache key 稳定性 三层修复** — ① 触发：2026-04-11 `--map-notes`(00:40) + full run(03:00) 连续 60 min 超时，Reduce 从未执行，WhatsApp 告警"Dream 失败"。根因三层：(a) 286 notes × 76s/batch ÷ 4.4 = **82 min > 60 min** workload 数学溢出 (b) Reduce full run 重跑 Phase 1a/1b LLM 循环，不相信缓存 (c) Notes cache key = md5(批次拼接) 对 mtime/sort/batch 组合敏感，00:40 写的缓存 03:00 全部 miss ② **Fix A (契约)**：Reduce path 新增 cache-only fast path — 扫 `$MAP_DIR` 填充 MAP_SIGNALS / NOTES_SIGNALS，`SKIP_MAP_LOOPS=true` 门控 Phase 1a + Phase 1b + Fast-mode elif，03:00 full run 从 60 min 压到 <5 min ③ **Fix B (效率)**：Notes 批次 15 条/12000B → **30 条/24000B**，LLM 调用次数减半（~47→~24） ④ **Fix C (稳定)**：per-note cache，key=`md5(content)` 前 12 位（+ macOS `md5 -q` fallback），同 batch N 个 note 共享 signals（dedup via signal hash），mtime/sort/batch 组合漂移都不再触发 miss；第二天只有新增 notes 是 cache miss ⑤ **预算动态化**：`DREAM_TIMEOUT_SEC` 按 MAP_ONLY 5400s (90min) / 3600s (60min) 分配；`DREAM_TIMEOUT_SEC_OVERRIDE` env 支持调试 ⑥ 案例文档 `ontology/docs/cases/dream_map_budget_overflow_case.md`（四维度因果链 + 三层根因 + 时间线 + 条件组合 + 设计决策）⑦ 3 新不变式 `INV-DREAM-001` (map-budget-scales-with-mode) + `INV-DREAM-002` (reduce-path-must-not-re-run-map-loops, severity=critical) + `INV-CACHE-002` (notes-cache-key-stable-under-mtime-drift, severity=critical)，governance v3.2 → v3.3, 23→26 不变式 / 43→52 检查 ⑧ `test_dream_cache_stability.py` 20 单测锁定三 fix + 预算动态 + flush 辅助函数 + Sources 键不变 ⑨ 接入 full_regression.sh → **29 suites / 774 tests / 0 fail / 26/26 invariants / 41/52 checks** |
| V37.3 | 2026-04-11 | **Governance 自观察元规则 MR-7 + INV-GOV-001 summary-counts-all-non-pass** — ① 案例文档 `ontology/docs/cases/governance_silent_error_case.md`（四维度因果链架构图 + 三层根因 + 时间线 + 条件组合 + 本体喂养）完整分析 V37.2+ 三层嵌套盲区：子串匹配→exec 作用域陷阱→silent error summary，提炼"观察者的自我盲区"元洞察（治理系统从未对自己应用 MR-4） ② 新增 **MR-7 governance-execution-is-self-observable**：治理系统自身是一等被治理对象，check 层所有状态（pass/fail/skip/error）必须在汇总层有观察路径，不允许聚合时被透明化 ③ 新增 **INV-GOV-001 governance-summary-counts-all-non-pass**（meta_rule: MR-7，severity: critical，verification_layer: [declaration, runtime]）：声明层 grep 守卫 `r["status"] in ("fail","error")` + 运行时层构造 error 注入 probe 验证汇总不说"所有不变式成立"（含 JSON_MODE 全局状态 save/restore，解决嵌套调用视角污染） ④ 新增 `ontology/tests/test_governance_summary.py` 7 单测专门锁定 bug 3：error 状态不被吞、💥 图标正确、pure fail 仍用 ❌、all-pass 仍说 ✅、mixed fail+error 各自计数、源码级 grep 守卫 ⑤ 接入 full_regression.sh，**28 suites / 754 tests / 0 fail, governance 23/23 invariants / 32/43 checks** ⑥ governance_ontology.yaml 升级 v3.1 → v3.2（total_invariants: 22→23, meta_rules: 6→7, total_checks: 41→43） |
| V37.2+ | 2026-04-11 | **Governance INV-CRON 三层 bug 修复 + silent error detection 加固** — ① INV-CRON-003/004 子串匹配 false-positive（`kb_dream.sh` 被 Map-Reduce split 误报 ×3，`sname in l` 无法区分 prefix-subset entries）→ `endswith(entry)` + word-boundary `cmd[idx-1] in "/ \t\"'"` 精确匹配 ② YAML `_exec_python_assert` exec() 作用域陷阱（`def _cron_cmd_invokes` 在 exec 局部，`sum(1 for l in lines if ...)` 生成器表达式新作用域看不到，`NameError` 每次都炸）→ for-loop 替代生成器表达式 ③ `governance_checker.py` silent error bug（`failed_invs` 只数 `status=="fail"`，`error` 状态被忽略，💥 icon 藏在正文，汇总行显示 ✅ 所有不变式成立）→ 区分 `fail`/`error` 并在汇总行显式标注（`❌ N 违反, 💥 M 出错`） ④ 2 个新回归测试锁定：`test_yaml_no_generator_expression_over_cron_cmd_invokes`（grep 守卫）+ `test_exec_scope_trap_is_real`（正向对照，自带 Python 语义文档） ⑤ Mac Mini 生产验证：governance `--full` 40/41+💥 → **41/41 ✅**，preflight 75/1/2 → **76/0/2**（`kb_embed.py` 补齐 3 未索引 notes + 2 过期文件）⑥ 27 suites / **747 tests** / 0 fail |
| V37.2 | 2026-04-10 | **系统韧性加固 + Adapter Hot-Reload + 幻觉工具过滤 + 异常分析宪法** — ① Dream 配额爆炸链修复（智能退避 429/524 + Map 熔断 3 次 + inter-call 节流）② HN 垃圾推送修复（RSS 描述注入 + JSON 输出 + `__LLM_FAILED__` 信号 + 3 次重试）③ Adapter FALLBACK_CHAIN hot-reload（`_build_fallback_chain()` 提取 + daemon 线程 + feature flag `ADAPTER_HOT_RELOAD` + /health 暴露）④ Proxy 幻觉工具过滤（`<tool_call>` XML 清理：主响应路径 + search_kb followup 路径）⑤ 原则 #26 升级为宪法级异常分析五步法 ⑥ Dream 配额爆炸链案例文档 + 2 新治理不变式（INV-QUOTA-001/INV-PUSH-001，19 不变式）⑦ 718 测试 |
| V37.1 | 2026-04-09 | **Ontology 信息源 + 对话数据零丢失 + 治理主动监控 + PA 批判性思考** — ① Ontology 专属信息源（4 RSS: W3C/JWS/DKE/KBS + 两层关键词过滤 + LLM 摘要 + Discord #ontology + KB 归档，cron 10:00/20:00）② kb_harvest_chat MapReduce 升级（分段提炼+去重，零对话数据丢失，28 单测）③ DBLP/S2 加 ontology 关键词 ④ X 监控加 4 位 ontology 先驱（Barry Smith/Guizzardi/Hitzler/Horrocks）⑤ adversarial_audit 合并入 governance_ontology（17 不变式）⑥ 每日 governance_audit cron（07:00 自动执行+失败告警）⑦ SOUL.md 规则 9 批判性思考（反迎合+禁模糊关联+PA 回声室案例分析）⑧ Ontology 终态架构文档（四层+三阶段门控+迁移 Phase 3-5）⑨ ScienceDirect 描述正则修复 ⑩ 692 测试 |
| V37 | 2026-04-08 | **V3 路标启动 + LLM 协作方法论 + 对话数据闭环** — ① Provider Plugin Interface（YAML/Python 插件+合约验证+Extension Guide+128单测）② Capability-Based Routing（find_by_capability+build_fallback_chain+auto-discovery fallback chain 接入 adapter.py）③ 对话数据闭环（proxy 热路径捕获→kb_harvest_chat.py 冷路径提炼→MEMORY.md 索引→KB 可检索）④ KB 统一（HN+Freight 双写 notes 对齐 12/12 job）⑤ LLM 协作 4 条新原则（#22 顺势设计/#23 链式幻觉防范/#24 触发词机制/#25 对话数据一等公民）⑥ industrial_ai_paradigm.md 切断幻觉链 ⑦ 692 测试 |
| V36.3 | 2026-04-08 | **Runtime Governance + Ontology Shadow Mode** — ① 遗留修复(crontab漂移3job+重复清理35→28+DBLP/Dream推送恢复+notify.sh zsh兼容+smoke test python3检测) ② Governance v3(12→15不变式: 运行时层INV-CRON-003/004+INV-ENV-002, MR-6多层深度要求) ③ 验证深度三层模型(声明/运行时/效果, governance自我意识盲区, MRD-LAYER-001) ④ 语义推理落地(classify_tool_call从属性推理risk_level+policy_tags) ⑤ Phase 2 shadow模式(off→shadow→on三档, Mac Mini生产上线) ⑥ 832测试 |
| V36.2 | 2026-04-07 | **Governance Ontology + 对抗审计体系** — ① Dream修复(printf注入+残留锁) ② 凌晨静默期(00-07零推送) ③ Crontab漂移检测(registry vs crontab) ④ 对抗审计22个声明-实际断裂→adversarial_audit.py(9项) ⑤ governance_ontology.yaml v2(12不变式+28可执行检查+5元规则) ⑥ Phase 0元规则自主发现(23个未覆盖job) ⑦ 工具数量硬断言(MAX_TOOLS import+截断) ⑧ 立场文章(EN+ZH) + Ontology子项目深度建设(Tool Engine+宪法+PoC+特性开关) |
| V36.1 | 2026-04-06 | **Agent Dream v2 + Ontology KB** — MapReduce 全量 KB 探索（14源+226笔记）+ Notes 一等信号 + Ontology KB 创建（7文件）+ 论文监控加 ontology 关键词 + X 监控 9→15 人（+Palantir）+ Cron 调度优化（~55→30 次/天）+ 凌晨 GPU 黄金窗口 |
| V36 | 2026-04-05 | **V2 路标双P0完成** — Agent Reliability Bench（7场景47检查） + Memory Plane v1（4层统一接口+45单测+架构文档） + 560 测试 |
| V35 | 2026-04-05 | **V1 路标冲刺** — SLO Benchmark 实验报告 + Quick Start 一键 demo + Golden Test Trace + Sub-agent PoC（链路通，deferred 等模型升级）+ 605 测试 |
| V34 | 2026-04-03 | **Stage2 启动** — Provider Compatibility Layer + 导师战略复盘嵌入治理体系 + V1/V2/V3 路标 + 461 测试 |
| V33 | 2026-04-03 | Discord 双通道支持 + 统一推送 notify.sh + Gateway 不升级可用 |
| V30.5 | 2026-03-31 | search_kb 混合检索 + 论文监控矩阵 5 源全覆盖 + DBLP 上线 |
| V30.4 | 2026-03-28 | SOUL.md 激活 + 三方宪法闭环 + 方法论进化（结果验证优先） |
| V30.3 | 2026-03-27 | 数据清洗 Phase 1 + 自定义工具注入机制 + WhatsApp E2E |
| V30.2 | 2026-03-26 | 安全评分体系 + 审计日志 + 持续安全机制 |
| V30.1 | 2026-03-26 | status.json 实时刷新 + KB 完整性 + 全量回归 374 测试 |
| V30 | 2026-03-26 | crontab 事故修复 + cron 安全三层保护 + 原子写入加固 |
| V29.5 | 2026-03-25 | KB 周趋势报告 + 模型智能路由 + 三方共享状态 |
| V29.4 | 2026-03-25 | 多模态图片理解（Qwen2.5-VL-72B 自动路由） |
| V29.3 | 2026-03-24 | 本地 Embedding + KB RAG 语义搜索 |
| V29.1 | 2026-03-14 | Fallback 降级链 + 每日备份 + Multi-Agent + MM 索引 |
| V29 | 2026-03-13 | KB 搜索/LLM 回顾/每日摘要注入 |
| V28.x | 2026-03-11~13 | 线程化 + preflight 体检 + WhatsApp 保活 + OpenClaw 架构同步 |
| V27.x | 2026-03-10 | Proxy 拆层 + 任务注册表 + auto_deploy + 回滚机制 |

## 常用命令

```bash
# 启动服务
nohup python3 ~/adapter.py > ~/adapter.log 2>&1 &
nohup python3 ~/tool_proxy.py > ~/tool_proxy.log 2>&1 &

# 健康检查
curl http://localhost:5002/health

# 一键重启
bash ~/restart.sh

# 运行单测
python3 test_tool_proxy.py
python3 test_check_registry.py

# 校验任务注册表
python3 check_registry.py

# 一键 smoke test（单测+注册表+连通性）
bash smoke_test.sh

# 全量回归测试（461个用例，发布前必须100%通过）
bash full_regression.sh

# 治理审计（ontology-native，23不变式+7元规则+6元发现）
python3 ontology/governance_checker.py              # dev 模式
python3 ontology/governance_checker.py --full        # Mac Mini（含 crontab/env/服务）
python3 ontology/governance_checker.py --json        # JSON 输出

# 安全评分（7维度100分）
python3 security_score.py
python3 security_score.py --update  # 写入 status.json

# 审计日志
python3 audit_log.py --tail 20      # 查看最近操作
python3 audit_log.py --verify       # 校验链式哈希
python3 audit_log.py --stats        # 统计概览

# 收工前全面体检（dev 环境）
bash preflight_check.sh
# 收工前全面体检（Mac Mini，含部署一致性+环境变量+连通性）
bash preflight_check.sh --full

# KB 搜索 / 摘要
bash kb_search.sh "关键词"         # 全文搜索
bash kb_search.sh --summary        # 统计概览
bash kb_search.sh --source arxiv   # 搜索来源归档
bash kb_inject.sh                  # 手动生成每日摘要

# Multimodal Memory（需要 pip3 install google-genai numpy）
python3 mm_index.py                # 增量索引媒体文件
python3 mm_index.py --reindex      # 重建全部索引
python3 mm_search.py "猫的照片"    # 语义搜索媒体
python3 mm_search.py --stats       # 索引统计

# KB 本地 Embedding + RAG（需要 pip3 install sentence-transformers）
python3 local_embed.py --bench     # 性能基准测试
python3 kb_embed.py                # 增量索引 KB 文本
python3 kb_embed.py --reindex      # 重建全部索引
python3 kb_embed.py --stats        # 索引统计
python3 kb_rag.py "Qwen3 模型"     # 语义搜索 KB
python3 kb_rag.py --context "AI论文" # LLM 可直接注入的上下文格式
python3 kb_rag.py --json "shipping" # JSON 输出（供脚本调用）

# 数据清洗（支持 CSV/TSV/JSON/JSONL/Excel）
python3 data_clean.py profile data.xlsx --format text   # 数据画像
python3 data_clean.py execute data.xlsx --ops trim,dedup,fix_dates  # 执行清洗
python3 data_clean.py validate original.csv cleaned.csv  # 验证结果
python3 data_clean.py list-ops                           # 可用操作
python3 data_clean.py history data.xlsx                  # 版本历史
curl http://localhost:5002/data_clean/help               # REST 端点帮助

# Quick Start（一键 10 分钟跑通全栈）
bash quickstart.sh                # 完整 4 阶段（前置检查→启动→健康→demo）
bash quickstart.sh --check        # 仅检查前置条件
bash quickstart.sh --demo         # 仅运行 demo 请求

# Memory Plane（统一记忆平面）
python3 memory_plane.py layers                    # 层可用性检查
python3 memory_plane.py stats                     # 各层统计
python3 memory_plane.py query "Qwen3"             # 统一搜索
python3 memory_plane.py query --context "AI论文"   # LLM可注入格式
python3 memory_plane.py query --layers kb "RAG"    # 仅搜索KB层

# 每日深度分析（V37.9.16，22:30 HKT cron）
bash kb_deep_dive.sh                       # 手动触发（挑选今日⭐≥4 候选 + 抓取原文 + LLM 深度分析 + 双通道推送）
KB_DIR=~/.kb python3 kb_deep_dive.py       # 直接跑 collector（JSON 输出到 stdout，不推送）
cat ~/.kb/deep_dives/$(date +%Y-%m-%d).md  # 查看今日归档

# Agent Dream v2（Map-Reduce 三阶段分离调度）
bash kb_dream.sh --map-sources # Sources Map 预热（00:00 cron，~10min）
bash kb_dream.sh --map-notes   # Notes Map 预热（00:25 cron，~10min）
bash kb_dream.sh              # Reduce：两层缓存命中→跨域关联→推送（03:00 cron，~3.5min）
bash kb_dream.sh --map-only   # 全部 Map 预热（Sources + Notes，~20min）
bash kb_dream.sh --dry-run    # 素材统计（不调 LLM）
bash kb_dream.sh --fast       # 跳过 Map，直接采样做梦（旧模式）
cat ~/.kb/dreams/2026-04-06.md  # 查看梦境结果

# Agent Reliability Bench（7场景故障评测）
python3 reliability_bench.py            # Markdown 报告
python3 reliability_bench.py --json     # JSON 格式
python3 reliability_bench.py --save     # 保存到 docs/reliability_bench_report.md
python3 reliability_bench.py --scenario 3  # 运行单个场景

# SLO Benchmark（真实生产数据报告）
python3 slo_benchmark.py          # Markdown 报告
python3 slo_benchmark.py --json   # JSON 格式
python3 slo_benchmark.py --save   # 保存到 docs/slo_benchmark_report.md

# Provider 兼容性矩阵
python3 providers.py              # Markdown 表格
python3 providers.py --json       # JSON 格式（供脚本调用）

# 生成任务文档 / 检测文档漂移
python3 gen_jobs_doc.py           # 输出 markdown 表格
python3 gen_jobs_doc.py --check   # 对比 docs/config.md 检测漂移

# 查询远端当前模型ID
curl -s https://hkagentx.hkopenlab.com/v1/models \
  -H "Authorization: Bearer $REMOTE_API_KEY" \
  | python3 -c "import json,sys; [print(m['id']) for m in json.load(sys.stdin)['data'] if 'Qwen3' in m['id']]"

# Mac Mini 同步仓库（禁止用 git pull，会因历史 merge commit 分叉失败）
cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main

# GitHub push前安全扫描（必须全部为空才允许push）
grep -r "sk-[A-Za-z0-9]\{15,\}" . --include="*.py" --include="*.sh" --include="*.md" | grep -v ".git"
grep -r "BSA[A-Za-z0-9]\{15,\}" . --include="*.py" --include="*.sh" --include="*.md" | grep -v ".git"
```

## 关键规则

### 模型ID规则
| 位置 | 格式 |
|------|------|
| `adapter.py` / `tool_proxy.py` | 裸ID（无前缀） |
| `openclaw.json` agents.defaults.model.primary | **必须带 `qwen-local/` 前缀** |
| `jobs.json` payload.model | **不指定**（继承默认值） |

### 硬性限制
- 工具数量 <= 12（超出导致模型混乱）
- 每任务工具调用 <= 2次（超出超时风险指数级上升）
- 请求体 <= 200KB（硬限制280KB，留buffer）
- `--thinking` 合法值：`off, minimal, low, medium, high, adaptive`（**禁止用 `none`**，这是v26修复的bug #92）

### 双 Cron 归属规则（V27新增）

| 调度器 | 管理方式 | 是否经过 LLM | 登记位置 |
|--------|----------|-------------|----------|
| `system` | macOS `crontab -e` | 否 | `jobs_registry.yaml` scheduler=system |
| `openclaw` | `openclaw cron add` | 是 | `jobs_registry.yaml` scheduler=openclaw |

**原则**：确定性脚本（清理、备份、抓取）用 `system`；需要 LLM 理解/生成的用 `openclaw`。
**新增任务必须先登记到 `jobs_registry.yaml`，运行 `python3 check_registry.py` 通过后才能注册 cron。**

### 安全规则（GitHub push前强制）
- API Key 必须通过环境变量：`os.environ.get("REMOTE_API_KEY")`
- 配置文档（含真实手机号/密钥）永不入库（已在 .gitignore）
- 公开仓库手机号统一用 `+85200000000` 占位

## 工作原则

### 🔴🔴🔴 第 0 号宪法：最强模型，不降配不降速不妥协

> **每次使用 Claude Code 必须使用家族中最强的 Opus 级模型。当前合法模型（按发布时间新旧）：Claude Opus 4.7（`claude-opus-4-7`，2026 发布，当前最强）> Claude Opus 4.6（`claude-opus-4-6`，向下兼容）。**
>
> 禁止为了"快一点"切换到较弱模型家族（Sonnet / Haiku），禁止开启 fast mode 牺牲推理深度，禁止因为 token 用量或响应速度而降级。
>
> 这个项目的核心竞争力是**思考深度和工程质量**，不是速度。用弱模型省下的 10 分钟，会在后续的 bug 修复、连锁故障、返工中付出 10 倍代价。
>
> **1111 个测试、53 个治理不变式、15 条元规则——这个系统的复杂度要求最强的推理能力来驾驭，没有妥协空间。**
>
> **"更强的新版本不是降级"原则**：Anthropic 发布更强的 Opus 版本（4.6 → 4.7 → 4.8 ...）时，自动纳入合法列表。**降级的判定不是"模型 ID 变了"，而是"推理能力变弱了"**。把 Opus 4.6 换成 Opus 4.7 是升级，不是违反第 0 号宪法；把 Opus 换成 Sonnet/Haiku 才是违反。
>
> **执行机制（2026-04-14 强制 + 2026-04-20 升级）**：每次新 session 开工的**第一条回复**必须包含一行模型声明，格式为：
> `🤖 本次 session 模型：Claude Opus <X.Y> (claude-opus-<x-y>) | 最强级别，无降级 | fast mode 状态见 /fast 命令`
> 其中 `<X.Y>` 是当前实际运行的 Opus 版本号（4.6 / 4.7 / 未来更新）。声明放在开工报告之前，独占一行，前面不加任何寒暄。如果运行时检测到模型**不是 Opus 家族**（例如被错配到 Sonnet 4.6 / Haiku 4.5），**立即停止工作并告知用户**。见原则 #30。

### 🔴 三合一宪法

> **用户提供专业深度 + Claude Code 提供高效设计部署 + OpenClaw 提供数据复利 — 三者合一成为有生命的闭环系统。**
>
> 共享状态：`~/.kb/status.json`（三方实时同步优先级、反馈、系统健康）

### 🔴 战略定位（2026-04-03 导师评审确立）

> **项目已跨过关键门槛：Stage 1 完成（系统构建者）→ 正在冲刺 Stage 2（被社区认可的系统作者）。**
>
> **主战场**：不再是抽象的"LLM推理系统"，已收敛为两条线：
> 1. **Agent Runtime / Inference Gateway / Control Plane** — 模型接入 + 工具治理 + 可观测性 + 故障恢复
> 2. **Agent Memory Plane / KB-RAG / Job-Orchestrated Intelligence** — 记忆系统 + 知识检索 + 作业编排
>
> **旗舰叙事**：`OpenClaw Runtime Control Plane for Tool-Calling Agents`
>
> **核心洞察**：项目最强的不是单独算法，而是把模型接入、工具治理、可观测性、故障恢复、记忆与作业系统编织成可运行的 agent runtime。顶级专家不是死守最初设想，而是顺着已证明的能力继续放大。
>
> **12 个月路线图**：
> - **V1（0-4月）别人能跑**：安装稳定 / 配置清晰 / 文档闭环 / 最小 demo / golden test trace
> - **V2（4-8月）别人敢用**：benchmark / SLO dashboard / incident drill / 兼容矩阵 / semver
> - **V3（8-12月）别人会扩展**：provider plugin / tool policy plugin / memory plane plugin / SDK / extension guide
>
> **距离世界顶级的三块差距**：可迁移性（去硬编码场景依赖）/ 证据密度（benchmark+演练+案例）/ 话语权输出（代码+文档+评测+方法论=完整叙事）
>
> **详细战略文档**：`docs/strategic_review_20260403.md`

### 🔴 每次必查（35条，优先级最高）

| # | 原则 | 一句话 |
|---|------|--------|
| 1 | **开工刷新 OpenClaw 架构（先读决策再评估）** | 先读 `docs/config.md` 中现有的升级 hold 决策和版本状态，再查 OpenClaw 最新 release；如已有明确 hold 决策且上游无新版本，跳过重复评估；有新版本时对比决策条件是否变化，变化则重新评估，否则沿用。**禁止"上游已修复"就改代码——必须确认本地已部署该版本**（#48703教训） |
| 2 | **开工先读 config** | 读 `docs/config.md` 获取系统状态 + 踩坑记录，避免重复犯错 |
| 3 | **开工先读/收工必写 status.json** | `python3 status_update.py --read --human` 查看三方共享状态（优先级、反馈、系统健康）；收工时更新 priorities + recent_changes：`python3 status_update.py --add recent_changes '{"date":"...","what":"...","by":"claude_code"}' --by claude_code` |
| 4 | **改完先测** | 新脚本手动验证 → 新任务先写 `jobs_registry.yaml` 并 `python3 check_registry.py` 通过 → 才能注册 cron |
| 5 | **push前必扫描** | 安全扫描（见上方命令）全部为空才允许 push |
| 6 | **新功能必须 Mac Mini E2E 验证** | dev 环境单测通过不算完成；**必须提醒用户在 Mac Mini 上运行 `bash preflight_check.sh --full` + `bash job_smoke_test.sh` + 手动触发目标 job**，确认端到端有效果（消息到达 WhatsApp / 文件生成 / 日志正常）。dev 通过 ≠ 生产工作。 |
| 7 | **故障先查自身代码** | 排查问题时默认从我们自己的代码和架构中找 bug（shell 数据传递、cron 环境、进程管理等），不归因于上游服务不稳定（#97教训） |
| 8 | **做减法不做加法**（→ #34 日落法战略升级版） | 新增防护/监控前先问"谁已经在管这件事"；每加一层保险 = 多一个故障源（#95教训）。**2026-06-05 升级**：这条的战略化北极星是 #34 日落法——不只"别加"，是"加之前先问能否退役"。 |
| 9 | **🔴 收工必须执行完整检查清单（不可跳过）** | "结束今天的工作"时，**必须逐项执行以下清单，每项完成后打勾确认，禁止跳过或合并**：**A. 全量回归** `bash full_regression.sh`（必须 0 fail，完成后自动更新 status.json test_count）**B. 安全评分** `python3 security_score.py --update` **C. 安全扫描** API key + 手机号 + BSA 泄漏扫描 **D. 治理审计** `python3 ontology/governance_checker.py` **E. 文档刷新**（逐一 check）：`status.json`（recent_changes/session_context/focus）→ `CLAUDE.md`（版本/文件表/changelog/待办交叉校验）→ `docs/config.md`（如有配置变更）→ `README.md`（如有架构变更）→ `SOUL.md`（如有 PA 行为变更）→ `docs/ontology/`（如有 ontology 变更）**F. 交叉校验** 原则#17：commits vs CLAUDE.md 待办一致性 **G. 全部提交推送** **H. 提醒 Mac Mini 验证** `preflight_check.sh --full` + `job_smoke_test.sh` — **不是"提醒"而是必须等用户执行并确认结果** **I. 遗留问题登记** 未完成事项写入 session_context.unfinished。（2026-04-08教训：长 session 后"赶紧结束"心态导致跳过 6 项检查，用户两次追问才补齐） |
| 10 | **相信 OpenClaw，用好 OpenClaw** | 优先利用 OpenClaw 已有能力（Multi-Agent、contextPruning、workspace SOUL.md/CLAUDE.md、memory、sessions_spawn 等），而非重新造轮子；遇到新需求先查 OpenClaw 文档和 release notes |
| 11 | **🆕 结果验证优先于功能建设** | 先定义"从用户视角，成功长什么样"，再写代码。status.json 的成功标准不是"能写入"，而是"PA 能正确回答项目进展"。（2026-03-28教训：393个单测通过但 PA 说"没有项目"） |
| 12 | **🆕 上下文工程是一等公民** | SOUL.md = 宪法级（身份+关键状态，LLM 注意力最高），CLAUDE.md = 手册级（工具+详情）；信息放哪里、占多少 token、LLM 能否注意到——都是架构决策，和 API 设计同等严肃。（2026-03-28教训：SOUL.md 空置数月，17KB CLAUDE.md 信息被"lost in the middle"） |
| 13 | **🆕 定期像用户一样使用系统** | 不是跑单测，而是在 WhatsApp 上实际问 PA 问题。每次涉及 PA 行为的变更后，必须清空 session（`echo '{"sessions":[]}' > sessions.json`）+ 重启 Gateway + WhatsApp 实测。单测验证组件内部，系统价值在组件之间的接缝处。 |
| 14 | **🔴 合并 PR 后下一步首先同步 Mac Mini (主动给命令不等用户问)** | **这是卡点，不是提醒。** GitHub PR 合并到 main 后，**下一步必须是 Mac Mini 同步，不做任何其他操作**。同步命令：`cd ~/openclaw-model-bridge && git fetch origin main && git reset --hard origin/main`。同步后立即验证：`bash preflight_check.sh --full`。**不要在 Mac Mini 上测试未同步的代码**——多次返工都是因为合并后没同步就直接跑旧代码。不要等 auto_deploy 轮询。**🔴 执行机制 (2026-05-13 升级)**：每次 push commit 到 PR 分支后，或检测到 PR 合并 (用户说"已合并"/"merged"/`git log` 看到 main 有新 merge commit) 时，**Claude 必须立即主动给出同步命令 + 验证命令** (上方两条 bash 块)，不等用户问"是否需要同步". 这是原则 #29 "零遗漏" 的具体兑现——同步是已知必须的下一步，不需要每次用户提醒。**禁止反模式**: 回复"请用户决定下一步" 或 "工作已完成, 等用户合并" 而不附同步命令 (用户合并后会再问"需要同步吗?" 是这个反模式的症状). （2026-04-01教训：合并后 preflight 8 项失败全是部署漂移；2026-04-06教训：合并后直接测试跑的是旧代码，浪费时间排查不存在的 bug；2026-05-13教训：V37.9.62 doc commit f70503a push 后未主动提示同步, 用户合并 PR #547 后必须再问"需要同步吗?", 才提示同步命令——证明 #14 执行不彻底, 升级为主动给指令）|
| 15 | **🆕 测试必须全量：单测 + full_regression + WhatsApp 业务验证** | 每次变更后测试三层缺一不可：① `bash full_regression.sh`（394 单测 + 注册表 + 安全扫描 + 代码质量）② `bash preflight_check.sh --full` + `bash job_smoke_test.sh`（Mac Mini 部署验证）③ **WhatsApp 端实际业务测试**（用户视角发消息验证 PA 回复、search_kb 检索、图片理解等核心功能）。只跑单测不算测完——单测验证组件，WhatsApp 验证系统。（2026-04-01教训：394 单测全过但 preflight 8 项失败） |
| 16 | **🆕 所有推送必须双通道（WhatsApp + Discord）** | 新增或修改任何消息推送时，**必须同时覆盖 WhatsApp 和 Discord 两个通道**，不允许遗留单通道发送。优先使用 `notify.sh`（`source notify.sh && notify "msg" --topic papers`）统一推送；若直接调用 `openclaw message send`，每个 WhatsApp 发送后必须紧跟对应的 Discord 发送（成功路径→对应 topic 频道，错误/告警→`DISCORD_CH_ALERTS`）。审计方法：`grep -c "message send.*whatsapp"` 与 `grep -c "message send.*discord"` 计数必须一致。（2026-04-03教训：货代客户画像推送遗漏 Discord，11 个脚本错误路径缺 Discord） |
| 17 | **🆕 收工必须交叉校验待办状态** | 收工时不仅更新 `status.json`，还必须**扫描 CLAUDE.md 待办列表**，对照本次 session 的 commits 和 recent_changes，将已实现的任务标记 ✅。实现代码 + 更新待办 = 一个完整的交付，缺一不可。同时检查：① CLAUDE.md 待办 vs 实际代码一致 ② status.json priorities vs CLAUDE.md 待办一致 ③ 版本号/文件表/常用命令是否需要同步更新。（2026-04-03教训：V32 实现了 7 个 P0+P1 任务但 CLAUDE.md 全部未标记，直到 V33 审计才发现） |
| 18 | **🆕 补证据而非补功能** | 下一阶段最该补的不是功能，而是**可对外复述的证据链**：A.兼容性矩阵（provider/模型/模态/工具模式验证 matrix+checklist）B.性能/SLO 实验结果（延迟/成功率/降级恢复时间）C.运维韧性证据（故障注入+恢复时间统计）D.可复现证据（一键启动+demo transcript）。新增功能前先问"这能产出什么证据？"（2026-04-03导师评审：系统已有但证据密度不足） |
| 19 | **🆕 纵向做深不横向铺开** | 沿 `providers.py` 已证明的方向继续放大，不轻易开新战线。每个改动必须对应 V1/V2/V3 路标中的具体目标：V1=别人能跑，V2=别人敢用，V3=别人会扩展。对照 `docs/strategic_review_20260403.md` 和 status.json 路标检查。偏离路标的功能需要明确理由。（2026-04-03导师建议：不是再做更多功能，而是把已有能力做成证据链） |
| 20 | **🆕 话语权输出是一等公民** | 代码只是第一步，真正的顶级专家把代码、文档、评测、方法论、复盘文章串成完整叙事。每个 milestone 完成后考虑：能否产出一篇架构型/证据型/立场型文章？README 里的方法论要持续扩写成观点体系。（2026-04-03导师建议：建立"话语权上层建筑"） |
| 21 | **🆕 对抗审计：问"什么坏了我们发现不了"（含治理自身）** | 每月至少一次 adversarial review：不问"检查了什么"，而问"**什么东西坏了我们会发现不了？**"。**治理系统自己也在这个问题的范围里**——MR-7 (governance-execution-is-self-observable) 要求 check 层所有状态（pass/fail/skip/error）必须在汇总层有观察路径。治理审计（`ontology/governance_checker.py`，每日 07:00 自动执行+失败告警）防止已知漏洞回归；人工对抗思维发现新维度盲区。每发现一个"没人会发现"的答案，就转化为 `governance_ontology.yaml` 的新不变式（ontology-native，不用硬编码）。检查体系最危险的漏洞不是某个检查没写好，而是某个维度从未被纳入检查。（2026-04-09：adversarial_audit.py 9个检查合并入 governance_ontology.yaml；2026-04-11 升级：V37.3 MR-7 治理自观察 + INV-GOV-001 summary 不吞 error，23 不变式 / 7 元规则 / 6 元发现，首次实现"治理系统治理自己"） |
| 22 | **🆕 顺势设计：适配模型行为，不对抗** | LLM 工具使用服从训练分布，不服从"应该"。通用工具（write/read/exec）自然使用，专用工具（memory/sessions）需 SOUL.md 强制规则才触发。设计系统时**顺着模型的自然行为**：PA 自然用 write 写 MEMORY.md → 我们把 MEMORY.md 接入 KB 索引；PA 不会主动调 kb_write.sh → 我们在 proxy 层静默捕获对话。对抗模型倾向的设计必然失败。（2026-04-08教训：等了一个月让 Qwen3 调 memory_create，从未成功；改为顺势捕获后一天闭环） |
| 23 | **🆕 链式幻觉防范：LLM 链路中每一跳都会放大幻觉** | 多个 LLM 共享上下文时，一个 LLM 的幻觉会被下游 LLM 当作事实执行。Dream LLM 编造文件名 → PA LLM 尝试读取 → 失败。防范方法：① 讨论密度必须等于文档密度（KB 里高频讨论的主题必须有对应文档，否则 LLM 会补全出不存在的文件名）② LLM 生成的行动建议不能直接执行，需要 grounding 检查（文件是否存在、工具是否可用）③ 上下文中提供明确的文件清单，让 LLM 知道"有什么"和"没有什么"。（2026-04-08教训：industrial_ai_paradigm.md 幻觉链——Dream 生成→PA 执行→文件不存在） |
| 24 | **🆕 SOUL.md 触发词是唯一可靠的工具调用机制** | 当前 Qwen3 不会自主决定调用专用工具。唯一可靠的强制方式是 SOUL.md 的"遇到X必须调Y"规则+具体触发词列表。ops agent 的 sessions_spawn 成功不是因为 Qwen3 学会了，而是触发词"排查/超时/告警"命中了 SOUL.md 硬规则。新增专用工具时，必须同步更新 SOUL.md 触发词规则，否则工具永远不会被调用。（2026-04-08教训：memory 工具上线数周零调用，ops spawn 靠触发词 100% 成功） |
| 25 | **🆕 对话数据是最高质量信号源** | 用户与 PA 的对话包含决策、偏好、专业洞察、领域判断——这些是 cron 抓取的论文/新闻无法替代的一手数据。必须确保对话数据被捕获并进入 KB 索引（`tool_proxy.py` 热路径捕获 → `kb_harvest_chat.py` 冷路径提炼 → KB notes）。同时关注 PA 自主写入的文件（如 `MEMORY.md`），将其纳入索引范围。数据流失 = 系统失忆。（2026-04-08教训：240 条 KB notes 全是机器抓取，零对话数据；PA 自主写入的 MEMORY.md 也是孤岛） |
| 26 | **🔴 异常分析宪法：必须输出完整因果链架构图** | 见下方独立章节"异常分析宪法"。（2026-04-10 升级为宪法级） |
| 27 | **🆕 X/Twitter 是高质量实时数据的第一选择（但账号健康 ≠ HTTP 200）** | 当 RSS 源失效（官方取消、CDN 封锁、RSSHub 公共实例 403）时，**X/Twitter Syndication API 是最可靠的替代通道**——无需认证、零成本、覆盖全球权威机构官方账号。Twitter Syndication API (`syndication.twitter.com/srv/timeline-profile/screen-name/{handle}`) 返回 HTML 内含 `__NEXT_DATA__` JSON，可解析出完整推文内容+时间+ID。新增数据抓取任务时，优先评估目标机构的 X 账号是否活跃，再考虑 RSS/API。实践证明：14 个财经 X 账号 100% 成功率 vs 10 个 RSSHub 路由 100% 失败率。**🔴 V37.8.4 血案补充：X 账号健康 ≠ HTTP 200**——Syndication API 对已停更账号返回 stale 快照（HTTP 200 + 可解析 HTML + 推文数据，但最新推文可能是几百天甚至几年前），embed-disabled 账号则返回 2KB 空 stub。**账号健康必须通过最新推文时间戳验证**（`newest_tweet_dt > now - N 天`），不能依赖 HTTP 状态码或 HTML 大小。新增账号前必须先抽查最新推文时间；生产脚本必须对"抓到内容但 0 条过时间窗"的账号打 ZOMBIE 嫌疑标记，连续多天命中触发告警。（2026-04-13 教训：finance_news 12/20 RSS 源失败；2026-04-14 教训：V37.8.3 修复把 3 个正常 handle 改名成僵尸账号——caixin/yicaichina/straits_times 分别停更 2227/3364/420 天，Reuters 253 天，BrookingsInst 585 天，WorldBank 返回 stub。这是 MR-10 violation：看到失败先猜原因改代码而不是先验证账号真实状态） |
| 28 | **🔴 理解再动手：修复前必答三问** | 看到报错/失败时，**禁止直接开始"修"**，必须先回答三个问题：**(1) 这个问题之前存在吗？** 如果之前不存在，那是我的改动引入的，不是系统本身的 bug。**(2) 是我的哪个改动引入的？** 精确定位因果链，不猜测。**(3) 最小修复方案是什么？** 不引入新概念、新模式、新复杂度。三个问题答不上来 = 还没理解问题，禁止动手。**每次"修复"都可能制造下一个 bug——连锁修复是最危险的系统破坏模式。**（2026-04-13教训：preflight 一个部署同步问题被误诊为"缺少配置"，5 轮连锁修复、4 层新复杂度、用户 Mac Mini 手动测试 5 次，才修好一个原本只需 `cp` 一下的问题） |
| 29 | **🔴 开工/收工清单逐项执行，零遗漏** | 开工和收工的检查清单**每一项都必须逐一执行并确认**，不允许"差不多就行"、不允许合并跳过、不允许因为 session 太长而"赶紧结束"。系统已达 951 测试 / 35 不变式 / 34 cron job 的复杂度，任何一项遗漏都可能造成连锁故障。**开工时**：逐项执行原则 #1~#3（读 config → 读 status.json → 检查 OpenClaw 版本），不跳过任何一步。**收工时**：原则 #9 的 A~I 九项清单逐一执行并打勾，每完成一项立即标记，禁止批量处理。如果某项因客观原因无法执行，必须**显式说明原因并登记到 session_context.unfinished**，而不是静默跳过。（2026-04-13教训：开工/收工流程逐渐敷衍，原则执行不彻底导致遗留问题积累；2026-04-08教训：长 session 后"赶紧结束"心态跳过 6 项检查） |
| 30 | **🔴🔴🔴 开工必须主动声明模型（第 0 号宪法执行机制）** | 每次新 session 开工的**第一条回复必须以模型声明开头**，独占一行，格式为：`🤖 本次 session 模型：Claude Opus <X.Y> (claude-opus-<x-y>) \| 最强级别，无降级 \| fast mode 状态见 /fast 命令`。`<X.Y>` 是当前实际运行的 Opus 版本号（4.6 / 4.7 / 未来更新），读取 `$0` 或环境注入信息确定。**用户无需询问也必须声明**，这是第 0 号宪法的自动执行机制，不是可选项。**合法模型家族 = Opus**（4.6/4.7/更新版本均合规）；如果运行时检测到模型**不是 Opus 家族**（即被错配到 Sonnet / Haiku 或其他），**立即停止工作，把错配告知用户，等待处理后再继续**。升级到更新的 Opus 版本（4.6 → 4.7 → …）自动合规无需告警——那是升级不是降级。禁止"先干活再说"的侥幸思维——弱模型写的代码会在后续造成连锁故障。声明位置：在任何寒暄、分析、工具调用之前。（2026-04-14教训：用户必须手动追问"是否最强模型"才能确认，声明应主动前置而非被动回答；2026-04-20升级：Opus 4.7 发布后原"硬编码 4.6"规则误把升级当降级，改为"Opus 家族"通配） |
| 31 | **🆕 跨消费者豁免必须全量同步** | 同一配置数据（如 FILE_MAP）被多个脚本独立消费时（preflight / auto_deploy / job_smoke_test），**任何豁免规则必须在所有消费者中同步落实**，不得只改一个。发现新豁免需求时，必须**系统性扫描所有消费者**并打包修复，禁止单点修复。（2026-04-15教训 V37.8.11：V37.8.1 给 preflight 加了 status.json 豁免但 auto_deploy 漏改，导致每小时 drift 告警噪声长期潜伏；2026-04-16 又因 FILE_MAP 自复制行触发 cp 非零 + set -e 杀脚本，是同一原理的第二次演出。**正确做法**：每次改 FILE_MAP 豁免前 `grep -l "FILE_MAP\|for mapping" ` 找出所有消费者 → 打包一起改 → 加单测守卫跨文件一致性。）|
| 32 | **🆕 每周用户视角观察制度（30min）** | 每周固定时段（建议周一早）做一次**纯用户视角**的系统观察，**不写代码不修 bug**，专门看四个维度：① **告警噪声**（WhatsApp + Discord #告警 频道里告警频率/重复度/可读性）② **推送延迟**（cron job 推送到达手机的延时分布）③ **信息密度**（推送内容是否真有用 / 有没有水货）④ **用户感知**（自己使用时 PA 是否答非所问 / 慢 / 错乱）。每发现一个问题立刻登记到 status.json unfinished 而不是当场修。这是原则 #13 (定期像用户用) 和 #15 (测试全量) 的运营层兑现 — 单测/治理只能验证组件正确，**用户感知质量只能用户视角观察**。（2026-04-15 V37.8.11 教训：drift 噪声告警长期存在但开发环境永远绿灯，用户半天 WhatsApp 观察就发现；2026-04-16 V37.8.13 教训：Gateway 宕 9h 静默，原因之一就是没人主动巡视双通道告警频道。**执行机制**：周一早开工时第一件事执行此观察，30min 时间盒，发现项写入 status.json `--add unfinished` + `recent_changes` 标记为 weekly_observation 类目，本周内择机修复。） |

| 33 | **🆕 信源可达性必须在部署环境验证，SPA 必查 API** | 判定一个网站"不可抓取"前，必须完成三步验证：**(1) Mac Mini curl 测试**（不是 dev 环境）— 带 User-Agent 请求首页，dev 环境的 403 可能只是 IP/地域限制 **(2) 读 HTML 源码找 API** — SPA 网站的后端 API 必然在 JS 里（如 chaspark `/chasiwu/v1/`），读 `<script>` 标签找 `fetch/XMLHttpRequest/makeRequest` 调用 **(3) 只有三步都失败，才考虑复杂方案**（Puppeteer/间接渠道/放弃）。**禁止在 dev 环境得到 403 就下"全站封锁"的结论。X 账号是僵尸 ≠ 该机构停止发布 — 检查其官网 RSS/API。**（2026-04-17 教训：chaspark.com 在 dev 环境 403，被误判为"全站封锁+SPA 不可抓取"，提议 Puppeteer 重方案。实际 Mac Mini 首页 200，HTML 源码里 API 明文写着，5 分钟就抓到 39 篇文章。同日审计发现 Brookings Atom + WorldBank JSON API 也可直达，此前从未尝试。） |
| 34 | **🔴 日落法（Sunset Law）：降低复杂度优先于增加功能（北极星）** | 2026-06-05 确立为项目未来发展北极星。**系统演进的默认动作是"退役/合并"，不是"新增"**。意外频发的真因不是"系统复杂"(部件难懂)，是"系统组合"(简单正确的部件，交互面积超线性增长超过测试覆盖)——**复杂关乎部件，意外关乎接缝**。三条操作规则：**(1) 加之前先问能否退役** — 每加一层(脚本/不变式/MR/框架/表示/路径)前必须先问"能否退役一个等价的现有机制"(原则 #8 的战略升级，不只是"别加"是"主动退役") **(2) 一物一形** — 同一逻辑事物只应有一个物理表示，多重表示(路径/文件/身份)必然漂移 bug 住在缝里(auto_deploy 两份文件两条 crontab 路径 / ~/ontology symlink vs repo 路径) **(3) 防御本身是事故面** — "再加一层治理"往往不是答案，"缩小接缝"才是(减少一物多形、缩小 dev-production 差距、让观察者只读)。**治理验证"代码符合规则"，验证不了"规则符合现实/部署符合假设"——87 不变式全在仓库内层验证仓库自己，事故住在仓库与真实 Mac Mini 的接缝里(无测试覆盖)。** 平衡视角：很多"意外"是免疫系统开火(暴露潜伏债)，零意外可能只是免疫系统瞎了(MOVESPEED 潜伏 60 天)。目标不是"零意外"，是"快速数据驱动根因诊断 + 持续退役复杂度"。详见 `ontology/docs/cases/why_so_many_incidents_2026_06_05_reflection.md` + MR-22(sunset-over-accretion) + MR-23(audit-observes-never-mutates)。（2026-06-05 深度反思：一天五版意外频发，逐层剖析五根因——组合非复杂/地图≠领土/观察者改被观察者/不完整修复伪装完整/潜伏条件累积。） |
| 35 | **🔴 给用户的终端命令块禁止注释行（2026-06-11 用户最终指令）** | 任何贴给用户复制粘贴执行的 shell 命令块,**绝对不带 `#` 注释行、不带行内中文括号说明**——zsh `interactive_comments` 默认 OFF 把 `#` 当命令、把 `（(` 当 glob 限定符,已多次报错（2026-06-11 升级阶段 1 连炸两次 `command not found: #` + `unknown file attribute`；V37.9.56-hotfix2 / V37.9.32 同源 quirk 家族）。说明文字写在命令块**外面**的正文里；命令块内只有纯命令。多步操作拆成多个独立命令块,每块可整段粘贴零报错。这同样适用于写给用户的文档中的可执行示例块。 |

### 🔴 异常分析宪法（原则 #26 展开，无例外强制执行）

> **修代码之前先画图。画不清因果链 = 还没理解问题。**

遇到任何 bug/异常/故障，必须按以下流程输出，**不可跳过任何步骤**：

#### 步骤一：完整因果链架构图（强制，必须是第一个输出）

按**时间线 × 层级 × 逻辑 × 架构**四维度，画从上游触发到下游用户感知的全链路 ASCII 图：

```
HH:MM  [组件A] 事件描述
       │
       ├─ [组件B] 具体行为 → 具体错误码/现象
       ├─ [组件C] 因为B的错误 → 触发什么后果
       │
HH:MM  [组件D] 下游事件
       ├─ 调用链: 组件X(:端口) → 组件Y(:端口)
       ├─ 组件Y 尝试A → 失败（具体原因）
       ├─ 组件Y 尝试B → 失败（具体原因）
       ├─ 组件Y 返回错误码
       │
       ├─ [消费方] 收到错误 → 但未正确处理
       ├─ 具体代码逻辑: variable = "" ← 标注关键 bug
       ├─ 具体检查: if condition → TRUE/FALSE ← 标注为什么没拦住
       └─ [用户] 最终感知到的现象
```

**四维度要求**：
- **时间线**：左侧标注精确到分钟的时间戳
- **层级**：标注每个组件名称和端口（如 Adapter:5001、Proxy:5002）
- **逻辑**：标注关键代码分支的 TRUE/FALSE 走向和变量值
- **架构**：标注组件间调用关系和错误传播路径

#### 步骤二：三层根因（触发器 → 放大器 → 掩护者）

| 层级 | 问题 | 发现 |
|------|------|------|
| **触发器** | 什么外部事件引爆？ | （填写） |
| **放大器** | 什么架构缺陷让影响扩散？ | （填写） |
| **掩护者** | 什么缺失让问题被隐藏到用户发现？ | （填写） |

#### 步骤三：时间线还原表

| 时间 | 事件 | 影响 |
|------|------|------|
| HH:MM | ... | ... |

#### 步骤四：为什么以前没发生（条件组合分析）

| 条件 | 以前 | 现在 |
|------|------|------|
| 条件A | ... | ... |

必须找到**多条件组合**：哪些条件单独出现不会触发，组合才触发。

#### 步骤五：喂养本体工程

- 案例文档：写入 `ontology/docs/cases/`
- 提炼 governance 不变式（INV-xxx）加入 `governance_ontology.yaml`
- 更新相关原则（如有新认知）

**参考案例**：`ontology/docs/cases/dream_quota_blast_radius_case.md`

### 🟡 按需查阅（操作 & 架构参考）

<details>
<summary>展开查看完整原则列表（16条）</summary>

**操作类**
- **故障先回滚** — 线上故障 → `git checkout v26-snapshot` 恢复服务 → 再排查根因
- **收工全量同步** — "今天工作结束" → `bash preflight_check.sh` 全面体检 → 扫描全部文档同步当日变更 → 提交推送
- **每日文档刷新** — `CLAUDE.md` + `docs/config.md` + `docs/openclaw_architecture.md` 在开工/收工时强制 read → write
- **纯推理绕过Gateway** — 不需要工具的LLM任务直接 curl 调 API，禁止用 `openclaw agent`（#94）
- **macOS sed禁用OR语法** — `\|` 在 BSD sed 不支持，用 Python 替代
- **禁用交互式编辑器** — git merge 用 `--no-edit`，commit 用 `-m`
- **crontab 安全操作** — **严禁 `echo ... | crontab -`**（2026-03-25事故：清空全部 cron），必须用 `bash crontab_safe.sh add '<行>'`
- **分支合并由用户在GitHub操作** — 推送到 `claude/xxx` 分支 → 用户合并 PR → **⚠️ 合并后下一步首先同步 Mac Mini，不做任何其他操作**（`git fetch origin main && git reset --hard origin/main`）→ 同步后再测试（见必查 #14，2026-04-06 再次踩坑）
- **Mac Mini 同步用 reset 不用 pull** — `git fetch origin main && git reset --hard origin/main`（Mac Mini 是纯消费端，无本地 commit；`git pull` 会因历史 merge commit 导致分叉失败）
- **全量测试三层标准** — 单测通过 ≠ 测完，必须 full_regression + preflight + **WhatsApp 业务验证**（见必查 #15）

**战略类（导师建议 2026-04-03）**
- **不再是桥接器，是控制平面产品** — 项目已远超 "bridge"，实际是 agent runtime control plane。旗舰叙事：`OpenClaw Runtime Control Plane for Tool-Calling Agents`
- **沿此仓库继续长 12 个月** — 不轻易切换去做完全不同的大项目，把这个仓库做成第一性代表作
- **下次汇报准备 5 样东西** — 版本变化 + 1-2 个关键架构图 + benchmark 数据 + 一次真实故障案例 + 对下一阶段的取舍判断

**架构类**
- **进程管理单一主控** — Gateway 由 launchd 管理，禁止再加 cron watchdog（#95）
- **cron 脚本显式声明 PATH** — 首行 `export PATH="/opt/homebrew/bin:/opt/homebrew/sbin:$PATH"`
- **健康检查只检目标组件** — `curl localhost:18789`，不走完整 LLM 链路
- **`--thinking` 参数** — 合法值：`off, minimal, low, medium, high, adaptive`（禁止 `none`，#92）
- **工具数量 <= 12** — 超出导致模型混乱；每任务工具调用 <= 2次
- **双 cron 职责分工** — 确定性脚本用 system crontab；需 LLM 参与的用 openclaw cron
- **开发流程** — Claude Code 只推 `claude/` 分支，Mac Mini 只从 main 拉取，避免双向提交同一分支

</details>

## 系统定位：三平面架构

> 来源：2026-04-01 外部专业评审反馈 + 2026-04-03 导师战略复盘

```
控制平面（先做强 → 60%→90%）：治理、限流、降级、观测、审计
  → V34: Provider Compatibility Layer (providers.py) 已实现
能力平面（持续演进 → 80%）    ：模型路由、工具编排、多模态能力
  → V34: 兼容性矩阵 + 能力声明 (ProviderCapabilities) 已实现
记忆平面（长期投入 → 60%）    ：知识沉淀、冲突消解、可信度评分
  → V2 路标: Memory Plane v1 统一叙事（将 5 个散落组件统一）
```

**核心原则：控制平面先行。否则能力越强，系统越难控。**

### 导师确立的三个高价值模块（V34+）

| 模块 | 目标 | 当前基础 | 路标 |
|------|------|----------|------|
| **Provider Compatibility Layer** | auth/chat/tool-calling/multimodal/streaming/fallback 标准接口 | `providers.py`+`adapter.py` 重构完成 | **V1 (in progress)** |
| **Agent Reliability Bench** | 系统性可靠性评测（7场景47检查：provider宕机/tool timeout/malformed args/oversized/kb miss-hit/cron drift/state corruption） | `reliability_bench.py`+`gameday.sh` | **V2 (✅ V36 done)** |
| **Memory Plane v1** | 4层统一接口（KB语义/多媒体/偏好/状态）+ query/context/stats + 优雅降级 | `memory_plane.py` + 5个底层组件 | **V2 (✅ V36 done)** |

## 当前待办（按导师 V1/V2/V3 路标组织）

> 来源：2026-04-03 导师战略复盘。路标 = 时间窗口 + 成功标准。详见 `docs/strategic_review_20260403.md`

### V1 路标（0-4 个月）：别人能跑

| 优先级 | 任务 | 状态 |
|--------|------|------|
| **V1-P0** | **Provider Compatibility Layer**：`providers.py` BaseProvider 抽象 + **7 个实现** + ProviderRegistry + 能力声明 + CLI 兼容性矩阵（V34 实现，V35+ 扩展至 7 provider） | ✅ V35+ 完成，7 provider 生产验证通过 |
| **V1-P0** | **兼容性矩阵 + SLO Benchmark 证据**：`docs/compatibility_matrix.md` + `slo_benchmark.py` + `docs/slo_benchmark_report.md`（5/5 PASS，p95=459ms） | ✅ V35 完成 |
| **V1-P1** | **一键启动 + 最小 demo + golden test trace**：`quickstart.sh` 4阶段（前置检查→启动→健康→demo），19/19 通过，`docs/golden_trace.json` | ✅ V35 完成 |
| **V1-P1** | **可复现证据**：Quick Start + golden trace + SLO benchmark report 均已入库 | ✅ V35 完成 |

### V2 路标（4-8 个月）：别人敢用

| 优先级 | 任务 | 状态 |
|--------|------|------|
| **V2-P0** | **Agent Reliability Bench**（导师建议模块二）：`reliability_bench.py` 7场景47检查（Provider宕机/工具超时/畸形参数/超大请求/KB未命中/Cron漂移/状态损坏），mock-based可在dev运行，36单测 | ✅ V36 完成 |
| **V2-P0** | **Memory Plane v1 统一叙事**（导师建议模块三）：`memory_plane.py` 4层统一接口（KB语义/多媒体/偏好/状态）+ query/context/stats API + 45单测 + 架构文档 | ✅ V36 完成 |
| **V2-P1** | **运维韧性证据**：`docs/resilience_report.md` — 7场景故障注入实验 + Recovery Time 汇总 + Dev Bench vs Production GameDay 对比 + 5项改进建议 | ✅ V36 完成 |
| **V2-P1** | **SLO Dashboard**：`slo_dashboard.py` 历史快照追踪 + sparkline 趋势 + cron 定时采集 + 31 单测 | ✅ V36 完成 |
| **V2-P1** | **semver 版本治理**：`VERSION` 文件 + /health 端点暴露版本 + changelog 格式升级 | ✅ V36 完成 |
| **V2-P1** | **安全边界说明文档**：`docs/security_boundaries.md`（8节：认证/网络/输入验证/数据保护/LLM安全/运维/评分/已知风险） | ✅ V36 完成 |
| **V2-P1** | **Memory Plane v2**：跨层去重（filename+text）+ 置信度加权（4层权重+新鲜度衰减）+ 冲突消解（优先级vs偏好矛盾检测）+ 64单测 | ✅ V36 完成 |

### V3 路标（8-12 个月）：别人会扩展

| 优先级 | 任务 | 状态 |
|--------|------|------|
| **V3** | **Provider Plugin Interface**：YAML/Python 插件 + 合约验证 + 能力路由 + auto-discovery fallback chain + Extension Guide + 128 单测 | ✅ V37 完成 |
| **V3** | **Tool Policy Plugin + Memory Plane Plugin**：可插拔的工具策略和记忆平面扩展 | 待启动 |
| **V3** | **Job Template/Registry SDK + Extension Guide**：让别人能基于框架扩展 | 待启动 |

### 话语权输出（持续推进）

| 类型 | 任务 | 状态 |
|------|------|------|
| 架构型 | **Why Agent Systems Need a Control Plane** — `docs/articles/why_control_plane.md`（问题→三平面架构→7场景证据→5条教训→立场） | ✅ V36 完成 |
| 证据型 | **Benchmark Report** / **Failure Injection Report** / **Lessons from 461-test Regression** | 待写 |
| 立场型 | **为什么 agent 系统首先是治理问题** / **为什么 control plane 必须先于 capability plane** | 待写 |
| **学术论文** | **When Errors Become Narratives: A Longitudinal Taxonomy of Silent Failures in a Production LLM Agent Runtime** — ArXiv 论文（fail-plausible 概念 + 5 类 taxonomy + 22 postmortem 实证），`docs/paper/silent_failures_taxonomy/` | ✅ V37.9.139 第一稿完成，待用户决策 7 项（DECISIONS_NEEDED.md）后投稿 |
| 立场型 | **Why Enterprise AI Needs Ontology Before It Needs More Models** — Ontology+LLM+Agent 三角架构论述 | ✅ V36.2 完成（EN dev.to + ZH 知乎发布） |

### Ontology 子项目（终态架构：Semantic Control Plane）

> 终态架构文档：`ontology/docs/architecture/target_architecture.md`
> 迁移路径：Phase 2 Shadow（完成）→ Phase 3 渐进替换（✅ P0 已切换）→ Phase 4 完全推理 → Phase 5 `pip install ontology-engine`（终极目标）

#### Phase 2 已完成（Shadow 观察，V36.1-V37.1）

<details>
<summary>展开查看 17 项已完成</summary>

| 任务 | 版本 |
|------|------|
| Ontology KB 目录结构 + 初始文件（7 文件） | V36.1 |
| 论文监控加 ontology 关键词（ArXiv/S2/DBLP） | V36.1 |
| X 监控加 ontology 人物（Marcus/Leskovec/Witbrock/Palantir×3） | V36.1 |
| Ontology 独立子项目：engine.py+tool_ontology.yaml+diff.py+宪法+PoC+tests | V36.2 |
| Tool Ontology Engine：81条声明式规则 + 推理引擎 + 一致性校验 | V36.2 |
| Ontology 宪法：6条+最高条款+价值评估矩阵 | V36.2 |
| BFO/DOLCE/UFO 流派对比、Neuro-Symbolic、供应链本体 | V36.1 |
| 语义查询 PoC：从枚举到推理 | V36.2 |
| 特性开关 Phase 1：equivalence proof + 3模式 rollback | V36.2 |
| 验证深度三层模型：声明/运行时/效果 + MR-6 + MRD-LAYER-001 | V36.3 |
| classify_tool_call() 从属性推理 risk_level + policy_tags | V36.3 |
| Feature Flag Phase 2：shadow 模式 Mac Mini 生产上线 | V36.3 |
| 立场文章：Why Enterprise AI Needs Ontology（EN+ZH 发布） | V36.2 |
| Governance Ontology v3：17不变式+35检查+6元规则+执行引擎 | V37.1 |
| Phase 0 元规则自主发现：23 个未覆盖 job | V36.2 |
| 对抗审计 ontology-native 化 + 每日定时审计 + 效果层启动 | V37.1 |
| Ontology 专属信息源（4 RSS + 两层过滤 + LLM 摘要 + Discord） | V37.1 |

</details>

#### Phase 3: 渐进替换（近期，P0-P1）

| 优先级 | 任务 | 状态 | 说明 |
|--------|------|------|------|
| **P0** | **ONTOLOGY_MODE=on 切换**：引擎数据替代硬编码 | ✅ V37.8.14 完成 | 等价验证通过，249 测试，已切换为默认 |
| **P0** | **filter_tools() 改用引擎**：内部调用 `ontology.query_tools()` 替代 `ALLOWED_TOOLS` 枚举 | 待启动 | 依赖 ONTOLOGY_MODE=on |
| **P0** | **fix_tool_args() 改用引擎**：参数修复调用 `ontology.resolve_alias()` 替代硬编码映射 | 待启动 | 依赖 ONTOLOGY_MODE=on |
| **P1** | **夜间阻止语义化**：从手动维护阻止列表改为 `infer("side_effects==true")` 自动覆盖 | 待启动 | Phase 3 标志性交付 |
| **P1** | **新工具只加 YAML**：推广 V37 Provider Plugin 模式到 Tool，新增工具零 Python 改动 | 待启动 | 需要 Tool Plugin YAML schema |
| **P1** | **元规则扩展**：MR-7 新策略必须有 shadow 观察期 / MR-8 概念变更触发影响分析 | 待启动 | 治理体系自我演进 |
| **P1** | 用本体论视角重新审视 OpenClaw（深度版，含工具语义本体实验） | 进行中 | `cases/openclaw_as_ontology.md` |

#### Phase 4: 完全推理（中期，P1-P2）

| 优先级 | 任务 | 状态 | 说明 |
|--------|------|------|------|
| **P1** | **domain_ontology.yaml**：六域概念模型（Actor/Tool/Resource/Task/Provider/Memory），概念间关系推理 | ✅ V37.9.9 骨架 + V37.9.12 wiring API (`find_by_domain`) | Layer 1 终态：从工具列表到领域模型 |
| **P1** | **policy_ontology.yaml**：策略声明式定义（静态+时序+路由三类策略统一） | ✅ V37.9.9 骨架 + V37.9.12 `evaluate_policy()` + V37.9.13 P2 context evaluator + 2 条 policy 切换 | Layer 2 终态部分兑现：static + 6 条 contextual/temporal 已 wire，剩 4 条待注册 |
| **P1** | **三阶段门控**：Pre-check（前置条件）→ Runtime Gate → Post-verify（后置验证）接入请求管线 | ✅ V37.9.15 shadow wiring 完成（`ontology/three_gate.py` + tool_proxy 两处调用点 + INV-GATE-001 14 checks + 66 新单测） | Layer 3 终态部分兑现：P3.1 (shadow→on 一周观察) / P3.2 (第三条 policy 切换) / P4 (enforcement 行为) 待启动 |
| **P2** | **contextual/temporal policy 的 context evaluator**：实现 hour_of_day / request-context matcher 让 `evaluate_policy().applicable` 对非 static policy 也返回真值 | ✅ V37.9.13 完成 — 6 个 matcher（quiet_hours / task_match / has_alert / has_image / need_fallback / data_clean_keywords）+ `_CONTEXT_EVALUATORS` dispatch + 三档 reason（needs_context / no_evaluator / evaluator_error） | 未注册 policy 走"可扩展路径"不崩溃 |
| **P2** | **第二条 policy 切换**：选 `max-tool-calls-per-task` 或 `max-request-body-size` 做第二次 wiring，复用 V37.9.12 `_resolve_*` 模式 | ✅ V37.9.13 完成 — `_resolve_max_tool_calls_per_task_limit()` 镜像 V37.9.12 5 档 safe-fallback + MR-8 copy-paste 防御源码守卫 | 验证 wiring 模式可扩展性 ✓ |
| **P2** | **审计带规则链**：每条审计记录包含 policy_evaluated + rule_chain + rationale | 待启动 | Layer 4 终态：从"做了什么"到"基于什么规则" |
| **P2** | **策略冲突检测**：策略间矛盾自动发现（如夜间阻止 vs 紧急通知） | 待启动 | 策略引擎高级能力 |
| **P2** | **影响分析工具**：`ontology.impact_analysis("修改 max_tools")` → 受影响策略/工具列表 | 待启动 | 变更安全保障 |
| **P2** | **效果层覆盖率 ≥ 60%**：30+ 不变式中至少 18 个有 L3 效果验证 | 待启动 | MR-9 元规则 |

#### Phase 5: 对外输出（长期，V3 路标对齐）— 终极目标：`pip install ontology-engine`

> **项目终极目标**：将引擎和规则解耦为二层结构，让任何 Agent Runtime 项目只需编写自己的 YAML 就能获得工具治理+语义查询+governance 审计能力。
>
> **Layer 1 — `ontology-engine` 通用 pip 包**（项目无关）：
> - Tool Ontology Engine：YAML → 白名单/schema/参数映射/别名解析/语义查询/分类
> - Governance Checker 框架：5 种 check 执行器 + 元规则自动发现 + 三档特性开关(off/shadow/on)
> - 策略推理引擎：`infer_policy_targets("side_effects==true")` 零硬编码
>
> **Layer 2 — 项目级 YAML 配置**（项目特定）：
> - `tool_ontology.yaml`：工具声明（名称/类别/副作用/参数/别名）
> - `governance_ontology.yaml`：治理规则（不变式/元规则/check 定义）
> - `providers.d/*.yaml`：Provider 插件
>
> **当前基础**：Phase 3 ONTOLOGY_MODE=on 已切换，52 不变式 100% job 覆盖，89 引擎单测。
> **瓶颈**：领域本体(Phase 4) + 引擎包化(Phase 5) 尚未开始。

| 优先级 | 任务 | 状态 | 说明 |
|--------|------|------|------|
| **P1** | **引擎包化**：`ontology-engine` 可独立 `pip install` 的通用治理引擎 | 待启动 | **终极目标核心交付物** |
| **P2** | **Tool Policy Plugin**：`tool_policy.yaml` 声明式工具策略扩展接口 | 待启动 | V3 路标对齐 |
| **P2** | **Memory Policy Plugin**：`memory_policy.yaml` 记忆平面策略扩展 | 待启动 | V3 路标对齐 |
| **P2** | **Ontology Extension Guide**：第三方基于 ontology 框架扩展的指南 | 待启动 | V3 路标对齐 |
| **P3** | 证据型文章：从 17 不变式到 52 的治理演进实战 | 待启动 | 话语权输出 |

### 现有功能任务（V1 稳定后继续推进）

| 优先级 | 任务 | 状态 |
|--------|------|------|
| 中 | **数据清洗 Phase 2**：三 Agent 架构（Profiler/Planner/Executor，用 `sessions_spawn`）、语义去重、自定义规则 | active |
| deferred | **PA 子 Agent 委派**：`sessions_spawn` + `sessions_send`。V35 PoC 完成：链路通（显式触发可用），但 Qwen3 隐式触发不可靠（优先从上下文回答）。等下一代模型 | deferred |
| deferred | **PA 长期记忆**：Qwen3 不主动调用 memory 工具，等模型升级后重新验证 | blocked |
| 低 | **可迁移性抽象**：去除个人/场景定制痕迹，抽象成别人也能迁移的框架（导师指出三块差距之一） | V2-V3 |
| 低 | **记忆系统分层**：短期/长期/任务，含冲突消解和可信度评分 → 纳入 Memory Plane v1 | V2 |
| 低 | **成本-质量-时延联动调度**：根据查询复杂度动态选择模型/参数组合 | V2+ |
| 低 | 知识图谱：AI 大模型领域知识图谱构建（需 6-12 个月数据积累） | V3 |
| 低 | 货代 Watcher V3：Bing News API 替代 GoogleNews | 按需 |
| 低 | 语音消息支持：WhatsApp 语音→STT→LLM 回复 | 按需 |
| 低 | **视频号内容转录分析**：firethinker 视频号监控 → STT 转录 → LLM 提炼 → KB 沉淀 | 按需 |
| 低 | KB 静态加密：status.json / index.json 使用 age/gpg 加密存盘 | 按需 |

### 已完成里程碑（V27-V35）

<details>
<summary>展开查看 25+ 项已完成任务</summary>

| 版本 | 任务 |
|------|------|
| V35 | **V1 路标完成** — SLO Benchmark 实验报告（5/5 PASS, p95=459ms）+ Quick Start 一键 demo（19/19）+ Golden Test Trace + Sub-agent PoC（链路通，deferred）+ 605 测试 |
| V34 | **Provider Compatibility Layer**：providers.py + 48 单测 + 兼容性矩阵 + adapter.py 重构 |
| V33 | SLO 最小集 + 阈值中心化 + 旅程级 E2E 进 CI + 故障快照机制 + Job 分层治理 + Fallback Matrix + 变更影响评估 + GameDay 故障演练 + Discord 双通道 + notify.sh + pip-audit |
| V32 | 配置中心化 + 变更审计 + config_loader.py |
| V30.5 | search_kb 混合检索 + 论文监控矩阵 5 源全覆盖 + DBLP |
| V30.4 | SOUL.md 激活 + 三方宪法闭环 + 方法论进化 |
| V30.3 | 数据清洗 Phase 1 + 自定义工具注入 + WhatsApp E2E |
| V30.2 | 安全评分体系 + 审计日志 + 持续安全机制 |
| V30.1 | status.json 实时刷新 + KB 完整性 + 全量回归 374→461 测试 |
| V30 | crontab 事故修复 + cron 安全三层保护 |
| V29.x | KB 搜索/RAG/趋势/MM 索引/Fallback/备份/Multi-Agent |
| V28.x | preflight 体检 + WhatsApp 保活 + CI + pre-commit |
| V27.x | Proxy 拆层 + 任务注册表 + auto_deploy + 回滚机制 |

</details>

## 远程连接（本机）

```bash
ssh bisdom@10.102.0.23       # 办公室内网（en1 Wi-Fi, V37.9.84+ DHCP 更新）
ssh bisdom@10.120.230.23     # ZeroTier（回家后）
```

## Git 仓库

```
git@github.com:bisdom-cell/openclaw-model-bridge.git
```
Remote 已改为 SSH（v25修复HTTPS认证失败）。
回滚标签：`v26-snapshot`（V27变更前的完整快照）。

### Git 分支规则
- 默认直接在 main 分支上开发提交，除非任务指令明确指定其他分支
- 即使 session 系统指令指定了 `claude/xxx` 分支，仍优先遵守本规则在 main 上开发
