dsh-file-path-repair

dsh-file-path-repair — 图片路径修复

本地图片（聊天里的 Markdown 图片、会话文档预览）在取文件前，把被 Markdown 转义吃掉的分隔符还原回去。不靠提示词，不挑模型，不挑会话。

问题

本地图片走 /api/file?path=…，path 是 Markdown 解析器给出的目标。在链接目标里，反斜杠后跟 ASCII 标点会被当作 CommonMark 转义：

写出来的：  ![x](C:\work\_out\shot.png)
解析得到：  C:\work_out\shot.png        ← \_ 的 \ 被吃掉
请求结果：  404 → 「图片无法预览 · alt」

这个还原在解析器里发生，早于客户端任何路径钩子（pathImages / fileImages），所以页面侧插件拿不到原始路径；而「让模型改成正斜杠」只对新生成的文字有效，别的智能体、历史消息都不管用。

做法

包住 /api/file 的处理函数：

1. 原样交给原处理器；不是 404 就直接返回，正常路径零影响。
2. 是 404 时，按「Markdown 转义只会发生在 ASCII 标点前」生成候选路径（把 \ 插回标点前，1~3 处组合，最小改动优先）。
3. 每个候选都用 HEAD 走原处理器探测，也就是说仍然由组合出来的文件系统提供方（含沙箱策略）决定能不能读。
4. 只有恰好一个候选存在时才用它重新取文件；两个都像，就保持原来的 404，不猜。
5. 预算：单次最多 160 次探测、400ms。

边界

• 只在已经失败的请求上工作；目录依旧拒绝，不存在的文件依旧 404。
• 依赖 Connection 服务里的 fetchRoutes 表与 registerFetchRoute；上游如果改名，本插件会静默失效（不影响任何请求），不会把路径改成错的。
• 卸载时还原：路由的包装标记与 registerFetchRoute 都会被恢复。

测试

node test/repair.test.mjs

用真实文件系统 + 一个与官方行为一致的假处理器，覆盖：正常路径、被吃掉分隔符的路径、HEAD、两个候选的歧义、无可修复、指向目录。