dsh-bailinghub 0.4.0 → 0.5.0

package/docs/CROSS_SYSTEM_CONVERSATIONS.md

@@ -0,0 +1,136 @@
+# One conversation across business systems
+
+**Release pairing: Core 0.7.0, SDK 0.5.0 and DSH 0.5.0.** The plugin installs its exact SDK
+dependency. Core 0.6.1 / SDK 0.4.0 / DSH 0.4.0 do not include this extension; upgrade the Hub
+before selecting targets from different systems.
+
+## What you can do
+
+Select, for example, a shop account and an inventory account already authorized on the same
+BailingHub deployment. Ask the same local Agent to check product stock, then change a corresponding shop product's price and list it using permitted actions. The Agent keeps each system's tools and authorizations distinct; you do not switch
+the global connection between steps. Available actions still depend on each system's declared
+capabilities and the permissions of the selected account.
+
+The Agent initially sees the selected target directory. It searches the intended target's
+capabilities when needed, then calls the corresponding typed tool. A capability search opens
+that target's run with the search's minimal task description. Other systems do not automatically
+receive the original user turn or contribute their memory. The local Agent and the independent
+conversation audit still share the visible conversation.
+
+## Start a conversation
+
+### Understand the selected systems before choosing tools
+
+An administrator can provide each connected system's name, short purpose, usual business areas
+and boundaries in BailingHub. The Agent reads these descriptions for the selected accounts before
+its first capability search. For example, it can distinguish online selling from inventory
+management without a client-specific product dictionary. Business-supplied subject names identify
+the particular organization, project or other authorized subject for display. They are separate
+from product purpose and do not prove identity or grant permissions.
+
+A description says what the product usually does. The actual tools and permissions still come
+from authorized capability discovery. “Not loaded” means the tools have not been requested yet;
+it does not mean the product has no capabilities. Missing descriptions or an older server show
+unknown information and preserve the existing search flow. Reading a description sends no user
+message and creates no business run. Existing same-system first-turn runs are unchanged.
+
+If the server explicitly reports that a selected workspace is unavailable, its directory says
+unavailable while retaining the original selection. An uncertain network failure remains unknown;
+neither condition selects another account. A later turn reads the original target again.
+
+### Select the accounts
+
+1. Authorize each target separately and verify the intended subject on the business authorization
+   page. With a compatible business backend, the backend supplies its name automatically. A local
+   connection selector remains independent; missing names show “Authorization name pending sync”.
+   Names do not prove a mapping between two systems or distinguish duplicate-named subjects.
+2. In a new conversation, use `/bailinghub connections list`, then
+   `/bailinghub scope set <shop-connection-key> <inventory-connection-key>`.
+3. Wait for successful confirmation before sending the first message. Start with a precise
+   request identifying the intended systems, objects and allowed action.
+4. Review the separate results and any approval requests. Use `/bailinghub archive status`
+   to check visible-record upload; `/bailinghub archive sync` retries uploads without repeating
+   business actions.
+
+An empty scope remains ordinary chat. The first user message freezes the selected targets.
+Reopening a conversation restores the original selection after all original members pass
+validation; a draft that never started needs fresh confirmation. A temporary outage can be
+retried in the same runtime. Revoked/replaced members never cause a switch to a default or subset.
+
+## Host integration
+
+Keep the existing `setSessionScope`, `getSessionScope`, `restoreSessionScope`,
+`getSessionArchiveStatus` and `syncSessionArchive` flow. The returned scope view retains its v1
+schema and gains `targetMode: "multi_system"`; authorization entries additionally include
+`clientAppId` and `systemRef`. Use those public fields to group the selection UI if helpful.
+Never feed raw keys, credentials or writable scope records to the model.
+
+The built-in stores understand both v1 and v2. A custom store must retain the complete v2 record
+without reconstructing it from today's registry, preserve the original host Session identity,
+and provide atomic revision comparison. Persist original DSH events so incomplete capture can
+be detected on reopen. No second body-reporting path is required.
+
+Cross-system operation requires the matching SDK's capability negotiation, frozen-binding guard,
+and the Core's target-member archive extension. Missing support reports
+`CROSS_SYSTEM_SCOPE_UNSUPPORTED`; it is not a reason to send the first message with an old scope.
+The matched Core requires an additive database migration through its own deployment process;
+installing this plugin does not migrate or deploy the Hub.
+
+## Limits
+
+- One Hub, with independently authorized Sessions for every selected target. Cross-Hub scope
+  and multiple selected routes sharing one Agent Session are not supported.
+- Task planning and step ordering are performed by the Agent. This is not a deterministic
+  dependency engine, a distributed transaction, automatic rollback, or cross-process task recovery.
+- Original invocation recovery is available in later turns of the same live runtime. Archive
+  restoration after restart does not reconstruct pending invocations or approvals.
+- Different systems' object IDs are unrelated unless a verified business mapping establishes
+  the relationship. The Agent must clarify an ambiguous mapping.
+- The runtime enforces target and capability boundaries. It does not provide automatic
+  sensitive-text redaction or a field-level cross-system data-sharing policy.
+- Complete transcript reading remains an administrator audit operation. An individual business
+  authorization does not grant an API to read the entire mixed transcript.
+
+## 简体中文
+
+本版配套 Core 0.7.0、SDK 0.5.0 与 DSH 0.5.0，插件会安装精确 SDK 依赖。
+Core 0.6.1、SDK/DSH 0.4.0 不含本次扩展；选择不同系统前先升级中枢。
+
+### 对使用者有什么变化
+
+你可以在同一个会话里选中“商城”和“库存系统”的授权，让助手先查询保温杯库存，再使用商城允许的
+改价、上架等动作。每一步都会使用对应系统的工具与授权，仍按该系统的权限和审批规则执行。
+
+助手先看到你选中的目标目录，需要哪个系统时才查找它的能力、加载它的上下文。不会因为选中了两个系统，
+就把每句话自动发送给两者。某个系统的查询结果进入本地模型后，会成为同一会话的上下文；只有允许这样共享
+的数据才适合放在同一会话。完整可见沟通通过独立会话账本归档，各系统仍保留自己的操作记录。
+
+### 怎样开始
+
+接入方可以在中枢维护系统名称、简短用途、典型业务方向和边界。助手在首次搜索工具前就能看到本会话所选系统
+的介绍，例如分清“线上售卖”和“库存管理”，不需要每个客户端分别写死产品词典。同系统的多个账号也会显示
+相同的系统归属。授权主体展示接口单独提供业务授权主体的名称，用于表示具体的组织、账号、项目等；名称不证明身份，
+也不增加权限。
+
+系统介绍说明产品通常做什么，实际能做什么仍取决于此授权的能力查询和原有权限规则。“尚未加载”表示还未
+查询工具，不表示没有能力。介绍缺失、旧版本不支持或介绍请求暂时失败时，可继续使用原有的授权工具搜索。
+读取介绍本身不发送用户正文、不创建业务运行记录；同系统原有首轮运行机制保持不变。
+
+如果服务端明确报告所选工作空间不可用，目录会显示“不可用”并保留原选择；无法确定的网络失败显示“未知”。
+两者都不会自动切换授权，后续轮次仍查询原目标。
+
+先分别授权并在业务授权页确认对象。授权主体展示接口由业务后端提供主体名称；名称缺失时明确显示“授权名称待同步”，
+内部连接标识独立保留。再新建会话，使用上面的 scope 命令选中两份固定授权。
+等选择成功后，再明确提出操作对象和要做的事。首次消息后范围固定；需要增减系统时新建会话。
+
+如果库存里的商品与商城中的某个商品需要关联，应使用已经确认的业务映射，或由用户明确确认。
+两个系统的商品名或编号看起来相同，并不能证明它们是同一对象。库存查询不等于锁库存或建立自动库存同步。
+
+### 下游需要配合什么
+
+宿主继续使用现有五个范围与归档接口，不需要另加一条正文上报链路。界面可以按新返回的系统字段分组展示，
+并继续保持“选择成功才允许发首条消息”。内置持久化已支持新记录；自定义存储需要原样保留 v2 的目标绑定、
+原会话身份、事件和修订号。Core 0.7.0 需要通过自身升级流程应用未执行的迁移（本次包括 058/059）。
+
+业务后端只需继续声明能力、独立授权并执行原有业务规则；如果用户要做的动作尚未开放，才需要补充该业务能力。
+本版解决跨系统选择、调用和完整追溯，不包含周年庆等长任务的持久依赖调度、跨进程恢复或自动回滚。

