dsh-bailinghub 0.4.0 → 0.6.0

package/CHANGELOG.md

@@ -1,5 +1,113 @@
 # Changelog
 
+## 0.6.0 - 2026-09-16
+
+See [scenarios and upgrade](docs/RELEASE_NOTES_v0.6.0.md) · [English](docs/RELEASE_NOTES_v0.6.0.en.md).
+
+- Bind administrator-created tasks through persistent taskStore and public host APIs. Preserve original members, cumulative budgets, cancellation and read-only receipt inspection; models cannot create or switch tasks.
+
+- Let a conversation panel inspect a pending shop listing or inventory change
+  after reopening, without starting a model turn or business run. Explicit continuation
+  first inspects the original receipt, preserves approval and task controls, and never
+  replaces an uncertain write. Panel and model actions serialize the same invocation.
+  Preserve local storage errors, cancellation and original retry deadlines. See the
+  [host integration contract](docs/TASK_CONTROL.md).
+
+- Let a host read original conversation and selected shop/inventory authorization
+  coordinates through `getSessionTaskCoordinates(session)` when preparing a governed
+  task. Revalidate the complete original group without locking a draft, creating a
+  run or exposing unselected targets. Keep persistence failures distinct from
+  retryable network failures and unsupported versions. Existing task binding and
+  execution rules remain in force; see [the host contract](docs/TASK_CONTROL.md).
+
+- Let an opted-in host retain complete shop, inventory or other business tool
+  declarations across user messages in the same living Session. Prepare current
+  target context once per user turn; valid exact-name lookups need no additional
+  capability-search request. Ordinary chat starts no business run.
+- Bound the session cache to 64 target-tool pairs and 2 MiB, with a 12-schema
+  presentation window. Separate cached declarations from currently prepared tools;
+  return full schemas and current context through the existing search entry point.
+- A direct unprepared cached call returns preparation only. It creates no business
+  invocation, and replaying its call ID cannot turn it into a write. Current identity,
+  declaration changes, cancellation and original-invocation recovery remain enforced.
+- Keep legacy `active_turn` behavior by default. Hosts explicitly enable
+  `toolLifecycle: 'session'` after handling preparation results. Core and SDK need
+  no additional API for this candidate. See [the integration contract](docs/SESSION_TOOL_REUSE.md).
+
+- Preserve an authoritative `invocation_not_found` response during polling and
+  direct recovery. Stop automatic retries and ask for inspection of the original
+  execution evidence, without declaring the business action unexecuted or creating
+  a replacement write. Generic network/HTTP failures retain conservative recovery.
+
+- Reopen a conversation after pending approval or a lost business response and recover
+  the original invocation through a durable, metadata-only local journal. Persist the
+  original authorization, run, invocation and parameter digest before dispatch; never
+  rebuild a business write from transcript text or substitute another account.
+- Custom hosts can supply an invocation store and inspect or restore its local status.
+  Storage failures remain explicit. Restoring metadata sends no business recovery
+  request; an explicit resume may continue the original approved operation.
+  See [reopening and original invocation recovery](docs/INVOCATION_RECOVERY.md).
+
+- Keep long tasks moving between product creation, queries and inventory checks:
+  searches merge valid tools during the active turn instead of unloading the previous
+  batch. Retain up to 64 callable tools behind a 12-schema model window; unchanged
+  registrations survive concurrent discovery and calls.
+- Invalidate only the changed authorization catalog, quarantine contradictory
+  declarations, and preserve original invocation recovery and cancellation boundaries.
+  See [long-task lifecycle and host upgrade guidance](docs/CAPABILITY_FEEDBACK.md).
+
+- Honor Hub retry delays after pre-dispatch rate limiting. Long waits retain the original invocation for later recovery; early manual resumes avoid extra requests. Shared quota details stay visible to the model.
+
+- Add an image-first Local Agent attachment space for adapted hosts: list approved conversation
+  outputs, upload 1–8 PNG/JPEG/WebP images to an explicitly selected authorization, and reuse
+  ready URLs with existing business tools. Persist original upload records for recovery.
+- See [attachment integration](docs/GENERATED_ARTIFACTS.md) for campaign artwork, charts
+  and shop examples. Host file access is explicit; upload success and business action results
+  are independent. Business limits and original-call recovery remain independent from attachment delivery.
+
+- Explain each search target’s returned candidates separately from the conversation’s
+  currently loaded tools. Keep unknown totals explicit and describe the shared loading limit.
+- Return actionable, safe failure feedback through native DSH dispatch, including retired
+  tool names rejected before the business SDK. Valid loaded tools remain directly callable.
+- Keep an unconfirmed write bound to its original invocation; discovery cannot create
+  a replacement operation. Add read-only feedback seams for custom hosts.
+- See [capability discovery and recovery](docs/CAPABILITY_FEEDBACK.md) for shop/inventory
+  examples, compatibility and exact candidate installation requirements.
+
+## 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,15 +97,19 @@ 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.
 
 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.
+Invocation bindings stay host-side. The [durable recovery journal](docs/INVOCATION_RECOVERY.md)
+adds a separate `invocation-records` store in the plugin data directory for original binding
+metadata, parameter/receipt digests, last-known state and retry deadline. It stores no raw
+arguments, receipt bodies, credentials or conversation text. Records remain until the host/operator
+removes them; there is no automatic cleanup or upload of this journal. The same original Session
+can recover known calls after reopening; new conversations and unknown IDs cannot use that binding.
 
 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
@@ -84,12 +127,13 @@ loading it does not query its old authorizations or send them user input. A fail
 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.
