dsh-bailinghub 0.5.0 → 0.7.0

package/docs/GETTING_STARTED.md

@@ -1,7 +1,7 @@
-# Get started with 0.5.0
+# Get started with 0.6.0
 
 This guide is for users whose business system is already connected to BailingHub. Your
-administrator must prepare Core 0.7.0, a public Client App ID, a workspace, and the business
+administrator must prepare Core 0.8.0, a public Client App ID, a workspace, and the business
 browser-authorization entry first. For multiple systems, prepare one independently authorized
 connection per target on the same Hub and audit domain. Existing business capability declarations
 remain valid; each requested action must already be exposed by its own system.
@@ -12,10 +12,10 @@ Use Node.js `22.19.0+` or `24+` and the compatible DSH version:
 
 ```bash
 npm install --global pnpm @deepseek-ai/dsh@0.1.1-rc.2
-dsh plugin --profile web add dsh-bailinghub@0.5.0
+dsh plugin --profile web add dsh-bailinghub@0.6.0
 ```
 
-The plugin installs SDK 0.5.0 automatically. Enter the four public values in DSH plugin settings,
+The plugin installs SDK 0.6.0 automatically. Enter the four public values in DSH plugin settings,
 or use their environment names. The example values below are placeholders:
 
 ```bash
@@ -115,7 +115,7 @@ connection does not change a conversation's scope.
 ## 4. Check results and the visible conversation
 
 Check the actual business result and its original invocation trail in BailingHub. With the matching
-Core 0.7.0, you can also follow visible user/assistant messages, turns, and the linked runs as one
+Core 0.8.0, you can also follow visible user/assistant messages, turns, and the linked runs as one
 conversation record. Multi-authorization runs keep their own call summaries separately.
 
 ```text

package/docs/GETTING_STARTED.zh-CN.md

@@ -1,6 +1,6 @@
-# 开始使用 0.5.0
+# 开始使用 0.6.0
 
-这份指南面向业务系统已经接入 BailingHub 的用户。管理员需要先准备 Core 0.7.0、公开的 Client
+这份指南面向业务系统已经接入 BailingHub 的用户。管理员需要先准备 Core 0.8.0、公开的 Client
 App ID、workspace 和浏览器业务授权入口。多系统时，每个目标分别授权，且属于同一中枢、同一
 审计域；已有能力无需重新声明，但每项动作必须已由相应业务系统开放。
 
@@ -10,10 +10,10 @@ App ID、workspace 和浏览器业务授权入口。多系统时，每个目标
 
 ```bash
 npm install --global pnpm @deepseek-ai/dsh@0.1.1-rc.2
-dsh plugin --profile web add dsh-bailinghub@0.5.0
+dsh plugin --profile web add dsh-bailinghub@0.6.0
 ```
 
