OmniRoute/docs/i18n/pl/docs/ops/RELEASE_CHECKLIST.md

Release Checklist (Polski)

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

---

title: "Checklista wydania" version: 3.8.40 lastUpdated: 2026-06-28

Checklista wydania

Ostatnia aktualizacja: 2026-06-28 — v3.8.40 Uproszczony przepływ wydania wykorzystujący skill-e Claude Code do automatyzacji.

Utrzymuj kolejkę/gałąź na zielono między wydaniami: zobacz RELEASE_GREEN.md (rodzina /green-prs + npm run check:release-green + /babysit + nightly). Uruchamianie tego okresowo — a zwłaszcza przed tą checklistą — sprawia, że PR wydania startuje na zielono.

TL;DR

# 1. Zwiększ wersję + wygeneruj CHANGELOG (umiejętność)
/version-bump-cc patch    # lub minor/major

# 2. Uruchom lokalnie kontrolę jakości
npm run check              # lintowanie + testy
npm run test:coverage      # pełna kontrola pokrycia (60/60/60/60)

# 3. Zbuduj i wykonaj test dymny
npm run build
npm run test:e2e           # opcjonalne, ale zalecane

# 4. Wygeneruj wydanie (umiejętność)
/generate-release-cc

# 5. Wdróż (umiejętność)
/deploy-vps-both-cc        # lub akamai-cc / local-cc

# 6. Zarejestruj dowody wydania (umiejętność)
/capture-release-evidences-cc

Zaufane publikowanie npm (domyślne od v3.8.51) — publikowanie etapowe na żądanie, bezpośrednie jako rozwiązanie awaryjne

npm-publish.yml domyślnie publikuje za pośrednictwem zaufanego publikowania npm (OIDC): zadanie stage-npm (hostowane przez GitHub) wymienia token id-token GitHuba na krótkotrwałe poświadczenie npm na potrzeby danego uruchomienia — bez długoterminowego tokena npm w sekretach repozytorium, bez monitu 2FA, z dołączonym poświadczeniem pochodzenia. Jest to obecnie zatwierdzony przez npm sposób obejścia problemu wycofywania tokenów pomijających 2FA; przywraca on w pełni automatyczny przepływ, który projekt miał do v3.8.48, zachowując gwarancję WS1.3 (wyciek tokena nie wystarczy do publikacji — tokena po prostu nie ma).

Konfiguracja jednorazowa (właściciel): npmjs.com → pakiet omniroute → Settings → Trusted Publisher → GitHub: właściciel diegosouzapw, repozytorium OmniRoute, przepływ pracy npm-publish.yml (środowisko: brak). Dopóki ta konfiguracja nie istnieje, automatyczny krok kończy się błędem ENEEDAUTH: uruchom go ponownie z publish_mode=staged (poniżej) lub direct.

Publikowanie etapowe (na żądanie — publish_mode=staged)

Przepływ pracy npm-publish nie publikuje już bezpośrednio: uruchamia spakowane archiwum tar (check:pack-boot), a następnie wykonuje npm stage publish — dokładnie te same bajty są umieszczane w rejestrze, ale nie można ich zainstalować, dopóki właściciel ich nie zatwierdzi. Kontrola 2FA wykonywana przez człowieka została przeniesiona na etap PO weryfikacji, a nie przed nią.

Procedura właściciela po pomyślnym zakończeniu przepływu pracy:

1. npm stage list omniroute — znajdź identyfikator etapu (jest on również wyświetlany w podsumowaniu przepływu pracy).
2. Zweryfikuj pliki umieszczone etapowo (zalecane): npm stage download <id>, a następnie zainstaluj pobrane archiwum tar w tymczasowym prefiksie i uruchom je (npm run check:pack-boot automatyzuje w CI tę samą weryfikację: pakowanie→instalacja→uruchomienie).
3. npm stage approve <id> — monit 2FA JEST publikacją. npm stage reject <id> odrzuca etap.
4. Zabezpieczenie po publikacji: weryfikator po publikacji (WS1.4 planu v3.8.49) instaluje opublikowaną wersję z publicznego rejestru w czystym kontenerze i ją uruchamia.

