Compatibility

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 and release scenario.

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.

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 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 and the host contract.

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; 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.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.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.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.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 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

The plugin accepts only these four public routing fields:

hubUrl
clientAppId
workspace
connectionName

In Agent Client v1, workspace is the BailingHub route id. Business endpoints, authorization page 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
DeepSeek Harness	0.1.0-rc.7
DSH MCP Client	in-box version shipped by 0.1.0-rc.7
BailingHub MCP Server	exactly 0.1.1
BailingHub Client API	bailing.client-api.v1
Node.js	22.19.0+

Public dsh-bailinghub@0.1.1 remains a configuration-only bundle. It starts the exact bailinghub-mcp-server@0.1.1 stdio command, exposes three fixed governed-job tools, and uses one 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 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.

Release compatibility rule

Compatibility requires independent evidence for both paths:

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. 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.

Passing one path does not establish compatibility for the other.