dsh-bailinghub 0.2.0 → 0.4.0

package/docs/COMPATIBILITY.md

@@ -1,38 +1,88 @@
 # Compatibility
 
-## Native Agent Client 0.2.0
+## Native Agent Client 0.4.0
+
+| Component | Release pairing / requirement |
+| --- | --- |
+| DeepSeek Harness | `0.1.1-rc.2`; real Session, Cordis lifecycle, commands, prompt assembly, and ToolRuntime regression coverage |
+| Node.js | `^22.19.0` or `>=24.0.0` |
+| DSH tool presentation | Native Tool Mode; Code Mode deliberately degraded |
+| Generic Agent Client SDK | Exact `bailinghub-mcp-server@0.4.0` via `./sdk` |
+| BailingHub Core | Recommended `bailinghub@0.6.1`; Agent Auth v1, Agent Client Runtime v1, and conversation audit v1 |
+| Visible archive acknowledgement | `bailing.agent-conversation-audit-ack.v1` |
+| Selected authorization group | One Hub + Client App + workspace; no cross-system or cross-route scope |
+
+Core `0.6.0` is the minimum API version for this contract. Use Core `0.6.1` for the
+recommended release pairing; the patch does not change these business APIs.
+
+Install only `dsh-bailinghub@0.4.0`; its ordinary dependency installs the exact SDK. A release
+requires a registry-generated lockfile and a clean package/profile check. Local source and
+synthetic HTTP verification are compatibility evidence, not evidence of an organization's
+production use. The older 0.3 baseline is retained below for existing users, not as a claim that
+0.3 includes 0.4 features.
+
+New conversations need explicit scope selection before the first message. Custom hosts must await
+and display selection, preserve the stable conversation id, and restore the original scope before
+sending on reopen. Missing started-session snapshots stay blocked. Saved drafts require fresh
+confirmation. Scope restoration and archive synchronization do not recover business invocations,
+approvals, or task execution after a process restart.
+
+Temporary network failure during reopening is retryable on the same runtime under the complete
+original scope. Confirmed revocation, replaced identity, or storage/CAS conflict stays blocked.
+Archived event ids and payloads remain stable on retry; known local write errors and detectable
+history gaps cannot be hidden by a connectivity failure.
+
+The archive transport seam is optional for injected older SDKs. They report `unsupported` while
+existing business methods remain usable. An older Core may leave durable events pending or
+unsupported; that degradation does not establish full compatibility with this release. Empty scope
+starts no business run or archive operation. No model can select a new credential or bypass the
+full selected group.
+
+Local scope and outbox files use private POSIX permissions and atomic/CAS persistence. The outbox
+contains plaintext visible task text, persists after acknowledgement, and has no automatic
+retention cleanup. See [Privacy](../PRIVACY.md) and the [host contract](AGENT_CLIENT_CONTRACT.md).
+
+The CI matrix checks Ubuntu and Windows with Node.js 22.19.0 and 24. Live business/browser
+acceptance still belongs to each deployment; the matrix is not a universal deployment claim.
+
+## Historical native Agent Client 0.3.0
 
 | Component | Verified version |
 | --- | --- |
-| DeepSeek Harness / Cordis lifecycle | `0.1.0-rc.7` |
+| DeepSeek Harness / Cordis lifecycle | `0.1.0-rc.7`; `0.1.1-rc.2` |
 | Node.js | `22.19.0+` or `24+` |
 | DSH tool presentation | Native Tool Mode |
-| Generic Agent Client SDK | `bailinghub-mcp-server@0.2.0` via `./sdk` |
-| BailingHub Core | `bailinghub@0.5.0`; Agent Auth v1 + Agent Client Runtime v1 |
+| Generic Agent Client SDK | `bailinghub-mcp-server@0.3.0` via `./sdk` |
+| BailingHub Core | `bailinghub@0.5.1`; Agent Auth v1 + Agent Client Runtime v1 |
 | BailingHub turn context | `bailing.agent-turn-context.v1` |
 | BailingHub capability search | `bailing.agent-capability-search.v1` |
 | BailingHub governed invocation | `bailing.agent-tool-invocation.v1` |
 | BailingHub run completion | `bailing.agent-run-completion.v1` |
 
