DeepSeek Harness 0.2.1-alpha.2 迁移：webRuntime 服务删除与 cwd 变量移除

DeepSeek Harness（DSH）从 0.2.1-alpha.1 升到 0.2.1-alpha.2 时有两处破坏性变更**，而且都表现为「静默失效 / 每轮失败」而不是「升级报错」，所以很容易被误判成插件坏了或升级装坏了：公开服务 webRuntime 被删除、能力合并进 webStartup，仍按旧名字声明依赖的第三方插件会永远停在等待该服务的状态；以及 cwd 提示变量被有意移除，任何在预设或角色后缀里插值它的配置都会让每个回合在系统提示组装阶段直接失败。 两处都能通过改配置解决，但前提是先认出它们是版本变更而不是故障（#9598、#9428）。

一条背景值得记：该版本的升级指南写在了相邻版本目录下（v0.2.1-alpha.1），而发行说明里零命中——所以你按「当前版本目录」去找是找不到的，这也是这两处容易被漏掉的原因（#9598）。

DeepSeek Harness 变更一：公开服务 webRuntime 被删除并改名

一句话结论：该服务在 0.2.1-alpha.2 被删除、能力合并进新服务；插件仍声明依赖旧服务名，条目就永远停在 waiting for service 状态，而它的 HTTP 路由返回空体的不可用码**（看起来像路由写错了）。** 症状是「一批插件同时看起来装着但界面能力全失效」（#9598）。

DeepSeek Harness 判据：两个都能一眼确认

1. 看条目状态：插件列表里相关条目显示为等待服务，且服务名正是被删除的那个（#9598）。
2. 看 HTTP 返回形态：空体的不可用码 → 偏「宿主没挂载这个插件」；带消息的响应 → 偏「插件的路由写错了」。这条判据能省掉把插件代码翻一遍的时间（#9598）。

DeepSeek Harness 五步迁移

1. 先确认升级前后的分界线：只有升到该版本后才出现；回退到上一版本即恢复。这条能确认是版本变更而非插件自身问题（#9598）。
2. 在插件里把服务引用改成新名字：把对旧网络服务的依赖与取值改为新服务（#9598）。
3. 同步相关配置字段：新服务把原先分散的字段做了合并，所以原来写在旧服务上的配置项要一并挪过去（#9598）。
4. 在 profile 补丁里同步：如果配置文件里也引用了旧服务名，同样需要改写（#9598）。
5. 验证：重启后确认插件条目不再处于等待状态、其界面能力恢复（#9598）。

顺带说明：本次会话里还有另一个同批变更（把 host: '0.0.0.0' 这类通配绑定改为在服务边界按解析后的地址拒绝），它属于修复而非破坏，无需迁移动作（#9598）。

DeepSeek Harness 变更二：cwd 提示变量被移除

一句话结论：这是有意移除**——理由是「可变的目录信息不应进入可复用的提示前缀」，改由工作目录服务以用户上下文的形式提供；但因为大量预设与角色后缀里写死了插值该变量，于是每个回合在提示组装阶段就失败，连模型都没被调用。** 报错文本会明确列出当前已注册的变量名（只剩提供方与模型）（#9428）。

DeepSeek Harness 三步判据

1. 确认报错发生在组装阶段：错误提到「未知的提示变量」并列出已注册变量；模型没有收到任何请求（#9428）。
2. 确认分界线：只有 alpha.1 → alpha.2 之后出现；这不是回归缺陷，而是按设计移除，官方文档、决策记录与回归测试都已就位（#9428）。
3. 确认影响面：因为内置预设本身也写了这句，所以不是只有自定义配置会中招——任何插值该变量的预设都会 100% 失败（#9428）。

DeepSeek Harness 四步迁移

1. 找出所有插值该变量的位置：在预设、角色后缀、以及你自己的 profile 补丁里搜索该变量名（#9428）。
2. 直接删掉那句插值（本轮不需要替代写法）：

# 从 personaSuffix / preset suffix 里删除类似下面这行
# Your working directory is {{cwd}}.

（#9428）

3. 改用官方的替代路径：目录信息已由工作目录相关能力以用户上下文形式注入；需要动态切换目录时用对应的目录工具，而不是往提示前缀里插值（#9428）。
4. 验证：发一条消息，预期不再出现「未知的提示变量」，且模型能正常收到请求（#9428）。
5. 记住这个模式的取舍：把可变内容从可复用的提示前缀里拿掉，是为了让前缀可被缓存复用——所以「想让它回来」在方向上不太可能被接受（#9428）。

DeepSeek Harness 升级检查清单（针对该版本）

把下面两项当作升级的必做动作，能避免上面两个坑（#9598、#9428）：

1. 搜服务名：在插件代码、profile 补丁与配置文件里搜索与网络服务相关的服务名引用，确认没有沿用被删的旧名。
2. 搜提示变量：搜索提示变量的插值写法，确认没有引用已被移除的那个。
3. 按版本目录核对升级指南：注意指南可能挂在相邻版本目录下，别只按当前版本号找（#9598）。
4. 升级后立刻验证两条链路：一条是「插件能否挂载」（看条目状态），一条是「回合能否组装」（发一条消息）。
5. 保留回退路径：先记录升级前版本号，出现难以判断的失效时可回退对照（#9598）。

DSH插件 排查注意事项

这个版本的两处变更都属于「表现不像升级问题」的类型，所以第一条纪律是：升级后先主动对照升级指南，而不是等出问题再查。 七条要点：

1. 「插件静默失效」优先怀疑服务改名，而不是插件本身坏了（#9598）。
2. 空体不可用码 = 没挂载；带消息 = 路由错，这条判据很省时间（#9598）。
3. 升级指南可能在相邻版本目录下，找的时候别只按当前版本号（#9598）。
4. 「未知提示变量」不是回归，是按设计移除（#9428）。
5. 内置预设也会中招：别以为只有自定义配置需要改（#9428）。
6. 报错发生在模型调用之前，这是快速区分「组装期失败」与「模型/网络失败」的判据（#9428）。
7. 修复状态如实：两处都不需要「修复」——它们是该版本有意为之的破坏性变更；你需要的动作是迁移配置（改服务名 / 删变量插值），而不是等官方回滚。

升级类问题最容易误判成故障。若你想在升级前后把「当前到底装了哪些插件、版本各是多少」确认下来，与其在各处手敲命令，不如用 DSH Plugin Hub 这类可视化插件市场：已安装列表带来源与版本、装卸历史与系统日志集中在一个面板里。

来源：Discussion #9598、Discussion #9428。