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>

ECOSYSTEM_PLAN.md

@@ -44,9 +44,8 @@ A mérce a saját folyamatunk, a wiki [PDLC](https://wiki.teletypegames.org/team
 **Erősség:** ez a legérettebb részünk. Hét platform, egységes minta, központi konfiguráció — egy új játék `.woodpecker.yaml`-ja egyetlen sor (`platform: ebitengine`).
 
 **Hiányzik:**
-- **A `bevy` és a `love` platformon nincs egyetlen aktív pipeline sem.** Mindkettőnek van toolchainje, builder image-e, demója és katalógus-bejegyzése — de a `demos/bevy-demo` és a `demos/love-demo` nincs regisztrálva a Woodpeckerben, tehát ezt a két platformot ma kézzel buildeljük.
-- **A `demos/ebitengine-demo` és a `demos/phaser-demo` sincs regisztrálva**, noha `.woodpecker.yaml`-juk van és a katalógusban szerepelnek.
-- **A pipelines tábla elavult tulajdonost tárol** a `demos/pong` és `demos/inkwell-demo` sorában (`games/…`), mert a szinkron az org-költözés óta nem futott.
+- **A WarpEngine `pipelines` táblája hiányos.** A Woodpecker 19 repót ismer és mind aktív, a `/api/ci/pipelines` viszont csak 10-et mutat, elavult tulajdonossal. A tábla a felület, amin a CI állapotát nézzük, tehát félrevezet — a valóság a `woodpecker-cli repo ls`.
+- **Négy build nem zöld** (2026-08-16): a `bevy-demo` a `bevy-builder` image miatt (a Dockerfile-ban ott a `pkg-config`, a publikált image-ben nincs — újra kell építeni), a `bombexpert` az `ldoc` miatt (a Lua forrás dokumentációs kommentjei nem értelmezhetők), a `trickster-tiles` pedig azért, mert a phaser pipeline `src/*.js`-t ellenőriz egy TypeScript projektben (javítva a sablonban, deploy után él).
 - **Kétféle fájlnév él egymás mellett:** `.woodpecker.yaml` és `.woodpecker.yml` (`impostor`, `mranderson`). Apróság, de a keresést és a sablonozást megnehezíti.
 - **Nincs kiadás-előtti ellenőrzés.** A pipeline buildel és publikál, de nem futtat tesztet, lintet vagy méretkorlát-ellenőrzést.
 
@@ -65,8 +64,8 @@ A mérce a saját folyamatunk, a wiki [PDLC](https://wiki.teletypegames.org/team
 | ebitengine | ✓ | ✓ | ✓✓ | 1 | ✓ |
 | godot | ✓ | ✓ | ✓ (pong) | — | ✓ |
 | phaser | ✓ | ✓ | ✓ | — (1 fejlesztés alatt) | ✓ |
-| bevy | ✓ | ✓ | ✓ | — | ✗ |
-| love | ✓ | ✓ | ✓ | — | ✗ |
+| bevy | ✓ | ✓ | ✓ | — | ⚠ builder image elavult |
+| love | ✓ | ✓ | ✓ | — | ✓ |
 
 **Hiányzik:**
 - **Négy platformon nincs kiadott játék** (godot, phaser, bevy, love). A teljes eszközlánc kiépült alattuk, de nem bizonyítja semmi.
@@ -140,7 +139,7 @@ Ez a három nem illeszthető egyetlen meglévő orgba sem — új org vagy új r
 
 Hatás szerint, nem nehézség szerint.
 
-1. **A négy nem regisztrált demó bekötése a Woodpeckerbe**, és a pipeline-szinkron lefuttatása. Ez pár kattintás, és ettől lesz mind a hét platform ténylegesen automatizált — ma kettő nem az.
+1. **A négy nem zöld build rendbetétele**, és a WarpEngine pipeline-szinkron lefuttatása, hogy a `/api/ci/pipelines` a valóságot mutassa. A demók bekötve vannak — a korábbi feltevés, hogy hiányoznak, a hiányos táblából jött.
 2. **Projekt-scaffolder** a `tools` orgba. A `build` és a `games` közti kézi lépéseket szünteti meg, és a demókat sablonná lépteti elő.
 3. **`assets` org** és az első konverter. A leghosszabb út, de a legnagyobb napi megtakarítás.
 4. ~~**Csomagpublikálás**~~ — **kész** (2026-08-16): `inkwell` v0.1.0, `gorpg` v0.1.0 és a `warp_engine` 0.2.0 gem kiadva, mindhárom külső projektből ellenőrizve.

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.

README.md

@@ -80,6 +80,9 @@ any single repo:
   is for and what it contains.
 - **[ECOSYSTEM_PLAN.md](ECOSYSTEM_PLAN.md)** — what we have per org towards a
   complete game development lifecycle, and what is still missing.
+- **[MORE_STORES.md](MORE_STORES.md)** — which further host platforms could get
+  a store like the Batocera one, measured against what the catalog actually
+  ships.
 
 The `ttg-ops` plugin in `ttg-marketplace` reads these rather than carrying its
 own copy of the rules.

REPO_REFACT.md

@@ -88,13 +88,13 @@ git.teletypegames.org/
 - `WIKI_CONNECTION.md` — új `Org` oszlop.
 - **Go modulnevek rendezve** (2026-08-16): `engines/inkwell`, `engines/gorpg` és `demos/inkwell-demo` `go.mod`-ja a mai orgot viszi; a `gorpg`-é korábban `module game` volt. Mindhárom kiadva, lásd `ECOSYSTEM_PLAN.md`.
 - **Gem git-források rendezve** (2026-08-16): `bbs/bbs-server`, `bbs/sermo-bbs` és `bbs/impostor-bbs` — mindhárom a kanonikus hoszton az `engines/rubbs`-ra mutat, a rögzített revíziók változatlanul.
+- **Builder image-ek átköltöztetve** (2026-08-16): mind a 8 konténer-csomag a `build` org alá került, a `ci_platforms` és a dokumentáció (7 toolchain README + Dockerfile, 2 wiki-oldal) átírva. Az `internal` org ezzel kiüríthető — ez volt az egyetlen, ami visszatartotta.
 - **Wiki `engines/` névtér** (2026-08-16): a `warp-engine`, `rubbs` és `inkwell` oldal egy közös `/engines` szekcióba került, a régi URL-ek Grav-átirányítással élnek tovább.
 - **Workspace mappák igazítva** (2026-08-16): a mappa mostantól egy az egyben az org (`bbs/`, `build/`, `demos/`, `engines/`, `games/`, `infra/`, `services/`, `tools/`). Kivétel a `devarea`, ami a gyökérben marad, mert a `clone-repos.sh` a szülőjébe klónoz.
 
 ## Nyitott pontok
 
-- **Az `internal` org megmarad**, mert 8 konténer-csomagot tart: a `*-builder` image-eket és a `tic80pro`-t. A csomagnévtér nem költözik a repókkal és nem kap átirányítást, tehát az org törlése minden buildet megölne. Ahhoz, hogy megszűnjön, az image-eket újra kell publikálni a `build` org alá, és a `services/teletypegames` repóban a `apps/api/config/initializers/warp_engine.rb:15-21` sorokat átírni.
-- **Woodpecker** — összesen 10 repót követ, mind `games`-ben volt; ezek közül kettő mozdult (`demos/inkwell-demo`, `demos/pong`). A `pipelines` tábla magától frissül a következő szinkronnál (`woodpecker_repo_id`-ra kulcsol), de a Woodpecker oldali repo-kötést érdemes ellenőrizni.
+- **Woodpecker** — a `/api/ci/pipelines` tábla hiányos: 10 repót mutat, miközben a Woodpecker 19-et ismer és mind aktív, és a tulajdonos több sorban a költözés előtti orgot mutatja. A szinkron lefuttatása rendbe teszi; addig a `woodpecker-cli repo ls` a mérvadó.
 
 ## Ami magától rendben van
 

WIKI_CONNECTION.md

@@ -46,7 +46,7 @@ This file lives in the `devarea` repo (`tools/devarea`). The repo's `scripts/` f
 - **pncdsl → inkwell rename**: the former `pncdsl` repo lives on as `inkwell` (`tools_libs/inkwell`), and `pncdsl-demo` as `inkwell-demo` (`demos/inkwell-demo`). The wiki page moved too: `development/ebitengine/pncdsl` → `development/ebitengine/inkwell` (both repos are documented by the same page: framework intro + companion demo).
 - For `games/realworld`, the `projects/realworld` page (tree) is the developer/project doc (login-protected, subpages: catalog, entities, story); there is also a NU lore page: `projects/neumatronic-universe/arcs/norman-arc/games/02-realworld`.
 - The former separate `pipeline.md` + `makefile.md` pages of the `*-tools` repos were **merged** into the engine-wide pages (`development/ebitengine`, `development/love`, `development/tic80`): a single page holds the engine intro, the Makefile docs and the CI pipeline.
-- The `tic80pro-dockerfile` repo no longer has a standalone `builder-image` page; the TIC-80 Pro builder image (`git.teletypegames.org/internal/tic80pro`) is documented in the pipeline/export section of the TIC-80 page.
+- The `tic80pro-dockerfile` repo no longer has a standalone `builder-image` page; the TIC-80 Pro builder image (`git.teletypegames.org/build/tic80pro`) is documented in the pipeline/export section of the TIC-80 page.
 - For the `impostor` repo, the developer doc is the `projects/impostor` page (tree) (fact sheet: git repo, Redmine, Woodpecker + subordinate howto/design pages); there is also a Neumatronic Universe **lore page**: `projects/neumatronic-universe/arcs/norman-arc/games/01-definitely-not-an-impostor`.
 - For `impostor-bbs`, the wiki page is still the NU lore page (Game 1.5), not classic repo documentation.
 - For the `sermo-bbs` repo (rubbs-based SERMO-DOS telnet simulator), the related page is the Sermo OS Showcase design/lore doc (its sibling page is `scratchpad/sermo-os2`), not classic repo documentation.