Files
dsh-slopo/cordis.patch.yml
T
dsh-slopo agent 1b2ab3613f
Release / release (push) Successful in 6s
fix!: port the settings page and shell seam to dsh 0.1.7-rc.2
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.
2026-09-26 06:38:16 +01:00

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