devarea/MORE_STORES.md

# 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.

> **2026-08-18: újramérés a doksi végén.** Két store és a kiemelt közös mag után
> a kérdés újra feltéve — új jelöltekkel (Pegasus, Lutris), egy korrekcióval
> (az ES-DE nem drop-in, a Steam alá van becsülve), és egy méréssel, ami az
> egész listát átrendezi: a katalógus 8/15-e `demo` vagy `development`, tehát a
> store-ok ma 7 címet látnak. Az alábbi lefedettségi számok a demókat is
> beszámolják.

## A mérés, ami átrendezi a kérdést

A katalógus legfrissebb kiadásaiban (15 szoftver) ennyi asset van (2026-08-17-i mérés):

| Asset | Hány szoftvernél | Ki használja ma |
|---|---|---|
| `html` | **11** | senki — a publikus oldal lejátssza, de nincs könyvtár |
| `win_x64` | **9** | senki |
| `linux_x64` | **9** | senki |
| `linux_arm64` | 1 | a batocera-store (arch-illesztéssel) |
| `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 — *kész*

*(2026-08-16-án megoldva; az alábbi indoklás megmaradt, mert a 3. és 4. pont erre épül.)*

**Akkori állapot: a build-mátrixunkban nem volt 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. `linux_*` → Batocera *ports* — *kész*

*(2026-08-17-én megvalósítva a motorban.)* A ROM-rendszerek mellett van egy második telepítési mód: `install: "port"` esetén a zip kicsomagolódik, és egy `.sh` indító kerül a Ports rendszerbe. A payload a `ports/.data/<subfolder>/` alá megy — a pont rejti el az ES elől —, az indító pedig egy normál almappába, amit az ES ugyanúgy pásztáz, mint bármely más rendszerét.

Számokban, a mai assetekkel:

| Gép | Lefedettség (mérve 2026-08-17) |
|---|---|
| x86_64 Batocera | **13/15** |
| ARM Batocera | **9/15** — és nő, ahogy a repók újrafutnak az ARM pipeline-nal |

A kimaradó kettő a `phaserdemo` és a `trickster-tiles`: mindkettő csak `html`-t
ad, natív binárisuk nincs, tehát ezekhez böngésző kell — natív store soha nem
fogja őket kiszolgálni.

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
*(A 2026-08-18-i szakasz ezt pontosítja: az ES-DE nem drop-in — máshonnan olvassa a gamelisteket, mint ahová a Batocera-adapter ír.)*

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.

**Kész (2026-08-18), majd a repók törölve (2026-08-19):** a motor a `warp-engine-client`be
került, a két repó megszűnt. Ami alább áll, a működésre továbbra is igaz — csak nem két
külön repóban lakik, hanem a kliensben.
Két telepítési mód: `app` (a per-OS zip kicsomagolva, menü-bejegyzéssel) és `web`
(a kiszolgált böngészős build oldalát megnyitó bejegyzés) — utóbbi azért, mert a
`html` asset **nem letölthető archívum**, hanem egy kiszolgált könyvtár. A kettő
visszaesési sorrendben van, ezért egy natív build nélküli cím is bekerül a menübe:
gépenként **10 cím** (a demókkal). macOS-en végigmérve és a játékok valóban
elindítva; Linux és Windows valódi gépen még nincs kipróbálva.

**Grafikus kliens hozzá (2026-08-18):** `stores/warp-engine-client`, Electron-ablak a CLI fölé. Ezért kapott a motor `--json`-t. Egyben a Windows-telepítő is, mert ott a `curl … | sh` nem opció — store nélkül az app maga tölti le a motort.

### 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.

**Kész (2026-08-17).** Terv és mérések: `RETROARCH_STORE.md`. Három repó:
`engines/warpstore` (a kiemelt közös mag), `stores/warp-engine-retroarch-store`
(motor), `stores/ttg-retroarch-store` (a mi store-unk). A Batocera-motor ugyanabban
a körben átült a közös magra. **Hátra van:** valódi gépen kipróbálni, hogy a
VICE-mag magától indítja-e a `.prg`-t, és hogy az Android `adb push` útvonalai
állnak-e. Ott mérve: mind a két mag (`vice_x64`, `tic80`) elérhető minden célon, Androidon is; a playlist-könyvtár nem feltétlenül a RetroArch alapkönyvtárában van, tehát a `retroarch.cfg` kötelező olvasmány; a borító csak PNG lehet, amin az `impostor` GIF-je ma elhasal; leírást a `.lpl` nem tud. A motor egyetlen valódi új képessége az út-átírás (`stage_root` / `target_prefix`), ami az Androidot és a 2. pont asztali store-ját egyszerre szolgálja.

### 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
*(2026-08-18: **levéve** — a `html`-t az asztali store, a Pegasus és az ES-DE viszi el egy indítóval; lásd a doksi végét.)*

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 közös rész 2026-08-17-én kiemelve:** `engines/warpstore`, egyetlen fájl, amit mindkét motor a telepítéskor letölt. Benne a katalógus és gyorsítótára, a kiadásválasztás, a `state.json`, a borító-letöltés, az atomikus írás és a törlés-őr — plusz az architektúra-illesztés, ami a második adapter miatt `resolve_for_host`-tá bővült: nem csak az `arch`, hanem az `os` is kulcs lehet, mert egy libretro mag fájlneve OS-enként más. Egy új store innentől valóban egy adapter plusz egy config.

## A javasolt sorrend

1. ~~**`linux_arm64` a build-mátrixba**~~ — **kész** (2026-08-16). Az `ebitengine` és a `bevy` gyártja; a `godot`-hoz a játék repójában kell ARM export preset, a LÖVE-hoz nincs upstream ARM AppImage, a TIC-80 `export` parancsának meg nincs ARM célja. A `bevydemo` 1.0.0 már `linux_arm64`-et is ad.
2. ~~**Architektúra-illesztés a motorba**~~ — **kész** (2026-08-17). A `kind` és az `ext` lehet architektúra-leképezés `*` tartalékkal; a felismert arch látszik a `list` és a `config` kimenetében. `aarch64`-en végigpróbálva: az ARM csomagot tölti le, és a benne lévő bináris valóban AArch64.
3. ~~**`linux_*` → Batocera ports**~~ — **kész** (2026-08-17). `install: "port"`; `aarch64`-en végigpróbálva: telepítés, idempotens újraszinkron, eltávolítás a 106 MB-os payloaddal, és a névtér-védés is (idegen `.data` útra mutató bejegyzést elutasít). **Hátra van:** bekapcsolni a `ttg-batocera-store` configjában, és valódi gépen kipróbálni, hogy a natív játékok tényleg elindulnak-e.
4. ~~**RetroArch playlistek**~~ — **kész** (2026-08-17), a közös mag kiemelésével együtt. Lásd `RETROARCH_STORE.md`. **Hátra van:** a VICE `.prg`-autostart és az Android-út valódi gépen.
5. **ES-családú store-ok** (1.) — a motor itt már majdnem kész, és a `warpstore` óta az adapter tényleg csak a gazdaplatform írása.

## 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.

---

# Újramérés és új jelöltek — 2026-08-18

*Két store és a kiemelt közös mag után újra feltéve a kérdés. A formátum-állítások
alább vagy a gépen mérve, vagy a hivatkozott dokumentációból ellenőrizve vannak; ahol
nem sikerült ellenőrizni, az külön ki van írva.*

## A mérés, ami megint átrendezi a kérdést: a `status`

A doksi eddigi lefedettségi számai (13/15, 9/15) **a demókat is beszámolják**. A
store-ok viszont alapból nem: mindkettő configjában `catalog.statuses:
["released", "archived"]`. A mai katalógus 15 bejegyzése így oszlik:

| `status` | Darab | Store-ban látszik ma |
|---|---|---|
| `released` + `archived` | **7** | ✔ |
| `demo` | 6 | ✘ |
| `development` | 2 | ✘ |

Ugyanaz a lefedettség a kétféle szűréssel:

| Amit a gazdaplatform enni tud | Minden status | Csak `released`+`archived` |
|---|---|---|
| `cartridge` | 7 | **6** |
| `html` | 11 | **4** |
| bármilyen natív (win/linux/mac) | 9 | **4** |
| `cartridge` + natív | 13 | 6 |
| mindent, `html`-lel együtt | 15 | 7 |

**A tanulság:** a szűk keresztmetszet ma nem a store-ok száma és nem is az
asset-fajta, hanem az, hogy a katalógus 8/15-e `demo` vagy `development`. Egy
harmadik store nulla új *tartalmat* ad — csak új *gépeket*.

És hogy a `demo` státusz melyik store-t érinti, az nem érzésre kitalálható, ezért
kimérve (`catalog.statuses` bővítése mit ad):

| Store-fajta | ma | `+ "demo"` | `+ "development"` |
|---|---|---|---|
| cartridge (Batocera ROM-út, RetroArch) | 6 | **6** (+0) | 7 (+`c64-demo`) |
| asztali, natív | 4 | **9** (+5) | 9 (+0) |
| asztali, natív **vagy** `html` | 4 | **10** (+6) | 11 (+`trickster-tiles`) |

**A meglévő két store-on tehát a demók engedélyezése semmit nem változtat**:
egyetlen cartridge-címünk sem `demo`. A 7. cartridge-cím a `c64-demo`, ami
`development` — vagyis befejezetlen, azt épp nem akarjuk kiadni.

A `demo` kérdés ezért nem a mai store-ok kapcsolója, hanem **az asztali store
előfeltétele**: demók nélkül az asztali store 4 címmel indulna, velük 10-tel. Ez
dönti el, hogy megéri-e megírni. A `REPO_REFACT.md` szerint a `demo` státusz épp
azt jelenti, hogy „nem önálló termék" — tehát terméki döntés, nem technikai.

## Az `html` kérdése: nem webes könyvtár kell hozzá, hanem indító

A `html` a legelterjedtebb assetünk (11/15), és továbbra sincs fogyasztója. A 7.
pont ezt „webes könyvtár / PWA"-ként vette fel, és ezért lett a legkisebb
határhasznú. A mérések szerint viszont máshol van a válasz.

**Batocerán nincs.** Ellenőrizve: a BUA böngésző-bejegyzései Flatpak/AppImage
alapúak, a Batocera Flatpak-támogatása pedig dokumentáltan x86_64-only — ARM-on,
tehát Pi-n és a kézikonzolokon, nincs böngésző. A `html` a Batocera-store számára
zsákutca; ezt a `ttg-batocera-store` README-jében is érdemes kimondani, hogy más
ne próbálja.

**Asztali gépen viszont majdnem ingyen van**, mert ott van böngésző. Amelyik
gazdaplatform **bármilyen parancsot** el tud indítani, az a `html`-t is tudja:

| Gazdaplatform | Mivel indítja a `html`-t | Ellenőrizve |
|---|---|---|
| Lutris | `web` runner (`lutris/runners/web.py` létezik) | ✔ a forrásfában |
| Pegasus | per-game `launch`/`command` felülírás, tetszőleges parancs | ✔ a dokumentációban |
| ES-DE | `~/ES-DE/custom_systems/es_systems.xml`, saját parancs | ✔ a USERGUIDE-ban |
| asztali store (2. pont) | `.desktop` / `.lnk` / `.app`, ami `xdg-open`-t hív | — |

Vagyis a `html` a **2. pont asztali store-jába** tartozik egy második
telepítési módként (ahogy Batocerán a `port` lett a `rom` mellé), nem egy külön
webes store-ba. Ez a 7. pontot gyakorlatilag leveszi a listáról.

## Új jelöltek, amik eddig nem voltak a listán

### Pegasus Frontend — a legjobb új jelölt
Sima szöveges `metadata.txt`: `collection` + `game` blokkok, per-game
`launch`/`command` felülírás, `{file.path}` behelyettesítéssel, `developer`,
`release`, `rating` mezők. **Windows, macOS, Linux, Raspberry Pi és Android** —
egy adapter, ami mind a három asset-fajtánkat viszi: cartridge (emulátort indít),
natív (közvetlenül), `html` (böngészőt). A formátum egyszerűbb, mint a
`gamelist.xml`, és nincs benne olyan csapda, mint a RetroArch bináris/PNG-kényszere.

### ES-DE — de nem drop-in, ahogy az 1. pont sejteti
Az 1. pont az ES-családot egy tételként kezeli, „a motor már generikus" felkiáltással.
A USERGUIDE ezt két ponton megcáfolja:

- A gamelisteket **nem** a ROM-mappából olvassa, hanem a központi
  `~/ES-DE/gamelists/` fából — a ROM-fában lévőket alapból **figyelmen kívül hagyja**.
  A mi Batocera-adapterünk pontosan oda ír, ahonnan az ES-DE nem olvas.
- A `path` tagben **kötelező a `./` prefix** (a mi merge-ünk szerencsére már így írja).

Cserébe többet ad, mint a Batocera: fut Linuxon, macOS-en, Windowson, **Androidon**,
Haikun és Steam Decken, és `custom_systems/es_systems.xml`-ben saját rendszert lehet
definiálni tetszőleges indító paranccsal — tehát nála is megvan a `html`-út.
Az adapter tehát nem a Batocera-adapter újrahasznosítása, hanem egy testvére:
ugyanaz a metaadat-formátum, más útmodell.

### Lutris — egy Linux-asztali gépen elvileg 15/15
Ellenőrizve: a Lutris-installer lehet **tisztán lokális YAML**, weboldal nélkül
(`lutris -i /path/to/file.yaml`), a kulcsok a gyökérben, minden más a `script`
alatt, `$SCRIPTDIR`-rel relatív fájlokra. A runnerek között ott van a `linux`
(natív), a `web` (böngésző) és a `wine` — vagyis egy Lutris-store a `html`-t, a
Linux-natívot és akár a Windows-buildeket is fel tudja tenni **ugyanabba a
könyvtárba**. Ez a legnagyobb elméleti lefedettség a listán.

A minta viszont más: nem mi írjuk a könyvtárformátumot, hanem generálunk egy
telepítőt és meghívjuk a Lutrist. Kevesebb kontroll (a prune-hoz a Lutris saját
adatbázisát kellene bántani), de a `state.json`-unk így is tudja, mit tettünk fel.

### LaunchBox és Playnite — nem tudtam ellenőrizni
Mindkettő nagy Windows-közönség, és mindkettőnél elakadtam:

- **LaunchBox**: a játéklista `Data/Platforms/<Platform>.xml`-ben van, de a séma
  nincs dokumentálva (a közösség visszafejtette), és az alkalmazás maga is
  újraírja a fájlt. Egy valódi telepítés nélkül nem érdemes tervezni rá.
- **Playnite**: a hivatalos út egy C#/.NET library plugin, nem egy adatfájl —
  ez kilóg a „stdlib Python + egy fájl" mintánkból. A dokumentációt nem sikerült
  elérnem (403), tehát ez is nyitott kérdés.

Egyik sem javasolt a Pegasus és az ES-DE előtt.

## Korrekció a meglévő listához: a Steam alá van becsülve

A 3. pont szerint „a letöltést a 2. pontról örökli, tehát ráépül" — a letöltést
igen, a formátum viszont a listán a legkellemetlenebb:

- A `shortcuts.vdf` **bináris VDF**, nem szöveg: `appid` (4 bájt little-endian),
  `AppName`, `Exe`, `StartDir`, `LaunchOptions`.
- Az `appid` az exe és a név CRC32-jéből számolt érték, a legfelső bit beállítva —
  és ez az `appid` a borítóképek fájlneve is (`userdata/<id>/config/grid/<appid>p.png`).
- **Ha a fájl hibás, a Steam indulás után törli**; ha a felhasználó a Steam UI-ból
  vesz fel egy nem-Steam játékot, felülírja, amit írtunk. Írás után Steam-újraindítás
  kell.
- A `userdata/<id>` ág felhasználónként más, tehát felderítés is kell hozzá.

Bináris formátumot írni stdlib Pythonból megoldható, de ez nem „kevés munka", és
egy elrontott fájl a felhasználó teljes nem-Steam listáját viszi. A 3. pont ezért
a 2. pont **után** és önálló körben való, nem mellékesként.

## Az újrarendezett sorrend

1. **Döntés a demókról** — 0 kód, de nem a mai store-okról szól: azokon nem
   változtat semmit (nincs `demo` státuszú cartridge-ünk). Az asztali store
   értelmét dönti el: 4 cím demók nélkül, 10 velük. Ezért ez a 2. pont
   előfeltétele, nem önálló nyereség.
2. **Asztali store** (2. pont) — változatlanul a legnagyobb valóban új képesség,
   most már azzal, hogy a `html` is bele tartozik egy második telepítési módként.
   Ez teszi elérhetővé a katalógus 15/15-ét (a demókkal együtt).
3. **Pegasus** — egy adapter, ami mind a három asset-fajtát viszi öt platformra,
   köztük Androidra, szöveges formátumban. A legjobb arány a listán.
4. **ES-DE** — ugyanaz a metaadat-formátum, más útmodell; desktop + Android +
   Steam Deck. Az 1. pont maradéka (RetroPie, Recalbox, kézikonzolok) ezután jön,
   mert azok a Batocera-adapterhez állnak közelebb.
5. **Steam** (3.) — a 2. pontra épül, de önálló körben, a bináris formátum miatt.
6. **BBS store** (5.) — változatlanul a márkaérték-tétel, nem elérés-tétel.
7. **Csomagkezelők** (6.) — a 2. pont csomagolására épül.
8. ~~**Webes könyvtár / PWA**~~ (7.) — **levehető**: a `html`-t a 2., 3. és 4. pont
   viszi el, ez pedig a publikus oldallal fedne át.

## Amit valódi gépen kell ellenőrizni (bővítve)

A korábbi kettő (per-OS zipek önmagukban futtathatók-e; macOS-aláírás) mellé:

- **Pegasus**: elolvassa-e a generált `metadata.txt`-t Androidon is, és mit tesz a
  `launch` paranccsal ott (Android-on nincs shell úgy, ahogy asztalon).
- **ES-DE**: a `~/ES-DE/gamelists/` fába írt metaadat és a `custom_systems` együtt
  működik-e, illetve mit lát az ES-DE Android-kiadása.
- **Lutris**: a `lutris -i` fut-e fejetlenül (headless), vagy GUI-t nyit — ez dönti
  el, hogy egy szinkron automatizálható-e.
- **LaunchBox / Playnite**: van-e egyáltalán írható formátum. Egy telepítés
  megválaszolja; addig ne tervezzünk rájuk.