-插件会自动安装 SDK 0.5.0。通过插件设置填写四项公开信息，或使用对应环境变量。下面都是
+插件会自动安装 SDK 0.6.0。通过插件设置填写四项公开信息，或使用对应环境变量。下面都是
 占位值，需要替换成管理员提供的中枢地址、Client App ID 和 workspace：
 
 ```bash
@@ -101,7 +101,7 @@ B 店连接可以继续保留。
 
 ## 第四步：核对业务结果与沟通过程
 
-在业务后台核对最终结果，在 BailingHub 查看原调用轨迹。配合 Core 0.7.0，还能把可见用户消息、
+在业务后台核对最终结果，在 BailingHub 查看原调用轨迹。配合 Core 0.8.0，还能把可见用户消息、
 助手回复、轮次与相关执行记录放在同一份沟通记录里查看。多授权的各份执行记录仍分别保留自身
 调用摘要。
 

package/docs/INVOCATION_RECOVERY.md

@@ -0,0 +1,182 @@
+# Reopen a conversation and recover its original business actions
+
+Available in DSH 0.6.0 with SDK 0.6.0 and Core 0.8.0. Configure a durable invocation store and preserve original Session records.
+
+A shop listing may still await approval when a user closes the Agent. An inventory
+adjustment may have reached the server even though its response was lost. Reopening
+the same conversation must keep those actions attached to their original accounts
+and calls. It must not create a second listing or stock adjustment from remembered text.
+
+The plugin adds durable **invocation metadata**, separate from the visible conversation
+archive and attachment space. It retains the original fixed scope fingerprint/revision,
+connection key, Hub/client/workspace, Agent Session, authorization reference, run,
+invocation ID, tool name, declaration revision, host call ID and parameter digest.
+It also stores the last received state, receipt digest and retry deadline. It does not
+store credentials, raw tool arguments, receipt bodies or conversation text in this journal.
+Digests support association and change detection; they are not independent tamper-proof evidence.
+
+## What happens before and after reopening
+
+1. Before a new business request leaves the host, save its original binding using
+   compare-and-swap (CAS). If that cannot be confirmed, do not send the request.
+2. After a response, save only its state and digest. A failed save remains
+   `storage_error` with an unsaved record. A successful business response does not
+   erase the local recovery-storage error.
+3. Reopen the real DSH Session with its original persisted events and scope. Reuse
+   its invocation store. Do not create a replacement Session or replay user messages.
+4. Inspect or restore local invocation metadata. This does **not** create business
+   runs, invoke/resume business actions, or restore old dynamic tools.
+5. When the user or Agent explicitly requests recovery, call
+   `resume_governed_tool_invocation` with only the original `invocation_id`. The plugin
+   verifies every original scope member and uses that call's original target. It sends
+   `resume` with the original ID and an empty payload, never a replacement `invoke`.
+
+`resume` is **not a read-only status operation**: Core may continue an approved or
+otherwise resumable original operation. Unknown dispatched writes remain subject to
+Core's existing reconciliation and approval rules. Reopening alone does not do this.
+This feature does not automatically continue a whole task, DAG or sequence of actions.
+When the user starts a new recovery turn, the existing runtime may create a current-turn
+run for the original selected target to keep the new conversation/audit association.
+That run never replaces the recovered call's original run or invocation. The startup and
+local status/restore stage creates no such run.
+
+A local last-known state is not current server proof (`result_verified: false`). After
+full reopening, recovery obtains the original server receipt even if local metadata says
+`executed`. Within a living host, its original confirmed response may be reused. A
+cancelled or ended turn can retain late original receipts without re-enabling its tools.
+
+## Host integration
+
+The default plugin uses its protected `invocation-records` directory under the DSH
+plugin data directory. A host supplying a custom `scopeStore` must **explicitly** supply
+an `invocationStore`; omission preserves existing business behavior but does not support
+durable recovery after a full restart. `null` also explicitly disables the new store.
+
+```js
+import { createAgentClientPlugin, createFileInvocationStore } from 'dsh-bailinghub'
+
+const plugin = createAgentClientPlugin({
+  scopeStore: hostScopeStore,
+  archiveStore: hostArchiveStore,
+  invocationStore: createFileInvocationStore({ directory: hostInvocationDirectory }),
+})
+```
+
+Place `hostInvocationDirectory` in the same durable, access-controlled host data area as
+the original Session scope. Never derive it from model input. An explicit memory store
+is exported for tests; a new empty memory store is not persistence after process restart.
+
+Custom adapters implement the same asynchronous interface:
+
+```js
+await store.load(sessionId) // null or the complete metadata record
+await store.save(sessionId, nextRecord, expectedRevision) // return saved record
+```
+
+The current record schema is `bailing.agent-invocations.v2`; original v1 records
+without task bindings remain readable and do not acquire a task implicitly.
+Its top-level fields are `schema`,
+`sessionId`, `revision`, `entries`. Revisions start at 1; missing expects `null`. Save must
+atomically compare the previous revision, persist the full record, and acknowledge only
+after durable success. A load error must not return `null`. Custom stores must retain
+the strict metadata-only field restrictions and enforce the same 8 MiB record bound.
+
+In the standard DSH command interface, `/bailinghub invocations status` reads this
+status and `/bailinghub invocations restore` retries only the local metadata save.
+Neither command calls the business resume endpoint.
+
+The runtime exposes:
+
+| Interface | Effect |
+| --- | --- |
+| `getSessionInvocationStatus(sessionId)` | Verify original scope and read local journal status. |
+| `restoreSessionInvocations(sessionId)` | Verify scope and flush pending local metadata with original CAS identity. No business invocation or resume. |
+| `inspectSessionInvocation(realSession, invocationId, { signal }?)` | Read the original remote receipt without a model turn or new run. Does not continue an approved action. |
+| `resumeSessionInvocation(realSession, invocationId, { signal }?)` | Explicitly inspect, then continue an eligible original undispatched action at most once. Later observation is read-only. |
+
+The first two return `state`, `entries`, `unsavedRecords`, plus `revision`/`reason` when available.
+Each entry has `invocation_id`, `authorization_ref`, `tool`, `original_run_id`,
+`last_known_state`, `retry_at`, and `result_verified: false`. Treat tool names as data.
+Do not turn these entries into new calls or consider the task complete from this list.
+
+The two remote actions require the actual Session and return a
+`bailing.agent-session-invocation-action.v1` envelope. `ready` means the interface
+returned normally, not that the business action succeeded. `resume_dispatched`
+only reports whether the runtime submitted resume to the SDK, not whether the
+Hub received it or the business action ran; read the original receipt for
+business state. A missing result remains unconfirmed. Storage or coverage failures
+retain priority, and a failure after sending resume never proves no dispatch occurred.
+See the [idle-panel integration and failure contract](TASK_CONTROL.md).
+
+| State | Host action |
+| --- | --- |
+| `ready` | Metadata is readable and saved; explicit original-call recovery is available for known records. This is not a claim that every historical call has a journal record. It does not confirm Core connectivity or the business outcome. |
+| `inactive` | No selected business scope, or the conversation has not started. Ordinary chat makes no Hub request for this journal. |
+| `unsupported` | No invocation store. Existing same-host business/recovery behavior is retained. |
+| `blocked` | Original scope or invocation binding is unavailable/conflicting. Do not switch account or use a surviving subset. |
+| `storage_error` | Restore local persistence first. Keep unsaved records and the original call identity. |
+
+Keep conversation archive `storage_error`, `unsavedEvents` and `recovery_gap` visible
+independently. A `ready` invocation journal cannot make an incomplete transcript complete. If local
+metadata is unsaved while authorization is also blocked, preserve `storage_error` and
+`unsavedRecords` as the primary state, with `scope_state: blocked` and `scope_reason`;
+this does not enable business access or discard either failure.
+
+## Failure and compatibility rules
+
+- `invocation_store_unavailable` / `invocation_store_conflict`: category `storage_error`,
+  next action `restore_invocations`. Do not interpret `not_dispatched` on a failed
+  recovery attempt as evidence that the original business action never ran.
+- `invocation_binding_unavailable` / `invocation_binding_conflict`: inspect original
+  evidence. Never guess the binding from transcript text or accept model-supplied targets.
+- `invocation_store_unsupported`: the host has not enabled durable invocation storage.
+- An authoritative HTTP 404 with SDK `publicCode=invocation_not_found` stops the
+  current recovery poll immediately, even if an older receipt said `awaiting_approval`.
+  Both the native model tool and direct `runtime.resume` preserve the original ID in
+  `feedback`: `category=invocation_outcome_unknown`, `code=invocation_not_found`,
+  `next_action=inspect_original`, `retryable=false`, `original_outcome=unverified`.
+  Dispatch remains `attempted` or `unknown`; the original business outcome is not
+  declared unexecuted. The local journal, scope and original run are retained.
+  Inspect that call's original evidence instead of retrying automatically or
+  reconstructing a new write. The existing feedback schema and host APIs are unchanged.
+- An arbitrary 404, a message containing that name, a missing public code or a
+  conflicting status is not authoritative not-found evidence. Older SDKs and custom
+  transports keep conservative bounded recovery for unconfirmed requests. A timeout
+  or temporary network failure does not become a missing-record diagnosis.
+- Existing SDK/Core network, authorization, unsupported and reconciliation feedback
+  continues unchanged. No new Core endpoint, SDK method, database migration or business
+  backend capability declaration is required for this feature.
+
+Whole-scope revalidation includes single-system multiple accounts. Temporary offline
+checks stay closed but can recover in the same runtime. A confirmed revoked or rebound
+member blocks the complete original group. Existing cross-Hub restrictions remain.
+
+Concurrent writers cannot overwrite a different stored outcome with a stale receipt.
+On a conflict, preserve both the stored record and unsaved local status for inspection.
+Do not clear an unsaved record simply to make the screen green. File-store locks are
+not automatically treated as stale: after an abnormal host exit while saving, an
+operator must establish that no writer remains, preserve the record/lock evidence and
+resolve storage ownership before retrying. Do not instruct a model to delete locks.
+
+The journal closes the host-side identity gap, not every crash gap. If the host saved
+its dispatch fence but crashed before the request reached Core, an explicit resume can
+return `invocation_not_found`. That response does not authorize automatic reconstruction
+or resubmission. Missing/deleted records from older installations cannot be backfilled
+from conversation prose. Old sessions without a journal remain explicitly unsupported
+or unavailable; new calls begin producing records once the host enables the store.
+
+## Acceptance expectations
+
+Use synthetic shop/inventory data and real persisted DSH Session events. Cover pending
+approval and lost responses across complete host reconstruction; unchanged original
+invocation ID, authorization and run; zero duplicate `invoke`; no automatic startup
+resume; all-member revalidation; offline recovery; pre/post-dispatch storage failures;
+CAS conflicts and lost save acknowledgements; cancellation before delayed save returns;
+and empty scope with zero Hub requests. Preserve the existing long-task tool retention,
+declaration-change, archive and attachment regressions.
+
+For missing-record regressions, use the real SDK and Core's error response shape
+`{"error":"invocation_not_found","message":"..."}` with HTTP 404. Test both recovery
+paths for pending approval and unknown outcomes. Require accurate final model/host
+feedback and no replacement `invoke`, rediscovery, changed target or journal revision.
+A test that only reproduces the old generic error is not a passing recovery test.

package/docs/MIGRATION_VNEXT.md

@@ -1,3 +1,7 @@
+# Migrate to 0.6.0
+
+Use [the 0.6.0 paired upgrade guide](UPGRADE_v0.6.0.en.md) / [中文](UPGRADE_v0.6.0.md). Preserve original scopes, events, journals and task bindings. Session tool reuse requires host opt-in. The following sections retain earlier upgrade history.
+
 # Migrate to 0.5.0
 
 ## From 0.4.0: add systems without replacing existing authorizations
@@ -251,3 +255,7 @@ Before a public 0.5 release:
 
 Do not tag or publish a future version until all gates pass, and do not describe release
 validation as public adoption.
+
+## Task-control migration in 0.6.0
+
+The host-only task binding and read-only invocation inspection integration is documented in [TASK_CONTROL.md](./TASK_CONTROL.md). It requires SDK 0.6.0 and Core 0.8.0. Existing journal v1 is read compatibly; subsequent writes use v2 without inferring a task for old entries. Keep scope, task and invocation stores together when reopening, and do not downgrade managed Sessions to an older host. Follow the current paired upgrade guide before enabling task enrollment.

package/docs/README.zh-CN.md

@@ -1,7 +1,17 @@
 # BailingHub for DeepSeek Harness
 
+## 0.7.0：可选模型服务与套餐计费
+
+本地宿主继续编排，中枢提供模型转发、共享额度与异步计量。对话模型和图片工具分开下发；原业务权限、审批与审计保持。配套 Core 0.9.0 / SDK 0.7.0 / DSH 0.7.0。
+
+[本次变化](RELEASE_NOTES_v0.7.0.md) · [升级指南](UPGRADE_v0.7.0.md)
+
+
 [English](../README.md) | 简体中文
 
+
+## 已公开功能
+
 让本地 DeepSeek Harness 智能体操作已经接入 BailingHub 的业务系统：查询记录、修改允许的字段，
 需要审批时继续走原有规则。BailingHub 会记录用了哪份授权、做了什么，以及业务系统返回的结果。
 
@@ -25,14 +35,14 @@
 ## 安装与开始使用
 
 需要 Node.js `22.19.0+` 或 `24+`、pnpm，以及兼容的 DeepSeek Harness。管理员应先完成业务系统
-接入。配套版本为 **BailingHub Core 0.7.0 → BailingHub MCP/SDK 0.5.0 → 本插件 0.5.0**。
+接入。配套版本为 **BailingHub Core 0.9.0 → BailingHub MCP/SDK 0.7.0 → 本插件 0.7.0**。
 
 ```bash
 npm install --global pnpm @deepseek-ai/dsh@0.1.1-rc.2
