plugin-status
| Version | 2026.194.1600 |
| Repo | superproject |
| Plugin | yes — see the plugin reference |
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, BundleConfig/ResolveDeployChain/ClassifyTarget/
LoadBundleConfig, 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/k8s/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 the generic “status-substrate” HostBuild seam (charly/status_substrate_host.go, now a THIN forward to verb:status-fanout — 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. “status-substrate” is a class-generic action noun, not a provider word (F11). 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 call HostBuild(“status-substrate”). The out-of-process CliMain path has no reverse channel, so it errors: status cannot run out-of-process, it needs the status-substrate host seam. 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): HostBuild (“status-substrate”) → 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).
Acceptance plan
Section titled “Acceptance plan”This candy’s plan: — the runnable spec charly check executes against a live deployment. check: steps are idempotent probes; run: steps change state.
| Intent | Step |
|---|---|
check |
the status command plugin ships a buildable Go module (go.mod + the provider package) compiled into charly; the full charly status end-to-end (the in-proc HostBuild status-substrate dispatch + the PURE nested overlay) is exercised by the live R10 bed plus the candy’s overlay_golden_test.go |