From f4af8a441d4384cb06ec804ba3f5c7740f7bd537 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Sat, 2 May 2026 23:42:50 +0000 Subject: [PATCH] chore(i18n): refresh pl translations --- docs/pl/ci.md | 425 +++++++------- docs/pl/concepts/system-prompt.md | 235 ++++---- docs/pl/nodes/audio.md | 87 +-- docs/pl/plugins/codex-harness.md | 909 ++++++++++++++---------------- docs/pl/providers/arcee.md | 74 +-- docs/pl/reference/RELEASING.md | 738 ++++++++++++------------ docs/pl/web/control-ui.md | 272 ++++----- docs/pl/web/webchat.md | 67 +-- 8 files changed, 1371 insertions(+), 1436 deletions(-) diff --git a/docs/pl/ci.md b/docs/pl/ci.md index 54f19d088..a70203788 100644 --- 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= ## 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//-//`. Bieżący wskaźnik gałęzi jest zapisywany jako `openclaw-performance//latest-.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//-//`. Bieżący wskaźnik gałęzi jest zapisywany jako `openclaw-performance//latest-.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=`: +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=`: ```bash pnpm ci:full-release --sha ``` -Refy uruchamiania workflow GitHub muszą być gałęziami lub tagami, a nie surowymi SHA commitów. Helper wypycha tymczasową gałąź `release-ci/-...` 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/-...` 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:` 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:` 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 # download Docker artifacts and print combined/per-lane targeted rerun commands pnpm test:docker:timings # 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 --shell "OPENCLAW_TESTBOX=1 pnpm check:changed pnpm crabbox:stop -- ``` -`.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 ` 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 ` 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) diff --git a/docs/pl/concepts/system-prompt.md b/docs/pl/concepts/system-prompt.md index c43941a85..256d6c253 100644 --- 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 `, aby odświeżyć z konkretnego pliku `models_cache.json` +fikstury. Przekaż `--catalog `, 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`. -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. -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. ``` -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 diff --git a/docs/pl/nodes/audio.md b/docs/pl/nodes/audio.md index 1925b499a..b81747ae8 100644 --- 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..disableAudioPreflight: true`, aby pominąć sprawdzanie wzmianek w transkrypcie preflight dla tej grupy. -- Ustaw `channels.telegram.groups..topics..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..disableAudioPreflight: true`, aby pominąć wstępne sprawdzanie wzmianek w transkrypcji dla tej grupy. +- Ustaw `channels.telegram.groups..topics..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 `/.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 `/.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) diff --git a/docs/pl/plugins/codex-harness.md b/docs/pl/plugins/codex-harness.md index 0c704ca66..27f2af59b 100644 --- a/docs/pl/plugins/codex-harness.md +++ b/docs/pl/plugins/codex-harness.md @@ -1,60 +1,59 @@ --- read_when: - - Chcesz użyć dołączonego środowiska app-server Codex + - Chcesz używać dołączonego mechanizmu Codex app-server - Potrzebujesz przykładów konfiguracji środowiska Codex - - Chcesz, aby wdrożenia wyłącznie z Codex kończyły się niepowodzeniem zamiast przechodzić awaryjnie na PI -summary: Uruchamiaj tury osadzonego agenta OpenClaw przez dołączony mechanizm serwera aplikacji Codex -title: Środowisko uruchomieniowe Codex + - Chcesz, aby wdrożenia wyłącznie z Codex kończyły się niepowodzeniem zamiast korzystać awaryjnie z PI +summary: Uruchamiaj tury osadzonego agenta OpenClaw przez dołączony mechanizm app-server Codex +title: Środowisko Codex x-i18n: - generated_at: "2026-05-02T09:56:27Z" + generated_at: "2026-05-02T23:39:39Z" model: gpt-5.5 provider: openai - source_hash: 107f9fc0a3e8ad6a4790fc9eb68276c81d299236f11293014d2ab9bf6e235133 + source_hash: 8ffa0cbb28422b2ed8d7c0eef6ee0222072c523d170b4b33597bb37bd3fa9700 source_path: plugins/codex-harness.md workflow: 16 --- -Wbudowany plugin `codex` pozwala OpenClaw uruchamiać osadzone tury agenta przez -app-server Codex zamiast wbudowanego harnessu PI. +Dołączony plugin `codex` pozwala OpenClaw uruchamiać osadzone tury agentów przez +serwer aplikacji Codex zamiast wbudowanego środowiska PI. Użyj tego, gdy chcesz, aby Codex odpowiadał za niskopoziomową sesję agenta: -wykrywanie modeli, natywne wznawianie wątków, natywną kompakcję i wykonywanie -przez app-server. OpenClaw nadal odpowiada za kanały czatu, pliki sesji, wybór -modelu, narzędzia, zatwierdzenia, dostarczanie multimediów oraz widoczne -lustrzane odzwierciedlenie transkrypcji. +wykrywanie modeli, natywne wznawianie wątków, natywną Compaction i wykonywanie +na serwerze aplikacji. OpenClaw nadal odpowiada za kanały czatu, pliki sesji, +wybór modelu, narzędzia, zatwierdzenia, dostarczanie multimediów i widoczne +odbicie transkrypcji. -Gdy tura czatu źródłowego działa przez harness Codex, widoczne odpowiedzi -domyślnie używają narzędzia OpenClaw `message`, jeśli wdrożenie nie -skonfigurowało jawnie `messages.visibleReplies`. Agent może nadal prywatnie -zakończyć swoją turę Codex; publikuje w kanale tylko wtedy, gdy wywoła -`message(action="send")`. Ustaw `messages.visibleReplies: "automatic"`, aby -zachować końcowe odpowiedzi czatu bezpośredniego na starszej automatycznej -ścieżce dostarczania. +Gdy tura czatu źródłowego działa przez środowisko Codex, widoczne odpowiedzi +domyślnie używają narzędzia OpenClaw `message`, jeśli wdrożenie nie skonfigurowało +jawnie `messages.visibleReplies`. Agent nadal może prywatnie zakończyć swoją turę +Codex; publikuje w kanale tylko wtedy, gdy wywoła `message(action="send")`. Ustaw +`messages.visibleReplies: "automatic"`, aby zachować końcowe odpowiedzi w czacie +bezpośrednim na starszej ścieżce automatycznego dostarczania. -Tury heartbeat Codex domyślnie otrzymują też narzędzie `heartbeat_respond`, więc -agent może zapisać, czy wybudzenie ma pozostać ciche, czy powiadomić, bez -kodowania tego przepływu sterowania w tekście końcowym. +Tury Codex Heartbeat domyślnie otrzymują także narzędzie `heartbeat_respond`, dzięki +czemu agent może zapisać, czy wybudzenie ma pozostać ciche, czy wysłać +powiadomienie, bez kodowania tego przepływu sterowania w tekście końcowym. Jeśli próbujesz się zorientować, zacznij od -[Środowiska uruchomieniowe agentów](/pl/concepts/agent-runtimes). Krótka wersja: -`openai/gpt-5.5` to referencja modelu, `codex` to runtime, a Telegram, +[Czasów wykonania agentów](/pl/concepts/agent-runtimes). Krótka wersja jest taka: +`openai/gpt-5.5` to referencja modelu, `codex` to czas wykonania, a Telegram, Discord, Slack lub inny kanał pozostaje powierzchnią komunikacji. ## Szybka konfiguracja -Większość użytkowników, którzy chcą „Codex w OpenClaw”, chce tej ścieżki: -zalogować się subskrypcją ChatGPT/Codex, a następnie uruchamiać osadzone tury -agenta przez natywny runtime app-server Codex. Referencja modelu nadal pozostaje -kanoniczna jako `openai/gpt-*`; uwierzytelnianie subskrypcji pochodzi z konta lub -profilu Codex, a nie z prefiksu modelu `openai-codex/*`. +Większość użytkowników, którzy chcą „Codex w OpenClaw”, chce tej ścieżki: zaloguj +się przy użyciu subskrypcji ChatGPT/Codex, a następnie uruchamiaj osadzone tury +agentów przez natywny czas wykonania serwera aplikacji Codex. Referencja modelu +nadal pozostaje kanoniczna jako `openai/gpt-*`; uwierzytelnianie subskrypcji +pochodzi z konta/profilu Codex, a nie z prefiksu modelu `openai-codex/*`. -Najpierw zaloguj się przez Codex OAuth, jeśli jeszcze tego nie zrobiono: +Najpierw zaloguj się przy użyciu Codex OAuth, jeśli jeszcze tego nie zrobiono: ```bash openclaw models auth login --provider openai-codex ``` -Następnie włącz wbudowany plugin `codex` i wymuś runtime Codex: +Następnie włącz dołączony plugin `codex` i wymuś czas wykonania Codex: ```json5 { @@ -77,7 +76,7 @@ Następnie włącz wbudowany plugin `codex` i wymuś runtime Codex: } ``` -Jeśli konfiguracja używa `plugins.allow`, dodaj tam także `codex`: +Jeśli Twoja konfiguracja używa `plugins.allow`, dodaj tam również `codex`: ```json5 { @@ -92,39 +91,40 @@ Jeśli konfiguracja używa `plugins.allow`, dodaj tam także `codex`: } ``` -Nie używaj `openai-codex/gpt-*`, gdy chodzi Ci o natywny runtime Codex. Ten -prefiks jest jawną ścieżką „Codex OAuth przez PI”. Zmiany konfiguracji dotyczą -nowych lub zresetowanych sesji; istniejące sesje zachowują zapisany runtime. +Nie używaj `openai-codex/gpt-*`, gdy masz na myśli natywny czas wykonania Codex. +Ten prefiks oznacza jawną ścieżkę „Codex OAuth przez PI”. Zmiany konfiguracji +dotyczą nowych lub resetowanych sesji; istniejące sesje zachowują zapisany czas +wykonania. ## Co zmienia ten plugin -Wbudowany plugin `codex` dostarcza kilka oddzielnych możliwości: +Dołączony plugin `codex` zapewnia kilka odrębnych możliwości: -| Możliwość | Jak jej używasz | Co robi | +| Możliwość | Jak jej używać | Co robi | | --------------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------------- | -| Natywny runtime osadzony | `agentRuntime.id: "codex"` | Uruchamia osadzone tury agenta OpenClaw przez app-server Codex. | -| Natywne polecenia sterowania czatem | `/codex bind`, `/codex resume`, `/codex steer`, ... | Wiąże i kontroluje wątki app-server Codex z konwersacji komunikatora. | -| Dostawca/katalog app-server Codex | elementy wewnętrzne `codex`, udostępniane przez harness | Pozwala runtime wykrywać i walidować modele app-server. | -| Ścieżka rozumienia multimediów Codex | ścieżki zgodności modeli obrazów `codex/*` | Uruchamia ograniczone tury app-server Codex dla obsługiwanych modeli rozumienia obrazów. | -| Natywny przekaźnik hooków | Hooki pluginu wokół natywnych zdarzeń Codex | Pozwala OpenClaw obserwować/blokować obsługiwane natywne zdarzenia narzędzi/finalizacji Codex. | +| Natywny osadzony czas wykonania | `agentRuntime.id: "codex"` | Uruchamia osadzone tury agentów OpenClaw przez serwer aplikacji Codex. | +| Natywne komendy sterowania czatem | `/codex bind`, `/codex resume`, `/codex steer`, ... | Wiąże wątki serwera aplikacji Codex z konwersacją komunikatora i nimi steruje. | +| Dostawca/katalog serwera aplikacji Codex | elementy wewnętrzne `codex`, udostępniane przez środowisko | Pozwala czasowi wykonania wykrywać i weryfikować modele serwera aplikacji. | +| Ścieżka rozumienia multimediów Codex | ścieżki zgodności modeli obrazów `codex/*` | Uruchamia ograniczone tury serwera aplikacji Codex dla obsługiwanych modeli rozumienia obrazów. | +| Natywny przekaźnik haków | Haki Plugin wokół natywnych zdarzeń Codex | Pozwala OpenClaw obserwować/blokować obsługiwane natywne zdarzenia narzędzi/finalizacji Codex. | Włączenie pluginu udostępnia te możliwości. **Nie** powoduje to: -- używania Codex dla każdego modelu OpenAI -- konwertowania referencji modeli `openai-codex/*` na natywny runtime +- rozpoczęcia używania Codex dla każdego modelu OpenAI +- konwersji referencji modeli `openai-codex/*` do natywnego czasu wykonania - ustawienia ACP/acpx jako domyślnej ścieżki Codex -- przełączania na gorąco istniejących sesji, które już zapisały runtime PI +- gorącego przełączenia istniejących sesji, które już zapisały czas wykonania PI - zastąpienia dostarczania kanałów OpenClaw, plików sesji, przechowywania profili uwierzytelniania ani routingu wiadomości -Ten sam plugin odpowiada także za natywną powierzchnię poleceń sterowania czatem -`/codex`. Jeśli plugin jest włączony, a użytkownik prosi o powiązanie, -wznowienie, sterowanie, zatrzymanie lub sprawdzenie wątków Codex z czatu, agenci -powinni preferować `/codex ...` zamiast ACP. ACP pozostaje jawnym rozwiązaniem -awaryjnym, gdy użytkownik prosi o ACP/acpx albo testuje adapter ACP Codex. +Ten sam plugin odpowiada również za natywną powierzchnię komend sterowania czatem +`/codex`. Jeśli plugin jest włączony, a użytkownik prosi o powiązanie, wznowienie, +sterowanie, zatrzymanie lub sprawdzenie wątków Codex z czatu, agenci powinni +preferować `/codex ...` zamiast ACP. ACP pozostaje jawną alternatywą, gdy +użytkownik prosi o ACP/acpx lub testuje adapter ACP Codex. -Natywne tury Codex zachowują hooki pluginów OpenClaw jako publiczną warstwę -zgodności. Są to wewnątrzprocesowe hooki OpenClaw, a nie hooki poleceń Codex +Natywne tury Codex zachowują haki pluginów OpenClaw jako publiczną warstwę +zgodności. To są haki OpenClaw działające w procesie, a nie haki komend Codex `hooks.json`: - `before_prompt_build` @@ -135,165 +135,177 @@ zgodności. Są to wewnątrzprocesowe hooki OpenClaw, a nie hooki poleceń Codex - `before_agent_finalize` przez przekaźnik Codex `Stop` - `agent_end` -Pluginy mogą także rejestrować neutralne względem runtime middleware wyników -narzędzi, aby przepisywać dynamiczne wyniki narzędzi OpenClaw po wykonaniu -narzędzia przez OpenClaw i przed zwróceniem wyniku do Codex. Jest to oddzielne -od publicznego hooka pluginu `tool_result_persist`, który przekształca zapisy -wyników narzędzi w transkrypcji należącej do OpenClaw. +Pluginy mogą też rejestrować neutralne względem czasu wykonania oprogramowanie +pośredniczące wyników narzędzi, aby przepisywać dynamiczne wyniki narzędzi +OpenClaw po wykonaniu narzędzia przez OpenClaw i przed zwróceniem wyniku do +Codex. Jest to oddzielne od publicznego haka pluginu `tool_result_persist`, który +przekształca zapisy wyników narzędzi transkrypcji należące do OpenClaw. -Semantykę samych hooków pluginów opisują [Hooki pluginów](/pl/plugins/hooks) oraz -[Zachowanie strażnika pluginów](/pl/tools/plugin). +Semantykę samych haków pluginów opisują [Haki Plugin](/pl/plugins/hooks) i +[Zachowanie strażnika Plugin](/pl/tools/plugin). -Harness jest domyślnie wyłączony. Nowe konfiguracje powinny utrzymywać +Środowisko jest domyślnie wyłączone. Nowe konfiguracje powinny zachowywać referencje modeli OpenAI w kanonicznej postaci `openai/gpt-*` i jawnie wymuszać -`agentRuntime.id: "codex"` albo `OPENCLAW_AGENT_RUNTIME=codex`, gdy potrzebują -natywnego wykonywania przez app-server. Starsze referencje modeli `codex/*` -nadal automatycznie wybierają harness dla zgodności, ale starsze prefiksy -dostawców oparte na runtime nie są pokazywane jako normalne wybory -modelu/dostawcy. +`agentRuntime.id: "codex"` lub `OPENCLAW_AGENT_RUNTIME=codex`, gdy potrzebują +natywnego wykonywania na serwerze aplikacji. Starsze referencje modeli `codex/*` +nadal automatycznie wybierają środowisko ze względu na zgodność, ale starsze +prefiksy dostawców oparte na czasie wykonania nie są pokazywane jako zwykłe +wybory modelu/dostawcy. -Jeśli plugin `codex` jest włączony, ale model główny nadal ma postać -`openai-codex/*`, `openclaw doctor` wyświetla ostrzeżenie zamiast zmieniać -ścieżkę. To celowe: `openai-codex/*` pozostaje ścieżką PI Codex -OAuth/subskrypcji, a natywne wykonywanie app-server pozostaje jawnym wyborem -runtime. +Jeśli plugin `codex` jest włączony, ale główny model nadal ma postać +`openai-codex/*`, `openclaw doctor` ostrzega zamiast zmieniać ścieżkę. To +zamierzone: `openai-codex/*` pozostaje ścieżką PI Codex OAuth/subskrypcji, a +natywne wykonywanie na serwerze aplikacji pozostaje jawnym wyborem czasu +wykonania. ## Mapa ścieżek Użyj tej tabeli przed zmianą konfiguracji: -| Oczekiwane zachowanie | Referencja modelu | Konfiguracja runtime | Ścieżka uwierzytelniania/profilu | Oczekiwana etykieta statusu | +| Pożądane zachowanie | Referencja modelu | Konfiguracja czasu wykonania | Ścieżka uwierzytelniania/profilu | Oczekiwana etykieta statusu | | ---------------------------------------------------- | -------------------------- | -------------------------------------- | ---------------------------- | ------------------------------ | -| Subskrypcja ChatGPT/Codex z natywnym runtime Codex | `openai/gpt-*` | `agentRuntime.id: "codex"` | Codex OAuth lub konto Codex | `Runtime: OpenAI Codex` | -| OpenAI API przez zwykły runner OpenClaw | `openai/gpt-*` | pominięte lub `runtime: "pi"` | Klucz OpenAI API | `Runtime: OpenClaw Pi Default` | -| Subskrypcja ChatGPT/Codex przez PI | `openai-codex/gpt-*` | pominięte lub `runtime: "pi"` | Dostawca OpenAI Codex OAuth | `Runtime: OpenClaw Pi Default` | -| Mieszani dostawcy z konserwatywnym trybem automatycznym | referencje specyficzne dla dostawcy | `agentRuntime.id: "auto"` | Według wybranego dostawcy | Zależy od wybranego runtime | -| Jawna sesja adaptera Codex ACP | zależne od promptu/modelu ACP | `sessions_spawn` z `runtime: "acp"` | Uwierzytelnianie backendu ACP | Status zadania/sesji ACP | +| Subskrypcja ChatGPT/Codex z natywnym czasem wykonania Codex | `openai/gpt-*` | `agentRuntime.id: "codex"` | Codex OAuth lub konto Codex | `Runtime: OpenAI Codex` | +| OpenAI API przez zwykły runner OpenClaw | `openai/gpt-*` | pominięte lub `runtime: "pi"` | Klucz OpenAI API | `Runtime: OpenClaw Pi Default` | +| Subskrypcja ChatGPT/Codex przez PI | `openai-codex/gpt-*` | pominięte lub `runtime: "pi"` | Dostawca OpenAI Codex OAuth | `Runtime: OpenClaw Pi Default` | +| Mieszani dostawcy z konserwatywnym trybem automatycznym | referencje specyficzne dla dostawcy | `agentRuntime.id: "auto"` | Według wybranego dostawcy | Zależy od wybranego czasu wykonania | +| Jawna sesja adaptera Codex ACP | zależne od promptu/modelu ACP | `sessions_spawn` z `runtime: "acp"` | Uwierzytelnianie zaplecza ACP | Status zadania/sesji ACP | -Ważny podział to dostawca kontra runtime: +Istotny jest podział na dostawcę i czas wykonania: -- `openai-codex/*` odpowiada na pytanie „której ścieżki dostawcy/uwierzytelniania - powinien użyć PI?” -- `agentRuntime.id: "codex"` odpowiada na pytanie „która pętla powinna wykonać tę +- `openai-codex/*` odpowiada na pytanie „której ścieżki dostawcy/uwierzytelniania ma użyć PI?” +- `agentRuntime.id: "codex"` odpowiada na pytanie „która pętla ma wykonać tę osadzoną turę?” -- `/codex ...` odpowiada na pytanie „którą natywną konwersację Codex ten czat ma - powiązać lub kontrolować?” -- ACP odpowiada na pytanie „który zewnętrzny proces harnessu powinien uruchomić - acpx?” +- `/codex ...` odpowiada na pytanie „z którą natywną konwersacją Codex ma się + powiązać ten czat lub którą ma kontrolować?” +- ACP odpowiada na pytanie „który zewnętrzny proces środowiska ma uruchomić acpx?” ## Wybierz właściwy prefiks modelu -Ścieżki rodziny OpenAI zależą od prefiksu. Dla typowej konfiguracji subskrypcji -plus natywnego runtime Codex użyj `openai/*` z `agentRuntime.id: "codex"`. -Używaj `openai-codex/*` tylko wtedy, gdy celowo chcesz Codex OAuth przez PI: +Ścieżki rodziny OpenAI zależą od prefiksu. W typowej konfiguracji subskrypcji +plus natywnego czasu wykonania Codex użyj `openai/*` z +`agentRuntime.id: "codex"`. Używaj `openai-codex/*` tylko wtedy, gdy celowo +chcesz Codex OAuth przez PI: -| Referencja modelu | Ścieżka runtime | Kiedy używać | +| Referencja modelu | Ścieżka czasu wykonania | Kiedy używać | | --------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------- | -| `openai/gpt-5.4` | Dostawca OpenAI przez instalację OpenClaw/PI | Gdy chcesz aktualnego bezpośredniego dostępu do OpenAI Platform API z `OPENAI_API_KEY`. | -| `openai-codex/gpt-5.5` | OpenAI Codex OAuth przez OpenClaw/PI | Gdy chcesz uwierzytelniania subskrypcją ChatGPT/Codex z domyślnym runnerem PI. | -| `openai/gpt-5.5` + `agentRuntime.id: "codex"` | Harness app-server Codex | Gdy chcesz uwierzytelniania subskrypcją ChatGPT/Codex z natywnym wykonywaniem Codex. | +| `openai/gpt-5.4` | Dostawca OpenAI przez mechanizmy OpenClaw/PI | Gdy chcesz bieżącego bezpośredniego dostępu do OpenAI Platform API z `OPENAI_API_KEY`. | +| `openai-codex/gpt-5.5` | OpenAI Codex OAuth przez OpenClaw/PI | Gdy chcesz uwierzytelniania subskrypcji ChatGPT/Codex z domyślnym runnerem PI. | +| `openai/gpt-5.5` + `agentRuntime.id: "codex"` | Środowisko serwera aplikacji Codex | Gdy chcesz uwierzytelniania subskrypcji ChatGPT/Codex z natywnym wykonywaniem Codex. | GPT-5.5 może pojawiać się zarówno na bezpośrednich ścieżkach klucza API OpenAI, -jak i subskrypcji Codex, gdy konto je udostępnia. Użyj `openai/gpt-5.5` z -harnessem app-server Codex dla natywnego runtime Codex, `openai-codex/gpt-5.5` -dla PI OAuth albo `openai/gpt-5.5` bez nadpisania runtime Codex dla ruchu z -bezpośrednim kluczem API. +jak i subskrypcji Codex, gdy Twoje konto je udostępnia. Użyj +`openai/gpt-5.5` ze środowiskiem serwera aplikacji Codex dla natywnego czasu +wykonania Codex, `openai-codex/gpt-5.5` dla PI OAuth albo `openai/gpt-5.5` bez +nadpisania czasu wykonania Codex dla ruchu z bezpośrednim kluczem API. Starsze referencje `codex/gpt-*` nadal są akceptowane jako aliasy zgodności. -Migracja zgodności doctor przepisuje starsze referencje głównego runtime na -kanoniczne referencje modeli i zapisuje politykę runtime oddzielnie, natomiast -starsze referencje używane tylko jako fallback pozostają niezmienione, ponieważ -runtime jest konfigurowany dla całego kontenera agenta. Nowe konfiguracje PI -Codex OAuth powinny używać `openai-codex/gpt-*`; nowe konfiguracje natywnego -harnessu app-server powinny używać `openai/gpt-*` plus -`agentRuntime.id: "codex"`. +Migracja zgodności doctor przepisuje starsze główne referencje czasu wykonania +na kanoniczne referencje modeli i zapisuje politykę czasu wykonania oddzielnie, +natomiast starsze referencje używane wyłącznie jako fallback pozostają bez zmian, +ponieważ czas wykonania jest konfigurowany dla całego kontenera agenta. Nowe +konfiguracje PI Codex OAuth powinny używać `openai-codex/gpt-*`; nowe +konfiguracje natywnego środowiska serwera aplikacji powinny używać +`openai/gpt-*` plus `agentRuntime.id: "codex"`. -`agents.defaults.imageModel` podlega temu samemu podziałowi prefiksów. Użyj -`openai-codex/gpt-*`, gdy rozumienie obrazów powinno działać przez ścieżkę -dostawcy OpenAI Codex OAuth. Użyj `codex/gpt-*`, gdy rozumienie obrazów powinno -działać przez ograniczoną turę app-server Codex. Model app-server Codex musi -deklarować obsługę wejścia obrazowego; modele Codex obsługujące tylko tekst -zawiodą przed rozpoczęciem tury multimedialnej. +`agents.defaults.imageModel` stosuje ten sam podział prefiksów. Użyj +`openai-codex/gpt-*`, gdy rozumienie obrazów ma działać przez ścieżkę dostawcy +OpenAI Codex OAuth. Użyj `codex/gpt-*`, gdy rozumienie obrazów ma działać przez +ograniczoną turę serwera aplikacji Codex. Model serwera aplikacji Codex musi +deklarować obsługę wejścia obrazowego; modele Codex wyłącznie tekstowe zawodzą +zanim tura multimedialna się rozpocznie. -Użyj `/status`, aby potwierdzić efektywny harness bieżącej sesji. Jeśli wybór -jest zaskakujący, włącz logowanie debugowania dla podsystemu `agents/harness` i -sprawdź ustrukturyzowany rekord `agent harness selected` gatewaya. Zawiera on -wybrany identyfikator harnessu, powód wyboru, politykę runtime/fallback oraz, w -trybie `auto`, wynik obsługi każdego kandydata pluginu. +Użyj `/status`, aby potwierdzić skuteczne środowisko dla bieżącej sesji. Jeśli +wybór jest zaskakujący, włącz logowanie debugowania dla podsystemu +`agents/harness` i sprawdź ustrukturyzowany rekord Gateway `agent harness selected`. +Zawiera on wybrany identyfikator środowiska, powód wyboru, politykę +czasu wykonania/fallbacku oraz, w trybie `auto`, wynik obsługi każdego kandydata +pluginu. ### Co oznaczają ostrzeżenia doctor -`openclaw doctor` ostrzega, gdy wszystkie poniższe warunki są prawdziwe: +`openclaw doctor` ostrzega, gdy wszystkie te warunki są spełnione: -- wbudowany plugin `codex` jest włączony lub dozwolony -- główny model agenta ma postać `openai-codex/*` -- efektywny runtime tego agenta nie jest `codex` +- dołączony plugin `codex` jest włączony lub dozwolony +- główny model agenta to `openai-codex/*` +- skuteczny czas wykonania tego agenta nie jest `codex` -To ostrzeżenie istnieje, ponieważ użytkownicy często oczekują, że „plugin Codex -włączony” oznacza „natywny runtime app-server Codex”. OpenClaw nie wykonuje tego -skoku. Ostrzeżenie oznacza: +To ostrzeżenie istnieje, ponieważ użytkownicy często oczekują, że „włączony +plugin Codex” oznacza „natywny czas wykonania serwera aplikacji Codex”. OpenClaw +nie wykonuje takiego przeskoku. Ostrzeżenie oznacza: -- **Nie jest wymagana żadna zmiana**, jeśli zamierzałeś użyć ChatGPT/Codex OAuth - przez PI. +- **Żadna zmiana nie jest wymagana**, jeśli zamierzeniem było ChatGPT/Codex OAuth przez PI. - Zmień model na `openai/` i ustaw - `agentRuntime.id: "codex"`, jeśli zamierzałeś użyć natywnego wykonywania - app-server. -- Istniejące sesje nadal wymagają `/new` albo `/reset` po zmianie runtime, - ponieważ przypięcia runtime sesji są trwałe. + `agentRuntime.id: "codex"`, jeśli zamierzeniem było natywne wykonywanie na + serwerze aplikacji. +- Istniejące sesje nadal wymagają `/new` lub `/reset` po zmianie czasu wykonania, + ponieważ przypięcia czasu wykonania sesji są trwałe. -Wybór harnessu nie jest kontrolą sesji na żywo. Gdy działa tura osadzona, -OpenClaw zapisuje wybrany identyfikator harnessu w tej sesji i dalej używa go w -późniejszych turach z tym samym identyfikatorem sesji. Zmień konfigurację -`agentRuntime` albo `OPENCLAW_AGENT_RUNTIME`, gdy chcesz, aby przyszłe sesje -używały innego harnessu; użyj `/new` albo `/reset`, aby rozpocząć świeżą sesję -przed przełączeniem istniejącej konwersacji między PI i Codex. Pozwala to -uniknąć odtwarzania jednej transkrypcji przez dwa niezgodne natywne systemy -sesji. +Wybór środowiska nie jest kontrolą sesji na żywo. Gdy wykonywana jest osadzona +tura, OpenClaw zapisuje wybrany identyfikator środowiska w tej sesji i używa go +dla kolejnych tur w tym samym identyfikatorze sesji. Zmień konfigurację +`agentRuntime` lub `OPENCLAW_AGENT_RUNTIME`, gdy chcesz, aby przyszłe sesje +używały innego środowiska; użyj `/new` lub `/reset`, aby rozpocząć świeżą sesję +przed przełączeniem istniejącej konwersacji między PI a Codex. Pozwala to uniknąć +odtwarzania jednej transkrypcji przez dwa niezgodne natywne systemy sesji. -Starsze sesje utworzone przed przypięciami harnessu są traktowane jako przypięte -do PI, gdy mają historię transkrypcji. Użyj `/new` albo `/reset`, aby włączyć tę -konwersację do Codex po zmianie konfiguracji. +Starsze sesje utworzone przed przypięciami środowiska są traktowane jako +przypięte do PI, gdy mają już historię transkrypcji. Użyj `/new` lub `/reset`, +aby włączyć Codex dla tej konwersacji po zmianie konfiguracji. -`/status` pokazuje efektywne środowisko wykonawcze modelu. Domyślny harness PI jest wyświetlany jako -`Runtime: OpenClaw Pi Default`, a harness serwera aplikacji Codex jako +`/status` pokazuje efektywny runtime modelu. Domyślny mechanizm PI jest wyświetlany jako +`Runtime: OpenClaw Pi Default`, a mechanizm Codex app-server jako `Runtime: OpenAI Codex`. ## Wymagania - OpenClaw z dostępnym dołączonym pluginem `codex`. -- Serwer aplikacji Codex `0.125.0` lub nowszy. Dołączony plugin domyślnie zarządza zgodnym - binarium serwera aplikacji Codex, więc lokalne polecenia `codex` w `PATH` nie - wpływają na normalne uruchamianie harnessu. -- Uwierzytelnianie Codex dostępne dla procesu serwera aplikacji albo dla mostka - uwierzytelniania Codex w OpenClaw. Lokalne uruchomienia serwera aplikacji używają zarządzanego przez OpenClaw katalogu domowego Codex dla każdego - agenta oraz izolowanego podrzędnego `HOME`, więc domyślnie nie odczytują Twojego osobistego - konta, Skills, pluginów, konfiguracji, stanu wątków ani natywnego - `$HOME/.agents/skills` z `~/.codex`. +- Codex app-server `0.125.0` lub nowszy. Dołączony Plugin domyślnie zarządza zgodnym + plikiem binarnym Codex app-server, więc lokalne polecenia `codex` w `PATH` nie + wpływają na normalne uruchamianie mechanizmu. +- Uwierzytelnianie Codex dostępne dla procesu app-server albo dla mostka uwierzytelniania Codex + w OpenClaw. Lokalne uruchomienia app-server używają zarządzanego przez OpenClaw katalogu domowego Codex dla każdego + agenta oraz izolowanego potomnego `HOME`, więc domyślnie nie odczytują Twojego osobistego + konta `~/.codex`, Skills, pluginów, konfiguracji, stanu wątków ani natywnego + `$HOME/.agents/skills`. -Plugin blokuje starsze lub niewersjonowane uzgodnienia serwera aplikacji. Dzięki temu -OpenClaw pozostaje na powierzchni protokołu, z którą został przetestowany. +Plugin blokuje starsze lub pozbawione wersji uzgodnienia app-server. Utrzymuje to +OpenClaw na powierzchni protokołu, względem której został przetestowany. -W testach dymnych live i Docker uwierzytelnianie zwykle pochodzi z konta Codex CLI -albo profilu uwierzytelniania OpenClaw `openai-codex`. Lokalne uruchomienia serwera aplikacji stdio mogą -również awaryjnie użyć `CODEX_API_KEY` / `OPENAI_API_KEY`, gdy nie ma żadnego konta. +W testach smoke na żywo i w Dockerze uwierzytelnianie zwykle pochodzi z konta Codex CLI +albo z profilu uwierzytelniania OpenClaw `openai-codex`. Lokalne uruchomienia stdio app-server mogą +również awaryjnie użyć `CODEX_API_KEY` / `OPENAI_API_KEY`, gdy nie ma konta. + +## Pliki bootstrapu workspace + +Codex obsługuje `AGENTS.md` samodzielnie przez natywne wykrywanie dokumentacji projektu. OpenClaw +nie zapisuje syntetycznych plików dokumentacji projektu Codex ani nie zależy od zapasowych +nazw plików Codex dla plików persony, ponieważ zapasowe nazwy Codex mają zastosowanie tylko wtedy, gdy +brakuje `AGENTS.md`. + +Aby zachować parytet workspace w OpenClaw, mechanizm Codex rozwiązuje pozostałe +pliki bootstrapu (`SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, +`BOOTSTRAP.md` oraz `MEMORY.md`, gdy istnieje) i przekazuje je przez instrukcje +konfiguracji Codex przy `thread/start` i `thread/resume`. Dzięki temu +`SOUL.md` i powiązany kontekst persony/profilu workspace pozostają widoczne bez +duplikowania `AGENTS.md`. ## Dodawanie Codex obok innych modeli Nie ustawiaj globalnie `agentRuntime.id: "codex"`, jeśli ten sam agent ma swobodnie przełączać się -między Codex a modelami dostawców innych niż Codex. Wymuszone środowisko wykonawcze dotyczy każdej -osadzonej tury tego agenta lub sesji. Jeśli wybierzesz model Anthropic, gdy -to środowisko wykonawcze jest wymuszone, OpenClaw nadal próbuje użyć harnessu Codex i kończy niepowodzeniem w trybie zamkniętym -zamiast po cichu kierować tę turę przez PI. +między Codex a modelami dostawców innych niż Codex. Wymuszony runtime ma zastosowanie do każdego +osadzonego turn dla tego agenta lub sesji. Jeśli wybierzesz model Anthropic, gdy +ten runtime jest wymuszony, OpenClaw nadal spróbuje użyć mechanizmu Codex i zakończy się niepowodzeniem w trybie zamkniętym, +zamiast po cichu kierować ten turn przez PI. -Zamiast tego użyj jednego z tych układów: +Zamiast tego użyj jednej z tych struktur: - Umieść Codex na dedykowanym agencie z `agentRuntime.id: "codex"`. -- Zachowaj domyślnego agenta na `agentRuntime.id: "auto"` oraz awaryjne użycie PI dla zwykłego mieszanego +- Zostaw domyślnego agenta na `agentRuntime.id: "auto"` i zapasowym PI dla normalnego mieszanego użycia dostawców. -- Używaj starszych referencji `codex/*` tylko dla zgodności. Nowe konfiguracje powinny preferować - `openai/*` oraz jawną politykę środowiska wykonawczego Codex. +- Używaj starszych odwołań `codex/*` tylko dla zgodności. Nowe konfiguracje powinny preferować + `openai/*` plus jawną politykę runtime Codex. -Na przykład to pozostawia domyślnego agenta przy normalnym automatycznym wyborze i +Na przykład ta konfiguracja zostawia domyślnego agenta przy normalnym automatycznym wyborze i dodaje osobnego agenta Codex: ```json5 @@ -331,37 +343,38 @@ dodaje osobnego agenta Codex: } ``` -W tym układzie: +Przy tej strukturze: -- Domyślny agent `main` używa normalnej ścieżki dostawcy i awaryjnej zgodności PI. -- Agent `codex` używa harnessu serwera aplikacji Codex. -- Jeśli Codex jest brakujący lub nieobsługiwany dla agenta `codex`, tura kończy się niepowodzeniem - zamiast po cichu używać PI. +- Domyślny agent `main` używa normalnej ścieżki dostawcy i zapasowej zgodności PI. +- Agent `codex` używa mechanizmu Codex app-server. +- Jeśli Codex jest brakujący lub nieobsługiwany dla agenta `codex`, turn kończy się niepowodzeniem + zamiast cicho użyć PI. -## Kierowanie poleceń agenta +## Routing poleceń agenta -Agenci powinni kierować żądania użytkownika według intencji, a nie tylko według słowa „Codex”: +Agenci powinni kierować żądania użytkownika według intencji, a nie wyłącznie po słowie „Codex”: | Użytkownik prosi o... | Agent powinien użyć... | | ------------------------------------------------------ | ------------------------------------------------ | -| „Powiąż ten czat z Codex” | `/codex bind` | +| „Przypnij ten czat do Codex” | `/codex bind` | | „Wznów tutaj wątek Codex ``” | `/codex resume ` | | „Pokaż wątki Codex” | `/codex threads` | -| „Zgłoś raport wsparcia dla błędnego uruchomienia Codex” | `/diagnostics [note]` | -| „Wyślij tylko opinię Codex dla tego dołączonego wątku” | `/codex diagnostics [note]` | -| „Użyj mojej subskrypcji ChatGPT/Codex ze środowiskiem wykonawczym Codex” | `openai/*` plus `agentRuntime.id: "codex"` | -| „Użyj mojej subskrypcji ChatGPT/Codex przez PI” | referencje modeli `openai-codex/*` | +| „Złóż raport wsparcia dla złego uruchomienia Codex” | `/diagnostics [note]` | +| „Wyślij feedback Codex tylko dla tego załączonego wątku” | `/codex diagnostics [note]` | +| „Użyj mojej subskrypcji ChatGPT/Codex z runtime Codex” | `openai/*` plus `agentRuntime.id: "codex"` | +| „Użyj mojej subskrypcji ChatGPT/Codex przez PI” | odwołania modeli `openai-codex/*` | | „Uruchom Codex przez ACP/acpx” | ACP `sessions_spawn({ runtime: "acp", ... })` | -| „Uruchom Claude Code/Gemini/OpenCode/Cursor w wątku” | ACP/acpx, nie `/codex` i nie natywni podagenci | +| „Uruchom Claude Code/Gemini/OpenCode/Cursor w wątku” | ACP/acpx, nie `/codex` i nie natywne subagenty | -OpenClaw reklamuje agentom wskazówki uruchamiania ACP tylko wtedy, gdy ACP jest włączone, -możliwe do wysłania i wspierane przez załadowany backend środowiska wykonawczego. Jeśli ACP nie jest dostępne, -prompt systemowy i Skills pluginu nie powinny uczyć agenta kierowania przez ACP. +OpenClaw reklamuje agentom wskazówki dotyczące spawn ACP tylko wtedy, gdy ACP jest włączone, +możliwe do wywołania i obsługiwane przez załadowany backend runtime. Jeśli ACP jest niedostępne, +prompt systemowy i Skills pluginu nie powinny uczyć agenta routingu +ACP. -## Wdrożenia tylko Codex +## Wdrożenia wyłącznie z Codex -Wymuś harness Codex, gdy musisz udowodnić, że każda osadzona tura agenta -używa Codex. Jawne środowiska wykonawcze pluginów domyślnie nie mają awaryjnego PI, więc +Wymuś mechanizm Codex, gdy musisz dowieść, że każdy osadzony turn agenta +używa Codex. Jawne runtime pluginów domyślnie nie mają zapasowego PI, więc `fallback: "none"` jest opcjonalne, ale często przydatne jako dokumentacja: ```json5 @@ -384,14 +397,14 @@ Nadpisanie środowiskowe: OPENCLAW_AGENT_RUNTIME=codex openclaw gateway run ``` -Gdy Codex jest wymuszony, OpenClaw kończy wcześnie niepowodzeniem, jeśli plugin Codex jest wyłączony, -serwer aplikacji jest zbyt stary albo serwer aplikacji nie może się uruchomić. Ustaw -`OPENCLAW_AGENT_HARNESS_FALLBACK=pi` tylko wtedy, gdy celowo chcesz, aby PI obsłużyło -brakujący wybór harnessu. +Przy wymuszonym Codex OpenClaw kończy się wcześnie niepowodzeniem, jeśli Plugin Codex jest wyłączony, +app-server jest zbyt stary albo app-server nie może się uruchomić. Ustaw +`OPENCLAW_AGENT_HARNESS_FALLBACK=pi` tylko wtedy, gdy celowo chcesz, aby PI obsługiwał +brakujący wybór mechanizmu. -## Codex na agenta +## Codex per agent -Możesz ustawić jednego agenta jako tylko Codex, podczas gdy domyślny agent zachowa normalny +Możesz uczynić jednego agenta wyłącznie Codex, podczas gdy domyślny agent zachowuje normalny automatyczny wybór: ```json5 @@ -423,21 +436,21 @@ automatyczny wybór: } ``` -Używaj normalnych poleceń sesji, aby przełączać agentów i modele. `/new` tworzy nową -sesję OpenClaw, a harness Codex tworzy lub wznawia swój boczny wątek serwera aplikacji +Używaj normalnych poleceń sesji, aby przełączać agentów i modele. `/new` tworzy świeżą +sesję OpenClaw, a mechanizm Codex tworzy lub wznawia swój poboczny wątek app-server w razie potrzeby. `/reset` czyści powiązanie sesji OpenClaw dla tego wątku -i pozwala następnej turze ponownie rozwiązać harness z bieżącej konfiguracji. +i pozwala następnemu turn ponownie rozwiązać mechanizm z bieżącej konfiguracji. ## Wykrywanie modeli -Domyślnie plugin Codex pyta serwer aplikacji o dostępne modele. Jeśli -wykrywanie się nie powiedzie lub przekroczy limit czasu, używa dołączonego katalogu awaryjnego dla: +Domyślnie Plugin Codex pyta app-server o dostępne modele. Jeśli +wykrywanie się nie powiedzie albo przekroczy limit czasu, używa dołączonego katalogu zapasowego dla: - GPT-5.5 - GPT-5.4 mini - GPT-5.2 -Możesz dostroić wykrywanie w `plugins.entries.codex.config.discovery`: +Wykrywanie możesz dostroić pod `plugins.entries.codex.config.discovery`: ```json5 { @@ -457,8 +470,8 @@ Możesz dostroić wykrywanie w `plugins.entries.codex.config.discovery`: } ``` -Wyłącz wykrywanie, gdy chcesz, aby start unikał sondowania Codex i trzymał się -katalogu awaryjnego: +Wyłącz wykrywanie, gdy chcesz, aby uruchamianie unikało sondowania Codex i trzymało się +katalogu zapasowego: ```json5 { @@ -477,26 +490,26 @@ katalogu awaryjnego: } ``` -## Połączenie i polityka serwera aplikacji +## Połączenie i polityka app-server -Domyślnie plugin uruchamia lokalnie zarządzane przez OpenClaw binarium Codex z: +Domyślnie Plugin uruchamia lokalnie zarządzany przez OpenClaw plik binarny Codex z: ```bash codex app-server --listen stdio:// ``` -Zarządzane binarium jest dostarczane z pakietem pluginu `codex`. Dzięki temu -wersja serwera aplikacji jest powiązana z dołączonym pluginem zamiast z dowolnym osobnym -Codex CLI zainstalowanym lokalnie. Ustaw `appServer.command` tylko wtedy, +Zarządzany plik binarny jest dostarczany z pakietem pluginu `codex`. Dzięki temu +wersja app-server jest powiązana z dołączonym pluginem, a nie z dowolnym osobnym +Codex CLI, który akurat jest zainstalowany lokalnie. Ustaw `appServer.command` tylko wtedy, gdy celowo chcesz uruchomić inny plik wykonywalny. -Domyślnie OpenClaw uruchamia lokalne sesje harnessu Codex w trybie YOLO: +Domyślnie OpenClaw uruchamia lokalne sesje mechanizmu Codex w trybie YOLO: `approvalPolicy: "never"`, `approvalsReviewer: "user"` oraz -`sandbox: "danger-full-access"`. To zaufana postawa lokalnego operatora używana -dla autonomicznych Heartbeat: Codex może używać powłoki i narzędzi sieciowych bez -zatrzymywania się na natywnych promptach zatwierdzania, na które nikt nie jest dostępny, aby odpowiedzieć. +`sandbox: "danger-full-access"`. To zaufana lokalna postawa operatora używana +dla autonomicznych Heartbeat: Codex może używać narzędzi powłoki i sieci bez +zatrzymywania się na natywnych promptach zatwierdzania, na które nikt nie jest dostępny odpowiedzieć. -Aby włączyć zatwierdzenia sprawdzane przez strażnika Codex, ustaw `appServer.mode: +Aby włączyć zatwierdzenia przeglądane przez guardiana Codex, ustaw `appServer.mode: "guardian"`: ```json5 @@ -517,11 +530,11 @@ Aby włączyć zatwierdzenia sprawdzane przez strażnika Codex, ustaw `appServer } ``` -Tryb strażnika używa natywnej ścieżki zatwierdzania z automatyczną recenzją Codex. Gdy Codex prosi o -opuszczenie piaskownicy, zapis poza obszarem roboczym albo dodanie uprawnień, takich jak dostęp do sieci, +Tryb Guardian używa natywnej ścieżki zatwierdzania z automatycznym przeglądem Codex. Gdy Codex prosi o +opuszczenie sandboxa, zapis poza workspace albo dodanie uprawnień takich jak dostęp do sieci, Codex kieruje to żądanie zatwierdzenia do natywnego recenzenta zamiast do promptu dla człowieka. Recenzent stosuje ramy ryzyka Codex i zatwierdza lub odrzuca -konkretne żądanie. Użyj Guardiana, gdy chcesz mieć więcej zabezpieczeń niż w trybie YOLO, +konkretne żądanie. Użyj Guardian, gdy chcesz więcej zabezpieczeń niż w trybie YOLO, ale nadal potrzebujesz, aby nienadzorowani agenci robili postępy. Preset `guardian` rozwija się do `approvalPolicy: "on-request"`, @@ -531,7 +544,7 @@ preset z jawnymi wyborami. Starsza wartość recenzenta `guardian_subagent` jest nadal akceptowana jako alias zgodności, ale nowe konfiguracje powinny używać `auto_review`. -Dla już działającego serwera aplikacji użyj transportu WebSocket: +Dla już uruchomionego app-server użyj transportu WebSocket: ```json5 { @@ -553,15 +566,16 @@ Dla już działającego serwera aplikacji użyj transportu WebSocket: } ``` -Uruchomienia serwera aplikacji stdio domyślnie dziedziczą środowisko procesu OpenClaw, -ale OpenClaw jest właścicielem mostka konta serwera aplikacji Codex i ustawia zarówno -`CODEX_HOME`, jak i `HOME` na katalogi per agent w stanie OpenClaw tego agenta. -Własny loader Skills Codex odczytuje `$CODEX_HOME/skills` oraz -`$HOME/.agents/skills`, więc obie wartości są izolowane dla lokalnych uruchomień serwera aplikacji. +Uruchomienia stdio app-server domyślnie dziedziczą środowisko procesu OpenClaw, +ale OpenClaw posiada mostek konta Codex app-server i ustawia zarówno +`CODEX_HOME`, jak i `HOME` na katalogi per-agent w stanie OpenClaw +tego agenta. Własny loader Skills Codex odczytuje `$CODEX_HOME/skills` i +`$HOME/.agents/skills`, więc obie wartości są izolowane dla lokalnych uruchomień app-server. Dzięki temu natywne Skills, pluginy, konfiguracja, konta i stan wątków Codex -są ograniczone do agenta OpenClaw zamiast przenikać z osobistego katalogu domowego Codex CLI operatora. +pozostają ograniczone do agenta OpenClaw, zamiast przenikać z osobistego +katalogu domowego Codex CLI operatora. -Pluginy OpenClaw i migawki Skills OpenClaw nadal przepływają przez własny +Pluginy OpenClaw i snapshoty Skills OpenClaw nadal przepływają przez własny rejestr pluginów i loader Skills OpenClaw. Osobiste zasoby Codex CLI nie. Jeśli masz przydatne Skills lub pluginy Codex CLI, które powinny stać się częścią agenta OpenClaw, zinwentaryzuj je jawnie: @@ -571,27 +585,27 @@ openclaw migrate codex --dry-run openclaw migrate apply codex --yes ``` -Dostawca migracji Codex kopiuje Skills do bieżącego obszaru roboczego agenta OpenClaw. -Natywne pluginy, hooki i pliki konfiguracyjne Codex są raportowane lub archiwizowane -do ręcznego przeglądu zamiast być aktywowane automatycznie, ponieważ mogą -wykonywać polecenia, udostępniać serwery MCP albo zawierać poświadczenia. +Dostawca migracji Codex kopiuje Skills do bieżącego workspace agenta OpenClaw. +Natywne pluginy, hooki i pliki konfiguracji Codex są raportowane lub archiwizowane +do ręcznego przeglądu zamiast automatycznej aktywacji, ponieważ mogą +wykonywać polecenia, udostępniać serwery MCP albo przenosić dane uwierzytelniające. Uwierzytelnianie jest wybierane w tej kolejności: 1. Jawny profil uwierzytelniania OpenClaw Codex dla agenta. -2. Istniejące konto serwera aplikacji w katalogu domowym Codex tego agenta. -3. Tylko dla lokalnych uruchomień serwera aplikacji stdio, `CODEX_API_KEY`, potem - `OPENAI_API_KEY`, gdy nie ma konta serwera aplikacji i uwierzytelnianie OpenAI - jest nadal wymagane. +2. Istniejące konto app-server w katalogu domowym Codex tego agenta. +3. Tylko dla lokalnych uruchomień stdio app-server, `CODEX_API_KEY`, a następnie + `OPENAI_API_KEY`, gdy nie ma konta app-server, a uwierzytelnianie OpenAI jest + nadal wymagane. -Gdy OpenClaw widzi profil uwierzytelniania Codex w stylu subskrypcji ChatGPT, usuwa +Gdy OpenClaw zobaczy profil uwierzytelniania Codex w stylu subskrypcji ChatGPT, usuwa `CODEX_API_KEY` i `OPENAI_API_KEY` z uruchamianego procesu potomnego Codex. Dzięki temu -klucze API na poziomie Gateway pozostają dostępne dla embeddingów lub bezpośrednich modeli OpenAI -bez przypadkowego rozliczania natywnych tur serwera aplikacji Codex przez API. -Jawne profile klucza API Codex oraz lokalne awaryjne użycie kluczy środowiskowych stdio korzystają z logowania serwera aplikacji -zamiast z odziedziczonego środowiska procesu potomnego. Połączenia WebSocket z serwerem aplikacji -nie otrzymują awaryjnych kluczy API środowiska Gateway; użyj jawnego profilu uwierzytelniania albo -własnego konta zdalnego serwera aplikacji. +klucze API na poziomie Gateway pozostają dostępne dla embeddings albo bezpośrednich modeli OpenAI +bez przypadkowego rozliczania natywnych turn Codex app-server przez API. +Jawne profile klucza API Codex i lokalny zapasowy klucz środowiskowy stdio używają logowania app-server +zamiast dziedziczonego środowiska procesu potomnego. Połączenia WebSocket app-server +nie otrzymują zapasowego klucza API ze środowiska Gateway; użyj jawnego profilu uwierzytelniania albo +własnego konta zdalnego app-server. Jeśli wdrożenie wymaga dodatkowej izolacji środowiska, dodaj te zmienne do `appServer.clearEnv`: @@ -613,52 +627,38 @@ Jeśli wdrożenie wymaga dodatkowej izolacji środowiska, dodaj te zmienne do } ``` -`appServer.clearEnv` wpływa tylko na uruchamiany proces potomny serwera aplikacji Codex. +`appServer.clearEnv` wpływa tylko na utworzony proces podrzędny app-server Codex. -Dynamiczne narzędzia Codex domyślnie używają profilu `native-first`. W tym trybie -OpenClaw nie udostępnia dynamicznych narzędzi, które duplikują natywne operacje obszaru roboczego Codex: -`read`, `write`, `edit`, `apply_patch`, `exec`, `process` oraz -`update_plan`. Narzędzia integracyjne OpenClaw, takie jak komunikacja, sesje, media, -Cron, przeglądarka, węzły, Gateway, `heartbeat_respond` oraz `web_search`, pozostają -dostępne. +Narzędzia dynamiczne Codex domyślnie używają profilu `native-first`. W tym trybie OpenClaw nie udostępnia narzędzi dynamicznych, które duplikują natywne operacje obszaru roboczego Codex: `read`, `write`, `edit`, `apply_patch`, `exec`, `process` i `update_plan`. Narzędzia integracyjne OpenClaw, takie jak wiadomości, sesje, media, cron, przeglądarka, węzły, gateway, `heartbeat_respond` i `web_search`, pozostają dostępne. -Obsługiwane pola Plugin najwyższego poziomu Codex: +Obsługiwane pola najwyższego poziomu Pluginu Codex: -| Pole | Domyślnie | Znaczenie | -| -------------------------- | ---------------- | ---------------------------------------------------------------------------------------- | -| `codexDynamicToolsProfile` | `"native-first"` | Użyj `"openclaw-compat"`, aby udostępnić pełny zestaw dynamicznych narzędzi OpenClaw app-serverowi Codex. | -| `codexDynamicToolsExclude` | `[]` | Dodatkowe nazwy dynamicznych narzędzi OpenClaw, które mają zostać pominięte w turach app-servera Codex. | +| Pole | Domyślnie | Znaczenie | +| -------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------ | +| `codexDynamicToolsProfile` | `"native-first"` | Użyj `"openclaw-compat"`, aby udostępnić pełny zestaw narzędzi dynamicznych OpenClaw app-server Codex. | +| `codexDynamicToolsExclude` | `[]` | Dodatkowe nazwy narzędzi dynamicznych OpenClaw pomijane w turach app-server Codex. | Obsługiwane pola `appServer`: -| Pole | Domyślnie | Znaczenie | -| ------------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `transport` | `"stdio"` | `"stdio"` uruchamia Codex; `"websocket"` łączy się z `url`. | -| `command` | zarządzany plik binarny Codex | Plik wykonywalny dla transportu stdio. Pozostaw nieustawione, aby użyć zarządzanego pliku binarnego; ustaw tylko w celu jawnego nadpisania. | -| `args` | `["app-server", "--listen", "stdio://"]` | Argumenty dla transportu stdio. | -| `url` | nieustawione | URL app-servera WebSocket. | -| `authToken` | nieustawione | Token Bearer dla transportu WebSocket. | -| `headers` | `{}` | Dodatkowe nagłówki WebSocket. | -| `clearEnv` | `[]` | Dodatkowe nazwy zmiennych środowiskowych usuwane z uruchomionego procesu app-servera stdio po zbudowaniu przez OpenClaw dziedziczonego środowiska. `CODEX_HOME` i `HOME` są zarezerwowane dla izolacji Codex per agent OpenClaw podczas lokalnych uruchomień. | -| `requestTimeoutMs` | `60000` | Limit czasu dla wywołań płaszczyzny sterowania app-servera. | -| `mode` | `"yolo"` | Preset dla wykonywania YOLO albo sprawdzanego przez opiekuna. | -| `approvalPolicy` | `"never"` | Natywna polityka zatwierdzania Codex wysyłana do startu/wznowienia wątku/tury. | -| `sandbox` | `"danger-full-access"` | Natywny tryb piaskownicy Codex wysyłany do startu/wznowienia wątku. | -| `approvalsReviewer` | `"user"` | Użyj `"auto_review"`, aby Codex sprawdzał natywne monity zatwierdzania. `guardian_subagent` pozostaje starszym aliasem. | -| `serviceTier` | nieustawione | Opcjonalna warstwa usługi app-servera Codex: `"fast"`, `"flex"` albo `null`. Nieprawidłowe starsze wartości są ignorowane. | +| Pole | Domyślnie | Znaczenie | +| ------------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `transport` | `"stdio"` | `"stdio"` uruchamia Codex; `"websocket"` łączy się z `url`. | +| `command` | zarządzany plik binarny Codex | Plik wykonywalny dla transportu stdio. Pozostaw nieustawione, aby użyć zarządzanego pliku binarnego; ustaw tylko przy jawnym nadpisaniu. | +| `args` | `["app-server", "--listen", "stdio://"]` | Argumenty dla transportu stdio. | +| `url` | nieustawione | URL app-server WebSocket. | +| `authToken` | nieustawione | Token bearer dla transportu WebSocket. | +| `headers` | `{}` | Dodatkowe nagłówki WebSocket. | +| `clearEnv` | `[]` | Dodatkowe nazwy zmiennych środowiskowych usuwane z utworzonego procesu app-server stdio po zbudowaniu przez OpenClaw dziedziczonego środowiska. `CODEX_HOME` i `HOME` są zarezerwowane dla lokalnej izolacji Codex per agent OpenClaw. | +| `requestTimeoutMs` | `60000` | Limit czasu dla wywołań płaszczyzny sterowania app-server. | +| `mode` | `"yolo"` | Ustawienie wstępne dla wykonania YOLO lub sprawdzanego przez guardiana. | +| `approvalPolicy` | `"never"` | Natywna polityka zatwierdzania Codex wysyłana przy rozpoczęciu/wznowieniu wątku/turze. | +| `sandbox` | `"danger-full-access"` | Natywny tryb piaskownicy Codex wysyłany przy rozpoczęciu/wznowieniu wątku. | +| `approvalsReviewer` | `"user"` | Użyj `"auto_review"`, aby Codex sprawdzał natywne monity zatwierdzeń. `guardian_subagent` pozostaje starszym aliasem. | +| `serviceTier` | nieustawione | Opcjonalny poziom usługi app-server Codex: `"fast"`, `"flex"` lub `null`. Nieprawidłowe starsze wartości są ignorowane. | -Wywołania dynamicznych narzędzi należących do OpenClaw są ograniczane niezależnie od -`appServer.requestTimeoutMs`: każde żądanie Codex `item/tool/call` musi otrzymać -odpowiedź OpenClaw w ciągu 30 sekund. Po przekroczeniu limitu czasu OpenClaw przerywa -sygnał narzędzia tam, gdzie jest to obsługiwane, i zwraca do Codex nieudaną odpowiedź -dynamicznego narzędzia, aby tura mogła być kontynuowana zamiast pozostawiać sesję w stanie `processing`. +Wywołania narzędzi dynamicznych należące do OpenClaw są ograniczane niezależnie od `appServer.requestTimeoutMs`: każde żądanie Codex `item/tool/call` musi otrzymać odpowiedź OpenClaw w ciągu 30 sekund. Po przekroczeniu limitu czasu OpenClaw przerywa sygnał narzędzia tam, gdzie jest to obsługiwane, i zwraca nieudaną odpowiedź narzędzia dynamicznego do Codex, aby tura mogła być kontynuowana zamiast pozostawiać sesję w stanie `processing`. -Po tym, jak OpenClaw odpowie na żądanie app-servera Codex ograniczone do tury, harness -oczekuje także, że Codex zakończy natywną turę przez `turn/completed`. Jeśli -app-server milczy przez 60 sekund po tej odpowiedzi, OpenClaw w trybie best-effort -przerywa turę Codex, zapisuje diagnostyczne przekroczenie limitu czasu i zwalnia -pas sesji OpenClaw, aby kolejne wiadomości czatu nie były kolejkowane za nieaktualną -natywną turą. +Po tym, jak OpenClaw odpowie na żądanie app-server ograniczone do tury Codex, harness oczekuje również, że Codex zakończy natywną turę komunikatem `turn/completed`. Jeśli app-server milczy przez 60 sekund po tej odpowiedzi, OpenClaw w trybie best-effort przerywa turę Codex, zapisuje diagnostyczny timeout i zwalnia tor sesji OpenClaw, aby kolejne wiadomości czatu nie były kolejkowane za przestarzałą natywną turą. Nadpisania środowiska pozostają dostępne do lokalnego testowania: @@ -668,29 +668,17 @@ Nadpisania środowiska pozostają dostępne do lokalnego testowania: - `OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY` - `OPENCLAW_CODEX_APP_SERVER_SANDBOX` -`OPENCLAW_CODEX_APP_SERVER_BIN` omija zarządzany plik binarny, gdy -`appServer.command` jest nieustawione. +`OPENCLAW_CODEX_APP_SERVER_BIN` omija zarządzany plik binarny, gdy `appServer.command` jest nieustawione. -`OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1` zostało usunięte. Zamiast tego użyj -`plugins.entries.codex.config.appServer.mode: "guardian"` albo -`OPENCLAW_CODEX_APP_SERVER_MODE=guardian` do jednorazowego lokalnego testu. Konfiguracja -jest preferowana w powtarzalnych wdrożeniach, ponieważ utrzymuje zachowanie Plugin -w tym samym sprawdzanym pliku co resztę konfiguracji harnessu Codex. +`OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1` zostało usunięte. Zamiast tego użyj `plugins.entries.codex.config.appServer.mode: "guardian"` albo `OPENCLAW_CODEX_APP_SERVER_MODE=guardian` do jednorazowego lokalnego testowania. Konfiguracja jest preferowana dla powtarzalnych wdrożeń, ponieważ utrzymuje zachowanie Pluginu w tym samym sprawdzanym pliku co resztę konfiguracji harnessu Codex. ## Użycie komputera -Użycie komputera opisano w osobnym przewodniku konfiguracji: -[Użycie komputera w Codex](/pl/plugins/codex-computer-use). +Computer Use jest omówione we własnym przewodniku konfiguracji: [Codex Computer Use](/pl/plugins/codex-computer-use). -W skrócie: OpenClaw nie vendoryzuje aplikacji do sterowania pulpitem ani samodzielnie -nie wykonuje działań na pulpicie. Przygotowuje app-server Codex, weryfikuje, że -serwer MCP `computer-use` jest dostępny, a następnie pozwala Codex obsłużyć natywne -wywołania narzędzi MCP podczas tur w trybie Codex. +W skrócie: OpenClaw nie dostarcza w pakiecie aplikacji sterowania pulpitem ani samodzielnie nie wykonuje akcji na pulpicie. Przygotowuje app-server Codex, weryfikuje dostępność serwera MCP `computer-use`, a następnie pozwala Codex obsługiwać natywne wywołania narzędzi MCP podczas tur w trybie Codex. -Aby uzyskać bezpośredni dostęp do sterownika TryCua poza przepływem marketplace Codex, zarejestruj -`cua-driver mcp` poleceniem `openclaw mcp set cua-driver '{"command":"cua-driver","args":["mcp"]}'`. -Zobacz [Użycie komputera w Codex](/pl/plugins/codex-computer-use), aby poznać różnicę -między użyciem komputera należącym do Codex a bezpośrednią rejestracją MCP. +Aby uzyskać bezpośredni dostęp sterownika TryCua poza przepływem marketplace Codex, zarejestruj `cua-driver mcp` za pomocą `openclaw mcp set cua-driver '{"command":"cua-driver","args":["mcp"]}'`. Zobacz [Codex Computer Use](/pl/plugins/codex-computer-use), aby poznać różnicę między Computer Use należącym do Codex a bezpośrednią rejestracją MCP. Minimalna konfiguracja: @@ -727,19 +715,9 @@ Konfigurację można sprawdzić lub zainstalować z powierzchni poleceń: - `/codex computer-use install --source ` - `/codex computer-use install --marketplace-path ` -Użycie komputera jest specyficzne dla systemu macOS i może wymagać lokalnych uprawnień systemu operacyjnego, zanim -serwer MCP Codex będzie mógł sterować aplikacjami. Jeśli `computerUse.enabled` ma wartość true, a serwer MCP -jest niedostępny, tury w trybie Codex kończą się niepowodzeniem przed uruchomieniem wątku zamiast -po cichu działać bez natywnych narzędzi użycia komputera. Zobacz -[Użycie komputera w Codex](/pl/plugins/codex-computer-use), aby poznać wybory marketplace, -limity zdalnego katalogu, przyczyny statusu i rozwiązywanie problemów. +Computer Use jest specyficzne dla macOS i może wymagać lokalnych uprawnień systemu operacyjnego, zanim serwer MCP Codex będzie mógł sterować aplikacjami. Jeśli `computerUse.enabled` ma wartość true, a serwer MCP jest niedostępny, tury w trybie Codex kończą się niepowodzeniem przed rozpoczęciem wątku, zamiast cicho działać bez natywnych narzędzi Computer Use. Zobacz [Codex Computer Use](/pl/plugins/codex-computer-use), aby poznać opcje marketplace, limity zdalnego katalogu, przyczyny statusu i rozwiązywanie problemów. -Gdy `computerUse.autoInstall` ma wartość true, OpenClaw może zarejestrować standardowy -dołączony marketplace Codex Desktop z -`/Applications/Codex.app/Contents/Resources/plugins/openai-bundled`, jeśli Codex -nie wykrył jeszcze lokalnego marketplace. Użyj `/new` albo `/reset` po -zmianie konfiguracji runtime lub użycia komputera, aby istniejące sesje nie zachowały starego -powiązania wątku PI lub Codex. +Gdy `computerUse.autoInstall` ma wartość true, OpenClaw może zarejestrować standardowy dołączony marketplace Codex Desktop z `/Applications/Codex.app/Contents/Resources/plugins/openai-bundled`, jeśli Codex nie wykrył jeszcze lokalnego marketplace. Użyj `/new` lub `/reset` po zmianie konfiguracji środowiska uruchomieniowego albo Computer Use, aby istniejące sesje nie zachowywały starego powiązania z PI lub wątkiem Codex. ## Typowe przepisy @@ -757,7 +735,7 @@ Lokalny Codex z domyślnym transportem stdio: } ``` -Walidacja harnessu tylko Codex: +Walidacja harnessu tylko dla Codex: ```json5 { @@ -779,7 +757,7 @@ Walidacja harnessu tylko Codex: } ``` -Zatwierdzenia Codex sprawdzane przez opiekuna: +Zatwierdzenia Codex sprawdzane przez guardiana: ```json5 { @@ -824,263 +802,252 @@ Zdalny app-server z jawnymi nagłówkami: } ``` -Przełączanie modeli pozostaje kontrolowane przez OpenClaw. Gdy sesja OpenClaw jest dołączona -do istniejącego wątku Codex, następna tura ponownie wysyła aktualnie wybrany -model OpenAI, dostawcę, politykę zatwierdzania, piaskownicę i warstwę usługi do -app-servera. Przełączenie z `openai/gpt-5.5` na `openai/gpt-5.2` zachowuje -powiązanie wątku, ale prosi Codex o kontynuowanie z nowo wybranym modelem. +Przełączanie modelu pozostaje kontrolowane przez OpenClaw. Gdy sesja OpenClaw jest dołączona do istniejącego wątku Codex, następna tura ponownie wysyła aktualnie wybrany model OpenAI, dostawcę, politykę zatwierdzania, piaskownicę i poziom usługi do app-server. Przełączenie z `openai/gpt-5.5` na `openai/gpt-5.2` zachowuje powiązanie wątku, ale prosi Codex o kontynuowanie z nowo wybranym modelem. ## Polecenie Codex -Dołączony Plugin rejestruje `/codex` jako autoryzowane polecenie z ukośnikiem. Jest -ogólne i działa na każdym kanale obsługującym polecenia tekstowe OpenClaw. +Dołączony Plugin rejestruje `/codex` jako autoryzowane polecenie ukośnikowe. Jest ono ogólne i działa na każdym kanale obsługującym polecenia tekstowe OpenClaw. Typowe formy: -- `/codex status` pokazuje aktywną łączność app-servera, modele, konto, limity użycia, serwery MCP i Skills. -- `/codex models` wyświetla modele aktywnego app-servera Codex. +- `/codex status` pokazuje aktywną łączność z serwerem aplikacji, modele, konto, limity szybkości, serwery MCP oraz Skills. +- `/codex models` wyświetla modele aktywnego serwera aplikacji Codex. - `/codex threads [filter]` wyświetla ostatnie wątki Codex. - `/codex resume ` dołącza bieżącą sesję OpenClaw do istniejącego wątku Codex. -- `/codex compact` prosi app-server Codex o skompaktowanie dołączonego wątku. -- `/codex review` uruchamia natywne sprawdzanie Codex dla dołączonego wątku. -- `/codex diagnostics [note]` pyta przed wysłaniem opinii diagnostycznej Codex dla dołączonego wątku. -- `/codex computer-use status` sprawdza skonfigurowany Plugin użycia komputera i serwer MCP. -- `/codex computer-use install` instaluje skonfigurowany Plugin użycia komputera i przeładowuje serwery MCP. -- `/codex account` pokazuje konto i status limitów użycia. -- `/codex mcp` wyświetla status serwerów MCP app-servera Codex. -- `/codex skills` wyświetla Skills app-servera Codex. +- `/codex compact` prosi serwer aplikacji Codex o skompaktowanie dołączonego wątku. +- `/codex review` uruchamia natywną recenzję Codex dla dołączonego wątku. +- `/codex diagnostics [note]` pyta przed wysłaniem opinii diagnostycznej Codex dotyczącej dołączonego wątku. +- `/codex computer-use status` sprawdza skonfigurowany plugin Computer Use i serwer MCP. +- `/codex computer-use install` instaluje skonfigurowany plugin Computer Use i przeładowuje serwery MCP. +- `/codex account` pokazuje stan konta i limitów szybkości. +- `/codex mcp` wyświetla stan serwerów MCP serwera aplikacji Codex. +- `/codex skills` wyświetla Skills serwera aplikacji Codex. ### Typowy przepływ debugowania Gdy agent oparty na Codex zrobi coś zaskakującego w Telegram, Discord, Slack lub innym kanale, zacznij od rozmowy, w której wystąpił problem: -1. Uruchom `/diagnostics bad tool choice after image upload` albo inną krótką notatkę - opisującą to, co zobaczyłeś. -2. Zatwierdź żądanie diagnostyki raz. Zatwierdzenie tworzy lokalny plik zip - diagnostyki Gateway, a ponieważ sesja używa warstwy uruchomieniowej Codex, - wysyła też odpowiedni pakiet opinii Codex na serwery OpenAI. -3. Skopiuj ukończoną odpowiedź diagnostyczną do zgłoszenia błędu albo wątku - wsparcia. Zawiera ona lokalną ścieżkę pakietu, podsumowanie prywatności, - identyfikatory sesji OpenClaw, identyfikatory wątków Codex oraz wiersz - `Inspect locally` dla każdego wątku Codex. -4. Jeśli chcesz samodzielnie debugować przebieg, uruchom wypisane polecenie - `Inspect locally` w terminalu. Wygląda ono jak `codex resume ` i - otwiera natywny wątek Codex, aby można było przejrzeć rozmowę, kontynuować ją - lokalnie albo zapytać Codex, dlaczego wybrał konkretne narzędzie lub plan. +1. Uruchom `/diagnostics bad tool choice after image upload` albo inną krótką notatkę, + która opisuje to, co widzisz. +2. Zatwierdź żądanie diagnostyki raz. Zatwierdzenie tworzy lokalny pakiet zip diagnostyki + Gateway i, ponieważ sesja używa środowiska uruchomieniowego Codex, wysyła też + odpowiedni pakiet opinii Codex na serwery OpenAI. +3. Skopiuj ukończoną odpowiedź diagnostyczną do zgłoszenia błędu albo wątku pomocy. + Zawiera ona ścieżkę lokalnego pakietu, podsumowanie prywatności, identyfikatory sesji OpenClaw, + identyfikatory wątków Codex oraz wiersz `Inspect locally` dla każdego wątku Codex. +4. Jeśli chcesz samodzielnie debugować przebieg, uruchom wypisane polecenie `Inspect locally` + w terminalu. Wygląda ono jak `codex resume ` i otwiera + natywny wątek Codex, aby można było przejrzeć rozmowę, kontynuować ją lokalnie + albo zapytać Codex, dlaczego wybrał konkretne narzędzie lub plan. Używaj `/codex diagnostics [note]` tylko wtedy, gdy konkretnie chcesz przesłać -opinię Codex dla aktualnie dołączonego wątku bez pełnego lokalnego pakietu -diagnostycznego OpenClaw Gateway. W przypadku większości zgłoszeń do wsparcia -`/diagnostics [note]` jest lepszym punktem wyjścia, ponieważ łączy lokalny stan -Gateway i identyfikatory wątków Codex w jednej odpowiedzi. Zobacz [Eksport diagnostyki](/pl/gateway/diagnostics), +opinię Codex dla aktualnie dołączonego wątku bez pełnego pakietu diagnostyki +OpenClaw Gateway. W większości zgłoszeń do pomocy lepszym punktem wyjścia jest +`/diagnostics [note]`, ponieważ wiąże lokalny stan Gateway i identyfikatory +wątków Codex w jednej odpowiedzi. Zobacz [Eksport diagnostyki](/pl/gateway/diagnostics), aby poznać pełny model prywatności i zachowanie w czatach grupowych. -Rdzeń OpenClaw udostępnia też przeznaczone tylko dla właściciela -`/diagnostics [note]` jako ogólne polecenie diagnostyczne Gateway. Monit -zatwierdzenia pokazuje wstęp dotyczący danych wrażliwych, zawiera link do -[Eksport diagnostyki](/pl/gateway/diagnostics) i za każdym razem żąda -`openclaw gateway diagnostics export --json` przez jawne zatwierdzenie exec. -Nie zatwierdzaj diagnostyki regułą allow-all. Po zatwierdzeniu OpenClaw wysyła -raport gotowy do wklejenia, zawierający lokalną ścieżkę pakietu i podsumowanie -manifestu. Gdy aktywna sesja OpenClaw używa warstwy uruchomieniowej Codex, to -samo zatwierdzenie autoryzuje też wysłanie odpowiednich pakietów opinii Codex na -serwery OpenAI. Monit zatwierdzenia informuje, że opinia Codex zostanie wysłana, -ale przed zatwierdzeniem nie podaje identyfikatorów sesji ani wątków Codex. +Rdzeń OpenClaw udostępnia też dostępne tylko dla właściciela `/diagnostics [note]` jako ogólne +polecenie diagnostyki Gateway. Jego monit zatwierdzenia pokazuje wstęp dotyczący +danych wrażliwych, odsyła do [Eksport diagnostyki](/pl/gateway/diagnostics) i za każdym razem +żąda wykonania `openclaw gateway diagnostics export --json` przez jawne zatwierdzenie wykonania. +Nie zatwierdzaj diagnostyki regułą zezwalającą na wszystko. Po zatwierdzeniu +OpenClaw wysyła raport gotowy do wklejenia ze ścieżką lokalnego pakietu i +podsumowaniem manifestu. Gdy aktywna sesja OpenClaw używa środowiska uruchomieniowego +Codex, to samo zatwierdzenie autoryzuje również wysłanie odpowiednich pakietów opinii Codex +na serwery OpenAI. Monit zatwierdzenia informuje, że opinia Codex zostanie wysłana, ale +przed zatwierdzeniem nie wymienia identyfikatorów sesji ani wątków Codex. -Jeśli `/diagnostics` zostanie wywołane przez właściciela w czacie grupowym, -OpenClaw utrzymuje wspólny kanał w czystości: grupa otrzymuje tylko krótką -notatkę, a wstęp diagnostyczny, monity zatwierdzenia oraz identyfikatory -sesji/wątków Codex są wysyłane do właściciela prywatną ścieżką zatwierdzania. -Jeśli prywatna ścieżka właściciela nie istnieje, OpenClaw odmawia obsługi -żądania z grupy i prosi właściciela o uruchomienie go z DM. +Jeśli `/diagnostics` zostanie wywołane przez właściciela w czacie grupowym, OpenClaw utrzymuje +współdzielony kanał w czystości: grupa otrzymuje tylko krótkie powiadomienie, a +wstęp diagnostyki, monity zatwierdzenia oraz identyfikatory sesji/wątków Codex są wysyłane do +właściciela prywatną ścieżką zatwierdzania. Jeśli nie ma prywatnej ścieżki właściciela, +OpenClaw odrzuca żądanie grupowe i prosi właściciela o uruchomienie go z wiadomości prywatnej. -Zatwierdzone przesłanie Codex wywołuje `feedback/upload` app-server Codex i -prosi app-server o dołączenie logów dla każdego wymienionego wątku oraz -utworzonych podwątków Codex, gdy są dostępne. Przesyłanie odbywa się zwykłą -ścieżką opinii Codex na serwery OpenAI; jeśli opinie Codex są wyłączone w tym -app-server, polecenie zwraca błąd app-server. Ukończona odpowiedź diagnostyczna -wymienia kanały, identyfikatory sesji OpenClaw, identyfikatory wątków Codex oraz -lokalne polecenia `codex resume ` dla wysłanych wątków. Jeśli -odmówisz zatwierdzenia albo je zignorujesz, OpenClaw nie wypisze tych -identyfikatorów Codex. To przesłanie nie zastępuje lokalnego eksportu -diagnostyki Gateway. +Zatwierdzone przesłanie Codex wywołuje `feedback/upload` serwera aplikacji Codex i prosi +serwer aplikacji o dołączenie logów dla każdego wymienionego wątku oraz utworzonych podwątków Codex, +gdy są dostępne. Przesłanie przechodzi standardową ścieżką opinii Codex na serwery OpenAI; +jeśli opinie Codex są wyłączone w tym serwerze aplikacji, polecenie zwraca błąd +serwera aplikacji. Ukończona odpowiedź diagnostyczna wymienia kanały, +identyfikatory sesji OpenClaw, identyfikatory wątków Codex oraz lokalne polecenia `codex resume ` +dla wysłanych wątków. Jeśli odmówisz zatwierdzenia lub je zignorujesz, +OpenClaw nie wypisze tych identyfikatorów Codex. To przesłanie nie zastępuje lokalnego +eksportu diagnostyki Gateway. -`/codex resume` zapisuje ten sam plik powiązań sidecar, którego warstwa -uruchomieniowa używa dla zwykłych tur. Przy następnej wiadomości OpenClaw -wznawia ten wątek Codex, przekazuje aktualnie wybrany model OpenClaw do -app-server i utrzymuje włączoną rozszerzoną historię. +`/codex resume` zapisuje ten sam plik powiązania towarzyszącego, którego środowisko uruchomieniowe używa dla +zwykłych tur. Przy następnej wiadomości OpenClaw wznawia ten wątek Codex, przekazuje +aktualnie wybrany model OpenClaw do serwera aplikacji i utrzymuje włączoną rozszerzoną historię. -### Sprawdź wątek Codex z CLI +### Inspekcja wątku Codex z CLI -Najszybszym sposobem zrozumienia nieudanego przebiegu Codex często jest -bezpośrednie otwarcie natywnego wątku Codex: +Najszybszym sposobem zrozumienia błędnego przebiegu Codex jest często bezpośrednie otwarcie +natywnego wątku Codex: ```sh codex resume ``` -Użyj tego, gdy zauważysz błąd w rozmowie kanału i chcesz sprawdzić problematyczną -sesję Codex, kontynuować ją lokalnie albo zapytać Codex, dlaczego podjął -konkretną decyzję dotyczącą narzędzia lub rozumowania. Najłatwiejszą ścieżką -zwykle jest najpierw uruchomienie `/diagnostics [note]`: po zatwierdzeniu -ukończony raport wymienia każdy wątek Codex i wypisuje polecenie -`Inspect locally`, na przykład `codex resume `. Możesz skopiować to -polecenie bezpośrednio do terminala. +Użyj tego, gdy zauważysz błąd w rozmowie kanałowej i chcesz przejrzeć +problematyczną sesję Codex, kontynuować ją lokalnie albo zapytać Codex, dlaczego dokonał +konkretnego wyboru narzędzia lub rozumowania. Najłatwiejszą ścieżką jest zwykle najpierw uruchomienie +`/diagnostics [note]`: po zatwierdzeniu ukończony raport wymienia +każdy wątek Codex i wypisuje polecenie `Inspect locally`, na przykład +`codex resume `. Możesz skopiować to polecenie bezpośrednio do terminala. -Możesz też uzyskać identyfikator wątku z `/codex binding` dla bieżącego czatu -albo z `/codex threads [filter]` dla ostatnich wątków app-server Codex, a potem -uruchomić to samo polecenie `codex resume` w powłoce. +Identyfikator wątku możesz też uzyskać z `/codex binding` dla bieżącego czatu albo +`/codex threads [filter]` dla ostatnich wątków serwera aplikacji Codex, a następnie uruchomić to samo +polecenie `codex resume` w swojej powłoce. -Powierzchnia poleceń wymaga app-server Codex `0.125.0` lub nowszego. Poszczególne +Powierzchnia poleceń wymaga serwera aplikacji Codex `0.125.0` lub nowszego. Poszczególne metody sterowania są zgłaszane jako `unsupported by this Codex app-server`, jeśli -przyszły lub niestandardowy app-server nie udostępnia tej metody JSON-RPC. +przyszły lub niestandardowy serwer aplikacji nie udostępnia tej metody JSON-RPC. ## Granice hooków -Warstwa uruchomieniowa Codex ma trzy warstwy hooków: +Środowisko uruchomieniowe Codex ma trzy warstwy hooków: | Warstwa | Właściciel | Cel | | ------------------------------------- | ------------------------ | ------------------------------------------------------------------- | -| Hooki pluginów OpenClaw | OpenClaw | Zgodność produktu/pluginów w warstwach uruchomieniowych PI i Codex. | -| Middleware rozszerzeń app-server Codex | Wbudowane pluginy OpenClaw | Zachowanie adaptera dla każdej tury wokół narzędzi dynamicznych OpenClaw. | +| Hooki pluginów OpenClaw | OpenClaw | Zgodność produktu/pluginów między środowiskami PI i Codex. | +| Middleware rozszerzeń serwera aplikacji Codex | Wbudowane pluginy OpenClaw | Zachowanie adaptera na turę wokół dynamicznych narzędzi OpenClaw. | | Natywne hooki Codex | Codex | Niskopoziomowy cykl życia Codex i natywna polityka narzędzi z konfiguracji Codex. | -OpenClaw nie używa projektowych ani globalnych plików Codex `hooks.json` do -kierowania zachowaniem pluginów OpenClaw. Dla obsługiwanego mostu natywnych -narzędzi i uprawnień OpenClaw wstrzykuje konfigurację Codex dla każdego wątku dla -`PreToolUse`, `PostToolUse`, `PermissionRequest` i `Stop`. Inne hooki Codex, -takie jak `SessionStart` i `UserPromptSubmit`, pozostają kontrolkami na poziomie -Codex; nie są udostępniane jako hooki pluginów OpenClaw w kontrakcie v1. +OpenClaw nie używa projektowych ani globalnych plików Codex `hooks.json` do kierowania +zachowaniem pluginów OpenClaw. Dla obsługiwanego mostu natywnych narzędzi i uprawnień +OpenClaw wstrzykuje konfigurację Codex na wątek dla `PreToolUse`, `PostToolUse`, +`PermissionRequest` i `Stop`. Inne hooki Codex, takie jak `SessionStart` i +`UserPromptSubmit`, pozostają kontrolkami poziomu Codex; nie są udostępniane jako +hooki pluginów OpenClaw w kontrakcie v1. -W przypadku narzędzi dynamicznych OpenClaw, OpenClaw wykonuje narzędzie po tym, -jak Codex poprosi o wywołanie, więc OpenClaw uruchamia zachowanie pluginów i -middleware, które posiada, w adapterze warstwy uruchomieniowej. W przypadku -narzędzi natywnych Codex to Codex posiada kanoniczny rekord narzędzia. OpenClaw -może odzwierciedlać wybrane zdarzenia, ale nie może przepisać natywnego wątku -Codex, chyba że Codex udostępni taką operację przez app-server albo wywołania -zwrotne natywnych hooków. +W przypadku dynamicznych narzędzi OpenClaw OpenClaw wykonuje narzędzie po tym, jak Codex poprosi o +wywołanie, więc OpenClaw uruchamia zachowanie pluginów i middleware, których jest właścicielem, w +adapterze środowiska uruchomieniowego. W przypadku narzędzi natywnych Codex właścicielem kanonicznego rekordu narzędzia jest Codex. +OpenClaw może odzwierciedlać wybrane zdarzenia, ale nie może przepisać natywnego wątku Codex, +chyba że Codex udostępni taką operację przez serwer aplikacji albo wywołania zwrotne natywnych hooków. -Projekcje cyklu życia Compaction i LLM pochodzą z powiadomień app-server Codex -oraz stanu adaptera OpenClaw, a nie z poleceń natywnych hooków Codex. Zdarzenia -OpenClaw `before_compaction`, `after_compaction`, `llm_input` i `llm_output` są -obserwacjami na poziomie adaptera, a nie przechwyceniami bajt po bajcie -wewnętrznych żądań Codex ani payloadów Compaction. +Projekcje cyklu życia Compaction i LLM pochodzą z powiadomień serwera aplikacji Codex +oraz stanu adaptera OpenClaw, a nie z natywnych poleceń hooków Codex. +Zdarzenia `before_compaction`, `after_compaction`, `llm_input` i +`llm_output` OpenClaw są obserwacjami na poziomie adaptera, a nie przechwyceniami bajt po bajcie +wewnętrznego żądania Codex ani ładunków Compaction. -Natywne powiadomienia app-server Codex `hook/started` i `hook/completed` są -projektowane jako zdarzenia agenta `codex_app_server.hook` na potrzeby -trajektorii i debugowania. Nie wywołują hooków pluginów OpenClaw. +Natywne powiadomienia serwera aplikacji Codex `hook/started` i `hook/completed` są +projektowane jako zdarzenia agenta `codex_app_server.hook` na potrzeby trajektorii i debugowania. +Nie wywołują hooków pluginów OpenClaw. -## Kontrakt obsługi V1 +## Kontrakt wsparcia v1 -Tryb Codex nie jest PI z innym wywołaniem modelu pod spodem. Codex posiada większą -część natywnej pętli modelu, a OpenClaw dostosowuje swoje powierzchnie pluginów i -sesji wokół tej granicy. +Tryb Codex nie jest PI z innym wywołaniem modelu pod spodem. Codex jest właścicielem większej części +natywnej pętli modelu, a OpenClaw dostosowuje swoje powierzchnie pluginów i sesji +wokół tej granicy. -Obsługiwane w środowisku uruchomieniowym Codex v1: +Obsługiwane w środowisku wykonawczym Codex v1: -| Powierzchnia | Obsługa | Dlaczego | -| --------------------------------------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Pętla modelu OpenAI przez Codex | Obsługiwane | App-server Codex posiada turę OpenAI, natywne wznowienie wątku i natywną kontynuację narzędzia. | -| Routing i dostarczanie kanałów OpenClaw | Obsługiwane | Telegram, Discord, Slack, WhatsApp, iMessage i inne kanały pozostają poza środowiskiem uruchomieniowym modelu. | -| Narzędzia dynamiczne OpenClaw | Obsługiwane | Codex prosi OpenClaw o wykonanie tych narzędzi, więc OpenClaw pozostaje na ścieżce wykonania. | -| Pluginy promptów i kontekstu | Obsługiwane | OpenClaw buduje nakładki promptów i projektuje kontekst do tury Codex przed uruchomieniem albo wznowieniem wątku. | -| Cykl życia silnika kontekstu | Obsługiwane | Składanie, ingest albo konserwacja po turze oraz koordynacja Compaction silnika kontekstu działają dla tur Codex. | -| Hooki narzędzi dynamicznych | Obsługiwane | `before_tool_call`, `after_tool_call` i middleware wyników narzędzi działają wokół narzędzi dynamicznych należących do OpenClaw. | -| Hooki cyklu życia | Obsługiwane jako obserwacje adaptera | `llm_input`, `llm_output`, `agent_end`, `before_compaction` i `after_compaction` uruchamiają się z uczciwymi payloadami trybu Codex. | -| Bramka rewizji odpowiedzi końcowej | Obsługiwane przez przekaźnik natywnych hooków | Codex `Stop` jest przekazywany do `before_agent_finalize`; `revise` prosi Codex o jeszcze jedno przejście modelu przed finalizacją. | -| Blokowanie albo obserwowanie natywnej powłoki, patchy i MCP | Obsługiwane przez przekaźnik natywnych hooków | Codex `PreToolUse` i `PostToolUse` są przekazywane dla zatwierdzonych natywnych powierzchni narzędzi, w tym payloadów MCP w app-server Codex `0.125.0` lub nowszym. Blokowanie jest obsługiwane; przepisywanie argumentów nie jest. | -| Natywna polityka uprawnień | Obsługiwane przez przekaźnik natywnych hooków | Codex `PermissionRequest` może być kierowane przez politykę OpenClaw tam, gdzie środowisko uruchomieniowe ją udostępnia. Jeśli OpenClaw nie zwróci decyzji, Codex kontynuuje przez zwykłą ścieżkę guardiana albo zatwierdzenia użytkownika. | -| Przechwytywanie trajektorii app-server | Obsługiwane | OpenClaw rejestruje żądanie wysłane do app-server i powiadomienia app-server, które otrzymuje. | +| Powierzchnia | Wsparcie | Dlaczego | +| --------------------------------------------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Pętla modelu OpenAI przez Codex | Obsługiwane | Serwer aplikacji Codex jest właścicielem tury OpenAI, wznowienia natywnego wątku i kontynuacji natywnych narzędzi. | +| Trasowanie i dostarczanie kanałów OpenClaw | Obsługiwane | Telegram, Discord, Slack, WhatsApp, iMessage i inne kanały pozostają poza środowiskiem wykonawczym modelu. | +| Dynamiczne narzędzia OpenClaw | Obsługiwane | Codex prosi OpenClaw o wykonanie tych narzędzi, więc OpenClaw pozostaje na ścieżce wykonania. | +| Pluginy promptów i kontekstu | Obsługiwane | OpenClaw buduje nakładki promptu i projektuje kontekst do tury Codex przed rozpoczęciem lub wznowieniem wątku. | +| Cykl życia silnika kontekstu | Obsługiwane | Składanie, pobieranie lub konserwacja po turze oraz koordynacja Compaction silnika kontekstu działają dla tur Codex. | +| Hooki narzędzi dynamicznych | Obsługiwane | `before_tool_call`, `after_tool_call` i middleware wyników narzędzi działają wokół dynamicznych narzędzi, których właścicielem jest OpenClaw. | +| Hooki cyklu życia | Obsługiwane jako obserwacje adaptera | `llm_input`, `llm_output`, `agent_end`, `before_compaction` i `after_compaction` uruchamiają się z uczciwymi ładunkami trybu Codex. | +| Bramka rewizji odpowiedzi końcowej | Obsługiwane przez przekaźnik natywnych hooków | Codex `Stop` jest przekazywany do `before_agent_finalize`; `revise` prosi Codex o jeszcze jedno przejście modelu przed finalizacją. | +| Blokowanie lub obserwacja natywnej powłoki, poprawek i MCP | Obsługiwane przez przekaźnik natywnych hooków | Codex `PreToolUse` i `PostToolUse` są przekazywane dla zatwierdzonych natywnych powierzchni narzędzi, w tym ładunków MCP na serwerze aplikacji Codex `0.125.0` lub nowszym. Blokowanie jest obsługiwane; przepisywanie argumentów nie. | +| Natywna polityka uprawnień | Obsługiwane przez przekaźnik natywnych hooków | Codex `PermissionRequest` może być trasowany przez politykę OpenClaw tam, gdzie środowisko wykonawcze ją udostępnia. Jeśli OpenClaw nie zwróci żadnej decyzji, Codex kontynuuje przez swoją normalną ścieżkę strażnika lub zatwierdzenia użytkownika. | +| Przechwytywanie trajektorii serwera aplikacji | Obsługiwane | OpenClaw rejestruje żądanie wysłane do serwera aplikacji oraz otrzymywane od niego powiadomienia. | -Nieobsługiwane w środowisku uruchomieniowym Codex v1: +Nieobsługiwane w środowisku wykonawczym Codex v1: -| Powierzchnia | Granica V1 | Przyszła ścieżka | +| Powierzchnia | Granica V1 | Przyszła ścieżka | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | -| Modyfikacja argumentów natywnych narzędzi | Natywne haki Codex przed narzędziem mogą blokować, ale OpenClaw nie przepisuje argumentów narzędzi natywnych dla Codex. | Wymaga obsługi haków/schematu Codex dla zastępczych danych wejściowych narzędzia. | -| Edytowalna historia natywnej transkrypcji Codex | Codex jest właścicielem kanonicznej historii natywnego wątku. OpenClaw ma lustro i może projektować przyszły kontekst, ale nie powinien modyfikować nieobsługiwanych elementów wewnętrznych. | Dodaj jawne API serwera aplikacji Codex, jeśli potrzebna jest chirurgiczna edycja natywnego wątku. | -| `tool_result_persist` dla natywnych rekordów narzędzi Codex | Ten hak przekształca zapisy transkrypcji należące do OpenClaw, a nie natywne rekordy narzędzi Codex. | Można odzwierciedlać przekształcone rekordy, ale kanoniczne przepisanie wymaga obsługi Codex. | +| Mutacja argumentów natywnych narzędzi | Natywne haki Codex przed użyciem narzędzia mogą blokować, ale OpenClaw nie przepisuje argumentów narzędzi natywnych dla Codex. | Wymaga obsługi haków/schematu Codex dla zastępczych danych wejściowych narzędzia. | +| Edytowalna historia transkryptu natywnego Codex | Codex posiada kanoniczną natywną historię wątku. OpenClaw posiada kopię lustrzaną i może projektować przyszły kontekst, ale nie powinien mutować nieobsługiwanych elementów wewnętrznych. | Dodać jawne API serwera aplikacji Codex, jeśli potrzebna jest chirurgiczna edycja natywnego wątku. | +| `tool_result_persist` dla rekordów narzędzi natywnych Codex | Ten hak przekształca zapisy transkryptu należące do OpenClaw, a nie rekordy narzędzi natywnych Codex. | Można kopiować lustrzanie przekształcone rekordy, ale kanoniczne przepisywanie wymaga obsługi Codex. | | Bogate natywne metadane Compaction | OpenClaw obserwuje rozpoczęcie i zakończenie Compaction, ale nie otrzymuje stabilnej listy zachowanych/usuniętych elementów, delty tokenów ani ładunku podsumowania. | Wymaga bogatszych zdarzeń Compaction w Codex. | -| Interwencja w Compaction | Obecne haki Compaction OpenClaw są w trybie Codex na poziomie powiadomień. | Dodaj haki Codex przed/po Compaction, jeśli pluginy muszą wetować lub przepisywać natywną Compaction. | -| Przechwytywanie żądania API modelu bajt po bajcie | OpenClaw może przechwytywać żądania i powiadomienia serwera aplikacji, ale rdzeń Codex wewnętrznie buduje końcowe żądanie API OpenAI. | Wymaga zdarzenia śledzenia żądania modelu Codex albo API debugowania. | +| Interwencja w Compaction | Obecne haki Compaction OpenClaw w trybie Codex działają na poziomie powiadomień. | Dodać haki Codex przed/po Compaction, jeśli pluginy muszą wetować lub przepisywać natywną Compaction. | +| Przechwytywanie żądania API modelu bajt po bajcie | OpenClaw może przechwytywać żądania i powiadomienia serwera aplikacji, ale rdzeń Codex wewnętrznie buduje finalne żądanie API OpenAI. | Wymaga zdarzenia śledzenia żądania modelu Codex albo API debugowania. | ## Narzędzia, media i Compaction -Harness Codex zmienia tylko niskopoziomowy wykonawca osadzonego agenta. +Uprząż Codex zmienia tylko niskopoziomowy osadzony executor agenta. OpenClaw nadal buduje listę narzędzi i odbiera dynamiczne wyniki narzędzi z -harnessu. Tekst, obrazy, wideo, muzyka, TTS, zatwierdzenia i dane wyjściowe -narzędzia wiadomości nadal przechodzą przez normalną ścieżkę dostarczania +uprzęży. Tekst, obrazy, wideo, muzyka, TTS, zatwierdzenia i dane wyjściowe +narzędzi komunikacyjnych nadal przechodzą przez normalną ścieżkę dostarczania OpenClaw. -Natywny przekaźnik haków jest celowo ogólny, ale kontrakt obsługi v1 jest +Natywny przekaźnik haków jest celowo generyczny, ale kontrakt obsługi v1 jest ograniczony do natywnych dla Codex ścieżek narzędzi i uprawnień, które testuje -OpenClaw. W środowisku uruchomieniowym Codex obejmuje to ładunki shell, patch i MCP `PreToolUse`, -`PostToolUse` oraz `PermissionRequest`. Nie zakładaj, że każde przyszłe -zdarzenie haka Codex jest powierzchnią Plugin OpenClaw, dopóki kontrakt środowiska uruchomieniowego jej -nie nazwie. +OpenClaw. W środowisku uruchomieniowym Codex obejmuje to ładunki shell, patch i MCP +`PreToolUse`, `PostToolUse` oraz `PermissionRequest`. Nie zakładaj, że każde przyszłe +zdarzenie haka Codex jest powierzchnią pluginu OpenClaw, dopóki nie nazwie go +kontrakt środowiska uruchomieniowego. Dla `PermissionRequest` OpenClaw zwraca jawne decyzje zezwolenia lub odmowy -tylko wtedy, gdy decyduje polityka. Wynik bez decyzji nie jest zezwoleniem. Codex traktuje go jako brak -decyzji haka i przechodzi do własnej ścieżki guardiana lub zatwierdzenia przez użytkownika. +tylko wtedy, gdy decyduje polityka. Wynik bez decyzji nie jest zezwoleniem. +Codex traktuje go jako brak decyzji haka i przechodzi do własnej ścieżki +strażnika albo zatwierdzenia przez użytkownika. -Wywołania zatwierdzeń narzędzi Codex MCP są kierowane przez przepływ zatwierdzeń +Żądania zatwierdzenia narzędzi Codex MCP są kierowane przez przepływ zatwierdzania pluginów OpenClaw, gdy Codex oznacza `_meta.codex_approval_kind` jako `"mcp_tool_call"`. Monity Codex `request_user_input` są odsyłane do -czatu źródłowego, a następna zakolejkowana wiadomość uzupełniająca odpowiada na to natywne -żądanie serwera zamiast być kierowana jako dodatkowy kontekst. Inne żądania wywołań MCP -nadal kończą się zamkniętą odmową. +pierwotnego czatu, a następna zakolejkowana wiadomość uzupełniająca odpowiada +na to natywne żądanie serwera zamiast być kierowana jako dodatkowy kontekst. +Inne żądania elicytacji MCP nadal kończą się bezpiecznym zamknięciem. Sterowanie kolejką aktywnego uruchomienia mapuje się na `turn/steer` serwera aplikacji Codex. Przy domyślnym `messages.queue.mode: "steer"` OpenClaw grupuje zakolejkowane wiadomości czatu dla skonfigurowanego okna ciszy i wysyła je jako jedno żądanie `turn/steer` w kolejności nadejścia. Starszy tryb `queue` wysyła osobne żądania `turn/steer`. Tury -przeglądu Codex i ręcznej Compaction mogą odrzucić sterowanie w tej samej turze; w takim przypadku +recenzji Codex i ręcznej Compaction mogą odrzucić sterowanie w tej samej turze; w takim przypadku OpenClaw używa kolejki uzupełniającej, gdy wybrany tryb pozwala na fallback. Zobacz [Kolejka sterowania](/pl/concepts/queue-steering). -Gdy wybrany model używa harnessu Codex, natywna Compaction wątku jest -delegowana do serwera aplikacji Codex. OpenClaw utrzymuje lustro transkrypcji dla historii -kanału, wyszukiwania, `/new`, `/reset` oraz przyszłego przełączania modelu lub harnessu. Lustro -obejmuje monit użytkownika, końcowy tekst asystenta oraz lekkie rekordy rozumowania lub planu Codex, -gdy serwer aplikacji je emituje. Obecnie OpenClaw rejestruje tylko sygnały rozpoczęcia i zakończenia -natywnej Compaction. Nie udostępnia jeszcze czytelnego dla człowieka podsumowania Compaction ani -audytowalnej listy wpisów, które Codex zachował po Compaction. +Gdy wybrany model używa uprzęży Codex, natywna Compaction wątku jest +delegowana do serwera aplikacji Codex. OpenClaw utrzymuje kopię lustrzaną transkryptu dla historii +kanału, wyszukiwania, `/new`, `/reset` oraz przyszłego przełączania modelu lub uprzęży. Kopia +lustrzana obejmuje monit użytkownika, finalny tekst asystenta oraz lekkie rekordy +rozumowania lub planu Codex, gdy serwer aplikacji je emituje. Obecnie OpenClaw +zapisuje tylko sygnały rozpoczęcia i zakończenia natywnej Compaction. Nie udostępnia jeszcze +czytelnego dla człowieka podsumowania Compaction ani audytowalnej listy wpisów, które Codex +zachował po Compaction. -Ponieważ Codex jest właścicielem kanonicznego natywnego wątku, `tool_result_persist` obecnie nie -przepisuje natywnych rekordów wyników narzędzi Codex. Ma zastosowanie tylko wtedy, gdy -OpenClaw zapisuje wynik narzędzia w transkrypcji sesji należącej do OpenClaw. +Ponieważ Codex posiada kanoniczny natywny wątek, `tool_result_persist` obecnie nie +przepisuje rekordów wyników narzędzi natywnych Codex. Ma zastosowanie tylko wtedy, +gdy OpenClaw zapisuje wynik narzędzia transkryptu sesji należącej do OpenClaw. -Generowanie mediów nie wymaga PI. Obraz, wideo, muzyka, PDF, TTS i rozumienie +Generowanie mediów nie wymaga PI. Obrazy, wideo, muzyka, PDF, TTS i rozumienie mediów nadal używają odpowiednich ustawień dostawcy/modelu, takich jak `agents.defaults.imageGenerationModel`, `videoGenerationModel`, `pdfModel` i `messages.tts`. ## Rozwiązywanie problemów -**Codex nie pojawia się jako normalny dostawca `/model`:** jest to oczekiwane w -nowych konfiguracjach. Wybierz model `openai/gpt-*` z +**Codex nie pojawia się jako zwykły dostawca `/model`:** jest to oczekiwane dla +nowych konfiguracji. Wybierz model `openai/gpt-*` z `agentRuntime.id: "codex"` (albo starszą referencję `codex/*`), włącz `plugins.entries.codex.enabled` i sprawdź, czy `plugins.allow` nie wyklucza `codex`. **OpenClaw używa PI zamiast Codex:** `agentRuntime.id: "auto"` nadal może używać PI jako -zaplecza zgodności, gdy żaden harness Codex nie przejmie uruchomienia. Ustaw +backendu zgodności, gdy żadna uprząż Codex nie przejmie uruchomienia. Ustaw `agentRuntime.id: "codex"`, aby wymusić wybór Codex podczas testowania. Wymuszone -środowisko uruchomieniowe Codex teraz kończy się błędem zamiast wracać do PI, chyba że +środowisko uruchomieniowe Codex obecnie kończy się niepowodzeniem zamiast wracać do PI, chyba że jawnie ustawisz `agentRuntime.fallback: "pi"`. Gdy serwer aplikacji Codex zostanie -wybrany, jego błędy są ujawniane bezpośrednio bez dodatkowej konfiguracji fallback. +wybrany, jego błędy są ujawniane bezpośrednio, bez dodatkowej konfiguracji fallback. -**Serwer aplikacji jest odrzucany:** zaktualizuj Codex, aby handshake serwera aplikacji -zgłaszał wersję `0.125.0` lub nowszą. Prerelease o tej samej wersji albo wersje z sufiksem -kompilacji, takie jak `0.125.0-alpha.2` lub `0.125.0+custom`, są odrzucane, ponieważ +**Serwer aplikacji jest odrzucany:** zaktualizuj Codex, aby uzgadnianie serwera aplikacji +zgłaszało wersję `0.125.0` lub nowszą. Wydania przedpremierowe tej samej wersji albo wersje z sufiksem kompilacji, +takie jak `0.125.0-alpha.2` lub `0.125.0+custom`, są odrzucane, ponieważ stabilny próg protokołu `0.125.0` jest tym, co testuje OpenClaw. -**Wykrywanie modeli jest wolne:** zmniejsz `plugins.entries.codex.config.discovery.timeoutMs` +**Wykrywanie modeli jest wolne:** obniż `plugins.entries.codex.config.discovery.timeoutMs` albo wyłącz wykrywanie. -**Transport WebSocket natychmiast kończy się błędem:** sprawdź `appServer.url`, `authToken` -oraz to, czy zdalny serwer aplikacji używa tej samej wersji protokołu serwera aplikacji Codex. +**Transport WebSocket natychmiast zawodzi:** sprawdź `appServer.url`, `authToken` +oraz to, czy zdalny serwer aplikacji mówi tą samą wersją protokołu serwera aplikacji Codex. **Model inny niż Codex używa PI:** jest to oczekiwane, chyba że wymuszono `agentRuntime.id: "codex"` dla tego agenta albo wybrano starszą referencję @@ -1090,17 +1057,17 @@ tura dla tego agenta musi być modelem OpenAI obsługiwanym przez Codex. **Computer Use jest zainstalowany, ale narzędzia się nie uruchamiają:** sprawdź `/codex computer-use status` ze świeżej sesji. Jeśli narzędzie zgłasza -`Native hook relay unavailable`, użyj `/new` lub `/reset`; jeśli problem trwa, uruchom ponownie -gateway, aby wyczyścić nieaktualne rejestracje natywnych haków. Jeśli `computer-use.list_apps` -przekracza limit czasu, uruchom ponownie Codex Computer Use lub Codex Desktop i spróbuj ponownie. +`Native hook relay unavailable`, użyj `/new` lub `/reset`; jeśli problem się utrzymuje, uruchom ponownie +gateway, aby wyczyścić nieaktualne natywne rejestracje haków. Jeśli `computer-use.list_apps` +przekracza limit czasu, uruchom ponownie Codex Computer Use albo Codex Desktop i spróbuj ponownie. ## Powiązane -- [Pluginy harnessu agenta](/pl/plugins/sdk-agent-harness) -- [Środowiska uruchomieniowe agentów](/pl/concepts/agent-runtimes) +- [Pluginy uprzęży agenta](/pl/plugins/sdk-agent-harness) +- [Środowiska uruchomieniowe agenta](/pl/concepts/agent-runtimes) - [Dostawcy modeli](/pl/concepts/model-providers) - [Dostawca OpenAI](/pl/providers/openai) - [Status](/pl/cli/status) -- [Haki Plugin](/pl/plugins/hooks) +- [Haki pluginów](/pl/plugins/hooks) - [Dokumentacja konfiguracji](/pl/gateway/configuration-reference) - [Testowanie](/pl/help/testing-live#live-codex-app-server-harness-smoke) diff --git a/docs/pl/providers/arcee.md b/docs/pl/providers/arcee.md index 41e96f845..b5102151d 100644 --- 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 - + Utwórz klucz API w [Arcee AI](https://chat.arcee.ai/). @@ -53,7 +53,7 @@ Dostęp do modeli Arcee AI można uzyskać bezpośrednio przez platformę Arcee - + Utwórz klucz API w [OpenRouter](https://openrouter.ai/keys). @@ -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`). @@ -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 | -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. ## 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) | - + 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`). - 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. @@ -143,9 +143,9 @@ Preset onboardingu ustawia `arcee/trinity-large-thinking` jako model domyślny. - 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. - Wybór providerów, odwołań modeli i zachowania failover. + Wybieranie dostawców, odwołań do modeli i zachowania przełączania awaryjnego. diff --git a/docs/pl/reference/RELEASING.md b/docs/pl/reference/RELEASING.md index be6c97a54..f6ef6c08e 100644 --- a/docs/pl/reference/RELEASING.md +++ b/docs/pl/reference/RELEASING.md @@ -2,132 +2,129 @@ read_when: - Wyszukiwanie definicji publicznych kanałów wydań - Uruchamianie walidacji wydania lub akceptacji pakietu - - Szukasz nazewnictwa wersji i harmonogramu wydań -summary: Ścieżki wydań, lista kontrolna operatora, środowiska walidacyjne, nazewnictwo wersji i harmonogram + - Wyszukiwanie nazewnictwa wersji i częstotliwości wydań +summary: Ścieżki wydań, lista kontrolna operatora, boksy walidacyjne, nazewnictwo wersji i kadencja title: Polityka wydań x-i18n: - generated_at: "2026-05-02T20:57:35Z" + generated_at: "2026-05-02T23:39:34Z" model: gpt-5.5 provider: openai - source_hash: 493cb8b42f0e15f3bf5f8fb9be7d01fd626f4f16db9ac0a85e6efa747ef12d12 + source_hash: ba316d1736eae8edd2fb0a71b9a3da345f8895c3b536e9a1f619718ea12fc851 source_path: reference/RELEASING.md workflow: 16 --- -OpenClaw ma cztery publiczne ścieżki wydań: +OpenClaw ma trzy publiczne ścieżki wydań: -- stable: oznaczone tagami wydania, które domyślnie są publikowane w npm `beta`, albo w npm `latest`, gdy zostanie to wyraźnie zażądane -- alpha: tagi przedwydań publikowane w npm `alpha` -- beta: tagi przedwydań publikowane w npm `beta` -- dev: ruchoma głowica `main` +- stabilna: wydania oznaczone tagami, które domyślnie publikują do npm `beta`, albo do npm `latest`, gdy zostanie to wyraźnie zażądane +- beta: tagi przedpremierowe publikowane do npm `beta` +- deweloperska: ruchoma głowica `main` ## Nazewnictwo wersji -- Wersja wydania stable: `YYYY.M.D` +- Wersja stabilnego wydania: `YYYY.M.D` - Tag Git: `vYYYY.M.D` -- Wersja wydania poprawkowego stable: `YYYY.M.D-N` +- Wersja stabilnego wydania poprawkowego: `YYYY.M.D-N` - Tag Git: `vYYYY.M.D-N` -- Wersja przedwydania alpha: `YYYY.M.D-alpha.N` - - Tag Git: `vYYYY.M.D-alpha.N` -- Wersja przedwydania beta: `YYYY.M.D-beta.N` +- Wersja przedpremierowa beta: `YYYY.M.D-beta.N` - Tag Git: `vYYYY.M.D-beta.N` - Nie dodawaj zer wiodących do miesiąca ani dnia -- `latest` oznacza aktualnie promowane stabilne wydanie npm -- `alpha` oznacza aktualny cel instalacji alpha +- `latest` oznacza aktualne promowane stabilne wydanie npm - `beta` oznacza aktualny cel instalacji beta -- Wydania stable i poprawkowe stable są domyślnie publikowane w npm `beta`; operatorzy wydań mogą wyraźnie wskazać `latest` albo później wypromować sprawdzoną kompilację beta -- Każde stabilne wydanie OpenClaw dostarcza jednocześnie pakiet npm i aplikację macOS; - wydania beta zwykle najpierw walidują i publikują ścieżkę npm/pakietu, a - kompilowanie/podpisywanie/notaryzację aplikacji Mac rezerwuje się dla stable, chyba że wyraźnie zażądano inaczej +- Stabilne wydania i stabilne wydania poprawkowe domyślnie publikują do npm `beta`; operatorzy wydań mogą jawnie wskazać `latest` albo później wypromować zweryfikowaną kompilację beta +- Każde stabilne wydanie OpenClaw dostarcza razem pakiet npm i aplikację macOS; + wydania beta zwykle najpierw weryfikują i publikują ścieżkę npm/pakietu, a + kompilowanie/podpisywanie/notaryzacja aplikacji Mac są zarezerwowane dla wydań + stabilnych, chyba że zostanie to wyraźnie zażądane ## Rytm wydań -- Wydania przechodzą najpierw przez beta -- Stable następuje dopiero po zwalidowaniu najnowszej beta -- Maintainerzy zwykle tworzą wydania z gałęzi `release/YYYY.M.D` utworzonej - z bieżącego `main`, tak aby walidacja wydania i poprawki nie blokowały nowego - rozwoju na `main` +- Wydania przechodzą najpierw przez wersję beta +- Wydanie stabilne następuje dopiero po zweryfikowaniu najnowszej wersji beta +- Maintainerzy zwykle przygotowują wydania z gałęzi `release/YYYY.M.D` utworzonej + z bieżącej gałęzi `main`, aby walidacja wydania i poprawki nie blokowały + nowego rozwoju na `main` - Jeśli tag beta został wypchnięty lub opublikowany i wymaga poprawki, maintainerzy tworzą - następny tag `-beta.N` zamiast usuwać lub odtwarzać stary tag beta -- Szczegółowa procedura wydania, zatwierdzenia, dane uwierzytelniające i notatki odzyskiwania są - dostępne tylko dla maintainerów + następny tag `-beta.N` zamiast usuwać albo odtwarzać stary tag beta +- Szczegółowa procedura wydania, zatwierdzenia, poświadczenia i notatki odzyskiwania są + przeznaczone wyłącznie dla maintainerów ## Lista kontrolna operatora wydania -Ta lista kontrolna pokazuje publiczny kształt przepływu wydania. Prywatne dane uwierzytelniające, +Ta lista kontrolna opisuje publiczny kształt procesu wydania. Prywatne poświadczenia, podpisywanie, notaryzacja, odzyskiwanie dist-tagów i szczegóły awaryjnego wycofania pozostają w -runbooku wydania dostępnym tylko dla maintainerów. +runbooku wydaniowym przeznaczonym wyłącznie dla maintainerów. -1. Zacznij od bieżącego `main`: pobierz najnowsze zmiany, potwierdź, że commit docelowy został wypchnięty, - i potwierdź, że bieżące CI `main` jest wystarczająco zielone, aby utworzyć z niego gałąź. +1. Zacznij od bieżącej gałęzi `main`: pobierz najnowsze zmiany, potwierdź, że docelowy commit został wypchnięty, + i potwierdź, że bieżące CI na `main` jest wystarczająco zielone, aby utworzyć z niej gałąź. 2. Przepisz najwyższą sekcję `CHANGELOG.md` na podstawie rzeczywistej historii commitów za pomocą - `/changelog`, utrzymaj wpisy jako skierowane do użytkowników, zacommituj je, wypchnij i wykonaj rebase/pull + `/changelog`, zachowaj wpisy skierowane do użytkowników, commituj ją, wypchnij i wykonaj rebase/pull jeszcze raz przed utworzeniem gałęzi. 3. Przejrzyj rekordy zgodności wydania w `src/plugins/compat/registry.ts` i `src/commands/doctor/shared/deprecation-compat.ts`. Usuń wygasłą - zgodność tylko wtedy, gdy ścieżka aktualizacji pozostaje pokryta, albo zapisz, dlaczego jest - celowo zachowana. -4. Utwórz `release/YYYY.M.D` z bieżącego `main`; nie wykonuj zwykłej pracy wydaniowej + zgodność tylko wtedy, gdy ścieżka aktualizacji pozostaje pokryta, albo odnotuj, dlaczego jest + celowo utrzymywana. +4. Utwórz `release/YYYY.M.D` z bieżącej gałęzi `main`; nie wykonuj zwykłych prac wydaniowych bezpośrednio na `main`. 5. Podbij każdą wymaganą lokalizację wersji dla zamierzonego tagu, uruchom - `pnpm plugins:sync`, aby publikowalne pakiety Plugin miały wspólną wersję wydania + `pnpm plugins:sync`, aby publikowalne pakiety Plugin współdzieliły wersję wydania i metadane zgodności, a następnie uruchom lokalny deterministyczny preflight: `pnpm check:test-types`, `pnpm check:architecture`, - `pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` i + `pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` oraz `pnpm release:check`. -6. Uruchom `OpenClaw NPM Release` z `preflight_only=true`. Zanim istnieje tag, - pełny 40-znakowy SHA gałęzi wydania jest dozwolony dla preflight wyłącznie walidacyjnego. - Zapisz pomyślny `preflight_run_id`. +6. Uruchom `OpenClaw NPM Release` z `preflight_only=true`. Zanim tag istnieje, + pełny 40-znakowy SHA gałęzi wydania jest dozwolony wyłącznie do walidacyjnego + preflightu. Zapisz pomyślny `preflight_run_id`. 7. Uruchom wszystkie testy przedwydaniowe za pomocą `Full Release Validation` dla - gałęzi wydania, tagu lub pełnego SHA commitu. To jeden ręczny punkt wejścia - dla czterech dużych pól testów wydaniowych: Vitest, Docker, QA Lab i Package. -8. Jeśli walidacja się nie powiedzie, napraw problem na gałęzi wydania i uruchom ponownie najmniejszy nieudany - plik, ścieżkę, zadanie workflow, profil pakietu, dostawcę lub allowlistę modeli, które - dowodzą poprawki. Uruchom ponownie cały parasol tylko wtedy, gdy zmieniona powierzchnia sprawia, - że wcześniejsze dowody są nieaktualne. -9. Dla alpha lub beta oznacz `vYYYY.M.D-alpha.N` albo `vYYYY.M.D-beta.N`, a następnie uruchom `OpenClaw Release Publish` z - pasującej gałęzi `release/YYYY.M.D`. Sprawdza `pnpm plugins:sync:check`, - publikuje najpierw wszystkie publikowalne pakiety Plugin w npm, publikuje ten sam - zestaw w ClawHub jako drugi krok, a następnie promuje przygotowany artefakt preflight npm OpenClaw - z pasującym dist-tagiem. Po publikacji uruchom akceptację pakietu po publikacji - wobec opublikowanego pakietu `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`, - `openclaw@YYYY.M.D-beta.N` lub `openclaw@beta`. Jeśli wypchnięte lub - opublikowane przedwydanie wymaga poprawki, utwórz następny pasujący numer przedwydania; - nie usuwaj ani nie przepisuj starego przedwydania. -10. Dla stable kontynuuj dopiero po tym, jak sprawdzona beta lub kandydat do wydania ma - wymagane dowody walidacji. Publikacja stable npm również przechodzi przez - `OpenClaw Release Publish`, ponownie używając pomyślnego artefaktu preflight przez - `preflight_run_id`; gotowość stabilnego wydania macOS wymaga także - spakowanych `.zip`, `.dmg`, `.dSYM.zip` oraz zaktualizowanego `appcast.xml` na `main`. -11. Po publikacji uruchom weryfikator npm po publikacji, opcjonalne samodzielne - opublikowane-npm Telegram E2E, gdy potrzebujesz dowodu kanału po publikacji, + gałęzi wydania, tagu albo pełnego SHA commitu. To jeden ręczny punkt wejścia + dla czterech dużych boksów testów wydaniowych: Vitest, Docker, QA Lab i Package. +8. Jeśli walidacja się nie powiedzie, popraw na gałęzi wydania i ponownie uruchom najmniejszy nieudany + plik, ścieżkę, zadanie workflow, profil pakietu, dostawcę albo allowlistę modeli, które + dowodzą poprawki. Ponownie uruchom pełny parasol tylko wtedy, gdy zmieniona powierzchnia sprawia, że + wcześniejsze dowody są nieaktualne. +9. Dla wersji beta oznacz `vYYYY.M.D-beta.N`, a następnie uruchom `OpenClaw Release Publish` z + odpowiadającej gałęzi `release/YYYY.M.D`. Weryfikuje `pnpm plugins:sync:check`, + najpierw publikuje wszystkie publikowalne pakiety Plugin do npm, jako drugie publikuje ten sam + zestaw do ClawHub, a następnie promuje przygotowany artefakt preflight npm OpenClaw + z pasującym dist-tagiem. Po publikacji uruchom powydaniową akceptację pakietu + względem opublikowanego pakietu `openclaw@YYYY.M.D-beta.N` albo + `openclaw@beta`. Jeśli wypchnięte albo opublikowane wydanie przedpremierowe wymaga poprawki, + utwórz następny pasujący numer wydania przedpremierowego; nie usuwaj ani nie przepisuj starego + wydania przedpremierowego. +10. Dla wydania stabilnego kontynuuj dopiero wtedy, gdy zweryfikowana beta albo kandydat wydania ma + wymagane dowody walidacji. Publikacja stabilna npm także przechodzi przez + `OpenClaw Release Publish`, ponownie używając pomyślnego artefaktu preflight za pomocą + `preflight_run_id`; gotowość stabilnego wydania macOS wymaga również + spakowanych plików `.zip`, `.dmg`, `.dSYM.zip` oraz zaktualizowanego `appcast.xml` na `main`. +11. Po publikacji uruchom powydaniowy weryfikator npm, opcjonalny samodzielny + E2E Telegram opublikowanego npm, gdy potrzebujesz powydaniowego dowodu kanału, promocję dist-tagu, gdy jest potrzebna, notatki wydania/przedwydania GitHub z kompletnej pasującej sekcji `CHANGELOG.md` oraz kroki ogłoszenia wydania. ## Preflight wydania -- Uruchom `pnpm check:test-types` przed przedstartową kontrolą wydania, aby testowy TypeScript pozostawał - objęty sprawdzaniem poza szybszą lokalną bramką `pnpm check` -- Uruchom `pnpm check:architecture` przed przedstartową kontrolą wydania, aby szersze kontrole cykli +- Uruchom `pnpm check:test-types` przed kontrolą wstępną wydania, aby testowy TypeScript pozostawał + objęty kontrolą poza szybszą lokalną bramką `pnpm check` +- Uruchom `pnpm check:architecture` przed kontrolą wstępną wydania, aby szersze kontrole cykli importów i granic architektury były zielone poza szybszą lokalną bramką - Uruchom `pnpm build && pnpm ui:build` przed `pnpm release:check`, aby oczekiwane - artefakty wydania `dist/*` i pakiet Control UI istniały dla kroku walidacji - pakietu -- Uruchom `pnpm plugins:sync` po podbiciu wersji głównej i przed tagowaniem. Aktualizuje - wersje publikowalnych pakietów pluginów, metadane zgodności peer/API OpenClaw, - metadane kompilacji oraz zalążki changelogów pluginów tak, aby odpowiadały wersji - wydania rdzenia. `pnpm plugins:sync:check` to niemutująca osłona wydania; - przepływ publikowania kończy się niepowodzeniem przed jakąkolwiek mutacją rejestru, jeśli ten krok został + artefakty wydania `dist/*` oraz pakiet Control UI istniały na potrzeby kroku + walidacji pakietu +- Uruchom `pnpm plugins:sync` po podbiciu wersji w katalogu głównym i przed tagowaniem. Aktualizuje + wersje publikowalnych pakietów pluginów, metadane zgodności OpenClaw peer/API, + metadane kompilacji oraz zalążki changelogów pluginów tak, aby pasowały do wersji wydania + core. `pnpm plugins:sync:check` to niemutująca straż wydania; + workflow publikowania kończy się niepowodzeniem przed jakąkolwiek mutacją rejestru, jeśli ten krok został pominięty. - Uruchom ręczny workflow `Full Release Validation` przed zatwierdzeniem wydania, aby - uruchomić wszystkie przedwydaniowe testboxy z jednego punktu wejścia. Przyjmuje gałąź, - tag albo pełny SHA commita, wywołuje ręczny `CI` oraz wywołuje - `OpenClaw Release Checks` dla instalacyjnego smoke testu, akceptacji pakietu, zestawów - ścieżki wydania Docker, testów live/E2E, OpenWebUI, parytetu QA Lab, Matrix i ścieżek Telegram. - Z `release_profile=full` i `rerun_group=all` uruchamia też pakietowe - Telegram E2E względem artefaktu `release-package-under-test` z kontroli wydania. - Podaj `npm_telegram_package_spec` po opublikowaniu, gdy to samo + uruchomić wszystkie przedwydaniowe boxy testowe z jednego punktu wejścia. Przyjmuje branch, + tag albo pełny SHA commita, dispatchuje ręczny `CI` oraz dispatchuje + `OpenClaw Release Checks` dla install smoke, package acceptance, zestawów ścieżki wydania Docker, + live/E2E, OpenWebUI, zgodności QA Lab, Matrix oraz pasów Telegram. Przy + `release_profile=full` i `rerun_group=all` uruchamia też package + Telegram E2E względem artefaktu `release-package-under-test` z release + checks. Podaj `npm_telegram_package_spec` po opublikowaniu, gdy ten sam Telegram E2E ma także potwierdzić opublikowany pakiet npm. Podaj `package_acceptance_package_spec` po opublikowaniu, gdy Package Acceptance ma uruchomić swoją macierz pakietu/aktualizacji względem wysłanego pakietu npm zamiast @@ -136,153 +133,153 @@ runbooku wydania dostępnym tylko dla maintainerów. walidacja odpowiada opublikowanemu pakietowi npm bez wymuszania Telegram E2E. Przykład: `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D` -- Uruchom ręczny workflow `Package Acceptance`, gdy chcesz uzyskać dowód kanałem bocznym - dla kandydata pakietu, podczas gdy prace nad wydaniem trwają. Użyj `source=npm` dla - `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` albo dokładnej wersji wydania; `source=ref` - aby spakować zaufaną gałąź/tag/SHA `package_ref` z bieżącą - uprzężą `workflow_ref`; `source=url` dla archiwum tarball HTTPS z wymaganym - SHA-256; albo `source=artifact` dla archiwum tarball przesłanego przez inny przebieg GitHub +- Uruchom ręczny workflow `Package Acceptance`, gdy chcesz uzyskać dowód bocznym kanałem + dla kandydata pakietu, podczas gdy prace nad wydaniem trwają dalej. Użyj `source=npm` dla + `openclaw@beta`, `openclaw@latest` albo dokładnej wersji wydania; `source=ref`, + aby spakować zaufany branch/tag/SHA `package_ref` przy użyciu bieżącego harnessu + `workflow_ref`; `source=url` dla tarballa HTTPS z wymaganym + SHA-256; albo `source=artifact` dla tarballa przesłanego przez inne uruchomienie GitHub Actions. Workflow rozwiązuje kandydata do `package-under-test`, ponownie używa harmonogramu wydania Docker E2E względem tego - archiwum tarball i może uruchomić Telegram QA względem tego samego archiwum tarball z + tarballa i może uruchomić Telegram QA względem tego samego tarballa z `telegram_mode=mock-openai` albo `telegram_mode=live-frontier`. Gdy - wybrane ścieżki Docker obejmują `published-upgrade-survivor`, artefakt pakietu - jest kandydatem, a `published_upgrade_survivor_baseline` wybiera opublikowaną - bazę. + wybrane pasy Docker obejmują `published-upgrade-survivor`, artefakt pakietu + jest kandydatem, a `published_upgrade_survivor_baseline` wybiera + opublikowaną bazę. Przykład: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai` Typowe profile: - - `smoke`: ścieżki instalacji/kanału/agenta, sieci Gateway i przeładowania konfiguracji - - `package`: natywne dla artefaktu ścieżki pakietu/aktualizacji/pluginów bez OpenWebUI ani live ClawHub + - `smoke`: pasy instalacji/kanału/agenta, sieci Gateway i przeładowania konfiguracji + - `package`: natywne dla artefaktu pasy pakietu/aktualizacji/pluginu bez OpenWebUI ani live ClawHub - `product`: profil pakietu plus kanały MCP, czyszczenie cron/subagent, - wyszukiwanie webowe OpenAI i OpenWebUI + wyszukiwanie w sieci OpenAI oraz OpenWebUI - `full`: fragmenty ścieżki wydania Docker z OpenWebUI - - `custom`: dokładny wybór `docker_lanes` dla skoncentrowionego ponownego uruchomienia -- Uruchom ręczny workflow `CI` bezpośrednio, gdy potrzebujesz tylko pełnego zwykłego pokrycia CI - dla kandydata wydania. Ręczne wywołania CI omijają zakresowanie zmian - i wymuszają shardy Linux Node, shardy dołączonych pluginów, kontrakty kanałów, - zgodność z Node 22, `check`, `check-additional`, smoke test kompilacji, - kontrole dokumentacji, Python skills, Windows, macOS, Android oraz ścieżki i18n Control UI. + - `custom`: dokładny wybór `docker_lanes` dla skupionego ponownego uruchomienia +- Uruchom ręczny workflow `CI` bezpośrednio, gdy potrzebujesz tylko pełnego normalnego + pokrycia CI dla kandydata wydania. Ręczne dispatchowanie CI omija zakresowanie zmian + i wymusza shardy Linux Node, shardy dołączonych pluginów, kontrakty kanałów, + zgodność Node 22, `check`, `check-additional`, build smoke, + kontrole dokumentacji, Python skills, Windows, macOS, Android oraz pasy i18n Control UI. Przykład: `gh workflow run ci.yml --ref release/YYYY.M.D` -- Uruchom `pnpm qa:otel:smoke` podczas walidacji telemetrii wydania. Sprawdza - QA-lab przez lokalny odbiornik OTLP/HTTP i weryfikuje wyeksportowane nazwy spanów - śladu, ograniczone atrybuty oraz redakcję treści/identyfikatorów bez +- Uruchom `pnpm qa:otel:smoke` podczas walidowania telemetrii wydania. Ćwiczy + QA-lab przez lokalny odbiornik OTLP/HTTP i weryfikuje wyeksportowane nazwy + spanów trace, ograniczone atrybuty oraz redakcję treści/identyfikatorów bez wymagania Opik, Langfuse ani innego zewnętrznego kolektora. - Uruchom `pnpm release:check` przed każdym tagowanym wydaniem - Uruchom `OpenClaw Release Publish` dla mutującej sekwencji publikowania po tym, jak - tag już istnieje. Wywołaj go z `release/YYYY.M.D` (albo `main`, gdy publikujesz - tag osiągalny z main), przekaż tag wydania i udany `preflight_run_id` - OpenClaw npm oraz pozostaw domyślny zakres publikowania pluginów - `all-publishable`, chyba że celowo uruchamiasz skoncentrowaną naprawę. Workflow - serializuje publikowanie pluginów npm, publikowanie pluginów ClawHub i publikowanie OpenClaw - npm, aby pakiet rdzenia nie został opublikowany przed swoimi zewnętrznymi + tag już istnieje. Dispatchuj go z `release/YYYY.M.D` (albo `main`, gdy publikujesz + tag osiągalny z main), przekaż tag wydania oraz udany OpenClaw npm + `preflight_run_id` i zachowaj domyślny zakres publikowania pluginów + `all-publishable`, chyba że celowo uruchamiasz skupioną naprawę. Workflow + serializuje publikację pluginów npm, publikację pluginów ClawHub oraz publikację OpenClaw + npm, aby pakiet core nie został opublikowany przed swoimi wyeksternalizowanymi pluginami. - Kontrole wydania działają teraz w osobnym ręcznym workflow: `OpenClaw Release Checks` -- `OpenClaw Release Checks` uruchamia też ścieżkę parytetu mock QA Lab oraz szybki - profil live Matrix i ścieżkę Telegram QA przed zatwierdzeniem wydania. Ścieżki live - używają środowiska `qa-live-shared`; Telegram używa też dzierżaw poświadczeń Convex CI. +- `OpenClaw Release Checks` uruchamia też pas zgodności mock QA Lab oraz szybki + profil live Matrix i pas Telegram QA przed zatwierdzeniem wydania. Pasy live + używają środowiska `qa-live-shared`; Telegram używa także dzierżaw poświadczeń Convex CI. Uruchom ręczny workflow `QA-Lab - All Lanes` z `matrix_profile=all` i `matrix_shards=true`, gdy chcesz pełny inwentarz transportu, - multimediów i E2EE Matrix równolegle. + mediów i E2EE Matrix równolegle. - Walidacja runtime instalacji i aktualizacji między systemami operacyjnymi jest częścią publicznych - `OpenClaw Release Checks` i `Full Release Validation`, które wywołują + `OpenClaw Release Checks` oraz `Full Release Validation`, które wywołują reusable workflow `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` bezpośrednio -- Ten podział jest zamierzony: utrzymuje prawdziwą ścieżkę wydania npm krótką, - deterministyczną i skoncentrowaną na artefaktach, podczas gdy wolniejsze kontrole live pozostają we - własnej ścieżce, aby nie wstrzymywać ani nie blokować publikowania -- Kontrole wydania zawierające sekrety powinny być wywoływane przez `Full Release +- Ten podział jest celowy: zachowuje realną ścieżkę wydania npm krótką, + deterministyczną i skoncentrowaną na artefaktach, podczas gdy wolniejsze kontrole live pozostają we własnym + pasie, aby nie opóźniały ani nie blokowały publikacji +- Kontrole wydania z sekretami powinny być dispatchowane przez `Full Release Validation` albo z refa workflow `main`/release, aby logika workflow i sekrety pozostawały kontrolowane -- `OpenClaw Release Checks` przyjmuje gałąź, tag albo pełny SHA commita, o ile - rozwiązany commit jest osiągalny z gałęzi OpenClaw albo tagu wydania -- Przedstartowa kontrola tylko walidacyjna `OpenClaw NPM Release` akceptuje też bieżący - pełny 40-znakowy SHA commita gałęzi workflow bez wymagania wypchniętego tagu -- Ta ścieżka SHA jest tylko walidacyjna i nie może zostać wypromowana do prawdziwego publikowania -- W trybie SHA workflow syntetyzuje `v` tylko dla - kontroli metadanych pakietu; prawdziwe publikowanie nadal wymaga prawdziwego tagu wydania -- Oba workflow utrzymują prawdziwą ścieżkę publikowania i promowania na runnerach - hostowanych przez GitHub, podczas gdy niemutująca ścieżka walidacji może używać większych +- `OpenClaw Release Checks` przyjmuje branch, tag albo pełny SHA commita, o ile + rozwiązany commit jest osiągalny z brancha OpenClaw albo tagu wydania +- Kontrola wstępna tylko do walidacji `OpenClaw NPM Release` akceptuje też bieżący + pełny 40-znakowy SHA commita brancha workflow bez wymagania wypchniętego tagu +- Ta ścieżka SHA jest tylko walidacyjna i nie może zostać promowana do prawdziwej publikacji +- W trybie SHA workflow syntetyzuje `v` tylko na potrzeby + kontroli metadanych pakietu; prawdziwa publikacja nadal wymaga prawdziwego tagu wydania +- Oba workflow utrzymują prawdziwą ścieżkę publikacji i promocji na runnerach hostowanych przez GitHub, + podczas gdy niemutująca ścieżka walidacji może używać większych runnerów Blacksmith Linux - Ten workflow uruchamia `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` z użyciem sekretów workflow `OPENAI_API_KEY` i `ANTHROPIC_API_KEY` -- Przedstartowa kontrola wydania npm nie czeka już na osobną ścieżkę kontroli wydania +- Kontrola wstępna wydania npm nie czeka już na osobny pas kontroli wydania - Uruchom `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` (albo odpowiadający tag beta/korekty) przed zatwierdzeniem -- Po opublikowaniu npm uruchom +- Po publikacji npm uruchom `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (albo odpowiadającą wersję beta/korekty), aby zweryfikować ścieżkę instalacji z opublikowanego rejestru - w świeżym tymczasowym prefiksie -- Po opublikowaniu beta uruchom `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live` - aby zweryfikować onboarding zainstalowanego pakietu, konfigurację Telegram i prawdziwe Telegram E2E - względem opublikowanego pakietu npm z użyciem współdzielonej puli dzierżawionych poświadczeń Telegram. - Lokalne jednorazowe przebiegi maintainerów mogą pominąć zmienne Convex i przekazać trzy + (albo odpowiadającą wersję beta/korekty), aby zweryfikować ścieżkę instalacji + opublikowanego rejestru w świeżym prefiksie tymczasowym +- Po publikacji beta uruchom `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live` + aby zweryfikować onboarding zainstalowanego pakietu, konfigurację Telegram oraz rzeczywisty Telegram E2E + względem opublikowanego pakietu npm przy użyciu wspólnej puli dzierżawionych poświadczeń Telegram. + Jednorazowe lokalne uruchomienia maintainerów mogą pominąć zmienne Convex i przekazać trzy poświadczenia env `OPENCLAW_QA_TELEGRAM_*` bezpośrednio. - Maintainerzy mogą uruchomić tę samą kontrolę po publikacji z GitHub Actions przez - ręczny workflow `NPM Telegram Beta E2E`. Jest on celowo wyłącznie ręczny i - nie uruchamia się przy każdym scaleniu. -- Automatyzacja wydań maintainerów używa teraz schematu preflight-then-promote: - - prawdziwe publikowanie npm musi przejść udany npm `preflight_run_id` - - prawdziwe publikowanie npm musi zostać wywołane z tej samej gałęzi `main` albo - `release/YYYY.M.D`, co udany przebieg przedstartowy + ręczny workflow `NPM Telegram Beta E2E`. Jest celowo tylko ręczny i + nie uruchamia się przy każdym mergu. +- Automatyzacja wydań maintainerów używa teraz schematu kontrola wstępna, potem promocja: + - prawdziwa publikacja npm musi przejść udany npm `preflight_run_id` + - prawdziwa publikacja npm musi być dispatchowana z tego samego brancha `main` albo + `release/YYYY.M.D` co udane uruchomienie kontroli wstępnej - stabilne wydania npm domyślnie trafiają do `beta` - - stabilne publikowanie npm może jawnie celować w `latest` przez wejście workflow - - mutacja npm dist-tag oparta na tokenie znajduje się teraz w + - stabilna publikacja npm może jawnie wskazać `latest` przez input workflow + - mutacja dist-tagów npm oparta na tokenie znajduje się teraz w `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` ze względów bezpieczeństwa, ponieważ `npm dist-tag add` nadal potrzebuje `NPM_TOKEN`, podczas gdy - publiczne repo utrzymuje publikowanie wyłącznie OIDC - - publiczny `macOS Release` jest tylko walidacyjny; gdy tag istnieje tylko na - gałęzi wydania, ale workflow jest wywoływany z `main`, ustaw + publiczne repo utrzymuje publikację wyłącznie OIDC + - publiczny `macOS Release` służy tylko do walidacji; gdy tag istnieje tylko na + branchu wydania, ale workflow jest dispatchowany z `main`, ustaw `public_release_branch=release/YYYY.M.D` - - prawdziwe prywatne publikowanie mac musi przejść udane prywatne mac + - prawdziwa prywatna publikacja mac musi przejść udany prywatny mac `preflight_run_id` i `validate_run_id` - - prawdziwe ścieżki publikowania promują przygotowane artefakty zamiast budować + - prawdziwe ścieżki publikacji promują przygotowane artefakty zamiast budować je ponownie - Dla stabilnych wydań korygujących, takich jak `YYYY.M.D-N`, weryfikator po publikacji - sprawdza też tę samą ścieżkę aktualizacji w tymczasowym prefiksie z `YYYY.M.D` do `YYYY.M.D-N`, - aby korekty wydania nie mogły po cichu pozostawić starszych globalnych instalacji na - bazowym stabilnym ładunku -- Przedstartowa kontrola wydania npm kończy się zamknięciem niepowodzeniem, chyba że archiwum tarball zawiera zarówno - `dist/control-ui/index.html`, jak i niepusty ładunek `dist/control-ui/assets/`, + sprawdza też tę samą ścieżkę aktualizacji w prefiksie tymczasowym z `YYYY.M.D` do `YYYY.M.D-N`, + aby korekty wydań nie mogły po cichu zostawić starszych globalnych instalacji na + bazowym stabilnym payloadzie +- Kontrola wstępna wydania npm kończy się zamkniętym niepowodzeniem, chyba że tarball zawiera zarówno + `dist/control-ui/index.html`, jak i niepusty payload `dist/control-ui/assets/`, abyśmy ponownie nie wysłali pustego dashboardu przeglądarkowego - Weryfikacja po publikacji sprawdza też, czy opublikowane entrypointy pluginów i metadane pakietu są obecne w zainstalowanym układzie rejestru. Wydanie, które - wysyła brakujące ładunki runtime pluginów, oblewa weryfikator po publikacji i - nie może zostać wypromowane do `latest`. -- `pnpm test:install:smoke` egzekwuje też budżet npm pack `unpackedSize` na - kandydackim archiwum tarball aktualizacji, dzięki czemu instalacyjne e2e wyłapuje przypadkowe rozdęcie pakietu - przed ścieżką publikowania wydania + wysyła brakujące runtime payloady pluginów, oblewa weryfikator po publikacji i + nie może zostać promowane do `latest`. +- `pnpm test:install:smoke` egzekwuje też budżet `unpackedSize` paczki npm na + tarballu kandydata aktualizacji, dzięki czemu installer e2e wyłapuje przypadkowe rozrośnięcie paczki + przed ścieżką publikacji wydania - Jeśli prace nad wydaniem dotknęły planowania CI, manifestów timingów rozszerzeń albo - macierzy testów rozszerzeń, przed zatwierdzeniem wygeneruj ponownie i przejrzyj należące do planera + macierzy testów rozszerzeń, wygeneruj ponownie i przejrzyj należące do planera wyjścia macierzy `plugin-prerelease-extension-shard` z - `.github/workflows/plugin-prerelease.yml`, aby notatki wydania nie opisywały - nieaktualnego układu CI + `.github/workflows/plugin-prerelease.yml` przed zatwierdzeniem, aby notatki wydania nie + opisywały przestarzałego układu CI - Gotowość stabilnego wydania macOS obejmuje też powierzchnie aktualizatora: - - wydanie GitHub musi ostatecznie zawierać spakowane `.zip`, `.dmg` i `.dSYM.zip` - - `appcast.xml` na `main` musi wskazywać na nowy stabilny zip po publikacji - - spakowana aplikacja musi utrzymywać niedebugowy identyfikator bundle, niepusty adres URL kanału Sparkle - oraz `CFBundleVersion` równy lub wyższy od kanonicznego dolnego progu kompilacji Sparkle + - release GitHub musi ostatecznie zawierać spakowane `.zip`, `.dmg` i `.dSYM.zip` + - `appcast.xml` na `main` musi wskazywać nowy stabilny zip po publikacji + - spakowana aplikacja musi zachować niedebugowy identyfikator pakietu, niepusty adres URL feedu Sparkle + oraz `CFBundleVersion` równy lub wyższy od kanonicznego progu builda Sparkle dla tej wersji wydania -## Testboxy wydania +## Boxy testowe wydania `Full Release Validation` to sposób, w jaki operatorzy uruchamiają wszystkie testy przedwydaniowe z -jednego punktu wejścia. Dla dowodu przypiętego commita na szybko zmieniającej się gałęzi użyj -helpera, aby każdy workflow potomny działał z tymczasowej gałęzi ustalonej na docelowy +jednego punktu wejścia. Aby uzyskać dowód przypiętego commita na szybko zmieniającym się branchu, użyj +helpera, aby każdy workflow potomny działał z tymczasowego brancha ustawionego na docelowy SHA: ```bash pnpm ci:full-release --sha ``` -Helper wypycha `release-ci/-...`, wywołuje `Full Release Validation` -z tej gałęzi z `ref=`, weryfikuje, że każdy `headSha` workflow potomnego -odpowiada celowi, a następnie usuwa tymczasową gałąź. Zapobiega to przypadkowemu -potwierdzeniu nowszego przebiegu potomnego `main`. +Helper wypycha `release-ci/-...`, dispatchuje `Full Release Validation` +z tego brancha z `ref=`, weryfikuje, że każdy workflow potomny `headSha` +pasuje do celu, a następnie usuwa tymczasowy branch. Zapobiega to przypadkowemu +potwierdzeniu nowszego uruchomienia potomnego `main`. -Dla walidacji gałęzi wydania albo tagu uruchom go z zaufanego refa workflow `main` -i przekaż gałąź wydania albo tag jako `ref`: +Dla walidacji brancha wydania albo tagu uruchom go z zaufanego refa workflow `main` +i przekaż branch wydania albo tag jako `ref`: ```bash gh workflow run full-release-validation.yml \ @@ -294,51 +291,47 @@ gh workflow run full-release-validation.yml \ -f evidence_package_spec=openclaw@YYYY.M.D-beta.N ``` -Przepływ pracy rozwiązuje docelowy ref, uruchamia ręczne `CI` z +Przepływ pracy rozpoznaje docelowy ref, uruchamia ręcznie `CI` z `target_ref=`, uruchamia `OpenClaw Release Checks` oraz uruchamia -samodzielny pakietowy Telegram E2E, gdy `release_profile=full` z -`rerun_group=all` albo gdy ustawiono `npm_telegram_package_spec`. Następnie -`OpenClaw Release Checks` rozgałęzia się na install smoke, międzyplatformowe -kontrole wydania, pokrycie live/E2E Docker dla ścieżki wydania, Package -Acceptance z QA pakietu Telegram, parytet QA Lab, live Matrix oraz live -Telegram. Pełny przebieg jest akceptowalny tylko wtedy, gdy podsumowanie -`Full Release Validation` pokazuje `normal_ci` i `release_checks` jako -zakończone powodzeniem. W trybie full/all proces potomny `npm_telegram` również -musi zakończyć się powodzeniem; poza full/all jest pomijany, chyba że podano -opublikowany `npm_telegram_package_spec`. Końcowe podsumowanie weryfikatora -zawiera tabele najwolniejszych zadań dla każdego przebiegu potomnego, dzięki -czemu release manager widzi bieżącą ścieżkę krytyczną bez pobierania logów. -Zobacz [Pełną walidację wydania](/pl/reference/full-release-validation), aby -poznać kompletną macierz etapów, dokładne nazwy zadań workflow, różnice między -profilami stable i full, artefakty oraz uchwyty do ukierunkowanych ponownych -uruchomień. -Workflow potomne są uruchamiane z zaufanego ref, który uruchamia `Full Release -Validation`, zwykle `--ref main`, nawet gdy docelowy `ref` wskazuje starszą -gałąź wydania lub tag. Nie ma osobnego wejścia workflow-ref dla Full Release -Validation; zaufany harness wybiera się przez wybór ref przebiegu workflow. -Nie używaj `--ref main -f ref=` do dowodu dokładnego commita na ruchomym -`main`; surowe SHA commitów nie mogą być refami dispatch workflow, więc użyj +samodzielne package Telegram E2E, gdy `release_profile=full` z +`rerun_group=all` albo gdy ustawiono `npm_telegram_package_spec`. Następnie `OpenClaw Release +Checks` rozdziela się na install smoke, cross-OS release checks, live/E2E Docker +release-path coverage, Package Acceptance z Telegram package QA, QA Lab +parity, live Matrix i live Telegram. Pełne uruchomienie jest akceptowalne tylko wtedy, gdy +podsumowanie `Full Release Validation` +pokazuje `normal_ci` i `release_checks` jako zakończone sukcesem. W trybie full/all +proces potomny `npm_telegram` także musi zakończyć się sukcesem; poza full/all jest pomijany, +chyba że podano opublikowany `npm_telegram_package_spec`. Końcowe +podsumowanie weryfikatora zawiera tabele najwolniejszych zadań dla każdego uruchomienia potomnego, dzięki czemu release +manager może zobaczyć bieżącą ścieżkę krytyczną bez pobierania logów. +Zobacz [Pełna walidacja wydania](/pl/reference/full-release-validation), aby poznać +pełną macierz etapów, dokładne nazwy zadań przepływu pracy, różnice między profilami stable i full, +artefakty oraz uchwyty do ukierunkowanych ponownych uruchomień. +Przepływy pracy potomne są uruchamiane z zaufanego ref, który uruchamia `Full Release +Validation`, zwykle `--ref main`, nawet gdy docelowy `ref` wskazuje na +starszą gałąź lub tag wydania. Nie ma osobnego wejścia workflow-ref dla Full Release Validation; +wybierz zaufany harness przez wybór ref uruchomienia przepływu pracy. +Nie używaj `--ref main -f ref=` do dowodu dokładnego commita na zmieniającym się `main`; +surowe SHA commitów nie mogą być refami uruchamiania przepływu pracy, więc użyj `pnpm ci:full-release --sha `, aby utworzyć przypiętą tymczasową gałąź. -Użyj `release_profile`, aby wybrać zakres live/provider: +Użyj `release_profile`, aby wybrać zakres live/dostawców: - `minimum`: najszybsza krytyczna dla wydania ścieżka OpenAI/core live i Docker -- `stable`: minimum plus stabilne pokrycie provider/backend do zatwierdzenia wydania -- `full`: stable plus szerokie pokrycie doradczych providerów i mediów +- `stable`: minimum plus stabilne pokrycie dostawców/backendów do zatwierdzenia wydania +- `full`: stable plus szerokie doradcze pokrycie dostawców/mediów -`OpenClaw Release Checks` używa zaufanego ref workflow, aby jednorazowo -rozwiązać docelowy ref jako `release-package-under-test` i ponownie używa tego -artefaktu zarówno w kontrolach Docker ścieżki wydania, jak i w Package -Acceptance. Dzięki temu wszystkie boksy obsługujące pakiet działają na tych -samych bajtach i unika się powtarzanych buildów pakietu. -Międzyplatformowy install smoke OpenAI używa `OPENCLAW_CROSS_OS_OPENAI_MODEL`, -gdy ustawiona jest zmienna repo/org, w przeciwnym razie `openai/gpt-5.4`, -ponieważ ta ścieżka dowodzi instalacji pakietu, onboardingu, startu Gateway i -jednego obrotu agenta live, a nie benchmarkuje najwolniejszego modelu -domyślnego. Szersza macierz providerów live pozostaje miejscem na pokrycie -specyficzne dla modeli. +`OpenClaw Release Checks` używa zaufanego ref przepływu pracy, aby raz rozpoznać docelowy +ref jako `release-package-under-test` i ponownie używa tego artefaktu zarówno w +release-path Docker checks, jak i Package Acceptance. Dzięki temu wszystkie +środowiska skierowane na pakiet używają tych samych bajtów i unikają powtarzanych buildów pakietu. +Cross-OS OpenAI install smoke używa `OPENCLAW_CROSS_OS_OPENAI_MODEL`, gdy +ustawiono zmienną repo/org, w przeciwnym razie `openai/gpt-5.4`, ponieważ ta ścieżka +potwierdza instalację pakietu, onboarding, uruchomienie Gateway i jedną turę agenta live, +a nie benchmarkuje najwolniejszego modelu domyślnego. Szersza macierz dostawców live +pozostaje miejscem na pokrycie specyficzne dla modeli. -Używaj tych wariantów zależnie od etapu wydania: +Użyj tych wariantów zależnie od etapu wydania: ```bash # Validate an unpublished release candidate branch. @@ -368,46 +361,40 @@ gh workflow run full-release-validation.yml \ -f npm_telegram_provider_mode=mock-openai ``` -Nie używaj pełnego parasola jako pierwszego ponownego uruchomienia po -ukierunkowanej poprawce. Jeśli jeden boks zawiedzie, użyj nieudanego workflow -potomnego, zadania, ścieżki Docker, profilu pakietu, providera modelu albo -ścieżki QA jako następnego dowodu. Uruchom pełny parasol ponownie tylko wtedy, -gdy poprawka zmieniła wspólną orkiestrację wydania albo sprawiła, że wcześniejsze -dowody ze wszystkich boksów stały się nieaktualne. Końcowy weryfikator parasola -ponownie sprawdza zapisane identyfikatory przebiegów workflow potomnych, więc po -udanym ponownym uruchomieniu workflow potomnego uruchom ponownie tylko nieudane +Nie używaj pełnego umbrella jako pierwszego ponownego uruchomienia po ukierunkowanej poprawce. Jeśli jedno środowisko +zawiedzie, do następnego dowodu użyj nieudanego przepływu potomnego, zadania, ścieżki Docker, +profilu pakietu, dostawcy modelu albo ścieżki QA. Uruchom pełny umbrella ponownie tylko wtedy, +gdy poprawka zmieniła współdzieloną orkiestrację wydania albo unieważniła wcześniejszy dowód ze wszystkich środowisk. +Końcowy weryfikator umbrella ponownie sprawdza zapisane identyfikatory uruchomień potomnych przepływów pracy, +więc po udanym ponownym uruchomieniu przepływu potomnego ponownie uruchom tylko nieudane zadanie nadrzędne `Verify full validation`. -Do ograniczonego odzyskiwania przekaż `rerun_group` do parasola. `all` jest -rzeczywistym przebiegiem release-candidate, `ci` uruchamia tylko normalny proces -potomny CI, `plugin-prerelease` uruchamia tylko proces potomny Plugin wyłącznie -dla wydania, `release-checks` uruchamia każdy boks wydania, a węższe grupy -wydania to `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, -`qa-parity`, `qa-live` oraz `npm-telegram`. Ukierunkowane ponowne uruchomienia -`npm-telegram` wymagają `npm_telegram_package_spec`; przebiegi full/all z -`release_profile=full` używają artefaktu pakietu z release-checks. +W celu ograniczonego odzyskiwania przekaż `rerun_group` do umbrella. `all` to prawdziwe +uruchomienie release-candidate, `ci` uruchamia tylko normalny proces potomny CI, `plugin-prerelease` +uruchamia tylko proces potomny pluginu wyłącznie dla wydania, `release-checks` uruchamia każde środowisko wydania, +a węższe grupy wydania to `install-smoke`, `cross-os`, +`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` i `npm-telegram`. +Ukierunkowane ponowne uruchomienia `npm-telegram` wymagają `npm_telegram_package_spec`; uruchomienia full/all +z `release_profile=full` używają artefaktu pakietu release-checks. ### Vitest -Boks Vitest to ręczny workflow potomny `CI`. Ręczne CI celowo omija zakres -zmian i wymusza normalny graf testów dla release candidate: shardy Linux Node, -shardy dołączonych Plugin, kontrakty kanałów, zgodność z Node 22, `check`, -`check-additional`, build smoke, kontrole dokumentacji, Python skills, Windows, -macOS, Android oraz i18n Control UI. +Środowisko Vitest to ręczny potomny przepływ pracy `CI`. Ręczne CI celowo +omija zakres zmian i wymusza normalny graf testów dla kandydata wydania: shardy Linux Node, +shardy bundled-plugin, kontrakty kanałów, zgodność Node 22, `check`, `check-additional`, +build smoke, sprawdzenia dokumentacji, Python skills, Windows, macOS, Android i Control UI i18n. -Użyj tego boksu, aby odpowiedzieć na pytanie „czy drzewo źródeł przeszło pełny -normalny zestaw testów?”. To nie to samo co walidacja produktu na ścieżce -wydania. Dowody do zachowania: +Użyj tego środowiska, aby odpowiedzieć na pytanie „czy drzewo źródeł przeszło pełny normalny zestaw testów?” +To nie to samo co walidacja produktu w ścieżce wydania. Dowody do zachowania: -- podsumowanie `Full Release Validation` pokazujące URL uruchomionego przebiegu `CI` -- zielony przebieg `CI` na dokładnym docelowym SHA +- podsumowanie `Full Release Validation` pokazujące URL uruchomionego `CI` +- zielone uruchomienie `CI` na dokładnym docelowym SHA - nazwy nieudanych lub wolnych shardów z zadań CI podczas badania regresji - artefakty czasów Vitest, takie jak `.artifacts/vitest-shard-timings.json`, gdy - przebieg wymaga analizy wydajności + uruchomienie wymaga analizy wydajności -Uruchom ręczne CI bezpośrednio tylko wtedy, gdy wydanie potrzebuje -deterministycznego normalnego CI, ale nie boksów Docker, QA Lab, live, cross-OS -ani pakietowych: +Uruchom ręczne CI bezpośrednio tylko wtedy, gdy wydanie wymaga deterministycznego normalnego CI, ale +nie środowisk Docker, QA Lab, live, cross-OS ani package: ```bash gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D @@ -415,69 +402,66 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D ### Docker -Boks Docker znajduje się w `OpenClaw Release Checks` przez -`openclaw-live-and-e2e-checks-reusable.yml` oraz workflow `install-smoke` w trybie -wydania. Waliduje release candidate przez spakowane środowiska Docker, a nie -tylko testy na poziomie źródeł. +Środowisko Docker znajduje się w `OpenClaw Release Checks` przez +`openclaw-live-and-e2e-checks-reusable.yml`, plus przepływ pracy `install-smoke` +w trybie wydania. Waliduje kandydata wydania przez spakowane +środowiska Docker, a nie tylko testy na poziomie źródeł. -Pokrycie Docker wydania obejmuje: +Pokrycie Docker dla wydania obejmuje: - pełny install smoke z włączonym wolnym globalnym install smoke Bun -- przygotowanie/ponowne użycie obrazu smoke root Dockerfile według docelowego - SHA, z zadaniami QR, root/gateway oraz installer/Bun smoke działającymi jako - osobne shardy install-smoke +- przygotowanie/ponowne użycie obrazu smoke root Dockerfile według docelowego SHA, z zadaniami QR, + root/gateway i installer/Bun smoke uruchamianymi jako osobne shardy install-smoke - ścieżki E2E repozytorium -- chunki Docker ścieżki wydania: `core`, `package-update-openai`, +- fragmenty release-path Docker: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a`, `plugins-runtime-install-b`, `plugins-runtime-install-c`, `plugins-runtime-install-d`, `plugins-runtime-install-e`, `plugins-runtime-install-f`, - `plugins-runtime-install-g` oraz `plugins-runtime-install-h` -- pokrycie OpenWebUI wewnątrz chunka `plugins-runtime-services`, gdy jest wymagane -- podzielone ścieżki instalacji/deinstalacji dołączonych Plugin - `bundled-plugin-install-uninstall-0` do + `plugins-runtime-install-g` i `plugins-runtime-install-h` +- pokrycie OpenWebUI wewnątrz fragmentu `plugins-runtime-services`, gdy jest wymagane +- podzielone ścieżki instalacji/deinstalacji bundled plugin + od `bundled-plugin-install-uninstall-0` do `bundled-plugin-install-uninstall-23` -- zestawy providerów live/E2E oraz pokrycie modeli Docker live, gdy release checks +- zestawy dostawców live/E2E i pokrycie modeli Docker live, gdy release checks obejmują zestawy live -Używaj artefaktów Docker przed ponownym uruchomieniem. Scheduler ścieżki -wydania przesyła `.artifacts/docker-tests/` z logami ścieżek, `summary.json`, -`failures.json`, czasami faz, planem schedulera JSON oraz poleceniami -ponownego uruchomienia. Do ukierunkowanego odzyskiwania użyj -`docker_lanes=` w reusable workflow live/E2E zamiast ponownie -uruchamiać wszystkie chunki wydania. Wygenerowane polecenia ponownego -uruchomienia obejmują wcześniejsze `package_artifact_run_id` i przygotowane -wejścia obrazów Docker, gdy są dostępne, więc nieudana ścieżka może ponownie użyć -tego samego tarballa i obrazów GHCR. +Użyj artefaktów Docker przed ponownym uruchomieniem. Harmonogram release-path przesyła +`.artifacts/docker-tests/` z logami ścieżek, `summary.json`, `failures.json`, +czasami faz, JSON planu harmonogramu i komendami ponownego uruchomienia. W celu ukierunkowanego odzyskiwania +użyj `docker_lanes=` w wielokrotnego użytku przepływie live/E2E zamiast +ponownie uruchamiać wszystkie fragmenty wydania. Wygenerowane komendy ponownego uruchomienia obejmują wcześniejsze +`package_artifact_run_id` oraz przygotowane wejścia obrazu Docker, gdy są dostępne, więc +nieudana ścieżka może ponownie użyć tego samego tarballa i obrazów GHCR. ### QA Lab -Boks QA Lab jest również częścią `OpenClaw Release Checks`. To bramka wydania -dla zachowania agentowego i poziomu kanałów, osobna od mechaniki pakietów Vitest -i Docker. +Środowisko QA Lab także jest częścią `OpenClaw Release Checks`. To agentowa +bramka zachowania i poziomu kanałów dla wydania, oddzielna od Vitest i mechaniki +pakietów Docker. -Pokrycie QA Lab wydania obejmuje: +Pokrycie QA Lab dla wydania obejmuje: -- ścieżkę parytetu mock porównującą ścieżkę kandydata OpenAI z baseline Opus 4.6 - przy użyciu pakietu parytetu agentowego +- ścieżkę mock parity porównującą ścieżkę kandydata OpenAI z bazą Opus 4.6 + przy użyciu agentowego pakietu parity - szybki profil QA live Matrix używający środowiska `qa-live-shared` - ścieżkę QA live Telegram używającą dzierżaw poświadczeń Convex CI - `pnpm qa:otel:smoke`, gdy telemetria wydania wymaga jawnego lokalnego dowodu -Użyj tego boksu, aby odpowiedzieć na pytanie „czy wydanie zachowuje się poprawnie -w scenariuszach QA i przepływach kanałów live?”. Przy zatwierdzaniu wydania -zachowaj URL-e artefaktów dla ścieżek parytetu, Matrix i Telegram. Pełne -pokrycie Matrix pozostaje dostępne jako ręczny shardowany przebieg QA-Lab, a nie -domyślna ścieżka krytyczna dla wydania. +Użyj tego środowiska, aby odpowiedzieć na pytanie „czy wydanie zachowuje się poprawnie w scenariuszach QA i +przepływach kanałów live?” Zachowaj URL-e artefaktów dla ścieżek parity, Matrix i Telegram +przy zatwierdzaniu wydania. Pełne pokrycie Matrix pozostaje dostępne jako +ręczne, shardowane uruchomienie QA-Lab, a nie domyślna ścieżka krytyczna dla wydania. ### Pakiet -Boks pakietu jest bramką produktu instalowalnego. Opiera się na -`Package Acceptance` i resolverze `scripts/resolve-openclaw-package-candidate.mjs`. -Resolver normalizuje kandydata do tarballa `package-under-test` używanego przez -Docker E2E, waliduje inwentarz pakietu, zapisuje wersję pakietu i SHA-256 oraz -oddziela ref harnessa workflow od ref źródła pakietu. +Środowisko Package to bramka produktu instalowalnego. Opiera się na +`Package Acceptance` i resolverze +`scripts/resolve-openclaw-package-candidate.mjs`. Resolver normalizuje +kandydata do tarballa `package-under-test` używanego przez Docker E2E, waliduje +inventory pakietu, zapisuje wersję pakietu i SHA-256 oraz utrzymuje +ref harnessu przepływu pracy oddzielnie od ref źródła pakietu. Obsługiwane źródła kandydatów: @@ -485,47 +469,43 @@ Obsługiwane źródła kandydatów: - `source=ref`: spakuj zaufaną gałąź, tag albo pełny SHA commita `package_ref` z wybranym harnessem `workflow_ref` - `source=url`: pobierz HTTPS `.tgz` z wymaganym `package_sha256` -- `source=artifact`: użyj ponownie `.tgz` przesłanego przez inny przebieg GitHub Actions +- `source=artifact`: użyj ponownie `.tgz` przesłanego przez inne uruchomienie GitHub Actions -`OpenClaw Release Checks` uruchamia Package Acceptance z `source=artifact`, -przygotowanym artefaktem pakietu wydania, `suite_profile=custom`, +`OpenClaw Release Checks` uruchamia 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` oraz -`telegram_mode=mock-openai`. Package Acceptance utrzymuje migrację, aktualizację, -czyszczenie przestarzałych zależności Plugin, offline fixtures Plugin, -aktualizację Plugin oraz QA pakietu Telegram względem tego samego rozwiązanego -tarballa. Macierz upgrade obejmuje każdy stabilny baseline opublikowany w npm od -`2026.4.23` do `latest`; użyj Package Acceptance z `source=npm` dla już -wysłanego kandydata albo `source=ref`/`source=artifact` dla lokalnego tarballa -npm opartego na SHA przed publikacją. To natywny dla GitHub zamiennik większości -pokrycia pakietu/aktualizacji, które wcześniej wymagało Parallels. Kontrole -wydania cross-OS nadal są ważne dla onboardingu, instalatora i zachowania -platformy specyficznych dla systemu operacyjnego, ale walidacja produktu w -zakresie pakietu/aktualizacji powinna preferować Package Acceptance. +`published_upgrade_survivor_scenarios=reported-issues` i +`telegram_mode=mock-openai`. Package Acceptance utrzymuje migrację, update, czyszczenie przestarzałych +zależności pluginów, offline fixtures pluginów, update pluginów oraz Telegram +package QA względem tego samego rozpoznanego tarballa. Macierz upgrade obejmuje każdą stabilną bazę opublikowaną w npm od `2026.4.23` do `latest`; użyj +Package Acceptance z `source=npm` dla już wysłanego kandydata albo +`source=ref`/`source=artifact` dla lokalnego tarballa npm opartego na SHA przed +publikacją. Jest to natywne dla GitHub +zastępstwo większości pokrycia package/update, które wcześniej wymagało +Parallels. Cross-OS release checks nadal mają znaczenie dla onboardingu, +instalatora i zachowań platformowych specyficznych dla OS, ale walidacja produktu package/update powinna +preferować Package Acceptance. -Kanoniczna checklista dla walidacji aktualizacji i Plugin to -[Testowanie aktualizacji i Plugin](/pl/help/testing-updates-plugins). Używaj jej -przy decydowaniu, która lokalna ścieżka, Docker, Package Acceptance albo -release-check dowodzi zmiany instalacji/aktualizacji Plugin, czyszczenia doctor -albo migracji opublikowanego pakietu. -Wyczerpująca migracja opublikowanych aktualizacji z każdego stabilnego pakietu -`2026.4.23+` jest osobnym ręcznym workflow `Update Migration`, a nie częścią Full -Release CI. +Kanoniczna lista kontrolna dla walidacji update i pluginów to +[Testowanie aktualizacji i pluginów](/pl/help/testing-updates-plugins). Użyj jej podczas +decydowania, która lokalna ścieżka, Docker, Package Acceptance albo release-check potwierdza +instalację/update pluginu, czyszczenie przez doctor albo zmianę migracji opublikowanego pakietu. +Wyczerpująca migracja opublikowanych update’ów z każdego stabilnego pakietu `2026.4.23+` to +osobny ręczny przepływ pracy `Update Migration`, nie część Full Release CI. -Łagodność legacy package-acceptance jest celowo ograniczona czasowo. Pakiety do -`2026.4.25` włącznie mogą używać ścieżki zgodności dla luk metadanych już -opublikowanych w npm: prywatnych wpisów inwentarza QA brakujących w tarballu, -brakującego `gateway install --wrapper`, brakujących plików patchy w fixture git -pochodzącym z tarballa, brakującego utrwalonego `update.channel`, legacy -lokalizacji rekordów instalacji Plugin, brakującej trwałości rekordów instalacji -marketplace oraz migracji metadanych konfiguracji podczas `plugins update`. -Opublikowany pakiet `2026.4.26` może ostrzegać o plikach znaczników metadanych -lokalnego buildu, które już zostały wysłane. Późniejsze pakiety muszą spełniać -nowoczesne kontrakty pakietów; te same luki powodują niepowodzenie walidacji +Pobłażliwość legacy package-acceptance jest celowo ograniczona czasowo. Pakiety do +`2026.4.25` mogą używać ścieżki zgodności dla luk w metadanych już opublikowanych +w npm: prywatnych wpisów inventory QA brakujących w tarballu, brakującego +`gateway install --wrapper`, brakujących plików patchy w fixture git pochodzącej z tarballa, +brakującego utrwalonego `update.channel`, legacy lokalizacji rekordów instalacji pluginów, +brakującego utrwalania rekordów instalacji marketplace oraz migracji metadanych config +podczas `plugins update`. Opublikowany pakiet `2026.4.26` może ostrzegać +o plikach znaczników metadanych lokalnego buildu, które już wysłano. Późniejsze pakiety +muszą spełniać nowoczesne kontrakty pakietów; te same luki powodują niepowodzenie walidacji wydania. -Używaj szerszych profili Package Acceptance, gdy pytanie o wydanie dotyczy +Użyj szerszych profili Package Acceptance, gdy pytanie o wydanie dotyczy rzeczywistego instalowalnego pakietu: ```bash @@ -540,31 +520,31 @@ gh workflow run package-acceptance.yml \ Typowe profile pakietów: -- `smoke`: szybkie ścieżki instalacji pakietu/kanału/agenta, sieci Gateway oraz - przeładowania konfiguracji -- `package`: kontrakty instalacji/aktualizacji/pakietu Plugin bez live ClawHub; to domyślna wartość release-check -- `product`: `package` plus kanały MCP, czyszczenie cron/subagent, wyszukiwanie - web OpenAI oraz OpenWebUI -- `full`: chunki Docker ścieżki wydania z OpenWebUI +- `smoke`: szybkie ścieżki instalacji pakietu/kanału/agenta, sieci Gateway i przeładowania config +- `package`: kontrakty pakietu install/update/plugin bez live ClawHub; to domyślny + release-check +- `product`: `package` plus kanały MCP, czyszczenie cron/subagent, wyszukiwanie web OpenAI + i OpenWebUI +- `full`: fragmenty release-path Docker z OpenWebUI - `custom`: dokładna lista `docker_lanes` do ukierunkowanych ponownych uruchomień -Do weryfikacji kandydata pakietu dla Telegram włącz `telegram_mode=mock-openai` lub -`telegram_mode=live-frontier` w Package Acceptance. Przepływ pracy przekazuje -rozwiązany tarball `package-under-test` do ścieżki Telegram; samodzielny -przepływ pracy Telegram nadal akceptuje opublikowaną specyfikację npm na potrzeby kontroli po publikacji. +W przypadku dowodu Telegram dla kandydata pakietu włącz `telegram_mode=mock-openai` lub +`telegram_mode=live-frontier` w Package Acceptance. Workflow przekazuje rozwiązany +tarball `package-under-test` do ścieżki Telegram; samodzielny workflow Telegram +nadal akceptuje opublikowaną specyfikację npm do kontroli po publikacji. ## Automatyzacja publikowania wydania -`OpenClaw Release Publish` to standardowy mutujący punkt wejścia publikacji. -Orkiestruje przepływy pracy zaufanego wydawcy w kolejności wymaganej przez wydanie: +`OpenClaw Release Publish` to normalny mutujący punkt wejścia publikacji. +Orkiestruje workflow zaufanego wydawcy w kolejności wymaganej przez wydanie: 1. Pobierz tag wydania i rozwiąż jego commit SHA. -2. Zweryfikuj, że tag jest osiągalny z `main` albo `release/*`. +2. Sprawdź, czy tag jest osiągalny z `main` lub `release/*`. 3. Uruchom `pnpm plugins:sync:check`. 4. Uruchom `Plugin NPM Release` z `publish_scope=all-publishable` i `ref=`. 5. Uruchom `Plugin ClawHub Release` z tym samym zakresem i SHA. -6. Uruchom `OpenClaw NPM Release` z tagiem wydania, tagiem dystrybucji npm i +6. Uruchom `OpenClaw NPM Release` z tagiem wydania, tagiem dist npm oraz zapisanym `preflight_run_id`. Przykład publikacji beta: @@ -577,17 +557,7 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=beta ``` -Przykład publikacji alfa: - -```bash -gh workflow run openclaw-release-publish.yml \ - --ref release/YYYY.M.D \ - -f tag=vYYYY.M.D-alpha.N \ - -f preflight_run_id= \ - -f npm_dist_tag=alpha -``` - -Stabilna publikacja do domyślnego tagu dystrybucji beta: +Stabilna publikacja do domyślnego tagu dist beta: ```bash gh workflow run openclaw-release-publish.yml \ @@ -607,94 +577,94 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=latest ``` -Używaj niższopoziomowych przepływów pracy `Plugin NPM Release` i `Plugin ClawHub Release` -tylko do ukierunkowanych napraw lub ponownych publikacji. Dla naprawy wybranego Plugin przekaż +Używaj workflow niższego poziomu `Plugin NPM Release` i `Plugin ClawHub Release` +tylko do skoncentrowanej naprawy lub ponownej publikacji. Dla naprawy wybranego pluginu przekaż `plugin_publish_scope=selected` i `plugins=@openclaw/name` do -`OpenClaw Release Publish`, albo uruchom podrzędny przepływ pracy bezpośrednio, gdy +`OpenClaw Release Publish` albo uruchom workflow podrzędny bezpośrednio, gdy pakiet OpenClaw nie może zostać opublikowany. -## Dane wejściowe przepływu pracy NPM +## Dane wejściowe workflow NPM -`OpenClaw NPM Release` akceptuje te dane wejściowe kontrolowane przez operatora: +`OpenClaw NPM Release` akceptuje następujące dane wejściowe kontrolowane przez operatora: - `tag`: wymagany tag wydania, taki jak `v2026.4.2`, `v2026.4.2-1` albo - `v2026.4.2-alpha.1` lub `v2026.4.2-beta.1`; gdy `preflight_only=true`, może to być także bieżący - pełny 40-znakowy commit SHA gałęzi przepływu pracy do preflightu wyłącznie walidacyjnego -- `preflight_only`: `true` tylko dla walidacji/budowania/pakietowania, `false` dla + `v2026.4.2-beta.1`; gdy `preflight_only=true`, może to być również bieżący + pełny 40-znakowy commit SHA gałęzi workflow dla wstępnej kontroli wyłącznie + walidacyjnej +- `preflight_only`: `true` tylko dla walidacji/budowania/pakietu, `false` dla rzeczywistej ścieżki publikacji -- `preflight_run_id`: wymagane na rzeczywistej ścieżce publikacji, aby przepływ pracy ponownie użył - przygotowanego tarballa z udanego przebiegu preflight +- `preflight_run_id`: wymagane w rzeczywistej ścieżce publikacji, aby workflow ponownie użył + przygotowanego tarballa z udanego przebiegu wstępnej kontroli - `npm_dist_tag`: docelowy tag npm dla ścieżki publikacji; domyślnie `beta` -`OpenClaw Release Publish` akceptuje te dane wejściowe kontrolowane przez operatora: +`OpenClaw Release Publish` akceptuje następujące dane wejściowe kontrolowane przez operatora: - `tag`: wymagany tag wydania; musi już istnieć -- `preflight_run_id`: identyfikator udanego przebiegu preflight `OpenClaw NPM Release`; +- `preflight_run_id`: identyfikator udanego przebiegu wstępnej kontroli `OpenClaw NPM Release`; wymagany, gdy `publish_openclaw_npm=true` - `npm_dist_tag`: docelowy tag npm dla pakietu OpenClaw - `plugin_publish_scope`: domyślnie `all-publishable`; używaj `selected` tylko - do ukierunkowanych napraw + do skoncentrowanych prac naprawczych - `plugins`: rozdzielone przecinkami nazwy pakietów `@openclaw/*`, gdy `plugin_publish_scope=selected` - `publish_openclaw_npm`: domyślnie `true`; ustaw `false` tylko wtedy, gdy używasz - przepływu pracy jako orkiestratora napraw wyłącznie dla Plugin + workflow jako orkiestratora napraw wyłącznie dla pluginów -`OpenClaw Release Checks` akceptuje te dane wejściowe kontrolowane przez operatora: +`OpenClaw Release Checks` akceptuje następujące dane wejściowe kontrolowane przez operatora: -- `ref`: gałąź, tag albo pełny commit SHA do walidacji. Kontrole używające sekretów +- `ref`: gałąź, tag lub pełny commit SHA do walidacji. Kontrole z sekretami wymagają, aby rozwiązany commit był osiągalny z gałęzi OpenClaw albo tagu wydania. -Reguły: +Zasady: -- Tagi stabilne i korekcyjne mogą publikować do `beta` albo `latest` -- Tagi przedwydania alfa mogą publikować tylko do `alpha` -- Tagi przedwydania beta mogą publikować tylko do `beta` -- Dla `OpenClaw NPM Release` pełny commit SHA jako dane wejściowe jest dozwolony tylko wtedy, gdy +- Tagi stabilne i korygujące mogą publikować do `beta` albo `latest` +- Tagi wydań beta mogą publikować tylko do `beta` +- W `OpenClaw NPM Release` pełny commit SHA jest dozwolony tylko wtedy, gdy `preflight_only=true` -- `OpenClaw Release Checks` i `Full Release Validation` zawsze są +- `OpenClaw Release Checks` i `Full Release Validation` są zawsze wyłącznie walidacyjne -- Rzeczywista ścieżka publikacji musi używać tego samego `npm_dist_tag`, którego użyto podczas preflight; - przepływ pracy weryfikuje te metadane przed kontynuacją publikacji +- Rzeczywista ścieżka publikacji musi używać tego samego `npm_dist_tag`, którego użyto podczas wstępnej kontroli; + workflow weryfikuje te metadane przed kontynuowaniem publikacji ## Sekwencja stabilnego wydania npm Podczas przygotowywania stabilnego wydania npm: 1. Uruchom `OpenClaw NPM Release` z `preflight_only=true` - - Zanim tag będzie istnieć, możesz użyć bieżącego pełnego SHA commita gałęzi przepływu pracy - do wyłącznie walidacyjnego próbnego uruchomienia przepływu preflight -2. Wybierz `npm_dist_tag=beta` dla normalnego przepływu najpierw-beta albo `latest` tylko - wtedy, gdy celowo chcesz bezpośrednią stabilną publikację + - Zanim tag istnieje, możesz użyć bieżącego pełnego commit SHA gałęzi workflow + do walidacyjnego suchego przebiegu workflow wstępnej kontroli +2. Wybierz `npm_dist_tag=beta` dla normalnego przepływu najpierw beta albo `latest` tylko + wtedy, gdy celowo chcesz bezpośrednio stabilnej publikacji 3. Uruchom `Full Release Validation` na gałęzi wydania, tagu wydania albo pełnym - commicie SHA, gdy chcesz uzyskać z jednego ręcznego przepływu pracy normalne CI oraz pokrycie live prompt cache, Docker, QA Lab, - Matrix i Telegram + commit SHA, gdy chcesz z jednego ręcznego workflow uzyskać normalne CI oraz pokrycie + live prompt cache, Docker, QA Lab, Matrix i Telegram 4. Jeśli celowo potrzebujesz tylko deterministycznego normalnego grafu testów, uruchom - ręczny przepływ pracy `CI` na refie wydania + ręczny workflow `CI` na referencji wydania 5. Zapisz udany `preflight_run_id` 6. Uruchom `OpenClaw Release Publish` z tym samym `tag`, tym samym `npm_dist_tag` - i zapisanym `preflight_run_id`; publikuje zewnętrzne pluginy do npm + oraz zapisanym `preflight_run_id`; publikuje zewnętrzne pluginy do npm i ClawHub przed promocją pakietu npm OpenClaw -7. Jeśli wydanie trafiło na `beta`, użyj prywatnego przepływu pracy +7. Jeśli wydanie trafiło na `beta`, użyj prywatnego workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, aby wypromować tę stabilną wersję z `beta` do `latest` 8. Jeśli wydanie celowo opublikowano bezpośrednio do `latest`, a `beta` - powinno natychmiast wskazywać ten sam stabilny build, użyj tego samego prywatnego - przepływu pracy, aby skierować oba tagi dystrybucji na stabilną wersję, albo pozwól jego zaplanowanej - samonaprawiającej synchronizacji przenieść `beta` później + powinno natychmiast wskazywać tę samą stabilną kompilację, użyj tego samego prywatnego + workflow, aby skierować oba tagi dist na stabilną wersję, albo pozwól, aby jego zaplanowana + samonaprawiająca synchronizacja przeniosła `beta` później -Mutacja tagu dystrybucji znajduje się w prywatnym repozytorium ze względów bezpieczeństwa, ponieważ nadal -wymaga `NPM_TOKEN`, podczas gdy publiczne repozytorium zachowuje publikowanie wyłącznie przez OIDC. +Mutacja tagów dist znajduje się w prywatnym repo ze względów bezpieczeństwa, ponieważ nadal +wymaga `NPM_TOKEN`, podczas gdy publiczne repo zachowuje publikowanie wyłącznie przez OIDC. -Dzięki temu zarówno bezpośrednia ścieżka publikacji, jak i ścieżka promocji najpierw-beta +Dzięki temu zarówno bezpośrednia ścieżka publikacji, jak i ścieżka promocji najpierw beta są udokumentowane i widoczne dla operatora. -Jeśli maintainer musi awaryjnie użyć lokalnego uwierzytelniania npm, uruchamiaj wszystkie polecenia 1Password -CLI (`op`) tylko w dedykowanej sesji tmux. Nie wywołuj `op` -bezpośrednio z głównej powłoki agenta; trzymanie go w tmux sprawia, że monity, +Jeśli maintainer musi awaryjnie użyć lokalnego uwierzytelniania npm, uruchamiaj wszystkie polecenia +CLI 1Password (`op`) tylko w dedykowanej sesji tmux. Nie wywołuj `op` +bezpośrednio z głównej powłoki agenta; utrzymywanie go wewnątrz tmux sprawia, że monity, alerty i obsługa OTP są obserwowalne oraz zapobiega powtarzającym się alertom hosta. -## Publiczne odwołania +## Publiczne odniesienia - [`.github/workflows/full-release-validation.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/full-release-validation.yml) - [`.github/workflows/package-acceptance.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/package-acceptance.yml) @@ -706,9 +676,9 @@ alerty i obsługa OTP są obserwowalne oraz zapobiega powtarzającym się alerto - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh) - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh) -Maintainerzy używają prywatnej dokumentacji wydań w +Maintainerzy używają prywatnej dokumentacji wydania w [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) -jako właściwej instrukcji wykonawczej. +jako właściwego runbooka. ## Powiązane diff --git a/docs/pl/web/control-ui.md b/docs/pl/web/control-ui.md index d2f689daf..7922bfa86 100644 --- 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://: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” - + ```bash openclaw devices list ``` - + ```bash openclaw devices approve ``` -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 --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 --role `. Zobacz [CLI urządzeń](/pl/cli/devices), aby uzyskać informacje o rotacji i odwoływaniu tokenów. - 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. -## 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/`, adresy URL edytora takie jak `https://tweakcn.com/editor/theme?theme=amethyst-haze`, względne ścieżki `/themes/`, 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/`, adresy URL edytora takie jak `https://tweakcn.com/editor/theme?theme=amethyst-haze`, względne ścieżki `/themes/`, 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) - - - 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). + + - 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). - - - 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`). + + - 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`). - + - 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.*`). - - - 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. + + - 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. - + - 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. - - - 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). + + - 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. @@ -154,54 +155,55 @@ Zaimportowane motywy są przechowywane tylko w bieżącym profilu przeglądarki. ## Zachowanie czatu - + - `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 `...`, `...`, `...`, `...` 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 `...`, `...`, `...`, `...` 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. - - 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. + + 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. - + - 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. - - - 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. + + - 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. -## 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. -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. -## 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`: Wyłącza wykonywanie skryptów wewnątrz hostowanych osadzeń. - 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. 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: ``` -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. -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) - - Utrzymuj Gateway na loopback i pozwól Tailscale Serve pośredniczyć z HTTPS: + + 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:///` (lub skonfigurowany `gateway.controlUi.basePath`) + - `https:///` (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. - 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. - + ```bash openclaw gateway --bind tailnet --token "$(openssl rand -hex 32)" ``` Następnie otwórz: - - `http://:18789/` (lub skonfigurowany `gateway.controlUi.basePath`) + - `http://: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`). @@ -313,17 +315,17 @@ Jeśli otworzysz pulpit przez zwykły HTTP (`http://` lub `http:///` (Serve) -- `http://127.0.0.1:18789/` (na hoście Gateway) +- `http://127.0.0.1:18789/` (na hoście gateway) - + ```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). - + ```json5 { gateway: { @@ -353,14 +355,14 @@ Udokumentowane wyjątki: ``` - `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. - - - 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). + + - 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). @@ -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/`) 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/`) 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/` zwraca obraz awatara tylko uwierzytelnionym wywołującym. `GET /avatar/?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. @@ -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%3A18789 ``` - Opcjonalne jednorazowe uwierzytelnienie (jeśli potrzebne): + Opcjonalne jednorazowe uwierzytelnianie (jeśli potrzebne): ```text http://localhost:5173/?gatewayUrl=wss%3A%2F%2F%3A18789#token= @@ -439,15 +441,15 @@ Control UI to pliki statyczne; cel WebSocket jest konfigurowalny i może różni - `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:` i `http://127.0.0.1:`, 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:` i `http://127.0.0.1:`, 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. diff --git a/docs/pl/web/webchat.md b/docs/pl/web/webchat.md index 4e8f72ac4..c213187a2 100644 --- 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 `...`, `...`, `...`, - `...` 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, + `...` 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