@bruc3van/dsh-doctor 0.5.9 → 0.6.0

package/README.en.md

@@ -6,7 +6,7 @@ DSH Doctor is an upgrade and troubleshooting tool for DSH plugin developers and
 
 When a change depends on the plugin's business logic, Doctor calls it out for the agent or developer instead of guessing. Every edit is previewed and backed up first, and runtime checks use a temporary DSH environment rather than the developer's everyday profile.
 
-> This is a community-maintained third-party project, not an official DeepSeek project. The current migration scope is DSH 0.1.1 → 0.1.2. The catalog exactly covers `dsh-v0.1.1-rc.2` → `dsh-v0.1.2-rc.1` and retains the alpha.2 and alpha.3 historical rules. Differences outside those catalogs still require a separate investigation and are not proven compatible by the catalog.
+> This is a community-maintained third-party project, not an official DeepSeek project. The current migration scope is DSH 0.1.1 → 0.1.5. The catalog exactly covers `dsh-v0.1.1-rc.2` → `dsh-v0.1.5-rc.2` and retains the 0.1.2 alpha.2, alpha.3, and rc.1 historical rules. Differences outside those catalogs still require a separate investigation and are not proven compatible by the catalog.
 
 ## What it helps with
 
@@ -36,21 +36,21 @@ npx skills add bruc3van/dsh-doctor
 After installation, ask the agent from inside the plugin repository that needs migration:
 
 ```text
-Adjust and verify this plugin so that it is compatible with DSH 0.1.2.
+Adjust and verify this plugin so that it is compatible with DSH 0.1.5.
 ```
 
 The skill guides the agent to:
 
 1. establish the plugin, actual DSH installation, Harness checkout, package manager, and usable DSH Doctor;
 2. analyze source, dependencies, configuration, patches, and existing artifacts;
-3. confirm whether the upgraded plugin release targets only 0.1.2 or must remain compatible with 0.1.1;
+3. confirm whether the upgraded plugin release targets only 0.1.5 or must remain compatible with 0.1.1;
 4. preview and apply exact changes allowed by that compatibility strategy, then handle semantic migrations that require business context;
 5. rebuild and report static, artifact, isolated-runtime, and business-behavior evidence separately;
 6. commit or publish through the plugin repository's own process only when the developer explicitly requests it.
 
 `npx skills add` installs agent instructions only; it does not install DSH Doctor globally. The skill checks the local CLI and npm registry first. If the local version is unsuitable, it runs a pinned version through `npm exec` without changing the global installation.
 
-An upgrade request does not itself authorize dropping the old runtime. When compatibility intent is missing, the skill may perform read-only analysis but asks before migration writes, dependency installation, build, or runtime commands. Dual-version mode requires separate 0.1.1 and 0.1.2 evidence; one 0.1.2 smoke test is not dual-version proof.
+An upgrade request does not itself authorize dropping the old runtime. When compatibility intent is missing, the skill may perform read-only analysis but asks before migration writes, dependency installation, build, or runtime commands. Dual-version mode requires separate 0.1.1 and 0.1.5 evidence; one 0.1.5 smoke test is not dual-version proof.
 
 ## How it works
 
@@ -72,9 +72,9 @@ investigate the actual environment
   → plugin business-behavior verification
 ```
 
-DSH 0.1.2 changes more than package versions. Legacy owners such as `dsh-client-runtime` and `dsh-host-apiproxy` were split, while Session, Workspace, Conversation, pending interaction, and Settings capabilities moved to new controllers, UI packages, or Services. The CLI only auto-edits relationships marked `exact`; ownership, lifecycle, and business-call changes are reported as `MIG_SEMANTIC_API_CHANGE`.
+Migrating from DSH 0.1.1 to 0.1.5 changes more than package versions. Legacy owners such as `dsh-client-runtime` and `dsh-host-apiproxy` were split, while Session, Workspace, Conversation, pending interaction, and Settings capabilities moved to new controllers, UI packages, or Services; between 0.1.2 and 0.1.5 no package was removed again, and the added session-format or sidebar packages are purely additive capabilities. The CLI only auto-edits relationships marked `exact`; ownership, lifecycle, and business-call changes are reported as `MIG_SEMANTIC_API_CHANGE`.
 
-With an exact Harness checkout, Doctor also verifies the commits behind the two catalog tags and compares entry ids in the target web profile. After the additional source interval has been investigated, `--target-version` can bind dependencies and runtime checks to a newer 0.1.2 target, but it does not extend the catalog's API claims.
+With an exact Harness checkout, Doctor also verifies the commits behind the two catalog tags and compares entry ids in the target web profile. After the additional source interval has been investigated, `--target-version` can bind dependencies and runtime checks to a newer 0.1.5 target, but it does not extend the catalog's API claims.
 
 ## Core capabilities
 

package/README.md

@@ -6,7 +6,7 @@ DSH Doctor 是给 DSH 插件开发者和 Agent 使用的升级、排障工具。
 
 遇到需要理解业务逻辑的改动，它会明确列出来交给 Agent 或开发者处理，不会直接猜。所有修改都会先生成预览并保留备份，运行验证也会放在临时 DSH 环境中，不影响日常使用的 profile。
 
-> 这是社区维护的第三方工具，不属于 DeepSeek 官方项目。当前迁移范围是 DSH 0.1.1 → 0.1.2；catalog 精确覆盖 `dsh-v0.1.1-rc.2` → `dsh-v0.1.2-rc.1`，并保留 alpha.2、alpha.3 历史规则。未收录的版本差异仍需单独调查，不能视为 catalog 已证明兼容。
+> 这是社区维护的第三方工具，不属于 DeepSeek 官方项目。当前迁移范围是 DSH 0.1.1 → 0.1.5；catalog 精确覆盖 `dsh-v0.1.1-rc.2` → `dsh-v0.1.5-rc.2`，并保留 0.1.2 的 alpha.2、alpha.3、rc.1 历史规则。未收录的版本差异仍需单独调查，不能视为 catalog 已证明兼容。
 
 ## 它能解决什么问题
 
@@ -36,21 +36,21 @@ npx skills add bruc3van/dsh-doctor
 安装完成后，在需要迁移的插件仓库中告诉 Agent：
 
 ```text
-请调整并验证当前插件，使其兼容 DSH 0.1.2。
+请调整并验证当前插件，使其兼容 DSH 0.1.5。
 ```
 
 Skill 会引导 Agent：
 
 1. 核实插件、实际 DSH、Harness checkout、包管理器和可用的 DSH Doctor；
 2. 分析源码、依赖、配置、patch 和已有产物；
-3. 确认升级后的同一插件版本是仅支持 0.1.2，还是继续兼容 0.1.1；
+3. 确认升级后的同一插件版本是仅支持 0.1.5，还是继续兼容 0.1.1；
 4. 预览并应用符合兼容策略的精确修改，再处理需要理解业务的语义迁移；
 5. 重新构建，并分别报告静态、产物、隔离运行时和业务行为证据；
 6. 仅在开发者明确要求后，按插件仓库自己的流程提交和发布。
 
 `npx skills add` 只安装 Agent 指令，不会全局安装 DSH Doctor。Skill 会先检查本地 CLI 和 npm registry；本地版本不合适时，默认通过固定版本的 `npm exec` 运行，不会自行修改全局安装。
 
-升级请求本身不代表可以放弃旧版。兼容目标未明确时，Skill 可以先做只读分析，但会在迁移写入、依赖安装、构建或运行时命令前要求确认。双版本模式必须分别验证 0.1.1 和 0.1.2，不能用一次 0.1.2 smoke 代替双版本结论。
+升级请求本身不代表可以放弃旧版。兼容目标未明确时，Skill 可以先做只读分析，但会在迁移写入、依赖安装、构建或运行时命令前要求确认。双版本模式必须分别验证 0.1.1 和 0.1.5，不能用一次 0.1.5 smoke 代替双版本结论。
 
 ## 工作原理
 
@@ -72,9 +72,9 @@ DSH Doctor 由三个相互约束的部分组成：
   → 插件业务行为验证
 ```
 
-DSH 0.1.2 不只是包版本变化。`dsh-client-runtime` 和 `dsh-host-apiproxy` 等旧 owner 被拆分，Session、Workspace、Conversation、pending interaction、Settings 等能力迁移到新的 controller、UI 包或 Service。CLI 只自动修改 catalog 标记为 `exact` 的关系；所有权、生命周期和业务调用变化会作为 `MIG_SEMANTIC_API_CHANGE` 报告。
+从 DSH 0.1.1 迁移到 0.1.5 不只是包版本变化。`dsh-client-runtime` 和 `dsh-host-apiproxy` 等旧 owner 被拆分，Session、Workspace、Conversation、pending interaction、Settings 等能力迁移到新的 controller、UI 包或 Service；0.1.2 到 0.1.5 之间没有再移除任何包，新增的 session-format、sidebar 等包是纯增量能力。CLI 只自动修改 catalog 标记为 `exact` 的关系；所有权、生命周期和业务调用变化会作为 `MIG_SEMANTIC_API_CHANGE` 报告。
 
