Back to Details

plugin-upgrade

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
English | 简体中文
English | 简体中文

plugin-upgrade

plugin-upgrade

Safely handle three task types: read-only update inspection, installed-plugin upgrades, and DSH host version compatibility migration. If user intent is unclear, confirm the mode first; never let "help me check for updates" slide into installing or changing code.
Note: the version cards and reference docs under 
references/
are in English; card IDs and cited commands are language-neutral.
安全处理三类任务：只读更新检查、已安装插件升级，以及DSH主机版本兼容性迁移。若用户意图不明确，需先确认模式；绝不能将“帮我检查更新”的请求直接转为安装或修改代码操作。
注意：
references/
目录下的版本卡片和参考文档为英文；卡片ID和引用命令为通用语言（无语言限制）。

Step 0: choose a mode

步骤0：选择模式

ModeUser intentDefault allowed action
A · inspectCheck for updates or assess impact from a DSH releaseRead-only investigation and report; then stop
B · updateUpgrade an installed plugin to an explicit versionPlan and confirm before changing composition or dependencies
C · author-migrateUpgrade a plugin author's source repository for a newer DSH hostBaseline, build the version corridor and touchpoint inventory, then implement the approved migration
This skill does not handle "upgrade DSH core only and leave the plugins alone," and it must not modify DSH core to conceal plugin incompatibility.
模式用户意图默认允许操作
A · inspect（检查）检查更新或评估DSH版本发布带来的影响只读调查并生成报告，随后停止操作
B · update（更新）将已安装插件升级至指定版本在修改组件或依赖前制定计划并获得确认
C · author-migrate（开发者迁移）为适配新版本DSH主机，升级插件开发者的源码仓库建立基线、构建版本区间和触点清单，随后执行已获批的迁移操作
本技能不处理“仅升级DSH核心而保留插件不变”的场景，且不得通过修改DSH核心来掩盖插件不兼容问题。

Global DSH host upgrades (agent discipline)

全局DSH主机升级（Agent规范）

Upgrading the dsh host itself (
npm install -g @deepseek-ai/dsh@…
) is not Mode B/C plugin work — and when the requesting agent runs INSIDE a dsh session it is structurally fatal: the session IS the host process, npm removes/replaces the very package tree it executes from, the host dies mid-install (the tool call never returns), and the interrupted install leaves package content present WITHOUT regenerated shims — the 
dsh
command itself is gone until an external pinned re-install repairs it. Never execute the global host upgrade from inside a session on that host; hand the user the external procedure:
  1. fully stop every dsh process (a running host holds native-module file locks → EBUSY; a browser refresh is not a host stop);
  2. from an EXTERNAL terminal, run the pinned install 
    npm install -g @deepseek-ai/dsh@<exact-version>
    (a bare package name resolves to the 
    latest
    dist-tag and can silently downgrade to an older line);
  3. restart 
    dsh web
    , hard-refresh the browser, verify version markers and plugins.
Because the host is fully stopped before npm runs, nothing crashes mid-install — a crash during the upgrade is a signature of doing it wrong, not a risk to tolerate. If an install was already interrupted: repair from an external shell by re-running the pinned formal install (never hand-copy package directories or hand-write shims).
升级dsh主机本身（
npm install -g @deepseek-ai/dsh@…
）不属于模式B/C的插件工作范畴——若请求Agent在dsh会话内运行该操作，会导致结构性故障：会话本身就是主机进程，npm会移除/替换其正在执行的包目录，主机会在安装中途崩溃（工具调用永远不会返回），中断的安装会留下包内容但未重新生成shim，
dsh
命令会消失，直到通过外部固定版本重新安装才能修复。绝不能在主机的会话内执行全局主机升级；需告知用户外部操作流程：
  1. 完全停止所有dsh进程（运行中的主机会持有原生模块文件锁，导致EBUSY错误；浏览器刷新不等于停止主机）；
  2. 在外部终端中运行固定版本安装命令：
    npm install -g @deepseek-ai/dsh@<exact-version>
    （仅写包名会解析为
    latest
    dist-tag，可能会静默降级至旧版本分支）；
  3. 重启
    dsh web
    ，强制刷新浏览器，验证版本标记和插件状态。
因为主机在npm运行前已完全停止，安装中途不会出现崩溃——若升级过程中崩溃，说明操作方式错误，而非可容忍的风险。若安装已中断：需从外部shell重新运行固定版本的正式安装（绝不要手动复制包目录或手动编写shim）。

