plugin-installstep

Version	2026.203.0900
Repo	superproject
Plugin	yes — see the plugin reference

Compiled-in DUAL-PLACEMENT charly class:step plugin serving the BUILD-context OpEmit leg for the compiler-emitted builtin InstallStep kinds. Two sub-categories: the PURE kinds (C1.1) — file, shell-hook, shell-snippet, service-packaged, service-custom, repo-change, apk-install, plus the no-op-emit reboot (C1.6) — whose fragment is pure string formatting from the compiler-produced spec.InstallStepView (the SAME view the deploy walk consumes), so the plugin returns the pod-overlay Containerfile fragment directly from OpEmit (apk-install and reboot declare Emits=false and return an empty fragment — an image build installs no apk / reboots nothing); and the HOST-COUPLED system-packages (C1.2) + builder (C1.3) + local-pkg-install (C1.4) + op (C1.5) kinds, whose build-context render needs box/candy/distro/builder STRUCTURE a bare step view cannot carry. Rather than calling back a host-side renderer, this plugin fetches the “resolved-project” envelope ONCE per project dir (InvokeProvider(“build”,“project”), cached — the SAME generic seam candy/plugin-box/plugin-bundle/plugin-check consume) and builds its OWN *deploykit.Generator from it via the SAME deploykit.NewRenderGeneratorFromProject helper candy/plugin-build (the box-build render) and candy/plugin-deploy-pod (the overlay render) use, then renders each fragment DIRECTLY (dg.EmitTasks / dg.BuildStageContext / kit.BuilderResolve / deploykit.RenderLocalPkgImageInstall) — NO per-render host round-trip. The few per-invocation scalars a resolved-project snapshot cannot carry (which box, a dev-bed build, an Op step’s inline-content staging dir) ride the SAME OpEmit Invoke’s spec.BuildEnv (op.Env) every word already receives. The DEPLOY leg for ALL these kinds STAYS unchanged in sdk/kit.WalkPlans (system-packages + builder + local-pkg-install are host-engine kinds driven via RunHostStep → deploykit.RenderHostPackageCommand / runVenueBuilderStep / deploykit.ExecLocalPkgInstall; op is the act-OpStep resolveProvisionScript / renderOpCommand path; reboot is the host-side guest reboot via RunHostStep → rebootVenueAndWait, driven only on a rebootable VM venue); this plugin serves ONLY OpEmit. Every InstallStep kind is plugin-served (12 via this candy; ExternalPlugin via its own class:step plugin dispatch), and the former in-core “step-emit” per-word renderers (charly/step_emit_hostbuild.go’s stepEmitSystemPackages/stepEmitBuilder/ stepEmitLocalPkgInstall/stepEmitOp) are GONE — only the unrelated “oci-emit-step” word (the pod-overlay candy’s own per-step render request, needing the FULL core provider-registry dispatch) remains on that seam. Its Go lives in this candy’s own module (NewProvider/NewMeta + a cmd/serve out-of-process shim), compiled INTO charly via charly.yml compiled_plugins:.

Acceptance plan

This candy’s plan: — the runnable spec charly check executes against a live deployment. check: steps are idempotent probes; run: steps change state.

Intent	Step
check	the compiled-in class:step build-emit plugin ships a buildable Go module the host can build + serve (in-proc in the default binary, out-of-process via cmd/serve when not compiled in)