Files
admin e6207aa691
build / build-and-scan (push) Waiting to run
chore(仓库对齐): 文档库结构治理 + IM/插件线落地
文档库:目录改为编号制(01-规范/02-架构设计/03-数据库/04-调整方案/
05-交接单/06-ops/07-scripts/08-skills/09-archive),顶层散文件归入 01-规范/;
INDEX.md 与 docs-manifest.json 重刷(档案 146 篇);旧目录名引用全量对齐。

IM 线:src/im/**(SDK / hub / store / presence / ws / gateway-token)、
src/web/routes/im.ts、src/db/plugin-data/**、src/supervisor/plugin-assembly.ts
及对应 test/**。

插件线:poc/{im-agent-bridge,im-connection-gateway,im-conversation-tabs,
business-plugins-im,carbon-mcp-probe}、src/web/routes/{sessions,overlay-device}.ts、
src/net/relay/{device-grant,instance-credential}.ts。

仓库卫生:清出 40 个历史误入库 / 已改名文件(34 个交接单归档 + 6 个旧结构,
本地均有副本);dsh-server-docs/.gitignore 补 tmp/;交接单不入库(政策)。
2026-09-24 07:25:16 +08:00

5.6 KiB
Raw Permalink Blame History

反例库 · 被驳回 / 被纠正的决策(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) |