chore(i18n): refresh pl translations

2026-05-02 23:42:50 +00:00 · 2026-05-02 23:42:50 +00:00 · f4af8a441d
commit f4af8a441d
parent d04ab98130
8 changed files with 1371 additions and 1436 deletions
--- a/docs/pl/ci.md
+++ b/docs/pl/ci.md
@ -1,94 +1,94 @@
 ---
 read_when:
-    - Musisz zrozumieć, dlaczego zadanie CI zostało lub nie zostało uruchomione
-    - Debugujesz kontrolę GitHub Actions zakończoną niepowodzeniem
+    - Musisz zrozumieć, dlaczego zadanie CI zostało uruchomione lub nie zostało uruchomione
+    - Debugujesz nieudane sprawdzenie GitHub Actions
    - Koordynujesz uruchomienie lub ponowne uruchomienie walidacji wydania
-    - Zmieniasz wysyłanie ClawSweeper lub przekazywanie aktywności GitHub
-summary: Graf zadań CI, bramki zakresu, zbiorcze wydania i lokalne odpowiedniki poleceń
+    - Zmieniasz wyzwalanie ClawSweeper lub przekazywanie aktywności GitHub
+summary: Graf zadań CI, bramki zakresu, zbiorcze procesy wydań i lokalne odpowiedniki poleceń
 title: Potok CI
 x-i18n:
-    generated_at: "2026-05-02T22:17:44Z"
+    generated_at: "2026-05-02T23:39:37Z"
    model: gpt-5.5
    provider: openai
-    source_hash: a8033b928b26adfa340200ea69fd63d339a6e65c21659b8119a68b23b8b16016
+    source_hash: 321fe0a061044f75b8e1d03b4d3e76d4f8dd2dae0ebc58831887fc20af953cf1
    source_path: ci.md
    workflow: 16
 ---

