dsh-ptc-plus 0.5.4 → 0.5.6

package/README.en.md

@@ -29,7 +29,7 @@ PTC Plus provides a stateful TypeScript computation environment for DSH's **PTC
 
 ## Quick start
 
-Requires Node.js `^22.19.0 || >=24.0.0` and the latest available official DSH release:
+Requires the latest available official DSH release and a Node.js runtime satisfying both the plugin's `^22.19.0 || >=24.0.0` range and the selected DSH release's requirements:
 
 ```sh
 dsh plugin --profile <profile> add dsh-ptc-plus
@@ -37,7 +37,7 @@ dsh plugin --profile <profile> add dsh-ptc-plus
 
 Replace `<profile>` with your profile name, restart DSH, and select **PTC mode** in the session. Continuous computation, call tolerance, and global bindings are on by default. To upgrade, run `dsh plugin --profile <profile> add dsh-ptc-plus@latest` and restart that Host; see the [installation guide](docs/installation.md) for other installation methods, Desktop, the local development launcher, and troubleshooting.
 
-The plugin declares `engines.dsh: "*"` for the Host's compatibility preflight; public capability checks and packed tests against the latest official release verify compatibility.
+The plugin declares the DSH compatibility range `>=0.2.1-0 <0.2.3` for the Host's version preflight; public capability checks and packed tests verify integration within that range.
 
 The session shows a **REPL** tab, and wide screens show a **PTC Plus** header indicator. The sparkle button beside the composer opens the global binding menu, the session capability workbench, and **PTC Plus settings**; **Plugins → Installed → dsh-ptc-plus → Configure** in the sidebar is the same configuration.
 

package/README.md

@@ -29,7 +29,7 @@ PTC Plus 为 DSH 的 **PTC 模式**提供有状态的 TypeScript 计算环境。
 
 ## 快速开始
 
-需要 Node.js `^22.19.0 || >=24.0.0` 和最新可用的官方 DSH：
+需要最新可用的官方 DSH；Node.js 需同时满足插件的 `^22.19.0 || >=24.0.0` 与所选 DSH 的运行要求：
 
 ```sh
 dsh plugin --profile <profile> add dsh-ptc-plus
@@ -37,7 +37,7 @@ dsh plugin --profile <profile> add dsh-ptc-plus
 
 把 `<profile>` 换成实际 profile 名称，重启 DSH，在会话中选择 **PTC 模式**。连续计算、调用容错和全局绑定默认开启；升级用 `dsh plugin --profile <profile> add dsh-ptc-plus@latest` 再重启宿主，其他安装方式、Desktop、本地开发启动器和故障排查见[安装指南](docs/installation.md)。
 
-插件通过 `engines.dsh: "*"` 接入宿主兼容性预检，按最新官方发行版的公共能力检查与打包测试验证兼容性。
+插件声明 DSH 兼容范围 `>=0.2.1-0 <0.2.3`，由宿主执行版本预检；范围内的接口适配仍通过公共能力检查与打包测试验证。
 
 界面默认显示会话里的 **REPL** 页签，宽屏顶部还有 **PTC Plus** 标志。输入框旁的星光按钮打开全局绑定菜单、会话能力工作台和 **PTC Plus 设置**，侧边栏的 **插件 → 已安装 → dsh-ptc-plus → 配置** 是同一套设置。
 

package/docs/adr/0005-temporary-rejected-cell-edit-transport.md

