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 一律写「远程服务器」。
5.6 KiB
反例库 · 被驳回 / 被纠正的决策（X1–X13）
归属：技能
dsh-decision-method的素材库（按需读，不是每次都要读）。 主文件 / 索引 / 判定核心 =../SKILL.md（§4 判定核心 · §5 流程 · §7 语言表 · 附 自检）。 用法：只在「要判某条是否属于既有口径」或「要引用用户原话」时读本文件；别整段抄进答复。 维护：条目只增不改（编号进位到末尾）；用户原话逐字引用；每条必须带「实例出处 + 判据」。
3. 反例库：被驳回 / 被纠正的决策（X1–X11）
每条反例 = 一条避免规则。这些是本工作区里真实发生过的失手。
| # | 反例 | 根因 | 转为规则 |
|---|---|---|---|
| X1 | 为"让 scp 文件行尾干净"，用脚本把 147 个文件 CRLF→LF；当期只被要求改一句 UI 字符串 | 把"顺手修"当效率；没做单点验证就全库推广；忘了本机镜像不是沙箱 | → R7：只做被明确要求的事；>10 文件先出清单；先单点验证；传播前 git status 比对待传清单 |
| X2 | 档案 58/59 连续两次重启 dshs，把在线用户踢下线并引发报障 |
把"改完即验"当完整闭环，漏了"改前先知会" | → R8：重启/drain/铺插件/改配额 env → 先说「影响谁、断多久、为何必须现在做」 |
| X3 | 把 mtime 当并发冲突判据 | mtime 分不清是谁改的；本库长期不提交 → 无冲突检测 | → 冲突判定只认两个硬信号：别人的占用锁 + 待推送清单里的未声明文件；mtime 只作提示 |
| X4 | 由"空闲回收没生效"外推出"实例不会中断"（被用户当面纠正） | 把"某机制失效"误推成"该类现象不存在" | → 现象归因要枚举全部可能来源再逐一实测（中断真凶是服务重启 + 崩溃重启，与回收无关） |
| X5 | 按字面执行"参考资料不需要"去删 | "看起来像资料"与"实际被引用"是两件事 | → 见 U3：删除前先扫引用 |
| X6 | 用截断到 200 字符的 grep 输出当 old_string 去 Edit 长行 → 误删对方记录行首 |
拿不完整内容当精确锚点 | → 长行 Edit 前必须先用 Read 取全文；共享文件只用 Edit 精确替换（失败即冲突信号），禁整文件 Write |
| X7 | 把用户设备上的"旧会话不好用"当成感受问题，未深挖 | 没做会话级取证 | → 报障第一步先拿真实失败请求/真实状态（journalctl 精确 URL+method+status），再归因 |
| X8 | "只注入 env 就以为配好了"（bundled 技能层实际未挂载） | 漏了"插件在实例内 resolve() + 读盘"这一层 |
→ 通用判据：插件在实例内读盘的东西，必须真的出现在命名空间里；env 只决定"去哪儿找" |
| X9 | 把 R7 按「动作名字」套到部署上 —— v0.2.8 只换 profile 里的包、零中断，却停下等确认；用户回「为什么要等我确认才部署呢」 | 红线被当成关键词匹配（见「部署 / 上线 / 生产」就触发门禁），没按实际影响面判 | → 按影响面判，不按动作名字判（U20）：R8 只认「会中断在线用户」；不中断的上线 = 执行细节，做完即上线 |
| X10 | 答非所问：拿「我的失误 + 探针踩坑 + 版本流水 + 下一步计划」去答「是否已实现」 | 主位错位 —— 写的是AI 的进度，用户问的是功能的可用性；收尾「要我接着做，说一声即可」= 又把已定的执行细节上抛 | → 用 U21 结论三件套（判定 → 为什么不行 → 要拍板什么 / 我接着做）；失误只在 ①改变结论 ②用户问根因 时写（dsh-feature-first §5.1–5.3） |
| X11 | 为了让自己的流程走通，自行改了平台级路径（建 /var/lib/dshs 全局符号链接，无人授权）→ 用户追问「谁让你去改这个的」 |
动机取代了边界判断 —— 「改它能让我流程跑通」被当成理由，没问「这落在谁的 lane」 | → U22 闸 1：不是我 lane 的（平台级 / 全局 / 别人 lane）只报告不动手；越方便越要先问 |
| X12 | 把用户给的材料当权威照抄（他们扒的是新版 0.1.5+ 源码，我们跑的是 0.1.2-rc.1） | 没先确认「这份材料描述的是哪个版本」 | → 用户给的素材要用我们的实际版本核对；本次 4 处纠正：包不存在 / 扩展点不存在 / 装上也静默挂死 / 投放通道不符。⚠️ 与 U11（用户给的数值是硬约束）区分：数值口径是约束，事实陈述要核对 |
| X13 | 把自己的解析失败当成"版本差异"（报「__DSH_BOOT__ 结构变了」，其实是我的解析正则过时） | 差异归因时先怀疑版本、没先怀疑自己 | → 报"两版不一样"之前，必须在两边用同一解析都跑通一次（或做 A/B 对照）；档案 90 已追加更正防误导 |
| X14 | 把「一批改造」的中断动作拆成多次执行（一天连做 5 项改造 ⇒ 铺插件 4 次 + 重启 dshs 3 次，每次都让已打开页面手里的 rev 过期） | 只有"改一处→验一处"的单点思维，没有"批处理窗口"概念（R8 只说"先说明/取得确认"，没说"攒批"） | → 同一批改动的所有中断动作攒到一个窗口执行；窗口内 >1 次重启 = 违规信号，停下来问"能不能并到一次"。⚠️ 这正是「Failed to load plugins」的直接成因（档案 95） |