checkstep

Documentation

Overview

Package checkstep hosts the TYPED-STEP state-provision contract cluster for host-coupled check-verb candies (#55 CHECK-ENGINE cone Option A): the OPTIONAL StepProvider / ProvisionActor roles a kit candy implements alongside CheckVerbProvider, and the ResolvePackageName cross-distro resolver.

The StepProvider role lets the CANDY own BOTH halves of its typed install-step lowering: StepKind names the internal InstallPlan IR spec.StepKind it lowers into, and MaterializeStep builds the real spec.InstallStep from the op's plugin_input + the host-resolved ctx scalars (run-as user, candy name, package format, distro tags). Core holds NO per-kind switch — its in-proc kit adapter (charly/check_kit_adapter.go) delegates both calls to the provider, since a core kind switch is an incomplete seam (the kernel/plugin boundary law).

Housing this contract here (not spec/spec) lets charly core's in-proc kitVerbAdapter reference it importing zero kit, while sdk/kit re-exports the surviving symbols (sdk/kit/check_step_descriptors.go) so a candy that NAMES the roles compiles against the same identifier. The C7 re-signature is a hard cutover: every StepProvider implementer (plugin-service / plugin-package) adopts StepKind() → spec.StepKind + MaterializeStep in the same producer-first chain. CheckVerbProvider / CheckContext / the CheckContext scalar types stay in spec/spec (checkcontext.go) — this cluster is the step-role sibling, imported here alongside spec/spec for the *spec.Op the StepProvider / ProvisionActor methods take.

Index

• func ResolvePackageName(pkg string, packageMap map[string]string, distros []string) string
• type ProvisionActor
• type StepProvider

Functions

func ResolvePackageName

func ResolvePackageName(pkg string, packageMap map[string]string, distros []string) string

ResolvePackageName picks the correct package name for the running image's distro: if packageMap has a key matching any of the image's distro tags (first match wins — tags are authored most-specific-first, "fedora:43" before "fedora"), that mapping is used; otherwise the bare pkg name. The single cross-distro name resolver shared by the `package` candy's check + act + step materializer (R3).

Types

type ProvisionActor

type ProvisionActor interface {
	Reserved() string
	RenderProvisionScript(op *spec.Op, distros []string) (script string, ok bool)
}

ProvisionActor is the OPTIONAL second role of a host-coupled verb candy: the do:act renderer for a state-provision verb (kernel_param/mount/user/unix_group/file/command/ service/package), rendering the shell that ENACTS the op under the live init / package manager. It is reached at install COMPILE+EMIT (a `run: {plugin: <verb>}` step → the build-act RUN in emitTasks, and the local/vm deploy act) AND at runtime act. A candy whose verb type implements this ALONGSIDE CheckVerbProvider is registered as a multi-role provider (the host adapter then also satisfies the package-main ProvisionActor). op is the *spec.Op (the verb's plugin_input rides op.PluginInput); distros is the image's distro tag list for package-name resolution. Returns (script, ok); ok=false means "no act form for this op" (the host skips/errors per its act path). This is the SHELL-string act role — a verb that instead lowers into a typed InstallPlan step (service/package) additionally needs the StepProvider contract.

type StepProvider

type StepProvider interface {
	StepKind() spec.StepKind
	MaterializeStep(op *spec.Op, runAsUser, candyName, pkgFormat string, distroTags []string) spec.InstallStep
}

StepProvider is the OPTIONAL third role of a host-coupled verb candy: a verb whose build/deploy ACT lowers into a TYPED install-plan step (service → ServicePackagedStep, package → SystemPackagesStep) rather than a shell (ProvisionActor) or a generic OpStep. The CANDY owns the whole lowering: StepKind names the target internal IR spec.StepKind (the static half), and MaterializeStep builds the real spec.InstallStep for one op (the dynamic half). The host's kit adapter (charly/check_kit_adapter.go) delegates both calls to the provider, so core keeps NO per-kind mapping and NO materializer switch — the kernel/plugin boundary law's incomplete-seam tell is exactly a per-kind branch in core.

op is the verb's *spec.Op (the verb's plugin_input rides op.PluginInput). The four ctx scalars are host-RESOLVED before the call: runAsUser is the resolved user directive (deploykit.ResolveUserSpec's result), candyName the layer's name, pkgFormat the image's package format, and distroTags the image's distro tag list (most-specific-first, the input ResolvePackageName consumes). The load-bearing Reverse()s stay on the returned step (package main owns the reversal timeline); the candy owns only the construction.