plugin-cmd

Version	2026.209.0000
Repo	superproject
Plugin	yes — see the plugin reference

COMPILED-IN charly COMMAND-class plugin owning the externalized charly cmd command (#118 loader+check-tail cone) — run a single command in a running container with an optional desktop notification on completion.

The plugin owns the command end to end: the kong grammar (CmdCmd), the container resolve (deploykit.ResolveContainer / ResolveSidecarContainer), and –notify (the venue’s gdbus session-bus call, driven directly on the deploykit.ContainerChain executor — a plugin drives gdbus itself, the boundary law’s host-object-is-never-permanence rule). The ONE thing it cannot do is the interactive exec, which is deploy-lifecycle machinery (dispatchLifecycleTarget → OpAttach): it drives the hidden charly __cmd core reentry over the generic HostBuild(“cli”) seam with INHERITED stdio, so the -i interactive stream reaches the operator. The __cmd handler stays core (deploy-lifecycle-coupled RESIDUE, gated on that coupling relocating), NOT a plugin — so no charly-core symbol crosses the boundary; the plugin imports the sdk module alone.

cmd is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand — to drive HostBuild(“cli”). The out-of-process CliMain path has no reverse channel, so it errors. command:cmd is a FLAT command (Box + Command positionals), so NewMeta declares no Subcommands and ships no plugin_input.

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 cmd command plugin ships a buildable Go module (go.mod + the provider package) compiled into charly; the live charly cmd interactive exec + desktop notification is exercised against a running deployment by the bed roster