Release / release (push) Successful in 6s
0.1.7-rc.2 moved four things this bundle was built on, and every one of them
failed quietly rather than loudly, so the plugin looked installed and did
nothing:
* `ctx.settings.installSection(...)` is gone. The call threw into a
`try/catch` that only logged a warning, so the settings namespace was never
registered and `configure` had nowhere to persist. An entry's exported
Config IS the form now; the namespace is the Loader entry id the bundle's
patch declares, and `ctx.settings.configure({ auto: false })` is what claims
that entry's own page.
* `settingsScope` and the `settings.plugin.item` slot are gone. The card
registered into both, so it never rendered — the tab draws the intersection
of served namespaces and registered cards, and that intersection was empty.
It now registers into `plugins.bundle.config` keyed by the bundle's package
name, over the `configForms` service, and uses the framework's own form
chrome (`SettingsFormModel` / `SettingsForm` / `SettingsValueField` /
`SettingsSecretField`) instead of the hand-rolled equivalent. A save is one
revision-fenced write.
* `ctx.shell.run(spec)` is gone. Every action that runs a command threw
`shell.run is not a function`; the seam is now
`await ctx.shell.execute(ctx.shell.resolve(request)).result()`.
* A job's `owner` is a session id, not the agent object. The wrong owner
registered a job no session could collect or cancel, and the producer's
`done` resolved `output` where the registry reads `result`, so a finished
job handed back nothing.
Two conformance gaps went with them: a Config field that is not marked
`volatile()` is invisible to every settings UI — the form projection keeps only
volatile fields, and an entry with no form is dropped from `settings.describe`
entirely — and `embeddingApiKey` was a plain field, so the key rode every
settings read back to the browser. It is `role('secret')` now: the browser is
told whether a key is stored and never receives the key.
Also declares the `@deepseek-ai/dsh-*` peerDependencies the compatibility gate
reads, so an incompatible runtime refuses this plugin at startup instead of
half-loading it.
Verified against a real 0.1.7-rc.2 boot: `settings.describe` serves the entry
with `autoGenerate: false`, the key redacted and reported only as `set: true`,
and no startup diagnostics. The host mock in the tests now has no `run` and no
`installSection`, so those seams are contract-tested rather than assumed, and
the browser tests read the installed harness's own slot catalog and package
exports — a rename fails a test instead of quietly emptying a page.
26 lines
1.3 KiB
YAML
26 lines
1.3 KiB
YAML
# The layer this bundle contributes to a dsh profile that lists it.
|
|
#
|
|
# One row: the dsh-slopo host plugin. It contributes three things —
|
|
# * three skills on `ctx.skills`, all user-invocable and NOT model-invocable
|
|
# (slopo's own agent configs make the same choice, because every one of
|
|
# these commands can spend minutes embedding);
|
|
# * the `dsh-slopo` configuration, which is this plugin's own exported Config:
|
|
# since dsh 0.1.7-rc.2 the framework projects that schema onto this entry and
|
|
# addresses it by `id`, which is why the id below is also the browser card's
|
|
# slot key. It is editable at runtime rather than baked into this file;
|
|
# * one `slopo` tool that resolves the CLI, runs it, and streams progress.
|
|
#
|
|
# The row references the package by NAME rather than a relative path, so Node
|
|
# resolution finds the installed copy — see the dsh publish docs.
|
|
#
|
|
# There is deliberately NO `config:` block here. Every value the plugin needs is
|
|
# either discovered at runtime (the slopo binary), set by the user through the
|
|
# settings card or the tool's `configure` action, or genuinely optional. Shipping
|
|
# defaults would mean baking one machine's paths into a layer that other machines
|
|
# also apply, and the plugin's own schema already carries the defaults it can
|
|
# honestly claim.
|
|
|
|
- insert:
|
|
- id: dsh-slopo
|
|
name: dsh-slopo
|