package/docs/GETTING_STARTED.md

@@ -1,8 +1,10 @@
-# Get started with 0.4.0
+# Get started with 0.5.0
 
 This guide is for users whose business system is already connected to BailingHub. Your
-administrator must prepare Core 0.6.1, a public Client App ID, a workspace, and the business
-browser-authorization entry first. You do not need to change business capability declarations.
+administrator must prepare Core 0.7.0, a public Client App ID, a workspace, and the business
+browser-authorization entry first. For multiple systems, prepare one independently authorized
+connection per target on the same Hub and audit domain. Existing business capability declarations
+remain valid; each requested action must already be exposed by its own system.
 
 ## 1. Install and configure
 
@@ -10,10 +12,10 @@ Use Node.js `22.19.0+` or `24+` and the compatible DSH version:
 
 ```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.5.0
 ```
 
-The plugin installs SDK 0.4.0 automatically. Enter the four public values in DSH plugin settings,
+The plugin installs SDK 0.5.0 automatically. Enter the four public values in DSH plugin settings,
 or use their environment names. The example values below are placeholders:
 
 ```bash
@@ -41,7 +43,10 @@ In DSH, authorize the first account:
 
 The browser opens the original business authorization page. Sign in or switch accounts there,
 select the intended store/tenant when asked, and check the actual identity before approving.
-The business page determines the identity; the local label `Store A` does not.
+The business page determines the identity; the local label `Store A` does not. A compatible
+backend supplies the approved subject name automatically. The current display name is separate
+from its fixed key and the system description; missing names remain explicit. Duplicate names
+or renames do not recreate authorization or change old conversation records.
 
 For another account in the **same system and workspace**, register a clearly named connection,
 using the same three administrator-provided values, then authorize it separately:
@@ -59,24 +64,45 @@ an available alias. Names such as `default-2` do not prove which store was autho
 mapping before use. If login reports cleanup required, the new connection is already authorized;
 inspect and remove the reported old entry rather than authorizing again.
 
+To add a **different system**, use its administrator-provided Client App and workspace on the
+same Hub, then authorize it independently. For example, an inventory target may use:
+
+```text
+/bailinghub connections add "Inventory" https://hub.example.com inventory-client inventory_assistant
+/bailinghub login
+/bailinghub connections list
+```
+
+These are placeholders, not values to guess from a product name. Each selected target needs its
+own original Agent Session. Keep the existing Store B connection if using the same-system flow.
+
 ## 3. Choose this conversation's business scope
 
 Start a **new conversation before sending any message**, then run:
 
 ```text
 /bailinghub connections list
