Skip to content

v0.3.2 — DSH 0.1.7 support and automatic legacy-data migration

Choose a tag to compare

@hytime hytime released this 23 Sep 12:29
· 106 commits to main since this release

变更 / Changed

  • 发布前的兼容矩阵新增 dsh-v0.1.7-alpha.1(entry-config 设置模型)作为第五个官方能力代表,0.1.7 根节点上会验证插件确实加载成功、其设置分区被发布,以及宿主的三条行为(llm-pi-ai 的 providers 仍为 volatile;路径写入仍基于用户原始层;默认档位补齐自己的写入能够落盘)。
  • The pre-publish compatibility matrix adds dsh-v0.1.7-alpha.1 (the entry-config settings model) as a fifth official capability representative; the 0.1.7 root verifies that the plugin loads, that its settings section is published, and that three host behaviours hold (llm-pi-ai's providers stays volatile; a path write is still derived from the raw user layer; the provider-defaults fill's own write lands).
  • 修复 0.1.7 上默认档位补齐无法写回的问题:该版本把设置变更事件放在写入事务内部触发,插件在事务里再发起写入会被宿主以 HMR transactions cannot be nested 拒绝,而事务上下文会随 AsyncLocalStorage 传播到任何延迟调用。补齐现在从一个在插件加载时创建的执行上下文中发起写入,因此新增模型时会正常补上默认档位,无需重启。
  • Fix the provider-defaults fill being unable to write back on 0.1.7: that release raises the settings-change event from inside its own write transaction, so a write started from the listener is refused with HMR transactions cannot be nested — and the transaction context travels with AsyncLocalStorage into anything the listener defers. The fill now starts its write from an execution context created while the plugin is applied, so a newly added model gets its default levels without a restart.
  • 默认档位补齐改为只写入用户层:由组合 base 或 schema 默认值提供的模型不会被补全(0.1.7 的 entry-config 设置服务会把整棵解析后的子树落盘,为它们补全会把 input、compat、headers、thinkingBudgets、defaultContextWindow 等 schema 默认值钉进你的设置文档)。跳过的模型会在宿主日志中报出数量。
  • The provider-default fill now writes through the user layer only: a model a composition base or a schema default supplies is left unfilled (under the 0.1.7 entry-config settings service a resolved subtree lands on disk whole, so filling those models pinned input, compat, headers, thinkingBudgets, defaultContextWindow and other schema defaults into your settings document). The Host logs how many models it skipped.

