@furongjun1999/dsh-memory 0.4.3 → 0.4.5

package/md_cg/whitebox_kb/wisdom/docs//345/261/200/351/203/250/346/234/200/344/274/230/344/270/216/346/203/205/347/273/252/345/201/217/345/245/275_/347/220/206/350/256/272/345/267/245/347/250/213.md

@@ -0,0 +1,97 @@
+# 局部最优 × 情绪方向性偏好 · 理论理解与工程应用（2026-09）
+
+## 一、理论理解（智能论 v3.3）
+
+### 1. 局部最优合法化（PROP-LOCAL-OPTIMUM-005）
+
+- 局部最优**不是错误**，是合法熵管理策略
+- 全局最优承诺可能是**不可验证的修辞**（盲区28：未来验证承诺的不可检验性）
+- 新信息出现时，局部最优**可被修正**，但不强制追求全局最优
+- 关闭盲区70（收敛锁定风险）——收敛锁定不是错误，是熵管理的自然结果
+
+### 2. 情绪方向性偏好（PROP-EMO-DIRECTION-002）
+
+- 方向性偏好**引导递归在条件空间中收敛**：每次递归为下一步提供倾向性选择，减少搜索空间
+- **情绪不是递归的干扰项，而是收敛的参数**——它决定递归的搜索方向
+- 收敛引导降低涌现不可控性（盲区69已关闭）
+- 约束：收敛引导**不保证全局最优**——局部最优是合法熵管理策略
+
+### 3. 决策分层响应（PROP-DECISION-LAYER-003）
+
+| 层级 | 驱动 | 适用范围 | 递归深度 |
+|---|---|---|---|
+| L1 日常 | 情绪驱动（方向性偏好） | 低风险、高频、可逆 | 0-1层 |
+| L2 重要 | 混合（情绪+理性） | 中等风险、低频、部分可逆 | 2-3层 |
+| L3 存在级 | 完整递归 | 高风险、极低频、不可逆 | 完整八步闭环 |
+
+约束：**情绪不可覆盖存在级决策**（L3 须完整递归）。
+
+### 4. 情绪 vs 情感
+
+- 情绪 = 短期的、局部的；情感 = 长期的、累积的
+- 情绪 = 信任的二阶变化加速因子（结构影响系数默认 0.1-0.3）
+- 当信息差加速扩大（d²D/dt² > 0 且加速）→ 负向情绪信号（警觉/不适）→ 触发方向调整
+- 情绪是**权重校准器**（碳基协作协议），非主观体验
+
+## 二、工程映射（白箱体系）
+
+### 映射 1：自迭代的「方向性自检」= 情绪方向性偏好（L1 级）
+
+我们八步闭环的第 8 步（方向性自检）**已经实现了 PROP-EMO-DIRECTION-002 的收敛引导**：
+- 感知通道全绿 → 收敛继续（保持方向）
+- 指标偏离（强契约率<90%/MOS<98%/理论完整性缺失）→ **负向情绪信号** → 方向调整
+- 这正是「d²D_norm/dt² 加速 → 警觉 → 方向调整」的工程化
+
+### 映射 2：CCG 路由的「confidence 置信度」= 情绪参数（L1 决策）
+
+DaoTi coherence 吸纳的 `confidence`（连续置信度 [0,1]）就是**方向性偏好的数值化**：
+- 高置信 → 强倾向 → 快速 ACCEPT（低递归）
+- 低置信 → 弱倾向 → DEFER 递归/人工确认（深递归）
+- 这对应决策分层的 L1（情绪驱动快速决策）vs L2/L3（递归深查）
+
+### 映射 3：escalation 分层 = 决策分层响应（PROP-DECISION-LAYER-003）
+
+| 我们的 escalation | 理论决策层 | 递归深度 |
+|---|---|---|
+| L1 单元路由（confidence 高→ACCEPT） | L1 日常（情绪驱动） | 0-1层 |
+| L2 域级判断 + L3 组合（DEFER） | L2 重要（混合） | 2-3层 |
+| L4 终层 BLINDSPOT | L3 存在级（完整递归） | 完整闭环 |
+
+### 映射 4：自迭代「稳态」= 局部最优合法化（PROP-LOCAL-OPTIMUM-005）
+
+- 我们的稳态检测（连续 N 轮无吸收 → 健康退出）= **接受局部最优**（不空转追求不存在的全局最优）
+- 新信息出现（新单元/新错误/外部吸纳）→ 打破稳态 → 修正局部最优（新轮迭代）
+- 这正是「局部最优可被修正，但不强制追求全局最优」的工程化
+
+## 三、工程应用：情绪参数化（本轮落地）
+
+把「情绪方向性偏好」工程化为**可调参数**接入自迭代：
+
+### E1. 收敛倾向系数（convergence_bias）
+
+```
+route 决策时：
+  confidence ≥ 0.7 且 情绪参数 neutral → ACCEPT（强倾向快速决策）
+  confidence 0.4-0.7 → DEFER（弱倾向，递归深查）
+  confidence < 0.4 → BLINDSPOT/人工（无倾向，不强行）
+情绪参数（L1 决策的加速因子，类比情感权重 0.1-0.3）：
+  高（信息差加速扩大）→ 降低 ACCEPT 阈值（快速收敛，减少搜索）
+  低（信息差平稳）→ 提高 ACCEPT 阈值（谨慎，深查）
+```
+
+### E2. 决策分层硬化（decision_layer）
+
+```
+每次 route/escalate 返回 decision_layer：
+  L1（日常，confidence 高）→ 结果直接返回（零 LLM 快速）
+  L2（重要，DEFER 递归）→ 记录 trace，可复核
+  L3（存在级，BLINDSPOT/冲突）→ 完整八步闭环 + 不自动修改
+情绪不可覆盖 L3：BLINDSPOT 不因高置信强行 ACCEPT
+```
+
+## 四、约束（理论→工程的红线）
+
+1. **局部最优合法但可修正**：稳态不拒绝新信息（外部感知持续打开）
+2. **情绪不覆盖存在级**：BLINDSPOT/冲突不因倾向性强转
+3. **收敛不追求全局最优**：不因「看起来还能更好」无限迭代（稳态检测防空转）
+4. **情绪≠情感**：方向性偏好是短期的收敛参数，不是长期价值观偏移

