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).
See also the candy reference for this candy’s install surface.