@bruc3van/dsh-doctor 0.5.4 → 0.5.6

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

@@ -1,13 +1,13 @@
 ---
 name: dsh-plugin-upgrade
-description: Help diagnose and upgrade a DeepSeek Harness plugin from DSH 0.1.1 to 0.1.2 with dsh-doctor, while deciding explicitly whether the upgraded release must remain compatible with DSH 0.1.1. Use when a plugin developer asks to assess compatibility, identify changed APIs, replace removed dsh-client-runtime or dsh-host-apiproxy usage, update DSH dependencies, modify plugin code, rebuild artifacts, or verify the plugin before releasing a new version. Apply only catalog-confirmed exact rewrites automatically, guide semantic code changes, and report what still needs developer verification. The current catalog uses dsh-v0.1.1-rc.2 and dsh-v0.1.2-alpha.2 as its reference points.
+description: Help diagnose and upgrade a DeepSeek Harness plugin from DSH 0.1.1 to 0.1.2 with dsh-doctor, while deciding explicitly whether the upgraded release must remain compatible with DSH 0.1.1. Use when a plugin developer asks to assess compatibility, identify changed APIs, replace removed dsh-client-runtime or dsh-host-apiproxy usage, update DSH dependencies, modify plugin code, rebuild artifacts, or verify the plugin before releasing a new version. Apply only catalog-confirmed exact rewrites automatically, guide semantic code changes, and report what still needs developer verification. The current known target reference is dsh-v0.1.2-alpha.3.
 ---
 
 # Upgrade a DSH 0.1.1 plugin to 0.1.2
 
 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 current migration knowledge covers the DSH 0.1.1 to 0.1.2 transition. Its CLI catalog records `dsh-v0.1.1-rc.2` and `dsh-v0.1.2-alpha.2` as the exact reference points used to derive and verify known changes. Use those refs in dsh-doctor commands, but first record the plugin's actual DSH ranges and requested target. When another patch or prerelease is involved, use the catalog for known changes only and report that the additional version difference still needs review. Do not claim that the catalog proves an unlisted version combination.
+The migration knowledge covers the DSH 0.1.1 to 0.1.2 transition. The current known catalog records `dsh-v0.1.1-rc.2` and `dsh-v0.1.2-alpha.3` as the exact reference points used to derive and verify known changes. 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. Do not claim that the catalog proves an unlisted version combination.
 
 ## Inputs
 
@@ -24,13 +24,15 @@ Determine:
 Use these catalog reference points in the current CLI commands:
 
 - source: `dsh-v0.1.1-rc.2`
-- target: `dsh-v0.1.2-alpha.2`
+- target: `dsh-v0.1.2-alpha.3`
 
-Read [cli-bootstrap.md](references/cli-bootstrap.md) before running any migration command, [compatibility-strategy.md](references/compatibility-strategy.md) before proposing or writing changes, [migration-map.md](references/migration-map.md) before making semantic changes, and [verification.md](references/verification.md) before build or runtime verification.
+The standard commands target the current known alpha.3 catalog and do not need `--target-version`. If the developer explicitly targets a newer 0.1.2 build before the catalog is updated, inspect the interval first, then pass its exact version to every migration phase as `--target-version <actual-0.1.2-version>`. This changes dependency pins and runtime expectations only; it does not extend the catalog's API claims.
 
-Before touching the plugin, inspect the local CLI and perform the read-only registry update check described in `cli-bootstrap.md`. Select one exact DSH Doctor version, verify it exposes this migration catalog, and keep the same invocation for analyze, apply, and verify. Prefer an exact-version `npx` fallback over changing the developer's global installation. Never globally install or update the CLI without explicit authorization.
+Read [cli-bootstrap.md](references/cli-bootstrap.md) before running any migration command, [compatibility-strategy.md](references/compatibility-strategy.md) before proposing or writing changes, [source-investigation.md](references/source-investigation.md) before investigating an unlisted version or semantic task, [migration-map.md](references/migration-map.md) before making semantic changes, and [verification.md](references/verification.md) before dependency, build, or runtime verification.
 