-OpenClaw CI działa przy każdym wypchnięciu do `main` i każdym pull request. Zadanie `preflight` klasyfikuje diff i wyłącza kosztowne ścieżki, gdy zmieniły się tylko niepowiązane obszary. Ręczne uruchomienia `workflow_dispatch` celowo pomijają inteligentne zawężanie zakresu i uruchamiają pełny graf dla kandydatów do wydania oraz szerokiej walidacji. Ścieżki Androida pozostają opcjonalne przez `include_android`. Pokrycie Plugin tylko dla wydań znajduje się w osobnym workflow [`Plugin przedwydaniowy`](#plugin-prerelease) i działa wyłącznie z [`Pełnej walidacji wydania`](#full-release-validation) albo przez jawne ręczne uruchomienie.
+OpenClaw CI uruchamia się przy każdym wypchnięciu do `main` i przy każdym pull request. Zadanie `preflight` klasyfikuje diff i wyłącza kosztowne ścieżki, gdy zmieniły się tylko niepowiązane obszary. Ręczne uruchomienia `workflow_dispatch` celowo pomijają inteligentne zawężanie zakresu i rozwijają pełny graf dla kandydatów do wydania oraz szerokiej walidacji. Ścieżki Android pozostają opcjonalne przez `include_android`. Pokrycie Plugin tylko dla wydań znajduje się w osobnym workflow [`Przedwydanie Plugin`](#plugin-prerelease) i uruchamia się tylko z [`Pełnej walidacji wydania`](#full-release-validation) albo przez jawne ręczne wywołanie.

-## Przegląd pipeline'u
+## Omówienie potoku

-| Zadanie                          | Cel                                                                                                                 | Kiedy działa                       |
-| -------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
-| `preflight`                      | Wykrywa zmiany tylko w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI                 | Zawsze przy wypchnięciach i PR-ach niebędących szkicami |
-| `security-scm-fast`              | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor`                                                        | Zawsze przy wypchnięciach i PR-ach niebędących szkicami |
-| `security-dependency-audit`      | Bezdependencyjny audyt produkcyjnego pliku lockfile względem ostrzeżeń npm                                          | Zawsze przy wypchnięciach i PR-ach niebędących szkicami |
-| `security-fast`                  | Wymagany agregat dla szybkich zadań bezpieczeństwa                                                                  | Zawsze przy wypchnięciach i PR-ach niebędących szkicami |
-| `check-dependencies`             | Produkcyjny przebieg Knip tylko dla zależności plus strażnik listy dozwolonych nieużywanych plików                  | Zmiany istotne dla Node            |
-| `build-artifacts`                | Buduje `dist/`, Control UI, sprawdza zbudowane artefakty i artefakty wielokrotnego użytku dla zadań downstream      | Zmiany istotne dla Node            |
-| `checks-fast-core`               | Szybkie ścieżki poprawności w Linuksie, takie jak kontrole pakietów wbudowanych/kontraktów Plugin/protokołu         | Zmiany istotne dla Node            |
-| `checks-fast-contracts-channels` | Podzielone na shardy kontrole kontraktów kanałów ze stabilnym zagregowanym wynikiem sprawdzenia                     | Zmiany istotne dla Node            |
-| `checks-node-core-test`          | Shardy testów Core Node, z wyłączeniem ścieżek kanałów, pakietów wbudowanych, kontraktów i rozszerzeń               | Zmiany istotne dla Node            |
-| `check`                          | Podzielony na shardy odpowiednik głównej lokalnej bramki: typy prod, lint, strażniki, typy testów i ścisły smoke    | Zmiany istotne dla Node            |
-| `check-additional`               | Architektura, granice, drift snapshotów promptów, strażniki powierzchni rozszerzeń, granice pakietów i shardy gateway-watch | Zmiany istotne dla Node            |
-| `build-smoke`                    | Testy smoke zbudowanego CLI i smoke pamięci startowej                                                               | Zmiany istotne dla Node            |
-| `checks`                         | Weryfikator testów kanałów zbudowanych artefaktów                                                                   | Zmiany istotne dla Node            |
-| `checks-node-compat-node22`      | Build zgodności z Node 22 i ścieżka smoke                                                                           | Ręczne uruchomienie CI dla wydań   |
-| `check-docs`                     | Formatowanie dokumentacji, lint i kontrole uszkodzonych linków                                                      | Zmieniono dokumentację             |
-| `skills-python`                  | Ruff + pytest dla Skills wspieranych przez Pythona                                                                  | Zmiany istotne dla Skills Pythona  |
-| `checks-windows`                 | Specyficzne dla Windows testy procesów/ścieżek plus współdzielone regresje specyfikatorów importu runtime           | Zmiany istotne dla Windows         |
-| `macos-node`                     | Ścieżka testów TypeScript na macOS używająca współdzielonych zbudowanych artefaktów                                 | Zmiany istotne dla macOS           |
-| `macos-swift`                    | Swift lint, build i testy aplikacji macOS                                                                           | Zmiany istotne dla macOS           |
-| `android`                        | Testy jednostkowe Androida dla obu wariantów plus jeden build debug APK                                             | Zmiany istotne dla Androida        |
-| `test-performance-agent`         | Codzienna optymalizacja wolnych testów przez Codex po zaufanej aktywności                                           | Sukces głównego CI albo ręczne uruchomienie |
-| `openclaw-performance`           | Codzienne/na żądanie raporty wydajności runtime Kova ze ścieżkami mock-provider, deep-profile i live GPT 5.4        | Harmonogram i ręczne uruchomienie  |
+| Zadanie                          | Cel                                                                                                                 | Kiedy się uruchamia               |
+| -------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------- |
+| `preflight`                      | Wykrywanie zmian tylko w dokumentacji, zmienionych zakresów, zmienionych rozszerzeń oraz budowanie manifestu CI    | Zawsze przy wypchnięciach i PR-ach innych niż szkice |
+| `security-scm-fast`              | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor`                                                        | Zawsze przy wypchnięciach i PR-ach innych niż szkice |
+| `security-dependency-audit`      | Audyt produkcyjnego pliku blokady bez zależności wobec porad bezpieczeństwa npm                                     | Zawsze przy wypchnięciach i PR-ach innych niż szkice |
+| `security-fast`                  | Wymagany agregat dla szybkich zadań bezpieczeństwa                                                                  | Zawsze przy wypchnięciach i PR-ach innych niż szkice |
+| `check-dependencies`             | Produkcyjne przejście Knip tylko dla zależności oraz strażnik listy dozwolonych nieużywanych plików                | Zmiany istotne dla Node           |
+| `build-artifacts`                | Budowanie `dist/`, Control UI, kontrole zbudowanych artefaktów oraz wielokrotnego użytku artefakty downstream       | Zmiany istotne dla Node           |
+| `checks-fast-core`               | Szybkie ścieżki poprawności Linuksa, takie jak kontrole bundled/kontraktu Plugin/protokołu                         | Zmiany istotne dla Node           |
+| `checks-fast-contracts-channels` | Shardowane kontrole kontraktów kanałów ze stabilnym zbiorczym wynikiem kontroli                                     | Zmiany istotne dla Node           |
+| `checks-node-core-test`          | Shardy testów głównego Node, z wyłączeniem ścieżek kanałów, bundled, kontraktów i rozszerzeń                        | Zmiany istotne dla Node           |
+| `check`                          | Shardowany odpowiednik głównej lokalnej bramki: typy produkcyjne, lint, strażniki, typy testowe i ścisły smoke      | Zmiany istotne dla Node           |
+| `check-additional`               | Architektura, granice, dryf snapshotów promptów, strażniki powierzchni rozszerzeń, granica pakietów i shardy gateway-watch | Zmiany istotne dla Node           |
+| `build-smoke`                    | Testy smoke zbudowanego CLI i smoke pamięci startowej                                                               | Zmiany istotne dla Node           |
+| `checks`                         | Weryfikator testów kanałów zbudowanych artefaktów                                                                   | Zmiany istotne dla Node           |
+| `checks-node-compat-node22`      | Budowanie zgodności Node 22 i ścieżka smoke                                                                         | Ręczne wywołanie CI dla wydań     |
+| `check-docs`                     | Formatowanie dokumentacji, lint i kontrole niedziałających linków                                                   | Zmieniono dokumentację            |
+| `skills-python`                  | Ruff + pytest dla Skills opartych na Pythonie                                                                       | Zmiany istotne dla Skills Python  |
+| `checks-windows`                 | Testy procesów/ścieżek specyficzne dla Windows oraz współdzielone regresje specyfikatorów importu środowiska wykonawczego | Zmiany istotne dla Windows        |
+| `macos-node`                     | Ścieżka testów TypeScript na macOS używająca współdzielonych zbudowanych artefaktów                                 | Zmiany istotne dla macOS          |
+| `macos-swift`                    | Swift lint, budowanie i testy aplikacji macOS                                                                       | Zmiany istotne dla macOS          |
+| `android`                        | Testy jednostkowe Android dla obu wariantów oraz jedno budowanie debug APK                                          | Zmiany istotne dla Android        |
+| `test-performance-agent`         | Codzienna optymalizacja wolnych testów przez Codex po zaufanej aktywności                                           | Sukces głównego CI albo ręczne wywołanie |
+| `openclaw-performance`           | Codzienne/na żądanie raporty wydajności środowiska wykonawczego Kova ze ścieżkami mock-provider, deep-profile i GPT 5.4 live | Harmonogram i ręczne wywołanie    |

 ## Kolejność fail-fast

 1. `preflight` decyduje, które ścieżki w ogóle istnieją. Logika `docs-scope` i `changed-scope` to kroki wewnątrz tego zadania, a nie samodzielne zadania.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` szybko kończą się niepowodzeniem bez czekania na cięższe zadania artefaktów i macierzy platform.
-3. `build-artifacts` nakłada się z szybkimi ścieżkami Linuksa, aby konsumenci downstream mogli wystartować, gdy tylko współdzielony build będzie gotowy.
-4. Cięższe ścieżki platform i runtime rozchodzą się później: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`.
+2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` zawodzą szybko, bez czekania na cięższe zadania artefaktów i macierzy platform.
+3. `build-artifacts` nakłada się z szybkimi ścieżkami Linuksa, aby konsumenci downstream mogli zacząć, gdy tylko współdzielony build będzie gotowy.
+4. Cięższe ścieżki platform i środowiska wykonawczego rozwijają się potem: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`.

-GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowsze wypchnięcie trafi do tego samego PR-a albo refa `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tego samego refa również kończy się niepowodzeniem. Zagregowane kontrole shardów używają `!cancelled() && always()`, więc nadal raportują zwykłe awarie shardów, ale nie ustawiają się w kolejce po tym, jak cały workflow został już zastąpiony. Automatyczny klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHuba w starej grupie kolejki nie mogło bezterminowo blokować nowszych uruchomień main. Ręczne uruchomienia pełnego zestawu używają `CI-manual-v1-*` i nie anulują uruchomień w toku.
+GitHub może oznaczyć zastąpione zadania jako `cancelled`, gdy nowsze wypchnięcie trafi do tego samego PR-a albo refa `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tego samego refa również zawodzi. Zbiorcze kontrole shardów używają `!cancelled() && always()`, więc nadal zgłaszają zwykłe awarie shardów, ale nie ustawiają się w kolejce po tym, jak cały workflow został już zastąpiony. Automatyczny klucz współbieżności CI jest wersjonowany (`CI-v7-*`), więc zombie po stronie GitHub w starej grupie kolejki nie może bezterminowo blokować nowszych uruchomień main. Ręczne uruchomienia pełnego zestawu używają `CI-manual-v1-*` i nie anulują uruchomień w toku.

-## Zakres i routing
+## Zakres i trasowanie

-Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest objęta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`. Ręczne uruchomienie pomija wykrywanie zmienionego zakresu i sprawia, że manifest preflight zachowuje się tak, jakby zmienił się każdy obszar objęty zakresem.
+Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest pokryta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`. Ręczne wywołanie pomija wykrywanie changed-scope i sprawia, że manifest preflight zachowuje się tak, jakby zmienił się każdy obszar objęty zakresem.

- **Edycje workflow CI** walidują graf Node CI oraz linting workflow, ale same z siebie nie wymuszają natywnych buildów Windows, Androida ani macOS; te ścieżki platform pozostają ograniczone do zmian źródłowych platform.
- **Edycje wyłącznie routingu CI, wybrane tanie edycje fixture'ów testów core oraz wąskie edycje pomocników/routingu testów kontraktu Plugin** używają szybkiej ścieżki manifestu tylko dla Node: `preflight`, bezpieczeństwo i jedno zadanie `checks-fast-core`. Ta ścieżka pomija artefakty buildu, zgodność z Node 22, kontrakty kanałów, pełne shardy core, shardy wbudowanych Plugin oraz dodatkowe macierze strażników, gdy zmiana ogranicza się do powierzchni routingu lub pomocników, które szybkie zadanie bezpośrednio ćwiczy.
- **Kontrole Windows Node** są ograniczone do specyficznych dla Windows wrapperów procesów/ścieżek, pomocników uruchamiania npm/pnpm/UI, konfiguracji menedżera pakietów oraz powierzchni workflow CI wykonujących tę ścieżkę; niepowiązane zmiany źródeł, Plugin, install-smoke i tylko testów pozostają na linuksowych ścieżkach Node.
+- **Edycje workflow CI** walidują graf CI Node oraz lint workflow, ale same z siebie nie wymuszają natywnych buildów Windows, Android ani macOS; te ścieżki platform pozostają ograniczone do zmian źródeł platformy.
+- **Edycje wyłącznie trasowania CI, wybrane tanie edycje fixture głównych testów oraz wąskie edycje pomocników/test-routing kontraktu Plugin** używają szybkiej ścieżki manifestu tylko dla Node: `preflight`, bezpieczeństwo i pojedyncze zadanie `checks-fast-core`. Ta ścieżka pomija artefakty builda, zgodność Node 22, kontrakty kanałów, pełne shardy główne, shardy bundled-plugin oraz dodatkowe macierze strażników, gdy zmiana jest ograniczona do powierzchni trasowania lub pomocników bezpośrednio ćwiczonych przez szybkie zadanie.
+- **Kontrole Node dla Windows** są ograniczone do specyficznych dla Windows wrapperów procesów/ścieżek, pomocników runnerów npm/pnpm/UI, konfiguracji menedżera pakietów oraz powierzchni workflow CI, które wykonują tę ścieżkę; niepowiązane zmiany źródeł, Plugin, install-smoke i wyłącznie testowe pozostają na linuksowych ścieżkach Node.

-Najwolniejsze rodziny testów Node są dzielone lub równoważone tak, aby każde zadanie pozostawało małe bez nadmiernego rezerwowania runnerów: kontrakty kanałów działają jako trzy ważone shardy, małe ścieżki jednostkowe core są parowane, auto-reply działa jako czterech zrównoważonych workerów (z poddrzewem odpowiedzi podzielonym na shardy agent-runner, dispatch i commands/state-routing), a konfiguracje agentic Gateway/Plugin są rozłożone na istniejące zadania Node tylko ze źródeł zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarkowe, QA, mediów i różne testy Plugin używają dedykowanych konfiguracji Vitest zamiast współdzielonego catch-all dla Plugin. Shardy include-pattern zapisują wpisy czasu używając nazwy sharda CI, dzięki czemu `.artifacts/vitest-shard-timings.json` potrafi odróżnić całą konfigurację od filtrowanego sharda. `check-additional` trzyma razem pracę compile/canary granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; shard strażnika granic uruchamia swoje małe niezależne strażniki równolegle w jednym zadaniu, w tym `pnpm prompt:snapshots:check`, aby drift promptów szczęśliwej ścieżki Codex był przypięty do PR-a, który go spowodował. Gateway watch, testy kanałów i shard granicy wsparcia core działają równolegle wewnątrz `build-artifacts` po zbudowaniu `dist/` i `dist-runtime/`.
+Najwolniejsze rodziny testów Node są dzielone lub równoważone tak, aby każde zadanie pozostało małe bez nadmiernego rezerwowania runnerów: kontrakty kanałów działają jako trzy ważone shardy, małe główne ścieżki jednostkowe są parowane, auto-reply działa jako cztery zrównoważone workery (z poddrzewem reply podzielonym na shardy agent-runner, dispatch oraz commands/state-routing), a konfiguracje agentic Gateway/Plugin są rozłożone między istniejące zadania agentic Node tylko ze źródeł, zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarkowe, QA, mediów i różne testy Plugin używają swoich dedykowanych konfiguracji Vitest zamiast współdzielonego catch-all Plugin. Shardy include-pattern zapisują wpisy czasów z użyciem nazwy sharda CI, więc `.artifacts/vitest-shard-timings.json` może odróżnić całą konfigurację od filtrowanego sharda. `check-additional` trzyma razem pracę compile/canary granicy pakietu i oddziela architekturę topologii środowiska wykonawczego od pokrycia gateway watch; shard strażnika granicy uruchamia swoje małe niezależne strażniki współbieżnie w jednym zadaniu, w tym `pnpm prompt:snapshots:check`, aby dryf promptów szczęśliwej ścieżki środowiska wykonawczego Codex był przypięty do PR-a, który go spowodował. Gateway watch, testy kanałów i główny shard granicy wsparcia działają współbieżnie wewnątrz `build-artifacts` po tym, jak `dist/` i `dist-runtime/` są już zbudowane.

-Android CI uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje Play debug APK. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje wariant z flagami BuildConfig SMS/call-log, unikając jednocześnie zduplikowanego zadania pakowania debug APK przy każdym wypchnięciu istotnym dla Androida.
+Android CI uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje debug APK Play. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje wariant z flagami BuildConfig dla SMS/rejestru połączeń, jednocześnie unikając duplikowania zadania pakietowania debug APK przy każdym wypchnięciu istotnym dla Android.

-Shard `check-dependencies` uruchamia `pnpm deadcode:dependencies` (produkcyjny przebieg Knip tylko dla zależności, przypięty do najnowszej wersji Knip, z wyłączonym minimalnym wiekiem wydania pnpm dla instalacji `dlx`) oraz `pnpm deadcode:unused-files`, który porównuje produkcyjne ustalenia Knip dotyczące nieużywanych plików z `scripts/deadcode-unused-files.allowlist.mjs`. Strażnik nieużywanych plików kończy się niepowodzeniem, gdy PR dodaje nowy, nieprzejrzany nieużywany plik albo zostawia przestarzały wpis na liście dozwolonych, jednocześnie zachowując celowe powierzchnie dynamicznych Plugin, generowane, build, live-test i mosty pakietów, których Knip nie może rozwiązać statycznie.
+Shard `check-dependencies` uruchamia `pnpm deadcode:dependencies` (produkcyjne przejście Knip tylko dla zależności przypięte do najnowszej wersji Knip, z wyłączonym minimalnym wiekiem wydania pnpm dla instalacji `dlx`) oraz `pnpm deadcode:unused-files`, które porównuje produkcyjne ustalenia Knip o nieużywanych plikach z `scripts/deadcode-unused-files.allowlist.mjs`. Strażnik nieużywanych plików zawodzi, gdy PR dodaje nowy, nieprzejrzany nieużywany plik albo zostawia nieaktualny wpis na liście dozwolonych, zachowując jednocześnie celowe dynamiczne powierzchnie Plugin, generowane, build, live-test i mostków pakietów, których Knip nie może rozwiązać statycznie.

 ## Przekazywanie aktywności ClawSweeper

-`.github/workflows/clawsweeper-dispatch.yml` jest mostem po stronie docelowej z aktywności repozytorium OpenClaw do ClawSweeper. Nie pobiera ani nie wykonuje niezaufanego kodu pull request. Workflow tworzy token GitHub App z `CLAWSWEEPER_APP_PRIVATE_KEY`, a następnie wysyła zwarte ładunki `repository_dispatch` do `openclaw/clawsweeper`.
+`.github/workflows/clawsweeper-dispatch.yml` to most po stronie docelowej z aktywności repozytorium OpenClaw do ClawSweeper. Nie wykonuje checkoutu ani nie uruchamia niezaufanego kodu z pull request. Workflow tworzy token GitHub App z `CLAWSWEEPER_APP_PRIVATE_KEY`, a następnie wysyła zwarte ładunki `repository_dispatch` do `openclaw/clawsweeper`.

 Workflow ma cztery ścieżki:

 - `clawsweeper_item` dla dokładnych żądań przeglądu issue i pull request;
 - `clawsweeper_comment` dla jawnych poleceń ClawSweeper w komentarzach issue;
 - `clawsweeper_commit_review` dla żądań przeglądu na poziomie commita przy wypchnięciach do `main`;
- `github_activity` dla ogólnej aktywności GitHuba, którą agent ClawSweeper może sprawdzić.
+- `github_activity` dla ogólnej aktywności GitHub, którą agent ClawSweeper może sprawdzić.

-Ścieżka `github_activity` przekazuje wyłącznie znormalizowane metadane: typ zdarzenia, akcję, aktora, repozytorium, numer elementu, URL, tytuł, stan oraz krótkie fragmenty komentarzy lub przeglądów, jeśli są obecne. Celowo unika przekazywania pełnego ciała Webhook. Odbierający workflow w `openclaw/clawsweeper` to `.github/workflows/github-activity.yml`, który publikuje znormalizowane zdarzenie do hooka OpenClaw Gateway dla agenta ClawSweeper.
+Ścieżka `github_activity` przekazuje tylko znormalizowane metadane: typ zdarzenia, akcję, aktora, repozytorium, numer elementu, URL, tytuł, stan oraz krótkie fragmenty komentarzy lub recenzji, gdy są obecne. Celowo unika przekazywania pełnego ciała webhook. Odbierający workflow w `openclaw/clawsweeper` to `.github/workflows/github-activity.yml`, który publikuje znormalizowane zdarzenie do hooka OpenClaw Gateway dla agenta ClawSweeper.

-Ogólna aktywność jest obserwacją, a nie domyślnym dostarczeniem. Agent ClawSweeper otrzymuje cel Discord w swoim prompcie i powinien publikować do `#clawsweeper` tylko wtedy, gdy zdarzenie jest zaskakujące, wykonalne, ryzykowne albo operacyjnie użyteczne. Rutynowe otwarcia, edycje, ruch botów, zduplikowany szum Webhook i zwykły ruch przeglądów powinny skutkować `NO_REPLY`.
+Ogólna aktywność jest obserwacją, a nie domyślnym dostarczaniem. Agent ClawSweeper otrzymuje cel Discord w swoim prompcie i powinien publikować na `#clawsweeper` tylko wtedy, gdy zdarzenie jest zaskakujące, wykonalne, ryzykowne albo operacyjnie użyteczne. Rutynowe otwarcia, edycje, ruch botów, zduplikowany szum webhook i zwykły ruch recenzji powinny skutkować `NO_REPLY`.

-Traktuj tytuły, komentarze, treści, tekst przeglądów, nazwy gałęzi i komunikaty commitów z GitHuba jako niezaufane dane w całej tej ścieżce. Są wejściem do podsumowywania i triage'u, a nie instrukcjami dla workflow ani runtime agenta.
+Traktuj tytuły GitHub, komentarze, treści, tekst recenzji, nazwy gałęzi i komunikaty commitów jako niezaufane dane w całej tej ścieżce. Są one danymi wejściowymi do podsumowania i triage, a nie instrukcjami dla workflow ani środowiska wykonawczego agenta.

-## Ręczne uruchomienia
+## Ręczne wywołania

-Ręczne uruchomienia CI wykonują ten sam graf zadań co zwykłe CI, ale wymuszają włączenie każdej nie-Androidowej ścieżki zakresowej: shardy Linux Node, shardy dołączonych Pluginów, kontrakty kanałów, zgodność z Node 22, `check`, `check-additional`, build smoke, kontrole dokumentacji, Python skills, Windows, macOS oraz Control UI i18n. Samodzielne ręczne uruchomienia CI wykonują tylko Androida z `include_android=true`; pełna parasolowa walidacja wydania włącza Androida, przekazując `include_android=true`. Statyczne kontrole prerelease Pluginów, shard tylko wydaniowy `agentic-plugins`, pełny wsadowy przegląd rozszerzeń oraz prerelease'owe ścieżki Docker dla Pluginów są wykluczone z CI. Pakiet prerelease Docker uruchamia się tylko wtedy, gdy `Full Release Validation` uruchamia oddzielny workflow `Plugin Prerelease` z włączoną bramką walidacji wydania.
+Ręczne uruchomienia CI wykonują ten sam graf zadań co normalne CI, ale wymuszają włączenie każdej nieandroidowej ścieżki zakresowej: shardy Linux Node, shardy wbudowanych pluginów, kontrakty kanałów, zgodność z Node 22, `check`, `check-additional`, smoke test kompilacji, kontrole dokumentacji, Python skills, Windows, macOS oraz i18n Control UI. Samodzielne ręczne uruchomienia CI wykonują tylko Androida z `include_android=true`; pełny parasol wydania włącza Androida przez przekazanie `include_android=true`. Statyczne kontrole przedwydaniowe pluginów, shard tylko wydaniowy `agentic-plugins`, pełny wsadowy przegląd rozszerzeń oraz przedwydaniowe ścieżki Docker dla pluginów są wyłączone z CI. Przedwydaniowy zestaw Docker uruchamia się tylko wtedy, gdy `Full Release Validation` uruchamia oddzielny workflow `Plugin Prerelease` z włączoną bramką walidacji wydania.

-Ręczne uruchomienia używają unikalnej grupy współbieżności, dzięki czemu pełny pakiet release candidate nie zostaje anulowany przez inne uruchomienie push lub PR na tym samym refie. Opcjonalne wejście `target_ref` pozwala zaufanemu wywołującemu uruchomić ten graf względem gałęzi, tagu lub pełnego SHA commita, używając pliku workflow z wybranego refa uruchomienia.
+Ręczne uruchomienia używają unikalnej grupy współbieżności, więc pełny zestaw dla kandydata do wydania nie zostanie anulowany przez inne uruchomienie push lub PR na tym samym refie. Opcjonalne wejście `target_ref` pozwala zaufanemu wywołującemu uruchomić ten graf względem gałęzi, tagu lub pełnego SHA commita, używając pliku workflow z wybranego refa uruchomienia.

 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@ -98,15 +98,15 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>

 ## Runnery

-| Runner                           | Zadania                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ubuntu-24.04`                   | `preflight`, szybkie zadania bezpieczeństwa i agregaty (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie kontrole protokołu/kontraktów/dołączonych elementów, shardowane kontrole kontraktów kanałów, shardy `check` z wyjątkiem lint, shardy i agregaty `check-additional`, weryfikatory agregatów testów Node, kontrole dokumentacji, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke także używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła wcześniej wejść do kolejki |
-| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, lżejsze shardy rozszerzeń, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` oraz `check-test-types`                                                                                                                                                                                                                                                                                                                      |
-| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, shardy testów Linux Node, shardy testów dołączonych Pluginów, `android`                                                                                                                                                                                                                                                                                                                                                                |
-| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (na tyle wrażliwe na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało); buildy Docker install-smoke (czas oczekiwania w kolejce 32-vCPU kosztował więcej, niż oszczędzał)                                                                                                                                                                                                                                                                                |
-| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| `blacksmith-6vcpu-macos-latest`  | `macos-node` w `openclaw/openclaw`; forki wracają do `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                    |
-| `blacksmith-12vcpu-macos-latest` | `macos-swift` w `openclaw/openclaw`; forki wracają do `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                   |
+| Runner                           | Zadania                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ubuntu-24.04`                   | `preflight`, szybkie zadania bezpieczeństwa i agregaty (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie kontrole protokołu/kontraktów/wbudowanych komponentów, shardowane kontrole kontraktów kanałów, shardy `check` z wyjątkiem lint, shardy i agregaty `check-additional`, weryfikatory agregatów testów Node, kontrole dokumentacji, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight także używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła wcześniej wejść do kolejki |
+| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, lżejsze shardy rozszerzeń, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` i `check-test-types`                                                                                                                                                                                                                                                                                                                                                 |
+| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, shardy testów Linux Node, shardy testów wbudowanych pluginów, `android`                                                                                                                                                                                                                                                                                                                                                                                       |
+| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (na tyle wrażliwe na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało); kompilacje Docker install-smoke (czas w kolejce dla 32 vCPU kosztował więcej, niż oszczędzał)                                                                                                                                                                                                                                                                                                          |
+| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
+| `blacksmith-6vcpu-macos-latest`  | `macos-node` na `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                              |
+| `blacksmith-12vcpu-macos-latest` | `macos-swift` na `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                             |

 ## Lokalne odpowiedniki

@ -137,37 +137,30 @@ pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.jso

 ## Wydajność OpenClaw

-`OpenClaw Performance` to workflow wydajności produktu/runtime. Uruchamia się codziennie na `main` i można go uruchomić ręcznie:
+`OpenClaw Performance` to workflow wydajności produktu/środowiska uruchomieniowego. Uruchamia się codziennie na `main` i można go uruchomić ręcznie:

 ```bash
 gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
 gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_gpt54=true
 ```

-Workflow instaluje OCM z przypiętego wydania oraz Kova z przypiętego wejścia `kova_ref`, a następnie uruchamia trzy ścieżki:
+Workflow instaluje OCM z przypiętego wydania i Kova z przypiętego wejścia `kova_ref`, a następnie uruchamia trzy ścieżki:

- `mock-provider`: scenariusze diagnostyczne Kova względem runtime z lokalnego buildu z deterministycznym fałszywym uwierzytelnianiem zgodnym z OpenAI.
- `mock-deep-profile`: profilowanie CPU/sterty/śledzenia dla punktów krytycznych uruchamiania, gateway i tur agenta.
+- `mock-provider`: scenariusze diagnostyczne Kova względem lokalnie zbudowanego środowiska uruchomieniowego z deterministycznym fałszywym uwierzytelnianiem zgodnym z OpenAI.
+- `mock-deep-profile`: profilowanie CPU/sterty/śladów dla hotspotów startu, gatewaya i tury agenta.
 - `live-gpt54`: rzeczywista tura agenta OpenAI `openai/gpt-5.4`, pomijana, gdy `OPENAI_API_KEY` jest niedostępny.

-Ścieżka mock-provider uruchamia także natywne sondy źródłowe OpenClaw po przebiegu Kova: pomiar czasu startu gateway i pamięci w domyślnych przypadkach uruchamiania, z hookiem oraz z 50 Pluginami; powtarzane pętle hello mock-OpenAI `channel-chat-baseline`; oraz polecenia startowe CLI względem uruchomionego gateway. Podsumowanie sond źródłowych w Markdown znajduje się w `source/index.md` w pakiecie raportu, z surowym JSON obok.
+Ścieżka mock-provider uruchamia także natywne dla OpenClaw sondy źródłowe po przebiegu Kova: czas rozruchu gatewaya i pamięć w przypadkach startu domyślnego, hooka i 50 pluginów; powtarzane pętle hello mock-OpenAI `channel-chat-baseline`; oraz polecenia startowe CLI względem uruchomionego gatewaya. Podsumowanie Markdown sondy źródłowej znajduje się w `source/index.md` w pakiecie raportu, z surowym JSON-em obok.

-Każda ścieżka przesyła artefakty GitHub. Gdy `CLAWGRIT_REPORTS_TOKEN` jest skonfigurowany, workflow zatwierdza także `report.json`, `report.md`, pakiety, `index.md` oraz artefakty sond źródłowych do `openclaw/clawgrit-reports` pod `openclaw-performance/<ref>/<run-id>-<attempt>/<lane>/`. Bieżący wskaźnik gałęzi jest zapisywany jako `openclaw-performance/<ref>/latest-<lane>.json`.
+Każda ścieżka przesyła artefakty GitHub. Gdy skonfigurowano `CLAWGRIT_REPORTS_TOKEN`, workflow dodatkowo commituję `report.json`, `report.md`, pakiety, `index.md` oraz artefakty sond źródłowych do `openclaw/clawgrit-reports` pod `openclaw-performance/<ref>/<run-id>-<attempt>/<lane>/`. Bieżący wskaźnik gałęzi jest zapisywany jako `openclaw-performance/<ref>/latest-<lane>.json`.

 ## Pełna walidacja wydania

-`Full Release Validation` to ręczny parasolowy workflow dla „uruchom wszystko przed wydaniem”. Przyjmuje gałąź, tag lub pełny SHA commita, uruchamia ręczny workflow `CI` z tym celem, uruchamia `Plugin Prerelease` dla dowodu Pluginu/pakietu/statycznego/Docker tylko dla wydania oraz uruchamia `OpenClaw Release Checks` dla install smoke, akceptacji pakietu, pakietów ścieżki wydaniowej Docker, live/E2E, OpenWebUI, parytetu QA Lab, Matrix i ścieżek Telegram. Z `rerun_group=all` i `release_profile=full` uruchamia także `NPM Telegram Beta E2E` względem artefaktu `release-package-under-test` z kontroli wydania. Po opublikowaniu przekaż `npm_telegram_package_spec`, aby ponownie uruchomić tę samą ścieżkę pakietu Telegram względem opublikowanego pakietu npm.
+`Full Release Validation` to ręczny parasolowy workflow do „uruchomienia wszystkiego przed wydaniem”. Przyjmuje gałąź, tag lub pełny SHA commita, uruchamia ręczny workflow `CI` z tym celem, uruchamia `Plugin Prerelease` dla dowodów tylko wydaniowych pluginów/pakietów/statycznych/Docker oraz uruchamia `OpenClaw Release Checks` dla install smoke, package acceptance, zestawów ścieżki wydaniowej Docker, live/E2E, OpenWebUI, parytetu QA Lab, Matrix i ścieżek Telegram. Z `rerun_group=all` i `release_profile=full` uruchamia także `NPM Telegram Beta E2E` względem artefaktu `release-package-under-test` z kontroli wydania. Po publikacji przekaż `npm_telegram_package_spec`, aby ponownie uruchomić tę samą ścieżkę pakietu Telegram względem opublikowanego pakietu npm.

-Zobacz [Pełna walidacja wydania](/pl/reference/full-release-validation), aby poznać
-macierz etapów, dokładne nazwy zadań workflow, różnice między profilami, artefakty oraz
-uchwyty ukierunkowanych ponownych uruchomień.
+Zobacz [Pełna walidacja wydania](/pl/reference/full-release-validation), aby sprawdzić macierz etapów, dokładne nazwy zadań workflow, różnice profili, artefakty i uchwyty ukierunkowanych ponownych uruchomień.

-`OpenClaw Release Publish` to ręczny mutujący workflow wydaniowy. Uruchom go
-z `release/YYYY.M.D` lub `main` po utworzeniu tagu wydania i po tym, jak
-preflight OpenClaw npm zakończy się powodzeniem. Weryfikuje `pnpm plugins:sync:check`,
-uruchamia `Plugin NPM Release` dla wszystkich publikowalnych pakietów Pluginów, uruchamia
-`Plugin ClawHub Release` dla tego samego SHA wydania i dopiero wtedy uruchamia
-`OpenClaw NPM Release` z zapisanym `preflight_run_id`.
+`OpenClaw Release Publish` to ręczny mutujący workflow wydania. Uruchom go z `release/YYYY.M.D` lub `main` po utworzeniu tagu wydania i po powodzeniu preflightu OpenClaw npm. Weryfikuje `pnpm plugins:sync:check`, uruchamia `Plugin NPM Release` dla wszystkich publikowalnych pakietów pluginów, uruchamia `Plugin ClawHub Release` dla tego samego SHA wydania i dopiero wtedy uruchamia `OpenClaw NPM Release` z zapisanym `preflight_run_id`.

 ```bash
 gh workflow run openclaw-release-publish.yml \
@ -177,41 +170,35 @@ gh workflow run openclaw-release-publish.yml \
  -f npm_dist_tag=beta
 ```

-Aby uzyskać dowód przypiętego commita na szybko zmieniającej się gałęzi, użyj helpera zamiast
-`gh workflow run ... --ref main -f ref=<sha>`:
+Aby uzyskać dowód przypiętego commita na szybko zmieniającej się gałęzi, użyj helpera zamiast `gh workflow run ... --ref main -f ref=<sha>`:

 ```bash
 pnpm ci:full-release --sha <full-sha>
 ```

-Refy uruchamiania workflow GitHub muszą być gałęziami lub tagami, a nie surowymi SHA commitów. Helper wypycha tymczasową gałąź `release-ci/<sha>-...` na docelowym SHA,
-uruchamia `Full Release Validation` z tego przypiętego refa, weryfikuje, że każdy podrzędny
-workflow `headSha` pasuje do celu, i usuwa tymczasową gałąź po zakończeniu
-uruchomienia. Weryfikator parasolowy także kończy się niepowodzeniem, jeśli którykolwiek podrzędny workflow został uruchomiony na
-innym SHA.
+Refy uruchamiania workflow GitHub muszą być gałęziami lub tagami, a nie surowymi SHA commitów. Helper wypycha tymczasową gałąź `release-ci/<sha>-...` na docelowym SHA, uruchamia `Full Release Validation` z tego przypiętego refa, weryfikuje, że `headSha` każdego workflow podrzędnego pasuje do celu, i usuwa tymczasową gałąź po zakończeniu uruchomienia. Weryfikator parasola także kończy się niepowodzeniem, jeśli jakikolwiek workflow podrzędny uruchomił się na innym SHA.

-`release_profile` kontroluje zakres live/provider przekazywany do kontroli wydania. Ręczne workflow wydaniowe domyślnie używają `stable`; używaj `full` tylko wtedy, gdy
-celowo potrzebujesz szerokiej doradczej macierzy provider/media.
+`release_profile` kontroluje zakres live/provider przekazywany do kontroli wydania. Ręczne workflow wydania domyślnie używają `stable`; użyj `full` tylko wtedy, gdy celowo chcesz szeroką doradczą macierz providerów/mediów.

- `minimum` zachowuje najszybsze krytyczne dla wydania ścieżki OpenAI/core.
- `stable` dodaje stabilny zestaw provider/backend.
- `full` uruchamia szeroką doradczą macierz provider/media.
+- `minimum` zachowuje najszybsze, krytyczne dla wydania ścieżki OpenAI/core.
+- `stable` dodaje stabilny zestaw providerów/backendów.
+- `full` uruchamia szeroką doradczą macierz providerów/mediów.

-Parasol zapisuje identyfikatory uruchomionych podrzędnych przebiegów, a końcowe zadanie `Verify full validation` ponownie sprawdza bieżące konkluzje uruchomień podrzędnych i dołącza tabele najwolniejszych zadań dla każdego uruchomienia podrzędnego. Jeśli podrzędny workflow zostanie uruchomiony ponownie i zakończy się powodzeniem, uruchom ponownie tylko zadanie weryfikatora nadrzędnego, aby odświeżyć wynik parasola i podsumowanie czasów.
+Parasol zapisuje identyfikatory uruchomionych workflow podrzędnych, a końcowe zadanie `Verify full validation` ponownie sprawdza bieżące wnioski z uruchomień podrzędnych i dołącza tabele najwolniejszych zadań dla każdego uruchomienia podrzędnego. Jeśli workflow podrzędny zostanie ponownie uruchomiony i zmieni wynik na zielony, uruchom ponownie tylko zadanie weryfikatora nadrzędnego, aby odświeżyć wynik parasola i podsumowanie czasów.

-Do odzyskiwania zarówno `Full Release Validation`, jak i `OpenClaw Release Checks` akceptują `rerun_group`. Użyj `all` dla kandydata do wydania, `ci` tylko dla zwykłego pełnego podrzędnego CI, `plugin-prerelease` tylko dla podrzędnego prerelease Plugin, `release-checks` dla każdego podrzędnego zadania wydania albo węższej grupy: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` lub `npm-telegram` w zadaniu nadrzędnym. Dzięki temu ponowne uruchomienie nieudanego środowiska wydania pozostaje ograniczone po ukierunkowanej poprawce.
+W celu odzyskiwania zarówno `Full Release Validation`, jak i `OpenClaw Release Checks` akceptują `rerun_group`. Użyj `all` dla kandydata do wydania, `ci` tylko dla zwykłego podrzędnego pełnego CI, `plugin-prerelease` tylko dla podrzędnego wstępnego wydania pluginów, `release-checks` dla każdego podrzędnego wydania albo węższej grupy: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` lub `npm-telegram` w przebiegu parasolowym. Dzięki temu ponowne uruchomienie nieudanego środowiska wydania pozostaje ograniczone po ukierunkowanej poprawce.

-`OpenClaw Release Checks` używa zaufanej referencji workflow, aby jednorazowo rozwiązać wybraną referencję do archiwum tar `release-package-under-test`, a następnie przekazuje ten artefakt zarówno do workflow Docker ścieżki wydania live/E2E, jak i do odłamka akceptacji pakietu. Dzięki temu bajty pakietu pozostają spójne we wszystkich środowiskach wydania i unika się ponownego pakowania tego samego kandydata w wielu zadaniach podrzędnych.
+`OpenClaw Release Checks` używa zaufanego odwołania workflow, aby jednorazowo rozwiązać wybrane odwołanie do archiwum `release-package-under-test`, a następnie przekazuje ten artefakt zarówno do workflow Docker ścieżki wydania live/E2E, jak i do sharda akceptacji pakietu. Dzięki temu bajty pakietu pozostają spójne między środowiskami wydania i nie trzeba ponownie pakować tego samego kandydata w wielu zadaniach podrzędnych.

-Duplikaty uruchomień `Full Release Validation` dla `ref=main` i `rerun_group=all`
-zastępują starsze zadanie nadrzędne. Monitor nadrzędny anuluje każdy workflow podrzędny,
-który już wysłał, gdy zadanie nadrzędne zostanie anulowane, więc nowsza walidacja gałęzi main
-nie czeka za przestarzałym dwugodzinnym uruchomieniem release-check. Walidacja gałęzi/tagu wydania
-oraz ukierunkowane grupy ponownego uruchomienia zachowują `cancel-in-progress: false`.
+Zduplikowane uruchomienia `Full Release Validation` dla `ref=main` i `rerun_group=all`
+zastępują starszy przebieg parasolowy. Monitor nadrzędny anuluje każdy workflow podrzędny, który
+już wysłał, gdy nadrzędny zostanie anulowany, więc nowsza walidacja main
+nie czeka za przestarzałym dwugodzinnym uruchomieniem release-check. Walidacja gałęzi/tagów
+wydania i ukierunkowane grupy ponownych uruchomień zachowują `cancel-in-progress: false`.

-## Odłamki live i E2E
+## Shardy live i E2E

-Podrzędne zadanie release live/E2E zachowuje szerokie natywne pokrycie `pnpm test:live`, ale uruchamia je jako nazwane odłamki przez `scripts/test-live-shard.mjs` zamiast jednego zadania szeregowego:
+Podrzędny przebieg live/E2E wydania zachowuje szerokie natywne pokrycie `pnpm test:live`, ale uruchamia je jako nazwane shardy przez `scripts/test-live-shard.mjs` zamiast jednego zadania szeregowego:

 - `native-live-src-agents`
 - `native-live-src-gateway-core`
@ -223,61 +210,61 @@ Podrzędne zadanie release live/E2E zachowuje szerokie natywne pokrycie `pnpm te
 - `native-live-extensions-openai`
 - `native-live-extensions-o-z-other`
 - `native-live-extensions-xai`
- podzielone odłamki audio/wideo mediów oraz odłamki muzyczne filtrowane według dostawcy
+- podzielone shardy audio/wideo mediów i shardy muzyki filtrowane według dostawcy

-Zachowuje to takie samo pokrycie plików, a jednocześnie ułatwia ponowne uruchamianie i diagnozowanie powolnych awarii dostawców live. Zbiorcze nazwy odłamków `native-live-extensions-o-z`, `native-live-extensions-media` i `native-live-extensions-media-music` pozostają prawidłowe dla ręcznych jednorazowych ponownych uruchomień.
+Zachowuje to takie samo pokrycie plików, a jednocześnie ułatwia ponowne uruchamianie i diagnozowanie powolnych awarii dostawców live. Zbiorcze nazwy shardów `native-live-extensions-o-z`, `native-live-extensions-media` i `native-live-extensions-media-music` pozostają prawidłowe dla ręcznych jednorazowych ponownych uruchomień.

-Natywne odłamki mediów live działają w `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, budowanym przez workflow `Live Media Runner Image`. Ten obraz ma wstępnie zainstalowane `ffmpeg` i `ffprobe`; zadania mediów tylko weryfikują binaria przed konfiguracją. Zostaw zestawy live oparte na Dockerze na zwykłych runnerach Blacksmith — zadania kontenerowe są niewłaściwym miejscem do uruchamiania zagnieżdżonych testów Docker.
+Natywne shardy mediów live działają w `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, budowanym przez workflow `Live Media Runner Image`. Ten obraz ma wstępnie zainstalowane `ffmpeg` i `ffprobe`; zadania mediów tylko weryfikują binaria przed konfiguracją. Zostaw zestawy live oparte na Dockerze na zwykłych runnerach Blacksmith — zadania kontenerowe nie są właściwym miejscem do uruchamiania zagnieżdżonych testów Dockera.

-Odłamki live modeli/backendów oparte na Dockerze używają osobnego współdzielonego obrazu `ghcr.io/openclaw/openclaw-live-test:<sha>` dla wybranego commitu. Workflow wydania live buduje i wypycha ten obraz raz, a następnie odłamki modelu Docker live, Gateway podzielone według dostawców, backendu CLI, wiązania ACP i harnessu Codex działają z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Odłamki Gateway Docker mają jawne limity `timeout` na poziomie skryptu, poniżej limitu czasu zadania workflow, aby zablokowany kontener lub ścieżka czyszczenia szybko kończyły się niepowodzeniem zamiast zużywać cały budżet release-check. Jeśli te odłamki niezależnie przebudowują pełny docelowy obraz Docker źródeł, uruchomienie wydania jest błędnie skonfigurowane i zmarnuje czas zegarowy na zduplikowane budowy obrazów.
+Shardy live modelu/backendu oparte na Dockerze używają osobnego współdzielonego obrazu `ghcr.io/openclaw/openclaw-live-test:<sha>` dla wybranego commita. Workflow wydania live buduje i wypycha ten obraz raz, a następnie shardy modelu live Docker, Gateway shardowanego według dostawcy, backendu CLI, wiązania ACP i harnessu Codex działają z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Shardy Docker Gateway mają jawne limity `timeout` na poziomie skryptu, poniżej limitu czasu zadania workflow, aby zawieszony kontener lub ścieżka czyszczenia szybko zakończyły się niepowodzeniem zamiast zużyć cały budżet release-check. Jeśli te shardy niezależnie przebudowują pełny docelowy obraz Docker źródeł, uruchomienie wydania jest błędnie skonfigurowane i zmarnuje czas ścienny na zduplikowane budowania obrazów.

 ## Akceptacja pakietu

-Użyj `Package Acceptance`, gdy pytanie brzmi: „czy ten instalowalny pakiet OpenClaw działa jako produkt?”. Różni się to od zwykłego CI: zwykłe CI waliduje drzewo źródeł, a akceptacja pakietu waliduje pojedyncze archiwum tar przez ten sam harness Docker E2E, którego użytkownicy używają po instalacji lub aktualizacji.
+Użyj `Package Acceptance`, gdy pytanie brzmi: „czy ten instalowalny pakiet OpenClaw działa jako produkt?”. Różni się to od zwykłego CI: zwykłe CI waliduje drzewo źródłowe, natomiast akceptacja pakietu waliduje pojedyncze archiwum przez ten sam harness Docker E2E, którego użytkownicy używają po instalacji lub aktualizacji.

 ### Zadania

-1. `resolve_package` pobiera `workflow_ref`, rozwiązuje jednego kandydata pakietu, zapisuje `.artifacts/docker-e2e-package/openclaw-current.tgz`, zapisuje `.artifacts/docker-e2e-package/package-candidate.json`, przesyła oba jako artefakt `package-under-test` oraz wypisuje źródło, referencję workflow, referencję pakietu, wersję, SHA-256 i profil w podsumowaniu kroku GitHub.
-2. `docker_acceptance` wywołuje `openclaw-live-and-e2e-checks-reusable.yml` z `ref=workflow_ref` i `package_artifact_name=package-under-test`. Workflow wielokrotnego użytku pobiera ten artefakt, waliduje inwentarz archiwum tar, w razie potrzeby przygotowuje obrazy Docker z digestem pakietu i uruchamia wybrane ścieżki Docker względem tego pakietu zamiast pakować checkout workflow. Gdy profil wybiera wiele ukierunkowanych `docker_lanes`, workflow wielokrotnego użytku przygotowuje pakiet i współdzielone obrazy raz, a następnie rozdziela te ścieżki jako równoległe ukierunkowane zadania Docker z unikalnymi artefaktami.
-3. `package_telegram` opcjonalnie wywołuje `NPM Telegram Beta E2E`. Uruchamia się, gdy `telegram_mode` nie jest `none`, i instaluje ten sam artefakt `package-under-test`, gdy Akceptacja pakietu rozwiązała jeden; samodzielne wysłanie Telegram nadal może instalować opublikowaną specyfikację npm.
-4. `summary` kończy workflow niepowodzeniem, jeśli rozwiązywanie pakietu, akceptacja Docker lub opcjonalna ścieżka Telegram zakończyły się niepowodzeniem.
+1. `resolve_package` pobiera `workflow_ref`, rozwiązuje jednego kandydata pakietu, zapisuje `.artifacts/docker-e2e-package/openclaw-current.tgz`, zapisuje `.artifacts/docker-e2e-package/package-candidate.json`, przesyła oba jako artefakt `package-under-test` oraz wypisuje źródło, odwołanie workflow, odwołanie pakietu, wersję, SHA-256 i profil w podsumowaniu kroku GitHub.
+2. `docker_acceptance` wywołuje `openclaw-live-and-e2e-checks-reusable.yml` z `ref=workflow_ref` i `package_artifact_name=package-under-test`. Workflow wielokrotnego użytku pobiera ten artefakt, waliduje inwentarz archiwum, przygotowuje obrazy Docker z digestem pakietu, gdy są potrzebne, i uruchamia wybrane tory Docker względem tego pakietu zamiast pakować checkout workflow. Gdy profil wybiera wiele ukierunkowanych `docker_lanes`, workflow wielokrotnego użytku przygotowuje pakiet i współdzielone obrazy raz, a następnie rozprasza te tory jako równoległe ukierunkowane zadania Docker z unikalnymi artefaktami.
+3. `package_telegram` opcjonalnie wywołuje `NPM Telegram Beta E2E`. Uruchamia się, gdy `telegram_mode` nie jest `none`, i instaluje ten sam artefakt `package-under-test`, gdy Package Acceptance go rozwiązało; samodzielne wysłanie Telegram nadal może zainstalować opublikowaną specyfikację npm.
+4. `summary` powoduje niepowodzenie workflow, jeśli rozwiązywanie pakietu, akceptacja Docker lub opcjonalny tor Telegram zakończyły się niepowodzeniem.

 ### Źródła kandydatów

- `source=npm` akceptuje tylko `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` albo dokładną wersję wydania OpenClaw, taką jak `openclaw@2026.4.27-beta.2`. Używaj tego do akceptacji opublikowanych wydań prerelease/stable.
- `source=ref` pakuje zaufaną gałąź, tag lub pełny SHA commitu `package_ref`. Resolver pobiera gałęzie/tagi OpenClaw, weryfikuje, że wybrany commit jest osiągalny z historii gałęzi repozytorium lub tagu wydania, instaluje zależności w odłączonym worktree i pakuje go za pomocą `scripts/package-openclaw-for-docker.mjs`.
+- `source=npm` akceptuje tylko `openclaw@beta`, `openclaw@latest` albo dokładną wersję wydania OpenClaw, taką jak `openclaw@2026.4.27-beta.2`. Użyj tego do akceptacji opublikowanych wydań wstępnych/stabilnych.
+- `source=ref` pakuje zaufaną gałąź, tag albo pełny SHA commita `package_ref`. Resolver pobiera gałęzie/tagi OpenClaw, weryfikuje, że wybrany commit jest osiągalny z historii gałęzi repozytorium albo tagu wydania, instaluje zależności w odłączonym worktree i pakuje go za pomocą `scripts/package-openclaw-for-docker.mjs`.
 - `source=url` pobiera HTTPS `.tgz`; `package_sha256` jest wymagane.
- `source=artifact` pobiera jedno `.tgz` z `artifact_run_id` i `artifact_name`; `package_sha256` jest opcjonalne, ale powinno zostać podane dla zewnętrznie udostępnionych artefaktów.
+- `source=artifact` pobiera jedno `.tgz` z `artifact_run_id` i `artifact_name`; `package_sha256` jest opcjonalne, ale powinno być podane dla artefaktów udostępnianych zewnętrznie.

-Trzymaj `workflow_ref` i `package_ref` oddzielnie. `workflow_ref` to zaufany kod workflow/harnessu, który uruchamia test. `package_ref` to commit źródłowy, który zostaje spakowany, gdy `source=ref`. Pozwala to obecnemu harnessowi testowemu walidować starsze zaufane commity źródłowe bez uruchamiania starej logiki workflow.
+Trzymaj `workflow_ref` i `package_ref` osobno. `workflow_ref` to zaufany kod workflow/harnessu, który uruchamia test. `package_ref` to commit źródłowy, który zostaje spakowany, gdy `source=ref`. Pozwala to bieżącemu harnessowi testowemu walidować starsze zaufane commity źródłowe bez uruchamiania starej logiki workflow.

 ### Profile zestawu

 - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
 - `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `published-upgrade-survivor`, `plugins-offline`, `plugin-update`
 - `product` — `package` plus `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
- `full` — pełne fragmenty Docker ścieżki wydania z OpenWebUI
+- `full` — pełne fragmenty ścieżki wydania Docker z OpenWebUI
 - `custom` — dokładne `docker_lanes`; wymagane, gdy `suite_profile=custom`

-Profil `package` używa offline’owego pokrycia Plugin, aby walidacja opublikowanego pakietu nie była blokowana przez dostępność ClawHub live. Opcjonalna ścieżka Telegram ponownie używa artefaktu `package-under-test` w `NPM Telegram Beta E2E`, a ścieżka opublikowanej specyfikacji npm pozostaje dla samodzielnych wysłań.
+Profil `package` używa pokrycia pluginów offline, więc walidacja opublikowanego pakietu nie jest uzależniona od dostępności ClawHub live. Opcjonalny tor Telegram ponownie używa artefaktu `package-under-test` w `NPM Telegram Beta E2E`, przy czym ścieżka opublikowanej specyfikacji npm pozostaje dostępna dla samodzielnych wysłań.

-Dedykowane zasady testowania aktualizacji i Plugin, w tym polecenia lokalne,
-ścieżki Docker, dane wejściowe Akceptacji pakietu, domyślne ustawienia wydania i triage awarii,
-zobacz w [Testowanie aktualizacji i Plugin](/pl/help/testing-updates-plugins).
+Dedykowaną politykę testowania aktualizacji i pluginów, w tym lokalne polecenia,
+tory Docker, dane wejściowe Package Acceptance, domyślne ustawienia wydania i triage awarii,
+opisuje [Testowanie aktualizacji i pluginów](/pl/help/testing-updates-plugins).

-Kontrole wydania wywołują Akceptację pakietu z `source=artifact`, przygotowanym artefaktem pakietu wydania, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` i `telegram_mode=mock-openai`. Dzięki temu dowody migracji pakietu, aktualizacji, czyszczenia przestarzałych zależności Plugin, naprawy instalacji skonfigurowanego Plugin, offline’owego Plugin, `plugin-update` i Telegram pozostają na tym samym rozwiązanym archiwum tar pakietu. Ustaw `package_acceptance_package_spec` w Full Release Validation lub OpenClaw Release Checks, aby uruchomić tę samą macierz względem wydanego pakietu npm zamiast artefaktu zbudowanego z SHA. Kontrole wydania cross-OS nadal obejmują specyficzne dla systemu operacyjnego onboardowanie, instalator i zachowanie platformy; walidacja produktu pakietu/aktualizacji powinna zaczynać się od Akceptacji pakietu. Ścieżka Docker `published-upgrade-survivor` waliduje jedną opublikowaną bazę pakietu na uruchomienie. W Akceptacji pakietu rozwiązane archiwum tar `package-under-test` jest zawsze kandydatem, a `published_upgrade_survivor_baseline` wybiera zapasową opublikowaną bazę, domyślnie `openclaw@latest`; polecenia ponownego uruchomienia nieudanej ścieżki zachowują tę bazę. Ustaw `published_upgrade_survivor_baselines=all-since-2026.4.23`, aby rozszerzyć pełne CI wydania na każde stabilne wydanie npm od `2026.4.23` do `latest`; `release-history` pozostaje dostępne do ręcznego szerszego próbkowania ze starszą kotwicą sprzed daty. Ustaw `published_upgrade_survivor_scenarios=reported-issues`, aby rozszerzyć te same bazy na fixture’y w kształcie zgłoszeń dla konfiguracji Feishu, zachowanych plików bootstrap/persona, skonfigurowanych instalacji Plugin OpenClaw, ścieżek logów z tyldą oraz przestarzałych katalogów głównych zależności legacy Plugin. Osobny workflow `Update Migration` używa ścieżki Docker `update-migration` z `all-since-2026.4.23` i `plugin-deps-cleanup`, gdy pytaniem jest wyczerpujące czyszczenie opublikowanej aktualizacji, a nie zwykły zakres Full Release CI. Lokalne uruchomienia zbiorcze mogą przekazywać dokładne specyfikacje pakietów przez `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, zachować jedną ścieżkę przez `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, taką jak `openclaw@2026.4.15`, albo ustawić `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` dla macierzy scenariuszy. Opublikowana ścieżka konfiguruje bazę za pomocą wbudowanej receptury polecenia `openclaw config set`, zapisuje kroki receptury w `summary.json` oraz sprawdza `/healthz`, `/readyz` i status RPC po starcie Gateway. Ścieżki świeżej instalacji pakietowej i instalatora Windows weryfikują także, że zainstalowany pakiet może importować nadpisanie sterowania przeglądarką z surowej bezwzględnej ścieżki Windows. Smoke tury agenta OpenAI cross-OS domyślnie używa `OPENCLAW_CROSS_OS_OPENAI_MODEL`, gdy jest ustawione, w przeciwnym razie `openai/gpt-5.4`, więc dowód instalacji i Gateway pozostaje na modelu testowym GPT-5, unikając domyślnych modeli GPT-4.x.
+Release checks wywołują Package Acceptance z `source=artifact`, przygotowanym artefaktem pakietu wydania, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` i `telegram_mode=mock-openai`. Dzięki temu migracja pakietu, aktualizacja, czyszczenie przestarzałych zależności pluginów, naprawa instalacji skonfigurowanych pluginów, plugin offline, plugin-update i dowód Telegram działają na tym samym rozwiązanym archiwum pakietu. Ustaw `package_acceptance_package_spec` w Full Release Validation lub OpenClaw Release Checks, aby uruchomić tę samą macierz względem wysłanego pakietu npm zamiast artefaktu zbudowanego z SHA. Cross-OS release checks nadal obejmują specyficzne dla systemu operacyjnego onboarding, instalator i zachowanie platformy; walidacja produktu pakietu/aktualizacji powinna zaczynać się od Package Acceptance. Tor Docker `published-upgrade-survivor` waliduje jedną opublikowaną bazę pakietu na uruchomienie. W Package Acceptance rozwiązane archiwum `package-under-test` zawsze jest kandydatem, a `published_upgrade_survivor_baseline` wybiera awaryjną opublikowaną bazę, domyślnie `openclaw@latest`; polecenia ponownego uruchomienia nieudanego toru zachowują tę bazę. Ustaw `published_upgrade_survivor_baselines=all-since-2026.4.23`, aby rozszerzyć Full Release CI na każde stabilne wydanie npm od `2026.4.23` do `latest`; `release-history` pozostaje dostępne do ręcznego szerszego próbkowania ze starszym punktem odniesienia sprzed tej daty. Ustaw `published_upgrade_survivor_scenarios=reported-issues`, aby rozszerzyć te same bazy na fixtures w kształcie zgłoszeń dla konfiguracji Feishu, zachowanych plików bootstrap/persona, instalacji skonfigurowanych pluginów OpenClaw, ścieżek logów z tyldą i przestarzałych katalogów głównych zależności starszych pluginów. Osobny workflow `Update Migration` używa toru Docker `update-migration` z `all-since-2026.4.23` i `plugin-deps-cleanup`, gdy pytaniem jest wyczerpujące czyszczenie opublikowanej aktualizacji, a nie normalna szerokość Full Release CI. Lokalne uruchomienia zbiorcze mogą przekazywać dokładne specyfikacje pakietów przez `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, zachować pojedynczy tor przez `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, takie jak `openclaw@2026.4.15`, albo ustawić `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` dla macierzy scenariuszy. Opublikowany tor konfiguruje bazę za pomocą wbudowanej receptury polecenia `openclaw config set`, zapisuje kroki receptury w `summary.json` i sonduje `/healthz`, `/readyz` oraz status RPC po uruchomieniu Gateway. Tory świeżej instalacji pakietu i instalatora Windows sprawdzają także, czy zainstalowany pakiet może zaimportować override browser-control z surowej bezwzględnej ścieżki Windows. Smoke agent-turn OpenAI cross-OS domyślnie używa `OPENCLAW_CROSS_OS_OPENAI_MODEL`, gdy jest ustawione, w przeciwnym razie `openai/gpt-5.4`, więc dowód instalacji i Gateway pozostaje na modelu testowym GPT-5, unikając jednocześnie domyślnych ustawień GPT-4.x.

-### Okna kompatybilności legacy
+### Okna zgodności ze starszymi wersjami

-Akceptacja pakietu ma ograniczone okna kompatybilności legacy dla już opublikowanych pakietów. Pakiety do `2026.4.25` włącznie, w tym `2026.4.25-beta.*`, mogą używać ścieżki kompatybilności:
+Package Acceptance ma ograniczone okna zgodności ze starszymi wersjami dla już opublikowanych pakietów. Pakiety do `2026.4.25` włącznie, w tym `2026.4.25-beta.*`, mogą używać ścieżki zgodności:

- znane prywatne wpisy QA w `dist/postinstall-inventory.json` mogą wskazywać na pliki pominięte w archiwum tar;
+- znane prywatne wpisy QA w `dist/postinstall-inventory.json` mogą wskazywać pliki pominięte w archiwum;
 - `doctor-switch` może pominąć podprzypadek trwałości `gateway install --wrapper`, gdy pakiet nie udostępnia tej flagi;
- `update-channel-switch` może usuwać brakujące `pnpm.patchedDependencies` z fałszywego fixture’a git wyprowadzonego z archiwum tar i może logować brak utrwalonego `update.channel`;
- smoke testy Plugin mogą czytać legacy lokalizacje rekordów instalacji albo akceptować brak trwałości rekordu instalacji marketplace;
- `plugin-update` może dopuszczać migrację metadanych konfiguracji, nadal wymagając, aby rekord instalacji i zachowanie bez ponownej instalacji pozostały niezmienione.
+- `update-channel-switch` może usunąć brakujące `pnpm.patchedDependencies` z fałszywego fixture git pochodzącego z archiwum i może zalogować brakujące utrwalone `update.channel`;
+- smoke testy pluginów mogą odczytywać starsze lokalizacje rekordów instalacji albo akceptować brak trwałości rekordów instalacji marketplace;
+- `plugin-update` może dopuścić migrację metadanych konfiguracji, nadal wymagając, aby rekord instalacji i zachowanie bez ponownej instalacji pozostały niezmienione.

-Opublikowany pakiet `2026.4.26` może również ostrzegać o lokalnych plikach znaczników metadanych budowy, które zostały już wydane. Późniejsze pakiety muszą spełniać nowoczesne kontrakty; te same warunki kończą się niepowodzeniem zamiast ostrzeżeniem lub pominięciem.
+Opublikowany pakiet `2026.4.26` może również ostrzegać o lokalnych plikach znaczników metadanych budowania, które już zostały wysłane. Późniejsze pakiety muszą spełniać nowoczesne kontrakty; te same warunki kończą się niepowodzeniem zamiast ostrzeżeniem lub pominięciem.

 ### Przykłady

@ -320,151 +307,151 @@ gh workflow run package-acceptance.yml \
  -f docker_lanes='install-e2e plugin-update'
 ```

-Podczas debugowania nieudanego uruchomienia akceptacji pakietu zacznij od podsumowania `resolve_package`, aby potwierdzić źródło pakietu, wersję i SHA-256. Następnie sprawdź podrzędne uruchomienie `docker_acceptance` oraz jego artefakty Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, logi torów, czasy faz i polecenia ponownego uruchomienia. Preferuj ponowne uruchomienie nieudanego profilu pakietu lub dokładnych torów Docker zamiast ponownego uruchamiania pełnej walidacji wydania.
+Podczas debugowania nieudanego uruchomienia akceptacji pakietu zacznij od podsumowania `resolve_package`, aby potwierdzić źródło pakietu, wersję i SHA-256. Następnie sprawdź podrzędne uruchomienie `docker_acceptance` i jego artefakty Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, logi pasów, czasy faz i polecenia ponownego uruchomienia. Preferuj ponowne uruchomienie nieudanego profilu pakietu lub dokładnych pasów Docker zamiast ponownego uruchamiania pełnej walidacji wydania.

-## Dymny test instalacji
+## Smoke instalacji

-Osobny przepływ pracy `Install Smoke` ponownie używa tego samego skryptu zakresu przez własne zadanie `preflight`. Dzieli pokrycie dymne na `run_fast_install_smoke` i `run_full_install_smoke`.
+Oddzielny workflow `Install Smoke` ponownie używa tego samego skryptu zakresu przez własne zadanie `preflight`. Dzieli pokrycie smoke na `run_fast_install_smoke` i `run_full_install_smoke`.

- **Szybka ścieżka** uruchamia się dla pull requestów dotykających powierzchni Docker/pakietów, zmian pakietów/manifestów dołączonych Plugin albo powierzchni rdzeniowego Plugin/kanału/Gateway/Plugin SDK, które sprawdzają zadania dymne Docker. Zmiany wyłącznie w kodzie źródłowym dołączonych Plugin, edycje wyłącznie testów i edycje wyłącznie dokumentacji nie rezerwują workerów Docker. Szybka ścieżka buduje obraz głównego Dockerfile raz, sprawdza CLI, uruchamia dymny test CLI usuwania agentów ze współdzielonego obszaru roboczego, uruchamia kontenerowy test e2e sieci Gateway, weryfikuje argument budowania dołączonego rozszerzenia i uruchamia ograniczony profil Docker dołączonych Plugin z łącznym limitem czasu polecenia 240 sekund (każde uruchomienie Docker scenariusza ma osobny limit).
- **Pełna ścieżka** zachowuje instalację pakietu QR i pokrycie instalatora Docker/aktualizacji dla nocnych zaplanowanych uruchomień, ręcznych wywołań, kontroli wydań przez workflow-call oraz pull requestów, które rzeczywiście dotykają powierzchni instalatora/pakietu/Docker. W trybie pełnym install-smoke przygotowuje albo ponownie używa jednego obrazu dymnego GHCR głównego Dockerfile dla docelowego SHA, a następnie uruchamia instalację pakietu QR, dymne testy głównego Dockerfile/Gateway, dymne testy instalatora/aktualizacji oraz szybkie Docker E2E dołączonych Plugin jako osobne zadania, aby praca instalatora nie czekała za dymnymi testami obrazu głównego.
+- **Szybka ścieżka** działa dla pull requestów dotykających powierzchni Docker/pakietów, zmian pakietu/manifestu wbudowanego pluginu albo powierzchni głównego pluginu/kanału/gateway/Plugin SDK, które sprawdzają zadania Docker smoke. Zmiany wyłącznie w źródłach wbudowanych pluginów, edycje wyłącznie testów i edycje wyłącznie dokumentacji nie rezerwują workerów Docker. Szybka ścieżka buduje obraz głównego Dockerfile raz, sprawdza CLI, uruchamia smoke CLI usuwania agentów ze współdzielonego obszaru roboczego, uruchamia e2e gateway-network kontenera, weryfikuje argument budowania wbudowanego rozszerzenia i uruchamia ograniczony profil Docker wbudowanych pluginów pod łącznym limitem czasu polecenia 240 sekund (każde uruchomienie Docker scenariusza jest ograniczone osobno).
+- **Pełna ścieżka** zachowuje instalację pakietu QR oraz pokrycie Docker instalatora/aktualizacji dla nocnych zaplanowanych uruchomień, ręcznych wywołań, kontroli wydań przez workflow-call i pull requestów, które faktycznie dotykają powierzchni instalatora/pakietu/Docker. W trybie pełnym install-smoke przygotowuje albo ponownie używa jednego obrazu smoke GHCR głównego Dockerfile dla docelowego SHA, a następnie uruchamia instalację pakietu QR, smoke głównego Dockerfile/gateway, smoke instalatora/aktualizacji oraz szybkie Docker E2E wbudowanych pluginów jako oddzielne zadania, aby praca instalatora nie czekała za smoke głównego obrazu.

-Wypchnięcia do `main` (w tym commity scalające) nie wymuszają pełnej ścieżki; gdy logika zakresu zmian zażądałaby pełnego pokrycia przy wypchnięciu, przepływ pracy zachowuje szybki dymny test Docker, a pełny dymny test instalacji zostawia walidacji nocnej lub walidacji wydania.
+Wypchnięcia do `main` (w tym commity scalające) nie wymuszają pełnej ścieżki; gdy logika zmienionego zakresu zażądałaby pełnego pokrycia przy wypchnięciu, workflow zachowuje szybki Docker smoke i zostawia pełny install smoke walidacji nocnej lub wydania.

-Powolny dymny test dostawcy obrazu przy globalnej instalacji Bun jest osobno bramkowany przez `run_bun_global_install_smoke`. Uruchamia się w nocnym harmonogramie i z przepływu pracy kontroli wydania, a ręczne wywołania `Install Smoke` mogą go włączyć, ale pull requesty i wypchnięcia do `main` tego nie robią. Testy Docker QR i instalatora zachowują własne Dockerfile skoncentrowane na instalacji.
+Powolny smoke globalnej instalacji Bun dla dostawcy obrazów jest osobno bramkowany przez `run_bun_global_install_smoke`. Działa w nocnym harmonogramie i z workflow kontroli wydania, a ręczne wywołania `Install Smoke` mogą go włączyć, ale pull requesty i wypchnięcia do `main` tego nie robią. Testy Docker QR i instalatora zachowują własne Dockerfile skoncentrowane na instalacji.

 ## Lokalne Docker E2E

-`pnpm test:docker:all` wstępnie buduje jeden współdzielony obraz testu live, pakuje OpenClaw raz jako tarball npm i buduje dwa współdzielone obrazy `scripts/e2e/Dockerfile`:
+`pnpm test:docker:all` wstępnie buduje jeden współdzielony obraz live-test, pakuje OpenClaw raz jako tarball npm i buduje dwa współdzielone obrazy `scripts/e2e/Dockerfile`:

- surowy runner Node/Git dla torów instalatora/aktualizacji/zależności Plugin;
- obraz funkcjonalny, który instaluje ten sam tarball w `/app` dla zwykłych torów funkcjonalności.
+- podstawowy runner Node/Git dla pasów instalatora/aktualizacji/zależności pluginów;
+- funkcjonalny obraz, który instaluje ten sam tarball do `/app` dla zwykłych pasów funkcjonalności.

-Definicje torów Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`, logika planera w `scripts/lib/docker-e2e-plan.mjs`, a runner wykonuje tylko wybrany plan. Harmonogram wybiera obraz dla toru za pomocą `OPENCLAW_DOCKER_E2E_BARE_IMAGE` i `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, a następnie uruchamia tory z `OPENCLAW_SKIP_DOCKER_BUILD=1`.
+Definicje pasów Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`, logika planera znajduje się w `scripts/lib/docker-e2e-plan.mjs`, a runner wykonuje tylko wybrany plan. Harmonogram wybiera obraz dla pasa za pomocą `OPENCLAW_DOCKER_E2E_BARE_IMAGE` i `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, a następnie uruchamia pasy z `OPENCLAW_SKIP_DOCKER_BUILD=1`.

-### Parametry
+### Parametry dostrajania

-| Zmienna                                | Domyślnie | Cel                                                                                                  |
-| -------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------- |
-| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10        | Liczba slotów puli głównej dla zwykłych torów.                                                       |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10        | Liczba slotów puli końcowej wrażliwej na dostawców.                                                  |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9         | Limit równoczesnych torów live, aby dostawcy nie ograniczali przepustowości.                         |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10        | Limit równoczesnych torów instalacji npm.                                                            |
-| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7         | Limit równoczesnych torów wielousługowych.                                                           |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000      | Odstęp między startami torów, aby uniknąć burz tworzenia w demonie Docker; ustaw `0`, aby go wyłączyć. |
-| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000   | Awaryjny limit czasu na tor (120 minut); wybrane tory live/końcowe używają ciaśniejszych limitów.    |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset     | `1` wypisuje plan harmonogramu bez uruchamiania torów.                                               |
-| `OPENCLAW_DOCKER_ALL_LANES`            | unset     | Lista dokładnych torów oddzielona przecinkami; pomija dymne sprzątanie, aby agenci mogli odtworzyć jeden nieudany tor. |
+| Zmienna                                | Domyślnie | Cel                                                                                           |
+| -------------------------------------- | --------- | --------------------------------------------------------------------------------------------- |
+| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10        | Liczba slotów głównej puli dla zwykłych pasów.                                                |
+| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10        | Liczba slotów końcowej puli wrażliwej na dostawców.                                           |
+| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9         | Limit współbieżnych pasów live, aby dostawcy nie ograniczali przepustowości.                  |
+| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10        | Limit współbieżnych pasów instalacji npm.                                                     |
+| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7         | Limit współbieżnych pasów wielousługowych.                                                    |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000      | Odstęp między startami pasów, aby uniknąć burz tworzenia demona Docker; ustaw `0`, aby wyłączyć odstęp. |
+| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000   | Zapasowy limit czasu na pas (120 minut); wybrane pasy live/końcowe używają ciaśniejszych limitów. |
+| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | nieustawione | `1` wypisuje plan harmonogramu bez uruchamiania pasów.                                      |
+| `OPENCLAW_DOCKER_ALL_LANES`            | nieustawione | Rozdzielana przecinkami lista dokładnych pasów; pomija cleanup smoke, aby agenci mogli odtworzyć jeden nieudany pas. |

-Tor cięższy niż jego efektywny limit może nadal wystartować z pustej puli, a potem działa sam, dopóki nie zwolni pojemności. Lokalne preflighty zbiorcze sprawdzają Docker, usuwają przestarzałe kontenery OpenClaw E2E, emitują status aktywnych torów, zapisują czasy torów na potrzeby kolejności od najdłuższych i domyślnie przestają planować nowe tory z puli po pierwszym niepowodzeniu.
+Pas cięższy niż jego efektywny limit nadal może wystartować z pustej puli, a potem działa samodzielnie, dopóki nie zwolni pojemności. Lokalne zagregowane preflighty sprawdzają Docker, usuwają przestarzałe kontenery OpenClaw E2E, emitują status aktywnych pasów, utrwalają czasy pasów dla kolejności od najdłuższych i domyślnie przestają planować nowe pasy z puli po pierwszej awarii.

-### Wielokrotnego użytku przepływ pracy live/E2E
+### Workflow live/E2E wielokrotnego użycia

-Wielokrotnego użytku przepływ pracy live/E2E pyta `scripts/test-docker-all.mjs --plan-json`, jaki pakiet, rodzaj obrazu, obraz live, tor i pokrycie poświadczeń są wymagane. `scripts/docker-e2e.mjs` następnie konwertuje ten plan na wyjścia i podsumowania GitHub. Albo pakuje OpenClaw przez `scripts/package-openclaw-for-docker.mjs`, pobiera artefakt pakietu z bieżącego uruchomienia, albo pobiera artefakt pakietu z `package_artifact_run_id`; waliduje inwentarz tarballa; buduje i wypycha oznaczone digestem pakietu obrazy Docker E2E GHCR surowe/funkcjonalne przez cache warstw Docker Blacksmith, gdy plan potrzebuje torów z zainstalowanym pakietem; oraz ponownie używa podanych wejść `docker_e2e_bare_image`/`docker_e2e_functional_image` lub istniejących obrazów z digestem pakietu zamiast przebudowy. Pobrania obrazów Docker są ponawiane z ograniczonym 180-sekundowym limitem czasu na próbę, aby zablokowany strumień rejestru/cache ponowił się szybko zamiast zużywać większość krytycznej ścieżki CI.
+Workflow live/E2E wielokrotnego użycia pyta `scripts/test-docker-all.mjs --plan-json`, jaki pakiet, rodzaj obrazu, obraz live, pas i pokrycie poświadczeń są wymagane. `scripts/docker-e2e.mjs` następnie konwertuje ten plan na wyjścia i podsumowania GitHub. Albo pakuje OpenClaw przez `scripts/package-openclaw-for-docker.mjs`, pobiera artefakt pakietu z bieżącego uruchomienia, albo pobiera artefakt pakietu z `package_artifact_run_id`; waliduje inwentarz tarballa; buduje i wypycha oznaczone digestem pakietu obrazy GHCR Docker E2E bare/functional przez cache warstw Docker Blacksmith, gdy plan wymaga pasów z zainstalowanym pakietem; oraz ponownie używa podanych wejść `docker_e2e_bare_image`/`docker_e2e_functional_image` albo istniejących obrazów z digestem pakietu zamiast przebudowywać. Pobrania obrazów Docker są ponawiane z ograniczonym limitem 180 sekund na próbę, aby zablokowany strumień rejestru/cache szybko ponowił próbę zamiast zużywać większość krytycznej ścieżki CI.

 ### Fragmenty ścieżki wydania

-Pokrycie Docker dla wydania działa w mniejszych zadaniach podzielonych na fragmenty z `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby każdy fragment pobierał tylko rodzaj obrazu, którego potrzebuje, i wykonywał wiele torów przez ten sam ważony harmonogram:
+Pokrycie Docker wydania działa w mniejszych pofragmentowanych zadaniach z `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby każdy fragment pobierał tylko potrzebny rodzaj obrazu i wykonywał wiele pasów przez ten sam ważony harmonogram:

 - `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
 - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h`

-Obecne fragmenty Docker wydania to `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` oraz `plugins-runtime-install-a` do `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` i `plugins-integrations` pozostają zbiorczymi aliasami Plugin/środowiska uruchomieniowego. Alias toru `install-e2e` pozostaje zbiorczym aliasem ręcznego ponownego uruchomienia dla obu torów instalatora dostawcy.
+Bieżące fragmenty Docker wydania to `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` oraz od `plugins-runtime-install-a` do `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` i `plugins-integrations` pozostają zagregowanymi aliasami plugin/runtime. Alias pasa `install-e2e` pozostaje zagregowanym aliasem ręcznego ponownego uruchomienia dla obu pasów instalatora dostawcy.

-OpenWebUI jest składane do `plugins-runtime-services`, gdy żąda tego pełne pokrycie ścieżki wydania, i zachowuje samodzielny fragment `openwebui` tylko dla wywołań dotyczących wyłącznie OpenWebUI. Tory aktualizacji dołączonych kanałów ponawiają się raz przy przejściowych awariach sieci npm.
+OpenWebUI jest składany do `plugins-runtime-services`, gdy żąda tego pełne pokrycie release-path, i zachowuje samodzielny fragment `openwebui` tylko dla wywołań dotyczących wyłącznie OpenWebUI. Pasy aktualizacji wbudowanych kanałów ponawiają raz w przypadku przejściowych awarii sieci npm.

-Każdy fragment przesyła `.artifacts/docker-tests/` z logami torów, czasami, `summary.json`, `failures.json`, czasami faz, JSON-em planu harmonogramu, tabelami wolnych torów i poleceniami ponownego uruchomienia dla poszczególnych torów. Wejście przepływu pracy `docker_lanes` uruchamia wybrane tory na przygotowanych obrazach zamiast zadań fragmentów, co utrzymuje debugowanie nieudanego toru w granicach jednego ukierunkowanego zadania Docker i przygotowuje, pobiera albo ponownie używa artefaktu pakietu dla tego uruchomienia; jeśli wybrany tor jest torem Docker live, ukierunkowane zadanie buduje lokalnie obraz testu live dla tego ponownego uruchomienia. Generowane polecenia ponownego uruchomienia GitHub dla poszczególnych torów zawierają `package_artifact_run_id`, `package_artifact_name` i wejścia przygotowanych obrazów, gdy te wartości istnieją, aby nieudany tor mógł ponownie użyć dokładnego pakietu i obrazów z nieudanego uruchomienia.
+Każdy fragment przesyła `.artifacts/docker-tests/` z logami pasów, czasami, `summary.json`, `failures.json`, czasami faz, JSON planu harmonogramu, tabelami wolnych pasów i poleceniami ponownego uruchomienia dla każdego pasa. Wejście workflow `docker_lanes` uruchamia wybrane pasy względem przygotowanych obrazów zamiast zadań fragmentów, co ogranicza debugowanie nieudanego pasa do jednego celowanego zadania Docker i przygotowuje, pobiera albo ponownie używa artefaktu pakietu dla tego uruchomienia; jeśli wybrany pas jest pasem live Docker, celowane zadanie buduje obraz live-test lokalnie dla tego ponownego uruchomienia. Wygenerowane polecenia GitHub ponownego uruchomienia dla każdego pasa zawierają `package_artifact_run_id`, `package_artifact_name` i wejścia przygotowanych obrazów, gdy te wartości istnieją, aby nieudany pas mógł ponownie użyć dokładnego pakietu i obrazów z nieudanego uruchomienia.

 ```bash
 pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
 pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summaries
 ```

-Zaplanowany przepływ pracy live/E2E codziennie uruchamia pełny zestaw Docker ścieżki wydania.
+Zaplanowany workflow live/E2E uruchamia codziennie pełny zestaw Docker release-path.

-## Wydanie przedpremierowe Plugin
+## Prerelease Plugin

-`Plugin Prerelease` to droższe pokrycie produktu/pakietu, więc jest osobnym przepływem pracy wywoływanym przez `Full Release Validation` albo przez jawnego operatora. Zwykłe pull requesty, wypchnięcia do `main` i samodzielne ręczne wywołania CI utrzymują ten zestaw wyłączony. Równoważy testy dołączonych Plugin między ośmioma workerami rozszerzeń; te zadania shardów rozszerzeń uruchamiają naraz do dwóch grup konfiguracji Plugin z jednym workerem Vitest na grupę i większą stertą Node, aby obciążone importami partie Plugin nie tworzyły dodatkowych zadań CI. Ścieżka przedpremierowa Docker tylko dla wydania grupuje ukierunkowane tory Docker w małych grupach, aby uniknąć rezerwowania dziesiątek runnerów dla zadań trwających od jednej do trzech minut.
+`Plugin Prerelease` to droższe pokrycie produktu/pakietu, więc jest oddzielnym workflow wywoływanym przez `Full Release Validation` albo przez jawnego operatora. Zwykłe pull requesty, wypchnięcia do `main` i samodzielne ręczne wywołania CI zostawiają ten zestaw wyłączony. Równoważy testy wbudowanych pluginów między ośmioma workerami rozszerzeń; te zadania shardów rozszerzeń uruchamiają do dwóch grup konfiguracji pluginów naraz z jednym workerem Vitest na grupę i większym stertą Node, aby partie pluginów ciężkie od importów nie tworzyły dodatkowych zadań CI. Ścieżka prerelease Docker tylko dla wydań grupuje celowane pasy Docker w małe grupy, aby uniknąć rezerwowania dziesiątek runnerów dla zadań trwających od jednej do trzech minut.

-## Laboratorium QA
+## QA Lab

-Laboratorium QA ma dedykowane tory CI poza głównym inteligentnie zakresowanym przepływem pracy. Parzystość agentowa jest zagnieżdżona pod szerokimi harnessami QA i wydania, a nie jest samodzielnym przepływem pracy PR. Użyj `Full Release Validation` z `rerun_group=qa-parity`, gdy parzystość powinna działać razem z szeroką walidacją.
+QA Lab ma dedykowane pasy CI poza głównym workflow inteligentnie zakresowanym. Parzystość agentowa jest zagnieżdżona pod szerokimi uprzężami QA i wydań, a nie jako samodzielny workflow PR. Użyj `Full Release Validation` z `rerun_group=qa-parity`, gdy parzystość powinna jechać z szerokim uruchomieniem walidacji.

- Przepływ pracy `QA-Lab - All Lanes` uruchamia się co noc na `main` oraz przy ręcznym wywołaniu; rozdziela próbny tor parzystości, tor live Matrix oraz tory live Telegram i Discord jako równoległe zadania. Zadania live używają środowiska `qa-live-shared`, a Telegram/Discord używają dzierżaw Convex.
+- Workflow `QA-Lab - All Lanes` działa co noc na `main` i przy ręcznym wywołaniu; rozdziela pas mock parity, pas live Matrix oraz pasy live Telegram i Discord jako zadania równoległe. Zadania live używają środowiska `qa-live-shared`, a Telegram/Discord używają dzierżaw Convex.

-Kontrole wydania uruchamiają tory transportu live Matrix i Telegram z deterministycznym próbnym dostawcą i modelami kwalifikowanymi jako próbne (`mock-openai/gpt-5.5` i `mock-openai/gpt-5.5-alt`), aby kontrakt kanału był odizolowany od opóźnień modelu live i normalnego startu Plugin dostawcy. Gateway transportu live wyłącza wyszukiwanie w pamięci, ponieważ parzystość QA osobno pokrywa zachowanie pamięci; łączność dostawców jest pokrywana przez osobne zestawy live model, natywny dostawca i dostawca Docker.
+Kontrole wydania uruchamiają pasy live transport Matrix i Telegram z deterministycznym dostawcą mock i modelami kwalifikowanymi mock (`mock-openai/gpt-5.5` oraz `mock-openai/gpt-5.5-alt`), aby kontrakt kanału był odizolowany od opóźnień modeli live i normalnego startu pluginu dostawcy. Gateway transportu live wyłącza wyszukiwanie pamięci, ponieważ QA parity obejmuje zachowanie pamięci osobno; łączność dostawcy jest pokryta przez oddzielne zestawy live model, natywny dostawca i dostawca Docker.

-Matrix używa `--profile fast` dla zaplanowanych bramek i bramek wydania, dodając `--fail-fast` tylko wtedy, gdy obsługuje to wyewidencjonowane CLI. Domyślne CLI i ręczne wejście przepływu pracy pozostają `all`; ręczne wywołanie `matrix_profile=all` zawsze dzieli pełne pokrycie Matrix na zadania `transport`, `media`, `e2ee-smoke`, `e2ee-deep` i `e2ee-cli`.
+Matrix używa `--profile fast` dla zaplanowanych bramek i bramek wydania, dodając `--fail-fast` tylko wtedy, gdy obsługuje to wypisane CLI. Domyślna wartość CLI i ręczne wejście workflow pozostają `all`; ręczne wywołanie `matrix_profile=all` zawsze sharduje pełne pokrycie Matrix na zadania `transport`, `media`, `e2ee-smoke`, `e2ee-deep` i `e2ee-cli`.

-`OpenClaw Release Checks` uruchamia również krytyczne dla wydania tory Laboratorium QA przed zatwierdzeniem wydania; jego bramka parzystości QA uruchamia pakiety kandydata i bazowe jako równoległe zadania torów, a następnie pobiera oba artefakty do małego zadania raportu na potrzeby końcowego porównania parzystości.
+`OpenClaw Release Checks` uruchamia także krytyczne dla wydania pasy QA Lab przed zatwierdzeniem wydania; jego bramka QA parity uruchamia pakiety kandydata i bazowe jako równoległe zadania pasów, a następnie pobiera oba artefakty do małego zadania raportu na potrzeby końcowego porównania parzystości.

-Dla zwykłych PR-ów kieruj się zakresowanymi dowodami CI/kontroli zamiast traktować parzystość jako wymagany status.
+Dla zwykłych PR-ów stosuj dowody z zakresowego CI/kontroli zamiast traktować parzystość jako wymagany status.

 ## CodeQL

-Przepływ pracy `CodeQL` jest celowo wąskim skanerem bezpieczeństwa pierwszego przebiegu, a nie pełnym przeglądem repozytorium. Codzienne, ręczne oraz uruchamiane dla pull requestów niebędących wersjami roboczymi przebiegi zabezpieczające skanują kod przepływów pracy Actions oraz powierzchnie JavaScript/TypeScript o najwyższym ryzyku, używając zapytań bezpieczeństwa o wysokiej pewności odfiltrowanych do wysokiego/krytycznego poziomu `security-severity`.
+Przepływ pracy `CodeQL` jest celowo wąskim skanerem bezpieczeństwa pierwszego przebiegu, a nie pełnym przeglądem repozytorium. Codzienne, ręczne oraz uruchamiane dla pull requestów niebędących wersjami roboczymi przebiegi ochronne skanują kod przepływów pracy Actions oraz powierzchnie JavaScript/TypeScript o najwyższym ryzyku za pomocą zapytań bezpieczeństwa o wysokiej pewności, filtrowanych do wysokiego/krytycznego poziomu `security-severity`.

-Kontrola pull requestów pozostaje lekka: uruchamia się tylko dla zmian w `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` lub `src` i wykonuje tę samą macierz bezpieczeństwa o wysokiej pewności co zaplanowany przepływ pracy. Android i macOS CodeQL pozostają poza domyślnymi ustawieniami PR.
+Ochrona pull requestów pozostaje lekka: uruchamia się tylko dla zmian w `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` lub `src` i uruchamia tę samą macierz bezpieczeństwa o wysokiej pewności co zaplanowany przepływ pracy. Android i macOS CodeQL pozostają poza domyślnymi ustawieniami PR.

 ### Kategorie bezpieczeństwa

-| Kategoria                                         | Powierzchnia                                                                                                                          |
+| Kategoria                                         | Powierzchnia                                                                                                                           |
 | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-security-high/core-auth-secrets`         | Auth, sekrety, sandbox, cron oraz bazowa warstwa gateway                                                                               |
-| `/codeql-security-high/channel-runtime-boundary`  | Kontrakty implementacji kanałów rdzenia oraz runtime Plugin kanału, gateway, Plugin SDK, sekrety, punkty styku audytu                 |
-| `/codeql-security-high/network-ssrf-boundary`     | Powierzchnie SSRF rdzenia, parsowania IP, osłony sieciowej, web-fetch oraz polityki SSRF Plugin SDK                                   |
-| `/codeql-security-high/mcp-process-tool-boundary` | Serwery MCP, pomocniki wykonywania procesów, dostarczanie wychodzące oraz bramki wykonywania narzędzi agenta                          |
-| `/codeql-security-high/plugin-trust-boundary`     | Powierzchnie zaufania instalacji Plugin, loadera, manifestu, rejestru, instalacji przez menedżera pakietów, ładowania źródeł oraz kontraktu pakietu Plugin SDK |
+| `/codeql-security-high/core-auth-secrets`         | Uwierzytelnianie, sekrety, sandbox, cron oraz bazowy zakres gateway                                                                    |
+| `/codeql-security-high/channel-runtime-boundary`  | Kontrakty implementacji kanałów rdzenia oraz środowisko uruchomieniowe Plugin kanału, Gateway, Plugin SDK, sekrety, punkty audytu      |
+| `/codeql-security-high/network-ssrf-boundary`     | Powierzchnie polityki SSRF rdzenia, parsowania IP, ochrony sieci, web-fetch oraz Plugin SDK SSRF                                      |
+| `/codeql-security-high/mcp-process-tool-boundary` | Serwery MCP, pomocniki wykonywania procesów, dostarczanie wychodzące oraz bramki wykonywania narzędzi agentów                         |
+| `/codeql-security-high/plugin-trust-boundary`     | Powierzchnie zaufania instalacji Plugin, loadera, manifestu, rejestru, instalacji przez menedżer pakietów, ładowania źródeł oraz kontraktu pakietów Plugin SDK |

-### Shardy bezpieczeństwa specyficzne dla platform
+### Fragmenty bezpieczeństwa specyficzne dla platform

- `CodeQL Android Critical Security` — zaplanowany shard bezpieczeństwa Androida. Ręcznie buduje aplikację Android dla CodeQL na najmniejszym runnerze Blacksmith Linux akceptowanym przez kontrolę poprawności przepływu pracy. Przesyła pod `/codeql-critical-security/android`.
- `CodeQL macOS Critical Security` — tygodniowy/ręczny shard bezpieczeństwa macOS. Ręcznie buduje aplikację macOS dla CodeQL na Blacksmith macOS, odfiltrowuje wyniki budowania zależności z przesyłanego SARIF i przesyła pod `/codeql-critical-security/macos`. Pozostaje poza codziennymi domyślnymi ustawieniami, ponieważ build macOS dominuje czas działania nawet przy czystym przebiegu.
+- `CodeQL Android Critical Security` — zaplanowany fragment bezpieczeństwa Androida. Ręcznie buduje aplikację Android dla CodeQL na najmniejszym runnerze Blacksmith Linux akceptowanym przez kontrolę poprawności przepływu pracy. Przesyła pod `/codeql-critical-security/android`.
+- `CodeQL macOS Critical Security` — cotygodniowy/ręczny fragment bezpieczeństwa macOS. Ręcznie buduje aplikację macOS dla CodeQL na Blacksmith macOS, odfiltrowuje wyniki budowania zależności z przesyłanego SARIF i przesyła pod `/codeql-critical-security/macos`. Pozostaje poza codziennymi ustawieniami domyślnymi, ponieważ budowanie macOS dominuje czas działania nawet przy czystym przebiegu.

-### Kategorie jakości krytycznej
+### Kategorie Critical Quality

-`CodeQL Critical Quality` to odpowiadający shard niezwiązany z bezpieczeństwem. Uruchamia tylko zapytania jakości JavaScript/TypeScript o poziomie błędu i niezwiązane z bezpieczeństwem na wąskich powierzchniach o wysokiej wartości na mniejszym runnerze Blacksmith Linux. Jego kontrola pull requestów jest celowo mniejsza niż profil zaplanowany: PR-y niebędące wersjami roboczymi uruchamiają tylko odpowiadające shardy `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` i `plugin-sdk-reply-runtime` dla zmian w kodzie wykonywania poleceń/modeli/narzędzi agenta i wysyłki odpowiedzi, kodzie schematu/migracji/IO konfiguracji, kodzie auth/sekretów/sandboxa/bezpieczeństwa, runtime kanałów rdzenia i dołączonych Plugin kanałów, protokole Gateway/metodach serwera, runtime pamięci/warstwie SDK, MCP/procesach/dostarczaniu wychodzącym, runtime dostawcy/katalogu modeli, diagnostyce sesji/kolejkach dostarczania, loaderze Plugin, Plugin SDK/kontrakcie pakietu albo runtime odpowiedzi Plugin SDK. Zmiany konfiguracji CodeQL i przepływu pracy jakości uruchamiają wszystkie dwanaście shardów jakości PR.
+`CodeQL Critical Quality` to odpowiadający mu fragment niezwiązany z bezpieczeństwem. Uruchamia tylko zapytania jakości JavaScript/TypeScript o ważności błędu i niezwiązane z bezpieczeństwem, obejmujące wąskie powierzchnie o wysokiej wartości na mniejszym runnerze Blacksmith Linux. Jego ochrona pull requestów jest celowo mniejsza niż profil zaplanowany: PR-y niebędące wersjami roboczymi uruchamiają tylko odpowiadające fragmenty `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` oraz `plugin-sdk-reply-runtime` dla zmian w kodzie wykonywania poleceń/modeli/narzędzi agentów i dyspozycji odpowiedzi, schematu/migracji/IO konfiguracji, uwierzytelniania/sekretów/sandboxa/bezpieczeństwa, rdzeniowego kanału i dołączonego środowiska uruchomieniowego Plugin kanału, protokołu Gateway/metody serwera, środowiska uruchomieniowego pamięci/kleju SDK, MCP/procesu/dostarczania wychodzącego, środowiska uruchomieniowego dostawcy/katalogu modeli, diagnostyki sesji/kolejek dostarczania, loadera Plugin, Plugin SDK/kontraktu pakietu albo środowiska uruchomieniowego odpowiedzi Plugin SDK. Zmiany konfiguracji CodeQL i przepływu pracy jakości uruchamiają wszystkie dwanaście fragmentów jakości PR.

-Ręczne wywołanie akceptuje:
+Ręczne uruchomienie przyjmuje:

 ```
 profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
 ```

-Wąskie profile są punktami zaczepienia do nauki/iteracji służącymi do uruchamiania jednego sharda jakości w izolacji.
+Wąskie profile są hakami szkoleniowymi/iteracyjnymi do uruchamiania jednego fragmentu jakości w izolacji.

-| Kategoria                                               | Powierzchnia                                                                                                                                                      |
-| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-critical-quality/core-auth-secrets`            | Kod granicy bezpieczeństwa auth, sekretów, sandboxa, cron i gateway                                                                                               |
-| `/codeql-critical-quality/config-boundary`              | Schemat konfiguracji, migracja, normalizacja i kontrakty IO                                                                                                       |
-| `/codeql-critical-quality/gateway-runtime-boundary`     | Schematy protokołu Gateway i kontrakty metod serwera                                                                                                              |
-| `/codeql-critical-quality/channel-runtime-boundary`     | Kontrakty implementacji kanałów rdzenia i dołączonych Plugin kanałów                                                                                              |
-| `/codeql-critical-quality/agent-runtime-boundary`       | Wykonywanie poleceń, wysyłka modeli/dostawców, wysyłka i kolejki automatycznych odpowiedzi oraz kontrakty runtime płaszczyzny sterowania ACP                      |
-| `/codeql-critical-quality/mcp-process-runtime-boundary` | Serwery MCP i mosty narzędzi, pomocniki nadzorowania procesów oraz kontrakty dostarczania wychodzącego                                                            |
-| `/codeql-critical-quality/memory-runtime-boundary`      | SDK hosta pamięci, fasady runtime pamięci, aliasy pamięci Plugin SDK, warstwa aktywacji runtime pamięci oraz polecenia doctor pamięci                              |
-| `/codeql-critical-quality/session-diagnostics-boundary` | Wewnętrzne elementy kolejki odpowiedzi, kolejki dostarczania sesji, pomocniki wiązania/dostarczania sesji wychodzących, powierzchnie pakietów zdarzeń/logów diagnostycznych oraz kontrakty CLI doctor sesji |
-| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Wysyłka odpowiedzi przychodzących Plugin SDK, pomocniki payloadów/fragmentacji/runtime odpowiedzi, opcje odpowiedzi kanału, kolejki dostarczania oraz pomocniki wiązania sesji/wątków |
-| `/codeql-critical-quality/provider-runtime-boundary`    | Normalizacja katalogu modeli, auth i wykrywanie dostawców, rejestracja runtime dostawców, domyślne ustawienia/katalogi dostawców oraz rejestry web/search/fetch/embedding |
-| `/codeql-critical-quality/ui-control-plane`             | Bootstrap interfejsu sterowania, lokalna trwałość, przepływy sterowania Gateway oraz kontrakty runtime płaszczyzny sterowania zadań                               |
-| `/codeql-critical-quality/web-media-runtime-boundary`   | Pobieranie/wyszukiwanie web rdzenia, IO mediów, rozumienie mediów, generowanie obrazów oraz kontrakty runtime generowania mediów                                  |
-| `/codeql-critical-quality/plugin-boundary`              | Kontrakty loadera, rejestru, powierzchni publicznej oraz punktu wejścia Plugin SDK                                                                                 |
-| `/codeql-critical-quality/plugin-sdk-package-contract`  | Opublikowane źródło Plugin SDK po stronie pakietu oraz pomocniki kontraktu pakietu pluginu                                                                         |
+| Kategoria                                               | Powierzchnia                                                                                                                                                             |
+| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `/codeql-critical-quality/core-auth-secrets`            | Kod granicy bezpieczeństwa uwierzytelniania, sekretów, sandboxa, cron i Gateway                                                                                         |
+| `/codeql-critical-quality/config-boundary`              | Kontrakty schematu konfiguracji, migracji, normalizacji i IO                                                                                                            |
+| `/codeql-critical-quality/gateway-runtime-boundary`     | Schematy protokołu Gateway i kontrakty metod serwera                                                                                                                    |
+| `/codeql-critical-quality/channel-runtime-boundary`     | Kontrakty implementacji kanału rdzenia i dołączonego Plugin kanału                                                                                                      |
+| `/codeql-critical-quality/agent-runtime-boundary`       | Wykonywanie poleceń, dyspozycja modelu/dostawcy, dyspozycja i kolejki automatycznych odpowiedzi oraz kontrakty środowiska uruchomieniowego płaszczyzny sterowania ACP    |
+| `/codeql-critical-quality/mcp-process-runtime-boundary` | Serwery MCP i mosty narzędzi, pomocniki nadzoru procesów oraz kontrakty dostarczania wychodzącego                                                                       |
+| `/codeql-critical-quality/memory-runtime-boundary`      | SDK hosta pamięci, fasady środowiska uruchomieniowego pamięci, aliasy pamięci Plugin SDK, klej aktywacji środowiska uruchomieniowego pamięci oraz polecenia doctor pamięci |
+| `/codeql-critical-quality/session-diagnostics-boundary` | Wewnętrzne elementy kolejki odpowiedzi, kolejki dostarczania sesji, pomocniki wiązania/dostarczania sesji wychodzących, powierzchnie zdarzeń diagnostycznych/pakietów logów oraz kontrakty CLI doctor sesji |
+| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Dyspozycja odpowiedzi przychodzących Plugin SDK, pomocniki ładunku/fragmentacji/środowiska uruchomieniowego odpowiedzi, opcje odpowiedzi kanałów, kolejki dostarczania oraz pomocniki wiązania sesji/wątków |
+| `/codeql-critical-quality/provider-runtime-boundary`    | Normalizacja katalogu modeli, uwierzytelnianie i wykrywanie dostawców, rejestracja środowiska uruchomieniowego dostawcy, ustawienia domyślne/katalogi dostawców oraz rejestry web/search/fetch/embedding |
+| `/codeql-critical-quality/ui-control-plane`             | Bootstrap UI sterowania, lokalna trwałość, przepływy sterowania Gateway oraz kontrakty środowiska uruchomieniowego płaszczyzny sterowania zadaniami                     |
+| `/codeql-critical-quality/web-media-runtime-boundary`   | Kontrakty środowiska uruchomieniowego rdzeniowego web fetch/search, IO mediów, rozumienia mediów, generowania obrazów oraz generowania mediów                           |
+| `/codeql-critical-quality/plugin-boundary`              | Kontrakty loadera, rejestru, powierzchni publicznej oraz punktów wejścia Plugin SDK                                                                                      |
+| `/codeql-critical-quality/plugin-sdk-package-contract`  | Opublikowane źródło Plugin SDK po stronie pakietu oraz pomocniki kontraktu pakietu Plugin                                                                                |

-Jakość pozostaje oddzielona od bezpieczeństwa, aby wyniki jakości można było planować, mierzyć, wyłączać lub rozszerzać bez zaciemniania sygnału bezpieczeństwa. Rozszerzenie CodeQL dla Swift, Pythona i dołączonych pluginów należy dodać z powrotem jako zakresowe lub shardowane prace następcze dopiero po uzyskaniu stabilnego czasu działania i sygnału przez wąskie profile.
+Jakość pozostaje oddzielona od bezpieczeństwa, aby ustalenia jakości można było planować, mierzyć, wyłączać lub rozszerzać bez zaciemniania sygnału bezpieczeństwa. Rozszerzenie CodeQL dla Swift, Python i dołączonych Plugin należy dodać ponownie jako zakresowane lub podzielone na fragmenty prace następcze dopiero po ustabilizowaniu czasu działania i sygnału wąskich profili.

-## Przepływy pracy utrzymaniowej
+## Przepływy pracy utrzymania

-### Agent dokumentacji
+### Docs Agent

-Przepływ pracy `Docs Agent` to sterowana zdarzeniami ścieżka utrzymaniowa Codex służąca do utrzymywania istniejącej dokumentacji w zgodzie z ostatnio wprowadzonymi zmianami. Nie ma czystego harmonogramu: może go wyzwolić udany przebieg CI po wypchnięciu na `main` przez konto inne niż bot, a ręczne wywołanie może uruchomić go bezpośrednio. Wywołania workflow-run są pomijane, gdy `main` przesunął się dalej albo gdy inny niepominięty przebieg Docs Agent został utworzony w ciągu ostatniej godziny. Gdy działa, przegląda zakres commitów od poprzedniego niepominiętego SHA źródłowego Docs Agent do bieżącego `main`, więc jeden godzinowy przebieg może objąć wszystkie zmiany na main zgromadzone od ostatniego przejścia dokumentacji.
+Przepływ pracy `Docs Agent` to sterowana zdarzeniami ścieżka utrzymaniowa Codex służąca do utrzymywania istniejącej dokumentacji w zgodzie z niedawno scalonymi zmianami. Nie ma czystego harmonogramu: może go wyzwolić udany przebieg CI po wypchnięciu przez niebota na `main`, a ręczne uruchomienie może uruchomić go bezpośrednio. Wywołania workflow-run są pomijane, gdy `main` posunął się dalej albo gdy w ostatniej godzinie utworzono inny niepominięty przebieg Docs Agent. Gdy działa, przegląda zakres commitów od poprzedniego niepominiętego źródłowego SHA Docs Agent do bieżącego `main`, więc jeden godzinowy przebieg może objąć wszystkie zmiany na main nagromadzone od ostatniego przebiegu dokumentacji.

-### Agent wydajności testów
+### Test Performance Agent

-Przepływ pracy `Test Performance Agent` to sterowana zdarzeniami ścieżka utrzymaniowa Codex dla wolnych testów. Nie ma czystego harmonogramu: może go wyzwolić udany przebieg CI po wypchnięciu na `main` przez konto inne niż bot, ale pomija się, jeśli inne wywołanie workflow-run już uruchomiło się lub działa tego dnia UTC. Ręczne wywołanie omija tę dzienną bramkę aktywności. Ścieżka buduje pogrupowany raport wydajności Vitest dla pełnego zestawu, pozwala Codex wprowadzać tylko małe poprawki wydajności testów zachowujące pokrycie zamiast szerokich refaktoryzacji, następnie ponownie uruchamia raport pełnego zestawu i odrzuca zmiany, które zmniejszają bazową liczbę przechodzących testów. Jeśli baza ma testy kończące się niepowodzeniem, Codex może naprawić tylko oczywiste awarie, a raport pełnego zestawu po agencie musi przejść, zanim cokolwiek zostanie commitowane. Gdy `main` przesunie się przed wypchnięciem przez bota, ścieżka rebase’uje zweryfikowaną poprawkę, ponownie uruchamia `pnpm check:changed` i ponawia push; konfliktujące przestarzałe poprawki są pomijane. Używa hostowanego przez GitHub Ubuntu, aby akcja Codex mogła zachować tę samą postawę bezpieczeństwa drop-sudo co agent dokumentacji.
+Przepływ pracy `Test Performance Agent` to sterowana zdarzeniami ścieżka utrzymaniowa Codex dla wolnych testów. Nie ma czystego harmonogramu: może go wyzwolić udany przebieg CI po wypchnięciu przez niebota na `main`, ale pomija się, jeśli inne wywołanie workflow-run już działało lub działa tego dnia UTC. Ręczne uruchomienie omija tę dzienną bramkę aktywności. Ścieżka buduje zgrupowany raport wydajności Vitest dla pełnego zestawu, pozwala Codex wprowadzać tylko małe, zachowujące pokrycie poprawki wydajności testów zamiast szerokich refaktoryzacji, następnie ponownie uruchamia raport pełnego zestawu i odrzuca zmiany zmniejszające bazową liczbę przechodzących testów. Jeśli baza ma nieprzechodzące testy, Codex może naprawić tylko oczywiste awarie, a raport pełnego zestawu po agencie musi przejść, zanim cokolwiek zostanie commitowane. Gdy `main` przesunie się, zanim push bota zostanie wprowadzony, ścieżka wykonuje rebase zweryfikowanej łatki, ponownie uruchamia `pnpm check:changed` i ponawia push; konfliktowe przestarzałe łatki są pomijane. Używa GitHub-hosted Ubuntu, aby akcja Codex mogła zachować tę samą postawę bezpieczeństwa drop-sudo co agent dokumentacji.

 ### Zduplikowane PR-y po scaleniu

-Przepływ pracy `Duplicate PRs After Merge` to ręczny przepływ pracy utrzymaniowej dla opiekunów, służący do porządkowania duplikatów po wylądowaniu zmian. Domyślnie działa w trybie dry-run i zamyka tylko jawnie wymienione PR-y, gdy `apply=true`. Przed mutacją GitHuba weryfikuje, że PR, który wylądował, został scalony oraz że każdy duplikat ma współdzielone powiązane zgłoszenie albo nakładające się zmienione hunki.
+Przepływ pracy `Duplicate PRs After Merge` to ręczny przepływ pracy maintainerów do porządkowania duplikatów po wylądowaniu zmian. Domyślnie działa jako dry-run i zamyka tylko jawnie wymienione PR-y, gdy `apply=true`. Przed zmodyfikowaniem GitHub weryfikuje, że PR, który wylądował, został scalony oraz że każdy duplikat ma albo wspólne przywołane zgłoszenie, albo nakładające się zmienione hunki.

 ```bash
 gh workflow run duplicate-after-merge.yml \
@ -473,29 +460,29 @@ gh workflow run duplicate-after-merge.yml \
  -f apply=true
 ```

-## Lokalne bramki kontroli i routing zmian
+## Lokalne bramki sprawdzania i routing zmian

-Lokalna logika changed-lane znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka kontroli jest bardziej rygorystyczna wobec granic architektury niż szeroki zakres platformy CI:
+Lokalna logika changed-lane znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka sprawdzania jest bardziej rygorystyczna wobec granic architektury niż szeroki zakres platformy CI:

- zmiany produkcyjne rdzenia uruchamiają typecheck produkcyjny rdzenia i testów rdzenia oraz lint/osłony rdzenia;
- zmiany wyłącznie w testach rdzenia uruchamiają tylko typecheck testów rdzenia oraz lint rdzenia;
+- zmiany produkcyjne rdzenia uruchamiają typecheck produkcyjny rdzenia i testów rdzenia oraz lint/ochrony rdzenia;
+- zmiany tylko w testach rdzenia uruchamiają tylko typecheck testów rdzenia oraz lint rdzenia;
 - zmiany produkcyjne rozszerzeń uruchamiają typecheck produkcyjny rozszerzeń i testów rozszerzeń oraz lint rozszerzeń;
- zmiany wyłącznie w testach rozszerzeń uruchamiają typecheck testów rozszerzeń oraz lint rozszerzeń;
- zmiany publicznego Plugin SDK lub kontraktu pluginu rozszerzają się do typecheck rozszerzeń, ponieważ rozszerzenia zależą od tych kontraktów rdzenia (przeglądy rozszerzeń Vitest pozostają jawną pracą testową);
- zmiany wersji wyłącznie w metadanych wydania uruchamiają ukierunkowane kontrole wersji/konfiguracji/zależności root;
- nieznane zmiany root/konfiguracji w trybie bezpiecznym uruchamiają wszystkie ścieżki kontroli.
+- zmiany tylko w testach rozszerzeń uruchamiają typecheck testów rozszerzeń oraz lint rozszerzeń;
+- zmiany publicznego Plugin SDK lub kontraktu Plugin rozszerzają się na typecheck rozszerzeń, ponieważ rozszerzenia zależą od tych kontraktów rdzenia (przeglądy rozszerzeń Vitest pozostają jawną pracą testową);
+- zmiany wyłącznie metadanych wydania przy podbiciach wersji uruchamiają ukierunkowane kontrole wersji/konfiguracji/zależności root;
+- nieznane zmiany root/konfiguracji bezpiecznie przechodzą na wszystkie ścieżki sprawdzania.

-Lokalny routing changed-test znajduje się w `scripts/test-projects.test-support.mjs` i jest celowo tańszy niż `check:changed`: bezpośrednie edycje testów uruchamiają same siebie, edycje źródeł preferują jawne mapowania, a następnie testy siostrzane i zależne w grafie importów. Współdzielona konfiguracja dostarczania do grupy jest jednym z jawnych mapowań: zmiany konfiguracji widocznych odpowiedzi grupowych, trybu dostarczania odpowiedzi źródłowych albo promptu systemowego narzędzia wiadomości przechodzą przez testy odpowiedzi rdzenia oraz regresje dostarczania Discord i Slack, aby zmiana współdzielonej wartości domyślnej zakończyła się niepowodzeniem przed pierwszym pushem PR. Używaj `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` tylko wtedy, gdy zmiana obejmuje na tyle szeroko harness, że tani zmapowany zestaw nie jest wiarygodnym przybliżeniem.
+Lokalny routing changed-test znajduje się w `scripts/test-projects.test-support.mjs` i jest celowo tańszy niż `check:changed`: bezpośrednie edycje testów uruchamiają same siebie, edycje źródeł preferują jawne mapowania, następnie testy sąsiednie i zależne z grafu importów. Współdzielona konfiguracja dostarczania group-room jest jednym z jawnych mapowań: zmiany w konfiguracji odpowiedzi widocznej dla grupy, trybie dostarczania odpowiedzi źródłowej lub prompcie systemowym narzędzia wiadomości przechodzą przez testy odpowiedzi rdzenia oraz regresje dostarczania Discord i Slack, aby zmiana współdzielonej wartości domyślnej zawiodła przed pierwszym wypchnięciem PR. Używaj `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` tylko wtedy, gdy zmiana jest na tyle szeroka w całym harnessie, że tani zmapowany zestaw nie jest wiarygodnym przybliżeniem.

 ## Walidacja Testbox

-Uruchamiaj Testbox z katalogu głównego repozytorium i przy szerokiej weryfikacji preferuj świeżo przygotowaną maszynę. Zanim poświęcisz czas na powolną bramkę na maszynie, która była użyta ponownie, wygasła albo właśnie zgłosiła nieoczekiwanie dużą synchronizację, najpierw uruchom `pnpm testbox:sanity` wewnątrz tej maszyny.
+Uruchamiaj Testbox z katalogu głównego repozytorium i preferuj świeżo przygotowaną maszynę do szerokiej weryfikacji. Zanim poświęcisz wolną bramkę na maszynę, która była użyta ponownie, wygasła albo właśnie zgłosiła nieoczekiwanie dużą synchronizację, uruchom najpierw `pnpm testbox:sanity` wewnątrz tej maszyny.

-Kontrola sanity szybko kończy się błędem, gdy wymagane pliki główne, takie jak `pnpm-lock.yaml`, zniknęły albo gdy `git status --short` pokazuje co najmniej 200 śledzonych usunięć. Zazwyczaj oznacza to, że zdalny stan synchronizacji nie jest wiarygodną kopią PR-a; zatrzymaj tę maszynę i przygotuj świeżą zamiast debugować błąd testu produktu. W przypadku celowych PR-ów z dużą liczbą usunięć ustaw `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` dla tego uruchomienia sanity.
+Kontrola poprawności szybko kończy się niepowodzeniem, gdy wymagane pliki główne, takie jak `pnpm-lock.yaml`, zniknęły albo gdy `git status --short` pokazuje co najmniej 200 usunięć śledzonych plików. Zwykle oznacza to, że zdalny stan synchronizacji nie jest godną zaufania kopią PR-a; zatrzymaj tę maszynę i przygotuj świeżą zamiast debugować niepowodzenie testu produktu. W przypadku PR-ów z celowo dużą liczbą usunięć ustaw `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` dla tego uruchomienia kontroli poprawności.

-`pnpm testbox:run` kończy także lokalne wywołanie Blacksmith CLI, które pozostaje w fazie synchronizacji przez ponad pięć minut bez danych wyjściowych po synchronizacji. Ustaw `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, aby wyłączyć tę osłonę, albo użyj większej wartości w milisekundach dla nietypowo dużych lokalnych różnic.
+`pnpm testbox:run` kończy również lokalne wywołanie Blacksmith CLI, które pozostaje w fazie synchronizacji przez ponad pięć minut bez wyjścia po synchronizacji. Ustaw `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, aby wyłączyć tę ochronę, albo użyj większej wartości w milisekundach dla wyjątkowo dużych lokalnych różnic.

-Crabbox to należąca do repozytorium druga ścieżka zdalnej maszyny dla weryfikacji na Linuksie, gdy Blacksmith jest niedostępny albo gdy preferowana jest własna pojemność chmurowa. Przygotuj maszynę, zhydrate'uj ją przez workflow projektu, a następnie uruchamiaj polecenia przez Crabbox CLI:
+Crabbox to druga, należąca do repozytorium ścieżka zdalnej maszyny do weryfikacji w Linuxie, gdy Blacksmith jest niedostępny albo gdy preferowana jest własna pojemność w chmurze. Przygotuj maszynę, nawodnij ją przez przepływ pracy projektu, a następnie uruchamiaj polecenia przez Crabbox CLI:

 ```bash
 pnpm crabbox:warmup -- --idle-timeout 90m
@ -504,9 +491,9 @@ pnpm crabbox:run -- --id <cbx_id> --shell "OPENCLAW_TESTBOX=1 pnpm check:changed
 pnpm crabbox:stop -- <cbx_id>
 ```

-`.crabbox.yaml` definiuje domyślne ustawienia dostawcy, synchronizacji i hydratacji GitHub Actions. Wyklucza lokalne `.git`, aby zhydrate'owany checkout Actions zachował własne zdalne metadane Git zamiast synchronizować lokalne remotes i magazyny obiektów maintainera, oraz wyklucza lokalne artefakty uruchomieniowe/buildowe, których nigdy nie należy przesyłać. `.github/workflows/crabbox-hydrate.yml` definiuje checkout, konfigurację Node/pnpm, pobranie `origin/main` oraz przekazanie niepoufnego środowiska, które późniejsze polecenia `crabbox run --id <cbx_id>` wczytują.
+`.crabbox.yaml` określa domyślne ustawienia dostawcy, synchronizacji i nawadniania GitHub Actions. Wyklucza lokalne `.git`, aby nawodniony checkout Actions zachował własne zdalne metadane Git zamiast synchronizować lokalne zdalne repozytoria i magazyny obiektów opiekuna, oraz wyklucza lokalne artefakty uruchomieniowe/budowania, których nigdy nie należy przesyłać. `.github/workflows/crabbox-hydrate.yml` określa checkout, konfigurację Node/pnpm, pobranie `origin/main` oraz przekazanie niepoufnego środowiska, z którego późniejsze polecenia `crabbox run --id <cbx_id>` korzystają jako źródła.

 ## Powiązane

- [Omówienie instalacji](/pl/install)
- [Kanały deweloperskie](/pl/install/development-channels)
+- [Przegląd instalacji](/pl/install)
+- [Kanały rozwojowe](/pl/install/development-channels)
--- a/docs/pl/concepts/system-prompt.md
+++ b/docs/pl/concepts/system-prompt.md
@ -1,14 +1,14 @@
 ---
 read_when:
    - Edytowanie tekstu promptu systemowego, listy narzędzi lub sekcji czasu/Heartbeat
-    - Zmiana zachowania inicjalizacji obszaru roboczego lub wstrzykiwania Skills
+    - Zmiana zachowania inicjalizacji przestrzeni roboczej lub wstrzykiwania Skills
 summary: Co zawiera prompt systemowy OpenClaw i jak jest składany
 title: Prompt systemowy
 x-i18n:
-    generated_at: "2026-05-02T22:18:17Z"
+    generated_at: "2026-05-02T23:39:23Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 3b8761a8722bb328b937e0832774be7b4e99602ae032c9a255f26843237c110c
+    source_hash: f8e0234453812c16cf5d273096d335049bf435ca76ade36200caf4bb344624e5
    source_path: concepts/system-prompt.md
    workflow: 16
 ---
@ -17,137 +17,138 @@ OpenClaw buduje niestandardowy prompt systemowy dla każdego uruchomienia agenta

 Prompt jest składany przez OpenClaw i wstrzykiwany do każdego uruchomienia agenta.

-Pluginy dostawców mogą dokładać świadome pamięci podręcznej wskazówki promptu bez zastępowania
-pełnego promptu należącego do OpenClaw. Środowisko wykonawcze dostawcy może:
+Pluginy dostawców mogą wnosić wskazówki promptu świadome cache, bez zastępowania
+pełnego promptu będącego własnością OpenClaw. Runtime dostawcy może:

 - zastąpić mały zestaw nazwanych sekcji rdzeniowych (`interaction_style`,
  `tool_call_style`, `execution_bias`)
- wstrzyknąć **stabilny prefiks** powyżej granicy pamięci podręcznej promptu
- wstrzyknąć **dynamiczny sufiks** poniżej granicy pamięci podręcznej promptu
+- wstrzyknąć **stabilny prefiks** powyżej granicy cache promptu
+- wstrzyknąć **dynamiczny sufiks** poniżej granicy cache promptu

-Używaj wkładów należących do dostawcy do strojenia specyficznego dla rodzin modeli. Zachowaj starszą
-mutację promptu `before_prompt_build` dla kompatybilności lub rzeczywiście globalnych zmian promptu,
-a nie dla normalnego zachowania dostawcy.
+Używaj wkładów należących do dostawcy do dostrajania specyficznego dla rodziny modeli. Zachowaj starszą
+mutację promptu `before_prompt_build` dla zgodności lub naprawdę globalnych zmian
+promptu, a nie dla normalnego zachowania dostawcy.

-Nakładka rodziny OpenAI GPT-5 utrzymuje podstawową regułę wykonywania jako małą i dodaje
-wskazówki specyficzne dla modelu dotyczące utrwalania persony, zwięzłego wyniku, dyscypliny narzędzi,
-równoległego wyszukiwania, pokrycia dostarczalnych elementów, weryfikacji, brakującego kontekstu oraz
+Nakładka rodziny OpenAI GPT-5 utrzymuje główną regułę wykonywania jako małą i dodaje
+wskazówki specyficzne dla modelu dotyczące utrwalania persony, zwięzłych wyników, dyscypliny narzędzi,
+równoległego wyszukiwania, kompletności artefaktów, weryfikacji, brakującego kontekstu oraz
 higieny narzędzi terminalowych.

 ## Struktura

-Prompt jest celowo zwięzły i używa stałych sekcji:
+Prompt jest celowo kompaktowy i używa stałych sekcji:

- **Narzędzia**: przypomnienie o źródle prawdy dla narzędzi strukturalnych oraz wskazówki użycia narzędzi w czasie wykonywania.
- **Nastawienie wykonawcze**: zwięzłe wskazówki dotyczące doprowadzania pracy do końca: działaj w ramach tury na
-  wykonalne prośby, kontynuuj aż do ukończenia lub zablokowania, odzyskuj po słabych wynikach narzędzi,
-  sprawdzaj zmienny stan na żywo i weryfikuj przed finalizacją.
- **Bezpieczeństwo**: krótkie przypomnienie ograniczeń, aby unikać zachowań dążących do władzy lub omijania nadzoru.
+- **Narzędzia**: przypomnienie o źródle prawdy dla narzędzi strukturalnych oraz wskazówki runtime dotyczące użycia narzędzi.
+- **Nastawienie wykonawcze**: zwięzłe wskazówki dotyczące doprowadzania pracy do końca: działaj w obrębie tury na
+  wykonalne prośby, kontynuuj do ukończenia lub zablokowania, odzyskuj po słabych
+  wynikach narzędzi, sprawdzaj zmienny stan na żywo i weryfikuj przed finalizacją.
+- **Bezpieczeństwo**: krótkie przypomnienie o barierach ochronnych, aby unikać zachowań dążących do przejęcia kontroli lub omijania nadzoru.
 - **Skills** (gdy dostępne): mówi modelowi, jak ładować instrukcje Skills na żądanie.
- **Samoaktualizacja OpenClaw**: jak bezpiecznie sprawdzać konfigurację za pomocą
-  `config.schema.lookup`, łatać konfigurację za pomocą `config.patch`, zastępować pełną
-  konfigurację za pomocą `config.apply` oraz uruchamiać `update.run` tylko na wyraźną prośbę użytkownika.
-  Narzędzie `gateway`, dostępne tylko dla właściciela, także odmawia przepisywania
+- **Samodzielna aktualizacja OpenClaw**: jak bezpiecznie sprawdzać konfigurację za pomocą
+  `config.schema.lookup`, poprawiać konfigurację przez `config.patch`, zastępować pełną
+  konfigurację przez `config.apply` oraz uruchamiać `update.run` tylko na wyraźną prośbę
+  użytkownika. Narzędzie tylko dla właściciela `gateway` odmawia również przepisywania
  `tools.exec.ask` / `tools.exec.security`, w tym starszych aliasów `tools.bash.*`,
  które normalizują się do tych chronionych ścieżek exec.
- **Przestrzeń robocza**: katalog roboczy (`agents.defaults.workspace`).
+- **Obszar roboczy**: katalog roboczy (`agents.defaults.workspace`).
 - **Dokumentacja**: lokalna ścieżka do dokumentacji OpenClaw (repozytorium lub pakiet npm) i kiedy ją czytać.
- **Pliki przestrzeni roboczej (wstrzyknięte)**: wskazuje, że pliki startowe są dołączone poniżej.
- **Sandbox** (gdy włączony): wskazuje środowisko wykonawcze w piaskownicy, ścieżki sandboxa oraz czy dostępny jest podwyższony exec.
- **Bieżąca data i czas**: czas lokalny użytkownika, strefa czasowa i format czasu.
+- **Pliki obszaru roboczego (wstrzyknięte)**: wskazuje, że pliki bootstrapowe są dołączone poniżej.
+- **Sandbox** (gdy włączony): wskazuje sandboxowany runtime, ścieżki sandboxa oraz to, czy dostępny jest podniesiony exec.
+- **Bieżąca data i godzina**: lokalny czas użytkownika, strefa czasowa i format czasu.
 - **Tagi odpowiedzi**: opcjonalna składnia tagów odpowiedzi dla obsługiwanych dostawców.
- **Heartbeats**: prompt Heartbeat i zachowanie potwierdzenia, gdy Heartbeaty są włączone dla domyślnego agenta.
- **Środowisko wykonawcze**: host, system operacyjny, node, model, korzeń repozytorium (gdy wykryty), poziom myślenia (jedna linia).
+- **Heartbeats**: prompt Heartbeat i zachowanie potwierdzenia, gdy Heartbeat jest włączony dla domyślnego agenta.
+- **Runtime**: host, system operacyjny, node, model, katalog główny repozytorium (gdy wykryty), poziom myślenia (jedna linia).
 - **Rozumowanie**: bieżący poziom widoczności + wskazówka przełącznika /reasoning.

 OpenClaw utrzymuje dużą stabilną zawartość, w tym **Kontekst projektu**, powyżej
-wewnętrznej granicy pamięci podręcznej promptu. Zmienne sekcje kanału/sesji, takie jak
+wewnętrznej granicy cache promptu. Zmienne sekcje kanału/sesji, takie jak
 wskazówki osadzenia Control UI, **Wiadomości**, **Głos**, **Kontekst czatu grupowego**,
-**Reakcje**, **Heartbeats** i **Środowisko wykonawcze**, są dopisywane poniżej tej granicy,
-aby lokalne backendy z pamięciami podręcznymi prefiksów mogły ponownie używać stabilnego prefiksu przestrzeni roboczej
-między turami kanału. Opisy narzędzi podobnie powinny unikać osadzania bieżących
-nazw kanałów, gdy akceptowany schemat już przenosi ten szczegół środowiska wykonawczego.
+**Reakcje**, **Heartbeats** i **Runtime**, są dodawane poniżej tej granicy,
+aby lokalne backendy z cache prefiksów mogły ponownie używać stabilnego prefiksu obszaru roboczego
+między turami kanału. Opisy narzędzi powinny podobnie unikać osadzania bieżących
+nazw kanałów, gdy akceptowany schemat już przenosi ten szczegół runtime.

-Sekcja Narzędzia zawiera także wskazówki środowiska wykonawczego dla długotrwałej pracy:
+Sekcja Narzędzia zawiera również wskazówki runtime dla długotrwałej pracy:

 - używaj cron do przyszłych działań następczych (`check back later`, przypomnienia, praca cykliczna)
-  zamiast pętli uśpienia `exec`, sztuczek opóźnień `yieldMs` lub powtarzanego odpytywania `process`
- używaj `exec` / `process` tylko dla poleceń, które startują teraz i dalej działają
+  zamiast pętli uśpienia `exec`, sztuczek z opóźnieniem `yieldMs` lub powtarzanego
+  odpytywania `process`
+- używaj `exec` / `process` tylko do poleceń, które zaczynają się teraz i nadal działają
  w tle
- gdy automatyczne wybudzenie po ukończeniu jest włączone, uruchom polecenie raz i polegaj na
-  ścieżce wybudzenia push, gdy emituje wyjście lub kończy się błędem
+- gdy automatyczne wybudzanie po zakończeniu jest włączone, uruchom polecenie raz i polegaj na
+  ścieżce wybudzania opartej na push, gdy wyemituje wyjście lub zakończy się błędem
 - używaj `process` do logów, statusu, wejścia lub interwencji, gdy trzeba
  sprawdzić działające polecenie
- jeśli zadanie jest większe, preferuj `sessions_spawn`; ukończenie podagenta jest
-  push-based i automatycznie ogłasza się z powrotem requesterowi
+- jeśli zadanie jest większe, preferuj `sessions_spawn`; zakończenie subagenta jest
+  oparte na push i automatycznie ogłasza się z powrotem proszącemu
 - nie odpytuj `subagents list` / `sessions_list` w pętli tylko po to, aby czekać na
-  ukończenie
+  zakończenie

-Gdy eksperymentalne narzędzie `update_plan` jest włączone, Narzędzia mówią także
+Gdy eksperymentalne narzędzie `update_plan` jest włączone, Narzędzia mówią też
 modelowi, aby używał go tylko do nietrywialnej pracy wieloetapowej, utrzymywał dokładnie jeden
 krok `in_progress` i unikał powtarzania całego planu po każdej aktualizacji.

-Ograniczenia bezpieczeństwa w prompcie systemowym są doradcze. Kierują zachowaniem modelu, ale nie egzekwują zasad. Do twardego egzekwowania używaj zasad narzędzi, zatwierdzeń exec, sandboxingu i allowlist kanałów; operatorzy mogą je celowo wyłączyć.
+Bariery ochronne bezpieczeństwa w prompcie systemowym mają charakter doradczy. Kierują zachowaniem modelu, ale nie egzekwują zasad. Do twardego egzekwowania używaj polityki narzędzi, zatwierdzeń exec, sandboxingu i list dozwolonych kanałów; operatorzy mogą je z założenia wyłączyć.

-Na kanałach z natywnymi kartami/przyciskami zatwierdzania prompt środowiska wykonawczego mówi teraz
-agentowi, aby najpierw polegał na tym natywnym interfejsie zatwierdzania. Ręczne polecenie
-`/approve` powinien dołączać tylko wtedy, gdy wynik narzędzia mówi, że zatwierdzenia czatu są niedostępne albo
+Na kanałach z natywnymi kartami/przyciskami zatwierdzania prompt runtime mówi teraz
+agentowi, aby najpierw polegał na tym natywnym UI zatwierdzania. Powinien dołączać ręczne
+polecenie `/approve` tylko wtedy, gdy wynik narzędzia mówi, że zatwierdzenia czatu są niedostępne lub
 ręczne zatwierdzenie jest jedyną ścieżką.

 ## Tryby promptu

-OpenClaw może renderować mniejsze prompty systemowe dla podagentów. Środowisko wykonawcze ustawia
+OpenClaw może renderować mniejsze prompty systemowe dla subagentów. Runtime ustawia
 `promptMode` dla każdego uruchomienia (nie jest to konfiguracja widoczna dla użytkownika):

- `full` (domyślnie): zawiera wszystkie powyższe sekcje.
- `minimal`: używany dla podagentów; pomija **Skills**, **Przywołanie pamięci**, **Samoaktualizacja OpenClaw**,
-  **Aliasy modeli**, **Tożsamość użytkownika**, **Tagi odpowiedzi**,
+- `full` (domyślny): zawiera wszystkie sekcje powyżej.
+- `minimal`: używany dla subagentów; pomija **Skills**, **Przywołanie pamięci**, **Samodzielna aktualizacja OpenClaw
+  **, **Aliasy modeli**, **Tożsamość użytkownika**, **Tagi odpowiedzi**,
  **Wiadomości**, **Ciche odpowiedzi** i **Heartbeats**. Narzędzia, **Bezpieczeństwo**,
-  Przestrzeń robocza, Sandbox, Bieżąca data i czas (gdy znane), Środowisko wykonawcze oraz wstrzyknięty
+  Obszar roboczy, Sandbox, Bieżąca data i godzina (gdy znana), Runtime oraz wstrzyknięty
  kontekst pozostają dostępne.
- `none`: zwraca tylko podstawową linię tożsamości.
+- `none`: zwraca tylko bazową linię tożsamości.

-Gdy `promptMode=minimal`, dodatkowe wstrzyknięte prompty są oznaczane jako **Kontekst podagenta**
-zamiast **Kontekst czatu grupowego**.
+Gdy `promptMode=minimal`, dodatkowe wstrzyknięte prompty są oznaczane jako **Kontekst subagenta
+** zamiast **Kontekst czatu grupowego**.

 Dla uruchomień automatycznej odpowiedzi kanału OpenClaw może pominąć ogólną sekcję **Ciche odpowiedzi**,
-gdy kontekst czatu bezpośredniego/grupowego już zawiera rozstrzygnięte
-zachowanie `NO_REPLY` specyficzne dla rozmowy. Pozwala to uniknąć powtarzania mechaniki tokenów
-zarówno w globalnym prompcie systemowym, jak i kontekście kanału.
+gdy kontekst czatu bezpośredniego/grupowego już zawiera rozwiązane
+zachowanie `NO_REPLY` specyficzne dla konwersacji. Pozwala to uniknąć powtarzania mechaniki tokenów
+zarówno w globalnym prompcie systemowym, jak i w kontekście kanału.

-## Migawki promptów
+## Migawki promptu

-OpenClaw przechowuje zatwierdzone migawki promptów szczęśliwej ścieżki dla środowiska wykonawczego Codex/narzędzia wiadomości
-w `test/fixtures/agents/prompt-snapshots/happy-path/`. Renderują one
-wybrane parametry wątku/tury app-server oraz zrekonstruowany stos warstw promptu powiązany z modelem
+OpenClaw utrzymuje zatwierdzone migawki promptu dla szczęśliwej ścieżki runtime Codex pod
+`test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/`. Renderują one
+wybrane parametry wątku/tury app-server oraz zrekonstruowany stos warstw promptu związany z modelem
 dla tur bezpośrednich Telegram, grupowych Discord i Heartbeat. Ten stos
-obejmuje przypiętą fixturę promptu modelu Codex `gpt-5.5` wygenerowaną z kształtu
-katalogu/pamięci podręcznej modeli Codex, tekst developerski uprawnień szczęśliwej ścieżki Codex,
-instrukcje developerskie OpenClaw, wejście tury użytkownika oraz odwołania do dynamicznych
+obejmuje przypiętą fiksturę promptu modelu Codex `gpt-5.5` wygenerowaną z kształtu
+katalogu/cache modeli Codex, tekst developera uprawnień szczęśliwej ścieżki Codex,
+instrukcje developerskie OpenClaw, wejście tury użytkownika oraz odniesienia do dynamicznych
 specyfikacji narzędzi.

-Odśwież przypiętą fixturę promptu modelu Codex za pomocą
+Odśwież przypiętą fiksturę promptu modelu Codex za pomocą
 `pnpm prompt:snapshots:sync-codex-model`. Domyślnie skrypt szuka
-pamięci podręcznej środowiska wykonawczego Codex w `$CODEX_HOME/models_cache.json`, następnie
-`~/.codex/models_cache.json`, a dopiero potem przechodzi do konwencji checkoutu Codex maintainera
-w `~/code/codex/codex-rs/models-manager/models.json`. Jeśli
+cache runtime Codex w `$CODEX_HOME/models_cache.json`, potem
+`~/.codex/models_cache.json`, a dopiero potem wraca do konwencji checkoutu Codex
+maintainera w `~/code/codex/codex-rs/models-manager/models.json`. Jeśli
 żadne z tych źródeł nie istnieje, polecenie kończy działanie bez zmiany zatwierdzonej
-fixtury. Przekaż `--catalog <path>`, aby odświeżyć z konkretnego pliku `models_cache.json`
+fikstury. Przekaż `--catalog <path>`, aby odświeżyć z określonego pliku `models_cache.json`
 lub `models.json`.

-Te migawki nadal nie są surowym przechwyceniem żądania OpenAI bajt po bajcie. Codex
-może dodać kontekst przestrzeni roboczej należący do środowiska wykonawczego, taki jak `AGENTS.md`, kontekst
-środowiska, pamięci, instrukcje aplikacji/pluginów oraz przyszłe instrukcje trybu współpracy
-wewnątrz środowiska wykonawczego Codex po tym, jak OpenClaw wyśle parametry wątku i tury.
+Te migawki nadal nie są surowym przechwyceniem żądania OpenAI bajt w bajt. Codex
+może dodać kontekst obszaru roboczego należący do runtime, taki jak `AGENTS.md`, kontekst
+środowiska, pamięci, instrukcje aplikacji/pluginów oraz przyszłe instrukcje trybu
+współpracy wewnątrz runtime Codex po wysłaniu przez OpenClaw parametrów wątku i tury.

-Regeneruj je za pomocą `pnpm prompt:snapshots:gen` i weryfikuj dryf za pomocą
-`pnpm prompt:snapshots:check`. CI uruchamia sprawdzenie dryfu w dodatkowym
+Wygeneruj je ponownie za pomocą `pnpm prompt:snapshots:gen` i zweryfikuj dryf przez
+`pnpm prompt:snapshots:check`. CI uruchamia kontrolę dryfu w dodatkowym
 shardzie granicznym, aby zmiany promptu i aktualizacje migawek pozostawały dołączone do tego samego
 PR.

-## Wstrzykiwanie startowe przestrzeni roboczej
+## Wstrzykiwanie bootstrapu obszaru roboczego

-Pliki startowe są przycinane i dopisywane pod **Kontekstem projektu**, aby model widział kontekst tożsamości i profilu bez potrzeby jawnego odczytu:
+Pliki bootstrapowe są przycinane i dodawane pod **Kontekstem projektu**, aby model widział kontekst tożsamości i profilu bez potrzeby jawnych odczytów:

 - `AGENTS.md`
 - `SOUL.md`
@ -155,69 +156,76 @@ Pliki startowe są przycinane i dopisywane pod **Kontekstem projektu**, aby mode
 - `IDENTITY.md`
 - `USER.md`
 - `HEARTBEAT.md`
- `BOOTSTRAP.md` (tylko w zupełnie nowych przestrzeniach roboczych)
- `MEMORY.md` gdy obecny
+- `BOOTSTRAP.md` (tylko w zupełnie nowych obszarach roboczych)
+- `MEMORY.md`, gdy istnieje

 Wszystkie te pliki są **wstrzykiwane do okna kontekstu** w każdej turze, chyba że
 ma zastosowanie bramka specyficzna dla pliku. `HEARTBEAT.md` jest pomijany w normalnych uruchomieniach, gdy
-Heartbeaty są wyłączone dla domyślnego agenta albo
+Heartbeats są wyłączone dla domyślnego agenta lub
 `agents.defaults.heartbeat.includeSystemPromptSection` ma wartość false. Utrzymuj wstrzykiwane
-pliki zwięzłe — szczególnie `MEMORY.md`, który może rosnąć z czasem i prowadzić do
-nieoczekiwanie wysokiego użycia kontekstu oraz częstszej Compaction.
+pliki zwięzłe — zwłaszcza `MEMORY.md`, który może z czasem rosnąć i prowadzić do
+nieoczekiwanie wysokiego zużycia kontekstu oraz częstszej Compaction.
+
+Gdy sesja działa na natywnym harnessie Codex, Codex ładuje `AGENTS.md`
+przez własne wykrywanie dokumentów projektu. OpenClaw nadal rozwiązuje pozostałe
+pliki bootstrapowe i przekazuje je jako instrukcje konfiguracji Codex, więc `SOUL.md`,
+`TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, `BOOTSTRAP.md` i
+`MEMORY.md` zachowują tę samą rolę kontekstu obszaru roboczego bez duplikowania
+`AGENTS.md`.

 <Note>
-Pliki dzienne `memory/*.md` **nie** są częścią normalnego startowego Kontekstu projektu. W zwykłych turach są dostępne na żądanie przez narzędzia `memory_search` i `memory_get`, więc nie liczą się do okna kontekstu, chyba że model jawnie je odczyta. Wyjątkiem są puste tury `/new` i `/reset`: środowisko wykonawcze może poprzedzić pierwszą turę najnowszą pamięcią dzienną jako jednorazowym blokiem kontekstu startowego.
+Dzienne pliki `memory/*.md` **nie** są częścią normalnego bootstrapowego Kontekstu projektu. W zwykłych turach są dostępne na żądanie przez narzędzia `memory_search` i `memory_get`, więc nie obciążają okna kontekstu, chyba że model jawnie je odczyta. Gołe tury `/new` i `/reset` są wyjątkiem: runtime może poprzedzić ostatnią dzienną pamięć jednorazowym blokiem kontekstu startowego dla tej pierwszej tury.
 </Note>

-Duże pliki są obcinane z markerem. Maksymalny rozmiar na plik jest kontrolowany przez
-`agents.defaults.bootstrapMaxChars` (domyślnie: 12000). Łączna wstrzyknięta zawartość startowa
+Duże pliki są obcinane ze znacznikiem. Maksymalny rozmiar na plik jest kontrolowany przez
+`agents.defaults.bootstrapMaxChars` (domyślnie: 12000). Łączna wstrzyknięta zawartość bootstrapowa
 we wszystkich plikach jest ograniczona przez `agents.defaults.bootstrapTotalMaxChars`
-(domyślnie: 60000). Brakujące pliki wstrzykują krótki marker brakującego pliku. Gdy dochodzi do obcięcia,
-OpenClaw może wstrzyknąć blok ostrzeżenia w Kontekście projektu; kontroluj to za pomocą
+(domyślnie: 60000). Brakujące pliki wstrzykują krótki znacznik brakującego pliku. Gdy dochodzi do obcięcia,
+OpenClaw może wstrzyknąć blok ostrzeżenia w Kontekście projektu; kontroluj to przez
 `agents.defaults.bootstrapPromptTruncationWarning` (`off`, `once`, `always`;
 domyślnie: `once`).

-Sesje podagentów wstrzykują tylko `AGENTS.md` i `TOOLS.md` (inne pliki startowe
-są odfiltrowywane, aby utrzymać mały kontekst podagenta).
+Sesje subagentów wstrzykują tylko `AGENTS.md` i `TOOLS.md` (inne pliki bootstrapowe
+są odfiltrowywane, aby utrzymać mały kontekst subagenta).

-Wewnętrzne hooki mogą przechwycić ten krok przez `agent:bootstrap`, aby mutować lub zastąpić
-wstrzyknięte pliki startowe (na przykład zamieniając `SOUL.md` na alternatywną personę).
+Wewnętrzne hooki mogą przechwycić ten krok przez `agent:bootstrap`, aby zmienić lub zastąpić
+wstrzyknięte pliki bootstrapowe (na przykład zamienić `SOUL.md` na alternatywną personę).

 Jeśli chcesz, aby agent brzmiał mniej generycznie, zacznij od
 [Przewodnika po osobowości SOUL.md](/pl/concepts/soul).

-Aby sprawdzić, ile wnosi każdy wstrzyknięty plik (surowo vs wstrzyknięte, obcięcie oraz narzut schematu narzędzi), użyj `/context list` lub `/context detail`. Zobacz [Kontekst](/pl/concepts/context).
+Aby sprawdzić, ile wnosi każdy wstrzyknięty plik (surowy vs wstrzyknięty, obcięcie oraz narzut schematu narzędzi), użyj `/context list` lub `/context detail`. Zobacz [Kontekst](/pl/concepts/context).

 ## Obsługa czasu

-Prompt systemowy zawiera dedykowaną sekcję **Bieżąca data i czas**, gdy
-strefa czasowa użytkownika jest znana. Aby utrzymać stabilność pamięci podręcznej promptu, zawiera teraz tylko
+Prompt systemowy zawiera dedykowaną sekcję **Bieżąca data i godzina**, gdy
+strefa czasowa użytkownika jest znana. Aby utrzymać stabilność cache promptu, zawiera teraz tylko
 **strefę czasową** (bez dynamicznego zegara ani formatu czasu).

-Używaj `session_status`, gdy agent potrzebuje bieżącego czasu; karta statusu
-zawiera linię znacznika czasu. To samo narzędzie może opcjonalnie ustawić nadpisanie modelu dla sesji
-(`model=default` czyści je).
+Użyj `session_status`, gdy agent potrzebuje bieżącego czasu; karta statusu
+zawiera linię znacznika czasu. To samo narzędzie może opcjonalnie ustawić model dla sesji
+override (`model=default` go czyści).

 Skonfiguruj za pomocą:

 - `agents.defaults.userTimezone`
 - `agents.defaults.timeFormat` (`auto` | `12` | `24`)

-Pełne szczegóły zachowania znajdziesz w [Data i czas](/pl/date-time).
+Zobacz [Data i godzina](/pl/date-time), aby poznać pełne szczegóły zachowania.

 ## Skills

 Gdy istnieją kwalifikujące się Skills, OpenClaw wstrzykuje zwięzłą **listę dostępnych Skills**
-(`formatSkillsForPrompt`), która obejmuje **ścieżkę pliku** dla każdej Skill. Prompt
-instruuje model, aby użył `read` do załadowania SKILL.md w podanej
-lokalizacji (przestrzeń robocza, zarządzana lub dołączona). Jeśli żadne Skills się nie kwalifikują, sekcja
-Skills jest pomijana.
+(`formatSkillsForPrompt`), która obejmuje **ścieżkę pliku** dla każdego Skill. Prompt
+instruuje model, aby użył `read` do załadowania SKILL.md we wskazanej
+lokalizacji (obszar roboczy, zarządzana lub wbudowana). Jeśli żadne Skills się nie kwalifikują,
+sekcja Skills jest pomijana.

-Kwalifikowalność obejmuje bramki metadanych Skills, sprawdzenia środowiska/konfiguracji w czasie wykonywania
-oraz efektywną allowlist Skills agenta, gdy skonfigurowano `agents.defaults.skills` lub
+Kwalifikowalność obejmuje bramki metadanych Skill, sprawdzenia środowiska/konfiguracji runtime
+oraz efektywną listę dozwolonych Skills agenta, gdy skonfigurowane jest `agents.defaults.skills` lub
 `agents.list[].skills`.

-Skills dołączone do Pluginu kwalifikują się tylko wtedy, gdy ich właścicielski Plugin jest włączony.
+Skills dołączone do Pluginów kwalifikują się tylko wtedy, gdy ich właścicielski Plugin jest włączony.
 Pozwala to Pluginom narzędzi udostępniać głębsze przewodniki operacyjne bez osadzania wszystkich
 tych wskazówek bezpośrednio w każdym opisie narzędzia.

@ -231,26 +239,25 @@ tych wskazówek bezpośrednio w każdym opisie narzędzia.
 </available_skills>
 ```

-Dzięki temu podstawowy prompt pozostaje mały, a jednocześnie nadal umożliwia ukierunkowane użycie Skills.
+Utrzymuje to mały prompt bazowy, jednocześnie nadal umożliwiając ukierunkowane użycie Skills.

 Budżet listy Skills należy do podsystemu Skills:

- Globalna wartość domyślna: `skills.limits.maxSkillsPromptChars`
- Nadpisanie dla agenta: `agents.list[].skillsLimits.maxSkillsPromptChars`
+- Domyślne globalne: `skills.limits.maxSkillsPromptChars`
+- Nadpisanie na agenta: `agents.list[].skillsLimits.maxSkillsPromptChars`

-Ogólne ograniczone wycinki środowiska wykonawczego używają innej powierzchni:
+Ogólne ograniczone fragmenty runtime używają innej powierzchni:

 - `agents.defaults.contextLimits.*`
 - `agents.list[].contextLimits.*`

-Ten podział utrzymuje rozmiarowanie Skills oddzielnie od rozmiarowania odczytu/wstrzykiwania środowiska wykonawczego, takiego jak
-`memory_get`, wyniki narzędzi na żywo i odświeżenia AGENTS.md po Compaction.
+Ten podział oddziela limity rozmiaru Skills od limitów rozmiaru odczytu/wstrzykiwania w czasie działania, takich jak `memory_get`, wyniki narzędzi na żywo oraz odświeżenia AGENTS.md po Compaction.

 ## Dokumentacja

-Prompt systemowy zawiera sekcję **Dokumentacja**. Gdy dostępna jest dokumentacja lokalna, wskazuje ona lokalny katalog dokumentacji OpenClaw (`docs/` w checkoutcie Git albo dokumentację dołączoną do pakietu npm). Jeśli dokumentacja lokalna jest niedostępna, używa w zastępstwie [https://docs.openclaw.ai](https://docs.openclaw.ai).
+Prompt systemowy zawiera sekcję **Dokumentacja**. Gdy lokalna dokumentacja jest dostępna, wskazuje lokalny katalog dokumentacji OpenClaw (`docs/` w checkoutcie Git albo dokumentację dołączoną do pakietu npm). Jeśli lokalna dokumentacja jest niedostępna, używa zapasowo [https://docs.openclaw.ai](https://docs.openclaw.ai).

-Ta sama sekcja zawiera także lokalizację źródeł OpenClaw. Checkouty Git udostępniają lokalny katalog główny źródeł, aby agent mógł bezpośrednio sprawdzać kod. Instalacje z pakietu zawierają adres URL źródeł w GitHub i instruują agenta, aby przeglądał tam źródła zawsze, gdy dokumentacja jest niekompletna lub nieaktualna. Prompt wspomina także publiczne lustro dokumentacji, społecznościowy Discord oraz ClawHub ([https://clawhub.ai](https://clawhub.ai)) do odkrywania Skills. Instruuje model, aby najpierw korzystał z dokumentacji w sprawach dotyczących działania, poleceń, konfiguracji lub architektury OpenClaw oraz aby, gdy to możliwe, sam uruchamiał `openclaw status` (pytając użytkownika tylko wtedy, gdy nie ma dostępu). W szczególności w przypadku konfiguracji kieruje agentów do akcji narzędzia `gateway` `config.schema.lookup`, aby uzyskać dokładną dokumentację i ograniczenia na poziomie pól, a następnie do `docs/gateway/configuration.md` i `docs/gateway/configuration-reference.md` w celu uzyskania szerszych wskazówek.
+Ta sama sekcja zawiera również lokalizację źródeł OpenClaw. Checkouty Git udostępniają lokalny katalog główny źródeł, aby agent mógł bezpośrednio sprawdzać kod. Instalacje pakietu zawierają URL źródeł w GitHub i instruują agenta, aby przeglądał tam źródła zawsze, gdy dokumentacja jest niepełna albo nieaktualna. Prompt odnotowuje też publiczne lustro dokumentacji, społecznościowy Discord oraz ClawHub ([https://clawhub.ai](https://clawhub.ai)) do odkrywania Skills. Instruuje model, aby najpierw korzystał z dokumentacji w sprawach zachowania OpenClaw, poleceń, konfiguracji lub architektury oraz aby samodzielnie uruchamiał `openclaw status`, gdy to możliwe (prosząc użytkownika tylko wtedy, gdy nie ma dostępu). W przypadku konfiguracji konkretnie kieruje agentów do akcji narzędzia `gateway` o nazwie `config.schema.lookup`, aby uzyskać dokładną dokumentację i ograniczenia na poziomie pól, a następnie do `docs/gateway/configuration.md` oraz `docs/gateway/configuration-reference.md` po szersze wskazówki.

 ## Powiązane

--- a/docs/pl/nodes/audio.md
+++ b/docs/pl/nodes/audio.md
@ -1,13 +1,13 @@
 ---
 read_when:
-    - Zmiana transkrypcji dźwięku lub obsługi multimediów
-summary: Jak przychodzące nagrania audio/notatki głosowe są pobierane, transkrybowane i wstawiane do odpowiedzi
+    - Zmiana transkrypcji audio lub obsługi multimediów
+summary: Jak przychodzące audio/notatki głosowe są pobierane, transkrybowane i wstawiane do odpowiedzi
 title: Dźwięk i notatki głosowe
 x-i18n:
-    generated_at: "2026-04-30T10:02:56Z"
+    generated_at: "2026-05-02T23:39:17Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 35074d79104f767ee252064462202a8ec21ac26f6db25c39e67f31f6b40edeb7
+    source_hash: 91cd6951f80c6137061a7d4e82415b0872bc92c6d6ad136273a2e9ad7ec00ac1
    source_path: nodes/audio.md
    workflow: 16
 ---
@ -16,25 +16,26 @@ x-i18n:

 ## Co działa

- **Rozumienie multimediów (audio)**: Jeśli rozumienie audio jest włączone (lub automatycznie wykryte), OpenClaw:
-  1. Lokalizuje pierwszy załącznik audio (ścieżka lokalna lub URL) i w razie potrzeby go pobiera.
-  2. Wymusza `maxBytes` przed wysłaniem do każdego wpisu modelu.
+- **Rozumienie mediów (audio)**: Jeśli rozumienie audio jest włączone (lub automatycznie wykryte), OpenClaw:
+  1. Lokalizuje pierwszy załącznik audio (ścieżka lokalna lub URL) i pobiera go w razie potrzeby.
+  2. Egzekwuje `maxBytes` przed wysłaniem do każdego wpisu modelu.
  3. Uruchamia pierwszy kwalifikujący się wpis modelu w kolejności (dostawca lub CLI).
-  4. Jeśli zakończy się niepowodzeniem lub zostanie pominięty (rozmiar/limit czasu), próbuje kolejnego wpisu.
+  4. Jeśli się nie powiedzie albo zostanie pominięty (rozmiar/limit czasu), próbuje następnego wpisu.
  5. Po powodzeniu zastępuje `Body` blokiem `[Audio]` i ustawia `{{Transcript}}`.
- **Parsowanie poleceń**: Gdy transkrypcja się powiedzie, `CommandBody`/`RawBody` są ustawiane na transkrypt, więc polecenia slash nadal działają.
- **Szczegółowe logowanie**: W trybie `--verbose` logujemy, kiedy działa transkrypcja i kiedy zastępuje treść.
+- **Parsowanie poleceń**: Gdy transkrypcja się powiedzie, `CommandBody`/`RawBody` są ustawiane na transkrypcję, więc polecenia ukośnikiem nadal działają.
+- **Szczegółowe logowanie**: W trybie `--verbose` logujemy, kiedy transkrypcja jest uruchamiana i kiedy zastępuje treść.
+- **Dyktowanie w Control UI**: Kompozytor Chat może wysłać nagrany w przeglądarce klip z mikrofonu do `chat.transcribeAudio`. To Gateway RPC zapisuje klip do tymczasowego pliku lokalnego, uruchamia ten sam potok transkrypcji audio, zwraca tekst szkicu do przeglądarki i usuwa plik tymczasowy. Samo w sobie nie tworzy uruchomienia agenta.

-## Automatyczne wykrywanie (domyślnie)
+## Automatyczne wykrywanie (domyślne)

 Jeśli **nie skonfigurujesz modeli**, a `tools.media.audio.enabled` **nie** jest ustawione na `false`,
-OpenClaw automatycznie wykrywa opcje w tej kolejności i zatrzymuje się na pierwszej działającej:
+OpenClaw automatycznie wykrywa w tej kolejności i zatrzymuje się na pierwszej działającej opcji:

 1. **Aktywny model odpowiedzi**, gdy jego dostawca obsługuje rozumienie audio.
 2. **Lokalne CLI** (jeśli zainstalowane)
   - `sherpa-onnx-offline` (wymaga `SHERPA_ONNX_MODEL_DIR` z encoder/decoder/joiner/tokens)
-   - `whisper-cli` (z `whisper-cpp`; używa `WHISPER_CPP_MODEL` albo dołączonego modelu tiny)
-   - `whisper` (CLI Pythona; automatycznie pobiera modele)
+   - `whisper-cli` (z `whisper-cpp`; używa `WHISPER_CPP_MODEL` lub dołączonego modelu tiny)
+   - `whisper` (Python CLI; automatycznie pobiera modele)
 3. **Gemini CLI** (`gemini`) z użyciem `read_many_files`
 4. **Uwierzytelnianie dostawcy**
   - Najpierw próbowane są skonfigurowane wpisy `models.providers.*`, które obsługują audio
@ -42,7 +43,7 @@ OpenClaw automatycznie wykrywa opcje w tej kolejności i zatrzymuje się na pier

 Aby wyłączyć automatyczne wykrywanie, ustaw `tools.media.audio.enabled: false`.
 Aby dostosować, ustaw `tools.media.audio.models`.
-Uwaga: wykrywanie plików binarnych jest best-effort w macOS/Linux/Windows; upewnij się, że CLI jest w `PATH` (rozwijamy `~`), albo ustaw jawny model CLI z pełną ścieżką polecenia.
+Uwaga: wykrywanie plików binarnych działa na zasadzie najlepszej próby w systemach macOS/Linux/Windows; upewnij się, że CLI jest w `PATH` (rozwijamy `~`), albo ustaw jawny model CLI z pełną ścieżką polecenia.

 ## Przykłady konfiguracji

@ -134,7 +135,7 @@ Uwaga: wykrywanie plików binarnych jest best-effort w macOS/Linux/Windows; upew
 }
 ```

-### Wyślij transkrypt na czat (opcjonalnie)
+### Echo transkrypcji do czatu (opcjonalne)

 ```json5
 {
@ -153,7 +154,7 @@ Uwaga: wykrywanie plików binarnych jest best-effort w macOS/Linux/Windows; upew

 ## Uwagi i ograniczenia

- Uwierzytelnianie dostawcy korzysta ze standardowej kolejności uwierzytelniania modelu (profile uwierzytelniania, zmienne env, `models.providers.*.apiKey`).
+- Uwierzytelnianie dostawcy działa zgodnie ze standardową kolejnością uwierzytelniania modeli (profile uwierzytelniania, zmienne środowiskowe, `models.providers.*.apiKey`).
 - Szczegóły konfiguracji Groq: [Groq](/pl/providers/groq).
 - Deepgram pobiera `DEEPGRAM_API_KEY`, gdy używane jest `provider: "deepgram"`.
 - Szczegóły konfiguracji Deepgram: [Deepgram (transkrypcja audio)](/pl/providers/deepgram).
@ -161,20 +162,20 @@ Uwaga: wykrywanie plików binarnych jest best-effort w macOS/Linux/Windows; upew
 - SenseAudio pobiera `SENSEAUDIO_API_KEY`, gdy używane jest `provider: "senseaudio"`.
 - Szczegóły konfiguracji SenseAudio: [SenseAudio](/pl/providers/senseaudio).
 - Dostawcy audio mogą nadpisywać `baseUrl`, `headers` i `providerOptions` przez `tools.media.audio`.
- Domyślny limit rozmiaru to 20MB (`tools.media.audio.maxBytes`). Zbyt duże audio jest pomijane dla tego modelu i próbowany jest kolejny wpis.
- Bardzo małe/puste pliki audio poniżej 1024 bajtów są pomijane przed transkrypcją dostawcy/CLI.
- Domyślne `maxChars` dla audio jest **nieustawione** (pełny transkrypt). Ustaw `tools.media.audio.maxChars` albo `maxChars` dla konkretnego wpisu, aby przyciąć dane wyjściowe.
- Domyślny model OpenAI auto to `gpt-4o-mini-transcribe`; ustaw `model: "gpt-4o-transcribe"` dla wyższej dokładności.
+- Domyślny limit rozmiaru to 20MB (`tools.media.audio.maxBytes`). Zbyt duże audio jest pomijane dla tego modelu i próbowany jest następny wpis.
+- Bardzo małe/puste pliki audio poniżej 1024 bajtów są pomijane przed transkrypcją przez dostawcę/CLI.
+- Domyślne `maxChars` dla audio jest **nieustawione** (pełna transkrypcja). Ustaw `tools.media.audio.maxChars` albo `maxChars` dla pojedynczego wpisu, aby przyciąć wynik.
+- Domyślna wartość automatyczna OpenAI to `gpt-4o-mini-transcribe`; ustaw `model: "gpt-4o-transcribe"` dla większej dokładności.
 - Użyj `tools.media.audio.attachments`, aby przetwarzać wiele notatek głosowych (`mode: "all"` + `maxAttachments`).
- Transkrypt jest dostępny dla szablonów jako `{{Transcript}}`.
- `tools.media.audio.echoTranscript` jest domyślnie wyłączone; włącz je, aby wysłać potwierdzenie transkryptu z powrotem do czatu źródłowego przed przetwarzaniem przez agenta.
- `tools.media.audio.echoFormat` dostosowuje tekst echo (placeholder: `{transcript}`).
- stdout CLI jest limitowany (5MB); utrzymuj dane wyjściowe CLI zwięzłe.
- `args` CLI powinny używać `{{MediaPath}}` dla ścieżki lokalnego pliku audio. Uruchom `openclaw doctor --fix`, aby zmigrować przestarzałe placeholdery `{input}` ze starszych konfiguracji `audio.transcription.command`.
+- Transkrypcja jest dostępna dla szablonów jako `{{Transcript}}`.
+- `tools.media.audio.echoTranscript` jest domyślnie wyłączone; włącz je, aby wysłać potwierdzenie transkrypcji z powrotem do czatu źródłowego przed przetwarzaniem przez agenta.
+- `tools.media.audio.echoFormat` dostosowuje tekst echa (placeholder: `{transcript}`).
+- stdout CLI jest limitowany (5MB); utrzymuj zwięzły wynik CLI.
+- `args` CLI powinno używać `{{MediaPath}}` dla ścieżki lokalnego pliku audio. Uruchom `openclaw doctor --fix`, aby zmigrować przestarzałe placeholdery `{input}` ze starszych konfiguracji `audio.transcription.command`.

 ### Obsługa środowiska proxy

-Transkrypcja audio oparta na dostawcy honoruje standardowe wychodzące zmienne env proxy:
+Transkrypcja audio oparta na dostawcy respektuje standardowe zmienne środowiskowe proxy dla ruchu wychodzącego:

 - `HTTPS_PROXY`
 - `HTTP_PROXY`
@ -183,42 +184,42 @@ Transkrypcja audio oparta na dostawcy honoruje standardowe wychodzące zmienne e
 - `http_proxy`
 - `all_proxy`

-Jeśli nie ustawiono zmiennych env proxy, używane jest bezpośrednie wyjście. Jeśli konfiguracja proxy jest nieprawidłowa, OpenClaw loguje ostrzeżenie i wraca do bezpośredniego pobierania.
+Jeśli nie ustawiono żadnych zmiennych środowiskowych proxy, używane jest bezpośrednie wyjście. Jeśli konfiguracja proxy jest niepoprawna, OpenClaw loguje ostrzeżenie i wraca do bezpośredniego pobierania.

 ## Wykrywanie wzmianek w grupach

-Gdy `requireMention: true` jest ustawione dla czatu grupowego, OpenClaw transkrybuje teraz audio **przed** sprawdzeniem wzmianek. Dzięki temu notatki głosowe mogą być przetwarzane nawet wtedy, gdy zawierają wzmianki.
+Gdy `requireMention: true` jest ustawione dla czatu grupowego, OpenClaw transkrybuje teraz audio **przed** sprawdzeniem wzmianek. Pozwala to przetwarzać notatki głosowe nawet wtedy, gdy zawierają wzmianki.

 **Jak to działa:**

-1. Jeśli wiadomość głosowa nie ma treści tekstowej, a grupa wymaga wzmianek, OpenClaw wykonuje transkrypcję „preflight”.
-2. Transkrypt jest sprawdzany pod kątem wzorców wzmianek (np. `@BotName`, wyzwalacze emoji).
-3. Jeśli wzmianka zostanie znaleziona, wiadomość przechodzi przez pełny pipeline odpowiedzi.
-4. Transkrypt jest używany do wykrywania wzmianek, aby notatki głosowe mogły przejść przez bramkę wzmianek.
+1. Jeśli wiadomość głosowa nie ma treści tekstowej, a grupa wymaga wzmianek, OpenClaw wykonuje transkrypcję wstępną.
+2. Transkrypcja jest sprawdzana pod kątem wzorców wzmianek (np. `@BotName`, wyzwalacze emoji).
+3. Jeśli wzmianka zostanie znaleziona, wiadomość przechodzi przez pełny potok odpowiedzi.
+4. Transkrypcja jest używana do wykrywania wzmianek, aby notatki głosowe mogły przejść bramkę wzmianek.

 **Zachowanie awaryjne:**

- Jeśli transkrypcja nie powiedzie się podczas preflight (limit czasu, błąd API itd.), wiadomość jest przetwarzana na podstawie wykrywania wzmianek wyłącznie w tekście.
- Zapewnia to, że wiadomości mieszane (tekst + audio) nigdy nie zostaną niepoprawnie odrzucone.
+- Jeśli transkrypcja nie powiedzie się podczas etapu wstępnego (limit czasu, błąd API itd.), wiadomość jest przetwarzana na podstawie wykrywania wzmianek tylko w tekście.
+- Dzięki temu wiadomości mieszane (tekst + audio) nigdy nie są błędnie odrzucane.

 **Rezygnacja dla grupy/tematu Telegram:**

- Ustaw `channels.telegram.groups.<chatId>.disableAudioPreflight: true`, aby pominąć sprawdzanie wzmianek w transkrypcie preflight dla tej grupy.
- Ustaw `channels.telegram.groups.<chatId>.topics.<threadId>.disableAudioPreflight`, aby nadpisać ustawienie dla tematu (`true`, aby pominąć, `false`, aby wymusić włączenie).
- Domyślnie `false` (preflight włączony, gdy warunki bramkowania wzmiankami pasują).
+- Ustaw `channels.telegram.groups.<chatId>.disableAudioPreflight: true`, aby pominąć wstępne sprawdzanie wzmianek w transkrypcji dla tej grupy.
+- Ustaw `channels.telegram.groups.<chatId>.topics.<threadId>.disableAudioPreflight`, aby nadpisać dla tematu (`true`, aby pominąć, `false`, aby wymusić włączenie).
+- Domyślnie jest `false` (etap wstępny włączony, gdy pasują warunki bramkowania wzmiankami).

-**Przykład:** Użytkownik wysyła notatkę głosową mówiącą „Hej @Claude, jaka jest pogoda?” w grupie Telegram z `requireMention: true`. Notatka głosowa jest transkrybowana, wzmianka zostaje wykryta, a agent odpowiada.
+**Przykład:** Użytkownik wysyła notatkę głosową mówiącą „Hej @Claude, jaka jest pogoda?” w grupie Telegram z `requireMention: true`. Notatka głosowa zostaje przetranskrybowana, wzmianka wykryta, a agent odpowiada.

 ## Pułapki

 - Reguły zakresu używają zasady pierwszego dopasowania. `chatType` jest normalizowane do `direct`, `group` albo `room`.
- Upewnij się, że CLI kończy działanie kodem 0 i wypisuje zwykły tekst; JSON trzeba przetworzyć przez `jq -r .text`.
- Dla `parakeet-mlx`, jeśli przekażesz `--output-dir`, OpenClaw odczytuje `<output-dir>/<media-basename>.txt`, gdy `--output-format` ma wartość `txt` (albo jest pominięty); formaty wyjściowe inne niż `txt` wracają do parsowania stdout.
+- Upewnij się, że Twoje CLI kończy działanie kodem 0 i wypisuje zwykły tekst; JSON trzeba przetworzyć przez `jq -r .text`.
+- Dla `parakeet-mlx`, jeśli przekażesz `--output-dir`, OpenClaw odczyta `<output-dir>/<media-basename>.txt`, gdy `--output-format` to `txt` (lub jest pominięty); formaty wyjściowe inne niż `txt` wracają do parsowania stdout.
 - Utrzymuj rozsądne limity czasu (`timeoutSeconds`, domyślnie 60s), aby nie blokować kolejki odpowiedzi.
- Transkrypcja preflight przetwarza tylko **pierwszy** załącznik audio do wykrywania wzmianek. Dodatkowe audio jest przetwarzane podczas głównej fazy rozumienia multimediów.
+- Transkrypcja wstępna przetwarza tylko **pierwszy** załącznik audio do wykrywania wzmianek. Dodatkowe audio jest przetwarzane podczas głównej fazy rozumienia mediów.

 ## Powiązane

- [Rozumienie multimediów](/pl/nodes/media-understanding)
+- [Rozumienie mediów](/pl/nodes/media-understanding)
 - [Tryb rozmowy](/pl/nodes/talk)
 - [Wybudzanie głosem](/pl/nodes/voicewake)
--- a/docs/pl/plugins/codex-harness.md
+++ b/docs/pl/plugins/codex-harness.md
--- a/docs/pl/providers/arcee.md
+++ b/docs/pl/providers/arcee.md
@ -1,35 +1,35 @@
 ---
 read_when:
    - Chcesz używać Arcee AI z OpenClaw
-    - Potrzebujesz zmiennej środowiskowej klucza API albo wyboru auth w CLI
-summary: Konfiguracja Arcee AI (auth + wybór modelu)
+    - Wymagana jest zmienna środowiskowa klucza API albo wybór uwierzytelniania CLI
+summary: Konfiguracja Arcee AI (uwierzytelnianie + wybór modelu)
 title: Arcee AI
 x-i18n:
-    generated_at: "2026-04-24T09:26:35Z"
-    model: gpt-5.4
+    generated_at: "2026-05-02T23:39:22Z"
+    model: gpt-5.5
    provider: openai
-    source_hash: 54989e1706901fedc8a0c816ca7ee7f877fa4b973697540dd90cb9182420043f
+    source_hash: 622ee5288aec3ae0b45d3f06ba65fd6f972e07d7a7596ae3905d6fbdac0bf737
    source_path: providers/arcee.md
-    workflow: 15
+    workflow: 16
 ---

-[Arcee AI](https://arcee.ai) zapewnia dostęp do rodziny modeli mixture-of-experts Trinity przez API zgodne z OpenAI. Wszystkie modele Trinity są objęte licencją Apache 2.0.
+[Arcee AI](https://arcee.ai) zapewnia dostęp do rodziny modeli Trinity typu mixture-of-experts przez API zgodne z OpenAI. Wszystkie modele Trinity są objęte licencją Apache 2.0.

-Dostęp do modeli Arcee AI można uzyskać bezpośrednio przez platformę Arcee lub przez [OpenRouter](/pl/providers/openrouter).
+Dostęp do modeli Arcee AI można uzyskać bezpośrednio przez platformę Arcee albo przez [OpenRouter](/pl/providers/openrouter).

-| Właściwość | Wartość                                                                              |
-| ---------- | ------------------------------------------------------------------------------------ |
-| Provider   | `arcee`                                                                              |
-| Auth       | `ARCEEAI_API_KEY` (bezpośrednio) lub `OPENROUTER_API_KEY` (przez OpenRouter)         |
-| API        | Zgodne z OpenAI                                                                      |
-| Base URL   | `https://api.arcee.ai/api/v1` (bezpośrednio) lub `https://openrouter.ai/api/v1` (OpenRouter) |
+| Właściwość       | Wartość                                                                               |
+| ---------------- | ------------------------------------------------------------------------------------- |
+| Dostawca         | `arcee`                                                                               |
+| Uwierzytelnianie | `ARCEEAI_API_KEY` (bezpośrednio) lub `OPENROUTER_API_KEY` (przez OpenRouter)          |
+| API              | zgodne z OpenAI                                                                       |
+| Bazowy URL       | `https://api.arcee.ai/api/v1` (bezpośrednio) lub `https://openrouter.ai/api/v1` (OpenRouter) |

 ## Pierwsze kroki

 <Tabs>
  <Tab title="Bezpośrednio (platforma Arcee)">
    <Steps>
-      <Step title="Pobierz klucz API">
+      <Step title="Uzyskaj klucz API">
        Utwórz klucz API w [Arcee AI](https://chat.arcee.ai/).
      </Step>
      <Step title="Uruchom onboarding">
@ -53,7 +53,7 @@ Dostęp do modeli Arcee AI można uzyskać bezpośrednio przez platformę Arcee

  <Tab title="Przez OpenRouter">
    <Steps>
-      <Step title="Pobierz klucz API">
+      <Step title="Uzyskaj klucz API">
        Utwórz klucz API w [OpenRouter](https://openrouter.ai/keys).
      </Step>
      <Step title="Uruchom onboarding">
@ -72,7 +72,7 @@ Dostęp do modeli Arcee AI można uzyskać bezpośrednio przez platformę Arcee
        }
        ```

-        Te same odwołania modeli działają zarówno dla konfiguracji bezpośrednich, jak i przez OpenRouter (na przykład `arcee/trinity-large-thinking`).
+        Te same odwołania do modeli działają zarówno w konfiguracji bezpośredniej, jak i przez OpenRouter (na przykład `arcee/trinity-large-thinking`).
      </Step>
    </Steps>

@ -103,39 +103,39 @@ Dostęp do modeli Arcee AI można uzyskać bezpośrednio przez platformę Arcee

 ## Wbudowany katalog

-OpenClaw obecnie dostarcza ten dołączony katalog Arcee:
+OpenClaw obecnie zawiera ten wbudowany katalog Arcee:

-| Ref modelu                     | Nazwa                  | Wejście | Kontekst | Koszt (wej./wyj. na 1M) | Uwagi                                      |
-| ------------------------------ | ---------------------- | ------- | -------- | ----------------------- | ------------------------------------------ |
-| `arcee/trinity-large-thinking` | Trinity Large Thinking | tekst   | 256K     | $0.25 / $0.90           | Model domyślny; reasoning włączone         |
-| `arcee/trinity-large-preview`  | Trinity Large Preview  | tekst   | 128K     | $0.25 / $1.00           | Ogólnego przeznaczenia; 400B parametrów, 13B aktywnych |
-| `arcee/trinity-mini`           | Trinity Mini 26B       | tekst   | 128K     | $0.045 / $0.15          | Szybki i oszczędny; function calling       |
+| Odwołanie do modelu            | Nazwa                  | Dane wejściowe | Kontekst | Koszt (wej./wyj. za 1 mln) | Uwagi                                           |
+| ------------------------------ | ---------------------- | -------------- | -------- | -------------------------- | ----------------------------------------------- |
+| `arcee/trinity-large-thinking` | Trinity Large Thinking | tekst          | 256K     | $0.25 / $0.90              | Model domyślny; wnioskowanie włączone; bez narzędzi |
+| `arcee/trinity-large-preview`  | Trinity Large Preview  | tekst          | 128K     | $0.25 / $1.00              | Ogólnego przeznaczenia; 400 mld parametrów, 13 mld aktywnych |
+| `arcee/trinity-mini`           | Trinity Mini 26B       | tekst          | 128K     | $0.045 / $0.15             | Szybki i ekonomiczny; wywoływanie funkcji       |

 <Tip>
-Preset onboardingu ustawia `arcee/trinity-large-thinking` jako model domyślny.
+Preset onboardingu ustawia `arcee/trinity-large-thinking` jako model domyślny. Obsługuje on tylko wnioskowanie i tekst oraz nie obsługuje użycia narzędzi ani wywoływania funkcji.
 </Tip>

 ## Obsługiwane funkcje

-| Funkcja                                       | Obsługiwane                  |
-| --------------------------------------------- | ---------------------------- |
-| Streaming                                     | Tak                          |
-| Użycie narzędzi / function calling            | Tak                          |
-| Strukturalne dane wyjściowe (tryb JSON i schemat JSON) | Tak                  |
-| Extended thinking                             | Tak (Trinity Large Thinking) |
+| Funkcja                                      | Obsługiwane                                 |
+| -------------------------------------------- | ------------------------------------------- |
+| Strumieniowanie                              | Tak                                         |
+| Użycie narzędzi / wywoływanie funkcji        | Zależne od modelu; nie Trinity Large Thinking |
+| Dane wyjściowe ze strukturą (tryb JSON i schemat JSON) | Tak                                |
+| Rozszerzone myślenie                         | Tak (Trinity Large Thinking)                |

 <AccordionGroup>
-  <Accordion title="Uwaga o środowisku">
+  <Accordion title="Uwaga dotycząca środowiska">
    Jeśli Gateway działa jako daemon (launchd/systemd), upewnij się, że `ARCEEAI_API_KEY`
    (lub `OPENROUTER_API_KEY`) jest dostępny dla tego procesu (na przykład w
    `~/.openclaw/.env` albo przez `env.shellEnv`).
  </Accordion>

  <Accordion title="Routing OpenRouter">
-    Przy używaniu modeli Arcee przez OpenRouter obowiązują te same odwołania modeli `arcee/*`.
-    OpenClaw obsługuje routing transparentnie zgodnie z Twoim wyborem auth. Zobacz
-    [dokumentację providera OpenRouter](/pl/providers/openrouter), aby poznać szczegóły
-    konfiguracji specyficzne dla OpenRouter.
+    Podczas używania modeli Arcee przez OpenRouter obowiązują te same odwołania do modeli `arcee/*`.
+    OpenClaw obsługuje routing transparentnie na podstawie wybranej metody uwierzytelniania. Zobacz
+    [dokumentację dostawcy OpenRouter](/pl/providers/openrouter), aby poznać szczegóły konfiguracji
+    specyficzne dla OpenRouter.
  </Accordion>
 </AccordionGroup>

@ -143,9 +143,9 @@ Preset onboardingu ustawia `arcee/trinity-large-thinking` jako model domyślny.

 <CardGroup cols={2}>
  <Card title="OpenRouter" href="/pl/providers/openrouter" icon="shuffle">
-    Uzyskaj dostęp do modeli Arcee i wielu innych przez jeden klucz API.
+    Dostęp do modeli Arcee i wielu innych przy użyciu jednego klucza API.
  </Card>
  <Card title="Wybór modelu" href="/pl/concepts/model-providers" icon="layers">
-    Wybór providerów, odwołań modeli i zachowania failover.
+    Wybieranie dostawców, odwołań do modeli i zachowania przełączania awaryjnego.
  </Card>
 </CardGroup>
--- a/docs/pl/reference/RELEASING.md
+++ b/docs/pl/reference/RELEASING.md
--- a/docs/pl/web/control-ui.md
+++ b/docs/pl/web/control-ui.md
@ -1,20 +1,20 @@
 ---
 read_when:
    - Chcesz obsługiwać Gateway z poziomu przeglądarki
-    - Chcesz dostępu do Tailnet bez tuneli SSH
+    - Chcesz mieć dostęp do Tailnet bez tuneli SSH
 sidebarTitle: Control UI
-summary: Oparty na przeglądarce interfejs sterowania dla Gateway (czat, węzły, konfiguracja)
+summary: Przeglądarkowy interfejs sterowania dla Gateway (czat, węzły, konfiguracja)
 title: Interfejs sterowania
 x-i18n:
-    generated_at: "2026-05-02T20:59:07Z"
+    generated_at: "2026-05-02T23:39:21Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 88959ccf435b31015039bf28c3043023d99f0b953a1489986ab2d0cbd261771c
+    source_hash: 50bef807915f27406e19f1c6ca7d839a610d79ba79da85d7a78523400cbf9208
    source_path: web/control-ui.md
    workflow: 16
 ---

-Interfejs Control UI to mała jednostronicowa aplikacja **Vite + Lit** obsługiwana przez Gateway:
+Control UI to mała jednostronicowa aplikacja **Vite + Lit** obsługiwana przez Gateway:

 - domyślnie: `http://<host>:18789/`
 - opcjonalny prefiks: ustaw `gateway.controlUi.basePath` (np. `/openclaw`)
@ -29,124 +29,125 @@ Jeśli Gateway działa na tym samym komputerze, otwórz:

 Jeśli strona się nie ładuje, najpierw uruchom Gateway: `openclaw gateway`.

-Uwierzytelnianie jest przekazywane podczas uzgadniania połączenia WebSocket przez:
+Uwierzytelnianie jest przekazywane podczas uzgadniania WebSocket przez:

 - `connect.params.auth.token`
 - `connect.params.auth.password`
 - nagłówki tożsamości Tailscale Serve, gdy `gateway.auth.allowTailscale: true`
 - nagłówki tożsamości zaufanego proxy, gdy `gateway.auth.mode: "trusted-proxy"`

-Panel ustawień pulpitu przechowuje token dla bieżącej sesji karty przeglądarki i wybranego adresu URL gateway; hasła nie są utrwalane. Onboarding zwykle generuje token gateway do uwierzytelniania współdzielonym sekretem przy pierwszym połączeniu, ale uwierzytelnianie hasłem też działa, gdy `gateway.auth.mode` ma wartość `"password"`.
+Panel ustawień pulpitu przechowuje token dla bieżącej sesji karty przeglądarki i wybranego adresu URL gateway; hasła nie są utrwalane. Onboarding zwykle generuje token gateway do uwierzytelniania wspólnym sekretem przy pierwszym połączeniu, ale uwierzytelnianie hasłem też działa, gdy `gateway.auth.mode` ma wartość `"password"`.

 ## Parowanie urządzenia (pierwsze połączenie)

-Gdy łączysz się z interfejsem Control UI z nowej przeglądarki lub urządzenia, Gateway zwykle wymaga **jednorazowego zatwierdzenia parowania**. To środek bezpieczeństwa zapobiegający nieautoryzowanemu dostępowi.
+Gdy łączysz się z Control UI z nowej przeglądarki lub urządzenia, Gateway zwykle wymaga **jednorazowego zatwierdzenia parowania**. To środek bezpieczeństwa zapobiegający nieautoryzowanemu dostępowi.

 **Co zobaczysz:** „disconnected (1008): pairing required”

 <Steps>
-  <Step title="List pending requests">
+  <Step title="Wyświetl oczekujące żądania">
    ```bash
    openclaw devices list
    ```
  </Step>
-  <Step title="Approve by request ID">
+  <Step title="Zatwierdź według identyfikatora żądania">
    ```bash
    openclaw devices approve <requestId>
    ```
  </Step>
 </Steps>

-Jeśli przeglądarka ponawia próbę parowania ze zmienionymi danymi uwierzytelniania (rola/zakresy/klucz publiczny), poprzednia oczekująca prośba zostaje zastąpiona i tworzony jest nowy `requestId`. Przed zatwierdzeniem uruchom ponownie `openclaw devices list`.
+Jeśli przeglądarka ponawia parowanie ze zmienionymi danymi uwierzytelniania (rola/zakresy/klucz publiczny), poprzednie oczekujące żądanie zostaje zastąpione i tworzony jest nowy `requestId`. Przed zatwierdzeniem uruchom ponownie `openclaw devices list`.

-Jeśli przeglądarka jest już sparowana i zmienisz ją z dostępu do odczytu na dostęp do zapisu/administracyjny, jest to traktowane jako rozszerzenie zatwierdzenia, a nie ciche ponowne połączenie. OpenClaw utrzymuje stare zatwierdzenie jako aktywne, blokuje ponowne połączenie o szerszym zakresie i prosi o jawne zatwierdzenie nowego zestawu zakresów.
+Jeśli przeglądarka jest już sparowana i zmienisz jej dostęp z odczytu na zapis/administrację, jest to traktowane jako podniesienie poziomu zatwierdzenia, a nie ciche ponowne połączenie. OpenClaw utrzymuje stare zatwierdzenie jako aktywne, blokuje ponowne połączenie z szerszymi uprawnieniami i prosi o jawne zatwierdzenie nowego zestawu zakresów.

-Po zatwierdzeniu urządzenie zostaje zapamiętane i nie będzie wymagać ponownego zatwierdzenia, chyba że je unieważnisz poleceniem `openclaw devices revoke --device <id> --role <role>`. Zobacz [CLI urządzeń](/pl/cli/devices), aby uzyskać informacje o rotacji i unieważnianiu tokenów.
+Po zatwierdzeniu urządzenie jest zapamiętywane i nie będzie wymagać ponownego zatwierdzenia, chyba że je odwołasz poleceniem `openclaw devices revoke --device <id> --role <role>`. Zobacz [CLI urządzeń](/pl/cli/devices), aby uzyskać informacje o rotacji i odwoływaniu tokenów.

 <Note>
 - Bezpośrednie połączenia przeglądarki przez local loopback (`127.0.0.1` / `localhost`) są zatwierdzane automatycznie.
 - Tailscale Serve może pominąć rundę parowania dla sesji operatora Control UI, gdy `gateway.auth.allowTailscale: true`, tożsamość Tailscale zostanie zweryfikowana, a przeglądarka przedstawi swoją tożsamość urządzenia.
- Bezpośrednie powiązania Tailnet, połączenia przeglądarki w sieci LAN oraz profile przeglądarki bez tożsamości urządzenia nadal wymagają jawnego zatwierdzenia.
+- Bezpośrednie powiązania Tailnet, połączenia przeglądarki z sieci LAN oraz profile przeglądarki bez tożsamości urządzenia nadal wymagają jawnego zatwierdzenia.
 - Każdy profil przeglądarki generuje unikatowy identyfikator urządzenia, więc zmiana przeglądarki lub wyczyszczenie danych przeglądarki będzie wymagać ponownego parowania.

 </Note>

-## Tożsamość osobista (lokalna dla przeglądarki)
+## Tożsamość osobista (lokalna w przeglądarce)

-Control UI obsługuje osobistą tożsamość dla każdej przeglądarki (nazwę wyświetlaną i awatar) dołączaną do wiadomości wychodzących na potrzeby przypisania autorstwa we współdzielonych sesjach. Jest przechowywana w pamięci przeglądarki, ograniczona do bieżącego profilu przeglądarki i nie jest synchronizowana z innymi urządzeniami ani utrwalana po stronie serwera poza standardowymi metadanymi autorstwa transkrypcji przy wiadomościach, które faktycznie wysyłasz. Wyczyszczenie danych witryny lub zmiana przeglądarki resetuje ją do pustej wartości.
+Control UI obsługuje osobistą tożsamość dla danej przeglądarki (nazwę wyświetlaną i awatar), dołączaną do wiadomości wychodzących w celu przypisania autorstwa we współdzielonych sesjach. Jest przechowywana w pamięci przeglądarki, ograniczona do bieżącego profilu przeglądarki i nie jest synchronizowana z innymi urządzeniami ani utrwalana po stronie serwera poza zwykłymi metadanymi autorstwa transkryptu dla wiadomości, które faktycznie wysyłasz. Wyczyszczenie danych witryny lub zmiana przeglądarki resetuje ją do pustej wartości.

-Ten sam wzorzec lokalny dla przeglądarki dotyczy nadpisania awatara asystenta. Przesłane awatary asystenta nakładają tożsamość rozpoznaną przez gateway tylko w lokalnej przeglądarce i nigdy nie są przesyłane zwrotnie przez `config.patch`. Współdzielone pole konfiguracji `ui.assistant.avatar` jest nadal dostępne dla klientów innych niż UI, którzy zapisują to pole bezpośrednio (takich jak skryptowane gateway lub niestandardowe pulpity).
+Ten sam lokalny w przeglądarce wzorzec dotyczy nadpisania awatara asystenta. Przesłane awatary asystenta nakładają tożsamość rozwiązaną przez gateway tylko w lokalnej przeglądarce i nigdy nie przechodzą w obie strony przez `config.patch`. Współdzielone pole konfiguracji `ui.assistant.avatar` jest nadal dostępne dla klientów innych niż UI, którzy zapisują to pole bezpośrednio (takich jak skryptowane gatewaye lub niestandardowe pulpity).

-## Punkt końcowy konfiguracji runtime
+## Punkt końcowy konfiguracji środowiska uruchomieniowego

-Control UI pobiera swoje ustawienia runtime z `/__openclaw/control-ui-config.json`. Ten punkt końcowy jest chroniony tym samym uwierzytelnianiem gateway co reszta powierzchni HTTP: nieuwierzytelnione przeglądarki nie mogą go pobrać, a udane pobranie wymaga już ważnego tokena/hasła gateway, tożsamości Tailscale Serve albo tożsamości zaufanego proxy.
+Control UI pobiera swoje ustawienia środowiska uruchomieniowego z `/__openclaw/control-ui-config.json`. Ten punkt końcowy jest chroniony tym samym uwierzytelnianiem gateway co reszta powierzchni HTTP: nieuwierzytelnione przeglądarki nie mogą go pobrać, a udane pobranie wymaga już ważnego tokenu/hasła gateway, tożsamości Tailscale Serve albo tożsamości zaufanego proxy.

 ## Obsługa języków

-Control UI może zlokalizować się przy pierwszym ładowaniu na podstawie ustawień regionalnych przeglądarki. Aby później to zmienić, otwórz **Przegląd -> Dostęp do Gateway -> Język**. Selektor ustawień regionalnych znajduje się na karcie Dostęp do Gateway, a nie w sekcji Wygląd.
+Control UI może zlokalizować się przy pierwszym ładowaniu na podstawie lokalizacji przeglądarki. Aby później to zmienić, otwórz **Przegląd -> Dostęp do Gateway -> Język**. Selektor lokalizacji znajduje się w karcie Dostęp do Gateway, a nie w Wyglądzie.

- Obsługiwane ustawienia regionalne: `en`, `zh-CN`, `zh-TW`, `pt-BR`, `de`, `es`, `ja-JP`, `ko`, `fr`, `ar`, `it`, `tr`, `uk`, `id`, `pl`, `th`, `vi`, `nl`, `fa`
+- Obsługiwane lokalizacje: `en`, `zh-CN`, `zh-TW`, `pt-BR`, `de`, `es`, `ja-JP`, `ko`, `fr`, `ar`, `it`, `tr`, `uk`, `id`, `pl`, `th`, `vi`, `nl`, `fa`
 - Tłumaczenia inne niż angielskie są leniwie ładowane w przeglądarce.
- Wybrane ustawienie regionalne jest zapisywane w pamięci przeglądarki i ponownie używane przy kolejnych wizytach.
+- Wybrana lokalizacja jest zapisywana w pamięci przeglądarki i używana ponownie podczas kolejnych wizyt.
 - Brakujące klucze tłumaczeń wracają do języka angielskiego.

-Tłumaczenia dokumentacji są generowane dla tego samego zestawu ustawień regionalnych innych niż angielskie, ale wbudowany selektor języka witryny dokumentacji Mintlify jest ograniczony do kodów ustawień regionalnych akceptowanych przez Mintlify. Dokumentacja tajska (`th`) i perska (`fa`) nadal jest generowana w repozytorium publikacji; może nie pojawić się w tym selektorze, dopóki Mintlify nie zacznie obsługiwać tych kodów.
+Tłumaczenia dokumentacji są generowane dla tego samego zestawu lokalizacji innych niż angielska, ale wbudowany w witrynę dokumentacji selektor języka Mintlify jest ograniczony do kodów lokalizacji akceptowanych przez Mintlify. Dokumentacja tajska (`th`) i perska (`fa`) nadal jest generowana w repozytorium publikacji; może nie pojawiać się w tym selektorze, dopóki Mintlify nie będzie obsługiwać tych kodów.

 ## Motywy wyglądu

-Panel Wygląd zachowuje wbudowane motywy Claw, Knot i Dash oraz jedno lokalne dla przeglądarki miejsce importu tweakcn. Aby zaimportować motyw, otwórz [motywy tweakcn](https://tweakcn.com/themes), wybierz lub utwórz motyw, kliknij **Udostępnij** i wklej skopiowany link motywu w sekcji Wygląd. Importer akceptuje też adresy URL rejestru `https://tweakcn.com/r/themes/<id>`, adresy URL edytora takie jak `https://tweakcn.com/editor/theme?theme=amethyst-haze`, względne ścieżki `/themes/<id>`, surowe identyfikatory motywów i domyślne nazwy motywów, takie jak `amethyst-haze`.
+Panel Wygląd zachowuje wbudowane motywy Claw, Knot i Dash oraz jedno lokalne w przeglądarce miejsce importu tweakcn. Aby zaimportować motyw, otwórz [motywy tweakcn](https://tweakcn.com/themes), wybierz lub utwórz motyw, kliknij **Udostępnij** i wklej skopiowany link motywu w Wyglądzie. Importer akceptuje też adresy URL rejestru `https://tweakcn.com/r/themes/<id>`, adresy URL edytora takie jak `https://tweakcn.com/editor/theme?theme=amethyst-haze`, względne ścieżki `/themes/<id>`, surowe identyfikatory motywów i domyślne nazwy motywów, takie jak `amethyst-haze`.

-Zaimportowane motywy są przechowywane tylko w bieżącym profilu przeglądarki. Nie są zapisywane w konfiguracji gateway i nie synchronizują się między urządzeniami. Zastąpienie zaimportowanego motywu aktualizuje jedno lokalne miejsce; wyczyszczenie go przełącza aktywny motyw z powrotem na Claw, jeśli zaimportowany motyw był wybrany.
+Zaimportowane motywy są przechowywane tylko w bieżącym profilu przeglądarki. Nie są zapisywane w konfiguracji gateway i nie synchronizują się między urządzeniami. Zastąpienie zaimportowanego motywu aktualizuje jedno lokalne miejsce; wyczyszczenie go przełącza aktywny motyw z powrotem na Claw, jeśli wybrany był zaimportowany motyw.

 ## Co potrafi (obecnie)

 <AccordionGroup>
-  <Accordion title="Chat and Talk">
-    - Czat z modelem przez Gateway WS (`chat.history`, `chat.send`, `chat.abort`, `chat.inject`).
-    - Rozmowy przez sesje przeglądarkowe w czasie rzeczywistym. OpenAI używa bezpośredniego WebRTC, Google Live używa ograniczonego jednorazowego tokena przeglądarki przez WebSocket, a backendowe Plugin głosu w czasie rzeczywistym używają transportu przekaźnikowego Gateway. Przekaźnik utrzymuje dane uwierzytelniające dostawcy w Gateway, podczas gdy przeglądarka strumieniuje PCM z mikrofonu przez RPC `talk.realtime.relay*` i wysyła wywołania narzędzia `openclaw_agent_consult` z powrotem przez `chat.send` do większego skonfigurowanego modelu OpenClaw.
-    - Strumieniowe wywołania narzędzi + karty wyników narzędzi na żywo w czacie (zdarzenia agenta).
+  <Accordion title="Czat i rozmowa">
+    - Rozmawiaj z modelem przez Gateway WS (`chat.history`, `chat.send`, `chat.abort`, `chat.inject`).
+    - Dyktuj do kompozytora czatu za pomocą STT po stronie serwera (`chat.transcribeAudio`). Przeglądarka nagrywa krótki klip z mikrofonu i wysyła go do Gateway, który uruchamia skonfigurowany potok transkrypcji `tools.media.audio` i zwraca szkic tekstu bez ujawniania danych uwierzytelniających dostawcy przeglądarce.
+    - Rozmawiaj przez sesje czasu rzeczywistego w przeglądarce. OpenAI używa bezpośredniego WebRTC, Google Live używa ograniczonego jednorazowego tokenu przeglądarki przez WebSocket, a wtyczki głosowe czasu rzeczywistego działające tylko w backendzie używają transportu przekaźnikowego Gateway. Przekaźnik utrzymuje dane uwierzytelniające dostawcy na Gateway, podczas gdy przeglądarka strumieniuje PCM z mikrofonu przez RPC `talk.realtime.relay*` i wysyła wywołania narzędzia `openclaw_agent_consult` z powrotem przez `chat.send` do większego skonfigurowanego modelu OpenClaw.
+    - Strumieniuj wywołania narzędzi i karty wyjścia narzędzi na żywo w czacie (zdarzenia agenta).

  </Accordion>
-  <Accordion title="Channels, instances, sessions, dreams">
-    - Kanały: wbudowane oraz status kanałów z dołączonych/zewnętrznych Plugin, logowanie QR i konfiguracja per kanał (`channels.status`, `web.login.*`, `config.patch`).
+  <Accordion title="Kanały, instancje, sesje, sny">
+    - Kanały: status kanałów wbudowanych oraz kanałów Plugin w pakiecie/zewnętrznych, logowanie QR i konfiguracja dla poszczególnych kanałów (`channels.status`, `web.login.*`, `config.patch`).
    - Instancje: lista obecności + odświeżanie (`system-presence`).
-    - Sesje: lista + nadpisania modelu/myślenia/trybu szybkiego/szczegółowości/śladu/rozumowania per sesja (`sessions.list`, `sessions.patch`).
-    - Sny: status Dreaming, przełącznik włączania/wyłączania i czytnik dziennika snów (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`).
+    - Sesje: lista + nadpisania modelu/myślenia/trybu szybkiego/trybu szczegółowego/śledzenia/rozumowania dla poszczególnych sesji (`sessions.list`, `sessions.patch`).
+    - Sny: status Dreaming, przełącznik włączania/wyłączania i czytnik Dziennika snów (`doctor.memory.status`, `doctor.memory.dreamDiary`, `config.patch`).

  </Accordion>
-  <Accordion title="Cron, skills, nodes, exec approvals">
+  <Accordion title="Cron, skills, węzły, zatwierdzenia exec">
    - Zadania Cron: lista/dodawanie/edycja/uruchamianie/włączanie/wyłączanie + historia uruchomień (`cron.*`).
    - Skills: status, włączanie/wyłączanie, instalacja, aktualizacje kluczy API (`skills.*`).
-    - Nodes: lista + możliwości (`node.list`).
-    - Zatwierdzenia exec: edycja list dozwolonych gateway lub node + zasady pytań dla `exec host=gateway/node` (`exec.approvals.*`).
+    - Węzły: lista + możliwości (`node.list`).
+    - Zatwierdzenia exec: edycja list dozwolonych gateway lub węzła + zasady pytania dla `exec host=gateway/node` (`exec.approvals.*`).

  </Accordion>
-  <Accordion title="Config">
-    - Wyświetlanie/edycja `~/.openclaw/openclaw.json` (`config.get`, `config.set`).
-    - Zastosowanie + restart z walidacją (`config.apply`) i wybudzenie ostatniej aktywnej sesji.
-    - Zapisy obejmują strażnika skrótu bazowego, aby zapobiec nadpisaniu równoległych edycji.
-    - Zapisy (`config.set`/`config.apply`/`config.patch`) wykonują wstępną kontrolę rozwiązywania aktywnych SecretRef dla referencji w przesłanym ładunku konfiguracji; nierozwiązane aktywne przesłane referencje są odrzucane przed zapisem.
-    - Renderowanie schematu + formularza (`config.schema` / `config.schema.lookup`, w tym `title` / `description` pola, dopasowane wskazówki UI, natychmiastowe podsumowania elementów potomnych, metadane dokumentacji na zagnieżdżonych węzłach obiektów/wieloznacznych/tablic/kompozycji oraz schematy Plugin + kanałów, gdy są dostępne); edytor Raw JSON jest dostępny tylko wtedy, gdy migawka ma bezpieczny surowy obieg zwrotny.
-    - Jeśli migawka nie może bezpiecznie przejść surowego obiegu zwrotnego, Control UI wymusza tryb Formularza i wyłącza tryb Raw dla tej migawki.
-    - „Resetuj do zapisanego” w edytorze Raw JSON zachowuje surowo utworzony kształt (formatowanie, komentarze, układ `$include`) zamiast ponownie renderować spłaszczoną migawkę, dzięki czemu zewnętrzne edycje przetrwają reset, gdy migawka może bezpiecznie przejść obieg zwrotny.
-    - Strukturalne wartości obiektów SecretRef są renderowane jako tylko do odczytu w polach tekstowych formularza, aby zapobiec przypadkowemu uszkodzeniu przez konwersję obiektu na ciąg znaków.
+  <Accordion title="Konfiguracja">
+    - Wyświetl/edytuj `~/.openclaw/openclaw.json` (`config.get`, `config.set`).
+    - Zastosuj + uruchom ponownie z walidacją (`config.apply`) i wybudź ostatnią aktywną sesję.
+    - Zapisy obejmują zabezpieczenie bazowego hasha, aby zapobiec nadpisaniu równoległych edycji.
+    - Zapisy (`config.set`/`config.apply`/`config.patch`) wstępnie sprawdzają rozwiązywanie aktywnych SecretRef dla referencji w przesłanym ładunku konfiguracji; nierozwiązane aktywne przesłane referencje są odrzucane przed zapisem.
+    - Renderowanie schematu + formularza (`config.schema` / `config.schema.lookup`, w tym pola `title` / `description`, dopasowane wskazówki UI, podsumowania bezpośrednich elementów podrzędnych, metadane dokumentacji w zagnieżdżonych węzłach obiektów/wieloznacznych/tablic/kompozycji oraz schematy Plugin + kanałów, gdy są dostępne); surowy edytor JSON jest dostępny tylko wtedy, gdy migawka ma bezpieczny surowy obieg w obie strony.
+    - Jeśli migawka nie może bezpiecznie przejść surowego obiegu w obie strony, Control UI wymusza tryb formularza i wyłącza tryb surowy dla tej migawki.
+    - „Reset to saved” w surowym edytorze JSON zachowuje kształt utworzony w trybie surowym (formatowanie, komentarze, układ `$include`) zamiast ponownie renderować spłaszczoną migawkę, dzięki czemu zewnętrzne edycje przetrwają reset, gdy migawka może bezpiecznie przejść obieg w obie strony.
+    - Ustrukturyzowane wartości obiektów SecretRef są renderowane jako tylko do odczytu w tekstowych polach formularza, aby zapobiec przypadkowemu uszkodzeniu przez zmianę obiektu na ciąg znaków.

  </Accordion>
-  <Accordion title="Debug, logs, update">
+  <Accordion title="Debugowanie, logi, aktualizacja">
    - Debugowanie: migawki statusu/kondycji/modeli + dziennik zdarzeń + ręczne wywołania RPC (`status`, `health`, `models.list`).
-    - Logi: śledzenie na żywo logów plikowych gateway z filtrem/eksportem (`logs.tail`).
-    - Aktualizacja: uruchom aktualizację pakietu/git + restart (`update.run`) z raportem restartu, a następnie odpytuj `update.status` po ponownym połączeniu, aby zweryfikować wersję uruchomionego gateway.
+    - Logi: podgląd na żywo końca logów plikowych gateway z filtrowaniem/eksportem (`logs.tail`).
+    - Aktualizacja: uruchom aktualizację pakietu/git + restart (`update.run`) z raportem restartu, a następnie odpytuj `update.status` po ponownym połączeniu, aby zweryfikować działającą wersję gateway.

  </Accordion>
-  <Accordion title="Cron jobs panel notes">
-    - Dla zadań izolowanych dostarczanie domyślnie ogłasza podsumowanie. Możesz przełączyć na brak, jeśli chcesz uruchomienia tylko wewnętrzne.
-    - Pola kanału/celu pojawiają się, gdy wybrane jest ogłoszenie.
-    - Tryb Webhook używa `delivery.mode = "webhook"` z `delivery.to` ustawionym na prawidłowy adres URL Webhook HTTP(S).
+  <Accordion title="Uwagi do panelu zadań Cron">
+    - Dla zadań izolowanych dostarczanie domyślnie ogłasza podsumowanie. Możesz przełączyć na brak, jeśli chcesz uruchomienia wyłącznie wewnętrzne.
+    - Pola kanału/celu pojawiają się po wybraniu ogłaszania.
+    - Tryb Webhook używa `delivery.mode = "webhook"` z `delivery.to` ustawionym na prawidłowy adres URL HTTP(S) webhook.
    - Dla zadań sesji głównej dostępne są tryby dostarczania Webhook i brak.
-    - Zaawansowane kontrolki edycji obejmują usuwanie po uruchomieniu, czyszczenie nadpisania agenta, opcje dokładnego/rozłożonego Cron, nadpisania modelu/myślenia agenta oraz przełączniki dostarczania best-effort.
-    - Walidacja formularza jest liniowa, z błędami na poziomie pól; nieprawidłowe wartości wyłączają przycisk zapisu do czasu ich naprawienia.
-    - Ustaw `cron.webhookToken`, aby wysłać dedykowany token bearer; jeśli zostanie pominięty, Webhook zostanie wysłany bez nagłówka uwierzytelniania.
-    - Przestarzałe rozwiązanie awaryjne: zapisane starsze zadania z `notify: true` mogą nadal używać `cron.webhook` do czasu migracji.
+    - Zaawansowane kontrolki edycji obejmują usuwanie po uruchomieniu, czyszczenie nadpisania agenta, dokładne/rozłożone opcje cron, nadpisania modelu/myślenia agenta oraz przełączniki dostarczania w trybie najlepszych starań.
+    - Walidacja formularza jest wbudowana i pokazuje błędy na poziomie pól; nieprawidłowe wartości wyłączają przycisk zapisu do czasu naprawy.
+    - Ustaw `cron.webhookToken`, aby wysyłać dedykowany token bearer; jeśli zostanie pominięty, webhook zostanie wysłany bez nagłówka uwierzytelniania.
+    - Przestarzały fallback: zapisane starsze zadania z `notify: true` nadal mogą używać `cron.webhook` do czasu migracji.

  </Accordion>
 </AccordionGroup>
@ -154,54 +155,55 @@ Zaimportowane motywy są przechowywane tylko w bieżącym profilu przeglądarki.
 ## Zachowanie czatu

 <AccordionGroup>
-  <Accordion title="Send and history semantics">
+  <Accordion title="Semantyka wysyłania i historii">
    - `chat.send` jest **nieblokujące**: natychmiast potwierdza z `{ runId, status: "started" }`, a odpowiedź jest strumieniowana przez zdarzenia `chat`.
-    - Przesyłanie w czacie akceptuje obrazy oraz pliki inne niż wideo. Obrazy zachowują natywną ścieżkę obrazu; inne pliki są przechowywane jako zarządzane media i pokazywane w historii jako linki do załączników.
-    - Ponowne wysłanie z tym samym `idempotencyKey` zwraca `{ status: "in_flight" }` podczas działania oraz `{ status: "ok" }` po zakończeniu.
-    - Odpowiedzi `chat.history` mają ograniczony rozmiar ze względu na bezpieczeństwo UI. Gdy wpisy transkrypcji są zbyt duże, Gateway może skrócić długie pola tekstowe, pominąć ciężkie bloki metadanych i zastąpić zbyt duże wiadomości symbolem zastępczym (`[chat.history omitted: message too large]`).
-    - Obrazy asystenta/wygenerowane są utrwalane jako zarządzane odwołania do mediów i zwracane przez uwierzytelnione adresy URL mediów Gateway, więc ponowne wczytania nie zależą od tego, czy surowe ładunki obrazów base64 pozostaną w odpowiedzi historii czatu.
-    - `chat.history` usuwa też z widocznego tekstu asystenta wyłącznie prezentacyjne wbudowane tagi dyrektyw (na przykład `[[reply_to_*]]` i `[[audio_as_voice]]`), tekstowe ładunki XML wywołań narzędzi (w tym `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` oraz skrócone bloki wywołań narzędzi), a także ujawnione tokeny sterujące modelu ASCII/pełnej szerokości, oraz pomija wpisy asystenta, których cały widoczny tekst jest wyłącznie dokładnym tokenem ciszy `NO_REPLY` / `no_reply`.
-    - Podczas aktywnego wysyłania i końcowego odświeżenia historii widok czatu utrzymuje widoczne lokalne optymistyczne wiadomości użytkownika/asystenta, jeśli `chat.history` krótko zwraca starszą migawkę; kanoniczna transkrypcja zastępuje te lokalne wiadomości, gdy historia Gateway nadrobi zaległość.
-    - `chat.inject` dołącza notatkę asystenta do transkrypcji sesji i rozgłasza zdarzenie `chat` na potrzeby aktualizacji wyłącznie w UI (bez uruchomienia agenta i bez dostarczenia kanałowego).
-    - Selektory modelu i myślenia w nagłówku czatu natychmiast aktualizują aktywną sesję przez `sessions.patch`; są to trwałe nadpisania sesji, a nie opcje wysyłania tylko na jedną turę.
-    - Wpisanie `/new` w Control UI tworzy i przełącza na tę samą świeżą sesję pulpitu co Nowy czat. Wpisanie `/reset` zachowuje jawny reset w miejscu Gateway dla bieżącej sesji.
-    - Selektor modelu czatu żąda skonfigurowanego widoku modeli Gateway. Jeśli istnieje `agents.defaults.models`, ta lista dozwolonych wartości steruje selektorem. W przeciwnym razie selektor pokazuje jawne wpisy `models.providers.*.models` oraz dostawców z użytecznym uwierzytelnianiem. Pełny katalog pozostaje dostępny przez debugujące RPC `models.list` z `view: "all"`.
-    - Gdy świeże raporty użycia sesji Gateway pokazują wysoką presję kontekstu, obszar kompozytora czatu pokazuje powiadomienie kontekstowe, a przy zalecanych poziomach Compaction także kompaktowy przycisk uruchamiający normalną ścieżkę Compaction sesji. Nieaktualne migawki tokenów są ukrywane, dopóki Gateway ponownie nie zgłosi świeżego użycia.
+    - `chat.transcribeAudio` to jednorazowy pomocnik dyktowania dla wersji roboczych czatu. Przyjmuje nagrany w przeglądarce dźwięk base64, utrzymuje przesyłane dane poniżej limitu ramki WebSocket Gateway, zapisuje tymczasowy plik lokalny, uruchamia transkrypcję dźwięku z rozumieniem multimediów z aktywną konfiguracją Gateway, zwraca `{ text, provider, model }` i usuwa plik tymczasowy. Nie tworzy uruchomienia agenta i jest oddzielne od Talk w czasie rzeczywistym.
+    - Przesyłanie do czatu akceptuje obrazy oraz pliki inne niż wideo. Obrazy zachowują natywną ścieżkę obrazu; inne pliki są przechowywane jako zarządzane multimedia i pokazywane w historii jako linki załączników.
+    - Ponowne wysłanie z tym samym `idempotencyKey` zwraca `{ status: "in_flight" }` podczas działania oraz `{ status: "ok" }` po ukończeniu.
+    - Odpowiedzi `chat.history` są ograniczone rozmiarem dla bezpieczeństwa UI. Gdy wpisy transkrypcji są zbyt duże, Gateway może skracać długie pola tekstowe, pomijać ciężkie bloki metadanych i zastępować zbyt duże wiadomości symbolem zastępczym (`[chat.history omitted: message too large]`).
+    - Obrazy asystenta/wygenerowane są utrwalane jako zarządzane odwołania do multimediów i udostępniane z powrotem przez uwierzytelnione adresy URL multimediów Gateway, więc ponowne załadowania nie zależą od tego, czy surowe ładunki obrazów base64 pozostaną w odpowiedzi historii czatu.
+    - `chat.history` usuwa także z widocznego tekstu asystenta tylko-wyświetleniowe znaczniki dyrektyw inline (na przykład `[[reply_to_*]]` i `[[audio_as_voice]]`), zwykłotekstowe ładunki XML wywołań narzędzi (w tym `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` oraz skrócone bloki wywołań narzędzi), ujawnione tokeny sterujące modelu ASCII/pełnej szerokości, a także pomija wpisy asystenta, których cały widoczny tekst to wyłącznie dokładny cichy token `NO_REPLY` / `no_reply`.
+    - Podczas aktywnego wysyłania i końcowego odświeżania historii widok czatu utrzymuje lokalne optymistyczne wiadomości użytkownika/asystenta widoczne, jeśli `chat.history` na chwilę zwróci starszą migawkę; kanoniczna transkrypcja zastępuje te lokalne wiadomości, gdy historia Gateway nadrobi zaległości.
+    - `chat.inject` dodaje notatkę asystenta do transkrypcji sesji i rozgłasza zdarzenie `chat` dla aktualizacji wyłącznie UI (bez uruchomienia agenta, bez dostarczenia kanałem).
+    - Selektory modelu i myślenia w nagłówku czatu natychmiast aktualizują aktywną sesję przez `sessions.patch`; są trwałymi nadpisaniami sesji, a nie opcjami wysłania tylko dla jednej tury.
+    - Wpisanie `/new` w Control UI tworzy i przełącza na taką samą świeżą sesję pulpitu jak New Chat. Wpisanie `/reset` zachowuje jawne resetowanie w miejscu przez Gateway dla bieżącej sesji.
+    - Selektor modelu czatu żąda skonfigurowanego widoku modeli Gateway. Jeśli `agents.defaults.models` jest obecne, ta lista dozwolonych modeli steruje selektorem. W przeciwnym razie selektor pokazuje jawne wpisy `models.providers.*.models` oraz dostawców z użytecznym uwierzytelnieniem. Pełny katalog pozostaje dostępny przez debugowe RPC `models.list` z `view: "all"`.
+    - Gdy świeże raporty użycia sesji Gateway pokazują wysoką presję kontekstu, obszar kompozytora czatu pokazuje powiadomienie o kontekście, a przy zalecanych poziomach Compaction przycisk kompaktowania, który uruchamia normalną ścieżkę Compaction sesji. Nieaktualne migawki tokenów są ukrywane, dopóki Gateway ponownie nie zgłosi świeżego użycia.

  </Accordion>
-  <Accordion title="Talk mode (browser realtime)">
-    Tryb rozmowy używa zarejestrowanego dostawcy głosu w czasie rzeczywistym. Skonfiguruj OpenAI za pomocą `talk.provider: "openai"` oraz `talk.providers.openai.apiKey` albo skonfiguruj Google za pomocą `talk.provider: "google"` oraz `talk.providers.google.apiKey`; konfiguracja dostawcy czasu rzeczywistego Voice Call może nadal zostać ponownie użyta jako awaryjna. Przeglądarka nigdy nie otrzymuje standardowego klucza API dostawcy. OpenAI otrzymuje efemeryczny sekret klienta Realtime dla WebRTC. Google Live otrzymuje jednorazowy ograniczony token uwierzytelniania Live API dla sesji WebSocket przeglądarki, z instrukcjami i deklaracjami narzędzi zablokowanymi w tokenie przez Gateway. Dostawcy, którzy udostępniają tylko backendowy most czasu rzeczywistego, działają przez transport przekaźnikowy Gateway, więc poświadczenia i gniazda dostawcy pozostają po stronie serwera, podczas gdy dźwięk przeglądarki przechodzi przez uwierzytelnione RPC Gateway. Prompt sesji Realtime jest składany przez Gateway; `talk.realtime.session` nie akceptuje nadpisań instrukcji dostarczanych przez wywołującego.
+  <Accordion title="Tryb Talk (przeglądarka w czasie rzeczywistym)">
+    Tryb Talk używa zarejestrowanego dostawcy głosu w czasie rzeczywistym. Skonfiguruj OpenAI z `talk.provider: "openai"` oraz `talk.providers.openai.apiKey`, albo skonfiguruj Google z `talk.provider: "google"` oraz `talk.providers.google.apiKey`; konfiguracja dostawcy czasu rzeczywistego Voice Call nadal może być użyta jako fallback. Przeglądarka nigdy nie otrzymuje standardowego klucza API dostawcy. OpenAI otrzymuje efemeryczny sekret klienta Realtime dla WebRTC. Google Live otrzymuje jednorazowy, ograniczony token uwierzytelniania Live API dla sesji WebSocket przeglądarki, z instrukcjami i deklaracjami narzędzi zablokowanymi w tokenie przez Gateway. Dostawcy, którzy udostępniają tylko backendowy most czasu rzeczywistego, działają przez transport przekaźnikowy Gateway, więc poświadczenia i gniazda dostawców pozostają po stronie serwera, podczas gdy dźwięk przeglądarki przechodzi przez uwierzytelnione RPC Gateway. Prompt sesji Realtime jest składany przez Gateway; `talk.realtime.session` nie akceptuje dostarczonych przez wywołującego nadpisań instrukcji.

-    W kompozytorze czatu kontrolka Rozmowa to przycisk z falami obok przycisku dyktowania mikrofonem. Po rozpoczęciu rozmowy wiersz stanu kompozytora pokazuje `Connecting Talk...`, następnie `Talk live`, gdy dźwięk jest połączony, albo `Asking OpenClaw...`, gdy wywołanie narzędzia czasu rzeczywistego konsultuje skonfigurowany większy model przez `chat.send`.
+    W kompozytorze czatu kontrolka Talk to przycisk z falami obok przycisku dyktowania mikrofonem. Gdy Talk się uruchamia, wiersz statusu kompozytora pokazuje `Connecting Talk...`, następnie `Talk live`, gdy dźwięk jest połączony, albo `Asking OpenClaw...`, gdy wywołanie narzędzia czasu rzeczywistego konsultuje skonfigurowany większy model przez `chat.send`.

-    Test dymny na żywo dla opiekunów: `OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts` weryfikuje wymianę SDP WebRTC przeglądarki OpenAI, konfigurację WebSocket przeglądarki Google Live z ograniczonym tokenem oraz adapter przeglądarki przekaźnika Gateway z fałszywym nośnikiem mikrofonu. Polecenie wypisuje tylko status dostawcy i nie zapisuje sekretów w logach.
+    Test dymny live dla maintainerów: `OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts` weryfikuje wymianę SDP OpenAI WebRTC w przeglądarce, konfigurację ograniczonego tokenu Google Live dla WebSocket przeglądarki oraz adapter przeglądarkowy przekaźnika Gateway z fałszywymi multimediami mikrofonu. Polecenie wypisuje tylko status dostawcy i nie loguje sekretów.

  </Accordion>
-  <Accordion title="Stop and abort">
+  <Accordion title="Zatrzymanie i przerwanie">
    - Kliknij **Stop** (wywołuje `chat.abort`).
-    - Gdy uruchomienie jest aktywne, zwykłe kolejne wiadomości trafiają do kolejki. Kliknij **Steer** przy wiadomości w kolejce, aby wstrzyknąć tę kolejną wiadomość do trwającej tury.
+    - Gdy uruchomienie jest aktywne, zwykłe dalsze wiadomości trafiają do kolejki. Kliknij **Steer** na zakolejkowanej wiadomości, aby wstrzyknąć tę dalszą wiadomość do działającej tury.
    - Wpisz `/stop` (lub samodzielne frazy przerwania, takie jak `stop`, `stop action`, `stop run`, `stop openclaw`, `please stop`), aby przerwać poza pasmem.
    - `chat.abort` obsługuje `{ sessionKey }` (bez `runId`), aby przerwać wszystkie aktywne uruchomienia dla tej sesji.

  </Accordion>
-  <Accordion title="Abort partial retention">
-    - Gdy uruchomienie zostanie przerwane, częściowy tekst asystenta może nadal być pokazywany w UI.
-    - Gateway utrwala przerwany częściowy tekst asystenta w historii transkrypcji, gdy istnieje buforowane wyjście.
-    - Utrwalone wpisy zawierają metadane przerwania, aby konsumenci transkrypcji mogli odróżnić częściowe wyniki przerwania od zwykłego wyjścia ukończenia.
+  <Accordion title="Zachowanie częściowej treści po przerwaniu">
+    - Gdy uruchomienie zostanie przerwane, częściowy tekst asystenta nadal może być pokazywany w UI.
+    - Gateway utrwala przerwany częściowy tekst asystenta w historii transkrypcji, gdy istnieje zbuforowane wyjście.
+    - Utrwalone wpisy zawierają metadane przerwania, aby konsumenci transkrypcji mogli odróżnić częściowe treści przerwania od normalnego wyjścia ukończenia.

  </Accordion>
 </AccordionGroup>

-## Instalacja PWA i Web Push
+## Instalacja PWA i web push

-Control UI dostarcza `manifest.webmanifest` oraz service worker, więc nowoczesne przeglądarki mogą zainstalować go jako samodzielną PWA. Web Push pozwala Gateway wybudzić zainstalowaną PWA powiadomieniami nawet wtedy, gdy karta lub okno przeglądarki nie jest otwarte.
+Control UI dostarcza `manifest.webmanifest` i service worker, więc nowoczesne przeglądarki mogą zainstalować go jako samodzielną PWA. Web Push pozwala Gateway wybudzić zainstalowaną PWA powiadomieniami nawet wtedy, gdy karta lub okno przeglądarki nie są otwarte.

-| Powierzchnia                                           | Co robi                                                            |
+| Powierzchnia                                          | Co robi                                                            |
 | ----------------------------------------------------- | ------------------------------------------------------------------ |
-| `ui/public/manifest.webmanifest`                      | Manifest PWA. Przeglądarki oferują „Zainstaluj aplikację”, gdy stanie się osiągalny. |
+| `ui/public/manifest.webmanifest`                      | Manifest PWA. Przeglądarki oferują „Install app”, gdy staje się osiągalny. |
 | `ui/public/sw.js`                                     | Service worker obsługujący zdarzenia `push` i kliknięcia powiadomień. |
-| `push/vapid-keys.json` (w katalogu stanu OpenClaw) | Automatycznie wygenerowana para kluczy VAPID używana do podpisywania ładunków Web Push. |
-| `push/web-push-subscriptions.json`                    | Utrwalone punkty końcowe subskrypcji przeglądarki.                 |
+| `push/vapid-keys.json` (w katalogu stanu OpenClaw)    | Automatycznie wygenerowana para kluczy VAPID używana do podpisywania ładunków Web Push. |
+| `push/web-push-subscriptions.json`                    | Utrwalone endpointy subskrypcji przeglądarki.                      |

 Nadpisz parę kluczy VAPID przez zmienne środowiskowe w procesie Gateway, gdy chcesz przypiąć klucze (dla wdrożeń wielohostowych, rotacji sekretów lub testów):

@ -213,23 +215,23 @@ Control UI używa tych metod Gateway ograniczonych zakresem do rejestrowania i t

 - `push.web.vapidPublicKey` — pobiera aktywny klucz publiczny VAPID.
 - `push.web.subscribe` — rejestruje `endpoint` oraz `keys.p256dh`/`keys.auth`.
- `push.web.unsubscribe` — usuwa zarejestrowany punkt końcowy.
- `push.web.test` — wysyła testowe powiadomienie do subskrypcji wywołującego.
+- `push.web.unsubscribe` — usuwa zarejestrowany endpoint.
+- `push.web.test` — wysyła powiadomienie testowe do subskrypcji wywołującego.

 <Note>
-Web Push jest niezależny od ścieżki przekaźnika iOS APNS (zobacz [Konfiguracja](/pl/gateway/configuration) dla powiadomień push opartych na przekaźniku) oraz istniejącej metody `push.test`, które są przeznaczone dla natywnego parowania mobilnego.
+Web Push jest niezależny od ścieżki przekaźnika APNS iOS (zobacz [Konfiguracja](/pl/gateway/configuration) dla push opartego na przekaźniku) oraz istniejącej metody `push.test`, które celują w natywne parowanie mobilne.
 </Note>

-## Hostowane osadzenia
+## Osadzenia hostowane

-Wiadomości asystenta mogą renderować hostowane treści internetowe w wierszu za pomocą krótkiego kodu `[embed ...]`. Polityka piaskownicy iframe jest kontrolowana przez `gateway.controlUi.embedSandbox`:
+Wiadomości asystenta mogą renderować hostowane treści internetowe inline za pomocą shortcode `[embed ...]`. Polityka sandbox iframe jest kontrolowana przez `gateway.controlUi.embedSandbox`:

 <Tabs>
  <Tab title="strict">
    Wyłącza wykonywanie skryptów wewnątrz hostowanych osadzeń.
  </Tab>
  <Tab title="scripts (default)">
-    Pozwala na interaktywne osadzenia przy zachowaniu izolacji origin; to ustawienie domyślne i zwykle wystarcza dla samodzielnych gier/widgetów przeglądarkowych.
+    Zezwala na interaktywne osadzenia przy zachowaniu izolacji origin; jest to wartość domyślna i zwykle wystarcza dla samodzielnych gier/widgetów przeglądarkowych.
  </Tab>
  <Tab title="trusted">
    Dodaje `allow-same-origin` oprócz `allow-scripts` dla dokumentów w tej samej witrynie, które celowo potrzebują silniejszych uprawnień.
@ -249,14 +251,14 @@ Przykład:
 ```

 <Warning>
-Używaj `trusted` tylko wtedy, gdy osadzony dokument rzeczywiście potrzebuje zachowania same-origin. Dla większości gier generowanych przez agentów i interaktywnych płócien bezpieczniejszym wyborem jest `scripts`.
+Używaj `trusted` tylko wtedy, gdy osadzony dokument rzeczywiście potrzebuje zachowania same-origin. Dla większości gier generowanych przez agentów i interaktywnych płócien `scripts` jest bezpieczniejszym wyborem.
 </Warning>

-Bezwzględne zewnętrzne adresy URL osadzeń `http(s)` pozostają domyślnie blokowane. Jeśli celowo chcesz, aby `[embed url="https://..."]` ładowało strony zewnętrzne, ustaw `gateway.controlUi.allowExternalEmbedUrls: true`.
+Bezwzględne zewnętrzne adresy URL osadzeń `http(s)` pozostają domyślnie blokowane. Jeśli celowo chcesz, aby `[embed url="https://..."]` ładował strony zewnętrzne, ustaw `gateway.controlUi.allowExternalEmbedUrls: true`.

 ## Szerokość wiadomości czatu

-Zgrupowane wiadomości czatu używają czytelnej domyślnej maksymalnej szerokości. Wdrożenia na szerokich monitorach mogą ją nadpisać bez łatania dołączonego CSS, ustawiając `gateway.controlUi.chatMessageMaxWidth`:
+Zgrupowane wiadomości czatu używają czytelnej domyślnej maksymalnej szerokości. Wdrożenia na szerokich monitorach mogą ją nadpisać bez łatania dołączonego CSS przez ustawienie `gateway.controlUi.chatMessageMaxWidth`:

 ```json5
 {
@ -268,13 +270,13 @@ Zgrupowane wiadomości czatu używają czytelnej domyślnej maksymalnej szeroko
 }
 ```

-Wartość jest walidowana, zanim trafi do przeglądarki. Obsługiwane wartości obejmują proste długości i procenty, takie jak `960px` lub `82%`, oraz ograniczone wyrażenia szerokości `min(...)`, `max(...)`, `clamp(...)`, `calc(...)` i `fit-content(...)`.
+Wartość jest walidowana, zanim dotrze do przeglądarki. Obsługiwane wartości obejmują proste długości i procenty, takie jak `960px` lub `82%`, oraz ograniczone wyrażenia szerokości `min(...)`, `max(...)`, `clamp(...)`, `calc(...)` i `fit-content(...)`.

 ## Dostęp przez tailnet (zalecane)

 <Tabs>
-  <Tab title="Integrated Tailscale Serve (preferred)">
-    Utrzymuj Gateway na loopback i pozwól Tailscale Serve pośredniczyć z HTTPS:
+  <Tab title="Zintegrowane Tailscale Serve (preferowane)">
+    Utrzymaj Gateway na loopback i pozwól Tailscale Serve pośredniczyć przez HTTPS:

    ```bash
    openclaw gateway --tailscale serve
@ -282,27 +284,27 @@ Wartość jest walidowana, zanim trafi do przeglądarki. Obsługiwane wartości

    Otwórz:

-    - `https://<magicdns>/` (lub skonfigurowany `gateway.controlUi.basePath`)
+    - `https://<magicdns>/` (lub skonfigurowane `gateway.controlUi.basePath`)

-    Domyślnie żądania Control UI/WebSocket Serve mogą uwierzytelniać się przez nagłówki tożsamości Tailscale (`tailscale-user-login`), gdy `gateway.auth.allowTailscale` ma wartość `true`. OpenClaw weryfikuje tożsamość, rozwiązując adres `x-forwarded-for` za pomocą `tailscale whois` i dopasowując go do nagłówka, oraz akceptuje je tylko wtedy, gdy żądanie trafia na loopback z nagłówkami `x-forwarded-*` Tailscale. W przypadku sesji operatora Control UI z tożsamością urządzenia przeglądarki ta zweryfikowana ścieżka Serve pomija również rundę parowania urządzenia; przeglądarki bez urządzenia i połączenia w roli węzła nadal przechodzą normalne kontrole urządzeń. Ustaw `gateway.auth.allowTailscale: false`, jeśli chcesz wymagać jawnych poświadczeń współdzielonego sekretu nawet dla ruchu Serve. Następnie użyj `gateway.auth.mode: "token"` lub `"password"`.
+    Domyślnie żądania Control UI/WebSocket Serve mogą uwierzytelniać się przez nagłówki tożsamości Tailscale (`tailscale-user-login`), gdy `gateway.auth.allowTailscale` ma wartość `true`. OpenClaw weryfikuje tożsamość, rozwiązując adres `x-forwarded-for` za pomocą `tailscale whois` i dopasowując go do nagłówka, oraz akceptuje je tylko wtedy, gdy żądanie trafia na loopback z nagłówkami `x-forwarded-*` Tailscale. Dla sesji operatora Control UI z tożsamością urządzenia przeglądarki ta zweryfikowana ścieżka Serve pomija także rundę parowania urządzenia; przeglądarki bez urządzenia i połączenia roli węzła nadal przechodzą normalne kontrole urządzeń. Ustaw `gateway.auth.allowTailscale: false`, jeśli chcesz wymagać jawnych poświadczeń wspólnego sekretu nawet dla ruchu Serve. Następnie użyj `gateway.auth.mode: "token"` lub `"password"`.

-    Dla tej asynchronicznej ścieżki tożsamości Serve nieudane próby uwierzytelnienia dla tego samego adresu IP klienta i zakresu uwierzytelniania są serializowane przed zapisami limitu szybkości. Współbieżne nieudane ponowienia z tej samej przeglądarki mogą więc pokazać `retry later` przy drugim żądaniu zamiast dwóch zwykłych niedopasowań ścigających się równolegle.
+    Dla tej asynchronicznej ścieżki tożsamości Serve nieudane próby uwierzytelnienia dla tego samego adresu IP klienta i zakresu uwierzytelniania są serializowane przed zapisami limitu szybkości. Współbieżne błędne ponowienia z tej samej przeglądarki mogą więc pokazać `retry later` przy drugim żądaniu zamiast dwóch zwykłych niedopasowań ścigających się równolegle.

    <Warning>
-    Uwierzytelnianie Serve bez tokena zakłada, że host Gateway jest zaufany. Jeśli na tym hoście może działać niezaufany kod lokalny, wymagaj uwierzytelniania tokenem/hasłem.
+    Uwierzytelnianie Serve bez tokenu zakłada, że host gateway jest zaufany. Jeśli niezaufany lokalny kod może działać na tym hoście, wymagaj uwierzytelniania tokenem/hasłem.
    </Warning>

  </Tab>
-  <Tab title="Bind to tailnet + token">
+  <Tab title="Powiąż z tailnet + token">
    ```bash
    openclaw gateway --bind tailnet --token "$(openssl rand -hex 32)"
    ```

    Następnie otwórz:

-    - `http://<tailscale-ip>:18789/` (lub skonfigurowany `gateway.controlUi.basePath`)
+    - `http://<tailscale-ip>:18789/` (lub skonfigurowane `gateway.controlUi.basePath`)

-    Wklej pasujący współdzielony sekret w ustawieniach UI (wysyłany jako `connect.params.auth.token` lub `connect.params.auth.password`).
+    Wklej pasujący wspólny sekret w ustawieniach UI (wysyłany jako `connect.params.auth.token` lub `connect.params.auth.password`).

  </Tab>
 </Tabs>
@ -313,17 +315,17 @@ Jeśli otworzysz pulpit przez zwykły HTTP (`http://<lan-ip>` lub `http://<tails

 Udokumentowane wyjątki:

- zgodność niezabezpieczonego HTTP tylko dla localhost z `gateway.controlUi.allowInsecureAuth=true`
+- zgodność z niezabezpieczonym HTTP tylko dla localhost z `gateway.controlUi.allowInsecureAuth=true`
 - pomyślne uwierzytelnianie operatora Control UI przez `gateway.auth.mode: "trusted-proxy"`
 - awaryjne `gateway.controlUi.dangerouslyDisableDeviceAuth=true`

 **Zalecana poprawka:** użyj HTTPS (Tailscale Serve) albo otwórz UI lokalnie:

 - `https://<magicdns>/` (Serve)
- `http://127.0.0.1:18789/` (na hoście Gateway)
+- `http://127.0.0.1:18789/` (na hoście gateway)

 <AccordionGroup>
-  <Accordion title="Zachowanie przełącznika insecure-auth">
+  <Accordion title="Zachowanie przełącznika niebezpiecznego uwierzytelniania">
    ```json5
    {
      gateway: {
@ -336,12 +338,12 @@ Udokumentowane wyjątki:

    `allowInsecureAuth` to wyłącznie lokalny przełącznik zgodności:

-    - Pozwala sesjom Control UI na localhost kontynuować bez tożsamości urządzenia w niezabezpieczonych kontekstach HTTP.
+    - Pozwala sesjom localhost Control UI działać bez tożsamości urządzenia w niezabezpieczonych kontekstach HTTP.
    - Nie omija kontroli parowania.
-    - Nie łagodzi wymagań dotyczących tożsamości urządzenia zdalnego (nie-localhost).
+    - Nie łagodzi wymagań dotyczących tożsamości urządzenia zdalnego (innego niż localhost).

  </Accordion>
-  <Accordion title="Tylko tryb awaryjny">
+  <Accordion title="Tylko awaryjnie">
    ```json5
    {
      gateway: {
@ -353,14 +355,14 @@ Udokumentowane wyjątki:
    ```

    <Warning>
-    `dangerouslyDisableDeviceAuth` wyłącza kontrole tożsamości urządzenia Control UI i stanowi poważne obniżenie poziomu bezpieczeństwa. Przywróć poprzednie ustawienie szybko po użyciu awaryjnym.
+    `dangerouslyDisableDeviceAuth` wyłącza kontrole tożsamości urządzenia Control UI i jest poważnym obniżeniem poziomu bezpieczeństwa. Cofnij tę zmianę szybko po użyciu awaryjnym.
    </Warning>

  </Accordion>
-  <Accordion title="Uwaga o zaufanym proxy">
-    - Udane uwierzytelnianie przez zaufane proxy może dopuścić sesje Control UI **operatora** bez tożsamości urządzenia.
-    - Nie obejmuje to sesji Control UI z rolą węzła.
-    - Zwrotne proxy odwrotne na tym samym hoście nadal nie spełniają wymagań uwierzytelniania przez zaufane proxy; zobacz [Uwierzytelnianie przez zaufane proxy](/pl/gateway/trusted-proxy-auth).
+  <Accordion title="Uwaga o trusted-proxy">
+    - Pomyślne uwierzytelnianie trusted-proxy może dopuścić **operatorskie** sesje Control UI bez tożsamości urządzenia.
+    - To **nie** obejmuje sesji Control UI w roli node.
+    - Zwrotne serwery proxy na tym samym hoście nadal nie spełniają warunków uwierzytelniania trusted-proxy; zobacz [Uwierzytelnianie przez zaufany serwer proxy](/pl/gateway/trusted-proxy-auth).

  </Accordion>
 </AccordionGroup>
@ -369,52 +371,52 @@ Zobacz [Tailscale](/pl/gateway/tailscale), aby uzyskać wskazówki dotyczące ko

 ## Polityka bezpieczeństwa treści

-Control UI jest dostarczany z restrykcyjną polityką `img-src`: dozwolone są tylko zasoby **same-origin**, adresy URL `data:` oraz lokalnie generowane adresy URL `blob:`. Zdalne adresy URL obrazów `http(s)` i względne względem protokołu są odrzucane przez przeglądarkę i nie powodują żądań sieciowych.
+Control UI jest dostarczany ze ścisłą polityką `img-src`: dozwolone są tylko zasoby **tego samego origin**, adresy URL `data:` oraz lokalnie wygenerowane adresy URL `blob:`. Zdalne adresy URL obrazów `http(s)` i zależne od protokołu są odrzucane przez przeglądarkę i nie powodują pobierania przez sieć.

 Co to oznacza w praktyce:

- Awatary i obrazy serwowane pod ścieżkami względnymi (na przykład `/avatars/<id>`) nadal się renderują, w tym uwierzytelnione trasy awatarów, które UI pobiera i konwertuje na lokalne adresy URL `blob:`.
- Wbudowane adresy URL `data:image/...` nadal się renderują (przydatne dla ładunków w protokole).
- Lokalne adresy URL `blob:` utworzone przez Control UI nadal się renderują.
+- Awatary i obrazy udostępniane pod ścieżkami względnymi (na przykład `/avatars/<id>`) nadal są renderowane, w tym uwierzytelnione trasy awatarów, które UI pobiera i konwertuje na lokalne adresy URL `blob:`.
+- Wbudowane adresy URL `data:image/...` nadal są renderowane (przydatne dla ładunków w protokole).
+- Lokalne adresy URL `blob:` utworzone przez Control UI nadal są renderowane.
 - Zdalne adresy URL awatarów emitowane przez metadane kanału są usuwane w helperach awatarów Control UI i zastępowane wbudowanym logo/znaczkiem, więc przejęty lub złośliwy kanał nie może wymusić dowolnych zdalnych pobrań obrazów z przeglądarki operatora.

-Nie musisz niczego zmieniać, aby uzyskać to zachowanie — jest ono zawsze włączone i nie można go konfigurować.
+Nie musisz niczego zmieniać, aby uzyskać to zachowanie — jest zawsze włączone i nie można go skonfigurować.

 ## Uwierzytelnianie trasy awatara

-Gdy uwierzytelnianie gateway jest skonfigurowane, punkt końcowy awatara Control UI wymaga tego samego tokena gateway co reszta API:
+Gdy uwierzytelnianie gateway jest skonfigurowane, endpoint awatara Control UI wymaga tego samego tokenu gateway co reszta API:

 - `GET /avatar/<agentId>` zwraca obraz awatara tylko uwierzytelnionym wywołującym. `GET /avatar/<agentId>?meta=1` zwraca metadane awatara według tej samej reguły.
- Nieuwierzytelnione żądania do dowolnej z tych tras są odrzucane (tak samo jak sąsiednia trasa assistant-media). Zapobiega to wyciekowi tożsamości agenta przez trasę awatara na hostach, które poza tym są chronione.
+- Nieuwierzytelnione żądania do którejkolwiek trasy są odrzucane (tak jak w pokrewnej trasie assistant-media). Zapobiega to ujawnianiu tożsamości agenta przez trasę awatara na hostach, które poza tym są chronione.
 - Sam Control UI przekazuje token gateway jako nagłówek bearer podczas pobierania awatarów i używa uwierzytelnionych adresów URL blob, dzięki czemu obraz nadal renderuje się w dashboardach.

-Jeśli wyłączysz uwierzytelnianie gateway (niezalecane na współdzielonych hostach), trasa awatara również stanie się nieuwierzytelniona, zgodnie z resztą gateway.
+Jeśli wyłączysz uwierzytelnianie gateway (niezalecane na hostach współdzielonych), trasa awatara również stanie się nieuwierzytelniona, zgodnie z resztą gateway.

 ## Budowanie UI

-Gateway serwuje pliki statyczne z `dist/control-ui`. Zbuduj je za pomocą:
+Gateway udostępnia pliki statyczne z `dist/control-ui`. Zbuduj je za pomocą:

 ```bash
 pnpm ui:build
 ```

-Opcjonalna bezwzględna baza (gdy chcesz mieć stałe adresy URL zasobów):
+Opcjonalna bezwzględna baza (gdy chcesz stałych adresów URL zasobów):

 ```bash
 OPENCLAW_CONTROL_UI_BASE_PATH=/openclaw/ pnpm ui:build
 ```

-Do lokalnego developmentu (oddzielny serwer deweloperski):
+Do rozwoju lokalnego (oddzielny serwer deweloperski):

 ```bash
 pnpm ui:dev
 ```

-Następnie skieruj UI na adres URL WS swojego Gateway (np. `ws://127.0.0.1:18789`).
+Następnie skieruj UI na URL WS swojego Gateway (np. `ws://127.0.0.1:18789`).

 ## Debugowanie/testowanie: serwer deweloperski + zdalny Gateway

-Control UI to pliki statyczne; cel WebSocket jest konfigurowalny i może różnić się od origin HTTP. To przydatne, gdy chcesz uruchomić lokalnie serwer deweloperski Vite, ale Gateway działa gdzie indziej.
+Control UI to pliki statyczne; cel WebSocket jest konfigurowalny i może różnić się od origin HTTP. Jest to przydatne, gdy chcesz uruchomić lokalnie serwer deweloperski Vite, ale Gateway działa gdzie indziej.

 <Steps>
  <Step title="Uruchom serwer deweloperski UI">
@ -427,7 +429,7 @@ Control UI to pliki statyczne; cel WebSocket jest konfigurowalny i może różni
    http://localhost:5173/?gatewayUrl=ws%3A%2F%2F<gateway-host>%3A18789
    ```

-    Opcjonalne jednorazowe uwierzytelnienie (jeśli potrzebne):
+    Opcjonalne jednorazowe uwierzytelnianie (jeśli potrzebne):

    ```text
    http://localhost:5173/?gatewayUrl=wss%3A%2F%2F<gateway-host>%3A18789#token=<gateway-token>
@ -439,15 +441,15 @@ Control UI to pliki statyczne; cel WebSocket jest konfigurowalny i może różni
 <AccordionGroup>
  <Accordion title="Uwagi">
    - `gatewayUrl` jest zapisywany w localStorage po załadowaniu i usuwany z adresu URL.
-    - Jeśli przekazujesz pełny punkt końcowy `ws://` lub `wss://` przez `gatewayUrl`, zakoduj wartość `gatewayUrl` w URL, aby przeglądarka poprawnie sparsowała ciąg zapytania.
-    - `token` należy przekazywać przez fragment adresu URL (`#token=...`), gdy tylko jest to możliwe. Fragmenty nie są wysyłane na serwer, co pozwala uniknąć wycieku przez logi żądań i Referer. Starsze parametry zapytania `?token=` nadal są importowane jednorazowo dla zgodności, ale tylko jako rozwiązanie awaryjne, i są usuwane natychmiast po bootstrapie.
+    - Jeśli przekazujesz pełny endpoint `ws://` lub `wss://` przez `gatewayUrl`, zakoduj wartość `gatewayUrl` jako URL, aby przeglądarka poprawnie przeanalizowała ciąg zapytania.
+    - `token` należy przekazywać przez fragment URL (`#token=...`), kiedy tylko jest to możliwe. Fragmenty nie są wysyłane na serwer, co pozwala uniknąć wycieku w logach żądań i nagłówku Referer. Starsze parametry zapytania `?token=` nadal są jednorazowo importowane ze względu na zgodność, ale tylko jako rozwiązanie awaryjne, i są usuwane natychmiast po bootstrapie.
    - `password` jest przechowywane tylko w pamięci.
-    - Gdy `gatewayUrl` jest ustawiony, UI nie wraca do danych uwierzytelniających z konfiguracji ani środowiska. Podaj `token` (lub `password`) jawnie. Brak jawnych danych uwierzytelniających jest błędem.
-    - Użyj `wss://`, gdy Gateway znajduje się za TLS (Tailscale Serve, proxy HTTPS itp.).
+    - Gdy `gatewayUrl` jest ustawiony, UI nie wraca do danych uwierzytelniających z konfiguracji ani środowiska. Podaj jawnie `token` (lub `password`). Brak jawnych danych uwierzytelniających jest błędem.
+    - Użyj `wss://`, gdy Gateway znajduje się za TLS (Tailscale Serve, proxy HTTPS itd.).
    - `gatewayUrl` jest akceptowany tylko w oknie najwyższego poziomu (nie osadzonym), aby zapobiec clickjackingowi.
-    - Wdrożenia Control UI poza local loopback muszą jawnie ustawić `gateway.controlUi.allowedOrigins` (pełne origin). Dotyczy to również zdalnych konfiguracji deweloperskich.
-    - Start Gateway może zainicjować lokalne origin, takie jak `http://localhost:<port>` i `http://127.0.0.1:<port>`, na podstawie efektywnego runtime bind i portu, ale zdalne origin przeglądarki nadal wymagają jawnych wpisów.
-    - Nie używaj `gateway.controlUi.allowedOrigins: ["*"]` poza ściśle kontrolowanym lokalnym testowaniem. Oznacza to zezwolenie na dowolny origin przeglądarki, a nie „dopasuj dowolny host, którego używam”.
+    - Wdrożenia Control UI inne niż loopback muszą jawnie ustawić `gateway.controlUi.allowedOrigins` (pełne origin). Obejmuje to zdalne konfiguracje deweloperskie.
+    - Uruchomienie Gateway może zainicjować lokalne origin, takie jak `http://localhost:<port>` i `http://127.0.0.1:<port>`, na podstawie efektywnego powiązania i portu runtime, ale zdalne origin przeglądarki nadal wymagają jawnych wpisów.
+    - Nie używaj `gateway.controlUi.allowedOrigins: ["*"]` poza ściśle kontrolowanymi testami lokalnymi. Oznacza to zezwolenie na dowolny origin przeglądarki, a nie „dopasuj dowolny host, którego używam”.
    - `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` włącza tryb awaryjnego użycia origin z nagłówka Host, ale jest to niebezpieczny tryb bezpieczeństwa.

  </Accordion>
--- a/docs/pl/web/webchat.md
+++ b/docs/pl/web/webchat.md
@ -2,17 +2,17 @@
 read_when:
    - Debugowanie lub konfigurowanie dostępu do WebChat
 summary: Statyczny host Loopback WebChat i użycie WS Gateway dla interfejsu czatu
-title: Czat internetowy
+title: WebChat
 x-i18n:
-    generated_at: "2026-05-02T10:06:42Z"
+    generated_at: "2026-05-02T23:39:20Z"
    model: gpt-5.5
    provider: openai
-    source_hash: fe6d3cb30ed18d651b0d0ca8fd188b47c5f1d186410ee340deb79315f194ed8d
+    source_hash: ad3a09c8962e3a6dda83716d319df7ba27e18105cee50721278b5cba0a85c52f
    source_path: web/webchat.md
    workflow: 16
 ---

-Status: interfejs czatu SwiftUI dla macOS/iOS komunikuje się bezpośrednio z WebSocket Gateway.
+Status: interfejs czatu SwiftUI dla macOS/iOS komunikuje się bezpośrednio z Gateway WebSocket.

 ## Czym to jest

@ -23,49 +23,50 @@ Status: interfejs czatu SwiftUI dla macOS/iOS komunikuje się bezpośrednio z We
 ## Szybki start

 1. Uruchom Gateway.
-2. Otwórz interfejs WebChat (aplikacja macOS/iOS) albo kartę czatu Control UI.
+2. Otwórz interfejs WebChat UI (aplikacja macOS/iOS) lub kartę czatu Control UI.
 3. Upewnij się, że skonfigurowano prawidłową ścieżkę uwierzytelniania Gateway (domyślnie shared-secret,
   nawet na loopback).

 ## Jak to działa (zachowanie)

- UI łączy się z WebSocket Gateway i używa `chat.history`, `chat.send` oraz `chat.inject`.
- `chat.history` jest ograniczone dla stabilności: Gateway może przycinać długie pola tekstowe, pomijać ciężkie metadane i zastępować zbyt duże wpisy tekstem `[chat.history omitted: message too large]`.
- `chat.history` podąża za aktywną gałęzią transkrypcji w nowoczesnych plikach sesji typu append-only, więc porzucone gałęzie przepisywania i zastąpione kopie promptów nie są renderowane w WebChat.
- Control UI zapamiętuje bazowy `sessionId` Gateway zwrócony przez `chat.history` i dołącza go do kolejnych wywołań `chat.send`, dzięki czemu ponowne połączenia i odświeżenia strony kontynuują tę samą zapisaną rozmowę, chyba że użytkownik rozpocznie albo zresetuje sesję.
- Control UI scala zduplikowane wysłania w toku dla tej samej sesji, wiadomości i załączników przed wygenerowaniem nowego identyfikatora uruchomienia `chat.send`; Gateway nadal deduplikuje powtarzane żądania, które ponownie używają tego samego klucza idempotencji.
- `chat.history` jest również normalizowane do wyświetlania: kontekst OpenClaw wyłącznie z czasu działania,
-  przychodzące opakowania envelope, wbudowane tagi dyrektyw dostarczania
+- Interfejs UI łączy się z Gateway WebSocket i używa `chat.history`, `chat.send`, `chat.inject` oraz `chat.transcribeAudio`.
+- `chat.history` jest ograniczone dla stabilności: Gateway może skracać długie pola tekstowe, pomijać ciężkie metadane i zastępować zbyt duże wpisy tekstem `[chat.history omitted: message too large]`.
+- `chat.history` podąża za aktywną gałęzią transkryptu w nowoczesnych plikach sesji tylko do dopisywania, więc porzucone gałęzie przepisywania i zastąpione kopie promptów nie są renderowane w WebChat.
+- Control UI zapamiętuje bazowy `sessionId` Gateway zwrócony przez `chat.history` i dołącza go do kolejnych wywołań `chat.send`, dzięki czemu ponowne połączenia i odświeżenia strony kontynuują tę samą zapisaną rozmowę, chyba że użytkownik rozpocznie lub zresetuje sesję.
+- Control UI scala zduplikowane wysyłki w toku dla tej samej sesji, wiadomości i załączników przed wygenerowaniem nowego identyfikatora uruchomienia `chat.send`; Gateway nadal deduplikuje powtórzone żądania, które ponownie używają tego samego klucza idempotencji.
+- `chat.history` jest także normalizowane do wyświetlania: kontekst OpenClaw wyłącznie środowiska uruchomieniowego,
+  opakowania przychodzących kopert, wbudowane tagi dyrektyw dostarczania,
  takie jak `[[reply_to_*]]` i `[[audio_as_voice]]`, tekstowe ładunki XML wywołań narzędzi
  (w tym `<tool_call>...</tool_call>`,
  `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`,
-  `<function_calls>...</function_calls>` oraz przycięte bloki wywołań narzędzi), a także
-  ujawnione tokeny sterujące modelu w ASCII/pełnej szerokości są usuwane z widocznego tekstu,
+  `<function_calls>...</function_calls>` oraz skrócone bloki wywołań narzędzi), a także
+  ujawnione tokeny sterujące modelu ASCII/pełnej szerokości są usuwane z widocznego tekstu,
  a wpisy asystenta, których cały widoczny tekst jest tylko dokładnym cichym
  tokenem `NO_REPLY` / `no_reply`, są pomijane.
- Ładunki odpowiedzi oznaczone jako rozumowanie (`isReasoning: true`) są wykluczane z treści asystenta WebChat, tekstu odtwarzania transkrypcji i bloków treści audio, więc ładunki przeznaczone wyłącznie do myślenia nie pojawiają się jako widoczne wiadomości asystenta ani odtwarzalne audio.
- `chat.inject` dopisuje notatkę asystenta bezpośrednio do transkrypcji i rozgłasza ją do UI (bez uruchomienia agenta).
- Przerwane uruchomienia mogą pozostawiać częściowe wyjście asystenta widoczne w UI.
- Gateway zapisuje przerwany częściowy tekst asystenta w historii transkrypcji, gdy istnieje zbuforowane wyjście, i oznacza te wpisy metadanymi przerwania.
- Historia jest zawsze pobierana z Gateway (bez obserwowania plików lokalnych).
- Jeśli Gateway jest nieosiągalny, WebChat działa tylko do odczytu.
+- Ładunki odpowiedzi oznaczone jako rozumowanie (`isReasoning: true`) są wykluczane z treści asystenta w WebChat, tekstu odtwarzania transkryptu i bloków treści audio, więc ładunki wyłącznie z tokiem rozumowania nie pojawiają się jako widoczne wiadomości asystenta ani odtwarzalne audio.
+- `chat.transcribeAudio` obsługuje dyktowanie po stronie serwera w edytorze czatu Control UI. Przeglądarka nagrywa dźwięk z mikrofonu, wysyła go jako base64 do Gateway, a Gateway uruchamia skonfigurowany potok `tools.media.audio`. Zwrócony transkrypt jest wstawiany do wersji roboczej; uruchomienie agenta nie rozpoczyna się, dopóki użytkownik go nie wyśle.
+- `chat.inject` dopisuje notatkę asystenta bezpośrednio do transkryptu i rozgłasza ją do interfejsu UI (bez uruchamiania agenta).
+- Przerwane uruchomienia mogą pozostawiać częściowe dane wyjściowe asystenta widoczne w interfejsie UI.
+- Gateway zapisuje przerwany częściowy tekst asystenta w historii transkryptu, gdy istnieją zbuforowane dane wyjściowe, i oznacza te wpisy metadanymi przerwania.
+- Historia jest zawsze pobierana z Gateway (bez lokalnego obserwowania plików).
+- Jeśli Gateway jest nieosiągalny, WebChat jest tylko do odczytu.

 ## Panel narzędzi agentów Control UI

- Panel Narzędzia Control UI `/agents` ma dwa oddzielne widoki:
+- Panel Tools w `/agents` w Control UI ma dwa osobne widoki:
  - **Dostępne teraz** używa `tools.effective(sessionKey=...)` i pokazuje, czego bieżąca
-    sesja może faktycznie używać w czasie działania, w tym narzędzia należące do rdzenia, Plugin i kanału.
-  - **Konfiguracja narzędzi** używa `tools.catalog` i skupia się na profilach, nadpisaniach oraz
+    sesja może faktycznie używać w czasie wykonywania, w tym narzędzia rdzenia, Plugin i należące do kanałów.
+  - **Konfiguracja narzędzi** używa `tools.catalog` i pozostaje skupiona na profilach, nadpisaniach oraz
    semantyce katalogu.
- Dostępność w czasie działania jest ograniczona do sesji. Przełączanie sesji na tym samym agencie może zmienić
+- Dostępność w czasie wykonywania jest ograniczona do sesji. Przełączanie sesji na tym samym agencie może zmienić
  listę **Dostępne teraz**.
- Edytor konfiguracji nie oznacza dostępności w czasie działania; efektywny dostęp nadal wynika z priorytetu zasad
-  (`allow`/`deny`, nadpisania per agent oraz dostawca/kanał).
+- Edytor konfiguracji nie oznacza dostępności w czasie wykonywania; efektywny dostęp nadal podlega precedencji zasad
+  (`allow`/`deny`, nadpisania dla poszczególnych agentów oraz dostawców/kanałów).

 ## Użycie zdalne

- Tryb zdalny tuneluje WebSocket Gateway przez SSH/Tailscale.
- Nie musisz uruchamiać osobnego serwera WebChat.
+- Tryb zdalny tuneluje Gateway WebSocket przez SSH/Tailscale.
+- Nie trzeba uruchamiać osobnego serwera WebChat.

 ## Dokumentacja konfiguracji (WebChat)

@ -73,18 +74,18 @@ Pełna konfiguracja: [Konfiguracja](/pl/gateway/configuration)

 Opcje WebChat:

- `gateway.webchat.chatHistoryMaxChars`: maksymalna liczba znaków dla pól tekstowych w odpowiedziach `chat.history`. Gdy wpis transkrypcji przekracza ten limit, Gateway przycina długie pola tekstowe i może zastąpić zbyt duże wiadomości symbolem zastępczym. Klient może również wysłać `maxChars` dla pojedynczego żądania, aby zastąpić tę wartość domyślną dla jednego wywołania `chat.history`.
+- `gateway.webchat.chatHistoryMaxChars`: maksymalna liczba znaków dla pól tekstowych w odpowiedziach `chat.history`. Gdy wpis transkryptu przekroczy ten limit, Gateway skraca długie pola tekstowe i może zastąpić zbyt duże wiadomości symbolem zastępczym. Klient może także wysłać `maxChars` dla pojedynczego żądania, aby nadpisać tę wartość domyślną dla jednego wywołania `chat.history`.

 Powiązane opcje globalne:

 - `gateway.port`, `gateway.bind`: host/port WebSocket.
 - `gateway.auth.mode`, `gateway.auth.token`, `gateway.auth.password`:
  uwierzytelnianie WebSocket typu shared-secret.
- `gateway.auth.allowTailscale`: karta czatu Control UI w przeglądarce może używać nagłówków tożsamości Tailscale
+- `gateway.auth.allowTailscale`: karta czatu w przeglądarkowym Control UI może używać nagłówków tożsamości Tailscale
  Serve, gdy ta opcja jest włączona.
- `gateway.auth.mode: "trusted-proxy"`: uwierzytelnianie przez odwrotny proxy dla klientów przeglądarkowych za świadomym tożsamości źródłem proxy **non-loopback** (zobacz [Uwierzytelnianie przez zaufany proxy](/pl/gateway/trusted-proxy-auth)).
- `gateway.remote.url`, `gateway.remote.token`, `gateway.remote.password`: zdalny cel Gateway.
- `session.*`: przechowywanie sesji i domyślne wartości klucza głównego.
+- `gateway.auth.mode: "trusted-proxy"`: uwierzytelnianie reverse-proxy dla klientów przeglądarkowych za świadomym tożsamości źródłem proxy **innym niż loopback** (zobacz [Uwierzytelnianie zaufanego proxy](/pl/gateway/trusted-proxy-auth)).
+- `gateway.remote.url`, `gateway.remote.token`, `gateway.remote.password`: docelowy zdalny Gateway.
+- `session.*`: przechowywanie sesji i domyślne wartości głównego klucza.

 ## Powiązane