The plugin's self-described settings JSON Schema, read from the SIGNED manifest's `settings_schema` field, which works for every plugin kind (store/secret/auth/hook), not just hooks. `hook` plugins keep the live describe-proxy behavior when describe answers (source: describe); a loaded hook whose describe answers null falls back server-side to the manifest baseline (source: manifest)

The plugin's kind (hook | secret | …) from its manifest. Both GET /plugins/{file}/schema and POST /plugins/inspect emit it (null only when the plugin cannot be resolved to a manifest). Declared so codegen'd clients keep it.

The kind-derived restart-scoping default (busbar_plugin_sign::kind_restart_default), so busbar-ui need not hardcode the kind→default table. Emitted by both schema endpoints (null only when the plugin has no resolvable manifest/kind). Declared so codegen'd clients keep it.

Set only when the manifest's settings_schema was present but failed to parse as JSON; null for a manifest that genuinely never set the field. Never collapsed into a bare schema: null: a present-but-corrupt schema is a real authoring/packaging bug, not "this plugin simply has none."

"describe" when a currently-loaded kind: hook answered its live describe wire message (the existing describe-proxy behavior, unchanged); "manifest" otherwise. Lets busbar-ui explain "why does this form look different from what I expected" without implementing the describe/manifest precedence rule itself.

"trusted" | "unverified" | "rejected": the same vocabulary the plugin catalog already uses (never "verified").

The plugin's semantic version from its manifest. Present on POST /plugins/inspect (which previews an on-disk candidate's manifest); null/absent on GET /plugins/{file}/schema, which does not surface the version. Declared here so a codegen'd client keeps the field the inspect handler always sends, rather than silently dropping it.