v2026.283.0000

fix(pins): advance plugin-candy to v2026.281.0948 — the pin predated …

v2026.282.2042

feat(pluginsgen): let --dev-plugin reach an OUT-OF-PROCESS plugin — e…

v2026.282.1914

fix(migrate): compile the plugin-migrate that carries its own version…

v2026.282.1710

fix(docs)!: drop the retired openclaw beds from the roster comment (#…

v2026.281.2259

test(check-commands-local): witness the candy params verb and both of…

v2026.281.2127

fix(deps): carry the sdk loader fix that names an uninitialized submo…

v2026.281.1905

fix(candy): pin plugin-candy and align the lockstep modules with it (…

v2026.281.1444

fix(import)!: advance the fedora import past the retired-refs sweep (…

v2026.281.1350

fix(import)!: advance the cachyos import to the post-M4 tag (#856)

The CachyOS distro import still pointed at v2026.274.2120, a PRE-M4 tag, while this repo's
own box/cachyos gitlink is already post-M4 (673b1b6). That split is what makes the retired
OpenClaw content keep coming back in every consumer:

  distro-cachyos@v2026.274.2120  ->  candy/cachyos-app-skills/charly.yml carries the
                                     openclaw-desktop/-full/-full-layer/-full-ml-layer skill entities
  distro-cachyos@v2026.281.1001  ->  zero such entities (M4 deleted them)

charly's import block is a consumer pin like any other, so M4's cutover owed it an advance
and did not get one. Until it lands, every project that resolves this repo's namespace -
including the marketplace corpus, through plugin-herdr's nested charly checkout - resolves the
pre-M4 tree and re-projects the four retired skills.

- charly.yml: cachyos '@github.com/opencharly/distro-cachyos:v2026.274.2120' ->
  '@github.com/opencharly/distro-cachyos:v2026.281.1001'.
- Nothing else changes: no Go, no schema, no box, no candy.

Measured, claim-keyed: under the old tag the entity grep finds 1 file
(candy/cachyos-app-skills/charly.yml); under the new tag and in this repo's post-M4
box/cachyos checkout it finds 0.

charly box validate: OK — checked 610 candies, 122 boxes, 45 deploys, 7 distros, 7 builders; 0 warnings, 0 errors.

Refs opencharly/opencharly#431

Agent: openclaw-family
Assisted-by: DSH DeepSeek V4.1 Flash (fully tested and validated)

v2026.281.1251

fix(vm): pin the Arch cloud image to a release the mirror serves (#849)

Six entities pinned v20260701.551070 — a release the mirror has pruned from its rolling
window (its directory 404s and the version is absent from the index; the oldest release
still served is v20260715.556894) — so every VM-bedded change failed at the FETCH, before
its own diff could be judged. eval-host-vm is the guest-as-host image behind the
check-local-vm bed, which is why this blocked VM beds rather than one VM.

The six sites now name the release the mirror serves, with the checksum it publishes for
exactly that filename (…cloudimg.qcow2.SHA256 names the file verbatim):

  url:      https://geo.mirror.pkgbuild.com/images/v20261001.604814/Arch-Linux-x86_64-cloudimg.qcow2
  checksum: 360f0fa49db6813bdc8e35bed230a2dc2ae3567b7b5ab74719c0a706e4e34e87

Measured, not assumed: a ranged GET of that URL returns the qcow2 magic (QFI3), and the same
shape serves on the oldest released version — so the SHAPE was never the problem, the VERSION
was. An earlier reading of mine claimed the shape was gone too; it had probed
cloudimg-v<version>, a spelling the current main does not use. That correction is recorded in
the PR body rather than quietly dropped.

The durability risk that remains is named rather than hidden: the mirror PRUNES release
directories, so v20261001.604814 will age out in turn — filed as opencharly/charly#844.

Gate: check-local-vm (disposable: true) — vm-build (the fetch AND the checksum verification),
then vm-create, deploy-add, check-live, update, rebuild-ready, check-live-rebuild, cleanup,
cleanup-members: rc=0, PASS (steps=10), summary.yml ok=true. charly box validate: 0 warnings,
0 errors.

Assisted-by: DeepSeek Harness ollama-cloud/deepseek-v4.1-flash (fully tested and validated)