plugin-cache
| Version | 2026.248.0001 |
| Repo | box/github.com/opencharly/plugin-cache:v2026.270.1314 |
| Plugin | yes — see the plugin reference |
The charly cache command — the git-ref cache operator surface, served as a
charly COMMAND-class plugin (dual-placement: compiled-in + external). On
charly cache status|clear|refresh|bypass, the plugin operates on the
git-ref cache DIRECTLY through spec/refs (the same per-host charly.yml
cache: section the core singleton uses — shared on-disk state). The
bypass (charly cache bypass) is PERSISTED in the cache: git: section via
refs.GitClient.SetBypass, so a fresh core process honors it at construction —
the plugin owns the whole operator surface; core keeps only the mechanism
(spec/refs) + the singleton. The command-class companion of the verb-class
plugin-example-external; the command class is external-capable: charly
prescans cache into the CLI grammar and dispatches it in-proc (compiled-in)
or fork/execs this binary (external).
The OCI-transport surface (charly cache push <name> <ref> / pull) moves
a named spec/cache.ArtifactStore (an OCI Image Layout) to and from a
registry, reaching candy/plugin-oci’s verb:oci cache-push/cache-pull over
the F10 peer-dispatch leg — the go-containerregistry transport stays
single-homed in plugin-oci, never linked here. Needs the compiled-in
placement (the reverse channel).
Acceptance plan
Section titled “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 cache command plugin ships a buildable Go module (go.mod + the provider main) the host can build + fork/exec; the full charly cache end-to-end is exercised by the Go e2e + the live R10 |
check |
the charly cache push/pull OCI-transport leaves are present in the compiled binary’s command grammar (charly cache push --help exits 0) |