Shared read-only preparation

通用只读准备步骤

  1. Read the target repository's rules such as 
    AGENTS.md
    / 
    CLAUDE.md
    ; check branch, HEAD, working tree, and submodules. Stop and report unfamiliar changes or untracked files; never auto-stash, reset, clean, or checkout.
  2. Record source identity and installation identity separately: registry package, Git checkout, workspace/junction, or copied install; record the source repository/URL, Git SHA, actual package name, the plugin's own version, the declared/resolved DSH dependency cohort, and current DSH/Node versions. A plugin release version (for example 
    0.6.4 → 0.7.0-alpha.0
    ) is not the DSH host corridor (
    0.1.0-rc.6 → 0.1.2-alpha.4
    ). GitHub owner/repo and registry scope/package are independent coordinates — do not derive or rewrite one from the other.
  3. Preserve file ownership boundaries: 
    • package.json
      / lockfile: package and dependencies;
    • dsh-plugin.json
      : community-standard manifest (if adopted);
    • cordis.patch.yml
      / 
      agent.cordis.yml
      / legacy 
      cordis.yml
      : profile composition;
    • resolved config: runtime composition result, used for verification only; never write the whole object back.
  4. Verify the target version's source, tag/package name, compatibility range, release notes, install scripts, and known breaking changes. Never read, print, or commit tokens, 
    .npmrc
    contents, credentials, or session logs.
  5. Record the rollback baseline: current HEAD/package version, lockfile, and hashes/paths for configuration that may change. Describe recovery only for the explicit paths owned by this task; do not promise rollback of arbitrary third-party script side effects.
  1. 阅读目标仓库的规则文档，如
    AGENTS.md
    / 
    CLAUDE.md
    ；检查分支、HEAD、工作区和子模块。若发现不熟悉的变更或未跟踪文件，需停止操作并报告；绝不能自动暂存、重置、清理或切换分支。
  2. 分别记录源码标识和安装标识：注册表包、Git检出、工作区/链接或复制安装；记录源码仓库/URL、Git SHA、实际包名、插件自身版本、声明/解析的DSH依赖组，以及当前DSH/Node版本。插件发布版本（例如
    0.6.4 → 0.7.0-alpha.0
    ）不等于DSH主机版本区间（
    0.1.0-rc.6 → 0.1.2-alpha.4
    ）。GitHub所有者/仓库与注册表作用域/包是独立的坐标——不要从其中一个推导或改写另一个。
  3. 保留文件所有权边界： 
    • package.json
      / 锁文件：包及其依赖；
    • dsh-plugin.json
      ：社区标准清单（若已采用）；
    • cordis.patch.yml
      / 
      agent.cordis.yml
      / 旧版
      cordis.yml
      ：配置文件组合；
    • 解析后的配置：运行时组合结果，仅用于验证；绝不能将整个对象写回。
  4. 验证目标版本的源码、标签/包名、兼容性范围、发布说明、安装脚本和已知破坏性变更。绝不能读取、打印或提交令牌、
    .npmrc
    内容、凭证或会话日志。
  5. 记录回滚基线：当前HEAD/包版本、锁文件，以及可能变更的配置的哈希值/路径。仅描述本任务涉及的明确路径的恢复方法；不要承诺回滚任意第三方脚本的副作用。

Mode A · inspect (read-only)

模式A · 检查（只读）

Report: current/available versions, source, compatibility range, breaking changes, recommended target, risks, and a validation plan. Do not edit files, install dependencies, run lifecycle scripts, 
git pull
, or switch versions. If the user decides to proceed, enter Mode B or C with separate confirmation.
生成报告：当前/可用版本、源码、兼容性范围、破坏性变更、推荐目标版本、风险，以及验证计划。不得编辑文件、安装依赖、运行生命周期脚本、执行
git pull
或切换版本。若用户决定继续，需单独确认后进入模式B或C。

Mode B · update (upgrade an installed plugin)

