Repository navigation
Releases
dsh-keys-setting v0.2.6 — 文档重构
dsh-keys-setting v0.2.5
审计收尾：把上一轮列出的剩余项处理掉。
修的内容
- dsh-keys-setting：共享
<style>不再由实例的 disposer 移除（第二个实例会跳过注入，第一个实例的
disposer 却把它删掉 → 行样式丢失到下次刷新）；把「settings.yaml 是文档化配置路径」的过时注释改对；
引擎默认值改用宿主返回的defaults（此前state.defaults写了没人读，UI 用的是另一份硬编码常量，
两边会漂移）。 - dsh-model-surplus：
toIsoOrNull真正支持秒级时间戳（文档早就这么写，代码没实现 → 一旦上游改用
秒，所有重置时间会显示成 1970 且没有任何报错）；删掉limitTooltip里两个分支完全相同的三元；
UA 不再写死版本号（此前写 0.3.1，包已经是 0.4.x）；给「pending 占位」补上说明它为何存在。 - dsh-gateway-models：
debugFile允许列表按引擎的方式解析 home（非空$DSH_HOME，否则~/.dsh）
—— 之前只读环境变量，而引擎从不设置它，于是文档化的<home>/logs/...被拒、<cwd>/logs/...反被接受；
重复了两次的 header-source 表达式抽成一个函数；补上「路由级 api/baseURL 会盖过每个模型自己的值」这个
事实的说明（这条是刻意保留的行为，见下）。 - 测试完整性：两个插件测试里未
await的check(...)补上（汇总数字此前少算，且未来异步断言会丢）。
一条我改了又改回去的（重要）
审计建议把 planRouteUpdate 写 baseURL 的条件收紧到「列表里所有模型都不在目录中」。我照做后发现
本插件自己的 V4.1 条目不带 baseUrl，而引擎只从目录条目解析 base?.baseUrl —— 目录里没有的模型
就只剩「路由级 baseURL」这一个来源。收紧后，混合路由上的 V4.1 模型会被引擎静默丢弃，正是这个插件
存在的意义。所以恢复原判据，并把取舍写进注释：路由级 api/baseURL 会盖过目录里各模型自己的值，
这在引擎提供不了「按模型」开关的前提下无法两全 —— 不写就丢模型，写了就改协议。
（引擎侧优先级已在源码核实：baseUrl = request.baseURL ?? base?.baseUrl ?? providerBaseUrl，
api = request.api ?? base?.api ?? routeApi，其中 request 是路由层。）
dsh-keys-setting v0.2.4 — 兼容性声明收窄到 0.2.0
审计修复
兼容性声明不再真实：本插件的读写路径已按引擎 0.2.0 的 SettingsForms API 重写
（get / section /
egister 已从引擎移除）。因此在 0.1.x 上它存不了设置，而清单却仍
声明兼容 0.1.x —— 那句已是假声明。现在收窄为：
"compatibility": { "node": ">=20", "dsh": ">=0.2.0-rc.2",
"dshReleases": { "0.2.0-rc.2": "compatible" } }并在中英 README 各加一节「引擎版本要求」说明原因与后果。
这一版只动清单元数据，运行时代码与 0.2.3 完全一致（0.2.3 已按新 API 重写，是真正的功能修复）。
环境要求
- DSH >= 0.2.0-rc.2、Node >= 20、零运行时依赖
安装 / 升级
dsh plugin --profile web add github:itchenshi/dsh-keys-setting或本 Release 的 tarball（dsh-keys-setting-0.2.4.tgz）。用 DSH Ready GUI 的话，随包版本已抬高
到 0.2.4，下次启动会自动换过来。
验证
本仓库
pm test：21 项通过。
dsh-keys-setting v0.2.3 — 改键设置在引擎 0.2.0 上重新生效
这一版是功能修复，不是文案
在引擎 0.2.0-rc.2 上，本插件此前是完全静默失效的：插件照常加载、路由照常在、
日志里什么都不说 —— 但改键设置怎么改都没用。
原因
引擎从 0.1.5 升到 0.2.0 时，settings 服务被换成了 SettingsForms：
旧：get(ns) / section(ns) / register(ns, Config) ← 全部移除
新：describe() / update(ns, patch, revision) / replace() / mutate() / configure()
本插件原来调 settings.register() 注册自己的命名空间，这个调用在 0.2.0 上抛错 →
apply 失败 → 路由根本没注册 → 设置页那一行还在，改它却毫无效果。
（三条独立证据：dsh-settings 的类型声明、全引擎 0 处旧调用、运行时探测的 404。）
修法
偏好现在就是本插件自己 row 的配置：
- 读：
apply(ctx, config)收到的字段是引擎交进来的 Volatile 引用，
每次用.get()读 —— 缓存下来就等于把偏好冻结在启动那一刻； - 写：
settings.update('composer-keys', patch, revision)，revision 先由describe()读出； cordis.patch.yml的插入行补了config: {}（实测没有它这个 entry 既不可描述也不可写）；- 调
settings.configure({ auto: false })，避免引擎再自动生成一个重复的设置页
（我们自带 Settings → 通用 那一行）。
顺带：settings.yaml 这个文档在 0.2.0 已被取消，可调值改为落在插件自己的 row config 里 ——
这正是引擎自带的 cordis-plugin-development 文档要求的口径。
环境要求
- DSH ≥ 0.2.0-rc.2（本版按该版本的 settings API 重写）
- Node ≥ 20
- 零运行时依赖（
dependencies为空）
安装 / 升级
dsh plugin --profile web add github:itchenshi/dsh-keys-setting或本 Release 的 tarball（dsh-keys-setting-0.2.3.tgz）。
用 DSH Ready GUI：随包版本已抬高到 0.2.3，下次启动 GUI 会自动换过来。
验证
- 本仓库
npm test：21 项通过（新增readPrefs用例，含「同一引用改值后再读必须
拿到新值」——防止有人把它缓存起来） - GUI 侧
verify:builtin运行时探测：/composer-keys由 404 变为 401，
即插件重新注册成功
dsh-keys-setting v0.2.2 — DSH 兼容性声明（范围 + 在跑的引擎版本）
只改清单元数据：把 DSH 兼容性声明补成「范围 + 在跑的引擎版本」
DSH STORE 的固定 commit 自动检查对同类插件报过一条
「DSH compatibility is not explicitly declared」。查下来原因是清单里只写了：
"dshReleases": { "0.1.5-rc.2": "compatible" }而本插件实际跑的引擎是 0.2.0-rc.2 —— 也就是说，清单里没有任何一条声明对应
「正在被审查的那个引擎版本」。
现在改为：
"compatibility": {
"node": ">=20",
"dsh": ">=0.1.5-rc.2",
"dshReleases": { "0.1.5-rc.2": "compatible", "0.2.0-rc.2": "compatible" }
}dsh是范围（商城建议的写法）：>=0.1.5-rc.2语义上覆盖 0.2.0-rc.2 及之后；dshReleases是逐版本证据，两端都有实测：0.1.5-rc.2 是此前长期在跑的引擎，
0.2.0-rc.2 是现在在跑的（verify:builtin第 4 幕就是在它上面启动引擎、四个插件
都在 bundle 列表里、ALL CHECKS PASSED）。不是猜的。
运行时代码一行没动，行为与前一版完全一致。版本号照常抬高，是为了让「声明的兼容范围」
能对应到一个确定的版本 —— 同版本改内容会让这个声明无从归属。
本插件的能力边界（便于静态审查）
- 运行时依赖：无（
dependencies为空）。 - 凭据 / 命令 / 原生制品 / 生命周期脚本：无。
- 详见 README 的「权限与边界」一节。
安装
dsh plugin --profile web add github:itchenshi/dsh-keys-setting或本 Release 的 tarball（dsh-keys-setting-0.2.2.tgz）。
dsh-keys-setting v0.2.1 — 去掉第三方运行时依赖（整改 DSH STORE 检查）
dsh-keys-setting v0.2.1
会话输入框的按键行为：让 Enter / Shift+Enter / Ctrl+Enter 各自「发送」还是「换行」。
从设置窗口的「通用」页直接改，默认与引擎一致。
这一版是回应 DSH STORE 固定 commit 自动检查（Catalog blocked）的整改。
🔧 去掉唯一的第三方运行时依赖
商城给的四条原因里，只有这一条确凿、且只属于本插件：它有运行时依赖。
四个随包插件里只有本插件的 dependencies 不空，依赖的是 npm 上非 scoped 的
schemastery；而引擎自己用的却是 scoped 的 @deepseek-ai/schemastery（3.18.4，
dsh-settings / dsh-llm-pi-ai 都 import 它）。两者同属 3.18.x、API 一致，但只有后者
随引擎而来：
- 它在
profiles/node_modules/@deepseek-ai/下，插件装到哪儿都解析得到； - 它与引擎设置服务拿到的是同一个模块实例，比换一个同名库更安全。
做法：改用引擎自带那份，并把 dependencies 整键删掉 —— 至此四个随包插件都没有
运行时依赖，清单也保持纯 ASCII。
验证（不是只看版本号）：
- 从两个真实数据目录的插件安装位置解析
@deepseek-ai/schemastery，均成功，
命中的都是引擎自己那份； - 用引擎那份 3.18.4 实构造本插件的
Config：默认值、type、dict、toJSON
与原来（3.18.0）完全一致。
📋 补上 DSH 兼容性范围
商城说「未声明 DSH 兼容范围」这条其实不成立（清单里一直有），但既然建议了范围写法，
就补上：
"dsh": {
"compatibility": {
"node": ">=20",
"dsh": ">=0.1.5-rc.2",
"dshReleases": { "0.1.5-rc.2": "compatible" }
}
}原有的 dshReleases 映射保留，不影响既有读者。
📁 另外两条「信号」的说明
- files 信号：代码里没有任何文件操作（无
node:fs）。偏好是经引擎自己的设置服务
间接写进settings.yaml，不是直接磁盘 I/O。 - network 信号：页面半边那次
fetch打的是同源路由（在引擎自己的信任围栏之后），
不产生对外流量、不携带凭据。
🧪 一次性 Profile 的安装 / 启动 / 卸载证据
商城明确要求这一项。三环都跑过（每次都在临时数据目录里，不碰你的数据）：
| 环节 | 做法 | 结果 |
|---|---|---|
| 安装 | staging 出磁盘目录 → 引擎自己的 dsh plugin --profile web add file:… |
装成功，node_modules/dsh-keys-setting/ 落地并登记进 profile |
| 启动 | 同一 profile 启动引擎（dsh web --no-open --port 0） |
引擎正常起来，四个插件都在 bundle 列表里 —— 宿主编译期真的 import 了本插件（含 schema 库） |
| 卸载 | 引擎自己的 dsh plugin remove + 摘除 profile 登记 |
干净移除：bundle 登记、dependencies、catalogStatus 三者都不留痕 |
安装与启动由 verify:builtin 第 1-4 幕覆盖；卸载此前只是被通用用例间接覆盖，
这一版在 verify:builtin 新增第 7 幕，对本插件显式断言：
- bundle 登记里没有了；
dependencies里也没有了（留下file:依赖会让引擎下次启动把它 reconcile 回来）；catalogStatus报未安装（设置窗口会显示成未装）；- 另外三个随包插件不受影响。
📦 安装
# 推荐：直接从 GitHub 装（记进 profile，之后可跟着更新）
dsh plugin --profile web add github:itchenshi/dsh-keys-setting
# 备选：本 Release 的 tarball（git 协议走不通、但 HTTPS 能通时用这条）
dsh plugin --profile web add https://github.com/itchenshi/dsh-keys-setting/releases/download/v0.2.1/dsh-keys-setting-0.2.1.tgz⬆️ 升级
- 用 DSH Ready GUI：随包版本已抬高到 0.2.1，下次启动 GUI 时会自动重装，不需要手动操作。
- 自己装的：按上面任一命令重装即可。偏好值存在
settings.yaml的composer-keys段里，
重装不丢。
✅ 验证
- 本仓库
npm test：20 项通过 - GUI 侧
npm run verify:builtin：ALL CHECKS PASSED（含新增的卸载一幕） npm test（GUI 全量）：全绿
dsh-keys-setting v0.2.0
Configures whether Enter, Shift+Enter and Ctrl/Cmd+Enter send the message or insert a line break.
- Lives in Settings -> General
- The engine default is kept until you change it, so installing alone changes nothing
- Detects the composer using the engine's own marker rather than guessing class names, so sidebar editors are unaffected
- Does not interfere with IME composition
Install: dsh plugin --profile web add github:itchenshi/dsh-keys-setting