@furongjun1999/dsh-memory 0.4.11 → 0.5.0

package/docs/{mdcg → hive}//344/273/244/347/211/214/344/270/216/350/247/222/350/211/262/346/235/203/350/201/214/345/210/206/347/246/273_v0.1.md

@@ -1,160 +1,165 @@
-# 令牌与角色权职分离 v0.1
-
-> 把管理权限从「环境变量开关」改为「令牌 + 角色职责矩阵 + 派生链」。
-> 实现：`md_cg/tokens.py`、`md_cg/security.py`、`md_cg/mcp_server.py`、`md_cg/mdcos.py`
-> 测试：`python -m md_cg.test_p21_tokens`（31 项，含 MCP 进程层）
-
-## 1. 为什么改
-
-改造前，管理权限来自环境变量 `MDCG_CAN_ADMIN=1`：
-
-```
-MDCG_CAN_ADMIN=1  →  can_admin=True  →  可 review_decide / forget / protect
-```
-
-问题有三：
-
-1. **无凭据**：任何能设置该进程环境的调用方都能自授权限，没有可追溯的授权主体；
-2. **不可区分**：写权限是一根整体开关，无法表达「验证单元不得改事实层」；
-3. **不可委派**：子代理只能拿同一把钥匙，权职分离无从谈起。
-
-## 2. 三层模型
-
-| 层 | 机制 | 落点 |
-|---|---|---|
-| ① 令牌 | 身份与权限的唯一凭据；明文只在签发时返回一次，落盘只存 `sha256` | `~/.mdcg/_tokens.json`（0600） |
-| ② 角色 | 职责矩阵：可写层 / 可执行 op / 密级上限 / 可否管理 | `tokens.ROLE_SPECS` |
-| ③ 派生 | 设计者令牌派生子令牌，**权限只能收窄**，子令牌默认不可再派生 | `tokens.derive()` |
-
-令牌格式 `mdcg1.<role>.<token_id>.<secret>`：`role` 便于人读，但**权威来源是令牌记录**——
-校验时比对记录中的 role 与 `sha256(secret)`，不一致即拒绝。
-
-### fail-closed
-
-| 情形 | 行为 |
-|---|---|
-| `MDCG_TOKEN` 合法 | 按令牌角色注入身份 |
-| `MDCG_TOKEN` 非法/过期/吊销 | **拒绝启动**，退出码 `3`，不降级为可用 |
-| 无 `MDCG_TOKEN` 且无 `MDCG_LEGACY_ENV_AUTH` | 降级为 `guest`：只读、`internal` 密级、不可管理 |
-| `MDCG_LEGACY_ENV_AUTH=1` | 兼容旧部署的 env 直连（`auth_mode=legacy_env`，不推荐） |
-
-## 3. 角色职责矩阵
-
-五大单元（`record / reflect / verify / output / sustain`）的 `unit / effect / duty`
-与 `identity.POSITIONS`（智能论 v3.4 §十三）**同源**，`test_p21_tokens` 有断言防漂移。
-
-| 角色 | 单元 | 效 | 可写层 | 可执行 op | 密级上限 | 管理 | 可派生 |
-|---|---|---|---|---|---|---|---|
-| `designer` | 设计者权限载体 | 主 | `*` | `*` | secret | ✅ | ✅ |
-| `record` | 记录单元 | 全 | knowledge, contextual, structural, unresolved, rejected, goals | info, route, read, write, goal, recent | internal | ✗ | ✗ |
-| `reflect` | 反思单元 | 新 | contextual | info, route, read, write, recent, metacognition | internal | ✗ | ✗ |
-| `verify` | 验证单元 | 稳 | rejected, contextual | info, route, read, write, verify | internal | ✗ | ✗ |
-| `output` | 输出单元 | 通 | —（只读） | info, route, read, recent, whitebox | internal | ✗ | ✗ |
-| `sustain` | 维生系统 | 存 | self | info, read, write, sustain, scrub, evolution, self_state, metacognition | internal | ✗ | ✗ |
-| `guest` | 未认证访客 | — | —（只读） | info, route, read, recent, whitebox | internal | ✗ | ✗ |
-
-别名：`recorder→record`、`reflection→reflect`、`verifier→verify`、`viewer→output`、
-`admin/root→designer`、`anon/anonymous→guest`。
-
-## 4. 核心私有内容保护
-
-「其他单元不应越权修改核心私有内容」由**两道闸门**共同保证：
-
-1. **密级闸门**：`private` / `secret` 内容只有 `clearance` 达标的身份可写。
-   除 `designer` 外的角色密级上限一律 `internal`，因此**天然无法写入核心私有内容**。
-2. **层闸门**：`anchor`（身份锚点）与 `self`（灵枢自身）保护层，
-   只对 `layers_allow` 含该层或 `"*"` 的角色开放。
-
-写入路径统一走 `Principal.require_layer_write(layer, sensitivity)`，
-在 `MdCGSecure.add / add_rejected / add_unresolved / propose / add_goal / set_goal_status`
-六处生效。越权即 `AccessDenied`，不做静默降级。
-
-另有一道 **op 闸门**：`_cg_call` 入口调用 `Principal.require_op(op)`，
-使「只读角色执行 write / review」在进入业务逻辑前就被拦下。
-
-## 5. 单智能体的子代理权职分离
-
-即使是单智能体环境，也用**子代理 + 子令牌**把职责分开，从而校验偏差与盲区：
-
-```python
-from md_cg import tokens
-
-# 外部用户为唯一主智能体签发「设计者权限载体」
-d = tokens.issue("designer", actor="codebuddy", label="设计者载体")
-
-# 主智能体为各单元派生受限子令牌（权限只能收窄）
-v = tokens.derive(d["token"], "verify",  actor="codebuddy-verify",  ttl=3600)
-r = tokens.derive(d["token"], "reflect", actor="codebuddy-reflect", ttl=3600)
-o = tokens.derive(d["token"], "output",  actor="codebuddy-output",  ttl=3600)
-```
-
-由此得到的性质：
-
-- **验证单元写不了被验证内容**：`layers_allow=['rejected','contextual']`，
-  写 `knowledge` 层直接 `AccessDenied`，因此「自己写、自己验」在结构上不成立；
-- **记录单元不能自我验证**：无 `verify` op、无 `rejected` 以外的裁决权；
-- **输出单元不产生副作用**：`can_write=False`，连审计节点都写不了；
-- **维生系统改不了事实**：只能写 `self` 层运维域；
-- **委派链封口**：子令牌 `delegable=False`，不能继续往下派生；
-  父令牌吊销时**级联吊销**整条链。
-
-这样，主智能体无法用「同一个身份」既产出又验收，偏差与盲区有独立单元交叉检查。
-
-## 6. 操作手册
-
-```bash
-# ① 签发设计者载体（明文令牌只返回这一次）
-python -m md_cg.tokens issue --role designer --actor codebuddy --label "外部用户授权载体"
-
-# ② 派生各单元子令牌
-python -m md_cg.tokens derive --token <设计者令牌> --role verify --actor codebuddy-verify --ttl 3600
-
-# ③ 校验身份（打印 role / 可写层 / op 作用域）
-python -m md_cg.tokens verify --token <令牌>
-
-# ④ 清单与吊销
-python -m md_cg.tokens list
-python -m md_cg.tokens revoke --token-id tk_xxxxxxxxxxxx
-
-# ⑤ 打印角色职责矩阵
-python -m md_cg.tokens roles
-```
-
-MCP 接入（`~/.codebuddy/mcp.json`）：
-
-```json
-{
-  "mcpServers": {
-    "mdcg": {
-      "command": "python",
-      "args": ["-m", "md_cg.mcp_server"],
-      "env": {
-        "MDCG_ROOT": "data/mdcg",
-        "MDCG_TOKEN": "mdcg1.designer.tk_xxxxxxxxxxxx.xxxxxxxx"
-      }
-    }
-  }
-}
-```
-
-令牌文件路径可用 `MDCG_TOKEN_FILE` 覆盖（默认 `~/.mdcg/_tokens.json`）。
-
-## 7. 迁移与兼容
-
-- 既有直接构造的 `Principal(...)`（测试、脚本）行为不变：
-  `role="system"`、`layers_allow=None`（不限制），仅新增字段。
-- 旧部署可临时设 `MDCG_LEGACY_ENV_AUTH=1` 继续用 env 身份，
-  `whoami.principal.auth_mode` 会标注 `legacy_env` 以便识别与清理。
-- `test_p2_mcp.py` 已自动带上该开关以保持回归。
-
-## 8. 诚实边界
-
-- **令牌文件即信任根**：`~/.mdcg/_tokens.json` 被写入者可自行追加令牌。
-  本方案把「可自授权限」从进程环境收敛到文件系统权限（0600），
-  未引入外部 KMS/签名链——那是下一步。
-- **明文令牌仍出现在客户端配置里**：MCP 客户端需要它。若需更高强度，
-  应改为「客户端持私钥 + 服务端校验签名」。
-- **角色矩阵是策略不是证明**：`layers_allow` 收窄的是**写层**，
-  读权限仍由 `clearance` 单维控制；跨租户隔离依赖 `MDCG_ROOT` 与 DEK。
-- **`op` 闸门是入口检查**：未覆盖 MCP 暴露的全部 33 个细粒度工具，
-  它们走 `cg`/`stg` 基元时同样受检，但直接调用 `MdCGSecure` 的脚本需自行遵守。
+# 令牌与角色权职分离 v0.1
+
+> 把管理权限从「环境变量开关」改为「令牌 + 角色职责矩阵 + 派生链」。
+> 实现：`md_cg/tokens.py`、`md_cg/security.py`、`md_cg/mcp_server.py`、`md_cg/mdcos.py`
+> 测试：`python -m md_cg.test_p21_tokens`（38 项，含 MCP 进程层）
+>
+> **v0.2 增补（2026-09-22）**：新增 `orchestr` 角色（3.9 仲裁实例投影，蜂巢编排者）；
+> `review_decide` 闸门从 `require_admin` 拆为 `require_op("review")`+层写复合
+> ——裁决权与存在级管理权正式分离。详见《令牌语义修正·仲裁位 v0.1》。
+
+## 1. 为什么改
+
+改造前，管理权限来自环境变量 `MDCG_CAN_ADMIN=1`：
+
+```
+MDCG_CAN_ADMIN=1  →  can_admin=True  →  可 review_decide / forget / protect
+```
+
+问题有三：
+
+1. **无凭据**：任何能设置该进程环境的调用方都能自授权限，没有可追溯的授权主体；
+2. **不可区分**：写权限是一根整体开关，无法表达「验证单元不得改事实层」；
+3. **不可委派**：子代理只能拿同一把钥匙，权职分离无从谈起。
+
+## 2. 三层模型
+
+| 层 | 机制 | 落点 |
+|---|---|---|
+| ① 令牌 | 身份与权限的唯一凭据；明文只在签发时返回一次，落盘只存 `sha256` | `~/.mdcg/_tokens.json`（0600） |
+| ② 角色 | 职责矩阵：可写层 / 可执行 op / 密级上限 / 可否管理 | `tokens.ROLE_SPECS` |
+| ③ 派生 | 设计者令牌派生子令牌，**权限只能收窄**，子令牌默认不可再派生 | `tokens.derive()` |
+
+令牌格式 `mdcg1.<role>.<token_id>.<secret>`：`role` 便于人读，但**权威来源是令牌记录**——
+校验时比对记录中的 role 与 `sha256(secret)`，不一致即拒绝。
+
+### fail-closed
+
+| 情形 | 行为 |
+|---|---|
+| `MDCG_TOKEN` 合法 | 按令牌角色注入身份 |
+| `MDCG_TOKEN` 非法/过期/吊销 | **拒绝启动**，退出码 `3`，不降级为可用 |
+| 无 `MDCG_TOKEN` 且无 `MDCG_LEGACY_ENV_AUTH` | 降级为 `guest`：只读、`internal` 密级、不可管理 |
+| `MDCG_LEGACY_ENV_AUTH=1` | 兼容旧部署的 env 直连（`auth_mode=legacy_env`，不推荐） |
+
+## 3. 角色职责矩阵
+
+五大单元（`record / reflect / verify / output / sustain`）的 `unit / effect / duty`
+与 `identity.POSITIONS`（智能论 v3.4 §十三）**同源**，`test_p21_tokens` 有断言防漂移。
+
+| 角色 | 单元 | 效 | 可写层 | 可执行 op | 密级上限 | 管理 | 可派生 |
+|---|---|---|---|---|---|---|---|
+| `designer` | 设计者权限载体 | 主 | `*` | `*` | secret | ✅ | ✅ |
+| `orchestr` | 仲裁实例（3.9，蜂巢编排者） | 裁 | contextual, unresolved, rejected | info, route, read, write, review, recent, consistency | internal | ✗ | ✗ |
+| `record` | 记录单元 | 全 | knowledge, contextual, structural, unresolved, rejected, goals | info, route, read, write, goal, recent | internal | ✗ | ✗ |
+| `reflect` | 反思单元 | 新 | contextual | info, route, read, write, recent, metacognition | internal | ✗ | ✗ |
+| `verify` | 验证单元 | 稳 | rejected, contextual | info, route, read, write, verify | internal | ✗ | ✗ |
+| `output` | 输出单元 | 通 | —（只读） | info, route, read, recent, whitebox | internal | ✗ | ✗ |
+| `sustain` | 维生系统 | 存 | self | info, read, write, sustain, scrub, evolution, self_state, metacognition | internal | ✗ | ✗ |
+| `guest` | 未认证访客 | — | —（只读） | info, route, read, recent, whitebox | internal | ✗ | ✗ |
+
+别名：`recorder→record`、`reflection→reflect`、`verifier→verify`、`viewer→output`、
+`admin/root→designer`、`anon/anonymous→guest`。
+
+## 4. 核心私有内容保护
+
+「其他单元不应越权修改核心私有内容」由**两道闸门**共同保证：
+
+1. **密级闸门**：`private` / `secret` 内容只有 `clearance` 达标的身份可写。
+   除 `designer` 外的角色密级上限一律 `internal`，因此**天然无法写入核心私有内容**。
+2. **层闸门**：`anchor`（身份锚点）与 `self`（灵枢自身）保护层，
+   只对 `layers_allow` 含该层或 `"*"` 的角色开放。
+
+写入路径统一走 `Principal.require_layer_write(layer, sensitivity)`，
+在 `MdCGSecure.add / add_rejected / add_unresolved / propose / add_goal / set_goal_status`
+六处生效。越权即 `AccessDenied`，不做静默降级。
+
+另有一道 **op 闸门**：`_cg_call` 入口调用 `Principal.require_op(op)`，
+使「只读角色执行 write / review」在进入业务逻辑前就被拦下。
+
+## 5. 单智能体的子代理权职分离
+
+即使是单智能体环境，也用**子代理 + 子令牌**把职责分开，从而校验偏差与盲区：
+
+```python
+from md_cg import tokens
+
+# 外部用户为唯一主智能体签发「设计者权限载体」
+d = tokens.issue("designer", actor="codebuddy", label="设计者载体")
+
+# 主智能体为各单元派生受限子令牌（权限只能收窄）
+v = tokens.derive(d["token"], "verify",  actor="codebuddy-verify",  ttl=3600)
+r = tokens.derive(d["token"], "reflect", actor="codebuddy-reflect", ttl=3600)
+o = tokens.derive(d["token"], "output",  actor="codebuddy-output",  ttl=3600)
+```
+
+由此得到的性质：
+
+- **验证单元写不了被验证内容**：`layers_allow=['rejected','contextual']`，
+  写 `knowledge` 层直接 `AccessDenied`，因此「自己写、自己验」在结构上不成立；
+- **记录单元不能自我验证**：无 `verify` op、无 `rejected` 以外的裁决权；
+- **输出单元不产生副作用**：`can_write=False`，连审计节点都写不了；
+- **维生系统改不了事实**：只能写 `self` 层运维域；
+- **委派链封口**：子令牌 `delegable=False`，不能继续往下派生；
+  父令牌吊销时**级联吊销**整条链。
+
+这样，主智能体无法用「同一个身份」既产出又验收，偏差与盲区有独立单元交叉检查。
+
+## 6. 操作手册
+
+```bash
+# ① 签发设计者载体（明文令牌只返回这一次）
+python -m md_cg.tokens issue --role designer --actor codebuddy --label "外部用户授权载体"
+
+# ② 派生各单元子令牌
+python -m md_cg.tokens derive --token <设计者令牌> --role verify --actor codebuddy-verify --ttl 3600
+
+# ③ 校验身份（打印 role / 可写层 / op 作用域）
+python -m md_cg.tokens verify --token <令牌>
+
+# ④ 清单与吊销
+python -m md_cg.tokens list
+python -m md_cg.tokens revoke --token-id tk_xxxxxxxxxxxx
+
+# ⑤ 打印角色职责矩阵
+python -m md_cg.tokens roles
+```
+
+MCP 接入（`~/.codebuddy/mcp.json`）：
+
+```json
+{
+  "mcpServers": {
+    "mdcg": {
+      "command": "python",
+      "args": ["-m", "md_cg.mcp_server"],
+      "env": {
+        "MDCG_ROOT": "data/mdcg",
+        "MDCG_TOKEN": "mdcg1.designer.tk_xxxxxxxxxxxx.xxxxxxxx"
+      }
+    }
+  }
+}
+```
+
+令牌文件路径可用 `MDCG_TOKEN_FILE` 覆盖（默认 `~/.mdcg/_tokens.json`）。
+
+## 7. 迁移与兼容
+
+- 既有直接构造的 `Principal(...)`（测试、脚本）行为不变：
+  `role="system"`、`layers_allow=None`（不限制），仅新增字段。
+- 旧部署可临时设 `MDCG_LEGACY_ENV_AUTH=1` 继续用 env 身份，
+  `whoami.principal.auth_mode` 会标注 `legacy_env` 以便识别与清理。
+- `test_p2_mcp.py` 已自动带上该开关以保持回归。
+
+## 8. 诚实边界
+
+- **令牌文件即信任根**：`~/.mdcg/_tokens.json` 被写入者可自行追加令牌。
+  本方案把「可自授权限」从进程环境收敛到文件系统权限（0600），
+  未引入外部 KMS/签名链——那是下一步。
+- **明文令牌仍出现在客户端配置里**：MCP 客户端需要它。若需更高强度，
+  应改为「客户端持私钥 + 服务端校验签名」。
+- **角色矩阵是策略不是证明**：`layers_allow` 收窄的是**写层**，
+  读权限仍由 `clearance` 单维控制；跨租户隔离依赖 `MDCG_ROOT` 与 DEK。
+- **`op` 闸门是入口检查**：未覆盖 MCP 暴露的全部 33 个细粒度工具，
+  它们走 `cg`/`stg` 基元时同样受检，但直接调用 `MdCGSecure` 的脚本需自行遵守。

