Skip to content
OpenCharly

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

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

Section titled “Providers”

The reserved words this plugin serves:

  • status — command class

What it does

Section titled “What it does”

COMPILED-IN charly COMMAND-class plugin that OWNS the externalized charly status CLI — the runtime-status surface (table / detail / JSON, –all, –nested). The plugin owns the command end to end: the Kong grammar (command.go, moved from charly/status.go’s StatusCmd), the declared-nested-tree pre-resolution (nested_tree.go, K5, relocated from charly/status_nested.go’s buildStatusRootsTree — every dependency it once claimed core-coupled, DeployConfig/ResolveDeployChain/ClassifyTarget/ LoadDeployConfig, is sdk-portable), the PURE nested-deployment overlay fold (overlay.go, ported from charly/status_nested.go’s applyNestedOverlay/buildNestedChildren/ nestedChildStatus/claimFlatRow), and the render output (render.go, moved verbatim from charly/status_render.go). No plugin-specific command LOGIC is left in core.

The ONE thing the plugin cannot do itself is the LIVE collection engine — fan out across every deployment substrate (pod/vm/kubernetes/local/android) and probe live tools. That engine now lives in candy/plugin-substrate (status_flat.go’s flatCollector, K6 — the former charly/status_collector.go, whole-file moved; the earlier “stays core, registry-boundary blocker” verdict on it was reopened and reversed) and is reached via InvokeProvider(verb:status-fanout) DIRECTLY over the in-proc reverse channel (spec.StatusSubstrateRequest{Single,IncludeAll,Box,Instance} → spec.StatusSubstrateReply{Rows,Single}) — narrowed (K5) to drop Nested/Roots now that the declared-tree resolution is plugin-side. The former “status-substrate” HostBuild seam + charly/status_substrate_host.go are DELETED (K-wave 2): the wire broker’s in-proc InvokeProvider branch now threads the reverse channel onward to the fan-out generically, so the fan-out’s vm/kubernetes collectors reach the host for themselves. This is the same “plugin owns the command + a generic seam for the core-coupled bits” doctrine candy/plugin-settings established.

status 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”) — to InvokeProvider(verb:status-fanout). The out-of-process CliMain path has no reverse channel, so it errors: status cannot run out-of-process, it needs the in-proc reverse channel for the fan-out. There is NO hidden core-command forward — the plugin does the work directly, calling back only for the live-collection engine it can’t run itself; no core symbol crosses the boundary, no ad-hoc podman.

The plugin ALSO serves sdk.OpStatusCollect — the programmatic status-collection API (distinct from the lifecycle OpStatus a substrate plugin serves): InvokeProvider (verb:status-fanout) → the PURE overlay → the overlaid []spec.DeploymentStatus as ResultJson (no render), reachable by any in-process peer via InvokeProvider(class:command, word:status, op:status-collect).

command:status dispatches through the COMPILED-IN registry path (registerCompiledPlugin → resolve(ClassCommand,“status”) → dispatchInProcCommand → Invoke(OpRun) with the threaded in-proc reverse channel), so NewMeta advertises command:status while the served CUE schema carries no plugin_input (the args are plain CLI tokens). The overlay’s byte-parity is proven by the candy’s OWN overlay_golden_test.go; the host collection engine’s parity by the plugin’s TestCollectPodLiveGolden (candy/plugin-substrate/status_test.go) — the relocated pod-live transform golden (P14a, moved from charly/status_golden_test.go).

Parameter schema

Section titled “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/status.cue

Section titled “schema/status.cue”
// plugin-status'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: status` contract. The concrete flags/config live in the CLI grammar; this schema declares the command word + its contract.
#StatusPlugin: {
  // The command word the plugin serves.
  command: "status"


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


}

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