dsh-config-form

In the DSH plugin ecosystem, every plugin that exposes user settings tends to hand-roll the same four artifacts: a React form, an HTTP route with a hand-written security check, a storage decision (localStorage, a file, a sidecar service), and separate credential handling for secrets. A survey of twelve installed third-party plugins confirmed the pattern and explained why an auto-discovery design would have found almost nothing to render—the bottleneck was never the wire protocol, but the absence of a shared layer that lets authors declare fields instead of implementing them.

dsh-config-form fills that gap. It is a router and a renderer, not a framework: an adopting plugin calls declare with its field groups, types, and defaults, and the plugin handles rendering a single settings tab under Settings → Plugins, revision-fenced path-op writes (never a whole-section replace), compiling secret fields out of the schema and routing them to the credentials layer, and a shared endpoint guarded by loopback peer, loopback Host header, and same-origin provenance checks. Storage remains the author’s choice—pass a custom store to keep your existing approach, or omit it and let the settings seam hold values with layered resolution and external-edit reload.

It is intended for DSH plugin authors who need to expose a handful of configuration options without building a React form, a security-checked route, and credential plumbing from scratch. One declaration yields a settings experience consistent with the host, while ownership, id collisions, and unload cleanup stay within the declaring plugin’s fiber lifecycle.