plugin-feature

Placement	compiled-in (in-process)
Source	github.com/opencharly/plugin-feature/candy/plugin-feature
Version	2026.179.0000
Candy	plugin-feature

This plugin is listed in charly/charly.yml’s compiled_plugins:, so its providers are compiled into the charly binary and register in-process.

Providers

The reserved words this plugin serves:

• feature — command class

What it does

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.

Parameter schema

The CUE schema below is the authoritative grammar for this plugin’s input. It is the same single source that generates the plugin’s Go parameter types and answers the runtime Describe RPC, so this page cannot disagree with either.

schema/feature.cue

// plugin-feature's OWN self-contained CUE schema — the plugin's declaration
// surface, served over Describe exactly like every other
// plugin's schema (there is no schema-less plugin):
//
//  1. SERVE over Describe — the host splices `base ++ plugin` at the load gate
//     (registerPluginUnitSchema), so the plugin's declarations travel WITH it and
//     a self-contained schema that will not splice is a LOUD load failure.
//  2. DOCUMENT — `charly docs generate` renders this plugin's page from its
//     providers + this schema + the candy `description:`.
//
// command:feature's authored input is its pass-through CLI grammar (`list` /
// `pending` / `validate`), the `{args: [...]}` envelope the host dispatches to
// Invoke(OpRun) — not a structured plugin_input — so this schema DOCUMENTS the
// command contract (no #*Input def). SELF-CONTAINED: it references no base def, so
// it compiles STANDALONE (the property that lets the SDK compile it serve-side).
#FeaturePlugin: {
  // The capability word the plugin serves.
  command: "feature"

  // What the command does, in one line (the public-docs surface): inspect a
  // project's plan-shaped entity descriptions (list / pending / validate).
  contract: string & !=""
}

---

See also the candy reference for this candy’s install surface.