-The examples below use `dsh-doctor` for readability. When bootstrap selected an npx invocation, substitute the complete pinned prefix, `npx --yes --package=@bruc3van/dsh-doctor@<selected-version> dsh-doctor`, in every phase.
+Before touching the plugin, inspect the local CLI and perform the read-only registry update check described in `cli-bootstrap.md`. Select one exact DSH Doctor version, verify it exposes this migration catalog, and keep the same invocation for analyze, apply, and verify. Prefer the exact-version `npm exec` fallback over changing the developer's global installation. Never globally install or update the CLI without explicit authorization.
+
+The examples below use `dsh-doctor` for readability. When bootstrap selected a package-runner invocation, substitute the complete pinned prefix, `npm exec --yes --package=@bruc3van/dsh-doctor@<selected-version> -- dsh-doctor`, in every phase.
 
 ## Compatibility decision gate
 
@@ -53,12 +55,18 @@ Run from any directory:
 ```sh
 dsh-doctor migrate analyze <plugin-root> \
   --from dsh-v0.1.1-rc.2 \
-  --to dsh-v0.1.2-alpha.2 \
+  --to dsh-v0.1.2-alpha.3 \
   --json
 ```
 
 Append `--harness-root <deepseek-harness-root>` when the checkout is available. Prefer an exact Harness checkout so the CLI verifies both tag commits. Both tags must exist and resolve to the commits recorded by the catalog; fetch the repository tags first when a shallow checkout lacks them. Without `--harness-root`, analysis is catalog-only and must be reported as such.
 
+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 refs, inspect that additional ref 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 plugin callers; do not stop at naming a likely new owner.
+
+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. Do not remove still-exported symbols such as `SettingsConflictError` merely because 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.
+
 Group the result by:
 
 1. errors blocking compatibility;
@@ -76,16 +84,20 @@ Enter this phase only after the compatibility decision gate is resolved. The com
 Preview first:
 
 ```sh
-dsh-doctor migrate apply <plugin-root> --safe --harness-root <deepseek-harness-root> --json
+dsh-doctor migrate apply <plugin-root> --safe \
+  --plan-file <reviewed-plan-outside-plugin-root.json> \
+  --harness-root <deepseek-harness-root> --json
 ```
 
-Review affected files and hashes. Apply only with explicit authorization:
+Store the plan outside the plugin root so it is not treated as plugin input. Review the plan id, complete analysis, affected files, and before/after hashes. Apply that exact plan only with explicit authorization:
 
 ```sh
-dsh-doctor migrate apply <plugin-root> --safe --yes --harness-root <deepseek-harness-root> --json
+dsh-doctor migrate apply <plugin-root> --safe --yes \
+  --plan-file <same-reviewed-plan.json> \
+  --harness-root <deepseek-harness-root> --json
 ```
 
-The CLI creates timestamped backups and refuses writes when a file changed after preview. It may split a mixed import: exact symbols move to their new owners while semantic symbols remain unresolved. It may pin non-removed DSH development dependencies and add dependencies required by exact symbol moves. It does not change the ranges of existing published peers automatically. Never mechanically replace the removed Client Runtime with one aggregate package; no such replacement exists.
+The CLI binds the apply to the persisted report and edit hashes, creates timestamped backups, and refuses writes when the plugin analysis changed after preview. It may split a mixed import: exact symbols move to their new owners while semantic symbols remain unresolved. Dependency additions follow catalog-owned Client/Host and peer/dev policies instead of copying the removed package's old dependency section. It may pin non-removed DSH development dependencies. It does not widen the ranges of existing published peers automatically. Never mechanically replace the removed Client Runtime with one aggregate package; no such replacement exists.
 
 After apply, inspect every `MIG_SEMANTIC_API_CHANGE`. Rewrite behavior using the new domain owner and its current snapshot/lifecycle contract. Keep these edits separate enough to review and test.
 
@@ -95,11 +107,11 @@ Run the gates in order:
 
 ```sh
 dsh-doctor migrate verify <plugin-root> --level static --harness-root <deepseek-harness-root> --json
-dsh-doctor migrate verify <plugin-root> --level build --yes --harness-root <deepseek-harness-root> --json
-dsh-doctor migrate verify <plugin-root> --level runtime --yes --harness-root <deepseek-harness-root> --json
+dsh-doctor migrate verify <plugin-root> --level build --yes --install --harness-root <deepseek-harness-root> --json
+dsh-doctor migrate verify <plugin-root> --level runtime --yes --install --dsh-command <actual-dsh-command> --json
 ```
 