模式B · 更新（升级已安装插件）

  1. Choose the single update mechanism that matches the resolved package identity and installation track; when a lockfile exists, use only its package manager — do not mix npm/pnpm/bun, and do not rewrite a registry package name to match a GitHub owner.
  2. Produce a change plan: exact target version, commands to run, files that will change, lifecycle scripts that may run, configuration migration, and rollback steps.
  3. Obtain explicit user confirmation before any write or install, even when no breaking change is known.
  4. Make minimal changes in a dedicated branch/worktree; patch configuration by path and preserve unknown fields. For Git sources, fetch and compare an explicit tag or commit first; never 
    git pull
    a dirty worktree.
  5. Successful dependency installation does not mean DSH has enabled the plugin; verify the target profile's composition actually resolves to the target package, remove old source lines owned by this upgrade if any exist, and confirm the runtime entry is active.
  6. Run "Validation and reporting"; on failure, restore only the paths owned by this task and report residual side effects.
  1. 选择与解析后的包标识和安装路径匹配的单一更新机制；若存在锁文件，仅使用其对应的包管理器——不要混合使用npm/pnpm/bun，也不要将注册表包名改写为匹配GitHub所有者。
  2. 生成变更计划：精确的目标版本、要运行的命令、将变更的文件、可能运行的生命周期脚本、配置迁移步骤和回滚步骤。
  3. 即使已知无破坏性变更，在进行任何写入或安装操作前也需获得用户明确确认。
  4. 在专用分支/工作区中进行最小化变更；按路径修补配置并保留未知字段。对于Git源码，先获取并比较明确的标签或提交；绝不能在脏工作区执行
    git pull
    。
  5. 依赖安装成功不代表DSH已启用该插件；验证目标配置的组合是否确实指向目标包，移除本次升级涉及的旧源码行（若存在），并确认运行时入口已激活。
  6. 执行“验证与报告”步骤；若失败，仅恢复本任务涉及的路径并报告残留副作用。

Mode C · author-migrate (migrate a plugin source repository with a DSH upgrade)

模式C · 开发者迁移（随DSH升级迁移插件源码仓库）

  1. Run the baseline first: in the repository's own dependency state (no target pin, no target env) run the mechanical suite (build / typecheck / tests; these run package scripts, so first show the commands to be executed per the safety boundaries and obtain confirmation), and record pre-existing failures as an exemption list (see R-06 in references/rollup-0.1.2.md; later corridors follow the same pattern). The migration must not add or worsen failures; pre-existing failures are exempted per the baseline.
  2. Confirm exact from/to tags; connect version corridors by the 
    from → to
    metadata in references/README.md — never by filename lexicographic order. If the source is older than the earliest card, mark that segment as an unsupported gap and derive it from exact-tag source, packed declarations, and reproducible tests; do not pretend a later card covers it.
  3. Read the full corridor first and compute the final net state. When a field is removed in an intermediate version and restored in the target, do not delete and re-add it.
  4. Scan the seven touchpoint classes per pre-flight.md: source patches, events, services/Remote, host filesystem, UI/commands/tools, custom channels, subprocess/output. You may first run the read-only migration planner to generate paths/line numbers and candidate cards, but its results remain heuristic; zero hits still require checking dependencies/imports and running build plus a real mount.
  5. Keep only cards that intersect the hit touchpoints and the actual face (Host / Web Client / ordinary plugin). Cards are a curated list, not a complete API diff; when corridor edges or API coordinates are missing, mark them unsupported/pending instead of changing things from memory.
  6. Produce a source-migration plan grouped by Host/Web Client seam, listing hit files, cards, target behavior, and tests; obtain confirmation before implementing in a dedicated branch/worktree. Keep the DSH cohort exact and coherent in 
    package.json
    and the lockfile; a successful install with mixed old/new peers is not a migration. If a selector or callback unexpectedly becomes 
    any
    , run one diagnostic typecheck with 
    skipLibCheck: false
    and declare the packages that own the consumed declarations directly. 
    capability
    cards are suggestions only — never adopt them automatically.
  7. After compatibility changes pass, choose and apply the plugin's own SemVer bump separately. Verify the packed filename and packed manifest both carry that plugin version; never use the DSH host version as the plugin release version by accident. For the removed 
    dsh-client-runtime
    , keyed chat snapshots, command execution signature, or Workspace navigation (
    connectWorkspace
    / 
    pickDirectory
    ), use the alpha.2 API ledger and DSH-0.1.2-A1-32.
  1. 先执行基线检查：在仓库自身的依赖状态（无目标版本固定、无目标环境）下运行机械测试套件（构建/类型检查/测试；这些会运行包脚本，因此需先展示将执行的命令以符合安全边界并获得确认），并将预先存在的失败记录为豁免列表（参见references/rollup-0.1.2.md中的R-06；后续版本区间遵循相同模式）。迁移不得新增或加剧失败；预先存在的失败按基线规则豁免。
  2. 确认精确的起始/目标标签；通过references/README.md中的
    from → to
    元数据连接版本区间——绝不要按文件名字典序连接。若源码早于最早的卡片，将该段标记为不支持的空白区间，并从精确标签源码、打包声明和可复现测试中推导；不要假设后续卡片涵盖该区间。
  3. 先通读完整的版本区间并计算最终的净状态。若某个字段在中间版本被移除并在目标版本中恢复，不要执行删除后重新添加的操作。
  4. 按pre-flight.md中的七类触点进行扫描：源码补丁、事件、服务/Remote、主机文件系统、UI/命令/工具、自定义通道、子进程/输出。可先运行只读的migration planner生成路径/行号和候选卡片，但其结果仍为启发式；即使无命中，仍需检查依赖/导入并运行构建及实际挂载。
  5. 仅保留与命中触点和实际载体（Host / Web Client / 普通插件）相交的卡片。卡片是经过筛选的列表，并非完整的API差异；若版本区间边缘或API坐标缺失，标记为不支持/待处理，而非凭记忆修改。
  6. 生成按Host/Web Client边界分组的源码迁移计划，列出命中文件、卡片、目标行为和测试；在专用分支/工作区中执行前需获得确认。保持
    package.json
    和锁文件中的DSH组精确且一致；混合新旧依赖的成功安装不代表迁移完成。若某个选择器或回调意外变为
    any
    ，运行一次
    skipLibCheck: false
    的诊断类型检查，并直接声明拥有所使用声明的包。
    capability
    卡片仅为建议——绝不要自动采用。
  7. 兼容性变更通过后，单独选择并应用插件自身的SemVer版本提升。验证打包文件名和打包清单均携带该插件版本；绝不要意外将DSH主机版本用作插件发布版本。对于已移除的
    dsh-client-runtime
    、键控聊天快照、命令执行签名或Workspace导航（
    connectWorkspace
    / 
    pickDirectory
    ），请使用alpha.2 API ledger和DSH-0.1.2-A1-32。