+Restoring the scope alone does not recover pending business invocations, approvals, completions,
+or tasks across a process restart. Original invocation recovery requires the separate durable
+journal and an explicit recovery request; it does not automatically resume the whole task.
 
 ## 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
@@ -112,7 +156,8 @@ Network failures preserve successfully written events for later upload. Local wr
 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
+does not itself restore business invocation or approval execution after restart; the separate
+invocation journal does not make an incomplete visible archive complete. 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.
@@ -120,3 +165,8 @@ A later retry on the same runtime may recover a temporary network failure, but c
 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.
+
+
+## Task records in 0.6.0
+
+A private persistent task store binds the original Session, fixed members and administrator-created task. It does not store administrative credentials or grant model task-management authority. Retain original scope, task, invocation and archive records; storage errors never downgrade to an unrestricted flow. Task enrollment persists on the original Agent Session even after cancellation. Do not downgrade an enrolled authorization to a host/Core that ignores that requirement. See [task control](docs/TASK_CONTROL.md) and [upgrade](docs/UPGRADE_v0.6.0.en.md).

package/README.md

@@ -1,19 +1,33 @@
 # BailingHub for DeepSeek Harness
 
+## 0.6.0: longer tasks, attachments and original-call recovery
+
+Retain the correct target while moving between edits and queries, reuse uploaded image URLs and inspect original calls after reopening. Task budgets survive turn changes. Pair Core 0.8.0 / SDK 0.6.0 / DSH 0.6.0; host integration is required for task binding and opt-in cross-turn reuse.
+
+[Changes](docs/RELEASE_NOTES_v0.6.0.en.md) · [Upgrade](docs/UPGRADE_v0.6.0.en.md)
+
+
 [简体中文](docs/README.zh-CN.md) | English
 
 Ask your local DeepSeek Harness Agent to work with a business system connected to BailingHub:
 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:
+
+> Check tumbler stock. If any are available, change the corresponding shop product's price to 59
+> and list it; otherwise leave it unlisted.
 
-> Compare today's sales at Store A and Store B. Show each store separately.
+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 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 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.
@@ -21,19 +35,20 @@ that record fails, it can retry after reconnecting or restarting without repeati
 This is an independent community integration, not a plugin developed, certified, endorsed, or
 recommended by DeepSeek.
 
+
 ## Install and start
 
 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.8.0 → BailingHub MCP/SDK 0.6.0 → this plugin 0.6.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.6.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.6.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 +56,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 +83,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 +95,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.
@@ -156,6 +176,7 @@ identity separately. Custom DSH hosts must implement the [scope selection and re
 and display confirmation before the first message. The native slash commands already use those
 APIs. Tool envelopes, persistence, event schemas, and recovery limits are documented in the
 [Agent Client contract](docs/AGENT_CLIENT_CONTRACT.md).
+For the Local Agent attachment space (image-first), see [host artifact integration](docs/GENERATED_ARTIFACTS.md). Register approved conversation outputs, upload them once, and use ready URLs with existing business tools.
 
 Use Native Tool Mode. DSH Code Mode is deliberately degraded because it cannot safely present the
 current-turn dynamic schemas. See the [compatibility matrix](docs/COMPATIBILITY.md).
@@ -164,9 +185,18 @@ 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
 versions and redacted errors. Do not include tokens, private URLs, personal data, or production
 payloads. Compatibility tests and package downloads are not evidence of production adoption.
+
+
+## Recover an original action after reopening
+
+Version 0.6.0 adds a local invocation journal for actions such as a product listing
+awaiting approval or an inventory update whose response was lost. Reopen the same conversation
+and explicitly recover the original call without creating a second business request. Custom
+hosts must retain the new store alongside their existing Session scope. See the
+[recovery contract, limits and host integration](docs/INVOCATION_RECOVERY.md).

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
@@ -85,8 +118,11 @@ Each invocation binds its chosen authorization, Core run, and capability revisio
 accepts only an invocation known to this conversation and resolves its original binding; the
 model cannot provide a replacement authorization. Changing a default connection cannot retarget
 an existing call.
-This invocation map lasts only for the live conversation: later turns can recover its original
-calls, while new conversations and process restarts must reject unknown invocation ids.
+The live invocation map supports later turns of the same conversation. The unreleased
+[durable recovery journal](docs/INVOCATION_RECOVERY.md) additionally persists original
+metadata before dispatch and validates it after reopening. New conversations, missing records,
+and conflicting original identities still reject recovery. Raw parameters and credentials do
+not belong in the invocation journal; model text never reconstructs its authority.
 
 Only non-secret scope metadata belongs in the scope store. Its default file store uses SHA-256 session filenames,
 mode-0600 files and mode-0700 directories on POSIX, bounded reads, rejection of symlinks/non-regular files,
@@ -141,3 +177,8 @@ that validation. Confirmed revocation/replacement and storage/CAS conflicts rema
 blocked, with no default or subset fallback. The gate is rechecked after asynchronous archive
 capability discovery and outbox opening; a late result cannot erase a confirmed revocation.
 Known local storage errors and capture gaps remain visible even while network or scope checks block upload.
+
+
+## Task records in 0.6.0
+
+A private persistent task store binds the original Session, fixed members and administrator-created task. It does not store administrative credentials or grant model task-management authority. Retain original scope, task, invocation and archive records; storage errors never downgrade to an unrestricted flow. Task enrollment persists on the original Agent Session even after cancellation. Do not downgrade an enrolled authorization to a host/Core that ignores that requirement. See [task control](docs/TASK_CONTROL.md) and [upgrade](docs/UPGRADE_v0.6.0.en.md).