Awaryjne rozwiązanie zastępcze: workflow_dispatch z publish_mode=direct przywraca starszy, natychmiastowy tryb npm publish (używaj tylko wtedy, gdy samo publikowanie etapowe działa nieprawidłowo; udokumentuj przyczynę).

Jednorazowe wzmocnienie zabezpieczeń (właściciel, npmjs.com): skonfiguruj zaufanego wydawcę dla omniroute w trybie wyłącznie etapowym, aby ujawniony długoterminowy token nie mógł wykonać npm publish bezpośrednio z dowolnego miejsca — CI może jedynie utworzyć etap; publikację może zatwierdzić wyłącznie właściciel za pomocą 2FA.

Procedura postępowania z uszkodzonym artefaktem (bez zmian): npm deprecate omniroute@<bad> "<reason> — use <fixed>" jako domyślna reakcja (kilka minut, działanie odwracalne); npm unpublish tylko w ciągu 72 godzin, gdy nie ma zależnych pakietów, i nigdy jako pierwszy krok. Docker: nigdy nie nadpisuj tagu wersji — wycofanie wersji polega na ponownym wskazaniu przez latest ostatniego prawidłowego skrótu.

Docker Hub latest (wymagane przy każdej publikacji stabilnej wersji SemVer): przepływ pracy docker-publish musi oznaczyć tagiem zarówno X.Y.Z, jak i — gdy should-promote-latest.sh potwierdzi, że jest to najwyższa stabilna wersja SemVer — :latest, używając tego samego skrótu. Po zakończeniu zadania: skrót latest w Hubie musi być zgodny ze skrótem nowej wersji SemVer, a wartość last_updated musi zostać zaktualizowana. Nie pozostawiaj :latest wskazującego na starszą kompilację, gdy informacje o wydaniu opisują poprawki dostępne wyłącznie w git. Przykłady szybkiego startu Compose używają :latest; rozwiązania GitOps powinny nadal przypinać X.Y.Z. Zobacz Kanały wydań Dockera i #10317.

Szybki pas hotfix (etykieta hotfix)

PR z etykietą hotfix pomija ciężką macierz CI (9-shard E2E, coverage ratchet, quality-gate, quality-extended) i zostawia szybkie, wysokosygnałowe bramki: build, unit shards, integration, vitest, lint/typecheck, docs-sync, check:pack-artifact oraz tarball boot-smoke (check:pack-boot). Cel: zieleń w ≤15 min zamiast ~33 min.

Polityka wejścia — wszystkie cztery wymagane (wzorowane na pasach awaryjnych Chromium/VS Code/Node):

1. Severity: produkcja jest zepsuta — opublikowany artefakt pada przy bootcie / poprawka bezpieczeństwa / każdy użytkownik wydania jest dotknięty. „Ważne” to nie „zepsute”.
2. Authority: tylko właściciel repozytorium nakłada etykietę hotfix. Etykieta JEST zatwierdzeniem — nigdy self-serve na PR-ze kampanii.
3. Evidence: treść PR linkuje poprzedni w pełni zielony heavy run (suite, którą pominięte joby by ponownie walidowały) plus własny test poprawki failing-then-passing.
4. Scope: wyłącznie cherry-pick — minimalna poprawka, bez refaktorów, bez ride-alongów.

Pominięta powierzchnia coverage/ratchet jest ponownie walidowana przez kolejny pełny run na gałęzi release (continuous release-green) — pas pomija OCZEKIWANIE, nigdy walidację. Diffy tylko-testowe (wszystkie pliki pod tests/, żaden pod tests/e2e/) pomijają macierz E2E automatycznie, bez żadnej etykiety.

Szczegółowa lista kontrolna

Przed wydaniem

• Wszystkie PR-y przeznaczone do tego wydania zostały scalone z release/vX.Y.0
• Wszystkie otwarte elementy Linear/zgłoszenia dotyczące tej wersji zostały zamknięte lub przeniesione do następnego kamienia milowego
• CI działa poprawnie na gałęzi release/vX.Y.0
• Brak znaczników TODO(release) w kodzie: grep -r "TODO(release)" src/ open-sse/
• Bazowy obraz Dockera jest aktualny (obecnie node:24.15.0-trixie-slim)

Wersja i dziennik zmian

