dsh-bailinghub 0.4.0 → 0.6.0

package/docs/MIGRATION_VNEXT.md

@@ -1,6 +1,73 @@
-# Migrate to 0.4.0
+# Migrate to 0.6.0
 
-## From 0.3.0: choose the conversation scope explicitly
+Use [the 0.6.0 paired upgrade guide](UPGRADE_v0.6.0.en.md) / [中文](UPGRADE_v0.6.0.md). Preserve original scopes, events, journals and task bindings. Session tool reuse requires host opt-in. The following sections retain earlier upgrade history.
+
+# Migrate to 0.5.0
+
+## From 0.4.0: add systems without replacing existing authorizations
+
+Version 0.5.0 extends one-system multi-account conversations to different business systems on one
+Hub and audit domain. It adds system descriptions before capability search and optional business
+subject names. The four public plugin fields, existing host scope/archive APIs, permissions and
+business approval rules remain in place.
+
+1. Have the administrator back up and upgrade to Core 0.7.0. Apply only outstanding migrations in
+   order; upgrading from 0.6.1 includes 058/059. The plugin installer does not migrate the Hub.
+2. Finish active business work and retry known pending completions with `/bailinghub sync`.
+   Retain the original DSH home, SDK credentials, real Session events, scope files and archive outbox.
+3. Install and restart DSH:
+
+   ```bash
+   dsh plugin --profile web add dsh-bailinghub@0.5.0
+   ```
+
+   The package installs exact SDK 0.5.0. Do not manually mix in an older SDK or a local file dependency.
+4. Check `/bailinghub doctor` and `/bailinghub connections list`. Valid existing authorizations
+   continue working; no new login is needed just for a version change or a display rename.
+5. Add and authorize only the extra systems needed for the new task. In a new conversation, select
+   their fixed connection keys and wait for `/bailinghub scope` to confirm before sending a message.
+6. Test an inventory read and a low-risk shop action with confirmed product mappings. Check each
+   target, separate result/approval, and original run link. Then check `/bailinghub archive status`.
+
+Existing started v1 conversations keep their exact original scope and archive identity. The upgrade
+never expands them to every account or converts them to a cross-system selection. A saved unstarted
+draft requires confirmation; a started conversation whose scope cannot be restored stays blocked.
+The same-runtime offline recovery rules continue to use the complete original group.
+
+Custom hosts keep `setSessionScope`, `getSessionScope`, `restoreSessionScope`,
+`getSessionArchiveStatus` and `syncSessionArchive`. Custom stores must preserve complete scope/outbox
+v2 records, original bindings, events, acknowledgement positions and CAS revisions. Hosts may show
+current `subjectDisplay` fields and omit a manual display-name input, but keep internal connection
+selectors/keys separate; do not rebuild authorization or archive state to update a name. Missing
+names stay explicit. Administrator-maintained system descriptions are separate from subject names
+and do not grant tools or permissions.
+
+### 0.4 用户升级摘要
+
+管理员先备份并升级 Core 0.7.0，按顺序仅执行未完成迁移（从 0.6.1 升级包括 058/059）。用户先
+结束当前业务任务，用 `/bailinghub sync` 重试待同步结尾，安装 `dsh-bailinghub@0.5.0` 并重启。
+插件自动安装 SDK 0.5.0。保留原凭据、真实 Session 事件及范围/待传文件；有效授权不因升级或改名重建。
+
+已有同系统会话范围保持不变。要把商城与库存一起使用，分别授权，另开会话，在首消息前选中固定
+连接键并等确认。先验证库存查询与一个低风险商城动作，核对各自结果、原审批和执行关联。
+自定义宿主保留原五个接口；自定义存储需完整保存 v2 的原绑定、事件、确认进度与修订号。名称
+只用于展示，不能替代连接键、身份或系统说明。详情见[本次更新](RELEASE_NOTES_v0.5.0.md#简体中文)。
+
+### Downgrading from 0.5 to 0.4
+
+Finish active work and synchronize pending completions and archives first. Keep the original profile
+and v2 files as recovery material. Version 0.4.0 does not understand cross-system v2 scope/outbox or
+provide this release's system/subject metadata. Do not reinterpret v2 as v1, delete it, or reconstruct
+it from the current registry. Use a separate profile with new same-system conversations if reverting.
+An application downgrade does not undo an accepted business action or remove its Hub audit. Core
+database rollback follows Core's own migration guide; never drop new columns as a plugin rollback.
+
+## Historical 0.3.0 → 0.4.0 behavior
+
+The section below documents the scope change introduced in 0.4.0. When upgrading directly to 0.5.0,
+follow the current install/Core versions above and also preserve these explicit-scope requirements.
+
+### From 0.3.0: choose the conversation scope explicitly
 
 Version 0.4.0 keeps the four public configuration fields and existing SDK-owned authorizations.
 It changes how a conversation gets business access: logging in or selecting a default no longer
@@ -107,7 +174,7 @@ switch account, and select a tenant.
 
 ## Safe evaluation before migration
 
-Do not replace a working production profile merely to evaluate 0.4.0. Use a separate DSH home or
+Do not replace a working production profile merely to evaluate 0.5.0. Use a separate DSH home or
 another isolated Web profile and verify that the CLI really honors that location. The named
 connection lifecycle introduced in `0.3.0` creates a separate credential for each name registered through
 `connections add` while authorization is pending. After authorization, the SDK replaces an older
@@ -117,7 +184,7 @@ alias and Session and receives a non-conflicting alias that becomes current. Use
 SDK installed by the DSH package when evaluating that behavior.
 
 1. Keep the existing `0.1.1` profile and its legacy environment unchanged.
-2. Install the exact released 0.4.0 package into an isolated profile.
+2. Install the exact released 0.5.0 package into an isolated profile.
 3. Configure only the four public native fields using neutral values for dry composition.
 4. Run `/bailinghub login` and approve a dedicated non-production client app/workspace whose
    credential can be revoked without affecting a maintainer's existing profile.
@@ -128,14 +195,14 @@ SDK installed by the DSH package when evaluating that behavior.
 Passing the native path does not prove legacy compatibility, and passing the legacy path does not
 prove the native Agent Client.
 
-## Moving a legacy 0.1 profile to 0.4
+## Moving a legacy 0.1 profile to 0.5
 
 Only after the isolated acceptance passes:
 
 1. Record the exact old plugin, DSH, MCP, and Core versions without copying credentials into the
    migration record.
 2. Finish or cancel outstanding legacy jobs. A wait timeout is not a terminal failure.
-3. Install the exact accepted 0.4.0 plugin version. Do not use an unpinned dist-tag.
+3. Install the exact accepted 0.5.0 plugin version. Do not use an unpinned dist-tag.
 4. Replace the legacy plugin configuration with the four native fields. Remove the old Client
    Token from that process environment after confirming no remaining 0.1 integration uses it.
 5. Start DSH, run `/bailinghub login`, use the business page to log in or switch account and select
@@ -172,7 +239,7 @@ reuse, move, or republish an npm version or Git tag as a rollback mechanism.
 
 ## Release gates
 
-Before a public 0.4 release:
+Before a public 0.5 release:
 
 1. The matching BailingHub Core Agent Auth/Agent API contracts are released.
 2. The exact `bailinghub-mcp-server/sdk` version is publicly installable and has passed DTO,
@@ -188,3 +255,7 @@ Before a public 0.4 release:
 
 Do not tag or publish a future version until all gates pass, and do not describe release
 validation as public adoption.
+
+## Task-control migration in 0.6.0
+
+The host-only task binding and read-only invocation inspection integration is documented in [TASK_CONTROL.md](./TASK_CONTROL.md). It requires SDK 0.6.0 and Core 0.8.0. Existing journal v1 is read compatibly; subsequent writes use v2 without inferring a task for old entries. Keep scope, task and invocation stores together when reopening, and do not downgrade managed Sessions to an older host. Follow the current paired upgrade guide before enabling task enrollment.

package/docs/PROJECT_BOUNDARIES.md

@@ -24,7 +24,10 @@ community integration, not an official DeepSeek plugin or partnership.
 ## Public native line (0.2.0 onward)
 
 Version 0.2.0 introduced this dependency path; 0.3.0 added the named connection lifecycle.
-Version 0.4.0 adds explicit same-system conversation scope and visible conversation archiving.
+Version 0.4.0 added explicit same-system conversation scope and visible conversation archiving.
+Version 0.5.0 extends selection across systems on one Hub and audit domain, and adds controlled
+system descriptions and business subject display names. These names do not establish identity or
+product mappings, and cross-system selection does not provide durable task orchestration or rollback.
 All remain separate from the public static MCP path:
 
 ```text

package/docs/README.zh-CN.md

@@ -1,17 +1,31 @@
 # BailingHub for DeepSeek Harness
 
+## 0.6.0：长任务、附件与原调用恢复
+
+连续查询、编辑和核对时保留正确目标；上传获准图片后复用URL，重开后核对原调用，任务额度不因换轮重置。配套 Core 0.8.0 / SDK 0.6.0 / DSH 0.6.0；任务启用和跨轮复用需宿主按契约接入。
+
+[本次变化](RELEASE_NOTES_v0.6.0.md) · [升级指南](UPGRADE_v0.6.0.md)
+
+
 [English](../README.md) | 简体中文
 
+
+## 已公开功能
+
 让本地 DeepSeek Harness 智能体操作已经接入 BailingHub 的业务系统：查询记录、修改允许的字段，
 需要审批时继续走原有规则。BailingHub 会记录用了哪份授权、做了什么，以及业务系统返回的结果。
 
-**0.4.0 支持在一个会话中使用同一系统的多份授权。** 例如，分别授权 A 店和 B 店后，新建会话并
-选中两者，就可以说：
+**0.5.0 支持在同一会话中使用同一中枢内不同系统的授权。** 分别授权商城与库存系统，新建会话
+并选中两者，就可以说：
 
-> 对比今天 A 店和 B 店的营业情况，按门店分别说明。
+> 先查保温杯还有多少库存。有货的话，把商城对应商品的售价改为 59 元并上架；没货就先不要上架。
 
-智能体会为每次调用选择对应授权，不需要你反复切换当前连接。具体能查什么、能改什么，仍取决于
-业务系统开放的能力和各账号权限。本版尚不提供不同系统或不同路由之间的编排。
+查库存使用库存系统的授权，改价和上架使用商城授权。前提是业务系统已开放这些能力，商品对应
+关系已确认。查库存不等于锁库存或自动同步库存；改价成功、上架待审批或失败需要分别看实际结果。
+
+0.4.0 的同系统多账户流程继续保留，例如选择 A 店与 B 店对比营业情况，不用切换全局连接。新增
+系统说明让智能体在搜索工具前了解各系统用途；业务提供的名称用于辨认已授权的组织、账户等对象。
+详见[本次变化与升级步骤](RELEASE_NOTES_v0.5.0.md#简体中文)。
 
 本版也能把可见沟通过程与业务操作关联起来。记录上传失败后，可以在联网或重启后继续补传，
 不会因此重新执行业务操作。
@@ -21,41 +35,44 @@
 ## 安装与开始使用
 
 需要 Node.js `22.19.0+` 或 `24+`、pnpm，以及兼容的 DeepSeek Harness。管理员应先完成业务系统
-接入。配套版本为 **BailingHub Core 0.6.1 → BailingHub MCP/SDK 0.4.0 → 本插件 0.4.0**。
+接入。配套版本为 **BailingHub Core 0.8.0 → BailingHub MCP/SDK 0.6.0 → 本插件 0.6.0**。
 
 ```bash
 npm install --global pnpm @deepseek-ai/dsh@0.1.1-rc.2
-dsh plugin --profile web add dsh-bailinghub@0.4.0
+dsh plugin --profile web add dsh-bailinghub@0.6.0
 ```
 
-插件会自动安装精确依赖 `bailinghub-mcp-server@0.4.0`，无需另装 SDK。
-已经使用旧版的用户请先看[0.3 到 0.4 的迁移步骤](MIGRATION_VNEXT.md)。
+插件会自动安装精确依赖 `bailinghub-mcp-server@0.6.0`，无需另装 SDK。
+已经使用旧版的用户请先看[从 0.4.0 及更早版本升级的步骤](MIGRATION_VNEXT.md)。
 
 按照[开始使用指南](GETTING_STARTED.zh-CN.md)填写管理员提供的四项公开连接信息，再到浏览器授权。
 不要把业务密码、Client Token、签名密钥或模型 Key 填进插件设置或聊天消息。
 
 ## 为每个会话选择账号
 
-在原业务授权页面分别授权 A 店和 B 店。创建连接时使用清晰的本机名称，例如 `A 店`、`B 店`，
-并在授权页核对实际业务身份。名称是你提供的标签，不证明身份，也不授予权限；`default`、
-`default-2` 无法让智能体知道你指的是哪家店。
+在各自原业务授权页面分别授权并核对实际对象。配套业务后端可自动提供“品牌旗舰店”“主仓库”
+等展示名称；缺名时明确显示“授权名称待同步”，不会从本机别名猜名称。
+
+名称仅用于展示。同名、改名不会合并或重建凭据、替换原 Session 或改写历史。本机连接选择器、
+固定连接键、当前业务名称与系统用途说明分别保留。
 
 **新建会话，在发送第一条消息前**执行：
 
 ```text
 /bailinghub connections list
-/bailinghub scope set <A店连接键> <B店连接键>
+/bailinghub scope set <商城连接键> <库存连接键>
 /bailinghub scope
 ```
 
-把占位符换成列表里的固定连接键，不是连接名称。也可以只选一份授权；多份授权必须属于同一个
-中枢、Client App 和 workspace。等待设置成功回显后，再发送业务请求。
+把占位符换成列表里的固定连接键，不是连接名称。可以选择单份授权、同系统多份授权，或同一
+中枢、同一审计域的不同系统；每个目标须有独立原 Agent Session。等待设置成功回显后再发请求。
 
 **新会话默认是普通聊天，选择业务范围后才会提供业务工具。** 登录成功或切换默认连接不会自动
 开启业务访问。`/bailinghub scope none` 可显式选择普通聊天。第一条用户消息会固定这个范围；
 之后要增减账号，或从普通聊天改成业务会话，都需要新建会话。
 
-同一套能力不必为每家店重复声明。智能体选择每次调用使用的授权，不会拿到凭据；各项操作仍受
+同一系统的能力不必为每家店重复声明，不同系统的同名工具则保持分离。智能体选择每次调用
+使用的授权，不会拿到凭据；各项操作仍受
 对应账号权限和审批规则约束。需要审批时，在会话仍运行的情况下，继续的是原调用。
 
 任意一份选中授权撤销、被替换或暂时无法核验时，整个会话的业务访问暂停，不会偷偷改用其他账号。
@@ -63,7 +80,7 @@ dsh plugin --profile web add dsh-bailinghub@0.4.0
 
 ## 查看沟通过程与操作结果
 
-配合 Core 0.6.1 和 SDK 0.4.0，BailingHub 可以把可见的用户消息、助手回复、轮次，以及原业务
+配合 Core 0.7.0 和 SDK 0.5.0，BailingHub 可以把可见的用户消息、助手回复、轮次，以及原业务
 执行记录的关联放在同一份会话记录中。各份授权仍保留自己的业务调用记录，汇总回答不会复制到
 每个账号的记忆中。
 
@@ -131,6 +148,7 @@ DSH 负责思考与工具编排；BailingHub Core 负责可信身份、治理、
 业务系统继续声明原有能力，为每个身份分别授权即可。自定义 DSH 宿主需接入[范围选择与恢复 API](AGENT_CLIENT_CONTRACT.md#host-owned-session-scope-api)，
 在首条消息前显示确认；原生斜杠命令已经使用这些 API。参数结构、持久化和恢复细节见
 [Agent Client 契约](AGENT_CLIENT_CONTRACT.md)。
+本地智能体附件空间（首期支持图片）见[宿主接入说明](GENERATED_ARTIFACTS.md)：登记当前会话的生成结果，上传保存并取得可供已有业务工具使用的地址。
 
 请使用 Native Tool Mode。DSH Code Mode 无法安全呈现本轮动态工具结构，因此明确降级。
 版本范围见[兼容矩阵](COMPATIBILITY.md)。
@@ -139,7 +157,30 @@ DSH 负责思考与工具编排；BailingHub Core 负责可信身份、治理、
 
 公开 `dsh-bailinghub@0.1.1` 继续作为独立的静态 MCP 兼容路径：它启动
 `bailinghub-mcp-server@0.1.1`，使用运营者提供的固定路由 Client Token，由 BailingHub 编排。
-0.4.0 不会读取或转换该凭据。使用旧路径时继续固定旧版本，并参考[迁移说明](MIGRATION_VNEXT.md)。
+原生插件不会读取或转换该凭据。使用旧路径时继续固定旧版本，并参考[迁移说明](MIGRATION_VNEXT.md)。
 
 问题请提交到 [GitHub Issues](https://github.com/bailinghub/bailinghub-dsh-plugin/issues)，提供版本与
 脱敏错误，不附带 Token、私有地址、个人信息或生产业务数据。兼容测试与下载量不代表生产采用。
+## 能力发现与错误反馈
+
+这轮优化解决的是：查完库存后，AI 要知道商城工具是否仍然可用；上架请求没有拿到确认时，要沿原调用核对结果，不能再上架一次。
+
+- 搜索返回多少候选、当前会话加载多少工具、哪些因为共享上限没加载，分别说明；未知总数不填写为 0。
+- 先发现创建商品、再发现查询工具，查完后可以直接继续创建商品。同一轮搜索会保留仍有效的旧工具，跨系统也遵守各自授权。
+- 每次最多展示 12 个完整工具说明，本轮共享保留最多 64 种可调用工具；退出展示窗口不等于卸载。64 是工具种类数，不是商品数、调用次数或任务时长。
+- 缓存淘汰、声明变化或需要新能力时需重新发现。默认 active_turn 在轮次结束后卸载，显式 session 模式可在同一存活会话内复用；未确认的写操作始终恢复原调用。
+- 网络暂时失败、授权不可用、版本不支持和原操作结果未知，使用不同的结构化反馈。旧工具名在宿主层被拒绝，也能获得对应指引。
+- 原权限、审批、会话范围、归档和恢复约束保持。本节能力发现不新增迁移；完整版本升级仍需核对 Core 的 060–062 迁移。
+
+客户端宿主接口、字段含义和兼容要求见 [能力发现与恢复契约](CAPABILITY_FEEDBACK.md)。
+
+
+## 重开后继续核对原业务操作
+
+例如上架商品还在等审批时关闭客户端，重新打开原会话后，可以继续处理原上架调用；
+商品操作已发出但回包丢失时，也只核对原调用，不再生成一次上架请求。
+这需要宿主持久保存原会话范围和调用恢复记录。没有旧记录时会明确提示，不能从聊天正文猜回参数。
+
+这部分包含在 0.6.0 中，需宿主配置持久 invocationStore。
+接入方式、保存失败处理及兼容边界见 [调用恢复说明](INVOCATION_RECOVERY.md)。
+恢复记录本身不执行业务；显式恢复原调用可能继续已获批但尚未派发的操作。

package/docs/RELEASE_NOTES_v0.5.0.md

@@ -0,0 +1,79 @@
+# DSH 0.5.0: check stock, then update and list a shop product
+
+[简体中文](#简体中文)
+
+**Release pairing: Core 0.7.0 → SDK 0.5.0 → DSH 0.5.0.** This release extends the same-system multi-account flow introduced in 0.4.0. Core 0.6.1 and SDK/DSH 0.4.0 do not include the additions described here.
+
+## What changes for a user
+
+After separately authorizing a shop and inventory system on the same Hub, select both for a new conversation and ask:
+
+> “Check how many tumblers are in stock. If any are available, change the corresponding shop product's price to 59 and list it. Otherwise leave it unlisted.”
+
+The 0.4 plugin already supports multiple accounts in one system. Version 0.5.0 extends that flow to different selected systems. It looks up stock with inventory tools, then performs permitted shop actions with shop tools. If only the shop is needed, inventory is not marked as executed. The original permissions and approvals apply to each action.
+
+These actions must be exposed by the business systems, with product mappings confirmed. A stock read is not a reservation or automatic stock synchronization. A price change can succeed while listing waits for approval or fails; follow the actual results and original execution records rather than assuming the whole request completed.
+
+## New and improved
+
+- **One conversation across selected systems.** Discover capabilities by target, keep same-named tools separate, and preserve the original authorization for each call and recovery. First-message scope freezing remains in force.
+- **Understand the target before searching.** Administrator-managed descriptions explain that a shop handles online selling while inventory handles stock. Missing metadata stays unknown; “not loaded” does not mean “no capabilities.” Description reads create no business run.
+- **Recognize the approved business subject.** A compatible backend can supply “Brand flagship store” automatically. Current display names stay separate from the product description and internal connection key. Missing names remain explicit; duplicates and renames do not replace identities or rewrite history.
+- **Follow the whole conversation and each system's actions.** The existing visible archive now retains cross-system member bindings and original run links. Upload retry uses saved events and never repeats business writes.
+
+## Who needs to upgrade
+
+Users need a matching Core and plugin installation, not just new display labels. Administrators can use **Agent Clients → Setup** in Core to configure authorization, system descriptions, tools/approvals and connection checks. Business backends supply names and keep their existing capability, permission and approval rules.
+
+Custom hosts retain `setSessionScope`, `getSessionScope`, `restoreSessionScope`, `getSessionArchiveStatus` and `syncSessionArchive`. Preserve original real DSH Session events and complete v2 scope/outbox records with their revisions. Do not rebuild old conversations from the current authorization list.
+
+## Upgrade order and checks
+
+1. Ask the administrator to upgrade Core to 0.7.0 using its release guide. Back up first and apply only outstanding migrations in order, including 058/059 when upgrading from 0.6.1. Installing the plugin does not deploy or migrate the Hub.
+2. Finish active business work, retry pending run completions with `/bailinghub sync`, then install `dsh-bailinghub@0.5.0` and restart DSH. It installs exact SDK 0.5.0 automatically. Keep existing credentials, original Session events and scope/outbox files; an upgrade alone is not a reason to authorize again.
+3. Authorize each target and confirm the business subject. In a new conversation, select the fixed connection keys before the first message and wait for successful scope confirmation. A display name is not a connection key.
+4. Verify a permitted stock read and a low-risk shop action, each actual target, any required approval, and their original execution associations in the conversation. An inventory-only or shop-only request must not claim the other system executed.
+5. Check original-scope restoration, temporary offline recovery in the same runtime, revoked-member blocking and archive-only retry. Keep local history errors visible; changing a display name must not replace a Session or reset the archive.
+
+Empty scope remains ordinary chat. Started conversations retain their original scope; additions require a new conversation. Revocation or identity replacement blocks the selected group instead of falling back to a default or subset. Missing cross-system SDK/Core support explicitly refuses that mode while preserving existing same-system behavior.
+
+## Limits
+
+One Hub and audit domain, with a distinct original Session per selected target. No cross-Hub scope, automatic product identity mapping, durable task scheduler, distributed transaction, automatic rollback or cross-process business task recovery. The local conversation can contain results from both systems; this is not automatic redaction or a field-level data-sharing policy.
+
+See [cross-system integration](CROSS_SYSTEM_CONVERSATIONS.md), [host contract](AGENT_CLIENT_CONTRACT.md), [compatibility](COMPATIBILITY.md), [release procedure](https://github.com/bailinghub/bailinghub-dsh-plugin/blob/v0.5.0/docs/RELEASING.md) and [Core scenarios](https://github.com/bailinghub/bailinghub/blob/v0.7.0/docs/RELEASE_NOTES_v0.7.0.en.md).
+
+## 简体中文
+
+**配套版本：Core 0.7.0 → SDK 0.5.0 → DSH 0.5.0。** 本版延续 0.4.0 的同系统多账户流程，扩展到同一中枢内的多个业务系统。Core 0.6.1 与 SDK/DSH 0.4.0 不含下述增量。
+
+### 用一个商城场景说明变化
+
+分别授权同一中枢下的商城与库存系统，为新会话选中两者，再说：“先查保温杯还有多少库存，有货再把商城对应商品改为 59 元并上架，没货就先不上架。”
+
+0.4 已经支持同系统多账户。本次扩展到不同系统：查库存使用库存工具和授权，改价上架使用商城工具和授权；只用到商城时，库存系统不会被标成执行过。各步骤仍按原权限和审批处理。
+
+前提是业务系统已开放相应动作，商品对应关系已确认。查库存不等于锁库存或建立自动同步。改价成功、上架待审批或失败可能分别发生，要看实际结果及原执行记录，不能笼统说全部完成。
+
+### 本次更新了什么
+
+- 在已选系统内按目标发现能力并调用，同名工具不串系统，调用和恢复保留原授权；首消息后范围固定。
+- 第一次搜索工具前了解商城负责售卖、库存负责库存等受控系统说明；缺少说明显示未知，“尚未加载”不等于没有能力，介绍读取不创建业务 run。
+- 配套后端可自动提供“品牌旗舰店”等真实授权主体名称；名称独立于系统用途和内部连接键。缺名明确提示，同名、改名不合并身份或改写历史。
+- 在原完整可见归档上增加跨系统成员和执行关联。重试只补传保存的记录，不重复业务写操作。
+
+### 谁需要调整、怎样升级
+
+用户需要配套中枢和插件，不能只换显示标签。管理员在 Core“智能体客户端 → 接入配置”维护授权入口、系统说明、工具审批与连接检查。业务后端提供名称，保留原能力声明、权限与审批。
+
+管理员先按 Core 发布指南备份并升级到 0.7.0，按顺序仅执行未应用迁移；从 0.6.1 升级时包括 058/059。用户结束当前业务任务，用 `/bailinghub sync` 重试待同步结尾记录，再安装 `dsh-bailinghub@0.5.0` 并重启 DSH；插件会自动安装精确 SDK 0.5.0。保留原凭据、真实 Session 事件与范围/待传记录，不因版本升级重新授权。
+
+宿主继续使用原五个范围/归档接口，保存真实 DSH Session 事件及完整 v2 范围、待传事件与修订号，不按当前授权列表重建旧会话。新会话发送首消息前用固定连接键选定目标，等确认成功再发消息，不能用展示名代替键。
+
+用一个允许的库存查询和一个低风险商城动作，核对目标、后台结果、原审批和会话中的执行关联；只用一个系统时，另一个不能被标为已执行。另需核对原范围恢复、同 runtime 断网重试、撤销整组阻断、仅重试归档，以及改名不替换 Session 或重置归档。
+
+未选范围仍为普通聊天；旧会话不扩大，改选新建会话。原授权撤销或身份变化整组阻断，不换默认或剩余子集。SDK/Core 缺少跨系统支持时明确拒绝新模式，原同系统流程保留。
+
+范围限同 Hub、同审计域和各自独立原 Session，不提供跨 Hub、自动商品映射、持久调度、分布式事务、自动回滚或跨进程恢复未完成业务任务。两边结果会参与同一段本地沟通，本功能不等于自动脱敏或字段级共享策略。
+
+详见[跨系统接入](CROSS_SYSTEM_CONVERSATIONS.md#简体中文)、[宿主契约](AGENT_CLIENT_CONTRACT.md)、[兼容说明](COMPATIBILITY.md)、[发布流程](https://github.com/bailinghub/bailinghub-dsh-plugin/blob/v0.5.0/docs/RELEASING.md)和[Core 场景说明](https://github.com/bailinghub/bailinghub/blob/v0.7.0/docs/RELEASE_NOTES_v0.7.0.md)。

package/docs/RELEASE_NOTES_v0.6.0.en.md

@@ -0,0 +1,39 @@
+# v0.6.0 DSH plugin: move between queries, edits and result checks
+
+Release 0.6.0. Pairing: Core 0.8.0 / Agent Client SDK 0.6.0 / DSH 0.6.0. Changes below are relative to the preceding public release.
+
+An Agent creates a shop product, checks inventory and returns to editing it. New searches now merge still-valid tools within a turn instead of discarding the earlier batch. Adapted hosts can also reuse declarations across messages in the same living Session, reducing repeated remote discovery.
+
+## User-visible changes
+
+**Smoother tool switching.** The retained registry is bounded to 64 tools with a 12-schema presentation window. Session reuse has a cache of at most 64 target-tool pairs and 2 MiB; these are not operation or product quotas. Each turn still prepares the intended target's current context. Identity, permission and declaration-revision checks remain. The existing search entry point supplies full schemas so the model need not guess old parameters.
+
+**Inspect an original operation after reopening.** A persistent journal retains original target, run and invocation links. A pending shop listing can be inspected after closing the host. Public host methods support panel inspection and explicit continuation without manufacturing a model turn. Unknown writes are not replaced, and inspection never consumes approval.
+
+**Task controls across turns.** Hosts can bind an administrator-created task with its original members and cumulative budget. Models cannot choose a task ID, create tasks or increase budgets. Pause, cancellation, budget exhaustion and ordinary frequency limits have distinct states.
+
+**Use attachments in business actions.** Hosts register generated images or images explicitly selected by the user for business use. `list_generated_artifacts` / `upload_generated_artifacts` return reusable URLs. Their existing names do not restrict the source to AI generation. PNG/JPEG/WebP, 1–8 per batch and up to 6 MiB each, are supported. Ordinary chat attachments are not uploaded automatically. Subsequent business actions have separate results.
+
+**Understand failures.** Rediscovery, unsupported interfaces, temporary outages, changed identity and unknown outcomes have distinct guidance. Rate-limited work retains its original invocation. A missing original record stops automatic recovery and requests inspection of original evidence; it does not prove that the business action never happened.
+
+## Host integration
+
+| Feature | Required host work |
+| --- | --- |
+| Cross-turn reuse | Opt into `toolLifecycle: 'session'`, keep the real Session/runtime and handle preparation results; the default remains `active_turn` |
+| Original-call restart recovery | Provide a persistent `invocationStore` and retain scopes, events and archives; a custom scope store needs explicit durable companion stores |
+| Task controls | Provide a persistent `taskStore`, use `getSessionTaskCoordinates` and public binding/restore methods for administrator-created tasks |
+| Invocation panel | Call `inspectSessionInvocation` / `resumeSessionInvocation` with the real Session, original ID and cancellation signal; display business state from receipts |
+| Attachment space | Connect a controlled `artifactSource` and persistent `artifactStore`; resolve approved references, not arbitrary paths |
+
+Preparation is not business execution. Direct calls to unprepared cached tools return preparation only; read the current schema before issuing the actual action. Replaying that old call ID must not turn preparation into a write. `ready` likewise does not mean business success. Preserve storage failures, unsaved events and recovery gaps as primary errors.
+
+Propagate cancellation when a panel closes or the user switches conversations. Late results must not reactivate ended-turn tools. Cancelling a wait does not withdraw an already submitted request.
+
+## Upgrade and limits
+
+Follow the [paired upgrade guide](UPGRADE_v0.6.0.en.md): upgrade Core and SDK before the actual host's DSH and persistence adapters. Existing backend APIs and approvals need no change.
+
+The declaration cache survives only within the current Session/runtime; a restart requires discovery again. Original-call recovery uses a separate durable journal and does not resume a whole model plan. Missing historical bindings are not reconstructed, and any invalid original member blocks the whole group. The same-Hub, same-audit-domain boundary remains. These DSH seams do not automatically appear in generic MCP hosts.
+
+Bounded client synthetic acceptance and actual development Profile package verification are complete. Actual clicks in the latest panel, Windows devices and arbitrary model-driven long tasks are not fully covered. Verify the actual installed release package.

package/docs/RELEASE_NOTES_v0.6.0.md

@@ -0,0 +1,39 @@
+# DSH 插件 v0.6.0：查询、编辑、核对，可以连着做
+
+发布版本：0.6.0。配套：Core 0.8.0 / Agent Client SDK 0.6.0 / DSH 0.6.0。相对上一公开版本的变化如下。
+
+助手先创建商城商品，再查询库存，最后回到商品编辑。以前新搜索可能替换前一批工具；下一条消息也需要重新发现。现在，一轮内的搜索会合并仍有效的工具，已适配宿主还可以在同一个存活会话中复用声明，减少重复远端发现。
+
+## 使用体验的变化
+
+**工具切换更连贯。** 保留集合最多 64 个工具，完整 schema 展示窗口为 12 个。开启会话复用后，缓存上限是 64 个“目标—工具”条目、2 MiB，不是操作次数或商品数量限额。每轮首次需要某个目标时仍准备当前上下文；授权、权限和声明版本检查继续生效。模型能从现有搜索入口取得完整参数说明，不必凭记忆猜字段。
+
+**重开后核对原操作。** 持久调用账本保存原目标、运行和调用关联。例如商品上架等待审批时退出，再打开仍可核对同一笔上架。宿主面板通过正式接口直接“核对结果”或明确“继续原调用”，不需要先伪造一条用户消息。未知写结果不另建调用，核对也不会消费审批。
+
+**任务控制贯穿多轮。** 宿主可关联管理端建立的原任务，保留整组授权和累计预算。模型不选择任务 ID、不创建新任务、不提高额度。暂停、取消、额度用尽和普通频率等待有各自状态。
+
+**附件可以接着用于业务。** 宿主登记生成图片或用户明确指定业务用途的图片，模型用 `list_generated_artifacts` / `upload_generated_artifacts` 取得可用 URL。工具名为兼容保留，来源不限于 AI 生成。本期支持 PNG/JPEG/WebP，每批 1–8 张、每张最高 6 MiB。普通聊天附件不会自动上传，业务工具仍单独执行并返回结果。
+
+**失败后知道下一步。** 需要重新发现的工具、不支持的接口、暂时断网、授权变化和原结果未知不会都被说成“系统没有能力”。限流等待后保留原调用；原调用不存在时停止自动恢复，提示核对原执行证据，而非认定业务没有发生。
+
+## 宿主必须接的部分
+
+| 能力 | 接入动作 |
+| --- | --- |
+| 跨轮声明复用 | 显式设置 `toolLifecycle: 'session'`，保持真实 Session/runtime，处理准备结果；默认仍为 `active_turn` |
+| 原调用重开恢复 | 配置持久 `invocationStore`，保留原 scope、事件和归档记录；自定义 scopeStore 的宿主不能依赖临时内存默认值 |
+| 任务控制 | 配置持久 `taskStore`，通过 `getSessionTaskCoordinates` 获取原坐标，用正式绑定/恢复方法接管理端任务 |
+| 会话面板 | 接 `inspectSessionInvocation` / `resumeSessionInvocation`，传真实 Session、原 ID 和取消信号；按 receipt 结果展示业务状态 |
+| 附件空间 | 接受控 `artifactSource` 和持久 `artifactStore`；读取引用而非任意文件路径 |
+
+准备成功不代表业务执行成功。直接调用尚未准备的缓存工具只会返回准备结果；宿主和模型必须读取当前说明再发出业务操作，不能重复旧调用 ID 把准备变成写入。`ready` 也不代表业务完成，应检查实际回执。存储失败、未保存消息和历史缺口优先展示。
+
+关闭面板、切换会话或取消等待须传递取消；晚到回应不能启用旧轮次工具。取消等待不是撤销已经提交的业务请求。
+
+## 升级与边界
+
+见[配套升级指南](UPGRADE_v0.6.0.md)。先升级 Core 与 SDK，再升级实际宿主的 DSH 及持久适配器，不需要让业务后端重做接口或审批。
+
+跨轮工具缓存仅在当前 Session/runtime 存活期间保留，重启后需要重新发现；原调用恢复依靠另一份持久账本。它不自动续跑整项模型计划。没有可信旧记录时不猜补，任一原授权失效时整组阻断。仍限同一 Hub、同一审计域；通用 MCP 宿主不会自动获得这些 DSH 接缝。
+
+配套客户端已完成限定合成验收和实际开发 Profile 包核对。最新面板的人工点击、Windows 实机和任意模型长任务表现尚未获得全范围验证；升级时核对实际安装包。