Safety boundaries

安全边界

  • Show the plan and obtain confirmation before any file write, install, version fetch/switch, or package script run;
  • Never auto-stash/reset/clean/force-update, and never overwrite user or other agents' work;
  • Never expose credentials; diagnostics may report only whether something is configured and non-sensitive versions/sources;
  • Do not retry unknown 
    gateway/internal
    or other failures by default; retry only when the error is retryable, the operation is idempotent, and policy allows;
  • When a migration approach cannot be determined with high confidence from primary sources or reproducible behavior, stop automatic changes and mark it "pending review";
  • When local observation conflicts with a primary source, record both, reproduce, and report — do not silently pick one side.
  • 在进行任何文件写入、安装、版本获取/切换或包脚本运行前，展示计划并获得确认；
  • 绝不能自动暂存/重置/清理/强制更新，也不能覆盖用户或其他Agent的工作；
  • 绝不能暴露凭证；诊断仅可报告是否已配置以及非敏感的版本/源码信息；
  • 默认不要重试未知的
    gateway/internal
    或其他失败；仅当错误可重试、操作具有幂等性且策略允许时才重试；
  • 若无法从主源或可复现行为中高置信度确定迁移方法，停止自动变更并标记为“待审核”；
  • 当本地观察结果与主源冲突时，记录两者、复现并报告——不要静默选择其中一方。

Validation and reporting

验证与报告

Validate at least the applicable layers:
  1. Dependency resolution: the package manager, lockfile, and dependency graph change only as expected; scan the full lockfile for the old DSH cohort and removed packages, not only top-level dependencies;
  2. Enablement resolution: the target profile's composition points to the expected package identity, with no old source or duplicate rows;
  3. Static: build, typecheck, and plugin tests;
  4. Runtime: cold-start a real DSH profile; verify entry activation and that required/provided Cordis services do not remain pending — verify-runtime.mjs runs this layer end-to-end in an isolated profile and reports failure attribution (plugin-code / dependency-resolution / profile-config / dsh-runtime). For a Web Client plugin, exchange the printed token URL for its cookie, read the host boot manifest, request the advertised client artifact, and prove registration/mount rather than accepting a bare HTTP 200;
  5. Behavior: execute one core plugin path; host migrations must complete at least one message → tool → response flow, or an equivalent dedicated flow;
  6. Wrapper: verify exit code, stdout, stderr, cancellation, and teardown.