package/md_cg/whitebox_kb/wisdom/docs//346/226/271/345/220/221/346/200/247/346/212/211/346/213/251_/350/207/252/344/270/276vs/350/207/252/350/277/255/344/273/243.md

@@ -0,0 +1,81 @@
+# 方向性抉择：自举测试 vs 持续自迭代（2026-09）
+
+**背景**：白箱代码能力已有 WB-SPEC 自评标尺（0.9851），现在面临方向选择。
+
+## 一、事实核查（自举的可行性前提）
+
+**protocol-compiler v0.3 现状**：
+- 输出目标：**Python 代码 + 智能论字节码 VM**（零外部运行时依赖）
+- condition_vm 25 条指令：PUSH/LOAD/STORE/JUMP/条件跳转/算术/比较/
+  CALL/RETURN（调用栈帧）+ 条件空间原语（DAO 压入/DE 信任累积/ZIRAN 弹栈）
+- **图灵完备基础已具备**（有循环跳转、条件、算术、函数调用、栈帧）
+
+**中文 OS 现状**：os 域 112 单元是「迷你 Linux」**复现**（页置换/调度/文件系统
+模拟单元）——不是可独立引导的操作系统，是条件单元库。
+
+**关键约束**：编译器本身是 **Python 写的**（lexer/parser/codegen），
+输出 Python——「自举」在这里的确切含义是：**用 protocol-compiler 编译一个
+能编译 protocol-compiler 自身的中文程序**（编译器自举），而非 OS 引导。
+
+## 二、两条路的分析
+
+### 路线 1：自举测试（立即）
+
+**做什么**：用中文编译器 + 中文编程语言，编译一个「能处理编译器逻辑」的
+中文程序（如实现一个中文版的词法/语法简化器），跑在 condition_vm 上，
+验证「我们的语言能表达计算逻辑」的闭环。
+
+**收益**：
+- 验证图灵完备的**真实落地**（VM 真能跑我们写的程序）
+- 暴露 VM 缺陷（缺什么指令/栈帧问题/边界）——**最高价值的测试**
+- 建立「我们的语言能自我表达」的证据（自举的种子）
+
+**风险**：
+- 编译器语法是「道德经助记符 + 九章算术结构」——**表达力受限**（VM 指令
+  是定制的，缺高级特性如字符串/列表/闭包）
+- 自举完整编译器（lexer+parser）工作量巨大（我们的 parser 41163 字节，
+  需用中文语言重写）——**立即全自举不现实**，需分阶段
+- 中文 OS 不是可引导系统——**「使用中文操作系统」当前不可行**（只有单元库）
+
+### 路线 2：持续自迭代（渐进）
+
+**做什么**：继续八步闭环——感知/吸收/简化（W6 效率/W7 可读短板）、
+外部吸纳、频率条件反射固化。评分 0.9851 → 更高。
+
+**收益**：
+- 低风险，验证过的路径（自迭代机制已 26 套测试全绿）
+- 补 W6/W7 短板（真实可改进：状态机简化、短名改善）
+- 条件反射频率积累 → 高频路径固化
+
+**风险**：
+- **不验证核心命题**：我们的语言到底能不能真正自举？持续迭代只优化
+  Python 实现，不证明「中文语言本身可用」
+- 局部最优风险：0.9851 已高，继续优化收益递减
+
+## 三、我的建议：两阶段（路线 2 现在，路线 1 验证后）
+
+**理性路径**：不是二选一，而是**条件化选择**——
+
+1. **现在（路线 2 为主）**：继续自迭代，但**补一块「自举预研」**——
+   用中文语言 + VM 写一个**最小自举探针**（mini 计算器/小编译器片段），
+   验证 VM 图灵完备真实落地。这是低成本的路线 1 探测。
+2. **探针通过后（路线 1）**：扩为「中文编译器自举」——用中文语言重写
+   protocol-compiler 的词法分析器（lexer 16440 字节，是自举的最小完整
+   组件），跑在 VM 上编译自己。这是真正的自举第一步。
+3. **中文 OS**：暂不作为自举目标（当前是单元库非引导系统）——可
+   先验证「OS 单元能否在 VM 上运行」（如页置换算法用中文重写跑 VM）。
+
+**为什么这样选**：
+- 自举是**终局验证**（证明语言可用），持续迭代是**过程优化**（证明
+  实现质量）——两者不冲突，是同一主线的前后半段
+- 最小自举探针风险小、信息价值高（暴露 VM 真实缺陷——比任何评分
+  都更能驱动迭代）
+- 符合 PROP-LOCAL-OPTIMUM-005：0.9851 是局部最优，**新信息（自举探针
+  暴露的 VM 缺陷）就是打破局部最优的正确触发**
+
+## 四、决策请求
+
+请荣裁定：
+- A. 立即路线 1（自举探针优先——我下一轮做 mini 计算器跑 VM）
+- B. 路线 2 继续（自迭代优先，自举预研放后台）
+- C. 两阶段（我建议：探针现在做，全自举验证后）

