v1.5.0 - DSH 0.2.0 peer window

DSH 0.2.0 compatibility

@deepseek-ai/dsh-app-boot pre-flights every profile row before loading it:
evaluatePluginCompatibility() tests each @deepseek-ai/dsh / @deepseek-ai/dsh-* peer
against the running runtime with includePrerelease, and disables the whole row when one
fails. The pinned 0.1.7-rc.1 || 0.1.7-rc.2 therefore excluded the 0.2.0 line.

This release declares >=0.1.7-rc.1 <0.3.0 for @deepseek-ai/dsh. The window spans the
0.1.7 line and the whole 0.2.0 line; a caret range cannot express it, because any
0.1.x range stops at <0.2.0. No runtime code changed.

Verified against dsh 0.2.0-rc.2 with the host's own gate, an end-to-end dsh plugin add,
and a 20-check host-half smoke test.

Published to npm via Trusted Publishing (OIDC), with provenance.

v1.4.0 — DSH 0.1.7-rc support, time bars, GitHub Packages

First release of the fork Astervolans/dsh-opencode-go-usage, published as the scoped package @astervolans/dsh-opencode-go-usage — and the first release here to publish automatically, to GitHub Packages.

Upstream yumusb/dsh-opencode-go-usage publishes the unscoped dsh-opencode-go-usage; that name belongs to upstream, so this fork publishes under its own scope.

Install

dsh plugin --profile web add @astervolans/dsh-opencode-go-usage

Then store your GO API key as OPENCODE_GO_API_KEY in ~/.dsh/.credentials.yaml and restart dsh web.

1.4.0 — DSH 0.1.7-rc compatibility

DSH 0.1.7-rc replaced the settings service with SettingsForms, removing register()/get(). The old call threw inside apply(), and the loader then wrote the entry back with disabled: true, so the plugin silently stayed off:

dsh: warning: 1 entry did not activate dsh-opencode-go-usage
(@astervolans/dsh-opencode-go-usage): TypeError ctx.settings.register is not a function

• Config seam — ctx.settings.register(...) / ctx.settings.get(...) are gone. The loader consumes the exported Config and passes the validated config as apply(ctx, config).
• Reading other plugins' config — locale / llm-pi-ai are read through ctx.loader.entries() + entry.fiber.config, unwrapping cosmokit volatile references, with a fallback to this plugin's own defaults so load order cannot disable it.
• Browser half — composed by the official client-modules scan from the package's dsh.client declaration and exports["./client"]. The 1.x self-hosted bundle route and webServer.tapIndex injection were removed, because 0.1.7-rc turned window.__DSH_BOOT__ from an array into a { rev, entries, batches } object that must come from client-modules alone.
• Volatile guard — .volatile() needs schemastery ≥ 3.18.4, and a profile can still hoist 3.18.2. It is now probed before use, so an older copy activates normally (minus the settings page and hot edit) instead of aborting.
• Compatibility declared — peerDependencies pins "@deepseek-ai/dsh": "0.1.7-rc.1 || 0.1.7-rc.2", so an unlisted runtime fails loudly instead of half-working. The pre-0.1.7 line is served by 1.3.3; anything else can be exempted with dsh plugin allow-version.

Also in this release

• 1.3.3 — the scoped rename had missed two runtime identifiers: cordis.patch.yml's name (the module specifier the loader imports, which made dsh web abort with Cannot find package 'dsh-opencode-go-usage') and the browser bundle's __ModuleLoader__.load({ id }), which client-modules checks against the package name. Both are fixed. The id, settings namespace, HTTP routes and /opencode-go command name stay unscoped, so migrating from upstream needs no configuration change.
• Time bars — under each usage bar: gray is time elapsed, blue is time remaining. The blue segment uses --dsw-static-deepseek-450 (#5686fe), a real brand blue; the previous --dsw-alias-brand-primary is a neutral token that rendered white in dark mode.
• Official packages as peers — @deepseek-ai/schemastery moved from dependencies to peerDependencies, so the copy DSH itself ships is used and no duplicate lands in the profile.
• GitHub Packages publishing — release-package.yml publishes on release: created with the workflow's GITHUB_TOKEN, and re-running an already-published version is a no-op. This is the first automatic publish path for the fork: the inherited npm-publish.yml is an explicit no-op here, because npm trusted publishing is bound to the upstream repository and a fork is not in its allow-list.

Releases to npmjs.org remain manual — see docs/RELEASE.md.

Full diff: v1.3.2...v1.4.0