dsh-model-priority
自定义模型/提供方顺序：侧边栏拖拽排序，宿主的模型列表按这份顺序返回
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:mengge237/dsh-model-priority#6bf898656233d4606d59404e6d831346a0d21268Model Priority 以 dsh-model-priority 发布，当前版本为 0.2.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
自定义模型 / 提供方的排列顺序。宿主的模型选择列表按适配器注册顺序排，常用的模型 常常排在后面；这个插件让你在侧边栏里拖一下就把它顶到前面去。
右侧栏多一个「模型排序」页面（better-sidebar 的 tab，设置页「侧边卡片」里有对应开关）。 页面上半是提供方列表，下半是选中提供方下面的模型列表，两边都能按住拖动。点「保存」 写盘，点「恢复默认」清空顺序回到宿主原样。
~/.dsh/model-order.json，纯数据，可以手改，删掉就回默认。ctx.llm 的实例属性上包一层，让这三个方法按这份顺序返回：
listProviders()、listConfigurableProviders()、listModels(provider)。
排序是稳定排序：没被点过名的条目保持原来的相对位置，所以只调两个不会搅乱别的。Reflect.get(活实例, 'listProviders')
（dsh-api-gateway 的 prepareInvocation），own property 优先，所以这一处改动
同时覆盖直调方与远端两条路。模型选择对话框走的 session/modelCatalog 链内部
同步调 ctx.llm.listProviders()、异步调 ctx.llm.listModels()，都在这条路上。listProviders / listConfigurableProviders 的替换必须是同步函数。
宿主 buildModelCatalog 同步调用它，返回 Promise 会在紧接着的
providers.map(...) 上炸掉，模型选择对话框直接打不开。listProviders() 收 0 个，
listModels(provider) 收 1 个。GET /dsh-model-priority/state.json —— 目录快照 + 当前顺序 + 挂钩状态PUT /dsh-model-priority/order.json —— 保存（{"reset":true} 清空）两条路由不走浏览器鉴权，所以不登 GUI 也能直接 curl 验。
| 文件 | 什么时候 | 怎么收拾 |
|---|---|---|
~/.dsh/model-order.json | 每次点「保存」 | 删掉就回默认 |
~/.dsh/settings.yaml | 点「保存」并同步宿主时 | 写之前先备份成 settings.yaml.bak-<时间戳>；只重排对应提供方 models 数组的顺序，其它键一个都不动 |
~/.dsh/model-priority-proxy.json | 只有启用下面那个轮换代理才会创建 | 删掉即停用 |
为什么连 settings.yaml 也要写：宿主是拿 settings 里 models 数组的顺序来渲染模型列表的（设置页与选择器都看它）。
只在读的时候排序，会出现「设置页一个顺序、模型选择器另一个顺序」，两套顺序来源必然打架。所以写盘这一边是刻意的 ——
也正因为如此，写之前必须备份。
dsh plugin --profile web add "<本仓目录，或 git 地址>"
dsh plugin --profile web remove dsh-model-priority
「模型排序」这个页面挂在 dsh-better-sidebar 的侧边卡片位上（设置页「侧边卡片」里有开关）， 没装 better-sidebar 时页面不挂载，但下面那两条 HTTP 路由照常可用。
装完要重启 dsh web：服务端半边（注册路由、挂钩）与浏览器侧半边（进 boot 图的 combo） 都是启动时装配的，只有重启才生效。顺序文件是每次调用现读的，改它不用重启。
npm test
三个脚本，都不启动 dsh、不碰 3080 端口：
test/selftest.mjs —— 数据层：顺序文件的读写与清洗、稳定排序的边界
（名单里有不存在的 id、缺 id、空名单、原数组不被就地改动）。test/server-routes.mjs —— 服务端半边端到端：拿假 ctx（假 webServer + 假 llm）
把两条路由真跑一遍，验状态码、排序真的作用到 listProviders / listModels /
listConfigurableProviders、坏 body 回 400、不支持的方法回 405、
同步契约、以及重复 apply 不套第二层挂钩。test/client-smoke.mjs —— 浏览器侧半边：用假 window.__ModuleLoader__ 与假 react
把 bundle 跑一遍，验模块 id、只 require react、注册的描述符字段、icon 是内联 svg。ctx.llm 真的暴露上述方法的宿主版本上生效；挂不上时 state.json 的
hook.ok 会是 false 并带上原因，页面顶部会把原因显示出来，顺序文件仍然可编辑。~/.dsh/settings.yaml 里对应提供方的 models 数组（写前自动备份，见上）。卸载后 model-order.json 与代理配置留在 ~/.dsh 下，手动删。settings.yaml 里 provider 的键顺序来排序不可靠：宿主的
registrationFacts 会对 provider 做 sort 来判断"是否变化"，单纯调键序不触发
replace，运行中不会立刻生效，而且被 replace 的那批路由会被挪到 Map 末尾。
要固定顺序就用这个插件。dsh-model-router 一类，用量统计看 dsh-provider-usage 一类），
塞进一个插件里最容易互相打架。包内另有一个小的本机转发层：把某个 provider 的 baseURL 指到本插件的 rotate 端点，
它会在 .credentials.yaml 里的多把 key 之间依次试（429 / 额度尽那类响应才换）。
~/.dsh/model-priority-proxy.json），不知道 token 一律 403 ——
插件路由不走浏览器鉴权，不设这道门等于本机任何进程都能拿你的密钥刷额度；dsh-model-router 那类插件比过再决定用哪个。