plugin-check

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

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:

• check — command class

What it does

COMPILED-IN charly COMMAND-class plugin that OWNS the externalized charly check command family (P12) — the box/live/run/feature evaluation surface plus the AI-iteration harness / R10 disposable bed-runner. The plugin owns the command end to end: the kong grammar (charly check box/live/run/feature/note/scope/list-agent/…), the plan gathering, the iteration loop, and the text/json/tap/junit/yaml output.

The things the plugin cannot compute itself are the composite HOST-SERVING Mechanisms — building the venue executor, extracting the OCI-label baked plan, and dispatching the plan-walk’s verbs through the provider registry. Those STAY core (the venue→executor, endpoint-resolve, and HTTP-do serving atoms are the explicitly-retained fabric floor) and the plugin reaches them via the generic “check-run” HostBuild seam (charly/host_build_ check_run.go, spec.CheckRunRequest → kit.CheckRunReply): the host builds the venue + runs the kit-Runner through the in-core VerbResolver + returns the []StepResult the plugin formats. The check ENGINE itself (the Runner + plan walk + grammar) lives in sdk/kit as a library both the host seam and any plugin import. “check-run” is a class-generic action noun, not a provider word (F11). The harness reaches the config loader + deploy-ledger READ via HostBuild(“config-resolve”), re-invokes charly build/deploy/check subcommands via HostBuild(“cli”), and resolves the agent CLI via InvokeProvider(kind: agent). No plugin-specific command LOGIC is left in core — this is the same “plugin owns the logic + a generic seam for the core-coupled bits” doctrine the vm + clean + pod deploy plugins established.

check is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand — to reach the check-run / config / cli / agent host seams. The out-of-process CliMain path has no reverse channel, so it errors: check cannot run out-of-process. There is NO hidden core-command forward — the plugin does the work directly, calling back only for the host-serving atoms; no core symbol crosses the boundary, no ad-hoc podman.

command:check dispatches through the COMPILED-IN registry path (registerCompiledPlugin → resolve(ClassCommand,“check”) → dispatchInProcCommand → Invoke(OpRun) with the threaded in-proc reverse channel), so NewMeta advertises command:check while the served schema carries no plugin_input (the args are plain CLI tokens kong-parsed into the CheckCmd tree). The R10 witness is the disposable check-local bed run to a fresh charly update plus a short iterate: smoke, proving the externalized command + the full box→deploy→live→bed-run gate machinery 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/checkroster.cue

// schema/checkroster.cue — the SELF-CONTAINED CUE def validating the
// `check-roster` kind's authored body. A check-roster entity declares a set of
// disposable check beds to run together (in parallel) as one gate. Ships over
// Describe (schema_cue); references no base def so it compiles standalone.
//
// A roster selects beds by `select` (a name glob, namespace-qualified; default
// "*" = every disposable bed in every imported namespace) and runs them at
// `lanes` parallelism. Negative controls are declared `expected_fail` (a
// correct non-zero exit counts as pass). Arbitration groups are AUTO-DERIVED
// from each bed's own requires_exclusive:/requires_shared: declarations — no
// hand-maintained token list.
#CheckRosterInput: {
  // select — a glob matched against every disposable bed's QUALIFIED name
  // (bare for a local bed, `ns.name` for an imported namespace). Empty/"*"
  // selects every bed. Standard globs (`check-*`, `main.check-*`) are honored.
  select?: string
  // exclude — qualified bed names (or globs) never run, even when `select` matches
  // (e.g. a multi-hour `iterate:` bed that is not a deterministic R10 bed).
  exclude?: [...string]
  // expected_fail — qualified bed names whose CORRECT outcome is a check failure
  // (exit 2): the roster passes the gate when such a bed fails on checks, and
  // fails it when the bed unexpectedly passes or hits an infra error.
  expected_fail?: [...string]
  // lanes — max concurrent bed runs. 0/absent => a host-derived default.
  lanes?: int & >=0
  // cpu / ram — enforced on every VM bed the roster runs (threaded to the bed's
  // vm-create), independent of the bed's own declaration.
  cpu?: int & >=1
  ram?: string
  // refuse_host_local — refuse (do not run) beds on `host: local`, which mutate
  // the operator's workstation. Defaults to true; set false deliberately to opt in.
  refuse_host_local?: bool
  // var — per-run variable passthrough (key=value), forwarded to every bed.
  var?: [...string]
}

---

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