feature
| plugin-box — Served by | plugin-box |
| plugin-box — Placement | compiled-in (in-process) |
| plugin-box — Version | 2026.194.0000 |
| plugin-box — Served by | plugin-box |
| plugin-box — Placement | compiled-in (in-process) |
| plugin-box — Version | 2026.194.0000 |
| plugin-feature — Served by | plugin-feature |
| plugin-feature — Placement | compiled-in (in-process) |
| plugin-feature — Version | 2026.179.0000 |
| plugin-feature — Served by | plugin-feature |
| plugin-feature — Placement | compiled-in (in-process) |
| plugin-feature — Version | 2026.179.0000 |
feature is a command word served by 4 plugin candies — plugin-box and plugin-box and plugin-feature and plugin-feature — at different points in the command tree. Both are real invocations; charly --help prints which is which.
About plugin-box, which serves it
Section titled “About plugin-box, which serves it”The build-mode charly box … verb HANDLERS relocated into a COMPILED-IN command plugin
candy (P15, K5). charly box is a SHARED command group whose subcommands have different
owners: the core BoxCmd keeps only the grammar spine (a bare kong.Plugins holder, no
retained verb) and candy/plugin-authoring contributes the authoring words, while THIS
candy contributes twelve NESTED command providers under the box parent (each
command:generate renders
the .build/ tree by InvokeProvider’ing the peer build:generate word (candy/plugin-build),
which drives HostBuild(“build-resolve”, GenerateOnly); new (candy/project/box) calls the
sdk/kit scaffold engine directly (kit.ScaffoldCandy/ScaffoldProject/AddBox), no core
reentry; validate fetches the error-TOLERANT resolved-project envelope
(HostBuild(“validate-project”)) and runs the whole per-kind/op rule engine + the deploykit
resolution-graph checks IN-PLUGIN over it, merging the host’s CUE-conformance / tunable /
base⊻from diagnostics for the verdict; load streams a host image into a RUNNING pod
venue’s nested podman store over deploykit.TransferImageToVenue — the container twin of
charly vm cp-box, needing no host reentry at all; inspect and list read the generic spec.ResolvedProject envelope
(InvokeProvider(“build”,“project”)) — inspect’s default JSON is snake_case canonical — with the
deploy-overlay formats (inspect tunnel/bind_mounts) + store-live list tags reaching the
hidden core __box-inspect-overlay / __box-list-tags reentries. Their data still needs the
fully-resolved project / deploy overlay / podman store the plugin cannot compute pre-K1. It
imports only the sdk module, never charly core. Placement-invisible (F8): the SAME provider
compiles into charly or serves out-of-process.
About plugin-box, which serves it
Section titled “About plugin-box, which serves it”The build-mode charly box … verb HANDLERS relocated into a COMPILED-IN command plugin
candy (P15, K5). charly box is a SHARED command group whose subcommands have different
owners: the core BoxCmd keeps only the grammar spine (a bare kong.Plugins holder, no
retained verb) and candy/plugin-authoring contributes the authoring words, while THIS
candy contributes twelve NESTED command providers under the box parent (each
command:generate renders
the .build/ tree by InvokeProvider’ing the peer build:generate word (candy/plugin-build),
which drives HostBuild(“build-resolve”, GenerateOnly); new (candy/project/box) calls the
sdk/kit scaffold engine directly (kit.ScaffoldCandy/ScaffoldProject/AddBox), no core
reentry; validate fetches the error-TOLERANT resolved-project envelope
(HostBuild(“validate-project”)) and runs the whole per-kind/op rule engine + the deploykit
resolution-graph checks IN-PLUGIN over it, merging the host’s CUE-conformance / tunable /
base⊻from diagnostics for the verdict; load streams a host image into a RUNNING pod
venue’s nested podman store over deploykit.TransferImageToVenue — the container twin of
charly vm cp-box, needing no host reentry at all; inspect and list read the generic spec.ResolvedProject envelope
(InvokeProvider(“build”,“project”)) — inspect’s default JSON is snake_case canonical — with the
deploy-overlay formats (inspect tunnel/bind_mounts) + store-live list tags reaching the
hidden core __box-inspect-overlay / __box-list-tags reentries. Their data still needs the
fully-resolved project / deploy overlay / podman store the plugin cannot compute pre-K1. It
imports only the sdk module, never charly core. Placement-invisible (F8): the SAME provider
compiles into charly or serves out-of-process.
About plugin-feature, which serves it
Section titled “About plugin-feature, which serves it”COMPILED-IN charly COMMAND-class plugin (command:feature) serving the externalized
charly feature … CLI — the plan-shaped-description inspection surface
(list / pending / validate). The plugin OWNS the subcommand grammar, the output
formatting (command.go: runFeatureCLI) AND the project ENUMERATION — the former
“feature” HostBuild seam’s body (charly/host_build_feature.go) is DELETED (K-wave 2
cone R6): the loader is plugin-reachable, so enumerateFeatures loads the project
PLUGIN-SIDE over the reverse channel via loaderkit (LoadUnifiedViaExecutor +
ProjectCandiesScanned + FinalizeScannedCandies) and flattens every kind: entity’s plan
into plain DATA (per-entity kind/name/description/plan, spec.FeatureEntity). The Step
plan model + validatePlanSteps (shared with charly box validate, R3) are spec/kit.
The plugin does ALL the list/pending/validate formatting + the exit code. No core
symbol crosses the boundary. (The Feature RUN verbs are NOT part of this move —
charly box feature run / charly check feature run stay children of box/check in the
core binary.)
feature is COMPILED-IN (charly.yml compiled_plugins) because its Invoke(OpRun) (provider.go) needs the in-proc reverse channel — threaded by dispatchInProcCommand (“Seam A”) — to reach the host loader legs for the plugin-side load; the out-of-process CliMain path has no reverse channel and errors. NewMeta advertises command:feature, so the compiled-in registry path (registerCompiledPlugin → resolve(ClassCommand,“feature”) → dispatchInProcCommand → Invoke(OpRun)) dispatches it in-process, where it owns the operator’s terminal stdio natively.
The R10 witness is the disposable check-feature-local bed: charly feature list candy
exits 0 and lists this project’s candies — including the plugin-feature candy itself —
proving the compiled-in command + the plugin-side loader enumeration end-to-end.
About plugin-feature, which serves it
Section titled “About plugin-feature, which serves it”COMPILED-IN charly COMMAND-class plugin (command:feature) serving the externalized
charly feature … CLI — the plan-shaped-description inspection surface
(list / pending / validate). The plugin OWNS the subcommand grammar, the output
formatting (command.go: runFeatureCLI) AND the project ENUMERATION — the former
“feature” HostBuild seam’s body (charly/host_build_feature.go) is DELETED (K-wave 2
cone R6): the loader is plugin-reachable, so enumerateFeatures loads the project
PLUGIN-SIDE over the reverse channel via loaderkit (LoadUnifiedViaExecutor +
ProjectCandiesScanned + FinalizeScannedCandies) and flattens every kind: entity’s plan
into plain DATA (per-entity kind/name/description/plan, spec.FeatureEntity). The Step
plan model + validatePlanSteps (shared with charly box validate, R3) are spec/kit.
The plugin does ALL the list/pending/validate formatting + the exit code. No core
symbol crosses the boundary. (The Feature RUN verbs are NOT part of this move —
charly box feature run / charly check feature run stay children of box/check in the
core binary.)
feature is COMPILED-IN (charly.yml compiled_plugins) because its Invoke(OpRun) (provider.go) needs the in-proc reverse channel — threaded by dispatchInProcCommand (“Seam A”) — to reach the host loader legs for the plugin-side load; the out-of-process CliMain path has no reverse channel and errors. NewMeta advertises command:feature, so the compiled-in registry path (registerCompiledPlugin → resolve(ClassCommand,“feature”) → dispatchInProcCommand → Invoke(OpRun)) dispatches it in-process, where it owns the operator’s terminal stdio natively.
The R10 witness is the disposable check-feature-local bed: charly feature list candy
exits 0 and lists this project’s candies — including the plugin-feature candy itself —
proving the compiled-in command + the plugin-side loader enumeration end-to-end.
charly --help prints the command tree, including where each feature is invoked and under which parent.