One entry in PluginInfoResult.parameters — a user-configurable setting shown in
the plugin's settings UI. The host persists one value per declared parameter (GET/
PUT /plugins/settings?namespace=..., lanrurugi-api::plugins::plugin_settings_key, Redis
field customargs) and passes the whole array back on every call, positionally matching this
array (parameters[0]'s saved value is hostArgs.customargs[0], etc. — see
MetadataHostArgs.customargs), each element already in its own declared type — a bool parameter's value arrives as a real boolean, never a string a plugin has to
parse back out itself. Distinct from PluginInfoResult.oneshot_arg, which is a single
value typed fresh into a "run once" dialog each time, not persisted here.
name: string
description: string
required: boolean
type: "string" | "bool" | "int"
Matches legacy's own param.type (~/LANraragi/templates/plugins.html.tt2's SWITCH param.type — 'string' → a text input, 'bool' → a checkbox/switch, 'int' → a number
input). Missing entirely before this — every converted plugin's parameters rendered as a
plain, unstyled text input regardless of their real semantics, including boolean toggles like
plugins/metadata/mems.ts's own 3 params (real legacy MEMS.pm declares all 3 as type => 'bool', rendered as ON/OFF switches — a plain blank text box here was a real, visible
mismatch). Legacy's own unmatched-SWITCH fallback renders a type="color" picker (its
source literally comments this default "ayy lmao" — an unintentional quirk, not a real 4th
parameter kind any real plugin in this corpus uses); this SDK deliberately defaults absent
type to 'string' instead, since every one of this corpus's 31 plugins with declared
parameters had none of this field before now and were already correctly rendered/used as plain
text inputs — matching legacy's silly color-picker default would have turned every one of
those already-working parameters into a broken control instead of leaving them unaffected.