@@ -19,9 +19,9 @@ The editor captures the most recent eligible cell at the persisted `tool/ptc-dis
 
 The editor accepts exactly one `edits` or `regex_edits` array. Exact edits require unique nonempty `old_string` matches. Each regex edit requires `pattern`, `flags`, `replacement` and `expected_matches`; replacement uses JavaScript `$1`, `$<name>` and `$$` syntax. At most 16 nonoverlapping edits are applied atomically. `internal/rejected-cell-editor.js` owns matching, expansion and CPU/source budgets.
 
-For an accepted edit, the nested SDK call returns `{ accepted: true, scheduled: true, target_call_seq }`. This is an acceptance receipt, not the revised computation's value or an idempotence promise. The current outer cell continues with its existing state and original return value or error. After that cell releases its worker, but before its top-level `run_code` result settles, PTC Plus dispatches the complete revised source through DSH's real `tools.execute({ name: 'run_code', ... })` pipeline. The root result retains that outer canonical value or error and forwards the derived result's Host-rendered content, images, additional contexts and, for a successful root result, turn-conclusion flag. The definition-owned `projectContent` callback is installed before dispatch starts, so derived content reaches root post-policy; `exec.deferContext` and `exec.concludeTurn` carry contexts and the successful root conclusion. Root policy may replace or block that presentation. The runtime bridge preserves existing callbacks and their property descriptors, restores only its own installed callbacks on disposal, and unwinds partial installation on failure. The next cell sees the revised bindings. A nested receipt rejected or changed before acceptance prevents dispatch; cancellation or disposal before dispatch does likewise. Removal of the final root metadata after a derived run has executed invalidates recovery evidence but cannot undo its effects.
+For an accepted edit, the nested SDK call returns `{ accepted: true, scheduled: true, target_call_seq }`. This is an acceptance receipt, not the revised computation's value or an idempotence promise. The current outer cell continues with its existing state and original return value or error. After that cell releases its worker, but before its top-level `run_code` result settles, PTC Plus dispatches the complete revised source through DSH's public invocation pipeline. Registry Hosts accept the execution input through `tools.execute`; executor Hosts use the published `@deepseek-ai/dsh-tools/pipeline` `ToolExecutionPipeline.prepare`, `dispatch` and `complete` stages with the selected live transport definition. The invocation retains the actual root token as `parent`, the original `rootCallId` and the root's step admission. The Host still owns validation, policy, cancellation and final result materialization; a root model-call batch cannot carry this nested relation. The root result retains that outer canonical value or error and forwards the derived result's Host-rendered content, images, additional contexts and, for a successful root result, turn-conclusion flag. The definition-owned `projectContent` callback is installed before dispatch starts, so derived content reaches root post-policy; `exec.deferContext` and `exec.concludeTurn` carry contexts and the successful root conclusion. Root policy may replace or block that presentation. The runtime bridge preserves existing callbacks and their property descriptors, restores only its own installed callbacks on disposal, and unwinds partial installation on failure. The next cell sees the revised bindings. A nested receipt rejected or changed before acceptance prevents dispatch; cancellation or disposal before dispatch does likewise. Removal of the final root metadata after a derived run has executed invalidates recovery evidence but cannot undo its effects.
 
-The model-authored outer `run_code` remains the sole top-level call in assistant history. Official nested events retain the editor's real name, arguments and settled receipt. The plugin records its actual derived `tools.execute` call through public `Session.append`: the start carries losslessly detached arguments, a distinct sub-call identity, the original root ID and that still-running root's ID as its parent. The actual execution uses the root's real token as `parent`. Its settled event records the canonical error status and metadata; rendered content passes through the public scoped `tools/ptc-dispatch-log` waterfall with the real root execution. A throwing log projector falls back to the original settled content. These records describe actual executions and do not invent an assistant call, parent or completion. Recovery proves exactly one start and one later settlement for each editor and actual derived sub-call identity within its root-call/final-result window. A metadata start sequence alone cannot resolve duplicate dispatch identities; settled ID reuse outside that window remains independent.
+The model-authored outer `run_code` remains the sole top-level call in assistant history. Official nested events retain the editor's real name, arguments and settled receipt. The plugin records its actual derived Host invocation through public `Session.append`: the start carries losslessly detached arguments, a distinct sub-call identity, the original root ID and that still-running root's ID as its parent. The actual execution uses the root's real token as `parent`. Its settled event records the canonical error status and metadata; rendered content passes through the public scoped `tools/ptc-dispatch-log` waterfall with the real root execution. A throwing log projector falls back to the original settled content. These records describe actual executions and do not invent an assistant call, parent or completion. Recovery proves exactly one start and one later settlement for each editor and actual derived sub-call identity within its root-call/final-result window. A metadata start sequence alone cannot resolve duplicate dispatch identities; settled ID reuse outside that window remains independent.
 
 If the public Host never invokes `presentationMeta` for this owned nested success, the bridge may capture its canonical frozen value and tentative settlement through the read-only pre-policy `projectContent` callback. Private evidence is admissible only for the exact execution token, session, parent and continuation, with no initial plugin journal, no subsequent projector call, unchanged base metadata, final success and the same canonical value object. Host value replacement, block/error, missing capture or removal of already projected metadata rejects it. The sidecar supplies only the plugin-owned actual derived settlement and root relation; it never changes the Host result or restores pre-policy content. Final root metadata remains required. The proof comes from public canonical value identity and the before/after policy callbacks, without a Host version branch.
 

package/docs/adr/0017-track-the-latest-dsh-public-surface.md

@@ -8,9 +8,9 @@ PTC Plus integrates with DSH services, request bindings, prompt assembly, sessio
 
 PTC Plus must remain independently installable on unmodified official DSH distributions. Host source is read-only research evidence, not an implementation workspace for plugin features. Plugin changes must not patch host source or installed packages, introduce install-time host patches, or require a custom host build. Plugin-owned components, panels, styling, portals and public renderer replacements are valid UI choices within the consumed contracts; integration does not require every visual element or layout to be native. A locally invented extension declaration is not a published public capability. Choose among published surfaces according to the required user experience rather than assuming that a UI feature must become a historical message node. If none can satisfy the required behavior, record the actual limitation; do not substitute a custom distribution or present a compatibility fallback as delivery.
 
-The compatibility target is the latest available DSH release. Production behavior, configuration, tests, installation guidance, and current compatibility claims depend on public extension contracts and observed live schemas, never on a DSH version allowlist or comparison. An upstream default projection is not an extension ceiling: when public scoped registration and presentation support a plugin-owned capability, PTC Plus preserves that capability and its model-visible identity instead of deleting or renaming it to match the default. Deterministic normalization remains valid for a call that is outside the declared direct surface when the live schema proves one native target and the lowering preserves arguments, call identity, authority, and result semantics. Deterministic tests exercise the consumed contracts; model-backed and packaging acceptance runners use the installed DSH and record `dsh --version` in generated reports so failures remain attributable without turning the observed value into policy. Concrete DSH release numbers may appear only in source comments that identify historical integration or evaluation evidence and cannot influence execution or acceptance.
+The compatibility target is the latest available DSH release. The manifest declares a bounded `engines.dsh` range for DSH-owned installation and startup preflight. Runtime interface selection depends on public extension contracts and observed live schemas, never on a DSH version comparison. An upstream default projection is not an extension ceiling: when public scoped registration and presentation support a plugin-owned capability, PTC Plus preserves that capability and its model-visible identity instead of deleting or renaming it to match the default. Deterministic normalization remains valid for a call that is outside the declared direct surface when the live schema proves one native target and the lowering preserves arguments, call identity, authority, and result semantics. Deterministic tests exercise the consumed contracts; model-backed and packaging acceptance runners use the installed DSH and record `dsh --version` in generated reports so failures remain attributable without turning the observed value into policy. The manifest range, its lockfile counterpart, package-admission tests and user guidance may name DSH versions to state and verify the admission contract. Those declarations do not select runtime interface branches.
 
-Release discovery is separated from candidate verification. Support is expressed as channels, not versions. `compat/channels.json` is generated from the official dist-tags and records, per channel, the resolved host release, the tarball integrity of every host package whose published surface the plugin probes, and whether that channel may block a release: `latest` (newest published release) and `next` (in-flight release candidate) block, while `alpha` (a pre-adaptation for a line the host has not released yet) only reports. A probe package the release does not publish is recorded with the version and integrity that release's own dependency range resolves to, so the channel still names the bytes an install receives; a probe package the release neither publishes nor depends on is recorded as absent, and the install proof rejects a graph that contains one. These records are reproducibility evidence selected by the channel declarations; they are not compatibility allowlists or runtime branches. `npm run host:channels:update` is the only way to refresh them and starts from the registry; ordinary `verify` and the full branch of `check` make no registry request and validate the tracked manifest offline. The root manifest declares the official `next` channel for the DSH packages used by development, and `host:channels:graph` moves the lock onto the release that channel resolves to; the scheduled channel workflow runs it in the same commit as a channel change. Ordinary gates read whichever graph the lock froze and never resolve a tag.
+Release discovery is separated from candidate verification. Verification targets are expressed as channels; the manifest range separately bounds Host admission. `compat/channels.json` is generated from the official dist-tags and records, per channel, the resolved host release, the tarball integrity of every host package whose published surface the plugin probes, and whether that channel may block a release: `latest` (newest published release) and `next` (in-flight release candidate) block, while `alpha` (a pre-adaptation for a line the host has not released yet) only reports. A probe package the release does not publish is recorded with the version and integrity that release's own dependency range resolves to, so the channel still names the bytes an install receives; a probe package the release neither publishes nor depends on is recorded as absent, and the install proof rejects a graph that contains one. These records are reproducibility evidence selected by the channel declarations; they are not compatibility allowlists or runtime branches. `npm run host:channels:update` is the only way to refresh them and starts from the registry; ordinary `verify` and the full branch of `check` make no registry request and validate the tracked manifest offline. The root manifest declares the official `next` channel for the DSH packages used by development, and `host:channels:graph` moves the lock onto the release that channel resolves to; the scheduled channel workflow runs it in the same commit as a channel change. Ordinary gates read whichever graph the lock froze and never resolve a tag.
 
 The scheduled channel refresh resolves every channel from its dist-tag. When a channel moves it commits the regenerated manifest on an automation-owned branch, opens or updates one pull request, and dispatches the normal CI workflow once for that candidate. GitHub suppresses workflow runs from branch and pull-request events produced by the workflow's `GITHUB_TOKEN`, so the explicit dispatch is the candidate's only CI run. If no channel moved, the refresh writes the identical document and nothing is committed. The Host contract suite installs each channel on demand from the manifest into an ignored cache, proves the installed versions against the manifest, packs the plugin, and runs the execution-seam, RPC-codec, compressed Session persistence, and pathless Cordis companion contracts through a repository-external consumer that exposes the selected Host's public packages. `npm run test:host-contract -- <channel>` selects one channel, and the default selection is the blocking set. CI runs one job per channel and lets the `alpha` job report without failing the workflow. No compatibility run independently selects tags for DSH service packages, because their dist-tags need not move as one cohort.
 
@@ -65,7 +65,7 @@ capability, storage and observation rules independently of transport.
 
 **Pin one verified DSH release.** A pin makes one historical environment reproducible but turns normal upstream progress into an artificial incompatibility and allows the implementation to drift from the release users actually install.
 
-**Maintain a supported-version range.** A range communicates broader intent, but semver cannot prove compatibility with evolving extension contracts. Maintaining the range duplicates evidence already produced by contract and end-to-end tests while still requiring every new release to be evaluated. The package therefore declares `engines.dsh: "*"` for the Host-owned manifest preflight, preserving capability-based admission without a release allowlist. The packed contract suite runs the selected Host's public `evaluatePluginCompatibility` before importing plugin code; required service peers still establish package resolution.
+**Leave manifest admission unrestricted.** A wildcard admits Host versions beyond the compatibility boundary the package declares to users. The package therefore retains a bounded `engines.dsh` range, while capability checks select runtime interfaces. A range is an admission contract, not proof that every matching release has passed testing. Updating a Host within the range does not justify removing its bounds; moving a bound requires an explicit compatibility decision and relevant Host evidence. The packed contract suite runs the selected Host's public `evaluatePluginCompatibility` before importing plugin code; required service peers still establish package resolution.
 
 **Treat the upstream default tool projection as an immutable plugin limit.** This avoids scoped presentation work, but discards capabilities that the public registry supports and can force valid model calls through lossy aliases. Defaults describe the host's built-in product choice; public extension contracts define what a plugin may add. Invalid out-of-surface calls may still be normalized when their intended native target is provable.
 
@@ -75,4 +75,4 @@ capability, storage and observation rules independently of transport.
 
 Feature completion requires evidence from the actual packaged plugin running on the selected unmodified Host, including the affected user flow. Component fixtures and public-interface unit tests validate narrower properties; they do not prove that a required renderer exists or is loaded in that distribution. A clean code review and passing deterministic checks are separate from product acceptance. Both must cover the final change before a feature is described as delivered; commit and publish authorization remain separate user decisions.
 
-Each upstream DSH release becomes the immediate compatibility target and must pass the public-surface, packaging, and model-backed checks appropriate to the change. The automated pull request makes an upstream tag movement an explicit source candidate; the lockfile and CI result keep its proof reproducible after the registry moves again. Users are not blocked by stale version metadata. Historical reports remain attributable through generated runtime metadata or source comments, while a passing older run never substitutes for validation against the latest release.
+Each upstream DSH release becomes the immediate compatibility target and must pass the public-surface, packaging, and model-backed checks appropriate to the change. The automated pull request makes an upstream tag movement an explicit source candidate; the lockfile and CI result keep its proof reproducible after the registry moves again. When a new target falls outside the declared range, its admission bounds must be reviewed and updated with the relevant evidence before claiming support. Historical reports remain attributable through generated runtime metadata or source comments, while a passing older run never substitutes for validation against the latest release.

package/docs/architecture.md

@@ -23,7 +23,7 @@ DSH 的公开 presentation 为 `native` 或 `ptc`。agent composition owner、
 
 `edit_run_code` 在持久化 `tool/ptc-dispatch-start` 处捕获当前 open turn 最近的可编辑 cell，按 root、parent、sub-call identity、参数与 sequence 校验正式事件。调查工具不擦除目标，后来的 settlement 不追溯改变它。调用必须且只能提交 `edits` 或 `regex_edits` 之一，并可携带 `expected_target_call_seq`；目标前置条件不一致时不派生执行。`internal/rejected-cell-editor.js` 统一拥有 schema、匹配、JavaScript replacement 语义、预算和原子源码物化。
 
-接受收据为 `{ accepted: true, scheduled: true, target_call_seq }`，拒绝为 `{ accepted: false, scheduled: false, reason }`。接受只表示待执行：外层 cell 的后续语句仍使用当前状态，保留其 canonical return 或 error。外层 worker 结束后、根结果结算前，runtime bridge 通过 DSH 公共 `tools.execute()` 执行完整修订源码，并通过调用开始前已安装的公开 `projectContent` 将派生 content、images 送入根 post-policy；`exec.deferContext` 与 `exec.concludeTurn` 转发 additionalContexts 和成功根结果的 concludesTurn。成功根结果保留 Host canonical 对象，避免重新投影丢失 journal；根 policy 仍可替换或阻断这些展示内容。 runtime bridge 保留原有 callback 与 property descriptor；安装失败时撤回已安装部分，卸载时只恢复自己仍拥有的 callback。普通外层计算失败不撤销已接受编辑；取消、lease 结束或 disposal 阻止未开始的派生执行。同一根 cell 至多接受一次编辑，派生执行不能重新取得根编辑资格。
+接受收据为 `{ accepted: true, scheduled: true, target_call_seq }`，拒绝为 `{ accepted: false, scheduled: false, reason }`。接受只表示待执行：外层 cell 的后续语句仍使用当前状态，保留其 canonical return 或 error。外层 worker 结束后、根结果结算前，runtime bridge 通过 DSH 公共调用流水线执行完整修订源码：registry 宿主使用 `tools.execute()`，executor 宿主使用已发布的 `ToolExecutionPipeline.prepare/dispatch/complete`，保留原 `rootCallId`、真实 parent token 与根调用的 step admission，并通过调用开始前已安装的公开 `projectContent` 将派生 content、images 送入根 post-policy；`exec.deferContext` 与 `exec.concludeTurn` 转发 additionalContexts 和成功根结果的 concludesTurn。成功根结果保留 Host canonical 对象，避免重新投影丢失 journal；根 policy 仍可替换或阻断这些展示内容。 runtime bridge 保留原有 callback 与 property descriptor；安装失败时撤回已安装部分，卸载时只恢复自己仍拥有的 callback。普通外层计算失败不撤销已接受编辑；取消、lease 结束或 disposal 阻止未开始的派生执行。同一根 cell 至多接受一次编辑，派生执行不能重新取得根编辑资格。
 
 assistant history 保留原始根 `run_code`，正式 nested events 保留 editor 的名称、delta 参数与收据。插件通过公开 `Session.append` 记录真实派生 `run_code` 的 start/settle，实际执行的 parent token 与事件 parent 都来自仍在运行的根 transport；公开 scoped `tools/ptc-dispatch-log` 使用真实根 execution 留存内容。根结果私有 `dshPtcPlusPostEdit` 记录完整派生源码、journal、目标、editor 的 `startSeq` 与实际执行的 `executionStartSeq`；不虚构 assistant call、父调用或结算。最终 metadata 丢失不能撤销已发生效果，只使未证明状态丧失恢复资格。恢复 owner 校验根 journal 的收据、editor 和派生执行的正式 dispatch pairs、canonical 结算事实、目标变换与根/目标双重模型可见来源，按实际 root 后 derived 顺序恢复状态；cold replay 返回 recorded binding 值，不重新派发 editor 或外部效果。成功修订成为下一编辑目标。历史顶层 editor metadata 继续由其原有 generation 校验。详见 [ADR 0005](adr/0005-temporary-rejected-cell-edit-transport.md)。
 

package/docs/installation.md

@@ -1,10 +1,10 @@
 # Installation
 
-PTC Plus requires Node.js `^22.19.0 || >=24.0.0` and targets the latest available DSH release with TypeScript PTC mode. Historical interface branches are retained through capability detection, without promising a fully verified earlier Host installation; when both generations expose competing presentation evidence, the current DSH contract wins. Compatibility follows those live extension surfaces rather than a version allowlist.
+PTC Plus requires Node.js `^22.19.0 || >=24.0.0` and targets the latest available DSH release with TypeScript PTC mode. The runtime must also meet the selected Host's own Node.js requirement, which may be stricter than the plugin's range. Historical interface branches are retained through capability detection, without promising a fully verified earlier Host installation; when both generations expose competing presentation evidence, the current DSH contract wins. DSH checks the declared compatibility range before loading the plugin; runtime interface selection follows those live extension surfaces.
 
-The package declares `engines.dsh: "*"` for DSH's plugin compatibility preflight. This keeps release-number gating open while public capability checks and packed Host contracts establish compatibility; it does not claim that every historical or future Host has been tested. Host-owned service packages are peers of the plugin because the host supplies them; the PTC tool executor is an optional peer, because a host that keeps tool presentation in its registry does not publish that package at all.
+The package declares `engines.dsh: ">=0.2.1-0 <0.2.3"` for DSH's plugin compatibility preflight. DSH evaluates that range, including prereleases, before loading the plugin. Public capability checks and packed Host contracts establish integration within the range; the declaration does not claim that every matching release has been tested. Host-owned service packages are peers of the plugin because the host supplies them; the PTC tool executor is an optional peer, because a host that keeps tool presentation in its registry does not publish that package at all.
 
-The worker uses the Host's Node executable. Startup verifies native REPL framing, imports, syntax failures, synchronous throws, awaited rejections, and original return values. The adapter combines public eval callbacks with domain error events before REPL formatting; a source-end witness distinguishes empty completion from falsy rejection. A failed or timed-out probe reports a runtime prerequisite failure before user code executes. The engine range follows DSH; CI exercises Node 22.19, 24, and 26, without claiming that untested future releases have already passed.
+The worker uses the Host's Node executable. Startup verifies native REPL framing, imports, syntax failures, synchronous throws, awaited rejections, and original return values. The adapter combines public eval callbacks with domain error events before REPL formatting; a source-end witness distinguishes empty completion from falsy rejection. A failed or timed-out probe reports a runtime prerequisite failure before user code executes. The plugin engine range and the Host's engine range are separate requirements; CI exercises Node 22.19, 24, and 26, without claiming that untested future releases have already passed.
 
 Install the plugin into the profile that actually runs the target DSH surface. Do not assume a profile named `default` is active.
 
@@ -12,7 +12,7 @@ Install the plugin into the profile that actually runs the target DSH surface. D
 
 | Component | Current contract |
 | --- | --- |
-| DeepSeek Harness | `>=0.2.1-0 <0.2.3` (the 0.2.1 and 0.2.2 lines), declared once in `engines.dsh`; validate the live public extension surfaces after every upstream release |
+| DeepSeek Harness | `engines.dsh: ">=0.2.1-0 <0.2.3"`; DSH owns version preflight, while live public extension checks and packed Host contracts establish integration |
 | Runtime | DSH TypeScript PTC mode; cells currently accept modern JavaScript syntax |
 | Node.js | `^22.19.0 || >=24.0.0` |
 | Platforms | Windows CLI/Desktop and Linux CLI/Web verified locally; macOS package tests and import smoke run in CI, while live DSH integration and Desktop require release-time smoke testing |
@@ -32,7 +32,7 @@ The Client root requires `slots`, `locale`, `connection`, and `remote`; it adopt
 
 ### Compatibility Evidence
 
-The plugin states its runtime requirement once, in `engines.dsh`: DSH evaluates that range alone and ignores the `peerDependencies` on its own packages, so the peers stay unrestricted while the accepted runtime line is one fact. The range admits both the 0.2.1 and 0.2.2 lines, prereleases included; 0.2.0 is outside it. Support is expressed as channels, not versions. `compat/channels.json` records, per channel, the host release each official dist-tag resolves to and the tarball integrity of every host package whose published surface the plugin probes. `latest` and `next` are the blocking channels; `alpha` carries the line this checkout develops against and reports without blocking a release. The development graph declares that channel rather than a release — every host `devDependencies` entry names it, and the lock resolves it — so a supported line is reached by moving the channel definition, not by editing the graph by hand. A probed package the release does not publish is recorded at the version and integrity its own declared dependency range resolves to, so a publish inside that range is a recorded drift; a probed package the release neither publishes nor depends on is recorded as absent, and the install proof rejects a graph that contains one. The recorded versions do not prove live registry availability or untested compatibility, and behaviour never branches on them: presentation, transport ownership and state retention are detected from the host's published shapes. `npm run host:channels:verify` checks the tracked manifest offline; `npm run host:channels:update` is the only command that resolves it from the registry.
+The plugin declares a bounded `engines.dsh` range for manifest admission and leaves Host service peers unrestricted. This metadata does not prove a usable public extension surface; the selected Host must pass capability checks and packed contracts. Verification targets are expressed as channels, independently of the manifest range. `compat/channels.json` records, per channel, the host release each official dist-tag resolves to and the tarball integrity of every host package whose published surface the plugin probes. `latest` and `next` are the blocking channels; `alpha` carries the line this checkout develops against and reports without blocking a release. The development graph declares that channel rather than a release — every host `devDependencies` entry names it, and the lock resolves it — so a supported line is reached by moving the channel definition, not by editing the graph by hand. A probed package the release does not publish is recorded at the version and integrity its own declared dependency range resolves to, so a publish inside that range is a recorded drift; a probed package the release neither publishes nor depends on is recorded as absent, and the install proof rejects a graph that contains one. The recorded versions do not prove live registry availability or untested compatibility, and behaviour never branches on them: presentation, transport ownership and state retention are detected from the host's published shapes. `npm run host:channels:verify` checks the tracked manifest offline; `npm run host:channels:update` is the only command that resolves it from the registry.
 
 | Retained interface | Evidence and consequence of removal |
 | --- | --- |
@@ -54,7 +54,7 @@ Capabilities select behavior, never a release number. Historical fixture success
 Use this form after the selected version is available from the npm registry:
 
 ```sh