Structure the report as:
  • pre-existing (Mode C with the baseline run; other modes note "not collected"): the list of failures from the baseline (untouched, not attributed to this migration);
  • Completed: versions, files, cards, and validation;
  • Skipped: non-hits or inapplicable items with evidence;
  • Pending/residual risk: missing sources, untested platforms, lifecycle-script side effects;
  • Rollback: recorded baseline and recoverable paths;
  • Recommendations: optional capabilities and follow-up work migrating to public seams.
至少验证适用的层级：
  1. 依赖解析：包管理器、锁文件和依赖图仅按预期变更；扫描完整锁文件查找旧DSH组和已移除包，而非仅检查顶层依赖；
  2. 启用解析：目标配置的组合指向预期的包标识，无旧源码或重复行；
  3. 静态检查：构建、类型检查和插件测试；
  4. 运行时：冷启动真实DSH配置；验证入口激活状态，以及所需/提供的Cordis服务未处于待处理状态——verify-runtime.mjs在隔离配置中端到端运行该层级，并报告失败归因（插件代码/依赖解析/配置文件/dsh运行时）。对于Web Client插件，将打印的令牌URL转换为其Cookie，读取主机启动清单，请求已声明的客户端工件，并证明注册/挂载成功，而非仅接受HTTP 200响应；
  5. 行为：执行一条核心插件路径；主机迁移必须至少完成一次消息→工具→响应流程，或等效的专用流程；
  6. 包装器：验证退出代码、标准输出、标准错误、取消操作和清理过程。
报告结构如下：
  • 预先存在的问题（模式C需运行基线检查；其他模式标注“未收集”）：基线检查中发现的失败列表（未修改，不归因于本次迁移）；
  • 已完成：版本、文件、卡片和验证情况；
  • 已跳过：未命中或不适用的项目及证据；
  • 待处理/残留风险：缺失的源码、未测试的平台、生命周期脚本副作用；
  • 回滚：已记录的基线和可恢复路径；
  • 建议：可选功能及迁移至公共边界的后续工作。

References

参考资料

