plugin-feature
| Version | 2026.179.0000 |
| Repo | box/github.com/opencharly/plugin-feature:v2026.242.0530 |
| Plugin | yes — see the plugin reference |
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.
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 |
a trivial deterministic build-context gate (the built-in command check verb running true); the full compiled-in charly feature end-to-end is exercised by the plugin’s Go coverage (flattenFeatures unit test) + the live R10 (check-feature-local) |