-Version 0.2.0 declares `bailinghub-mcp-server@0.2.0` as an exact ordinary dependency. A clean DSH
+Version 0.3.0 declares `bailinghub-mcp-server@0.3.0` as an exact ordinary dependency. A clean DSH
 profile must work after installing only the plugin; ambient `node_modules`, peer/optional
 dependencies, dist-tags, ranges, and local `file:` paths are outside the supported contract.
-Compatibility with Core 0.5.0 includes migrations 055/056 and the live Agent Auth/Runtime
+Compatibility with Core 0.5.1 includes the live Agent Auth/Runtime
 contracts from that release.
 
 DeepSeek Harness remains a developer preview. Every Harness version change requires a new smoke
 against its real Cordis lifecycle, prompt waterfall, ToolRuntime, commands, durable session events,
 and Web profile installation before this table can change.
 
+`/bailinghub doctor` validates the required host API shape at runtime and reports the releases for
+which that shape has been exercised. This is a diagnostic check, not a substitute for the live
+browser authorization, read/write, approval/recovery, trajectory, and revocation gates below.
+
 ### Tool-mode and operating-system boundaries
 
 - Native Tool Mode is required. DSH Code Mode is deliberately degraded because it cannot safely
-  present the current-turn dynamic business schemas in 0.2.0.
+  present the current-turn dynamic business schemas in 0.3.0.
 - macOS Agent Session credentials use Keychain.
 - Linux and other POSIX systems require the SDK's explicit secure file-store opt-in; the file must
   remain owned by the current user with mode `0600`.
-- Windows Agent Session credential storage is not supported by 0.2.0. Do not describe
-  Client Token compatibility as native Agent Session support.
+- Windows Agent Session credentials use CurrentUser DPAPI. Native package installation, SDK
+  resolution, and host lifecycle are Windows CI gates; each deployment must still accept its own
+  live browser and business authorization flow.
 - Non-loopback Hub connections require HTTPS. Loopback HTTP is for local development only.
 
 ### Host configuration contract
@@ -50,6 +100,16 @@ In Agent Client v1, `workspace` is the BailingHub route id. Business endpoints,
 URLs, Client Tokens, Tool Provider signing secrets, business credentials, and model-provider keys
 are not DSH plugin configuration.
 
+The public binding is the normalized Hub URL, client app id, and workspace tuple.
+`connectionName` is a user-controlled local selector, not an identity claim. The Hub Client App
+supplies one stable business authorization entry, and the business page
+handles login, account switching, and tenant selection. After authorization, the SDK compares the
+trusted `on_behalf_of` within the same public binding: the same identity replaces the older local
+connection, while different identities remain independent. When a same-alias login returns a
+different identity, the old alias and Session remain intact and the new identity receives a
+non-conflicting alias that becomes current. A cleanup-required result keeps the new connection
+authorized and must be resolved explicitly without another authorization attempt.
+
 ## Public legacy 0.1.x
 
 | Component | Published version |
@@ -65,7 +125,7 @@ Public `dsh-bailinghub@0.1.1` remains a configuration-only bundle. It starts the
 operator-configured Hub URL, route-scoped Client Token, and route. It does not establish an Agent
 Session, receive a dynamic capability catalog, or move orchestration into local DSH.
 
-The 0.2 line must not mutate the published 0.1 package or reinterpret its configuration. A new
+The native line must not mutate the published 0.1 package or reinterpret its configuration. A new
 BailingHub Core release is compatible only after a separate clean legacy profile proves that the
 0.1.1 `/run` and `/jobs/{job_id}` flow still works.
 
@@ -73,8 +133,11 @@ BailingHub Core release is compatible only after a separate clean legacy profile
 
 Compatibility requires independent evidence for both paths:
 
