plugin-candy

Version	2026.181.0001
Repo	superproject
Plugin	yes — see the plugin reference

COMPILED-IN charly COMMAND-class plugin (command:candy) OWNING the entire charly candy CLI — the TOP-LEVEL candy-manifest authoring surface (set / add-rpm / add-deb / add-pac / add-aur). The plugin owns the ENTIRE logic: the subcommand grammar AND the comment-preserving yaml.Node mutation of candy//charly.yml (candySet / appendCandyPackages / candyBodyNode / ensureMappingChild — all in the plugin, none in core). There is NO core candy logic and NO HostBuild seam — a plugin editing yaml owns that itself. (This is NOT charly new candy — a different command, a child of charly new, that stays a builtin.)

The ONLY shared pieces are the GENERIC yaml utilities kit.SetByDotPath + kit.MappingChild (sdk/kit/yaml.go), which ALSO back charly box set + charly box scaffold — ONE copy, no duplication (R3). Nothing candy-specific crosses between core and the plugin.

Because the logic is self-contained — no reverse channel needed, the yaml mutation is host-local file work — charly candy works IDENTICALLY compiled-in OR out-of-process, like migrate. Listed in charly.yml compiled_plugins, it registers in-proc and the host dispatches it through dispatchInProcCommand → Invoke(OpRun) → runCandyCLI (which just runs directly — no executor, no HostBuild). The out-of-process placement fork/execs the module (cmd/serve → CliMain) running the SAME runCandyCLI; NewMeta advertises command:candy so the compiled-in registry path resolves it.

The R10 witness is the disposable check-commands-local bed: charly candy --help exits 0, proving the command tree resolves and dispatches end-to-end.

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 command plugin ships a buildable Go module (go.mod + the provider) the host can build; the full charly candy end-to-end is exercised by the live R10 (check-commands-local)