dsh-bailinghub 0.3.0 → 0.5.0

package/docs/COMPATIBILITY.md

@@ -1,6 +1,94 @@
 # Compatibility
 
-## Native Agent Client 0.3.0
+## Native Agent Client 0.5.0
+
+| Component | Release pairing / requirement |
+| --- | --- |
+| DeepSeek Harness | `0.1.1-rc.2`; real Session and native Cordis lifecycle |
+| 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.5.0` via `./sdk` |
+| BailingHub Core | `bailinghub@0.7.0`, with outstanding migrations through 059 applied |
+| Selected scope | Single account, same-system multiple accounts, or different Client Apps/workspaces on one Hub and audit domain |
+| Original authorization | A distinct original Agent Session for every selected target |
+| Persistence | Existing same-system v1 scope/outbox and cross-system v2 records |
+
+Install `dsh-bailinghub@0.5.0`; its ordinary dependency installs the exact SDK automatically.
+Core 0.6.1 and SDK/plugin 0.4.0 remain the historical same-system baseline, not an alternative
+pairing for new cross-system features. See the [upgrade steps](MIGRATION_VNEXT.md) and
+[release scenario](RELEASE_NOTES_v0.5.0.md).
+
+### Authorization subject display
+
+Core 0.7.0, SDK 0.5.0 and plugin 0.5.0 support business-supplied authorization names. New
+names are optional: an old SDK reports `unsupported`, a missing business name reports `missing`,
+and neither blocks the existing tools. A list may show cached display data without claiming it
+is fresh identity evidence. Current names and cache-write status remain separate from scope,
+credential, archive and business errors. Existing v1/v2 records need no conversion or new labels;
+names never replace their original key, binding or Session. See the
+[display contract](AGENT_CLIENT_CONTRACT.md#authorization-subject-display-050).
+
+### Cross-system scope
+
+Requires Core 0.7.0, SDK 0.5.0 and plugin 0.5.0. Core must advertise
+`cross_binding_members: true` and `member_bindings: "session-client-route.v1"` through
+`bailing.agent-conversation-audit-capabilities.v1`, with its additive target-member migration ready.
+The SDK must implement `getConversationArchiveCapabilities` and the `expectedBinding` dispatch guard.
+Cross-system selection refuses missing support before creating any business run. Existing
+same-system scope and archive interfaces continue using their v1 behavior.
+
+One Hub may contain different Client Apps and workspaces; every target must have a distinct
+original Agent Session. Multiple routes sharing a single Agent Session and cross-Hub conversations
+are outside this release. Hosts using custom stores must preserve scope/outbox v2 records with
+their original bindings and CAS revisions; do not convert v2 into v1 or reconstruct missing state.
+See [the cross-system guide](CROSS_SYSTEM_CONVERSATIONS.md) for usage and limits.
+
+## Historical 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.
+
+For this historical pairing, install `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 |
 | --- | --- |
@@ -80,7 +168,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.3 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.
 
@@ -88,9 +176,13 @@ BailingHub Core release is compatible only after a separate clean legacy profile
 
 Compatibility requires independent evidence for both paths:
 
-1. Native 0.3: clean install of only the exact plugin package, browser authorization, workspace
+1. Native 0.5: 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.
+   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. Verify cross-system routing and same-named tools,
+   unselected-target isolation, metadata before tool search, and duplicate/renamed subject displays.
+   Metadata reads must create no business run; subject names must not change identity or scope.
 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/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,92 +1,152 @@
-# Get started in three minutes
+# Get started with 0.5.0
 
-This guide is for someone whose organization has already connected a business system to
-BailingHub. If that integration does not exist yet, the BailingHub administrator and business
-developer must prepare it before an end user installs this plugin.
+This guide is for users whose business system is already connected to BailingHub. Your
+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.
 
-## What to ask your administrator for
+## 1. Install and configure
 
-Ask for these four public connection values:
+Use Node.js `22.19.0+` or `24+` and the compatible DSH version:
 
