dsh-kingdom 3.1.0 → 3.2.0

package/README.md

@@ -5,7 +5,7 @@
 **在 DeepSeek Harness 里，装一个插件，拥有一个自己的 Agent 王国。**
 
 [![CI](https://github.com/lusblead/dsh-Kingdom/actions/workflows/ci.yml/badge.svg)](https://github.com/lusblead/dsh-Kingdom/actions/workflows/ci.yml)
-[![Version](https://img.shields.io/badge/version-3.1.0%20local%20candidate-blue)](docs/V3.1-RELEASE-NOTES.md)
+[![Version](https://img.shields.io/badge/version-3.2.0%20local%20candidate-blue)](docs/V3.2-RELEASE-NOTES.md)
 [![License](https://img.shields.io/badge/license-AGPL--3.0--or--later-green)](LICENSE)
 [![DSH](https://img.shields.io/badge/DSH-0.1.5--rc%20%7C%200.1.7--rc-orange)](#1-前置要求)
 [![Node](https://img.shields.io/badge/Node-%3E%3D22.19-339933)](#1-前置要求)
@@ -67,12 +67,12 @@ DSH：任务 CREATED → ASSIGNED → RUNNING → REVIEW → DONE ✅
 - **Node.js** ≥ `22.19`（内置 SQLite，插件零原生依赖）
 - 一个可用的模型 API key（Worker 执行需要）
 
-### 2. 安装 v3.1.0
+### 2. 安装 v3.2.0
 
-本版以 GitHub [Releases](https://github.com/lusblead/dsh-Kingdom/releases) 与 npm 为公开入口；若当前环境还取不到已发布包，可从源码构建取得准确的 `dsh-kingdom-3.1.0.tgz`，核对包与本机备份后，再在自己的 DSH Web profile 安装：
+本版以 GitHub [Releases](https://github.com/lusblead/dsh-Kingdom/releases) 与 npm 为公开入口；若当前环境还取不到已发布包，可从源码构建取得准确的 `dsh-kingdom-3.2.0.tgz`，核对包与本机备份后，再在自己的 DSH Web profile 安装：
 
 ```bash
-dsh plugin --profile web add ./dsh-kingdom-3.1.0.tgz
+dsh plugin --profile web add ./dsh-kingdom-3.2.0.tgz
 ```
 
 安装后重启 Web profile 才会加载新包。不要将本地候选的版本号当作 npm 或 GitHub Releases 已可下载的证据。
@@ -199,7 +199,8 @@ GUI 已内置在插件中，不需要下载或启动第二个前端项目。直
 | 1.0.0 | 王国地图、管理中心、王国账本、移交、沙箱与诚实的执行控制投影 | ✅ 已发布 |
 | 2.0.0 | 个人工作台、人类管理窗口、有界协作、用量与软预算、恢复约束 | 上一版本；发布状态以 Releases 为准 |
 | 3.0.0 | Owner 交付清单、逐条知悉、主管确认的改动证据、条目问答 | 随 3.1.0 一并发布 |
-| 3.1.0 | DSH 0.1.7 兼容（peer 分线声明）、无 live Agent 会话可绑定席位、`session_evidence` 证据字段 | 当前版本；发布状态以 Releases 为准 |
+| 3.1.0 | DSH 0.1.7 兼容（peer 分线声明）、无 live Agent 会话可绑定席位、`session_evidence` 证据字段 | 上一版本；发布状态以 Releases 为准 |
+| 3.2.0 | 主管与领地完全绑定（任命即指定领地、席位与主理同一事务、退任同时解除主理）、交付区版面修复 | 当前版本；发布状态以 Releases 为准 |
 
 > 已发布版本与市场更新状态以 [Releases](https://github.com/lusblead/dsh-Kingdom/releases) 为准（发布流程见 [RELEASE.md](RELEASE.md)）。
 
@@ -207,6 +208,7 @@ GUI 已内置在插件中，不需要下载或启动第二个前端项目。直
 
 ## 📖 文档
 
+- [3.2 版本说明](docs/V3.2-RELEASE-NOTES.md) — 主管与领地完全绑定、原子写入与退任联动、交付区版面修复
 - [3.1 版本说明](docs/V3.1-RELEASE-NOTES.md) — DSH 0.1.7 兼容范围与无 live Agent 会话的席位绑定
 - [3.0 使用指南](docs/V3.0-USER-GUIDE.md) — 交付清单、知悉、查看改动与条目问答
 - [3.0 版本说明](docs/V3.0-RELEASE-NOTES.md) — 新增内容及实际验证范围

package/docs/DSH-KINGDOM-3.0-ANNOUNCEMENT.md

@@ -1,13 +1,13 @@
-# dsh-Kingdom 3.0 本地候选：让 Agent 的交付，真正到达人
-
-一轮 Worker 执行的结果经宿主接收，主管审查并接受后，人若只看到一句“审核系统完成了”，仍很难判断自己该看什么、哪里变了、还有哪些问题需要追问。dsh-Kingdom 3.0 在已有 2.0 工作台上加入一份可逐层打开的交付清单，由 Owner 主动查看；宰相目前不会自动上报。
-
-先看结果，再看依据。Owner 可以从交付摘要进入具体事项、产物、风险和改动证据。点开一项，能看到它对应的内容版本；点“查看改动”，能进一步查看有界的文件差异。未提交的修改也能通过执行前后快照保留证据，由主管挑选并确认哪些条目属于本次交付。界面会明确写出“主管确认的改动证据”——它不是 Git 对 Worker 作者身份的证明，覆盖不足也不会伪装成完整记录。
-
-看过之后，可以逐条点“知悉”。这不是考试，也不是让系统猜人是否理解：Owner 点了并在管理窗口确认，就表示“我知道这一条当前版本”。摘要与细项各记各的；后续内容改版，旧知悉留在历史，新版本重新待知悉。知悉不会替主管验收，也不会把任务自动标成完成。
-
-如果还想问，从那条内容直接点“提问”。问题固定在该任务、该条目、该版本上，由**接受这份交付的主管**在自己的会话身份下读取并回复。回复回到同一条问答记录；主管退任或换绑时，系统明确显示不可达，不会悄悄把问题交给继任者。未确认主管已读取之前，界面只说“待领取”，不把写入账本误称为已经通知。
-
-这一轮的核心不是让 Agent 多说几段总结，而是让人可以沿着“结论 → 细节 → 改动 → 问题”自主深入，并把自己已经知悉的版本留成可追溯事实。按钮和图标承担操作，长文字只留给真正需要解释的内容。
-
-3.0.0 目前是本地候选：这批新内容是在已升级的 2.0 工作台上完成的；开发期曾用仍标为 2.0.0 的本地包提前安装验证，现在把它准确归入 3.0。它还不是 npm/GitHub 上已发布的新版本。知悉不是最终验收，改动证据不是作者鉴定，真实 Agent 回合与正式验收仍需单独验证。我们希望先把信息差变成看得见、点得开、问得清的界面，再用真实使用反馈检验它是否真的减轻人的负担。
+# dsh-Kingdom 3.0 本地候选：让 Agent 的交付，真正到达人
+
+一轮 Worker 执行的结果经宿主接收，主管审查并接受后，人若只看到一句“审核系统完成了”，仍很难判断自己该看什么、哪里变了、还有哪些问题需要追问。dsh-Kingdom 3.0 在已有 2.0 工作台上加入一份可逐层打开的交付清单，由 Owner 主动查看；宰相目前不会自动上报。
+
+先看结果，再看依据。Owner 可以从交付摘要进入具体事项、产物、风险和改动证据。点开一项，能看到它对应的内容版本；点“查看改动”，能进一步查看有界的文件差异。未提交的修改也能通过执行前后快照保留证据，由主管挑选并确认哪些条目属于本次交付。界面会明确写出“主管确认的改动证据”——它不是 Git 对 Worker 作者身份的证明，覆盖不足也不会伪装成完整记录。
+
+看过之后，可以逐条点“知悉”。这不是考试，也不是让系统猜人是否理解：Owner 点了并在管理窗口确认，就表示“我知道这一条当前版本”。摘要与细项各记各的；后续内容改版，旧知悉留在历史，新版本重新待知悉。知悉不会替主管验收，也不会把任务自动标成完成。
+
+如果还想问，从那条内容直接点“提问”。问题固定在该任务、该条目、该版本上，由**接受这份交付的主管**在自己的会话身份下读取并回复。回复回到同一条问答记录；主管退任或换绑时，系统明确显示不可达，不会悄悄把问题交给继任者。未确认主管已读取之前，界面只说“待领取”，不把写入账本误称为已经通知。
+
+这一轮的核心不是让 Agent 多说几段总结，而是让人可以沿着“结论 → 细节 → 改动 → 问题”自主深入，并把自己已经知悉的版本留成可追溯事实。按钮和图标承担操作，长文字只留给真正需要解释的内容。
+
+3.0.0 目前是本地候选：这批新内容是在已升级的 2.0 工作台上完成的；开发期曾用仍标为 2.0.0 的本地包提前安装验证，现在把它准确归入 3.0。它还不是 npm/GitHub 上已发布的新版本。知悉不是最终验收，改动证据不是作者鉴定，真实 Agent 回合与正式验收仍需单独验证。我们希望先把信息差变成看得见、点得开、问得清的界面，再用真实使用反馈检验它是否真的减轻人的负担。

package/docs/V3.0-RELEASE-NOTES.md

@@ -1,21 +1,21 @@
-# dsh-Kingdom 3.0.0 本地候选说明
-
-本轮在已升级的 2.0 个人工作台基础上，新增 Owner 可见的交付清单、逐条知悉、主管确认的改动证据与条目问答，并把它们确立为 3.0 的主题。开发验证阶段的本地包仍标为 2.0.0，曾提前包含本轮代码；这个临时包号不改变 3.0 的功能归属，也不代表公共 npm/GitHub Release 已存在。
-
-## 使用者可见内容
-
-- Owner 主动打开已确认交付，从摘要展开到具体条目；宰相目前不会自动上报。每条有稳定身份和内容版本；旧版知悉不会自动覆盖新版，父摘要知悉也不会覆盖子条。
-- Owner 可在独立管理窗口预览并提交“知悉”。它只记录 Owner 声明知道该条当前版本，不是理解测验、质量验收、任务完成或发布授权。
-- 执行前后有界快照支持未提交文件的差异证据。主管在 `ACCEPT` 时显式确认属于本交付的条目；Owner 可按条目查看。证据说明“主管确认的改动”，不证明文件由哪个 Worker 编写；覆盖不足时不伪称完整。
-- Owner 可就一条交付提出问题；接受该交付的原主管通过当前 session-bound Agent Tool 收件和回复。正文不进入普通工作台快照或事件轮询；工作台仅展示状态/计数。没有自动通知、自动唤醒或继任者转派。
-- 旧格式主管接受记录可知悉，但标注历史接受证据较弱。
-
-## 安装和兼容边界
-
-本候选沿用现有 schema v4 和事件账本，没有因知悉/问答增加新表。它仍按已声明的 DSH `0.1.5-rc` peer 范围运行。升级前请保留旧包和配置，并对数据库做 SQLite 一致备份；安装后须重启所用的 DSH profile。若要安装此候选，须先从当前源码构建并核验准确的本地 `dsh-kingdom-3.0.0.tgz`；公共 registry 与 GitHub Releases 发布未执行。操作见 [3.0 使用指南](V3.0-USER-GUIDE.md)。
-
-## 证据与未完成项
-
-本轮功能开发期（本地包号仍为 2.0.0）的代码评审中，Owner 面板定向测试 50/50、问答闭环 21/21，构建和 Feature Flow 校验通过；提前安装到本机 DSH Web 后，模块可导入、Web/Kingdom GUI 可启动，新问答路由对未授权请求返回 401（不存在的路由返回 404）。这不证明授权读取成功。重新标记 3.0.0 后，定向测试 109 通过、1 跳过，全量 `npm test` 582 通过、2 跳过，Feature Flow 变更校验为 0 错误、0 警告。3.0.0 安装结果仍须以准确包和独立安装回执核验，不能继承旧包哈希。
-
-正式 Audit、Owner 最终验收、正式数据库中的知悉/问答写入、真实 Agent/Provider 回合、完整浏览器人工交互与收益测量均 `NOT_RUN`。因此不宣传具体节省时间、Token 或成本比例，也不把本地安装写成公开发布或生产就绪。
+# dsh-Kingdom 3.0.0 本地候选说明
+
+本轮在已升级的 2.0 个人工作台基础上，新增 Owner 可见的交付清单、逐条知悉、主管确认的改动证据与条目问答，并把它们确立为 3.0 的主题。开发验证阶段的本地包仍标为 2.0.0，曾提前包含本轮代码；这个临时包号不改变 3.0 的功能归属，也不代表公共 npm/GitHub Release 已存在。
+
+## 使用者可见内容
+
+- Owner 主动打开已确认交付，从摘要展开到具体条目；宰相目前不会自动上报。每条有稳定身份和内容版本；旧版知悉不会自动覆盖新版，父摘要知悉也不会覆盖子条。
+- Owner 可在独立管理窗口预览并提交“知悉”。它只记录 Owner 声明知道该条当前版本，不是理解测验、质量验收、任务完成或发布授权。
+- 执行前后有界快照支持未提交文件的差异证据。主管在 `ACCEPT` 时显式确认属于本交付的条目；Owner 可按条目查看。证据说明“主管确认的改动”，不证明文件由哪个 Worker 编写；覆盖不足时不伪称完整。
+- Owner 可就一条交付提出问题；接受该交付的原主管通过当前 session-bound Agent Tool 收件和回复。正文不进入普通工作台快照或事件轮询；工作台仅展示状态/计数。没有自动通知、自动唤醒或继任者转派。
+- 旧格式主管接受记录可知悉，但标注历史接受证据较弱。
+
+## 安装和兼容边界
+
+本候选沿用现有 schema v4 和事件账本，没有因知悉/问答增加新表。它仍按已声明的 DSH `0.1.5-rc` peer 范围运行。升级前请保留旧包和配置，并对数据库做 SQLite 一致备份；安装后须重启所用的 DSH profile。若要安装此候选，须先从当前源码构建并核验准确的本地 `dsh-kingdom-3.0.0.tgz`；公共 registry 与 GitHub Releases 发布未执行。操作见 [3.0 使用指南](V3.0-USER-GUIDE.md)。
+
+## 证据与未完成项
+
+本轮功能开发期（本地包号仍为 2.0.0）的代码评审中，Owner 面板定向测试 50/50、问答闭环 21/21，构建和 Feature Flow 校验通过；提前安装到本机 DSH Web 后，模块可导入、Web/Kingdom GUI 可启动，新问答路由对未授权请求返回 401（不存在的路由返回 404）。这不证明授权读取成功。重新标记 3.0.0 后，定向测试 109 通过、1 跳过，全量 `npm test` 582 通过、2 跳过，Feature Flow 变更校验为 0 错误、0 警告。3.0.0 安装结果仍须以准确包和独立安装回执核验，不能继承旧包哈希。
+
+正式 Audit、Owner 最终验收、正式数据库中的知悉/问答写入、真实 Agent/Provider 回合、完整浏览器人工交互与收益测量均 `NOT_RUN`。因此不宣传具体节省时间、Token 或成本比例，也不把本地安装写成公开发布或生产就绪。

package/docs/V3.0-USER-GUIDE.md

@@ -1,33 +1,33 @@
-# dsh-Kingdom 3.0 交付知悉与问答指南
-
-3.0.0 是当前本地候选版本，尚未发布到 npm 或 GitHub Releases。本轮在已升级的 2.0 工作台上新增 Owner 交付知悉与问答层；任务、协作、用量和基础配置仍见 [2.0 使用指南](V2.0-USER-GUIDE.md)。开发验证时曾使用仍标为 2.0.0 的本地包，不应把那个临时包号当作 3.0 功能已正式发布的证据。
-
-## 安装与第一次使用
-
-先保留原插件包与配置，对现有 SQLite 数据库做一致备份。取得从本候选源码构建并核对过的 `dsh-kingdom-3.0.0.tgz` 后，在自己的 DSH Web profile 中安装，再重启该 profile；仅更改 `package.json` 的版本号不会让运行中的 DSH 自动加载新代码。
-
-```shell
-dsh plugin --profile web add ./dsh-kingdom-3.0.0.tgz
-```
-
-不要将上述本地包命令替换成尚不存在的 `dsh-kingdom@3.0.0` 公共 registry 版本。首次建立王国、领地和角色仍按 [2.0 第一次使用](V2.0-USER-GUIDE.md#第一次使用) 操作。Owner 是人类操作者，不是 Agent 或 DSH Session。
-
-## Owner：从交付清单到逐条知悉
-
-1. Worker 提交结果后，先由该任务的主管完成审查并 `ACCEPT`。Worker 的 Claim 本身不是已确认交付。
-2. Owner 主动在个人工作台打开已确认交付；宰相目前不会自动上报。先看摘要，再展开事项、产物、风险和主管确认的改动条目。父条目和每个子条目分别有自己的内容版本与知悉状态。
-3. 对改动条目选择“查看改动”，在有效的人类管理窗口里读取固定版本的仓库相对路径、有界差异和证据状态。未提交改动也可来自执行前后快照；只有主管显式选择的条目才标为“主管确认的改动证据”。这不是 Git 对 Worker 作者身份的证明；忽略、超限或证据漂移时以界面标注的部分覆盖或不可定位为准。
-4. 选择某条的“知悉”后，管理窗口固定该 Task、条目及内容版本；尚未激活窗口时，按提示从本人直接命令入口完成授权，回来仍定位原条目。核对预览并提交后才写入 Owner 知悉事实；同版重试幂等，条目改版后旧知悉只留历史，新版需要重新知悉。
-5. “知悉”只表示 Owner 声明知道**这一条的当前版本**。它不测理解程度，不代表质量认可、人类最终验收、主管 `ACCEPT`、Task `DONE` 或发布许可；知道父摘要也不会自动覆盖子条目。
-
-旧版 `TASK_ACCEPTED` 若没有结果摘要绑定，仍允许查看和知悉，但界面明确标出较弱的历史接受证据。不能把该标签升级成新格式的精确结果证明。
-
-## Owner 提问与主管回复
-
-从具体条目点“提问”，管理窗口会固定同一个 Task、条目和内容版本。填写问题、预览并提交后，它成为独立事件；提问不会顺带写入“知悉”。工作台只显示有界计数与状态，问题和回复正文须在有效 Owner 管理窗口回看。
-
-问题交给**接受该交付时记录的主管**。该主管在自己真实、当前且有效的 session-bound 身份下，用 `kingdom_delivery_questions` 读取属于自己的问题，再用 `kingdom_delivery_reply` 回复。系统不会自动通知、唤醒主管或把问题改投继任者；未核实主管已读取前只称“待领取”。原主管退任、换 Session 或领地改绑时，问题保留可回看，但当前不可回复。条目改版后，旧问答仍是历史，不冒充新版待办。
-
-## 当前验证边界
-
-本地代码评审和隔离测试覆盖知悉、改动证据及问答的关键成功/拒绝路径；开发期本地 DSH 安装验证只证明包已加载、新问答路由对未授权请求返回 401（不存在的路由返回 404），不证明授权读取成功。正式数据库中的真实知悉/提问、真实 Agent/Provider 回合、完整浏览器人工验收与正式 Audit 尚未完成。不要从版本号或安装成功推出这些结论。详情见 [3.0 版本说明](V3.0-RELEASE-NOTES.md)。
+# dsh-Kingdom 3.0 交付知悉与问答指南
+
+3.0.0 是当前本地候选版本，尚未发布到 npm 或 GitHub Releases。本轮在已升级的 2.0 工作台上新增 Owner 交付知悉与问答层；任务、协作、用量和基础配置仍见 [2.0 使用指南](V2.0-USER-GUIDE.md)。开发验证时曾使用仍标为 2.0.0 的本地包，不应把那个临时包号当作 3.0 功能已正式发布的证据。
+
+## 安装与第一次使用
+
+先保留原插件包与配置，对现有 SQLite 数据库做一致备份。取得从本候选源码构建并核对过的 `dsh-kingdom-3.0.0.tgz` 后，在自己的 DSH Web profile 中安装，再重启该 profile；仅更改 `package.json` 的版本号不会让运行中的 DSH 自动加载新代码。
+
+```shell
+dsh plugin --profile web add ./dsh-kingdom-3.0.0.tgz
+```
+
+不要将上述本地包命令替换成尚不存在的 `dsh-kingdom@3.0.0` 公共 registry 版本。首次建立王国、领地和角色仍按 [2.0 第一次使用](V2.0-USER-GUIDE.md#第一次使用) 操作。Owner 是人类操作者，不是 Agent 或 DSH Session。
+
+## Owner：从交付清单到逐条知悉
+
+1. Worker 提交结果后，先由该任务的主管完成审查并 `ACCEPT`。Worker 的 Claim 本身不是已确认交付。
+2. Owner 主动在个人工作台打开已确认交付；宰相目前不会自动上报。先看摘要，再展开事项、产物、风险和主管确认的改动条目。父条目和每个子条目分别有自己的内容版本与知悉状态。
+3. 对改动条目选择“查看改动”，在有效的人类管理窗口里读取固定版本的仓库相对路径、有界差异和证据状态。未提交改动也可来自执行前后快照；只有主管显式选择的条目才标为“主管确认的改动证据”。这不是 Git 对 Worker 作者身份的证明；忽略、超限或证据漂移时以界面标注的部分覆盖或不可定位为准。
+4. 选择某条的“知悉”后，管理窗口固定该 Task、条目及内容版本；尚未激活窗口时，按提示从本人直接命令入口完成授权，回来仍定位原条目。核对预览并提交后才写入 Owner 知悉事实；同版重试幂等，条目改版后旧知悉只留历史，新版需要重新知悉。
+5. “知悉”只表示 Owner 声明知道**这一条的当前版本**。它不测理解程度，不代表质量认可、人类最终验收、主管 `ACCEPT`、Task `DONE` 或发布许可；知道父摘要也不会自动覆盖子条目。
+
+旧版 `TASK_ACCEPTED` 若没有结果摘要绑定，仍允许查看和知悉，但界面明确标出较弱的历史接受证据。不能把该标签升级成新格式的精确结果证明。
+
+## Owner 提问与主管回复
+
+从具体条目点“提问”，管理窗口会固定同一个 Task、条目和内容版本。填写问题、预览并提交后，它成为独立事件；提问不会顺带写入“知悉”。工作台只显示有界计数与状态，问题和回复正文须在有效 Owner 管理窗口回看。
+
+问题交给**接受该交付时记录的主管**。该主管在自己真实、当前且有效的 session-bound 身份下，用 `kingdom_delivery_questions` 读取属于自己的问题，再用 `kingdom_delivery_reply` 回复。系统不会自动通知、唤醒主管或把问题改投继任者；未核实主管已读取前只称“待领取”。原主管退任、换 Session 或领地改绑时，问题保留可回看，但当前不可回复。条目改版后，旧问答仍是历史，不冒充新版待办。
+
+## 当前验证边界
+
+本地代码评审和隔离测试覆盖知悉、改动证据及问答的关键成功/拒绝路径；开发期本地 DSH 安装验证只证明包已加载、新问答路由对未授权请求返回 401（不存在的路由返回 404），不证明授权读取成功。正式数据库中的真实知悉/提问、真实 Agent/Provider 回合、完整浏览器人工验收与正式 Audit 尚未完成。不要从版本号或安装成功推出这些结论。详情见 [3.0 版本说明](V3.0-RELEASE-NOTES.md)。

package/docs/V3.1-RELEASE-NOTES.md

@@ -1,72 +1,76 @@
-# dsh-Kingdom 3.1.0 本地候选说明
-
-3.1.0 只有两处产品变更：**DSH peer 兼容范围** 与 **无 live Agent 会话的席位绑定**。
-schema、事件账本、GUI 与治理语义均未改动——沿用 schema v4 与既有事件类型，没有新增表、
-没有新增迁移。
-
-## 验证状态（本轮实际执行过的）
-
-| 项 | 结果 |
-|---|---|
-| `npm run typecheck`（`tsc -p tsconfig.json --noEmit`） | 通过，0 错误 |
-| 全量 `node --test tests/*.test.ts` | 586 项：**584 通过 / 0 失败 / 2 跳过**（2 项为 Unix-only 用例） |
-| 定向用例 `tests/index-owner-binding-integration.test.ts` | 8/8 通过（含 2 个 v3.1 新增用例） |
-| peer 谓词复算（运行时自带 `semver@7.8.5`） | `0.1.5-rc.2` ✓、`0.1.7-rc.2` ✓；`0.1.6-*` 与 `0.1.8+` 刻意不含 |
-| peer 预检复算（用 DSH 0.1.7-rc.2 自带的 `evaluatePluginCompatibility`，`includePrerelease: true`） | `0.1.7-rc.2` → 不跳过；父提交声明 → 4 条 peer 全部不兼容（会被整层跳过） |
-| 发布门 `pwsh -File scripts/release.ps1 -Version 3.1.0 -DryRun` | P0–P3 全 PASS |
-| 本机 profile 重装 3.1.0（2026-09-28 11:43） | 完成：profile 依赖指向 `dsh-kingdom-3.1.0.tgz`，已装 `version=3.1.0`，`lib/index.js` 与候选构建同哈希 |
-| DSH `0.1.7-rc.2` 实机加载回归（2026-09-28 11:48 起） | 完成：宿主命令行指向 `dsh-0.1.7-rc.2`，`skipping profile bundle` 与 `disabling profile plugin` 均 **0 行** |
-| 无 live Agent 会话的真机验证 | 完成：`ROLE_BOUND` 事件记 `session_evidence=DURABLE_SESSION`（无 live Agent 的会话被接受）；不存在的 session id 仍被 `SESSION_ABSENT` 拒绝且零写入 |
-
-**未执行（NOT_RUN）**：真实浏览器人工交互验收；DSH 0.1.7 下**全部 14 条 bundle 的真实 boot**（只做了
-`--dump-config` dry-run 与行级门禁的离线复算）；其它第三方插件在 0.1.7 下的业务功能正确性；Linux 平台；
-收益与成本测量。未运行过的项不得当作已通过。本版发布前的独立审查结论与 Owner 验收记录见发布回执（不在包内）。
-
-## 1. DSH peer 兼容范围放宽
-
-- 旧：`@deepseek-ai/dsh-commands` / `dsh-llm` / `dsh-tools` = `>=0.1.5-rc.1 <0.1.5`，
-  `dsh-token-meter` = `>=0.1.5-rc.2 <0.1.5`。
-- 新：两条版本线并列 `>=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-0 <0.1.8-0`
-  （`dsh-token-meter` 下界为 `0.1.5-rc.2`）。`package-lock.json` 的 peer 快照同步。
-- **为什么必须分线写**：在 semver 的 prerelease 规则下，`>=0.1.5-rc.1 <0.2.0` 并**不包含**
-  `0.1.7-rc.2`（只包含 0.1.5-rc 线与 0.1.8 稳定版）。分线写法是唯一能同时表达"已验证的
-  0.1.5-rc 线"与"目标 0.1.7 线"且不误收未测版本的形式。
-- **为什么必须改**：DSH `0.1.7-rc.2` 的 `@deepseek-ai/dsh-app-boot` 新增插件兼容性预检
-  （`evaluatePluginCompatibility`，`lib/index.js:286-313`）。它只检查 `@deepseek-ai/dsh` 与
-  `@deepseek-ai/dsh-*`，判据是 `semver.satisfies(runtime, range, { includePrerelease: true })`；
-  `loadProfileDirectory`（`:919-955`）对 `dsh.profile.bundles` 中每个 bundle 判定，不通过且未豁免
-  即抛出 → 收进 `skippedBundles` → **该 bundle 整层不加载**。症状是启动不报错，只在 stderr 留
-  一行 skip 警告，而工具、`/kingdom` 命令与 GUI 会一起消失。
-- **只改声明不够**：预检读取的是**已安装副本**的 `package.json`。必须重新打包并重装该 profile，
-  否则升级后仍然是旧的 `<0.1.5` 声明。
-- 未改 `@deepseek-ai/cordis`（`>=4.0.0-rc <5`）与 `@deepseek-ai/schemastery`（`^3.18.0`）：它们
-  不在预检集合内，且 0.1.7-rc.2 携带的 4.0.4 / 3.18.4 均落在范围内。
-
-## 2. 无 live Agent 的会话现在可以绑定席位
-
-- **症状**：对一个刚创建、尚未产生任何消息的会话执行
-  `/kingdom role.bind {"role_type":"SUPERVISOR",…,"session_id":"…"}` 会得到
-  `INPUT_DENIED [SESSION_ABSENT]`，于是无法预先设置主管席位。
-- **原因**：目标会话校验只接受 live Agent（`agents.get(session_id)` 返回同一条 Agent，且状态为
-  `idle` 或 `running`）。DSH 的 Agent 一旦被回收就会移出注册表（`AgentStatus` 本身只有
-  `idle | running`，disposal 不是第三种状态），此后该 session_id 再也过不了校验。
-- **现行为**（`resolveDirectTargetSession`）：
-  1. live Agent 命中 → 放行，事件记 `session_evidence: "LIVE_AGENT"`；
-  2. 仅当分类为 `ABSENT`（注册表里没有这条 live Agent）时，回退到"该 session_id 已在本机 DSH
-     持久会话存储中登记"的存在性证明（`ctx.sessionQuery.observeSession`，只用 header 做身份比对，
-     观察租约用完即释放）→ 放行，事件记 `session_evidence: "DURABLE_SESSION"`；
-  3. 两条路都证明不了 → 仍然拒绝，**零写入**。
-- **没有放宽的部分**：`FOREIGN` / `MULTIPLE` / `EXPIRED` / `UNKNOWN` 一律保持 fail-closed，不因
-  "可能是它"而放行；调用者身份校验（`resolveTrustedToolSession`）未改动，仍要求 live Agent；
-  宿主未挂载 `sessionQuery` 时退化为原行为（拒绝并说明缺少观察通道）。Owner 管理窗口的目标会话
-  校验与列表使用同一解析器，行为一致。
-- **语义边界**：`DURABLE_SESSION` 只说明"这条会话属于本机 DSH"，**不说明它当前可执行**。席位在
-  该会话真正启动前不能派发或复核；这条证据强度差异会记进 `ROLE_BOUND` /
-  `BINDING_PROFILE_UPDATED` 事件的 `session_evidence` 字段，供审计区分。
-
-## 3. 与本机现状的关系
-
-本文件描述 3.1.0 候选。截至 2026-09-28：本机 `web` profile 已于 11:43 重装为 `dsh-kingdom-3.1.0`
-（依赖指向 `dsh-kingdom-3.1.0.tgz`），运行宿主自 11:48 起为 DSH `0.1.7-rc.2`，且未出现任何 bundle 跳过。
-回退路径：保留的 `dsh-kingdom-3.0.0.tgz`、profile 三件套备份、会话与 storages 全量副本、王国库一致性
-副本，以及 `rollback-to-015.ps1`。
+# dsh-Kingdom 3.1.0 本地候选说明
+
+> 本文是 3.1.0 的历史记录，描述的是当时的语法与行为。**3.2.0 起主管的 `role.bind` 必须同时给出
+> `territory_id`**（席位与领地主理同一事务原子写入），本文第 48 行附近的示例已不适用于 3.2.0；
+> 请以 [3.2 版本说明](V3.2-RELEASE-NOTES.md) 为准。
+
+3.1.0 只有两处产品变更：**DSH peer 兼容范围** 与 **无 live Agent 会话的席位绑定**。
+schema、事件账本、GUI 与治理语义均未改动——沿用 schema v4 与既有事件类型，没有新增表、
+没有新增迁移。
+
+## 验证状态（本轮实际执行过的）
+
+| 项 | 结果 |
+|---|---|
+| `npm run typecheck`（`tsc -p tsconfig.json --noEmit`） | 通过，0 错误 |
+| 全量 `node --test tests/*.test.ts` | 586 项：**584 通过 / 0 失败 / 2 跳过**（2 项为 Unix-only 用例） |
+| 定向用例 `tests/index-owner-binding-integration.test.ts` | 8/8 通过（含 2 个 v3.1 新增用例） |
+| peer 谓词复算（运行时自带 `semver@7.8.5`） | `0.1.5-rc.2` ✓、`0.1.7-rc.2` ✓；`0.1.6-*` 与 `0.1.8+` 刻意不含 |
+| peer 预检复算（用 DSH 0.1.7-rc.2 自带的 `evaluatePluginCompatibility`，`includePrerelease: true`） | `0.1.7-rc.2` → 不跳过；父提交声明 → 4 条 peer 全部不兼容（会被整层跳过） |
+| 发布门 `pwsh -File scripts/release.ps1 -Version 3.1.0 -DryRun` | P0–P3 全 PASS |
+| 本机 profile 重装 3.1.0（2026-09-28 11:43） | 完成：profile 依赖指向 `dsh-kingdom-3.1.0.tgz`，已装 `version=3.1.0`，`lib/index.js` 与候选构建同哈希 |
+| DSH `0.1.7-rc.2` 实机加载回归（2026-09-28 11:48 起） | 完成：宿主命令行指向 `dsh-0.1.7-rc.2`，`skipping profile bundle` 与 `disabling profile plugin` 均 **0 行** |
+| 无 live Agent 会话的真机验证 | 完成：`ROLE_BOUND` 事件记 `session_evidence=DURABLE_SESSION`（无 live Agent 的会话被接受）；不存在的 session id 仍被 `SESSION_ABSENT` 拒绝且零写入 |
+
+**未执行（NOT_RUN）**：真实浏览器人工交互验收；DSH 0.1.7 下**全部 14 条 bundle 的真实 boot**（只做了
+`--dump-config` dry-run 与行级门禁的离线复算）；其它第三方插件在 0.1.7 下的业务功能正确性；Linux 平台；
+收益与成本测量。未运行过的项不得当作已通过。本版发布前的独立审查结论与 Owner 验收记录见发布回执（不在包内）。
+
+## 1. DSH peer 兼容范围放宽
+
+- 旧：`@deepseek-ai/dsh-commands` / `dsh-llm` / `dsh-tools` = `>=0.1.5-rc.1 <0.1.5`，
+  `dsh-token-meter` = `>=0.1.5-rc.2 <0.1.5`。
+- 新：两条版本线并列 `>=0.1.5-rc.1 <0.1.6-0 || >=0.1.7-0 <0.1.8-0`
+  （`dsh-token-meter` 下界为 `0.1.5-rc.2`）。`package-lock.json` 的 peer 快照同步。
+- **为什么必须分线写**：在 semver 的 prerelease 规则下，`>=0.1.5-rc.1 <0.2.0` 并**不包含**
+  `0.1.7-rc.2`（只包含 0.1.5-rc 线与 0.1.8 稳定版）。分线写法是唯一能同时表达"已验证的
+  0.1.5-rc 线"与"目标 0.1.7 线"且不误收未测版本的形式。
+- **为什么必须改**：DSH `0.1.7-rc.2` 的 `@deepseek-ai/dsh-app-boot` 新增插件兼容性预检
+  （`evaluatePluginCompatibility`，`lib/index.js:286-313`）。它只检查 `@deepseek-ai/dsh` 与
+  `@deepseek-ai/dsh-*`，判据是 `semver.satisfies(runtime, range, { includePrerelease: true })`；
+  `loadProfileDirectory`（`:919-955`）对 `dsh.profile.bundles` 中每个 bundle 判定，不通过且未豁免
+  即抛出 → 收进 `skippedBundles` → **该 bundle 整层不加载**。症状是启动不报错，只在 stderr 留
+  一行 skip 警告，而工具、`/kingdom` 命令与 GUI 会一起消失。
+- **只改声明不够**：预检读取的是**已安装副本**的 `package.json`。必须重新打包并重装该 profile，
+  否则升级后仍然是旧的 `<0.1.5` 声明。
+- 未改 `@deepseek-ai/cordis`（`>=4.0.0-rc <5`）与 `@deepseek-ai/schemastery`（`^3.18.0`）：它们
+  不在预检集合内，且 0.1.7-rc.2 携带的 4.0.4 / 3.18.4 均落在范围内。
+
+## 2. 无 live Agent 的会话现在可以绑定席位
+
+- **症状**：对一个刚创建、尚未产生任何消息的会话执行
+  `/kingdom role.bind {"role_type":"SUPERVISOR",…,"session_id":"…"}` 会得到
+  `INPUT_DENIED [SESSION_ABSENT]`，于是无法预先设置主管席位。
+- **原因**：目标会话校验只接受 live Agent（`agents.get(session_id)` 返回同一条 Agent，且状态为
+  `idle` 或 `running`）。DSH 的 Agent 一旦被回收就会移出注册表（`AgentStatus` 本身只有
+  `idle | running`，disposal 不是第三种状态），此后该 session_id 再也过不了校验。
+- **现行为**（`resolveDirectTargetSession`）：
+  1. live Agent 命中 → 放行，事件记 `session_evidence: "LIVE_AGENT"`；
+  2. 仅当分类为 `ABSENT`（注册表里没有这条 live Agent）时，回退到"该 session_id 已在本机 DSH
+     持久会话存储中登记"的存在性证明（`ctx.sessionQuery.observeSession`，只用 header 做身份比对，
+     观察租约用完即释放）→ 放行，事件记 `session_evidence: "DURABLE_SESSION"`；
+  3. 两条路都证明不了 → 仍然拒绝，**零写入**。
+- **没有放宽的部分**：`FOREIGN` / `MULTIPLE` / `EXPIRED` / `UNKNOWN` 一律保持 fail-closed，不因
+  "可能是它"而放行；调用者身份校验（`resolveTrustedToolSession`）未改动，仍要求 live Agent；
+  宿主未挂载 `sessionQuery` 时退化为原行为（拒绝并说明缺少观察通道）。Owner 管理窗口的目标会话
+  校验与列表使用同一解析器，行为一致。
+- **语义边界**：`DURABLE_SESSION` 只说明"这条会话属于本机 DSH"，**不说明它当前可执行**。席位在
+  该会话真正启动前不能派发或复核；这条证据强度差异会记进 `ROLE_BOUND` /
+  `BINDING_PROFILE_UPDATED` 事件的 `session_evidence` 字段，供审计区分。
+
+## 3. 与本机现状的关系
+
+本文件描述 3.1.0 候选。截至 2026-09-28：本机 `web` profile 已于 11:43 重装为 `dsh-kingdom-3.1.0`
+（依赖指向 `dsh-kingdom-3.1.0.tgz`），运行宿主自 11:48 起为 DSH `0.1.7-rc.2`，且未出现任何 bundle 跳过。
+回退路径：保留的 `dsh-kingdom-3.0.0.tgz`、profile 三件套备份、会话与 storages 全量副本、王国库一致性
+副本，以及 `rollback-to-015.ps1`。

package/docs/V3.2-RELEASE-NOTES.md

@@ -0,0 +1,103 @@
+# dsh-Kingdom 3.2.0 本地候选说明
+
+3.2.0 只有两类产品变更：**主管与领地的完全绑定**（任命时必须同时指定领地、一个主管只主理一个
+领地，席位与主理同一事务原子写入；退任时同时解除主理）与**交付区版面修复**（控制区不再抢宽导致
+正文退化成竖排）。没有新增表、没有新增迁移，沿用 schema v4 与既有事件类型。
+
+## 验证状态（本轮实际执行过的）
+
+| 项 | 结果 |
+|---|---|
+| `npm run typecheck`（`tsc -p tsconfig.json --noEmit`） | 通过，0 错误 |
+| 全量 `node --test tests/*.test.ts` | 594 项：**592 通过 / 0 失败 / 2 跳过**（2 项在 Windows 上跳过：1 项是 `process.platform === 'win32'` 的平台门，1 项是宿主无法创建符号链接时的运行时跳过） |
+| 新增定向用例 `tests/v320-supervisor-territory-binding.test.ts` | 6/6 通过（AC1–AC5 + 事务嵌套） |
+| `scripts/p2-smoke.mjs` | 36/36 通过 |
+| `scripts/p3-smoke.mjs` | 19/19 通过 |
+| `scripts/hotplug-audit.mjs` | 26/26 通过 |
+
+**未执行（NOT_RUN）**：发布门 `scripts/release.ps1 -DryRun`（须在干净工作区、冻结提交后运行）；
+真实浏览器人工交互验收（含新版表单在四种主题与窄屏下的实际观感）；把本版 tgz 装进本机
+profile 后的 DSH `0.1.7-rc.2` 实机加载回归；Linux 平台；收益与成本测量。未运行过的项不得当作
+已通过。本版发布前的独立审查结论与 Owner 验收记录见发布回执（不在包内）。
+
+## 1. 主管与领地完全绑定
+
+**问题**：此前"任命主管"与"指定它的领地"是两条独立命令。中途放弃第二步，就会留下一个没有
+领地的在任主管：席位显示已任命，GUI 里那块领地却仍显示"没有主管"，而治理操作按
+`TERRITORY_SUPERVISOR_MISSING` fail-closed。
+
+**现在的规则**（Owner 口径 2026-09-28 + 1:1 裁定 2026-09-29）：
+
+- **任命主管必须同时给出领地**：`role.bind` 的 `role_type=SUPERVISOR` 需要 `territory_id`；
+  缺省即拒绝，不写入任何事实。非主管角色携带 `territory_id` 同样拒绝（不静默忽略）。
+- **同一事务原子写入**：席位与「该领地的主理」一起提交或一起回滚。领地侧被拒时，已经插入的
+  席位随事务回滚，**不会**留下"有主管、没领地"的中间态。
+- **不静默替换在任主理**：目标领地已有**在任 ACTIVE** 主理时，改派被拒绝并提示先解除；
+  解除（`supervisor_binding_id: null`）后再指派。指向**已退任席位**的历史悬挂引用属于修复，
+  可以直接改派（direct Slash 与 Owner GUI 窗口是同一条判据）。
+- **一个主管席位只主理一个领地（1:1）**：席位已隶属其它未删除领地时，指派被拒绝并提示先解除
+  原领地的主理。要在领地之间移动一个主管，必须"先解除原领地，再指派到新领地"。
+  已被删除（tombstone）的领地不参与治理，其历史指针不锁住席位。
+- **退任联动**：`role.unbind` 退任一个主管时，**同一事务**里解除它在领地上的主理关系并写出一条
+  明确的解除事实（`TERRITORY_SUPERVISOR_UPDATED`，`unassigned: true`），不留下指向 RETIRED
+  席位的悬挂引用。
+- **存量未隶属席位**：3.2.0 之前建立的、没有领地的在任主管**不会被自动归属**。席位投影会给出
+  它实际主理的领地列表，为空时由界面标注「未隶属领地（待处理）」，由 Owner 决定指派或解除。
+  这类遗留席位同样受 1:1 约束（已经主理某领地的席位不会被自动改派）。
+
+命令与界面：
+
+```
+/kingdom role.bind {"role_type":"SUPERVISOR","role_name":"主理","territory_id":"<领地 id>","session_id":"<真实 DSH session>"}
+/kingdom role.bind {"role_type":"WORKER","role_name":"执行者"}                 # 非主管不带 territory_id
+/kingdom territory.supervisor {"territory_id":"...","supervisor_binding_id":null}   # 解除该领地主理
+/kingdom role.unbind {"binding_id":"<主管 binding id>","reason":"换届"}        # 同时解除其领地主理
+```
+
+Owner GUI 管理窗口的 `role.bind` 表单在角色为主管时出现**必选**领地下拉（内容来自本次授权范围
+目录），其它角色隐藏该字段；`kingdom_draft_owner_binding_intent` 的自然语言草案对主管改为
+**单步**可执行命令（`role.bind` 自带 `territory_id`），不再是旧的两步。
+
+**领地范围判据**：主管任命的目标领地必须**显式**出现在本次管理窗口的授权范围内
+（`catalog.territories` 与提交判定完全一致，不用 `kingdomWide` 放宽）。若要在窗口里给新建的
+领地任命主管，请重新激活一个包含该领地的窗口。
+
+**管理窗口现在也能解除主理**：`territory.supervisor` 的 `supervisor_binding_id` 接受**显式 `null`**
+（表单上是"解除现任主理（不指派新主管）"勾选框；省略该字段仍是输入错误，不会被当成解除）。
+因此 1:1 之下"把主理从领地 A 换到领地 B"可以完全在窗口里完成：先在 A 上解除、再到 B 上指派。
+解除同样受未结算执行守卫约束（有在途工作时不允许解除责任），预览会写清"解除后该领地无主理 →
+fail-closed 直到指派新的"。
+
+**存量数据的说明**：3.2.0 之前可能留下两类与上面规则不符的存量——① 没有隶属领地的在任主管席位；
+② 一个席位同时挂在多个领地（旧能力允许）。本版**不会自动收敛**它们：① 只作可见标注，② 只约束
+**新的**指派。两者在退任时都会被一并解除（退任联动遍历该席位名下的所有未删除领地）。
+
+**事务嵌套**：直接 Slash 的 `ownerWrite` 与 Owner GUI 窗口的 `apply` 各自已经开了一层事务，
+而这条原子通道还要求自己的边界。`KingdomStore.withImmediateTransaction` 因此改为真正的嵌套：
+外层 `BEGIN IMMEDIATE`/`COMMIT`/`ROLLBACK`，内层 `SAVEPOINT`/`RELEASE`/`ROLLBACK TO`。
+只做"加入外层"是不够的——内层把拒绝变成返回文案时，它已写下的行会留在外层事务里被提交。
+`schema`、表结构与事件类型均未改动。
+
+**边界**：`bindRole()` 仍是低层原语，本身不承载"主管必须有领地"这条策略；策略在全部 Owner 入口
+（direct Slash、Owner GUI 窗口、GUI 表单）强制执行，并统一由 `bindSupervisorForTerritory` 完成
+原子写入。这样既保证产品层面不存在"有主管、没领地"的创建路径，又不改动只用于构造测试夹具的
+低层调用。Agent Tool（`kingdom_bind_role` 等）依旧是 zero-write。
+
+**未结算执行的拦截范围（3.2.0 审计 r1 更正）**：`UNSETTLED_EXECUTION` / `UNSETTLED_LEASE` /
+`UNSETTLED_DISPATCH` 守卫只覆盖 **Owner 管理窗口**这条路径（`guardUnsettled`）。direct Slash 与
+core 的 `role.bind` / `territory.supervisor` **没有**等价守卫——这是 3.1.0 的既有语义，本版没有
+改动它，文档也不得声称"旧主管的未结算执行一定会拦住改派"。需要该守卫时请走 Owner 管理窗口。
+
+## 2. 交付区版面修复
+
+交付条目的控制区里有一条 `flex: 1 0 100%` 的状态文本，而它在 `grid-template-columns:
+minmax(0, 1fr) auto` 的右列（`auto` = max-content）里。右轨被撑到最宽，左轨被压成 0 宽，
+正文因此退化成每行一两个字、竖排显示。现在改成分行 flex：正文占弹性主列（20rem 起），
+控制区按自身内容窄排，放不下时整体换行。这是纯 CSS 改动，不改变任何数据、事件或判断。
+交付条目里显示的 `UNKNOWN` 是**数据**（v1.0.0 旧格式的弱接受证据），产品按设计不推断。
+
+## 不适用范围
+
+- 不改 schema，不新增迁移；不改 Owner Control Plane 的授权模型。
+- 不改 `resolveTrustedToolSession`，不改 3.1.0 的 peer 分线声明。
+- 不处理 3.1.0 审计遗留的文档残留（另行处理）。