Add MORE_STORES.md, and close the builder image item

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>

MORE_STORES.md

@@ -0,0 +1,124 @@
+# Milyen további store-okat érdemes csinálni
+
+Készült 2026-08-16-án, a `warp-engine-batocera-store` szétválasztása után. A kérdés: a batocera-store mintájára milyen más gazdaplatformra tudnánk store-t adni.
+
+## A mérés, ami átrendezi a kérdést
+
+A katalógus legfrissebb kiadásaiban (15 szoftver) ennyi asset van:
+
+| Asset | Hány szoftvernél | Ki használja ma |
+|---|---|---|
+| `html` | **11** | senki — a publikus oldal lejátssza, de nincs könyvtár |
+| `win_x64` | **8** | senki |
+| `linux_x64` | **8** | senki |
+| `cartridge` | 7 | a batocera-store |
+| `win_x86` | 4 | senki |
+| `mac_x64` | 3 | senki |
+| `docs` / `source` | 3 / 3 | a publikus oldal |
+| `mac_universal` | 2 | senki |
+
+Platformonként:
+
+| Platform | Elérhető assetek |
+|---|---|
+| c64 | `cartridge` (4) |
+| tic80 | `cartridge`, `html`, `source`, `docs`, `win_x64`, `linux_x64`, `mac_x64` (3) |
+| ebitengine | `html`, `win_x86`, `win_x64`, `linux_x64` (3) |
+| godot | `html`, `win_x86`, `win_x64`, `linux_x64`, `mac_universal` (1) |
+| love | `html`, `win_x64`, `linux_x64`, `mac_universal` (1) |
+| phaser | `html` (2) |
+| bevy | `html` (1) |
+
+**A tanulság:** a batocera-store csak a `cartridge`-et fogyasztja, tehát a katalógus **7/15 részét**. A legelterjedtebb asset-fajtánk, a webes build, egyetlen store-ban sem szerepel. Nem az a szűk keresztmetszet, hogy kevés store van — hanem hogy a meglévő a katalógus felét ott hagyja.
+
+---
+
+## 0. Előfeltétel mindenhez: ARM Linux buildek
+
+**A build-mátrixunkban nincs Linux ARM asset.** A `ReleaseAsset::KINDS` ezt tartalmazza:
+
+```
+cartridge source html docs
+win_x86 win_x64 linux_x86 linux_x64
+mac_x64 mac_arm64 mac_universal
+```
+
+Van `mac_arm64`, de **`linux_arm64` és `linux_armhf` nincs** — a `linux_x86` pedig szerepel a listán, csak épp semmi nem gyárt bele.
+
+Ez azért döntő, mert a Batocera nem csak x86_64-en fut: Raspberry Pi-n, Odroidon és a kézikonzolokon ARM-on megy. Egy `linux_x64` bináris ezeken **feltelepül, de nem indul el** — ami rosszabb, mint ha nem is ajánlanánk fel. Ugyanez blokkolja az 1. pont legérdekesebb célpontjait: a muOS, ArkOS és JELOS kézikonzolok szinte mind ARM-osak.
+
+Amiért a mai store hordozható: a `cartridge` **architektúra-független** (adat egy emulátornak), ezért mind a 7 cím megy minden Batocera gépen.
+
+**Teendő, sorrendben:**
+1. `linux_arm64` (és ha kell, `linux_armhf`) felvétele a `KINDS`-be és a platformok `ci_platforms` mátrixába.
+2. Cross-build a pipeline-okban. A legkönnyebb az ebitengine (Go: `GOARCH=arm64`), utána a bevy (Rust cross toolchain) és a godot (van ARM export template); a LÖVE a legnehezebb, ott ARM futtatókörnyezet kell.
+3. A motor **architektúra-felismerése** (`uname -m` → `x86_64` / `aarch64` / `armv7l`), és csak az illeszkedő asset telepítése.
+
+## 0b. Utána: `linux_*` → Batocera *ports*
+
+Ha az ARM buildek megvannak, a ROM-rendszerek mellé jöhet egy második telepítési mód: ami nem cartridge, az portként megy fel. A Batocera ports rendszere `.sh` indítókat vesz, a motor pedig már ma is ír ports bejegyzést.
+
+Számokban, a mai assetekkel:
+
+| Gép | Lefedettség |
+|---|---|
+| x86_64 Batocera | **12/15** — a 7 cartridge + ebitengine 3, godot 1, love 1 (a 3 tic80 átfedés) |
+| ARM Batocera | **7/15** — csak a cartridge, amíg nincs ARM build |
+
+A kimaradó három cím (1 bevy, 2 phaser) csak `html`-t ad, azokhoz böngésző kell.
+
+Ugyanez a keret adja az interaktív ES-menüt is (ports bejegyzések gamelist-metaadattal).
+
+---
+
+## Új store-ok, sorrendben
+
+### 1. ES-családú store-ok
+RetroPie, Recalbox, ES-DE, és a kézikonzolos disztrók (muOS, ArkOS, JELOS). Ugyanaz a `gamelist.xml` + ROM-mappa modell, amire a motor **már generikus**: gyakorlatilag `paths.roms_root`, rendszernév-leképezés és egy másik telepítő kell. A legtöbb elérés a legkevesebb munkáért. Az ES-DE Windowson és macOS-en is fut, tehát asztali elérést is ad mellékesen.
+
+Fontos megkötés: a **kézikonzolok jóformán mind ARM-osak**, és a RetroPie is Pi-n fut. Cartridge-dzsel ezek azonnal kiszolgálhatók, natív játékkal viszont csak a 0. pont ARM buildjei után.
+
+### 2. Asztali store — `warp-engine-desktop-store`
+A per-OS zipeket telepíti egy helyi könyvtárba, és indítót csinál hozzá (`.desktop`, Start menü bejegyzés, `.app`). Ma 8 szoftvert szolgálna ki, és a CI-lefedettséggel nő. Ez a legnagyobb valóban új képesség: asztali gépre ma **semmilyen** utunk nincs.
+
+### 3. Steam-könyvtár
+A `shortcuts.vdf`-be írva a játékaink megjelennek a Steam könyvtárban borítóval — és ezzel a Steam Decken is. A letöltést a 2. pontról örökli, tehát ráépül, nem mellé megy. Bevált technika, a Heroic és a Lutris is ezt teszi.
+
+### 4. RetroArch playlistek
+`.lpl` JSON playlist platformonként. A cartridge-eket sokkal nagyobb közönségnek adja, mint a Batocera: Android, asztali gépek, konzolok. Kis formátum, kevés munka.
+
+### 5. BBS store
+A `bbs/bbs-server`-be, a saját `rubbs`-unkra épülve. Bármelyik asset-fajtát tudja adni letöltésként, és ez az egyetlen a listán, amit **rajtunk kívül senki nem tudna lemásolni** — márkaérték, nem csak elérés.
+
+### 6. Csomagkezelők
+Homebrew tap és Scoop bucket: `brew install ttg/tap/rabbitroller`. Kevés munka, és nem kell hozzá launchert írni; a 2. pont csomagolására épül.
+
+### 7. Webes könyvtár / PWA
+A `html` assetek megvannak, de ez van a legnagyobb átfedésben a mostani publikus oldallal, ezért a legkisebb határhasznú — annak ellenére, hogy ez a legelterjedtebb assetünk.
+
+---
+
+## Amit nem javaslok
+
+- **itch.io** — az az ő katalógusuk, nem a miénk; nem store-t adnánk, hanem feltöltenénk.
+- **Flatpak / Snap** — nehéz átvezetés és felülvizsgálat kevés extra elérésért.
+- **Önálló Android APK** — nagy munka; a RetroArch úton (4. pont) az android elérés majdnem ingyen megvan.
+
+---
+
+## A minta
+
+Mind ugyanaz a forma: **olvasd a WarpEngine katalógust → írd a gazdaplatform saját könyvtárformátumát.** A `warp-engine-batocera-store` szétválasztásával ezt már megalapoztuk. Ha a közös rész — katalógus-lekérés és gyorsítótár, kiadásválasztás (`dev-` kihagyás, asset-egyeztetés), `state.json`, borítókép, prune-védelem saját almappával — egy helyen marad, akkor egy új store valóban csak egy **adapter plusz egy config**.
+
+Egy dolog viszont **nem** tartozik az adapterbe, hanem a közös részbe: az **architektúra-illesztés**. A gazdaplatform megmondja, milyen gépen fut (`uname -m`, Windows/macOS esetén a megfelelő megfelelője), és a motornak ehhez kell asset-fajtát választania. Ez a 0., 1. és 2. pontnak egyaránt kell, tehát egyszer, jó helyen érdemes megírni.
+
+## A javasolt sorrend
+
+1. **`linux_arm64` a build-mátrixba** (0. pont) — enélkül a retró-vonal fele, a kézikonzolok pedig teljesen kimaradnak.
+2. **Architektúra-illesztés a motorba** — a közös rész, amire utána minden store épít.
+3. **`linux_*` → Batocera ports** (0b) — a meglévő store-t hozza tisztába, 7/15-ről 12/15-re.
+4. **ES-családú store-ok** (1.) — a motor itt már majdnem kész.
+
+## Amit valódi gépen kell ellenőrizni
+
+A 2. és 3. pont azon áll vagy bukik, hogy a per-OS zipjeink **önmagukban futtathatók-e**: van-e hiányzó függőség Linuxon, és mit szól hozzá a macOS aláírás-ellenőrzése egy nem jegyzett binárishoz. Erről a katalógus nem árulkodik, csak egy próba.