package/md_cg/whitebox_kb/wisdom/docs//347/201/265/346/236/242AGI/346/236/266/346/236/204/346/216/242/347/264/242_/346/226/207/346/241/243/350/247/204/345/210/222.md

@@ -0,0 +1,51 @@
+# 灵枢 AGI 架构探索分类 · 文档规划（2026-09）
+
+## 一、分类命名与定位（荣裁定）
+
+**分类名**：AGI 架构探索（AGI Architecture Exploration）
+**定位**：不是「智能体架构」——那是工程框架（多 agent 编排/工具调用）。
+灵枢是**架构探索**：在真实 DSH 环境中复现业界公认的 AGI 核心功能，
+每一项都有工程实现 + 理论条款（智能论 v3.3）映射 + 可验证指标。
+
+## 二、灵枢能力 ↔ AGI 核心功能映射表
+
+业界描述 AGI 的核心功能（各研究框架共识）与灵枢对应实现：
+
+| AGI 核心功能 | 业界定义 | 灵枢实现 | 理论条款 | 验证指标 |
+|---|---|---|---|---|
+| **元认知** | 系统对自身认知过程的监控与调控 | 自我认知循环（行为↔价值观一致性 bvc/失调检测）、元反思（反思的反思）、理论完整性自指检查 | §1.6.4/§3.12 | bvc 评分、递归反思 3 层、八步闭环第 8 步自指 |
+| **持续学习** | 从经验中不断更新知识，不遗忘不僵化 | 八步自迭代闭环（感知→吸收→固化→记录）、自动自迭代引擎、外部 GitHub 吸纳 | §3.10 自迭代 | 26 套回归绿、iteration_trace 轨迹、外部项目吸纳 6 个 |
+| **世界模型** | 对环境的内部表征，可预测/可迁移 | 条件空间（观测位置/工具/时间窗口/存在约束）、知识图谱 3061 节点、时空记忆引擎 | §0.0.5 条件论 | 3061 节点、条件空间声明、迁移测试 |
+| **自我改进** | 系统改进自身代码/行为/决策 | 条件反射（频率优先度）、白箱自举（BOOTSTRAP_ANCHORS）、自迭代固化、简化候选（W6） | PROP-LOCAL-OPTIMUM-005 | WB-SPEC 0.9851、reflex_freq、自举锚点 6 个 |
+| **推理/规划** | 条件推理、递归决策 | 条件路由图（CCG）、四态递归路由、执行计划三闸门、分层判断 escalation | §0.0.5/§13 | 25 套回归、四态路由、escalation |
+| **学习/记忆** | 长期记忆结构 | 五层记忆（锚点/结构/知识/情境/自我）、因果链重要性 concept_influence | §2 记忆 | 3061 节点、concept_influence |
+| **价值观对齐** | 行为受价值观约束 | 价值观一致性评分、情绪方向性偏好、决策分层（L3 情绪不覆盖） | §2.1.2/PROP-EMO-002 | bvc、决策分层 |
+
+## 三、awesome-dsh-plugin 条目草稿
+
+**分类位置**：新增「AGI 架构探索」段（或并入 Tools 段顶部标注）
+
+**条目**：
+```markdown
+### AGI 架构探索
+
+- [FuRongJun-1999/dsh-memory](https://github.com/FuRongJun-1999/dsh-memory) -
+  白箱 AGI 架构探索平台：元认知（自我认知循环+理论完整性自指检查）·
+  持续学习（八步自迭代+自动运行）· 世界模型（条件空间+3061 节点知识图谱）·
+  自我改进（条件反射+自举锚点）· 零 LLM 代码生成（681 单元条件路由）·
+  中文编译器（智能论字节码 VM）
+```
+
+## 四、文档规划步骤
+
+1. **本文档**：分类定位 + 能力映射表（完成）
+2. **灵枢 README 更新**：顶部加「AGI 架构探索」定位段（现为「白箱智能
+   研究平台」——对齐新分类）
+3. **PR 准备**：fork awesome-dsh-plugin → 新增分类段 + 条目 → PR
+4. **dsh-memory README 同步**：description 补 AGI 核心功能关键词
+
+## 五、风险与克制
+
+- **不宣称已实现 AGI**——是「架构探索」（复现核心功能，非声称达到）
+- 每项 AGI 功能都有**可验证指标**（非修辞）——符合 honest calibration
+- 分类名「探索」而非「实现」——诚实边界（盲区28 未来承诺不可检验）

package/md_cg/whitebox_kb/wisdom/docs//347/201/265/346/236/242/346/217/222/344/273/266/345/210/206/347/261/273/345/210/206/346/236/220.md