-dsh plugin --profile web add dsh-bailinghub@0.5.0
+dsh plugin --profile web add dsh-bailinghub@0.7.0
 ```
 
-插件会自动安装精确依赖 `bailinghub-mcp-server@0.5.0`，无需另装 SDK。
+插件会自动安装精确依赖 `bailinghub-mcp-server@0.7.0`，无需另装 SDK。
 已经使用旧版的用户请先看[从 0.4.0 及更早版本升级的步骤](MIGRATION_VNEXT.md)。
 
 按照[开始使用指南](GETTING_STARTED.zh-CN.md)填写管理员提供的四项公开连接信息，再到浏览器授权。
@@ -138,6 +148,7 @@ DSH 负责思考与工具编排；BailingHub Core 负责可信身份、治理、
 业务系统继续声明原有能力，为每个身份分别授权即可。自定义 DSH 宿主需接入[范围选择与恢复 API](AGENT_CLIENT_CONTRACT.md#host-owned-session-scope-api)，
 在首条消息前显示确认；原生斜杠命令已经使用这些 API。参数结构、持久化和恢复细节见
 [Agent Client 契约](AGENT_CLIENT_CONTRACT.md)。
+本地智能体附件空间（首期支持图片）见[宿主接入说明](GENERATED_ARTIFACTS.md)：登记当前会话的生成结果，上传保存并取得可供已有业务工具使用的地址。
 
 请使用 Native Tool Mode。DSH Code Mode 无法安全呈现本轮动态工具结构，因此明确降级。
 版本范围见[兼容矩阵](COMPATIBILITY.md)。
@@ -150,3 +161,26 @@ DSH 负责思考与工具编排；BailingHub Core 负责可信身份、治理、
 
 问题请提交到 [GitHub Issues](https://github.com/bailinghub/bailinghub-dsh-plugin/issues)，提供版本与
 脱敏错误，不附带 Token、私有地址、个人信息或生产业务数据。兼容测试与下载量不代表生产采用。
+## 能力发现与错误反馈
+
+这轮优化解决的是：查完库存后，AI 要知道商城工具是否仍然可用；上架请求没有拿到确认时，要沿原调用核对结果，不能再上架一次。
+
+- 搜索返回多少候选、当前会话加载多少工具、哪些因为共享上限没加载，分别说明；未知总数不填写为 0。
+- 先发现创建商品、再发现查询工具，查完后可以直接继续创建商品。同一轮搜索会保留仍有效的旧工具，跨系统也遵守各自授权。
+- 每次最多展示 12 个完整工具说明，本轮共享保留最多 64 种可调用工具；退出展示窗口不等于卸载。64 是工具种类数，不是商品数、调用次数或任务时长。
+- 缓存淘汰、声明变化或需要新能力时需重新发现。默认 active_turn 在轮次结束后卸载，显式 session 模式可在同一存活会话内复用；未确认的写操作始终恢复原调用。
+- 网络暂时失败、授权不可用、版本不支持和原操作结果未知，使用不同的结构化反馈。旧工具名在宿主层被拒绝，也能获得对应指引。
+- 原权限、审批、会话范围、归档和恢复约束保持。本节能力发现不新增迁移；完整版本升级仍需核对 Core 的 060–062 迁移。
+
+客户端宿主接口、字段含义和兼容要求见 [能力发现与恢复契约](CAPABILITY_FEEDBACK.md)。
+
+
+## 重开后继续核对原业务操作
+
+例如上架商品还在等审批时关闭客户端，重新打开原会话后，可以继续处理原上架调用；
+商品操作已发出但回包丢失时，也只核对原调用，不再生成一次上架请求。
+这需要宿主持久保存原会话范围和调用恢复记录。没有旧记录时会明确提示，不能从聊天正文猜回参数。
+
+这部分包含在 0.6.0 中，需宿主配置持久 invocationStore。
+接入方式、保存失败处理及兼容边界见 [调用恢复说明](INVOCATION_RECOVERY.md)。
+恢复记录本身不执行业务；显式恢复原调用可能继续已获批但尚未派发的操作。

package/docs/RELEASE_NOTES_v0.6.0.en.md

@@ -0,0 +1,39 @@
+# v0.6.0 DSH plugin: move between queries, edits and result checks
+
+Release 0.6.0. Pairing: Core 0.8.0 / Agent Client SDK 0.6.0 / DSH 0.6.0. Changes below are relative to the preceding public release.
+
+An Agent creates a shop product, checks inventory and returns to editing it. New searches now merge still-valid tools within a turn instead of discarding the earlier batch. Adapted hosts can also reuse declarations across messages in the same living Session, reducing repeated remote discovery.
+
+## User-visible changes
+
+**Smoother tool switching.** The retained registry is bounded to 64 tools with a 12-schema presentation window. Session reuse has a cache of at most 64 target-tool pairs and 2 MiB; these are not operation or product quotas. Each turn still prepares the intended target's current context. Identity, permission and declaration-revision checks remain. The existing search entry point supplies full schemas so the model need not guess old parameters.
+
+**Inspect an original operation after reopening.** A persistent journal retains original target, run and invocation links. A pending shop listing can be inspected after closing the host. Public host methods support panel inspection and explicit continuation without manufacturing a model turn. Unknown writes are not replaced, and inspection never consumes approval.
+
+**Task controls across turns.** Hosts can bind an administrator-created task with its original members and cumulative budget. Models cannot choose a task ID, create tasks or increase budgets. Pause, cancellation, budget exhaustion and ordinary frequency limits have distinct states.
+
+**Use attachments in business actions.** Hosts register generated images or images explicitly selected by the user for business use. `list_generated_artifacts` / `upload_generated_artifacts` return reusable URLs. Their existing names do not restrict the source to AI generation. PNG/JPEG/WebP, 1–8 per batch and up to 6 MiB each, are supported. Ordinary chat attachments are not uploaded automatically. Subsequent business actions have separate results.
+
+**Understand failures.** Rediscovery, unsupported interfaces, temporary outages, changed identity and unknown outcomes have distinct guidance. Rate-limited work retains its original invocation. A missing original record stops automatic recovery and requests inspection of original evidence; it does not prove that the business action never happened.
+
+## Host integration
+
+| Feature | Required host work |
+| --- | --- |
+| Cross-turn reuse | Opt into `toolLifecycle: 'session'`, keep the real Session/runtime and handle preparation results; the default remains `active_turn` |
+| Original-call restart recovery | Provide a persistent `invocationStore` and retain scopes, events and archives; a custom scope store needs explicit durable companion stores |
+| Task controls | Provide a persistent `taskStore`, use `getSessionTaskCoordinates` and public binding/restore methods for administrator-created tasks |
+| Invocation panel | Call `inspectSessionInvocation` / `resumeSessionInvocation` with the real Session, original ID and cancellation signal; display business state from receipts |
+| Attachment space | Connect a controlled `artifactSource` and persistent `artifactStore`; resolve approved references, not arbitrary paths |
+
+Preparation is not business execution. Direct calls to unprepared cached tools return preparation only; read the current schema before issuing the actual action. Replaying that old call ID must not turn preparation into a write. `ready` likewise does not mean business success. Preserve storage failures, unsaved events and recovery gaps as primary errors.
+
+Propagate cancellation when a panel closes or the user switches conversations. Late results must not reactivate ended-turn tools. Cancelling a wait does not withdraw an already submitted request.
+
+## Upgrade and limits
+
+Follow the [paired upgrade guide](UPGRADE_v0.6.0.en.md): upgrade Core and SDK before the actual host's DSH and persistence adapters. Existing backend APIs and approvals need no change.
+
+The declaration cache survives only within the current Session/runtime; a restart requires discovery again. Original-call recovery uses a separate durable journal and does not resume a whole model plan. Missing historical bindings are not reconstructed, and any invalid original member blocks the whole group. The same-Hub, same-audit-domain boundary remains. These DSH seams do not automatically appear in generic MCP hosts.
+
+Bounded client synthetic acceptance and actual development Profile package verification are complete. Actual clicks in the latest panel, Windows devices and arbitrary model-driven long tasks are not fully covered. Verify the actual installed release package.

package/docs/RELEASE_NOTES_v0.6.0.md

@@ -0,0 +1,39 @@
+# DSH 插件 v0.6.0：查询、编辑、核对，可以连着做
+
+发布版本：0.6.0。配套：Core 0.8.0 / Agent Client SDK 0.6.0 / DSH 0.6.0。相对上一公开版本的变化如下。
+
+助手先创建商城商品，再查询库存，最后回到商品编辑。以前新搜索可能替换前一批工具；下一条消息也需要重新发现。现在，一轮内的搜索会合并仍有效的工具，已适配宿主还可以在同一个存活会话中复用声明，减少重复远端发现。
+
+## 使用体验的变化
+
+**工具切换更连贯。** 保留集合最多 64 个工具，完整 schema 展示窗口为 12 个。开启会话复用后，缓存上限是 64 个“目标—工具”条目、2 MiB，不是操作次数或商品数量限额。每轮首次需要某个目标时仍准备当前上下文；授权、权限和声明版本检查继续生效。模型能从现有搜索入口取得完整参数说明，不必凭记忆猜字段。
+
+**重开后核对原操作。** 持久调用账本保存原目标、运行和调用关联。例如商品上架等待审批时退出，再打开仍可核对同一笔上架。宿主面板通过正式接口直接“核对结果”或明确“继续原调用”，不需要先伪造一条用户消息。未知写结果不另建调用，核对也不会消费审批。
+
+**任务控制贯穿多轮。** 宿主可关联管理端建立的原任务，保留整组授权和累计预算。模型不选择任务 ID、不创建新任务、不提高额度。暂停、取消、额度用尽和普通频率等待有各自状态。
+
+**附件可以接着用于业务。** 宿主登记生成图片或用户明确指定业务用途的图片，模型用 `list_generated_artifacts` / `upload_generated_artifacts` 取得可用 URL。工具名为兼容保留，来源不限于 AI 生成。本期支持 PNG/JPEG/WebP，每批 1–8 张、每张最高 6 MiB。普通聊天附件不会自动上传，业务工具仍单独执行并返回结果。
+
+**失败后知道下一步。** 需要重新发现的工具、不支持的接口、暂时断网、授权变化和原结果未知不会都被说成“系统没有能力”。限流等待后保留原调用；原调用不存在时停止自动恢复，提示核对原执行证据，而非认定业务没有发生。
+
+## 宿主必须接的部分
+
+| 能力 | 接入动作 |
+| --- | --- |
+| 跨轮声明复用 | 显式设置 `toolLifecycle: 'session'`，保持真实 Session/runtime，处理准备结果；默认仍为 `active_turn` |
+| 原调用重开恢复 | 配置持久 `invocationStore`，保留原 scope、事件和归档记录；自定义 scopeStore 的宿主不能依赖临时内存默认值 |
+| 任务控制 | 配置持久 `taskStore`，通过 `getSessionTaskCoordinates` 获取原坐标，用正式绑定/恢复方法接管理端任务 |
+| 会话面板 | 接 `inspectSessionInvocation` / `resumeSessionInvocation`，传真实 Session、原 ID 和取消信号；按 receipt 结果展示业务状态 |
+| 附件空间 | 接受控 `artifactSource` 和持久 `artifactStore`；读取引用而非任意文件路径 |
+
+准备成功不代表业务执行成功。直接调用尚未准备的缓存工具只会返回准备结果；宿主和模型必须读取当前说明再发出业务操作，不能重复旧调用 ID 把准备变成写入。`ready` 也不代表业务完成，应检查实际回执。存储失败、未保存消息和历史缺口优先展示。
+
+关闭面板、切换会话或取消等待须传递取消；晚到回应不能启用旧轮次工具。取消等待不是撤销已经提交的业务请求。
+
+## 升级与边界
+
+见[配套升级指南](UPGRADE_v0.6.0.md)。先升级 Core 与 SDK，再升级实际宿主的 DSH 及持久适配器，不需要让业务后端重做接口或审批。
+
+跨轮工具缓存仅在当前 Session/runtime 存活期间保留，重启后需要重新发现；原调用恢复依靠另一份持久账本。它不自动续跑整项模型计划。没有可信旧记录时不猜补，任一原授权失效时整组阻断。仍限同一 Hub、同一审计域；通用 MCP 宿主不会自动获得这些 DSH 接缝。
+
+配套客户端已完成限定合成验收和实际开发 Profile 包核对。最新面板的人工点击、Windows 实机和任意模型长任务表现尚未获得全范围验证；升级时核对实际安装包。

package/docs/RELEASE_NOTES_v0.7.0.en.md

@@ -0,0 +1,15 @@
+# DSH 0.7.0: optional model services and shared plan billing
+
+Release pairing: Core 0.9.0, SDK 0.7.0 and DSH 0.7.0. The changes and integration impact below are relative to public 0.6.0.
+
+Local agents can use administrator-configured model plans and discover image generation as a model tool. Context, tool loops, subtasks and business orchestration stay in the host. Core relays model requests, checks allowance and meters usage asynchronously.
+
+- Separate `modelModels` and `modelTools` catalogs; bind requests to exact service IDs.
+- Preserve provider streaming and complete tool declarations through `stream`. Settlement does not hold usable results or impose user-turn/tool-loop limits.
+- Validate explicit `periodAllowanceUsd`; display server `presentation` as credits or percentage. Provider Token counts remain usage details, not a quota denominator.
+- Submit asynchronous `runModelTool` once and use `recoverOperation` with its original operation ID after ACK loss or restart. Distinguish pending, failed, uncertain and pending billing outcomes.
+- Preserve original identity, business authorization, approval, task, artifact and audit boundaries. Generating an image does not upload it to a business system.
+
+Executable image support follows the Core catalog. Video/audio declarations do not promise execution. Reference prices are not supplier invoices. Payments, orders and currency conversion belong to the product backend.
+
+See the [integration contract](USAGE_SERVICE.md) and [upgrade guide](UPGRADE_v0.7.0.en.md).

package/docs/RELEASE_NOTES_v0.7.0.md

@@ -0,0 +1,15 @@
+# DSH 0.7.0：可选模型服务与统一套餐计费
+
+版本配套：Core 0.9.0、SDK 0.7.0、DSH 0.7.0。以下为相对公开 0.6.0 的新增能力与接入影响。
+
+本地智能体可使用管理员配置的模型套餐，并将图片生成作为按需工具调用。上下文、工具循环、子任务和业务编排仍由本地宿主执行；中枢负责模型转发、额度检查及异步计量。
+
+- `modelModels` 与 `modelTools` 分离对话模型和可调用模型工具；使用服务标识绑定所选模型，不按名称猜测。
+- `stream` 保留供应商流式内容与工具声明，结算不阻塞可用结果；不增加用户轮次或工具循环上限。
+- `modelSummary` 严格读取周期额度 `periodAllowanceUsd`，用户展示继续消费服务端 `presentation`（积分或百分比），原始 Token 仅供用量明细。
+- `runModelTool` 异步受理生成；`recoverOperation` 按原 operation ID 查询，回包丢失不新建生成请求。明确失败、处理中、结果不确定和待计量分开处理。
+- 原业务授权、审批、任务控制、附件上传与审计约束保持；套餐不扩大业务权限。图片结果与上传到业务系统是两个独立动作。
+
+图片可执行适配以 Core 工具目录为准；视频与语音声明不等于已支持执行。参考价格不等于供应商实际账单。支付、订单、汇率由业务侧负责。
+
+参见[接入契约](USAGE_SERVICE.md)及[升级指南](UPGRADE_v0.7.0.md)。