• Uruchom /version-bump-cc <patch|minor|major> (umiejętność Claude Code)
  • Aktualizuje wersje w package.json, electron/package.json
  • Ponownie generuje CHANGELOG.md na podstawie commitów git od ostatniego tagu
  • Aktualizuje odznaki w README.md
• Ręcznie przejrzyj CHANGELOG.md i w razie potrzeby uporządkuj komunikaty commitów
• Upewnij się, że najnowsza sekcja semver w CHANGELOG.md odpowiada wersji w package.json
• Zachowaj ## [Unreleased] jako pierwszą sekcję dziennika zmian przeznaczoną na nadchodzące prace
• Zaktualizuj docs/openapi.yaml → info.version musi odpowiadać wersji w package.json

Jakość kodu

• npm run lint — 0 błędów (ostrzeżenia istniały już wcześniej)
• npm run typecheck:core — bez problemów
• npm run typecheck:noimplicit:core — bez problemów (tryb ścisły)
• npm run check:cycles — brak zależności cyklicznych
• npm run check:any-budget:t11 — w ramach limitu
• npm run check:route-validation:t06 — bez problemów
• npm run check:node-runtime — spełniona minimalna obsługiwana wersja środowiska uruchomieniowego (>=22.22.2 <23, >=24.0.0 <27, zgodnie z SUPPORTED_NODE_RANGE w src/shared/utils/nodeRuntimeSupport.ts; zgodne z engines w package.json)

Testowanie

• npm run test:unit — zakończone powodzeniem
• npm run test:vitest — zakończone powodzeniem (serwer MCP, autoCombo, pamięć podręczna)
• npm run test:coverage — spełniony próg 60/60/60/60 (instrukcje/wiersze/funkcje/gałęzie)
• npm run test:integration — zakończone powodzeniem (jeśli zmiany dotyczą bazy danych / procedur obsługi)
• npm run test:combo:matrix — zakończone powodzeniem (macierz strategii combo: deterministycznie potwierdza decyzje wyboru wszystkich 19 publicznych strategii routingu; uruchamiaj przy zmianach w routingu combo, rozwiązywaniu strategii lub logice awaryjnej)
• RUN_COMBO_LIVE=1 npm run test:combo:live — opcjonalne/ręczne (warunkowy test dymny z rzeczywistymi usługami nadrzędnymi; pobiera z VPS root@192.168.0.15 migawkę bazy danych tylko do odczytu; korzysta z rzeczywistych dostawców i zużywa kredyty; nigdy nie jest uruchamiany w CI; bez warunku jest prawidłowo pomijany)
• npm run test:combo:live:vps — opcjonalne/ręczne (test dymny na żywo VPS fazy 3: 7 scenariuszy HTTP względem działającego serwera .15 za pomocą zwykłego Node ESM; wymaga ssh root@192.168.0.15; tworzy/usuwa wyłącznie kombinacje __live_test__*; korzysta z rzeczywistych dostawców; nigdy nie jest uruchamiany w CI)
• npm run test:e2e — zakończone powodzeniem (zmiany interfejsu użytkownika)
• npm run test:protocols:e2e — zakończone powodzeniem (zmiany MCP/A2A)
• npm run test:ecosystem — zakończone powodzeniem

Hooki (zweryfikowane przez Husky)

Hooki Husky znajdują się w .husky/ i są uruchamiane automatycznie podczas operacji git.

• pre-commit: npx lint-staged + node scripts/check/check-docs-sync.mjs + npm run check:any-budget:t11
• pre-push: szybkie, deterministyczne kontrole — npm run check:any-budget:t11 && npm run check:tracked-artifacts (aktywowane 2026-06-13). Celowo pomijają test:unit (wolne; objęte zadaniem CI test-unit).
  • Przed wypchnięciem gałęzi wydania uruchom ręcznie npm run test:unit.

Jeśli hook zakończy się niepowodzeniem: napraw przyczynę problemu, nie omijaj go za pomocą --no-verify.

Conventional Commits

Wszystkie commity przeznaczone do wydania muszą być zgodne z formatem type(scope): subject.

Prawidłowe typy: feat, fix, refactor, docs, test, chore, perf, style, ci

Prawidłowe zakresy: db, sse, oauth, dashboard, api, cli, docker, ci, mcp, a2a, memory, skills, cloud-agent, guardrails, compression, auto-combo, resilience, providers, executors, translator, domain, authz