package/docs/hive//344/273/244/347/211/214/350/257/255/344/271/211/344/277/256/346/255/243_/344/273/262/350/243/201/344/275/215_v0.1.md

@@ -0,0 +1,76 @@
+# 令牌语义修正 · 仲裁位 v0.1（设计稿）
+
+> **定位**：关闭「编排者令牌被迫挂 designer 角色」的语义塌缩。参照《令牌与角色权职分离 v0.1》（三层模型/角色矩阵）、《单元自我锚点·子代理系统提示词标准 v0.3》（裁决者=verify 位）与《蜂巢设计·理论对齐 v0.1》裁定 A（实质权力唯一）。
+> **状态**：**已落地**（2026-09-22 施工完成并验证：`ORCH_ROLE="orchestr"` 在线，编排者令牌 tk_fc477e4401ba role=orchestr，端到端第三轮收口全绿；旧 designer 投影 tk_2700d603a5a0 已 revoke）。实测背景：批次 2/3（编排链两轮实测 + 令牌唯一化）。
+
+---
+
+## 〇 条件空间声明
+
+| 维度 | 声明 |
+|---|---|
+| 观测位置 | 设计者视角（全局观测），对象=md_cg 令牌权限模型 × hive 编排链 |
+| 观测工具 | 源码取证（tokens.py/mdcos.py/orch.py）+ 实测（批次 2/3 编排链两轮 + 令牌审计） |
+| 时间窗口 | 2026-09-22 设计；生效依赖维生批准与施工批次 |
+| 存在约束 | 三层模型不破（令牌/角色/派生）；五单元与 identity.POSITIONS 同源断言不破；fail-closed 不破 |
+
+## 一 问题：语义塌缩（实测取证）
+
+- 编排者职能 = 拆解派发 + **裁决子代理冲突**（orch.py 收口，理论位=智能论 3.9 仲裁实例；v0.3 标准对应裁决者/verify 位的判定单职能）。
+- 裁决要过 `MdCGSecure.review_decide` 的库层 `require_admin` 闸门，而 `can_admin` 只有 designer 角色为真 → **编排者被迫持 designer 角色**（tokens.py:225 `ORCH_ROLE = "designer"`，取证 2026-09-16）。
+- 后果：子代理链上出现 role 字面为 designer 的令牌，与「链上零第二设计者」治理意图字面冲突。裁定 A（实质权力唯一）是**过渡合法化**：收窄投影（ops 6 项、无 core 层、不可 forget/anchor/self/goals），但 role 名仍称 designer——**名实不符**。
+
+## 二 理论对齐
+
+- 智能论 3.9：**仲裁实例**是协议内部正式职能位（处理分歧、执行恢复）——裁决权属仲裁位，不属设计者位置（1.4.3 互斥）。
+- v0.3 标准的裁决者模板（判定单七字段）即该职能的提示词投影；五单元矩阵中与其最贴近的是 **verify（稳）**，但仲裁实例还需 write（收口归档）——故独立成位比塞进 verify 更诚实。
+- 令牌 v0.1 §5 已确立「单智能体子代理权职分离」先例：主智能体（唯一设计者载体）派生受限子令牌。本稿把「编排者」纳入同一范式。
+
+## 三 设计
+
+### 3.1 新增角色 `orchestr`（仲裁位）
+
+进 `tokens.ROLE_SPECS`（与五单元同源风格，effect 取「裁」，对应 3.9 仲裁实例）：
+
+| 字段 | 值 | 说明 |
+|---|---|---|
+| unit | 仲裁实例（3.9） | 非五单元，独立职能位（模板对应 v0.3 裁决者主轴+编排收口） |
+| effect | 裁 | 与全新稳通存并列，出处=3.9 |
+| 可写层 | contextual, unresolved, rejected | 收口归档所需；**无 knowledge**（升层仍走设计者/收口纪律既有通道）与 **无 anchor/self/goals** |
+| 可执行 op | info, route, read, write, review, recent, consistency | 即现 ORCH_OPS_ALLOW |
+| 密级上限 | internal | 同五单元 |
+| 管理 | ✗ | **can_admin=False（关键变化）**：不可 forget/protect/动 anchor |
+| 可派生 | ✗ | 委派链封口 |
+
+### 3.2 权限模型配套：拆开「裁决权」与「管理权」
+
+- `review_decide` 闸门：`require_admin` → **`require_op("review")` + `require_layer_write(被裁决节点所在层)`** 复合。
+- `can_admin` 语义收窄回本位：仅 forget / protect / anchor 写 / 令牌管理 等存在级操作。
+- 影响面（施工时逐点核对）：`mdcos.py`（review_decide 及 require_admin 其他调用点）、`md_cg/mcp_server.py` 的 review 面、`test_p21_tokens`（31 项断言扩展+修订）、`hive/orch.py`（principal role 日志与校验）、`tokens.py ORCH_*` 常量（`ORCH_ROLE = "orchestr"`）。
+
+### 3.3 兼容与迁移（顺序铁律：先改模型，后重签，再换链）
+
+1. 施工：新增角色 + 闸门拆分 + 断言（先行能红测试：orchestr 派生后 review_decide 可过、forget/anchor 写必拒）。
+2. 重签：`orch --token <579ce0> --out`（同一维生根，无需新授权——派生链不变，仅角色语义修正）。
+3. 换链：`hive/config.local.json` 的 `HIVE_ORCH_TOKEN_FILE` 不变（文件路径同位，内容被覆盖）→ `--restart`。
+4. 旧投影令牌（tk_2700d603a5a0，role=designer 收窄版）由维生 revoke 收口。
+5. 文档同步：本稿状态改「已落地」；`令牌与角色权职分离` 升 v0.2（矩阵加 orchestr 行）；hive/README 令牌段同步。
+
+### 3.4 验证判据（能红 + 反向对照，ref-14 标准）
+
+- 正向：orchestr 令牌 `review_decide` 成功（编排收口裁决可用）；`forget` 拒（AccessDenied）；写 `anchor/self/goals` 拒；写 `knowledge` 拒；`derive` 再派生拒。
+- 反向对照：旧模型（require_admin 一刀切）下 orchestr 裁决必被拒（旧行为可红）；role 字面校验（令牌串 `mdcg1.orchestr.` 前缀 + 记录 role 一致）。
+- 端到端：编排实测第三轮（失败子任务收口 + 冲突裁决场景），编排者持 orchestr 令牌完成裁决且认知图审计记录 actor=hive-orchestrator。
+
+## 四 诚实边界
+
+- **令牌文件即信任根**不变（v0.1 §8）：文件写入者仍可自授权限，收敛到 0600 是现状上限。
+- orchestr 的「裁」仍是**协议内部裁决**：判定不一致的终裁在维生（12 节），orchestr 不终裁——与其令牌能力一致（无 sustain op）。
+- 五单元同源断言（test_p21_tokens）需要扩展而非修改：orchestr 是 3.9 职能位投影，不冒充五单元。
+
+## 五 变更记录
+
+| 日期 | 版本 | 变更 |
+|---|---|---|
+| 2026-09-22 | v0.1 | 初稿：问题取证（批次 2/3 实测）+ 理论对齐（3.9 仲裁位/裁定 A）+ orchestr 角色设计 + 闸门拆分 + 迁移顺序 + 能红判据 |
+| 2026-09-22 | v0.1.1 | **施工落地**：tokens.py 新增 orchestr 角色 + ORCH_ROLE="orchestr"；mdcos.py review_decide 闸门拆分（require_op("review")）；test_p21_tokens 38/0（含 [2b] orchestr 断言组 7 项）；重签 tk_fc477e4401ba + revoke tk_2700d603a5a0 + restart；端到端第三轮（失败子任务收口）全绿。观测：失败处理场景 12 轮仍触发 forced_final，但收口指令加固使其产出真结论——轮次下限调参记台账不急调 |