-Build and runtime levels execute plugin scripts and therefore require `--yes`. Runtime verification packs the real plugin, creates a temporary `DSH_HOME`, installs into a new web profile, dumps effective config, and performs an activation smoke. It does not modify the developer's normal `~/.dsh`.
+Build and runtime levels require `--yes --install`: the CLI first runs the detected package manager with lifecycle scripts disabled, updates the lockfile when needed, and verifies the installed DSH/Cordis versions against runtime, development, peer, and optional dependency declarations before executing project scripts. A required peer must resolve and satisfy every declared range; a missing optional peer is recorded but does not fail the gate. Review lockfile changes as migration changes. Runtime verification then packs the real plugin, creates a temporary `DSH_HOME`, installs into a new web profile, dumps effective config, and performs an activation smoke. It does not modify the developer's normal `~/.dsh`.
 
 Resolve every semantic task and rebuild stale artifacts before expecting static verification to pass. An `apply` exit code of 1 after successful writes means migration blockers remain in the follow-up analysis; inspect `mode`, `writes`, and `report` instead of treating it as a write failure.
 
@@ -113,6 +125,8 @@ For a dual-version result, verify the produced release against both the actual 0
 
 Verification prepares the plugin for release but does not publish it. If the developer explicitly asks to release the upgraded plugin, 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. Do not commit, tag, or publish merely because the migration skill was installed or run.
 
+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.
+
 ## Report the outcome
 
 State the highest achieved gate exactly:
@@ -126,4 +140,5 @@ State the highest achieved gate exactly:
 Do not call the plugin compatible while errors, semantic tasks, stale artifacts, or required behavior checks remain. Include backups and retained temporary directories in the handoff.
 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.

package/skills/dsh-plugin-upgrade/references/cli-bootstrap.md

@@ -11,7 +11,7 @@ dsh-doctor --version
 dsh-doctor migrations list --json
 ```
 
-Record the local version and whether the exact `dsh-v0.1.1-rc.2` to `dsh-v0.1.2-alpha.2` catalog is present. A command that exists but lacks this catalog is not usable for this skill.
+Record the local version and whether the exact current `dsh-v0.1.1-rc.2` to `dsh-v0.1.2-alpha.3` catalog is present. A command that exists but lacks this catalog is not usable for the current known target.
 
 ## 2. Check the registry without changing the machine
 
@@ -26,12 +26,14 @@ This is a read-only update check. If it fails because the registry is unavailabl
 ## 3. Select and pin one invocation
 
 - When the local version equals the registry version and exposes the catalog, use `dsh-doctor` directly.
-- When the local CLI is missing, differs from the registry version, or lacks the catalog, prefer the registry version through exact-version npx. First verify that version exposes the required catalog:
+- When the local CLI is missing, differs from the registry version, or lacks the catalog, prefer the registry version through an exact-version package runner. First verify that version exposes the required catalog:
 
 ```sh