Zmiany niekompatybilne wstecznie: dodaj stopkę BREAKING CHANGE: lub ! po zakresie (np. feat(api)!: drop /v0).

Dokumentacja

• npm run check:docs-sync kończy się powodzeniem (uruchamiane automatycznie przez pre-commit)
• npm run check:docs-all kończy się powodzeniem (kontrola zbiorcza: docs-sync + docs-counts + env-doc-sync + deprecated-versions + doc-links)
• npm run check:env-doc-sync kończy się kodem 0 — kontrakt zmiennych środowiskowych między kodem ↔ .env.example ↔ docs/reference/ENVIRONMENT.md pozostaje spójny
• npm run check:doc-links kończy się kodem 0 — brak uszkodzonych wewnętrznych odwołań Markdown po zmianie struktury
• Plik docs/architecture/ARCHITECTURE.md został sprawdzony pod kątem rozbieżności dotyczących pamięci masowej/środowiska uruchomieniowego
• Plik docs/guides/TROUBLESHOOTING.md został sprawdzony pod kątem rozbieżności dotyczących zmiennych środowiskowych i działania systemu
• Jeśli zmieniono .env.example: zaktualizowano docs/reference/ENVIRONMENT.md
• Jeśli nowa funkcja ma interfejs użytkownika: wspomniano o niej w docs/guides/USER_GUIDE.md
• Jeśli nowa funkcja ma API: zaktualizowano docs/reference/API_REFERENCE.md + docs/openapi.yaml
• Jeśli nowa funkcja jest modułem: istnieje dedykowany plik docs/<MODULE>.md
• Jeśli jest to zmiana niekompatybilna wstecznie: docs/guides/TROUBLESHOOTING.md zawiera informację o migracji

i18n

• npm run i18n:check kończy się kodem 0 — stan tłumaczeń (.i18n-state.json) jest zsynchronizowany z dokumentami źródłowymi (brak rozbieżnych źródeł w trybie ścisłym; ostrzeżenie w trybie ostrzegawczym jest dopuszczalne w przypadku wprowadzanych w ostatniej chwili poprawek dokumentacji, ale przed utworzeniem tagu wynik powinien wynosić 0)
• npm run i18n:check-ui-coverage kończy się kodem 0 — każdy język interfejsu użytkownika osiąga próg pokrycia wynoszący co najmniej 80%
• npm run i18n:sync-ui:dry zgłasza 0 brakujących kluczy we wszystkich 42 językach
• Jeśli zmieniono źródłową dokumentację angielską, przed utworzeniem tagu uruchom npm run i18n:run (wymaga OMNIROUTE_TRANSLATION_API_KEY w .env)
• Wkład w tłumaczenia można odłożyć do następnego wydania, jeśli zmiany są niewielkie (odnotuj to w CHANGELOG)

Migracje bazy danych

• Jeśli src/lib/db/migrations/ zawiera nowe pliki:
  • Każda migracja jest idempotentna (CREATE TABLE IF NOT EXISTS itd.)
  • Migracje są opakowane w transakcje
  • Numeracja jest prawidłowa (brak luk w sekwencji)
• Przetestuj na świeżej instalacji: usuń ~/.omniroute/omniroute.db i uruchom npm run dev
• Przetestuj na istniejącej instalacji: wykonaj kopię zapasową bazy danych, uruchom migrację i zweryfikuj schemat
• Pliki WAL (-wal, -shm) są obsługiwane prawidłowo, jeśli migracja przepisuje tabele

Katalog dostawców (walidowany przez Zod)

• Schemat Zod w src/shared/constants/providers.ts jest prawidłowy podczas ładowania
  • Wszyscy dostawcy mają wymagane pola (id, label, kind itd.)
  • Dla nowych bezpłatnych dostawców podano freeNote
  • Dostawcy OAuth mają konfigurację oauthConfig zarejestrowaną w src/lib/oauth/constants/oauth.ts
• Jeśli dodano nowego dostawcę: odpowiadający mu executor znajduje się w open-sse/executors/
• Jeśli format jest inny niż OpenAI: translator znajduje się w open-sse/translator/
• Modele są zarejestrowane w open-sse/config/providerRegistry.ts
• Testy jednostkowe w tests/unit/ obejmują klasyfikację dostawców i routing

