candy

plugin-candy — Served by	plugin-candy
plugin-candy — Placement	compiled-in (in-process)
plugin-candy — Version	2026.181.0001
plugin-candy — Served by	plugin-candy
plugin-candy — Placement	compiled-in (in-process)
plugin-candy — Version	2026.181.0001

candy is a command word served by 2 plugin candies — plugin-candy and plugin-candy — at different points in the command tree. Both are real invocations; charly --help prints which is which.

About plugin-candy, which serves it

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.

About plugin-candy, which serves it

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.

charly --help prints the command tree, including where each candy is invoked and under which parent.