feat(plugin): a package's prompts and themes reach Studio

Both were parsed by pluginpkg and went nowhere, while the docs said they
worked. A package's prompts are now discovered with its commands and invoked
the same way, /<plugin>:<name>, which is what the manifest documented. Its
themes are Studio theme packs: an entry names a pack's theme.json, and the
theme library lists it as plugin:<plugin>:<directory>, read in place from the
plugin root with its own images, never copied into the user's library, and
gone when the plugin is disabled. The retired desktop's .reasonix-theme
archives are not a format Studio reads, and the docs now say so.

The plugin docs are brought in line with the code: the Studio installer takes
a repository address or a folder (a .zip installs through the CLI), the routes
Studio drives replace a list of Wails methods that no longer exist, and the
protocol documents the panel and view surface kinds it already carries.
This commit is contained in:
yhh committed 2026-09-23 17:23:35 -07:00
1 parent de375d26a5
commit 2c7bde8710
13 files changed
+255 -54

No files matched your search

+8 -2
View File
@@ -110,8 +110,9 @@ Streams follow `extension/provider/stream/open` → `stream/chunk` →
## Structured UI
Extensions with the `ui` capability publish `status`, `card`, `form`, and
`notification` payloads (`host/ui/publish`) and ask questions
Extensions with the `ui` capability publish `status`, `card`, `form`,
`notification`, `panel`, and `view` payloads (`host/ui/publish`) and ask
questions
(`host/ui/request`: confirm, input, select, multiselect). Surfaces are
**structured only**: no HTML, CSS, JavaScript, remote scripts, arbitrary
frontend components, or uncontrolled URLs; Markdown renders through each
@@ -120,6 +121,11 @@ ID, surface ID, session ID, and runtime generation; stale-generation
updates are dropped so late results after a tab switch or reload can never
overwrite current state.
A `panel` holds a place in the frontend's side rail rather than scrolling
past in the transcript: re-publishing the same surface id updates what is
already on screen. A `view` is composed rather than filled in: its payload is a
tree of host primitives, for a shape the fixed kinds do not have.
Actions declared at initialize are namespaced `/<plugin>:<action>` and are
invoked via `extension/ui/action`; form submissions arrive via
`extension/ui/submit`.