Aplikacja desktopowa (Electron)

Jeśli zmieniono electron/:

• npm run electron:smoke:packaged kończy się powodzeniem
• Kompilacje przetestowano dla co najmniej jednego z wariantów :win, :mac, :linux
• Certyfikaty podpisywania kodu nie wygasły (jeśli używane jest podpisywanie)
• Wersja w electron/package.json jest zgodna z głównym plikiem package.json
• Wskaźnik kanału automatycznych aktualizacji został zaktualizowany, jeśli wydanie trafia do kanału stable

Układ kompilacji

Repozytorium używa trzech odrębnych katalogów wyjściowych — nigdy ich nie pomyl:

Katalog	Przeznaczenie	Śledzony?
src/	Kod źródłowy aplikacji (TypeScript / TSX)	Tak
.build/	Pliki pośrednie kompilacji — wynik next build (distDir)	Nie (ignorowany przez git)
dist/	Dystrybucyjny pakiet npm — składany przez assembleStandalone	Nie (ignorowany przez git)

Uwaga dla operatora: katalog obrazu na zdalnym VPS pozostaje pod ścieżką /usr/lib/node_modules/omniroute/app/. Zmieniło się tylko wyjście kompilacji wewnątrz repozytorium (app/ → dist/). Procedury wdrażania synchronizują zawartość dist/ przez rsync ze zdalnym katalogiem app/ — zmiany ścieżek na VPS nie są wymagane.

Przepływ pojedynczej kompilacji:

npm run build:release
  └─ rm -rf .build dist          (czyszczenie)
  └─ next build → .build/next/   (pliki pośrednie)
  └─ assembleStandalone          (kopiuje standalone + static + public + natywne moduły → dist/)
  └─ zapisuje dist/BUILD_SHA     (wartość kontrolna HEAD)

NIE uruchamiaj npm run build, a następnie osobno npm run build:cli na potrzeby wdrożenia — użyj npm run build:release, które wykonuje czystą ponowną kompilację i zapisuje wartość kontrolną w jednym poleceniu.

Weryfikacja artefaktu

• npm run build:release kończy się powodzeniem, a dist/BUILD_SHA == git rev-parse --short HEAD
• npm run check:pack-artifact nie zgłasza problemów — brak app.__qa_backup, scripts/scratch, package-lock.json i innych lokalnych pozostałości
• Po kompilacji istnieje dist/server.js

Tagowanie i wydanie

• Uruchom /generate-release-cc (procedura Claude Code):
  • Tworzy tag vX.Y.Z
  • Wysyła tag i gałąź
  • Tworzy wydanie GitHub z treścią dziennika zmian
  • Dołącza instalatory Electron (jeśli zostały zbudowane)
• Lub wykonaj ręcznie:

  git tag -a vX.Y.Z -m "Wydanie vX.Y.Z"
  git push origin vX.Y.Z
  gh release create vX.Y.Z --notes-from-tag
  

Wdrożenie

Procedury wdrażania korzystają z lekkiego przepływu rsync — bez npm pack i bez npm i -g:

• Użyj procedury wdrażania odpowiedniej dla środowiska docelowego:
  • /deploy-vps-local-cc — lokalny VPS (192.168.0.15)
  • /deploy-vps-akamai-cc — VPS Akamai (69.164.221.35)
  • /deploy-vps-both-cc — oba
• Przed wdrożeniem potwierdź, że dist/BUILD_SHA == git rev-parse --short HEAD
• Kompilacja musi zostać uruchomiona w miejscu, w którym node_modules jest rzeczywistym katalogiem (główna kopia robocza lub worktree z wykonanym npm ci — NIE worktree korzystające z dowiązania symbolicznego)
• Wykonaj test dymny wdrożonej instancji:
  • Otwórz /dashboard/health → sprawdź, czy ciąg wersji odpowiada wydaniu
  • Wyślij żądanie /v1/chat/completions do znanego dostawcy
  • Sprawdź, czy /api/monitoring/health zwraca wyłączniki obwodu ze stanem CLOSED
  • Potwierdź, że transporty MCP odpowiadają (/mcp HTTP, /mcp-sse SSE)

Po wydaniu