-npx --yes --package=@bruc3van/dsh-doctor@<registry-version> dsh-doctor migrations list --json
+npm exec --yes --package=@bruc3van/dsh-doctor@<registry-version> -- dsh-doctor migrations list --json
 ```
 
+This `npm exec ... -- dsh-doctor` form is the preferred cross-platform invocation. On Windows, `npx --package=... dsh-doctor` can fail to resolve the temporary binary when launched from an unrelated project root. A direct `npx --yes @bruc3van/dsh-doctor@<version> ...` smoke from a fresh temporary directory is also acceptable, but keep one verified invocation for the whole migration.
+
 - When the registry is unavailable, use the local CLI only if its catalog check passed.
 - When neither candidate exposes the catalog, stop and report the missing prerequisite instead of guessing a compatible CLI.
 - Respect an explicit developer request to use a particular local or development CLI, but still record its version and verify the catalog.
@@ -54,6 +56,6 @@ Include these fields in the handoff:
 
 - local CLI version or `missing`;
 - registry version or `unknown`;
-- selected exact version and invocation source (`local`, `npx`, or authorized `global-install`);
+- selected exact version and invocation source (`local`, `npm-exec`, or authorized `global-install`);
 - required catalog present or absent;
 - update status: `current`, `outdated`, `missing`, or `unknown`.

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

@@ -19,14 +19,28 @@ Session snapshots no longer own Conversation views or all pending-interaction fa
 
 `@deepseek-ai/dsh-host-apiproxy` was removed. Browser operations use their natural generated Remote owners through API Remotes/API Gateway contributions. There is no facade-compatible package substitution.
 
+## Settings registration
+
+`@deepseek-ai/dsh-settings` remains, but its `settingsNamespace` factory export was removed in 0.1.2-alpha.2. This is a semantic Service migration, not an import move: inject the `settings` Service and register the plugin namespace through `ctx.settings.register(name, schema)`. Keep `SettingsConflictError` or other exports that still exist, and verify every namespace read path against the provider API (for example `describe`) instead of assuming the former factory object's methods still exist.
+
 ## Client graph
 
 - `dsh.client.inject` declares package dependency edges; Cordis service injection still controls activation.
 - React, Cordis, client-store, ui-slots, and ui-primitives baseline modules are implicit and should not be repeated in `dsh.client.external`.
 - A declared web client requires a published `exports["./client"]` artifact.
 
+## Dependency ownership
+
+An exact symbol move and its npm dependency placement are separate catalog decisions. The current target policy records Client relationships explicitly:
+
+- Cordis must be present in matching `peerDependencies` and `devDependencies` for a client plugin;
+- `dsh-client-store` and `dsh-session` Client/type relationships are development-only;
+- existing published peer ranges are not widened automatically merely because a development dependency is pinned to the target catalog version.
+
+Do not copy a replacement package into every dependency section that contained `dsh-client-runtime`. After apply, use the dependency verification gate to synchronize the lockfile and confirm the versions actually resolved in `node_modules`.
+
 ## Patch targets
 
 For `MIG_PATCH_TARGET_CHANGED`, first confirm the Harness checkout is exact and its tag scan succeeded. Then compare the old and target web profile bundle patches: remove an obsolete override only when the old row disappeared without a replacement, or update the id when upstream deliberately renamed/moved the row. Do not guess a replacement id from a similar name.
 
-The machine-readable source of truth ships with DSH Doctor. Confirm the installed CLI exposes this exact version pair with `dsh-doctor migrations list`; the canonical catalog source is also available in the [DSH Doctor repository](https://github.com/bruc3van/dsh-doctor/tree/master/migrations/dsh-v0.1.1-rc.2__dsh-v0.1.2-alpha.2).
+The machine-readable source of truth ships with DSH Doctor. Confirm the installed CLI exposes the current exact version pair with `dsh-doctor migrations list`; the canonical catalog source is also available in the [DSH Doctor repository](https://github.com/bruc3van/dsh-doctor/tree/master/migrations/dsh-v0.1.1-rc.2__dsh-v0.1.2-alpha.3). The older alpha.2 catalog remains historical evidence, not the current default.

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

@@ -0,0 +1,99 @@
+# Investigate the actual DSH source and installed runtime
+
+Use this workflow whenever the plugin's declared or requested DSH version differs from a catalog reference, a semantic migration remains, or the developer asks what changed in DSH. The catalog is a starting point, not a substitute for checking the actual runtime and source.
+
+## 1. Record the runtime actually in use
+
+Keep these as separate facts:
+
+- the DSH executable selected by PATH or an explicit command;
+- the version printed by that executable;
+- the DSH package installation backing the executable;
+- the plugin's dependency, peer, optional-peer, and development ranges;
+- the DSH packages resolved in the plugin lockfile and `node_modules`;
+- the requested target version;
+- the source and target refs used by the migration catalog.
+
+On Windows, use read-only commands such as:
+
+```powershell
+Get-Command dsh -All
+dsh --version
+npm root --global
+Get-Content "$env:APPDATA\npm\node_modules\@deepseek-ai\dsh\package.json"
+```
+
+On macOS or Linux:
+
+```sh
+command -v -a dsh
+dsh --version
+npm root --global
+cat "$(npm root --global)/@deepseek-ai/dsh/package.json"
+```
+
+Also inspect `DSH_HOME`, the selected profile manifest and lockfile, the plugin's lockfile, and any project-local DSH package. Do not assume PATH, a running DSH process, the profile, and the plugin workspace all resolve the same version.
+
+## 2. Locate or obtain a Harness checkout
+
+Prefer, in order:
+
+1. an explicit checkout supplied by the developer;
+2. a nearby project checkout whose remote and refs can be verified;
+3. source provenance recorded by the installed package or repository metadata;
+4. an upstream checkout obtained only when network access and cloning/fetching are within the developer's authorization.
+
+Record `git remote -v`, worktree status, `git rev-parse <ref>`, and whether the checkout contains both relevant refs. Do not switch, reset, clean, or update a developer's checkout merely to inspect another ref. Use `git show`, `git diff`, `git grep`, and `git ls-tree` against refs without changing the worktree. A dirty checkout can still be used for ref-based inspection; report that the worktree itself was not treated as target evidence.
+
+## 3. Build the additional-version delta
+
+When the plugin's actual source or requested target is not exactly the catalog pair, compare the missing interval separately. At minimum inspect:
+
+```sh
+git diff --name-status <actual-source-ref>..<actual-target-ref> -- packages apps
+git diff <actual-source-ref>..<actual-target-ref> -- '**/package.json'
+git grep -n '<old-symbol-or-service>' <actual-source-ref> -- packages apps
+git grep -n '<old-symbol-or-service>' <actual-target-ref> -- packages apps
+git grep -n '<new-owner-or-symbol>' <actual-target-ref> -- packages apps
+git show <actual-target-ref>:<candidate-package>/package.json
+```
+
+Check package existence and exports, declaration files or TypeScript source, Service names and Cordis injection, snapshot shapes, event and cleanup lifecycles, client manifest rules, profile patches, build presets, and upstream architecture or migration notes. Do not infer an API from a similarly named package or symbol.
+
+Classify every additional difference as:
+
+- confirmed exact move;
+- semantic behavior change;
+- removed with no replacement;
+- configuration or packaging change;
+- unknown because source or evidence is unavailable.
+
+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 alpha.3 catalog 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
+
+Start from the finding's `file`, `symbol`, `targetModule`, `targetSymbol`, and `reason`. Then:
+
+1. trace every caller and lifecycle owner in the plugin;
+2. inspect the target package export and implementation at the exact target ref;
+3. compare source and target snapshot/event shapes;
+4. identify activation, subscription, cleanup, error, and recovery behavior;
+5. decide whether one source tree can support both requested DSH versions;
+6. propose the smallest behavior-preserving change and name the tests needed to prove it.
+
+If the catalog reference paths in `migration.references` exist in the Harness checkout, read them at the target ref. They are supporting evidence, not a replacement for inspecting the actual exported API and the plugin's callers.
+
+## 5. Report provenance and uncertainty
+
+For each conclusion, report:
+
+- actual installed/runtime version evidence;
+- plugin manifest and resolved dependency evidence;
+- checkout remote, refs, and commits;
+- catalog-covered delta versus additionally inspected delta;
+- exact source paths, symbols, or commands used;
+- remaining unknowns and the developer decision they block.
+
+Never call an unlisted version combination compatible merely because the catalog pair passed.

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

@@ -4,9 +4,15 @@
 
 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 alpha.3. 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.
+
 ## Build
 
-The CLI selects the package manager from lockfiles and runs declared scripts in this order: `typecheck`, `build`, `test`, `pack:check`, stopping at the first failure. Artifact verification requires a successful `build` or `pack:check`; `typecheck`/`test` alone do not pass this gate.
+Build and runtime verification require `--yes --install`. The CLI selects the package manager from lockfiles, synchronizes dependencies with dependency lifecycle scripts disabled, records the lockfile hash before and after, and verifies installed DSH/Cordis versions against `dependencies`, `devDependencies`, `peerDependencies`, and `optionalDependencies`. Required peers must resolve and satisfy every declared range. Missing optional dependencies or peers are recorded as `optional-missing`; when installed, they must satisfy their ranges. It then runs declared scripts in this order: `typecheck`, `build`, `test`, `pack:check`, stopping at the first failure. Artifact verification requires a successful `build` or `pack:check`; `typecheck`/`test` alone do not pass this gate.
+
+If dependency installation or resolution verification fails, stop before running project scripts. Review and retain package manifest and lockfile changes with the source migration.
+
+If pnpm's `minimumReleaseAge` blocks a newly published target prerelease, do not disable or weaken the repository-wide supply-chain policy. Confirm the selected target and registry provenance, then add only the exact `package@version` rows required under `minimumReleaseAgeExclude`, including transitive DSH packages reported by pnpm. Review this workspace-policy change alongside the lockfile and report it explicitly.
 
 ## Runtime
 
@@ -22,6 +28,8 @@ The gate also checks the DSH CLI's exact target version, the created profile man
 
 Use a built target Harness CLI through `--harness-root`, or pass `--dsh-command` explicitly. The temporary home is deleted only after a successful run unless `--keep-temp` is set.
 
+The runtime executable must report the exact actual target selected by `--target-version` (or the catalog target when the option is omitted). A later prerelease is not accepted implicitly because that would disconnect the runtime evidence from the reviewed dependency and source target.
+
 ## Behavior
 
 Choose focused checks from the plugin contract: render the real UI, invoke each command, exercise settings, verify service availability, repeat activation/deactivation, check listener cleanup, and cover failure recovery. Record exact commands, screenshots, logs, or tests. This gate is deliberately not inferred by dsh-doctor.

package/src/cli.mjs

@@ -43,9 +43,12 @@ 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-alpha.2)
+  --to <ref>              target DSH ref (default: dsh-v0.1.2-alpha.3)
+  --target-version <ver>  actual DSH 0.1.2 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
+  --install               synchronize dependencies before build/runtime verification
   --keep-temp             retain a successful runtime verification directory
   -h, --help             show help
   -v, --version          show version
@@ -83,9 +86,12 @@ const HELP_ZH = `用法：
   --fix, --repair        旧式确认修复（绝不移除插件）
   --yes                  确认一个明确的写入或命令动作
   --from <ref>           源 DSH ref（默认：dsh-v0.1.1-rc.2）
