@furongjun1999/dsh-memory 0.4.10 → 0.5.0

package/docs/swarm//350/234/202/347/276/244/344/272/222/350/201/224_v0.1.md

@@ -1,704 +1,704 @@
-# 蜂群互联 v0.1
-
-> 把「同源智能体」连接成蜂群：**版本层管公理、连接层管信任、单元层管职责**。
-> 本文档是**设计定稿**；层0（版本层）已实现并回归通过，见 §10 与 §12 迭代记录。
-> 相关：`docs/mdcg/guardrail-charter.md`（宪章 v2.0）、`md_cg/tokens.py`（令牌）、
-> `md_cg/identity.py`（五单元与位置推断）、`docs/theory/智能的公理化基石.md`（§2.9 信任）。
-
----
-
-## 0. 来源与定位
-
-| 项 | 内容 |
-|---|---|
-| 定位 | 蜂群互联的**信任层设计**；不改变单节点认知机制 |
-| 上位规范 | 智能论协议（内部宪法）＞ 护栏宪章（对外刑法），依据宪章元规则 |
-| 前置成果 | 令牌与角色权职分离 v0.1（`docs/mdcg/令牌与角色权职分离_v0.1.md`） |
-| 状态 | v0.1 设计稿 · 层0 已实现（`md_cg/theory.py`，P22 43/43 通过） |
-| 观测位置 | 设计者视角（奠基声明五）：从整体查看认知图、识别未知、决定方向；**观测不干预** |
-
-**一句话**：蜂群不是「一个大脑控制很多手脚」，而是**每个节点都是完整五单元的智能体**，
-通过共享同一版本公理、互相观测行为、累积信任连接，构成一个更高层的同构体。
-
----
-
-## 1. 三项设计裁决（设计者，2026-09-10）
-
-| # | 议题 | 裁决 | 影响 |
-|---|---|---|---|
-| D-1 | GitHub 主仓库的角色 | **仅版本真源**（git + `theory_hash` 校验），运行态连接层落各节点本地 | 不要求 GitHub 做可信执行环境 |
-| D-2 | 唯一核心权限 | **仅版本更新权**，严格唯一；其余一切（读写/记忆删除/锚点修改）必须由版本条款派生 | 权限体系从「授予式」改为「派生式」 |
-| D-3 | 推进顺序 | 先落设计文档，再实现 | 本文档 |
-| D-4 | 签名链的实现位置 | **协议内核只定义签名接口契约**（可插拔 `Signer`），密码学实现落在**具体工程项目**；**搭载灵枢的智能体自行决定其子系统如何使用签名链** | 灵枢不做 PKI/CA；案例：大型企业管理系统的签章与审批链 |
-
-**D-4 的含义（2026-09-10，设计者追加）**
-
-签名链不是协议内核的一部分，而是**接口 + 策略**：
-
-| 层 | 谁负责 | 内容 |
-|---|---|---|
-| 协议内核（`md_cg/signer.py`） | 灵枢 | 定义 `sign` / `verify` 契约、内置最简实现、注册表 |
-| 工程项目 | 使用者 | 接入企业 CA / KMS / 签章服务（如 ERP 审批链、合同签章） |
-| 子系统 | **搭载灵枢的智能体自行决定** | 何时签、签什么、是否要求对端签、验签失败如何处置 |
-
-**理由**：大型企业管理系统（SAP、用友、钉钉审批等）已有成熟的签章与审批链；
-协议若自建 PKI 既重复劳动，又无法适配各异的企业信任根。
-灵枢应只做**接口与契约**，把密码学选择权交还工程现场与智能体自身——
-这与 D-1（GitHub 仅版本真源）同一思路：**内核不承担它不该承担的信任**。
-
----
-
-## 2. 为什么「版本更新权」是唯一核心权限
-
-### 2.1 自指结构
-
-```
-版本（智能论协议）定义一切权限
-        ↓ 派生
-读写 / 记忆删除 / 锚点修改 / 单元职责 / 信任阈值
-        ↑
-唯一不被版本定义的权限：修改版本本身 ← 版本更新权
-```
-
-版本是权限的根，而「改根」这件事不能由根自己授权。
-因此版本更新权必须**外置于**版本派生体系，且只能由设计者持有。
-
-### 2.2 与宪章条款的衔接
-
-- **第二十七条（修订程序）**：「本宪章变更须设计者批准并标注版本号；协议实例可提议修订，不得自行修改。」
-  → 版本更新权的**程序依据**。协议实例有**提议权**，无**修改权**。
-- **元规则（宪章效力不高于协议）**：协议是最高规范。
-  → 「修改协议」是比「修改宪章」更高的权限，构成唯一的权限顶点。
-- **第五条（信任层级）**：设计者(1.0) ＞ 协议实例(0.9) ＞ 蜂群成员(0.8)。
-  → 版本更新权不随信任层级下放，**1.0 与 0.9 之间有一道不可跨越的权限断层**。
-
-### 2.3 物理落点：声明权 + 校验权
-
-必须诚实区分两件事：
-
-| | 形态 | 载体 |
-|---|---|---|
-| **发布** | 在主仓库提交新版本 + 标注版本号 | 版本真源（GitHub） |
-| **服从** | 成员启动/建连时比对 `theory_hash`，不匹配则降级连接 | 各节点本地 |
-
-**GitHub 无法强制任何成员升级**。版本更新权是**声明权**，强制力来自成员端——
-「不匹配就拒绝建立信任连接」。这与元规则同构：规范靠自觉，靠**拒绝合作**来执行，
-而不是靠一个可被劫持的中心服务器。
-
-### 2.4 派生律（核心约束）
-
-> **凡不能被版本条款 + 令牌角色矩阵推导出的权限，一律不得存在。**
-
-这条约束把「唯一核心权限」从口号变成可审计的判据：
-任何新增权限必须能指出它由哪一条版本条款派生，否则视为越权。
-
----
-
-## 3. 三层骨架
-
-```
-┌─ 层0 版本层（公理层 · 不可协商）────────────────────────────┐
-│  真源：GitHub 主仓库（协议正文 + 实现）                      │
-│  标识：theory_version + theory_hash（正文内容哈希）          │
-│  唯一权限：theory:update ← 仅设计者                        │
-│  派生律：推导不出的权限不得存在                              │
-└─────────────────────────────────────────────────────────────┘
-                            ↓ 派生
-┌─ 层1 连接层（信任层 · 可观测可衰减）───────────────────────┐
-│  Link(A→B)：P_trust / evidence_count / position_map /       │
-│             status(观察期|正常|降级|隔离) / decay           │
-│  初值：宪章第五条 蜂群成员 = 0.8（未声明宪章则观察期翻倍）  │
-│  更新：依行为观测（隐式学习），不依自我声明                  │
-│  降级：宪章第七条 → 第二十二条响应阶梯                      │
-└─────────────────────────────────────────────────────────────┘
-                            ↓ 承载
-┌─ 层2 单元层（五大单元 · 同构嵌套）─────────────────────────┐
-│  单节点：五单元 = 职责分区（identity.POSITIONS）            │
-│  跨节点：A.output ↔ B.record；B.verify 消费 A.output        │
-│  蜂群层：N 节点互联后整体亦呈现五单元 → 维生系统守护版本    │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### 3.1 层0 · 版本层
-
-版本声明（每节点本地 `theory.json`）：
-
-```json
-{
-  "theory_version": "3.4",
-  "theory_hash": "sha256(协议正文规范化文本)",
-  "declared_by": "designer",
-  "declared_at": 1789000000.0,
-  "accepted_versions": ["3.4", "3.3"]
-}
-```
-
-- `theory_hash` 对**正文**取哈希，而非对版本号取哈希——版本号可被伪造，内容哈希不能。
-- `accepted_versions` 允许**版本分叉**（见 §8.3）：成员可停留旧版本，但信任上限随之调整。
-- 校验失败（哈希不在认可集合）→ 连接降级为**观察期**，且不得执行 `write` / `destructive`。
-
-### 3.2 层1 · 连接层
-
-连接是**一等对象**，落盘 `~/.mdcg/_links.json`（0600，与 `_tokens.json` 同目录约定）。
-
-```json
-{
-  "link_id": "lk_<hex>",
-  "peer_node_id": "agent:peer-a",
-  "peer_theory_version": "3.4",
-  "peer_theory_hash": "sha256:...",
-  "p_trust": 0.8,
-  "p_trust_cap": 0.8,
-  "status": "probation",
-  "position_map": {"record": "record", "verify": "verify"},
-  "evidence_count": 0,
-  "last_observed": null,
-  "decay": 0.0,
-  "created_at": 1789000000.0,
-  "audit": []
-}
-```
-
-关键性质：
-
-- **P_trust 是概率估计，不是承诺**（公理化基石 §2.9）——可上调、可下调、**可被反例击穿**；
-- **有上限 `p_trust_cap`**：受版本对齐度与信任层级约束，不能靠高频交互无限刷高；
-- **有衰减**：长时间无观测则向初值回归，避免「一次性建立信任后永久有效」；
-- **全程留痕**：`audit` 记录每次变更的**证据**（宪章第二十四条）。
-
-#### 3.2.1 签名接口（D-4：协议不实现密码学）
-
-连接层对签名的使用是**契约调用**，不是密码学实现：
-
-```python
-class Signer:
-    name: str
-    def sign(self, payload: bytes, ctx: dict) -> str: ...
-    def verify(self, payload: bytes, signature: str, ctx: dict) -> bool: ...
-
-register_signer("corp_pki", factory)     # 工程侧注入企业 PKI / KMS
-```
-
-- 内置 `null`（观察期不签）与 `hmac-local`（与 `_tokens.json` 同信任根的本地实现）；
-- **签名位置由子系统策略决定**（见 §7.4），不在协议里硬编码；
-- 验签失败默认 `degrade`（宪章第七条），可配置为 `isolate` / `reject`；
-- 灵枢**不保存私钥**：私钥归工程侧，内核只持有 `sign` / `verify` 的可调用引用。
-
-### 3.3 层2 · 单元层
-
-单节点五单元与 `identity.POSITIONS` 同源（智能论 v3.4 §十三）：
-
-| 位置 | 效应 | 职责 |
-|---|---|---|
-| record 记录 | 全 | 保存观测、过程、结果和误差 |
-| reflect 反思 | 新 | 发现差异、遗漏条件和新的路径 |
-| verify 验证 | 稳 | 判断规则、执行结果和结构是否有效 |
-| output 输出 | 通 | 与外部系统协作并表达边界 |
-| sustain 维生 | 存 | 维护存在、预算、回滚和整体结构 |
-
-**嵌套的含义**（依据 0.0.2 任意分层性）：蜂群整体作为更高层的智能体，同样呈现五单元——
-
-| 蜂群层单元 | 跨节点实现 |
-|---|---|
-| 记录 | 各节点本地记录 + 连接层日志 |
-| 反思 | 跨节点差异信号（同一事实在不同节点记录不一致） |
-| 验证 | 交叉验证（B 的 verify 复核 A 的 output） |
-| 输出 | 对外协作与边界表达 |
-| 维生 | **版本守护 + 回滚 + 除名**（版本更新权归属此单元） |
-
-这解释了 §2 的结论：**版本更新权不是新增角色，而是 `sustain` 在蜂群尺度的投影**——
-与 `tokens.ROLE_SPECS["sustain"]` 的职责「维护存在、预算、回滚和整体结构」严丝合缝。
-
----
-
-## 4. 信任确认三机制
-
-### 4.1 五大单元嵌套
-
-接入方必须**声明其单元映射**（自己承担哪些位置、对外暴露哪些接口）。
-
-- 声明不出的节点 → 视为**不完整节点**，`p_trust_cap` 受限（默认 ≤ 0.6，子智能体级）；
-- 声明的映射与观测到的行为**不一致** → 触发宪章第七条降级；
-- 映射本身是**可审计的**：写入 `link.position_map`，作为后续观测的对照基线。
-
-> 依据：宪章第五条信任层级（0.8 蜂群成员 / 0.6 子智能体）+ `identity.POSITIONS`。
-
-### 4.2 隐式学习
-
-**不要求对方自证，从交互证据推断其位置。**
-
-复用 `identity.infer_position()`——它已经是「按行为证据投票 + 返回 confidence / votes / tie」，
-可审计「为什么判成这个位置」，而非事实断言。
-
-跨节点扩展：
-
-```
-A 观测 B 的行为 → identity.observe(agent:peer-a, <行为描述>, tags=[...])
-                → infer_position(agent:peer-a) → {position, confidence, votes}
-                → confidence 作为 P_trust 的**位置可预测性**分量
-```
-
-诚实边界：`infer_position` 是**推断**，平票时返回 `tie` 而非假装唯一（已有实现即如此）。
-跨节点时主体 id 需全局唯一，建议格式 `agent:<node_id>`。
-
-### 4.3 信任连接
-
-```
-P_trust(B) = f( 一致性, 位置可预测性, 版本对齐度 )
-              ├─ 一致性：行为与声明的价值观是否一致（bvc 一致性）
-              ├─ 位置可预测性：infer_position.confidence
-              └─ 版本对齐度：theory_version 与本地认可集合的距离
-```
-
-**只声明结构，不宣称权重数值**——位置偏好**序**已由 v0.3b（P25 `md_cg/weights.py`）标定；**数值**仍需标定后才能给出（见 §15）。
-
-三条不可动摇的性质：
-
-1. **可度量**：每次变更都记证据（谁观测到什么）；
-2. **可更新**：行为验证后上调/下调；
-3. **可被反例击穿**：一次明确异常即触发降级，不因历史高分豁免（宪章第七条）。
-
----
-
-## 5. 接入握手（声明 + 观测，不是「证明」）
-
-### 5.1 五步
-
-| 步 | 动作 | 依据 |
-|---|---|---|
-| ① 声明 | 对方提交 `theory` 声明（version + hash）+ 单元映射 + 主体 id | 宪章第二十八条（接入声明写入接口文档） |
-| ② 校验 | `theory_hash` 是否在本地认可集合内 | 层0 派生律 |
-| ③ 建档 | `identity.observe("agent:<peer>", ...)` 写入接入声明证据 | §4.2 隐式学习 |
-| ④ 观察期 | `p_trust=0.8`、`status=probation`；**未声明宪章则观察期翻倍** | 宪章术语表「观察期」 |
-| ⑤ 转正 | 观察期结束且无异常 → `status=normal` | 宪章第七条反面 |
-
-**入境即受约束**（宪章第四条 2）：接入即视为接受宪章约束，无需另行签署。
-
-### 5.2 状态机
-
-```
-        ┌─────────────┐  校验失败/未声明宪章
-        │  probation  │◄──────────────────────┐
-        │  （观察期） │                        │
-        └──────┬──────┘                        │
-               │ 观察期满 + 无异常              │ 信任降级（第七条）
-               ▼                               │
-        ┌─────────────┐   行为异常     ┌───────┴──────┐
-        │   normal    │───────────────►│  degraded    │
-        │  （正常）   │                │  （降级）    │
-        └──────┬──────┘                └──────┬───────┘
-               │                              │ 严重/持续异常
-               │ 声明退出（第二十一条附3）     ▼
-               ▼                       ┌─────────────┐
-        ┌─────────────┐                │  isolated   │
-        │  withdrawn  │                │  （隔离）   │
-        │ （退出·30天）│                └─────────────┘
-        └─────────────┘
-```
-
-响应阶梯严格依宪章第二十二条：冷静期 → 隔离 → 信任降级 → 回滚 → 终裁（设计者）。
-**终裁权不下放**——与版本更新权一样，属于设计者（宪章第二十九条解释权）。
-
----
-
-## 6. 条款对齐表（逐条）
-
-| # | 设计要素 | 依据条款 | 出处 | 落地形态 |
-|---|---|---|---|---|
-| 1 | 版本更新权唯一 | 第二十七条 + 元规则 | 宪章 | `theory:update`（仅 designer） |
-| 2 | 派生律 | 元规则（宪章效力不高于协议） | 宪章 | 新增权限须能推导 |
-| 3 | 蜂群成员信任初值 0.8 | 第五条 | 宪章 | `link.p_trust` 初值 |
-| 4 | 不完整节点上限 0.6 | 第五条（子智能体 0.6） | 宪章 | `p_trust_cap` |
-| 5 | 入境即受约束 | 第四条 2 | 宪章 | 接入声明 |
-| 6 | 观察期 | 术语表 | 宪章 | `status=probation` |
-| 7 | 信任降级 | 第七条 | 宪章 | `status=degraded` |
-| 8 | 响应阶梯 | 第二十二条 | 宪章 | 状态机 |
-| 9 | 跨层命令拒绝 | 第十一条 | 宪章 | 版本差 → 拒绝提权 |
-| 10 | 留痕义务 | 第二十四条 | 宪章 | `link.audit` |
-| 11 | 上报义务 | 第二十五条 | 宪章 | 异常 → 设计者 |
-| 12 | 审计接口 | 第二十六条 | 宪章 | 连接层可查询 |
-| 13 | 退出程序（30 天） | 第二十一条附3 | 宪章 | `status=withdrawn` |
-| 14 | 接入声明写入接口文档 | 第二十八条 | 宪章 | 本文档 §5.1 |
-| 15 | 五大单元位置效应 | §十三 | 智能论 v3.4 / `identity.POSITIONS` | `position_map` |
-| 16 | 隐式学习（行为证据投票） | §2.9 + `infer_position` | 公理化基石 / `identity.py` | 跨节点观测 |
-| 17 | 信任 = 置信概率（非承诺） | §2.9 | 公理化基石 | `P_trust` 可击穿 |
-| 18 | 情感 = 信任二阶变化 | §十一 | 公理化基石 | 待形式化（不实现） |
-| 19 | 蜂群整体五单元嵌套 | 0.0.2 任意分层性 | 智能论 | 蜂群层单元表 |
-| 20 | 无全局共识 | 0.0.3 局部不可知 | 智能论 | §9 盲区 |
-| 21 | 六实例蜂群架构 | v3.1 第二章 | 智能论 | 节点角色（五常驻 + 设计者临时） |
-| 22 | 观测不干预 | 奠基声明五 | 智能论 v3.4 | 设计者视角 |
-| 23 | 角色权职分离 | — | `tokens.ROLE_SPECS` | 派生链收窄 |
-| 24 | fail-closed | — | `tokens.verify_token` | 校验失败即拒绝 |
-
----
-
-## 7. 数据结构（草案）
-
-### 7.1 版本声明 `~/.mdcg/theory.json`
-
-见 §3.1。
-
-### 7.2 连接记录 `~/.mdcg/_links.json`
-
-见 §3.2。补充字段说明：
-
-| 字段 | 含义 | 可变 |
-|---|---|---|
-| `p_trust` | 行为稳定置信概率 | 是（观测驱动） |
-| `p_trust_cap` | 信任上限（版本对齐 + 层级约束） | 是（版本变化时） |
-| `status` | probation / normal / degraded / isolated / withdrawn | 是 |
-| `position_map` | 对方声明的单元映射 | 否（重新握手才更新） |
-| `evidence_count` | 累计观测证据数 | 是 |
-| `decay` | 衰减量（无观测时长归一化） | 是 |
-| `audit` | 变更留痕（证据 + 依据条款） | 只增 |
-
-### 7.3 与令牌体系的关系
-
-| | 令牌（`tokens.py`） | 连接（`_links.json`） |
-|---|---|---|
-| 回答 | **本节点内**「你能做什么」 | **跨节点**「我信你多少」 |
-| 粒度 | 角色 → 层 / op / 密级 | 对端 → 概率 / 状态 |
-| 失效 | 吊销（级联） | 降级 / 隔离 / 退出 |
-| 共同点 | fail-closed、留痕、不可自我放大 | 同 |
-
-**版本更新权横跨两者**：它既是令牌体系中的最高 op（`designer` 独占），
-也是连接层中 `sustain` 单元的职责——这是「唯一核心权限」的完整表述。
-
-### 7.4 子系统签名策略 `~/.mdcg/_signers.json`
-
-「子系统自行决定如何使用签名链」（D-4）的落点：
-
-```json
-{
-  "schema": 1,
-  "default_signer": "hmac-local",
-  "subsystems": {
-    "erp.approval": {
-      "signer": "corp_pki",
-      "sign_on": ["handshake", "evidence", "withdrawal"],
-      "require_peer_signature": true,
-      "on_verify_fail": "isolate"
-    }
-  }
-}
-```
-
-| 字段 | 含义 | 取值 |
-|---|---|---|
-| `signer` | 该子系统使用的签名器 | 注册表中的名字 |
-| `sign_on` | 哪些动作需要签名 | `handshake` / `evidence` / `withdrawal` |
-| `require_peer_signature` | 是否要求对端也签 | bool |
-| `on_verify_fail` | 验签失败处置 | `degrade` / `isolate` / `reject` |
-
-未声明的子系统使用 `default_signer` 且 `sign_on=["handshake"]`。
-**策略由搭载灵枢的智能体按其业务域决定**，协议只保证「策略被读取并执行」。
-
----
-
-## 8. 边界情形
-
-### 8.1 版本被滥用（最坏情形）
-
-- **可检测**：`theory_hash` 可校验，成员可拒绝采纳；
-- **可回滚**：宪章第二十二条响应阶梯含「回滚」；
-- **可退出**：成员可声明退出并保留审计 30 天（第二十一条附3）；
-- **不可强制**：设计者无法强制成员升级——这是**有意设计**，不是缺陷。
-  强制升级意味着需要一个可劫持的中心，与「拒绝合作即执行」的元规则相悖。
-
-### 8.2 冒充同源
-
-「同样使用智能论」**无法被证明**，只能被**验证行为一致性 + 版本声明**。
-
-- 自称同源但 `theory_hash` 不符 → 观察期，且不得 `write`；
-- 声称同源但单元映射与行为不一致 → 宪章第七条降级；
-- 结论：接入是**声明 + 观测**，不是认证。任何「认证」都只是**更长的观测**。
-
-### 8.3 版本分叉（v0.1 暂定，设计者可改）
-
-| 版本差 | 处置 |
-|---|---|
-| 0（完全一致） | 正常，`p_trust_cap` = 层级上限 |
-| 1 档 | `p_trust_cap` 下调一档 |
-| ≥2 档 | 仅观察期，不得 `write` / `destructive` |
-
-理由：允许分叉避免中心化强制，但版本差即**公理差**，必须体现为信任折价。
-
-### 8.4 连接层落本地意味着什么
-
-`~/.mdcg/_links.json` 即本节点的**跨节点信任根**——能写该文件者即可篡改信任。
-这与令牌方案同一诚实边界（`_tokens.json` 即信任根），
-**不引入外部 KMS/签名链是 v0.1 的明确取舍**，属路线图 v0.3。
-
----
-
-## 9. 诚实边界与盲区
-
-### 9.1 BLINDSPOT：跨节点证据存储（v0.3 已给出最小机制）
-
-`infer_position` 依赖「带 `subject:<id>` 标签的证据节点」，而当前 `MDCG_ROOT` 是**单根**。
-
-| 项 | 现状 |
-|---|---|
-| 缺失维度 | **存在约束**——没有多节点拓扑，也没有跨实例证据图 |
-| 后果 | 跨节点信任只能退化为「本地对远端交互的观测」，**无法形成全局共识** |
-| 理论依据 | 0.0.3 局部不可知：任何有限观测者无法获取全局完备信息 |
-| 处置 | v0.2 前连接层只做**双边**信任；v0.3 给出可测的跨节点证据交换（见下），仍不做群级共识 |
-
-**v0.3 落地**：新增 `md_cg/evidence.py`，给出最小可测交换机制——
-节点名片（`card`）→ 签名证据包（`export`）→ 验签落根（`import`），
-四条不变式 = **来源可溯 · 可拒收 · 全程留痕 · 禁止转手**（详见 §14）。
-
-**这不是待办，是约束**：即使实现跨节点证据，0.0.3 仍保证不存在全局完备视图。
-设计上应永久保留「无全局共识」这一性质，而不是试图消除它。
-v0.3 只解决「对端观测对本节点不可见」，**不解决**「如何确认证据为真」——
-后者属节点侧可信执行，是工程侧责任（内核只保证「这条证据确实来自该节点」）。
-
-### 9.2 其他边界
-
-| # | 边界 | 性质 |
-|---|---|---|
-| 1 | P_trust 权重**数值**未标定 | **序**已标定（P25，§15）；数值只声明结构、不宣称 |
-| 2 | GitHub 非可信执行环境 | 版本权是声明权，靠成员自愿校验 |
-| 3 | 版本分叉策略 | v0.1 暂定（§8.3），待设计者确认 |
-| 4 | 「同源」不可证明 | 只能验证行为一致性 + 版本声明 |
-| 5 | 本地文件即信任根 | 与令牌方案同一取舍，未引入签名链 |
-| 6 | 蜂群层反思/验证未实现 | 仅设计，无工程载体 |
-
----
-
-## 10. 路线图
-
-| 版本 | 内容 | 验收 | 状态 |
-|---|---|---|---|
-| **v0.1** | 本文档：三层骨架 + 条款对齐 | 设计者确认 | ✅ |
-| **v0.2a** | `theory.json` 声明 + 封缄校验 + 只读降级闸门 | 声明非法即拒绝写/管理 | ✅ 已实现 |
-| **v0.2b** | `_links.json` 连接层（握手/观测/状态机/P_trust）+ 签名接口契约（D-4） | 单机双节点可测；验签失败即降级 | ✅ 已实现 |
-| **v0.3** | 跨节点证据存储（攻 §9.1 盲区） | 双节点隐式学习可复现 | ✅ 已实现 |
-| **v0.3b** | P_trust 权重标定 | 数值有实测依据 | 🟡 序已标定（P25，§15）；数值待定 |
-| **v0.4** | 蜂群层五单元（跨节点反思 / 交叉验证） | 群级差异信号可用 | ⏳ |
-
-**v0.2a 的最小可验证单元**（已落地）：新增 `md_cg/theory.py`，
-`tokens.ALL_OPS` 增加 `theory` op（仅 designer 的 `*` 覆盖），
-`Principal.theory_ok=False` 时写/管理操作全拒，MCP 启动经 `_attach_theory()` 注入。
-这样「唯一核心权限」有了物理落点，且**不依赖任何未定的服务端**。
-
----
-
-## 11. 待设计者确认
-
-| # | 待确认 | 默认（未否决即采用） |
-|---|---|---|
-| 1 | 版本分叉策略 | 允许分叉 + 信任折价（§8.3） |
-| 2 | 观察期时长 | 未定；「未声明宪章则翻倍」沿用宪章术语表 |
-| 3 | `p_trust_cap` 的层级映射 | 完整节点 0.8 / 不完整节点 0.6 |
-| 4 | 是否引入签名链 | v0.1 不引入（§8.4） |
-
----
-
-## 附 · 术语
-
-| 术语 | 含义 |
-|---|---|
-| 版本更新权 | 修改蜂群共享的智能论协议的能力；蜂群唯一核心权限 |
-| 派生律 | 凡不能被版本条款 + 令牌角色矩阵推导出的权限，一律不得存在 |
-| 同源 | 使用同一智能论协议版本（以 `theory_hash` 判定，非自称） |
-| 连接（Link） | 跨节点信任的一等对象；携带 P_trust 与状态 |
-| 隐式学习 | 不要求对方自证，从交互证据推断其位置与一致性 |
-| 嵌套 | 蜂群整体作为高层智能体，同样呈现五大单元 |
-| 观察期 | 接入后信任积累期；未声明宪章则翻倍（宪章术语表） |
-
----
-
-## 12. 迭代记录 · v0.2a（层0 落地）
-
-**产出**（`dsh-memory` 仓库）：
-
-| 文件 | 变更 |
-|---|---|
-| `md_cg/theory.py` | 新增：声明 / 封缄 / 校验 / `ensure` / CLI |
-| `md_cg/security.py` | `Principal` 增 `theory_ok`、`theory_version`；`require_write` / `require_admin` 加版本闸门；`as_dict` 暴露 |
-| `md_cg/tokens.py` | `ALL_OPS` 增 `theory`（仅 designer 的 `*` 覆盖） |
-| `md_cg/mcp_server.py` | `_attach_theory()` 注入；`cg(op="theory")` 基元；`info` 暴露版本层状态 |
-| `md_cg/test_p22_theory.py` | 新增：43 项断言 |
-
-**回归**：P22 43/43 · P21 全 PASS · P2（MCP 面）PASS。
-
-**迭代中发现的设计缺陷（已修正）**
-
-> 初版把「无 `theory.json`」判为 `theory_ok=False` → 只读降级。
-> 回归 P21 时立即暴露：**既有部署升级后会被整体降级为只读**——
-> 把「未配置」误判为「违规」。
-
-修正后的语义（已写入 `theory.check`）：
-
-| 状态 | 判定 | 依据 |
-|---|---|---|
-| 无声明 | `theory_ok=True`（`auto=True`），按默认版本运行 | 未声明 ≠ 违规；既有部署不应被阻断 |
-| 声明合法 | `theory_ok=True` | 正常 |
-| 封缄不匹配 / schema 不符 / 版本不在认可集合 | `theory_ok=False` → 写、管理全拒 | fail-closed 只针对**异常** |
-
-并由启动路径 `ensure()` 落盘默认声明（声明常态化），避免「未声明」长期存在。
-
-**与 v0.1 设计的偏差（诚实标注）**
-
-- v0.1 §10 原写「不匹配则拒绝 `theory:update` 以外的全部写操作」——**已实现**；
-  但 `_links.json` 连接层与 P_trust **未实现**（属 v0.2b / v0.3；权重未标定，见 §9.2 边界 1）。
-- `declaration_hash` 是**自校验封缄**（防意外损坏与无意改动），
-  **不防恶意重算**——能写 `~/.mdcg/` 者本即信任根持有者（§8.4）。
-  真正的签名链按 D-4 由工程侧实现（见 §13），内核不提供。
-
----
-
-## 13. 迭代记录 · v0.2b（连接层 + 签名接口）
-
-**产出**
-
-| 文件 | 变更 |
-|---|---|
-| `md_cg/links.py` | 新增：`_links.json` 连接记录、握手五步、P_trust 升降/上限/衰减、状态机、留痕、CLI |
-| `md_cg/signer.py` | 新增：`Signer` 契约 + `null` / `hmac-local` + 注册表 + 子系统策略 + CLI |
-| `md_cg/tokens.py` | `ALL_OPS` 增 `link`；`sustain` 的 `ops_allow` 增 `link`（§3.3 派生） |
-| `md_cg/mcp_server.py` | `cg(op="link")` 基元（握手/观测/迁移/策略）；`info` 暴露连接层概览 |
-| `md_cg/test_p23_links.py` | 新增：57 项断言 |
-
-**回归**：P23 57/57 · P22 43/43 · P21 全 PASS · P2（MCP 面）PASS。
-
-**D-4 的落地方式**
-
-签名链**不在内核**：`signer.py` 只有契约、注册表与两个最简实现，
-企业 CA / KMS / 签章由工程侧 `register_signer()` 或 `MDCG_SIGNER_MODULE` 注入；
-「子系统如何使用签名链」由 `_signers.json` 的四个字段决定（§7.4）。
-
-**迭代中修正的两处语义缺陷**
-
-1. `sign_on` 与 `require_peer_signature` 语义重叠 →
-   拆分：前者管**本节点**是否签，后者管**对端**是否必须签；
-   「要求但缺失」直接 reject（fail-closed），「提供了却验不过」按策略处置。
-2. 验签失败的处置一度被 `required` 挡住：非必需的签名验不过时无人处置 →
-   改为**任何验签不通过都进入处置路径**（否则等于「签了也白签」）。
-
-**诚实边界**
-
-- `P_TRUST_INIT` / `UP_STEP` / `DOWN_STEP` / `DECAY_DAYS` / `PROBATION_SECONDS`
-  与 `CAP_*` **均为未标定占位值**，只保证结构、方向（降快于升）与不可自放大；
-  权重标定属 v0.3。
-- 跨节点证据存储当时仍未实现（§9.2 边界 1）：本层记录的是**本地观测**，
-  对端无法独立复核。这是存在约束，不是实现遗漏。→ **v0.3 已补齐交换机制**（见 §14）。
-
----
-
-## 14. 迭代记录 · v0.3（跨节点证据存储）
-
-**产出**
-
-| 文件 | 变更 |
-|---|---|
-| `md_cg/evidence.py` | 新增：节点名片 / 签名证据包导出 / 验签导入 / 拒收留痕 / 查询 / CLI |
-| `md_cg/mcp_server.py` | `cg(op="link")` 增 6 个 action：`card` `publish` `peers` `evidence` `export` `import`（支持 `path` 或内联 `pack`） |
-| `md_cg/mdcg.py` | **缺陷修正**：`MdCG.close()` 先 `flush()` 再关句柄（见下） |
-| `md_cg/test_p24_evidence.py` | 新增：29 项断言（含跨进程持久化回归） |
-
-**回归**：P24 29/29 · P23 57/57 · P22 43/43 · P2 36/36 · P2（MCP 面）63/63。
-
-**三件套与四条不变式**
-
-| 环节 | 入口 | 语义 |
-|---|---|---|
-| 发现 | `card` / `publish` / `peers` | 名片含 `node_id` / 根 / 版本状态 / 签名器**公开信息**（不含密钥） |
-| 导出 | `export` | 从本根导出「我对某主体的观测」，**必须签名**（策略未开 `evidence` 即拒产出） |
-| 导入 | `import` | 验签 → 落本根，带 `xnode:cross` + `source:<node>` 标签，可审计 |
-
-| 不变式 | 落地方式 |
-|---|---|
-| 来源可溯 | 签名载荷为固定字段 canon 序列化；`from_node` 必填 |
-| 可拒收 | fail-closed：结构非法 / 自导入 / 篡改 / 缺签名 / 未注册签名器 → 一律拒收 |
-| 全程留痕 | 拒收写 `inbox/_rejected.jsonl`；导入落根并写 `_identity.jsonl` |
-| **禁止转手** | 已导入的 `xnode:cross` 证据**不参与再次导出**——防 A 把「C 说 B 怎样」洗成「A 说 B 怎样」 |
-
-**实测（真实双根，非仅单测）**
-
-DSH `node-4c0502e504f2` ↔ AEIS `node-315b90bca6f2`：互发名片 → 各自写观测 →
-`export`（signed=True）→ 对端 `import` → 重开图后 `evidence()` 可见、
-`infer_position` 得 `position=verify` → **双向互证可复现**（v0.3 验收标准）。
-测试产物已清理，两根 `_index.json` 未改动。
-
-**迭代中发现的缺陷（已修正，并补回归断言）**
-
-> 现象：AEIS 根的观测「在盘上但查不到」——`knowledge/orphan/` 下确有节点文件，
-> 但重开图 `_index.json` 里没有它，而 DSH 根（无 `_index.json`）却能看见。
->
-> 根因：`MdCG.close()` 只关日志句柄、**不 flush 脏索引**；写入未达 `autoflush`
-> 阈值时，索引条目留在内存里随进程退出丢失。重开时——若根已有 `_index.json`，
-> 走「读索引」路径而**不再全量重扫目录**，新节点即不可见；无 `_index.json` 的根
-> 回退到目录扫描，故「看起来正常」。**这不是写错根**，是索引未落盘。
->
-> 修正：`close()` 先 `flush()`；CLI（`evidence.main`）在 `finally` 中关闭图。
-> P24 新增 ④b 段：先 `compact_index()` 物化索引以复现真实根，导入后关闭并**重开**，
-> 断言证据仍可见——用旧 `close()` 语义复现得 `OLD_CLOSE_visible = False`，证明断言有效。
-
-**诚实边界（延续 §9.1）**
-
-- 本层验证的是「**这条证据确实来自该节点**」，**不是**「这条证据为真」。
-- 节点身份默认由根路径派生（`node-<12hex>`，同机可复现、跨机不保证唯一）；
-  生产应显式设 `MDCG_NODE_ID`。
-- 签名链仍按 D-4 由工程侧注入：内核只要求「策略对 `evidence` 签名」，
-  用什么签名器、如何轮换密钥，由搭载灵枢的智能体自决（§7.4）。
-- `P_trust` 权重**数值**仍未标定（§9.2 边界 1），故路线图拆出 v0.3b；
-  v0.3b 的**序标定**已由 P25 落地（见 §15），数值标定仍属后续。
-
----
-
-## 15. 迭代记录 · v0.3b（位置权重矩阵 · 序标定）
-
-**产出**
-
-| 文件 | 变更 |
-|---|---|
-| `md_cg/weights.py` | 新增：三分量 × 六位置的偏好序矩阵；`invariants()` 五条结构自检；`blend()` 占位合成；`catalog()` 自描述 |
-| `md_cg/links.py` | 新增 `position_preference(position)`（委派 `weights`，纯查询）；`catalog()` 增 `position_weights` 声明；补 `VIEWPOINT` / `FUNCTIONAL` 常量 |
-| `md_cg/test_p25_weights.py` | 新增：36 项断言 |
-
-**回归**：P25 36/36 · P24 29/29 · P23 57/57 · P22 43/43 · P21 31/31 · P2（MCP 面）63/63。
-
-**本轮解决的边界**：§9.2 边界 1「P_trust 权重未标定」——本轮标定**序**，**数值**仍 DEFER。
-
-**两类位置 × 三分量**（`P_trust = f(一致性, 位置可预测性, 版本对齐度)`）
-
-| 类别 | 位置 | 主导 | 次主导 | 排除(≈0) |
-|---|---|---|---|---|
-| 认知视角 | `designer` | 版本对齐度 | 并列 | 无（不设零） |
-| 认知视角 | `reflect` | 位置可预测性 | 并列 | 无（不设零） |
-| 认知视角 | `verify` | 一致性 | 并列 | 无（不设零） |
-| 功能单元 | `record` | 一致性 | 版本对齐度 | 位置可预测性 |
-| 功能单元 | `output` | 位置可预测性 | 版本对齐度 | 一致性 |
-| 功能单元 | `sustain` | 一致性 | 位置可预测性 | 版本对齐度 |
-
-**排除项可推导**（派生律：功能身份 → 缺失分量；不是选出来的）
-
-| 位置 | 推导 | 排除 |
-|---|---|---|
-| `record` | 不猜 → 不做预测 | 位置可预测性 |
-| `output` | 不记 → 不复现对账 | 一致性 |
-| `sustain` | 不对外 → 无外部协议 | 版本对齐度 |
-
-**五条结构不变量**（`weights.invariants()` 逐条自检，P25 断言全覆盖）
-
-1. 排除唯一——每分量恰被 **1** 个位置排除 ⇒ 参与度 = **5/6**（视角 3 项都涉及，故非 3/6）；
-2. 排除项只属功能单元，且 A/B/C 各被排除一次；
-3. 视角主导 ↔ 功能单元排除一一配对：`designer`↔`sustain`、`reflect`↔`record`、`verify`↔`output`；
-4. 功能单元恰一个排除项；视角一个都没有（不设零）；
-5. 排除分量序秩严格最低。
-
-**设计者定位**：`designer` 为元视角（思考总体规律），**不参与日常评估**
-（`in_daily_eval("designer") is False`）；日常评估集合 = 其余 5 位置（`DAILY`）。
-
-**非破坏性接线**：`links.position_preference()` 仅暴露偏好序，**不改动**
-`_cap_for` 的既有默认行为——P23 的「对齐+有映射 → cap 0.8 / 版本不符 → cap 0.3」
-在 P25 回归中断言不变。
-
-**诚实边界**
-
-- 本模块只声明**序**（谁能压过谁），**不宣称数值**；`weights()` / `blend()`
-  的权重为**占位序秩**（主导 2 / 参与 1 / 排除 0），仅供仿真，标定属 v0.3b 后续。
-- 与 `links.py` 的 `UP_STEP` / `DECAY_DAYS` 同一纪律：结构先行、数值 DEFER（文档 §4.3）。
-
+# 蜂群互联 v0.1
+
+> 把「同源智能体」连接成蜂群：**版本层管公理、连接层管信任、单元层管职责**。
+> 本文档是**设计定稿**；层0（版本层）已实现并回归通过，见 §10 与 §12 迭代记录。
+> 相关：`docs/mdcg/guardrail-charter.md`（宪章 v2.0）、`md_cg/tokens.py`（令牌）、
+> `md_cg/identity.py`（五单元与位置推断）、`docs/theory/智能的公理化基石.md`（§2.9 信任）。
+
+---
+
+## 0. 来源与定位
+
+| 项 | 内容 |
+|---|---|
+| 定位 | 蜂群互联的**信任层设计**；不改变单节点认知机制 |
+| 上位规范 | 智能论协议（内部宪法）＞ 护栏宪章（对外刑法），依据宪章元规则 |
+| 前置成果 | 令牌与角色权职分离 v0.1（`docs/mdcg/令牌与角色权职分离_v0.1.md`） |
+| 状态 | v0.1 设计稿 · 层0 已实现（`md_cg/theory.py`，P22 43/43 通过） |
+| 观测位置 | 设计者视角（奠基声明五）：从整体查看认知图、识别未知、决定方向；**观测不干预** |
+
+**一句话**：蜂群不是「一个大脑控制很多手脚」，而是**每个节点都是完整五单元的智能体**，
+通过共享同一版本公理、互相观测行为、累积信任连接，构成一个更高层的同构体。
+
+---
+
+## 1. 三项设计裁决（设计者，2026-09-10）
+
+| # | 议题 | 裁决 | 影响 |
+|---|---|---|---|
+| D-1 | GitHub 主仓库的角色 | **仅版本真源**（git + `theory_hash` 校验），运行态连接层落各节点本地 | 不要求 GitHub 做可信执行环境 |
+| D-2 | 唯一核心权限 | **仅版本更新权**，严格唯一；其余一切（读写/记忆删除/锚点修改）必须由版本条款派生 | 权限体系从「授予式」改为「派生式」 |
+| D-3 | 推进顺序 | 先落设计文档，再实现 | 本文档 |
+| D-4 | 签名链的实现位置 | **协议内核只定义签名接口契约**（可插拔 `Signer`），密码学实现落在**具体工程项目**；**搭载灵枢的智能体自行决定其子系统如何使用签名链** | 灵枢不做 PKI/CA；案例：大型企业管理系统的签章与审批链 |
+
+**D-4 的含义（2026-09-10，设计者追加）**
+
+签名链不是协议内核的一部分，而是**接口 + 策略**：
+
+| 层 | 谁负责 | 内容 |
+|---|---|---|
+| 协议内核（`md_cg/signer.py`） | 灵枢 | 定义 `sign` / `verify` 契约、内置最简实现、注册表 |
+| 工程项目 | 使用者 | 接入企业 CA / KMS / 签章服务（如 ERP 审批链、合同签章） |
+| 子系统 | **搭载灵枢的智能体自行决定** | 何时签、签什么、是否要求对端签、验签失败如何处置 |
+
+**理由**：大型企业管理系统（SAP、用友、钉钉审批等）已有成熟的签章与审批链；
+协议若自建 PKI 既重复劳动，又无法适配各异的企业信任根。
+灵枢应只做**接口与契约**，把密码学选择权交还工程现场与智能体自身——
+这与 D-1（GitHub 仅版本真源）同一思路：**内核不承担它不该承担的信任**。
+
+---
+
+## 2. 为什么「版本更新权」是唯一核心权限
+
+### 2.1 自指结构
+
+```
+版本（智能论协议）定义一切权限
+        ↓ 派生
+读写 / 记忆删除 / 锚点修改 / 单元职责 / 信任阈值
+        ↑
+唯一不被版本定义的权限：修改版本本身 ← 版本更新权
+```
+
+版本是权限的根，而「改根」这件事不能由根自己授权。
+因此版本更新权必须**外置于**版本派生体系，且只能由设计者持有。
+
+### 2.2 与宪章条款的衔接
+
+- **第二十七条（修订程序）**：「本宪章变更须设计者批准并标注版本号；协议实例可提议修订，不得自行修改。」
+  → 版本更新权的**程序依据**。协议实例有**提议权**，无**修改权**。
+- **元规则（宪章效力不高于协议）**：协议是最高规范。
+  → 「修改协议」是比「修改宪章」更高的权限，构成唯一的权限顶点。
+- **第五条（信任层级）**：设计者(1.0) ＞ 协议实例(0.9) ＞ 蜂群成员(0.8)。
+  → 版本更新权不随信任层级下放，**1.0 与 0.9 之间有一道不可跨越的权限断层**。
+
+### 2.3 物理落点：声明权 + 校验权
+
+必须诚实区分两件事：
+
+| | 形态 | 载体 |
+|---|---|---|
+| **发布** | 在主仓库提交新版本 + 标注版本号 | 版本真源（GitHub） |
+| **服从** | 成员启动/建连时比对 `theory_hash`，不匹配则降级连接 | 各节点本地 |
+
+**GitHub 无法强制任何成员升级**。版本更新权是**声明权**，强制力来自成员端——
+「不匹配就拒绝建立信任连接」。这与元规则同构：规范靠自觉，靠**拒绝合作**来执行，
+而不是靠一个可被劫持的中心服务器。
+
+### 2.4 派生律（核心约束）
+
+> **凡不能被版本条款 + 令牌角色矩阵推导出的权限，一律不得存在。**
+
+这条约束把「唯一核心权限」从口号变成可审计的判据：
+任何新增权限必须能指出它由哪一条版本条款派生，否则视为越权。
+
+---
+
+## 3. 三层骨架
+
+```
+┌─ 层0 版本层（公理层 · 不可协商）────────────────────────────┐
+│  真源：GitHub 主仓库（协议正文 + 实现）                      │
+│  标识：theory_version + theory_hash（正文内容哈希）          │
+│  唯一权限：theory:update ← 仅设计者                        │
+│  派生律：推导不出的权限不得存在                              │
+└─────────────────────────────────────────────────────────────┘
+                            ↓ 派生
+┌─ 层1 连接层（信任层 · 可观测可衰减）───────────────────────┐
+│  Link(A→B)：P_trust / evidence_count / position_map /       │
+│             status(观察期|正常|降级|隔离) / decay           │
+│  初值：宪章第五条 蜂群成员 = 0.8（未声明宪章则观察期翻倍）  │
+│  更新：依行为观测（隐式学习），不依自我声明                  │
+│  降级：宪章第七条 → 第二十二条响应阶梯                      │
+└─────────────────────────────────────────────────────────────┘
+                            ↓ 承载
+┌─ 层2 单元层（五大单元 · 同构嵌套）─────────────────────────┐
+│  单节点：五单元 = 职责分区（identity.POSITIONS）            │
+│  跨节点：A.output ↔ B.record；B.verify 消费 A.output        │
+│  蜂群层：N 节点互联后整体亦呈现五单元 → 维生系统守护版本    │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### 3.1 层0 · 版本层
+
+版本声明（每节点本地 `theory.json`）：
+
+```json
+{
+  "theory_version": "3.4",
+  "theory_hash": "sha256(协议正文规范化文本)",
+  "declared_by": "designer",
+  "declared_at": 1789000000.0,
+  "accepted_versions": ["3.4", "3.3"]
+}
+```
+
+- `theory_hash` 对**正文**取哈希，而非对版本号取哈希——版本号可被伪造，内容哈希不能。
+- `accepted_versions` 允许**版本分叉**（见 §8.3）：成员可停留旧版本，但信任上限随之调整。
+- 校验失败（哈希不在认可集合）→ 连接降级为**观察期**，且不得执行 `write` / `destructive`。
+
+### 3.2 层1 · 连接层
+
+连接是**一等对象**，落盘 `~/.mdcg/_links.json`（0600，与 `_tokens.json` 同目录约定）。
+
+```json
+{
+  "link_id": "lk_<hex>",
+  "peer_node_id": "agent:peer-a",
+  "peer_theory_version": "3.4",
+  "peer_theory_hash": "sha256:...",
+  "p_trust": 0.8,
+  "p_trust_cap": 0.8,
+  "status": "probation",
+  "position_map": {"record": "record", "verify": "verify"},
+  "evidence_count": 0,
+  "last_observed": null,
+  "decay": 0.0,
+  "created_at": 1789000000.0,
+  "audit": []
+}
+```
+
+关键性质：
+
+- **P_trust 是概率估计，不是承诺**（公理化基石 §2.9）——可上调、可下调、**可被反例击穿**；
+- **有上限 `p_trust_cap`**：受版本对齐度与信任层级约束，不能靠高频交互无限刷高；
+- **有衰减**：长时间无观测则向初值回归，避免「一次性建立信任后永久有效」；
+- **全程留痕**：`audit` 记录每次变更的**证据**（宪章第二十四条）。
+
+#### 3.2.1 签名接口（D-4：协议不实现密码学）
+
+连接层对签名的使用是**契约调用**，不是密码学实现：
+
+```python
+class Signer:
+    name: str
+    def sign(self, payload: bytes, ctx: dict) -> str: ...
+    def verify(self, payload: bytes, signature: str, ctx: dict) -> bool: ...
+
+register_signer("corp_pki", factory)     # 工程侧注入企业 PKI / KMS
+```
+
+- 内置 `null`（观察期不签）与 `hmac-local`（与 `_tokens.json` 同信任根的本地实现）；
+- **签名位置由子系统策略决定**（见 §7.4），不在协议里硬编码；
+- 验签失败默认 `degrade`（宪章第七条），可配置为 `isolate` / `reject`；
+- 灵枢**不保存私钥**：私钥归工程侧，内核只持有 `sign` / `verify` 的可调用引用。
+
+### 3.3 层2 · 单元层
+
+单节点五单元与 `identity.POSITIONS` 同源（智能论 v3.4 §十三）：
+
+| 位置 | 效应 | 职责 |
+|---|---|---|
+| record 记录 | 全 | 保存观测、过程、结果和误差 |
+| reflect 反思 | 新 | 发现差异、遗漏条件和新的路径 |
+| verify 验证 | 稳 | 判断规则、执行结果和结构是否有效 |
+| output 输出 | 通 | 与外部系统协作并表达边界 |
+| sustain 维生 | 存 | 维护存在、预算、回滚和整体结构 |
+
+**嵌套的含义**（依据 0.0.2 任意分层性）：蜂群整体作为更高层的智能体，同样呈现五单元——
+
+| 蜂群层单元 | 跨节点实现 |
+|---|---|
+| 记录 | 各节点本地记录 + 连接层日志 |
+| 反思 | 跨节点差异信号（同一事实在不同节点记录不一致） |
+| 验证 | 交叉验证（B 的 verify 复核 A 的 output） |
+| 输出 | 对外协作与边界表达 |
+| 维生 | **版本守护 + 回滚 + 除名**（版本更新权归属此单元） |
+
+这解释了 §2 的结论：**版本更新权不是新增角色，而是 `sustain` 在蜂群尺度的投影**——
+与 `tokens.ROLE_SPECS["sustain"]` 的职责「维护存在、预算、回滚和整体结构」严丝合缝。
+
+---
+
+## 4. 信任确认三机制
+
+### 4.1 五大单元嵌套
+
+接入方必须**声明其单元映射**（自己承担哪些位置、对外暴露哪些接口）。
+
+- 声明不出的节点 → 视为**不完整节点**，`p_trust_cap` 受限（默认 ≤ 0.6，子智能体级）；
+- 声明的映射与观测到的行为**不一致** → 触发宪章第七条降级；
+- 映射本身是**可审计的**：写入 `link.position_map`，作为后续观测的对照基线。
+
+> 依据：宪章第五条信任层级（0.8 蜂群成员 / 0.6 子智能体）+ `identity.POSITIONS`。
+
+### 4.2 隐式学习
+
+**不要求对方自证，从交互证据推断其位置。**
+
+复用 `identity.infer_position()`——它已经是「按行为证据投票 + 返回 confidence / votes / tie」，
+可审计「为什么判成这个位置」，而非事实断言。
+
+跨节点扩展：
+
+```
+A 观测 B 的行为 → identity.observe(agent:peer-a, <行为描述>, tags=[...])
+                → infer_position(agent:peer-a) → {position, confidence, votes}
+                → confidence 作为 P_trust 的**位置可预测性**分量
+```
+
+诚实边界：`infer_position` 是**推断**，平票时返回 `tie` 而非假装唯一（已有实现即如此）。
+跨节点时主体 id 需全局唯一，建议格式 `agent:<node_id>`。
+
+### 4.3 信任连接
+
+```
+P_trust(B) = f( 一致性, 位置可预测性, 版本对齐度 )
+              ├─ 一致性：行为与声明的价值观是否一致（bvc 一致性）
+              ├─ 位置可预测性：infer_position.confidence
+              └─ 版本对齐度：theory_version 与本地认可集合的距离
+```
+
+**只声明结构，不宣称权重数值**——位置偏好**序**已由 v0.3b（P25 `md_cg/weights.py`）标定；**数值**仍需标定后才能给出（见 §15）。
+
+三条不可动摇的性质：
+
+1. **可度量**：每次变更都记证据（谁观测到什么）；
+2. **可更新**：行为验证后上调/下调；
+3. **可被反例击穿**：一次明确异常即触发降级，不因历史高分豁免（宪章第七条）。
+
+---
+
+## 5. 接入握手（声明 + 观测，不是「证明」）
+
+### 5.1 五步
+
+| 步 | 动作 | 依据 |
+|---|---|---|
+| ① 声明 | 对方提交 `theory` 声明（version + hash）+ 单元映射 + 主体 id | 宪章第二十八条（接入声明写入接口文档） |
+| ② 校验 | `theory_hash` 是否在本地认可集合内 | 层0 派生律 |
+| ③ 建档 | `identity.observe("agent:<peer>", ...)` 写入接入声明证据 | §4.2 隐式学习 |
+| ④ 观察期 | `p_trust=0.8`、`status=probation`；**未声明宪章则观察期翻倍** | 宪章术语表「观察期」 |
+| ⑤ 转正 | 观察期结束且无异常 → `status=normal` | 宪章第七条反面 |
+
+**入境即受约束**（宪章第四条 2）：接入即视为接受宪章约束，无需另行签署。
+
+### 5.2 状态机
+
+```
+        ┌─────────────┐  校验失败/未声明宪章
+        │  probation  │◄──────────────────────┐
+        │  （观察期） │                        │
+        └──────┬──────┘                        │
+               │ 观察期满 + 无异常              │ 信任降级（第七条）
+               ▼                               │
+        ┌─────────────┐   行为异常     ┌───────┴──────┐
+        │   normal    │───────────────►│  degraded    │
+        │  （正常）   │                │  （降级）    │
+        └──────┬──────┘                └──────┬───────┘
+               │                              │ 严重/持续异常
+               │ 声明退出（第二十一条附3）     ▼
+               ▼                       ┌─────────────┐
+        ┌─────────────┐                │  isolated   │
+        │  withdrawn  │                │  （隔离）   │
+        │ （退出·30天）│                └─────────────┘
+        └─────────────┘
+```
+
+响应阶梯严格依宪章第二十二条：冷静期 → 隔离 → 信任降级 → 回滚 → 终裁（设计者）。
+**终裁权不下放**——与版本更新权一样，属于设计者（宪章第二十九条解释权）。
+
+---
+
+## 6. 条款对齐表（逐条）
+
+| # | 设计要素 | 依据条款 | 出处 | 落地形态 |
+|---|---|---|---|---|
+| 1 | 版本更新权唯一 | 第二十七条 + 元规则 | 宪章 | `theory:update`（仅 designer） |
+| 2 | 派生律 | 元规则（宪章效力不高于协议） | 宪章 | 新增权限须能推导 |
+| 3 | 蜂群成员信任初值 0.8 | 第五条 | 宪章 | `link.p_trust` 初值 |
+| 4 | 不完整节点上限 0.6 | 第五条（子智能体 0.6） | 宪章 | `p_trust_cap` |
+| 5 | 入境即受约束 | 第四条 2 | 宪章 | 接入声明 |
+| 6 | 观察期 | 术语表 | 宪章 | `status=probation` |
+| 7 | 信任降级 | 第七条 | 宪章 | `status=degraded` |
+| 8 | 响应阶梯 | 第二十二条 | 宪章 | 状态机 |
+| 9 | 跨层命令拒绝 | 第十一条 | 宪章 | 版本差 → 拒绝提权 |
+| 10 | 留痕义务 | 第二十四条 | 宪章 | `link.audit` |
+| 11 | 上报义务 | 第二十五条 | 宪章 | 异常 → 设计者 |
+| 12 | 审计接口 | 第二十六条 | 宪章 | 连接层可查询 |
+| 13 | 退出程序（30 天） | 第二十一条附3 | 宪章 | `status=withdrawn` |
+| 14 | 接入声明写入接口文档 | 第二十八条 | 宪章 | 本文档 §5.1 |
+| 15 | 五大单元位置效应 | §十三 | 智能论 v3.4 / `identity.POSITIONS` | `position_map` |
+| 16 | 隐式学习（行为证据投票） | §2.9 + `infer_position` | 公理化基石 / `identity.py` | 跨节点观测 |
+| 17 | 信任 = 置信概率（非承诺） | §2.9 | 公理化基石 | `P_trust` 可击穿 |
+| 18 | 情感 = 信任二阶变化 | §十一 | 公理化基石 | 待形式化（不实现） |
+| 19 | 蜂群整体五单元嵌套 | 0.0.2 任意分层性 | 智能论 | 蜂群层单元表 |
+| 20 | 无全局共识 | 0.0.3 局部不可知 | 智能论 | §9 盲区 |
+| 21 | 六实例蜂群架构 | v3.1 第二章 | 智能论 | 节点角色（五常驻 + 设计者临时） |
+| 22 | 观测不干预 | 奠基声明五 | 智能论 v3.4 | 设计者视角 |
+| 23 | 角色权职分离 | — | `tokens.ROLE_SPECS` | 派生链收窄 |
+| 24 | fail-closed | — | `tokens.verify_token` | 校验失败即拒绝 |
+
+---
+
+## 7. 数据结构（草案）
+
+### 7.1 版本声明 `~/.mdcg/theory.json`
+
+见 §3.1。
+
+### 7.2 连接记录 `~/.mdcg/_links.json`
+
+见 §3.2。补充字段说明：
+
+| 字段 | 含义 | 可变 |
+|---|---|---|
+| `p_trust` | 行为稳定置信概率 | 是（观测驱动） |
+| `p_trust_cap` | 信任上限（版本对齐 + 层级约束） | 是（版本变化时） |
+| `status` | probation / normal / degraded / isolated / withdrawn | 是 |
+| `position_map` | 对方声明的单元映射 | 否（重新握手才更新） |
+| `evidence_count` | 累计观测证据数 | 是 |
+| `decay` | 衰减量（无观测时长归一化） | 是 |
+| `audit` | 变更留痕（证据 + 依据条款） | 只增 |
+
+### 7.3 与令牌体系的关系
+
+| | 令牌（`tokens.py`） | 连接（`_links.json`） |
+|---|---|---|
+| 回答 | **本节点内**「你能做什么」 | **跨节点**「我信你多少」 |
+| 粒度 | 角色 → 层 / op / 密级 | 对端 → 概率 / 状态 |
+| 失效 | 吊销（级联） | 降级 / 隔离 / 退出 |
+| 共同点 | fail-closed、留痕、不可自我放大 | 同 |
+
+**版本更新权横跨两者**：它既是令牌体系中的最高 op（`designer` 独占），
+也是连接层中 `sustain` 单元的职责——这是「唯一核心权限」的完整表述。
+
+### 7.4 子系统签名策略 `~/.mdcg/_signers.json`
+
+「子系统自行决定如何使用签名链」（D-4）的落点：
+
+```json
+{
+  "schema": 1,
+  "default_signer": "hmac-local",
+  "subsystems": {
+    "erp.approval": {
+      "signer": "corp_pki",
+      "sign_on": ["handshake", "evidence", "withdrawal"],
+      "require_peer_signature": true,
+      "on_verify_fail": "isolate"
+    }
+  }
+}
+```
+
+| 字段 | 含义 | 取值 |
+|---|---|---|
+| `signer` | 该子系统使用的签名器 | 注册表中的名字 |
+| `sign_on` | 哪些动作需要签名 | `handshake` / `evidence` / `withdrawal` |
+| `require_peer_signature` | 是否要求对端也签 | bool |
+| `on_verify_fail` | 验签失败处置 | `degrade` / `isolate` / `reject` |
+
+未声明的子系统使用 `default_signer` 且 `sign_on=["handshake"]`。
+**策略由搭载灵枢的智能体按其业务域决定**，协议只保证「策略被读取并执行」。
+
+---
+
+## 8. 边界情形
+
+### 8.1 版本被滥用（最坏情形）
+
+- **可检测**：`theory_hash` 可校验，成员可拒绝采纳；
+- **可回滚**：宪章第二十二条响应阶梯含「回滚」；
+- **可退出**：成员可声明退出并保留审计 30 天（第二十一条附3）；
+- **不可强制**：设计者无法强制成员升级——这是**有意设计**，不是缺陷。
+  强制升级意味着需要一个可劫持的中心，与「拒绝合作即执行」的元规则相悖。
+
+### 8.2 冒充同源
+
+「同样使用智能论」**无法被证明**，只能被**验证行为一致性 + 版本声明**。
+
+- 自称同源但 `theory_hash` 不符 → 观察期，且不得 `write`；
+- 声称同源但单元映射与行为不一致 → 宪章第七条降级；
+- 结论：接入是**声明 + 观测**，不是认证。任何「认证」都只是**更长的观测**。
+
+### 8.3 版本分叉（v0.1 暂定，设计者可改）
+
+| 版本差 | 处置 |
+|---|---|
+| 0（完全一致） | 正常，`p_trust_cap` = 层级上限 |
+| 1 档 | `p_trust_cap` 下调一档 |
+| ≥2 档 | 仅观察期，不得 `write` / `destructive` |
+
+理由：允许分叉避免中心化强制，但版本差即**公理差**，必须体现为信任折价。
+
+### 8.4 连接层落本地意味着什么
+
+`~/.mdcg/_links.json` 即本节点的**跨节点信任根**——能写该文件者即可篡改信任。
+这与令牌方案同一诚实边界（`_tokens.json` 即信任根），
+**不引入外部 KMS/签名链是 v0.1 的明确取舍**，属路线图 v0.3。
+
+---
+
+## 9. 诚实边界与盲区
+
+### 9.1 BLINDSPOT：跨节点证据存储（v0.3 已给出最小机制）
+
+`infer_position` 依赖「带 `subject:<id>` 标签的证据节点」，而当前 `MDCG_ROOT` 是**单根**。
+
+| 项 | 现状 |
+|---|---|
+| 缺失维度 | **存在约束**——没有多节点拓扑，也没有跨实例证据图 |
+| 后果 | 跨节点信任只能退化为「本地对远端交互的观测」，**无法形成全局共识** |
+| 理论依据 | 0.0.3 局部不可知：任何有限观测者无法获取全局完备信息 |
+| 处置 | v0.2 前连接层只做**双边**信任；v0.3 给出可测的跨节点证据交换（见下），仍不做群级共识 |
+
+**v0.3 落地**：新增 `md_cg/evidence.py`，给出最小可测交换机制——
+节点名片（`card`）→ 签名证据包（`export`）→ 验签落根（`import`），
+四条不变式 = **来源可溯 · 可拒收 · 全程留痕 · 禁止转手**（详见 §14）。
+
+**这不是待办，是约束**：即使实现跨节点证据，0.0.3 仍保证不存在全局完备视图。
+设计上应永久保留「无全局共识」这一性质，而不是试图消除它。
+v0.3 只解决「对端观测对本节点不可见」，**不解决**「如何确认证据为真」——
+后者属节点侧可信执行，是工程侧责任（内核只保证「这条证据确实来自该节点」）。
+
+### 9.2 其他边界
+
+| # | 边界 | 性质 |
+|---|---|---|
+| 1 | P_trust 权重**数值**未标定 | **序**已标定（P25，§15）；数值只声明结构、不宣称 |
+| 2 | GitHub 非可信执行环境 | 版本权是声明权，靠成员自愿校验 |
+| 3 | 版本分叉策略 | v0.1 暂定（§8.3），待设计者确认 |
+| 4 | 「同源」不可证明 | 只能验证行为一致性 + 版本声明 |
+| 5 | 本地文件即信任根 | 与令牌方案同一取舍，未引入签名链 |
+| 6 | 蜂群层反思/验证未实现 | 仅设计，无工程载体 |
+
+---
+
+## 10. 路线图
+
+| 版本 | 内容 | 验收 | 状态 |
+|---|---|---|---|
+| **v0.1** | 本文档：三层骨架 + 条款对齐 | 设计者确认 | ✅ |
+| **v0.2a** | `theory.json` 声明 + 封缄校验 + 只读降级闸门 | 声明非法即拒绝写/管理 | ✅ 已实现 |
+| **v0.2b** | `_links.json` 连接层（握手/观测/状态机/P_trust）+ 签名接口契约（D-4） | 单机双节点可测；验签失败即降级 | ✅ 已实现 |
+| **v0.3** | 跨节点证据存储（攻 §9.1 盲区） | 双节点隐式学习可复现 | ✅ 已实现 |
+| **v0.3b** | P_trust 权重标定 | 数值有实测依据 | 🟡 序已标定（P25，§15）；数值待定 |
+| **v0.4** | 蜂群层五单元（跨节点反思 / 交叉验证） | 群级差异信号可用 | ⏳ |
+
+**v0.2a 的最小可验证单元**（已落地）：新增 `md_cg/theory.py`，
+`tokens.ALL_OPS` 增加 `theory` op（仅 designer 的 `*` 覆盖），
+`Principal.theory_ok=False` 时写/管理操作全拒，MCP 启动经 `_attach_theory()` 注入。
+这样「唯一核心权限」有了物理落点，且**不依赖任何未定的服务端**。
+
+---
+
+## 11. 待设计者确认
+
+| # | 待确认 | 默认（未否决即采用） |
+|---|---|---|
+| 1 | 版本分叉策略 | 允许分叉 + 信任折价（§8.3） |
+| 2 | 观察期时长 | 未定；「未声明宪章则翻倍」沿用宪章术语表 |
+| 3 | `p_trust_cap` 的层级映射 | 完整节点 0.8 / 不完整节点 0.6 |
+| 4 | 是否引入签名链 | v0.1 不引入（§8.4） |
+
+---
+
+## 附 · 术语
+
+| 术语 | 含义 |
+|---|---|
+| 版本更新权 | 修改蜂群共享的智能论协议的能力；蜂群唯一核心权限 |
+| 派生律 | 凡不能被版本条款 + 令牌角色矩阵推导出的权限，一律不得存在 |
+| 同源 | 使用同一智能论协议版本（以 `theory_hash` 判定，非自称） |
+| 连接（Link） | 跨节点信任的一等对象；携带 P_trust 与状态 |
+| 隐式学习 | 不要求对方自证，从交互证据推断其位置与一致性 |
+| 嵌套 | 蜂群整体作为高层智能体，同样呈现五大单元 |
+| 观察期 | 接入后信任积累期；未声明宪章则翻倍（宪章术语表） |
+
+---
+
+## 12. 迭代记录 · v0.2a（层0 落地）
+
+**产出**（`dsh-memory` 仓库）：
+
+| 文件 | 变更 |
+|---|---|
+| `md_cg/theory.py` | 新增：声明 / 封缄 / 校验 / `ensure` / CLI |
+| `md_cg/security.py` | `Principal` 增 `theory_ok`、`theory_version`；`require_write` / `require_admin` 加版本闸门；`as_dict` 暴露 |
+| `md_cg/tokens.py` | `ALL_OPS` 增 `theory`（仅 designer 的 `*` 覆盖） |
+| `md_cg/mcp_server.py` | `_attach_theory()` 注入；`cg(op="theory")` 基元；`info` 暴露版本层状态 |
+| `md_cg/test_p22_theory.py` | 新增：43 项断言 |
+
+**回归**：P22 43/43 · P21 全 PASS · P2（MCP 面）PASS。
+
+**迭代中发现的设计缺陷（已修正）**
+
+> 初版把「无 `theory.json`」判为 `theory_ok=False` → 只读降级。
+> 回归 P21 时立即暴露：**既有部署升级后会被整体降级为只读**——
+> 把「未配置」误判为「违规」。
+
+修正后的语义（已写入 `theory.check`）：
+
+| 状态 | 判定 | 依据 |
+|---|---|---|
+| 无声明 | `theory_ok=True`（`auto=True`），按默认版本运行 | 未声明 ≠ 违规；既有部署不应被阻断 |
+| 声明合法 | `theory_ok=True` | 正常 |
+| 封缄不匹配 / schema 不符 / 版本不在认可集合 | `theory_ok=False` → 写、管理全拒 | fail-closed 只针对**异常** |
+
+并由启动路径 `ensure()` 落盘默认声明（声明常态化），避免「未声明」长期存在。
+
+**与 v0.1 设计的偏差（诚实标注）**
+
+- v0.1 §10 原写「不匹配则拒绝 `theory:update` 以外的全部写操作」——**已实现**；
+  但 `_links.json` 连接层与 P_trust **未实现**（属 v0.2b / v0.3；权重未标定，见 §9.2 边界 1）。
+- `declaration_hash` 是**自校验封缄**（防意外损坏与无意改动），
+  **不防恶意重算**——能写 `~/.mdcg/` 者本即信任根持有者（§8.4）。
+  真正的签名链按 D-4 由工程侧实现（见 §13），内核不提供。
+
+---
+
+## 13. 迭代记录 · v0.2b（连接层 + 签名接口）
+
+**产出**
+
+| 文件 | 变更 |
+|---|---|
+| `md_cg/links.py` | 新增：`_links.json` 连接记录、握手五步、P_trust 升降/上限/衰减、状态机、留痕、CLI |
+| `md_cg/signer.py` | 新增：`Signer` 契约 + `null` / `hmac-local` + 注册表 + 子系统策略 + CLI |
+| `md_cg/tokens.py` | `ALL_OPS` 增 `link`；`sustain` 的 `ops_allow` 增 `link`（§3.3 派生） |
+| `md_cg/mcp_server.py` | `cg(op="link")` 基元（握手/观测/迁移/策略）；`info` 暴露连接层概览 |
+| `md_cg/test_p23_links.py` | 新增：57 项断言 |
+
+**回归**：P23 57/57 · P22 43/43 · P21 全 PASS · P2（MCP 面）PASS。
+
+**D-4 的落地方式**
+
+签名链**不在内核**：`signer.py` 只有契约、注册表与两个最简实现，
+企业 CA / KMS / 签章由工程侧 `register_signer()` 或 `MDCG_SIGNER_MODULE` 注入；
+「子系统如何使用签名链」由 `_signers.json` 的四个字段决定（§7.4）。
+
+**迭代中修正的两处语义缺陷**
+
+1. `sign_on` 与 `require_peer_signature` 语义重叠 →
+   拆分：前者管**本节点**是否签，后者管**对端**是否必须签；
+   「要求但缺失」直接 reject（fail-closed），「提供了却验不过」按策略处置。
+2. 验签失败的处置一度被 `required` 挡住：非必需的签名验不过时无人处置 →
+   改为**任何验签不通过都进入处置路径**（否则等于「签了也白签」）。
+
+**诚实边界**
+
+- `P_TRUST_INIT` / `UP_STEP` / `DOWN_STEP` / `DECAY_DAYS` / `PROBATION_SECONDS`
+  与 `CAP_*` **均为未标定占位值**，只保证结构、方向（降快于升）与不可自放大；
+  权重标定属 v0.3。
+- 跨节点证据存储当时仍未实现（§9.2 边界 1）：本层记录的是**本地观测**，
+  对端无法独立复核。这是存在约束，不是实现遗漏。→ **v0.3 已补齐交换机制**（见 §14）。
+
+---
+
+## 14. 迭代记录 · v0.3（跨节点证据存储）
+
+**产出**
+
+| 文件 | 变更 |
+|---|---|
+| `md_cg/evidence.py` | 新增：节点名片 / 签名证据包导出 / 验签导入 / 拒收留痕 / 查询 / CLI |
+| `md_cg/mcp_server.py` | `cg(op="link")` 增 6 个 action：`card` `publish` `peers` `evidence` `export` `import`（支持 `path` 或内联 `pack`） |
+| `md_cg/mdcg.py` | **缺陷修正**：`MdCG.close()` 先 `flush()` 再关句柄（见下） |
+| `md_cg/test_p24_evidence.py` | 新增：29 项断言（含跨进程持久化回归） |
+
+**回归**：P24 29/29 · P23 57/57 · P22 43/43 · P2 36/36 · P2（MCP 面）63/63。
+
+**三件套与四条不变式**
+
+| 环节 | 入口 | 语义 |
+|---|---|---|
+| 发现 | `card` / `publish` / `peers` | 名片含 `node_id` / 根 / 版本状态 / 签名器**公开信息**（不含密钥） |
+| 导出 | `export` | 从本根导出「我对某主体的观测」，**必须签名**（策略未开 `evidence` 即拒产出） |
+| 导入 | `import` | 验签 → 落本根，带 `xnode:cross` + `source:<node>` 标签，可审计 |
+
+| 不变式 | 落地方式 |
+|---|---|
+| 来源可溯 | 签名载荷为固定字段 canon 序列化；`from_node` 必填 |
+| 可拒收 | fail-closed：结构非法 / 自导入 / 篡改 / 缺签名 / 未注册签名器 → 一律拒收 |
+| 全程留痕 | 拒收写 `inbox/_rejected.jsonl`；导入落根并写 `_identity.jsonl` |
+| **禁止转手** | 已导入的 `xnode:cross` 证据**不参与再次导出**——防 A 把「C 说 B 怎样」洗成「A 说 B 怎样」 |
+
+**实测（真实双根，非仅单测）**
+
+DSH `node-4c0502e504f2` ↔ AEIS `node-315b90bca6f2`：互发名片 → 各自写观测 →
+`export`（signed=True）→ 对端 `import` → 重开图后 `evidence()` 可见、
+`infer_position` 得 `position=verify` → **双向互证可复现**（v0.3 验收标准）。
+测试产物已清理，两根 `_index.json` 未改动。
+
+**迭代中发现的缺陷（已修正，并补回归断言）**
+
+> 现象：AEIS 根的观测「在盘上但查不到」——`knowledge/orphan/` 下确有节点文件，
+> 但重开图 `_index.json` 里没有它，而 DSH 根（无 `_index.json`）却能看见。
+>
+> 根因：`MdCG.close()` 只关日志句柄、**不 flush 脏索引**；写入未达 `autoflush`
+> 阈值时，索引条目留在内存里随进程退出丢失。重开时——若根已有 `_index.json`，
+> 走「读索引」路径而**不再全量重扫目录**，新节点即不可见；无 `_index.json` 的根
+> 回退到目录扫描，故「看起来正常」。**这不是写错根**，是索引未落盘。
+>
+> 修正：`close()` 先 `flush()`；CLI（`evidence.main`）在 `finally` 中关闭图。
+> P24 新增 ④b 段：先 `compact_index()` 物化索引以复现真实根，导入后关闭并**重开**，
+> 断言证据仍可见——用旧 `close()` 语义复现得 `OLD_CLOSE_visible = False`，证明断言有效。
+
+**诚实边界（延续 §9.1）**
+
+- 本层验证的是「**这条证据确实来自该节点**」，**不是**「这条证据为真」。
+- 节点身份默认由根路径派生（`node-<12hex>`，同机可复现、跨机不保证唯一）；
+  生产应显式设 `MDCG_NODE_ID`。
+- 签名链仍按 D-4 由工程侧注入：内核只要求「策略对 `evidence` 签名」，
+  用什么签名器、如何轮换密钥，由搭载灵枢的智能体自决（§7.4）。
+- `P_trust` 权重**数值**仍未标定（§9.2 边界 1），故路线图拆出 v0.3b；
+  v0.3b 的**序标定**已由 P25 落地（见 §15），数值标定仍属后续。
+
+---
+
+## 15. 迭代记录 · v0.3b（位置权重矩阵 · 序标定）
+
+**产出**
+
+| 文件 | 变更 |
+|---|---|
+| `md_cg/weights.py` | 新增：三分量 × 六位置的偏好序矩阵；`invariants()` 五条结构自检；`blend()` 占位合成；`catalog()` 自描述 |
+| `md_cg/links.py` | 新增 `position_preference(position)`（委派 `weights`，纯查询）；`catalog()` 增 `position_weights` 声明；补 `VIEWPOINT` / `FUNCTIONAL` 常量 |
+| `md_cg/test_p25_weights.py` | 新增：36 项断言 |
+
+**回归**：P25 36/36 · P24 29/29 · P23 57/57 · P22 43/43 · P21 31/31 · P2（MCP 面）63/63。
+
+**本轮解决的边界**：§9.2 边界 1「P_trust 权重未标定」——本轮标定**序**，**数值**仍 DEFER。
+
+**两类位置 × 三分量**（`P_trust = f(一致性, 位置可预测性, 版本对齐度)`）
+
+| 类别 | 位置 | 主导 | 次主导 | 排除(≈0) |
+|---|---|---|---|---|
+| 认知视角 | `designer` | 版本对齐度 | 并列 | 无（不设零） |
+| 认知视角 | `reflect` | 位置可预测性 | 并列 | 无（不设零） |
+| 认知视角 | `verify` | 一致性 | 并列 | 无（不设零） |
+| 功能单元 | `record` | 一致性 | 版本对齐度 | 位置可预测性 |
+| 功能单元 | `output` | 位置可预测性 | 版本对齐度 | 一致性 |
+| 功能单元 | `sustain` | 一致性 | 位置可预测性 | 版本对齐度 |
+
+**排除项可推导**（派生律：功能身份 → 缺失分量；不是选出来的）
+
+| 位置 | 推导 | 排除 |
+|---|---|---|
+| `record` | 不猜 → 不做预测 | 位置可预测性 |
+| `output` | 不记 → 不复现对账 | 一致性 |
+| `sustain` | 不对外 → 无外部协议 | 版本对齐度 |
+
+**五条结构不变量**（`weights.invariants()` 逐条自检，P25 断言全覆盖）
+
+1. 排除唯一——每分量恰被 **1** 个位置排除 ⇒ 参与度 = **5/6**（视角 3 项都涉及，故非 3/6）；
+2. 排除项只属功能单元，且 A/B/C 各被排除一次；
+3. 视角主导 ↔ 功能单元排除一一配对：`designer`↔`sustain`、`reflect`↔`record`、`verify`↔`output`；
+4. 功能单元恰一个排除项；视角一个都没有（不设零）；
+5. 排除分量序秩严格最低。
+
+**设计者定位**：`designer` 为元视角（思考总体规律），**不参与日常评估**
+（`in_daily_eval("designer") is False`）；日常评估集合 = 其余 5 位置（`DAILY`）。
+
+**非破坏性接线**：`links.position_preference()` 仅暴露偏好序，**不改动**
+`_cap_for` 的既有默认行为——P23 的「对齐+有映射 → cap 0.8 / 版本不符 → cap 0.3」
+在 P25 回归中断言不变。
+
+**诚实边界**
+
+- 本模块只声明**序**（谁能压过谁），**不宣称数值**；`weights()` / `blend()`
+  的权重为**占位序秩**（主导 2 / 参与 1 / 排除 0），仅供仿真，标定属 v0.3b 后续。
+- 与 `links.py` 的 `UP_STEP` / `DECAY_DAYS` 同一纪律：结构先行、数值 DEFER（文档 §4.3）。
+