plugin-feature

Version	2026.179.0000
Repo	superproject
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 AND the output formatting (command.go: runFeatureCLI); the genuine core subsystem it can’t hold — the unified LOADER (LoadConfig / ScanCandy — the kernel), the Step plan model, and validatePlanSteps (shared with charly box validate, R3) — STAYS CORE (loader + plan model + validatePlanSteps MUST stay core) and is reached via the generic “feature” HostBuild seam (charly/host_build_feature.go: enumerateFeatures). The seam enumerates every kind: entity’s plan into plain DATA (per-entity kind/name/description/summary + flattened steps {keyword,text,is_agent,is_check} + validation errors, spec.FeatureRequest → spec.FeatureReply); 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 HostBuild(“feature”); 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. Same “plugin owns the command + a generic seam for the genuine core subsystem” doctrine as command:clean / command:settings / command:doctor.

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 “feature” HostBuild seam (loader + plan model) 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	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 Go coverage (charly/host_build_feature_test.go) + the live R10 (check-feature-local)