dsh-kingdom 3.2.0 → 3.3.0

package/docs/CURRENT-USER-GUIDE.md

@@ -0,0 +1,106 @@
+# dsh-Kingdom 3.3.0 使用指南
+
+日常只用三个入口：**运行总览、派发任务、主管设置**。也可以直接向 DSH 会话里的 AI 说需求，让它调用已开放的工具。
+
+本指南对应 3.3.0。安装要求见 [README](../README.md#-快速开始)；正式下载入口为 [npm 3.3.0](https://www.npmjs.com/package/dsh-kingdom/v/3.3.0) 与 [GitHub v3.3.0](https://github.com/lusblead/dsh-Kingdom/releases/tag/v3.3.0)。通过官方 npm 下载并安装到 Web profile：
+
+```bash
+npm pack dsh-kingdom@3.3.0 --registry=https://registry.npmjs.org
+dsh plugin --profile web add ./dsh-kingdom-3.3.0.tgz
+```
+
+安装或升级后重启原 DSH profile；使用其他 profile 时替换 `web`。已安装 3.2.1 的用户升级到 3.3.0 后可使用这三个入口，原版派发和恢复修复见 [3.2.1 说明](V3.2.1-RELEASE-NOTES.md)。
+
+## 第一次使用
+
+先在一个可用的 DSH 会话中说：
+
+> 帮我查看 dsh-Kingdom 当前的王国、领地、角色和任务。我要把当前项目交给它管理；先说明缺少哪些配置，再逐项引导我确认。
+
+已有王国和领地就继续使用。尚未初始化时，由人类在 DSH 的直接命令入口执行 `/kingdom init`。创建领地、登记执行者、模型配置和允许使用的能力，仍需经过现有的人类管理入口；让 AI 根据实际情况说明步骤和准备准确输入，不需要自己查内部编号。
+
+准备一个负责统筹的会话和一个负责具体领地的主管会话。角色来自真实会话绑定，在网页里选择名称不会切换角色权限。宰相创建任务，主管指派、启动和审查任务；执行者的长期会话由执行流程建立，不需要提前手工创建。
+
+在统筹会话中说：
+
+> 把当前会话设为宰相，并引导我完成确认。
+
+在希望担任主管的会话中说：
+
+> 把当前会话设为「前端」的主管，并引导我完成确认。
+
+将「前端」替换为工作台里真实、完整的领地名称。现有会话绑定引导覆盖宰相、主管任命与会话接替；其他首次配置仍使用原有管理流程，不能把这两句话理解成已完成全部初始化。
+
+## 绑定或更换主管
+
+在工作台的**主管设置**中查看各领地的主管和脱敏会话标识。点击“复制绑定主管请求”或“复制更换主管请求”，到你希望负责该领地的 DSH 会话发给 AI。
+
+也可以直接说：
+
+> 让当前会话负责「前端」。
+
+> 把「前端」主管换成当前会话。
+
+AI 会用当前真实会话与王国数据准备操作，并返回步骤和完整的人类管理窗口命令。你按以下顺序操作：
+
+1. 将 AI 提供的完整命令直接放到**当前 DSH 会话的命令入口**执行一次，不修改其中字段。
+2. 打开返回的管理链接。窗口预选本次目标；核对领地、角色与目标会话，点击“查看变更预览”。
+3. 预览正确后点击“确认应用此变更”。这一步才写入绑定；只复制请求、生成命令或打开页面都不会更换主管。
+4. 成功后让 AI 重新查看当前绑定，或回到主管设置重新读取，确认目标领地对应新的脱敏会话。
+
+更换主管采用接替现有席位的方式，保留该席位与任务历史。如果同一席位负责多个领地，引导和管理窗口会列出全部受影响领地；确认后它们会一起由新会话负责。只想更换一个领地时，先停止确认，让会话说明如何调整主管安排。若领地名称不唯一、当前会话无法确认、绑定已变化，或存在未结算工作，按 AI 或窗口提示先核对；不要自行解除主管来绕过阻止。
+
+这条路径让 AI 准备准确目标和输入。你只需说明负责哪个领地、核对预览并确认，不需要学习角色编号、会话编号或编辑 JSON。人类确认仍由你完成，AI 不能代替。
+
+## 查看任务和会话
+
+在对应 DSH 会话的直接命令入口执行 `/kingdom gui`，按宿主提供的链接打开工作台。默认进入**运行总览**。
+
+| 列表 | 看什么 |
+|---|---|
+| 任务 | 任务名称、领地、执行者、任务状态、本次执行状态；点击任务名称查看详情 |
+| 会话 | 当前登记角色、脱敏会话标识、领地、关联任务、已提供的执行观察 |
+
+任务状态和执行状态分别显示。例如，任务仍在处理中，但本次执行已经结束，可能需要主管审查、返工或核对恢复结果。
+
+| 任务状态 | 下一步 |
+|---|---|
+| 已创建 `CREATED` | 主管指定执行者 |
+| 已分配 `ASSIGNED` | 主管核对本次权限后启动 |
+| 处理中 `RUNNING` | 看本次执行记录；返工决定本身不会自动启动下一次执行 |
+| 待审 `REVIEW` | 主管检查执行者结果，再接受、返工或判定失败 |
+| 完成 `DONE` | 主管已接受；人类可继续查看交付，不等于人类最终验收 |
+| 失败 `FAILED` | 查看失败原因，由主管说明后续安排 |
+
+会话表只展示王国已登记角色与当前 Worker 长期会话，不是 DSH 的全部会话。**已登记、关联任务和执行记录，都不等于模型此刻正在生成。**主管职责范围内有运行任务时，若没有该会话的模型运行观测，仍显示未知。缺少观测不会当成闲置或已结束。
+
+待处理、异常和最近交付在首页折叠区。地图、用量、账本等可从主管设置的高级记录进入。
+
+## 派发一条任务
+
+先在宰相会话中说清目标、领地和验收。例如：
+
+> 在「前端」创建任务：修复登录页的窄屏布局。范围是登录页；验收是 390 像素宽度下没有横向滚动、按钮可以操作。先核对草稿，再创建。
+
+宰相只能在已有领地创建任务，不能替主管启动。需要网页操作时，从宰相会话打开 `/kingdom gui`，进入**派发任务**，填写任务、范围、验收条件与领地，再点击“创建任务”。一句话输入只帮助填入草稿，不调用模型规划，也不会直接派发。
+
+随后到该领地的主管会话说：
+
+> 查看「修复登录页的窄屏布局」这项任务，为它指定可用执行者，核对本次所需能力后启动；结果回来后检查验收条件并给出审查结论。
+
+也可从主管会话重新打开 `/kingdom gui`，在派发任务页完成“指定执行者”和“启动执行”。界面使用宿主允许的模式和能力；无法满足任务需要时，先让主管说明缺少什么。任命主管不会自动授予额外执行权限。
+
+任务开始后，在运行总览查看进展。执行者提交结果会进入待审；主管接受后才变成完成。查看具体任务的详情，可以读取呈报和历史，并进入当前会话有权限的审查或恢复操作。
+
+## 遇到提示时
+
+| 提示或现象 | 怎么处理 |
+|---|---|
+| 创建任务或启动按钮不可用 | 让当前会话的 AI 说明原因；创建任务使用宰相会话，指派、启动和审查使用任务领地的主管会话，然后从该会话重新打开工作台 |
+| 主管还没绑定，或想改由新会话负责 | 在主管设置复制请求，到目标会话交给 AI 引导确认 |
+| 能力检查被拒绝 | 让主管核对任务要求、现有允许能力和运行配置；任命主管本身不会解决能力限制 |
+| 工作区被占用 | 等前序任务结算后重新请求；系统不会自动把本项加入队列 |
+| 恢复核对 `RECOVERING` | 让主管核对原执行；不要重复启动。跨重启的只读观察不自动生成执行回执或完成事实 |
+| 提交结果不明或页面断开 | 先重新读取并核对事实，再决定下一步；不要反复点击写入按钮 |
+
+当前流程需要会话按需读取、启动和审查，不承诺无人值守自动推进。发布与实际验证范围见 [3.3 版本说明](V3.3-RELEASE-NOTES.md)；功能回归通过不等于陌生用户能独立上手，真人上手验收仍未运行。

package/docs/DISPATCH-IDENTITY-PROBE.md

@@ -0,0 +1,79 @@
+# Dispatch identity probe — 2026-10-13
+
+## 偏移与关键问题（必须首先阅读）
+
+- 设计偏移：NONE；Core 保留 opaque Runtime 引用，Adapter 不取得治理权限。
+- 最重要问题：持久化输入是正证据；缺少输入仍是 UNKNOWN，不能据此作废、释放 Lease 或重发。
+- 未通过状态：Provider、真实 enforcement、terminal、冷 cleanup、安全作废和子目录写根均 NOT_RUN / UNKNOWN。
+- 需要 Owner 裁决：NO；本探针验证关联与只读观察，不增加处置权限。
+
+## 官方版本和复用选择
+
+探针对调用方明确指定的已安装官方包读取各自 package.json。上一轮读取的 `dsh-agent`、`dsh-agent-loop`、`dsh-session`、`dsh-session-persistence-jsonl` 等组件均为 `0.1.5-rc.2`；安装目录名称不是组件版本。每次报告记录当前实际版本，结论仅对所列版本和该次明确指定的产品编译目录成立。
+
+复用官方 Agent Registry、公开 maintenance / followup、`sessions.flush` 和 JSONL persistence handle，不复制 Runtime 存储、不新增上游 metadata。官方包采用 MIT 许可证；本轮没有新增产品依赖或 Provider 插件。Adapter 延续结构型完整 UserMessage，通过 Node UUID 和深层 Object.freeze 在调用前冻结消息；没有调用官方 `MessageId` / `freezeMessage` 构造器，不将这两个 API 写为实测链。真实 rc.2 followup 接受该完整消息仍须由产品探针证明。
+
+匹配版本依据为安装包 `dsh-agent/README.md`、`dsh-session/README.md` 及其 `lib/types/index.d.ts`，`dsh-session-persistence/README.md` 及 `lib/types/handle.d.ts`，`dsh-session-persistence-jsonl/README.md`。公开说明和类型明确：
+
+- `followup` 是 next-turn 入队并唤醒 driver，不是 terminal 或持久化 Receipt。
+- `sessions.flush(session): Promise<boolean>` 在所有 durability listener 结束后返回；`true` 表示至少一个 listener 参与，`false` 表示没有 listener。`false` 不是“证明未派发”；也不是可靠接受。本探针装配官方 JSONL listener。
+- persistence `open(id, 'read') / read(offset, length) / close()` 允许不 resume 的公开只读事件读取；read 的默认全量行为没有被产品 reconcile 使用。
+- maintenance 预留真实 driver 的活动区间。本探针在该区间持有 reservation 到强杀，阻止模型轮次启动。
+
+## 第二轮产品路径与证据边界
+
+脚本：`scripts/e2e/dsh-dispatch-id-probe.mjs`。两个 case 都直接经过本轮编译的产品 Adapter 与 Core：
+
+1. 真实 `DshRuntimeAdapter.createSession` 创建独立 Session；公开 maintenance 保持 driver 暂停。
+2. 产品 `prepareDispatch` 冻结消息和单次 opaque token；此时未调用 followup。
+3. 真实 Core `prepareGovernedDispatch` 完成 TX-3，将 Kingdom dispatch ID 和 planned Runtime ref 持久化到 `INTENDED`。它们与 Receipt、terminal 和治理事实明确分开。
+4. `SENT_AFTER_FLUSH`：调用真实产品 `Adapter.dispatch`，仅在公开 flush 返回 true 后得到 Runtime Receipt；强杀 writer 前刻意不记录 Core Receipt。
+5. `COMMIT_BEFORE_SEND`：TX-3 后不发送输入，直接强杀 writer；只对空 Session 完成一次 baseline flush，确保 reader 能读取。baseline flush 不是派发接受。
+6. 两 case 启动全新 reader PID，只加载 session + persistence 服务，不 resume、不创建 Agent、不启模型。fresh 产品 Adapter 用真实已持久化 Core ref 调用 `.reconcile`；另用有界公开 read 交叉检查精确 inbox ref 数和 `turn/start` 数。
+7. 断言正例为 `QUEUED / located=true`，未发送例为 `UNKNOWN / located=false`。均要求 Core 行/事件不变、Receipt 缺失、Lease 仍 EXECUTING、Execution 仍 STARTING、Task 仍 ASSIGNED、Claim 为0、模型 turn 为0。
+
+权威、Binding、Capability Decision 和 cleanup plan 是显式直接写入隔离测试账本的 **FAKE_PREREQUISITES**；本探针只证明产品准备、Core TX-3、真实 DSH 派发耐久性和冷只读关联。它不是全受治理端到端、真实 sandbox/enforcement、Provider 成功、任务终态或最终验收证明。
+
+运行方式：
+
+```text
+node scripts/e2e/dsh-dispatch-id-probe.mjs <installed-runtime-root> <isolated-output-root> <current-compiled-product-lib-root>
+```
+
+第三参数也可由 `KINGDOM_DISPATCH_ID_PROBE_LIB_ROOT` 显式提供；未提供则在启动 Runtime / 创建目录前拒绝。脚本不会默认为仓库旧 `lib`，不能用旧编译输出证明新源码。调用方负责先把当前源码编译到独立 stage；探针不执行构建。
+
+脚本仅终止本次 fork 创建的子进程。每次创建随机名测试子目录，Session JSONL、测试 kernel DB 只留在指定的 ignored 本地输出目录。报告保存有界状态、版本和比较结果，不输出原始会话、消息文本、绝对个人路径或 exact Session/message ref。报告输出 `dispatch-id-probe-report.json`；此报告及测试账本不能进入发布包。
+
+`tests/dsh-dispatch-id-probe.test.mjs` 的4项失败路径检查验证：不得隐式沿用旧lib、缺失输入不得提升为 QUEUED、turn/Claim/DONE/Receipt/release不得假造、正常退出/同PID不得冒充强杀和新进程读取。它们不是 Runtime 探针证据。
+
+## 3.2.1 发布移植的版本核对
+
+派发关联改动从第二轮整改基线形成有限 delta，移入 `3.2.0` 发布源码；不会用旧开发树覆盖 3.0—3.2 的功能。下列静态核对只说明公开接口匹配，不继承旧编译或旧运行的 PASS：
+
+- 已读取安装的 `0.1.7-rc.2` 官方组件 README、package.json 和公开类型：`dsh-session`、`dsh-agent`、`dsh-session-persistence` 与 JSONL backend。这些组件均声明 MIT 许可证。
+- `sessions.flush(session): Promise<boolean>`、完整 UserMessage `followup` 和 persistence `open(id, 'read') / read(offset, length) / close()` 的本轮调用形状与 `0.1.5-rc.2` 一致；`read` 返回 `{ eventState, events }`，产品读取 `events`，不假定数组返回。
+- `0.1.7-rc.2` 的 Session README 与类型已将 `snapshotEvents`、`eventAt`、`ownEvents` 标记 deprecated，仍保留公开方法，并允许既有逻辑暂不迁移。本插件 live 观测继续依赖这一公开兼容面；本轮不改造既有 warm fence、cleanup 或 Runtime 投影。冷 persistence 观察使用公开异步 read handle。
+- 每个目标 Runtime 版本都必须用本次发布源码的明确编译目录重新跑产品探针。真实结果在运行后单独记录；只有类型检查或 probe 断言测试通过时，Runtime 能力仍为 `NOT_RUN / UNKNOWN`。
+
+## 结果记录
+
+- 3.2.1 发布基线：本轮当前源码构建分别对实际官方0.1.5-rc.2和0.1.7-rc.2运行v2产品探针，四个case全部PASS。两条线均为SENT_AFTER_FLUSH输入1条/QUEUED、COMMIT_BEFORE_SEND输入0条/UNKNOWN，fresh reader读取前后Core不变、Provider和模型turn均0。该结果不外推完整治理或安全作废。
+
+- 上一轮 v1：仅 Runtime 构造器 + followup + flush + 新 persistence reader，PASS；不代表本轮产品路径。
+- 整改开发树 v2（发布移植前）：2026-10-13 本机 PASS，使用当时整改源码的独立编译 stage。所有装配的 DSH 组件实际为 `0.1.5-rc.2`；没有加载 Provider 插件。这不是 `3.2.1` 发布源码的实测结果。
+
+| Case | 真 writer 强杀 / 新 reader PID | 持久化精确输入 | fresh Adapter observation | Core Receipt / Lease / Task / Claim | 模型 turn |
+|---|---|---|---|---|---|
+| SENT_AFTER_FLUSH | SIGKILL / YES | 1条；与 TX-3 planned ref 相同 | QUEUED，PERSISTED，complete=true | 无 / EXECUTING / ASSIGNED / 0 | 0 |
+| COMMIT_BEFORE_SEND | SIGKILL / YES | 0条；planned ref 已存在 | UNKNOWN，PERSISTED，complete=true | 无 / EXECUTING / ASSIGNED / 0 | 0 |
+
+两例均在 SEND 前确认 Core 已存 Kingdom ID 与 planned ref；reader observation 返回同一 ID/ref；Reader 对账前后隔离 Core 行和事件计数不变。实际报告在本地 ignored `dispatch-correlation-dev/probe/dispatch-id-probe-report.json`，不将本轮 PASS 外推到其他编译、版本或 backend。
+
+## 不能推导的结论
+
+- 未 flush、flush=false、throw 或超时均不能据此证明未派发。产品 prepared token 在第一次 side effect 前消耗；不确定时不能复用该 token 重发。
+- `flush=true` 仅在当前公开 listener 与 backend 成功完成前提下支持持久化接受；不能外推到任意 backend 的 durability 实现。
+- 找不到 ID 不证明未出境；查询完整性、原发送方失效屏障、迟发/未落盘输入和 enforcement cleanup 仍须单独证明。
+- 持久 inbox 中排队消息可能在未来 resume 时执行。当前 turn 为0不证明未派发或安全作废。
+- 只读恢复观察不重建原 Fence/cleanup context、不补写 Receipt、不 settle/release、不发 Claim、不推进 Task DONE。
+- 强杀仅针对本探针拥有的 writer，不能授权终止其他产品 Session 或进程。

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

@@ -1,103 +1,108 @@
-# 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 审计遗留的文档残留（另行处理）。
+# dsh-Kingdom 3.2.0 本地候选说明
+
+3.2.0 只有两类产品变更：**主管与领地的完全绑定**（任命时必须同时指定领地、一个主管只主理一个
+领地，席位与主理同一事务原子写入；退任时同时解除主理）与**交付区版面修复**（控制区不再抢宽导致
+正文退化成竖排）。没有新增表、没有新增迁移，沿用 schema v4 与既有事件类型。
+
+## 验证状态（本轮实际执行过的）
+
+| 项 | 结果 |
+|---|---|
+| `npm run typecheck`（`tsc -p tsconfig.json --noEmit`） | 通过，0 错误 |
+| 全量 `node --test tests/*.test.ts` | 596 项：**594 通过 / 0 失败 / 2 跳过**（2 项在 Windows 上跳过：1 项是 `process.platform === 'win32'` 的平台门，1 项是宿主无法创建符号链接时的运行时跳过） |
+| 新增定向用例 `tests/v320-supervisor-territory-binding.test.ts` | 6/6 通过（AC1–AC5 + 事务嵌套） |
+| `tests/owner-window.test.ts` | 28/28 通过（含"窗口解除主理"与"缺字段/范围外拒绝"两个新用例） |
+| `scripts/p2-smoke.mjs` | 36/36 通过 |
+| `scripts/p3-smoke.mjs` | 19/19 通过 |
+| `scripts/hotplug-audit.mjs` | 26/26 通过 |
+| 发布门 `pwsh -File scripts/release.ps1 -Version 3.2.0 -DryRun` | **P0–P3 全 PASS**（在提交 `075e410` 后的干净工作树运行；P3 产出 `dsh-kingdom-3.2.0.tgz`，722 669 字节，SHA-256 `6d40dc00d3457b223850f66cfa5a3ed0f2c42588d9e2042037607147ec7e3053`） |
+| GitHub Actions（push 到 `main`，ubuntu-latest / Node 24） | 成功（typecheck + 全量测试 + 三个 smoke + `npm pack --dry-run`） |
+| 独立审查 | `AUDIT_PASS`（AC1–AC7 全 PASS；AC8 的发布门在提交后补跑通过）。审查只读，未改动候选 |
+| npm | `dsh-kingdom@3.2.0` 已发布（`latest`），shasum `0bc97ac894519774a4aaf773bdc343a6aa74a946`；从 registry 取回的 tgz 与上面冻结的 tgz **字节一致** |
+
+**未执行（NOT_RUN）**：真实浏览器人工交互验收（新表单的"解除现任主理"勾选框与四种主题/窄屏下的
+实际观感；交付区版面只有"同源 CSS + 同构 DOM"的等效渲染对比）；把本版 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 审计遗留的文档残留（另行处理）。

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

@@ -0,0 +1,39 @@
+# dsh-Kingdom 3.2.1
+
+3.2.1 修复派发、恢复和授权事务中的正确性缺口。它在已发布的3.2.0上合入有限整改，保留主管与领地完全绑定、交付记录、schema v4和既有DSH兼容范围。没有数据库迁移。
+
+## 本版变化
+
+- **派发前保存关联。** 每次派发先生成Kingdom ID，并可由Adapter纯准备一个独立Runtime消息引用。在Runtime入队前，Execution、Lease、Dispatch Intent和计划引用已提交。计划引用不是接受回执。
+- **可靠Receipt经过持久化屏障。** DSH prepared消息和单次token绑定Adapter、Session、文本与两端引用。只有公开` sessions.flush `返回true才返回可靠Receipt。缺失、false、异常或超时不会触发重发；同一token不能再次入队。Receipt必须匹配已提交的Runtime/instance/Session/ref。
+- **丢回执或原上下文后可只读对账。** 当前主管可通过Tool或GUI查询同一计划引用。新Adapter只读live或公开持久化事件，不resume、不补Receipt、不建执行权限、不生成Claim、不清理或释放Lease。读取最多10000事件，每次持久化操作最多5000ms；读取前后重验授权及关键账本关系。
+- **收紧事务授权。** 受理及派发事务内重新验证原调用者；ACCEPT重新确认主管绑定和Task领地，使用条件状态更新，变化时整体拒绝或回滚。3.2的交付改动证据与SAVEPOINT嵌套事务保持有效。
+- **明确资源占用。** 占用提示提供有界、脱敏的执行/租约引用，并要求前序结束或对账后重新请求；没有自动排队。
+- **计划引用不计作已接受执行。** 用量入口和事务内持久化都要求精确引用及Receipt。稀疏或损坏事件数组按不可读处理。
+
+## 验证范围
+
+本版新基线在Windows/Node24下执行：
+
+| 验证 | 结果 |
+|---|---|
+| TypeScript typecheck和当前源码构建 | 通过 |
+| 完整TS测试与新增探针契约测试 | 665项：663通过、0失败、2跳过（平台条件） |
+| 隔离governance / GUI / lifecycle smoke | 36 / 19 / 26项全部通过 |
+| 官方0.1.5-rc.2实际组件产品探针 | 两例通过：flush后强杀再读为QUEUED；COMMIT后未发送再读为UNKNOWN |
+| 官方0.1.7-rc.2实际组件产品探针 | 同上两例通过 |
+| 两条线的产品探针数据不变断言 | Core行/事件不变，Receipt缺失，Claim0，模型turn0 |
+
+真实探针经过本版Adapter准备、Core TX-3、DSH入队/flush、owned writer强杀和fresh reader公开只读读取。Authority/Binding/Capability/enforcement前置使用隔离fake fixture，未加载Provider；它证明消息关联与持久化读取，不是完整受治理模型执行。Requested model为null，effective model为UNKNOWN。更多API与证据边界见[探针说明](DISPATCH-IDENTITY-PROBE.md)。
+
+本版还覆盖真实子进程提交边界与两个进程竞争同Session Lease；这些SQLite测试的Runtime为明确fake，不把它们当作DSH执行证明。首次全量检查发现的两处旧fixture缺flush和稀疏数组回归已修复，最终结果如上。
+
+## 升级与保留边界
+
+安装准确的`dsh-kingdom-3.2.1.tgz`或从官方npm获取`dsh-kingdom@3.2.1`。升级前核对未决执行并一致备份SQLite；本版不对正式数据库进行自动迁移或作废旧执行。
+
+找到精确输入是正观察；**找不到输入仍为UNKNOWN，不能证明未派发、已停机或可安全重试**。排队输入可能在未来resume时执行。本版没有安全作废按钮、冷启动Fence/cleanup重建、子目录WRITE并发、PostgreSQL或SSE。
+
+0.1.7的公开snapshot兼容读取已deprecated；本版既有兼容面仍使用该API，持久化冷读使用公开handle。未来Runtime版本需要单独验证，不能外推。完整付费Provider、真人GUI验收、任意旧库迁移和生产性能没有在本次发布中执行。
+
+GitHub Release与npm的公开版本、资产及integrity是发布状态的核对入口；打包/CI不等于Owner最终验收或Kingdom Task DONE。

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

@@ -0,0 +1,46 @@
+# dsh-Kingdom 3.3.0
+
+3.3.0 将日常工作台集中为**运行总览、派发任务、主管设置**，并让 DSH 会话准备主管绑定或接替的完整确认步骤。普通用户先说要做什么，再核对准确目标；无需手查角色/会话编号或编辑 JSON。本版延续 3.2.1 的派发关联、可靠回执和只读恢复对账，不增加数据库迁移。
+
+正式包入口：[GitHub v3.3.0](https://github.com/lusblead/dsh-Kingdom/releases/tag/v3.3.0) · [npm 3.3.0](https://www.npmjs.com/package/dsh-kingdom/v/3.3.0)。安装和完整操作步骤见 [当前使用指南](CURRENT-USER-GUIDE.md)。
+
+## 本版变化
+
+- **运行总览。** 首页分别显示任务和当前登记会话的领地、角色、关联任务与状态。任务状态、执行记录与模型此刻是否正在生成分别呈现；缺少会话运行观测时显示未知，不把关联任务当作模型正在运行。
+- **集中派发。** 创建任务、指定执行者和启动执行集中在派发入口。宰相会话创建任务，所属领地的主管会话指派、启动和审查；按钮会说明当前权限或前置条件。网页选择角色名称不改变真实会话身份。
+- **会话引导主管设置。** 设置页按领地展示主管，并可复制绑定或更换请求。到希望担任主管的 DSH 会话说“让当前会话负责「前端」”或“把「前端」主管换成当前会话”，AI 用真实上下文准备准确范围的十分钟管理窗口命令。
+- **确认后再读回。** 会话准备不会写入绑定。人类复制完整命令、打开管理链接、核对预览并确认提交，随后重新读取绑定。窗口只预填准确目标；失效、歧义或关系变化不提供旧命令，未结算工作仍由现有守卫阻止。
+- **明确整个席位的影响。** 更换主管会话沿用原席位及任务历史。同一席位如关联多个领地，摘要、步骤与窗口列出全部范围；确认后这些领地会一起由新会话负责。只想更换一个领地应停止确认，不能静默缩小席位变更的影响。
+- **保留高级记录。** 地图、用量、账本、交付与既有详情操作继续可用，日常主导航只呈现三个入口。
+
+## 验证与边界
+
+已通过的开发检查包括 TypeScript 类型检查、构建、隔离回归以及本机 loopback Tool→Owner 窗口预览→显式确认→结果读回。主管引导测试覆盖首次绑定、原席位接替、多领地全范围、关系漂移、失效/外来/歧义拒绝与零写入边界；相关测试和流程契约随源码交付。
+
+这些检查使用隔离数据库及明确的 Runtime/授权 fixture。本机 HTTP 和 DOM double 不代替真实 DSH/Provider 执行，也不证明真人能独立上手。
+
+| 验证项目 | 当前结果 |
+|---|---|
+| 类型检查、构建与隔离回归 | 通过；发布记录核对最终测试结果 |
+| 本机 Tool→Owner 窗口确认与读回 | 通过，Runtime/授权为 fixture |
+| 当前版本真实浏览器交互 | 内置浏览器隔离 fixture：总览/详情/派发选择/主管请求复制通过；四主题与 390px 窄屏检查 |
+| 陌生用户独立上手 | `NOT_RUN` |
+| 完整真实 Provider 受治理执行 | `NOT_RUN` |
+| 正式用户数据库迁移、生产性能 | `NOT_RUN` |
+
+任务 `DONE` 仍表示主管接受，不等于人类最终验收或发布批准。会话身份、领地范围、能力检查和 Owner 人类确认没有被界面便利操作替代。
+
+## 安装与升级
+
+```bash
+npm pack dsh-kingdom@3.3.0 --registry=https://registry.npmjs.org
+dsh plugin --profile web add ./dsh-kingdom-3.3.0.tgz
+```
+
+安装后重启原 DSH profile。升级前核对未决执行，并一致备份 SQLite；WAL 模式不能只复制主数据库。DSH 与 Node 要求见 [README](../README.md#1-前置要求)。本版仅发布 DSH 插件，不包括本地 Codex 候选。
+
+## 保留缺口
+
+首次初始化、创建领地、登记执行者、模型与能力配置仍使用原有的人类管理流程；现有会话引导不能代替完整首次配置。当前也不提供安全作废未派发意图、冷启动权限/Fence 清理重建、子目录 WRITE 并发、自动排队或无人值守自动审查。找不到原派发输入仍是未知，不能据此重复启动。
+
+3.2.1 的修复与两条 DSH 兼容线的历史验证范围保留在 [3.2.1 版本说明](V3.2.1-RELEASE-NOTES.md)，不能直接继承为本版完整模型执行或真人验收结果。