The `tools` definition — "one person installs and runs it for themselves" — stopped
describing the store engines: they are products other people can build on. So the
four store repositories left `tools` for a `stores` org of their own, and the org
map, the clone list, the wiki table and the ecosystem plan follow. `check-repos.sh`
is green at 49.
Worth writing down for the next org change: `tea` has no transfer subcommand, but
`tea api` makes authenticated calls with tea's own credentials, which is enough for
all of it — POST /orgs, POST /orgs/{org}/teams, PUT /teams/{id}/members/{user},
POST /repos/{owner}/{repo}/transfer. And the transfer keeps Gitea's redirect: the
old `tools/...` raw URLs answer 301, so the installers on already-configured boxes
did not break. That is why this was a transfer and not a migrate-and-delete.
`warpstore` stayed in `engines`: it is a library other repos depend on, which is
what that org is for. The launcher gap moved out of the tools chapter of
ECOSYSTEM_PLAN into the new stores one, where it belongs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RETROARCH_STORE.md is the design, written from measurements rather than
documentation: the format samples, thumbnail layout and core names come from
a real RetroArch install on this machine, the core availability from the
libretro buildbot index, and the CRC32s from the catalog itself.
Three findings shaped it. The playlist folder is not necessarily inside the
RetroArch directory — on the machine measured, playlist_directory is under
~/Documents while cores and thumbnails are under ~/Library — so reading
retroarch.cfg is a requirement, not a nicety. Thumbnails must be PNG, and
one of our covers is a GIF, which no store had cared about before. And a
.lpl entry has nowhere to put a description, so desc and author do not
survive the trip.
Built the same day, in three repositories: engines/warpstore (the shared
core, extracted immediately rather than in the second phase the plan
proposed), tools/warp-engine-retroarch-store and tools/ttg-retroarch-store.
The closing section of the design records what the implementation changed
about it.
MORE_STORES.md item 4 is closed, its "a minta" section now points at the
extracted core, and REPO_REFACT.md carries the three new repos —
check-repos.sh is green at 49.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The engine can install native builds as Batocera ports, so the coverage
number the plan was chasing is in reach. Measured rather than estimated:
13 of 15 on x86_64, 9 on ARM and rising as repos re-run with the ARM
pipeline. The two that stay out — phaserdemo and trickster-tiles — ship
only html, so no native store will ever carry them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The ARM asset kind is in the build matrix and the engine now picks the
asset that matches the machine, so the plan's first two steps are behind
us. The measurement is refreshed too: linux_arm64 exists for one title,
and the win/linux x64 counts moved as pipelines re-ran.
Next is the one that turns the coverage number: installing non-cartridge
assets as Batocera ports rather than ROMs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MORE_STORES.md asks which further host platforms could get a store like
the Batocera one, and starts from a measurement: the catalog ships html
for 11 of 15 titles and desktop binaries for 8, while the Batocera store
consumes only cartridge — 7. The gap is not the number of stores but
that the existing one leaves half the catalog untouched.
Also records that the ARM64 asset kind is the prerequisite for the
retro-handheld direction, and closes the internal-org item in
REPO_REFACT.md now that all eight builder images live under build/.
The Woodpecker note is corrected against what the CLI actually reports:
19 repos registered and active, not the 10 the pipelines table shows.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mr.zeroandClaude Opus 5