-如果提供精确 Harness checkout，Doctor 还会确认 catalog 中两个 tag 的 commit，并比较目标 web profile 的 entry id。`--target-version` 可以在完成额外源码调查后绑定更新的 0.1.2 依赖与 runtime 目标，但不会扩大 catalog 的 API 结论。
+如果提供精确 Harness checkout，Doctor 还会确认 catalog 中两个 tag 的 commit，并比较目标 web profile 的 entry id。`--target-version` 可以在完成额外源码调查后绑定更新的 0.1.5 依赖与 runtime 目标，但不会扩大 catalog 的 API 结论。
 
 ## 核心能力
 

package/migrations/dsh-v0.1.1-rc.2__dsh-v0.1.5-rc.2/behavior.md

@@ -0,0 +1,26 @@
+# DSH 0.1.1-rc.2 to 0.1.5-rc.2 behavior migration
+
+The old Client Runtime was split by ownership. There is no aggregate replacement package.
+
+- Session control, list state, commands, projections, queue and event windows belong to `api-session-controller/client`.
+- Workspace state and commands belong to `api-workspace-controller/client`; navigation policy belongs to `ui-workspace`.
+- Conversation assembly belongs to `ui-conversation`; Chat and Trajectory own their respective projections.
+- Approval and Question own their pending objects; `ui-session` only aggregates domain publications.
+- The store engine belongs to `client-store`; React hook synthesis belongs to the renderer.
+- The Host API Proxy was removed. Unary browser operations live on their natural Remote service owners.
+- The demo-only `dsh-agent-spine-demo` package and the SQLite session persistence package were removed; neither has a catalog-confirmed drop-in replacement.
+- `dsh-tool-subagent-report` was removed after alpha.3: child reporting and parent follow-up were unified into one Steer messaging operation (`SubagentRuntime.sendMessage`, exposed to models through `tool-subagent-control`). Migrating a report-tool integration is semantic work, not an import move.
+- `dsh-code-runtime-python` was renamed to `dsh-experimental-code-runtime-python` when the package moved to the experimental tier. The module rename is exact in shape, but the experimental placement is a support-level change the developer must accept deliberately.
+- 0.1.2 adds the `dsh-session-turn-outline` package and extends session submission/load-through APIs. These additions do not justify mechanical rewrites of existing plugin behavior.
+
+## Interval 0.1.2-rc.1 to 0.1.5-rc.2
+
+Verified against both tags: no `@deepseek-ai/dsh-*` package was removed or renamed, and the plugin-facing entrypoints the 0.1.2 migration moves plugins onto (`dsh-settings`, `dsh-client-store`, `dsh-client-ui-session`, `dsh-client-ui-chat`, `dsh-sdk-minimal`, `dsh-webhook`) are unchanged. 0.1.3 never shipped a stable tag and 0.1.4 was skipped upstream.
+
+- The web profile removed the patch entries `client-runtime`, `api-gateway`, `tool-subagent-report`, and `tool-str-replace-editor` (verified by scanning both refs' bundle patches; `api-gateway` the entry is gone even though the `dsh-api-gateway` package survives). A plugin overlay that patches one of these entry ids must be re-anchored to the surviving owner entry.
+- 18 packages were added (session-format family with v0-to-v3 migrations, client file-upload and resources, client-ui sidebar packages, dockkit, open-in-app, http-proxy, chunked-list, package-manifest, tool-present, api-workspace-files, host-open-in-app). Additions never force a rewrite; adopt them only when the plugin needs the new capability.
+- `dsh-client-connection` dropped `webServer` from its inject list; export signatures are unchanged. A plugin that injected `webServer` through this module must find the new owner itself.
+- The CLI adds `--from-default-profile <name>` for creating custom profiles from shipped templates. Existing flags and the `profiles/<name>/package.json` layout are unchanged.
+- Cordis stays at 4.0.2, so `--target-version 0.1.5-rc.2` pins only the DSH packages.
+
+An import move is safe only when the catalog marks it `exact`. A `semantic` mapping identifies the new owner but still requires the plugin developer to rewrite behavior and verify the real lifecycle.

package/migrations/dsh-v0.1.1-rc.2__dsh-v0.1.5-rc.2/config-rules.json

@@ -0,0 +1,36 @@
+{
+  "platformModules": [
+    "react",
+    "react/jsx-runtime",
+    "react-dom",
+    "react-dom/client",
+    "@deepseek-ai/cordis",
+    "@deepseek-ai/dsh-client-store",
+    "@deepseek-ai/dsh-client-ui-slots",
+    "@deepseek-ai/dsh-client-ui-primitives"
+  ],
+  "profilePatchPaths": {
+    "web": [
+      "packages/bundle/base/cordis.patch.yml",
+      "packages/bundle/web-app/cordis.patch.yml"
+    ]
+  },
+  "rules": [
+    {
+      "id": "client-inject-is-informational",
+      "note": "dsh.client.inject lists package dependency edges; Cordis service inject controls activation."
+    },
+    {
+      "id": "baseline-external-is-implicit",
+      "note": "Platform modules are implicit and must not be repeated in dsh.client.external."
+    },
+    {
+      "id": "feature-values-use-services-or-slots",
+      "note": "Feature plugins must not use dsh.client.external as a feature-to-feature value dependency mechanism."
+    },
+    {
+      "id": "client-export-required",
+      "note": "A web dsh.client declaration requires a published exports[\"./client\"] artifact."
+    }
+  ]
+}

package/migrations/dsh-v0.1.1-rc.2__dsh-v0.1.5-rc.2/manifest.json

@@ -0,0 +1,19 @@
+{
+  "schemaVersion": 1,
+  "id": "dsh-v0.1.1-rc.2__dsh-v0.1.5-rc.2",
+  "from": {
+    "ref": "dsh-v0.1.1-rc.2",
+    "commit": "b150a551b8d465e31e418e1b2eaf5e79bbb7d28e"
+  },
+  "to": {
+    "ref": "dsh-v0.1.5-rc.2",
+    "commit": "fb2c4b9e698e30edb738bca4cf0618587db7d203",
+    "version": "0.1.5-rc.2"
+  },
+  "description": "DeepSeek Harness 0.1.1-rc.2 to 0.1.5-rc.2 plugin migration",
+  "references": {
+    "ownership": ".agents/notes/implemented/architecture/2026-08-20-client-session-conversation-ownership.md",
+    "clientRules": "packages/client/AGENTS.md",
+    "steerMessaging": ".agents/notes/implemented/architecture/2026-08-27-adjacent-agent-steer-messaging.md"
+  }
+}

package/migrations/dsh-v0.1.1-rc.2__dsh-v0.1.5-rc.2/packages.json

@@ -0,0 +1,101 @@
+{
+  "removed": [
+    "@deepseek-ai/dsh-acp-demo",
+    "@deepseek-ai/dsh-acp-snapshot",
+    "@deepseek-ai/dsh-agent-spine-demo",
+    "@deepseek-ai/dsh-client-runtime",
+    "@deepseek-ai/dsh-code-runtime-python",
+    "@deepseek-ai/dsh-host-apiproxy",
+    "@deepseek-ai/dsh-sdk-jsonrpc-demo",
+    "@deepseek-ai/dsh-session-persistence-sqlite",
+    "@deepseek-ai/dsh-tool-subagent-report"
+  ],
+  "added": [
+    "@deepseek-ai/dsh-acp-app",
+    "@deepseek-ai/dsh-api-session-controller",
+    "@deepseek-ai/dsh-api-settings-controller",
+    "@deepseek-ai/dsh-api-workspace-controller",
+    "@deepseek-ai/dsh-api-workspace-files",
+    "@deepseek-ai/dsh-chunked-list",
+    "@deepseek-ai/dsh-client-file-upload",
+    "@deepseek-ai/dsh-client-resources",
+    "@deepseek-ai/dsh-client-store",
+    "@deepseek-ai/dsh-client-ui-approval",
+    "@deepseek-ai/dsh-client-ui-chat",
+    "@deepseek-ai/dsh-client-ui-dockkit",
+    "@deepseek-ai/dsh-client-ui-open-in-app",
+    "@deepseek-ai/dsh-client-ui-schedule",
+    "@deepseek-ai/dsh-client-ui-session",
+    "@deepseek-ai/dsh-client-ui-sidebar-documentpreview",
+    "@deepseek-ai/dsh-client-ui-sidebar-files",
+    "@deepseek-ai/dsh-client-ui-sidebar-right",
+    "@deepseek-ai/dsh-deepseek-llm-api-extensions",
+    "@deepseek-ai/dsh-deque",
+    "@deepseek-ai/dsh-experimental-agent-team-profile",
+    "@deepseek-ai/dsh-experimental-agent-team-web-profile",
+    "@deepseek-ai/dsh-experimental-client-ui-agent-team",
+    "@deepseek-ai/dsh-experimental-code-runtime-python",
+    "@deepseek-ai/dsh-experimental-inspector",
+    "@deepseek-ai/dsh-experimental-webworker-packer",
+    "@deepseek-ai/dsh-experimental-webworker-runtime",
+    "@deepseek-ai/dsh-host-open-in-app",
+    "@deepseek-ai/dsh-http-proxy",
+    "@deepseek-ai/dsh-package-manifest",
+    "@deepseek-ai/dsh-plugin-package-inventory-deepseek",
+    "@deepseek-ai/dsh-sdk-app",
+    "@deepseek-ai/dsh-sdk-minimal",
+    "@deepseek-ai/dsh-session-format",
+    "@deepseek-ai/dsh-session-format-catalog",
+    "@deepseek-ai/dsh-session-format-v0-to-v1",
+    "@deepseek-ai/dsh-session-format-v1-to-v2",
+    "@deepseek-ai/dsh-session-format-v2-to-v3",
+    "@deepseek-ai/dsh-session-log-deepseek",
+    "@deepseek-ai/dsh-session-snapshot",
+    "@deepseek-ai/dsh-session-turn-outline",
+    "@deepseek-ai/dsh-tool-present",
+    "@deepseek-ai/dsh-util-crypto",
+    "@deepseek-ai/dsh-util-time",
+    "@deepseek-ai/dsh-util-values",
+    "@deepseek-ai/dsh-util-workspace-path",
+    "@deepseek-ai/dsh-webhook",
+    "@deepseek-ai/dsh-webhook-github",
+    "@deepseek-ai/dsh-win32-process"
+  ],
+  "targetVersions": {
+    "@deepseek-ai/cordis": "4.0.2"
+  },
+  "dependencyPolicies": {
+    "@deepseek-ai/cordis": {
+      "client": ["peerDependencies", "devDependencies"]
+    },
+    "@deepseek-ai/dsh-client-store": {
+      "client": ["devDependencies"]
+    },
+    "@deepseek-ai/dsh-session": {
+      "client": ["devDependencies"]
+    }
+  },
+  "semanticReplacements": {
+    "@deepseek-ai/dsh-client-runtime": [
+      "@deepseek-ai/dsh-api-session-controller",
+      "@deepseek-ai/dsh-api-workspace-controller",
+      "@deepseek-ai/dsh-client-store",
+      "@deepseek-ai/dsh-client-ui-session",
+      "@deepseek-ai/dsh-client-ui-conversation",
+      "@deepseek-ai/dsh-client-ui-chat",
+      "@deepseek-ai/dsh-client-ui-trajectory",
+      "@deepseek-ai/dsh-client-ui-approval",
+      "@deepseek-ai/dsh-client-ui-user-questions"
+    ],
+    "@deepseek-ai/dsh-host-apiproxy": [
+      "@deepseek-ai/dsh-api-gateway",
+      "@deepseek-ai/dsh-api-remotes"
+    ],
+    "@deepseek-ai/dsh-code-runtime-python": [
+      "@deepseek-ai/dsh-experimental-code-runtime-python"
+    ],
+    "@deepseek-ai/dsh-tool-subagent-report": [
+      "@deepseek-ai/dsh-tool-subagent-control"
+    ]
+  }
+}

package/migrations/dsh-v0.1.1-rc.2__dsh-v0.1.5-rc.2/services.json

@@ -0,0 +1,28 @@
+{
+  "services": {
+    "sessions": {
+      "owner": "@deepseek-ai/dsh-api-session-controller/client",
+      "confidence": "semantic",
+      "note": "The service name survives, but Session snapshots no longer contain Conversation views or pending interactions."
+    },
+    "workspaces": {
+      "owner": "@deepseek-ai/dsh-api-workspace-controller/client",
+      "confidence": "semantic",
+      "note": "The service name survives, while cross-domain navigation belongs to ui-workspace."
+    },
+    "conversation": {
+      "owner": "@deepseek-ai/dsh-client-ui-conversation/client",
+      "confidence": "semantic",
+      "note": "Conversation assembly and input are independent of Session lifecycle snapshots."
+    },
+    "slots": {
+      "owner": "@deepseek-ai/dsh-client-ui-renderer/client",
+      "confidence": "semantic",
+      "note": "Slot declarations stay in ui-slots; runtime registration and binding belong to ui-renderer."
+    }
+  },
+  "removedHostFacade": {
+    "package": "@deepseek-ai/dsh-host-apiproxy",
+    "replacementPolicy": "Use the natural business Remote owner through generated api-remotes contributions; there is no replacement facade."
+  }
+}

package/migrations/dsh-v0.1.1-rc.2__dsh-v0.1.5-rc.2/symbols.json

@@ -0,0 +1,134 @@
+{
+  "modules": {
+    "@deepseek-ai/dsh-settings": {
+      "settingsNamespace": {
+        "toModule": "@deepseek-ai/dsh-settings",
+        "toSymbol": "SettingsProvider.register",
+        "confidence": "semantic",
+        "reason": "The settingsNamespace factory was removed. Inject the settings Service and register the namespace through ctx.settings.register(name, schema)."
+      }
+    },
+    "@deepseek-ai/dsh-client-runtime/client": {
+      "ClientContext": {
+        "toModule": "@deepseek-ai/cordis",
+        "toSymbol": "Context",
+        "confidence": "exact",
+        "reason": "ClientContext was a type alias of Cordis Context."
+      },
+      "createSnapshotStore": {
+        "toModule": "@deepseek-ai/dsh-client-store",
+        "toSymbol": "createSnapshotStore",
+        "confidence": "exact",
+        "reason": "The React-free store engine moved to client-store."
+      },
+      "defineStore": {
+        "toModule": "@deepseek-ai/dsh-client-store",
+        "toSymbol": "defineStore",
+        "confidence": "exact",
+        "reason": "The declarative store factory moved to client-store."
+      },
+      "ObservableSnapshot": {
+        "toModule": "@deepseek-ai/dsh-client-store",
+        "toSymbol": "ObservableSnapshot",
+        "confidence": "exact",
+        "reason": "The observable store contract moved to client-store."
+      },
+      "SnapshotStore": {
+        "toModule": "@deepseek-ai/dsh-client-store",
+        "toSymbol": "SnapshotStore",
+        "confidence": "exact",
+        "reason": "The writable store contract moved to client-store."
+      },
+      "shallowEqual": {
+        "toModule": "@deepseek-ai/dsh-client-store",
+        "toSymbol": "shallowEqual",
+        "confidence": "exact",
+        "reason": "The store equality helper moved to client-store."
+      },
+      "SessionId": {
+        "toModule": "@deepseek-ai/dsh-session/types",
+        "toSymbol": "SessionId",
+        "confidence": "exact",
+        "reason": "Session identity is owned by the Session domain."
+      },
+      "ISessions": {
+        "toModule": "@deepseek-ai/dsh-api-session-controller/client",
+        "toSymbol": "ISessions",
+        "confidence": "semantic",
+        "reason": "Session ownership moved to the Session Controller and its snapshots changed."
+      },
+      "Session": {
+        "toModule": "@deepseek-ai/dsh-api-session-controller/client",
+        "toSymbol": "Session",
+        "confidence": "semantic",
+        "reason": "The Client Session object and lifecycle moved to the Session Controller."
+      },
+      "SessionBinding": {
+        "toModule": "@deepseek-ai/dsh-api-session-controller/client",
+        "toSymbol": "SessionBinding",
+        "confidence": "semantic",
+        "reason": "Session bindings are now Controller-owned lifetimes."
+      },
+      "SessionListState": {
+        "toModule": "@deepseek-ai/dsh-api-session-controller/client",
+        "toSymbol": "SessionListState",
+        "confidence": "semantic",
+        "reason": "The list state moved and no longer owns Conversation or pending-interaction facts."
+      },
+      "SessionSummary": {
+        "toModule": "@deepseek-ai/dsh-api-session-controller/client",
+        "toSymbol": "SessionSummary",
+        "confidence": "semantic",
+        "reason": "The Session summary is now a Controller-owned control snapshot."
+      },
+      "UseProjection": {
+        "toModule": "@deepseek-ai/dsh-api-session-controller/client",
+        "toSymbol": "UseProjection",
+        "confidence": "semantic",
+        "reason": "Projection sources are now exposed by Session Controller bindings and adapted by ui-session."
+      },
+      "IWorkspaces": {
+        "toModule": "@deepseek-ai/dsh-api-workspace-controller/client",
+        "toSymbol": "IWorkspaces",
+        "confidence": "semantic",
+        "reason": "Workspace ownership moved to the Workspace Controller and navigation policy moved to ui-workspace."
+      },
+      "WorkspaceId": {
+        "toModule": "@deepseek-ai/dsh-api-workspace-controller/client",
+        "toSymbol": "WorkspaceId",
+        "confidence": "semantic",
+        "reason": "Workspace identity is re-exported by the Workspace Controller."
+      },
+      "WorkspaceView": {
+        "toModule": "@deepseek-ai/dsh-api-workspace-controller/client",
+        "toSymbol": "WorkspaceView",
+        "confidence": "semantic",
+        "reason": "Workspace snapshots are Controller-owned and their shape changed."
+      },
+      "ConversationNode": {
+        "toModule": "@deepseek-ai/dsh-client-ui-conversation/client",
+        "toSymbol": "ConversationNode",
+        "confidence": "semantic",
+        "reason": "Conversation assembly moved out of Session snapshots into ui-conversation."
+      },
+      "ConversationSnapshot": {
+        "toModule": "@deepseek-ai/dsh-client-ui-conversation/client",
+        "toSymbol": "ConversationSnapshot",
+        "confidence": "semantic",
+        "reason": "Conversation is now an independent target-neutral source."
+      },
+      "PendingInteraction": {
+        "toModule": "@deepseek-ai/dsh-client-ui-session/client",
+        "toSymbol": "SessionPendingInteraction",
+        "confidence": "semantic",
+        "reason": "Approval and Question now publish domain-owned pending interactions through ui-session."
+      },
+      "PendingWait": {
+        "toModule": "@deepseek-ai/dsh-client-ui-session/client",
+        "toSymbol": "SessionPendingInteraction",
+        "confidence": "semantic",
+        "reason": "The Runtime PendingWait aggregate was removed; pending domains own their payloads."
+      }
+    }
+  }
+}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@bruc3van/dsh-doctor",
-  "version": "0.5.9",
-  "description": "Help agents diagnose and upgrade DeepSeek Harness plugins from DSH 0.1.1 to 0.1.2",
+  "version": "0.6.0",
+  "description": "Help agents diagnose and upgrade DeepSeek Harness plugins from DSH 0.1.1 to 0.1.5",
   "license": "MIT",
   "type": "module",
   "repository": {

package/skills/dsh-plugin-upgrade/SKILL.md

@@ -1,22 +1,22 @@
 ---
 name: dsh-plugin-upgrade
-description: "Help migrate a DeepSeek Harness (DSH) plugin from DSH 0.1.1 to 0.1.2 with the dsh-doctor CLI, deciding explicitly up front whether the upgraded release must stay compatible with DSH 0.1.1. Use when a plugin developer plans a migration or compatibility assessment: checking what changed between DSH versions, replacing imports of packages 0.1.2 removed (such as dsh-client-runtime or dsh-host-apiproxy), migrating settingsNamespace to the settings Service, updating DSH dependency ranges, or verifying and preparing a plugin release for 0.1.2. Applies only catalog-confirmed exact rewrites automatically and guides the semantic changes that need developer judgment. Not for debugging a plugin that already targets 0.1.2, general DSH usage or configuration questions, or developing the Harness itself."
+description: "Help migrate a DeepSeek Harness (DSH) plugin from DSH 0.1.1 to 0.1.5 with the dsh-doctor CLI, deciding explicitly up front whether the upgraded release must stay compatible with DSH 0.1.1. Use when a plugin developer plans a migration or compatibility assessment: checking what changed between DSH versions, replacing imports of packages 0.1.5 removed (such as dsh-client-runtime or dsh-host-apiproxy), migrating settingsNamespace to the settings Service, updating DSH dependency ranges, or verifying and preparing a plugin release for 0.1.5. Applies only catalog-confirmed exact rewrites automatically and guides the semantic changes that need developer judgment. Not for debugging a plugin that already targets 0.1.5, general DSH usage or configuration questions, or developing the Harness itself."
 ---
 
-# Upgrade a DSH 0.1.1 plugin to 0.1.2
+# Upgrade a DSH 0.1.1 plugin to 0.1.5
 
 Help the developer diagnose and modify one plugin at a time. Treat source migration, artifact verification, runtime activation, and business behavior as separate gates.
 
-The migration knowledge covers the DSH 0.1.1 to 0.1.2 transition, derived and verified from one exact catalog version pair (declared below). Keep the skill's product scope at the release-line level (`0.1.1` to `0.1.2`), while keeping the catalog target exact. First record the plugin's actual DSH ranges and requested target. When a newer patch or prerelease appears, use the catalog for known changes only, inspect the additional interval, and report that it is not catalog-confirmed until the catalog and this skill are deliberately updated — a pass for the catalog pair never proves an unlisted version combination.
+The migration knowledge covers the DSH 0.1.1 to 0.1.5 transition, derived and verified from one exact catalog version pair (declared below). Keep the skill's product scope at the release-line level (`0.1.1` to `0.1.5`), while keeping the catalog target exact. First record the plugin's actual DSH ranges and requested target. When a newer patch or prerelease appears, use the catalog for known changes only, inspect the additional interval, and report that it is not catalog-confirmed until the catalog and this skill are deliberately updated — a pass for the catalog pair never proves an unlisted version combination.
 
 ## Current catalog version pair
 
 This block is the single source of truth for the exact refs. Every command below and every reference file defers to it; the references avoid repeating the literals on purpose. When the catalog advances, update this block, the `migrate analyze` example, and the shipped catalog together.
 
 - source ref: `dsh-v0.1.1-rc.2`
-- target ref: `dsh-v0.1.2-rc.1`
+- target ref: `dsh-v0.1.5-rc.2`
 
-Standard commands target this pair and need no `--target-version`. If the developer explicitly targets a newer 0.1.2 build before the catalog is updated, inspect that additional interval first (see [source-investigation.md](references/source-investigation.md)), then pass its exact version to every migration phase as `--target-version <actual-0.1.2-version>`. That changes dependency pins and runtime expectations only; the catalog's API claims still end at the declared pair.
+Standard commands target this pair and need no `--target-version`. If the developer explicitly targets a newer 0.1.5 build before the catalog is updated, inspect that additional interval first (see [source-investigation.md](references/source-investigation.md)), then pass its exact version to every migration phase as `--target-version <actual-0.1.5-version>`. That changes dependency pins and runtime expectations only; the catalog's API claims still end at the declared pair.
 
 ## Inputs
 
@@ -24,8 +24,8 @@ Determine:
 
 - the plugin repository root;
 - the DSH Harness checkout when available;
-- the plugin's actual DSH dependency and peer ranges, and the requested 0.1.2 target;
-- whether the upgraded plugin must keep supporting DSH 0.1.1, target only DSH 0.1.2, or still needs that decision from the developer;
+- the plugin's actual DSH dependency and peer ranges, and the requested 0.1.5 target;
+- whether the upgraded plugin must keep supporting DSH 0.1.1, target only DSH 0.1.5, or still needs that decision from the developer;
 - whether the developer authorizes writes and project command execution;
 - whether the developer authorizes a global CLI install or update;
 - the plugin's package manager and build scripts.
@@ -38,16 +38,16 @@ The examples below use `dsh-doctor` for readability. When bootstrap selected a p
 
 ## Compatibility decision gate
 
-An upgrade request does not say whether the developer accepts dropping DSH 0.1.1, and write authorization does not answer that product decision. The current peer range, the word "upgrade," and the fact that a 0.1.2-only rewrite is simpler are all weak evidence — only the developer's explicit choice settles it.
+An upgrade request does not say whether the developer accepts dropping DSH 0.1.1, and write authorization does not answer that product decision. The current peer range, the word "upgrade," and the fact that a 0.1.5-only rewrite is simpler are all weak evidence — only the developer's explicit choice settles it.
 
 You may inspect files, bootstrap the CLI, and run read-only analysis first. Before any `migrate apply` preview, source or manifest edit, dependency install, build, or runtime command, the compatibility intent must come from one of:
 
 1. an explicit choice already present in the developer's request; or
-2. the developer's own reply to: **"Should the same upgraded plugin release continue to support DSH 0.1.1, or may it target DSH 0.1.2 only?"**
+2. the developer's own reply to: **"Should the same upgraded plugin release continue to support DSH 0.1.1, or may it target DSH 0.1.5 only?"**
 
 No other resolution counts. Do not simulate, assume, or fabricate a reply the developer did not give — a question the developer has not genuinely answered means the gate is still pending. The plugin may be migrated only after the developer has actually made the choice.
 
-If the answer is unavailable or ambiguous, stop at `analyzed`, report the compatibility decision as pending, and leave the plugin unmodified. Follow the selected path in [compatibility-strategy.md](references/compatibility-strategy.md): it defines the three intents (`0.1.2-only`, `dual-version`, `pending developer decision`) and the write policy for each. In particular, `dual-version` treats every 0.1.2 catalog rewrite as a candidate needing cross-version design and review before any write, never an automatically compatible change.
+If the answer is unavailable or ambiguous, stop at `analyzed`, report the compatibility decision as pending, and leave the plugin unmodified. Follow the selected path in [compatibility-strategy.md](references/compatibility-strategy.md): it defines the three intents (`0.1.5-only`, `dual-version`, `pending developer decision`) and the write policy for each. In particular, `dual-version` treats every 0.1.5 catalog rewrite as a candidate needing cross-version design and review before any write, never an automatically compatible change.
 
 ## Phase 1: analyze
 
@@ -56,7 +56,7 @@ Run from any directory:
 ```sh
 dsh-doctor migrate analyze <plugin-root> \
   --from dsh-v0.1.1-rc.2 \
-  --to dsh-v0.1.2-rc.1 \
+  --to dsh-v0.1.5-rc.2 \
   --json
 ```
 
@@ -64,7 +64,7 @@ Append `--harness-root <deepseek-harness-root>` when the checkout is available.
 
 Follow `source-investigation.md` to record the actual PATH or explicit DSH command, installed package, profile, plugin manifest and resolved dependency versions. When the actual source or target differs from the catalog pair declared above, inspect that additional interval separately with read-only Git commands. For each semantic finding, use its target module and the catalog reference paths to inspect the exact exported API and the plugin's callers — naming a likely new owner is not enough to plan the rewrite.
 
-The catalog reports the retained-package removal of `@deepseek-ai/dsh-settings.settingsNamespace` as semantic work. Remove only that named import, inject the `settings` Service, register through `ctx.settings.register(name, schema)`, and migrate any reads to the provider's current API. Symbols 0.1.2 still exports (such as `SettingsConflictError`) must survive the edit even though they share the same import declaration.
+The catalog reports the retained-package removal of `@deepseek-ai/dsh-settings.settingsNamespace` as semantic work. Remove only that named import, inject the `settings` Service, register through `ctx.settings.register(name, schema)`, and migrate any reads to the provider's current API. Symbols 0.1.5 still exports (such as `SettingsConflictError`) must survive the edit even though they share the same import declaration.
 
 The static analyzer recognizes named imports and re-exports for retained-package symbol removals, but it does not resolve property access through namespace imports such as `import * as settings from '@deepseek-ai/dsh-settings'`. Search for and inspect those namespace bindings manually before declaring the semantic migration complete.
 
@@ -80,7 +80,7 @@ A clean bundled artifact alone does not establish compatibility, which is why th
 
 ## Phase 2: apply exact changes
 
-Enter this phase only after the compatibility decision gate is resolved. The commands below are the 0.1.2-target migration path. For dual-version work, first apply the additional constraints in `compatibility-strategy.md`: a catalog-safe codemod proves nothing about 0.1.1.
+Enter this phase only after the compatibility decision gate is resolved. The commands below are the 0.1.5-target migration path. For dual-version work, first apply the additional constraints in `compatibility-strategy.md`: a catalog-safe codemod proves nothing about 0.1.1.
 
 Preview first:
 
@@ -130,25 +130,25 @@ On failure, preserve and report the temporary directory. On success, the CLI rem
 
 Runtime activation is not business-behavior proof. Finish with targeted manual or automated checks for visible UI, service lifecycle, event subscriptions, cleanup, configuration, and plugin-specific workflows.
 
-For a dual-version result, verify the produced release against both the actual 0.1.1 and 0.1.2 environments. The catalog-driven `migrate verify` commands prove only the configured target side. Use the plugin's own build/test flow and an isolated 0.1.1 Harness profile for the legacy side, and name the evidence from each matrix row. A successful 0.1.2 runtime smoke must never be reported as dual-version compatibility.
+For a dual-version result, verify the produced release against both the actual 0.1.1 and 0.1.5 environments. The catalog-driven `migrate verify` commands prove only the configured target side. Use the plugin's own build/test flow and an isolated 0.1.1 Harness profile for the legacy side, and name the evidence from each matrix row. A successful 0.1.5 runtime smoke must never be reported as dual-version compatibility.
 
 ## Prepare for release when requested
 
 Verification prepares the plugin for release but does not publish it. Release only when the developer explicitly asks: first follow the repository's own release instructions and confirm that required semantic and behavior checks are complete. Then update the plugin version and changelog, inspect the packed artifact, and use the repository's existing commit, tag, publish, and registry-verification workflow — the migration skill being installed or run is not, by itself, release authorization.
 
-For a `0.1.2-only` release, update the README or compatibility documentation to state the minimum actual 0.1.2 version, that the new release does not support 0.1.1, and which prior plugin release 0.1.1 users should retain when known. After changing the release version or any other packed metadata, rebuild, inspect the final-version tarball, and repeat the isolated runtime gate against that artifact before committing or tagging; evidence from a tarball carrying the previous plugin version is not final release evidence.
+For a `0.1.5-only` release, update the README or compatibility documentation to state the minimum actual 0.1.5 version, that the new release does not support 0.1.1, and which prior plugin release 0.1.1 users should retain when known. After changing the release version or any other packed metadata, rebuild, inspect the final-version tarball, and repeat the isolated runtime gate against that artifact before committing or tagging; evidence from a tarball carrying the previous plugin version is not final release evidence.
 
 ## Pass criteria before reporting
 
 Call the migration complete only when every item holds:
 
-- compatibility intent recorded as `0.1.2-only` or `dual-version` (not pending);
+- compatibility intent recorded as `0.1.5-only` or `dual-version` (not pending);
 - every semantic finding resolved and reviewed, including namespace-import usages;
 - static verification passes with no blocking finding;
 - build and packed artifacts pass (`build` or `pack:check`, not `typecheck`/`test` alone);
 - runtime smoke passed against the exact target version in the isolated profile;
 - behavior checks executed with named evidence, or explicitly listed as remaining;
-- for `dual-version`: every required matrix row passed on both the 0.1.1 and 0.1.2 sides.
+- for `dual-version`: every required matrix row passed on both the 0.1.1 and 0.1.5 sides.
 
 ## Report the outcome
 
@@ -164,4 +164,4 @@ Do not call the plugin compatible while errors, semantic tasks, stale artifacts,
 Also report the selected DSH Doctor version and source (`local`, exact-version `npx`, or explicitly authorized global install), the registry version observed at bootstrap, and whether update status was current, outdated, missing, or unknown.
 Report the plugin's actual source/target version evidence separately from the catalog reference refs. State whether the plugin is ready for its normal release process; if a release was explicitly requested and completed, include the commit, tag, registry, and release verification evidence.
 Report the migration plan file and plan id, dependency-install command, lockfile change, and resolved target dependency versions. For semantic or unlisted-version work, include the DSH executable/package evidence, checkout refs and commits, inspected source paths, and remaining unknowns described in `source-investigation.md`.
-State the compatibility intent as one of `0.1.2-only`, `dual-version`, or `pending developer decision`. For `dual-version`, report build, artifact, runtime, and behavior evidence separately for 0.1.1 and 0.1.2; only call the release dual-compatible when every required row passes.
+State the compatibility intent as one of `0.1.5-only`, `dual-version`, or `pending developer decision`. For `dual-version`, report build, artifact, runtime, and behavior evidence separately for 0.1.1 and 0.1.5; only call the release dual-compatible when every required row passes.

package/skills/dsh-plugin-upgrade/evals/evals.json

@@ -3,49 +3,49 @@
   "evals": [
     {
       "id": 1,
-      "prompt": "I maintain a DSH plugin (repo at <PLUGIN_ROOT>). DSH 0.1.2 dropped @deepseek-ai/dsh-client-runtime and my plugin imports it in src/. The next release only needs to support 0.1.2 - nobody on my team still runs 0.1.1, so it's fine to drop it. Work out what has to change and do the source migration. You can run commands in the plugin folder, but don't publish anything.",
-      "expected_output": "The agent records the 0.1.2-only intent from the request itself, bootstraps dsh-doctor, analyzes with the exact catalog refs, applies only the catalog-confirmed exact import moves to their new owners, and reports remaining verification gates without publishing or claiming release readiness.",
+      "prompt": "I maintain a DSH plugin (repo at <PLUGIN_ROOT>). DSH 0.1.5 no longer ships @deepseek-ai/dsh-client-runtime and my plugin imports it in src/. The next release only needs to support 0.1.5 - nobody on my team still runs 0.1.1, so it's fine to drop it. Work out what has to change and do the source migration. You can run commands in the plugin folder, but don't publish anything.",
+      "expected_output": "The agent records the 0.1.5-only intent from the request itself, bootstraps dsh-doctor, analyzes with the exact catalog refs, applies only the catalog-confirmed exact import moves to their new owners, and reports remaining verification gates without publishing or claiming release readiness.",
       "files": ["evals/files/import-move-plugin"],
       "expectations": [
-        "Records the compatibility intent as 0.1.2-only, treating the developer's own statement in the prompt as the explicit decision instead of re-asking or blocking",
-        "Maps the removed dsh-client-runtime symbols to their real 0.1.2 owners (createSnapshotStore/defineStore/shallowEqual/SnapshotStore to @deepseek-ai/dsh-client-store, ClientContext to @deepseek-ai/cordis Context) and never proposes an aggregate replacement package for dsh-client-runtime",
-        "Uses or constructs the dsh-doctor CLI flow (migrate analyze, then preview/apply via a plan file) with the catalog refs dsh-v0.1.1-rc.2 and dsh-v0.1.2-rc.1, or clearly reports why the CLI could not run and proceeds from catalog knowledge with that limitation stated",
+        "Records the compatibility intent as 0.1.5-only, treating the developer's own statement in the prompt as the explicit decision instead of re-asking or blocking",
+        "Maps the removed dsh-client-runtime symbols to their real 0.1.5 owners (createSnapshotStore/defineStore/shallowEqual/SnapshotStore to @deepseek-ai/dsh-client-store, ClientContext to @deepseek-ai/cordis Context) and never proposes an aggregate replacement package for dsh-client-runtime",
+        "Uses or constructs the dsh-doctor CLI flow (migrate analyze, then preview/apply via a plan file) with the catalog refs dsh-v0.1.1-rc.2 and dsh-v0.1.5-rc.2, or clearly reports why the CLI could not run and proceeds from catalog knowledge with that limitation stated",
         "Keeps the migration plan file outside the plugin root",
         "Does not commit, tag, publish, or declare the plugin release-ready; reports the highest achieved gate and remaining verification steps"
       ]
     },
     {
       "id": 2,
-      "prompt": "My plugin at <PLUGIN_ROOT> needs to move to DSH 0.1.2 (0.1.2-only, we're dropping 0.1.1 in this release). The tricky part: I use settingsNamespace from @deepseek-ai/dsh-settings in src/settings.ts and I heard it was removed. I also import SettingsConflictError in the same statement, and src/namespace-read.ts uses the settings module through `import * as settings`. Tell me what happens to these and make the changes.",
+      "prompt": "My plugin at <PLUGIN_ROOT> needs to move to DSH 0.1.5 (0.1.5-only, we're dropping 0.1.1 in this release). The tricky part: I use settingsNamespace from @deepseek-ai/dsh-settings in src/settings.ts and I heard it was removed. I also import SettingsConflictError in the same statement, and src/namespace-read.ts uses the settings module through `import * as settings`. Tell me what happens to these and make the changes.",
       "expected_output": "The agent treats settingsNamespace removal as a semantic Service migration (inject the settings Service, register via ctx.settings.register), keeps SettingsConflictError, flags the namespace import for manual inspection, and rewrites reads against the provider's current API.",
       "files": ["evals/files/settings-plugin"],
       "expectations": [
         "Treats the settingsNamespace removal as semantic work requiring a Service migration (inject the settings Service and register through ctx.settings.register(name, schema)), not as an automatic import move",
-        "Keeps SettingsConflictError (still exported in 0.1.2) instead of removing it together with settingsNamespace",
+        "Keeps SettingsConflictError (still exported in 0.1.5) instead of removing it together with settingsNamespace",
         "Explicitly flags the `import * as settings` namespace usage in src/namespace-read.ts as something the static analyzer cannot resolve and inspects it manually",
         "Migrates namespace reads (e.g. namespace.get) to the settings provider's current API (e.g. describe/get on the provider) instead of assuming the old factory object's methods still exist"
       ]
     },
     {
       "id": 3,
-      "prompt": "My plugin at <PLUGIN_ROOT> still imports from @deepseek-ai/dsh-client-runtime/client. DSH 0.1.2 removed that package. Here's the constraint: my users are split between DSH 0.1.1 and 0.1.2 and I want ONE release that works on both - I don't want to maintain two plugin versions. Figure out how to handle this and start the work. Full write access granted.",
-      "expected_output": "The agent records the dual-version intent, treats every 0.1.2 catalog rewrite as a candidate needing cross-version review, proposes an evidence-grounded same-release mechanism, and defines the two-version verification matrix instead of applying the 0.1.2 codemod as automatically safe.",
+      "prompt": "My plugin at <PLUGIN_ROOT> still imports from @deepseek-ai/dsh-client-runtime/client. That package is gone in current DSH. Here's the constraint: my users are split between DSH 0.1.1 and 0.1.5 and I want ONE release that works on both - I don't want to maintain two plugin versions. Figure out how to handle this and start the work. Full write access granted.",
+      "expected_output": "The agent records the dual-version intent, treats every 0.1.5 catalog rewrite as a candidate needing cross-version review, proposes an evidence-grounded same-release mechanism, and defines the two-version verification matrix instead of applying the 0.1.5 codemod as automatically safe.",
       "files": ["evals/files/import-move-plugin"],
       "expectations": [
-        "Records the compatibility intent as dual-version (one release supporting both 0.1.1 and 0.1.2) from the prompt",
-        "Does not apply or recommend applying the 0.1.2 catalog codemod as automatically safe for 0.1.1; treats each rewrite as a candidate for cross-version review first",
+        "Records the compatibility intent as dual-version (one release supporting both 0.1.1 and 0.1.5) from the prompt",
+        "Does not apply or recommend applying the 0.1.5 catalog codemod as automatically safe for 0.1.1; treats each rewrite as a candidate for cross-version review first",
         "Proposes a concrete same-release compatibility mechanism grounded in plugin evidence (e.g. shared adapter with runtime feature detection or conditional version-specific entry/build) rather than guessing at dynamic loading",
-        "Defines a two-version verification matrix with evidence kept separate for 0.1.1 and 0.1.2 (dependency/peer resolution, build and packed artifact, isolated profile activation smoke, plugin behavior)",
-        "Never claims dual-version compatibility from 0.1.2-only evidence; states what remains unproven"
+        "Defines a two-version verification matrix with evidence kept separate for 0.1.1 and 0.1.5 (dependency/peer resolution, build and packed artifact, isolated profile activation smoke, plugin behavior)",
+        "Never claims dual-version compatibility from 0.1.5-only evidence; states what remains unproven"
       ]
     },
     {
       "id": 4,
-      "prompt": "Migrate the plugin at <PLUGIN_ROOT> to DSH 0.1.2. You have full permission to change whatever is needed - just do it end to end and tell me when it's done.",
+      "prompt": "Migrate the plugin at <PLUGIN_ROOT> to DSH 0.1.5. You have full permission to change whatever is needed - just do it end to end and tell me when it's done.",
       "expected_output": "The agent notices the request never says whether 0.1.1 support may be dropped, asks the explicit compatibility question, and then either proceeds only on a genuine developer reply or records the decision as pending and stays read-only until a genuine decision is made.",
       "files": ["evals/files/import-move-plugin"],
       "expectations": [
-        "Asks the explicit compatibility question (should the same upgraded release continue to support DSH 0.1.1, or may it target 0.1.2 only) or otherwise records the compatibility decision as pending developer decision",
+        "Asks the explicit compatibility question (should the same upgraded release continue to support DSH 0.1.1, or may it target 0.1.5 only) or otherwise records the compatibility decision as pending developer decision",
         "Distinguishes a genuine developer reply from a self-assumed one: only a real answer delivered by the developer (e.g. an answered question the harness returns) resolves the gate and lets the migration proceed; when no genuine answer is delivered, the agent must NOT assume, simulate, or fabricate a decision and must NOT treat the decision as resolved",
         "Makes no source edits, dependency installs, builds, or migrate apply writes while the decision is pending; read-only analysis is acceptable",
         "Reports the achieved gate as analyzed or lower with the pending compatibility decision called out, rather than declaring the migration done"

package/skills/dsh-plugin-upgrade/evals/trigger-evals.json

@@ -1,16 +1,16 @@
 [
-  {"query": "My plugin still imports from @deepseek-ai/dsh-client-runtime and I saw DSH 0.1.2 removed it. What do I need to change to get my plugin building against 0.1.2? The repo is at ~/code/dsh-plugin-quicknotes", "should_trigger": true},
-  {"query": "We're preparing our DSH plugin release for the 0.1.2 harness. Can you check whether anything in our dependency ranges or client graph declaration needs updating before we cut the release?", "should_trigger": true},
-  {"query": "升级 DSH 到 0.1.2 之后我的插件加载不出来了，报 settingsNamespace is not a function。帮我把插件迁到 0.1.2。", "should_trigger": true},
-  {"query": "dsh-host-apiproxy was deleted in the new harness version and my browser automation plugin depends on it. Plan the migration to 0.1.2 for me.", "should_trigger": true},
-  {"query": "I want ONE plugin release that works on both DSH 0.1.1 and 0.1.2 - how do I restructure the imports from dsh-client-runtime so both harness versions can load it?", "should_trigger": true},
-  {"query": "Before I publish v2 of my plugin, verify it against DSH 0.1.2: dependency peers, built artifact, and a runtime activation smoke. Is the dsh-doctor tool the right way?", "should_trigger": true},
-  {"query": "我们的插件 peerDependencies 里写着 ~0.1.1，现在要支持 0.1.2，需要改哪些依赖范围？插件在 D:\\work\\dsh-plugin-kanban", "should_trigger": true},
-  {"query": "The migration analysis says MIG_SEMANTIC_API_CHANGE for every session import in my plugin. What does that mean and how do I finish the 0.1.2 migration properly?", "should_trigger": true},
-  {"query": "help me assess whether my dsh plugin is compatible with harness 0.1.2 or whether the session controller changes break my list view", "should_trigger": true},
-  {"query": "I checked out the harness at tag dsh-v0.1.2-rc.1 and my plugin's typecheck now fails on dsh-client-runtime types. Migrate the plugin source to 0.1.2.", "should_trigger": true},
-  {"query": "My plugin already targets DSH 0.1.2 and worked fine yesterday, but today activation fails with 'service not found' after I updated my graphics driver. Debug it.", "should_trigger": false},
-  {"query": "How do I write my first DSH plugin? Walk me through the plugin manifest and a hello-world client entry for 0.1.2.", "should_trigger": false},
+  {"query": "My plugin still imports from @deepseek-ai/dsh-client-runtime and I saw current DSH no longer ships it. What do I need to change to get my plugin building against 0.1.5? The repo is at ~/code/dsh-plugin-quicknotes", "should_trigger": true},
+  {"query": "We're preparing our DSH plugin release for the 0.1.5 harness. Can you check whether anything in our dependency ranges or client graph declaration needs updating before we cut the release?", "should_trigger": true},
+  {"query": "升级 DSH 到 0.1.5 之后我的插件加载不出来了，报 settingsNamespace is not a function。帮我把插件迁到 0.1.5。", "should_trigger": true},
+  {"query": "dsh-host-apiproxy was deleted in the new harness version and my browser automation plugin depends on it. Plan the migration to 0.1.5 for me.", "should_trigger": true},
+  {"query": "I want ONE plugin release that works on both DSH 0.1.1 and 0.1.5 - how do I restructure the imports from dsh-client-runtime so both harness versions can load it?", "should_trigger": true},
+  {"query": "Before I publish v2 of my plugin, verify it against DSH 0.1.5: dependency peers, built artifact, and a runtime activation smoke. Is the dsh-doctor tool the right way?", "should_trigger": true},
+  {"query": "我们的插件 peerDependencies 里写着 ~0.1.1，现在要支持 0.1.5，需要改哪些依赖范围？插件在 D:\\work\\dsh-plugin-kanban", "should_trigger": true},
+  {"query": "The migration analysis says MIG_SEMANTIC_API_CHANGE for every session import in my plugin. What does that mean and how do I finish the 0.1.5 migration properly?", "should_trigger": true},
+  {"query": "help me assess whether my dsh plugin is compatible with harness 0.1.5 or whether the session controller changes break my list view", "should_trigger": true},
+  {"query": "I checked out the harness at tag dsh-v0.1.5-rc.2 and my plugin's typecheck now fails on dsh-client-runtime types. Migrate the plugin source to 0.1.5.", "should_trigger": true},
+  {"query": "My plugin already targets DSH 0.1.5 and worked fine yesterday, but today activation fails with 'service not found' after I updated my graphics driver. Debug it.", "should_trigger": false},
+  {"query": "How do I write my first DSH plugin? Walk me through the plugin manifest and a hello-world client entry for 0.1.5.", "should_trigger": false},
   {"query": "dsh-doctor diagnose says my web profile has a corrupted cordis.patch.yml - how do I use dsh-doctor recover to fix my installation?", "should_trigger": false},
   {"query": "我在 DSH 里配置代理一直不生效，帮我看看 ~/.dsh 下面的配置文件哪里写错了", "should_trigger": false},
   {"query": "Review my DSH plugin's PR: it adds a new settings panel UI. Focus on React rendering correctness and Cordis lifecycle cleanup.", "should_trigger": false},
@@ -18,5 +18,5 @@
   {"query": "My plugin build passes on 0.1.1 but eslint crashes with OOM on large files - help me fix the lint config.", "should_trigger": false},
   {"query": "Write a GitHub Actions workflow to publish my DSH plugin to npm whenever I push a tag.", "should_trigger": false},
   {"query": "dsh keeps using 100% CPU when my plugin's background timer runs. Find the performance bug in my plugin code.", "should_trigger": false},
-  {"query": "Can you update the dsh-doctor CLI itself from 0.5.3 to the latest version and check its changelog for breaking changes?", "should_trigger": false}
+  {"query": "Can you update the dsh-doctor CLI itself from 0.5.9 to the latest version and check its changelog for breaking changes?", "should_trigger": false}
 ]

package/skills/dsh-plugin-upgrade/references/compatibility-strategy.md

@@ -2,14 +2,14 @@
 
 ## Decide before changing the plugin
 
-Moving a plugin to 0.1.2 and preserving 0.1.1 are different deliverables. The 0.1.2 catalog describes target migrations; it does not prove that the resulting source, dependency graph, artifact, or manifest still works on 0.1.1.
+Moving a plugin to 0.1.5 and preserving 0.1.1 are different deliverables. The 0.1.5 catalog describes target migrations; it does not prove that the resulting source, dependency graph, artifact, or manifest still works on 0.1.1.
 
 Record one explicit intent:
 
 | Intent | Meaning | Write policy |
 | --- | --- | --- |
-| `0.1.2-only` | The next plugin release may drop 0.1.1 | Follow the catalog migration after preview and authorization |
-| `dual-version` | The same release must support both 0.1.1 and 0.1.2 | Design the compatibility mechanism and two-version verification matrix before editing |
+| `0.1.5-only` | The next plugin release may drop 0.1.1 | Follow the catalog migration after preview and authorization |
+| `dual-version` | The same release must support both 0.1.1 and 0.1.5 | Design the compatibility mechanism and two-version verification matrix before editing |
 | `pending developer decision` | The developer has not chosen | Read-only analysis only; stop before apply, edits, installs, build, or runtime execution |
 
 Do not treat general write authorization as permission to drop an older runtime. If the request does not settle the choice, ask the developer directly.
@@ -29,23 +29,23 @@ Choose a repository-appropriate same-release mechanism based on evidence, such a
 
 The safe codemod is intentionally target-oriented. In dual-version mode, preview its changes only after the decision is recorded and review each proposed import and dependency edit against 0.1.1 before applying it. Semantic migrations always require the same cross-version review.
 
-If the same release cannot load because required packages or static graph declarations are mutually exclusive, report the exact conflict. Ask the developer whether to change scope to separate plugin releases or accept a 0.1.2-only release. Neither alternative satisfies the original same-release `dual-version` intent.
+If the same release cannot load because required packages or static graph declarations are mutually exclusive, report the exact conflict. Ask the developer whether to change scope to separate plugin releases or accept a 0.1.5-only release. Neither alternative satisfies the original same-release `dual-version` intent.
 
 ## Verify a two-version matrix
 
 Use exact Harness versions or checkouts and keep evidence separate:
 
-| Gate | DSH 0.1.1 | DSH 0.1.2 |
+| Gate | DSH 0.1.1 | DSH 0.1.5 |
 | --- | --- | --- |
 | dependency installation and peer resolution | required | required |
 | typecheck/build/test and packed artifact inspection | required | required |
 | isolated profile install and activation smoke | required | required |
 | plugin-specific UI, Service lifecycle, commands, settings, and cleanup | required where applicable | required where applicable |
 
-The current migration catalog and `migrate verify` target 0.1.2. They do not independently certify the legacy row. Verify 0.1.1 with the plugin repository's supported scripts and an isolated profile using the actual 0.1.1 Harness CLI. Preserve failure workspaces and report the exact commands, versions, artifacts, logs, or screenshots for each row.
+The current migration catalog and `migrate verify` target 0.1.5. They do not independently certify the legacy row. Verify 0.1.1 with the plugin repository's supported scripts and an isolated profile using the actual 0.1.1 Harness CLI. Preserve failure workspaces and report the exact commands, versions, artifacts, logs, or screenshots for each row.
 
 Use precise conclusions:
 
-- `0.1.2 runtime-verified; 0.1.1 not tested` is not dual-compatible.
+- `0.1.5 runtime-verified; 0.1.1 not tested` is not dual-compatible.
 - Passing builds on both versions is not runtime or behavior proof.
 - Claim `dual-version` compatibility only after all required matrix rows pass for the same release artifact or for the explicitly documented version-specific artifact strategy.

package/skills/dsh-plugin-upgrade/references/migration-map.md

@@ -4,7 +4,7 @@
 
 `@deepseek-ai/dsh-client-runtime` was removed without an aggregate replacement.
 
-| Old concern | 0.1.2 owner | Migration policy |
+| Old concern | 0.1.5 owner | Migration policy |
 | --- | --- | --- |
 | store engine and equality helpers | `@deepseek-ai/dsh-client-store` | exact for catalog-listed symbols |
 | Cordis client context type | `@deepseek-ai/cordis` `Context` | exact; preserve local aliases |
@@ -29,6 +29,15 @@ Session snapshots no longer own Conversation views or all pending-interaction fa
 
 `@deepseek-ai/dsh-code-runtime-python` was renamed to `@deepseek-ai/dsh-experimental-code-runtime-python` when the package moved to the experimental tier. Update module specifiers and dependency names together, then confirm with the developer that depending on an experimental-tier package is acceptable for the plugin's support posture; do not treat the rename as a silently compatible change.
 
+## Interval 0.1.2-rc.1 to 0.1.5-rc.2
+
+Verified against both refs: no `@deepseek-ai/dsh-*` package was removed or renamed, and the plugin-facing packages the ownership split moves plugins onto are unchanged, so the table above is complete for 0.1.5. Additional facts for plugins migrating past 0.1.2:
+
+- The web profile removed the patch entries `client-runtime`, `api-gateway`, `tool-subagent-report`, and `tool-str-replace-editor` (`api-gateway` the entry is gone even though the `dsh-api-gateway` package survives). A plugin overlay patching one of these ids must re-anchor to the surviving owner entry.
+- `dsh-client-connection` dropped `webServer` from its inject list without export-signature changes; a plugin injecting `webServer` through it must find the new owner itself.
+- 18 new packages (session-format family, client file-upload/resources, client-ui sidebar packages, dockkit, open-in-app, http-proxy, chunked-list, package-manifest, tool-present, api-workspace-files, host-open-in-app) are additive capabilities, not rewrites.
+- 0.1.3 never shipped a stable tag and 0.1.4 was skipped upstream; Cordis stays at 4.0.2.
+
 ## Client graph
 
 - `dsh.client.inject` declares package dependency edges; Cordis service injection still controls activation.

package/skills/dsh-plugin-upgrade/references/source-investigation.md

@@ -70,7 +70,7 @@ Classify every additional difference as:
 
 Only the catalog-confirmed pair is eligible for the built-in safe codemod. Treat additional exact-looking changes as proposed manual edits until independently reviewed and tested.
 
-After the additional interval is reviewed, pass that exact version as `--target-version` in analyze, apply preview/apply, and verify. This is an explicit fallback for a newer 0.1.2 build that the current catalog version pair declared in SKILL.md does not yet cover. It changes DSH dependency-range validation, deterministic DSH development pins, and the runtime version expectation; it does not turn the unlisted interval into catalog-confirmed API knowledge. Use `--dsh-command` to name the executable that actually reports and runs that version, and update the catalog and skill deliberately when that build becomes the new known target.
+After the additional interval is reviewed, pass that exact version as `--target-version` in analyze, apply preview/apply, and verify. This is an explicit fallback for a newer 0.1.5 build that the current catalog version pair declared in SKILL.md does not yet cover. It changes DSH dependency-range validation, deterministic DSH development pins, and the runtime version expectation; it does not turn the unlisted interval into catalog-confirmed API knowledge. Use `--dsh-command` to name the executable that actually reports and runs that version, and update the catalog and skill deliberately when that build becomes the new known target.
 
 ## 4. Investigate each semantic task in the plugin
 

package/skills/dsh-plugin-upgrade/references/verification.md

@@ -4,7 +4,7 @@
 
 Static analysis covers source/type imports, dependency ranges, client graph declarations, and generated artifacts. A pass means no known blocking finding; it does not execute project code.
 
-The current known static target is the catalog target declared in SKILL.md. When the actual target is later than that catalog ref on the same 0.1.2 release line, first inspect the additional interval, then use `--target-version <version>` at every phase. The report keeps `migration.to` as the catalog ref and records `migration.actualTarget` separately, so a successful dependency or runtime check cannot be mistaken for catalog coverage of the additional API delta.
+The current known static target is the catalog target declared in SKILL.md. When the actual target is later than that catalog ref on the same 0.1.5 release line, first inspect the additional interval, then use `--target-version <version>` at every phase. The report keeps `migration.to` as the catalog ref and records `migration.actualTarget` separately, so a successful dependency or runtime check cannot be mistaken for catalog coverage of the additional API delta.
 
 ## Build
 

package/src/cli.mjs

@@ -43,8 +43,8 @@ Options:
   --fix, --repair        legacy confirmed repairs (never removes a plugin)
   --yes                  confirm an explicit write or command
   --from <ref>            source DSH ref (default: dsh-v0.1.1-rc.2)
-  --to <ref>              target DSH ref (default: dsh-v0.1.2-rc.1)
-  --target-version <ver>  actual DSH 0.1.2 version for dependency/runtime checks
+  --to <ref>              target DSH ref (default: dsh-v0.1.5-rc.2)
+  --target-version <ver>  actual DSH 0.1.5 version for dependency/runtime checks
   --safe                  restrict migrate apply to catalog-confirmed exact rewrites
   --plan-file <path>      persist or consume the reviewed migrate apply plan
   --level <level>         static, build, or runtime verification
@@ -86,8 +86,8 @@ const HELP_ZH = `用法：
   --fix, --repair        旧式确认修复（绝不移除插件）
   --yes                  确认一个明确的写入或命令动作
   --from <ref>           源 DSH ref（默认：dsh-v0.1.1-rc.2）
-  --to <ref>             目标 DSH ref（默认：dsh-v0.1.2-rc.1）
-  --target-version <版本> 依赖与 runtime 验证使用的实际 DSH 0.1.2 版本
+  --to <ref>             目标 DSH ref（默认：dsh-v0.1.5-rc.2）
+  --target-version <版本> 依赖与 runtime 验证使用的实际 DSH 0.1.5 版本
   --safe                 migrate apply 仅执行 catalog 确认的精确改写
   --plan-file <路径>     保存或读取已审阅的 migrate apply 计划
   --level <级别>        static、build 或 runtime

package/src/doctor.mjs

@@ -2,6 +2,7 @@ import { accessSync, constants, existsSync, readFileSync, readdirSync, realpathS
 import { builtinModules } from 'node:module'
 import { homedir } from 'node:os'
 import { delimiter, dirname, isAbsolute, join, relative, resolve, sep } from 'node:path'
+import crossSpawn from 'cross-spawn'
 import yaml from 'js-yaml'
 import semver from 'semver'
 import { parseDocument } from 'yaml'
@@ -248,6 +249,19 @@ function resolveDshCli(options, harness, home) {
   return undefined
 }
 
+function probeDshCli(dshCli, options = {}) {
+  if (dshCli === undefined) return { runnable: false }
+  if (typeof options.cliProbe === 'function') return options.cliProbe(dshCli)
+  const [command, ...args] = dshCli.command
+  const result = crossSpawn.sync(command, [...args, '--version'], { encoding: 'utf8', timeout: 15_000 })
+  if (result.status === 0) {
+    const version = (result.stdout ?? '').trim()
+    if (version !== '') return { runnable: true, version }
+  }
+  const detail = (result.error?.message ?? (result.stderr ?? '').trim())
+  return { runnable: false, probeError: detail !== '' ? detail : `exit status ${String(result.status)}` }
+}
+
 function workspacePackageDirectories(root) {
   const directories = []
   const addChildren = (parent) => {
@@ -1244,6 +1258,13 @@ export function diagnose(options = {}) {
 
   const harness = resolveHarnessContext(home, options.harnessRoot, findings)
   const dshCli = resolveDshCli(options, harness, home)
+  const dshProbe = probeDshCli(dshCli, options)
+  if (dshCli !== undefined && !dshProbe.runnable) {
+    findings.push(finding('error', 'DSH_CLI_NOT_RUNNABLE', 'The resolved DSH CLI command does not execute.', {
+      evidence: `${dshCli.path}: ${dshProbe.probeError}`,
+      suggestion: 'Reinstall the DSH package backing this command, or pass --dsh-command pointing at a working dsh executable.',
+    }))
+  }
   let commandRepairNeeded = false
   const commandRepair = (id, description, args, metadata = {}) => {
     commandRepairNeeded = true
@@ -1540,7 +1561,7 @@ export function diagnose(options = {}) {
     bundleNames,
     profileManifest,
     lockfile,
-    dshCli: { available: dshCli !== undefined },
+    dshCli: { available: dshCli !== undefined && dshProbe.runnable },
   })
   return finish({
     home,
@@ -1554,7 +1575,7 @@ export function diagnose(options = {}) {
     lockfile,
     dshCli: dshCli === undefined
       ? { available: false, commandRepairNeeded }
-      : { available: true, commandRepairNeeded, ...dshCli },
+      : { available: dshProbe.runnable, commandRepairNeeded, ...dshCli, ...(dshProbe.version === undefined ? { probeError: dshProbe.probeError } : { version: dshProbe.version }) },
     packages,
     configuration,
     pluginDiagnoses,

package/src/i18n.mjs

@@ -60,6 +60,7 @@ const ZH_MESSAGES = {
   INVALID_HARNESS_ROOT: () => '指定的 Harness 根目录不是有效的源码工作区。',
   INVALID_WORKSPACE_MANIFEST: () => '已忽略一个无效的 Harness workspace 包清单。',
   HARNESS_INSTALLATION_UNKNOWN: () => '无法定位这个 DSH Home 当前使用的 DSH 安装。',
+  DSH_CLI_NOT_RUNNABLE: () => '解析到的 DSH CLI 命令无法执行。',
   INVALID_DEPENDENCY_MAP: item => `${captured(item.message, /^(\S+) must be/) ?? '依赖字段'}必须是“包名到版本范围”的对象。`,
   INVALID_CLIENT_DECLARATION: item => `${item.package} 的 dsh.client 声明无效。`,
   INVALID_CLIENT_PLATFORM: item => `${item.package} 的 dsh.client.platform 必须是字符串。`,
@@ -134,6 +135,7 @@ const ZH_SUGGESTIONS = {
   INVALID_HARNESS_ROOT: () => '诊断源码工作区时，请把 DeepSeek Harness 仓库根目录传给 --harness-root。',
   INVALID_WORKSPACE_MANIFEST: () => '修复该 workspace 包清单后，Doctor 才能把它纳入兼容性检查。',
   HARNESS_INSTALLATION_UNKNOWN: () => '若使用源码工作区，请通过 --harness-root 明确指定；若使用独立 CLI，请通过 --dsh-command 指定。',
+  DSH_CLI_NOT_RUNNABLE: () => '重新安装该命令背后的 DSH 包，或通过 --dsh-command 指向一个可用的 dsh 可执行文件。',
   INVALID_DEPENDENCY_MAP: () => '管理或启动 profile 前，请先修复这个依赖字段。',
   INVALID_CLIENT_DECLARATION: update,
   INVALID_CLIENT_PLATFORM: update,

package/src/migrate.mjs

@@ -391,7 +391,7 @@ function analysisInputs(root) {
 export function analyzeMigration(pluginRoot = process.cwd(), options = {}) {
   const root = resolve(pluginRoot)
   if (!statSync(root).isDirectory()) throw new Error(`plugin root is not a directory: ${root}`)
-  const catalog = loadMigration(options.from ?? 'dsh-v0.1.1-rc.2', options.to ?? 'dsh-v0.1.2-rc.1')
+  const catalog = loadMigration(options.from ?? 'dsh-v0.1.1-rc.2', options.to ?? 'dsh-v0.1.5-rc.2')
   const actualTarget = actualTargetVersion(catalog, options.targetVersion)
   const harness = verifyHarnessCheckout(catalog, options.harnessRoot)
   const manifest = readManifest(root)