dsh-purge 1.1.71 安装后没生效：按路径、profile 和进程排查
dsh-purge 没有出现侧栏、插件启用报 failed to import、状态里有跳过项，这三种现象要分开处理。前一种先查安装位置与 profile，导入错误先查插件版本，跳过项则需要看对应组件是否存在。把它们都归为"模型不听提示词"，很容易排错方向。
本文依据 1.1.71 固定发行文档整理本地安装及状态核对步骤。项目作者为小杨（YuJunZhiXue），这是 DeepSeek Harness 的第三方本机评测插件，会改动宿主包与配置；下面的核对对象是插件是否正确加载，不包含模型效果测试。
先划定适配环境
该版文档支持 dsh 0.2，具体列出官方桌面 0.2.0-rc.2 与官方 dsh web。旧版 dsh 0.1.x 不能直接套用这一版适配结论，社区桌面端也不在维护范围内。若宿主不在这组范围内，应先解决版本匹配，不能靠重复应用确认兼容。
Node.js 最低为 18；Windows 想满足文档所述的无闪窗条件，需要 22 及以上。发行附件 dsh-purge-1.1.71.zip 是插件项目归档，没有随包提供完整宿主，也没有按不同处理器拆分安装器。运行条件要与当前 Harness 所用的环境一起核对。
同机 Web 和桌面需要分别处理：前者使用 web profile，后者使用 desktop。最小排查记录应包含宿主类型、宿主版本、插件版本和当前主目录。这样看到的状态才有明确归属。
从本地项目装入目标 profile
解压发行 ZIP，在终端进入实际项目根目录，确认那里有 package.json、lib、client.js。命令中的本地目标点号代表当前目录，因此必须先把目录选对。
已有可用 dsh 命令时，Web 对应：
sh
dsh plugin --profile web add .官方桌面对应：
sh
dsh plugin --profile desktop add .选择当前使用的那一个即可。不要为排查 Web 侧栏缺失，顺手把桌面 profile 也改一遍；多增加一份变化会让之后的观察更难解释。若命令本身不存在，应先核对 Harness 安装与 PATH，而不是把插件文件随意复制到猜测的系统目录。
这里采用固定原包的本地安装形式。标签 README 中的包名说明与当前主分支的指引已有差异，主分支归档也会变化；复现本文版本时，不应把可变来源当成相同的安装输入。
找不到 dsh 时，手动配置要看哪一份目录
固定文档给出了手动路径：先识别真实的 $DSH_HOME，里面应有 profiles 及目标 profile 的 package.json。定位时先看环境变量，再查启动器旁的 .dsh 和用户主目录等候选位置。桌面便携安装与命令行安装可能留下不同目录，目录名相似不代表正在使用。
插件目录应位于 $DSH_HOME/plugins/dsh-purge，项目的 package.json 名称也应为 dsh-purge。只在目标 profile 的 package.json 里追加依赖及 bundle，原有内容先备份并保留：
json
"dependencies": {
"dsh-purge": "file:../../plugins/dsh-purge"
}这段只表示需要增加的依赖关系，不能拿它覆盖整个文件。还要在 dsh.profile.bundles 末尾追加 dsh-purge，已经存在则不要重复添加；桌面原本没有的 Web bundle 也不要硬加。
随后在刚修改的 profiles/web 或 profiles/desktop 目录安装依赖，文档使用 pnpm install。成功后的路径应出现该 profile 的 node_modules/dsh-purge/package.json。JSON 解析失败先查逗号，本地依赖无法解析先查相对目录关系，别删光原有 bundle 试错。
侧栏出现以后，还要核对加载周期
安装完成先完全退出并重开目标宿主。桌面需要退出托盘实例，Web 需要重新启动对应进程。会话标题旁的 dsh-purge 打开侧栏，"清洗"里才是应用入口，宿主设置页没有同样的条目。
这张预览显示 v1.1.31，只帮助识别侧栏布局；不要把其中 44 项或满进度当成 1.1.71 的预期结果。
应用成功会自动重启，让改动后的文件进入当前进程；补丁未完成则不会按成功流程重启。之后新开一轮对话再观察，避免把旧会话残留混进结果。
聊天命令 /purge status 会输出主目录和补丁列表。主目录应属于刚才处理的宿主。可选包没有安装时，相关项目显示跳过不阻止其他项目完成；但状态输出不能证明模型效果，也不能替代检查真正发生的操作。
三类常见现象分别往哪里查
没有按钮。 先核对当前运行的是 Web 还是桌面，再查相应 profile 是否装有插件。若修改过手动配置，对照实际启动目录，确认没有改到另一份 .dsh。完全退出后再开，才能排除旧进程仍在使用原配置的情况。
启用时导入失败。 1.1.71 的发行说明明确修复了 1.1.70 混用 ?? 与 || 导致的 failed to import。这一错误发生在插件载入阶段，Web 与桌面共用入口，不应靠切换模型或编辑规则集来处理。该版同时修正旧 apply:x.y.z 标记跨版本沿用的问题。
技能已导入却没按预期加载。 Skill 在当前宿主的 $DSH_HOME/skills/<id>/SKILL.md 下，由 DSH 加载；它不直接加入提示词注入段。先查导入位置及宿主，再检查技能内容，别把规则集、提示词框和 Skill 当作三个可互换的入口。
工具迟迟不返回，要区分前台等待与执行
固定文档指出同批 Bash 调用按顺序执行。旧版插件写入过十分钟的前台等待，后续补丁将带插件标记的旧值恢复为六十秒，无标记的自定义值不动。看到后续调用一直排队，应先分辨是否是前一条命令仍占着前台，而非插件导入再次失败。
在 macOS、Linux 的 Web 环境，文档给出的配置位置是目标 Web profile 的 cordis.patch.yml。若已有相同条目，修改原项，不重复追加。下面是缩短前台等待的示例值：
yaml
- id: bash-sandbox
config:
timeoutMs: 10000能否继续后台运行，还取决于标准 jobs 服务及超时转后台是否开启。有该服务且允许转后台时，十秒后返回任务编号，使用相应任务查询查看结果；没有服务或关闭该行为，超时会终止命令。单次调用自己指定的等待值优先，因此配置默认值后仍需看实际调用条件。修改默认等待不会加速命令本身，核对时应分别记录前台返回和任务最终完成。
留好回退路径，再结束排查
目标文件应用前备份为 .dshpurge.bak。"还原"恢复目标文件并保留用户 prompt-inject.md；"卸载"先还原，再删除注入文件、规则库及插件。文档说明用户 Skill 保留，因此需要彻底整理环境时，还要自己区分哪些是用户内容。
本篇原包对应 v1.1.71 固定提交的 MIT 许可，保留作者版权及许可文本。当前主分支已经改用商业许可，不能从旧标签推广到后续版本。评测只在有权管理的本机、离线靶标或书面授权环境中进行。
排查时，把"按钮出现、主目录对应、插件加载、进程更新"逐项记下来。走到哪一步出了问题，就保留那一步的错误和版本信息；这样比反复重装后只留一句"还是不行"更容易继续定位。
作者：小杨（YuJunZhiXue）。GitHub 仓库：https://github.com/YuJunZhiXue/dsh-purge