admin
64dd82073b
1) stop-dialog-guard: session_budget() 早退路径返回 2 值、末尾返回 3 值，调用方按 3 值解包
⇒ transcript > 64 MiB 时每轮 ValueError。因 fail-open（异常仍 exit 0），
宿主零报错、install.py --verify 只判 rc=0 ⇒ 假绿；实测 86 条 EXCEPTION，
死掉的是整条（水位/收口、接续机制起点、预算告警、门禁自检、路径自检）。
2) session-rules-check 三处判据：
· hook_reg 按旧文件名找 ⇒ 合并成 prompt-guards.py 后每轮假红 ⇒ 改为一组可接受名
· snap_sync 拿 mtime 当内容判据 ⇒ 连续 4 天假红 ⇒ 改为复用抽取器本体比对内容
（变异对照：截断快照能报 fail，非恒绿）
· mem_ptr 只查全局技能根 ⇒ 工作区自带技能被判悬空 ⇒ 改查「全局 ∪ 工作区」
3) pitfalls 新增 P0-95（改判据必须重跑变异对照；fail-open + 只看 rc=0 = 假绿温床）
4) 回复排版核心块新增「变相征询同样禁止」（先只报不动／等你发话／我倾向X你看呢
这类不带选项的待定清单，一律按待拍板项写：问题＋说明＋各候选优缺点＋倾向）
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） |