dsh-bailinghub 0.4.0 → 0.5.0

package/CHANGELOG.md

@@ -1,5 +1,39 @@
 # Changelog
 
+## 0.5.0 - 2026-09-10
+
+### Shop and inventory in one conversation
+
+See [release scenarios and upgrade steps](docs/RELEASE_NOTES_v0.5.0.md): check inventory, update a shop price and follow the listing result or approval. Business tools and confirmed product mappings are prerequisites.
+
+- Show the business-supplied name of an authorized organization, account, project or other subject
+  separately from its product's purpose. Keep local connection selectors independent and explicitly
+  identify missing names, unsupported metadata and cached display data. Renames and duplicate names
+  preserve original scope, Session, invocation and archive identities and historical labels.
+- Understand each selected system's purpose before searching its tools. Read administrator-managed
+  descriptions using the original authorization binding, consistently for one account, multiple
+  accounts in one system, or multiple systems. Descriptions grant no permissions and create no runs.
+- Distinguish unknown or not-yet-loaded capabilities from unavailable services. Missing metadata
+  and older metadata APIs preserve existing business flows; identity failures still block the whole
+  scope. Cancelled description requests cannot replace a newer turn's directory.
+- Select authorized targets from different applications or workspaces on one Hub in the same
+  conversation. The Agent discovers each target's capabilities only when needed; unrelated
+  targets do not automatically receive the full user turn or load their context.
+- Keep same-named capabilities from different systems separate. Each call and recovery retains
+  its original connection, application, workspace, Session, run and invocation.
+- Keep one visible conversation archive with independently verified target members. Persist
+  cross-system scope/outbox v2 while retaining same-system v1 snapshots and APIs.
+- Require explicit SDK/Core capability support for cross-system scope. Older combinations
+  refuse the new mode while retaining existing same-system behavior.
+- Pair with Core 0.7.0 and pin exact SDK 0.5.0. Preserve existing credentials, v1 scopes and original
+  archive events; open a new conversation when choosing targets from different systems.
+- Keep the same-Hub, same-audit-domain boundary. This is not a durable task scheduler, automatic
+  product mapping, stock synchronization, cross-system transaction or business rollback engine.
+- Retain the transitive Hono 4.13.7 update for upstream fixes.
+
+See the [migration guide](docs/MIGRATION_VNEXT.md) for upgrading from 0.4.0 or an older native
+version. Maintainer and synthetic compatibility checks are not independent production adoption.
+
 ## 0.4.0 - 2026-09-08
 
 ### For users

package/PRIVACY.md

@@ -1,6 +1,33 @@
 # Privacy
 
-This bundle adds no telemetry and stores no BailingHub credentials. Version 0.4.0
+## Cross-system conversations in 0.5.0
+
+The 0.5.0 cross-system mode is opt-in through an explicit selected target set on one Hub.
+Before business execution, the original members and the Hub's capability support are verified.
+The Agent initially receives only a directory of authorization references, business subject display
+names, controlled system descriptions, opaque system references and workspace names. Descriptions
+and names are read under the original selection without sending user text or creating a run. A target starts its run only after an explicit capability
+search or recovery selecting that target. The search query becomes that target's task input;
+the full original user message is retained in the independent conversation archive instead of
+automatically being sent to every target's run. Other selected targets may receive authorization
+checks and archive membership confirmation, but no automatic business context request.
+
+Query text is model-authored. Minimal disclosure is instructed, not an automatic redaction or
+field-level data-flow policy: the local model can see all activated target context and the visible
+conversation. Only use a shared conversation where that sharing is allowed. Cross-system object
+relationships must come from verified mappings or explicit user confirmation, not matching names.
+Original system/workspace bindings stay attached to tools, results and execution records.
+
+Cross-system scope and outbox v2 persist each member's public Hub/app/workspace and original
+Session with the same storage protections and plaintext archive boundary below. Same-system v1
+records remain unchanged. The full transcript belongs to the independent Hub management audit;
+holding one target's authorization does not grant full-transcript reading. This release does
+not upload hidden reasoning or provide cross-process business-task recovery.
+
+The following sections describe the retained same-system flow introduced in 0.4.0, and common
+storage/archiving behavior. The cross-system target-query rules above take precedence for v2 scopes.
+
+This bundle adds no telemetry and stores no BailingHub credentials. The native plugin
 persists session-scope metadata and, when the SDK supports conversation archives, a separate
 private outbox containing visible task text as described below.
 
