From 93aa12d49665abc71cdf80b275e2c8873e1c487c Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Thu, 23 Apr 2026 14:59:32 +0000 Subject: [PATCH] chore(i18n): refresh pl translations --- docs/pl/ci.md | 117 ++-- docs/pl/gateway/authentication.md | 139 +++-- docs/pl/gateway/cli-backends.md | 232 +++---- docs/pl/help/testing.md | 974 +++++++++++++++--------------- 4 files changed, 749 insertions(+), 713 deletions(-) diff --git a/docs/pl/ci.md b/docs/pl/ci.md index abd798c1c..168b4a9b7 100644 --- a/docs/pl/ci.md +++ b/docs/pl/ci.md @@ -1,100 +1,107 @@ --- read_when: - Musisz zrozumieć, dlaczego zadanie CI uruchomiło się lub nie uruchomiło. - - Debugujesz nieudane kontrole GitHub Actions. + - Diagnozujesz nieudane kontrole GitHub Actions. summary: Graf zadań CI, bramki zakresu i lokalne odpowiedniki poleceń title: Potok CI x-i18n: - generated_at: "2026-04-23T13:58:11Z" + generated_at: "2026-04-23T14:55:04Z" model: gpt-5.4 provider: openai - source_hash: c5a8ea0d8e428826169b0e6aced1caeb993106fe79904002125ace86b48cae1f + source_hash: e9a03440ae28a15167fc08d9c66bb1fd719ddfa1517aaecb119c80f2ad826c0d source_path: ci.md workflow: 15 --- # Potok CI -CI uruchamia się przy każdym pushu do `main` oraz dla każdego pull requesta. Wykorzystuje inteligentne zawężanie zakresu, aby pomijać kosztowne zadania, gdy zmieniły się tylko niepowiązane obszary. +CI uruchamia się przy każdym wypchnięciu do `main` i przy każdym pull requeście. Używa inteligentnego zawężania zakresu, aby pomijać kosztowne zadania, gdy zmieniły się tylko niepowiązane obszary. -QA Lab ma dedykowane ścieżki CI poza głównym workflow z inteligentnym zawężaniem zakresu. Workflow `Parity gate` uruchamia się dla pasujących zmian w PR oraz ręcznie; buduje prywatne środowisko uruchomieniowe QA i porównuje agentowe pakiety mock GPT-5.4 oraz Opus 4.6. Workflow `QA-Lab - All Lanes` uruchamia się co noc na `main` oraz ręcznie; rozdziela równolegle zadania mock parity gate, żywą ścieżkę Matrix i żywą ścieżkę Telegram. Zadania live używają środowiska `qa-live-shared`, a ścieżka Telegram używa dzierżaw Convex. `OpenClaw Release Checks` uruchamia również te same ścieżki QA Lab przed zatwierdzeniem wydania. +QA Lab ma dedykowane ścieżki CI poza głównym workflow z inteligentnym zawężaniem zakresu. Workflow +`Parity gate` uruchamia się przy pasujących zmianach w PR oraz ręcznie; buduje +prywatne środowisko uruchomieniowe QA i porównuje agentowe pakiety mock GPT-5.4 i Opus 4.6. Workflow `QA-Lab - All Lanes` uruchamia się nocą na `main` oraz +ręcznie; rozdziela równolegle mock parity gate, aktywną ścieżkę Matrix i aktywną +ścieżkę Telegram. Zadania aktywne używają środowiska `qa-live-shared`, +a ścieżka Telegram używa dzierżaw Convex. `OpenClaw Release +Checks` uruchamia również te same ścieżki QA Lab przed zatwierdzeniem wydania. ## Przegląd zadań -| Zadanie | Cel | Kiedy się uruchamia | -| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- | -| `preflight` | Wykrywa zmiany tylko w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze dla pushy i PR, które nie są szkicami | -| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze dla pushy i PR, które nie są szkicami | -| `security-dependency-audit` | Audyt produkcyjnego lockfile bez zależności względem ostrzeżeń npm | Zawsze dla pushy i PR, które nie są szkicami | -| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze dla pushy i PR, które nie są szkicami | -| `build-artifacts` | Buduje `dist/`, Control UI, sprawdzenia zbudowanych artefaktów i współdzielone artefakty podrzędne | Zmiany istotne dla Node | -| `checks-fast-core` | Szybkie ścieżki poprawności na Linuxie, takie jak sprawdzenia bundled/plugin-contract/protocol | Zmiany istotne dla Node | -| `checks-fast-contracts-channels` | Szardowane sprawdzenia kontraktów kanałów ze stabilnym zagregowanym wynikiem | Zmiany istotne dla Node | -| `checks-node-extensions` | Pełne szardy testów bundled pluginów w całym zestawie rozszerzeń | Zmiany istotne dla Node | -| `checks-node-core-test` | Szardy testów rdzenia Node, z wyłączeniem ścieżek kanałów, bundled, kontraktów i rozszerzeń | Zmiany istotne dla Node | -| `extension-fast` | Ukierunkowane testy tylko dla zmienionych bundled pluginów | Pull requesty ze zmianami w rozszerzeniach | -| `check` | Szardowany odpowiednik głównej lokalnej bramki: typy prod, lint, guardy, typy testów i ścisły smoke | Zmiany istotne dla Node | -| `check-additional` | Guardy architektury, granic, powierzchni rozszerzeń, granic pakietów i szardy gateway-watch | Zmiany istotne dla Node | -| `build-smoke` | Testy smoke zbudowanego CLI i smoke zużycia pamięci przy starcie | Zmiany istotne dla Node | -| `checks` | Weryfikator dla testów kanałów opartych na zbudowanych artefaktach oraz zgodności z Node 22 tylko dla pushy | Zmiany istotne dla Node | -| `check-docs` | Formatowanie dokumentacji, lint i sprawdzanie uszkodzonych linków | Zmieniona dokumentacja | -| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla Python Skills | -| `checks-windows` | Ścieżki testowe specyficzne dla Windows | Zmiany istotne dla Windows | -| `macos-node` | Ścieżka testów TypeScript na macOS z użyciem współdzielonych zbudowanych artefaktów | Zmiany istotne dla macOS | -| `macos-swift` | Lint, build i testy Swift dla aplikacji macOS | Zmiany istotne dla macOS | -| `android` | Testy jednostkowe Androida dla obu wariantów oraz jeden build debug APK | Zmiany istotne dla Androida | +| Zadanie | Cel | Kiedy się uruchamia | +| -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- | +| `preflight` | Wykrywa zmiany tylko w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze przy niedraftowych pushach i PR | +| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze przy niedraftowych pushach i PR | +| `security-dependency-audit` | Niezależny od zależności audyt produkcyjnego lockfile względem ostrzeżeń npm | Zawsze przy niedraftowych pushach i PR | +| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze przy niedraftowych pushach i PR | +| `build-artifacts` | Buduje `dist/`, Control UI, kontrole zbudowanych artefaktów i artefakty wielokrotnego użytku dla zadań podrzędnych | Zmiany istotne dla Node | +| `checks-fast-core` | Szybkie linuksowe ścieżki poprawności, takie jak kontrole bundled/plugin-contract/protocol | Zmiany istotne dla Node | +| `checks-fast-contracts-channels` | Szardowane kontrole kontraktów kanałów ze stabilnym zagregowanym wynikiem kontroli | Zmiany istotne dla Node | +| `checks-node-extensions` | Pełne szardy testów bundled-plugin w całym zestawie rozszerzeń | Zmiany istotne dla Node | +| `checks-node-core-test` | Szardy testów rdzenia Node, z wyłączeniem kanałów, bundled, kontraktów i ścieżek rozszerzeń | Zmiany istotne dla Node | +| `extension-fast` | Ukierunkowane testy tylko dla zmienionych bundled plugins | Pull requesty ze zmianami w rozszerzeniach | +| `check` | Szardowany odpowiednik głównej lokalnej bramki: typy prod, lint, guardy, typy testowe i ścisły smoke | Zmiany istotne dla Node | +| `check-additional` | Architektura, granice, guardy powierzchni rozszerzeń, granice pakietów i szardy gateway-watch | Zmiany istotne dla Node | +| `build-smoke` | Smoke testy zbudowanego CLI i smoke pamięci przy uruchamianiu | Zmiany istotne dla Node | +| `checks` | Weryfikator dla testów kanałów na zbudowanych artefaktach oraz zgodności tylko dla pushy z Node 22 | Zmiany istotne dla Node | +| `check-docs` | Formatowanie dokumentacji, lint i kontrole niedziałających linków | Zmieniona dokumentacja | +| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla Python Skills | +| `checks-windows` | Ścieżki testowe specyficzne dla Windows | Zmiany istotne dla Windows | +| `macos-node` | Ścieżka testów TypeScript na macOS z użyciem współdzielonych zbudowanych artefaktów | Zmiany istotne dla macOS | +| `macos-swift` | Lint, build i testy Swift dla aplikacji macOS | Zmiany istotne dla macOS | +| `android` | Testy jednostkowe Androida dla obu wariantów oraz jeden build debug APK | Zmiany istotne dla Androida | -## Kolejność Fail-Fast +## Kolejność fail-fast -Zadania są uporządkowane tak, aby tanie sprawdzenia kończyły się niepowodzeniem przed uruchomieniem drogich zadań: +Zadania są uporządkowane tak, aby tanie kontrole kończyły się niepowodzeniem przed uruchomieniem droższych: 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 osobne zadania. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` kończą się szybko bez czekania na cięższe zadania artefaktów i macierzy platform. -3. `build-artifacts` nakłada się na szybkie ścieżki Linux, aby odbiorcy podrzędni mogli zacząć, gdy tylko współdzielony build będzie gotowy. -4. Cięższe ścieżki platformowe i uruchomieniowe rozgałęziają się potem: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, tylko-PR `extension-fast`, `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` szybko kończą się niepowodzeniem bez czekania na cięższe zadania artefaktów i macierzy platform. +3. `build-artifacts` działa równolegle z szybkimi linuksowymi ścieżkami, aby zadania podrzędne mogły ruszyć, gdy tylko współdzielony build będzie gotowy. +4. Cięższe ścieżki platformowe i runtime rozdzielają się później: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, tylko-PR `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`. -Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest pokryta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`. -Edycje workflow CI walidują graf Node CI oraz linting workflow, ale same nie wymuszają natywnych buildów Windows, Androida ani macOS; te ścieżki platformowe nadal są zawężane do zmian w kodzie danej platformy. -Sprawdzenia Windows Node są zawężane do wrapperów procesów/ścieżek specyficznych dla Windows, helperów uruchomieniowych npm/pnpm/UI, konfiguracji menedżera pakietów oraz powierzchni workflow CI, które uruchamiają tę ścieżkę; niepowiązane zmiany w kodzie źródłowym, pluginach, install-smoke oraz zmiany tylko w testach pozostają na ścieżkach Linux Node, aby nie rezerwować 16-vCPU workera Windows dla pokrycia, które i tak zapewniają normalne szardy testów. -Osobny workflow `install-smoke` ponownie używa tego samego skryptu zakresu przez własne zadanie `preflight`. Oblicza `run_install_smoke` na podstawie węższego sygnału changed-smoke, więc smoke Docker/install uruchamia się dla zmian związanych z instalacją, pakowaniem, kontenerami, produkcyjnymi zmianami bundled extension oraz powierzchniami rdzenia plugin/channel/gateway/Plugin SDK, które wykorzystują zadania Docker smoke. Edycje tylko testów i tylko dokumentacji nie rezerwują workerów Dockera. Jego smoke dla pakietu QR wymusza ponowne uruchomienie warstwy Docker `pnpm install`, zachowując jednocześnie cache BuildKit pnpm store, więc nadal testuje instalację bez ponownego pobierania zależności przy każdym uruchomieniu. Jego gateway-network e2e ponownie używa obrazu runtime zbudowanego wcześniej w zadaniu, więc dodaje rzeczywiste pokrycie WebSocket między kontenerami bez dokładania kolejnego buildu Dockera. Lokalnie `test:docker:all` wstępnie buduje jeden współdzielony obraz live-test i jeden współdzielony obraz built-app z `scripts/e2e/Dockerfile`, a następnie uruchamia równolegle ścieżki smoke live/E2E z `OPENCLAW_SKIP_DOCKER_BUILD=1`; domyślną współbieżność 4 można dostroić przez `OPENCLAW_DOCKER_ALL_PARALLELISM`. Lokalny agregat domyślnie przestaje planować nowe ścieżki z puli po pierwszym błędzie, a każda ścieżka ma limit czasu 120 minut, który można nadpisać przez `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Ścieżki wrażliwe na start lub providera uruchamiają się wyłącznie po puli równoległej. Workflow wielokrotnego użytku live/E2E odzwierciedla wzorzec współdzielonego obrazu, budując i wypychając jeden obraz Docker E2E z tagiem SHA do GHCR przed macierzą Dockera, a następnie uruchamiając macierz z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Zaplanowany workflow live/E2E uruchamia codziennie pełny zestaw Dockera dla ścieżki wydaniowej. Testy Docker dla QR i instalatora zachowują własne Dockerfile skoncentrowane na instalacji. Osobne zadanie `docker-e2e-fast` uruchamia ograniczony profil bundled pluginów w Dockerze z limitem czasu polecenia 120 sekund: naprawa zależności setup-entry oraz izolacja syntetycznych awarii bundled-loader. Pełna macierz aktualizacji bundled i kanałów pozostaje ręczna/pełny zestaw, ponieważ wykonuje powtarzane rzeczywiste przebiegi npm update i napraw przez doctor. +Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest objęta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`. +Edycje workflow CI weryfikują graf Node CI oraz lint workflow, ale same w sobie nie wymuszają natywnych buildów Windows, Android ani macOS; te ścieżki platformowe nadal są zawężone do zmian w kodzie danej platformy. +Kontrole Node dla Windows są zawężone do wrapperów procesów/ścieżek specyficznych dla Windows, helperów uruchamiania npm/pnpm/UI, konfiguracji menedżera pakietów i powierzchni workflow CI, które uruchamiają tę ścieżkę; niepowiązane zmiany w kodzie źródłowym, plugin, install-smoke i samych testach pozostają w linuksowych ścieżkach Node, aby nie rezerwować 16-vCPU workera Windows dla pokrycia, które jest już wykonywane przez zwykłe szardy testowe. +Osobny workflow `install-smoke` używa ponownie tego samego skryptu zakresu przez własne zadanie `preflight`. Wylicza `run_install_smoke` z węższego sygnału changed-smoke, więc smoke Docker/install uruchamia się dla zmian związanych z instalacją, pakowaniem, kontenerami, zmian produkcyjnych bundled extension oraz głównych powierzchni plugin/channel/gateway/Plugin SDK, które wykonują zadania smoke Dockera. Edycje tylko testów i tylko dokumentacji nie rezerwują workerów Docker. Jego smoke pakietu QR wymusza ponowne uruchomienie warstwy Docker `pnpm install`, zachowując cache magazynu pnpm BuildKit, więc nadal wykonuje instalację bez ponownego pobierania zależności przy każdym uruchomieniu. Jego gateway-network e2e ponownie używa obrazu runtime zbudowanego wcześniej w zadaniu, więc dodaje rzeczywiste pokrycie WebSocket między kontenerami bez dodawania kolejnego builda Docker. Lokalne `test:docker:all` buduje wcześniej jeden współdzielony obraz live-test i jeden współdzielony obraz built-app z `scripts/e2e/Dockerfile`, a następnie uruchamia równolegle ścieżki smoke live/E2E z `OPENCLAW_SKIP_DOCKER_BUILD=1`; domyślną współbieżność 4 można dostroić przez `OPENCLAW_DOCKER_ALL_PARALLELISM`. Lokalny agregat domyślnie przestaje planować nowe ścieżki z puli po pierwszym niepowodzeniu, a każda ścieżka ma limit czasu 120 minut, który można nadpisać przez `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Ścieżki wrażliwe na uruchamianie lub dostawców działają wyłącznie po zakończeniu puli równoległej. Workflow live/E2E wielokrotnego użytku odwzorowuje wzorzec współdzielonego obrazu, budując i wypychając jeden obraz Docker E2E GHCR oznaczony SHA przed macierzą Docker, a następnie uruchamiając macierz z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Zaplanowany workflow live/E2E uruchamia codziennie pełny zestaw Docker dla ścieżki wydaniowej. Testy Docker QR i instalatora zachowują własne Dockerfile skoncentrowane na instalacji. Osobne zadanie `docker-e2e-fast` uruchamia ograniczony profil Docker bundled-plugin z limitem czasu polecenia 120 sekund: naprawa zależności setup-entry oraz izolacja syntetycznej awarii bundled-loader. Pełna macierz aktualizacji bundled i kanałów pozostaje ręczna/pełnego zestawu, ponieważ wykonuje powtarzane rzeczywiste przebiegi npm update i naprawy doctor. -Lokalna logika zmienionych ścieżek znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka jest bardziej rygorystyczna względem granic architektury niż szeroki zakres platform CI: produkcyjne zmiany w rdzeniu uruchamiają typecheck prod rdzenia oraz testy rdzenia, zmiany tylko w testach rdzenia uruchamiają tylko typecheck/testy testowe rdzenia, produkcyjne zmiany rozszerzeń uruchamiają typecheck prod rozszerzeń oraz testy rozszerzeń, a zmiany tylko w testach rozszerzeń uruchamiają tylko typecheck/testy testowe rozszerzeń. Publiczne zmiany Plugin SDK lub plugin-contract rozszerzają walidację na rozszerzenia, ponieważ rozszerzenia zależą od tych kontraktów rdzenia. Podbicia wersji ograniczone wyłącznie do metadanych wydania uruchamiają ukierunkowane sprawdzenia wersji/konfiguracji/zależności głównych. Nieznane zmiany w root/config w trybie bezpiecznym uruchamiają wszystkie ścieżki. +Lokalna logika zmienionych ścieżek znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka jest bardziej rygorystyczna wobec granic architektury niż szeroki zakres platform CI: zmiany produkcyjne rdzenia uruchamiają typecheck prod rdzenia oraz testy rdzenia, zmiany tylko w testach rdzenia uruchamiają tylko typecheck/testy testowe rdzenia, zmiany produkcyjne rozszerzeń uruchamiają typecheck prod rozszerzeń oraz testy rozszerzeń, a zmiany tylko w testach rozszerzeń uruchamiają tylko typecheck/testy testowe rozszerzeń. Zmiany w publicznym Plugin SDK lub plugin-contract rozszerzają walidację na rozszerzenia, ponieważ rozszerzenia zależą od tych kontraktów rdzenia. Zmiany wyłącznie w metadanych wydania, takie jak podbicie wersji, uruchamiają ukierunkowane kontrole wersji/konfiguracji/zależności głównych. Nieznane zmiany w root/config w trybie bezpiecznym uruchamiają wszystkie ścieżki. -Przy pushach macierz `checks` dodaje ścieżkę `compat-node22` tylko dla pushy. Dla pull requestów ta ścieżka jest pomijana, a macierz pozostaje skupiona na zwykłych ścieżkach testów/kanałów. +Przy pushach macierz `checks` dodaje ścieżkę `compat-node22`, uruchamianą tylko przy pushach. Przy pull requestach ta ścieżka jest pomijana, a macierz pozostaje skupiona na zwykłych ścieżkach testów/kanałów. -Najwolniejsze rodziny testów Node są dzielone lub równoważone tak, aby każde zadanie pozostawało małe: kontrakty kanałów dzielą pokrycie rejestru i rdzenia na łącznie sześć ważonych szardów, testy bundled pluginów są równoważone na sześciu workerach rozszerzeń, auto-reply działa jako trzech zrównoważonych workerów zamiast sześciu małych workerów, a agentowe konfiguracje gateway/plugin są rozkładane na istniejące zadania agentic Node tylko ze źródeł zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarki, QA, mediów i różnych pluginów używają swoich dedykowanych konfiguracji Vitest zamiast współdzielonej ogólnej konfiguracji pluginów. Szeroka ścieżka agents używa współdzielonego planisty równoległości plików Vitest, ponieważ dominuje w niej import/schedulowanie, a nie pojedynczy wolny plik testowy. `runtime-config` działa z szardem infra core-runtime, aby współdzielony szard runtime nie był właścicielem końcowego ogona. `check-additional` utrzymuje razem prace compile/canary dla granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; szard boundary guard uruchamia swoje małe niezależne guardy współbieżnie w ramach jednego zadania. Gateway watch, testy kanałów i szard granicy wsparcia rdzenia uruchamiają się współbieżnie w `build-artifacts` po zbudowaniu `dist/` i `dist-runtime/`, zachowując swoje stare nazwy sprawdzeń jako lekkie zadania weryfikujące, a jednocześnie unikając dwóch dodatkowych workerów Blacksmith i drugiej kolejki odbiorców artefaktów. -Android CI uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje debug APK dla Play. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje ten wariant z flagami SMS/call-log w BuildConfig, jednocześnie unikając duplikowania zadania pakowania debug APK przy każdym pushu istotnym dla Androida. -`extension-fast` jest tylko dla PR, ponieważ przebiegi push i tak wykonują pełne szardy bundled pluginów. Dzięki temu recenzje dostają szybką informację zwrotną dla zmienionych pluginów bez rezerwowania dodatkowego workera Blacksmith na `main` dla pokrycia już obecnego w `checks-node-extensions`. +Najwolniejsze rodziny testów Node są dzielone lub równoważone, aby każde zadanie pozostawało małe bez nadmiernego rezerwowania runnerów: kontrakty kanałów działają jako trzy ważone szardy, testy bundled plugin są równoważone między sześcioma workerami rozszerzeń, małe ścieżki jednostkowe rdzenia są łączone w pary, auto-reply działa na trzech zrównoważonych workerach zamiast sześciu małych, 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óżnych plugin używają swoich dedykowanych konfiguracji Vitest zamiast współdzielonego ogólnego zestawu pluginów. Szeroka ścieżka agents używa współdzielonego planisty równoległego plików Vitest, ponieważ dominuje w niej import/szeregowanie, a nie pojedynczy wolny plik testowy. `runtime-config` działa z szardem infra core-runtime, aby współdzielony szard runtime nie pozostawał właścicielem końcówki. `check-additional` trzyma razem kompilację/canary granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; szard boundary guard uruchamia swoje małe niezależne guardy współbieżnie w ramach jednego zadania. Gateway watch, testy kanałów i szard granicy wsparcia rdzenia działają współbieżnie wewnątrz `build-artifacts` po tym, jak `dist/` i `dist-runtime/` są już zbudowane, zachowując swoje stare nazwy kontroli jako lekkie zadania weryfikujące, a jednocześnie unikając dwóch dodatkowych workerów Blacksmith i drugiej kolejki konsumentów artefaktów. +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 ten wariant z flagami BuildConfig dla SMS/call-log, jednocześnie unikając zduplikowanego zadania pakowania debug APK przy każdym pushu istotnym dla Androida. +`extension-fast` jest tylko dla PR, ponieważ uruchomienia push już wykonują pełne szardy bundled plugin. Dzięki temu recenzje dostają szybki feedback dla zmienionych pluginów bez rezerwowania dodatkowego workera Blacksmith na `main` dla pokrycia już obecnego w `checks-node-extensions`. -GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowszy push trafi do tego samego PR lub refa `main`. Traktuj to jako szum CI, chyba że najnowszy przebieg dla tego samego refa również kończy się błędem. Zagregowane sprawdzenia szardów używają `!cancelled() && always()`, więc nadal zgłaszają zwykłe błędy szardów, ale nie ustawiają się w kolejce po tym, jak cały workflow został już zastąpiony. -Klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHub w starej grupie kolejki nie mogło bezterminowo blokować nowszych przebiegów na main. +GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowszy push trafi na ten sam ref PR lub `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tego samego ref również kończy się niepowodzeniem. Zagregowane kontrole shardów używają `!cancelled() && always()`, dzięki czemu nadal raportują zwykłe awarie shardów, ale nie ustawiają się w kolejce po tym, jak cały workflow został już zastąpiony. +Klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHub w starej grupie kolejki nie mogło bezterminowo blokować nowszych uruchomień na main. -## Runery +## Runnery | Runner | Zadania | -| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, szybkie zadania bezpieczeństwa i agregaty (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie sprawdzenia protocol/contract/bundled, szardowane sprawdzenia kontraktów kanałów, szardy `check` z wyjątkiem lint, szardy i agregaty `check-additional`, zagregowane weryfikatory testów Node, sprawdzenia dokumentacji, Python Skills, workflow-sanity, labeler, auto-response; preflight dla install-smoke również używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła wcześniej trafić do kolejki | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, szardy testów Linux Node, szardy testów bundled pluginów, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, które pozostaje na tyle wrażliwe na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało; buildy Docker dla install-smoke, gdzie czas oczekiwania w kolejce dla 32 vCPU kosztował więcej, niż oszczędzał | +| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `ubuntu-24.04` | `preflight`, szybkie zadania bezpieczeństwa i agregaty (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie kontrole protocol/contract/bundled, szardowane kontrole kontraktów kanałów, szardy `check` z wyjątkiem lint, szardy i agregaty `check-additional`, zagregowane weryfikatory testów Node, kontrole dokumentacji, Python Skills, workflow-sanity, labeler, auto-response; preflight install-smoke również używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła wcześniej trafić do kolejki | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, szardy testów Linux Node, szardy testów bundled plugin, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, które nadal jest na tyle wrażliwe na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało; buildy Docker dla install-smoke, gdzie czas oczekiwania 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` | +| `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` | ## Lokalne odpowiedniki ```bash pnpm changed:lanes # sprawdź lokalny klasyfikator zmienionych ścieżek dla origin/main...HEAD pnpm check:changed # inteligentna lokalna bramka: zmienione typecheck/lint/testy według ścieżki granicznej -pnpm check # szybka lokalna bramka: produkcyjne tsgo + szardowany lint + równoległe szybkie guardy +pnpm check # szybka lokalna bramka: produkcyjny tsgo + szardowany lint + równoległe szybkie guardy pnpm check:test-types -pnpm check:timed # ta sama bramka z czasami dla każdego etapu +pnpm check:timed # ta sama bramka z pomiarami czasu dla każdego etapu pnpm build:strict-smoke pnpm check:architecture pnpm test:gateway:watch-regression pnpm test # testy vitest pnpm test:channels pnpm test:contracts:channels -pnpm check:docs # formatowanie dokumentacji + lint + uszkodzone linki -pnpm build # zbuduj dist, gdy ścieżki CI artifact/build-smoke mają znaczenie -node scripts/ci-run-timings.mjs # podsumuj czas wykonania, czas w kolejce i najwolniejsze zadania +pnpm check:docs # formatowanie dokumentacji + lint + niedziałające linki +pnpm build # zbuduj dist, gdy mają znaczenie ścieżki CI artifact/build-smoke +node scripts/ci-run-timings.mjs # podsumuj czas całkowity, czas w kolejce i najwolniejsze zadania +node scripts/ci-run-timings.mjs --recent 10 # porównaj ostatnie udane uruchomienia CI na main ``` diff --git a/docs/pl/gateway/authentication.md b/docs/pl/gateway/authentication.md index b8f87e1fb..d21b322c0 100644 --- a/docs/pl/gateway/authentication.md +++ b/docs/pl/gateway/authentication.md @@ -1,14 +1,14 @@ --- read_when: - - Debugujesz uwierzytelnianie modelu lub wygaśnięcie OAuth - - Dokumentujesz uwierzytelnianie lub przechowywanie poświadczeń -summary: 'Uwierzytelnianie modeli: OAuth, klucze API, ponowne użycie Claude CLI i setup-token Anthropic' + - Debugowanie uwierzytelniania modelu lub wygaśnięcia OAuth + - Dokumentowanie uwierzytelniania lub przechowywania poświadczeń +summary: 'Uwierzytelnianie modeli: OAuth, klucze API, ponowne użycie Claude CLI oraz token konfiguracji Anthropic' title: Uwierzytelnianie x-i18n: - generated_at: "2026-04-07T09:44:52Z" + generated_at: "2026-04-23T14:55:01Z" model: gpt-5.4 provider: openai - source_hash: 9db0ad9eccd7e3e3ca328adaad260bc4288a8ccdbe2dc0c24d9fd049b7ab9231 + source_hash: 37a7c20872b915d1d079f0578c933e43cbdb97eca1c60d8c4e6e5137ca83f8b2 source_path: gateway/authentication.md workflow: 15 --- @@ -16,35 +16,31 @@ x-i18n: # Uwierzytelnianie (dostawcy modeli) -Ta strona opisuje uwierzytelnianie **dostawców modeli** (klucze API, OAuth, ponowne użycie Claude CLI i setup-token Anthropic). W przypadku uwierzytelniania **połączenia z gateway** (token, hasło, trusted-proxy) zobacz [Configuration](/pl/gateway/configuration) i [Trusted Proxy Auth](/pl/gateway/trusted-proxy-auth). +Ta strona dotyczy uwierzytelniania **dostawcy modeli** (klucze API, OAuth, ponowne użycie Claude CLI oraz token konfiguracji Anthropic). Informacje o uwierzytelnianiu **połączenia z Gateway** (token, hasło, trusted-proxy) znajdziesz w [Configuration](/pl/gateway/configuration) oraz [Trusted Proxy Auth](/pl/gateway/trusted-proxy-auth). -OpenClaw obsługuje OAuth i klucze API dla dostawców modeli. Dla stale działających -hostów gateway klucze API są zwykle najbardziej przewidywalną opcją. Obsługiwane są -również przepływy subskrypcyjne/OAuth, gdy pasują do modelu konta u danego dostawcy. +OpenClaw obsługuje OAuth i klucze API dla dostawców modeli. W przypadku hostów Gateway działających stale klucze API są zwykle najbardziej przewidywalną opcją. Obsługiwane są również przepływy subskrypcji/OAuth, gdy pasują do modelu konta u dostawcy. -Zobacz [/concepts/oauth](/pl/concepts/oauth), aby poznać pełny przepływ OAuth i układ -przechowywania. -W przypadku uwierzytelniania opartego na SecretRef (dostawcy `env`/`file`/`exec`) zobacz [Secrets Management](/pl/gateway/secrets). -Informacje o regułach kwalifikowalności poświadczeń i kodów powodów używanych przez `models status --probe` znajdziesz w +Pełny przebieg OAuth i układ przechowywania opisano w [/concepts/oauth](/pl/concepts/oauth). +Informacje o uwierzytelnianiu opartym na SecretRef (dostawcy `env`/`file`/`exec`) znajdziesz w [Secrets Management](/pl/gateway/secrets). +Informacje o zasadach kwalifikowalności poświadczeń i kodach przyczyn używanych przez `models status --probe` znajdziesz w [Auth Credential Semantics](/pl/auth-credential-semantics). ## Zalecana konfiguracja (klucz API, dowolny dostawca) -Jeśli uruchamiasz długo działający gateway, zacznij od klucza API dla wybranego +Jeśli uruchamiasz długo działający Gateway, zacznij od klucza API dla wybranego dostawcy. -W przypadku Anthropic uwierzytelnianie kluczem API nadal jest najbardziej przewidywalną konfiguracją serwerową, -ale OpenClaw obsługuje też ponowne użycie lokalnego logowania Claude CLI. +W przypadku Anthropic uwierzytelnianie kluczem API nadal jest najbardziej przewidywalną konfiguracją serwerową, ale OpenClaw obsługuje też ponowne użycie lokalnego logowania Claude CLI. 1. Utwórz klucz API w konsoli dostawcy. -2. Umieść go na **hoście gateway** (maszynie uruchamiającej `openclaw gateway`). +2. Umieść go na **hoście Gateway** (maszynie uruchamiającej `openclaw gateway`). ```bash export _API_KEY="..." openclaw models status ``` -3. Jeśli Gateway działa pod systemd/launchd, lepiej umieścić klucz w +3. Jeśli Gateway działa pod systemd/launchd, najlepiej umieścić klucz w `~/.openclaw/.env`, aby demon mógł go odczytać: ```bash @@ -53,50 +49,62 @@ cat >> ~/.openclaw/.env <<'EOF' EOF ``` -Następnie uruchom ponownie demona (lub zrestartuj proces Gateway) i sprawdź ponownie: +Następnie uruchom ponownie demona (lub proces Gateway) i sprawdź ponownie: ```bash openclaw models status openclaw doctor ``` -Jeśli nie chcesz samodzielnie zarządzać zmiennymi env, onboarding może zapisać +Jeśli wolisz nie zarządzać samodzielnie zmiennymi środowiskowymi, onboarding może zapisać klucze API do użycia przez demona: `openclaw onboard`. -Szczegóły o dziedziczeniu env (`env.shellEnv`, +Szczegóły dotyczące dziedziczenia środowiska (`env.shellEnv`, `~/.openclaw/.env`, systemd/launchd) znajdziesz w [Help](/pl/help). ## Anthropic: zgodność Claude CLI i tokenów -Uwierzytelnianie setup-token Anthropic jest nadal dostępne w OpenClaw jako obsługiwana -ścieżka tokenu. Personel Anthropic poinformował nas później, że użycie Claude CLI w stylu OpenClaw -jest znowu dozwolone, więc OpenClaw traktuje ponowne użycie Claude CLI i użycie `claude -p` jako -zaakceptowane dla tej integracji, chyba że Anthropic opublikuje nowe zasady. Gdy -ponowne użycie Claude CLI jest dostępne na hoście, jest to obecnie preferowana ścieżka. +Uwierzytelnianie tokenem konfiguracji Anthropic jest nadal dostępne w OpenClaw jako obsługiwana ścieżka tokenu. Zespół Anthropic poinformował nas później, że użycie Claude CLI w stylu OpenClaw jest ponownie dozwolone, więc OpenClaw traktuje ponowne użycie Claude CLI oraz użycie `claude -p` jako usankcjonowane dla tej integracji, chyba że Anthropic opublikuje nową politykę. Gdy ponowne użycie Claude CLI jest dostępne na hoście, jest to obecnie preferowana ścieżka. -Dla długo działających hostów gateway klucz API Anthropic nadal jest najbardziej przewidywalną -konfiguracją. Jeśli chcesz ponownie użyć istniejącego logowania Claude na tym samym hoście, -użyj ścieżki Anthropic Claude CLI w onboardingu/konfiguracji. +W przypadku długo działających hostów Gateway klucz API Anthropic nadal jest najbardziej przewidywalną konfiguracją. Jeśli chcesz ponownie użyć istniejącego logowania Claude na tym samym hoście, użyj ścieżki Anthropic Claude CLI w onboarding/configure. -Ręczne wprowadzanie tokenu (dowolny dostawca; zapisuje `auth-profiles.json` i aktualizuje config): +Zalecana konfiguracja hosta do ponownego użycia Claude CLI: + +```bash +# Run on the gateway host +claude auth login +claude auth status --text +openclaw models auth login --provider anthropic --method cli --set-default +``` + +Jest to konfiguracja dwuetapowa: + +1. Zaloguj samo Claude Code do Anthropic na hoście Gateway. +2. Powiedz OpenClaw, aby przełączył wybór modelu Anthropic na lokalny backend `claude-cli` + i zapisał odpowiadający mu profil uwierzytelniania OpenClaw. + +Jeśli `claude` nie jest w `PATH`, najpierw zainstaluj Claude Code albo ustaw +`agents.defaults.cliBackends.claude-cli.command` na rzeczywistą ścieżkę do pliku binarnego. + +Ręczne wklejenie tokenu (dowolny dostawca; zapisuje `auth-profiles.json` + aktualizuje konfigurację): ```bash openclaw models auth paste-token --provider openrouter ``` -Obsługiwane są też odwołania do profili auth dla statycznych poświadczeń: +Odwołania do profili uwierzytelniania są też obsługiwane dla statycznych poświadczeń: - poświadczenia `api_key` mogą używać `keyRef: { source, provider, id }` - poświadczenia `token` mogą używać `tokenRef: { source, provider, id }` -- profile w trybie OAuth nie obsługują poświadczeń SecretRef; jeśli `auth.profiles..mode` jest ustawione na `"oauth"`, wejście `keyRef`/`tokenRef` oparte na SecretRef dla tego profilu zostanie odrzucone. +- Profile w trybie OAuth nie obsługują poświadczeń SecretRef; jeśli dla `auth.profiles..mode` ustawiono `"oauth"`, dane wejściowe `keyRef`/`tokenRef` oparte na SecretRef dla tego profilu są odrzucane. -Sprawdzenie przyjazne dla automatyzacji (kod wyjścia `1` przy wygaśnięciu/braku, `2` przy zbliżającym się wygaśnięciu): +Kontrola przyjazna automatyzacji (kod wyjścia `1`, gdy brak/wygaśnięcie, `2`, gdy wkrótce wygaśnie): ```bash openclaw models status --check ``` -Aktywne sondy auth: +Aktywne sondy uwierzytelniania: ```bash openclaw models status --probe @@ -104,64 +112,63 @@ openclaw models status --probe Uwagi: -- Wiersze sond mogą pochodzić z profili auth, poświadczeń env lub `models.json`. +- Wiersze sondy mogą pochodzić z profili uwierzytelniania, poświadczeń środowiskowych lub `models.json`. - Jeśli jawne `auth.order.` pomija zapisany profil, sonda zgłasza - `excluded_by_auth_order` dla tego profilu zamiast próbować go użyć. -- Jeśli auth istnieje, ale OpenClaw nie może ustalić modelu kandydującego, który można sondować, dla - tego dostawcy, sonda zgłasza `status: no_model`. -- Ograniczenia czasowe po rate limicie mogą być przypisane do konkretnego modelu. Profil w stanie cooldown dla jednego - modelu nadal może nadawać się do użycia z modelami pokrewnymi u tego samego dostawcy. + dla tego profilu `excluded_by_auth_order` zamiast próbować go użyć. +- Jeśli uwierzytelnianie istnieje, ale OpenClaw nie może ustalić kandydata modelu nadającego się do sondowania dla tego dostawcy, sonda zgłasza `status: no_model`. +- Okresy ochłodzenia limitów szybkości mogą być przypisane do modelu. Profil objęty okresem ochłodzenia dla jednego + modelu może nadal nadawać się do użycia dla pokrewnego modelu u tego samego dostawcy. -Opcjonalne skrypty operacyjne (systemd/Termux) opisano tutaj: -[Skrypty monitorowania auth](/pl/help/scripts#auth-monitoring-scripts) +Opcjonalne skrypty operacyjne (systemd/Termux) są opisane tutaj: +[Skrypty monitorowania uwierzytelniania](/pl/help/scripts#auth-monitoring-scripts) ## Uwaga dotycząca Anthropic Backend Anthropic `claude-cli` jest ponownie obsługiwany. -- Personel Anthropic poinformował nas, że ta ścieżka integracji OpenClaw jest ponownie dozwolona. -- Dlatego OpenClaw traktuje ponowne użycie Claude CLI i użycie `claude -p` jako zaakceptowane - dla uruchomień opartych na Anthropic, chyba że Anthropic opublikuje nowe zasady. -- Klucze API Anthropic pozostają najbardziej przewidywalnym wyborem dla długo działających hostów gateway - i jawnej kontroli rozliczeń po stronie serwera. +- Zespół Anthropic poinformował nas, że ta ścieżka integracji OpenClaw jest znów dozwolona. +- Dlatego OpenClaw traktuje ponowne użycie Claude CLI i użycie `claude -p` jako usankcjonowane + dla uruchomień opartych na Anthropic, chyba że Anthropic opublikuje nową politykę. +- Klucze API Anthropic pozostają najbardziej przewidywalnym wyborem dla długo działających hostów Gateway + oraz dla jawnej kontroli rozliczeń po stronie serwera. -## Sprawdzanie stanu auth modelu +## Sprawdzanie stanu uwierzytelniania modelu ```bash openclaw models status openclaw doctor ``` -## Zachowanie przy rotacji kluczy API (gateway) +## Zachowanie podczas rotacji kluczy API (Gateway) Niektórzy dostawcy obsługują ponawianie żądania z alternatywnymi kluczami, gdy wywołanie API -napotka rate limit po stronie dostawcy. +trafi na limit szybkości po stronie dostawcy. - Kolejność priorytetów: - `OPENCLAW_LIVE__KEY` (pojedyncze nadpisanie) - `_API_KEYS` - `_API_KEY` - `_API_KEY_*` -- Dostawcy Google uwzględniają też `GOOGLE_API_KEY` jako dodatkowy fallback. -- Ta sama lista kluczy jest deduplikowana przed użyciem. -- OpenClaw ponawia próbę z następnym kluczem tylko przy błędach rate limitu (na przykład +- Dostawcy Google uwzględniają też `GOOGLE_API_KEY` jako dodatkowy mechanizm awaryjny. +- Ta sama lista kluczy jest przed użyciem deduplikowana. +- OpenClaw ponawia próbę z następnym kluczem tylko przy błędach limitu szybkości (na przykład `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many concurrent requests`, `ThrottlingException`, `concurrency limit reached` lub `workers_ai ... quota limit exceeded`). -- Błędy inne niż rate limit nie są ponawiane z alternatywnymi kluczami. +- Błędy inne niż limit szybkości nie są ponawiane z alternatywnymi kluczami. - Jeśli wszystkie klucze zawiodą, zwracany jest końcowy błąd z ostatniej próby. -## Sterowanie tym, które poświadczenie jest używane +## Sterowanie używanym poświadczeniem -### Dla sesji (polecenie czatu) +### Dla sesji (komenda czatu) -Użyj `/model @`, aby przypiąć określone poświadczenie dostawcy dla bieżącej sesji (przykładowe identyfikatory profili: `anthropic:default`, `anthropic:work`). +Użyj `/model @`, aby przypiąć konkretne poświadczenie dostawcy dla bieżącej sesji (przykładowe identyfikatory profili: `anthropic:default`, `anthropic:work`). -Użyj `/model` (lub `/model list`) dla zwartego selektora; użyj `/model status` dla pełnego widoku (kandydaci + następny profil auth oraz szczegóły endpointu dostawcy, jeśli są skonfigurowane). +Użyj `/model` (lub `/model list`) dla zwartego selektora; użyj `/model status` dla pełnego widoku (kandydaci + następny profil uwierzytelniania oraz szczegóły endpointu dostawcy, jeśli są skonfigurowane). ### Dla agenta (nadpisanie CLI) -Ustaw jawne nadpisanie kolejności profili auth dla agenta (zapisywane w `auth-state.json` tego agenta): +Ustaw jawne nadpisanie kolejności profili uwierzytelniania dla agenta (zapisywane w `auth-state.json` tego agenta): ```bash openclaw models auth order get --provider anthropic @@ -169,10 +176,10 @@ openclaw models auth order set --provider anthropic anthropic:default openclaw models auth order clear --provider anthropic ``` -Użyj `--agent `, aby wskazać konkretnego agenta; pomiń ten parametr, aby użyć skonfigurowanego agenta domyślnego. +Użyj `--agent `, aby wskazać konkretnego agenta; pomiń tę opcję, aby użyć skonfigurowanego domyślnego agenta. Podczas debugowania problemów z kolejnością `openclaw models status --probe` pokazuje pominięte zapisane profile jako `excluded_by_auth_order` zamiast pomijać je po cichu. -Podczas debugowania problemów z cooldown pamiętaj, że ograniczenia czasowe po rate limicie mogą być powiązane +Podczas debugowania problemów z okresem ochłodzenia pamiętaj, że okresy ochłodzenia limitów szybkości mogą być powiązane z jednym identyfikatorem modelu, a nie z całym profilem dostawcy. ## Rozwiązywanie problemów @@ -180,14 +187,14 @@ z jednym identyfikatorem modelu, a nie z całym profilem dostawcy. ### „Nie znaleziono poświadczeń” Jeśli brakuje profilu Anthropic, skonfiguruj klucz API Anthropic na -**hoście gateway** albo ustaw ścieżkę setup-token Anthropic, a następnie sprawdź ponownie: +**hoście Gateway** albo skonfiguruj ścieżkę tokenu konfiguracji Anthropic, a następnie sprawdź ponownie: ```bash openclaw models status ``` -### Token wygasa/wygasł +### Token wkrótce wygasa/wygasł -Uruchom `openclaw models status`, aby potwierdzić, który profil wygasa. Jeśli -profil tokenu Anthropic jest nieobecny lub wygasł, odśwież tę konfigurację przez -setup-token albo przejdź na klucz API Anthropic. +Uruchom `openclaw models status`, aby potwierdzić, który profil wkrótce wygaśnie. Jeśli profil tokenu +Anthropic nie istnieje lub wygasł, odśwież tę konfigurację przez +token konfiguracji albo przejdź na klucz API Anthropic. diff --git a/docs/pl/gateway/cli-backends.md b/docs/pl/gateway/cli-backends.md index 8383e8ca2..cf58f31b8 100644 --- a/docs/pl/gateway/cli-backends.md +++ b/docs/pl/gateway/cli-backends.md @@ -1,47 +1,47 @@ --- read_when: - - Chcesz mieć niezawodne rozwiązanie awaryjne, gdy providerzy API zawodzą - - Używasz Codex CLI lub innych lokalnych CLI AI i chcesz je ponownie wykorzystać - - Chcesz zrozumieć most MCP local loopback do dostępu narzędzi dla backendów CLI -summary: 'Backendy CLI: lokalne awaryjne przejście do CLI AI z opcjonalnym mostem narzędzi MCP' + - Potrzebujesz niezawodnego rozwiązania awaryjnego, gdy dostawcy API zawodzą. + - Używasz Codex CLI lub innych lokalnych CLI AI i chcesz używać ich ponownie. + - Chcesz zrozumieć most local loopback MCP do dostępu narzędzi backendu CLI. +summary: 'Backendy CLI: lokalny awaryjny CLI AI z opcjonalnym mostem narzędzi MCP' title: Backendy CLI x-i18n: - generated_at: "2026-04-23T10:00:34Z" + generated_at: "2026-04-23T14:55:10Z" model: gpt-5.4 provider: openai - source_hash: 475923b36e4580d3e4e57014ff2e6b89e9eb52c11b0a0ab1fc8241655b07836e + source_hash: ff7458d18b8a5b716930579241177917fd3edffcf7f6e211c7d570cf76519316 source_path: gateway/cli-backends.md workflow: 15 --- -# Backendy CLI (środowisko awaryjne) +# Backendy CLI (awaryjne środowisko uruchomieniowe) -OpenClaw może uruchamiać **lokalne CLI AI** jako **awaryjne rozwiązanie tylko tekstowe**, gdy providerzy API są niedostępni, -objęci ograniczeniami szybkości lub tymczasowo działają nieprawidłowo. To podejście jest celowo zachowawcze: +OpenClaw może uruchamiać **lokalne CLI AI** jako **wyłącznie tekstowe rozwiązanie awaryjne**, gdy dostawcy API są niedostępni, +objęci limitami szybkości lub tymczasowo działają nieprawidłowo. Jest to celowo zachowawcze podejście: - **Narzędzia OpenClaw nie są wstrzykiwane bezpośrednio**, ale backendy z `bundleMcp: true` - mogą otrzymywać narzędzia Gateway przez most MCP local loopback. + mogą otrzymywać narzędzia gateway przez most local loopback MCP. - **Strumieniowanie JSONL** dla CLI, które je obsługują. -- **Sesje są obsługiwane** (dzięki czemu kolejne tury pozostają spójne). +- **Sesje są obsługiwane** (dzięki temu kolejne tury pozostają spójne). - **Obrazy mogą być przekazywane dalej**, jeśli CLI akceptuje ścieżki do obrazów. -To rozwiązanie zostało zaprojektowane jako **siatka bezpieczeństwa**, a nie główna ścieżka. Używaj go, gdy -chcesz mieć „zawsze działające” odpowiedzi tekstowe bez polegania na zewnętrznych API. +To rozwiązanie zaprojektowano jako **siatkę bezpieczeństwa**, a nie główną ścieżkę. Używaj go, gdy +chcesz uzyskać odpowiedzi tekstowe typu „zawsze działa” bez polegania na zewnętrznych API. -Jeśli chcesz pełnego środowiska harness z kontrolą sesji ACP, zadaniami w tle, -wiązaniem wątku / rozmowy oraz trwałymi zewnętrznymi sesjami kodowania, użyj -[ACP Agents](/pl/tools/acp-agents). Backendy CLI to nie ACP. +Jeśli chcesz mieć pełne środowisko uruchomieniowe harness z kontrolą sesji ACP, zadaniami w tle, +powiązaniem wątku/konwersacji i trwałymi zewnętrznymi sesjami kodowania, użyj +[agentów ACP](/pl/tools/acp-agents). Backendy CLI nie są ACP. ## Szybki start dla początkujących -Możesz używać Codex CLI **bez żadnej konfiguracji** (dołączony plugin OpenAI +Możesz używać Codex CLI **bez żadnej konfiguracji** (dołączony Plugin OpenAI rejestruje domyślny backend): ```bash openclaw agent --message "hi" --model codex-cli/gpt-5.4 ``` -Jeśli Twój Gateway działa pod launchd/systemd, a PATH jest minimalny, dodaj tylko +Jeśli Twój gateway działa pod launchd/systemd i `PATH` jest minimalne, dodaj tylko ścieżkę polecenia: ```json5 @@ -58,16 +58,16 @@ Jeśli Twój Gateway działa pod launchd/systemd, a PATH jest minimalny, dodaj t } ``` -To wszystko. Nie są potrzebne żadne klucze ani dodatkowa konfiguracja uwierzytelniania poza samym CLI. +To wszystko. Żadne klucze ani dodatkowa konfiguracja uwierzytelniania nie są potrzebne poza samym CLI. -Jeśli używasz dołączonego backendu CLI jako **głównego providera wiadomości** na -hoście Gateway, OpenClaw automatycznie wczytuje teraz należący do niego dołączony plugin, gdy Twoja konfiguracja -jawnie odwołuje się do tego backendu w model ref lub pod +Jeśli używasz dołączonego backendu CLI jako **głównego dostawcy wiadomości** na +hoście gateway, OpenClaw teraz automatycznie ładuje należący do niego dołączony Plugin, gdy Twoja konfiguracja +jawnie odwołuje się do tego backendu w odwołaniu do modelu albo w `agents.defaults.cliBackends`. ## Używanie jako rozwiązania awaryjnego -Dodaj backend CLI do listy awaryjnej, aby był uruchamiany tylko wtedy, gdy modele podstawowe zawiodą: +Dodaj backend CLI do listy rozwiązań awaryjnych, aby był uruchamiany tylko wtedy, gdy modele podstawowe zawiodą: ```json5 { @@ -88,9 +88,9 @@ Dodaj backend CLI do listy awaryjnej, aby był uruchamiany tylko wtedy, gdy mode Uwagi: -- Jeśli używasz `agents.defaults.models` (lista dozwolonych), musisz uwzględnić tam również modele backendu CLI. -- Jeśli podstawowy provider zawiedzie (uwierzytelnianie, limity szybkości, timeouty), OpenClaw - spróbuje następnie backendu CLI. +- Jeśli używasz `agents.defaults.models` (listy dozwolonych), musisz uwzględnić tam również modele backendu CLI. +- Jeśli podstawowy dostawca zawiedzie (uwierzytelnianie, limity szybkości, przekroczenia czasu), OpenClaw + spróbuje następnie użyć backendu CLI. ## Przegląd konfiguracji @@ -100,8 +100,8 @@ Wszystkie backendy CLI znajdują się pod: agents.defaults.cliBackends ``` -Każdy wpis jest kluczowany przez **id providera** (np. `codex-cli`, `my-cli`). -Id providera staje się lewą stroną model ref: +Każdy wpis jest kluczowany przez **id dostawcy** (np. `codex-cli`, `my-cli`). +Id dostawcy staje się lewą stroną odwołania do modelu: ``` / @@ -147,69 +147,82 @@ Id providera staje się lewą stroną model ref: ## Jak to działa -1. **Wybiera backend** na podstawie prefiksu providera (`codex-cli/...`). -2. **Buduje system prompt** przy użyciu tego samego promptu OpenClaw + kontekstu workspace. -3. **Wykonuje CLI** z id sesji (jeśli jest obsługiwane), dzięki czemu historia pozostaje spójna. - Dołączony backend `claude-cli` utrzymuje proces stdio Claude przy życiu dla każdej +1. **Wybiera backend** na podstawie prefiksu dostawcy (`codex-cli/...`). +2. **Buduje prompt systemowy** przy użyciu tego samego promptu OpenClaw i kontekstu workspace. +3. **Uruchamia CLI** z identyfikatorem sesji (jeśli jest obsługiwany), aby historia pozostała spójna. + Dołączony backend `claude-cli` utrzymuje proces Claude stdio aktywny dla każdej sesji OpenClaw i wysyła kolejne tury przez stdin stream-json. -4. **Parsuje wyjście** (JSON lub zwykły tekst) i zwraca końcowy tekst. -5. **Utrwala id sesji** dla każdego backendu, dzięki czemu kolejne tury używają tej samej sesji CLI. +4. **Parsuje dane wyjściowe** (JSON albo zwykły tekst) i zwraca końcowy tekst. +5. **Utrwala identyfikatory sesji** dla każdego backendu, aby kolejne tury ponownie używały tej samej sesji CLI. Dołączony backend Anthropic `claude-cli` jest ponownie obsługiwany. Pracownicy Anthropic powiedzieli nam, że użycie Claude CLI w stylu OpenClaw jest znów dozwolone, więc OpenClaw traktuje -użycie `claude -p` jako sankcjonowane dla tej integracji, chyba że Anthropic opublikuje +użycie `claude -p` jako usankcjonowane dla tej integracji, chyba że Anthropic opublikuje nową politykę. -Dołączony backend OpenAI `codex-cli` przekazuje system prompt OpenClaw przez -nadpisanie konfiguracji `model_instructions_file` Codex (`-c +Dołączony backend OpenAI `codex-cli` przekazuje prompt systemowy OpenClaw przez +nadpisanie konfiguracji `model_instructions_file` w Codex (`-c model_instructions_file="..."`). Codex nie udostępnia flagi w stylu Claude `--append-system-prompt`, więc OpenClaw zapisuje złożony prompt do pliku tymczasowego dla każdej nowej sesji Codex CLI. Dołączony backend Anthropic `claude-cli` otrzymuje migawkę Skills OpenClaw -na dwa sposoby: kompaktowy katalog Skills OpenClaw w dołączanym system prompt oraz -tymczasowy plugin Claude Code przekazywany przez `--plugin-dir`. Plugin zawiera -tylko Skills kwalifikujące się dla danego agenta / sesji, dzięki czemu natywny resolver Skills Claude Code +na dwa sposoby: kompaktowy katalog Skills OpenClaw w dołączonym prompcie systemowym oraz +tymczasowy Plugin Claude Code przekazywany przez `--plugin-dir`. Plugin zawiera +tylko Skills kwalifikujące się dla tego agenta/sesji, więc natywny mechanizm rozpoznawania Skills Claude Code widzi ten sam przefiltrowany zestaw, który OpenClaw w przeciwnym razie reklamowałby w prompcie. -Nadpisania env / kluczy API dla Skills są nadal stosowane przez OpenClaw do środowiska procesu potomnego dla runu. +Nadpisania env/kluczy API dla Skills są nadal stosowane przez OpenClaw do środowiska procesu potomnego na czas uruchomienia. + +Zanim OpenClaw będzie mógł użyć dołączonego backendu `claude-cli`, samo Claude Code +musi być już zalogowane na tym samym hoście: + +```bash +claude auth login +claude auth status --text +openclaw models auth login --provider anthropic --method cli --set-default +``` + +Używaj `agents.defaults.cliBackends.claude-cli.command` tylko wtedy, gdy plik binarny `claude` +nie jest już dostępny w `PATH`. ## Sesje -- Jeśli CLI obsługuje sesje, ustaw `sessionArg` (np. `--session-id`) lub - `sessionArgs` (placeholder `{sessionId}`), gdy id trzeba wstawić +- Jeśli CLI obsługuje sesje, ustaw `sessionArg` (np. `--session-id`) albo + `sessionArgs` (placeholder `{sessionId}`), gdy identyfikator musi zostać wstawiony do wielu flag. -- Jeśli CLI używa **podpolecenia resume** z innymi flagami, ustaw +- Jeśli CLI używa **podpolecenia wznowienia** z innymi flagami, ustaw `resumeArgs` (zastępuje `args` przy wznawianiu) i opcjonalnie `resumeOutput` - (dla wznawiania niebędącego JSON). + (dla wznowień innych niż JSON). - `sessionMode`: - - `always`: zawsze wysyła id sesji (nowe UUID, jeśli nic nie zapisano). - - `existing`: wysyła id sesji tylko wtedy, gdy wcześniej zostało zapisane. - - `none`: nigdy nie wysyła id sesji. + - `always`: zawsze wysyłaj identyfikator sesji (nowy UUID, jeśli nic nie zapisano). + - `existing`: wysyłaj identyfikator sesji tylko wtedy, gdy został wcześniej zapisany. + - `none`: nigdy nie wysyłaj identyfikatora sesji. - `claude-cli` domyślnie używa `liveSession: "claude-stdio"`, `output: "jsonl"` - i `input: "stdin"`, dzięki czemu kolejne tury używają ponownie aktywnego procesu Claude, - dopóki jest aktywny. Ciepłe stdio jest teraz ustawieniem domyślnym, także dla konfiguracji niestandardowych, - które pomijają pola transportu. Jeśli Gateway uruchomi się ponownie lub bezczynny proces - zakończy działanie, OpenClaw wznowi pracę z zapisanego id sesji Claude. Zapisane id sesji - są weryfikowane względem istniejącej czytelnej transkrypcji projektu przed - wznowieniem, więc widmowe powiązania są czyszczone z `reason=transcript-missing` - zamiast po cichu uruchamiać nową sesję Claude CLI pod `--resume`. -- Zapisane sesje CLI to ciągłość należąca do providera. Niejawny codzienny - reset sesji ich nie przecina; `/reset` i jawne polityki `session.reset` nadal to robią. + i `input: "stdin"`, dzięki czemu kolejne tury ponownie używają aktywnego procesu Claude, + gdy jest on aktywny. Ciepłe stdio jest teraz ustawieniem domyślnym, także dla konfiguracji niestandardowych, + które pomijają pola transportu. Jeśli Gateway uruchomi się ponownie albo bezczynny proces + zakończy działanie, OpenClaw wznowi pracę na podstawie zapisanego identyfikatora sesji Claude. Zapisane identyfikatory sesji + są weryfikowane względem istniejącego, czytelnego transkryptu projektu przed + wznowieniem, więc fantomowe powiązania są czyszczone z `reason=transcript-missing`, + zamiast po cichu rozpoczynać nową sesję Claude CLI pod `--resume`. +- Zapisane sesje CLI są ciągłością należącą do dostawcy. Domyślne codzienne + resetowanie sesji ich nie przerywa; `/reset` i jawne polityki `session.reset` już tak. Uwagi dotyczące serializacji: -- `serialize: true` utrzymuje kolejność uruchomień w tym samym pasie. -- Większość CLI serializuje na jednym pasie providera. -- OpenClaw odrzuca ponowne użycie zapisanej sesji CLI, gdy zmienia się wybrana tożsamość uwierzytelniania, - w tym zmienione id profilu uwierzytelniania, statyczny klucz API, statyczny token lub tożsamość konta OAuth, - gdy CLI ją udostępnia. Rotacja tokenów dostępu i odświeżania OAuth nie przecina zapisanej sesji CLI. Jeśli CLI nie udostępnia - stabilnego id konta OAuth, OpenClaw pozwala temu CLI samodzielnie egzekwować uprawnienia wznowienia. +- `serialize: true` utrzymuje kolejność uruchomień w tym samym lane. +- Większość CLI serializuje pracę w jednym lane dostawcy. +- OpenClaw porzuca ponowne użycie zapisanej sesji CLI, gdy zmienia się wybrana tożsamość uwierzytelniania, + w tym gdy zmienia się id profilu uwierzytelniania, statyczny klucz API, statyczny token + albo tożsamość konta OAuth, jeśli CLI ją udostępnia. Rotacja tokenów dostępu i odświeżania OAuth + nie przerywa zapisanej sesji CLI. Jeśli CLI nie udostępnia stabilnego id konta OAuth, + OpenClaw pozwala temu CLI samodzielnie egzekwować uprawnienia wznowienia. -## Obrazy (pass-through) +## Obrazy (przekazywanie dalej) -Jeśli Twoje CLI akceptuje ścieżki do obrazów, ustaw `imageArg`: +Jeśli Twój CLI akceptuje ścieżki do obrazów, ustaw `imageArg`: ```json5 imageArg: "--image", @@ -217,27 +230,28 @@ imageMode: "repeat" ``` OpenClaw zapisze obrazy base64 do plików tymczasowych. Jeśli ustawiono `imageArg`, te -ścieżki są przekazywane jako argumenty CLI. Jeśli `imageArg` nie istnieje, OpenClaw -dołącza ścieżki plików do promptu (wstrzyknięcie ścieżki), co wystarcza dla CLI, które automatycznie -wczytują pliki lokalne ze zwykłych ścieżek. +ścieżki są przekazywane jako argumenty CLI. Jeśli `imageArg` nie jest ustawione, OpenClaw dołącza +ścieżki plików do promptu (wstrzykiwanie ścieżek), co wystarcza dla CLI, które automatycznie +ładują pliki lokalne ze zwykłych ścieżek. ## Wejścia / wyjścia -- `output: "json"` (domyślnie) próbuje sparsować JSON i wyodrębnić tekst + id sesji. -- Dla wyjścia JSON Gemini CLI OpenClaw odczytuje tekst odpowiedzi z `response`, a - użycie z `stats`, gdy `usage` nie istnieje lub jest puste. -- `output: "jsonl"` parsuje strumienie JSONL (na przykład Codex CLI `--json`) i wyodrębnia końcową wiadomość agenta oraz identyfikatory sesji, gdy są obecne. +- `output: "json"` (domyślne) próbuje sparsować JSON i wyodrębnić tekst oraz identyfikator sesji. +- Dla danych wyjściowych Gemini CLI w formacie JSON OpenClaw odczytuje tekst odpowiedzi z `response` oraz + użycie z `stats`, gdy `usage` jest nieobecne lub puste. +- `output: "jsonl"` parsuje strumienie JSONL (na przykład Codex CLI `--json`) i wyodrębnia końcową wiadomość agenta oraz identyfikatory sesji, + jeśli są obecne. - `output: "text"` traktuje stdout jako końcową odpowiedź. Tryby wejścia: -- `input: "arg"` (domyślnie) przekazuje prompt jako ostatni argument CLI. +- `input: "arg"` (domyślne) przekazuje prompt jako ostatni argument CLI. - `input: "stdin"` wysyła prompt przez stdin. -- Jeśli prompt jest bardzo długi i ustawiono `maxPromptArgChars`, używane jest stdin. +- Jeśli prompt jest bardzo długi i ustawiono `maxPromptArgChars`, używany jest stdin. -## Ustawienia domyślne (należące do pluginu) +## Ustawienia domyślne (należące do Pluginu) -Dołączony plugin OpenAI rejestruje również domyślne ustawienia dla `codex-cli`: +Dołączony Plugin OpenAI rejestruje również domyślne ustawienia dla `codex-cli`: - `command: "codex"` - `args: ["exec","--json","--color","never","--sandbox","workspace-write","--skip-git-repo-check"]` @@ -248,7 +262,7 @@ Dołączony plugin OpenAI rejestruje również domyślne ustawienia dla `codex-c - `imageArg: "--image"` - `sessionMode: "existing"` -Dołączony plugin Google rejestruje również domyślne ustawienia dla `google-gemini-cli`: +Dołączony Plugin Google rejestruje również domyślne ustawienia dla `google-gemini-cli`: - `command: "gemini"` - `args: ["--output-format", "json", "--prompt", "{prompt}"]` @@ -260,31 +274,31 @@ Dołączony plugin Google rejestruje również domyślne ustawienia dla `google- - `sessionIdFields: ["session_id", "sessionId"]` Wymaganie wstępne: lokalny Gemini CLI musi być zainstalowany i dostępny jako -`gemini` w `PATH` (`brew install gemini-cli` lub +`gemini` w `PATH` (`brew install gemini-cli` albo `npm install -g @google/gemini-cli`). Uwagi dotyczące JSON Gemini CLI: - Tekst odpowiedzi jest odczytywany z pola JSON `response`. -- Użycie przechodzi awaryjnie do `stats`, gdy `usage` nie istnieje lub jest puste. +- Użycie wraca do `stats`, gdy `usage` jest nieobecne lub puste. - `stats.cached` jest normalizowane do OpenClaw `cacheRead`. -- Jeśli `stats.input` nie istnieje, OpenClaw wyprowadza tokeny wejściowe z +- Jeśli `stats.input` jest nieobecne, OpenClaw wyprowadza tokeny wejściowe z `stats.input_tokens - stats.cached`. -Nadpisuj tylko wtedy, gdy to potrzebne (najczęściej: bezwzględna ścieżka `command`). +Nadpisuj tylko wtedy, gdy to potrzebne (częsty przypadek: bezwzględna ścieżka `command`). -## Ustawienia domyślne należące do pluginu +## Ustawienia domyślne należące do Pluginu -Ustawienia domyślne backendów CLI są teraz częścią powierzchni pluginu: +Domyślne ustawienia backendu CLI są teraz częścią powierzchni Pluginu: - Pluginy rejestrują je przez `api.registerCliBackend(...)`. -- `id` backendu staje się prefiksem providera w model ref. -- Konfiguracja użytkownika w `agents.defaults.cliBackends.` nadal nadpisuje domyślne ustawienia pluginu. -- Czyszczenie konfiguracji specyficznej dla backendu pozostaje własnością pluginu dzięki opcjonalnemu +- Backend `id` staje się prefiksem dostawcy w odwołaniach do modeli. +- Konfiguracja użytkownika w `agents.defaults.cliBackends.` nadal nadpisuje domyślne ustawienia Pluginu. +- Czyszczenie konfiguracji specyficznej dla backendu nadal pozostaje po stronie Pluginu dzięki opcjonalnemu hookowi `normalizeConfig`. -Pluginy, które potrzebują drobnych shimów zgodności promptów / wiadomości, mogą deklarować -dwukierunkowe transformacje tekstu bez zastępowania providera ani backendu CLI: +Pluginy, które potrzebują drobnych shimów zgodności promptów/wiadomości, mogą deklarować +dwukierunkowe transformacje tekstu bez zastępowania dostawcy ani backendu CLI: ```typescript api.registerTextTransforms({ @@ -301,45 +315,45 @@ api.registerTextTransforms({ }); ``` -`input` przepisuje system prompt i prompt użytkownika przekazywane do CLI. `output` -przepisuje strumieniowane delty asystenta i sparsowany końcowy tekst, zanim OpenClaw obsłuży -własne markery sterujące i dostarczanie do kanału. +`input` przepisuje prompt systemowy i prompt użytkownika przekazywane do CLI. `output` +przepisuje strumieniowane delty asystenta i sparsowany tekst końcowy, zanim OpenClaw obsłuży +własne znaczniki sterujące i dostarczenie kanałowe. -Dla CLI, które emitują JSONL zgodny ze stream-json Claude Code, ustaw +Dla CLI, które emitują JSONL zgodny z Claude Code stream-json, ustaw `jsonlDialect: "claude-stream-json"` w konfiguracji tego backendu. -## Nakładki Bundle MCP +## Nakładki MCP dla bundle Backendy CLI **nie** otrzymują bezpośrednio wywołań narzędzi OpenClaw, ale backend może -włączyć wygenerowaną nakładkę konfiguracji MCP przez `bundleMcp: true`. +włączyć generowaną nakładkę konfiguracji MCP przez `bundleMcp: true`. -Bieżące dołączone zachowanie: +Obecne zachowanie dla dołączonych backendów: - `claude-cli`: wygenerowany ścisły plik konfiguracji MCP -- `codex-cli`: inline nadpisania konfiguracji dla `mcp_servers` +- `codex-cli`: wbudowane nadpisania konfiguracji dla `mcp_servers` - `google-gemini-cli`: wygenerowany plik ustawień systemowych Gemini Gdy bundle MCP jest włączone, OpenClaw: -- uruchamia serwer HTTP MCP local loopback, który udostępnia narzędzia Gateway procesowi CLI -- uwierzytelnia most tokenem na sesję (`OPENCLAW_MCP_TOKEN`) +- uruchamia serwer HTTP MCP local loopback, który udostępnia narzędzia gateway procesowi CLI +- uwierzytelnia most przy użyciu tokenu na sesję (`OPENCLAW_MCP_TOKEN`) - ogranicza dostęp do narzędzi do bieżącej sesji, konta i kontekstu kanału -- wczytuje włączone serwery bundle-MCP dla bieżącego workspace -- scala je z dowolnym istniejącym kształtem konfiguracji / ustawień MCP backendu -- przepisuje konfigurację uruchamiania przy użyciu należącego do backendu trybu integracji z rozszerzenia będącego właścicielem +- ładuje włączone serwery bundle-MCP dla bieżącego workspace +- scala je z dowolnym istniejącym kształtem konfiguracji/ustawień MCP backendu +- przepisuje konfigurację uruchomieniową przy użyciu trybu integracji należącego do backendu z rozszerzenia będącego jego właścicielem -Jeśli żaden serwer MCP nie jest włączony, OpenClaw nadal wstrzykuje ścisłą konfigurację, gdy -backend włącza bundle MCP, aby uruchomienia w tle pozostawały izolowane. +Jeśli żadne serwery MCP nie są włączone, OpenClaw nadal wstrzykuje ścisłą konfigurację, gdy +backend włącza bundle MCP, aby uruchomienia w tle pozostały odizolowane. ## Ograniczenia - **Brak bezpośrednich wywołań narzędzi OpenClaw.** OpenClaw nie wstrzykuje wywołań narzędzi do - protokołu backendu CLI. Backendy widzą narzędzia Gateway tylko wtedy, gdy włączą + protokołu backendu CLI. Backendy widzą narzędzia gateway tylko wtedy, gdy włączą `bundleMcp: true`. - **Strumieniowanie jest specyficzne dla backendu.** Niektóre backendy strumieniują JSONL; inne buforują - aż do zakończenia. -- **Ustrukturyzowane wyjścia** zależą od formatu JSON CLI. -- **Sesje Codex CLI** są wznawiane przez wyjście tekstowe (bez JSONL), które jest mniej + do zakończenia. +- **Wyjścia strukturalne** zależą od formatu JSON danego CLI. +- **Sesje Codex CLI** są wznawiane przez dane wyjściowe tekstowe (bez JSONL), co jest mniej ustrukturyzowane niż początkowe uruchomienie `--json`. Sesje OpenClaw nadal działają normalnie. @@ -347,6 +361,6 @@ backend włącza bundle MCP, aby uruchomienia w tle pozostawały izolowane. - **Nie znaleziono CLI**: ustaw `command` na pełną ścieżkę. - **Nieprawidłowa nazwa modelu**: użyj `modelAliases`, aby mapować `provider/model` → model CLI. -- **Brak ciągłości sesji**: upewnij się, że ustawiono `sessionArg`, a `sessionMode` nie ma - wartości `none` (Codex CLI obecnie nie potrafi wznawiać z wyjściem JSON). +- **Brak ciągłości sesji**: upewnij się, że `sessionArg` jest ustawione, a `sessionMode` nie ma wartości + `none` (Codex CLI obecnie nie potrafi wznawiać z wyjściem JSON). - **Obrazy są ignorowane**: ustaw `imageArg` (i sprawdź, czy CLI obsługuje ścieżki do plików). diff --git a/docs/pl/help/testing.md b/docs/pl/help/testing.md index 03d884d27..bbd68fe33 100644 --- a/docs/pl/help/testing.md +++ b/docs/pl/help/testing.md @@ -1,156 +1,162 @@ --- read_when: - Uruchamianie testów lokalnie lub w CI - - Dodawanie testów regresyjnych dla błędów modeli/providerów - - Debugowanie zachowania Gateway + agenta -summary: 'Zestaw testowy: zestawy unit/e2e/live, runnery Docker i zakres każdego testu' + - Dodawanie testów regresji dla błędów modeli/dostawców + - Debugowanie działania Gateway i agentów +summary: 'Zestaw testowy: pakiety unit/e2e/live, uruchamianie w Dockerze oraz zakres każdego testu' title: Testowanie x-i18n: - generated_at: "2026-04-23T10:02:31Z" + generated_at: "2026-04-23T14:55:03Z" model: gpt-5.4 provider: openai - source_hash: fe0e9bdea78cba7e512358d2e4d428da04a2071188e74af2d5419d2c85eafe15 + source_hash: fbec4996699577321116c94f60c01d205d7594ed41aca27c821f1c3d65a7dca3 source_path: help/testing.md workflow: 15 --- # Testowanie -OpenClaw ma trzy zestawy Vitest (unit/integration, e2e, live) oraz niewielki zestaw runnerów Docker. +OpenClaw ma trzy pakiety Vitest (unit/integration, e2e, live) oraz niewielki zestaw uruchomień w Dockerze. Ten dokument to przewodnik „jak testujemy”: -- Co obejmuje każdy zestaw (i czego celowo _nie_ obejmuje) -- Jakie polecenia uruchamiać w typowych przepływach pracy (lokalnie, przed pushem, debugowanie) -- Jak testy live wykrywają poświadczenia oraz wybierają modele/providery -- Jak dodawać testy regresyjne dla rzeczywistych problemów modeli/providerów +- Co obejmuje każdy pakiet (i czego celowo _nie_ obejmuje) +- Jakie polecenia uruchamiać w typowych workflow (lokalnie, przed push, debugowanie) +- Jak testy live wykrywają poświadczenia oraz wybierają modele/dostawców +- Jak dodawać testy regresji dla rzeczywistych problemów modeli/dostawców ## Szybki start -W większość dni: +Na co dzień: -- Pełna bramka (oczekiwana przed pushem): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- Szybsze lokalne uruchomienie pełnego zestawu na maszynie z dużą ilością zasobów: `pnpm test:max` +- Pełna bramka (oczekiwana przed push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` +- Szybsze lokalne uruchomienie pełnego pakietu na wydajnej maszynie: `pnpm test:max` - Bezpośrednia pętla watch Vitest: `pnpm test:watch` -- Bezpośrednie wskazywanie plików kieruje teraz także ścieżki extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Przy iteracji nad pojedynczym błędem najpierw preferuj uruchomienia celowane. +- Bezpośrednie wskazywanie plików obsługuje teraz również ścieżki rozszerzeń/kanałów: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Gdy iterujesz nad pojedynczą awarią, najpierw wybieraj uruchomienia ukierunkowane. - Strona QA oparta na Dockerze: `pnpm qa:lab:up` - Linia QA oparta na Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Gdy dotykasz testów albo chcesz mieć większą pewność: +Gdy modyfikujesz testy albo chcesz mieć większą pewność: - Bramka pokrycia: `pnpm test:coverage` -- Zestaw E2E: `pnpm test:e2e` +- Pakiet E2E: `pnpm test:e2e` -Przy debugowaniu rzeczywistych providerów/modeli (wymaga prawdziwych poświadczeń): +Podczas debugowania rzeczywistych dostawców/modeli (wymaga prawdziwych poświadczeń): -- Zestaw live (modele + sondy narzędzi/obrazów Gateway): `pnpm test:live` -- Uruchom po cichu jeden plik live: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Dockerowy przegląd modeli live: `pnpm test:docker:live-models` - - Pokrycie CI: codzienne `OpenClaw Scheduled Live And E2E Checks` i ręczne +- Pakiet live (modele + sondy narzędzi/obrazów Gateway): `pnpm test:live` +- Ciche uruchomienie jednego pliku live: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Sweep modeli live w Dockerze: `pnpm test:docker:live-models` + - Każdy wybrany model uruchamia teraz turę tekstową oraz małą sondę w stylu odczytu pliku. + Modele, których metadane deklarują wejście `image`, uruchamiają też małą turę obrazu. + Wyłącz dodatkowe sondy za pomocą `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` lub + `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, gdy izolujesz awarie dostawcy. + - Pokrycie w CI: codzienne `OpenClaw Scheduled Live And E2E Checks` oraz ręczne `OpenClaw Release Checks` wywołują wielokrotnego użytku workflow live/E2E z - `include_live_suites: true`, co obejmuje osobne zadania Docker live model - w macierzy podzielone według providera. - - Przy celowanych ponownych uruchomieniach CI wywołaj `OpenClaw Live And E2E Checks (Reusable)` + `include_live_suites: true`, co obejmuje osobne zadania macierzowe Docker live model + podzielone według dostawcy. + - Do ukierunkowanych ponownych uruchomień w CI wyślij `OpenClaw Live And E2E Checks (Reusable)` z `include_live_suites: true` oraz `live_models_only: true`. - - Dodaj nowe sekrety providerów o wysokiej wartości sygnału do `scripts/ci-hydrate-live-auth.sh` - oraz `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` i jego - wywołujących workflow scheduled/release. -- Smoke test kosztów Moonshot/Kimi: przy ustawionym `MOONSHOT_API_KEY` uruchom - `openclaw models list --provider moonshot --json`, a następnie uruchom izolowane + - Dodaj nowe sekrety dostawców o wysokim sygnale do `scripts/ci-hydrate-live-auth.sh` + oraz `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` i ich + wywołujących workflow harmonogramu/wydania. +- Smoke test kosztów Moonshot/Kimi: z ustawionym `MOONSHOT_API_KEY` uruchom + `openclaw models list --provider moonshot --json`, a następnie odizolowane `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` - względem `moonshot/kimi-k2.6`. Zweryfikuj, że JSON raportuje Moonshot/K2.6, a - transkrypt asystenta zapisuje znormalizowane `usage.cost`. + względem `moonshot/kimi-k2.6`. Sprawdź, że JSON raportuje Moonshot/K2.6 oraz że + transkrypt asystenta przechowuje znormalizowane `usage.cost`. -Wskazówka: gdy potrzebujesz tylko jednego nieudanego przypadku, preferuj zawężanie testów live przez zmienne środowiskowe allowlist opisane poniżej. +Wskazówka: gdy potrzebujesz tylko jednego nieudanego przypadku, zawężaj testy live przez zmienne środowiskowe allowlist opisane poniżej. -## Runnery specyficzne dla QA +## Uruchomienia specyficzne dla QA -Te polecenia działają obok głównych zestawów testów, gdy potrzebujesz realizmu qa-lab: +Te polecenia znajdują się obok głównych pakietów testowych, gdy potrzebujesz realizmu qa-lab: -CI uruchamia QA Lab w dedykowanych workflow. `Parity gate` działa na pasujących PR-ach -oraz po ręcznym wywołaniu z mock providerami. `QA-Lab - All Lanes` działa co noc na -`main` oraz po ręcznym wywołaniu z mock parity gate, linią live Matrix i -zarządzaną przez Convex linią live Telegram jako zadaniami równoległymi. `OpenClaw Release Checks` +CI uruchamia QA Lab w dedykowanych workflow. `Parity gate` działa dla pasujących PR-ów +i z ręcznego wyzwalania z mockowanymi dostawcami. `QA-Lab - All Lanes` działa nocnie na +`main` oraz z ręcznego wyzwalania z mockowaną bramką zgodności, linią live Matrix +i linią live Telegram zarządzaną przez Convex jako zadaniami równoległymi. `OpenClaw Release Checks` uruchamia te same linie przed zatwierdzeniem wydania. - `pnpm openclaw qa suite` - Uruchamia scenariusze QA oparte na repo bezpośrednio na hoście. - - Domyślnie uruchamia wiele wybranych scenariuszy równolegle z izolowanymi - workerami gateway. `qa-channel` domyślnie używa współbieżności 4 (ograniczonej przez - liczbę wybranych scenariuszy). Użyj `--concurrency `, aby dostroić liczbę workerów, - albo `--concurrency 1` dla starszej linii sekwencyjnej. - - Zwraca kod różny od zera, gdy którykolwiek scenariusz się nie powiedzie. Użyj `--allow-failures`, gdy - chcesz artefakty bez kończenia z błędem. - - Obsługuje tryby providerów `live-frontier`, `mock-openai` i `aimock`. - `aimock` uruchamia lokalny serwer providera oparty na AIMock dla eksperymentalnego - pokrycia fixture i mocków protokołu bez zastępowania świadomej scenariuszy linii `mock-openai`. + - Domyślnie uruchamia równolegle wiele wybranych scenariuszy z izolowanymi + workerami Gateway. `qa-channel` domyślnie używa współbieżności 4 (ograniczonej + przez liczbę wybranych scenariuszy). Użyj `--concurrency `, aby dostroić liczbę + workerów, lub `--concurrency 1` dla starszej linii szeregowej. + - Kończy się kodem niezerowym, gdy którykolwiek scenariusz zakończy się niepowodzeniem. Użyj `--allow-failures`, gdy + chcesz artefaktów bez kończenia z kodem błędu. + - Obsługuje tryby dostawców `live-frontier`, `mock-openai` oraz `aimock`. + `aimock` uruchamia lokalny serwer dostawcy oparty na AIMock dla eksperymentalnego + pokrycia fixture i mocków protokołu bez zastępowania świadomej scenariuszy + linii `mock-openai`. - `pnpm openclaw qa suite --runner multipass` - - Uruchamia ten sam zestaw QA wewnątrz jednorazowej linuxowej VM Multipass. - - Zachowuje takie samo zachowanie wyboru scenariuszy jak `qa suite` na hoście. - - Ponownie używa tych samych flag wyboru providera/modelu co `qa suite`. - - Przebiegi live przekazują obsługiwane wejścia auth QA, które są praktyczne dla gościa: - klucze providerów oparte na env, ścieżkę konfiguracji providera QA live oraz `CODEX_HOME`, gdy jest obecne. - - Katalogi wyjściowe muszą pozostać pod katalogiem głównym repo, aby gość mógł zapisywać z powrotem przez + - Uruchamia ten sam pakiet QA wewnątrz jednorazowej maszyny wirtualnej Multipass Linux. + - Zachowuje to samo zachowanie wyboru scenariuszy co `qa suite` na hoście. + - Ponownie wykorzystuje te same flagi wyboru dostawcy/modelu co `qa suite`. + - Uruchomienia live przekazują obsługiwane wejścia uwierzytelniania QA praktyczne dla gościa: + klucze dostawców oparte na env, ścieżkę konfiguracji dostawcy QA live oraz `CODEX_HOME`, + jeśli jest obecne. + - Katalogi wyjściowe muszą pozostawać pod katalogiem głównym repo, aby gość mógł zapisywać z powrotem przez zamontowany workspace. - - Zapisuje zwykły raport QA + podsumowanie oraz logi Multipass w + - Zapisuje zwykły raport i podsumowanie QA oraz logi Multipass w `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Uruchamia stronę QA opartą na Dockerze do pracy QA w stylu operatora. + - Uruchamia stronę QA opartą na Dockerze do pracy QA w stylu operatorskim. - `pnpm test:docker:npm-onboard-channel-agent` - - Buduje archiwum npm z bieżącego checkoutu, instaluje je globalnie w - Dockerze, uruchamia nieinteraktywny onboarding klucza OpenAI API, domyślnie konfiguruje Telegram, - weryfikuje, że włączenie Pluginu instaluje zależności runtime na żądanie, uruchamia doctor, - i uruchamia jedną lokalną turę agenta względem mockowanego endpointu OpenAI. + - Buduje tarball npm z bieżącego checkoutu, instaluje go globalnie w + Dockerze, uruchamia nieinteraktywny onboarding klucza API OpenAI, domyślnie konfiguruje Telegram, + sprawdza, że włączenie pluginu instaluje zależności uruchomieniowe na żądanie, + uruchamia doctor i uruchamia jedną lokalną turę agenta względem mockowanego endpointu OpenAI. - Użyj `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, aby uruchomić tę samą linię instalacji pakietowej z Discord. - `pnpm test:docker:bundled-channel-deps` - Pakuje i instaluje bieżący build OpenClaw w Dockerze, uruchamia Gateway - ze skonfigurowanym OpenAI, a następnie włącza dołączone kanały/Plugins przez edycje konfiguracji. - - Weryfikuje, że wykrywanie konfiguracji pozostawia nieskonfigurowane zależności runtime Pluginów - nieobecne, pierwszy skonfigurowany przebieg Gateway lub doctor instaluje zależności runtime - każdego dołączonego Pluginu na żądanie, a drugi restart nie reinstaluje zależności, - które zostały już aktywowane. + ze skonfigurowanym OpenAI, a następnie włącza bundlowane kanały/pluginy przez + edycje konfiguracji. + - Weryfikuje, że wykrywanie konfiguracji pozostawia nieobecne zależności uruchomieniowe + nieskonfigurowanych pluginów, że pierwsze skonfigurowane uruchomienie Gateway lub doctor + instaluje zależności uruchomieniowe każdego bundlowanego pluginu na żądanie, oraz że + drugie ponowne uruchomienie nie reinstaluje zależności, które zostały już aktywowane. - Instaluje też znaną starszą bazę npm, włącza Telegram przed uruchomieniem - `openclaw update --tag ` i weryfikuje, że - post-update doctor w kandydacie naprawia zależności runtime dołączonych kanałów bez - naprawy postinstall po stronie harnessu. + `openclaw update --tag ` i weryfikuje, że doctor po aktualizacji kandydata + naprawia zależności uruchomieniowe bundlowanych kanałów bez naprawy postinstall + po stronie harnessu. - `pnpm openclaw qa aimock` - - Uruchamia tylko lokalny serwer providera AIMock do bezpośredniego smoke testowania protokołu. + - Uruchamia tylko lokalny serwer dostawcy AIMock do bezpośredniego smoke testowania protokołu. - `pnpm openclaw qa matrix` - - Uruchamia linię QA Matrix live względem jednorazowego homeservera Tuwunel opartego na Dockerze. - - Ten host QA jest dziś tylko repo/dev. Spakowane instalacje OpenClaw nie dostarczają + - Uruchamia linię QA Matrix live względem jednorazowego homeserwera Tuwunel opartego na Dockerze. + - Ten host QA jest dziś dostępny tylko dla repo/dev. Spakowane instalacje OpenClaw nie dostarczają `qa-lab`, więc nie udostępniają `openclaw qa`. - - Checkouty repo ładują dołączony runner bezpośrednio; nie jest potrzebny - osobny krok instalacji Pluginu. - - Tworzy trzy tymczasowe użytkowniki Matrix (`driver`, `sut`, `observer`) oraz jeden prywatny pokój, po czym uruchamia podrzędny gateway QA z prawdziwym Pluginem Matrix jako transportem SUT. - - Domyślnie używa przypiętego stabilnego obrazu Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Nadpisz przez `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, gdy chcesz testować inny obraz. - - Matrix nie udostępnia współdzielonych flag źródeł poświadczeń, ponieważ ta linia lokalnie tworzy jednorazowych użytkowników. - - Zapisuje raport QA Matrix, podsumowanie, artefakt observed-events oraz połączony log wyjścia stdout/stderr w `.artifacts/qa-e2e/...`. + - Checkouty repo ładują bundlowany runner bezpośrednio; nie jest potrzebny osobny krok instalacji pluginu. + - Tworzy trzy tymczasowe konta Matrix (`driver`, `sut`, `observer`) oraz jeden prywatny pokój, po czym uruchamia podrzędny proces QA gateway z rzeczywistym pluginem Matrix jako transportem SUT. + - Domyślnie używa przypiętego stabilnego obrazu Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Nadpisz przez `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, gdy musisz testować inny obraz. + - Matrix nie udostępnia współdzielonych flag źródła poświadczeń, ponieważ linia tworzy lokalnie jednorazowych użytkowników. + - Zapisuje raport Matrix QA, podsumowanie, artefakt observed-events oraz połączony log wyjścia stdout/stderr w `.artifacts/qa-e2e/...`. - `pnpm openclaw qa telegram` - - Uruchamia linię QA Telegram live względem prawdziwej prywatnej grupy przy użyciu tokenów bota driver i SUT z env. + - Uruchamia linię QA Telegram live względem rzeczywistej prywatnej grupy przy użyciu tokenów bota driver i SUT z env. - Wymaga `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` oraz `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Id grupy musi być numerycznym identyfikatorem czatu Telegram. - - Obsługuje `--credential-source convex` dla współdzielonych poświadczeń z puli. Domyślnie używaj trybu env albo ustaw `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, aby przejść na współdzielone dzierżawy. - - Zwraca kod różny od zera, gdy którykolwiek scenariusz się nie powiedzie. Użyj `--allow-failures`, gdy - chcesz artefakty bez kończenia z błędem. + - Obsługuje `--credential-source convex` dla współdzielonych, pulowanych poświadczeń. Domyślnie używaj trybu env albo ustaw `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, aby włączyć dzierżawy z puli. + - Kończy się kodem niezerowym, gdy którykolwiek scenariusz zakończy się niepowodzeniem. Użyj `--allow-failures`, gdy + chcesz artefaktów bez kończenia z kodem błędu. - Wymaga dwóch różnych botów w tej samej prywatnej grupie, przy czym bot SUT musi udostępniać nazwę użytkownika Telegram. - Dla stabilnej obserwacji bot-do-bota włącz Bot-to-Bot Communication Mode w `@BotFather` dla obu botów i upewnij się, że bot driver może obserwować ruch botów w grupie. - - Zapisuje raport QA Telegram, podsumowanie i artefakt observed-messages w `.artifacts/qa-e2e/...`. Scenariusze odpowiedzi obejmują RTT od żądania wysłania przez driver do zaobserwowanej odpowiedzi SUT. + - Zapisuje raport Telegram QA, podsumowanie i artefakt observed-messages w `.artifacts/qa-e2e/...`. Scenariusze odpowiedzi obejmują RTT od żądania wysłania przez driver do zaobserwowanej odpowiedzi SUT. -Linie live transport współdzielą jeden standardowy kontrakt, aby nowe transporty nie dryfowały: +Linie transportu live współdzielą jeden standardowy kontrakt, aby nowe transporty nie dryfowały: -`qa-channel` pozostaje szerokim syntetycznym zestawem QA i nie jest częścią macierzy pokrycia live transport. +`qa-channel` pozostaje szerokim syntetycznym pakietem QA i nie jest częścią macierzy pokrycia transportów live. -| Linia | Canary | Brakowanie wzmianką | Blok allowlist | Odpowiedź najwyższego poziomu | Wznowienie po restarcie | Kontynuacja wątku | Izolacja wątku | Obserwacja reakcji | Polecenie help | -| -------- | ------ | ------------------- | -------------- | ----------------------------- | ----------------------- | ----------------- | -------------- | ------------------ | -------------- | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Linia | Canary | Bramka wzmianek | Blokada allowlist | Odpowiedź najwyższego poziomu | Wznowienie po restarcie | Kontynuacja wątku | Izolacja wątku | Obserwacja reakcji | Polecenie pomocy | +| -------- | ------ | --------------- | ----------------- | ----------------------------- | ----------------------- | ----------------- | -------------- | ------------------ | ---------------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | ### Współdzielone poświadczenia Telegram przez Convex (v1) Gdy `--credential-source convex` (lub `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) jest włączone dla -`openclaw qa telegram`, QA lab pobiera wyłączną dzierżawę z puli opartej na Convex, wysyła Heartbeat -tej dzierżawy, gdy linia działa, i zwalnia dzierżawę przy zamknięciu. +`openclaw qa telegram`, QA lab uzyskuje wyłączną dzierżawę z puli opartej na Convex, wysyła heartbeat +tej dzierżawy podczas działania linii i zwalnia dzierżawę przy zamknięciu. Referencyjny szkielet projektu Convex: @@ -164,7 +170,7 @@ Wymagane zmienne środowiskowe: - `OPENCLAW_QA_CONVEX_SECRET_CI` dla `ci` - Wybór roli poświadczeń: - CLI: `--credential-role maintainer|ci` - - Domyślna wartość env: `OPENCLAW_QA_CREDENTIAL_ROLE` (domyślnie `ci` w CI, w przeciwnym razie `maintainer`) + - Domyślne env: `OPENCLAW_QA_CREDENTIAL_ROLE` (domyślnie `ci` w CI, w przeciwnym razie `maintainer`) Opcjonalne zmienne środowiskowe: @@ -174,9 +180,9 @@ Opcjonalne zmienne środowiskowe: - `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (domyślnie `15000`) - `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (domyślnie `/qa-credentials/v1`) - `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (opcjonalny trace id) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` dopuszcza adresy URL Convex `http://` przez loopback tylko do lokalnego developmentu. +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` pozwala na loopbackowe adresy URL Convex `http://` tylko do lokalnego developmentu. -`OPENCLAW_QA_CONVEX_SITE_URL` powinno w normalnej pracy używać `https://`. +`OPENCLAW_QA_CONVEX_SITE_URL` powinien używać `https://` w normalnej pracy. Polecenia administracyjne maintainera (dodawanie/usuwanie/listowanie puli) wymagają konkretnie `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. @@ -189,14 +195,14 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Użyj `--json`, aby uzyskać wynik czytelny maszynowo w skryptach i narzędziach CI. +Użyj `--json` dla wyjścia czytelnego maszynowo w skryptach i narzędziach CI. Domyślny kontrakt endpointu (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Żądanie: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` - Sukces: `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` - - Wyczerpanie/możliwość ponowienia: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` + - Wyczerpane/do ponowienia: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - Żądanie: `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - Sukces: `{ status: "ok" }` (lub puste `2xx`) @@ -214,26 +220,26 @@ Domyślny kontrakt endpointu (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v - Żądanie: `{ kind?, status?, includePayload?, limit? }` - Sukces: `{ status: "ok", credentials, count }` -Kształt ładunku dla rodzaju Telegram: +Kształt payloadu dla rodzaju Telegram: - `{ groupId: string, driverToken: string, sutToken: string }` -- `groupId` musi być ciągiem numerycznego identyfikatora czatu Telegram. -- `admin/add` waliduje ten kształt dla `kind: "telegram"` i odrzuca nieprawidłowe ładunki. +- `groupId` musi być ciągiem znaków z numerycznym identyfikatorem czatu Telegram. +- `admin/add` waliduje ten kształt dla `kind: "telegram"` i odrzuca nieprawidłowe payloady. ### Dodawanie kanału do QA -Dodanie kanału do systemu QA w Markdown wymaga dokładnie dwóch rzeczy: +Dodanie kanału do markdownowego systemu QA wymaga dokładnie dwóch rzeczy: 1. Adaptera transportu dla kanału. -2. Pakietu scenariuszy, który testuje kontrakt kanału. +2. Pakietu scenariuszy, który sprawdza kontrakt kanału. -Nie dodawaj nowego głównego korzenia poleceń QA, jeśli współdzielony host `qa-lab` może -obsłużyć ten przepływ. +Nie dodawaj nowego głównego korzenia poleceń QA, gdy współdzielony host `qa-lab` może +obsługiwać ten przepływ. `qa-lab` zarządza współdzieloną mechaniką hosta: - korzeniem poleceń `openclaw qa` -- uruchamianiem i zamykaniem zestawu +- uruchamianiem i zamykaniem pakietu - współbieżnością workerów - zapisem artefaktów - generowaniem raportów @@ -243,34 +249,34 @@ obsłużyć ten przepływ. Pluginy runnerów zarządzają kontraktem transportu: - jak `openclaw qa ` jest montowane pod współdzielonym korzeniem `qa` -- jak gateway jest konfigurowany dla tego transportu +- jak Gateway jest konfigurowany dla tego transportu - jak sprawdzana jest gotowość - jak wstrzykiwane są zdarzenia przychodzące - jak obserwowane są wiadomości wychodzące - jak udostępniane są transkrypty i znormalizowany stan transportu - jak wykonywane są akcje oparte na transporcie -- jak obsługiwany jest reset lub cleanup specyficzny dla transportu +- jak obsługiwany jest reset lub czyszczenie specyficzne dla transportu Minimalny próg wdrożenia dla nowego kanału to: 1. Zachowaj `qa-lab` jako właściciela współdzielonego korzenia `qa`. 2. Zaimplementuj runner transportu na współdzielonym punkcie styku hosta `qa-lab`. -3. Zachowaj mechanikę specyficzną dla transportu wewnątrz Pluginu runnera albo harnessu kanału. -4. Zamontuj runner jako `openclaw qa ` zamiast rejestrować konkurencyjny korzeń polecenia. +3. Zachowaj mechanikę specyficzną dla transportu wewnątrz pluginu runnera lub harnessu kanału. +4. Zamontuj runner jako `openclaw qa ` zamiast rejestrować konkurencyjne główne polecenie. Pluginy runnerów powinny deklarować `qaRunners` w `openclaw.plugin.json` i eksportować pasującą tablicę `qaRunnerCliRegistrations` z `runtime-api.ts`. - Zachowaj lekkość `runtime-api.ts`; leniwe wykonywanie CLI i runnera powinno pozostać za oddzielnymi entrypointami. -5. Napisz lub dostosuj scenariusze Markdown w tematycznych katalogach `qa/scenarios/`. -6. Używaj generycznych helperów scenariuszy dla nowych scenariuszy. -7. Zachowaj działanie istniejących aliasów zgodności, chyba że repo prowadzi celową migrację. + Zachowaj lekkość `runtime-api.ts`; leniwe CLI i wykonywanie runnera powinny pozostać za oddzielnymi entrypointami. +5. Twórz lub dostosowuj scenariusze markdown w tematycznych katalogach `qa/scenarios/`. +6. Dla nowych scenariuszy używaj generycznych helperów scenariuszy. +7. Utrzymuj działanie istniejących aliasów zgodności, chyba że repo przeprowadza celową migrację. Reguła decyzyjna jest ścisła: -- Jeśli zachowanie można wyrazić raz w `qa-lab`, umieść je w `qa-lab`. -- Jeśli zachowanie zależy od jednego transportu kanału, zachowaj je w tym Pluginie runnera albo harnessie Pluginu. -- Jeśli scenariusz potrzebuje nowej możliwości, z której może korzystać więcej niż jeden kanał, dodaj generyczny helper zamiast gałęzi specyficznej dla kanału w `suite.ts`. -- Jeśli zachowanie ma sens tylko dla jednego transportu, zachowaj scenariusz jako specyficzny dla transportu i zaznacz to jawnie w kontrakcie scenariusza. +- Jeśli zachowanie da się wyrazić raz w `qa-lab`, umieść je w `qa-lab`. +- Jeśli zachowanie zależy od transportu jednego kanału, pozostaw je w pluginie tego runnera lub harnessie pluginu. +- Jeśli scenariusz potrzebuje nowej możliwości, z której może skorzystać więcej niż jeden kanał, dodaj generyczny helper zamiast gałęzi specyficznej dla kanału w `suite.ts`. +- Jeśli zachowanie ma sens tylko dla jednego transportu, zachowaj scenariusz jako specyficzny dla transportu i wyraźnie zaznacz to w kontrakcie scenariusza. -Preferowane generyczne nazwy helperów dla nowych scenariuszy to: +Preferowane nazwy generycznych helperów dla nowych scenariuszy to: - `waitForTransportReady` - `waitForChannelReady` @@ -285,7 +291,7 @@ Preferowane generyczne nazwy helperów dla nowych scenariuszy to: - `formatTransportTranscript` - `resetTransport` -Aliasy zgodności pozostają dostępne dla istniejących scenariuszy, w tym: +Aliasów zgodności nadal można używać w istniejących scenariuszach, w tym: - `waitForQaChannelReady` - `waitForOutboundMessage` @@ -294,234 +300,234 @@ Aliasy zgodności pozostają dostępne dla istniejących scenariuszy, w tym: - `resetBus` Nowa praca nad kanałami powinna używać generycznych nazw helperów. -Aliasy zgodności istnieją po to, by uniknąć migracji typu flag day, a nie jako model +Aliasy zgodności istnieją po to, aby uniknąć migracji typu flag day, a nie jako model dla tworzenia nowych scenariuszy. -## Zestawy testów (co uruchamia się gdzie) +## Pakiety testowe (co uruchamia się gdzie) -Myśl o zestawach jako o „rosnącym realizmie” (i rosnącej zawodności/koszcie): +Myśl o tych pakietach jako o „rosnącym realizmie” (i rosnącej zawodności/koszcie): ### Unit / integration (domyślne) - Polecenie: `pnpm test` -- Konfiguracja: niecelowane uruchomienia używają zestawu shardów `vitest.full-*.config.ts` i mogą rozwijać wieloprojektowe shardy do konfiguracji per projekt na potrzeby równoległego planowania -- Pliki: inwentarze core/unit pod `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` oraz dopuszczone testy node w `ui` objęte przez `vitest.unit.config.ts` +- Konfiguracja: uruchomienia bez wskazanego celu używają zestawu shardów `vitest.full-*.config.ts` i mogą rozwijać wieloprojektowe shardy do konfiguracji per projekt w celu równoległego planowania +- Pliki: inwentarze core/unit w `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` oraz testy Node z białej listy `ui`, objęte przez `vitest.unit.config.ts` - Zakres: - - Czyste testy unit - - Testy integracyjne in-process (auth gateway, routing, narzędzia, parsowanie, konfiguracja) - - Deterministyczne testy regresyjne dla znanych błędów + - Czyste testy jednostkowe + - Testy integracyjne w procesie (uwierzytelnianie gateway, routing, narzędzia, parsowanie, konfiguracja) + - Deterministyczne regresje dla znanych błędów - Oczekiwania: - - Uruchamiają się w CI + - Uruchamiane w CI - Nie wymagają prawdziwych kluczy - Powinny być szybkie i stabilne - Uwaga o projektach: - - Niecelowane `pnpm test` uruchamia teraz dwanaście mniejszych konfiguracji shardów (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) zamiast jednego ogromnego natywnego procesu projektu głównego. To zmniejsza szczytowy RSS na obciążonych maszynach i zapobiega temu, by prace auto-reply/extension zagłodziły niezwiązane zestawy. - - `pnpm test --watch` nadal używa natywnego grafu projektów z korzenia `vitest.config.ts`, ponieważ wieloshardowa pętla watch nie jest praktyczna. - - `pnpm test`, `pnpm test:watch` i `pnpm test:perf:imports` najpierw kierują jawne cele plików/katalogów przez zawężone linie, więc `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` unika pełnego kosztu startowego projektu głównego. - - `pnpm test:changed` rozwija zmienione ścieżki git do tych samych zawężonych linii, gdy diff dotyka tylko trasowalnych plików źródłowych/testowych; edycje konfiguracji/setupu nadal wracają do szerokiego ponownego uruchomienia projektu głównego. - - `pnpm check:changed` to normalna inteligentna lokalna bramka dla wąskiej pracy. Klasyfikuje diff do core, testów core, extensions, testów extension, apps, docs, metadanych release i tooling, po czym uruchamia pasujące linie typecheck/lint/test. Zmiany publicznego Plugin SDK i kontraktów pluginów obejmują walidację extension, ponieważ extensions zależą od tych kontraktów core. Zmiany tylko w metadanych release związane z podniesieniem wersji uruchamiają celowane kontrole wersji/konfiguracji/zależności root zamiast pełnego zestawu, z ochroną odrzucającą zmiany pakietów poza polem wersji najwyższego poziomu. - - Lekkie importowo testy unit z agents, commands, plugins, helperów auto-reply, `plugin-sdk` i podobnych czystych obszarów narzędziowych są kierowane przez linię `unit-fast`, która pomija `test/setup-openclaw-runtime.ts`; pliki stanowe/ciężkie runtime pozostają na istniejących liniach. - - Wybrane pliki źródłowe helperów `plugin-sdk` i `commands` również mapują uruchomienia w trybie changed do jawnych testów rodzeństwa w tych lekkich liniach, dzięki czemu edycje helperów unikają ponownego uruchamiania pełnego ciężkiego zestawu dla tego katalogu. - - `auto-reply` ma teraz trzy dedykowane koszyki: helpery core najwyższego poziomu, testy integracyjne najwyższego poziomu `reply.*` oraz poddrzewo `src/auto-reply/reply/**`. To utrzymuje najcięższy harness odpowiedzi z dala od tanich testów status/chunk/token. -- Uwaga o embedded runnerze: - - Gdy zmieniasz wejścia wykrywania message-tool albo kontekst runtime Compaction, - zachowaj oba poziomy pokrycia. - - Dodaj skoncentrowane testy regresyjne helperów dla czystych granic routingu/normalizacji. - - Utrzymuj też zdrowie osadzonych zestawów integracyjnych runnera: + - Niewskazane `pnpm test` uruchamia teraz dwanaście mniejszych konfiguracji shardów (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) zamiast jednego ogromnego natywnego procesu projektu root. To zmniejsza szczytowy RSS na obciążonych maszynach i zapobiega temu, by prace `auto-reply`/rozszerzeń zagłodziły niezwiązane pakiety. + - `pnpm test --watch` nadal używa natywnego grafu projektów root `vitest.config.ts`, ponieważ pętla watch z wieloma shardami nie jest praktyczna. + - `pnpm test`, `pnpm test:watch` oraz `pnpm test:perf:imports` najpierw kierują jawne cele plików/katalogów do zawężonych linii, więc `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` unika kosztu pełnego startu projektu root. + - `pnpm test:changed` rozwija zmienione ścieżki gita do tych samych zawężonych linii, gdy diff dotyka wyłącznie routowalnych plików źródłowych/testowych; edycje konfiguracji/setup nadal wracają do szerokiego ponownego uruchomienia projektu root. + - `pnpm check:changed` to normalna inteligentna lokalna bramka dla wąskich zmian. Klasyfikuje diff do core, testów core, rozszerzeń, testów rozszerzeń, aplikacji, dokumentacji, metadanych wydania i narzędzi, a następnie uruchamia pasujące linie typecheck/lint/test. Zmiany w publicznym Plugin SDK i kontraktach pluginów obejmują walidację rozszerzeń, ponieważ rozszerzenia zależą od tych kontraktów core. Zmiany wersji wyłącznie w metadanych wydania uruchamiają ukierunkowane kontrole wersji/konfiguracji/zależności root zamiast pełnego pakietu, z ochroną odrzucającą zmiany w pakietach poza polem wersji najwyższego poziomu. + - Lekkie importowo testy jednostkowe z agents, commands, plugins, helperów `auto-reply`, `plugin-sdk` i podobnych obszarów czystych utili trafiają do linii `unit-fast`, która pomija `test/setup-openclaw-runtime.ts`; pliki stanowe/ciężkie uruchomieniowo pozostają na istniejących liniach. + - Wybrane pliki źródłowe helperów `plugin-sdk` i `commands` również mapują uruchomienia trybu changed do jawnych sąsiednich testów w tych lekkich liniach, dzięki czemu edycje helperów nie wymuszają ponownego uruchamiania całego ciężkiego pakietu dla tego katalogu. + - `auto-reply` ma teraz trzy dedykowane koszyki: główne helpery core najwyższego poziomu, testy integracyjne najwyższego poziomu `reply.*` oraz poddrzewo `src/auto-reply/reply/**`. Dzięki temu najcięższa praca harnessu odpowiedzi nie trafia do tanich testów status/chunk/token. +- Uwaga o Embedded runner: + - Gdy zmieniasz wejścia wykrywania narzędzi wiadomości lub kontekst uruchomieniowy Compaction, + utrzymuj oba poziomy pokrycia. + - Dodawaj ukierunkowane regresje helperów dla granic czystego routingu/normalizacji. + - Utrzymuj też zdrowie pakietów integracyjnych embedded runner: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` oraz `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Te zestawy weryfikują, że identyfikatory z zakresem i zachowanie Compaction nadal przepływają - przez prawdziwe ścieżki `run.ts` / `compact.ts`; same testy helperów nie są - wystarczającym substytutem tych ścieżek integracyjnych. + - Te pakiety weryfikują, że zakresowane identyfikatory i zachowanie Compaction nadal przepływają + przez rzeczywiste ścieżki `run.ts` / `compact.ts`; same testy helperów nie są + wystarczającym zamiennikiem tych ścieżek integracyjnych. - Uwaga o puli: - - Bazowa konfiguracja Vitest domyślnie używa `threads`. - - Współdzielona konfiguracja Vitest ustawia też `isolate: false` i używa nieizolowanego runnera w projektach root, konfiguracjach e2e i live. - - Linia UI z root zachowuje swój setup `jsdom` i optimizer, ale teraz działa również na współdzielonym nieizolowanym runnerze. + - Bazowa konfiguracja Vitest domyślnie używa teraz `threads`. + - Współdzielona konfiguracja Vitest ustawia też na stałe `isolate: false` i używa nieizolowanego runnera we wszystkich projektach root, konfiguracjach e2e i live. + - Główna linia UI zachowuje konfigurację `jsdom` i optimizer, ale teraz również działa na współdzielonym nieizolowanym runnerze. - Każdy shard `pnpm test` dziedziczy te same domyślne ustawienia `threads` + `isolate: false` ze współdzielonej konfiguracji Vitest. - - Współdzielony launcher `scripts/run-vitest.mjs` domyślnie dodaje teraz również `--no-maglev` dla podrzędnych procesów Node Vitest, aby zmniejszyć churn kompilacji V8 podczas dużych lokalnych uruchomień. Ustaw `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, jeśli chcesz porównać zachowanie ze stockowym V8. -- Uwaga o szybkiej lokalnej iteracji: - - `pnpm changed:lanes` pokazuje, które linie architektoniczne wywołuje diff. - - Hook pre-commit uruchamia `pnpm check:changed --staged` po sformatowaniu/lintowaniu staged, więc commity tylko core nie płacą kosztu testów extension, chyba że dotykają publicznych kontraktów skierowanych do extension. Commity tylko w metadanych release pozostają na celowanej linii wersji/konfiguracji/zależności root. - - Jeśli dokładny zestaw zmian staged został już zweryfikowany równymi lub silniejszymi bramkami, użyj `scripts/committer --fast "" `, aby pominąć tylko ponowne uruchomienie hooka changed-scope. Format/lint staged nadal się uruchomią. Wspomnij o ukończonych bramkach w handoffie. Jest to również dopuszczalne po ponownym uruchomieniu izolowanego flaky hooka, który przejdzie ze scoped proof. - - `pnpm test:changed` kieruje przez zawężone linie, gdy zmienione ścieżki da się czysto zmapować do mniejszego zestawu. - - `pnpm test:max` i `pnpm test:changed:max` zachowują to samo routowanie, tylko z wyższym limitem workerów. - - Lokalne automatyczne skalowanie workerów jest teraz celowo konserwatywne i dodatkowo wycofuje się, gdy średnie obciążenie hosta jest już wysokie, więc wiele równoległych uruchomień Vitest domyślnie wyrządza mniej szkód. - - Bazowa konfiguracja Vitest oznacza projekty/pliki konfiguracji jako `forceRerunTriggers`, aby ponowne uruchomienia w trybie changed pozostawały poprawne przy zmianie połączeń testowych. - - Konfiguracja pozostawia `OPENCLAW_VITEST_FS_MODULE_CACHE` włączone na obsługiwanych hostach; ustaw `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, jeśli chcesz jedną jawną lokalizację cache do bezpośredniego profilowania. + - Współdzielony launcher `scripts/run-vitest.mjs` domyślnie dodaje teraz również `--no-maglev` dla podrzędnych procesów Node Vitest, aby ograniczyć churn kompilacji V8 podczas dużych lokalnych uruchomień. Ustaw `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, jeśli chcesz porównać zachowanie ze standardowym V8. +- Uwaga o szybkiej iteracji lokalnej: + - `pnpm changed:lanes` pokazuje, które linie architektoniczne uruchamia diff. + - Hook pre-commit uruchamia `pnpm check:changed --staged` po sformatowaniu/lintowaniu staged, więc commity tylko do core nie płacą kosztu testów rozszerzeń, chyba że dotykają publicznych kontraktów skierowanych do rozszerzeń. Commity wyłącznie do metadanych wydania pozostają na ukierunkowanej linii wersja/konfiguracja/zależności root. + - Jeśli dokładny zestaw staged change został już zwalidowany równymi lub silniejszymi bramkami, użyj `scripts/committer --fast "" `, aby pominąć tylko ponowne uruchomienie hooka changed-scope. Staged format/lint nadal się uruchamiają. W handoff wspomnij o ukończonych bramkach. Jest to również akceptowalne po ponownym uruchomieniu odizolowanej niestabilnej awarii hooka, jeśli przejdzie z dowodem w zawężonym zakresie. + - `pnpm test:changed` kieruje przez zawężone linie, gdy zmienione ścieżki czysto mapują się na mniejszy pakiet. + - `pnpm test:max` i `pnpm test:changed:max` zachowują to samo zachowanie routingu, tylko z wyższym limitem workerów. + - Automatyczne skalowanie lokalnych workerów jest teraz celowo konserwatywne i dodatkowo wycofuje się, gdy średnie obciążenie hosta jest już wysokie, więc wiele równoczesnych uruchomień Vitest domyślnie wyrządza mniej szkód. + - Bazowa konfiguracja Vitest oznacza teraz pliki projektów/konfiguracji jako `forceRerunTriggers`, aby ponowne uruchomienia trybu changed pozostawały poprawne przy zmianach w okablowaniu testów. + - Konfiguracja utrzymuje włączone `OPENCLAW_VITEST_FS_MODULE_CACHE` na obsługiwanych hostach; ustaw `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, jeśli chcesz mieć jedną jawną lokalizację cache do bezpośredniego profilowania. - Uwaga o debugowaniu wydajności: - - `pnpm test:perf:imports` włącza raportowanie czasu importu Vitest oraz wynik z rozbiciem importów. - - `pnpm test:perf:imports:changed` zawęża ten sam widok profilowania do plików zmienionych względem `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` porównuje routowane `test:changed` z natywną ścieżką projektu głównego dla tego zatwierdzonego diffu i wypisuje czas ścienny oraz macOS max RSS. -- `pnpm test:perf:changed:bench -- --worktree` benchmarkuje bieżące brudne drzewo, kierując listę zmienionych plików przez `scripts/test-projects.mjs` i główną konfigurację Vitest. - - `pnpm test:perf:profile:main` zapisuje profil CPU głównego wątku dla startu Vitest/Vite i narzutu transformacji. - - `pnpm test:perf:profile:runner` zapisuje profile CPU+heap runnera dla zestawu unit z wyłączoną równoległością plików. + - `pnpm test:perf:imports` włącza raportowanie czasu importu Vitest oraz wyjście z rozbiciem importów. + - `pnpm test:perf:imports:changed` zawęża ten sam widok profilowania do plików zmienionych od `origin/main`. +- `pnpm test:perf:changed:bench -- --ref ` porównuje kierowane `test:changed` z natywną ścieżką projektu root dla tego zatwierdzonego diffu i wypisuje wall time oraz macOS max RSS. +- `pnpm test:perf:changed:bench -- --worktree` benchmarkuje bieżące brudne drzewo, kierując listę zmienionych plików przez `scripts/test-projects.mjs` i konfigurację root Vitest. + - `pnpm test:perf:profile:main` zapisuje profil CPU głównego wątku dla narzutu startu i transformacji Vitest/Vite. + - `pnpm test:perf:profile:runner` zapisuje profile CPU+heap runnera dla pakietu unit z wyłączoną równoległością plików. ### Stability (gateway) - Polecenie: `pnpm test:stability:gateway` - Konfiguracja: `vitest.gateway.config.ts`, wymuszony jeden worker - Zakres: - - Uruchamia prawdziwy Gateway loopback z domyślnie włączoną diagnostyką - - Przepuszcza syntetyczne obciążenie wiadomości, pamięci i dużych payloadów gateway przez ścieżkę zdarzeń diagnostycznych + - Uruchamia rzeczywisty loopback Gateway z domyślnie włączoną diagnostyką + - Przepuszcza syntetyczny churn wiadomości gateway, pamięci i dużych payloadów przez ścieżkę zdarzeń diagnostycznych - Odpytuje `diagnostics.stability` przez Gateway WS RPC - - Obejmuje helpery trwałości pakietu diagnostyki stability + - Obejmuje helpery utrwalania pakietu diagnostycznej stabilności - Sprawdza, że rejestrator pozostaje ograniczony, syntetyczne próbki RSS pozostają poniżej budżetu presji, a głębokości kolejek per sesja spadają z powrotem do zera - Oczekiwania: - - Bezpieczny dla CI i bez kluczy - - Wąska linia do śledzenia regresji stability, a nie substytut pełnego zestawu Gateway + - Bezpieczne dla CI i bez kluczy + - Wąska linia do dalszej pracy nad regresjami stabilności, a nie zamiennik pełnego pakietu Gateway -### E2E (smoke Gateway) +### E2E (smoke gateway) - Polecenie: `pnpm test:e2e` - Konfiguracja: `vitest.e2e.config.ts` -- Pliki: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` oraz testy E2E dołączonych Pluginów pod `extensions/` -- Domyślne ustawienia runtime: +- Pliki: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` oraz testy E2E bundlowanych pluginów w `extensions/` +- Domyślne ustawienia uruchomieniowe: - Używa Vitest `threads` z `isolate: false`, zgodnie z resztą repo. - Używa adaptacyjnych workerów (CI: do 2, lokalnie: domyślnie 1). - - Domyślnie działa w trybie silent, aby zmniejszyć narzut I/O konsoli. + - Domyślnie działa w trybie silent, aby ograniczyć narzut I/O konsoli. - Przydatne nadpisania: - - `OPENCLAW_E2E_WORKERS=`, aby wymusić liczbę workerów (ograniczoną do 16). - - `OPENCLAW_E2E_VERBOSE=1`, aby ponownie włączyć verbose output konsoli. + - `OPENCLAW_E2E_WORKERS=`, aby wymusić liczbę workerów (maksymalnie 16). + - `OPENCLAW_E2E_VERBOSE=1`, aby ponownie włączyć szczegółowe wyjście konsoli. - Zakres: - - Wieloinstancyjne zachowanie end-to-end Gateway - - Powierzchnie WebSocket/HTTP, parowanie Node i cięższe sieciowanie + - Zachowanie end-to-end wieloinstancyjnego gateway + - Powierzchnie WebSocket/HTTP, parowanie Node oraz cięższa komunikacja sieciowa - Oczekiwania: - - Uruchamia się w CI (gdy włączone w pipeline) - - Nie wymaga prawdziwych kluczy - - Więcej ruchomych części niż testy unit (może być wolniejszy) + - Uruchamiane w CI (gdy są włączone w pipeline) + - Nie wymagają prawdziwych kluczy + - Mają więcej ruchomych części niż testy jednostkowe (mogą być wolniejsze) ### E2E: smoke backendu OpenShell - Polecenie: `pnpm test:e2e:openshell` - Plik: `extensions/openshell/src/backend.e2e.test.ts` - Zakres: - - Uruchamia izolowany Gateway OpenShell na hoście przez Docker + - Uruchamia odizolowany gateway OpenShell na hoście przez Docker - Tworzy sandbox z tymczasowego lokalnego Dockerfile - - Testuje backend OpenShell OpenClaw przez prawdziwe `sandbox ssh-config` + wykonanie SSH - - Weryfikuje zdalno-kanoniczne zachowanie systemu plików przez most fs sandboxa + - Testuje backend OpenShell OpenClaw przez rzeczywiste `sandbox ssh-config` + wykonanie SSH + - Weryfikuje zdalno-kanoniczne zachowanie systemu plików przez most fs sandboxu - Oczekiwania: - Tylko opt-in; nie jest częścią domyślnego uruchomienia `pnpm test:e2e` - Wymaga lokalnego CLI `openshell` oraz działającego demona Docker - - Używa izolowanego `HOME` / `XDG_CONFIG_HOME`, a następnie niszczy testowy gateway i sandbox + - Używa odizolowanych `HOME` / `XDG_CONFIG_HOME`, a następnie niszczy testowy gateway i sandbox - Przydatne nadpisania: - - `OPENCLAW_E2E_OPENSHELL=1`, aby włączyć test przy ręcznym uruchamianiu szerszego zestawu e2e - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, aby wskazać niestandardowe binarium CLI lub skrypt wrappera + - `OPENCLAW_E2E_OPENSHELL=1`, aby włączyć test przy ręcznym uruchamianiu szerszego pakietu e2e + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, aby wskazać niestandardowy binarny plik CLI lub skrypt wrappera -### Live (prawdziwi providerzy + prawdziwe modele) +### Live (rzeczywiści dostawcy + rzeczywiste modele) - Polecenie: `pnpm test:live` - Konfiguracja: `vitest.live.config.ts` -- Pliki: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` oraz testy live dołączonych Pluginów pod `extensions/` +- Pliki: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` oraz testy live bundlowanych pluginów w `extensions/` - Domyślnie: **włączone** przez `pnpm test:live` (ustawia `OPENCLAW_LIVE_TEST=1`) - Zakres: - - „Czy ten provider/model rzeczywiście działa _dzisiaj_ z prawdziwymi poświadczeniami?” - - Wychwytywanie zmian formatów providerów, dziwactw wywołań narzędzi, problemów auth i zachowania limitów szybkości + - „Czy ten dostawca/model faktycznie działa _dzisiaj_ z prawdziwymi poświadczeniami?” + - Wychwytywanie zmian formatów dostawców, osobliwości wywołań narzędzi, problemów z uwierzytelnianiem i zachowań limitów szybkości - Oczekiwania: - - Z założenia niestabilne w CI (prawdziwe sieci, prawdziwe polityki providerów, limity, awarie) + - Celowo niestabilne w CI (rzeczywiste sieci, rzeczywiste polityki dostawców, limity, awarie) - Kosztują pieniądze / zużywają limity szybkości - Lepiej uruchamiać zawężone podzbiory niż „wszystko” -- Uruchomienia live pobierają `~/.profile`, aby uzupełnić brakujące klucze API. -- Domyślnie uruchomienia live nadal izolują `HOME` i kopiują materiał konfiguracyjny/auth do tymczasowego katalogu testowego, aby fixture unit nie mogły modyfikować Twojego prawdziwego `~/.openclaw`. -- Ustaw `OPENCLAW_LIVE_USE_REAL_HOME=1` tylko wtedy, gdy celowo chcesz, by testy live używały Twojego prawdziwego katalogu domowego. -- `pnpm test:live` domyślnie działa teraz w cichszym trybie: zachowuje wyjście postępu `[live] ...`, ale wycisza dodatkową informację o `~/.profile` oraz wyłącza logi bootstrapu gateway/hałas Bonjour. Ustaw `OPENCLAW_LIVE_TEST_QUIET=0`, jeśli chcesz z powrotem pełne logi startowe. -- Rotacja kluczy API (specyficzna dla providera): ustaw `*_API_KEYS` w formacie przecinek/średnik albo `*_API_KEY_1`, `*_API_KEY_2` (na przykład `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) albo nadpisanie per live przez `OPENCLAW_LIVE_*_KEY`; testy ponawiają próby przy odpowiedziach z limitem szybkości. -- Wyjście postępu/Heartbeat: - - Zestawy live emitują teraz linie postępu do stderr, dzięki czemu długie wywołania providerów są wyraźnie aktywne nawet wtedy, gdy przechwytywanie konsoli Vitest jest ciche. - - `vitest.live.config.ts` wyłącza przechwytywanie konsoli przez Vitest, dzięki czemu linie postępu providera/gateway są natychmiast strumieniowane podczas uruchomień live. - - Dostosuj Heartbeat dla modeli bezpośrednich przez `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Dostosuj Heartbeat gateway/probe przez `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. +- Uruchomienia live pobierają `~/.profile`, aby przechwycić brakujące klucze API. +- Domyślnie uruchomienia live nadal izolują `HOME` i kopiują materiał config/auth do tymczasowego katalogu testowego home, aby fixture unit nie mogły modyfikować rzeczywistego `~/.openclaw`. +- Ustaw `OPENCLAW_LIVE_USE_REAL_HOME=1` tylko wtedy, gdy celowo chcesz, aby testy live używały rzeczywistego katalogu domowego. +- `pnpm test:live` domyślnie działa teraz w cichszym trybie: zachowuje wyjście postępu `[live] ...`, ale ukrywa dodatkową informację o `~/.profile` i wycisza logi bootstrapu gateway / komunikaty Bonjour. Ustaw `OPENCLAW_LIVE_TEST_QUIET=0`, jeśli chcesz przywrócić pełne logi startowe. +- Rotacja kluczy API (specyficzna dla dostawcy): ustaw `*_API_KEYS` w formacie z przecinkami/średnikami lub `*_API_KEY_1`, `*_API_KEY_2` (na przykład `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) albo nadpisanie per live przez `OPENCLAW_LIVE_*_KEY`; testy ponawiają próby przy odpowiedziach rate limit. +- Wyjście postępu/heartbeat: + - Pakiety live emitują teraz linie postępu do stderr, aby długie wywołania dostawców były widocznie aktywne nawet wtedy, gdy przechwytywanie konsoli Vitest jest ciche. + - `vitest.live.config.ts` wyłącza przechwytywanie konsoli Vitest, więc linie postępu dostawcy/gateway są strumieniowane natychmiast podczas uruchomień live. + - Dostosuj heartbeat bezpośrednich modeli przez `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Dostosuj heartbeat gateway/sond przez `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Który zestaw powinienem uruchomić? +## Który pakiet powinienem uruchomić? Użyj tej tabeli decyzyjnej: -- Edycja logiki/testów: uruchom `pnpm test` (oraz `pnpm test:coverage`, jeśli dużo zmieniłeś) -- Dotykanie sieci Gateway / protokołu WS / parowania: dodaj `pnpm test:e2e` -- Debugowanie „mój bot nie działa” / błędów specyficznych dla providera / wywołań narzędzi: uruchom zawężone `pnpm test:live` +- Edytujesz logikę/testy: uruchom `pnpm test` (oraz `pnpm test:coverage`, jeśli dużo zmieniłeś) +- Dotykasz sieci gateway / protokołu WS / parowania: dodaj `pnpm test:e2e` +- Debugujesz „mój bot nie działa” / awarie specyficzne dla dostawcy / wywoływanie narzędzi: uruchom zawężone `pnpm test:live` -## Live: przegląd możliwości Android Node +## Live: sweep możliwości Node Android - Test: `src/gateway/android-node.capabilities.live.test.ts` - Skrypt: `pnpm android:test:integration` -- Cel: wywołać **każde aktualnie reklamowane polecenie** podłączonego Android Node i sprawdzić zachowanie kontraktu poleceń. +- Cel: wywołać **każde polecenie aktualnie ogłaszane** przez podłączony Node Android i potwierdzić zachowanie kontraktu poleceń. - Zakres: - - Wstępnie przygotowana/ręczna konfiguracja (zestaw nie instaluje/nie uruchamia/nie paruje aplikacji). - - Walidacja `node.invoke` gateway polecenie po poleceniu dla wybranego Android Node. -- Wymagane przygotowanie: - - Aplikacja Android już podłączona + sparowana z gateway. - - Aplikacja utrzymywana na pierwszym planie. - - Uprawnienia/zgody na przechwytywanie przyznane dla możliwości, które mają przechodzić. + - Wstępnie przygotowana/ręczna konfiguracja (pakiet nie instaluje/nie uruchamia/nie paruje aplikacji). + - Walidacja `node.invoke` gateway polecenie po poleceniu dla wybranego Node Android. +- Wymagane wstępne przygotowanie: + - Aplikacja Android jest już podłączona i sparowana z gateway. + - Aplikacja pozostaje na pierwszym planie. + - Uprawnienia/zgoda na przechwytywanie zostały nadane dla możliwości, które mają przechodzić. - Opcjonalne nadpisania celu: - `OPENCLAW_ANDROID_NODE_ID` lub `OPENCLAW_ANDROID_NODE_NAME`. - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`. - Pełne szczegóły konfiguracji Android: [Aplikacja Android](/pl/platforms/android) -## Live: smoke modeli (klucze profilowe) +## Live: smoke modeli (klucze profili) -Testy live są podzielone na dwie warstwy, aby można było izolować błędy: +Testy live są podzielone na dwie warstwy, aby można było izolować awarie: -- „Model bezpośredni” mówi nam, czy provider/model w ogóle potrafi odpowiedzieć przy danym kluczu. -- „Smoke gateway” mówi nam, czy pełny pipeline gateway+agent działa dla tego modelu (sesje, historia, narzędzia, polityka sandboxa itd.). +- „Direct model” mówi nam, czy dostawca/model w ogóle potrafi odpowiedzieć przy danym kluczu. +- „Gateway smoke” mówi nam, czy pełny pipeline gateway+agent działa dla tego modelu (sesje, historia, narzędzia, polityka sandboxu itd.). -### Warstwa 1: Bezpośrednia kompletacja modelu (bez gateway) +### Warstwa 1: Bezpośrednie completion modelu (bez gateway) - Test: `src/agents/models.profiles.live.test.ts` - Cel: - Wyliczyć wykryte modele - - Użyć `getApiKeyForModel` do wyboru modeli, dla których masz poświadczenia - - Uruchomić małą kompletację dla każdego modelu (oraz celowane regresje tam, gdzie trzeba) + - Użyć `getApiKeyForModel`, aby wybrać modele, dla których masz poświadczenia + - Uruchomić małe completion na model dla każdego modelu (oraz ukierunkowane regresje tam, gdzie to potrzebne) - Jak włączyć: - `pnpm test:live` (lub `OPENCLAW_LIVE_TEST=1`, jeśli wywołujesz Vitest bezpośrednio) -- Ustaw `OPENCLAW_LIVE_MODELS=modern` (lub `all`, alias dla modern), aby rzeczywiście uruchomić ten zestaw; w przeciwnym razie zostanie pominięty, aby `pnpm test:live` pozostało skupione na smoke gateway +- Ustaw `OPENCLAW_LIVE_MODELS=modern` (lub `all`, alias dla modern), aby faktycznie uruchomić ten pakiet; w przeciwnym razie zostanie pominięty, by `pnpm test:live` pozostawało skupione na smoke gateway - Jak wybierać modele: - - `OPENCLAW_LIVE_MODELS=modern`, aby uruchomić nowoczesną allowlistę (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - - `OPENCLAW_LIVE_MODELS=all` to alias dla nowoczesnej allowlisty - - albo `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (allowlista rozdzielana przecinkami) - - Przeglądy modern/all domyślnie używają kuratorowanego limitu wysokiego sygnału; ustaw `OPENCLAW_LIVE_MAX_MODELS=0` dla wyczerpującego przeglądu modern albo dodatnią liczbę dla mniejszego limitu. -- Jak wybierać providerów: - - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlista rozdzielana przecinkami) + - `OPENCLAW_LIVE_MODELS=modern`, aby uruchomić nowoczesną allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) + - `OPENCLAW_LIVE_MODELS=all` to alias dla nowoczesnej allowlist + - albo `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (allowlist oddzielona przecinkami) + - Sweepy modern/all domyślnie używają wyselekcjonowanego limitu wysokiego sygnału; ustaw `OPENCLAW_LIVE_MAX_MODELS=0` dla wyczerpującego sweepu modern albo wartość dodatnią dla mniejszego limitu. +- Jak wybierać dostawców: + - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlist oddzielona przecinkami) - Skąd pochodzą klucze: - - Domyślnie: magazyn profili i fallbacki env - - Ustaw `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić użycie **wyłącznie magazynu profili** + - Domyślnie: store profili i fallbacki env + - Ustaw `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić wyłącznie **store profili** - Dlaczego to istnieje: - - Oddziela „API providera jest zepsute / klucz jest nieprawidłowy” od „pipeline agenta gateway jest zepsuty” - - Zawiera małe, izolowane regresje (przykład: OpenAI Responses/Codex Responses reasoning replay + przepływy tool-call) + - Oddziela „API dostawcy jest zepsute / klucz jest nieprawidłowy” od „pipeline agenta gateway jest zepsuty” + - Zawiera małe, odizolowane regresje (przykład: przepływy OpenAI Responses/Codex Responses reasoning replay + tool-call) ### Warstwa 2: Gateway + smoke agenta dev (to, co faktycznie robi „@openclaw”) - Test: `src/gateway/gateway-models.profiles.live.test.ts` - Cel: - - Uruchomić gateway in-process - - Utworzyć/załatać sesję `agent:dev:*` (nadpisanie modelu per przebieg) - - Iterować po modelach-z-kluczami i sprawdzać: - - „sensowną” odpowiedź (bez narzędzi) - - działanie prawdziwego wywołania narzędzia (sonda odczytu) + - Uruchomić gateway w procesie + - Utworzyć/załatać sesję `agent:dev:*` (nadpisanie modelu na uruchomienie) + - Iterować po modelach-z-kluczami i potwierdzić: + - „znaczącą” odpowiedź (bez narzędzi) + - że działa rzeczywiste wywołanie narzędzia (sonda odczytu) - opcjonalne dodatkowe sondy narzędzi (sonda exec+read) - - ciągłe działanie ścieżek regresji OpenAI (tylko tool-call → follow-up) -- Szczegóły sond (aby móc szybko wyjaśniać błędy): - - sonda `read`: test zapisuje plik nonce w workspace i prosi agenta o `read` go oraz odesłanie nonce. - - sonda `exec+read`: test prosi agenta o zapisanie nonce do pliku tymczasowego przez `exec`, a następnie odczytanie go przez `read`. - - sonda obrazu: test dołącza wygenerowany PNG (kot + losowy kod) i oczekuje, że model zwróci `cat `. + - że ścieżki regresji OpenAI (tylko tool-call → follow-up) nadal działają +- Szczegóły sond (aby dało się szybko wyjaśniać awarie): + - Sonda `read`: test zapisuje plik nonce w workspace i prosi agenta, aby go `read` i odesłał nonce. + - Sonda `exec+read`: test prosi agenta, aby przez `exec` zapisał nonce do pliku tymczasowego, a następnie przez `read` go odczytał. + - Sonda obrazu: test dołącza wygenerowany PNG (kot + losowy kod) i oczekuje, że model zwróci `cat `. - Referencja implementacji: `src/gateway/gateway-models.profiles.live.test.ts` oraz `src/gateway/live-image-probe.ts`. - Jak włączyć: - `pnpm test:live` (lub `OPENCLAW_LIVE_TEST=1`, jeśli wywołujesz Vitest bezpośrednio) - Jak wybierać modele: - - Domyślnie: nowoczesna allowlista (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - - `OPENCLAW_LIVE_GATEWAY_MODELS=all` to alias dla nowoczesnej allowlisty - - Albo ustaw `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (lub listę rozdzielaną przecinkami), aby zawęzić - - Przeglądy gateway modern/all domyślnie używają kuratorowanego limitu wysokiego sygnału; ustaw `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` dla wyczerpującego przeglądu modern albo dodatnią liczbę dla mniejszego limitu. -- Jak wybierać providerów (aby uniknąć „wszystko przez OpenRouter”): - - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlista rozdzielana przecinkami) -- Sondy narzędzi i obrazu są w tym teście live zawsze włączone: - - sonda `read` + sonda `exec+read` (stres narzędzi) - - sonda obrazu działa, gdy model reklamuje obsługę wejścia obrazowego + - Domyślnie: nowoczesna allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) + - `OPENCLAW_LIVE_GATEWAY_MODELS=all` to alias dla nowoczesnej allowlist + - Albo ustaw `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (lub listę oddzieloną przecinkami), aby zawęzić + - Sweepy gateway modern/all domyślnie używają wyselekcjonowanego limitu wysokiego sygnału; ustaw `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` dla wyczerpującego sweepu modern albo wartość dodatnią dla mniejszego limitu. +- Jak wybierać dostawców (unikaj „wszystko z OpenRouter”): + - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlist oddzielona przecinkami) +- Sondy narzędzi i obrazu są zawsze włączone w tym teście live: + - sonda `read` + sonda `exec+read` (obciążenie narzędzi) + - sonda obrazu działa, gdy model deklaruje obsługę wejścia obrazu - Przepływ (wysoki poziom): - - Test generuje mały PNG z napisem „CAT” + losowym kodem (`src/gateway/live-image-probe.ts`) + - Test generuje mały PNG z „CAT” + losowym kodem (`src/gateway/live-image-probe.ts`) - Wysyła go przez `agent` `attachments: [{ mimeType: "image/png", content: "" }]` - Gateway parsuje załączniki do `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) - - Osadzony agent przekazuje modelowi multimodalną wiadomość użytkownika - - Sprawdzenie: odpowiedź zawiera `cat` + kod (tolerancja OCR: drobne błędy są dopuszczalne) + - Embedded agent przekazuje multimodalną wiadomość użytkownika do modelu + - Asercja: odpowiedź zawiera `cat` + kod (tolerancja OCR: drobne błędy są dozwolone) Wskazówka: aby zobaczyć, co możesz testować na swojej maszynie (i dokładne identyfikatory `provider/model`), uruchom: @@ -533,22 +539,22 @@ openclaw models list --json ## Live: smoke backendu CLI (Claude, Codex, Gemini lub inne lokalne CLI) - Test: `src/gateway/gateway-cli-backend.live.test.ts` -- Cel: zweryfikować pipeline Gateway + agent przy użyciu lokalnego backendu CLI, bez dotykania domyślnej konfiguracji. -- Domyślne ustawienia smoke specyficzne dla backendu znajdują się w definicji `cli-backend.ts` należącej do odpowiedniej extension. +- Cel: zwalidować pipeline Gateway + agent z użyciem lokalnego backendu CLI, bez dotykania domyślnej konfiguracji. +- Domyślne ustawienia smoke specyficzne dla backendu znajdują się w należącej do niego definicji `cli-backend.ts` rozszerzenia. - Włączanie: - `pnpm test:live` (lub `OPENCLAW_LIVE_TEST=1`, jeśli wywołujesz Vitest bezpośrednio) - `OPENCLAW_LIVE_CLI_BACKEND=1` -- Domyślne wartości: - - Domyślny provider/model: `claude-cli/claude-sonnet-4-6` - - Zachowanie command/args/image pochodzi z metadanych Pluginu backendu CLI będącego właścicielem. +- Domyślne ustawienia: + - Domyślny dostawca/model: `claude-cli/claude-sonnet-4-6` + - Zachowanie command/args/image pochodzi z metadanych pluginu właściciela backendu CLI. - Nadpisania (opcjonalne): - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"` - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"` - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'` - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, aby wysłać prawdziwy załącznik obrazu (ścieżki są wstrzykiwane do promptu). - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, aby przekazywać ścieżki plików obrazu jako argumenty CLI zamiast wstrzykiwania ich do promptu. - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (lub `"list"`), aby kontrolować sposób przekazywania argumentów obrazu, gdy ustawione jest `IMAGE_ARG`. - - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, aby wysłać drugą turę i zweryfikować przepływ wznowienia. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, aby wysłać rzeczywisty załącznik obrazu (ścieżki są wstrzykiwane do promptu). + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, aby przekazywać ścieżki plików obrazów jako argumenty CLI zamiast wstrzykiwania do promptu. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (lub `"list"`), aby kontrolować sposób przekazywania argumentów obrazów, gdy ustawiono `IMAGE_ARG`. + - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, aby wysłać drugą turę i zwalidować przepływ wznowienia. - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0`, aby wyłączyć domyślną sondę ciągłości tej samej sesji Claude Sonnet -> Opus (ustaw `1`, aby wymusić jej włączenie, gdy wybrany model obsługuje cel przełączenia). Przykład: @@ -559,13 +565,13 @@ OPENCLAW_LIVE_CLI_BACKEND=1 \ pnpm test:live src/gateway/gateway-cli-backend.live.test.ts ``` -Przepis Docker: +Recepta Docker: ```bash pnpm test:docker:live-cli-backend ``` -Przepisy Docker dla pojedynczego providera: +Recepty Docker dla pojedynczego dostawcy: ```bash pnpm test:docker:live-cli-backend:claude @@ -577,24 +583,24 @@ pnpm test:docker:live-cli-backend:gemini Uwagi: - Runner Docker znajduje się w `scripts/test-live-cli-backend-docker.sh`. -- Uruchamia smoke backendu CLI live wewnątrz obrazu Docker repo jako nie-rootowy użytkownik `node`. -- Rozwiązuje metadane smoke CLI z extension będącej właścicielem, a następnie instaluje pasujący pakiet Linux CLI (`@anthropic-ai/claude-code`, `@openai/codex` lub `@google/gemini-cli`) do zapisywalnego katalogu z cache w `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (domyślnie: `~/.cache/openclaw/docker-cli-tools`). -- `pnpm test:docker:live-cli-backend:claude-subscription` wymaga przenośnego OAuth subskrypcji Claude Code przez `~/.claude/.credentials.json` z `claudeAiOauth.subscriptionType` albo `CLAUDE_CODE_OAUTH_TOKEN` z `claude setup-token`. Najpierw potwierdza bezpośrednie `claude -p` w Dockerze, a następnie uruchamia dwie tury backendu CLI Gateway bez zachowywania zmiennych env klucza Anthropic API. Ta linia subskrypcyjna domyślnie wyłącza sondy Claude MCP/tool i image, ponieważ Claude obecnie kieruje użycie aplikacji firm trzecich przez dodatkowe rozliczanie użycia zamiast zwykłych limitów planu subskrypcji. -- Smoke backendu CLI live testuje teraz ten sam przepływ end-to-end dla Claude, Codex i Gemini: tura tekstowa, tura klasyfikacji obrazu, a następnie wywołanie narzędzia MCP `cron` weryfikowane przez Gateway CLI. -- Domyślny smoke Claude dodatkowo łata sesję z Sonnet do Opus i weryfikuje, że wznowiona sesja nadal pamięta wcześniejszą notatkę. +- Uruchamia smoke live CLI-backend wewnątrz obrazu Docker repo jako nieuprzywilejowany użytkownik `node`. +- Rozwiązuje metadane smoke CLI z rozszerzenia właściciela, a następnie instaluje pasujący pakiet Linux CLI (`@anthropic-ai/claude-code`, `@openai/codex` lub `@google/gemini-cli`) do zapisywalnego prefiksu z cache pod `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (domyślnie: `~/.cache/openclaw/docker-cli-tools`). +- `pnpm test:docker:live-cli-backend:claude-subscription` wymaga przenośnego OAuth subskrypcji Claude Code przez `~/.claude/.credentials.json` z `claudeAiOauth.subscriptionType` albo `CLAUDE_CODE_OAUTH_TOKEN` z `claude setup-token`. Najpierw potwierdza bezpośrednie `claude -p` w Dockerze, a następnie uruchamia dwie tury Gateway CLI-backend bez zachowywania zmiennych env klucza API Anthropic. Ta linia subskrypcji domyślnie wyłącza sondy Claude MCP/tool i image, ponieważ Claude obecnie kieruje użycie aplikacji firm trzecich przez rozliczanie extra-usage zamiast zwykłych limitów planu subskrypcji. +- Smoke live CLI-backend testuje teraz ten sam pełny przepływ end-to-end dla Claude, Codex i Gemini: tura tekstowa, tura klasyfikacji obrazu, a następnie wywołanie narzędzia MCP `cron` zweryfikowane przez gateway CLI. +- Domyślny smoke Claude dodatkowo łata sesję z Sonnet do Opus i sprawdza, czy wznowiona sesja nadal pamięta wcześniejszą notatkę. -## Live: smoke wiązania ACP (`/acp spawn ... --bind here`) +## Live: smoke dowiązania ACP (`/acp spawn ... --bind here`) - Test: `src/gateway/gateway-acp-bind.live.test.ts` -- Cel: zweryfikować rzeczywisty przepływ wiązania konwersacji ACP z żywym agentem ACP: +- Cel: zwalidować rzeczywisty przepływ dowiązania rozmowy ACP z live agentem ACP: - wysłać `/acp spawn --bind here` - - związać syntetyczną konwersację kanału wiadomości w miejscu - - wysłać zwykły follow-up w tej samej konwersacji - - zweryfikować, że follow-up trafia do transkryptu związanej sesji ACP + - dowiązać syntetyczną rozmowę kanału wiadomości w miejscu + - wysłać zwykły follow-up w tej samej rozmowie + - zweryfikować, że follow-up trafia do transkryptu dowiązanej sesji ACP - Włączanie: - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts` - `OPENCLAW_LIVE_ACP_BIND=1` -- Domyślne wartości: +- Domyślne ustawienia: - Agenci ACP w Dockerze: `claude,codex,gemini` - Agent ACP dla bezpośredniego `pnpm test:live ...`: `claude` - Syntetyczny kanał: kontekst rozmowy w stylu Slack DM @@ -607,8 +613,8 @@ Uwagi: - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@'` - `OPENCLAW_LIVE_ACP_BIND_CODEX_MODEL=gpt-5.4` - Uwagi: - - Ta linia używa powierzchni gateway `chat.send` z polami syntetycznej trasy pochodzenia dostępnymi tylko dla administratora, aby testy mogły dołączyć kontekst kanału wiadomości bez udawania zewnętrznego dostarczania. - - Gdy `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` nie jest ustawione, test używa wbudowanego rejestru agentów Pluginu `acpx` dla wybranego agenta harness ACP. + - Ta linia używa powierzchni gateway `chat.send` z polami syntetycznej trasy pochodzenia tylko dla administratora, aby testy mogły dołączyć kontekst kanału wiadomości bez udawania zewnętrznego dostarczenia. + - Gdy `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` nie jest ustawione, test używa wbudowanego rejestru agentów pluginu `acpx` dla wybranego agenta harnessu ACP. Przykład: @@ -618,13 +624,13 @@ OPENCLAW_LIVE_ACP_BIND=1 \ pnpm test:live src/gateway/gateway-acp-bind.live.test.ts ``` -Przepis Docker: +Recepta Docker: ```bash pnpm test:docker:live-acp-bind ``` -Przepisy Docker dla pojedynczych agentów: +Recepty Docker dla pojedynczego agenta: ```bash pnpm test:docker:live-acp-bind:claude @@ -635,23 +641,24 @@ pnpm test:docker:live-acp-bind:gemini Uwagi dotyczące Dockera: - Runner Docker znajduje się w `scripts/test-live-acp-bind-docker.sh`. -- Domyślnie uruchamia smoke ACP bind względem wszystkich obsługiwanych żywych agentów CLI po kolei: `claude`, `codex`, potem `gemini`. -- Użyj `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` albo `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini`, aby zawęzić macierz. -- Pobiera `~/.profile`, przygotowuje pasujący materiał auth CLI do kontenera, instaluje `acpx` do zapisywalnego prefiksu npm, a następnie instaluje żądane CLI live (`@anthropic-ai/claude-code`, `@openai/codex` albo `@google/gemini-cli`), jeśli go brakuje. -- Wewnątrz Dockera runner ustawia `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, dzięki czemu acpx zachowuje zmienne env providera z pobranego profilu dostępne dla podrzędnego harness CLI. +- Domyślnie uruchamia smoke ACP bind kolejno dla wszystkich obsługiwanych live agentów CLI: `claude`, `codex`, a następnie `gemini`. +- Użyj `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` lub `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini`, aby zawęzić macierz. +- Pobiera `~/.profile`, przygotowuje pasujący materiał uwierzytelniania CLI w kontenerze, instaluje `acpx` do zapisywalnego prefiksu npm, a następnie instaluje wymagane live CLI (`@anthropic-ai/claude-code`, `@openai/codex` lub `@google/gemini-cli`), jeśli go brakuje. +- Wewnątrz Dockera runner ustawia `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, aby acpx zachował zmienne env dostawcy z pobranego profilu dostępne dla podrzędnego harnessu CLI. -## Live: smoke harnessu app-server Codex +## Live: smoke harnessu Codex app-server -- Cel: zweryfikować należący do Pluginu harness Codex przez zwykłą metodę gateway - `agent`: - - załadować dołączony Plugin `codex` +- Cel: zwalidować należący do pluginu harness Codex przez zwykłą metodę + gateway `agent`: + - załadować bundlowany plugin `codex` - wybrać `OPENCLAW_AGENT_RUNTIME=codex` - wysłać pierwszą turę gateway agent do `codex/gpt-5.4` - wysłać drugą turę do tej samej sesji OpenClaw i zweryfikować, że wątek app-server może zostać wznowiony - - uruchomić `/codex status` i `/codex models` przez tę samą ścieżkę poleceń gateway - - opcjonalnie uruchomić dwie eskalowane sondy shell przeglądane przez Guardian: jedno nieszkodliwe - polecenie, które powinno zostać zatwierdzone, i jedno fałszywe przesłanie sekretu, + - uruchomić `/codex status` i `/codex models` przez tę samą ścieżkę + poleceń gateway + - opcjonalnie uruchomić dwie sondy powłoki eskalowane po przeglądzie Guardian: jedno nieszkodliwe + polecenie, które powinno zostać zatwierdzone, oraz jedno fałszywe wysłanie sekretu, które powinno zostać odrzucone, aby agent dopytał - Test: `src/gateway/gateway-codex-harness.live.test.ts` - Włączanie: `OPENCLAW_LIVE_CODEX_HARNESS=1` @@ -659,12 +666,12 @@ Uwagi dotyczące Dockera: - Opcjonalna sonda obrazu: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` - Opcjonalna sonda MCP/tool: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` - Opcjonalna sonda Guardian: `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1` -- Smoke ustawia `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, aby uszkodzony harness Codex - nie mógł przejść przez cichy fallback do PI. +- Smoke ustawia `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, aby zepsuty harness Codex + nie mógł przejść przez ciche fallback do PI. - Auth: `OPENAI_API_KEY` z powłoki/profilu oraz opcjonalnie skopiowane `~/.codex/auth.json` i `~/.codex/config.toml` -Lokalny przepis: +Lokalna recepta: ```bash source ~/.profile @@ -676,7 +683,7 @@ OPENCLAW_LIVE_CODEX_HARNESS=1 \ pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts ``` -Przepis Docker: +Recepta Docker: ```bash source ~/.profile @@ -686,20 +693,21 @@ pnpm test:docker:live-codex-harness Uwagi dotyczące Dockera: - Runner Docker znajduje się w `scripts/test-live-codex-harness-docker.sh`. -- Pobiera zamontowane `~/.profile`, przekazuje `OPENAI_API_KEY`, kopiuje pliki - auth CLI Codex, gdy są obecne, instaluje `@openai/codex` do zapisywalnego montowanego prefiksu npm, - przygotowuje drzewo źródeł, a następnie uruchamia tylko test live Codex-harness. +- Pobiera zamontowane `~/.profile`, przekazuje `OPENAI_API_KEY`, kopiuje pliki auth CLI Codex, + jeśli są obecne, instaluje `@openai/codex` do zapisywalnego zamontowanego prefiksu npm, + przygotowuje drzewo źródeł, a następnie uruchamia tylko live test harnessu Codex. - Docker domyślnie włącza sondy obrazu, MCP/tool i Guardian. Ustaw - `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` albo + `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` lub `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` albo - `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0`, gdy potrzebujesz węższego uruchomienia debugowego. -- Docker eksportuje również `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, zgodnie z konfiguracją - testu live, dzięki czemu fallback `openai-codex/*` albo PI nie może ukryć regresji + `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0`, gdy potrzebujesz węższego uruchomienia + debugowego. +- Docker eksportuje też `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, zgodnie z konfiguracją + live testu, aby fallback `openai-codex/*` lub PI nie mógł ukryć regresji harnessu Codex. -### Zalecane przepisy live +### Zalecane recepty live -Wąskie, jawne allowlisty są najszybsze i najmniej podatne na flaky zachowanie: +Wąskie, jawne allowlist są najszybsze i najmniej podatne na niestabilność: - Pojedynczy model, bezpośrednio (bez gateway): - `OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts` @@ -707,31 +715,31 @@ Wąskie, jawne allowlisty są najszybsze i najmniej podatne na flaky zachowanie: - Pojedynczy model, smoke gateway: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Wywoływanie narzędzi przez kilku providerów: +- Wywoływanie narzędzi przez kilku dostawców: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Skupienie na Google (klucz Gemini API + Antigravity): +- Skupienie na Google (klucz API Gemini + Antigravity): - Gemini (klucz API): `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Antigravity (OAuth): `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` Uwagi: - `google/...` używa Gemini API (klucz API). -- `google-antigravity/...` używa mostka OAuth Antigravity (endpoint agenta w stylu Cloud Code Assist). -- `google-gemini-cli/...` używa lokalnego Gemini CLI na Twojej maszynie (oddzielne auth + specyficzne zachowanie narzędzi). +- `google-antigravity/...` używa mostu OAuth Antigravity (endpoint agenta w stylu Cloud Code Assist). +- `google-gemini-cli/...` używa lokalnego Gemini CLI na Twojej maszynie (osobne auth + osobliwości narzędziowe). - Gemini API vs Gemini CLI: - - API: OpenClaw wywołuje hostowane Gemini API Google przez HTTP (klucz API / auth profilu); to właśnie większość użytkowników ma na myśli, mówiąc „Gemini”. - - CLI: OpenClaw wykonuje lokalne binarium `gemini`; ma własne auth i może zachowywać się inaczej (streaming/obsługa narzędzi/rozbieżność wersji). + - API: OpenClaw wywołuje hostowane Gemini API Google przez HTTP (auth przez klucz API / profil); to właśnie większość użytkowników ma na myśli, mówiąc „Gemini”. + - CLI: OpenClaw wywołuje lokalny binarny plik `gemini`; ma własne auth i może zachowywać się inaczej (streaming/obsługa narzędzi/rozjazd wersji). ## Live: macierz modeli (co obejmujemy) -Nie ma stałej „listy modeli CI” (live jest opt-in), ale to są **zalecane** modele do regularnego pokrywania na maszynie developerskiej z kluczami. +Nie ma stałej „listy modeli CI” (live jest opt-in), ale to są **zalecane** modele do regularnego pokrywania na maszynie deweloperskiej z kluczami. -### Nowoczesny zestaw smoke (wywoływanie narzędzi + obraz) +### Zestaw nowoczesnego smoke (wywoływanie narzędzi + obraz) -To jest przebieg „typowych modeli”, który oczekujemy utrzymywać działający: +To jest uruchomienie „wspólnych modeli”, które oczekujemy utrzymać w działaniu: -- OpenAI (nie-Codex): `openai/gpt-5.4` (opcjonalnie: `openai/gpt-5.4-mini`) +- OpenAI (bez Codex): `openai/gpt-5.4` (opcjonalnie: `openai/gpt-5.4-mini`) - OpenAI Codex: `openai-codex/gpt-5.4` - Anthropic: `anthropic/claude-opus-4-6` (lub `anthropic/claude-sonnet-4-6`) - Google (Gemini API): `google/gemini-3.1-pro-preview` oraz `google/gemini-3-flash-preview` (unikaj starszych modeli Gemini 2.x) @@ -742,9 +750,9 @@ To jest przebieg „typowych modeli”, który oczekujemy utrzymywać działają Uruchom smoke gateway z narzędziami + obrazem: `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,openai-codex/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -### Baza: wywoływanie narzędzi (Read + opcjonalnie Exec) +### Bazowy zestaw: wywoływanie narzędzi (Read + opcjonalnie Exec) -Wybierz co najmniej jeden model z każdej rodziny providerów: +Wybierz przynajmniej jeden na rodzinę dostawców: - OpenAI: `openai/gpt-5.4` (lub `openai/gpt-5.4-mini`) - Anthropic: `anthropic/claude-opus-4-6` (lub `anthropic/claude-sonnet-4-6`) @@ -755,78 +763,78 @@ Wybierz co najmniej jeden model z każdej rodziny providerów: Opcjonalne dodatkowe pokrycie (mile widziane): - xAI: `xai/grok-4` (lub najnowszy dostępny) -- Mistral: `mistral/`… (wybierz jeden model zdolny do pracy z narzędziami, który masz włączony) +- Mistral: `mistral/`… (wybierz jeden model z obsługą „tools”, który masz włączony) - Cerebras: `cerebras/`… (jeśli masz dostęp) -- LM Studio: `lmstudio/`… (lokalnie; wywoływanie narzędzi zależy od trybu API) +- LM Studio: `lmstudio/`… (lokalne; wywoływanie narzędzi zależy od trybu API) ### Vision: wysyłanie obrazu (załącznik → wiadomość multimodalna) -Uwzględnij co najmniej jeden model zdolny do pracy z obrazem w `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/warianty OpenAI obsługujące vision itd.), aby przetestować sondę obrazu. +Uwzględnij co najmniej jeden model z obsługą obrazu w `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/warianty OpenAI obsługujące vision itd.), aby przetestować sondę obrazu. -### Agregatory / alternatywne gatewaye +### Agregatory / alternatywne gateway -Jeśli masz włączone klucze, obsługujemy również testowanie przez: +Jeśli masz włączone klucze, obsługujemy też testowanie przez: -- OpenRouter: `openrouter/...` (setki modeli; użyj `openclaw models scan`, aby znaleźć kandydatów zdolnych do narzędzi+obrazu) -- OpenCode: `opencode/...` dla Zen i `opencode-go/...` dla Go (auth przez `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) +- OpenRouter: `openrouter/...` (setki modeli; użyj `openclaw models scan`, aby znaleźć kandydatów z obsługą narzędzi+obrazu) +- OpenCode: `opencode/...` dla Zen oraz `opencode-go/...` dla Go (auth przez `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) -Więcej providerów, które możesz uwzględnić w macierzy live (jeśli masz poświadczenia/konfigurację): +Więcej dostawców, których możesz uwzględnić w macierzy live (jeśli masz creds/config): - Wbudowani: `openai`, `openai-codex`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot` -- Przez `models.providers` (niestandardowe endpointy): `minimax` (cloud/API) oraz dowolny proxy zgodny z OpenAI/Anthropic (LM Studio, vLLM, LiteLLM itd.) +- Przez `models.providers` (własne endpointy): `minimax` (cloud/API) oraz dowolny proxy zgodny z OpenAI/Anthropic (LM Studio, vLLM, LiteLLM itd.) -Wskazówka: nie próbuj na sztywno wpisywać do dokumentacji „wszystkich modeli”. Autorytatywna lista to to, co zwraca `discoverModels(...)` na Twojej maszynie + jakie klucze są dostępne. +Wskazówka: nie próbuj kodować na sztywno „wszystkich modeli” w dokumentacji. Autorytatywną listą jest to, co zwraca `discoverModels(...)` na Twojej maszynie + jakie klucze są dostępne. ## Poświadczenia (nigdy nie commituj) -Testy live wykrywają poświadczenia tak samo jak CLI. Praktyczne konsekwencje: +Testy live wykrywają poświadczenia w taki sam sposób jak CLI. Praktyczne konsekwencje: - Jeśli CLI działa, testy live powinny znaleźć te same klucze. -- Jeśli test live mówi „brak poświadczeń”, debuguj to tak samo, jak debugowałbyś `openclaw models list` / wybór modelu. +- Jeśli test live mówi „brak creds”, debuguj to tak samo, jak debugowałbyś `openclaw models list` / wybór modelu. -- Profile auth per agent: `~/.openclaw/agents//agent/auth-profiles.json` (to właśnie oznaczają „klucze profilowe” w testach live) +- Profile auth per agent: `~/.openclaw/agents//agent/auth-profiles.json` (to właśnie oznaczają „profile keys” w testach live) - Konfiguracja: `~/.openclaw/openclaw.json` (lub `OPENCLAW_CONFIG_PATH`) -- Starszy katalog stanu: `~/.openclaw/credentials/` (kopiowany do przygotowanego katalogu domowego live, gdy jest obecny, ale nie jest głównym magazynem kluczy profilowych) -- Lokalne uruchomienia live domyślnie kopiują aktywną konfigurację, pliki `auth-profiles.json` per agent, starsze `credentials/` oraz obsługiwane zewnętrzne katalogi auth CLI do tymczasowego katalogu domowego testów; przygotowane katalogi domowe live pomijają `workspace/` i `sandboxes/`, a nadpisania ścieżek `agents.*.workspace` / `agentDir` są usuwane, aby sondy pozostawały poza Twoim prawdziwym workspace hosta. +- Starszy katalog stanu: `~/.openclaw/credentials/` (kopiowany do przygotowanego katalogu domowego live, jeśli istnieje, ale nie jest głównym store kluczy profili) +- Lokalne uruchomienia live domyślnie kopiują aktywną konfigurację, pliki `auth-profiles.json` per agent, starsze `credentials/` oraz obsługiwane zewnętrzne katalogi auth CLI do tymczasowego katalogu domowego testu; przygotowane katalogi domowe live pomijają `workspace/` i `sandboxes/`, a nadpisania ścieżek `agents.*.workspace` / `agentDir` są usuwane, aby sondy nie działały w Twoim rzeczywistym workspace hosta. -Jeśli chcesz polegać na kluczach env (np. wyeksportowanych w `~/.profile`), uruchamiaj lokalne testy po `source ~/.profile`, albo użyj runnerów Docker poniżej (mogą montować `~/.profile` do kontenera). +Jeśli chcesz polegać na kluczach env (np. eksportowanych w `~/.profile`), uruchamiaj testy lokalne po `source ~/.profile` albo użyj runnerów Docker poniżej (mogą montować `~/.profile` do kontenera). -## Deepgram live (transkrypcja audio) +## Live Deepgram (transkrypcja audio) - Test: `extensions/deepgram/audio.live.test.ts` - Włączanie: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live extensions/deepgram/audio.live.test.ts` -## BytePlus coding plan live +## Live BytePlus coding plan - Test: `extensions/byteplus/live.test.ts` - Włączanie: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live extensions/byteplus/live.test.ts` - Opcjonalne nadpisanie modelu: `BYTEPLUS_CODING_MODEL=ark-code-latest` -## ComfyUI workflow media live +## Live mediów workflow ComfyUI - Test: `extensions/comfy/comfy.live.test.ts` - Włączanie: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` - Zakres: - - Testuje dołączone ścieżki comfy dla obrazów, wideo i `music_generate` - - Pomija każdą możliwość, chyba że skonfigurowano `models.providers.comfy.` - - Przydatne po zmianach w wysyłaniu workflow comfy, pollingu, pobieraniu albo rejestracji Pluginu + - Testuje bundlowane ścieżki comfy image, video i `music_generate` + - Pomija każdą możliwość, jeśli `models.providers.comfy.` nie jest skonfigurowane + - Przydatne po zmianie wysyłania workflow comfy, odpytywania, pobierania lub rejestracji pluginu -## Image generation live +## Live generowania obrazów - Test: `test/image-generation.runtime.live.test.ts` - Polecenie: `pnpm test:live test/image-generation.runtime.live.test.ts` - Harness: `pnpm test:live:media image` - Zakres: - - Wylicza każdy zarejestrowany Plugin providera generowania obrazów - - Ładuje brakujące zmienne env providera z Twojej powłoki logowania (`~/.profile`) przed sondowaniem - - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, dzięki czemu nieaktualne klucze testowe w `auth-profiles.json` nie maskują prawdziwych poświadczeń z powłoki - - Pomija providerów bez użytecznego auth/profilu/modelu + - Wylicza każdy zarejestrowany plugin dostawcy generowania obrazów + - Ładuje brakujące zmienne env dostawców z powłoki logowania (`~/.profile`) przed sondowaniem + - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń powłoki + - Pomija dostawców bez używalnego auth/profilu/modelu - Uruchamia standardowe warianty generowania obrazów przez współdzieloną możliwość runtime: - `google:flash-generate` - `google:pro-generate` - `google:pro-edit` - `openai:default-generate` -- Aktualnie objęci dołączeni providerzy: +- Aktualnie objęci bundlowani dostawcy: - `fal` - `google` - `minimax` @@ -838,172 +846,172 @@ Jeśli chcesz polegać na kluczach env (np. wyeksportowanych w `~/.profile`), ur - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-2,google/gemini-3.1-flash-image-preview,xai/grok-imagine-image"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit,xai:default-generate,xai:default-edit"` - Opcjonalne zachowanie auth: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić auth z magazynu profili i ignorować nadpisania tylko z env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić auth ze store profili i ignorować nadpisania wyłącznie z env -## Music generation live +## Live generowania muzyki - Test: `extensions/music-generation-providers.live.test.ts` - Włączanie: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` - Harness: `pnpm test:live:media music` - Zakres: - - Testuje współdzieloną dołączoną ścieżkę providera generowania muzyki + - Testuje współdzieloną bundlowaną ścieżkę dostawców generowania muzyki - Obecnie obejmuje Google i MiniMax - - Ładuje zmienne env providera z Twojej powłoki logowania (`~/.profile`) przed sondowaniem - - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, dzięki czemu nieaktualne klucze testowe w `auth-profiles.json` nie maskują prawdziwych poświadczeń z powłoki - - Pomija providerów bez użytecznego auth/profilu/modelu + - Ładuje zmienne env dostawców z powłoki logowania (`~/.profile`) przed sondowaniem + - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń powłoki + - Pomija dostawców bez używalnego auth/profilu/modelu - Uruchamia oba zadeklarowane tryby runtime, gdy są dostępne: - - `generate` z wejściem tylko prompt - - `edit`, gdy provider deklaruje `capabilities.edit.enabled` + - `generate` z wejściem opartym wyłącznie na prompt + - `edit`, gdy dostawca deklaruje `capabilities.edit.enabled` - Aktualne pokrycie współdzielonej linii: - `google`: `generate`, `edit` - `minimax`: `generate` - - `comfy`: osobny plik live Comfy, nie ten współdzielony przegląd + - `comfy`: osobny plik live Comfy, nie ten współdzielony sweep - Opcjonalne zawężanie: - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"` - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"` - Opcjonalne zachowanie auth: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić auth z magazynu profili i ignorować nadpisania tylko z env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić auth ze store profili i ignorować nadpisania wyłącznie z env -## Video generation live +## Live generowania wideo - Test: `extensions/video-generation-providers.live.test.ts` - Włączanie: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` - Harness: `pnpm test:live:media video` - Zakres: - - Testuje współdzieloną dołączoną ścieżkę providera generowania wideo - - Domyślnie używa bezpiecznej dla wydań ścieżki smoke: providery inne niż FAL, jedno żądanie text-to-video na providera, jednosekundowy prompt z homarem oraz limit operacji per provider z `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` domyślnie) - - Domyślnie pomija FAL, ponieważ opóźnienie kolejki po stronie providera może zdominować czas wydania; przekaż `--video-providers fal` albo `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"`, aby uruchomić go jawnie - - Ładuje zmienne env providera z Twojej powłoki logowania (`~/.profile`) przed sondowaniem - - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, dzięki czemu nieaktualne klucze testowe w `auth-profiles.json` nie maskują prawdziwych poświadczeń z powłoki - - Pomija providerów bez użytecznego auth/profilu/modelu + - Testuje współdzieloną bundlowaną ścieżkę dostawców generowania wideo + - Domyślnie używa bezpiecznej dla wydania ścieżki smoke: dostawcy bez FAL, jedno żądanie text-to-video na dostawcę, jednosekundowy prompt z homarem oraz limit operacji per dostawca z `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (domyślnie `180000`) + - Domyślnie pomija FAL, ponieważ opóźnienie kolejki po stronie dostawcy może dominować czas wydania; przekaż `--video-providers fal` lub `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"`, aby uruchomić go jawnie + - Ładuje zmienne env dostawców z powłoki logowania (`~/.profile`) przed sondowaniem + - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń powłoki + - Pomija dostawców bez używalnego auth/profilu/modelu - Domyślnie uruchamia tylko `generate` - - Ustaw `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1`, aby uruchomić także zadeklarowane tryby transformacji, gdy są dostępne: - - `imageToVideo`, gdy provider deklaruje `capabilities.imageToVideo.enabled` i wybrany provider/model akceptuje wejście lokalnego obrazu oparte na buforze we współdzielonym przeglądzie - - `videoToVideo`, gdy provider deklaruje `capabilities.videoToVideo.enabled` i wybrany provider/model akceptuje wejście lokalnego wideo oparte na buforze we współdzielonym przeglądzie - - Aktualni dostawcy `imageToVideo` zadeklarowani, ale pomijani we współdzielonym przeglądzie: - - `vydra`, ponieważ dołączony `veo3` obsługuje tylko tekst, a dołączony `kling` wymaga zdalnego URL obrazu - - Pokrycie Vydra specyficzne dla providera: + - Ustaw `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1`, aby uruchamiać również zadeklarowane tryby transformacji, gdy są dostępne: + - `imageToVideo`, gdy dostawca deklaruje `capabilities.imageToVideo.enabled`, a wybrany dostawca/model akceptuje lokalne wejście obrazu oparte na buforze we współdzielonym sweepie + - `videoToVideo`, gdy dostawca deklaruje `capabilities.videoToVideo.enabled`, a wybrany dostawca/model akceptuje lokalne wejście wideo oparte na buforze we współdzielonym sweepie + - Obecni dostawcy `imageToVideo` zadeklarowani, ale pomijani we współdzielonym sweepie: + - `vydra`, ponieważ bundlowany `veo3` jest tylko tekstowy, a bundlowany `kling` wymaga zdalnego adresu URL obrazu + - Pokrycie specyficzne dla dostawcy Vydra: - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts` - ten plik uruchamia `veo3` text-to-video oraz linię `kling`, która domyślnie używa fixture zdalnego URL obrazu - Aktualne pokrycie live `videoToVideo`: - tylko `runway`, gdy wybrany model to `runway/gen4_aleph` - - Aktualni dostawcy `videoToVideo` zadeklarowani, ale pomijani we współdzielonym przeglądzie: - - `alibaba`, `qwen`, `xai`, ponieważ te ścieżki obecnie wymagają zdalnych referencyjnych URL `http(s)` / MP4 - - `google`, ponieważ bieżąca współdzielona linia Gemini/Veo używa lokalnego wejścia opartego na buforze, a ta ścieżka nie jest akceptowana we współdzielonym przeglądzie - - `openai`, ponieważ bieżąca współdzielona linia nie gwarantuje dostępu do organizacyjnie specyficznych funkcji video inpaint/remix + - Obecni dostawcy `videoToVideo` zadeklarowani, ale pomijani we współdzielonym sweepie: + - `alibaba`, `qwen`, `xai`, ponieważ te ścieżki obecnie wymagają referencyjnych URL `http(s)` / MP4 + - `google`, ponieważ bieżąca współdzielona linia Gemini/Veo używa lokalnego wejścia opartego na buforze i ta ścieżka nie jest akceptowana we współdzielonym sweepie + - `openai`, ponieważ bieżąca współdzielona linia nie gwarantuje dostępu do org-specyficznego video inpaint/remix - Opcjonalne zawężanie: - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="google,openai,runway"` - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"` - - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""`, aby uwzględnić każdego providera w domyślnym przeglądzie, w tym FAL - - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000`, aby zmniejszyć limit operacji dla każdego providera na potrzeby agresywnego przebiegu smoke + - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""`, aby uwzględnić każdego dostawcę w domyślnym sweepie, w tym FAL + - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000`, aby zmniejszyć limit operacji każdego dostawcy dla agresywnego uruchomienia smoke - Opcjonalne zachowanie auth: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić auth z magazynu profili i ignorować nadpisania tylko z env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić auth ze store profili i ignorować nadpisania wyłącznie z env -## Harness media live +## Harness live mediów - Polecenie: `pnpm test:live:media` - Cel: - - Uruchamia współdzielone zestawy image, music i video live przez jeden natywny dla repo entrypoint - - Automatycznie ładuje brakujące zmienne env providera z `~/.profile` - - Domyślnie automatycznie zawęża każdy zestaw do providerów, które obecnie mają użyteczne auth - - Ponownie używa `scripts/test-live.mjs`, dzięki czemu zachowanie Heartbeat i quiet-mode pozostaje spójne + - Uruchamia współdzielone pakiety live dla obrazów, muzyki i wideo przez jeden natywny dla repo entrypoint + - Automatycznie ładuje brakujące zmienne env dostawców z `~/.profile` + - Domyślnie automatycznie zawęża każdy pakiet do dostawców, którzy aktualnie mają używalne auth + - Ponownie wykorzystuje `scripts/test-live.mjs`, więc heartbeat i zachowanie trybu quiet pozostają spójne - Przykłady: - `pnpm test:live:media` - `pnpm test:live:media image video --providers openai,google,minimax` - `pnpm test:live:media video --video-providers openai,runway --all-providers` - `pnpm test:live:media music --quiet` -## Runnery Docker (opcjonalne kontrole typu „działa w Linuxie”) +## Runnery Docker (opcjonalne kontrole „działa w Linuxie”) Te runnery Docker dzielą się na dwa koszyki: -- Runnery modeli live: `test:docker:live-models` i `test:docker:live-gateway` uruchamiają tylko odpowiadający im plik live z kluczami profilowymi wewnątrz obrazu Docker repo (`src/agents/models.profiles.live.test.ts` i `src/gateway/gateway-models.profiles.live.test.ts`), montując lokalny katalog konfiguracyjny i workspace (oraz pobierając `~/.profile`, jeśli jest zamontowany). Odpowiadające lokalne entrypointy to `test:live:models-profiles` i `test:live:gateway-profiles`. -- Runnery Docker live domyślnie używają mniejszego limitu smoke, aby pełny przegląd Docker pozostawał praktyczny: - `test:docker:live-models` domyślnie ustawia `OPENCLAW_LIVE_MAX_MODELS=12`, a - `test:docker:live-gateway` domyślnie ustawia `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, +- Runnery live modeli: `test:docker:live-models` i `test:docker:live-gateway` uruchamiają tylko pasujący plik live z kluczami profili wewnątrz obrazu Docker repo (`src/agents/models.profiles.live.test.ts` i `src/gateway/gateway-models.profiles.live.test.ts`), montując lokalny katalog config i workspace (oraz pobierając `~/.profile`, jeśli jest zamontowany). Pasujące lokalne entrypointy to `test:live:models-profiles` i `test:live:gateway-profiles`. +- Runnery Docker live domyślnie używają mniejszego limitu smoke, aby pełny sweep Docker pozostawał praktyczny: + `test:docker:live-models` domyślnie używa `OPENCLAW_LIVE_MAX_MODELS=12`, a + `test:docker:live-gateway` domyślnie używa `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` oraz `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Nadpisz te zmienne env, gdy jawnie chcesz większego, wyczerpującego skanu. -- `test:docker:all` buduje obraz Docker live raz przez `test:docker:live-build`, a następnie ponownie go używa dla dwóch linii live Docker. Buduje też jeden współdzielony obraz `scripts/e2e/Dockerfile` przez `test:docker:e2e-build` i używa go ponownie dla runnerów smoke kontenerów E2E, które testują zbudowaną aplikację. -- Runnery smoke kontenerów: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:gateway-network`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` oraz `test:docker:config-reload` uruchamiają jeden lub więcej prawdziwych kontenerów i weryfikują wyższe ścieżki integracyjne. +- `test:docker:all` buduje obraz live Docker raz przez `test:docker:live-build`, a następnie ponownie go używa dla dwóch linii Docker live. Buduje też jeden współdzielony obraz `scripts/e2e/Dockerfile` przez `test:docker:e2e-build` i ponownie go używa dla runnerów smoke kontenerów E2E, które testują zbudowaną aplikację. +- Runnery smoke kontenerów: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:gateway-network`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` oraz `test:docker:config-reload` uruchamiają jeden lub więcej rzeczywistych kontenerów i weryfikują ścieżki integracji wyższego poziomu. -Runnery Docker modeli live dodatkowo bind-mountują tylko potrzebne katalogi domowe auth CLI (albo wszystkie obsługiwane, gdy przebieg nie jest zawężony), a następnie kopiują je do katalogu domowego kontenera przed uruchomieniem, aby zewnętrzny OAuth CLI mógł odświeżać tokeny bez modyfikowania magazynu auth hosta: +Runnery Docker live modeli montują też tylko potrzebne katalogi auth CLI (lub wszystkie obsługiwane, gdy uruchomienie nie jest zawężone), a następnie kopiują je do katalogu domowego kontenera przed uruchomieniem, aby zewnętrzne OAuth CLI mogło odświeżać tokeny bez modyfikowania store auth hosta: -- Modele bezpośrednie: `pnpm test:docker:live-models` (skrypt: `scripts/test-live-models-docker.sh`) +- Bezpośrednie modele: `pnpm test:docker:live-models` (skrypt: `scripts/test-live-models-docker.sh`) - Smoke ACP bind: `pnpm test:docker:live-acp-bind` (skrypt: `scripts/test-live-acp-bind-docker.sh`) - Smoke backendu CLI: `pnpm test:docker:live-cli-backend` (skrypt: `scripts/test-live-cli-backend-docker.sh`) -- Smoke harnessu app-server Codex: `pnpm test:docker:live-codex-harness` (skrypt: `scripts/test-live-codex-harness-docker.sh`) +- Smoke harnessu Codex app-server: `pnpm test:docker:live-codex-harness` (skrypt: `scripts/test-live-codex-harness-docker.sh`) - Gateway + agent dev: `pnpm test:docker:live-gateway` (skrypt: `scripts/test-live-gateway-models-docker.sh`) -- Smoke Open WebUI live: `pnpm test:docker:openwebui` (skrypt: `scripts/e2e/openwebui-docker.sh`) +- Live smoke Open WebUI: `pnpm test:docker:openwebui` (skrypt: `scripts/e2e/openwebui-docker.sh`) - Kreator onboardingu (TTY, pełne scaffoldowanie): `pnpm test:docker:onboard` (skrypt: `scripts/e2e/onboard-docker.sh`) -- Smoke onboardingu/kanału/agenta z archiwum npm: `pnpm test:docker:npm-onboard-channel-agent` instaluje spakowane archiwum OpenClaw globalnie w Dockerze, konfiguruje OpenAI przez onboarding z odwołaniem do env oraz domyślnie Telegram, weryfikuje, że włączenie Pluginu instaluje jego zależności runtime na żądanie, uruchamia doctor i uruchamia jedną mockowaną turę agenta OpenAI. Użyj ponownie wstępnie zbudowanego archiwum przez `OPENCLAW_NPM_ONBOARD_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, pomiń przebudowę hosta przez `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` albo przełącz kanał przez `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Sieć Gateway (dwa kontenery, auth WS + health): `pnpm test:docker:gateway-network` (skrypt: `scripts/e2e/gateway-network-docker.sh`) -- Minimalna regresja rozumowania OpenAI Responses web_search: `pnpm test:docker:openai-web-search-minimal` (skrypt: `scripts/e2e/openai-web-search-minimal-docker.sh`) uruchamia mockowany serwer OpenAI przez Gateway, weryfikuje, że `web_search` podnosi `reasoning.effort` z `minimal` do `low`, a następnie wymusza odrzucenie schematu providera i sprawdza, że surowy szczegół pojawia się w logach Gateway. -- Most kanału MCP (zainicjalizowany Gateway + most stdio + smoke surowej ramki powiadomień Claude): `pnpm test:docker:mcp-channels` (skrypt: `scripts/e2e/mcp-channels-docker.sh`) -- Narzędzia Pi bundle MCP (prawdziwy serwer MCP stdio + smoke allow/deny osadzonego profilu Pi): `pnpm test:docker:pi-bundle-mcp-tools` (skrypt: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Cleanup MCP Cron/podagenta (prawdziwy Gateway + teardown podrzędnego MCP stdio po izolowanych przebiegach Cron i jednorazowego podagenta): `pnpm test:docker:cron-mcp-cleanup` (skrypt: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (install smoke + alias `/plugin` + semantyka restartu pakietu Claude): `pnpm test:docker:plugins` (skrypt: `scripts/e2e/plugins-docker.sh`) -- Smoke niezmienionej aktualizacji Pluginu: `pnpm test:docker:plugin-update` (skrypt: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Smoke metadanych reloadu konfiguracji: `pnpm test:docker:config-reload` (skrypt: `scripts/e2e/config-reload-source-docker.sh`) -- Zależności runtime dołączonych Pluginów: `pnpm test:docker:bundled-channel-deps` domyślnie buduje mały obraz runnera Docker, buduje i pakuje OpenClaw raz na hoście, a następnie montuje to archiwum w każdym scenariuszu instalacji Linux. Użyj ponownie obrazu przez `OPENCLAW_SKIP_DOCKER_BUILD=1`, pomiń przebudowę hosta po świeżym lokalnym buildzie przez `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0`, albo wskaż istniejące archiwum przez `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. -- Podczas iteracji zawęż zależności runtime dołączonych Pluginów, wyłączając niezwiązane scenariusze, na przykład: +- Smoke onboardingu/kanału/agenta z tarballem npm: `pnpm test:docker:npm-onboard-channel-agent` instaluje spakowany tarball OpenClaw globalnie w Dockerze, konfiguruje OpenAI przez onboarding env-ref oraz domyślnie Telegram, weryfikuje, że włączenie pluginu instaluje zależności uruchomieniowe na żądanie, uruchamia doctor i wykonuje jedną mockowaną turę agenta OpenAI. Użyj ponownie wstępnie zbudowanego tarballa przez `OPENCLAW_NPM_ONBOARD_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, pomiń przebudowę hosta przez `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` albo przełącz kanał przez `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Sieć gateway (dwa kontenery, auth WS + health): `pnpm test:docker:gateway-network` (skrypt: `scripts/e2e/gateway-network-docker.sh`) +- Minimalna regresja reasoning OpenAI Responses `web_search`: `pnpm test:docker:openai-web-search-minimal` (skrypt: `scripts/e2e/openai-web-search-minimal-docker.sh`) uruchamia mockowany serwer OpenAI przez Gateway, weryfikuje, że `web_search` podnosi `reasoning.effort` z `minimal` do `low`, a następnie wymusza odrzucenie przez schemat dostawcy i sprawdza, że surowy szczegół pojawia się w logach Gateway. +- Most kanału MCP (seedowany Gateway + most stdio + surowy smoke klatki powiadomień Claude): `pnpm test:docker:mcp-channels` (skrypt: `scripts/e2e/mcp-channels-docker.sh`) +- Narzędzia MCP pakietu Pi (rzeczywisty serwer stdio MCP + smoke allow/deny osadzonego profilu Pi): `pnpm test:docker:pi-bundle-mcp-tools` (skrypt: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Czyszczenie MCP Cron/subagent (rzeczywisty Gateway + teardown potomka stdio MCP po odizolowanych uruchomieniach cron i jednorazowego subagenta): `pnpm test:docker:cron-mcp-cleanup` (skrypt: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Pluginy (smoke instalacji + alias `/plugin` + semantyka restartu pakietu Claude): `pnpm test:docker:plugins` (skrypt: `scripts/e2e/plugins-docker.sh`) +- Smoke niezmienionej aktualizacji pluginu: `pnpm test:docker:plugin-update` (skrypt: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Smoke metadanych reloadu config: `pnpm test:docker:config-reload` (skrypt: `scripts/e2e/config-reload-source-docker.sh`) +- Zależności uruchomieniowe bundlowanych pluginów: `pnpm test:docker:bundled-channel-deps` domyślnie buduje mały obraz runnera Docker, raz buduje i pakuje OpenClaw na hoście, a następnie montuje ten tarball w każdym scenariuszu instalacji Linux. Użyj ponownie obrazu przez `OPENCLAW_SKIP_DOCKER_BUILD=1`, pomiń przebudowę hosta po świeżym lokalnym buildzie przez `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` albo wskaż istniejący tarball przez `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. +- Zawężaj zależności uruchomieniowe bundlowanych pluginów podczas iteracji, wyłączając niezwiązane scenariusze, na przykład: `OPENCLAW_BUNDLED_CHANNEL_SCENARIOS=0 OPENCLAW_BUNDLED_CHANNEL_UPDATE_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_ROOT_OWNED_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_SETUP_ENTRY_SCENARIO=0 pnpm test:docker:bundled-channel-deps`. -Aby ręcznie wstępnie zbudować i używać ponownie współdzielonego obrazu built-app: +Aby ręcznie wstępnie zbudować i ponownie wykorzystać współdzielony obraz zbudowanej aplikacji: ```bash OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e:local pnpm test:docker:e2e-build OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Nadpisania obrazu specyficzne dla zestawu, takie jak `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, nadal mają pierwszeństwo, gdy są ustawione. Gdy `OPENCLAW_SKIP_DOCKER_BUILD=1` wskazuje na zdalny współdzielony obraz, skrypty pobierają go, jeśli nie ma go jeszcze lokalnie. Testy Docker dla QR i instalatora zachowują własne Dockerfile, ponieważ walidują zachowanie pakietu/instalacji, a nie współdzielony runtime zbudowanej aplikacji. +Nadpisania obrazu specyficzne dla pakietu, takie jak `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, nadal mają pierwszeństwo, jeśli są ustawione. Gdy `OPENCLAW_SKIP_DOCKER_BUILD=1` wskazuje na zdalny współdzielony obraz, skrypty pobierają go, jeśli nie jest jeszcze dostępny lokalnie. Testy Docker dla QR i instalatora zachowują własne Dockerfile, ponieważ walidują zachowanie pakietu/instalacji, a nie współdzielone środowisko wykonawcze zbudowanej aplikacji. -Runnery Docker modeli live dodatkowo montują bieżący checkout w trybie tylko do odczytu i +Runnery Docker live modeli montują również bieżący checkout tylko do odczytu i przygotowują go w tymczasowym katalogu roboczym wewnątrz kontenera. Dzięki temu obraz runtime -pozostaje lekki, a jednocześnie Vitest działa na dokładnie Twoim lokalnym źródle/konfiguracji. +pozostaje niewielki, a jednocześnie Vitest nadal działa na dokładnie Twoim lokalnym źródle/konfiguracji. Krok przygotowania pomija duże lokalne cache i wyniki buildów aplikacji, takie jak -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` oraz lokalne dla aplikacji katalogi `.build` albo -wyjścia Gradle, aby uruchomienia Docker live nie spędzały minut na kopiowaniu +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` oraz lokalne dla aplikacji katalogi `.build` lub +wyniki Gradle, aby uruchomienia Docker live nie traciły minut na kopiowanie artefaktów specyficznych dla maszyny. -Ustawiają one również `OPENCLAW_SKIP_CHANNELS=1`, aby sondy gateway live nie uruchamiały -prawdziwych workerów kanałów Telegram/Discord itd. wewnątrz kontenera. -`test:docker:live-models` nadal uruchamia `pnpm test:live`, więc przekazuj dalej -także `OPENCLAW_LIVE_GATEWAY_*`, gdy potrzebujesz zawęzić lub wykluczyć pokrycie gateway +Ustawiają też `OPENCLAW_SKIP_CHANNELS=1`, aby sondy gateway live nie uruchamiały +rzeczywistych workerów kanałów Telegram/Discord/itd. wewnątrz kontenera. +`test:docker:live-models` nadal uruchamia `pnpm test:live`, więc przekaż również +`OPENCLAW_LIVE_GATEWAY_*`, gdy musisz zawęzić lub wykluczyć pokrycie gateway live z tej linii Docker. -`test:docker:openwebui` to smoke zgodności wyższego poziomu: uruchamia kontener -Gateway OpenClaw z włączonymi endpointami HTTP zgodnymi z OpenAI, +`test:docker:openwebui` to smoke kompatybilności wyższego poziomu: uruchamia +kontener gateway OpenClaw z włączonymi punktami końcowymi HTTP zgodnymi z OpenAI, uruchamia przypięty kontener Open WebUI względem tego gateway, loguje się przez Open WebUI, weryfikuje, że `/api/models` udostępnia `openclaw/default`, a następnie wysyła -prawdziwe żądanie czatu przez proxy `/api/chat/completions` Open WebUI. -Pierwszy przebieg może być zauważalnie wolniejszy, ponieważ Docker może potrzebować pobrać -obraz Open WebUI, a Open WebUI może potrzebować ukończyć własny cold-start setup. -Ta linia oczekuje użytecznego klucza modelu live, a `OPENCLAW_PROFILE_FILE` +rzeczywiste żądanie czatu przez proxy `/api/chat/completions` Open WebUI. +Pierwsze uruchomienie może być zauważalnie wolniejsze, ponieważ Docker może potrzebować pobrać +obraz Open WebUI, a samo Open WebUI może potrzebować dokończyć własną zimną inicjalizację. +Ta linia oczekuje używalnego klucza live modelu, a `OPENCLAW_PROFILE_FILE` (domyślnie `~/.profile`) jest podstawowym sposobem dostarczenia go w uruchomieniach dockerowych. -Udane uruchomienia wypisują niewielki ładunek JSON, taki jak `{ "ok": true, "model": +Udane uruchomienia wypisują mały payload JSON, taki jak `{ "ok": true, "model": "openclaw/default", ... }`. -`test:docker:mcp-channels` jest celowo deterministyczny i nie potrzebuje -prawdziwego konta Telegram, Discord ani iMessage. Uruchamia zainicjalizowany kontener -Gateway, uruchamia drugi kontener, który startuje `openclaw mcp serve`, a następnie -weryfikuje wykrywanie routowanych konwersacji, odczyty transkryptów, metadane załączników, -zachowanie kolejki zdarzeń live, routing wysyłek wychodzących oraz powiadomienia w stylu Claude dotyczące kanałów + -uprawnień przez prawdziwy most stdio MCP. Kontrola powiadomień -sprawdza bezpośrednio surowe ramki stdio MCP, dzięki czemu smoke waliduje to, co -most rzeczywiście emituje, a nie tylko to, co akurat pokazuje konkretny SDK klienta. -`test:docker:pi-bundle-mcp-tools` jest deterministyczny i nie potrzebuje klucza modelu -live. Buduje obraz Docker repo, uruchamia prawdziwy serwer sondy MCP stdio +`test:docker:mcp-channels` jest celowo deterministyczne i nie wymaga +rzeczywistego konta Telegram, Discord ani iMessage. Uruchamia seedowany +kontener Gateway, uruchamia drugi kontener, który wywołuje `openclaw mcp serve`, a następnie +weryfikuje routowane wykrywanie rozmów, odczyty transkryptów, metadane załączników, +zachowanie kolejki zdarzeń live, routing wysyłania wychodzącego oraz powiadomienia kanału + +uprawnień w stylu Claude przez rzeczywisty most stdio MCP. Kontrola powiadomień +bezpośrednio sprawdza surowe ramki stdio MCP, więc smoke waliduje to, co most +faktycznie emituje, a nie tylko to, co akurat udostępnia konkretny SDK klienta. +`test:docker:pi-bundle-mcp-tools` jest deterministyczne i nie wymaga klucza +live modelu. Buduje obraz Docker repo, uruchamia rzeczywisty serwer sondy stdio MCP wewnątrz kontenera, materializuje ten serwer przez osadzony runtime Pi bundle MCP, wykonuje narzędzie, a następnie weryfikuje, że `coding` i `messaging` zachowują narzędzia `bundle-mcp`, podczas gdy `minimal` i `tools.deny: ["bundle-mcp"]` je filtrują. -`test:docker:cron-mcp-cleanup` jest deterministyczny i nie potrzebuje klucza modelu -live. Uruchamia zainicjalizowany Gateway z prawdziwym serwerem sondy MCP stdio, wykonuje -izolowaną turę Cron oraz jednorazową turę podrzędnego procesu `/subagents spawn`, a następnie -weryfikuje, że podrzędny proces MCP kończy działanie po każdym przebiegu. +`test:docker:cron-mcp-cleanup` jest deterministyczne i nie wymaga klucza live modelu. +Uruchamia seedowany Gateway z rzeczywistym serwerem sondy stdio MCP, wykonuje +odizolowaną turę Cron oraz jednorazową turę potomną `/subagents spawn`, a następnie +weryfikuje, że podrzędny proces MCP kończy działanie po każdym uruchomieniu. -Ręczny smoke ACP plain-language thread (nie CI): +Ręczny smoke wątku ACP w prostym języku (nie CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Zachowaj ten skrypt dla przepływów regresyjnych/debugowych. Może być ponownie potrzebny do walidacji routingu wątków ACP, więc go nie usuwaj. +- Zachowaj ten skrypt do workflow regresji/debugowania. Może być ponownie potrzebny do walidacji routingu wątków ACP, więc go nie usuwaj. Przydatne zmienne env: @@ -1012,115 +1020,115 @@ Przydatne zmienne env: - `OPENCLAW_PROFILE_FILE=...` (domyślnie: `~/.profile`) montowane do `/home/node/.profile` i pobierane przed uruchomieniem testów - `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, aby zweryfikować wyłącznie zmienne env pobrane z `OPENCLAW_PROFILE_FILE`, z użyciem tymczasowych katalogów config/workspace i bez montowania zewnętrznych auth CLI - `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (domyślnie: `~/.cache/openclaw/docker-cli-tools`) montowane do `/home/node/.npm-global` dla cache instalacji CLI wewnątrz Dockera -- Zewnętrzne katalogi/pliki auth CLI pod `$HOME` są montowane w trybie tylko do odczytu pod `/host-auth...`, a następnie kopiowane do `/home/node/...` przed startem testów +- Zewnętrzne katalogi/pliki auth CLI w `$HOME` są montowane tylko do odczytu pod `/host-auth...`, a następnie kopiowane do `/home/node/...` przed startem testów - Domyślne katalogi: `.minimax` - Domyślne pliki: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Zawężone przebiegi providerów montują tylko potrzebne katalogi/pliki wywnioskowane z `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Nadpisz ręcznie przez `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` albo listę rozdzielaną przecinkami, taką jak `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` -- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, aby zawęzić przebieg -- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, aby filtrować providerów w kontenerze -- `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby ponownie użyć istniejącego obrazu `openclaw:local-live` dla kolejnych uruchomień, które nie wymagają przebudowy -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby upewnić się, że poświadczenia pochodzą z magazynu profili (a nie z env) + - Zawężone uruchomienia dostawców montują tylko potrzebne katalogi/pliki wywnioskowane z `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` + - Nadpisz ręcznie przez `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` albo listę rozdzielaną przecinkami, np. `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` +- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, aby zawęzić uruchomienie +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, aby filtrować dostawców w kontenerze +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby ponownie użyć istniejącego obrazu `openclaw:local-live` przy ponownych uruchomieniach, które nie wymagają przebudowy +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby upewnić się, że poświadczenia pochodzą ze store profili (a nie z env) - `OPENCLAW_OPENWEBUI_MODEL=...`, aby wybrać model udostępniany przez gateway dla smoke Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...`, aby nadpisać prompt sprawdzający nonce używany przez smoke Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, aby nadpisać prompt sprawdzania nonce używany przez smoke Open WebUI - `OPENWEBUI_IMAGE=...`, aby nadpisać przypięty tag obrazu Open WebUI -## Kontrola poprawności dokumentacji +## Spójność dokumentacji -Uruchamiaj kontrole dokumentacji po edycjach docs: `pnpm check:docs`. -Uruchamiaj pełną walidację anchorów Mintlify, gdy potrzebujesz również sprawdzeń nagłówków w obrębie strony: `pnpm docs:check-links:anchors`. +Po edycji dokumentacji uruchom kontrole dokumentacji: `pnpm check:docs`. +Uruchom pełną walidację kotwic Mintlify, gdy potrzebujesz również kontroli nagłówków na stronie: `pnpm docs:check-links:anchors`. ## Regresje offline (bezpieczne dla CI) -To regresje „prawdziwego pipeline” bez prawdziwych providerów: +To regresje „rzeczywistego pipeline” bez rzeczywistych dostawców: -- Wywoływanie narzędzi Gateway (mock OpenAI, prawdziwy gateway + pętla agenta): `src/gateway/gateway.test.ts` (przypadek: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Kreator Gateway (WS `wizard.start`/`wizard.next`, wymuszone zapisy config + auth): `src/gateway/gateway.test.ts` (przypadek: "runs wizard over ws and writes auth token config") +- Wywoływanie narzędzi gateway (mock OpenAI, rzeczywista pętla gateway + agent): `src/gateway/gateway.test.ts` (przypadek: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Kreator gateway (WS `wizard.start`/`wizard.next`, wymuszony zapis config + auth): `src/gateway/gateway.test.ts` (przypadek: "runs wizard over ws and writes auth token config") -## Oceny niezawodności agenta (Skills) +## Ewalucje niezawodności agenta (Skills) -Mamy już kilka bezpiecznych dla CI testów, które zachowują się jak „oceny niezawodności agenta”: +Mamy już kilka testów bezpiecznych dla CI, które zachowują się jak „ewaluacje niezawodności agenta”: -- Mockowane wywoływanie narzędzi przez prawdziwy gateway + pętlę agenta (`src/gateway/gateway.test.ts`). -- End-to-end przepływy kreatora, które walidują powiązanie sesji i efekty konfiguracji (`src/gateway/gateway.test.ts`). +- Mockowane wywoływanie narzędzi przez rzeczywistą pętlę gateway + agent (`src/gateway/gateway.test.ts`). +- Przepływy end-to-end kreatora, które walidują okablowanie sesji i skutki konfiguracji (`src/gateway/gateway.test.ts`). Czego nadal brakuje dla Skills (zobacz [Skills](/pl/tools/skills)): -- **Decyzyjność:** gdy Skills są wymienione w prompcie, czy agent wybiera właściwe Skills (albo unika nieistotnych)? +- **Podejmowanie decyzji:** gdy Skills są wymienione w prompcie, czy agent wybiera właściwy skill (albo unika nieistotnych)? - **Zgodność:** czy agent czyta `SKILL.md` przed użyciem i wykonuje wymagane kroki/argumenty? -- **Kontrakty przepływu pracy:** scenariusze wieloturowe, które sprawdzają kolejność narzędzi, przenoszenie historii sesji i granice sandboxa. +- **Kontrakty workflow:** scenariusze wieloturowe, które potwierdzają kolejność narzędzi, przenoszenie historii sesji oraz granice sandboxu. -Przyszłe oceny powinny najpierw pozostać deterministyczne: +Przyszłe ewaluacje powinny najpierw pozostać deterministyczne: -- Runner scenariuszy używający mock providerów do sprawdzania wywołań narzędzi + kolejności, odczytów plików Skills i powiązania sesji. -- Mały zestaw scenariuszy skupionych na Skills (użyj vs unikaj, bramkowanie, prompt injection). -- Opcjonalne oceny live (opt-in, ograniczone env) dopiero po wdrożeniu zestawu bezpiecznego dla CI. +- Runner scenariuszy wykorzystujący mockowanych dostawców do potwierdzania wywołań narzędzi i ich kolejności, odczytów plików skill oraz okablowania sesji. +- Mały pakiet scenariuszy skoncentrowanych na skillach (użycie vs unikanie, bramkowanie, prompt injection). +- Opcjonalne ewaluacje live (opt-in, bramkowane env) dopiero po wdrożeniu pakietu bezpiecznego dla CI. ## Testy kontraktowe (kształt pluginów i kanałów) -Testy kontraktowe weryfikują, że każdy zarejestrowany Plugin i kanał jest zgodny ze swoim -kontraktem interfejsu. Iterują po wszystkich wykrytych Pluginach i uruchamiają zestaw -sprawdzeń kształtu i zachowania. Domyślna linia unit `pnpm test` celowo +Testy kontraktowe weryfikują, że każdy zarejestrowany plugin i kanał jest zgodny ze swoim +kontraktem interfejsu. Iterują po wszystkich wykrytych pluginach i uruchamiają pakiet +asercji kształtu i zachowania. Domyślna linia unit `pnpm test` celowo pomija te współdzielone pliki seam i smoke; uruchamiaj polecenia kontraktowe jawnie, -gdy dotykasz współdzielonych powierzchni kanałów lub providerów. +gdy dotykasz współdzielonych powierzchni kanałów lub dostawców. ### Polecenia - Wszystkie kontrakty: `pnpm test:contracts` - Tylko kontrakty kanałów: `pnpm test:contracts:channels` -- Tylko kontrakty providerów: `pnpm test:contracts:plugins` +- Tylko kontrakty dostawców: `pnpm test:contracts:plugins` ### Kontrakty kanałów Znajdują się w `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** - Podstawowy kształt Pluginu (id, nazwa, możliwości) +- **plugin** - Podstawowy kształt pluginu (id, name, capabilities) - **setup** - Kontrakt kreatora konfiguracji -- **session-binding** - Zachowanie wiązania sesji +- **session-binding** - Zachowanie dowiązania sesji - **outbound-payload** - Struktura payloadu wiadomości - **inbound** - Obsługa wiadomości przychodzących - **actions** - Handlery akcji kanału - **threading** - Obsługa identyfikatorów wątków - **directory** - API katalogu/listy -- **group-policy** - Egzekwowanie polityki grup +- **group-policy** - Wymuszanie polityki grupowej -### Kontrakty statusu providerów +### Kontrakty statusu dostawców Znajdują się w `src/plugins/contracts/*.contract.test.ts`. -- **status** - Sondy statusu kanałów -- **registry** - Kształt rejestru Pluginów +- **status** - Sondy statusu kanału +- **registry** - Kształt rejestru pluginów -### Kontrakty providerów +### Kontrakty dostawców Znajdują się w `src/plugins/contracts/*.contract.test.ts`: - **auth** - Kontrakt przepływu auth - **auth-choice** - Wybór/selekcja auth - **catalog** - API katalogu modeli -- **discovery** - Odkrywanie Pluginów -- **loader** - Ładowanie Pluginów -- **runtime** - Runtime providera -- **shape** - Kształt/interfejs Pluginu +- **discovery** - Wykrywanie pluginów +- **loader** - Ładowanie pluginów +- **runtime** - Runtime dostawcy +- **shape** - Kształt/interfejs pluginu - **wizard** - Kreator konfiguracji ### Kiedy uruchamiać -- Po zmianie eksportów lub ścieżek podrzędnych Plugin SDK -- Po dodaniu lub modyfikacji Pluginu kanału albo providera -- Po refaktoryzacji rejestracji lub wykrywania Pluginów +- Po zmianie eksportów lub podścieżek plugin-sdk +- Po dodaniu lub modyfikacji pluginu kanału lub dostawcy +- Po refaktorze rejestracji lub wykrywania pluginów -Testy kontraktowe uruchamiają się w CI i nie wymagają prawdziwych kluczy API. +Testy kontraktowe są uruchamiane w CI i nie wymagają prawdziwych kluczy API. ## Dodawanie regresji (wskazówki) -Gdy naprawiasz problem providera/modelu wykryty w live: +Gdy naprawiasz problem dostawcy/modelu wykryty w live: -- Jeśli to możliwe, dodaj regresję bezpieczną dla CI (mock/stub providera albo przechwycenie dokładnej transformacji kształtu żądania) -- Jeśli z natury jest to tylko live (limity szybkości, polityki auth), utrzymuj test live wąski i opt-in przez zmienne env -- Preferuj targetowanie najmniejszej warstwy, która wychwytuje błąd: - - błąd konwersji/odtwarzania żądania providera → test modeli bezpośrednich - - błąd pipeline sesji/historii/narzędzi gateway → smoke gateway live albo bezpieczny dla CI test mock gateway -- Guardrail przechodzenia SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` wyprowadza jeden przykładowy cel dla każdej klasy SecretRef z metadanych rejestru (`listSecretTargetRegistryEntries()`), a następnie sprawdza, że identyfikatory exec segmentów przejścia są odrzucane. - - Jeśli dodasz nową rodzinę celów SecretRef `includeInPlan` w `src/secrets/target-registry-data.ts`, zaktualizuj `classifyTargetClass` w tym teście. Test celowo kończy się błędem dla niesklasyfikowanych identyfikatorów celów, aby nowe klasy nie mogły zostać pominięte po cichu. +- Jeśli to możliwe, dodaj regresję bezpieczną dla CI (mock/stub dostawcy albo przechwycenie dokładnej transformacji kształtu żądania) +- Jeśli z natury da się to testować tylko w live (limity szybkości, polityki auth), zachowaj test live wąski i opt-in przez zmienne env +- Preferuj najmniejszą warstwę, która wychwytuje błąd: + - błąd konwersji/odtwarzania żądania dostawcy → test bezpośrednich modeli + - błąd pipeline sesji/historii/narzędzi gateway → smoke gateway live lub bezpieczny dla CI mockowany test gateway +- Zabezpieczenie przechodzenia SecretRef: + - `src/secrets/exec-secret-ref-id-parity.test.ts` wyprowadza jeden próbkowany cel na klasę SecretRef z metadanych rejestru (`listSecretTargetRegistryEntries()`), a następnie potwierdza, że identyfikatory exec segmentów przechodzenia są odrzucane. + - Jeśli dodasz nową rodzinę celów SecretRef `includeInPlan` w `src/secrets/target-registry-data.ts`, zaktualizuj `classifyTargetClass` w tym teście. Test celowo kończy się niepowodzeniem dla niesklasyfikowanych identyfikatorów celów, aby nowych klas nie dało się pominąć po cichu.