-1. Native 0.2: clean install of only the exact plugin package, browser authorization, workspace
-   discovery, read, permitted mutation, approval/resume, visible completion, and Hub trajectory.
+1. Native 0.4: clean install of only the exact plugin package, browser authorization, workspace
+   discovery, same-identity replacement, different-identity isolation, read, permitted mutation,
+   approval/resume, visible completion, and Hub trajectory. Additionally verify explicit single/multiple
+   scope selection, full-set archive authorization, offline reopen/retry, revocation, and no business
+   replay after a lost archive acknowledgement.
 2. Legacy 0.1.1: clean static profile, fixed Client Token route, one submit, and same-job follow-up
    through the unchanged public Client API.
 

package/docs/GETTING_STARTED.md

@@ -0,0 +1,126 @@
+# Get started with 0.4.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.
+
+## 1. Install and configure
+
+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
+```
+
+The plugin installs SDK 0.4.0 automatically. Enter the four public values in DSH plugin settings,
+or use their environment names. The example values below are placeholders:
+
+```bash
+export BAILINGHUB_HUB_URL='https://hub.example.com'
+export BAILINGHUB_CLIENT_APP_ID='example-agent-client'
+export BAILINGHUB_WORKSPACE='order_assistant'
+export BAILINGHUB_CONNECTION_NAME='Store A'
+dsh --profile web --dump-config
+dsh web
+```
+
+Use your administrator's Hub URL, Client App ID, and workspace. `Connection Name` is your local
+label. None of these fields is a credential. Never put passwords, Client Tokens, signing secrets,
+model keys, or business API/authorization URLs into the plugin settings or chat.
+
+## 2. Authorize each account
+
+In DSH, authorize the first account:
+
+```text
+/bailinghub login
+/bailinghub doctor
+/bailinghub status
+```
+
+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.
+
+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:
+
+```text
+/bailinghub connections add "Store B" https://hub.example.com example-agent-client order_assistant
+/bailinghub login
+/bailinghub connections list
+```
+
+Confirm Store B on the business page. If you approve the same trusted identity again, the SDK
+replaces its old connection and Session instead of creating a second identity. If an existing
+name returns a different identity, the original connection remains and the new identity receives
+an available alias. Names such as `default-2` do not prove which store was authorized. Check the
+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.
+
+## 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
+```
+
+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:
+
+```text
+Compare today's sales at Store A and Store B. Show each store separately.
+```
+
+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.
+
+Without a selection, or with `/bailinghub scope none`, the conversation is ordinary chat and
+starts no BailingHub business runs. The first message freezes this choice. Start a new conversation
+to change accounts or enable business access after ordinary chat. Changing the registry's default
+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
+conversation record. Multi-authorization runs keep their own call summaries separately.
+
+```text
+/bailinghub archive status
+/bailinghub archive sync
+```
+
+The first command shows upload status; the second retries the saved record. It never repeats a
+business action. `synced` means saved events were acknowledged, not that an action succeeded.
+`pending` means upload is unfinished; `blocked` means the original authorizations cannot currently
+permit it; `unsupported` means the SDK or Hub lacks the archive contract. `storage_error` or
+`recovery_gap` means capture itself may be incomplete. Missing host history is unverified.
+
+## 5. Reconnect or reopen
+
+A saved business conversation restores its original selected accounts only after they all pass
+validation. If it was reopened offline, reconnect and run `/bailinghub archive sync` or
+`/bailinghub scope` in that same conversation. Temporary uncertainty can recover; a revoked or
+replaced authorization, corrupt snapshot, or storage conflict remains blocked for the whole scope.
+There is no automatic fallback to another account.
+
+Restoring scope and retrying uploads does **not** restore unfinished business invocations or
+approvals after a process restart. A never-started saved draft needs selection again. An older
+started conversation with no valid scope snapshot must be left as history; begin a new one.
+Use `/bailinghub sync` only to retry a pending run completion in the still-running conversation.
+
+All selected accounts' context shares the local model conversation. The private local archive
+contains plaintext visible task text and stays on disk until manually removed; it does not capture
+hidden reasoning, attachments, or all past history. Read [Privacy](../PRIVACY.md), and use separate
+conversations when account data must remain separate. Do not paste secrets into visible messages.
+
+If setup fails, include versions, operating system, failed command, and redacted error text in a
+[GitHub Issue](https://github.com/bailinghub/bailinghub-dsh-plugin/issues). Never attach credentials,
+private URLs, authorization codes, personal data, or production payloads.

package/docs/GETTING_STARTED.zh-CN.md

@@ -0,0 +1,113 @@
+# 开始使用 0.4.0
+
+这份指南面向业务系统已经接入 BailingHub 的用户。管理员需要先准备 Core 0.6.1、公开的 Client
+App ID、workspace 和浏览器业务授权入口；已有业务能力无需为多账号重新声明。
+
+## 第一步：安装与配置
+
+使用 Node.js `22.19.0+` 或 `24+`，并安装兼容的 DSH：
+
+```bash
+npm install --global pnpm @deepseek-ai/dsh@0.1.1-rc.2
+dsh plugin --profile web add dsh-bailinghub@0.4.0
+```
+
+插件会自动安装 SDK 0.4.0。通过插件设置填写四项公开信息，或使用对应环境变量。下面都是
+占位值，需要替换成管理员提供的中枢地址、Client App ID 和 workspace：
+
+```bash
+export BAILINGHUB_HUB_URL='https://hub.example.com'
+export BAILINGHUB_CLIENT_APP_ID='example-agent-client'
+export BAILINGHUB_WORKSPACE='order_assistant'
+export BAILINGHUB_CONNECTION_NAME='A 店'
+dsh --profile web --dump-config
+dsh web
+```
+
+`Connection Name` 是你设置的本机名称。这四项都不是凭据；不要把业务密码、Client Token、签名
+密钥、模型 Key、业务 API 地址或授权页面地址写入插件设置或聊天消息。
+
+## 第二步：分别授权账号
+
+在 DSH 中为第一家店执行：
+
+```text
+/bailinghub login
+/bailinghub doctor
+/bailinghub status
+```
+
+浏览器会打开原业务授权页面。在那里登录、切换账号，并按业务系统要求选择门店或租户；同意前
+核对实际业务身份。可信身份由业务授权页面决定，本机名称 `A 店` 不证明身份。
+
+如需使用**同一系统、同一 workspace** 的 B 店，用同样的三项公开信息创建清晰命名的新连接，
+再分别授权：
+
+```text
+/bailinghub connections add "B 店" https://hub.example.com example-agent-client order_assistant
+/bailinghub login
+/bailinghub connections list
+```
+
+请在业务页确认选中了 B 店。如果实际再次同意的是同一可信身份，SDK 会替换它的旧连接和 Session，
+不会凭名称造出第二个身份。从已有名称授权另一身份时，原连接保留，新身份会获得可用别名。
+`default-2` 之类的名称不能证明是哪家店，使用前应核对对应关系。若登录提示需要清理，新连接
+已经授权成功；请检查并删除提示的旧条目，不要重复授权。
+
+## 第三步：选择本次会话的业务范围
+
+**新建会话，在发送任何消息前**执行：
+
+```text
+/bailinghub connections list
+/bailinghub scope set <A店连接键> <B店连接键>
+/bailinghub scope
+```
+
+从列表复制固定连接键替换占位符，不能直接填写连接名称。只操作一家店就选一个键；多份授权
+必须属于相同中枢、Client App 和 workspace。等待设置成功回显后，再发送请求。例如，业务系统
+已开放报表能力时可以说：
+
+```text
+对比今天 A 店和 B 店的营业情况，按门店分别说明。
+```
+
+智能体自行选择每次调用使用哪份选中授权；实际数据和操作范围仍由业务权限决定。先验证一次
+查询，再在开发空间尝试一次可回滚且允许的修改。需要审批的操作继续沿用原规则。
+
+未选择范围，或执行 `/bailinghub scope none` 时，只进行普通聊天，不启动 BailingHub 业务执行。
+第一条消息会固定这个选择。之后要增减账号，或从普通聊天开启业务访问，需要新建会话；切换
+连接管理的默认连接不会改变会话范围。
+
+## 第四步：核对业务结果与沟通过程
+
+在业务后台核对最终结果，在 BailingHub 查看原调用轨迹。配合 Core 0.6.1，还能把可见用户消息、
+助手回复、轮次与相关执行记录放在同一份沟通记录里查看。多授权的各份执行记录仍分别保留自身
+调用摘要。
+
+```text
+/bailinghub archive status
+/bailinghub archive sync
+```
+
+第一条查看上传状态，第二条补传已保存记录，不会重做业务操作。`synced` 表示已保存事件获中枢
+确认，不代表业务成功；`pending` 表示尚未传完；`blocked` 表示原授权当前无法允许上传；
+`unsupported` 表示 SDK 或中枢不支持归档。`storage_error`、`recovery_gap` 表示采集本身可能
+不完整；宿主没有历史可供核对时，覆盖度为未验证。
+
+## 第五步：断网或重开后继续
+
+重开已保存的业务会话时，核验全部原授权后才恢复原账号范围。若离线重开，联网后可以在同一
+会话执行 `/bailinghub archive sync` 或 `/bailinghub scope` 再试一次。临时网络不确定可以恢复；
+已撤销、被替换的授权，损坏的范围快照或存储冲突仍会阻断整组，不会自动换账号。
+
+恢复范围与补传记录，**不等于恢复进程重启前未完成的业务调用或审批**。未开始的保存草稿需要
+重新选择；旧版已开始但没有有效范围快照的会话只能保留为历史，请另开新会话。
+`/bailinghub sync` 只用于当前仍运行会话的待同步执行结尾记录。
+
+所选账号的上下文会共用本地模型会话；本机私有归档含明文任务正文，直到手动清理才删除。它不
+采集隐藏思考、附件或全部历史。启用前请看[隐私说明](../PRIVACY.md)；数据需要隔离的账号应分开
+会话，不要在可见消息里粘贴秘密。
+
+初始化失败时，可向 [GitHub Issues](https://github.com/bailinghub/bailinghub-dsh-plugin/issues)
+提供版本、操作系统、失败命令和脱敏错误，不附带凭据、私有地址、授权码、个人信息或生产载荷。

package/docs/MIGRATION_VNEXT.md

@@ -1,7 +1,67 @@
-# Migration Boundary: Public 0.1.x to Native 0.2
-
-There is no automatic credential, configuration, tool, or orchestration migration from public
-`dsh-bailinghub@0.1.x` to the native 0.2 Agent Client.
+# Migrate to 0.4.0
+
+## 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
+automatically enables it. A new conversation is ordinary chat until you select its scope.
+
+1. Ask the administrator to upgrade the Hub to Core 0.6.1. The plugin installs exact SDK 0.4.0.
+2. Before restarting, finish active business work and retry known pending run completions with
+   `/bailinghub sync`. Do not assume a process restart resumes an invocation or approval.
+3. Upgrade the plugin and restart DSH:
+
+   ```bash
+   dsh plugin --profile web add dsh-bailinghub@0.4.0
+   ```
+
+4. Run `/bailinghub doctor` and `/bailinghub connections list`. Existing valid authorizations can
+   be selected; you do not need to authorize them again merely because the plugin was upgraded.
+5. Start a new conversation. Before its first message, run
+   `/bailinghub scope set <connection-key> [<another-connection-key> ...]`, using fixed keys from
+   the list, then `/bailinghub scope`. Wait for successful confirmation. Select only this task's
+   accounts; several accounts must share one Hub/Client App/workspace.
+6. Try a read, then a reversible permitted update. Check the actual result and original business
+   calls in BailingHub. Use `/bailinghub archive status` to inspect the separate visible record.
+
+Keep old started conversations as history: if they have no valid locked scope snapshot, they
+cannot automatically adopt today's selected connection. A stored draft that never started needs
+explicit selection again. Existing 0.4 saved business conversations can reopen with their original
+scope after every member is revalidated. An offline reopen can retry in the same conversation
+with `/bailinghub scope` or `/bailinghub archive sync` once connectivity returns.
+
+The new archive uploads visible user/assistant text, turn boundaries, and original run links for
+the full frozen member set. Local pending events survive restart and upload without replaying
+business work. It does not backfill all pre-upgrade history or restore unfinished invocations.
+A detectable gap stays `recovery_gap`; missing host history is unverified. Review [Privacy](../PRIVACY.md):
+the local outbox retains plaintext visible text, including acknowledged events, until removed by
+the host/operator. There is no automatic retention cleanup.
+
+### 0.3 用户升级摘要
+
+先由管理员升级 Core 0.6.1；结束当前业务任务并用 `/bailinghub sync` 收口待同步结尾记录，再安装
+`dsh-bailinghub@0.4.0` 并重启 DSH。已有有效授权可继续使用，不必仅因插件升级重新授权。
+执行 `/bailinghub connections list` 后，**新建会话，在首条消息前**用
+`/bailinghub scope set <连接键> [<另一连接键> ...]` 选择账号，并等待 `/bailinghub scope`
+确认。未选范围就只是普通聊天；旧版已开始会话没有范围快照时不能直接恢复业务访问。
+
+上传状态用 `/bailinghub archive status` 查看，联网后用 `/bailinghub archive sync` 补传。
+这会恢复原范围并上传已保存文本，不会恢复重启前的业务调用或待审批操作，也不代表全部旧历史已
+归档。更多步骤见[中文上手指南](GETTING_STARTED.zh-CN.md)与[隐私说明](../PRIVACY.md)。
+
+## Downgrading from 0.4 to 0.3
+
+Finish current business work and synchronize pending completions and archives before an explicit
+downgrade. Keep the old profile and its scope/outbox files intact. Version 0.3.0 does not provide
+0.4's explicit scope gate, multi-authorization conversation, or archive retries; its new conversations
+use its selected default connection. Use a separate profile and new conversation if reverting.
+Do not delete credential or archive files as a downgrade shortcut. A downgrade does not cancel an
+accepted business action or delete its Hub audit.
+
+## Legacy 0.1.x to the native Agent Client
+
+There is no automatic credential, configuration, tool, or orchestration migration from the legacy
+static MCP path. The following boundary remains separate from the 0.3 to 0.4 upgrade above.
 
 ## What remains unchanged
 
@@ -20,9 +80,9 @@ the orchestration. Local DSH does not obtain a trusted Agent Session or dynamic
 The retained [legacy patch](../cordis.patch.yml) documents that historical meaning. It is not
 selected by the current native package metadata, and its presence is not a dual-mode switch.
 
-## What changes in 0.2
+## What changed in 0.2
 
-| Concern | Public 0.1.1 | Native 0.2 |
+| Concern | Public 0.1.1 | Native 0.2 and later |
 | --- | --- | --- |
 | DSH integration | in-box MCP client | native Cordis host adapter |
 | Core unit | governed job | conversation, run, and governed invocation |
@@ -32,40 +92,56 @@ selected by the current native package metadata, and its presence is not a dual-
 | Business identity | not established by DSH | Agent Session approved through the business boundary |
 | Hub audit | job records | conversation, run, completion, and invocation trajectory |
 
+## What 0.3 adds
+
+Version 0.3 keeps the same native boundary and adds stable named multi-connection lifecycle,
+same-binding trusted-identity reconciliation, and Windows CurrentUser DPAPI credential storage.
+It does not reinterpret or migrate the public 0.1.x Client Token path.
+
 The new plugin config is limited to `hubUrl`, `clientAppId`, `workspace`, and `connectionName`.
 The old `BAILINGHUB_CLIENT_TOKEN` is not read, copied, exchanged, or converted into an Agent
 Session. Browser authorization creates a new independently revocable credential in SDK-owned
-secure storage.
+secure storage. The plugin does not accept a business URL: the Hub Client App resolves to one
+stable, account- and tenant-neutral business authorization entry, where the user can log in,
+switch account, and select a tenant.
 
 ## Safe evaluation before migration
 
-Do not replace a working production profile merely to evaluate 0.2.0. Use a separate DSH home or
-another isolated Web profile and verify that the CLI really honors that location.
+Do not replace a working production profile merely to evaluate 0.4.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
+same-binding connection when its trusted `on_behalf_of` is the same; different trusted identities
+remain independent. A different identity returned from a same-alias login keeps the original
+alias and Session and receives a non-conflicting alias that becomes current. Use the exact matching
+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.2 package into an isolated profile.
+2. Install the exact released 0.4.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 business identity/workspace.
-5. Verify status, workspace discovery, one read, one permitted mutation, approval/resume, and Hub
-   trajectory.
+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.
+5. Verify status and workspace discovery. In a new conversation explicitly select its scope, then
+   verify one read, one permitted mutation, approval/resume, and the Hub trajectory.
 6. Separately re-run the `0.1.1` submit and same-job follow-up against the newly released Core.
 
 Passing the native path does not prove legacy compatibility, and passing the legacy path does not
 prove the native Agent Client.
 
-## Moving a profile to 0.2
+## Moving a legacy 0.1 profile to 0.4
 
 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.2 plugin version. Do not use an unpinned dist-tag.
+3. Install the exact accepted 0.4.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`, inspect the business authorization page, and authorize the
-   intended workspace.
-6. Run `/bailinghub status`, open a new conversation, and repeat the accepted read/mutation checks.
+5. Start DSH, run `/bailinghub login`, use the business page to log in or switch account and select
+   a tenant if required, then authorize the intended workspace.
+6. Run `/bailinghub status`, open a new conversation, explicitly select its scope before the first
+   message, and repeat the accepted read/mutation checks.
 7. Confirm BailingHub receives visible conversation and invocation audit without hidden reasoning.
 
 The developer or deployer supplies the Hub URL, public client app id, and initial workspace/route.
@@ -76,6 +152,12 @@ key to this plugin.
 
 Rollback is explicit; it does not convert the Agent Session back into a Client Token.
 
+Before downgrading a 0.3 profile to 0.2, first use the installed 0.3 plugin to finish active runs
+and remove every named instance through `/bailinghub connections remove <name>`. The SDK returns
+the registry to schema v1 after the last such instance is removed. Stable `0.2.0` fails closed on
+schema v2; do not manually delete the registry, Keychain entry, DPAPI ciphertext, or secure file
+credentials as a downgrade shortcut.
+
 1. Finish active native runs and use `/bailinghub sync` for any known pending completion.
 2. Run `/bailinghub logout` if the new Agent Session should be revoked.
 3. Reinstall exact `dsh-bailinghub@0.1.1` in the target profile.
@@ -90,17 +172,19 @@ reuse, move, or republish an npm version or Git tag as a rollback mechanism.
 
 ## Release gates
 
-Before any public 0.2 release:
+Before a public 0.4 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,
    credential, invoke/resume, and completion tests.
-3. Installing only `dsh-bailinghub` into a clean DSH `0.1.0-rc.7` profile installs and resolves that
+3. Installing only `dsh-bailinghub` into a clean DSH `0.1.1-rc.2` profile installs and resolves that
    exact SDK dependency automatically.
 4. Browser login, session isolation, dynamic tool replacement, approval recovery, visible
-   completion, and Hub trajectory pass from the packaged artifact.
+   completion, same-identity replacement, different-identity isolation, explicit one/many-account
+   scope, visible archive, offline reopen/retry, and Hub trajectory pass from the packaged artifact.
+   Revocation must block the complete original selection, and archive retries must not replay business work.
 5. Public `0.1.1` still works against the new Core through the unchanged Client API.
 6. The maintainer explicitly selects the public version and migration story.
 
-Do not tag or publish a future 0.2.x version until all gates pass, and do not describe release
+Do not tag or publish a future version until all gates pass, and do not describe release
 validation as public adoption.

package/docs/PROJECT_BOUNDARIES.md

@@ -21,9 +21,11 @@ BailingHub tool surface.
 DeepSeek and DeepSeek Harness are names of their respective owners. This is an independent
 community integration, not an official DeepSeek plugin or partnership.
 
-## Public native 0.2.0
+## Public native line (0.2.0 onward)
 
-Version 0.2.0 adds a separate dependency path without reinterpreting the public static MCP path:
+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.
+All remain separate from the public static MCP path:
 
 ```text
 DeepSeek Harness local Agent