dsh-bailinghub 0.3.0 → 0.5.0

package/CHANGELOG.md

@@ -1,6 +1,85 @@
 # Changelog
 
-## Unreleased
+## 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
+
+- Use independently authorized accounts for the same system in one conversation. Select Store A,
+  Store B, or both before the first message; the Agent chooses the correct authorization for each
+  available business tool without changing the global connection. Existing permissions and approvals
+  still apply. Different Hubs, Client Apps, and workspaces are outside this release.
+- **New conversations now default to ordinary chat.** Login and connection defaults no longer enable
+  business access. Use `/bailinghub scope set <connection-key>...` and wait for confirmation before
+  the first message; later selection changes require a new conversation. See the [migration guide](docs/MIGRATION_VNEXT.md).
+- Follow visible user/assistant messages, turn boundaries, and links to original business runs in
+  a separate conversation archive with Core 0.6.1. Multi-account runs keep their own call summaries;
+  the combined reply is not broadcast into each account's memory. Hidden reasoning is excluded.
+- Check `/bailinghub archive status` and retry `/bailinghub archive sync` after a failed upload or
+  restart. Saved events retain their original identity; retries do not execute business actions again.
+- Recover the original saved scope after an offline reopen on the same runtime once connectivity
+  returns and every original authorization is valid. Revocation, identity replacement, and storage
+  conflicts still block the whole scope. Scope restoration does not restore unfinished invocations,
+  approvals, or tasks after a process restart.
+
+### Reliability and integration
+
+- Persist non-secret scope snapshots and a separate private visible-text outbox with revision checks,
+  cross-process locks, and atomic file replacement. Expose host selection, restore, archive status,
+  and archive sync APIs. Reopened unlocked drafts require explicit confirmation; started conversations
+  without valid locked scope cannot adopt current defaults. Metadata alone does not lock a draft.
+- Share matching typed business tools once. Multi-authorization calls use a host-issued reference
+  outside the unchanged business arguments; single-authorization arguments remain unchanged. Keep
+  the 12-tool total budget, reject conflicting declarations, and retain original invocation bindings
+  across turns of the same live conversation.
+- Preserve stable archive event ids, original run links, and acknowledgement cursors through ambiguous
+  network retries. Report detectable missing history as `recovery_gap`, and unavailable history as
+  unverified. Local write failures and unsaved events remain visible while uploads are blocked.
+  Archive capability network failures report pending, not a false storage error.
+- Recheck the original scope after asynchronous archive capability discovery and opening, so a
+  revocation confirmed during that work cannot return a misleading synchronized status or allow upload.
+  Concurrent business and archive callers wait for the current whole-scope validation.
+- Keep cancelled turns ended when their original run response arrives late. Retain only the original
+  audit link, without reactivating tools, dispatching remaining members, or replacing a newer turn.
+- Pin exact `bailinghub-mcp-server@0.4.0`. Injected older SDKs retain business operations with an
+  explicit unsupported archive status. Keep the separate public `0.1.1` static MCP path unchanged.
+
+The archive stores plaintext visible task text locally, including acknowledged events, until the
+host/operator removes it. It does not export all past conversations or attachments. Review
+[Privacy](PRIVACY.md) before enabling business scope; release verification is not production adoption.
 
 ## 0.3.0 - 2026-09-01
 

package/PRIVACY.md

@@ -1,6 +1,35 @@
 # Privacy
 
-This bundle adds no telemetry and stores no BailingHub credentials or task payloads.
+## 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.
 
 Task text submitted through the installed tools is sent to the BailingHub deployment chosen
 by the operator. DeepSeek Harness, the configured model provider, BailingHub, and the target
@@ -10,13 +39,14 @@ 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.3.0
+## Native Agent Client: retained same-system data flow
 
-The native 0.3.0 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 only
-the hash-aliased assistant message id, visible final text, legal status, optional model/runtime
-labels, and numeric public usage. It ignores `assistant/chunk` and never uploads hidden reasoning.
+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;
+multi-authorization runs receive only their own deterministic call summaries. It ignores
+`assistant/chunk` and never uploads hidden reasoning.
 
 Browser authorization, refresh, and credential storage remain SDK-owned; this adapter stores no
 BailingHub credential. The SDK uses macOS Keychain, Windows CurrentUser DPAPI, or an explicitly