• Uruchom /capture-release-evidences-cc (procedura Claude Code)
  • Rejestruje zrzuty ekranu/nagrania WebP nowych funkcji
  • Dołącza je do informacji o wydaniu / wpisu na blogu
• Zaktualizuj GitHub Discussions / Discord, publikując ogłoszenie o wydaniu
• Otwórz kamień milowy dla następnej wersji
• Jeśli wydanie jest krytyczne: przypnij dyskusję lub dodaj wpis w news.json, aby wyświetlić baner w aplikacji

Warunki publicznego uruchomienia Radar

Ogłoszenie Radar zostało celowo zatwierdzone z ustawieniem active: false. Aktywacja jest osobną zmianą wykonywaną po udokumentowaniu każdego z poniższych punktów:

• Wszystkie ułożone warstwowo PR-y Radar zostały scalone, a CI dla końcowego commita wydania przechodzi pomyślnie
• Wdróż i przetestuj dymnie trasy OSS Radar, pozostawiając RADAR_ENABLED domyślnie wyłączone
• Przetestuj dymnie GET /planos, /termos, /privacidade i /reembolso na wskazanym hoście Radar
• Zarejestruj tożsamość/dane kontaktowe/adres operatora oraz zatwierdzoną przez właściciela ocenę prawną w prywatnej usłudze
• Przetestuj Stripe Checkout i podpisany webhook wyłącznie w trybie testowym
• Przetestuj jedno zaszyfrowane dostarczenie wiadomości transakcyjnej od zatwierdzonego nadawcy/z zatwierdzonej domeny
• Udowodnij możliwość odtworzenia kopii zapasowej i przeprowadź jedno nadzorowane uruchomienie badawcze z ograniczonym budżetem
• Zatwierdź zasady weryfikacji BRL/PIX przed przyjmowaniem dowodów wpłat
• Włącz publiczny Checkout dopiero po spełnieniu powyższych warunków, a następnie aktywuj nowy identyfikator w news.json
• Sprawdź, czy baner na stronie głównej używa zlokalizowanej treści i czy nowy identyfikator pojawia się po odrzuceniu starszego identyfikatora

Smoke embedded services (v3.8.4+)

Przed wypuszczeniem dowolnego wydania zawierającego zmiany embedded services zweryfikuj:

Boot na świeżej DB (łapie kolizje migracji — dodane po hotfixie v3.8.4)

• DATA_DIR=$(mktemp -d) npm start & — poczekaj 10 s na boot
• curl -s http://127.0.0.1:20128/api/services/9router/status | jq '.tool' zwraca "9router" (NIE 404, NIE 500). Potwierdza, że migracja 071_services.sql się zastosowała + wiersz zaseedowany.
• sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(version_manager);" | grep -E "provider_expose|logs_buffer_path|last_sync_at" zwraca 3 wiersze.
• sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(webhooks);" | grep -E "kind|metadata_encrypted" zwraca 2 wiersze (waliduje zastosowanie 070_webhooks_kind_metadata.sql).
• node --import tsx/esm --test tests/unit/db/no-migration-collisions.test.ts przechodzi — strzeże przed przyszłymi kolizjami.

9Router

• POST /api/services/9router/install zwraca 200 z installedVersion w poniżej 2 min
• POST /api/services/9router/start zwraca 200 i state: "running" w poniżej 30 s
• GET /api/services/9router/status raportuje health: "healthy"
• POST /v1/chat/completions z "model": "9router/auto/..." zwraca 200 (routing end-to-end przez 9Router)
• GET /dashboard/providers/services/9router/embed/dashboard renderuje natywne UI 9Router wewnątrz proxy (bez bezpośredniego iframe 127.0.0.1:port)
• POST /api/services/9router/rotate-key zwraca { keyRotated: true } i usługa restartuje się czysto
• POST /api/services/9router/stop zwraca 200 i state: "stopped"
• GET /api/services/9router/logs?tail=50 zwraca stream SSE z eventem snapshot zawierającym ostatnie linie
• Instalacja w środowisku bez npm w PATH zwraca 500 z przyjaznym (bez stack-trace) komunikatem błędu

CLIProxyAPI