-/bailinghub scope set <store-a-connection-key> <store-b-connection-key>
+/bailinghub scope set <shop-connection-key> <inventory-connection-key>
 /bailinghub scope
 ```
 
 Copy the fixed connection keys from the list; the scope command does not accept names. Select
-one key for one account, or several for the same Hub/Client App/workspace. Wait for the successful
-confirmation before sending. For example, when the reporting capability is available:
+one key for one account, several for the same system, or several systems on one Hub and audit
+domain. Wait for successful confirmation. With the required inventory/shop capabilities and a
+confirmed product mapping, you can ask:
 
 ```text
-Compare today's sales at Store A and Store B. Show each store separately.
+Check tumbler stock. If any are available, change the corresponding shop product to 59 and list it.
+Otherwise leave it unlisted.
 ```
 
+The system description can explain online selling versus inventory before tool search. “Not loaded”
+means tools have not been queried, not that none exist. A stock read does not reserve or synchronize
+stock. Check price and listing outcomes separately, including any pending approval.
+
+For the retained same-system flow, select Store A and Store B instead and compare their sales
+when reporting tools are available. A system that was not used must not be marked as executed.
+
 The Agent chooses which selected authorization to use for each call. The system still decides
 which data and actions that authorization permits. Test a read first, then a reversible permitted
 update in a development workspace. Approval-required work follows the original approval flow.
@@ -89,7 +115,7 @@ connection does not change a conversation's scope.
 ## 4. Check results and the visible conversation
 
 Check the actual business result and its original invocation trail in BailingHub. With the matching
-Core 0.6.1, you can also follow visible user/assistant messages, turns, and the linked runs as one
+Core 0.7.0, you can also follow visible user/assistant messages, turns, and the linked runs as one
 conversation record. Multi-authorization runs keep their own call summaries separately.
 
 ```text

package/docs/GETTING_STARTED.zh-CN.md

@@ -1,7 +1,8 @@
-# 开始使用 0.4.0
+# 开始使用 0.5.0
 
-这份指南面向业务系统已经接入 BailingHub 的用户。管理员需要先准备 Core 0.6.1、公开的 Client
-App ID、workspace 和浏览器业务授权入口；已有业务能力无需为多账号重新声明。
+这份指南面向业务系统已经接入 BailingHub 的用户。管理员需要先准备 Core 0.7.0、公开的 Client
+App ID、workspace 和浏览器业务授权入口。多系统时，每个目标分别授权，且属于同一中枢、同一
+审计域；已有能力无需重新声明，但每项动作必须已由相应业务系统开放。
 
 ## 第一步：安装与配置
 
@@ -9,10 +10,10 @@ App ID、workspace 和浏览器业务授权入口；已有业务能力无需为
 
 ```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.5.0
 ```
 
-插件会自动安装 SDK 0.4.0。通过插件设置填写四项公开信息，或使用对应环境变量。下面都是
+插件会自动安装 SDK 0.5.0。通过插件设置填写四项公开信息，或使用对应环境变量。下面都是
 占位值，需要替换成管理员提供的中枢地址、Client App ID 和 workspace：
 
 ```bash
@@ -38,7 +39,9 @@ dsh web
 ```
 
 浏览器会打开原业务授权页面。在那里登录、切换账号，并按业务系统要求选择门店或租户；同意前
