# 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)。