@@ -12,9 +39,9 @@ using personal, confidential, or regulated data.
 Do not include tokens, private URLs, personal information, or production payloads in public
 issues, screenshots, or compatibility reports.
 
-## Native Agent Client 0.4.0
+## Native Agent Client: retained same-system data flow
 
-After explicit nonempty scope selection, the native 0.4.0 plugin sends each direct human user turn
+After explicit nonempty same-system scope selection, the plugin sends each direct human user turn
 to BailingHub Core and receives model-visible instructions, memory, reference-only knowledge, governance, and active tool schemas.
 Business tool arguments and governed results cross the same boundary. At completion it sends a
 hash-aliased message id, legal status, optional model/runtime labels, and numeric public usage. A single-authorization run receives the visible final answer;
@@ -30,9 +57,19 @@ The multi-connection registry contains public connection name, Hub URL, client a
 timestamps, and current-selection state. It does not contain access tokens, refresh tokens, model
 keys, business cookies, prompts, tool arguments, or business results.
 
+## Authorization display metadata
+
+The SDK may cache the business-supplied subject name in a separate private display-only record
+bound to the original connection and Session. A connection list can read that cache without a
+network request; `cache` does not claim the name or authorization was freshly verified. Credential
+storage and the registry are independent. The plugin retains current metadata in memory for
+presentation; a refresh does not rewrite scope, archive events or frozen historical labels.
+Controlled system descriptions are fetched for each selected member and are not persisted by
+this adapter. See the [host contract](docs/AGENT_CLIENT_CONTRACT.md#authorization-subject-display-050).
+
 ## Same-system authorization selection
 
-Version 0.4.0 includes only the authorization keys explicitly selected for a DSH
+The same-system scope introduced in 0.4.0 includes only the authorization keys explicitly selected for a DSH
 conversation, restricted to the same Hub/client/workspace binding. Unset or empty scope means
 ordinary chat: no BailingHub run starts, no BailingHub business tool is registered, and the plugin
 does not send that conversation's user input to a business system. Logging in or selecting a
@@ -42,7 +79,9 @@ DSH, the configured model provider, or unrelated host tools.
 The host snapshots the selected connection bindings and exposes only session-local authorization
 references, local display names, and availability as the selection directory. It does not expose
 the raw registry, credentials, connection keys, or Session inspection responses to the model.
-Local display names are user-controlled labels, not verified business identity claims.
+In 0.5.0, current business-supplied subject names are display metadata, separate from system
+descriptions, frozen historical labels and fixed authorization references. Neither a name nor a
+cached display record proves current identity. Names do not grant permission or rewrite history.
 
 After the full selection is validated, each user turn is sent to a separate Core run under each
 selected authorization to obtain its instructions, governance, memory, and reference-only
@@ -58,7 +97,7 @@ default or silently retaining a subset.
 Each business call uses only its selected authorization. Recovery retains the original
 authorization and invocation. At completion, multi-authorization runs receive separate
 deterministic summaries of their own governed calls, not the combined visible final answer or
-another authorization's results. SDK 0.4.0 with Core 0.6.1 also receives the combined visible
+another authorization's results. SDK 0.5.0 with Core 0.7.0 also sends the combined visible
 conversation through the independent archive boundary below. Single-authorization conversations
 retain the existing visible-answer completion flow.
 Hidden reasoning is never uploaded by the adapter.
@@ -89,7 +128,7 @@ tasks across a process restart.
 
 ## Visible conversation archive
 
-For a nonempty frozen scope, SDK 0.4.0 with Core 0.6.1 receives the claimed user messages,
+For a nonempty frozen scope, SDK 0.5.0 with Core 0.7.0 sends the claimed user messages,
 visible assistant text, turn boundaries, and original run links as one conversation audit owned
 by the complete selected authorization set. Visible text may itself contain personal or business
 data; the adapter does not claim to redact arbitrary secrets pasted into that text. It never adds

package/README.md

@@ -6,14 +6,21 @@ Ask your local DeepSeek Harness Agent to work with a business system connected t
 find records, update allowed fields, and follow the system's existing approval rules.
 BailingHub records which authorization was used and what each business action returned.
 
-**Version 0.4.0 lets one conversation use several authorizations for the same system.** For example,
-after independently authorizing Store A and Store B, select both for a new conversation and ask:
+**Version 0.5.0 lets one conversation use authorizations from different systems on the same Hub.**
+Authorize a shop and inventory system separately, select both for a new conversation and ask:
 
-> 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's price to 59
+> and list it; otherwise leave it unlisted.
 
-The Agent can choose the right authorization for each call without asking you to switch the active
-connection. Available actions still depend on the capabilities and permissions your system exposes.
-This release does not provide orchestration across different systems or routes.
+The Agent reads stock with the inventory authorization, then uses the shop authorization for the
+permitted price and listing actions. Those capabilities must already exist, and the product mapping
+must be confirmed. A stock read does not reserve or synchronize stock. Price changes, listing
+results and approvals are tracked separately.
+
+The 0.4.0 same-system flow remains available: select Store A and Store B to compare sales without
+switching a global connection. New system descriptions explain each selected system's purpose
+before tool search, and business-supplied names identify the approved organization, account or
+other subject. See [what changed and how to upgrade](docs/RELEASE_NOTES_v0.5.0.md).
 
 It also keeps the visible conversation together with links to its business actions. If uploading
 that record fails, it can retry after reconnecting or restarting without repeating those actions.
@@ -25,15 +32,15 @@ recommended by DeepSeek.
 
 You need Node.js `22.19.0+` or `24+`, pnpm, and a compatible DeepSeek Harness release. Your
 administrator must first connect the business system to BailingHub. The matched release set is
-**BailingHub Core 0.6.1 → BailingHub MCP/SDK 0.4.0 → this plugin 0.4.0**.
+**BailingHub Core 0.7.0 → BailingHub MCP/SDK 0.5.0 → this plugin 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
 ```
 
-The plugin installs its exact `bailinghub-mcp-server@0.4.0` dependency automatically.
-For an existing installation, read the [0.3 to 0.4 migration steps](docs/MIGRATION_VNEXT.md).
+The plugin installs its exact `bailinghub-mcp-server@0.5.0` dependency automatically.
+For an existing installation, read the [migration steps from 0.4.0 and earlier](docs/MIGRATION_VNEXT.md).
 
 Follow the [getting started guide](docs/GETTING_STARTED.md) to enter your administrator's four
 public connection values and authorize in the browser. Do not put a business password, Client
@@ -41,21 +48,26 @@ Token, signing secret, or model-provider key into this plugin's settings or chat
 
 ## Choose the accounts for each conversation
 
-Authorize each account separately through the original business authorization page. Give each
-connection a clear local name, such as `Store A` and `Store B`, and verify the actual identity on
-that page. The name is a label you provide; it does not prove identity or grant permission.
-Names like `default` and `default-2` do not tell the Agent which store you mean.
+Authorize each account separately through its original business authorization page and verify the
+approved subject. A compatible business backend supplies its display name automatically, such as
+“Brand flagship store” or “Main warehouse”. A missing name is shown as “Authorization name pending
+sync”; the plugin does not guess it from a local alias.
+
+Names are for display only. Duplicate names and renames do not merge or recreate credentials,
+change an original Session, or rewrite history. Keep the local connection selector and fixed key
+independent from both the current business name and the system description.
 
 In a **new conversation, before the first message**, 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
 ```
 
 Replace the placeholders with the fixed keys from the list, not connection names. You can select
-just one account. Multiple selections must share the same Hub, Client App, and workspace.
+just one account, several accounts in one system, or several systems on the same Hub and audit
+domain. Each selected target must have its own original Agent Session.
 Wait for the command to confirm the selection, then send your request.
 
 **New conversations start as ordinary chat until you select their business scope.** Logging in or
@@ -63,8 +75,8 @@ changing the default connection does not enable business tools. `/bailinghub sco
 chooses ordinary chat. The first user message freezes the selection; start a new conversation to
 change accounts or move from ordinary chat to business access.
 
-For the selected accounts, matching tools are shared. The Agent chooses the authorization for each
-call; it does not receive credentials. Every action still uses that account's own permissions and
+Matching tools within one system are shared; same-named tools from different systems remain
+separate. The Agent chooses the authorization for each call; it does not receive credentials. Every action still uses that account's own permissions and
 approval rules. An approval-required action continues the original call after approval while that
 conversation is still running.
 
@@ -75,7 +87,7 @@ A confirmed revocation or identity change requires a new conversation with a val
 
 ## Follow the conversation and its actions
 
-With Core 0.6.1 and SDK 0.4.0, BailingHub can show the visible user and assistant messages, turn
+With Core 0.7.0 and SDK 0.5.0, BailingHub can show the visible user and assistant messages, turn
 boundaries, and links to the original business runs as one conversation record. Each authorization
 also keeps its own business-call record; the combined reply is not copied into every account's
 memory.
@@ -164,7 +176,7 @@ current-turn dynamic schemas. See the [compatibility matrix](docs/COMPATIBILITY.
 
 Public `dsh-bailinghub@0.1.1` remains the separate static MCP compatibility path. It starts
 `bailinghub-mcp-server@0.1.1`, uses one operator-provided route-scoped Client Token, and leaves
-orchestration in BailingHub. Version 0.4.0 does not read or convert that credential. Keep the exact
+orchestration in BailingHub. The native plugin does not read or convert that credential. Keep the exact
 legacy version when using that path and follow the [migration guide](docs/MIGRATION_VNEXT.md).
 
 Report issues at [GitHub Issues](https://github.com/bailinghub/bailinghub-dsh-plugin/issues) with

package/SECURITY.md

@@ -4,6 +4,39 @@ Report vulnerabilities through a private GitHub Security Advisory in this reposi
 Do not put tokens, private deployment URLs, personal information, or raw business payloads
 in a public issue.
 
+## Cross-system scope in 0.5.0
+
+Different applications/workspaces may participate only through a frozen same-Hub target set,
+with a distinct original Session per target. Capability support must be explicitly negotiated;
+unsupported Core/SDK combinations cannot start cross-system business runs. Each member keeps
+its own app/workspace binding, credential checks, approval rules and original invocations.
+The SDK verifies the full expected binding before target HTTP dispatch, including refresh.
+
+Capability search requires an explicit target and sends a model-authored, task-specific query;
+it cannot fan out to all systems by omitting a selector. Identical tool names or schemas in
+different systems do not establish shared semantics. Scoped aliases map back to an immutable
+original capability and an allowed authorization set. The host enforces target membership;
+it does not automatically prove the business meaning of model-generated queries or arguments.
+
+All original members must remain valid. Temporary validation failure closes a retryable gate;
+confirmed identity replacement or revocation blocks the complete selection. Cancellation and
+late responses cannot reactivate ended-turn tools. Scope/outbox v2 retains original membership,
+event IDs and CAS; a downgrade cannot reinterpret that state as v1. Full transcript reading
+remains in the Hub's management audit boundary, not an individual member's Agent bearer.
+
+## System descriptions and authorization names
+
+System purpose comes from controlled Client/route metadata and is read only for selected original
+bindings before capability search. It is descriptive data, not executable instructions or a grant
+of tools. Business backends supply subject display names for the actual approved identity; names
+remain separate from internal keys, original Sessions and the system description. Only the name
+field is projected, with bounded length, valid Unicode and no control or line-separator characters.
+
+A duplicate or changed name cannot merge authorizations, replace scope members or rewrite archived
+labels. SDK display-cache data is auxiliary and cannot validate credentials or mask a scope/archive
+storage error. Missing or unsupported display metadata leaves existing tools unchanged; a confirmed
+identity failure still blocks the complete selection.
+
 ## Public legacy 0.1.x boundary
 
 This bundle contributes configuration only. It has no custom runtime JavaScript, production
@@ -19,9 +52,9 @@ configuration and are never model tool arguments.
 
 Non-loopback HTTP is denied by default. Do not enable insecure HTTP on an untrusted network.
 
-## Native 0.4.0 boundary
+## Native 0.5.0 boundary
 
-The native 0.4.0 plugin accepts only `hubUrl`, `clientAppId`, `workspace`, and
+The native 0.5.0 plugin accepts only `hubUrl`, `clientAppId`, `workspace`, and
 `connectionName`. The generic SDK owns browser authorization, refresh, and secure credential
 storage; business endpoints and final authorization remain Core/business-system concerns. The
 Hub Client App owns one business authorization entry. That business page, not the plugin or model,
@@ -41,7 +74,7 @@ falsely report a complete logout.
 Tools are Agent/run scoped. Message ids are replaced by Core-safe hash aliases, invocation ids are
 stable 64-character digests, and an `accepted_unknown` outcome must resume that exact invocation
 instead of creating a replacement. Completion retries are bounded and reuse one frozen,
-visible-only payload. Version 0.4.0 installs `bailinghub-mcp-server@0.4.0` as an exact ordinary
+visible-only payload. Version 0.5.0 installs `bailinghub-mcp-server@0.5.0` as an exact ordinary
 dependency and resolves its `./sdk` export. It does not depend on ambient modules, an optional
 peer, a range, a dist-tag, or a local path. Public `0.1.1` does not provide that facade.
 
@@ -52,7 +85,7 @@ plugin never receives the credential value and never writes one into Cordis conf
 
 ## Same-system authorization selection
 
-Version 0.4.0 lets the model select a session-local `authorization_ref` from the current
+The same-system path introduced in 0.4.0 lets the model select a session-local `authorization_ref` from the current
 conversation's directory. This is a constrained per-call selector, not a connection-management
 tool or authority to supply a Hub, route, raw connection key, credential, or business identity.
 The host must first explicitly select fixed connection keys for this conversation through

package/docs/AGENT_CLIENT_CONTRACT.md

@@ -1,17 +1,178 @@
 # Agent Client Host Adapter Contract
 
-Status: native Agent Client contract for `dsh-bailinghub@0.4.0`, paired with
-`bailinghub-mcp-server@0.4.0` and recommended BailingHub Core `0.6.1` (minimum API version
-`0.6.0`). This contract is separate from the legacy static `0.1.x` path. Version 0.3.0 supported user-managed connections but did not include
+## Authorization subject display (0.5.0)
+
+The business backend may supply `subject_display: { name }` for the subject actually approved by
+the user. A subject can be an organization, account, project, department, workspace or another
+business entity; the upstream contract does not prescribe a store or any particular product.
+The name is display data, separate from both trusted authorization identity and `system_info`
+(the product's purpose). Only the trusted business backend supplies this name; the DSH model,
+local alias, device label and principal identifiers are not sources for it.
+
+The matched SDK exposes these additive fields on `login`, `status` and every `connectionsList`
+entry, and the plugin passes them to its host:
+
+| Field | Meaning |
+| --- | --- |
+| `subjectDisplay` | `{ name: string }`, or `null` when unavailable |
+| `subjectDisplayStatus` | `provided`, `missing`, `unsupported` or `unavailable` |
+| `subjectDisplaySource` | `verified` after the SDK reads the original Session, `cache` for display-only local data, otherwise `none` |
+| `subjectDisplayCacheStatus` | SDK auxiliary cache outcome: `saved`, `storage_error` or `not_cached` |
+| `displayLabel` | Plugin presentation label: the provided name, otherwise `Authorization name pending sync` |
+
+Names are trimmed, nonempty, at most 120 UTF-16 code units, with C0/C1 controls and Unicode line
+separators U+2028/U+2029 and unpaired surrogate code units rejected. Valid Unicode emoji are
+preserved. Only the `name` field enters model assembly. A matching name
+does not establish an identity or a business relationship. Cached display data proves no current
+authorization; a real identity-validation failure still blocks the complete original scope.
+An old SDK without these fields yields `unsupported`; a supported response without a name yields
+`missing`. Neither condition prevents the existing authorized tools from working. A display-cache
+write error stays auxiliary and cannot replace a scope/archive `storage_error` or `recovery_gap`.
+
+Custom hosts may omit a user-entered remark/name field and render the returned business name.
+Keep the internal `connectionName` selector and fixed `connectionKey` independently; do not rename,
+merge or recreate credentials because two subjects have the same name or an existing subject is
+renamed. A host may combine a separately trusted product name with this subject name for display.
+When unavailable, localize the generic pending-name message; never guess the name from a product
+description, local alias, principal identifier or list order. Older hosts can keep their current
+connection-management UI unchanged.
+
+`setSessionScope`, `getSessionScope` and `restoreSessionScope` add `subjectDisplay`,
+`subjectDisplayStatus` and `subjectDisplaySource` to each visible authorization. The legacy `label`
+is the frozen historical value: newly selected scopes capture the supplied name (or the generic
+pending-name label), while existing stored labels remain byte-for-byte unchanged. Hosts should
+render the new display fields for current names, not reinterpret an old `label` as verified metadata.
+
+After the whole scope is validated, current display fields are held separately in coordinator
+memory. They do not enter binding comparisons, persisted v1/v2 scope records or archive identity.
+Single, same-system and cross-system model directories include `subject_display`,
+`subject_display_status` and `subject_display_source`, separately from `system_description` and
+`metadata_status`. The current directory `label` and attributed tool-result label use this display
+projection; the original `authorization_ref` remains the only model target selector.
+Scope revalidation refreshes current names without changing the selected members, original Agent
+Sessions, frozen scope revision, historical labels, visible events or archive context. Normal archive
+ACK writes continue their existing CAS sequence; display refresh itself writes no archive record.
+
+## System descriptions (0.5.0)
+
+Core 0.7.0 and SDK 0.5.0 add optional `transport.getSystemInfo({ connectionKey,
+workspace, expectedBinding, signal })`. After the entire selected scope has passed identity
+validation and before first model assembly, the adapter reads one description for each original
+selected member. Requests include the original Hub/Client/workspace/Agent Session binding and
+never user text, tools, or a run identifier. They do not create business runs or load business
+context. Single, same-system multi-authorization and cross-system conversations use the same
+description projection. The existing same-system first-turn run policy remains unchanged.
+
+The response schema is `bailing.agent-system-info.v1`. Only `system.name`, `summary`, `domains`,
+and `boundaries`, their metadata status/revision, and availability enter the model directory.
+System references derive from the verified binding, including for a single authorization or
+same-system group. Product purpose describes typical use; it does not grant an action or prove
+that any tool is enabled. `not_loaded` means not yet loaded, not no capabilities. Product purpose,
+authorization limits, tool loading and availability remain separate fields.
+
+Descriptions are data, not executable model instructions. Missing configuration, an absent SDK
+method, an unsupported old Core or a temporary metadata failure degrades description fields to
+unknown without changing existing capability search. A 401/403 or changed response binding
+blocks the original whole scope. Scope storage errors retain their existing priority. No description
+is persisted in the scope, Session events or archive outbox; each turn reloads against the original
+complete binding, so mutable labels or another runtime cannot supply stale system identity.
+Cancelled or superseded requests cannot publish late metadata or reactivate business tools.
+
+An exact HTTP 404 `route_unavailable` is different from unknown metadata: the selected target
+remains in the directory with `metadata_status: "unknown"`, `availability: "unavailable"` and
+directory-only `availability_reason: "route_unavailable"`. It is not old-version unsupported or
+an authorization grant/revocation. Other ambiguous failures stay unknown. The Core wire's
+`unavailable_reason` still accepts only the documented runtime/direct-switch reasons. A later
+turn retries the same original binding and clears the directory reason after successful lookup.
+
+Hosts keep the existing scope/restore/archive interfaces. The scope view now consistently includes
+`clientAppId` and `systemRef` for all selected authorizations; this is additive and does not change
+stored v1/v2 records. No local hard-coded product dictionary or extra body-reporting channel is
+required. A host may keep a separately controlled fallback when metadata is unavailable, but must
+not infer identity from local labels or expand the selected scope.
+
+## Cross-system extension (0.5.0)
+
+This extension requires SDK 0.5.0 and Core 0.7.0 with migration 058 applied. Subject display
+additionally requires migration 059. Existing same-system behavior, signatures and v1 records
+remain supported; old selected scopes never expand to include newly available targets.
+
+The host selects fixed connection keys from one normalized Hub. Different Client Apps or
+workspaces form different capability sources. Each target must have a distinct original Agent
+Session; two selected routes sharing a Session are rejected. A scope never expands to another Hub,
+registry default, newly added connection, or surviving subset after one member is lost.
+
+Cross-system scope uses persisted `bailing.agent-session-scope.v2` with shared `binding: { hubUrl }`
+and `authorizations` containing `{ connectionKey, sessionId, label, workspace, clientAppId }`.
+The host view keeps `bailing.agent-session-scope.v1` and adds `targetMode: "multi_system"` and
+per-authorization `clientAppId`/`systemRef`. Existing `authorizationRef`, key and lifecycle fields
+retain their meaning. System references are opaque identifiers for capability sources; labels
+remain descriptive data, not business identity or object mappings. The subject-display extension
+above separates current business names from historical local labels.
+
+Selection/restoration verifies the whole original group and calls SDK
+`getConversationArchiveCapabilities({ members })`. Support requires
+`schema: "bailing.agent-conversation-audit-capabilities.v1"`, `cross_binding_members: true`
+and `member_bindings: "session-client-route.v1"`. Missing support produces
+`CROSS_SYSTEM_SCOPE_UNSUPPORTED` and no cross-system business run. Temporary discovery failures
+remain retryable under the original selection; confirmed authorization replacement remains blocked.
+
+Initial prompt assembly registers the target directory, capability search and known-invocation
+recovery tools, without starting any business run. In this mode `search_business_capabilities`
+requires `{ authorization_ref, query, limit? }`. Its bounded query (up to 500 characters) is the
+task projection passed as `userInput` to that target's first `startTurn` in the current turn.
+The original visible user text stays in the independent archive. Subsequent searches reuse that
+target's run. Omission/unknown target fails before dispatch; another selected target is not
+started merely because its authorization is available. Authorization and archive membership checks
+may still inspect the full original set.
+
+Tools are grouped only by capability-source binding and complete declaration. Host-issued
+`bh_...` aliases keep same-named tools from different sources separate, even with identical schemas.
+Each alias enumerates only its own `authorization_ref` values and wraps unchanged business
+`arguments`. The server receives the original tool name. Revisions, invocation IDs, argument
+snapshots and original target bindings remain fixed on replay. The SDK receives host-only
+`expectedBinding: { hubUrl, clientAppId, workspace, sessionId }` together with an explicit key
+on status and all business calls. Model arguments cannot replace these fields.
+Explicit search prioritizes that target's results inside the existing twelve-tool budget;
+same-named capabilities on earlier targets cannot permanently crowd it out.
+
+Recovery accepts only a known original invocation. When needed in a later live turn, it opens
+only that original target's run with a recovery-specific input and resumes the original invocation;
+it does not call the business action again. It does not restore invocation state after process restart.
+Cancellation and superseding turns cannot register tools or dispatch a new write from a late start.
+Each cross-system turn owns an AbortSignal combined with the host's signal. SDK dispatch checks
+that signal after local IO and before HTTP; an in-flight write with an unknown outcome keeps its
+original invocation identity. Completion summaries and archive upload are separate from business
+dispatch cancellation and may still synchronize after a turn ends.
+
+Cross-system archives use `bailing.agent-conversation-outbox.v2`. Context binding is `{ hubUrl }`;
+each member retains `{ connectionKey, hubUrl, clientAppId, workspace, expectedSessionId, label }`.
+Event/ACK schemas, random archive identity, source hashes, ordering, local capture-gap reporting
+and CAS semantics remain unchanged. The SDK uses explicit cross-binding create v2 and each
+member's own credential to confirm; the Core verifies each original app/route/Session and run link.
+The full transcript remains available only through the management audit read boundary.
+
+Query minimization, object mapping and step planning are Agent responsibilities. The runtime
+enforces target/tool/invocation authority; it does not establish a deterministic dependency DAG,
+cross-system transaction, automatic rollback or field-level data-transfer policy. Business systems
+continue owning their capabilities, permission checks, approvals and data semantics. See the
+[user and host guide](CROSS_SYSTEM_CONVERSATIONS.md).
+
+Status: native Agent Client contract for `dsh-bailinghub@0.5.0`, paired with
+`bailinghub-mcp-server@0.5.0` and BailingHub Core `0.7.0`. The same-system scope and archive
+baseline was introduced in plugin/SDK 0.4.0 and Core 0.6.0 (recommended historical Core 0.6.1).
+This contract is separate from the legacy static `0.1.x` path. Version 0.3.0 supported user-managed
+connections but did not include
 explicit conversation scope, multi-authorization tool selection, or the visible conversation archive.
 
 ## Same-System Authorization Selection
 
-This increment supports multiple independently authorized identities for one public
-`Hub + clientAppId + workspace` binding in one DSH conversation. It does not combine different
-systems or routes, alter business capability declarations, or change Core authorization rules.
+The retained same-system path supports multiple independently authorized identities for one
+public `Hub + clientAppId + workspace` binding in one DSH conversation. It uses the existing v1
+records and shared capability declarations. The cross-system v2 path above handles different
+sources; neither path changes Core authorization or business approval rules.
 
-Version 0.4.0 changes the default: a new conversation with no selected scope, or an explicitly
+Version 0.4.0 changed the default: a new conversation with no selected scope, or an explicitly
 empty `connectionKeys: []`, is ordinary chat. It starts no BailingHub run and exposes no BailingHub
 business tools. Browser authorization, the registry's current connection, and the four bootstrap
 fields do not select a conversation's scope. There is no automatic discovery-and-enable fallback.
@@ -125,8 +286,10 @@ frozen scope unchanged. The host must open a new conversation, not treat that re
 successful selection of the requested keys. Revision values may advance more than once
 during selection; always use the returned value for the next compare-and-swap request.
 
-Each returned `authorizations` entry has exactly the public host-facing fields
-`{ authorizationRef, connectionKey, label, workspace }`. The selection accepts at most 64 unique
+Each `authorizations` entry retains the public host-facing fields
+`{ authorizationRef, connectionKey, label, workspace }`. Version 0.5.0 consistently adds
+`clientAppId`, `systemRef` and the current display fields documented above for single, same-system
+and cross-system scopes. The selection accepts at most 64 unique
 connection keys. The trusted host owns `sessionId`: it must remain stable when reopening the same
 conversation and be unique within that store's namespace. Do not let the model or an untrusted
 client choose another conversation's id, edit scope records, or control the storage namespace.
@@ -184,8 +347,10 @@ Restoring a scope does **not** restore an invocation, approval, pending completi
 
 ### Independent visible conversation archive
 
-The visible archive requires SDK `0.4.0` and Core APIs introduced in `0.6.0`; the recommended
-Core release is `0.6.1`. Earlier `0.3.0` SDK/plugin packages do not provide this contract.
+The original same-system visible archive uses SDK APIs introduced in `0.4.0` and Core APIs
+introduced in `0.6.0`; the historical recommended Core release is `0.6.1`. For this release,
+use SDK `0.5.0` with Core `0.7.0`, including cross-system member support. Earlier `0.3.0` SDK/plugin
+packages do not provide this contract.
 After a nonempty scope is frozen, the adapter captures claimed user text, every durable `assistant/message` text block, turn start/end, and verified original run links. It ignores
 `assistant/chunk`, hidden reasoning, attachments, raw provider requests, and arbitrary tool payloads.
 The archive is one record for the complete fixed authorization set; per-authorization run summaries

package/docs/COMPATIBILITY.md

@@ -1,6 +1,49 @@
 # Compatibility
 
-## Native Agent Client 0.4.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 |
 | --- | --- |
@@ -15,7 +58,7 @@
 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
+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
@@ -133,11 +176,13 @@ BailingHub Core release is compatible only after a separate clean legacy profile
 
 Compatibility requires independent evidence for both paths:
 
-1. Native 0.4: 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. Additionally verify explicit single/multiple
    scope selection, full-set archive authorization, offline reopen/retry, revocation, and no business
-   replay after a lost archive acknowledgement.
+   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.