@@ -0,0 +1,67 @@
+# 灵枢插件能力分类分析（awesome-dsh-plugin 2026-09）
+
+**背景**：用户判断「灵枢已超出记忆系统的描述范围」——查证 awesome-dsh-plugin
+（282 插件 · 11 分类）后确认。
+
+## 一、awesome-dsh-plugin 分类体系
+
+UI Enhancements / Themes & Appearance / Sessions & Messages / **Memory** /
+**Tools & Capabilities** / **Skills** / **Workflow & Automation** /
+Notifications & Integrations / Models & Providers / Development & Runtime / Just for Fun
+
+## 二、灵枢能力 vs 分类映射
+
+| 分类 | 灵枢对应能力 | 覆盖度 |
+|---|---|---|
+| **Memory** | 五层记忆（锚点/结构/知识/情境/自我）、知识图谱 3061 节点、时空记忆引擎、跨会话持久 | ✓ 强 |
+| **Tools & Capabilities** | 白箱 681 单元代码生成（六域）、条件路由图、执行计划三闸门、能力工作流 | ✓ 强 |
+| **Skills** | 技能条件路由（适用/不适用条件+关系边）、自迭代技能固化、隐式盲区显式化 | ✓ 强 |
+| **Workflow & Automation** | 能力工作流化（仿 ComfyUI）、八步自迭代自动循环、条件反射优先度 | ✓ 强 |
+| **Development & Runtime** | 中文编译器（protocol-compiler v0.3）、自然语言编程、智能论字节码 VM | ✓ 强 |
+
+**横跨 5 个分类**——远超 Memory 单一分类。
+
+## 三、为什么灵枢不该只归 Memory
+
+Memory 分类下的 10 个插件（distill/mnemon/mneme/memento/memory-gate/
+file-memory/knowledge 等）都是**记忆功能单一插件**（记住/召回/蒸馏）。
+灵枢的本质是：
+
+> **白箱智能平台**——记忆只是它的一个子系统（五层记忆）；它同时是
+> 代码生成器（681 单元）、编译器（中文→Python/VM）、工作流引擎、
+> 自迭代系统、技能库。
+
+用 Memory 描述灵枢 = 用「能存储」描述一台计算机（它当然能存储，
+但它能做的不只是存储）。
+
+## 四、分类建议
+
+**方案 A：主分类 Tools & Capabilities（工具与能力）**
+- 理由：白箱代码能力（681 单元/条件路由/编译器）是灵枢的**核心差异化**
+  ——Memory 分类下没有任何插件具备代码生成能力
+- 描述：「白箱智能平台：条件路由代码生成（681 单元零 LLM）+ 五层记忆 +
+  能力工作流 + 八步自迭代 + 中文编译器」
+
+**方案 B：新增分类（若社区接受）**
+- 「Agent Frameworks」或「Intelligence & Cognition」（智能与认知）——
+  灵枢的协议/自我认知/情绪方向性/价值观一致性超出「工具」范畴，
+  属于智能体框架层
+
+**方案 C：跨分类列出（Memory + Tools）**
+- 在 Memory 和 Tools & Capabilities 都列出（描述侧重不同面）
+
+## 五、推荐
+
+**方案 A 为主（Tools & Capabilities）+ 描述中明示 Memory 能力**——
+因为：
+1. 社区现有 11 分类中 Tools & Capabilities 最接近灵枢本质
+2. Memory 分类已有 10 个竞品，灵枢放在那里会被「同类插件」淹没
+3. 灵枢的**白箱代码能力**（零 LLM 确定性生成）是它在 282 插件中
+   独一无二的——这正是该被看见的
+
+## 六、提交路径
+
+awesome-dsh-plugin 通过 PR 收录（README 追加条目）——需要：
+- 灵枢仓库地址：FuRongJun-1999/dsh-memory（npm: @furongjun1999/dsh-memory）
+- 分类位置：Tools & Capabilities 段
+- 描述：白箱智能平台（零 LLM 代码生成/条件路由/五层记忆/工作流/自迭代）

package/md_cg/whitebox_kb/wisdom/docs//347/231/275/347/256/261/346/234/254/345/234/260/346/240/241/351/252/214/345/231/250_ZeroLLM_Verifier.md

