[widgetii]

Problem

A t31 lite image (t31_lite_xiaomi-mjsxj03hl-nor.tgz) shipped a stale majestic (master+2c8fc00, 2026-05-24) against a current webui, so the Majestic Settings page dies with "No settings groups in schema." Since webui #68 the settings tabs come only from majestic's x-groups schema manifest, which majestic emits only since 2026-06-12 (ab639ad3). The bundled majestic predated it.

Root cause

PR #105's "Refresh moving-ref package downloads" step evicts *-{HEAD,master,main,dist}.tar.gz. That covers the webui dist (majestic-webui-dist.tar.gz) but not majestic, which downloads from S3 as:

majestic.<family>.<variant>.master.tar.bz2     # e.g. majestic.t31.lite.master.tar.bz2

— a dot separator, .tar.bz2, on the S3 host the old pattern deliberately spared as "content-addressed". But that S3 object is a moving master build, re-uploaded on every majestic CI run, with no .hash to force a refetch. So it stayed frozen in the monthly builder-dl cache while the webui refreshed — the exact desync.

(Verified: the live S3 majestic.t31.lite.master.tar.bz2 is Last-Modified 2026-06-25 and does contain the x-groups manifest. So the bucket is fresh; only the build cache was stale. PR #105 fixed the prior polarity — stale webui — not this one.)

Fix

Broaden the eviction to a regex covering both -ref and .ref separators across gz/bz2/xz:

find <dl> -type f -regextype posix-extended \
  -regex '.*[-.](HEAD|master|main|dist)\.tar\.(gz|bz2|xz)' \
  -print -delete

Evicts majestic.*.master.tar.bz2 and majestic-webui-dist.tar.gz, while sparing semver/SHA-pinned tarballs (verified against samples, incl. the tricky mastermind-2.0.tar.gz). Applied to both build-one.yml and master.yml.

The same too-narrow pattern exists in OpenIPC/firmware (build.yml + build-one.yml) and wants the identical change in a follow-up.

🤖 Generated with Claude Code