@@ -26,3 +56,106 @@ business-system retention boundaries before enabling the plugin.
 The multi-connection registry contains public connection name, Hub URL, client app id, workspace,
 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
+
+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
+registry default does not select a conversation scope. This does not change the data boundary of
+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.
+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
+knowledge. The local Agent and its model
+provider therefore receive context from multiple authorized identities in the same conversation.
+Authorization labels preserve attribution; they do not create isolation from the local model.
+Use separate conversations when those identities' data must not share that boundary.
+The host must await and display scope confirmation before sending the first message. That first
+user message freezes the selection. A failed selection or any unavailable selected
+authorization pauses all BailingHub business access for the conversation, without switching to a
+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.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.
+
+The host checks the captured connection key, workspace, and original Agent Session id before
+transport operations without projecting those inspection fields into the model's directory.
+Invocation bindings are local to the running conversation; a new conversation or process restart
+does not recover unknown invocation ids from that map.
+
+The default file adapter saves scope schema/version, DSH session id, revision, lock/state, public
+Hub/client/workspace binding, and the selected connection keys, sanitized labels, workspace, and
+original Agent Session ids. These identifiers stay host-side; the snapshot contains no access or
+refresh token, browser credential, prompt, business argument/result, or invocation state. Files
+are stored under `$DSH_HOME/plugins/dsh-bailinghub/session-scopes` (`~/.dsh` is the default home),
+with hashed session filenames and, on POSIX, mode-0600 files and mode-0700 directories. They remain local until
+removed by the host/operator; the adapter does not upload them. An embedded host may inject its
+own durable store and retention policy. The explicit memory store is not persistent, and storage
+failure never causes an automatic switch to it.
+
+On reopening a conversation, only a valid locked scope is restored after its binding and original
+Agent Sessions are rechecked. A stored unlocked draft needs explicit scope confirmation again;
+loading it does not query its old authorizations or send them user input. A failed replacement
+write can leave that draft on disk, but it still cannot reactivate automatically in a new runtime.
+Configuration or metadata history alone does not lock a never-started draft. Missing or invalid
+scope snapshots on started conversations do not adopt current registry connections.
+Restoring that scope does not recover pending business invocations, approvals, completions, or
+tasks across a process restart.
+
+## Visible conversation archive
+
+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
+SDK credentials, hidden reasoning, raw provider requests, attachments, or arbitrary tool payloads.
+The combined conversation is not broadcast to each authorization's memory. Empty scope remains
+outside this archive boundary. Review the whole selected group's data-sharing permission before
+sending the first message.
+If an original run response arrives after cancellation, only its audit link is retained for that
+ended turn; it does not reactivate business tools, dispatch remaining members, or replace a newer turn.
+
+The independent outbox lives under `$DSH_HOME/plugins/dsh-bailinghub/conversation-outbox` by default.
+It contains a random persistent archive id, frozen public bindings/original Session ids, visible
+events, hashes, and synchronization cursor. POSIX directories use `0700` and files `0600`; text is
+not encrypted by this adapter. Outboxes remain on disk, including acknowledged events, until the
+host/operator removes them. Hosts may inject a different durable store and retention policy;
+there is no automatic retention cleanup or deletion of the separate Hub audit. Removing a local
+outbox loses retry identity/history and must not be treated as deleting the remote record.
+
+Network failures preserve successfully written events for later upload. Local write failures do
+not prove durable capture. Reopened DSH history is checked for detectable missing visible events,
+reported as `recovery_gap`; unavailable host history is marked unverified. Previously unarchived
+messages, attachments, and hidden content are not claimed as a complete transcript. The archive
+does not restore business invocation or approval execution after restart. An older SDK reports
+unsupported without creating an outbox, and business calls remain available.
+
+An offline reopen keeps the original frozen scope closed until every member can be revalidated.
+A later retry on the same runtime may recover a temporary network failure, but cannot recover
+confirmed revocation, replacement identity, or a storage conflict. Archive status retains known
+unsaved events and history gaps while upload is blocked. Revocation confirmed during asynchronous
+archive capability discovery or opening is rechecked before reporting availability or uploading.