plugin-build

Repo	box/github.com/opencharly/plugin-build:v2026.293.0926
Plugin	yes — see the plugin reference

The BUILD-DRIVE plugin: it OWNS the build drive — BuildKit is the builder (the build-order loop, the per-image build lock, the push, and the merge gate) for build:box (the charly box build engine) and build:generate (the charly box generate engine), AND the ensure-image ORCHESTRATION for build:ensure (core-min wave 3, build-engine cluster relocation — the former core ensure-image + cross-engine-transfer helpers): pull an image, falling back to a local (or remote-cached) build reached via the SAME in-process build:box drive this candy already owns — no new build seam. The heavy loader/render RESOLVE runs PLUGIN-SIDE ITSELF (resolveBuildEngine, K3 U6 — the former host-side NewGenerator this candy used to call over HostBuild is DELETED, #55 step3 3-II), reaching the host only for what a sdk-only candy structurally cannot do (the bootstrap-delicate local scan, the git fetch, the build-time plugin connect, the host-fs prep) over a small buildengine-* HostBuild leg family; the layer MERGE crosses to verb:oci via InvokeProvider (no HostBuild(“merge”) seam). Each stage is built with BuildKit and its image is STORED IN THE CONFIGURED CONTAINER BACKEND (the SDK LoadExport), then pushed to the LOCAL CHARLY OCI REGISTRY under the same FullTag, which the daemon mirrors ghcr.io/opencharly to — so the next stage’s FROM resolves an internal base locally, never against the upstream registry. build:generate renders the .build/ Containerfile tree in its own code (via sdk/deploykit, #67) and returns the written paths (no podman, no merge); build:ensure resolves a project-authored image identifier against charly.yml PLUGIN-SIDE (loaderkit.LoadUnified via the K1 loader reverse legs — no “box-ref-resolve” HostBuild seam, shed #55 coneK1 #8) and a remote @github.com/… identifier via HostBuild(“remote-image-resolve”, …) (git clone/cache ONLY, then plugin-side resolve), then execs podman pull/podman tag directly (no seam needed for that — same host, same privilege as the build drive’s own podman exec). Only the wire envelopes cross the seam; the podman exec happens IN the candy. COMPILED-IN (in the embedded compiled_plugins:) — charly box build / charly box generate / every dispatchBuildEnsure caller dispatch it IN-PROCESS, the host threading the reverse channel onto the Invoke context so HostBuild is reachable without a go-plugin broker. Also serves out-of-process via cmd/serve for module-shape parity (one provider, two placements).

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 build-drive plugin ships a buildable Go module the host compiles in (default) or serves out-of-process; its build:box / build:generate / build:ensure words own the build drive (BuildKit via the buildkitdrive kit, bridged into the run engine’s store) + the ensure-image orchestration and resolve/merge over the F10 HostBuild seam, exercised by EVERY box build and every image-ensure fallback across the whole ecosystem (every charly box build / charly box generate / charly box pull / deploy image-preflight invocation)