新增 / Added

  • 设置页新增「会话值生成器」卡片,可在 UI 中读写 opencodeSession.format 的全部字段(生成模式、时间戳来源、模板 / 表达式 / 脚本路径、校验正则与校验失败策略),无需再手写设置文档。卡片按当前模式只显示相关字段,并在写入前校验:非法正则、空模板 / 表达式 / 脚本、相对脚本路径,以及无法解析或引用了不存在名字的表达式,都会被拦下并给出原因——这些取值在宿主侧会静默退化(正则失效为「不校验」、其余回退为派生值),UI 里看不到就会误导。表达式校验与宿主共用同一份解析代码。写入按字段进行,不覆盖同命名空间的其他配置。

  • Add a "Session value generator" card to the settings page that reads and writes every opencodeSession.format field (mode, timestamp source, template / expression / script path, validation regex, and the on-invalid policy), so the settings document no longer has to be edited by hand. The card shows only the fields the current mode uses and validates before writing: an invalid regex, an empty template / expression / script, a relative script path, and an expression that does not parse or names something that does not exist are refused with a reason — each of those silently degrades on the Host side (the regex to "no validation at all", the rest to the derived value), so leaving them invisible in the UI would mislead. Expression validation shares one parser with the Host. Writes are field-level, so nothing else in the namespace is overwritten.

  • 支持 DSH 0.1.7 的 entry-config 设置模型:插件现在导出根节点 .volatile() 的 Config,设置页表单才能在该版本上出现(此前插件在 0.1.7 上会以 register is missing 加载失败)。0.1.7 及以后设置分区使用 Loader 条目 ID thinking-effort,0.1.0-rc.7 至 0.1.6 仍使用注册的 namespace dsh-thinking-effort,客户端按宿主实际发布的那一个解析。subagentEffort 随之迁入本插件自己的设置分区;在 0.1.7 上旧的 llm-pi-ai 位置既不可写也不可读(该 schema 只声明 providers,写入其他路径会被整批拒绝,用户层投影也会丢掉未声明的键),所以升级前设在那里的默认值会显示为未设置,需要在插件设置卡片里重新选择。导入旧快照时插件会把 llm-pi-ai 里的这个键迁移到自己的分区,同一批次的 providers 也才能被接受。0.1.7 及以后的设置保存在当前 profile 的 cordis.patch.yml,而不再是 ~/.dsh/settings.yaml(0.1.7 会重命名旧文件并尝试导入;对这个分区而言该导入会被拒绝并只留下警告,旧值仅保留在 settings.yaml.imported 中)。

  • Support the DSH 0.1.7 entry-config settings model: the plugin now exports a root-.volatile() Config, which is what makes its settings form appear on that release at all (before, the plugin failed to load there with register is missing). On 0.1.7+ the settings section is the Loader entry id thinking-effort, while 0.1.0-rc.7 through 0.1.6 keep the registered namespace dsh-thinking-effort, and the Client resolves whichever the running host publishes. subagentEffort moves into this plugin's own settings section; on 0.1.7 the old llm-pi-ai location is neither writable nor readable (that schema declares only providers, so a write to any other path is refused for the whole batch and the user layer drops undeclared keys), which means a default set there before the upgrade reads as unset and has to be chosen again in the plugin's settings card. Importing an older snapshot migrates that key out of llm-pi-ai into the plugin's own section, which is also what lets its providers import. Settings are now stored in the active profile's cordis.patch.yml instead of ~/.dsh/settings.yaml, which 0.1.7 renames and tries to import; for this section that import is refused with only a warning, so the old value survives in settings.yaml.imported alone.

  • 新增旧数据自动检测与迁移:DSH 0.1.7 把 settings.yaml 重命名并只导入一次,而旧版本插件在该版本上加载失败,因此你此前的思考档位与模型开关只留在 settings.yaml.imported 里。插件现在会在启动时扫描该文件(以及尚未重命名的 settings.yaml 与活的 llm-pi-ai 用户层),发现可迁移项后在设置页上方弹出询问,你确认后才把这些旧数据值写入插件自己的设置分区。迁移只补齐你尚未设置的值,绝不覆盖;写入前会先把当时的设置存进「配置备份与方案」的回滚槽(autoBackup,来源标记为 migration),且快照与迁移值在同一批写入中落盘,因此不会出现「有快照却没有迁移」的中间状态。选择「不再询问」后,仅当旧数据发生变化才会再次提示。

  • Add automatic detection and migration of stranded legacy data: DSH 0.1.7 renames and imports settings.yaml exactly once, and older plugin releases failed to load on that version, so a user's thinking levels and model toggles survive only inside settings.yaml.imported. On startup the plugin now scans that file (plus a not-yet-renamed settings.yaml and the live llm-pi-ai user layer) and, when it finds migratable values, asks above the settings page before writing any of those legacy values into its own settings section. The migration only fills in values you have not set and never overwrites; before writing it saves the then-current settings into the Backup and profiles rollback slot (autoBackup, marked sourceProfile: migration), and the snapshot rides the same write batch as the migrated values, so there is no state in which a rollback copy exists without the migration. After you choose not to be asked again, it re-prompts only when the legacy data changes.

修复 / Fixed

  • 修复两处只有真实宿主才会暴露的问题:迁移成功后弹窗不关闭(宿主尚未落地时的一次读取把提示重新打开,而重新打开后就不再轮询,于是过期候选与可用按钮一直留在屏幕上);以及重启后对已迁移的值重复提示(宿主自己的分区尚未发布时扫描,declared() 看到的用户层为空,于是整批又被当作未迁移)。
  • Fix two problems only a real host exposed: the prompt not closing after a successful migration (a read taken before the host had acted reopened it, and a reopened prompt stops polling, so stale candidates and live buttons stayed on screen), and a restart re-offering values that were already migrated (a scan taken before the plugin's own section was published saw an empty user layer, so declared() treated the whole set as unmigrated).