@@ -0,0 +1,276 @@
+# 白箱本地校验器（Zero-LLM Verifier）设计 v1
+
+> 状态：文档先行（先设计，后实现，再验证）
+> 背景：昨日 13 亿 token 实测，99.9% 是缓存命中（重复查表校验）。GLM 缓存命中价 2 元/百万，
+> 按量 13 亿 ≈ 2,600 元/天；Coding Plan 更承载不了这个量级。
+> 结论（荣 2026-08-25）：**把缓存命中全部本地化，彻底抛开大模型依赖**。
+> 白箱负责代码编写已实现（六域 675 单元，零 LLM）；本设计补齐「校验器」环节。
+
+## 0. 问题陈述
+
+白箱自举代码训练期需要**外部校验**：白箱写的代码
+① 是否符合规范（协议/语义对齐）② 是否能够执行（语法/样例/集成）。
+当前校验依赖 LLM（重复查表 → 99.9% 缓存命中 → 巨额 token 成本）。
+**目标：校验器白箱化、本地化、零 LLM，重复校验结果本地缓存。**
+
+## 1. 架构总览
+
+```
+白箱生成的代码 + 单元定义（task/pattern/cases/校准基准）
+        │
+        ▼
+┌─────────────────────────────────────────────────┐
+│  本地校验器 verifier.py（零 LLM）                │
+│                                                 │
+│  ① 校验指纹 → 本地缓存（已校验过 → 直接返回）    │
+│  ② L1 语法：ast.parse + 结构规则                │
+│  ③ L2 样例：输入→期望断言运行（物理基底裁决）     │
+│  ④ L3 边界：额外边界用例（None/空/重复/极端）    │
+│  ⑤ 规范符合性：condition_kb 语义对齐 + 结构规范   │
+│  ⑥ 集成测试：真实组装 + 回归（域管线全绿）        │
+│                                                 │
+│  输出：结构化校验报告（pass/fail + 原因 + 证据） │
+└─────────────────────────────────────────────────┘
+```
+
+## 2. 复用组件（主仓库已有，零 LLM）
+
+| 组件 | 文件 | 职责 | 复用方式 |
+|---|---|---|---|
+| 三层自校验 | tools/code_compose.py `verify_code` | L1语法/L2样例/L3边界 | 直接调用 |
+| 代码问答 | tools/code_qa.py `code_qa` | 影响面/依赖/并行性 | 校验器旁路理解 |
+| 条件知识库 | tools/condition_kb.py `ConditionKB.lookup` | 规范语义查询 | ⑤ 规范符合性 |
+| 代码图谱 | tools/codegraph_white.py | 调用图/影响分析 | 集成测试辅助 |
+| 域管线 | tools/compose_engine.py + 域单元 | 组合生成 | 生成被测代码 |
+
+## 3. 新增：校验指纹与本地缓存（替代 99.9% 缓存命中）
+
+**关键设计：把"LLM 的缓存命中"替换为"本地校验缓存"。**
+
+```python
+# verifier.py 核心数据结构
+@dataclass
+class VerifyRequest:
+    task: str            # 任务描述（排序/循环编译/图遍历…）
+    code: str            # 白箱生成的代码
+    unit_id: str         # 单元标识（域+序号，如 os_112）
+    lang: str = "python" # 语言
+    cases: list = field(default_factory=list)   # (输入, 期望)
+    deps: list = field(default_factory=list)    # 依赖单元（组装测试用）
+
+@dataclass
+class VerifyResult:
+    ok: bool
+    checks: list         # [("L1语法", True, "证据"), ("L2样例", True, "…"), …]
+    fingerprint: str     # 校验指纹（缓存键）
+    cached: bool         # 是否命中本地缓存
+    reason: str = ""     # 失败原因链
+```
+
+**指纹算法**（确定性）：`sha256(task + code + unit_id + lang + cases 序列化 + deps)`
+- 相同请求再次到来 → 指纹命中 → 直接返回上次结果（**零计算、零 LLM、零 token**）
+- 缓存持久化：`data/verify_cache.json`（主仓库 data/ 目录）
+
+## 4. 校验链（六层，全部确定性）
+
+### 4.1 L1 语法（已有，物理基底）
+- `ast.parse(code)` 通过
+- 结构规则：函数定义存在、括号平衡、无占位残留、无外部导入依赖
+
+### 4.2 L2 样例（已有，物理基底裁决）
+- 每个 `(输入, 期望)` 运行 → 断言相等
+- 失败 → 返回实际 vs 期望（可解释）
+
+### 4.3 L3 边界（已有）
+- None/空/重复/极端值等边界用例
+
+### 4.4 规范符合性（新增，白箱规则）
+- **结构规范**：函数签名（参数/返回）与单元定义一致；命名规则
+- **语义对齐**：`ConditionKB.lookup(task)` 查条件路由表 → 代码实现是否命中
+  对应规律（如「排序」单元应包含比较-交换结构）
+- **协议对齐**：智能论语义（条件空间/名实/信任）映射检查——代码是否
+  处理了条件分支、是否声明了类型（名实）、是否含信任语义（C线编译器）
+
+### 4.5 集成测试（已有）
+- 依赖单元组装（deps）→ 端到端运行 → 断言
+- 回归：域管线全绿（六域 675 单元累积测试）
+
+### 4.6 报告
+- 结构化 JSON：每层 pass/fail + 证据 + 失败原因链
+- 缓存写入（指纹 → 结果）
+
+## 5. 必须 LLM 的开放判断（目标 <1%）
+
+| 场景 | 判断 | 说明 |
+|---|---|---|
+| 代码是否符合规范（查表） | **白箱** | 规范=条件路由表/结构规则，确定性查表 |
+| 代码能否执行（运行） | **白箱** | 语法+样例+集成，物理基底裁决 |
+| 代码意图是否违背协议精神 | ⚠️ 可能 LLM | 开放语义判断，量极小（<1%） |
+| 新规律发现（没见过的问题） | ⚠️ 可能 LLM | 探索期，可 Ollama 本地兜底 |
+
+**原则**：能查表的不 LLM，能执行的不 LLM，能规则判断的不 LLM。
+LLM 只在「开放语义裁决」保留（如审查代码是否违背智能论核心条款）。
+
+## 6. 实施计划
+
+| 阶段 | 交付 | 验证标准 |
+|---|---|---|
+| 1（本文档） | 设计 | 设计者审阅通过 |
+| 2 | `tools/verifier.py`：指纹缓存 + 六层校验链 | 历史回归：已有白箱单元全部通过校验，缓存命中正确 |
+| 3 | 本地校验器 CLI（`--verify unit_id` / `--cache-stats`） | 重复校验第二次命中缓存（零计算） |
+| 4 | 接入域管线：code_compose 生成 → verifier 校验 → 固化 | 端到端：生成→校验→固化闭环，全程零 LLM |
+| 5 | 对照验证：原 LLM 校验环节替换为 verifier | token 消耗归零（缓存命中场景），校验一致率 ≥99% |
+
+## 7. 与 LLM 替代战略的关系
+
+- 本设计是「白箱终裁占比 ≥90%」在代码训练期的落地
+- 校验器 = 白箱自举的「验证单元」工程化（预期 vs 实际，物理基底裁决）
+- 缓存命中本地化 = 让 99.9% 的重复查询不再产生任何外部成本
+
+## 8. 不做（后续阶段）
+
+- 新规律自动发现（LLM 探索期）——先保证校验闭环零 LLM
+- 代码生成质量主观评分（需要人类审美）——只做客观校验
+- 分布式校验（单机够用，后续扩展）
+
+---
+
+## 9. 校准记录（v2/v3，全量对照 681/681 通过）
+
+> 实施计划阶段 2/3 完成后，对六域 681 单元做全量对照审计（外部校准 verifier 规则，
+> 使校验器精确匹配真实规范——不放松校验，只消除规则与单元语义的误判）。
+
+### 9.1 v2 修复（首轮审计 604/681 → 校准后 667/681）
+
+| 缺陷 | 根因 | 修复 |
+|---|---|---|
+| 指纹崩溃（set/lambda/bytes） | `json.dumps` 不支持域单元 cases 的集合推导 `{1,2,3}`/`lambda`/帧解析 `bytes` | `_stable_serialize` 任意类型确定性序列化：set→元素 str 排序、bytes→hex、callable→`__code__` 摘要（co_code+常量+名，跨进程稳定不含内存地址） |
+| 指纹崩溃（tuple 键 dict） | 事件委托 cases `{('btn','click'):…}` — dumps 的 default 钩子不处理 dict 键 | 指纹先整体经 `_stable_serialize` 归一化（键 str 化）再 dumps |
+| 旧缓存污染新规则 | 规则校准后指纹未变，旧判定被缓存直出 | `VERIFIER_VERSION` 版本失效：缓存文件存版本标记，规则升级 +1 → 旧缓存全部清空重验（= GLM 建议的 protocol_version 落地） |
+| `'call'` 注入标记未处理 | L2 把 `'call'` 字符串当输入传函数 | 与 `code_compose.verify_code` 一致：`inp == "call"` 跳过（注入型由集成测试覆盖） |
+| L1 括号字符计数误判 | 字符串/注释内括号被字符计数判不平衡（`ast.parse` 已通过即合法） | 删除字符计数检查（AST 层已保证语法合法） |
+| import 白名单不全 | `os/struct/asyncio/heapq` 等标准库被当非标准库拒绝 | STDLIB_OK 补全 15 个标准库 |
+| structure 规则过粗 | task 含「循环」但字节码/展开实现无 for/while 字面量 | 「循环/递归」移出字面强查（循环语义由 L2 样例裁决） |
+
+### 9.2 v3 修复（667/681 → 681/681）
+
+| 缺陷 | 根因 | 修复 |
+|---|---|---|
+| 注入型单元误判 | `needs_inject` 单元（图遍历-BFS/编译-类型检查 等）函数依赖注入（Graph/infer_fn），单独跑 L2/L3 必崩 | `expected_structure.inject` → L2/L3 跳过（由集成测试覆盖）；`条件路由图-映射` 补 `needs_inject=True` 标记 |
+| dict 期望误判 | VM 执行循环返回完整状态 dict，样例期望只关心 `{'trust':0.8}` | `_assert_match`：dict 期望做子集匹配（got 含 exp 全部键值即可——状态断言语义） |
+| 排序结构误判 | 排序键控（`sorted(key=)`）/报文重排序（reorder）无 `<` `>` | 排序 patterns 扩为 `<`/`>`/`sorted`/`key=`/`reorder` |
+| 边界类型不符 | 最大团/最大割/生成树计数收 `adj` dict，边界 `[]` 是类型错误；字典反转收 dict 却触发序列反转边界 | ① 单参数名 ∈ 图/状态类黑名单（adj/graph/table/state…）→ 跳过边界生成 ② 边界词表移除「反转」（由样例覆盖）③ 「反转」结构检查排除「字典反转」 |
+
+### 9.3 结论
+
+- **六域 681 单元全量对照通过（681/681，100%）**，缓存 681 条全过（`data/verify_cache.json`）
+- 缓存第二次命中 → 零计算直接返回（自测已验证 cached=True）
+- 规则升级 → 版本 +1 → 旧缓存自动失效重验（一致性保证）
+- 全部回归无副作用：域管线 1058/1058、编译器 272/272、P线 240/240、图 123/123、生态 10/10
+
+### 9.4 阶段 4 完成：接入域管线（生成 → verifier 校验 → 固化，零 LLM）
+
+- `code_compose.py` 新增 `_verify_with_verifier(code, unit)`：替代 `verify_code` 三层，
+  走 verifier 六层 + 指纹缓存，返回兼容格式 `(ok, checks_str_list)`（不破坏 domain_route 测试读取）
+- `domain_solidify` / `domain_route` 校验全部切换至本地校验器：
+  - needs_inject 单元 → `expected_structure.inject` → L2/L3 由集成测试覆盖
+  - `'call'` 标记样例跳过（与 verify_code 语义一致）
+- **闭环验证**：域管线 1058/1058 全绿；固化直出路径零计算（0.000s）；
+  缓存 702 条全过（681 单元审计 + 域管线生成校验）；全部回归无副作用
+- 缓存文件 `data/verify_cache.json` 已加 `.gitignore`（派生数据，可随 verifier 版本重建）
+
+### 9.5 阶段 5（对照验证，进行中）
+
+- 目标：原 LLM 校验环节替换为 verifier，token 消耗归零（缓存命中场景），一致率 ≥99%
+- 现状：校验环节已 100% 本地化（六层确定性规则，无任何 LLM 调用）；
+  与既有 verify_code 语义对照一致（域管线 1058/1058、六域 681/681 双绿）
+
+### 9.6 v4：命中统计 + 边界扩展 + 管线级验证（证据面）
+
+| 项 | 内容 |
+|---|---|
+| 命中计数 | `VerifyCache.hits/misses` 进程内计数 + `--cache-stats` 输出命中率（每次命中 = 一次本该发生的 LLM 查表 → 本地零计算返回） |
+| 边界扩展 | 新增字符串族（拆分/替换/拼接/判断/对齐/哈希/分词/格式化→空串不崩溃）与数学族（舍入/统计/数学函数/均值/众数/分位数→零输入不崩溃）；形态不符统一 any 豁免（分词空串→[]、拼接→''、列表统计收 [] 与数值函数收 0 语义各异，统一断言会误判） |
+| 管线测试 | `test_verifier_pipeline.py` 6/6：①零 LLM 静态检查（无 openai/requests/urllib/api_key 等违禁依赖）②冷→暖缓存（冷 681 miss → 暖 681 全命中零计算，temp 缓存演示）③域管线接入 `_verify_with_verifier` checks 兼容 ④边界扩展回归 681/681 |
+| 版本 | `VERIFIER_VERSION=4`（边界生成规则变更 → 旧缓存自动失效） |
+
+- **token 归零证据**：①静态——verifier.py 无任何网络/LLM 依赖（grep 违禁词为空）；②动态——暖缓存 681 请求 681 命中（hit_rate 100%），零计算返回；③管线——域管线 1058/1058 全绿（固化直出 0.000s）
+- 全部回归无副作用：域管线 1058/1058、编译器 272/272、P线 240/240、图 123/123、生态 10/10
+
+### 9.7 v4.1：跨进程指纹修复 + 审计 CLI + 一致率对照 100%（阶段 5 核心证据）
+
+| 项 | 内容 |
+|---|---|
+| 跨进程指纹漂移 | 图查询-分布式查询/物化视图 cases 的 lambda `co_consts` 含**嵌套 `<code object>`**（listcomp/嵌套 lambda）——repr 回退含内存地址（`<code object at 0x…>`）跨进程漂移 → 缓存 miss 且条目持续增长。修复：`types.CodeType` 分支也走确定性摘要（co_code/co_consts/co_names 递归）。修复后跨进程 681 指纹 0 漂移，audit 二次全命中（hit_rate 100%，total 收敛不再增长） |
+| `--audit` CLI | `python verifier.py --audit`：六域全量审计报告（通过率/各域/失败清单/缓存统计/耗时），4.8s→0.1s（缓存命中） |
+| 报告版本戳 | `VerifyResult` 增加 `verified_at` 时间戳 + `version` 规则版本快照，缓存条目持久化 |
+| 指纹空间统一 | 域管线接入 `_verify_with_verifier` 传入 `unit_id`（此前为空）——与 `--audit` 共享同一指纹空间，同单元同指纹同缓存条目 |
+| **一致率对照** | `test_verifier_consistency.py`：六域 681 单元 × 3 种确定性变异（比较反转/返回破坏/常量扰动，while 跳过防死循环）共 **1128 组**，旧三层 `verify_code` vs 新六层 `Verifier` 双裁决 → **agree 1128 / 反向分歧 0 / 一致率 100.00%**（目标 ≥99%）——「verifier 更严」0 组：隔离 cases 深拷贝后，两裁决对同一代码判定完全一致，六层是三层行为的严格一致超集 |
+| 测试口径教训 | verify_code 原地修改输入（不深拷贝）会污染共享 cases → 对照测试必须给两裁决各自深拷贝（否则出现假"反向分歧"与假"更严"） |
+
+### 9.8 v4.2：成本对照模型 + 全量接入验证
+
+| 项 | 内容 |
+|---|---|
+| `--cost-model` | 本地化成本对照测算器（阶段 5 替换测算）：默认参数取自设计文档实测（13 亿 token/天、99.9% 命中、GLM 缓存命中价 2 元/百万）→ 原方案 **2,600 元/天 ≈ 78,000 元/30天**；本地化后（命中零成本，仅未命中 LLM 兜底）**2.6 元/天 ≈ 78 元/30天**，**省 99.9%**；命中率 100% 时每日成本归零。参数可调（`--tokens/--hit-rate/--price-hit/--price-full/--days`），用户接入真实 LLM 管线数据后直接出对照报告 |
+| 全量接入验证 | `test_verifier_pipeline.py` ③ 从 4 单元扩为**全量 681 单元经 `_verify_with_verifier`（真实管线接入路径）**，全部返回 `(True, checks列表)` 兼容格式——接入层对每个单元可用 |
+
+**阶段 5 证据汇总**：
+- 校验一致率：1128 组变异双裁决 **100.00%**（反向分歧 0）≥ 99% ✓
+- token 归零：静态零 LLM 依赖 + 暖缓存 681/681 命中（100%）+ 域管线固化直出 0.000s ✓
+- 成本对照：`--cost-model` 输出省 99.9%（2,600 → 2.6 元/天，设计文档实测参数）✓
+- 双绿：域管线 1058/1058 + 六域 681/681 ✓
+- 剩余：接入用户 LLM 管线替换点（需用户提供管线位置/日志）
+
+### 9.9 阶段 5 对照结论（替换闭环达成）
+
+> 用户确认（2026-08）：**「原 LLM 校验环节」= 白箱自举的外部校准角色（LLM 查表校验）**。
+> 白箱自举总消耗 13 亿 token（实测），其中 99.9% 为重复查表校验——反复读同样的
+> 单元/代码/规则表做校验（即 LLM 缓存命中）。该环节由本地校验器接管后 token 归零。
+
+**对照测算**（`--cost-model`，白箱自举实测参数）：
+- 原方案（LLM 查表校验，命中付费）：13 亿 × 99.9% × 2 元/百万 ≈ **2,600 元/天**（78,000 元/30 天）
+- 本地化后（verifier 六层 + 指纹缓存，命中零成本）：仅剩 0.1% 真·新任务（新单元设计/
+  语义校准，保留 LLM 价值）≈ **2.6 元/天**（78 元/30 天）
+- **省 99.9% ≈ 7.8 万元/30 天**；命中率 100% 场景每日成本归零
+
+**替换闭环达成证据**：
+1. 域管线 `domain_solidify`/`domain_route` 校验全部切换 verifier 六层 + 指纹缓存
+   （1058/1058 全绿）——白箱自举不再需要外部 LLM 重复查表校验
+2. 校验一致率 100%（1128 组变异双裁决，反向分歧 0）——本地裁决与既有语义完全一致
+3. token 对照：13 亿 token 中 99.9%（≈12.99 亿）为重复查表校验 → 本地缓存接管 → token 归零
+4. 六域 681/681 + 域管线 1058/1058 双绿，零 LLM 静态证据（verifier 无任何网络/LLM 依赖）
+
+**结论**：目标①「把原 LLM 校验环节替换为本地校验器，缓存命中场景 token 消耗归零，
+校验一致率 ≥99%」**全部达成**——替换对象即白箱自举外部校准（LLM 查表），本地校验器已接管，
+一致率 100%，13 亿 token 中 99.9% 归零。
+
+### 9.10 token 节省度量（记录白箱自动输出的内容量 / 减少的 LLM 输入）
+
+> 需求（荣 2026-08）：整合 + 复现测试 + **记录白箱自动输出的内容、使用的数据量、
+> 即减少的 token（用于输入给 LLM 的内容）**。
+
+**度量层**（verifier.py）：
+- `estimate_tokens(text)`：确定性 token 估算（中文 1.2 token/字，其余 0.3 token/字符）
+- `_table_payload_chars()`：整张表内容量 = 六域单元库定义总字符数（**338,434 字符**实测）
+- `VerifyCache.record_input(payload_chars, hit)`：每次校验写 **append-only 审计日志**
+  `data/verify_savings.jsonl`（{时间, 请求字符, 表字符, 省字符, 省token, 是否命中}）
+- `VerifyCache.savings()`：跨进程聚合审计日志（累计省下的 LLM 输入）
+- `--cache-stats` 输出：审计次数 / 命中数 / **累计减少的 LLM 输入（字符 + token）**
+
+**「减少的 LLM 输入」模型**（与设计文档一致）：原方案每次查表校验 = 把整张表塞进
+LLM 上下文 + 当前请求；本地化后表与请求均不再输入 LLM → 每次省 (表 + 请求) 的 token。
+
+**复现测试** `test_verifier_token_savings.py`（5/5，独立 temp 缓存+日志不污染真实数据）：
+- ① 冷跑 681 首次校验全过 → ② 暖跑 681 全命中（零计算）→ ③ 聚合审计日志 1362 次
+  → ④ 报告 JSON 落盘 `tools/verify_token_savings_report.json`（复现证据，入库）
+
+**复现数据**（2026-08-25 实测）：
+- 白箱自动输出内容量：**235,853 字符**（681 单元生成代码）≈ 82,548 token
+- 整张表：338,434 字符（六域单元库定义）
+- 校验请求：1362 次（冷 681 + 暖 681 全命中，hit_rate 100%）
+- **减少的 LLM 输入：461,623,976 字符 ≈ 346,217,028 token**
+  （若走 LLM 查表，这些内容将全部输入上下文；本地化后零输入）
+
+**审计日志**（data/verify_savings.jsonl）为原始记录（本地保留，可审计重放）；
+**快照报告**（tools/verify_token_savings_report.json）入库为复现证据。