-dsh plugin --profile <profile> add dsh-ptc-plus@0.5.3
+dsh plugin --profile <profile> add dsh-ptc-plus@0.5.6
 dsh --profile <profile> --dump-config
 ```
 
@@ -159,7 +159,7 @@ dsh plugin add github:muyuanjin/dsh-ptc-plus#main
 dsh --dump-config
 ```
 
-After an npm release, the package spec may instead be `dsh-ptc-plus@0.5.3`. For a local package, use its absolute tarball path. Restart DSH Desktop after installation. Linux Desktop is not a current DSH Desktop release target; use DSH CLI/Web on Linux.
+After an npm release, the package spec may instead be `dsh-ptc-plus@0.5.6`. For a local package, use its absolute tarball path. Restart DSH Desktop after installation. Linux Desktop is not a current DSH Desktop release target; use DSH CLI/Web on Linux.
 
 ## Upgrades
 

package/docs/publishing.md

@@ -44,7 +44,7 @@ npm.cmd stage approve '<stage-id>' --registry=https://registry.npmjs.org/
 
 1. 提交前在稳定工作树上运行完整 `npm run check`，执行无覆盖插桩的完整普通后端测试并生成 review proof。覆盖率只在准备发布新版本时运行；Release workflow 在打包与 npm staging 前对 release tag 执行 `npm run coverage`，要求行与函数覆盖率 100%、分支覆盖率至少 95%。发布准备期间可在本地运行同一命令，并用 `npm run coverage:focus` 诊断覆盖率缺口；日常开发、审查与提交不运行覆盖率专用套件、采集探针或插桩分支；这些测试由 `test/coverage/` 和发布入口的显式标记拥有。仓库 CI 在 Linux Node `22.19.0`、24.x、26.x，以及 Windows 与 macOS Node 24.x 的干净安装上运行 `npm run verify:ci`，检查构建、Client 与跨平台关键运行契约；Ubuntu Node 24.x 另运行打包后的 `latest` / `next` Host contracts。普通 CI 不收集 coverage 或执行穷尽式后端套件。
 2. 运行 `npm audit --omit=dev`、`npx publint`、`git diff --check`、Markdown local-link check 和 `npm pack --silent --dry-run --json`。audit 检查随包安装的 production 依赖图；宿主 DSH 及其开发依赖不进入插件 tarball，由冻结宿主契约和 CI 单独验证。确认 tarball 只包含发布白名单内的运行时代码、文档和展示资产，不含凭据、本地路径、开发脚本或测试夹具，并执行 `npm run test:package:consumer -- <tarball>`：入口先校验当前安装的宿主与其 lock 一致，再将宿主实际提供的 peer 版本与 tarball 放在同一次 npm 安装事务中，在空目录执行 ESM import、内置编译器栈与内核 worker 加载 smoke。不能让 npm 对各宿主 peer 分别选用 dist-tag；插件继续声明不限制版本的 required peers，不私装宿主服务副本。机器读取 `npm pack --json` 时保持 `--silent`，避免 lifecycle 输出混入 JSON stream。
