plugin-loader

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

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:

• loader — loader class

What it does

The unified-config LOADER’s PARSE half, relocated out of charly core into a compiled-in plugin candy (P6) — the config front-end every command reaches before any project is read. A compiled-in plugin candy is a SEPARATE Go module importing only sdk (never charly core), so it cannot produce charly’s typed *UnifiedFile (which embeds the core Config mechanism + the runtime Candy graph the plan keeps in core). So the boundary is PARSE/MATERIALIZE: this plugin PARSES the project (file read → import resolution → YAML multi-doc → the #NodeDoc CUE gate → reserved-word node decomposition → discover walk) into a generic, sdk-expressible ParsedProject (kind-keyed opaque nodes + the resolved import/discover structure); the HOST MATERIALIZES the typed *UnifiedFile from it (the kind-blind materializer stays core, consuming the generic tree exactly as the per-node structural-kind fold already does). The bootstrap SEED (registry_bootstrap.go init → the embedded providers: manifest via a plain yaml.Unmarshal) STAYS core and never calls LoadUnified, so a compiled-in loader plugin has NO bootstrap cycle. COMPILED-IN (in the embedded compiled_plugins:), registered at init() before the first LoadUnified call; unlocks alternative config front-ends.

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/loader.cue

// plugin-loader'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:`.
//
// The loader capability is a TYPED seam, not a wire verb: the host resolves the
// registered provider to a spec.DocParser (per-document parse) and a spec.ProjectWalker
// (whole-project walk) and calls them compiled-in with no envelope, so this schema
// DOCUMENTS the config front-end 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).
#LoaderPlugin: {
  // The capability class + word the plugin serves.
  loader: "loader"

  // What the capability does, in one line (the public-docs surface): the swappable
  // config front-end — per-document parse + whole-project walk.
  contract: string & !=""
}

---

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