• POST /api/services/cliproxy/install zwraca 200 w poniżej 2 min
• POST /api/services/cliproxy/start zwraca 200 i state: "running" w poniżej 30 s
• GET /api/services/cliproxy/status raportuje health: "healthy"
• POST /api/services/cliproxy/stop zwraca 200 i state: "stopped"
• GET /api/services/cliproxy/logs?tail=50 zwraca stream SSE

Regresja bezpieczeństwa

• curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/9router/start zwraca 403 LOCAL_ONLY
• curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/cliproxy/start zwraca 403 LOCAL_ONLY
• Odpowiedzi błędów z /api/services/* nie zawierają err.stack ani bezwzględnych ścieżek plików

Kontrole v3.8.0+

Przed wypuszczeniem dowolnego wydania v3.8.x zweryfikuj te dodatkowe pozycje:

• omniroute --tray bootuje na macOS (systray2 instalowany do ~/.omniroute/runtime/)
• omniroute --tray bootuje na Linux (wymaga DISPLAY; graceful error jeśli nie ustawione)
• omniroute --tray bootuje na Windows (PowerShell NotifyIcon, bez dodatkowych binarek)
• omniroute config tray enable tworzy wpis autostart; disable go usuwa
• npm install -g omniroute@<this-version> uruchamia postinstall bez fatalnego wyjścia
• Ścieżka update zachowuje optional deps: omniroute update --apply i auto-updater uruchamiają npm install -g … --include=optional, żeby optionalDependencies (better-sqlite3, keytar, tls-client oraz stack SLM llmlingua: @atjsh/llmlingua-2@2.0.5, js-tiktoken) przeżyły update. Tier ultra modelPath SLM potrzebuje też modelu tinybert, auto-pobieranego do ${DATA_DIR}/models/llmlingua przy pierwszym użyciu. Postinstall (scripts/build/colocateOptionals.mjs) następnie ko-lokuje opcjonalne zamknięcie SLM do dist/node_modules, żeby worker rozwiązywał JEDNĄ instancję @huggingface/transformers ^4.2.0 — standalone trace bundluje tylko transformers, nie dynamicznie importowane optionals, więc bez tego worker załadowałby llmlingua-2 przeciw transformers z roota i tier SLM cicho fail-openowałby.
• omniroute status działa bez .env (ścieżka tokenu CLI, tylko loopback)
• curl http://localhost:20128/api/shutdown zwraca 401 (trasa zawsze chroniona)
• curl -H "host: evil.com" http://localhost:20128/api/mcp/sse zwraca 401 (strażnik loopback)
• Runtime SQLite resolvuje do bundled przy pierwszym uruchomieniu (bundlowana binarka poprawna dla platformy)
• Runtime SQLite spada na runtime, gdy node_modules/better-sqlite3 jest usunięte
• Smart MCP filter kompresuje realny output playwright-mcp browser_snapshot (redukcja ≥50%)
• Wszystkie 10 plików skills/omniroute*/SKILL.md są publicznie pobieralne przez raw GitHub URL
• Kreator onboardingu pokazuje krok tour „How It Works” tier na świeżym setupie
• Widget pokrycia tierów na home dashboard pokazuje liczby configured/active

---

Rollback

Jeśli wydanie ma krytyczny problem:

1. gh release edit vX.Y.Z --prerelease (oznacza jako nie-latest)
2. git tag -d vX.Y.Z && git push --delete origin vX.Y.Z (tylko jeśli użytkownicy jeszcze nie adoptowali)
3. Albo: hotfix na release/vX.Y.0 → patch release vX.Y.(Z+1)
4. Natychmiast zakomunikuj w GitHub Discussions i Discord

Twarde reguły

• Nigdy nie commituj bezpośrednio do main
• Nigdy nie używaj git push --force na gałęzie main ani release/*
• Nigdy nie pomijaj hooków Husky (--no-verify)
• Nigdy nie commituj sekretów, credentials ani plików .env
• Coverage musi zostać ≥60/60/60/60 (statements/lines/functions/branches)
• Zawsze dołączaj lub aktualizuj testy przy zmianie kodu produkcyjnego w src/, open-sse/, electron/ lub bin/

Automatyczna kontrola synchronizacji

Uruchom lokalnie strażnika sync docs przed otwarciem PR:

npm run check:docs-sync

CI też uruchamia tę kontrolę w .github/workflows/ci.yml (job lint).