dsh-preset-bridge — 模式目录桥接
把 0.1.x 惯例的预设目录（~/.dsh/.agent-presets//）重新接入 DSH 桌面版 0.2.x 的模式列表。
> DSH 桌面版 0.2.0 移除了预设目录扫描：官方文档明确「注册表不扫描目录，也不接受 preset 路径」。于是升级桌面版后，router-standard、router-spec 之类以目录形式安装的模式会全部从模式选择器消失（网页版 0.1.x 运行时仍自带扫描，不受影响）。本插件把这条发现通道补回来。
⚠️ 先读限制与不保证 —— 本插件不保证对你的预设生效，且属于过渡期补丁。
本项目由GLM-5.3Flash、DeepSeek V4.1Flash自主开发
安装
推荐方式：把网址发给 AI，由其自行安装
把本仓库地址直接发给 DSH 会话里的 AI（例如桌面端或网页版里说一句）：
> 帮我安装 https://github.com/Lyrissonare/dsh-preset-bridge 这个插件到桌面版 profile，装好后重启验证模式列表。
AI 会自行完成装配、登记 bundles、重启并检查 ~/.dsh/preset-bridge.log 与模式菜单——这比手动执行命令更能发现环境差异（不同机器上预设引用的包不同，可能需要补兼容映射，AI 可以当场处理）。
手动方式
D:\DSH\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop add https://github.com/Lyrissonare/dsh-preset-bridge
然后重启桌面端。验证：新建会话 → 模式选择器应出现 .agent-presets 下的各预设；或打开 设置 → Agent 预设 → 自定义。
> 每次修改 ~/.dsh/.agent-presets/ 里的预设后，需要重启桌面端才会重新注册。
⚠️ 限制与不保证生效
使用本插件前请务必理解以下各条。它是一个过渡期补丁，不是官方功能。
- 只适用于 0.2.x 桌面版 profile，不要装到 0.1.x 环境。 网页版 / 0.1.x 运行时自带目录扫描（
dsh-agent-presets组件提供同名agentPresets服务），再注入一个提供方会冲突。本插件声明了engines.dsh: >=0.2.0-rc <0.3.0-0，超出版本应被安装预检干净拒绝。 - 能被"发现"≠能"健康挂载"。 本插件把预设注册进注册表，但预设内容自身的 0.2.x 兼容性它管不了。健康的预设出现在模式菜单；挂载失败的预设会显示在 设置 → Agent 预设 → 自定义 里并带「加载失败」徽标及原因（菜单只列健康预设）。
- 兼容映射是逐个积累的，当前只覆盖已知的坑。 已处理的唯一一条：
@deepseek-ai/dsh-workflow-worker-thread（0.1.x 的 workflowEngine 提供方，0.2.0 已删除）→ 原位替换为官方的@deepseek-ai/dsh-workflow-ptc。如果你的预设还引用了其他被 0.2.0 移除的包，仍会挂载失败——需要往lib/index.js里补对应映射。引用越"纯官方包"的预设，生效概率越高。 - 引擎行为差异。 worker-thread 与 workflow-ptc 是两种不同的引擎实现（线程池 vs spawn 子进程），工作流类预设的运行细节可能有微妙差异。替换是对齐官方 0.2.x 的推荐做法，但若你的预设依赖 worker-thread 的特定行为，属于已知差异，不承诺一致。
- DSH 大版本更新可能使其失效。 桥接依赖 0.2.0 的内部约定（
agentPresets.register的定义形状、挂载审计规则、isolate 语义、!!js方言、ctx.effect语义）。0.3.0+ 这些随时可能变化——声明了版本上界，届时应被预检拒绝而不是静默失效。失效的后果是良性的：预设从菜单消失，应用本身照常工作，~/.dsh/preset-bridge.log会记录原因。 - 过渡期补丁，随时可能退役。 上游修复后（routing-suite 发布 0.2.x 适配，或 DSH 官方恢复/官方化目录发现），请直接卸载本插件、卸载方式：桌面端 设置 → 插件 → dsh-preset-bridge → 卸载。预设目录本身始终是唯一事实来源，不受任何影响。
- 本插件按"现状"提供，不作任何保证。 见 LICENSE（MIT）。作者不对因使用本插件造成的任何问题负责。
与其他预设的兼容性实测
| 预设 | 结果 |
|---|---|
| router-standard / router-spec / router-react（dsh-routing-suite） | ✅ 需 worker-thread → workflow-ptc 映射（插件已内置） |
| liangshen | ✅ 同上 |
| anchored-standard | ✅ 同上 |
| codex-document-mode | ✅ 零修改直接通过（不引用工作流） |
排障
- 日志：
~/.dsh/preset-bridge.log（桌面端 host 的 ctx.logger 不落盘，插件自己写文件）。 - 预设没出现在菜单：先看 设置 → Agent 预设 → 自定义 里是否带「加载失败」徽标及原因；再看 bridge.log。
- 新增/修改预设后必须重启桌面端（预设目录变化不触发热加载）。
配置
在 profile 的 cordis.patch.yml 里按 id 覆盖：
- id: dsh-preset-bridge
config:
roots: # 额外扫描目录；缺省只扫 ${DSH_HOME:-~/.dsh}/.agent-presets
- D:/somewhere/else/presets
实现细节（血泪坑，贡献者/魔改前必读）
- 相对行名必须改写为绝对
file:URL：0.2.0 注册表挂载预设时按「声明处 baseUrl」解析./xxx.mjs相对名，而所有声明都落在注册表自己的包地址上，预设目录里的本地脚本（router-core-v34.mjs 等）会解析失败。挂载前把./开头的行名（含?v=缓存戳）重写为pathToFileURL绝对地址。 @deepseek-ai/dsh-workflow-worker-thread已被 0.2.0 移除：0.1.x 时代预设的 delegation 组普遍自带这一行当 workflowEngine 提供方；0.2.0 只剩接缝包dsh-workflow和官方提供方dsh-workflow-ptc（provider: spawn，同组 isolate 语义一致）。提供方行导入失败会让同组 tool-workflow / tool-ralph 永远 "waiting for workflowEngine" → 预设被判 broken、模式菜单不显示。插件在注册前原位替换行名（组、isolate、config 形状均不变）。- 提供方行不能裸插在预设顶层：预设审计要求服务发布必须落在带
isolate: { workflowEngine: true }的cordis:group组里，裸行会报 "Preset services require isolate realms"。所以只做「同组原位替换」，不做顶层注入。 !!js节点要构造成{ __jsExpr: ... }惰性表达式节点（与 cordis-plugin-include 的 entryListSchema 同构），由 Loader 在条目激活时求值；不能在解析期 eval。- 本 cordis 的
ctx.effect(setup)语义：setup 立即执行、其返回值才是清理函数（React useEffect 式）。直接把 async 清理函数当 setup 传会导致注册完立刻反注册。 - 预设重名（与内置或彼此撞 id）时注册表会抛错：捕获后告警跳过，不让单个坏预设拖垮其余注册。
