Repository navigation
v0.4.5 — dsh peer 改为显式区间,内核 0.2.0-rc.1 下不再被跳过
0.4.5 (2026-09-29)
SSiD 的内嵌内核要从 0.1.7-rc.2 换到 0.2.0-rc.1,而本插件的 dsh peer 声明写成 caret 形式,
在那个内核上会被判为不兼容并跳过。本版修掉声明形态,并顺带把 README 逐条回源码核对了一遍。
修复
-
peer 区间在内核次版本进位后失效。内核
app-boot的plugin-compatibility.ts只挑
peerDependencies里的@deepseek-ai/dsh/@deepseek-ai/dsh-*条目,逐条按标准 semver
(includePrerelease: true)判。caret 作用在0.x上时上界被钉在次版本——^0.1.1-rc.1
展开即>=0.1.1-rc.1 <0.2.0-0,对0.2.0-rc.1判false;判定失败时插件被跳过,
不进 fiber graph,也不出现在「did not activate」列表里。dsh-client-connection与
dsh-host-apiproxy的 peer / dev 声明改为>=0.1.1-rc.1 <0.3.0:下限保持原值,上界抬到
0.3.0,下次次版本进位不必再改这一处。非dsh-前缀的@deepseek-ai/cordis与
cordis-plugin-loader不在该函数的检查范围内,未动。 -
README 三处与实现不符(判据全部来自源码,不是记忆):
- 系列成员清单只列了 14 项,而
shell/profile-template/package.json的dependencies与
dsh.profile.bundles里@max-null/*共 19 项——补dsh-allostasis、dsh-skills、
dsh-ssid-env、dsh-ssid-pwsh-retry、dsh-tone-layer。 - 社区市场只写了 awesome-dsh-plugin 与 Oh-My-DSH 两个源,实际
src/market.ts抓三个
(第三个是2BingLing/dsh-market),界面上的源选择器也是三项——补上。 - 删掉
## Part of the SSID family / SSID 系列成员这个空标题:ec6ad5d把该段移到
标题下第一段之后,标题下已无任何内容。
- 系列成员清单只列了 14 项,而
变更
- 顺带带上两条
v0.4.4之后未发出的提交:dsh-plugin-upgrade技能校正——profileDir拆成「精确 pin」与「link:」两套机制;写明
link:形态禁止pnpm add/update(那会把指向安装目录实体的 junction 变成 profile 自己的
独立副本,同一插件出现两份实体、版本分叉,而declared与installed两边都对得上,只有
重装时才暴露);决策树 §2 的判据改为去发版基准看该包是版本号还是file:./vendor/…;
新增「环境与内核版本」表。release-notes.md补 0.4.1 / 0.4.2 / 0.4.3 三条条目。
测试
- 真 semver(7.7.4)逐个核对改后的区间:对
0.1.7-rc.2与0.2.0-rc.1均satisfies = true。 - 全量 77 条通过(7 个文件);
pnpm typecheck无错。
验证
pnpm build重新产出client.js(119.7kb);dist/与client.js重建后与提交产物逐字节
一致(build 后git status无改动)。- 包内 skill
dsh-plugin-upgrade已核对,无需跟着本次内核升级改动:§环境与内核版本表里
SSiD 安装版一行本就只写装载形态、不写版本号,fork dev已记0.2.0-rc.1,0.1.5-rc.2与
0.1.7-rc.2分别是 web 副本与上游基准的当前值,均不受本次升级影响。
关于发布
npm 上的 @max-null/dsh-plugin-center@0.4.5 由用户手动 npm publish;本 tag 指向的提交
79bff17 即发布源。
关于此前几个 tag
v0.4.1 / v0.4.3 / v0.4.4 有 tag 但没有对应的 Release(Release 列表里目前只有 v0.4.0)。
本版不代补——补出来的说明只能凭 git log 反推,而三个 tag 的 message 已经把当时的情形写清楚了。