-```text
-Hub URL
-Client App ID
-Workspace
-Connection Name
+```bash
+npm install --global pnpm @deepseek-ai/dsh@0.1.1-rc.2
+dsh plugin --profile web add dsh-bailinghub@0.5.0
 ```
 
-They identify the BailingHub application and starting workspace. They are not credentials. Do not
-ask the administrator to send you a Client Token, Tool Provider secret, business password, model
-API key, authorization code, browser session cookie, business URL, or tenant-specific login URL.
-
-## 1. Install the plugin
-
-Install the exact public version into the DSH Web profile:
+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
-dsh plugin --profile web add dsh-bailinghub@0.3.0
+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
 ```
 
-The plugin installs the matching BailingHub SDK automatically.
+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. Enter the four connection values
+## 2. Authorize each account
 
-Use the DSH plugin settings page or these environment names:
+In DSH, authorize the first account:
 
-```bash
-export BAILINGHUB_HUB_URL='https://hub.example.com'
-export BAILINGHUB_CLIENT_APP_ID='example-agent-client'
-export BAILINGHUB_WORKSPACE='employee_assistant'
-export BAILINGHUB_CONNECTION_NAME='default'
+```text
+/bailinghub login
+/bailinghub doctor
+/bailinghub status
 ```
 
-The values above are placeholders. Use the public values from your own BailingHub administrator.
-Never paste credentials into the Cordis patch or a chat message.
+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. 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.
 
-## 3. Authorize in the browser
+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:
 
-Start DSH and run:
+```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.
+
+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 status
-/bailinghub workspaces
+/bailinghub connections list
 ```
 
-`login` opens the one business-side authorization entry configured for the Client App. Sign in or
-switch account there, select a tenant there when the business system asks, and check the resulting
-business identity and requested workspace before approving. Authorization uses the business
-system's own login; it does not send the business password or business URL to the plugin.
+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.
 
-`Connection Name` is only a local selector. If the same trusted business identity authorizes the
-same Hub/client/workspace binding again, the SDK replaces the older local connection. A different
-trusted identity remains separate. When the selected name already belongs to the old identity,
-the SDK preserves it and assigns the new identity an available alias such as `default-2`; the new
-alias becomes current. Run `/bailinghub connections list` to see both and
-`/bailinghub connections use <name-or-key>` to switch. If login says cleanup is required, the new
-connection is already authorized, but an existing connection may still need inspection or
-removal: do not authorize again; list connections and remove the reported old entry.
+## 3. Choose this conversation's business scope
 
-## 4. Try one safe business request
+Start a **new conversation before sending any message**, then run:
+
+```text
+/bailinghub connections list
+/bailinghub scope set <shop-connection-key> <inventory-connection-key>
+/bailinghub scope
+```
 
-Start a new conversation and ask for one read-only action that the connected system exposes, for
-example:
+Copy the fixed connection keys from the list; the scope command does not accept names. Select
+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
-Find the demonstration employee EMP-001 and summarize the visible fields.
+Check tumbler stock. If any are available, change the corresponding shop product to 59 and list it.
+Otherwise leave it unlisted.
 ```
 
-Then try one reversible permitted update in a dedicated development workspace. The exact requests
-depend on the capabilities your business system has exposed. An operation that requires approval
-must continue through the existing approval flow; an operation outside the current identity's
-permissions must remain unavailable.
+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.
 
-## 5. Confirm the result in BailingHub
+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 BailingHub console should show the same visible conversation, Agent Run, governed tool calls,
-approval state, and final result. Do not treat a successful installation alone as proof that a
-business action ran.
+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.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
+/bailinghub archive status
+/bailinghub archive sync
+```
 
-If setup fails, include the DSH version, plugin version, operating system, the command that failed,
-and redacted error text in a GitHub Issue. Never attach tokens, private URLs, personal information,
-authorization codes, or production payloads.
+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.