plugin-process

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

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:

• process — verb class

What it does

The process check verb relocated into a candy: a pgrep -x exact-name match against the live deployment. A HOST-COUPLED verb — its RunVerb runs against the live check engine (sdk/kit.CheckContext), so it is COMPILED-IN-ONLY. A pure check verb (probe-only, no act/step role); the second relocation on the kit contract after candy/plugin-port.

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

// The BUILT-IN `process` plugin's OWN CUE schema — the typed plugin_input for the
// `process` verb (pgrep -x exact-name match of a running process). It is the SINGLE
// SOURCE for this plugin's params, used two ways (the same contract the reference
// examplerunverb and core `spec` use):
//
//  1. GENERATE the Go param struct — `cue exp gengotypes` (driven by task cue:gen,
//     which wraps this with `package params` + `@go(params)`) emits
//     ../params/cue_types_gen.go, so the provider decodes plugin_input into a TYPED
//     struct, never a hand-parsed map.
//  2. VALIDATE authored input AT RUNTIME — the builtin serves this source over the
//     Describe channel (InProcTransport) exactly like an external serves it over
//     gRPC; the host splices it onto the base (base ++ plugin) and validates every
//     authored `process` step's plugin_input against #ProcessInput.
//
// SELF-CONTAINED: it references NO base def, so it compiles standalone (gengotypes +
// the load-gate compile) AND splices onto the base — the base ++ plugin splice
// exists to detect a def-name collision with the base, not to resolve base refs.
//
// `running` is reproduced here standalone (a bare primitive, NO def reference, so there
// is no collision when base ++ plugin compiles) because every plugin schema must be
// self-contained. It is NO LONGER a base #Op field: when `process` extracted, `running`
// stayed in #Op only because the `service` verb still read it off the step Op; the later
// service→plugin extraction moved `running` (and `enabled`) into #ServiceInput and removed
// all three from #Op, so process now reads its OWN plugin_input.running and #Op carries no
// `running` at all. Its provider is a CheckVerbProvider — it dispatches IN-PROCESS via
// RunVerb and so keeps the live *Runner the pgrep probe needs (mirrors examplerunverb),
// the property this extraction preserves.
#ProcessInput: {
  // process — the exact process name pgrep -x matches against.
  process: string @go(Process)
  // running — whether the process is expected to be running (default true). A
  // tri-state pointer so an absent key means "expected running"; this is the verb's
  // own plugin_input field (the base #Op no longer carries `running`).
  running?: bool @go(Running,type=*bool)
}

---

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