-3. 更新到最新可用 DSH release 并记录 `dsh --version`。分别从 npm 包、固定 Git commit、源码 checkout 和 tarball 安装到临时 profile，再执行 `dsh --profile <profile> --dump-config`，确认与 `cordis.patch.yml` 一致：新增 `ptc-plus-execution`、`ptc-plus` 两项，并将原 `ptc-runtime` 的 `ptcRuntime` 服务隔离到 `ptc-plus-original`。每个上游 release 都重新验证公共扩展面、CLI/Web 集成和 profile 装配，不设置版本白名单。
+3. 更新到最新可用 DSH release 并记录 `dsh --version`。分别从 npm 包、固定 Git commit、源码 checkout 和 tarball 安装到临时 profile，再执行 `dsh --profile <profile> --dump-config`，确认与 `cordis.patch.yml` 一致：新增 `ptc-plus-execution`、`ptc-plus` 两项，并将原 `ptc-runtime` 的 `ptcRuntime` 服务隔离到 `ptc-plus-original`。每个上游 release 都重新验证公共扩展面、CLI/Web 集成和 profile 装配，并核对 `engines.dsh` 的上下界；范围内的宿主升级保留现有边界，运行时不按版本号选择接口。
 4. 在 Windows 与 Linux 运行无模型调用的 `npm run test:client:web -- --dsh-entry <latest-installed-dsh/lib/bin.js>`，验证 tarball 安装后的真实 Web Client、设置与对话 surface；浏览器前置条件见 [安装指南](installation.md)。`build:check`、Host ESM import 和 factory smoke 均不能替代浏览器激活验收。macOS 由原生 runner 验证 CLI/Web；Windows 与 macOS Desktop 从托盘打开当前 profile 的 DSH Terminal 安装，重启 Desktop 后做一次 PTC 模式 smoke。Desktop 当前发布平台不包括 Linux。界面有变化时用同一前置条件刷新 README 截图：`npm run readme:screenshots -- --dsh-entry <latest-installed-dsh/lib/bin.js>` 从当前打包候选各写回一帧中英文 REPL 工作台与设置窗口；先用 `--out <directory>` 落到别处检查，命令、前置条件与失败边界见 [安装指南](installation.md)。
 5. 只有在明确授权模型消耗后才运行 `npm run test:expensive` 与 `npm run test:ab`；发布候选还要用 `DSH_PTC_ACCEPTANCE_SCENARIOS=managed-adaptive-surface,managed-session-resume,managed-surface-change,subagent-continuity` 追加托管能力面、会话恢复、宿主表面变化与子代理场景（运行方式、预算与版本差异判别见[评估](evaluation.md#managed-session-continuity-cohort)）。发布结论以结构化测试结果为准，不把一次模型样本推广为普遍保证。
 6. 确认 npm 包名可用、待发布版本高于 registry 版本、README 截图来自真实 DSH 会话，并核对 repository、homepage、bugs、license 与 `dsh-plugin` topic。

package/docs/release-notes.md

@@ -25,7 +25,7 @@
 4. **升级要求**：Node 版本、是否需要重启、是否有配置迁移。
 5. **内部交付**默认不出现；只有当它改变用户可见结果时，才用用户能理解的方式提及。
 
-兼容性声明落在公共扩展面上——设置座位、slot、公共 `Menu` 区域、会话投影、能力探测。版本号只用于标明本次适配的目标发行，不构成版本白名单；能力与座位仍以宿主声明的公共扩展面为准（[ADR 0017](adr/0017-track-the-latest-dsh-public-surface.md)）。
+兼容性声明落在公共扩展面上——设置座位、slot、公共 `Menu` 区域、会话投影、能力探测。版本号可用于标明本次适配的目标发行及 `engines.dsh` 的安装准入范围；运行时能力与座位仍以宿主声明的公共扩展面为准（[ADR 0017](adr/0017-track-the-latest-dsh-public-surface.md)）。
 
 ## 风格
 

package/docs/releases/v0.5.4.md

@@ -2,7 +2,7 @@
 
 <h3 id="cn-v054">宿主适配</h3>
 
-* 目标仍是当前官方 DSH 发行：插件继续使用它的公共扩展面（设置卡片座位、会话投影、能力探测与公共 `Menu`），本版本不要求宿主侧改动，也不按宿主版本分支；`engines.dsh` 声明 `>=0.2.1-0 <0.2.3`
+* 适配 DSH `0.2.2-alpha.3` 的公共扩展面，并保留上一代宿主调用方式；设置卡片、会话投影与公共 `Menu` 不要求宿主侧改动。兼容性按公共能力判定，不按版本号分支
 * 会话的能力决定与绑定取用改为写进会话日志本身，不再占用对话消息：重载或重启后恢复会话时，面板读到的仍是当时那次决定，模型也不会因此多收到一条消息
 * 支持哪些宿主仍由通道表达，而不是由版本号判定：`latest` 与 `next` 是阻塞通道，`alpha` 线只报告结果
 
@@ -15,6 +15,7 @@
 
 <h3>修复</h3>
 
+* 新版 DSH 中，`edit_run_code` 接受的修订继续属于原调用，保留本次运行可用的工具范围，并遵循宿主的策略与取消决定；后续单元格能继续使用修订后的状态
 * 本会话关闭过的能力不再出现在任何模型可见处：`tools:sdk` 声明块、程序里真实的 `tools` 成员、`capabilities.*` 的探索结果，以及能力方案与说明段，都与这个会话真正可调的成员保持一致，关闭的能力不会只剩声明还在
 * 已保存的开关单独成列陈述，不再与本会话的记录混读：一列只回答「保存了什么」，另一列只回答「这个会话记录了什么」
 * 能力状态改用整块样式区分，而不是给控件里的文字染色：下拉控件保持正常文字颜色，只改它的填充与边框，行首的标记与那一格的词照旧陈述状态；只陈述文字的那一列改用同样底色的胶囊标签
@@ -27,8 +28,9 @@
 
 <h3>升级</h3>
 
-* 需要 Node.js `^22.19.0 || >=24.0.0`；升级插件后请重启 DSH
-* 不需要配置迁移：本版本不改配置字段；已有会话日志不需要清理或重写
+* Node.js 需同时满足插件的 `^22.19.0 || >=24.0.0` 与所选 DSH 的要求；DSH `0.2.2-alpha.3` 要求 Node.js `>=24.9.0`。升级插件后请重启 DSH
+* 不需要迁移插件配置
+* 若旧会话因能力决定或绑定取用被写到受保护的会话头之前而无法导出或重新打开，请先停止使用该 profile 的宿主，再用仓库 checkout 中的 `scripts/repair-session-log.mjs` 修复；该脚本不随 npm 包发布，插件升级不会自动改写历史日志。用法见[安装指南](../installation.md#troubleshooting)
 
 ```sh
 dsh plugin --profile <profile> add dsh-ptc-plus@0.5.4
@@ -38,7 +40,7 @@ dsh plugin --profile <profile> add dsh-ptc-plus@0.5.4
 
 <h3 id="en-v054">Host Compatibility</h3>
 
-* It still targets the current official DSH release and keeps using its public extension surfaces (the settings card seat, the session projection, capability probing and the public `Menu`); no host-side change is required, and no behaviour branches on a host version. `engines.dsh` declares `>=0.2.1-0 <0.2.3`
+* Adapts to the public extension surfaces of DSH `0.2.2-alpha.3` while retaining the previous Host invocation contract. Settings cards, session projections and the public `Menu` require no Host-side changes. Compatibility follows public capabilities rather than version branches
 * A session's capability decisions and binding adoption are now written into the session log itself instead of taking up conversation messages: when a session is reloaded or resumed after a restart, the panel still reads the decision that was made, and the model receives no extra message for it
 * Which hosts are supported is still expressed as channels rather than decided by a version number: `latest` and `next` are the blocking channels, and the `alpha` line is reported on without blocking a release
 
@@ -51,6 +53,7 @@ dsh plugin --profile <profile> add dsh-ptc-plus@0.5.4
 
 <h3>Fixes</h3>
 
+* On the new DSH, a revision accepted by `edit_run_code` stays within its original call, retains the tools admitted for that run, and follows Host policy and cancellation; later cells can continue using the revised state
 * A capability this session closed no longer appears anywhere the model can see: the `tools:sdk` declaration block, the real `tools` members of a program, what `capabilities.*` can explore, and the capability plans and guidance sections all agree with the members this session can actually call, so a closed capability is never left declared on its own
 * The saved switch is stated in its own column instead of being read together with this session's record: one column answers only "what is saved", the other only "what this session recorded"
 * A capability state is told apart by the whole control instead of by tinting its words: a dropdown keeps the normal label colour and only its fill and border change, the row mark and the cell word still state the state, and a word-only cell states it as a chip of the same tone
@@ -63,8 +66,9 @@ dsh plugin --profile <profile> add dsh-ptc-plus@0.5.4
 
 <h3>Upgrade</h3>
 
-* Requires Node.js `^22.19.0 || >=24.0.0`; restart DSH after upgrading the plugin
-* No configuration migration is needed: no configuration field changes in this version, and existing session logs need no cleanup or rewrite
+* Node.js must satisfy both the plugin's `^22.19.0 || >=24.0.0` range and the selected DSH requirements; DSH `0.2.2-alpha.3` requires Node.js `>=24.9.0`. Restart DSH after upgrading the plugin
+* No plugin configuration migration is needed
+* If an older session cannot be exported or reopened because capability decisions or binding adoption were written before its protected session head, stop the Host using that profile and repair the log with `scripts/repair-session-log.mjs` from the repository checkout. The script is not shipped in the npm package, and a plugin upgrade does not rewrite historical logs automatically. See the [installation guide](../installation.md#troubleshooting) for usage
 
 ```sh
 dsh plugin --profile <profile> add dsh-ptc-plus@0.5.4

package/docs/releases/v0.5.5.md

@@ -0,0 +1,41 @@
+[中文](#cn-v055) | [English](#en-v055)
+
+<h3 id="cn-v055">宿主适配</h3>
+
+* 适配 DSH `0.2.2-rc.1` 的公共工具执行接口，保留上一代宿主的调用方式；兼容性按宿主提供的公共能力判定
+
+<h3>修复</h3>
+
+* 新版 DSH 中，`edit_run_code` 接受的修订保留原调用关系和本次运行可用的工具范围，继续遵循宿主策略与取消决定；后续单元格能继续使用修订后的状态
+
+<h3>升级</h3>
+
+* Node.js 需同时满足插件的 `^22.19.0 || >=24.0.0` 与所选 DSH 的要求；DSH `0.2.2-rc.1` 要求 Node.js `>=24.9.0`
+* 无需迁移插件配置；升级后重启 DSH。插件升级不会自动改写历史会话日志
+
+```sh
+dsh plugin --profile <profile> add dsh-ptc-plus@0.5.5
+```
+
+---
+
+<h3 id="en-v055">Host Compatibility</h3>
+
+* Adapts to the public tool execution interface of DSH `0.2.2-rc.1` while retaining the previous Host invocation contract; compatibility follows the public capabilities the Host provides
+
+<h3>Fixes</h3>
+
+* On the new DSH, a revision accepted by `edit_run_code` retains its original call relationship and the tools admitted for that run, and continues to follow Host policy and cancellation; later cells can continue using the revised state
+
+<h3>Upgrade</h3>
+
+* Node.js must satisfy both the plugin's `^22.19.0 || >=24.0.0` range and the selected DSH requirements; DSH `0.2.2-rc.1` requires Node.js `>=24.9.0`
+* No plugin configuration migration is needed; restart DSH after upgrading. A plugin upgrade does not rewrite historical session logs automatically
+
+```sh
+dsh plugin --profile <profile> add dsh-ptc-plus@0.5.5
+```
+
+---
+
+Full Changelog: https://github.com/muyuanjin/dsh-ptc-plus/compare/v0.5.4...v0.5.5

package/docs/releases/v0.5.6.md

@@ -0,0 +1,41 @@
+[中文](#cn-v056) | [English](#en-v056)
+
+<h3 id="cn-v056">宿主适配</h3>
+
+* 声明 DSH 兼容范围 `>=0.2.1-0 <0.2.3`，由宿主按官方版本预检规则判断安装与启动资格；`0.2.2-rc.1` 在该范围内
+
+<h3>修复</h3>
+
+* 修复 0.5.5 将 DSH 兼容范围意外改成 `*` 的问题，恢复 0.5.4 的上下界；范围内的运行时接口仍按宿主公共能力选择
+
+<h3>升级</h3>
+
+* Node.js 需同时满足插件的 `^22.19.0 || >=24.0.0` 与所选 DSH 的要求；DSH `0.2.2-rc.1` 要求 Node.js `>=24.9.0`
+* 无需迁移插件配置；升级后重启 DSH
+
+```sh
+dsh plugin --profile <profile> add dsh-ptc-plus@0.5.6
+```
+
+---
+
+<h3 id="en-v056">Host Compatibility</h3>
+
+* Declares the DSH compatibility range `>=0.2.1-0 <0.2.3`; the Host applies its official version preflight to installation and startup. This range includes `0.2.2-rc.1`
+
+<h3>Fixes</h3>
+
+* Fixes 0.5.5 unintentionally changing the DSH compatibility range to `*`, restoring the bounds from 0.5.4; runtime interfaces within that range continue to follow the Host's public capabilities
+
+<h3>Upgrade</h3>
+
+* Node.js must satisfy both the plugin's `^22.19.0 || >=24.0.0` range and the selected DSH requirements; DSH `0.2.2-rc.1` requires Node.js `>=24.9.0`
+* No plugin configuration migration is needed; restart DSH after upgrading
+
+```sh
+dsh plugin --profile <profile> add dsh-ptc-plus@0.5.6
+```
+
+---
+
+Full Changelog: https://github.com/muyuanjin/dsh-ptc-plus/compare/v0.5.5...v0.5.6

package/internal/edit-transport-owner.js

@@ -310,8 +310,9 @@ export function createEditTransportOwner(ctx, {
           subCallId: `${String(exec.callId)}:derived`, name: RUN_CODE, arguments: argumentsValue }
         const executionStart = agent.session.append('tool/ptc-dispatch-start', data)
         const derivedExec = { callId: data.subCallId, rootCallId: data.rootCallId,
-          parent: rootExec.token, name: RUN_CODE, arguments: argumentsValue, agent, signal: rootSignal }
-        const dispatch = () => dispatchToolCall(ctx.tools, derivedExec)
+          parent: rootExec.token, name: RUN_CODE, arguments: argumentsValue, agent, signal: rootSignal,
+          ...(rootExec.toolSet === undefined ? {} : { toolSet: rootExec.toolSet }) }
+        const dispatch = () => dispatchToolCall(ctx.tools, derivedExec, ctx)
         const tentative = await executeTentative(executionStart.seq, start.rootCallSeq,
           dispatch, executionLog, derivedExec)
         const inner = tentative.result

package/internal/host-tool-sdk.js

@@ -260,41 +260,29 @@ export function sessionExecutionAvailable(tools, scope, name = 'run_code') {
 }
 
 /**
- * Executions this plugin submitted under the host's batch dispatch contract.
+ * Dispatch one tool call through the Host's invocation policy.
  *
- * That contract assigns the execution identity itself, so the execution object a
- * host runs is not the one the caller built and carries no parent token the caller
- * could compare. The submission record is what remains: the call id this plugin
- * chose, which the host matched its result back to.
- */
-const batchSubmissions = new WeakSet()
-
-/**
- * Whether this execution was submitted as a host batch call.
- * @param {object} execution - an execution object this plugin built.
- * @returns {boolean} true when the batch contract dispatched it.
- */
-export function isBatchSubmission(execution) {
-  return execution !== null && typeof execution === 'object' && batchSubmissions.has(execution)
-}
-
-/**
- * Dispatch one tool call through the host registry.
- *
- * Two dispatch contracts are published. A registry host accepts one call and
- * resolves to that call's settled result. An executor host accepts a complete
- * model batch, assigns the execution identity itself, and resolves to the
- * ordered outcomes — so the caller supplies only the call it wants run, and the
- * executor's own token is the one its observers see.
+ * Registry Hosts accept an execution input directly. Executor Hosts reserve
+ * batches for root calls; nested inputs use the published invocation pipeline
+ * so the Host retains their actual parent token and enclosing root identity.
+ * The Host owns validation, policy, cancellation and result materialization.
  * @param {object} tools - the host tool registry (`ctx.tools`).
  * @param {object} execution - call identity, arguments, agent and signal.
+ * @param {object} [ctx] - the owning plugin context, required for nested execution.
  * @returns {Promise<object>} this call's settled result.
  */
-export async function dispatchToolCall(tools, execution) {
+export async function dispatchToolCall(tools, execution, ctx) {
   if (typeof tools?.selectExecutor !== 'function') return tools.execute(execution)
-  // Recorded before the host runs the batch: it calls back into this plugin during
-  // the dispatch, and the relation has to be provable then.
-  batchSubmissions.add(execution)
+  if (execution.parent !== undefined) {
+    if (ctx === undefined) throw new Error('ptc-plus: nested Host execution requires its owning context')
+    const { ToolExecutionPipeline } = await import('@deepseek-ai/dsh-tools/pipeline')
+    const pipeline = new ToolExecutionPipeline(ctx, {
+      get: (name, scope) => hostTransportDefinition(tools, scope, name),
+    })
+    const prepared = await pipeline.prepare(execution)
+    const outcome = prepared.kind === 'dispatch' ? await pipeline.dispatch(prepared.exec) : prepared
+    return pipeline.complete(prepared.exec, outcome)
+  }
   const settled = await tools.execute({
     calls: [{ id: execution.callId, name: execution.name, arguments: JSON.stringify(execution.arguments) }],
     signal: execution.signal,

package/internal/runtime-bridge-owner.js

@@ -25,7 +25,7 @@ import {
 } from './program-bindings.js'
 import { deepFreeze } from './record-utils.js'
 import { adaptRunCodeSchema } from './direct-surface-owner.js'
-import { hostTransportDefinition, isBatchSubmission } from './host-tool-sdk.js'
+import { hostTransportDefinition } from './host-tool-sdk.js'
 import { REPL_MEMORY_META_KEY, withReplMemorySnapshot } from './repl-memory-projection.js'
 import { withUserBindingDraftCapability } from './user-binding-draft-projection.js'
 import { POST_EDIT_KEY } from './session-journal-schema.js'
@@ -702,17 +702,13 @@ function applyEditableSlots(definition, promptText, slotPatches) {
   /**
    * Whether this execution is the derived execution the edit transport submitted.
    *
-   * A registry host runs the very object the plugin built, so the call id, the root
-   * call and the parent token it carries all prove the relation. The batch contract
-   * assigns its own identity instead: the parent token is the host's own and the
-   * root call is whichever call that host treats as direct. What survives there is
-   * the call id this plugin chose, which the host matched the batch result back to,
-   * together with the dispatch record; the derived source is compared beside it.
+   * Both Host invocation contracts preserve the submitted call id, enclosing
+   * root and actual parent token. All three must match; a root batch submission
+   * cannot establish a nested execution merely by choosing the same call id.
    */
   const isDerivedExecution = (derived, exec) => {
     if (derived === null || typeof derived !== 'object' || exec === null || typeof exec !== 'object') return false
     if (derived.callId !== exec.callId) return false
-    if (isBatchSubmission(derived)) return true
     return exec.parent !== undefined
       && derived.rootCallId === exec.rootCallId && derived.parent === exec.parent
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-ptc-plus",
-  "version": "0.5.4",
+  "version": "0.5.6",
   "icon": "assets/ptc-plus-icon.svg",
   "description": "A session-bound agent-native REPL for DeepSeek Harness PTC mode.",
   "type": "module",
@@ -52,7 +52,7 @@
     "@babel/code-frame": "^7.29.7",
     "@babel/parser": "^7.29.0",
     "@deepseek-ai/dsh-util-values": "^0.2.2-alpha.2",
-    "@deepseek-ai/schemastery": "~3.18.6-alpha.1",
+    "@deepseek-ai/schemastery": "~3.18.6-alpha.2",
     "@jridgewell/trace-mapping": "^0.3.31",
     "acorn": "^8.15.0"
   },
@@ -174,12 +174,12 @@
     "@codemirror/language": "^6.12.4",
     "@codemirror/state": "^6.7.4",
     "@codemirror/view": "^6.43.11",
-    "@deepseek-ai/cordis": "4.0.6-alpha.1",
-    "@deepseek-ai/cordis-plugin-group": "1.0.6-alpha.1",
-    "@deepseek-ai/cordis-plugin-include": "1.0.11-alpha.1",
-    "@deepseek-ai/cordis-plugin-loader": "1.0.7-alpha.1",
-    "@deepseek-ai/cordis-plugin-timer": "1.1.8-alpha.1",
-    "@deepseek-ai/cosmokit": "1.8.7-alpha.1",
+    "@deepseek-ai/cordis": "4.0.6-alpha.2",
+    "@deepseek-ai/cordis-plugin-group": "1.0.6-alpha.2",
+    "@deepseek-ai/cordis-plugin-include": "1.0.11-alpha.2",
+    "@deepseek-ai/cordis-plugin-loader": "1.0.7-alpha.2",
+    "@deepseek-ai/cordis-plugin-timer": "1.1.8-alpha.2",
+    "@deepseek-ai/cosmokit": "1.8.7-alpha.2",
     "@deepseek-ai/dsh": "alpha",
     "@deepseek-ai/dsh-agent-loop": "alpha",
     "@deepseek-ai/dsh-agent-loop-testkit": "alpha",