FilePurpose
references/README.mdVersion corridors, card schema, and maintenance rules
references/pre-flight.mdSeven-class touchpoint self-check and summary template
references/troubleshooting.mdPost-migration symptom → root cause → card lookup
references/v0.1.1-rc.1.mdrc.8→rc.1 draft cards: repository-plugins mechanism removal, 
dshClient
→
dsh.client
manifest merge, client-modules scan → bundle 
dsh.client
, strict injection + weak 
ctx.get
, session event contract, self-rendering client session aggregation, 
tasks.peek
removal, 0812 service renames (vlln plugin migrations; corridor is the closest published-tag alignment for the internal 0810–0812 snapshot window)
references/v0.1.2-alpha.1.mdrc.2→alpha.1 curated cards
references/v0.1.2-alpha.2.mdalpha.1→alpha.2 curated cards
references/v0.1.2-alpha.3.mdalpha.2→alpha.3 curated cards (1): no breaking plugin changes; additive 
settings.plugin.item
keyed-slot settings card capability; carries the verification record
references/v0.1.2-alpha.4.mdalpha.3→alpha.4 curated cards (6): 
report
tool package removed in favour of 
send_message
, Python code-runtime package renamed, 
Session.events
replaced by 
seq
/
eventAt
/
snapshotEvents
, branded 
SessionSeq
/
SessionLogOffset
+ 
seedLength
→
isSeeded
, PTC preset drops 
workflow
, base bundle enables 
web_fetch
; carries a three-host verification record
references/v0.1.2-alpha.5.mdalpha.4→alpha.5 curated cards (3): storage domains gain optional 
compatibleVersions
read tolerance and 
invalidRecords: 'backup-and-skip'
salvage; host fix for rc.2/alpha.3-era homes that refused to boot or dropped session titles on alpha.4; carries a storage-layer reproduction record
references/v0.1.2-rc.1.mdalpha.5→rc.1, the first release candidate of the 0.1.2 series (zero cards: pure version bump, no plugin-facing changes; verification record plus a release-notes coverage matrix mapping the rc.1 summary onto the corridor cards, with backfill candidates)
references/api-migration-0.1.2-alpha.2.mdExact rc.2→alpha.2 interface ledger; read when API, Remote, Settings, events, Headless, packaging, or composition surfaces are hit; includes the removed client runtime and keyed chat snapshots (API-10)
references/rollup-0.1.2.md0.1.1 → 0.1.2 corridor (rollup): cross-cohort coexistence, unpublished-cohort installation, 
RemoteResult
error flow, pre-migration baseline attribution, bounded retry for boot race, base-only preset precondition, type-surface export drift, host-self safety boundary, install-channel pitfalls (mirror lag, pnpm 11 supply-chain rules, peer-floor prerelease semantics), and the layered validation checklist; based on rc.1 and subject to final-release review
| scripts/README.md | Executable helper scripts: 
plan-migration
(read-only migration planner), 
verify-runtime
(offline runtime contract checker), and 
ghost-host-check
(ghost-host classifier for pre-flight step 1.5) | | examples/legacy-plugin/ | Static fixture for the seven touchpoint classes (never execute) | | examples/08-real-web-client-alpha2-migration.md | Real Host + Web Client source migration from an older unsupported corridor segment |
Normative background: dsh-community-standard owns manifests, contract coordinates, and negotiation conventions; this skill handles practical upgrades of existing plugins, reusing that classification without redefining it. The official call for contributions is deepseek-harness discussion #5120.
文件用途
references/README.md版本区间、卡片 schema 和维护规则
references/pre-flight.md七类触点自我检查和总结模板
references/troubleshooting.md迁移后症状→根因→卡片查找
references/v0.1.1-rc.1.mdrc.8→rc.1 草稿卡片：移除repository-plugins机制、
dshClient
→
dsh.client
清单合并、客户端模块扫描→打包
dsh.client
、严格注入+弱
ctx.get
、会话事件契约、自渲染客户端会话聚合、移除
tasks.peek
、0812服务重命名（vlln插件迁移；版本区间是内部0810–0812快照窗口最接近的发布标签对齐）
references/v0.1.2-alpha.1.mdrc.2→alpha.1 精选卡片
references/v0.1.2-alpha.2.mdalpha.1→alpha.2 精选卡片
references/v0.1.2-alpha.3.mdalpha.2→alpha.3 精选卡片（1个）：无插件破坏性变更；新增
settings.plugin.item
键控插槽配置卡片功能；包含验证记录
references/v0.1.2-alpha.4.mdalpha.3→alpha.4 精选卡片（6个）：移除
report
工具包并改用
send_message
、Python代码运行时包重命名、
Session.events
替换为
seq
/
eventAt
/
snapshotEvents
、标记化
SessionSeq
/
SessionLogOffset
+ 
seedLength
→
isSeeded
、PTC预设移除
workflow
、基础包启用
web_fetch
；包含三台主机的验证记录
references/v0.1.2-alpha.5.mdalpha.4→alpha.5 精选卡片（3个）：存储域新增可选
compatibleVersions
读取容忍度和
invalidRecords: 'backup-and-skip'
修复机制；修复rc.2/alpha.3版本主机在alpha.4版本无法启动或丢失会话标题的问题；包含存储层复现记录
references/v0.1.2-rc.1.mdalpha.5→rc.1，0.1.2系列首个候选版本（无卡片：仅版本提升，无插件相关变更；验证记录加上发布说明覆盖矩阵，将rc.1摘要映射到版本区间卡片，并包含补充候选项）
references/api-migration-0.1.2-alpha.2.mdrc.2→alpha.2 精确接口清单；当涉及API、Remote、Settings、事件、Headless、打包或组合层面时阅读；包含已移除的客户端运行时和键控聊天快照（API-10）
references/rollup-0.1.2.md0.1.1 → 0.1.2 版本区间（汇总）：跨版本共存、未发布版本安装、
RemoteResult
错误流程、迁移前基线归因、启动竞争的有限重试、仅基础预设前提、类型层面导出漂移、主机自我安全边界、安装通道陷阱（镜像延迟、pnpm 11供应链规则、peer下限预发布语义），以及分层验证清单；基于rc.1，需经最终发布审核
| scripts/README.md | 可执行辅助脚本：
plan-migration
（只读迁移规划器）、
verify-runtime
（离线运行时契约检查器）和
ghost-host-check
（预检查步骤1.5的幽灵主机分类器） | | examples/legacy-plugin/ | 七类触点的静态示例（绝不要执行） | | examples/08-real-web-client-alpha2-migration.md | 从旧版不支持版本区间迁移真实Host + Web Client源码的示例 |
规范性背景：dsh-community-standard定义了清单、契约坐标和协商约定；本技能处理现有插件的实际升级，复用该分类而非重新定义。官方贡献号召见deepseek-harness discussion #5120。