plugin-settings

Placement	compiled-in (in-process)
Source	github.com/opencharly/plugin-settings/candy/plugin-settings
Version	2026.181.0001
Candy	plugin-settings

This plugin is listed in charly/charly.yml’s compiled_plugins:, so its providers are compiled into the charly binary and register in-process.

Providers

The reserved words this plugin serves:

• settings — command class

What it does

COMPILED-IN charly COMMAND-class plugin that OWNS the externalized charly settings CLI — the runtime-configuration surface. The plugin owns the command end to end: the get/set/list/reset/path subcommand grammar (command.go runSettingsCLI) and the output formatting. No plugin-specific command LOGIC is left in core.

This plugin OWNS its entire config subsystem — read/write the runtime config file ~/.config/charly/config.yml (GetConfigValue / SetConfigValue / ListConfigValues / ResetConfigValue / RuntimeConfigPath) + the runtime-engine resolution — directly in config.go (ported from charly/runtime_config_values.go + charly/host_build_settings.go), as almost-entirely-pure kit.LoadRuntimeConfig / SaveRuntimeConfig file I/O + validation. The get special-cases live here too (engine.* resolved via kit.ResolveRuntime; secret_backend via the resolved credential store), in resolveSettingsGet. The THREE credential-store touches (vnc.password.* get/set/delete + secret_backend reset/name) dispatch verb:credential DIRECTLY via InvokeProvider — the same plugin-side pattern candy/plugin-pod/enc_cmd.go proves. The “settings” HostBuild seam (charly/host_build_settings.go) is RETIRED: the plugin already holds a real reverse-channel *sdk.Executor at Invoke(OpRun), so there is nothing left for core to do. This is the same “plugin owns the command AND its logic” doctrine the vm + pod deploy plugins established.

settings is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand (“Seam A”) — for its verb:credential InvokeProvider calls. The out-of-process CliMain path has no reverse channel, so it errors: settings cannot run out-of-process. There is NO hidden core-command forward and NO core config seam — the plugin does the config I/O itself, reaching only verb:credential over the reverse channel; no core symbol crosses the boundary, no ad-hoc podman.

command:settings dispatches through the COMPILED-IN registry path (registerCompiledPlugin → resolve(ClassCommand,“settings”) → dispatchInProcCommand → Invoke(OpRun) with the threaded in-proc reverse channel), so NewMeta advertises command:settings while the served CUE schema carries no plugin_input (the args are plain CLI tokens). The R10 witness is the disposable check-commands-local bed: charly settings list exits 0 and lists the resolved runtime-config keys, proving the externalized command + its plugin-owned config I/O end-to-end.

Parameter schema

The CUE schema below is the authoritative grammar for this plugin’s input. It is the same single source that generates the plugin’s Go parameter types and answers the runtime Describe RPC, so this page cannot disagree with either.

schema/settings.cue

// plugin-settings's OWN self-contained CUE schema — the SINGLE SOURCE for this plugin's
// served declaration surface (there is no schema-less plugin: every plugin ships a
// non-empty schema over Describe).
//
// SELF-CONTAINED and PACKAGE-LESS: it references no base def and carries no package
// clause, so it compiles STANDALONE — the property the SDK's serve-side compile needs
// and the property that lets the host splice `base ++ plugin` at the load gate
// (registerPluginUnitSchema); a self-contained schema that will not splice is a LOUD
// load failure.
//
// NO GO CONSUMER: the plugin declares no typed `plugin_input` (its authored input is
// its pass-through CLI grammar), so this schema generates NO `params` package and has
// NO `cue exp gengotypes` artifact — it is the SERVED documentation/config surface,
// not a code-generation source.
//
// It DOCUMENTS the `command: settings` contract and the subcommands its grammar owns.
#SettingsPlugin: {
  // The command word the plugin serves.
  command: "settings"

  // What the command does, in one line (the public-docs surface).
  contract: string & !=""

  // The subcommands the plugin's grammar owns.
  subcommands: ["get", "set", "list", "reset", "path"]
}

---

See also the candy reference for this candy’s install surface.