-  --to <ref>             目标 DSH ref（默认：dsh-v0.1.2-alpha.2）
+  --to <ref>             目标 DSH ref（默认：dsh-v0.1.2-alpha.3）
+  --target-version <版本> 依赖与 runtime 验证使用的实际 DSH 0.1.2 版本
   --safe                 migrate apply 仅执行 catalog 确认的精确改写
+  --plan-file <路径>     保存或读取已审阅的 migrate apply 计划
   --level <级别>        static、build 或 runtime
+  --install              在 build/runtime 验证前同步依赖
   --keep-temp            成功后仍保留运行时验证目录
   -h, --help             显示帮助
   -v, --version          显示版本
@@ -142,9 +148,14 @@ function parse(args) {
     else if (arg.startsWith('--from=')) options.from = optionValue(arg, '--from')
     else if (arg === '--to') options.to = valueAfter(args, index++, arg)
     else if (arg.startsWith('--to=')) options.to = optionValue(arg, '--to')
+    else if (arg === '--target-version') options.targetVersion = valueAfter(args, index++, arg)
+    else if (arg.startsWith('--target-version=')) options.targetVersion = optionValue(arg, '--target-version')
     else if (arg === '--safe') options.safe = true
+    else if (arg === '--plan-file') options.planFile = valueAfter(args, index++, arg)
+    else if (arg.startsWith('--plan-file=')) options.planFile = optionValue(arg, '--plan-file')
     else if (arg === '--level') options.level = valueAfter(args, index++, arg)
     else if (arg.startsWith('--level=')) options.level = optionValue(arg, '--level')
+    else if (arg === '--install') options.install = true
     else if (arg === '--keep-temp') options.keepTemp = true
     else if (arg === '--help' || arg === '-h') options.help = true
     else if (arg === '--version' || arg === '-v') options.version = true
@@ -293,7 +304,7 @@ async function main() {
     if (!['analyze', 'apply', 'verify'].includes(options.migrateAction)) throw new Error('migrate needs analyze, apply, or verify')
     if (options.migrateAction === 'apply' && options.safe !== true) throw new Error('migrate apply requires --safe')
     if (options.migrateAction === 'apply' && options.pluginRoot === undefined) throw new Error('migrate apply requires an explicit plugin root')
-    const migrationOptions = { from: options.from, to: options.to, harnessRoot: options.harnessRoot, dshCommand: options.dshCommand, level: options.level, yes: options.yes, safe: options.safe, keepTemp: options.keepTemp }
+    const migrationOptions = { from: options.from, to: options.to, targetVersion: options.targetVersion, harnessRoot: options.harnessRoot, dshCommand: options.dshCommand, level: options.level, yes: options.yes, safe: options.safe, keepTemp: options.keepTemp, planFile: options.planFile, install: options.install }
     if (options.migrateAction === 'verify') {
       const { formatVerification, verifyMigration } = await import('./migrate-verify.mjs')
       const result = verifyMigration(options.pluginRoot, migrationOptions)

package/src/migrate-verify.mjs

@@ -1,7 +1,8 @@
 import { existsSync, mkdirSync, mkdtempSync, readFileSync, rmSync } from 'node:fs'
 import { tmpdir } from 'node:os'
-import { basename, join, resolve } from 'node:path'
+import { basename, dirname, join, resolve } from 'node:path'
 import crossSpawn from 'cross-spawn'
+import semver from 'semver'
 import { analyzeMigration, publicMigrationReport } from './migrate.mjs'
 import { sha256 } from './safe-write.mjs'
 
@@ -38,9 +39,55 @@ function commandEvidence(result) {
 }
 
 function packageManager(root) {
-  if (existsSync(join(root, 'pnpm-lock.yaml'))) return { command: 'pnpm', run: script => ['run', script], pack: destination => ['pack', '--pack-destination', destination] }
-  if (existsSync(join(root, 'yarn.lock'))) return { command: 'yarn', run: script => [script], pack: destination => ['pack', '--out', join(destination, 'plugin.tgz')] }
-  return { command: 'npm', run: script => ['run', script], pack: destination => ['pack', '--json', '--pack-destination', destination] }
+  if (existsSync(join(root, 'pnpm-lock.yaml'))) return { command: 'pnpm', install: ['install', '--no-frozen-lockfile', '--ignore-scripts'], lockfile: 'pnpm-lock.yaml', run: script => ['run', script], pack: destination => ['pack', '--pack-destination', destination] }
+  if (existsSync(join(root, 'yarn.lock'))) return { command: 'yarn', install: ['install', '--ignore-scripts'], lockfile: 'yarn.lock', run: script => [script], pack: destination => ['pack', '--out', join(destination, 'plugin.tgz')] }
+  return { command: 'npm', install: ['install', '--ignore-scripts'], lockfile: 'package-lock.json', run: script => ['run', script], pack: destination => ['pack', '--json', '--pack-destination', destination] }
+}
+
+function lockfileHash(root, manager) {
+  const file = join(root, manager.lockfile)
+  return existsSync(file) ? sha256(readFileSync(file)) : undefined
+}
+
+function installedManifestFile(root, name) {
+  let current = resolve(root)
+  while (true) {
+    const file = join(current, 'node_modules', ...name.split('/'), 'package.json')
+    if (existsSync(file)) return file
+    const parent = dirname(current)
+    if (parent === current) return undefined
+    current = parent
+  }
+}
+
+export function installedDependencyEvidence(root, manifest) {
+  const requested = new Map()
+  for (const field of ['dependencies', 'devDependencies', 'peerDependencies', 'optionalDependencies']) {
+    for (const [name, range] of Object.entries(manifest[field] ?? {})) {
+      if (name !== '@deepseek-ai/cordis' && !name.startsWith('@deepseek-ai/dsh-')) continue
+      const optional = field === 'optionalDependencies' || (field === 'peerDependencies' && manifest.peerDependenciesMeta?.[name]?.optional === true)
+      const declarations = requested.get(name) ?? []
+      declarations.push({ field, range, optional })
+      requested.set(name, declarations)
+    }
+  }
+  return [...requested].map(([name, declarations]) => {
+    const file = installedManifestFile(root, name)
+    if (file === undefined) {
+      const optional = declarations.every(item => item.optional)
+      return { name, declarations, installed: false, optional, passed: optional, ...(optional ? { status: 'optional-missing' } : { error: 'declared dependency is not installed' }) }
+    }
+    try {
+      const installed = JSON.parse(readFileSync(file, 'utf8'))
+      const checks = declarations.map(item => {
+        const validRange = typeof item.range === 'string' ? semver.validRange(item.range) : null
+        return { ...item, passed: validRange !== null && semver.satisfies(installed.version, validRange) }
+      })
+      return { name, declarations: checks, installed: true, manifestFile: file, installedVersion: installed.version, passed: installed.name === name && checks.every(item => item.passed) }
+    } catch (error) {
+      return { name, declarations, installed: true, manifestFile: file, passed: false, error: error instanceof Error ? error.message : String(error) }
+    }
+  })
 }
 
 function discoverDsh(options) {
@@ -98,6 +145,7 @@ export function verifyMigration(pluginRoot = process.cwd(), options = {}) {
   const level = options.level ?? 'static'
   if (!['static', 'build', 'runtime'].includes(level)) throw new Error(`unsupported verification level ${level}`)
   if (level !== 'static' && options.yes !== true) throw new Error(`migrate verify --level ${level} executes project commands and requires --yes`)
+  if (level !== 'static' && options.install !== true) throw new Error(`migrate verify --level ${level} requires --install to synchronize and verify target dependencies`)
   const analysis = analyzeMigration(pluginRoot, options)
   const result = {
     schemaVersion: 1,
@@ -111,10 +159,29 @@ export function verifyMigration(pluginRoot = process.cwd(), options = {}) {
     manualBehaviorVerificationRequired: true,
   }
   if (level === 'static') return result
+  if (!result.passed) return result
 
   const root = analysis.plugin.root
   const manifest = JSON.parse(readFileSync(join(root, 'package.json'), 'utf8'))
   const manager = packageManager(root)
+  const lockfileBefore = lockfileHash(root, manager)
+  const installRun = commandResult(manager.command, manager.install, { cwd: root })
+  const dependencies = installedDependencyEvidence(root, manifest)
+  const dependenciesPassed = installRun.passed && dependencies.every(item => item.passed)
+  result.stages.push({
+    name: 'dependencies',
+    passed: dependenciesPassed,
+    packageManager: manager.command,
+    command: commandEvidence(installRun),
+    lockfile: {
+      file: manager.lockfile,
+      beforeHash: lockfileBefore,
+      afterHash: lockfileHash(root, manager),
+    },
+    resolved: dependencies,
+  })
+  result.passed = dependenciesPassed
+  if (!result.passed) return result
   const scripts = ['typecheck', 'build', 'test', 'pack:check'].filter(name => typeof manifest.scripts?.[name] === 'string')
   const commandRuns = []
   for (const script of scripts) {
@@ -147,7 +214,8 @@ export function verifyMigration(pluginRoot = process.cwd(), options = {}) {
   const [versionCommand, versionArgs] = dshInvocation(dsh, ['--version'])
   const versionRun = commandResult(versionCommand, versionArgs, { cwd: root, env })
   const actualDshVersion = versionRun.stdout.trim()
-  const versionPassed = versionRun.passed && actualDshVersion === analysis.migration.to.version
+  const expectedDshVersion = analysis.migration.actualTarget.version
+  const versionPassed = versionRun.passed && actualDshVersion === expectedDshVersion
   const pack = commandResult(manager.command, manager.pack(packDir), { cwd: root })
   const tarball = tarballFromPack(pack, packDir)
   const runtimeCommands = []
@@ -169,7 +237,7 @@ export function verifyMigration(pluginRoot = process.cwd(), options = {}) {
   result.stages.push({
     name: 'runtime',
     passed: runtimePassed,
-    dshVersion: { expected: analysis.migration.to.version, actual: actualDshVersion, passed: versionPassed, command: commandEvidence(versionRun) },
+    dshVersion: { expected: expectedDshVersion, catalog: analysis.migration.to.version, actual: actualDshVersion, passed: versionPassed, command: commandEvidence(versionRun) },
     pack: commandEvidence(pack),
     tarball,
     commands: runtimeCommands.map(commandEvidence),