admin
5ad755116e
1) dsh-server-docs/ 从工作区（原 E:\...\aliyun-dsh-server\dsh-server-docs）**整体并入本仓**，
保留目录名 ⇒ 仓库内 dsh-server-docs/... 的相对引用天然继续有效；旧目录（含其 .git）已归档到
工作区 _中间产物_待清理/，未随本提交带入。
2) .gitattributes：新增 `dsh-server-docs/** -text` —— 原文档库是 `* -text` + autocrlf=false，
必须保持纯 LF，否则会被本仓的 CRLF 规则翻掉。
3) 活引用里的绝对路径已全部改到新位置（docs 的 INDEX / README / scripts / skills + 用户级 skills
+ ~/.workbuddy/settings.json 的 hooks）；历史档案（04-调整方案/、archive/）按「只增不改」未动。
⚠️ hooks 路径改动需「完全重启会话」才生效（配置是会话启动快照）。
4) 交接单/T08：新增 §16「生产整体切换执行记录」（形态 / 落地动作 / **4 个只有真上线才暴露的真 bug** /
验收证据 / 回滚命令 / 残留项）；台账 T08 行 → 已完成并归档；03-路线图 §二 登记 T08 收尾项。
5) 统一称谓：**「本机」只指跑 WorkBuddy 的开发机**，47 / 106 一律写「远程服务器」。
3.9 KiB
3.9 KiB
调整方案 07：红线 — 禁止 dsh 自动获取最新版本 + 版本升级流程
2026-09-09 ｜ 状态：生效（配置已落地 + 核查记录）｜ 适用：dshs + dsh 0.1.2-rc.1 生产平台（47.77.182.89）
一、红线（用户 2026-09-09 提出，原文）
禁止启动 dsh 时自动获取最新版本，避免版本更新带来的功能差异导致运行失败。后续 dsh 版本更新时，需要单独建立项目升级测试评估和修复后，再整体更新到现有项目。
含义拆解：
- 任何"启动/命令时联网拉取 dsh 最新版本"的行为一律禁止——防止运行环境在某次启动后被悄悄切到新版本（功能差异 → 运行失败）。
- dsh 版本升级 = 独立升级项目：先在隔离环境做 升级测试 → 影响评估 → 差异修复，验证通过后才允许整体更新生产项目。
- 红线不阻止日常 dshs 平台层自身功能改造（那是本项目源码，不在此列）。
二、自动获取版本向量核查（2026-09-09，服务器实测）
| 向量 | 是否自动查版本 | 核查结果 | 处置 |
|---|---|---|---|
dsh 主程序启动（dsh --profile web） |
❌ 不会 | grep lib 全部源码：无 checkForUpdate / update-notifier / registry latest 拉取逻辑（零命中） | 无需处理（红线天然满足） |
| npm 命令 | ⚠️ 会 | npm update-notifier 默认 true，任何 npm 命令联网查 latest 并打印横幅 | /usr/local/etc/npmrc 追加 update-notifier=false ✅（npm/pnpm 双生效，实测均 false） |
pnpm 命令（含 dsh plugin 转发） |
⚠️ 会 | 此前已见横幅 "Update available 9.15.9 → 12.3.4"（仅提示，不自动升级） | 同上，同一条全局配置已覆盖 |
| 门户 spawn 实例 | ❌ 不会 | spawner 仅注入 DSH_HOME/DEEPSEEK_API_KEY 等 env，无版本检查 | 无需处理 |
| 门户自身升级 | — | dshs 由本项目 git 管理，手动构建部署 | 遵守第三节流程 |
结论：dsh 本身启动不查版本；真正会联网查版本的只有 npm/pnpm 的 update-notifier（横幅性质，不改变版本），已全局关闭。该配置在 /usr/local/etc/npmrc，对所有用户（root + 各 dsh-uid）生效。
三、版本升级流程（红线执行协议）
| 阶段 | 动作 | 产出/门禁 |
|---|---|---|
| 0 触发 | 官方发布新版本 / 修复需要升级时，先建独立任务，不得直接在现网执行升级 | 任务单 + 本档案更新 |
| 1 升级测试（隔离） | 独立项目/目录或临时 profile 安装目标版本，跑冒烟：profile 启动、插件装载、会话、工具、portal 联动 | 测试记录（通过/失败清单） |
| 2 影响评估 | 对比当前 0.1.2-rc.1 与目标版：breaking API、profile/bundle 兼容、自定义插件（portal-entry 等）API 依赖面、schema/DB 变化 | 评估表：差异项 → 影响 → 处置 |
| 3 差异修复 | 对受影响的自定义插件 / 平台代码做适配修复，在隔离环境回归 | 修复清单 + 回归通过 |
| 4 整体更新 | 评估+修复全部完成后，备份 → 更新全局 dsh（含主程序与 bundle）→ 更新自定义插件 → 全量回归（所有用户实例） | 备份归档 + 回归记录 |
| 5 回滚预案 | 任一步失败可回滚：备份清单见 /opt/dsh/backups/ + profile 快照机制（如 profile-web-admin-poc-*.tgz 同法） |
回滚演练确认 |
当前版本基线：dsh 0.1.2-rc.1（全局 /usr/local/lib/node_modules/@deepseek-ai/dsh）；dshs master@6f63108；自定义插件 @dsh-local/portal-entry v0.1.1（装于各 profile bundles）。
四、相关
- 档案 05 的既有红线仍有效：不改官方 dsh 主程序与缓存，扩展只走 profile 层官方插件机制（dsh plugin add）。本红线是其"版本侧"补充——两者都禁改主程序，本红线进一步禁止隐式换版本。
- 备份：本次仅改
/usr/local/etc/npmrc（追加一行，原内容为空）。