@furongjun1999/dsh-memory 0.4.10 → 0.5.0

package/docs/hive//350/234/202/345/267/242/345/217/214/345/256/236/344/276/213/344/272/222/351/252/214_/350/256/276/350/256/241/345/256/232/347/250/277.md

@@ -1,503 +1,503 @@
-# 蜂巢双实例互验 · 设计定稿（打破自指悖论的工程形态）
-
-> **定位（2026-09-17 使用者裁定）**
->
-> 灵枢做的是 **AGI 架构探索**。蜂巢的功能**正是「元认知」与「自我改进」的正式工程基础**，
-> **而非仅仅是智能论理论的落地案例**。
->
-> 这条定位决定本文件的性质：它不是把一个理论概念工程化，而是给出**自我改进系统得以成立的必要工程条件**——
-> 一个会修改自身代码的系统，若不能同时保住「验证资格」，它的自我改进在结构上就不成立（§1.1）。
-> 智能论提供形式化语言与约束校验（§2 的条款对照），但**工程基础地位在蜂巢这一侧**。
->
-> 两个概念在本设计中的精确落点：
->
-> | 概念 | 工程落点 |
-> |---|---|
-> | **元认知** | 系统观测自身状态（`instance` / `role` / `fingerprint` / `progress`）并据此**裁决**——心跳即其接口（§7.2），断言 A1–A3 即其可裁决判据（§7.5） |
-> | **自我改进** | 系统改自身源码而**不丧失验证资格**——判据冻结（§3）与判据面/候选面分离（§7.6）使「改进」与「验证」在结构上同时成立 |
->
-> **本文件是本机制的唯一状态源**（设计定稿阶段）。角色映射、机械守卫定义、边界声明一律以此为准；
-> 实现落地后，行为面的唯一真源让位于源码 + 守卫测试，本文件转为设计依据。
->
-> 与既有文档的分工：`docs/hive/蜂巢工作记忆_项目计划.md` 管**工作记忆**（任务上下文的快照/接管）；
-> 本文件管**互验**（改蜂巢这件事本身由谁来验）。两者共用 `hive/wm.py` 的 git 三级闸，但语义不同。
-
-- 创建日期：2026-09-17
-- 状态：**设计定稿，待排期实现**（本轮不写码——使用者裁定）
-- 文档纪律：代码引用一律用「**文件 + 符号名**」定位，**不写行号**（手写行号必腐化，仓内已有活体教训）；
-  理论引用一律标注为**条款要点**，逐字原文以 `docs/theory/智能论3.4.md` 对应章节为唯一真源。
-
-## 表 0-1 · 使用者裁定（2026-09-17）
-
-**第一轮 · 形态裁定**
-
-| 决策项 | 裁定 | 含义 |
-|---|---|---|
-| 落地范围 | **先出设计文档定稿，暂不写码** | 本文件即交付物；实现另案排期 |
-| 隔离形态 | **git worktree 双副本** | 每实例独立 checkout（独立源码 + 独立编译产物 + 独立 jobs） |
-| 裁决权 | **主实例 + 专职验证实例 + 仲裁实例** | 单次迭代内角色固化：验证者不参与修改；仲裁者处理分歧 |
-
-**第二轮 · 四项待裁定项落定**
-
-| # | 议题 | 裁定 | 落点 |
-|---|---|---|---|
-| 1 | 跨迭代身份轮换 | **固化，不轮换** | 验证者确认本轮修改完成后，经 git 把自身同步到已更新版本即可——「互相修改」由此满足（§4.2） |
-| 2 | 第四角色「记录实例」 | **不做** | 记录职责由 git + 灵枢记忆 + 工作纪律 + 任务清单承担（§4.1） |
-| 3 | 互验产物留痕位置 | **入库并同步 GitHub 仓库**（作为标准功能） | 留痕面 = 仓内受版本控制目录，随仓推送、公开可复核（§7.3） |
-| 4 | 验证范围与阻塞性 | **全量套件 + 异步不阻塞** | 用心跳暴露进度；多任务异步处理；不停主实例 serve、不阻塞与使用者交流（§7.4） |
-
----
-
-## 1 问题：自指悖论及其精确工程形态
-
-### 1.1 循环依赖的准确结构
-
-```
-我们依赖蜂巢去验证蜂巢  →  验证者与被验证者是同一份代码
-        ↓
-改动蜂巢代码 X  →  验证 X 所用的判据也随 X 一起变动
-        ↓
-无法区分两种情形：
-    (a) 改动是对的，验证通过
-    (b) 判据被改宽了，所以什么都通过
-        ↓
-自指确认闭环：结论不可采信
-```
-
-这不是「工具不好用」，是**判定资格问题**——被验证者同时充当判据来源时，判定在结构上失效。
-
-### 1.2 现场取证（本仓实测，非推测）
-
-| 环节 | 实测现象 |
-|---|---|
-| 改 `hive/src/*.rs` 后执行 `cargo build --release` | **报 `os error 5`**——运行中的 `hive.exe` 被 Windows 文件锁占用，无法覆盖 |
-| 规避 | 必须先停 serve，才能重新编译 |
-| 停 serve 的后果 | 蜂巢不可用 → 第 17 条（任务派发统一走蜂巢）无法执行 |
-| 当时的退化做法 | 本机直跑 + 手工起隔离进程对照新旧行为（**手工双实例的雏形，但无身份、无守卫、无留痕**） |
-| 合规状态 | 违反第 17 条，只能如实自述 |
-
-**结论**：该路径**每轮蜂巢迭代必然复现**，不是偶发。它是本设计的靶心。
-
-同时，本仓已出现过**双实例的负面形态**：`hive/hive_mcp/mcp_server.py` 的 `_fresh_s` 注释记录了历史缺陷——
-心跳新鲜窗口三处不一致（MCP 侧 5.0s / `serve_start` 15s / CLI doctor 5000ms）导致存活误判
-→ 重复拉起第二个 serve → **双实例抢队列 / `_serve.json` pid 互覆 / `--stop` 只杀得掉一个**。
-
-**本设计必须正面回答这个问题**：双实例不是「随意多起一个进程」，而是必须带身份、带角色、带守卫的**受治理并存**。
-
-### 1.3 已排除的路径
-
-| 候选 | 裁决 | 理由 |
-|---|---|---|
-| 加深自省层次（多套几层反思） | **REJECT** | 3.12 条款要点：递归深度**默认限制 3 层**，超出该层级的逻辑自指**视为结构性盲区**——靠加深递归解自指，理论层面已被判无效 |
-| 只写文档、不落机制 | **REJECT** | 工程痛点有 1.2 节实锤，不落地则每轮迭代重犯第 17 条 |
-| 用宿主自带 subagent/team 替代蜂巢验证 | **REJECT** | 违反第 17 条明文（「宿主自带 subagent/team 不是等价通道」） |
-| 双实例互验（本设计） | **ACCEPT** | 依据见 §2 |
-
----
-
-## 2 理论对照（智能论条款 ↔ 工程约束）
-
-> **本节的性质**：智能论在此处提供两样东西——**约束否证**（3.12 直接排除「靠加深递归破自指」这条路径，见 §1.3）
-> 与**结构命名**（角色清单 / 截断点 / 外部锚定的形式化语言）。
->
-> **但本机制是否成立，由 §1.2 的实测痛点与 §7 的机械断言裁决，不由理论条款裁决**——
-> 这正是「工程基础」与「理论应用」的实质区别：前者的判据在现场，后者的判据在文本。
->
-> 逐字原文见 `docs/theory/智能论3.4.md` 对应章节。
-
-| 条款 | 条款要点 | 对本设计的约束 |
-|---|---|---|
-| **认知公理（无法自举）** | 系统无法自我确认自己的认知状态；元反思必须**外部锚定** | 验证者必须是**另一个实例**，不能是同实例的自我复核 |
-| **0.0.3 局部不可知** | 全局完备的外部校准者不可实现 | 本设计定位为**降级方案**，不宣称悖论被消除（见 §8） |
-| **3.9 分布式多实例架构** | 实例角色分工：主实例 / 验证实例 / 仲裁实例 / 记录实例 | 直接给出本设计的**角色清单**（§4） |
-| **3.12 递归验证反思机制** | 三级结构（行为验证 / 根源回溯 / 递归截断）；递归深度默认 **3 层**，超出即结构性盲区 | ① 禁止靠加深递归破自指；② 「判据再校准」必须**截断**（§3.5） |
-| **6.5 独立演化实例的合并** | 三阶段：发现与连接 / 摘要交换与初步评估 / 信任重建 | 定义实例间的**协议面**（身份、摘要、信任） |
-| **13.5 外部校准者悖论** | 高认知的外部校准者一旦理解协议即被吸收，独立视角丧失；悖论不可消除，只可降级 | 诚实边界：同机同源**不是**真外部锚定；真外部锚定属另一通道（§8） |
-| **13.5.3 跨条件空间对话（推荐）** | 不同条件空间不触发内化，产出可直接用于协议校准 | worktree 双副本 = **两个不同条件空间**（不同源码 / 不同二进制 / 不同 jobs）——这是选择 worktree 的理论依据之一 |
-
----
-
-## 3 破解机制：判据冻结
-
-### 3.1 自指故障的精确形态
-
-自指的关键不是「同一个进程」，而是**判据与其被验证对象同源**：
-
-```
-故障形态：判据来源 = 被验证对象来源
-          改 X → 判据也变 → 观测失效
-
-允许形态：判据来源 ≠ 被验证对象来源
-          改 X → 判据不动 → X 的变动可被观测
-```
-
-### 3.2 冻结判据 = 可观测的参照系
-
-**核心判断**：双实例之所以能破自指，**不在于两个实例更聪明，而在于每一轮迭代中至少有一个实例的判据是被冻结的**。
-
-```
-迭代 N：
-  主实例   改动（判据随源码变动 → 无法自证）
-  验证实例 冻结（运行着上一轮固化的二进制与测试套件 → 判据稳定）
-           ↓
-  用「冻结的判据」去测「变动的候选」
-           ↓
-  ✔ 候选的变动才有参照系，结论才可采信
-```
-
-**冻结的物理载体**：验证实例的 serve 进程 + 其 worktree 内的测试套件。本次迭代中**不重启、不替换、不接管**。
-
-### 3.3 判据来源必须与验证者身份绑定（本设计最关键的一条约束）
-
-| 做法 | 后果 |
-|---|---|
-| 验证者用**被验证者提供的**测试套件去测被验证者的二进制 | 被验证者只需把测试改成「通过」即可通过验证——**判据被被验证者控制，退化回自证** |
-| 验证者用**自己 worktree 内的**测试套件去测被验证者的二进制 | 判据来源与验证者身份绑定，被验证者无法触及——**构成本设计要求的分离** |
-
-**一句话**：「用什么测」必须来自验证者，「测什么」来自主实例。二者同源即失效。
-
-### 3.4 横向分摊 ≠ 纵向加深（3.9 与 3.12 的辨析）
-
-本设计最容易被误读的一点，必须写清：
-
-| 维度 | 含义 | 本设计 |
-|---|---|---|
-| **纵向加深**（3.12 限制对象） | 验证的验证的验证……递归下探 | **禁止**。递归深度默认 3 层，超出即结构性盲区 |
-| **横向分摊**（3.9 描述对象） | 同一层级内，多个实例并行分担不同职责 | **采用**。主实例 / 验证实例 / 仲裁实例是**同层并行**，不是递归嵌套 |
-
-**结论**：多实例破自指**不违反** 3.12 的截断约束——它走的不是「更深」，而是「更宽」。
-把「验证者不参与修改」误读为「再加一层验证者去验验证者」，才是踩线。
-
-### 3.5 冻结的代价与再校准（截断点在此）
-
-| 项 | 说明 |
-|---|---|
-| 代价 | 判据永久冻结 → 会随主线演进**逐渐过时**（旧判据测新能力，可能误判为回归） |
-| 解 | 验证实例**定期再校准**：在明确的、被记录的时间点上，把自身二进制更新到已合并的主线版本 |
-| 截断（3.12） | 「谁校准校准者」**不得继续递归追问**——再校准本身构成一次**受审查的迭代**，其批准点即截断点，到此为止 |
-
----
-
-## 4 角色映射（3.9 四角色 → 本设计取三）
-
-### 4.1 职责边界
-
-| 角色 | 3.9 条款要点 | 本设计落码 | 能做 / 不能做 |
-|---|---|---|---|
-| **主实例** | 执行、与外部交互、生成输出 | 承担迭代改动、编译候选、发起互验请求、执行 merge | **能**改代码 / 编译 / 提交候选 / 合并；**不能**裁自己的验证结论 |
-| **专职验证实例** | 验证主实例的判定、检查偏差 | 带冻结判据（自身 worktree 的二进制 + 测试套件）验证候选，产出 `verdict.json` | **能**验证 / 出裁决；**不能**参与本轮修改（否则判据污染） |
-| **仲裁实例** | 处理实例间分歧、执行恢复 | 当 verdict=fail 而主实例主张「判据过时」时独立复核，产出 `arbitration.json` | **能**裁决分歧 / 触发再校准；**不能**代替验证者出具常规验证结论 |
-| （记录实例） | 记录所有实例状态变化 | **不单设**——记录职责由 **git 历史 + 灵枢记忆 + 工作纪律 + 任务清单**共同承担（见 §9） | —— |
-
-**取三不取四的理由（已裁定，2026-09-17）**：记录职责在本仓已有四个成熟载体——git 提交历史（不可篡改的时序）、
-灵枢记忆（决策与教训的语义留痕）、工作纪律（判定资格与动作规范）、任务清单（进程态与派发留痕）——
-再设一个常驻记录实例属重复建设。**裁定：不做记录实例。**
-
-### 4.2 跨迭代身份轮换（**已裁定：固化，不轮换**）
-
-使用者原始表述含「**互相修改**」，易被读成「主 / 验身份互换」。**已裁定为固化**，
-其理由是本设计此前未写明的一条机制：
-
-> **验证者在确认本轮修改完成后，可通过 git 把自身同步到已更新版本**——
-> 「互相修改」的实质由此满足，**不需要身份轮换**。
-
-即：验证实例**始终**是验证者（身份永不互换），但它会在**迭代边界**上推进自己的判据基线
-（`git pull` / `merge` 已合并的主线 → 重编译 → 判据前进到新版本）。两个诉求因此同时成立：
-
-| 诉求 | 满足方式 |
-|---|---|
-| 角色固化（参照系稳定） | 单次迭代内验证者不参与修改；身份**永不**互换 |
-| 「互相修改」（判据不僵化） | 验证者经 git 在**迭代边界**把自身推进到已更新版本（即 §3.5 的再校准） |
-
-**关键时序约束**：再校准只允许发生在**本轮验证结论已落痕之后**（即 §7.4 的第 7 / 8 步之间），
-**不得**发生在第 4–5 步之间——否则验证者中途更换二进制，断言 A3（§7.5）立即失败。
-这正是「**迭代内冻结、迭代间推进**」的精确边界。
-
----
-
-## 5 隔离形态：git worktree 双副本
-
-### 5.1 为什么 worktree 在本场景是**必需的**（不只是「外部性更强」）
-
-这是把使用者裁定从「更好」升级为「不可替代」的论证：
-
-| 形态 | 编译产物路径 | 后果 |
-|---|---|---|
-| 同机双目录（三 env 覆盖） | 两实例若指向**同一** `target/release/hive.exe` | 主实例编译时被验证实例的运行中二进制**锁死** → `os error 5` **依旧复现**，自指痛点未解 |
-| **worktree 双副本** | 各 worktree 各有独立 `target/` → **二进制路径天然不同** | 主实例可自由重编译自己的候选，**不与验证实例的运行中二进制冲突** |
-
-**同时**，worktree 让 §3.2 的「冻结」有了物理落点：验证实例的 worktree 在迭代期间**其判据面不被触碰**，
-二进制与测试套件因此真正冻结；§3.3 的「判据来源绑定验证者身份」在 worktree 形态下**结构性成立**
-（验证者的测试套件物理上就在它自己的目录里，主实例无权改）。
-
-> **前提限定**：这以 §7.6 的「判据面 / 候选面分离」为条件——候选源码进入验证实例 worktree 时，
-> 判据面必须**以覆盖方式保持冻结**，否则冻结会被候选自带的测试悄无声息地替换掉（§7.6 详述）。
-
-> 附带收益：worktree 与 `wm.py` 的 git 三级闸**天然同构**——两者都以 git 分支为候选版本的寻址面。
-
-### 5.2 布局（符号名，路径由实例自行解析）
-
-```
-仓库（共享 .git 对象库）
-├── <主实例 worktree>      HIVE_INSTANCE=main      HIVE_ROLE=primary
-│   ├── hive/target/release/   ← 候选二进制（可自由重编译）
-│   └── hive/jobs/             ← 主实例任务队列
-├── <验证实例 worktree>    HIVE_INSTANCE=verifier  HIVE_ROLE=verifier
-│   ├── hive/target/release/   ← 冻结判据载体（迭代期间不动）
-│   └── hive/jobs/             ← 验证实例任务队列（独立）
-└── <仲裁实例 worktree>    HIVE_INSTANCE=arbiter   HIVE_ROLE=arbiter
-    └── hive/jobs/             ← 仲裁实例任务队列（独立）
-```
-
-**关键**：三实例的 `HIVE_JOBS_DIR` 各不相同 → 各自满足「同一 jobs 目录至多一个 serve」的既有守卫，
-**不绕过守卫，而是合法并存**。
-
-### 5.3 与 `wm.py` 三级闸的对接
-
-| 闸 | 既有语义 | 本设计用法 |
-|---|---|---|
-| `snapshot`（凭证闸） | 要求 `result.ok == true` 才允许快照产物 | 主实例候选产物的留痕走同一凭证口径 |
-| `merge`（主代理显式） | 只有主代理可发起合并；冲突诚实报错不自动解决 | **合并唯一入口仍是主实例**——验证结论不自动触发合并 |
-| `revert`（免费） | 未合并前放弃零成本 | 验证失败时主实例 revert 候选，无副作用 |
-
-**边界**：`wm.py` 服务的是**任务产物**（`jobs/<id>/` 下的 spec / result / log / progress），
-互验产物（§7.3 的 `verdict.json`）**不在其快照白名单内**——它走**独立留痕面**：入库并同步 GitHub（§7.3）。
-
----
-
-## 6 既有基础设施盘点（本设计不是从零建）
-
-| 件 | 现状（已落地） | 本设计的缺口 |
-|---|---|---|
-| `hive/serve_start.py` | `HIVE_CONFIG` / `HIVE_EXE` / `HIVE_JOBS_DIR` 三 env 覆盖；模块注释明写「使同一套拉起逻辑同时服务『真实部署』与『隔离测试』两种形态」；`FRESH_S` 心跳新鲜窗口，与 `main.rs` 的 `FRESH_MS` 同口径（跨语言靠注释约定 + 守卫测试对齐） | 无实例身份 / 无角色 / 心跳不含指纹 |
-| `hive/hive_mcp/mcp_server.py` | 与 `serve_start` 同口径解析三 env；`_ensure_serve` **复用** `serve_start.start()`（杜绝两条拉起路径 env 不一致）；`_fresh_s()` 以 `serve_start.FRESH_S` 为**单一常量源** | 无身份透传 |
-| `hive/src/main.rs` | 单实例守卫（心跳新鲜度 + pid 双判据）、`--force` 豁免、`recover_orphans` 崩溃恢复；`FRESH_MS` 与 MCP 侧同口径；**已确立「serve 自报心跳承载启动期固化事实」的模式**（`exec_py` / `exec_mode` + `exec_source` 来源诚实标注） | 心跳无 `instance` / `role` / `fingerprint` 字段 |
-| `hive/src/scheduler.rs` | `ServeCfg` 携带 `exec_py` / `exec_mode`，主循环每次写心跳一并自报；`exec_mode_of` 由执行器文件名推得 | 同一模式待扩至身份与指纹（§7.2） |
-| `hive/wm.py` | git 三级闸（snapshot / merge / revert）；`task/<job_id>` 分支；`HIVE_WM_DIR` 可覆盖 | 无「候选版本 = 带指纹的待验对象」这一语义 |
-| `hive/README.md` | 已明确「同一 jobs 目录至多一个 serve」「**不同 jobs 目录 = 不同 serve 实例，互不干扰**」「三 env 可覆盖」 | 文档未定义「多实例的**治理**形态」（身份 / 角色 / 互验协议） |
-
-**结论**：多实例的**物理隔离机制已具备**（本仓已有 `HIVE_JOBS_DIR` + `HIVE_CONFIG` 做隔离测试的实践），
-且「serve 自报心跳承载启动期固化事实」的模式**已被上一轮验证过**（`exec_py` / `exec_mode`）。
-缺口因此收窄为三处**同模式的扩展**：身份化（§7.1）+ 分离守卫（§7.4）+ 判据冻结的可断言化（§7.5）。
-
----
-
-## 7 待落地的机械守卫（定义，不含实现）
-
-### 7.1 实例身份（env 扩展）
-
-| env | 取值 | 语义 |
-|---|---|---|
-| `HIVE_INSTANCE` | `main` / `verifier` / `arbiter`（缺省 = `main`） | 实例身份，落心跳 |
-| `HIVE_ROLE` | `primary` / `verifier` / `arbiter` | 角色，决定该实例**被允许做什么**（如 verifier 拒绝发起 merge） |
-
-**兼容原则**：两 env **缺省即旧行为**（单实例部署零变更），不得成为新必填项。
-
-### 7.2 心跳扩展（`_serve.json` 增字段）
-
-| 字段 | 内容 | 用途 |
-|---|---|---|
-| `instance` | 实例身份 | 断言 A1 的输入 |
-| `role` | 角色 | 角色守卫的输入 |
-| `fingerprint` | **自身二进制的指纹**（内容 hash） | 断言 A2 / A3 的输入 |
-| `source_commit` | 构建时的 git commit | 溯源「这个二进制是什么版本」 |
-| `iter_id` | 当前正在处理的迭代 id（空闲时为 Null） | 进度可见性——§7.4 异步不阻塞的**观测面** |
-| `progress` | 验证进度（阶段 + 计数，如 `cargo_test 1/3`） | 心跳式进度暴露，**替代阻塞轮询**（第 4 项裁定的落点） |
-
-**心跳承载进度是第 4 项裁定的关键**：全量套件耗时长，若靠阻塞等待则会冻结主实例；
-把进度写进心跳后，主实例（与使用者）只需**拉取**心跳即可获知进展，等待成本被消除。
-
-**为何必须由 serve 自报心跳、不得由消费者读 env 判断**（本仓实测教训，直接继承）：
-
-`HIVE_INSTANCE` / `HIVE_ROLE` 与既有 `HIVE_EXEC_PY` **同性质**——serve 启动时由 env 固化，
-**子进程无法反查**。`main.rs` 的 `cmd_doctor` 与 `mcp_server.py` 的 `_heartbeat` 均已就此写明：
-「跨进程 env 不可反查，故心跳是唯一权威来源；用本进程 env 判资格必得错位结论」
-（真实案例：CLI 裸起 serve 的执行器是 exec.py，而 doctor 进程 env 里却指向 exec_cmd.py，
-据此判资格会把 llm_only 看成兼跑命令）。
-
-**因此**：实例身份与指纹一律**由 serve 写入自己的心跳**，消费者只读心跳、不读 env。
-
-**兼容原则**：旧心跳无这些字段时，消费者按「未知」处理，**不伪造默认值**，且**如实标注来源**
-——沿用既有的 `exec_source` 诚实口径（心跳缺失即标 `no_heartbeat_or_legacy`，字段缺失透传 Null）。
-
-### 7.3 验证产物契约（`verdict.json`）
-
-```json
-{
-  "iter_id": "…",
-  "verifier_instance": "verifier",
-  "verifier_fingerprint": "<验证者二进制指纹>",
-  "subject_instance": "main",
-  "subject_fingerprint": "<候选二进制指纹>",
-  "suite_origin": "<测试套件来源——必须是验证者自己的 worktree>",
-  "frozen_at": "<本轮冻结时刻>",
-  "verdict": "pass | fail",
-  "passed": 0,
-  "failed": 0,
-  "details": []
-}
-```
-
-**留痕位置（已裁定）**：**入库并同步 GitHub 仓库**——互验产物是本机制的**标准功能产物**，
-随仓版本控制、随 `push` 上 GitHub，公开可复核。
-
-| 项 | 设计 |
-|---|---|
-| 目录 | 仓内**受版本控制**目录（如 `hive/interop/<iter_id>/`）。**不能用** `hive/jobs/`——该目录已被 `.gitignore` 排除且含运行态 |
-| 文件 | `verdict.json`（常规验证）／ `arbitration.json`（分歧仲裁） |
-| 发布 | 验证实例产出后提交到**与候选同一迭代分支**（`task/<iter_id>`）并 `push origin`——verdict 与候选同分支，随合并一并进主线，可溯源对应关系；**推送验证结论不属「参与修改」**，与它的角色约束不冲突 |
-| 复核 | GitHub 侧 commit SHA + 时间戳构成**平台侧记录**，比本地私有运行态更难事后改写 |
-| 噪声治理 | 按 `<iter_id>` 分目录；实现期可加「只保留最近 N 轮 + 归档到 `hive/interop/archive/`」策略（实现细节，非设计约束） |
-
-**脱敏契约（硬门禁，第 9 / 14 条）**：入库即**公开**，产物**只允许**含结构化事实——
-指纹（hash）、断言结果（A1 / A2 / A3）、计数（passed / failed）、commit SHA、迭代 id、时间戳、符号化路径。
-
-**禁止**写入：`spec` 正文 / prompt / `result.content` / API 相关信息（key、base、model）/ 本机绝对路径。
-**每轮 `push` 前必须过「内容政策 + 隐私」双清单、0 命中方可推送**（第 14 条）——
-这是把「产物入库」从便利升级为标准功能时必须付的代价。
-
-### 7.4 迭代时序（异步、不阻塞）
-
-**设计原则（已裁定）**：验证跑**全量套件**（质量不降级），但**不得阻塞主实例、不得阻塞与使用者的交流**。
-手段是**异步派发 + 心跳暴露进度**——主实例只做「投递」，不做「阻塞等待」。
-
-```
-0. 准备     三实例各自 worktree 就绪；各自 serve 存活；各自心跳落自己的 jobs/
-            验证实例记录本轮冻结指纹 F_ver（该值与心跳 fingerprint 一致）
-
-1. 改动     主实例在自身 worktree 改代码 → cargo build --release
-            （自己的 target/，不被他人锁定 —— §5.1 的解）
-
-2. 提交候选  候选二进制指纹 F_c + commit SHA 记入本轮 iter 凭证
-            源码提交到 task/<iter_id> 分支（复用 wm.py 同源机制）
-
-3. 派发验证  ★ 非阻塞 ★ 主实例把验证任务作为普通蜂巢 job 投递到**验证实例的 jobs 目录**
-            （文件协议即接口：写 spec.json 即完成投递，与 hive_spawn 同语义）
-            投递后**立即返回**——主实例继续处理其他任务、继续与使用者交流
-            进度不靠阻塞轮询，靠**心跳**暴露（验证实例心跳带当前 iter_id 与进度）
-
-4. 验证（异步）先以**判据面覆盖候选面**（§7.6）保判据冻结，再对候选跑**全量套件**：
-            cargo test + scripts/run_tests.py hive + MCP 冒烟（三项全量，不按改动面裁剪）
-            产出 verdict.json → 入库 → push origin（§7.3）
-
-5. 断言     A1 verifier_instance ≠ subject_instance
-            A2 verifier_fingerprint ≠ subject_fingerprint
-            A3 verifier_fingerprint == 第 0 步的 F_ver（判据确未被本轮改动）
-            任一不成立 → 验证结论作废（不得进入第 7 步）
-
-6. 分歧     verdict=fail 且主实例主张「判据过时」→ 交仲裁实例独立复核 → arbitration.json
-            （仲裁者同样使用自己的冻结判据，不采信主实例提供的套件；同样异步派发）
-
-7. 合并     verdict=pass → **主实例**经 wm.py merge 合入主线；冲突诚实报错，不自动解决
-
-8. 再校准   验证实例更新自身二进制到已合并版本，记录时点（§3.5 的截断点；§4.2 的时序约束）
-```
-
-**「全量套件」与「不阻塞」如何共存**（这是第 4 项裁定的关键）：
-
-| 关注点 | 做法 |
-|---|---|
-| 质量 | 全量套件，不因「要快」而裁剪验证面 |
-| 不阻塞 | 验证是**另一个实例的 job**，在主实例的进程外执行——主实例的 serve 不参与、不等待 |
-| 可观测 | 心跳携带进度；主实例（或使用者）随时 `poll` 查询，属**拉取**而非阻塞推送 |
-| 交流不中断 | 主实例 serve 持续存活 → MCP 工具面持续可用 → 与使用者的对话不被验证任务挂起 |
-| 多任务并行 | 验证 job 与主实例的其他 job 在各自 jobs 目录并发，互不抢占（jobs 目录隔离） |
-
-### 7.5 断言 A3 是全设计的承重墙
-
-A1（身份不同）与 A2（指纹不同）都**弱**——只要起了两个进程就自动成立，不构成任何保证。
-
-**A3 才把「判据冻结」从口头约定变成可断言事实**：验证者声明的指纹必须等于本轮开始时记录的冻结值。
-若验证者在验证过程中把自己更新到候选版本（判据随之变动），A3 立即失败。
-
-> 类比：A1 / A2 证明「是两个人」，A3 证明「其中一个在看同一把尺子」。
-
-### 7.6 判据面 vs 候选面（冻结如何真正落地）
-
-「用验证实例自己的测试套件测候选」在实现上有一个**必须解决的细节**：
-
-> 候选源码一旦进入验证实例的 worktree，**测试套件会被一并替换**——判据随即被污染，A3 形同虚设。
-
-因此必须把两面物理分开：
-
-| 面 | 内容 | 谁能改 | 变化规则 |
-|---|---|---|---|
-| **判据面** | 测试套件（`hive/tests/`、`scripts/run_tests.py hive`、`md_cg/test_*.py`）与验收命令 | **只有验证实例自己** | 仅在**迭代边界**（§4.2）随再校准推进 |
-| **候选面** | 被测源码（`hive/src/*.rs`、执行器脚本等） | 主实例 | 每轮迭代自由变化 |
-
-**执行方式**：候选 checkout / 编译后，以**判据面覆盖候选面**（同名测试文件以判据面为准）再运行。
-断言 A3 因此**细化为**：*判据面文件集合的 hash == 本轮冻结值*——这比笼统的「二进制指纹」更贴近真实判据。
-
-**主实例需要新增测试时**（扩展判据的合法诉求）：不得让测试改动在本轮直接生效——
-它提交的测试改动**本轮不参与判据**，须经仲裁 / 再校准在**下一轮**纳入判据树。
-这样「**判据只增不减、只在边界前进**」得以保持，而新增覆盖能力不被阻塞。
-
-**若判据面与候选面接口不兼容**（候选改了被测接口，旧测试编译不过）：
-诚实报「判据与候选接口不兼容」→ 交仲裁 → **不得**自动改用候选自带测试（那等于让被验者提供判据）。
-
----
-
-## 8 设计边界（诚实，不夸大）
-
-| 边界 | 说明 |
-|---|---|
-| **不是真外部锚定** | 同机同源两实例共享代码谱系与认知图真源，属 13.5.1 意义上的**降级方案**——悖论不可消除。真外部锚定需 13.5.4 多源异质聚合（外部评审等），属另一通道 |
-| **worktree 共享 `.git` 对象库** | git worktree 的「独立」是**工作区级**，不是仓库级——提交历史与对象库仍共享。恶意规避（绕过 worktree 直接改共享 ref）不在本设计防线内 |
-| **判据冻结会过时** | 见 §3.5。旧判据误判新能力为回归时，须走仲裁 → 再校准流程，**不得由主实例自行宣布判据失效** |
-| **不提升到信号级隔离** | 沿用既有诚实边界：kill 与超时检测粒度 = 1s 轮询，非信号级即时 |
-| **不改变单实例守卫** | 本设计**不修改**「同一 jobs 目录至多一个 serve」这条约束，而是在合法的多 jobs 目录前提下定义身份与角色——**共存而不绕过** |
-| **本设计不消除悖论** | 目标是把不可消除的自指从「运行期静默错判」降级为「结构上可见的单例冻结判据」 |
-| **GitHub 留痕 ≠ 外部锚定** | 产物入库并推送 GitHub 提升了**可复核性**（平台侧时间戳 + 公开可查、外部任何人可审计），但仍是**同一账号、同一代码谱系**。诚实定位：**可复核性↑，同源性不变**——不构成 13.5.4 意义上的多源异质外部锚定 |
-| **异步不等于无人负责** | 「不阻塞」只免除**等待**，不免除**裁决**：verdict 未出之前候选**不得**合入主线（第 7 步是唯一入口），且断言未过即作废 |
-| **「工程基础」是功能定位，不是完备性声明** | 本设计解决的是「**自我改进时的验证资格**」这一个必要条件——它使自我改进**可能**成立，不宣称元认知已完成。目标生成、长期记忆演化、跨域迁移等属其它通道，不在本设计射程内 |
-
----
-
-## 9 与既有件的对接边界
-
-| 既有件 | 对接方式 | 不做什么 |
-|---|---|---|
-| `hive/serve_start.py` | 新增两 env 读取；心跳写入扩展字段 | 不改三 env 覆盖语义；不改 `start` / `stop` / `status` 的既有行为 |
-| `hive/src/main.rs` + `hive/src/scheduler.rs` | 心跳增字段；角色守卫（如 verifier 拒 merge）；沿用 `exec_source` 的来源诚实标注 | 不改 `FRESH_MS` 判活口径；不改崩溃恢复语义；不改 `exec_mode_of` 既有启发式 |
-| `hive/wm.py` | 复用其分支寻址机制（分支命名沿用 `task/<job_id>` 惯例，迭代 id 承载 `job_id` 语义）作为候选版本寻址面 | 不把 `verdict.json` 塞进任务快照白名单（语义不同） |
-| `hive/hive_mcp/mcp_server.py` | 心跳透传 `instance` / `fingerprint` 供 doctor 展示 | 不改四工具 schema 与并发语义 |
-| 记录实例职责 | 由 **git 历史 + 灵枢记忆 + 工作纪律 + 任务清单**共同承载 | 不新设常驻记录进程（§4.1 已裁定） |
-| GitHub 仓库 | 互验产物（`verdict.json` / `arbitration.json`）入库并随 `push` 同步，成为**标准功能产物** | 产物**不得**含 spec 正文 / prompt / result 正文 / API 信息 / 本机绝对路径（§7.3 脱敏契约） |
-| 第 17 条纪律 | 互验的每一步（候选编译 / 测试执行）**本身也应经蜂巢派发并留痕**；验证任务**异步派发、不阻塞** | 不得以「互验是特殊流程」为由绕过派发；也不得以「验证要等待」为由阻塞主实例与使用者交流 |
-
----
-
-## 10 落地排期
-
-### 裁定全部落定（2026-09-17 第二轮）
-
-| # | 议题 | 裁定 | 落点 |
-|---|---|---|---|
-| 1 | 跨迭代身份轮换 | **固化，不轮换**；验证者经 git 在迭代边界推进基线 | §4.2 |
-| 2 | 第四角色「记录实例」 | **不做**；由 git + 灵枢记忆 + 工作纪律 + 任务清单承担 | §4.1 / §9 |
-| 3 | 互验产物留痕 | **入库并同步 GitHub**（标准功能）+ 脱敏契约硬门禁 | §7.3 |
-| 4 | 验证范围与阻塞性 | **全量套件 + 异步不阻塞 + 心跳暴露进度** | §7.4 |
-
-**本设计已无未决项**，可直接进入实现排期。
-
-### 建议实现顺序（每步独立可验证）
-
-| 步 | 内容 | 验证方式 |
-|---|---|---|
-| 1 | 身份与心跳字段（§7.1 / §7.2） | 起两个不同 `HIVE_JOBS_DIR` + 不同 `HIVE_INSTANCE` 的 serve，doctor 各自报出正确身份与指纹；旧部署零变更 |
-| 2 | 指纹计算与断言 A1 / A2 | 单元测试：构造身份相同 / 指纹相同两类输入，断言拒绝 |
-| 3 | 断言 A3（冻结值核对） | 单元测试：构造「验证者中途换二进制」场景，断言 A3 失败 |
-| 4 | `verdict.json` 契约 + 入库 + 脱敏门禁（§7.3） | 端到端：一次完整迭代产出可回放的 verdict；**双清单 0 命中方可 push** |
-| 5 | 仲裁路径 | 构造 verdict=fail + 主张判据过时，断言仲裁复核被触发且不采信主实例套件 |
-| 6 | 异步派发 + 心跳进度（§7.4） | 主实例投递验证 job 后**立即返回**；验证期间主实例 serve 保持可响应、对话不中断 |
-| 7 | worktree 三实例脚本化 | 三 worktree 一键就绪（建 worktree / 独立 config / 拉起 serve / doctor 核对） |
-
-**每步的门禁**：`cargo test` + `scripts/run_tests.py hive` + MCP 冒烟三项全绿方可固化（第 5 条）。
-
-### 验收判据（设计是否成立的唯一硬标准）
-
-> **能连续完成 N 轮「改蜂巢代码 → 异步互验 → 合并」，期间不停主实例 serve、不阻塞与使用者的交流，
-> 且每轮 verdict 均在 GitHub 上留有带三条断言全绿的脱敏留痕。**
-
-若做不到「不停 serve / 不阻塞交流」，则本设计未达成靶心（§1.2），须回溯条件层重新归因。
-
+# 蜂巢双实例互验 · 设计定稿（打破自指悖论的工程形态）
+
+> **定位（2026-09-17 使用者裁定）**
+>
+> 灵枢做的是 **AGI 架构探索**。蜂巢的功能**正是「元认知」与「自我改进」的正式工程基础**，
+> **而非仅仅是智能论理论的落地案例**。
+>
+> 这条定位决定本文件的性质：它不是把一个理论概念工程化，而是给出**自我改进系统得以成立的必要工程条件**——
+> 一个会修改自身代码的系统，若不能同时保住「验证资格」，它的自我改进在结构上就不成立（§1.1）。
+> 智能论提供形式化语言与约束校验（§2 的条款对照），但**工程基础地位在蜂巢这一侧**。
+>
+> 两个概念在本设计中的精确落点：
+>
+> | 概念 | 工程落点 |
+> |---|---|
+> | **元认知** | 系统观测自身状态（`instance` / `role` / `fingerprint` / `progress`）并据此**裁决**——心跳即其接口（§7.2），断言 A1–A3 即其可裁决判据（§7.5） |
+> | **自我改进** | 系统改自身源码而**不丧失验证资格**——判据冻结（§3）与判据面/候选面分离（§7.6）使「改进」与「验证」在结构上同时成立 |
+>
+> **本文件是本机制的唯一状态源**（设计定稿阶段）。角色映射、机械守卫定义、边界声明一律以此为准；
+> 实现落地后，行为面的唯一真源让位于源码 + 守卫测试，本文件转为设计依据。
+>
+> 与既有文档的分工：`docs/hive/蜂巢工作记忆_项目计划.md` 管**工作记忆**（任务上下文的快照/接管）；
+> 本文件管**互验**（改蜂巢这件事本身由谁来验）。两者共用 `hive/wm.py` 的 git 三级闸，但语义不同。
+
+- 创建日期：2026-09-17
+- 状态：**设计定稿，待排期实现**（本轮不写码——使用者裁定）
+- 文档纪律：代码引用一律用「**文件 + 符号名**」定位，**不写行号**（手写行号必腐化，仓内已有活体教训）；
+  理论引用一律标注为**条款要点**，逐字原文以 `docs/theory/智能论3.4.md` 对应章节为唯一真源。
+
+## 表 0-1 · 使用者裁定（2026-09-17）
+
+**第一轮 · 形态裁定**
+
+| 决策项 | 裁定 | 含义 |
+|---|---|---|
+| 落地范围 | **先出设计文档定稿，暂不写码** | 本文件即交付物；实现另案排期 |
+| 隔离形态 | **git worktree 双副本** | 每实例独立 checkout（独立源码 + 独立编译产物 + 独立 jobs） |
+| 裁决权 | **主实例 + 专职验证实例 + 仲裁实例** | 单次迭代内角色固化：验证者不参与修改；仲裁者处理分歧 |
+
+**第二轮 · 四项待裁定项落定**
+
+| # | 议题 | 裁定 | 落点 |
+|---|---|---|---|
+| 1 | 跨迭代身份轮换 | **固化，不轮换** | 验证者确认本轮修改完成后，经 git 把自身同步到已更新版本即可——「互相修改」由此满足（§4.2） |
+| 2 | 第四角色「记录实例」 | **不做** | 记录职责由 git + 灵枢记忆 + 工作纪律 + 任务清单承担（§4.1） |
+| 3 | 互验产物留痕位置 | **入库并同步 GitHub 仓库**（作为标准功能） | 留痕面 = 仓内受版本控制目录，随仓推送、公开可复核（§7.3） |
+| 4 | 验证范围与阻塞性 | **全量套件 + 异步不阻塞** | 用心跳暴露进度；多任务异步处理；不停主实例 serve、不阻塞与使用者交流（§7.4） |
+
+---
+
+## 1 问题：自指悖论及其精确工程形态
+
+### 1.1 循环依赖的准确结构
+
+```
+我们依赖蜂巢去验证蜂巢  →  验证者与被验证者是同一份代码
+        ↓
+改动蜂巢代码 X  →  验证 X 所用的判据也随 X 一起变动
+        ↓
+无法区分两种情形：
+    (a) 改动是对的，验证通过
+    (b) 判据被改宽了，所以什么都通过
+        ↓
+自指确认闭环：结论不可采信
+```
+
+这不是「工具不好用」，是**判定资格问题**——被验证者同时充当判据来源时，判定在结构上失效。
+
+### 1.2 现场取证（本仓实测，非推测）
+
+| 环节 | 实测现象 |
+|---|---|
+| 改 `hive/src/*.rs` 后执行 `cargo build --release` | **报 `os error 5`**——运行中的 `hive.exe` 被 Windows 文件锁占用，无法覆盖 |
+| 规避 | 必须先停 serve，才能重新编译 |
+| 停 serve 的后果 | 蜂巢不可用 → 第 17 条（任务派发统一走蜂巢）无法执行 |
+| 当时的退化做法 | 本机直跑 + 手工起隔离进程对照新旧行为（**手工双实例的雏形，但无身份、无守卫、无留痕**） |
+| 合规状态 | 违反第 17 条，只能如实自述 |
+
+**结论**：该路径**每轮蜂巢迭代必然复现**，不是偶发。它是本设计的靶心。
+
+同时，本仓已出现过**双实例的负面形态**：`hive/hive_mcp/mcp_server.py` 的 `_fresh_s` 注释记录了历史缺陷——
+心跳新鲜窗口三处不一致（MCP 侧 5.0s / `serve_start` 15s / CLI doctor 5000ms）导致存活误判
+→ 重复拉起第二个 serve → **双实例抢队列 / `_serve.json` pid 互覆 / `--stop` 只杀得掉一个**。
+
+**本设计必须正面回答这个问题**：双实例不是「随意多起一个进程」，而是必须带身份、带角色、带守卫的**受治理并存**。
+
+### 1.3 已排除的路径
+
+| 候选 | 裁决 | 理由 |
+|---|---|---|
+| 加深自省层次（多套几层反思） | **REJECT** | 3.12 条款要点：递归深度**默认限制 3 层**，超出该层级的逻辑自指**视为结构性盲区**——靠加深递归解自指，理论层面已被判无效 |
+| 只写文档、不落机制 | **REJECT** | 工程痛点有 1.2 节实锤，不落地则每轮迭代重犯第 17 条 |
+| 用宿主自带 subagent/team 替代蜂巢验证 | **REJECT** | 违反第 17 条明文（「宿主自带 subagent/team 不是等价通道」） |
+| 双实例互验（本设计） | **ACCEPT** | 依据见 §2 |
+
+---
+
+## 2 理论对照（智能论条款 ↔ 工程约束）
+
+> **本节的性质**：智能论在此处提供两样东西——**约束否证**（3.12 直接排除「靠加深递归破自指」这条路径，见 §1.3）
+> 与**结构命名**（角色清单 / 截断点 / 外部锚定的形式化语言）。
+>
+> **但本机制是否成立，由 §1.2 的实测痛点与 §7 的机械断言裁决，不由理论条款裁决**——
+> 这正是「工程基础」与「理论应用」的实质区别：前者的判据在现场，后者的判据在文本。
+>
+> 逐字原文见 `docs/theory/智能论3.4.md` 对应章节。
+
+| 条款 | 条款要点 | 对本设计的约束 |
+|---|---|---|
+| **认知公理（无法自举）** | 系统无法自我确认自己的认知状态；元反思必须**外部锚定** | 验证者必须是**另一个实例**，不能是同实例的自我复核 |
+| **0.0.3 局部不可知** | 全局完备的外部校准者不可实现 | 本设计定位为**降级方案**，不宣称悖论被消除（见 §8） |
+| **3.9 分布式多实例架构** | 实例角色分工：主实例 / 验证实例 / 仲裁实例 / 记录实例 | 直接给出本设计的**角色清单**（§4） |
+| **3.12 递归验证反思机制** | 三级结构（行为验证 / 根源回溯 / 递归截断）；递归深度默认 **3 层**，超出即结构性盲区 | ① 禁止靠加深递归破自指；② 「判据再校准」必须**截断**（§3.5） |
+| **6.5 独立演化实例的合并** | 三阶段：发现与连接 / 摘要交换与初步评估 / 信任重建 | 定义实例间的**协议面**（身份、摘要、信任） |
+| **13.5 外部校准者悖论** | 高认知的外部校准者一旦理解协议即被吸收，独立视角丧失；悖论不可消除，只可降级 | 诚实边界：同机同源**不是**真外部锚定；真外部锚定属另一通道（§8） |
+| **13.5.3 跨条件空间对话（推荐）** | 不同条件空间不触发内化，产出可直接用于协议校准 | worktree 双副本 = **两个不同条件空间**（不同源码 / 不同二进制 / 不同 jobs）——这是选择 worktree 的理论依据之一 |
+
+---
+
+## 3 破解机制：判据冻结
+
+### 3.1 自指故障的精确形态
+
+自指的关键不是「同一个进程」，而是**判据与其被验证对象同源**：
+
+```
+故障形态：判据来源 = 被验证对象来源
+          改 X → 判据也变 → 观测失效
+
+允许形态：判据来源 ≠ 被验证对象来源
+          改 X → 判据不动 → X 的变动可被观测
+```
+
+### 3.2 冻结判据 = 可观测的参照系
+
+**核心判断**：双实例之所以能破自指，**不在于两个实例更聪明，而在于每一轮迭代中至少有一个实例的判据是被冻结的**。
+
+```
+迭代 N：
+  主实例   改动（判据随源码变动 → 无法自证）
+  验证实例 冻结（运行着上一轮固化的二进制与测试套件 → 判据稳定）
+           ↓
+  用「冻结的判据」去测「变动的候选」
+           ↓
+  ✔ 候选的变动才有参照系，结论才可采信
+```
+
+**冻结的物理载体**：验证实例的 serve 进程 + 其 worktree 内的测试套件。本次迭代中**不重启、不替换、不接管**。
+
+### 3.3 判据来源必须与验证者身份绑定（本设计最关键的一条约束）
+
+| 做法 | 后果 |
+|---|---|
+| 验证者用**被验证者提供的**测试套件去测被验证者的二进制 | 被验证者只需把测试改成「通过」即可通过验证——**判据被被验证者控制，退化回自证** |
+| 验证者用**自己 worktree 内的**测试套件去测被验证者的二进制 | 判据来源与验证者身份绑定，被验证者无法触及——**构成本设计要求的分离** |
+
+**一句话**：「用什么测」必须来自验证者，「测什么」来自主实例。二者同源即失效。
+
+### 3.4 横向分摊 ≠ 纵向加深（3.9 与 3.12 的辨析）
+
+本设计最容易被误读的一点，必须写清：
+
+| 维度 | 含义 | 本设计 |
+|---|---|---|
+| **纵向加深**（3.12 限制对象） | 验证的验证的验证……递归下探 | **禁止**。递归深度默认 3 层，超出即结构性盲区 |
+| **横向分摊**（3.9 描述对象） | 同一层级内，多个实例并行分担不同职责 | **采用**。主实例 / 验证实例 / 仲裁实例是**同层并行**，不是递归嵌套 |
+
+**结论**：多实例破自指**不违反** 3.12 的截断约束——它走的不是「更深」，而是「更宽」。
+把「验证者不参与修改」误读为「再加一层验证者去验验证者」，才是踩线。
+
+### 3.5 冻结的代价与再校准（截断点在此）
+
+| 项 | 说明 |
+|---|---|
+| 代价 | 判据永久冻结 → 会随主线演进**逐渐过时**（旧判据测新能力，可能误判为回归） |
+| 解 | 验证实例**定期再校准**：在明确的、被记录的时间点上，把自身二进制更新到已合并的主线版本 |
+| 截断（3.12） | 「谁校准校准者」**不得继续递归追问**——再校准本身构成一次**受审查的迭代**，其批准点即截断点，到此为止 |
+
+---
+
+## 4 角色映射（3.9 四角色 → 本设计取三）
+
+### 4.1 职责边界
+
+| 角色 | 3.9 条款要点 | 本设计落码 | 能做 / 不能做 |
+|---|---|---|---|
+| **主实例** | 执行、与外部交互、生成输出 | 承担迭代改动、编译候选、发起互验请求、执行 merge | **能**改代码 / 编译 / 提交候选 / 合并；**不能**裁自己的验证结论 |
+| **专职验证实例** | 验证主实例的判定、检查偏差 | 带冻结判据（自身 worktree 的二进制 + 测试套件）验证候选，产出 `verdict.json` | **能**验证 / 出裁决；**不能**参与本轮修改（否则判据污染） |
+| **仲裁实例** | 处理实例间分歧、执行恢复 | 当 verdict=fail 而主实例主张「判据过时」时独立复核，产出 `arbitration.json` | **能**裁决分歧 / 触发再校准；**不能**代替验证者出具常规验证结论 |
+| （记录实例） | 记录所有实例状态变化 | **不单设**——记录职责由 **git 历史 + 灵枢记忆 + 工作纪律 + 任务清单**共同承担（见 §9） | —— |
+
+**取三不取四的理由（已裁定，2026-09-17）**：记录职责在本仓已有四个成熟载体——git 提交历史（不可篡改的时序）、
+灵枢记忆（决策与教训的语义留痕）、工作纪律（判定资格与动作规范）、任务清单（进程态与派发留痕）——
+再设一个常驻记录实例属重复建设。**裁定：不做记录实例。**
+
+### 4.2 跨迭代身份轮换（**已裁定：固化，不轮换**）
+
+使用者原始表述含「**互相修改**」，易被读成「主 / 验身份互换」。**已裁定为固化**，
+其理由是本设计此前未写明的一条机制：
+
+> **验证者在确认本轮修改完成后，可通过 git 把自身同步到已更新版本**——
+> 「互相修改」的实质由此满足，**不需要身份轮换**。
+
+即：验证实例**始终**是验证者（身份永不互换），但它会在**迭代边界**上推进自己的判据基线
+（`git pull` / `merge` 已合并的主线 → 重编译 → 判据前进到新版本）。两个诉求因此同时成立：
+
+| 诉求 | 满足方式 |
+|---|---|
+| 角色固化（参照系稳定） | 单次迭代内验证者不参与修改；身份**永不**互换 |
+| 「互相修改」（判据不僵化） | 验证者经 git 在**迭代边界**把自身推进到已更新版本（即 §3.5 的再校准） |
+
+**关键时序约束**：再校准只允许发生在**本轮验证结论已落痕之后**（即 §7.4 的第 7 / 8 步之间），
+**不得**发生在第 4–5 步之间——否则验证者中途更换二进制，断言 A3（§7.5）立即失败。
+这正是「**迭代内冻结、迭代间推进**」的精确边界。
+
+---
+
+## 5 隔离形态：git worktree 双副本
+
+### 5.1 为什么 worktree 在本场景是**必需的**（不只是「外部性更强」）
+
+这是把使用者裁定从「更好」升级为「不可替代」的论证：
+
+| 形态 | 编译产物路径 | 后果 |
+|---|---|---|
+| 同机双目录（三 env 覆盖） | 两实例若指向**同一** `target/release/hive.exe` | 主实例编译时被验证实例的运行中二进制**锁死** → `os error 5` **依旧复现**，自指痛点未解 |
+| **worktree 双副本** | 各 worktree 各有独立 `target/` → **二进制路径天然不同** | 主实例可自由重编译自己的候选，**不与验证实例的运行中二进制冲突** |
+
+**同时**，worktree 让 §3.2 的「冻结」有了物理落点：验证实例的 worktree 在迭代期间**其判据面不被触碰**，
+二进制与测试套件因此真正冻结；§3.3 的「判据来源绑定验证者身份」在 worktree 形态下**结构性成立**
+（验证者的测试套件物理上就在它自己的目录里，主实例无权改）。
+
+> **前提限定**：这以 §7.6 的「判据面 / 候选面分离」为条件——候选源码进入验证实例 worktree 时，
+> 判据面必须**以覆盖方式保持冻结**，否则冻结会被候选自带的测试悄无声息地替换掉（§7.6 详述）。
+
+> 附带收益：worktree 与 `wm.py` 的 git 三级闸**天然同构**——两者都以 git 分支为候选版本的寻址面。
+
+### 5.2 布局（符号名，路径由实例自行解析）
+
+```
+仓库（共享 .git 对象库）
+├── <主实例 worktree>      HIVE_INSTANCE=main      HIVE_ROLE=primary
+│   ├── hive/target/release/   ← 候选二进制（可自由重编译）
+│   └── hive/jobs/             ← 主实例任务队列
+├── <验证实例 worktree>    HIVE_INSTANCE=verifier  HIVE_ROLE=verifier
+│   ├── hive/target/release/   ← 冻结判据载体（迭代期间不动）
+│   └── hive/jobs/             ← 验证实例任务队列（独立）
+└── <仲裁实例 worktree>    HIVE_INSTANCE=arbiter   HIVE_ROLE=arbiter
+    └── hive/jobs/             ← 仲裁实例任务队列（独立）
+```
+
+**关键**：三实例的 `HIVE_JOBS_DIR` 各不相同 → 各自满足「同一 jobs 目录至多一个 serve」的既有守卫，
+**不绕过守卫，而是合法并存**。
+
+### 5.3 与 `wm.py` 三级闸的对接
+
+| 闸 | 既有语义 | 本设计用法 |
+|---|---|---|
+| `snapshot`（凭证闸） | 要求 `result.ok == true` 才允许快照产物 | 主实例候选产物的留痕走同一凭证口径 |
+| `merge`（主代理显式） | 只有主代理可发起合并；冲突诚实报错不自动解决 | **合并唯一入口仍是主实例**——验证结论不自动触发合并 |
+| `revert`（免费） | 未合并前放弃零成本 | 验证失败时主实例 revert 候选，无副作用 |
+
+**边界**：`wm.py` 服务的是**任务产物**（`jobs/<id>/` 下的 spec / result / log / progress），
+互验产物（§7.3 的 `verdict.json`）**不在其快照白名单内**——它走**独立留痕面**：入库并同步 GitHub（§7.3）。
+
+---
+
+## 6 既有基础设施盘点（本设计不是从零建）
+
+| 件 | 现状（已落地） | 本设计的缺口 |
+|---|---|---|
+| `hive/serve_start.py` | `HIVE_CONFIG` / `HIVE_EXE` / `HIVE_JOBS_DIR` 三 env 覆盖；模块注释明写「使同一套拉起逻辑同时服务『真实部署』与『隔离测试』两种形态」；`FRESH_S` 心跳新鲜窗口，与 `main.rs` 的 `FRESH_MS` 同口径（跨语言靠注释约定 + 守卫测试对齐） | 无实例身份 / 无角色 / 心跳不含指纹 |
+| `hive/hive_mcp/mcp_server.py` | 与 `serve_start` 同口径解析三 env；`_ensure_serve` **复用** `serve_start.start()`（杜绝两条拉起路径 env 不一致）；`_fresh_s()` 以 `serve_start.FRESH_S` 为**单一常量源** | 无身份透传 |
+| `hive/src/main.rs` | 单实例守卫（心跳新鲜度 + pid 双判据）、`--force` 豁免、`recover_orphans` 崩溃恢复；`FRESH_MS` 与 MCP 侧同口径；**已确立「serve 自报心跳承载启动期固化事实」的模式**（`exec_py` / `exec_mode` + `exec_source` 来源诚实标注） | 心跳无 `instance` / `role` / `fingerprint` 字段 |
+| `hive/src/scheduler.rs` | `ServeCfg` 携带 `exec_py` / `exec_mode`，主循环每次写心跳一并自报；`exec_mode_of` 由执行器文件名推得 | 同一模式待扩至身份与指纹（§7.2） |
+| `hive/wm.py` | git 三级闸（snapshot / merge / revert）；`task/<job_id>` 分支；`HIVE_WM_DIR` 可覆盖 | 无「候选版本 = 带指纹的待验对象」这一语义 |
+| `hive/README.md` | 已明确「同一 jobs 目录至多一个 serve」「**不同 jobs 目录 = 不同 serve 实例，互不干扰**」「三 env 可覆盖」 | 文档未定义「多实例的**治理**形态」（身份 / 角色 / 互验协议） |
+
+**结论**：多实例的**物理隔离机制已具备**（本仓已有 `HIVE_JOBS_DIR` + `HIVE_CONFIG` 做隔离测试的实践），
+且「serve 自报心跳承载启动期固化事实」的模式**已被上一轮验证过**（`exec_py` / `exec_mode`）。
+缺口因此收窄为三处**同模式的扩展**：身份化（§7.1）+ 分离守卫（§7.4）+ 判据冻结的可断言化（§7.5）。
+
+---
+
+## 7 待落地的机械守卫（定义，不含实现）
+
+### 7.1 实例身份（env 扩展）
+
+| env | 取值 | 语义 |
+|---|---|---|
+| `HIVE_INSTANCE` | `main` / `verifier` / `arbiter`（缺省 = `main`） | 实例身份，落心跳 |
+| `HIVE_ROLE` | `primary` / `verifier` / `arbiter` | 角色，决定该实例**被允许做什么**（如 verifier 拒绝发起 merge） |
+
+**兼容原则**：两 env **缺省即旧行为**（单实例部署零变更），不得成为新必填项。
+
+### 7.2 心跳扩展（`_serve.json` 增字段）
+
+| 字段 | 内容 | 用途 |
+|---|---|---|
+| `instance` | 实例身份 | 断言 A1 的输入 |
+| `role` | 角色 | 角色守卫的输入 |
+| `fingerprint` | **自身二进制的指纹**（内容 hash） | 断言 A2 / A3 的输入 |
+| `source_commit` | 构建时的 git commit | 溯源「这个二进制是什么版本」 |
+| `iter_id` | 当前正在处理的迭代 id（空闲时为 Null） | 进度可见性——§7.4 异步不阻塞的**观测面** |
+| `progress` | 验证进度（阶段 + 计数，如 `cargo_test 1/3`） | 心跳式进度暴露，**替代阻塞轮询**（第 4 项裁定的落点） |
+
+**心跳承载进度是第 4 项裁定的关键**：全量套件耗时长，若靠阻塞等待则会冻结主实例；
+把进度写进心跳后，主实例（与使用者）只需**拉取**心跳即可获知进展，等待成本被消除。
+
+**为何必须由 serve 自报心跳、不得由消费者读 env 判断**（本仓实测教训，直接继承）：
+
+`HIVE_INSTANCE` / `HIVE_ROLE` 与既有 `HIVE_EXEC_PY` **同性质**——serve 启动时由 env 固化，
+**子进程无法反查**。`main.rs` 的 `cmd_doctor` 与 `mcp_server.py` 的 `_heartbeat` 均已就此写明：
+「跨进程 env 不可反查，故心跳是唯一权威来源；用本进程 env 判资格必得错位结论」
+（真实案例：CLI 裸起 serve 的执行器是 exec.py，而 doctor 进程 env 里却指向 exec_cmd.py，
+据此判资格会把 llm_only 看成兼跑命令）。
+
+**因此**：实例身份与指纹一律**由 serve 写入自己的心跳**，消费者只读心跳、不读 env。
+
+**兼容原则**：旧心跳无这些字段时，消费者按「未知」处理，**不伪造默认值**，且**如实标注来源**
+——沿用既有的 `exec_source` 诚实口径（心跳缺失即标 `no_heartbeat_or_legacy`，字段缺失透传 Null）。
+
+### 7.3 验证产物契约（`verdict.json`）
+
+```json
+{
+  "iter_id": "…",
+  "verifier_instance": "verifier",
+  "verifier_fingerprint": "<验证者二进制指纹>",
+  "subject_instance": "main",
+  "subject_fingerprint": "<候选二进制指纹>",
+  "suite_origin": "<测试套件来源——必须是验证者自己的 worktree>",
+  "frozen_at": "<本轮冻结时刻>",
+  "verdict": "pass | fail",
+  "passed": 0,
+  "failed": 0,
+  "details": []
+}
+```
+
+**留痕位置（已裁定）**：**入库并同步 GitHub 仓库**——互验产物是本机制的**标准功能产物**，
+随仓版本控制、随 `push` 上 GitHub，公开可复核。
+
+| 项 | 设计 |
+|---|---|
+| 目录 | 仓内**受版本控制**目录（如 `hive/interop/<iter_id>/`）。**不能用** `hive/jobs/`——该目录已被 `.gitignore` 排除且含运行态 |
+| 文件 | `verdict.json`（常规验证）／ `arbitration.json`（分歧仲裁） |
+| 发布 | 验证实例产出后提交到**与候选同一迭代分支**（`task/<iter_id>`）并 `push origin`——verdict 与候选同分支，随合并一并进主线，可溯源对应关系；**推送验证结论不属「参与修改」**，与它的角色约束不冲突 |
+| 复核 | GitHub 侧 commit SHA + 时间戳构成**平台侧记录**，比本地私有运行态更难事后改写 |
+| 噪声治理 | 按 `<iter_id>` 分目录；实现期可加「只保留最近 N 轮 + 归档到 `hive/interop/archive/`」策略（实现细节，非设计约束） |
+
+**脱敏契约（硬门禁，第 9 / 14 条）**：入库即**公开**，产物**只允许**含结构化事实——
+指纹（hash）、断言结果（A1 / A2 / A3）、计数（passed / failed）、commit SHA、迭代 id、时间戳、符号化路径。
+
+**禁止**写入：`spec` 正文 / prompt / `result.content` / API 相关信息（key、base、model）/ 本机绝对路径。
+**每轮 `push` 前必须过「内容政策 + 隐私」双清单、0 命中方可推送**（第 14 条）——
+这是把「产物入库」从便利升级为标准功能时必须付的代价。
+
+### 7.4 迭代时序（异步、不阻塞）
+
+**设计原则（已裁定）**：验证跑**全量套件**（质量不降级），但**不得阻塞主实例、不得阻塞与使用者的交流**。
+手段是**异步派发 + 心跳暴露进度**——主实例只做「投递」，不做「阻塞等待」。
+
+```
+0. 准备     三实例各自 worktree 就绪；各自 serve 存活；各自心跳落自己的 jobs/
+            验证实例记录本轮冻结指纹 F_ver（该值与心跳 fingerprint 一致）
+
+1. 改动     主实例在自身 worktree 改代码 → cargo build --release
+            （自己的 target/，不被他人锁定 —— §5.1 的解）
+
+2. 提交候选  候选二进制指纹 F_c + commit SHA 记入本轮 iter 凭证
+            源码提交到 task/<iter_id> 分支（复用 wm.py 同源机制）
+
+3. 派发验证  ★ 非阻塞 ★ 主实例把验证任务作为普通蜂巢 job 投递到**验证实例的 jobs 目录**
+            （文件协议即接口：写 spec.json 即完成投递，与 hive_spawn 同语义）
+            投递后**立即返回**——主实例继续处理其他任务、继续与使用者交流
+            进度不靠阻塞轮询，靠**心跳**暴露（验证实例心跳带当前 iter_id 与进度）
+
+4. 验证（异步）先以**判据面覆盖候选面**（§7.6）保判据冻结，再对候选跑**全量套件**：
+            cargo test + scripts/run_tests.py hive + MCP 冒烟（三项全量，不按改动面裁剪）
+            产出 verdict.json → 入库 → push origin（§7.3）
+
+5. 断言     A1 verifier_instance ≠ subject_instance
+            A2 verifier_fingerprint ≠ subject_fingerprint
+            A3 verifier_fingerprint == 第 0 步的 F_ver（判据确未被本轮改动）
+            任一不成立 → 验证结论作废（不得进入第 7 步）
+
+6. 分歧     verdict=fail 且主实例主张「判据过时」→ 交仲裁实例独立复核 → arbitration.json
+            （仲裁者同样使用自己的冻结判据，不采信主实例提供的套件；同样异步派发）
+
+7. 合并     verdict=pass → **主实例**经 wm.py merge 合入主线；冲突诚实报错，不自动解决
+
+8. 再校准   验证实例更新自身二进制到已合并版本，记录时点（§3.5 的截断点；§4.2 的时序约束）
+```
+
+**「全量套件」与「不阻塞」如何共存**（这是第 4 项裁定的关键）：
+
+| 关注点 | 做法 |
+|---|---|
+| 质量 | 全量套件，不因「要快」而裁剪验证面 |
+| 不阻塞 | 验证是**另一个实例的 job**，在主实例的进程外执行——主实例的 serve 不参与、不等待 |
+| 可观测 | 心跳携带进度；主实例（或使用者）随时 `poll` 查询，属**拉取**而非阻塞推送 |
+| 交流不中断 | 主实例 serve 持续存活 → MCP 工具面持续可用 → 与使用者的对话不被验证任务挂起 |
+| 多任务并行 | 验证 job 与主实例的其他 job 在各自 jobs 目录并发，互不抢占（jobs 目录隔离） |
+
+### 7.5 断言 A3 是全设计的承重墙
+
+A1（身份不同）与 A2（指纹不同）都**弱**——只要起了两个进程就自动成立，不构成任何保证。
+
+**A3 才把「判据冻结」从口头约定变成可断言事实**：验证者声明的指纹必须等于本轮开始时记录的冻结值。
+若验证者在验证过程中把自己更新到候选版本（判据随之变动），A3 立即失败。
+
+> 类比：A1 / A2 证明「是两个人」，A3 证明「其中一个在看同一把尺子」。
+
+### 7.6 判据面 vs 候选面（冻结如何真正落地）
+
+「用验证实例自己的测试套件测候选」在实现上有一个**必须解决的细节**：
+
+> 候选源码一旦进入验证实例的 worktree，**测试套件会被一并替换**——判据随即被污染，A3 形同虚设。
+
+因此必须把两面物理分开：
+
+| 面 | 内容 | 谁能改 | 变化规则 |
+|---|---|---|---|
+| **判据面** | 测试套件（`hive/tests/`、`scripts/run_tests.py hive`、`md_cg/test_*.py`）与验收命令 | **只有验证实例自己** | 仅在**迭代边界**（§4.2）随再校准推进 |
+| **候选面** | 被测源码（`hive/src/*.rs`、执行器脚本等） | 主实例 | 每轮迭代自由变化 |
+
+**执行方式**：候选 checkout / 编译后，以**判据面覆盖候选面**（同名测试文件以判据面为准）再运行。
+断言 A3 因此**细化为**：*判据面文件集合的 hash == 本轮冻结值*——这比笼统的「二进制指纹」更贴近真实判据。
+
+**主实例需要新增测试时**（扩展判据的合法诉求）：不得让测试改动在本轮直接生效——
+它提交的测试改动**本轮不参与判据**，须经仲裁 / 再校准在**下一轮**纳入判据树。
+这样「**判据只增不减、只在边界前进**」得以保持，而新增覆盖能力不被阻塞。
+
+**若判据面与候选面接口不兼容**（候选改了被测接口，旧测试编译不过）：
+诚实报「判据与候选接口不兼容」→ 交仲裁 → **不得**自动改用候选自带测试（那等于让被验者提供判据）。
+
+---
+
+## 8 设计边界（诚实，不夸大）
+
+| 边界 | 说明 |
+|---|---|
+| **不是真外部锚定** | 同机同源两实例共享代码谱系与认知图真源，属 13.5.1 意义上的**降级方案**——悖论不可消除。真外部锚定需 13.5.4 多源异质聚合（外部评审等），属另一通道 |
+| **worktree 共享 `.git` 对象库** | git worktree 的「独立」是**工作区级**，不是仓库级——提交历史与对象库仍共享。恶意规避（绕过 worktree 直接改共享 ref）不在本设计防线内 |
+| **判据冻结会过时** | 见 §3.5。旧判据误判新能力为回归时，须走仲裁 → 再校准流程，**不得由主实例自行宣布判据失效** |
+| **不提升到信号级隔离** | 沿用既有诚实边界：kill 与超时检测粒度 = 1s 轮询，非信号级即时 |
+| **不改变单实例守卫** | 本设计**不修改**「同一 jobs 目录至多一个 serve」这条约束，而是在合法的多 jobs 目录前提下定义身份与角色——**共存而不绕过** |
+| **本设计不消除悖论** | 目标是把不可消除的自指从「运行期静默错判」降级为「结构上可见的单例冻结判据」 |
+| **GitHub 留痕 ≠ 外部锚定** | 产物入库并推送 GitHub 提升了**可复核性**（平台侧时间戳 + 公开可查、外部任何人可审计），但仍是**同一账号、同一代码谱系**。诚实定位：**可复核性↑，同源性不变**——不构成 13.5.4 意义上的多源异质外部锚定 |
+| **异步不等于无人负责** | 「不阻塞」只免除**等待**，不免除**裁决**：verdict 未出之前候选**不得**合入主线（第 7 步是唯一入口），且断言未过即作废 |
+| **「工程基础」是功能定位，不是完备性声明** | 本设计解决的是「**自我改进时的验证资格**」这一个必要条件——它使自我改进**可能**成立，不宣称元认知已完成。目标生成、长期记忆演化、跨域迁移等属其它通道，不在本设计射程内 |
+
+---
+
+## 9 与既有件的对接边界
+
+| 既有件 | 对接方式 | 不做什么 |
+|---|---|---|
+| `hive/serve_start.py` | 新增两 env 读取；心跳写入扩展字段 | 不改三 env 覆盖语义；不改 `start` / `stop` / `status` 的既有行为 |
+| `hive/src/main.rs` + `hive/src/scheduler.rs` | 心跳增字段；角色守卫（如 verifier 拒 merge）；沿用 `exec_source` 的来源诚实标注 | 不改 `FRESH_MS` 判活口径；不改崩溃恢复语义；不改 `exec_mode_of` 既有启发式 |
+| `hive/wm.py` | 复用其分支寻址机制（分支命名沿用 `task/<job_id>` 惯例，迭代 id 承载 `job_id` 语义）作为候选版本寻址面 | 不把 `verdict.json` 塞进任务快照白名单（语义不同） |
+| `hive/hive_mcp/mcp_server.py` | 心跳透传 `instance` / `fingerprint` 供 doctor 展示 | 不改四工具 schema 与并发语义 |
+| 记录实例职责 | 由 **git 历史 + 灵枢记忆 + 工作纪律 + 任务清单**共同承载 | 不新设常驻记录进程（§4.1 已裁定） |
+| GitHub 仓库 | 互验产物（`verdict.json` / `arbitration.json`）入库并随 `push` 同步，成为**标准功能产物** | 产物**不得**含 spec 正文 / prompt / result 正文 / API 信息 / 本机绝对路径（§7.3 脱敏契约） |
+| 第 17 条纪律 | 互验的每一步（候选编译 / 测试执行）**本身也应经蜂巢派发并留痕**；验证任务**异步派发、不阻塞** | 不得以「互验是特殊流程」为由绕过派发；也不得以「验证要等待」为由阻塞主实例与使用者交流 |
+
+---
+
+## 10 落地排期
+
+### 裁定全部落定（2026-09-17 第二轮）
+
+| # | 议题 | 裁定 | 落点 |
+|---|---|---|---|
+| 1 | 跨迭代身份轮换 | **固化，不轮换**；验证者经 git 在迭代边界推进基线 | §4.2 |
+| 2 | 第四角色「记录实例」 | **不做**；由 git + 灵枢记忆 + 工作纪律 + 任务清单承担 | §4.1 / §9 |
+| 3 | 互验产物留痕 | **入库并同步 GitHub**（标准功能）+ 脱敏契约硬门禁 | §7.3 |
+| 4 | 验证范围与阻塞性 | **全量套件 + 异步不阻塞 + 心跳暴露进度** | §7.4 |
+
+**本设计已无未决项**，可直接进入实现排期。
+
+### 建议实现顺序（每步独立可验证）
+
+| 步 | 内容 | 验证方式 |
+|---|---|---|
+| 1 | 身份与心跳字段（§7.1 / §7.2） | 起两个不同 `HIVE_JOBS_DIR` + 不同 `HIVE_INSTANCE` 的 serve，doctor 各自报出正确身份与指纹；旧部署零变更 |
+| 2 | 指纹计算与断言 A1 / A2 | 单元测试：构造身份相同 / 指纹相同两类输入，断言拒绝 |
+| 3 | 断言 A3（冻结值核对） | 单元测试：构造「验证者中途换二进制」场景，断言 A3 失败 |
+| 4 | `verdict.json` 契约 + 入库 + 脱敏门禁（§7.3） | 端到端：一次完整迭代产出可回放的 verdict；**双清单 0 命中方可 push** |
+| 5 | 仲裁路径 | 构造 verdict=fail + 主张判据过时，断言仲裁复核被触发且不采信主实例套件 |
+| 6 | 异步派发 + 心跳进度（§7.4） | 主实例投递验证 job 后**立即返回**；验证期间主实例 serve 保持可响应、对话不中断 |
+| 7 | worktree 三实例脚本化 | 三 worktree 一键就绪（建 worktree / 独立 config / 拉起 serve / doctor 核对） |
+
+**每步的门禁**：`cargo test` + `scripts/run_tests.py hive` + MCP 冒烟三项全绿方可固化（第 5 条）。
+
+### 验收判据（设计是否成立的唯一硬标准）
+
+> **能连续完成 N 轮「改蜂巢代码 → 异步互验 → 合并」，期间不停主实例 serve、不阻塞与使用者的交流，
+> 且每轮 verdict 均在 GitHub 上留有带三条断言全绿的脱敏留痕。**
+
+若做不到「不停 serve / 不阻塞交流」，则本设计未达成靶心（§1.2），须回溯条件层重新归因。
+