DSH 与插件日常维护运行手册

基线与原则

• 当前唯一基线：deepseek-harness dsh-v0.1.1-rc.2、pnpm@11.7.0。
• DSH 仍允许破坏性更新；插件直接迁移到新契约，不维护旧版兼容分支。
• Harness 与每个插件使用独立适配分支；先保存用户未提交工作，再更新上游。
• 自动巡检只做只读诊断。推送、合并、发布、关闭 Issue 等外部写操作必须基于已验证结果。

每日巡检

1. 获取 Harness 官方 tag、默认分支与 release 状态，确认是否出现新基线。
2. 读取五个插件仓库的未关闭 Issue、PR、CI 和分支状态。
3. 将事项分成：可直接修复、需要上游适配、需要用户决断、等待发布。
4. 输出建议执行顺序与验证矩阵，不修改代码、不合并、不发布。

适配流水线

1. 为 Harness 和所有插件记录 commit、branch、dirty 状态；脏工作先落可恢复快照。
2. 更新 Harness，运行依赖安装、单元测试和全量构建。
3. 插件 Host 共享依赖改为 optional peer，并在 devDependencies 镜像；profile 禁止自动安装 peer。
4. 逐插件执行 typecheck、build、client bundle 检查和功能 smoke test。
5. 将全部 tarball 安装进一个全新 profile，检查依赖树无重复 Host runtime，并运行 --dump-config。
6. 启动真实 Web profile，验证首页、客户端 bundle、自定义路由安全和进程恢复。
7. 通过后再推送分支、创建/合并 PR、关联 Issue；最后更新本指南。

必须提出决断的情形

• 上游新契约存在两个以上互斥实现，且会改变公开配置、数据格式或安全边界。
• 修复需要删除用户数据、重写历史、强制推送、撤回 npm 包或发布新版本。
• Issue 的产品语义不明确，无法从代码、测试和既有行为推导唯一答案。
• 需要引入新的外部服务、付费依赖、凭据或明显扩大插件权限。

普通编译错误、依赖版本迁移、槽位字段变化、CI 修复和已有契约内的缺陷不进入决断门，直接修复并提交验证证据。