# Release Checklist (Magyar)

🌐 **Languages:** 🇺🇸 [English](../../../../ops/RELEASE_CHECKLIST.md) · 🇪🇹 [am](../../../am/docs/ops/RELEASE_CHECKLIST.md) · 🇸🇦 [ar](../../../ar/docs/ops/RELEASE_CHECKLIST.md) · 🇦🇿 [az](../../../az/docs/ops/RELEASE_CHECKLIST.md) · 🇧🇬 [bg](../../../bg/docs/ops/RELEASE_CHECKLIST.md) · 🇧🇩 [bn](../../../bn/docs/ops/RELEASE_CHECKLIST.md) · 🇧🇦 [bs](../../../bs/docs/ops/RELEASE_CHECKLIST.md) · 🇨🇿 [cs](../../../cs/docs/ops/RELEASE_CHECKLIST.md) · 🇩🇰 [da](../../../da/docs/ops/RELEASE_CHECKLIST.md) · 🇩🇪 [de](../../../de/docs/ops/RELEASE_CHECKLIST.md) · 🇬🇷 [el](../../../el/docs/ops/RELEASE_CHECKLIST.md) · 🇪🇸 [es](../../../es/docs/ops/RELEASE_CHECKLIST.md) · 🇪🇪 [et](../../../et/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇷 [fa](../../../fa/docs/ops/RELEASE_CHECKLIST.md) · 🇫🇮 [fi](../../../fi/docs/ops/RELEASE_CHECKLIST.md) · 🇫🇷 [fr](../../../fr/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇪 [ga](../../../ga/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [gu](../../../gu/docs/ops/RELEASE_CHECKLIST.md) · 🇳🇬 [ha](../../../ha/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇱 [he](../../../he/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [hi](../../../hi/docs/ops/RELEASE_CHECKLIST.md) · 🇭🇷 [hr](../../../hr/docs/ops/RELEASE_CHECKLIST.md) · 🇦🇲 [hy](../../../hy/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇩 [id](../../../id/docs/ops/RELEASE_CHECKLIST.md) · 🇳🇬 [ig](../../../ig/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇹 [it](../../../it/docs/ops/RELEASE_CHECKLIST.md) · 🇯🇵 [ja](../../../ja/docs/ops/RELEASE_CHECKLIST.md) · 🇬🇪 [ka](../../../ka/docs/ops/RELEASE_CHECKLIST.md) · 🇰🇭 [km](../../../km/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [kn](../../../kn/docs/ops/RELEASE_CHECKLIST.md) · 🇰🇷 [ko](../../../ko/docs/ops/RELEASE_CHECKLIST.md) · 🇱🇹 [lt](../../../lt/docs/ops/RELEASE_CHECKLIST.md) · 🇱🇻 [lv](../../../lv/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [ml](../../../ml/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [mr](../../../mr/docs/ops/RELEASE_CHECKLIST.md) · 🇲🇾 [ms](../../../ms/docs/ops/RELEASE_CHECKLIST.md) · 🇲🇹 [mt](../../../mt/docs/ops/RELEASE_CHECKLIST.md) · 🇲🇲 [my](../../../my/docs/ops/RELEASE_CHECKLIST.md) · 🇳🇵 [ne](../../../ne/docs/ops/RELEASE_CHECKLIST.md) · 🇳🇱 [nl](../../../nl/docs/ops/RELEASE_CHECKLIST.md) · 🇳🇴 [no](../../../no/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [or](../../../or/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [pa](../../../pa/docs/ops/RELEASE_CHECKLIST.md) · 🇵🇭 [phi](../../../phi/docs/ops/RELEASE_CHECKLIST.md) · 🇵🇱 [pl](../../../pl/docs/ops/RELEASE_CHECKLIST.md) · 🇵🇹 [pt](../../../pt/docs/ops/RELEASE_CHECKLIST.md) · 🇧🇷 [pt-BR](../../../pt-BR/docs/ops/RELEASE_CHECKLIST.md) · 🇷🇴 [ro](../../../ro/docs/ops/RELEASE_CHECKLIST.md) · 🇷🇺 [ru](../../../ru/docs/ops/RELEASE_CHECKLIST.md) · 🇱🇰 [si](../../../si/docs/ops/RELEASE_CHECKLIST.md) · 🇸🇰 [sk](../../../sk/docs/ops/RELEASE_CHECKLIST.md) · 🇸🇮 [sl](../../../sl/docs/ops/RELEASE_CHECKLIST.md) · 🇷🇸 [sr](../../../sr/docs/ops/RELEASE_CHECKLIST.md) · 🇸🇪 [sv](../../../sv/docs/ops/RELEASE_CHECKLIST.md) · 🇰🇪 [sw](../../../sw/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [ta](../../../ta/docs/ops/RELEASE_CHECKLIST.md) · 🇮🇳 [te](../../../te/docs/ops/RELEASE_CHECKLIST.md) · 🇹🇭 [th](../../../th/docs/ops/RELEASE_CHECKLIST.md) · 🇹🇷 [tr](../../../tr/docs/ops/RELEASE_CHECKLIST.md) · 🇺🇦 [uk-UA](../../../uk-UA/docs/ops/RELEASE_CHECKLIST.md) · 🇵🇰 [ur](../../../ur/docs/ops/RELEASE_CHECKLIST.md) · 🇺🇿 [uz](../../../uz/docs/ops/RELEASE_CHECKLIST.md) · 🇻🇳 [vi](../../../vi/docs/ops/RELEASE_CHECKLIST.md) · 🇳🇬 [yo](../../../yo/docs/ops/RELEASE_CHECKLIST.md) · 🇨🇳 [zh-CN](../../../zh-CN/docs/ops/RELEASE_CHECKLIST.md) · 🇹🇼 [zh-TW](../../../zh-TW/docs/ops/RELEASE_CHECKLIST.md)

---

> **Legutóbb frissítve:** 2026-08-28 — v3.8.51
> Egyszerűsített kiadási folyamat, amely a Claude Code készségeit használja az automatizáláshoz.
>
> **Tartsd zölden a várólistát/ágat a kiadások között:** lásd: [RELEASE_GREEN.md](./RELEASE_GREEN.md)
> (`/green-prs` család + `npm run check:release-green` + `/babysit` + éjszakai futtatás). Ennek rendszeres futtatása
> — különösen **ezen ellenőrzőlista előtt** — biztosítja, hogy a kiadási PR zölden induljon.

## Röviden

```bash
# 1. Verzió növelése + CHANGELOG generálása (készség)
/version-bump-cc patch    # vagy minor/major

# 2. Minőségi ellenőrzések helyi futtatása
npm run check              # lintelés + tesztek
npm run test:coverage      # teljes lefedettségi ellenőrzés (60/60/60/60)

# 3. Build és smoke teszt
npm run build
npm run test:e2e           # opcionális, de ajánlott

# 4. Kiadás generálása (készség)
/generate-release-cc

# 5. Telepítés (készség)
/deploy-vps-both-cc        # vagy akamai-cc / local-cc

# 6. Kiadási bizonyítékok rögzítése (készség)
/capture-release-evidences-cc
```

## npm Trusted Publishing (v3.8.51 óta alapértelmezett) — kérésre előkészített, tartalékmegoldásként közvetlen

Az `npm-publish.yml` alapértelmezés szerint az **npm Trusted Publishing (OIDC)** használatával publikál: a
`stage-npm` feladat (GitHub által üzemeltetett környezetben) a GitHub id-tokenjét egy rövid élettartamú npm
hitelesítő adatra cseréli az adott futtatáshoz — nincs hosszú élettartamú npm-token a repository secretjei között, nincs 2FA-kérés, az eredetigazolás pedig csatolva van.
Ez az npm által támogatott megkerülési mód most, hogy a 2FA-t kihagyó tokeneket kivezetik;
visszaállítja a projektben v3.8.48-ig használt teljesen automatikus folyamatot, miközben fenntartja a
WS1.3 garanciáját (egy kiszivárgott token önmagában nem képes publikálni — nincs token).

**Egyszeri beállítás (tulajdonos):** npmjs.com → `omniroute` csomag → Settings → _Trusted
Publisher_ → GitHub: tulajdonos `diegosouzapw`, repository `OmniRoute`, munkafolyamat `npm-publish.yml`
(környezet: nincs). Amíg ez nem létezik, az automatikus lépés `ENEEDAUTH` hibával meghiúsul:
indítsd újra `publish_mode=staged` (lásd alább) vagy `direct` beállítással.

### Előkészített publikálás (kérésre — `publish_mode=staged`)

Az npm-publish munkafolyamat már nem publikál közvetlenül: elindítja a becsomagolt tarballt
(`check:pack-boot`), majd futtatja az `npm stage publish` parancsot — a pontos bájtok a
registryben várakoznak, és **nem telepíthetők**, amíg a tulajdonos jóvá nem hagyja őket. Az emberi 2FA-ellenőrzési pont
a bizonyítás ELŐTTRŐL az UTÁNRA került.

**Tulajdonosi folyamat, miután a munkafolyamat zöldre vált:**

1. `npm stage list omniroute` — keresd meg a stage azonosítóját (a munkafolyamat összefoglalója is megjeleníti).
2. Ellenőrizd az előkészített bájtokat (ajánlott): `npm stage download <id>`, majd telepítsd a
   letöltött tarballt egy ideiglenes prefixbe, és indítsd el (az `npm run check:pack-boot` ugyanezt a
   csomagolás→telepítés→indítás ellenőrzést automatizálja a CI-ban).
3. `npm stage approve <id>` — a 2FA-kérés MAGA a publikálás. Az `npm stage reject <id>` elveti az előkészített kiadást.
4. Publikálás utáni védőháló: a publikálás utáni ellenőrző (a v3.8.49 terv WS1.4 része) egy tiszta konténerben telepíti a
   publikált verziót a nyilvános registryből, majd elindítja.

**Vészhelyzeti tartalékmegoldás:** a `workflow_dispatch` `publish_mode=direct` beállítása visszaállítja a
korábbi, azonnali `npm publish` működést (csak akkor használd, ha maga az előkészítés hibásan működik; dokumentáld az okát).

**Egyszeri megerősítés (tulajdonos, npmjs.com):** állítsd be az `omniroute` Trusted Publisherét
csak előkészítési módban, hogy egy kiszivárgott, hosszú élettartamú token sehonnan se tudjon közvetlenül `npm publish`
parancsot végrehajtani — a CI csak előkészíthet; kizárólag a tulajdonos 2FA-ja adhatja ki a csomagot.

**Hibás artifact kezelési terv (változatlan):** alapértelmezett azonnali lépésként használd az `npm deprecate omniroute@<bad> "<reason> — use <fixed>"`
parancsot (percek alatt végrehajtható, visszafordítható); az `npm unpublish` csak a 72 órás/nincs-függő
időablakon belül használható, és soha ne ez legyen az első lépés. Docker: soha ne írj felül egy verziócímkét — a visszaállítás
azt jelenti, hogy a `latest` címkét az utolsó jó digestre irányítod.

**Docker Hub `latest` (minden stabil SemVer-publikálásnál kötelező):** a
`docker-publish` munkafolyamatnak az `X.Y.Z` címkét, valamint — amikor a
`should-promote-latest.sh` szerint ez a legmagasabb stabil SemVer — a `:latest`
címkét is **ugyanazzal a digesttel** kell ellátnia. A feladat után: a Hub `latest` digestje megegyezik az új
SemVer digestjével, és a `last_updated` értéke frissült. Ne hagyd a `:latest` címkét egy régebbi
builden, miközben a kiadási megjegyzések olyan javításokról szólnak, amelyek csak a gitben léteznek. A Compose
gyorsindítási példái a `:latest` címkét használják; a GitOps-konfigurációk továbbra is az `X.Y.Z` verziót rögzítsék. Lásd:
[Docker kiadási csatornák](../guides/DOCKER_GUIDE.md#release-channels) és #10317.

## Gyorsított hotfix-folyamat (`hotfix` címke)

A `hotfix` címkével ellátott PR kihagyja a nagy CI-mátrixot (9 részre osztott E2E, lefedettségi küszöbkövetés,
quality-gate, quality-extended), és megtartja a gyors, nagy jelértékű ellenőrzéseket: build,
egységteszt-részek, integrációs tesztek, vitest, lint/típusellenőrzés, docs-sync, `check:pack-artifact`,
valamint a tarball indulási füsttesztje (`check:pack-boot`). Cél: zöld eredmény ≤15 perc alatt a ~33 perc helyett.

**Belépési szabályzat — mind a négy feltétel kötelező (a Chromium/VS Code/Node vészhelyzeti folyamatai alapján):**

1. **Súlyosság**: a produkciós rendszer nem működik — egy közzétett artefaktum induláskor összeomlik / egy
   biztonsági javításról van szó / a kiadás minden felhasználója érintett. A „fontos” nem jelenti azt, hogy „nem működik”.
2. **Jogosultság**: kizárólag a repository tulajdonosa alkalmazhatja a `hotfix` címkét. A címke MAGA
   a jóváhagyás — kampány-PR esetén soha nem alkalmazható saját hatáskörben.
3. **Bizonyíték**: a PR törzse hivatkozik az előző, teljesen zöld nagy futtatásra (arra a tesztcsomagra, amelyet
   a kihagyott feladatok újra ellenőriznének), valamint a javítás saját, előbb sikertelen, majd sikeres tesztjére.
4. **Hatókör**: kizárólag cherry-pick — a minimális javítás, refaktorálás és kapcsolódó mellékes módosítások nélkül.

A kihagyott lefedettségi/küszöbkövetési felületet a release ágon következő teljes futtatás
újra ellenőrzi (folyamatosan zöld release) — a folyamat csak a VÁRAKOZÁST hagyja ki, az ellenőrzést soha.
A csak teszteket érintő módosítások (minden fájl a `tests/` alatt, egy sem a `tests/e2e/` alatt)
automatikusan, címke nélkül is kihagyják az E2E-mátrixot.

## Részletes ellenőrzőlista

### Kiadás előtt

- [ ] A kiadáshoz tartozó összes PR be van olvasztva a `release/vX.Y.0` ágba
- [ ] Az ehhez a verzióhoz tartozó összes nyitott Linear-/issue-elem le van zárva, vagy át van helyezve a következő mérföldkőhöz
- [ ] A CI zöld a `release/vX.Y.0` ágon
- [ ] Nincsenek `TODO(release)` jelölők a kódban: `grep -r "TODO(release)" src/ open-sse/`
- [ ] A Docker alaplemezkép naprakész (jelenleg `node:24.15.0-trixie-slim`)

### Verzió és változásnapló

- [ ] Futtassa a `/version-bump-cc <patch|minor|major>` parancsot (Claude Code-képesség)
  - Frissíti a verziót a `package.json` és `electron/package.json` fájlokban
  - Újragenerálja a `CHANGELOG.md` fájlt az utolsó címke óta létrejött git-commitokból
  - Frissíti a README.md jelvényeit
- [ ] Kézzel ellenőrizze a CHANGELOG.md fájlt, és szükség esetén tisztázza a commitüzeneteket
- [ ] Győződjön meg arról, hogy a `CHANGELOG.md` legújabb semver-szakasza megegyezik a `package.json` verziójával
- [ ] A következő munkák számára maradjon a `## [Unreleased]` a változásnapló első szakasza
- [ ] Frissítse a `docs/openapi.yaml` fájlt → az `info.version` értékének meg kell egyeznie a `package.json` verziójával

### Kódminőség

- [ ] `npm run lint` — 0 hiba (a figyelmeztetések már korábban is léteztek)
- [ ] `npm run typecheck:core` — hibamentes
- [ ] `npm run typecheck:noimplicit:core` — hibamentes (szigorú)
- [ ] `npm run check:cycles` — nincsenek körkörös függőségek
- [ ] `npm run check:any-budget:t11` — a kereten belül
- [ ] `npm run check:route-validation:t06` — hibamentes
- [ ] `npm run check:node-runtime` — a támogatott minimális futtatókörnyezeti követelmény teljesül (`>=22.22.2 <23`, `>=24.0.0 <27`, a `src/shared/utils/nodeRuntimeSupport.ts` fájlban található `SUPPORTED_NODE_RANGE` szerint; összhangban a `package.json` `engines` mezőjével)

### Tesztelés

- [ ] `npm run test:unit` — sikeres
- [ ] `npm run test:vitest` — sikeres (MCP-kiszolgáló, autoCombo, gyorsítótár)
- [ ] `npm run test:coverage` — a 60/60/60/60 küszöb teljesül (utasítások/sorok/függvények/elágazások)
- [ ] `npm run test:integration` — sikeres (ha a módosítások érintik az adatbázist / kezelőket)
- [ ] `npm run test:combo:matrix` — sikeres (kombinált stratégiamátrix: determinisztikusan igazolja mind a 19 nyilvános útválasztási stratégia kiválasztási döntéseit; a kombinált útválasztás, a stratégiafeloldás vagy a tartaléklogika módosításakor futtatandó)
- [ ] `RUN_COMBO_LIVE=1 npm run test:combo:live` — **opcionális/kézi** (kapuval védett, valódi upstreamet használó füstteszt; csak olvasható adatbázis-pillanatképet tölt be a `root@192.168.0.15` VPS-ről; valódi szolgáltatókat ér el, és krediteket használ; CI-ben soha nem fut; a kapu nélkül szabályosan kimarad)
- [ ] `npm run test:combo:live:vps` — **opcionális/kézi** (3. fázisú élő VPS-füstteszt: 7 HTTP-forgatókönyv az élő `.15` kiszolgáló ellen egyszerű Node ESM-en keresztül; `ssh root@192.168.0.15` szükséges hozzá; kizárólag `__live_test__*` kombinációkat hoz létre és töröl; valódi szolgáltatókat ér el; CI-ben soha nem fut)
- [ ] `npm run test:e2e` — sikeres (felhasználói felületet érintő módosítások)
- [ ] `npm run test:protocols:e2e` — sikeres (MCP/A2A-módosítások)
- [ ] `npm run test:ecosystem` — sikeres

### Hookok (Husky által ellenőrizve)

A Husky-hookok a `.husky/` könyvtárban találhatók, és automatikusan lefutnak a git-műveletek során.

- **pre-commit:** `npx lint-staged + node scripts/check/check-docs-sync.mjs + npm run check:any-budget:t11`
- **pre-push:** gyors, determinisztikus ellenőrzések — `npm run check:any-budget:t11 && npm run check:tracked-artifacts` (aktiválva: 2026-06-13). Szándékosan nem tartalmazza a `test:unit` feladatot (lassú; a CI `test-unit` feladata lefedi).
  - A release ágak pusholása előtt futtassa kézzel az `npm run test:unit` parancsot.

Ha egy hook sikertelen: javítsa a kiváltó problémát, ne kerülje meg a `--no-verify` kapcsolóval.

### Conventional Commits

Minden kiadásba kerülő commitnak a `type(scope): subject` formátumot kell követnie.

**Érvényes típusok:** `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `style`, `ci`

**Érvényes hatókörök:** `db`, `sse`, `oauth`, `dashboard`, `api`, `cli`, `docker`, `ci`, `mcp`, `a2a`, `memory`, `skills`, `cloud-agent`, `guardrails`, `compression`, `auto-combo`, `resilience`, `providers`, `executors`, `translator`, `domain`, `authz`

Visszamenőleg nem kompatibilis módosítások: adjon hozzá `BREAKING CHANGE:` láblécet vagy `!` jelet a hatókör után (például `feat(api)!: drop /v0`).

### Dokumentáció

- [ ] Az `npm run check:docs-sync` sikeresen lefut (a pre-commit automatikusan futtatja)
- [ ] Az `npm run check:docs-all` sikeresen lefut (gyűjtőparancs: docs-sync + docs-counts + env-doc-sync + deprecated-versions + doc-links)
- [ ] Az `npm run check:env-doc-sync` 0-s kilépési kóddal fejeződik be — a kód ↔ `.env.example` ↔ `docs/reference/ENVIRONMENT.md` környezeti szerződés sértetlen
- [ ] Az `npm run check:doc-links` 0-s kilépési kóddal fejeződik be — az átszervezés után nincsenek hibás belső markdown-hivatkozások
- [ ] A `docs/architecture/ARCHITECTURE.md` áttekintve a tárolási/futásidejű eltérések szempontjából
- [ ] A `docs/guides/TROUBLESHOOTING.md` áttekintve a környezeti változók és az üzemeltetési eltérések szempontjából
- [ ] Ha a `.env.example` módosult: a `docs/reference/ENVIRONMENT.md` frissítve
- [ ] Ha az új funkció rendelkezik felhasználói felülettel: a `docs/guides/USER_GUIDE.md` megemlíti
- [ ] Ha az új funkció rendelkezik API-val: a `docs/reference/API_REFERENCE.md` + `docs/openapi.yaml` frissítve
- [ ] Ha az új funkció egy modul: létezik hozzá külön `docs/<MODULE>.md`
- [ ] Ha visszafelé nem kompatibilis változás történt: a `docs/guides/TROUBLESHOOTING.md` tartalmaz migrációs megjegyzést

### i18n

- [ ] Az `npm run i18n:check` 0-s kilépési kóddal fejeződik be — a fordítási állapot (`.i18n-state.json`) szinkronban van a forrásdokumentációval (szigorú módban nincsenek eltérő források; a figyelmeztetési mód tájékoztató jelzése elfogadható az utolsó pillanatban végzett dokumentációs javításokhoz, de címkézés előtt az eredménynek 0-nak kell lennie)
- [ ] Az `npm run i18n:check-ui-coverage` 0-s kilépési kóddal fejeződik be — minden felhasználói felületi területi beállítás eléri vagy meghaladja a 80%-os lefedettségi küszöböt
- [ ] Az `npm run i18n:sync-ui:dry` 0 hiányzó kulcsot jelez mind a 42 területi beállításban
- [ ] Ha az angol forrásdokumentáció módosult, címkézés előtt futtassa az `npm run i18n:run` parancsot (az `.env` fájlban megadott `OMNIROUTE_TRANSLATION_API_KEY` szükséges)
- [ ] A kisebb fordítási hozzájárulások elhalaszthatók a következő kiadásig (kövesse nyomon a CHANGELOG-ban)

### Adatbázis-migrációk

- [ ] Ha a `src/lib/db/migrations/` új fájlokat tartalmaz:
  - [ ] Minden migráció idempotens (`CREATE TABLE IF NOT EXISTS` stb.)
  - [ ] A migrációk tranzakciókba vannak csomagolva
  - [ ] A számozás helyes (nincsenek hézagok a sorrendben)
- [ ] Tesztelés friss telepítésen: törölje a `~/.omniroute/omniroute.db` fájlt, majd futtassa az `npm run dev` parancsot
- [ ] Tesztelés meglévő telepítésen: készítsen biztonsági másolatot az adatbázisról, futtassa a migrációt, majd ellenőrizze a sémát
- [ ] A WAL-fájlok (`-wal`, `-shm`) megfelelően kezelve, ha a migráció újraírja a táblákat

### Szolgáltatói katalógus (Zod által validálva)

- [ ] A `src/shared/constants/providers.ts` Zod-sémája betöltéskor érvényes
  - [ ] Minden szolgáltató rendelkezik a kötelező mezőkkel (`id`, `label`, `kind` stb.)
  - [ ] Az új ingyenes szolgáltatóknál a `freeNote` meg van adva
  - [ ] Az OAuth-szolgáltatók `oauthConfig` beállítása regisztrálva van a `src/lib/oauth/constants/oauth.ts` fájlban
- [ ] Új szolgáltató hozzáadása esetén: megfelelő végrehajtó az `open-sse/executors/` könyvtárban
- [ ] Nem OpenAI-formátum esetén: fordító az `open-sse/translator/` könyvtárban
- [ ] A modellek regisztrálva vannak az `open-sse/config/providerRegistry.ts` fájlban
- [ ] A `tests/unit/` egységtesztjei lefedik a szolgáltatók osztályozását és az útválasztást

### Asztali alkalmazás (Electron)

Ha az `electron/` módosult:

- [ ] Az `npm run electron:smoke:packaged` sikeresen lefut
- [ ] A buildek tesztelve legalább az alábbiak egyikére: `:win`, `:mac`, `:linux`
- [ ] A kódaláírási tanúsítványok nem jártak le (ha történik aláírás)
- [ ] Az `electron/package.json` verziója megegyezik a gyökérszintű `package.json` verziójával
- [ ] Az automatikus frissítési csatorna mutatója frissítve, ha a kiadás a `stable` csatornára történik

### Buildkönyvtárak felépítése

A tároló három különálló kimeneti könyvtárat használ — soha ne keverje össze őket:

| Könyvtár  | Rendeltetés                                                     | Követett?        |
| --------- | --------------------------------------------------------------- | ---------------- |
| `src/`    | Alkalmazás forráskódja (TypeScript / TSX)                       | Igen             |
| `.build/` | Köztes buildfájlok — a `next build` kimenete (`distDir`)        | Nem (gitignored) |
| `dist/`   | Terjeszthető npm-csomag — az `assembleStandalone` állítja össze | Nem (gitignored) |

> **Üzemeltetői megjegyzés:** a távoli VPS lemezképkönyvtára továbbra is `/usr/lib/node_modules/omniroute/app/`.
> Csak a tárolón **belüli** buildkimenet helye változott (`app/` → `dist/`). A telepítési folyamatok rsync használatával
> a `dist/` tartalmát a távoli `app/` könyvtárba másolják — nincs szükség a VPS elérési útjainak módosítására.

**Egyszeri buildfolyamat:**

```
npm run build:release
  └─ rm -rf .build dist          (tisztítás)
  └─ next build → .build/next/   (köztes fájlok)
  └─ assembleStandalone          (az önálló csomag + statikus fájlok + nyilvános fájlok + natív összetevők másolása → dist/)
  └─ writes dist/BUILD_SHA       (HEAD ellenőrzőjel)
```

Telepítéshez NE futtassa az `npm run build` parancsot, majd külön az `npm run build:cli` parancsot — használja az
`npm run build:release` parancsot, amely egyetlen paranccsal tiszta újrabuildelést végez, és létrehozza az ellenőrzőjelet.

### Műtermék ellenőrzése

- [ ] Az `npm run build:release` sikeresen lefut, és `dist/BUILD_SHA` == `git rev-parse --short HEAD`
- [ ] Az `npm run check:pack-artifact` tiszta eredményt ad — nincs `app.__qa_backup`, `scripts/scratch`, `package-lock.json` vagy más helyi maradvány
- [ ] A `dist/server.js` a build után létezik
- [ ] Opcionális helyi, csomagolt futtatókörnyezeti füstteszt: az `npm run dev:candidate -- build` után az `npm run dev:candidate -- validate` elindítja a csomagolt tarballt egy elkülönített `DATA_DIR` használatával, és ellenőrzi az `/api/health` + `/v1/models` végpontokat (lásd: [Hozzájárulási aranyút](CONTRIBUTION_GOLDEN_PATH.md#local-candidate-loop))

### Címkézés és kiadás

- [ ] Futtassa a `/generate-release-cc` parancsot (Claude Code-készség):
  - Létrehozza a `vX.Y.Z` címkét
  - Feltölti a címkét és az ágat
  - Megnyitja a GitHub-kiadást a változásnapló szövegével
  - Csatolja az Electron-telepítőket (ha elkészültek)
- [ ] Vagy manuálisan:
  ```bash
  git tag -a vX.Y.Z -m "Release vX.Y.Z"
  git push origin vX.Y.Z
  gh release create vX.Y.Z --notes-from-tag
  ```

### Telepítés

A telepítési folyamatok a könnyű rsync-megoldást használják — nincs `npm pack`, nincs `npm i -g`:

- [ ] Használd a célkörnyezetnek megfelelő telepítési skillt:
  - `/deploy-vps-local-cc` — helyi VPS (192.168.0.15)
  - `/deploy-vps-akamai-cc` — Akamai VPS (69.164.221.35)
  - `/deploy-vps-both-cc` — mindkettő
- [ ] Telepítés előtt ellenőrizd, hogy `dist/BUILD_SHA` == `git rev-parse --short HEAD`
- [ ] A buildet olyan helyen kell futtatni, ahol a `node_modules` valódi (fő munkapéldány vagy `npm ci` használatával előkészített worktree — NEM szimbolikus hivatkozással csatolt worktree)
- [ ] Végezz smoke tesztet a telepített példányon:
  - Nyisd meg a `/dashboard/health` oldalt → ellenőrizd, hogy a verziókarakterlánc megfelel-e a kiadásnak
  - Futtass egy `/v1/chat/completions` kérést egy ismert szolgáltatóval
  - Ellenőrizd, hogy az `/api/monitoring/health` `CLOSED` állapotú megszakítókat ad-e vissza
  - Ellenőrizd, hogy az MCP-transzportok válaszolnak-e (`/mcp` HTTP, `/mcp-sse` SSE)

### Kiadás után

- [ ] Futtasd a `/capture-release-evidences-cc` parancsot (Claude Code skill)
  - WebP-képernyőképeket/-felvételeket készít az új funkciókról
  - Csatolja őket a kiadási megjegyzésekhez/blogbejegyzéshez
- [ ] Frissítsd a GitHub Discussions-oldalt/Discordot a kiadási bejelentéssel
- [ ] Nyiss mérföldkövet a következő verzióhoz
- [ ] Ha kritikus fontosságú: tűzd ki a beszélgetést, vagy tedd közzé a `news.json` fájlban az alkalmazáson belüli szalagcímhez

### A Radar nyilvános indulásának feltételei

A Radar bejelentése szándékosan `active: false` értékkel lett véglegesítve. Az aktiválás külön
módosításként történik, miután az alábbi elemek mindegyike igazolt:

- [ ] Minden egymásra épülő Radar PR be lett olvasztva, és a kiadás csúcsverziójának CI-je zöld
- [ ] Telepítsd és végezz smoke tesztet a nyílt forráskódú Radar-útvonalakon úgy, hogy a `RADAR_ENABLED` alapértelmezés szerint továbbra is ki legyen kapcsolva
- [ ] Végezz smoke tesztet a `GET /planos`, `/termos`, `/privacidade` és `/reembolso` útvonalakon a megnevezett Radar-gazdagépen
- [ ] Rögzítsd az üzemeltető személyazonosságát/kapcsolattartási adatait/címét, valamint a tulajdonos által jóváhagyott jogi felülvizsgálatot a privát szolgáltatásban
- [ ] Teszteld a Stripe Checkoutot és az aláírt webhookot kizárólag tesztmódban
- [ ] Tesztelj egy titkosított tranzakciós e-mail-kézbesítést a jóváhagyott feladóval/domainnel
- [ ] Igazold a biztonsági mentés visszaállítását és egy felügyelt, költségkorlátos kutatási futtatást
- [ ] Hagyd jóvá a BRL/PIX felülvizsgálati szabályzatot az adományigazolások elfogadása előtt
- [ ] Csak az előző feltételek teljesülése után engedélyezd a nyilvános Checkoutot, majd aktiváld az új `news.json`-azonosítót
- [ ] Ellenőrizd, hogy a Home szalagcíme lokalizált szöveget használ-e, és hogy egy új azonosító ismét megjelenik-e egy régebbi azonosító bezárása után

## Beágyazott szolgáltatások füsttesztje (v3.8.4+)

A beágyazott szolgáltatásokat érintő módosításokat tartalmazó kiadások közzététele előtt ellenőrizze a következőket:

### Indítás friss adatbázissal (észleli a migrációs ütközéseket — a v3.8.4 gyorsjavítása után hozzáadva)

- [ ] `DATA_DIR=$(mktemp -d) npm start &` — várjon 10 másodpercet az indulásra
- [ ] A `curl -s http://127.0.0.1:20128/api/services/9router/status | jq '.tool'` eredménye `"9router"` (NEM 404, NEM 500). Megerősíti, hogy a `071_services.sql` migráció alkalmazva lett, és a sor létrejött.
- [ ] A `sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(version_manager);" | grep -E "provider_expose|logs_buffer_path|last_sync_at"` 3 sort ad vissza.
- [ ] A `sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(webhooks);" | grep -E "kind|metadata_encrypted"` 2 sort ad vissza (ellenőrzi, hogy a `070_webhooks_kind_metadata.sql` alkalmazva lett).
- [ ] A `node --import tsx/esm --test tests/unit/db/no-migration-collisions.test.ts` sikeresen lefut — védelmet nyújt a jövőbeli ütközésekkel szemben.

### 9Router

- [ ] A `POST /api/services/9router/install` 2 percen belül 200-as választ ad vissza, benne az `installedVersion` mezővel
- [ ] A `POST /api/services/9router/start` 30 másodpercen belül 200-as választ és `state: "running"` állapotot ad vissza
- [ ] A `GET /api/services/9router/status` `health: "healthy"` állapotot jelez
- [ ] A `POST /v1/chat/completions` kérés `"model": "9router/auto/..."` értékkel 200-as választ ad vissza (teljes körű útválasztás a 9Routeren keresztül)
- [ ] A `GET /dashboard/providers/services/9router/embed/dashboard` megjeleníti a 9Router natív felhasználói felületét a proxyn belül (nem közvetlen `127.0.0.1:port` iframe-ben)
- [ ] A `POST /api/services/9router/rotate-key` `{ keyRotated: true }` választ ad vissza, és a szolgáltatás problémamentesen újraindul
- [ ] A `POST /api/services/9router/stop` 200-as választ és `state: "stopped"` állapotot ad vissza
- [ ] A `GET /api/services/9router/logs?tail=50` SSE-adatfolyamot ad vissza, amely egy friss sorokat tartalmazó `snapshot` eseményt tartalmaz
- [ ] A `npm` nélküli PATH környezetben végzett telepítés 500-as választ ad vissza egy felhasználóbarát (veremkiírást nem tartalmazó) hibaüzenettel

### CLIProxyAPI

- [ ] A `POST /api/services/cliproxy/install` 2 percen belül 200-as választ ad vissza
- [ ] A `POST /api/services/cliproxy/start` 30 másodpercen belül 200-as választ és `state: "running"` állapotot ad vissza
- [ ] A `GET /api/services/cliproxy/status` `health: "healthy"` állapotot jelez
- [ ] A `POST /api/services/cliproxy/stop` 200-as választ és `state: "stopped"` állapotot ad vissza
- [ ] A `GET /api/services/cliproxy/logs?tail=50` SSE-adatfolyamot ad vissza

### Biztonsági regresszió

- [ ] A `curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/9router/start` `403 LOCAL_ONLY` választ ad vissza
- [ ] A `curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/cliproxy/start` `403 LOCAL_ONLY` választ ad vissza
- [ ] Az `/api/services/*` hibaválaszai nem tartalmaznak `err.stack` értéket vagy abszolút fájlelérési utakat

## v3.8.0+ ellenőrzések

Bármely v3.8.x kiadás közzététele előtt ellenőrizze ezeket a további elemeket:

- [ ] Az `omniroute --tray` elindul macOS rendszeren (a systray2 telepítve van a `~/.omniroute/runtime/` könyvtárba)
- [ ] Az `omniroute --tray` elindul Linux rendszeren (DISPLAY szükséges; kulturált hibaüzenet jelenik meg, ha nincs beállítva)
- [ ] Az `omniroute --tray` elindul Windows rendszeren (PowerShell NotifyIcon, további binárisok nélkül)
- [ ] Az `omniroute config tray enable` létrehozza az automatikus indítási bejegyzést; a letiltás eltávolítja azt
- [ ] Az `npm install -g omniroute@<this-version>` végzetes kilépés nélkül futtatja a telepítés utáni lépést
- [ ] A frissítési folyamat megőrzi az opcionális függőségeket: az `omniroute update --apply` és az automatikus frissítő
      az `npm install -g … --include=optional` parancsot futtatja, így az `optionalDependencies` (better-sqlite3,
      keytar, tls-client és az llmlingua SLM-verem: `@atjsh/llmlingua-2@2.0.5`,
      `js-tiktoken`) megmarad a frissítés után. Az ultra `modelPath` SLM-szinthez szükség van továbbá a
      tinybert modellre, amely az első használatkor automatikusan letöltődik a `${DATA_DIR}/models/llmlingua` könyvtárba. A telepítés utáni lépés
      (`scripts/build/colocateOptionals.mjs`) ezután az SLM opcionális függőségi láncát a
      `dist/node_modules` könyvtárba helyezi, hogy a feldolgozó EGYETLEN `@huggingface/transformers` ^4.2.0
      példányt oldjon fel — az önálló nyomkövetési csomag csak a transformers csomagot tartalmazza, a dinamikusan importált
      opcionális függőségeket nem, ezért enélkül a feldolgozó a gyökér transformers példányával töltené be a llmlingua-2 csomagot,
      az SLM-szint pedig észrevétlenül tartalék működésre váltana.
- [ ] Az `omniroute status` `.env` nélkül is működik (CLI-token útvonala, csak loopback)
- [ ] A `curl http://localhost:20128/api/shutdown` 401-es választ ad vissza (mindig védett útvonal)
- [ ] A `curl -H "host: evil.com" http://localhost:20128/api/mcp/sse` 401-es választ ad vissza (loopback-védelem)
- [ ] Az SQLite-futtatókörnyezet az első futtatáskor `bundled` értékre oldódik fel (a mellékelt bináris érvényes az adott platformon)
- [ ] Az SQLite-futtatókörnyezet `runtime` értékre vált vissza, amikor a `node_modules/better-sqlite3` törölve van
- [ ] Az intelligens MCP-szűrő tömöríti a valódi `playwright-mcp browser_snapshot` kimenetet (≥50%-os csökkentés)
- [ ] Mind a 10 `skills/omniroute*/SKILL.md` fájl nyilvánosan elérhető nyers GitHub URL-en keresztül
- [ ] Az első beállításkor a bevezető varázsló megjeleníti a „Hogyan működik” szintbemutató lépést
- [ ] A kezdőoldali irányítópult szintlefedettségi vezérlője megjeleníti a konfigurált/aktív darabszámokat

---

## 3.9.0 LTS elágazás (próba a 3.8.58-ban)

A v3.8.59 után a következő verzió a 3.9.0, amelynek csúcsából két hosszú életű ág jön létre:
`stable/v3` (a v3 LTS-vonal, npm `latest`) és `develop` (v4, 4.0.0-ra emelve, npm
`nightly`). Az ág-/csatornamodellt, az előre portolást és a címkéket a
[RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) tartalmazza; a terv a [ROADMAP](../../ROADMAP.md) dokumentumban található (3. fázis). Az elágazás egyszer fut le;
a 3.8.58 egy forkban próbálja el a teljes folyamatot, a 3.8.59 pedig a
[GO/NO-GO ellenőrzőlistával](./LTS_GO_NO_GO.md) zárul.

### Próbafuttatás (csak olvasás, bármikor biztonságos)

```bash
npm run release:dry-run-lts-cut                       # a valódi elágazás: 3.9.0 a HEAD-ből, előző címke: v3.8.59
npm run release:dry-run-lts-cut -- --from <3.9.0-tip> # a forrás-commit rögzítése
```

A `scripts/release/dry-run-lts-cut.mjs` nem hajt végre semmit: beolvassa a git és a `gh` adatait, majd kiírja a
teljes folyamatot — az előfeltételeket (a forrás feloldható, a forrástároló teljes előzményekkel rendelkezik —
egy sekély klón nem tudja feltölteni a `stable/v3` ágat, mert a fogadó oldal az első
beillesztett szülőnél elutasítja a csomagot, ezért teljes klónból végezze az elágazást, vagy előbb futtassa a `git fetch --unshallow origin` parancsot —
az előző címke létezik, a `package.json` a célverziót tartalmazza, nyitva van egy `release-freeze` ügy, nincs nyitott
`Release branch not green` ügy
egy meglévő kiadási ágon — egy nem létező ág `?` ismeretlen állapotot jelez, soha nem
zöld — a Mergify `release` várólistája konfigurálva van (G11: `queue_rules`, `checks_timeout`,
`queue` címke), a `release/*` szabálykészlet továbbra is tiltja a törlést és a kényszerített feltöltést, valamint
a `stable/v3` és a `develop` még nem létezik), a két áglépést, hogy mely inaktív munkafolyamatok
triggerei és `if:` feltételei válnak igazzá (és melyek maradnak egy tárolóváltozó által korlátozva vagy
a kanonikus tárolóhoz rögzítve), a várt dist-tageket (`latest` → 3.9.0, a `next` és a
`nightly` üres), valamint a visszaállítást. A `0` kilépési kód jelentése `RESULT: READY`, az `1` azt jelzi, hogy egy blokkoló előfeltétel
meghiúsult (`✗`), a `2` pedig használati hibát jelent. Az `--advisory <id,...>` egy ellenőrzést figyelmeztetéssé (`!`)
minősít vissza anélkül, hogy elrejtené.

A valódi elágazás próbafuttatását akkor végezze el, amikor a 3.9.0 kiadás befagyasztása még érvényben van — az ágak
a címke után és azelőtt jönnek létre, hogy a 12c fázis feloldaná a befagyasztást.

### 3.8.58-próba (csak forkban)

```bash
# 1. Próbafuttatás az aktuális csúcson, a próba paramétereivel
npm run release:dry-run-lts-cut -- --target-version 3.8.58 --previous-tag v3.8.57 \
  --advisory freeze,base-green

# 2. Végrehajtás egy FORK távoli tárolóján (az origin, illetve bármely olyan távoli tároló,
#    amelynek URL-je a kanonikus tárolóra mutat, vissza lesz utasítva; minden lépés megerősítést kér a terminálon)
git remote add rehearsal https://github.com/<you>/OmniRoute.git
node scripts/release/dry-run-lts-cut.mjs --execute --remote rehearsal \
  --target-version 3.8.58 --previous-tag v3.8.57 --advisory freeze,base-green

# 3. Az inaktív munkafolyamatok kipróbálása a forkban (workflow_dispatch ott, ahol a próbafuttatás
#    a kanonikus tárolóhoz való rögzítést jelez), majd visszaállítás
node scripts/release/dry-run-lts-cut.mjs --execute --rollback --remote rehearsal \
  --target-version 3.8.58 --previous-tag v3.8.57 --advisory freeze,base-green
```

A develop verzióemelő commit git plumbing használatával készül (a munkafa érintése nélkül), és
ugyanazt az öt fájlt frissíti, mint egy ciklusnyitó commit: `package.json`, `open-sse/package.json`,
`electron/package.json`, `package-lock.json` és `docs/openapi.yaml`. A `[4.0.0]`
CHANGELOG-szakasz és annak i18n-tükörpéldányai ezt követően, az első
PR előtt nyílnak meg a `develop` ágon. A szkript soha nem módosítja az npm dist-tageket — ezeket egy ideiglenes csomagon próbálja el.

### PR-előnézeti műtermék (egyszeri build, ugyanazon bájtok előléptetése)

A `.github/workflows/preview-artifact.yml` egyetlen éles tarballt készít egy PR csúcsából, és
pontosan ezt a buildet ellenőrzi (#8084, (a) rész). Csak azonos tárolóból származó PR-ek esetén; semmi nem kerül közzétételre.

```bash
gh workflow run preview-artifact.yml -f pr_number=<N>   # vagy adja hozzá a `preview-artifact` címkét
gh run download <run-id> --name preview-artifact-pr<N>-<sha7> --dir preview
cd preview && sha256sum -c SHA256SUMS
gh attestation verify omniroute-*.tgz --repo diegosouzapw/OmniRoute
npm install -g ./omniroute-*.tgz                          # előnézeti telepítés
```

A futtatás végrehajtja az `npm ci`, `npm run build:release` és `npm run check:pack-artifact` parancsokat, becsomagolja a
tarballt, futtatja az `npm run check:pack-boot` parancsot (ál-hitelesítő adatokkal, ideiglenes adatkönyvtárral), újracsomagolja, és
meghiúsul, ha a kivonat nem azonos; ezután rögzíti az `artifact-identity.json` fájlt (csúcs-SHA, alap-
SHA, lockfile-kivonat, platform, architektúra, node ABI, csomagoló, buildszabályzat —
`scripts/release/artifact-identity.mjs`), majd egy külön feladatban igazolja a tarballt. Egy
előnézet előléptetése az adott tarball telepítését jelenti: soha ne készítsen új buildet a forrásból.

### Az elágazás (3.9.0, a GO után)

1. A GO rögzítve van az [LTS_GO_NO_GO.md](./LTS_GO_NO_GO.md) dokumentumban.
2. Az `npm run release:dry-run-lts-cut -- --from v3.9.0` kiírja a `RESULT: READY` eredményt.
3. Hozza létre kézzel az ágakat az `origin` tárolón a próbafuttatás által kiírt parancsokkal — a
   szkript nem hajlandó feltölteni az `origin` tárolóba. Egy ellenőrzött develop commit újrafelhasználásához először futtassa a
   `--execute` próbát a 3.9.0 csúcson a saját forkja ellen; ez kiírja mindkét SHA-t, és
   ugyanazok a commitok tölthetők fel:

   ```bash
   git push origin <stable-sha>:refs/heads/stable/v3 <develop-sha>:refs/heads/develop
   ```

4. Védd le a `stable/v3` és a `develop` ágakat (szabálykészletek + egyesítési várólista), mielőtt az első PR beérkezik.
5. A nyugalmi állapotban lévő munkafolyamatok az ágak megléte alapján kapcsolnak be: `forward-port.yml` (push a
   `stable/v3` ágra), `validate-stable-pr.yml` (PR-ok a `stable/v3` ágra) és `nightly-v4-build.yml`
   (a `develop` ágat buildeli). Az élesítés előtt állítsd be a `secrets.FORWARD_PORT_TOKEN` adattitkot a repositoryban (hogy a CI fusson a
   forward-port PR-okon); az éjszakai közzététel kikapcsolva marad, amíg a tulajdonos a repository
   `vars.NIGHTLY_PUBLISH` változóját `true` értékre nem állítja, és az npm Trusted Publishing el nem fogadja a
   `nightly-v4-build.yml` fájlt. A csatorna feloldását a `scripts/release/dist-tag.mjs` végzi, ugyanaz a
   feloldó, amelyet az `npm-publish.yml` használ.
6. Ellenőrizd a csatornákat: az `npm view omniroute dist-tags --json` kimenetében a `latest` = 3.9.0, és nincs
   `next` / `nightly`, amíg a v4 közzététele meg nem történik.
7. Visszaállítás, ha szükséges: `git push origin --delete refs/heads/stable/v3 refs/heads/develop`
   és `npm dist-tag add omniroute@3.8.59 latest`.

---

## Visszaállítás

Ha a kiadás kritikus hibát tartalmaz:

1. `gh release edit vX.Y.Z --prerelease` (megjelöli, hogy nem ez a legfrissebb)
2. `git tag -d vX.Y.Z && git push --delete origin vX.Y.Z` (csak akkor, ha a felhasználók még nem kezdték el használni)
3. Vagy: gyorsjavítás a `release/vX.Y.0` ágon → javító kiadás: `vX.Y.(Z+1)`
4. Azonnal tájékoztass mindenkit a GitHub Discussions és a Discord felületén

## Szigorú szabályok

- Soha ne véglegesíts közvetlenül a `main` ágon
- Soha ne használd a `git push --force` parancsot a `main` vagy a `release/*` ágakon
- Soha ne hagyd ki a Husky hookokat (`--no-verify`)
- Soha ne véglegesíts titkos adatokat, hitelesítő adatokat vagy `.env` fájlokat
- A lefedettségnek ≥60/60/60/60 szinten kell maradnia (utasítások/sorok/függvények/elágazások)
- Mindig adj hozzá vagy frissíts teszteket, amikor a `src/`, `open-sse/`, `electron/` vagy `bin/` könyvtárban lévő éles kódot módosítod

## Automatizált szinkronizálási ellenőrzés

PR megnyitása előtt futtasd helyben a dokumentáció szinkronizálási ellenőrzését:

```bash
npm run check:docs-sync
```

A CI ezt az ellenőrzést a `.github/workflows/ci.yml` fájlban is futtatja (lintelési feladat).