-核对实际业务身份。可信身份由业务授权页面决定，本机名称 `A 店` 不证明身份。
+核对实际业务身份。可信身份由业务授权页面决定，本机名称 `A 店` 不证明身份。配套后端可自动
+提供授权主体名称，它与固定连接键、系统用途说明独立；缺名会明确提示。同名或改名不重建授权，
+也不更改原会话记录。
 
 如需使用**同一系统、同一 workspace** 的 B 店，用同样的三项公开信息创建清晰命名的新连接，
 再分别授权：
@@ -54,24 +57,41 @@ dsh web
 `default-2` 之类的名称不能证明是哪家店，使用前应核对对应关系。若登录提示需要清理，新连接
 已经授权成功；请检查并删除提示的旧条目，不要重复授权。
 
+要接入**另一个系统**，使用管理员提供的该系统 Client App 与 workspace，并在同一中枢上
+独立授权。例如库存目标可以使用以下占位配置：
+
+```text
+/bailinghub connections add "库存系统" https://hub.example.com inventory-client inventory_assistant
+/bailinghub login
+/bailinghub connections list
+```
+
+这些配置不能从产品名称推测。每个选中目标都需要独立原 Agent Session；同系统流程中已有的
+B 店连接可以继续保留。
+
 ## 第三步：选择本次会话的业务范围
 
 **新建会话，在发送任何消息前**执行：
 
 ```text
 /bailinghub connections list
-/bailinghub scope set <A店连接键> <B店连接键>
+/bailinghub scope set <商城连接键> <库存连接键>
 /bailinghub scope
 ```
 
-从列表复制固定连接键替换占位符，不能直接填写连接名称。只操作一家店就选一个键；多份授权
-必须属于相同中枢、Client App 和 workspace。等待设置成功回显后，再发送请求。例如，业务系统
-已开放报表能力时可以说：
+从列表复制固定连接键替换占位符，不能直接填写名称。可以选单份授权、同系统多份授权，或
+同一中枢、同一审计域的多个系统。等设置成功回显后再发请求。相应能力已开放、商品关系已确认时：
 
 ```text
-对比今天 A 店和 B 店的营业情况，按门店分别说明。
+先查保温杯库存。有货就把商城对应商品的售价改为 59 元并上架；没货就先不要上架。
 ```
 
+系统说明可在首次查工具前解释“线上售卖”和“库存管理”的区别。“尚未加载”表示还没查询工具，
+不是没有能力。查库存不等于锁库存或自动同步；改价、上架及审批要分别核对结果。
+
+原同系统流程仍可选择 A 店和 B 店，在报表能力可用时对比营业情况。没有实际调用的系统不能
+被标为已执行。
+
 智能体自行选择每次调用使用哪份选中授权；实际数据和操作范围仍由业务权限决定。先验证一次
 查询，再在开发空间尝试一次可回滚且允许的修改。需要审批的操作继续沿用原规则。
 
@@ -81,7 +101,7 @@ dsh web
 
 ## 第四步：核对业务结果与沟通过程
 
-在业务后台核对最终结果，在 BailingHub 查看原调用轨迹。配合 Core 0.6.1，还能把可见用户消息、
+在业务后台核对最终结果，在 BailingHub 查看原调用轨迹。配合 Core 0.7.0，还能把可见用户消息、
 助手回复、轮次与相关执行记录放在同一份沟通记录里查看。多授权的各份执行记录仍分别保留自身
 调用摘要。
 

package/docs/MIGRATION_VNEXT.md

@@ -1,6 +1,69 @@
-# Migrate to 0.4.0
+# Migrate to 0.5.0
 
-## From 0.3.0: choose the conversation scope explicitly
+## 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 +170,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 +180,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 +191,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 +235,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,

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

@@ -5,13 +5,17 @@
 让本地 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 +25,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.7.0 → BailingHub MCP/SDK 0.5.0 → 本插件 0.5.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.5.0
 ```
 
-插件会自动安装精确依赖 `bailinghub-mcp-server@0.4.0`，无需另装 SDK。
-已经使用旧版的用户请先看[0.3 到 0.4 的迁移步骤](MIGRATION_VNEXT.md)。
+插件会自动安装精确依赖 `bailinghub-mcp-server@0.5.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 +70,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 可以把可见的用户消息、助手回复、轮次，以及原业务
 执行记录的关联放在同一份会话记录中。各份授权仍保留自己的业务调用记录，汇总回答不会复制到
 每个账号的记忆中。
 
@@ -139,7 +146,7 @@ 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、私有地址、个人信息或生产业务数据。兼容测试与下载量不代表生产采用。

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