diff --git a/docs/pl/ci.md b/docs/pl/ci.md index c1b25ebb0..e358fc428 100644 --- a/docs/pl/ci.md +++ b/docs/pl/ci.md @@ -1,75 +1,75 @@ --- read_when: - Musisz zrozumieć, dlaczego zadanie CI zostało lub nie zostało uruchomione - - Debugujesz nieudane sprawdzenie GitHub Actions + - Debugujesz nieudaną kontrolę GitHub Actions - Koordynujesz uruchomienie lub ponowne uruchomienie walidacji wydania summary: Graf zadań CI, bramki zakresu, parasole wydań i lokalne odpowiedniki poleceń title: Potok CI x-i18n: - generated_at: "2026-04-30T09:41:27Z" + generated_at: "2026-04-30T18:39:07Z" model: gpt-5.5 provider: openai - source_hash: a9c18f0801864ca1030aac9ea81117b011bd7936388984a1809ce3ae6e906e62 + source_hash: a24afc27606ac7f4e9ead89acdd319bffa23336610f8a6cd8b576ea1a5b233dd source_path: ci.md workflow: 16 --- -OpenClaw CI uruchamia się przy każdym wypchnięciu do `main` i dla każdego pull requestu. Zadanie `preflight` klasyfikuje diff i wyłącza kosztowne ścieżki, gdy zmieniły się tylko niepowiązane obszary. Ręczne uruchomienia `workflow_dispatch` celowo omijają inteligentne zawężanie zakresu i rozwijają pełny graf dla kandydatów do wydania oraz szerokiej walidacji. Ścieżki Androida pozostają opcjonalne przez `include_android`. Pokrycie Plugin tylko dla wydań znajduje się w osobnym workflow [`Plugin Prerelease`](#plugin-prerelease) i uruchamia się tylko z [`Full Release Validation`](#full-release-validation) albo przez jawne ręczne wywołanie. +OpenClaw CI uruchamia się przy każdym wypchnięciu do `main` i dla każdego pull requesta. Zadanie `preflight` klasyfikuje różnicę i wyłącza kosztowne ścieżki, gdy zmieniły się tylko niepowiązane obszary. Ręczne uruchomienia `workflow_dispatch` celowo omijają inteligentne zawężanie zakresu i rozgałęziają pełny graf dla kandydatów do wydania oraz szerokiej walidacji. Ścieżki Android pozostają opcjonalne przez `include_android`. Pokrycie Plugin tylko dla wydań znajduje się w osobnym workflow [`Wstępne wydanie Plugin`](#plugin-prerelease) i uruchamia się tylko z [`Pełnej walidacji wydania`](#full-release-validation) albo przez jawne ręczne wywołanie. ## Przegląd potoku | Zadanie | Cel | Kiedy się uruchamia | | -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- | -| `preflight` | Wykrywa zmiany wyłącznie w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze dla niedraftowych wypchnięć i PR-ów | -| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze dla niedraftowych wypchnięć i PR-ów | -| `security-dependency-audit` | Audyt produkcyjnego lockfile bez instalowania zależności względem advisory npm | Zawsze dla niedraftowych wypchnięć i PR-ów | -| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze dla niedraftowych wypchnięć i PR-ów | -| `check-dependencies` | Produkcyjny przebieg Knip tylko dla zależności oraz strażnik listy dozwolonych nieużywanych plików | Zmiany istotne dla Node | -| `build-artifacts` | Buduje `dist/`, Control UI, kontrole zbudowanych artefaktów i artefakty wielokrotnego użytku dla dalszych zadań | Zmiany istotne dla Node | -| `checks-fast-core` | Szybkie linuksowe ścieżki poprawności, takie jak kontrole dołączonych Pluginów, kontraktów Pluginów i protokołu | Zmiany istotne dla Node | -| `checks-fast-contracts-channels` | Shardowane kontrole kontraktów kanałów ze stabilnym zagregowanym wynikiem kontroli | Zmiany istotne dla Node | -| `checks-node-core-test` | Shardy testów rdzenia Node, z wyłączeniem ścieżek kanałów, dołączonych elementów, kontraktów i rozszerzeń | Zmiany istotne dla Node | -| `check` | Shardowany odpowiednik głównej lokalnej bramki: typy produkcyjne, lint, strażniki, typy testów i rygorystyczny smoke test | Zmiany istotne dla Node | -| `check-additional` | Shardy architektury, granic, strażników powierzchni rozszerzeń, granic pakietów i gateway-watch | Zmiany istotne dla Node | -| `build-smoke` | Smoke testy zbudowanego CLI i smoke test pamięci przy uruchomieniu | Zmiany istotne dla Node | -| `checks` | Weryfikator testów kanałów dla zbudowanych artefaktów | Zmiany istotne dla Node | -| `checks-node-compat-node22` | Ścieżka budowania zgodności z Node 22 i smoke testu | Ręczne wywołanie CI dla wydań | -| `check-docs` | Formatowanie dokumentacji, lint i kontrole uszkodzonych linków | Zmieniona dokumentacja | -| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla pythonowych Skills | -| `checks-windows` | Testy procesów/ścieżek specyficzne dla Windows oraz regresje współdzielonych specyfikatorów importu runtime | Zmiany istotne dla Windows | -| `macos-node` | Ścieżka testów TypeScript na macOS używająca współdzielonych zbudowanych artefaktów | Zmiany istotne dla macOS | -| `macos-swift` | Swift lint, budowanie i testy aplikacji macOS | Zmiany istotne dla macOS | -| `android` | Testy jednostkowe Androida dla obu wariantów oraz jedno zbudowanie debug APK | Zmiany istotne dla Androida | -| `test-performance-agent` | Codzienna optymalizacja wolnych testów przez Codex po zaufanej aktywności | Powodzenie CI na main albo ręczne wywołanie | +| `preflight` | Wykrywa zmiany tylko w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze przy wypchnięciach i PR-ach, które nie są szkicami | +| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze przy wypchnięciach i PR-ach, które nie są szkicami | +| `security-dependency-audit` | Audyt produkcyjnego lockfile bez zależności względem ostrzeżeń npm | Zawsze przy wypchnięciach i PR-ach, które nie są szkicami | +| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze przy wypchnięciach i PR-ach, które nie są szkicami | +| `check-dependencies` | Produkcyjne przejście Knip tylko dla zależności oraz strażnik listy dozwolonych nieużywanych plików | Zmiany istotne dla Node | +| `build-artifacts` | Buduje `dist/`, Control UI, sprawdzenia 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 sprawdzenia bundled/plugin-contract/protocol | Zmiany istotne dla Node | +| `checks-fast-contracts-channels` | Shardowane sprawdzenia kontraktów kanałów ze stabilnym zagregowanym wynikiem sprawdzenia | Zmiany istotne dla Node | +| `checks-node-core-test` | Shardy testów rdzenia Node, z wyłączeniem ścieżek kanałów, bundled, kontraktów i rozszerzeń | Zmiany istotne dla Node | +| `check` | Shardowany odpowiednik głównej lokalnej bramki: typy produkcyjne, lint, strażniki, typy testów i rygorystyczny smoke | Zmiany istotne dla Node | +| `check-additional` | Shardy architektury, granic, strażników powierzchni rozszerzeń, granic pakietów i gateway-watch | Zmiany istotne dla Node | +| `build-smoke` | Testy smoke zbudowanego CLI i smoke pamięci startowej | Zmiany istotne dla Node | +| `checks` | Weryfikator testów kanałów dla zbudowanych artefaktów | Zmiany istotne dla Node | +| `checks-node-compat-node22` | Ścieżka budowania i smoke zgodności z Node 22 | Ręczne wywołanie CI dla wydań | +| `check-docs` | Formatowanie dokumentacji, lint i sprawdzenia niedziałających linków | Zmieniono dokumentację | +| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla Python-skill | +| `checks-windows` | Testy procesów/ścieżek specyficzne dla Windows oraz współdzielone regresje specyfikatorów importu runtime | Zmiany istotne dla Windows | +| `macos-node` | Ścieżka testów TypeScript na macOS używająca współdzielonych zbudowanych artefaktów | Zmiany istotne dla macOS | +| `macos-swift` | Swift lint, budowanie i testy aplikacji macOS | Zmiany istotne dla macOS | +| `android` | Testy jednostkowe Android dla obu wariantów oraz jedna kompilacja debug APK | Zmiany istotne dla Android | +| `test-performance-agent` | Codzienna optymalizacja wolnych testów przez Codex po zaufanej aktywności | Sukces CI na main albo ręczne wywołanie | -## Kolejność fail-fast +## Kolejność szybkiego niepowodzenia -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ę niepowodzeniem szybko, bez czekania na cięższe zadania artefaktów i macierzy platform. -3. `build-artifacts` nakłada się z szybkimi ścieżkami Linuksa, aby dalsi konsumenci mogli wystartować, gdy tylko wspólna kompilacja będzie gotowa. -4. Cięższe ścieżki platform i runtime rozwijają się potem: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`. +1. `preflight` decyduje, które ścieżki w ogóle istnieją. Logika `docs-scope` i `changed-scope` to kroki wewnątrz tego zadania, a nie samodzielne zadania. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` szybko kończą się niepowodzeniem bez czekania na cięższe zadania artefaktów i macierzy platform. +3. `build-artifacts` nakłada się z szybkimi ścieżkami Linuksa, aby konsumenci podrzędni mogli wystartować, gdy tylko współdzielone budowanie będzie gotowe. +4. Cięższe ścieżki platform i runtime rozgałęziają się później: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`. -GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowsze wypchnięcie trafi do tego samego PR-a albo refa `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tego samego refa również kończy się niepowodzeniem. Zagregowane kontrole shardów używają `!cancelled() && always()`, więc nadal raportują zwykłe niepowodzenia shardów, ale nie kolejkują się po tym, jak całe workflow zostało już zastąpione. Automatyczny klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHuba w starej grupie kolejki nie mogło bezterminowo blokować nowszych uruchomień main. Ręczne uruchomienia pełnego zestawu używają `CI-manual-v1-*` i nie anulują trwających uruchomień. +GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowsze wypchnięcie trafi do tego samego PR-a albo referencji `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tej samej referencji również kończy się niepowodzeniem. Zagregowane sprawdzenia shardów używają `!cancelled() && always()`, więc nadal zgłaszają normalne niepowodzenia shardów, ale nie kolejkowują się po tym, jak cały workflow został już zastąpiony. Automatyczny klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHub w starej grupie kolejki nie mogło bezterminowo blokować nowszych uruchomień main. Ręczne uruchomienia pełnego zestawu używają `CI-manual-v1-*` i nie anulują uruchomień w toku. ## Zakres i routowanie -Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest pokryta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`. Ręczne wywołanie pomija wykrywanie changed-scope i sprawia, że manifest preflight zachowuje się tak, jakby zmienił się każdy obszar objęty zakresem. +Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest objęta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`. Ręczne wywołanie pomija wykrywanie changed-scope i sprawia, że manifest preflight zachowuje się tak, jakby zmienił się każdy zakresowy obszar. -- **Edycje workflow CI** walidują graf CI Node oraz linting workflow, ale same nie wymuszają natywnych buildów Windows, Androida ani macOS; te ścieżki platform pozostają ograniczone do zmian źródeł platformowych. -- **Edycje wyłącznie routingu CI, wybrane tanie edycje fixture’ów testów rdzenia oraz wąskie edycje pomocnicze/routingu testów kontraktów Pluginów** używają szybkiej ścieżki manifestu tylko dla Node: `preflight`, bezpieczeństwo i jedno zadanie `checks-fast-core`. Ta ścieżka pomija artefakty budowania, zgodność z Node 22, kontrakty kanałów, pełne shardy rdzenia, shardy dołączonych Pluginów i dodatkowe macierze strażników, gdy zmiana ogranicza się do powierzchni routingu lub pomocniczych, które szybkie zadanie ćwiczy bezpośrednio. -- **Kontrole Node dla Windows** są ograniczone do specyficznych dla Windows wrapperów procesów/ścieżek, helperów runnerów npm/pnpm/UI, konfiguracji menedżera pakietów oraz powierzchni workflow CI, które wykonują tę ścieżkę; niepowiązane zmiany źródeł, Pluginów, install-smoke i wyłącznie testowe pozostają na linuksowych ścieżkach Node. +- **Edycje workflow CI** walidują graf CI Node oraz linting workflow, ale same nie wymuszają natywnych buildów Windows, Android ani macOS; te ścieżki platform pozostają zawężone do zmian w źródłach platform. +- **Edycje dotyczące tylko routowania CI, wybrane tanie edycje fixture testów rdzenia oraz wąskie edycje pomocnicze/routingu testów kontraktu Plugin** używają szybkiej ścieżki manifestu tylko dla Node: `preflight`, bezpieczeństwo i jedno zadanie `checks-fast-core`. Ta ścieżka pomija artefakty budowania, zgodność z Node 22, kontrakty kanałów, pełne shardy rdzenia, shardy bundled-plugin oraz dodatkowe macierze strażników, gdy zmiana jest ograniczona do powierzchni routingu lub pomocniczych, które szybkie zadanie ćwiczy bezpośrednio. +- **Sprawdzenia Node na Windows** są zawężone do specyficznych dla Windows wrapperów procesów/ścieżek, pomocników runnerów npm/pnpm/UI, konfiguracji menedżera pakietów oraz powierzchni workflow CI, które wykonują tę ścieżkę; niepowiązane zmiany źródeł, Plugin, install-smoke i tylko testów pozostają na linuksowych ścieżkach Node. -Najwolniejsze rodziny testów Node są dzielone lub równoważone, aby każde zadanie pozostawało małe bez nadmiernej rezerwacji runnerów: kontrakty kanałów działają jako trzy ważone shardy, małe ścieżki jednostkowe rdzenia są parowane, auto-reply działa jako czterech zrównoważonych workerów (z poddrzewem odpowiedzi podzielonym na shardy agent-runner, dispatch oraz commands/state-routing), a agentic konfiguracje Gateway/Plugin są rozłożone między istniejące zadania agentic Node tylko dla źródeł zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarki, QA, mediów i różne testy Pluginów używają własnych dedykowanych konfiguracji Vitest zamiast wspólnego catch-all dla Pluginów. Shardy include-pattern zapisują wpisy czasów z użyciem nazwy sharda CI, więc `.artifacts/vitest-shard-timings.json` może odróżnić całą konfigurację od filtrowanego sharda. `check-additional` trzyma razem prace kompilacji/canary granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; shard strażnika granic uruchamia swoje małe niezależne strażniki współbieżnie w jednym zadaniu. Gateway watch, testy kanałów i shard granicy wsparcia rdzenia działają współbieżnie wewnątrz `build-artifacts` po tym, jak `dist/` i `dist-runtime/` są już zbudowane. +Najwolniejsze rodziny testów Node są dzielone lub balansowane tak, aby każde zadanie pozostało małe bez nadmiernego rezerwowania runnerów: kontrakty kanałów uruchamiają się jako trzy ważone shardy, małe ścieżki jednostkowe rdzenia są parowane, auto-reply działa jako czterech zbalansowanych workerów (z poddrzewem reply podzielonym na shardy agent-runner, dispatch oraz commands/state-routing), a agentowe konfiguracje Gateway/Plugin są rozłożone na istniejące agentowe zadania Node tylko ze źródeł zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarkowe, QA, multimediów i różne testy Plugin używają dedykowanych konfiguracji Vitest zamiast współdzielonego catch-all dla Plugin. Shardy include-pattern zapisują wpisy czasów z użyciem nazwy sharda CI, więc `.artifacts/vitest-shard-timings.json` może odróżnić całą konfigurację od przefiltrowanego sharda. `check-additional` trzyma razem pracę kompilacji/canary dla granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; shard strażnika granic uruchamia swoje małe niezależne strażniki współbieżnie w jednym zadaniu. Gateway watch, testy kanałów i shard granic wsparcia rdzenia działają współbieżnie wewnątrz `build-artifacts` po tym, jak `dist/` i `dist-runtime/` są już zbudowane. -CI Androida uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje Play debug APK. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje wariant z flagami BuildConfig SMS/call-log, unikając jednocześnie duplikowania zadania pakowania debug APK przy każdym wypchnięciu istotnym dla Androida. +Android CI uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje Play debug APK. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje wariant z flagami BuildConfig SMS/call-log, unikając jednocześnie zduplikowanego zadania pakowania debug APK przy każdym wypchnięciu istotnym dla Android. -Shard `check-dependencies` uruchamia `pnpm deadcode:dependencies` (produkcyjny przebieg Knip tylko dla zależności przypięty do najnowszej wersji Knip, z wyłączonym minimalnym wiekiem wydania pnpm dla instalacji `dlx`) oraz `pnpm deadcode:unused-files`, które porównuje produkcyjne znaleziska nieużywanych plików Knip z `scripts/deadcode-unused-files.allowlist.mjs`. Strażnik nieużywanych plików kończy się niepowodzeniem, gdy PR dodaje nowy nieprzejrzany nieużywany plik albo zostawia przestarzały wpis na liście dozwolonych, zachowując przy tym celowe dynamiczne powierzchnie Pluginów, wygenerowane, build, live-test i mosty pakietów, których Knip nie może rozwiązać statycznie. +Shard `check-dependencies` uruchamia `pnpm deadcode:dependencies` (produkcyjne przejście Knip tylko dla zależności przypięte do najnowszej wersji Knip, z wyłączonym minimalnym wiekiem wydania pnpm dla instalacji `dlx`) oraz `pnpm deadcode:unused-files`, które porównuje produkcyjne znaleziska nieużywanych plików z Knip z `scripts/deadcode-unused-files.allowlist.mjs`. Strażnik nieużywanych plików kończy się niepowodzeniem, gdy PR dodaje nowy, niezweryfikowany nieużywany plik albo pozostawia nieaktualny wpis listy dozwolonych, zachowując jednocześnie intencjonalne dynamiczne powierzchnie Plugin, generowane, build, live-test i mosty pakietów, których Knip nie może rozwiązać statycznie. ## Ręczne wywołania -Ręczne wywołania CI uruchamiają ten sam graf zadań co normalne CI, ale wymuszają każdą nieandroidową ścieżkę objętą zakresem: shardy Linux Node, shardy dołączonych Pluginów, kontrakty kanałów, zgodność z Node 22, `check`, `check-additional`, build smoke, kontrole dokumentacji, pythonowe Skills, Windows, macOS i i18n Control UI. Samodzielne ręczne wywołania CI uruchamiają Androida tylko z `include_android=true`; parasol pełnego wydania włącza Androida przez przekazanie `include_android=true`. Statyczne kontrole prerelease Pluginów, wyłącznie wydaniowy shard `agentic-plugins`, pełny wsadowy przegląd rozszerzeń i dockerowe ścieżki prerelease Pluginów są wyłączone z CI. Zestaw Docker prerelease uruchamia się tylko wtedy, gdy `Full Release Validation` wywołuje osobny workflow `Plugin Prerelease` z włączoną bramką release-validation. +Ręczne wywołania CI uruchamiają ten sam graf zadań co normalne CI, ale wymuszają każdą zakresową ścieżkę poza Android: shardy Linux Node, shardy bundled-plugin, kontrakty kanałów, zgodność Node 22, `check`, `check-additional`, build smoke, sprawdzenia dokumentacji, Python skills, Windows, macOS i i18n Control UI. Samodzielne ręczne wywołania CI uruchamiają Android tylko z `include_android=true`; parasol pełnego wydania włącza Android, przekazując `include_android=true`. Statyczne sprawdzenia wstępnego wydania Plugin, shard tylko dla wydania `agentic-plugins`, pełny sweep batch rozszerzeń oraz ścieżki Docker wstępnego wydania Plugin są wykluczone z CI. Pakiet Docker wstępnego wydania uruchamia się tylko wtedy, gdy `Full Release Validation` wywołuje osobny workflow `Plugin Prerelease` z włączoną bramką release-validation. -Ręczne uruchomienia używają unikalnej grupy współbieżności, więc pełny zestaw dla kandydata do wydania nie jest anulowany przez inne wypchnięcie albo uruchomienie PR na tym samym refie. Opcjonalne wejście `target_ref` pozwala zaufanemu wywołującemu uruchomić ten graf względem brancha, taga albo pełnego SHA commita, używając pliku workflow z wybranego refa wywołania. +Ręczne uruchomienia używają unikalnej grupy współbieżności, więc pełny zestaw dla kandydata do wydania nie jest anulowany przez inne wypchnięcie ani uruchomienie PR na tej samej referencji. Opcjonalne wejście `target_ref` pozwala zaufanemu wywołującemu uruchomić ten graf względem brancha, tagu albo pełnego SHA commita, używając pliku workflow z wybranej referencji wywołania. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -77,17 +77,17 @@ gh workflow run ci.yml --ref main -f target_ref= -f include_andro gh workflow run full-release-validation.yml --ref main -f ref= ``` -## Runnery +## Runery -| Uruchamiacz | Zadania | -| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, szybkie zadania bezpieczeństwa i agregaty (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie kontrole protokołu/kontraktu/pakietów, shardowane kontrole kontraktów kanałów, shardy `check` z wyjątkiem lint, shardy i agregaty `check-additional`, weryfikatory agregatów testów Node, kontrole dokumentacji, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke także używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła wcześniej trafić do kolejki | -| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lżejsze shardy rozszerzeń, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` i `check-test-types` | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shardy testów Node w Linuksie, shardy testów pakietowych pluginów, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (na tyle wrażliwe na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało); buildy Docker install-smoke (czas oczekiwania w kolejce dla 32 vCPU kosztował więcej, niż oszczędzał) | +| Runner | Zadania | +| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, szybkie zadania i agregaty bezpieczeństwa (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie kontrole protokołu/kontraktu/wbudowanych elementów, shardowane kontrole kontraktu kanałów, shardy `check` z wyjątkiem lintingu, shardy i agregaty `check-additional`, weryfikatory agregatów testów Node, kontrole dokumentacji, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke także używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła kolejkować się wcześniej | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lżejsze shardy rozszerzeń, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` oraz `check-test-types` | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shardy testów Node dla Linuksa, shardy testów wbudowanych pluginów, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (wystarczająco wrażliwy na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało); kompilacje Docker install-smoke (czas kolejki 32 vCPU kosztował więcej, niż oszczędzał) | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `macos-node` w `openclaw/openclaw`; forki wracają do `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` w `openclaw/openclaw`; forki wracają do `macos-latest` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` w `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` w `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest` | ## Lokalne odpowiedniki @@ -117,27 +117,27 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac ## Pełna walidacja wydania -`Full Release Validation` to ręczny nadrzędny workflow do „uruchomienia wszystkiego przed wydaniem”. Przyjmuje gałąź, tag lub pełny SHA commita, uruchamia ręczny workflow `CI` z tym celem, uruchamia `Plugin Prerelease` dla dowodu dotyczącego wyłącznie wydania: pluginów/pakietów/statyki/Dockera, oraz uruchamia `OpenClaw Release Checks` dla install smoke, package acceptance, zestawów ścieżki wydania Dockera, live/E2E, OpenWebUI, parytetu QA Lab, Matrix i ścieżek Telegram. Może też uruchomić powydaniowy workflow `NPM Telegram Beta E2E`, gdy podano specyfikację opublikowanego pakietu. +`Full Release Validation` to ręczny nadrzędny workflow dla „uruchom wszystko przed wydaniem”. Przyjmuje gałąź, tag lub pełny SHA commita, uruchamia ręczny workflow `CI` z tym celem, uruchamia `Plugin Prerelease` dla dowodu dotyczącego wyłącznie wydania: pluginu/pakietu/statycznych zasobów/Docker, oraz uruchamia `OpenClaw Release Checks` dla smoke testów instalacji, akceptacji pakietu, zestawów ścieżki wydania Docker, live/E2E, OpenWebUI, zgodności QA Lab, Matrix i ścieżek Telegram. Może także uruchomić powydaniowy workflow `NPM Telegram Beta E2E`, gdy podano specyfikację opublikowanego pakietu. -`release_profile` kontroluje zakres live/provider przekazywany do kontroli wydania: +`release_profile` steruje zakresem live/provider przekazywanym do kontroli wydania: -- `minimum` zachowuje najszybsze krytyczne dla wydania ścieżki OpenAI/core. +- `minimum` zachowuje najszybsze krytyczne dla wydania ścieżki OpenAI/rdzenia. - `stable` dodaje stabilny zestaw provider/backend. - `full` uruchamia szeroką macierz doradczą provider/media. -Nadrzędny workflow zapisuje identyfikatory uruchomionych workflow potomnych, a końcowe zadanie `Verify full validation` ponownie sprawdza bieżące wyniki workflow potomnych i dołącza tabele najwolniejszych zadań dla każdego uruchomienia potomnego. Jeśli workflow potomny zostanie ponownie uruchomiony i zakończy się powodzeniem, uruchom ponownie tylko zadanie weryfikatora nadrzędnego, aby odświeżyć wynik nadrzędny i podsumowanie czasu. +Workflow nadrzędny zapisuje identyfikatory uruchomionych workflow podrzędnych, a końcowe zadanie `Verify full validation` ponownie sprawdza bieżące konkluzje uruchomień podrzędnych i dołącza tabele najwolniejszych zadań dla każdego uruchomienia podrzędnego. Jeśli workflow podrzędny zostanie uruchomiony ponownie i zakończy się powodzeniem, uruchom ponownie tylko zadanie weryfikujące rodzica, aby odświeżyć wynik workflow nadrzędnego i podsumowanie czasów. -Do odzyskiwania zarówno `Full Release Validation`, jak i `OpenClaw Release Checks` akceptują `rerun_group`. Użyj `all` dla kandydata do wydania, `ci` tylko dla normalnego pełnego workflow potomnego CI, `release-checks` dla każdego potomnego zadania wydania albo węższej grupy: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` lub `npm-telegram` w workflow nadrzędnym. Dzięki temu ponowne uruchomienie nieudanego środowiska wydania pozostaje ograniczone po ukierunkowanej poprawce. +Do odzyskiwania zarówno `Full Release Validation`, jak i `OpenClaw Release Checks` przyjmują `rerun_group`. Użyj `all` dla kandydata do wydania, `ci` tylko dla zwykłego pełnego podrzędnego CI, `release-checks` dla każdego podrzędnego zadania wydania albo węższej grupy: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` lub `npm-telegram` w workflow nadrzędnym. Dzięki temu ponowne uruchomienie nieudanego zestawu wydania pozostaje ograniczone po ukierunkowanej poprawce. -`OpenClaw Release Checks` używa zaufanego ref workflow, aby jednorazowo rozwiązać wybrany ref do tarballa `release-package-under-test`, a następnie przekazuje ten artefakt zarówno do workflow Dockera dla ścieżki wydania live/E2E, jak i do sharda package acceptance. Dzięki temu bajty pakietu pozostają spójne między środowiskami wydania i unika się ponownego pakowania tego samego kandydata w wielu zadaniach potomnych. +`OpenClaw Release Checks` używa zaufanego odniesienia workflow, aby jednorazowo rozwiązać wybrane odniesienie do tarballa `release-package-under-test`, a następnie przekazuje ten artefakt zarówno do workflow Docker ścieżki wydania live/E2E, jak i do sharda akceptacji pakietu. To utrzymuje spójne bajty pakietu między zestawami wydania i unika ponownego pakowania tego samego kandydata w wielu zadaniach podrzędnych. ## Shardy live i E2E -Potomny workflow live/E2E wydania zachowuje szeroki natywny zakres `pnpm test:live`, ale uruchamia go jako nazwane shardy przez `scripts/test-live-shard.mjs` zamiast jednego zadania szeregowego: +Podrzędny workflow wydania live/E2E zachowuje szerokie natywne pokrycie `pnpm test:live`, ale uruchamia je jako nazwane shardy przez `scripts/test-live-shard.mjs` zamiast jednego zadania szeregowego: - `native-live-src-agents` - `native-live-src-gateway-core` -- zadania `native-live-src-gateway-profiles` filtrowane według providera +- filtrowane według providera zadania `native-live-src-gateway-profiles` - `native-live-src-gateway-backends` - `native-live-test` - `native-live-extensions-a-k` @@ -145,57 +145,57 @@ Potomny workflow live/E2E wydania zachowuje szeroki natywny zakres `pnpm test:li - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- rozdzielone shardy mediów audio/wideo oraz shardy muzyki filtrowane według providera +- podzielone shardy audio/wideo mediów oraz filtrowane według providera shardy muzyki -Zachowuje to ten sam zakres plików, a jednocześnie ułatwia ponowne uruchamianie i diagnozowanie wolnych awarii providerów live. Zbiorcze nazwy shardów `native-live-extensions-o-z`, `native-live-extensions-media` i `native-live-extensions-media-music` pozostają prawidłowe dla ręcznych jednorazowych ponownych uruchomień. +Dzięki temu zachowane jest to samo pokrycie plików, a powolne awarie providerów live są łatwiejsze do ponownego uruchomienia i diagnozowania. Nazwy agregatów shardów `native-live-extensions-o-z`, `native-live-extensions-media` i `native-live-extensions-media-music` pozostają prawidłowe dla ręcznych jednorazowych ponownych uruchomień. -Natywne shardy mediów live działają w `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, zbudowanym przez workflow `Live Media Runner Image`. Ten obraz wstępnie instaluje `ffmpeg` i `ffprobe`; zadania mediów przed konfiguracją tylko weryfikują binaria. Zachowaj pakiety testów live oparte na Dockerze na normalnych runnerach Blacksmith — zadania kontenerowe nie są właściwym miejscem do uruchamiania zagnieżdżonych testów Dockera. +Natywne shardy mediów live działają w `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, zbudowanym przez workflow `Live Media Runner Image`. Ten obraz wstępnie instaluje `ffmpeg` i `ffprobe`; zadania mediów tylko weryfikują pliki binarne przed konfiguracją. Utrzymuj zestawy live oparte na Docker na zwykłych runnerach Blacksmith — zadania kontenerowe są niewłaściwym miejscem do uruchamiania zagnieżdżonych testów Docker. -Shardy modeli/backendów live oparte na Dockerze używają osobnego współdzielonego obrazu `ghcr.io/openclaw/openclaw-live-test:` dla wybranego commita. Workflow wydania live buduje i wypycha ten obraz raz, a następnie shardy modelu live Dockera, Gateway, backendu CLI, wiązania ACP i harnessa Codex działają z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Jeśli te shardy niezależnie przebudowują pełny docelowy obraz Dockera ze źródeł, uruchomienie wydania jest błędnie skonfigurowane i zmarnuje czas zegarowy na zduplikowane buildy obrazu. +Shardy modeli/backendów live oparte na Docker używają oddzielnego współdzielonego obrazu `ghcr.io/openclaw/openclaw-live-test:` dla wybranego commita. Workflow wydania live buduje i wypycha ten obraz raz, a następnie shardy modelu live Docker, Gateway, backendu CLI, wiązania ACP i harnessa Codex działają z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Jeśli te shardy niezależnie przebudowują pełny cel źródłowy Docker, uruchomienie wydania jest błędnie skonfigurowane i zmarnuje czas zegarowy na duplikaty kompilacji obrazów. -## Package Acceptance +## Akceptacja pakietu -Użyj `Package Acceptance`, gdy pytanie brzmi: „czy ten instalowalny pakiet OpenClaw działa jako produkt?”. Różni się to od normalnego CI: normalne CI waliduje drzewo źródłowe, a package acceptance waliduje pojedynczy tarball przez ten sam harness Docker E2E, którego użytkownicy używają po instalacji lub aktualizacji. +Użyj `Package Acceptance`, gdy pytanie brzmi: „czy ten instalowalny pakiet OpenClaw działa jako produkt?”. Różni się to od zwykłego CI: zwykłe CI waliduje drzewo źródeł, podczas gdy akceptacja pakietu waliduje pojedynczy tarball przez ten sam harness Docker E2E, którego użytkownicy używają po instalacji lub aktualizacji. ### Zadania -1. `resolve_package` pobiera `workflow_ref`, rozwiązuje jednego kandydata pakietu, zapisuje `.artifacts/docker-e2e-package/openclaw-current.tgz`, zapisuje `.artifacts/docker-e2e-package/package-candidate.json`, przesyła oba jako artefakt `package-under-test` oraz wypisuje źródło, ref workflow, ref pakietu, wersję, SHA-256 i profil w podsumowaniu kroku GitHub. -2. `docker_acceptance` wywołuje `openclaw-live-and-e2e-checks-reusable.yml` z `ref=workflow_ref` i `package_artifact_name=package-under-test`. Workflow wielokrotnego użytku pobiera ten artefakt, waliduje inwentarz tarballa, przygotowuje obrazy Dockera z digestem pakietu, gdy są potrzebne, i uruchamia wybrane ścieżki Dockera względem tego pakietu zamiast pakować pobraną kopię workflow. Gdy profil wybiera wiele ukierunkowanych `docker_lanes`, workflow wielokrotnego użytku przygotowuje pakiet i współdzielone obrazy raz, a następnie rozdziela te ścieżki jako równoległe ukierunkowane zadania Dockera z unikalnymi artefaktami. -3. `package_telegram` opcjonalnie wywołuje `NPM Telegram Beta E2E`. Działa, gdy `telegram_mode` nie jest `none`, i instaluje ten sam artefakt `package-under-test`, gdy Package Acceptance rozwiązało pakiet; samodzielne uruchomienie Telegram nadal może instalować opublikowaną specyfikację npm. -4. `summary` kończy workflow niepowodzeniem, jeśli rozwiązywanie pakietu, Docker acceptance lub opcjonalna ścieżka Telegram zakończyły się niepowodzeniem. +1. `resolve_package` pobiera `workflow_ref`, rozwiązuje jednego kandydata pakietu, zapisuje `.artifacts/docker-e2e-package/openclaw-current.tgz`, zapisuje `.artifacts/docker-e2e-package/package-candidate.json`, przesyła oba jako artefakt `package-under-test` oraz wypisuje źródło, odniesienie workflow, odniesienie pakietu, wersję, SHA-256 i profil w podsumowaniu kroku GitHub. +2. `docker_acceptance` wywołuje `openclaw-live-and-e2e-checks-reusable.yml` z `ref=workflow_ref` i `package_artifact_name=package-under-test`. Workflow wielokrotnego użytku pobiera ten artefakt, waliduje inwentarz tarballa, przygotowuje obrazy Docker z digestem pakietu, gdy są potrzebne, i uruchamia wybrane ścieżki Docker względem tego pakietu zamiast pakować checkout workflow. Gdy profil wybiera wiele ukierunkowanych `docker_lanes`, workflow wielokrotnego użytku przygotowuje pakiet i współdzielone obrazy raz, a następnie rozdziela te ścieżki jako równoległe ukierunkowane zadania Docker z unikalnymi artefaktami. +3. `package_telegram` opcjonalnie wywołuje `NPM Telegram Beta E2E`. Działa, gdy `telegram_mode` nie jest `none`, i instaluje ten sam artefakt `package-under-test`, gdy Package Acceptance rozwiązało jeden; samodzielne uruchomienie Telegram nadal może zainstalować opublikowaną specyfikację npm. +4. `summary` powoduje niepowodzenie workflow, jeśli rozwiązanie pakietu, akceptacja Docker albo opcjonalna ścieżka Telegram zakończyły się niepowodzeniem. ### Źródła kandydatów - `source=npm` akceptuje tylko `openclaw@beta`, `openclaw@latest` albo dokładną wersję wydania OpenClaw, taką jak `openclaw@2026.4.27-beta.2`. Używaj tego do akceptacji opublikowanych wersji beta/stabilnych. -- `source=ref` pakuje zaufaną gałąź, tag lub pełny SHA commita `package_ref`. Resolver pobiera gałęzie/tagi OpenClaw, weryfikuje, że wybrany commit jest osiągalny z historii gałęzi repozytorium lub tagu wydania, instaluje zależności w odłączonym worktree i pakuje go za pomocą `scripts/package-openclaw-for-docker.mjs`. -- `source=url` pobiera `.tgz` przez HTTPS; `package_sha256` jest wymagane. -- `source=artifact` pobiera jeden `.tgz` z `artifact_run_id` i `artifact_name`; `package_sha256` jest opcjonalne, ale powinno zostać podane dla artefaktów udostępnianych zewnętrznie. +- `source=ref` pakuje zaufaną gałąź, tag albo pełny SHA commita `package_ref`. Resolver pobiera gałęzie/tagi OpenClaw, sprawdza, czy wybrany commit jest osiągalny z historii gałęzi repozytorium albo z tagu wydania, instaluje zależności w odłączonym worktree i pakuje go za pomocą `scripts/package-openclaw-for-docker.mjs`. +- `source=url` pobiera HTTPS `.tgz`; `package_sha256` jest wymagane. +- `source=artifact` pobiera jeden `.tgz` z `artifact_run_id` i `artifact_name`; `package_sha256` jest opcjonalne, ale powinno być podane dla artefaktów udostępnianych zewnętrznie. -Trzymaj `workflow_ref` i `package_ref` oddzielnie. `workflow_ref` to zaufany kod workflow/harness, który uruchamia test. `package_ref` to commit źródłowy, który zostaje spakowany, gdy `source=ref`. Dzięki temu bieżący harness testowy może walidować starsze zaufane commity źródłowe bez uruchamiania starej logiki workflow. +Trzymaj `workflow_ref` i `package_ref` oddzielnie. `workflow_ref` to zaufany kod workflow/harnessu, który uruchamia test. `package_ref` to commit źródłowy pakowany, gdy `source=ref`. Dzięki temu bieżący harness testowy może weryfikować starsze zaufane commity źródłowe bez uruchamiania starej logiki workflow. -### Profile zestawów +### Profile zestawu - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload` -- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update` +- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update` - `product` — `package` plus `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` - `full` — pełne fragmenty ścieżki wydania Docker z OpenWebUI - `custom` — dokładne `docker_lanes`; wymagane, gdy `suite_profile=custom` -Profil `package` używa offline pokrycia pluginów, aby walidacja opublikowanego pakietu nie była zależna od dostępności ClawHub na żywo. Opcjonalna ścieżka Telegram ponownie używa artefaktu `package-under-test` w `NPM Telegram Beta E2E`, przy czym opublikowana ścieżka specyfikacji npm pozostaje dostępna dla samodzielnych uruchomień. +Profil `package` używa offline pokrycia pluginów, aby walidacja opublikowanego pakietu nie zależała od dostępności ClawHub na żywo. Opcjonalna ścieżka Telegram ponownie używa artefaktu `package-under-test` w `NPM Telegram Beta E2E`, z zachowaną ścieżką specyfikacji opublikowanego npm dla samodzielnych uruchomień. -Kontrole wydania wywołują Package Acceptance z `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` i `telegram_mode=mock-openai`. Fragmenty Docker ścieżki wydania obejmują nakładające się ścieżki pakietu/aktualizacji/pluginów; Package Acceptance zachowuje natywny dla artefaktu dowód zgodności dołączonego kanału, offline pluginów i Telegram względem tego samego rozwiązanego tarballa pakietu. Międzyplatformowe kontrole wydania nadal obejmują specyficzne dla systemów operacyjnych wdrożenie, instalator i zachowanie platformy; walidacja produktu w zakresie pakietu/aktualizacji powinna zaczynać się od Package Acceptance. Ścieżki świeżej instalacji pakietu i instalatora Windows weryfikują też, że zainstalowany pakiet może importować nadpisanie sterowania przeglądarką z surowej bezwzględnej ścieżki Windows. Międzyplatformowy smoke zwrotu agenta OpenAI domyślnie używa `OPENCLAW_CROSS_OS_OPENAI_MODEL`, gdy jest ustawione, w przeciwnym razie `openai/gpt-5.4-mini`, dzięki czemu dowód instalacji i Gateway pozostaje szybki oraz deterministyczny. +Kontrole wydania wywołują Package Acceptance z `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` oraz `telegram_mode=mock-openai`. Fragmenty Docker ścieżki wydania pokrywają nakładające się ścieżki pakietu/aktualizacji/pluginów; Package Acceptance utrzymuje natywny dla artefaktu dowód zgodności bundled-channel, pluginów offline oraz Telegram względem tego samego rozwiązanego tarballa pakietu. Kontrole wydań między systemami operacyjnymi nadal obejmują specyficzne dla OS zachowanie onboardingu, instalatora i platformy; walidację produktu pakietu/aktualizacji należy zaczynać od Package Acceptance. Ścieżki świeżego pakietu i instalatora Windows sprawdzają także, czy zainstalowany pakiet może zaimportować nadpisanie browser-control z surowej bezwzględnej ścieżki Windows. Smoke między systemami operacyjnymi dla tury agenta OpenAI domyślnie używa `OPENCLAW_CROSS_OS_OPENAI_MODEL`, gdy jest ustawione, w przeciwnym razie `openai/gpt-5.4-mini`, aby dowód instalacji i Gateway pozostał szybki oraz deterministyczny. ### Okna zgodności ze starszymi wersjami Package Acceptance ma ograniczone okna zgodności ze starszymi wersjami dla już opublikowanych pakietów. Pakiety do `2026.4.25` włącznie, w tym `2026.4.25-beta.*`, mogą używać ścieżki zgodności: -- znane prywatne wpisy QA w `dist/postinstall-inventory.json` mogą wskazywać na pliki pominięte w tarballu; +- znane prywatne wpisy QA w `dist/postinstall-inventory.json` mogą wskazywać pliki pominięte w tarballu; - `doctor-switch` może pominąć podprzypadek utrwalania `gateway install --wrapper`, gdy pakiet nie udostępnia tej flagi; -- `update-channel-switch` może przyciąć brakujące `pnpm.patchedDependencies` z fałszywej fixture git pochodzącej z tarballa i może logować brakujące utrwalone `update.channel`; -- smoki pluginów mogą odczytywać starsze lokalizacje rekordów instalacji albo akceptować brak utrwalania rekordu instalacji marketplace; +- `update-channel-switch` może przyciąć brakujące `pnpm.patchedDependencies` z fałszywego fixture git pochodzącego z tarballa i może logować brakujące utrwalone `update.channel`; +- smoke testy pluginów mogą czytać starsze lokalizacje rekordów instalacji albo akceptować brak utrwalenia rekordu instalacji z marketplace; - `plugin-update` może zezwolić na migrację metadanych konfiguracji, nadal wymagając, aby rekord instalacji i zachowanie bez ponownej instalacji pozostały niezmienione. -Opublikowany pakiet `2026.4.26` może też ostrzegać o plikach znaczników metadanych lokalnej kompilacji, które zostały już wydane. Późniejsze pakiety muszą spełniać nowoczesne kontrakty; te same warunki kończą się niepowodzeniem zamiast ostrzeżeniem lub pominięciem. +Opublikowany pakiet `2026.4.26` może także ostrzegać o plikach stempli metadanych lokalnego builda, które zostały już dostarczone. Późniejsze pakiety muszą spełniać nowoczesne kontrakty; te same warunki powodują błąd zamiast ostrzeżenia albo pominięcia. ### Przykłady @@ -238,152 +238,152 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Podczas debugowania nieudanego uruchomienia akceptacji pakietu zacznij od podsumowania `resolve_package`, aby potwierdzić źródło pakietu, wersję i SHA-256. Następnie sprawdź podrzędne uruchomienie `docker_acceptance` oraz jego artefakty Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, logi ścieżek, czasy faz i polecenia ponownego uruchomienia. Preferuj ponowne uruchomienie nieudanego profilu pakietu lub dokładnych ścieżek Docker zamiast ponownego uruchamiania pełnej walidacji wydania. +Podczas debugowania nieudanego uruchomienia akceptacji pakietu zacznij od podsumowania `resolve_package`, aby potwierdzić źródło pakietu, wersję i SHA-256. Następnie sprawdź uruchomienie potomne `docker_acceptance` i jego artefakty Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, logi ścieżek, czasy faz i polecenia ponownego uruchomienia. Preferuj ponowne uruchomienie nieudanego profilu pakietu albo dokładnych ścieżek Docker zamiast ponownego uruchamiania pełnej walidacji wydania. ## Smoke instalacji Oddzielny workflow `Install Smoke` ponownie używa tego samego skryptu zakresu przez własne zadanie `preflight`. Dzieli pokrycie smoke na `run_fast_install_smoke` i `run_full_install_smoke`. -- **Szybka ścieżka** działa dla pull requestów dotykających powierzchni Docker/pakietu, zmian pakietu/manifestu dołączonego pluginu albo powierzchni rdzeniowego pluginu/kanału/Gateway/Plugin SDK, które wykonują zadania smoke Docker. Zmiany wyłącznie źródłowe w dołączonych pluginach, edycje wyłącznie testów i edycje wyłącznie dokumentacji nie rezerwują workerów Docker. Szybka ścieżka buduje obraz głównego Dockerfile raz, sprawdza CLI, uruchamia smoke CLI usuwania agentów ze współdzielonego workspace, uruchamia kontenerowe e2e gateway-network, weryfikuje argument kompilacji dołączonego rozszerzenia i uruchamia ograniczony profil Docker dołączonego pluginu w ramach 240-sekundowego łącznego limitu czasu polecenia (każde uruchomienie Docker scenariusza jest limitowane osobno). -- **Pełna ścieżka** utrzymuje instalację pakietu QR i pokrycie Docker instalatora/aktualizacji dla nocnych zaplanowanych uruchomień, ręcznych uruchomień, kontroli wydania workflow-call oraz pull requestów, które rzeczywiście dotykają powierzchni instalatora/pakietu/Docker. W trybie pełnym install-smoke przygotowuje lub ponownie używa jednego obrazu GHCR smoke głównego Dockerfile dla docelowego SHA, a następnie uruchamia instalację pakietu QR, smoki głównego Dockerfile/Gateway, smoki instalatora/aktualizacji oraz szybkie Docker E2E dołączonego pluginu jako oddzielne zadania, aby praca instalatora nie czekała za smokami obrazu głównego. +- **Szybka ścieżka** uruchamia się dla pull requestów dotykających powierzchni Docker/pakietu, zmian pakietu/manifestu bundled pluginów albo powierzchni core plugin/channel/gateway/Plugin SDK, które wykonują zadania smoke Docker. Zmiany wyłącznie źródłowe w bundled pluginach, edycje tylko testów i edycje tylko dokumentacji nie rezerwują workerów Docker. Szybka ścieżka buduje obraz głównego Dockerfile raz, sprawdza CLI, uruchamia smoke CLI usuwania współdzielonego workspace agentów, uruchamia kontenerowy e2e gateway-network, weryfikuje argument builda bundled extension i uruchamia ograniczony profil Docker bundled-plugin w ramach 240-sekundowego łącznego limitu czasu polecenia (każde uruchomienie Docker scenariusza jest ograniczone osobno). +- **Pełna ścieżka** zachowuje instalację pakietu QR oraz pokrycie Docker instalatora/aktualizacji dla nocnych uruchomień harmonogramu, ręcznych uruchomień, kontroli wydań przez workflow-call i pull requestów, które faktycznie dotykają powierzchni instalatora/pakietu/Docker. W trybie pełnym install-smoke przygotowuje albo ponownie używa jednego obrazu smoke GHCR głównego Dockerfile dla docelowego SHA, a następnie uruchamia instalację pakietu QR, smoke testy głównego Dockerfile/Gateway, smoke testy instalatora/aktualizacji oraz szybkie Docker E2E bundled-plugin jako osobne zadania, aby praca instalatora nie czekała za smoke testami obrazu głównego. -Push do `main` (w tym commity merge) nie wymuszają pełnej ścieżki; gdy logika zakresu zmian żądałaby pełnego pokrycia przy pushu, workflow zachowuje szybki smoke Docker i pozostawia pełny smoke instalacji walidacji nocnej lub wydania. +Push’e do `main` (w tym commity merge) nie wymuszają pełnej ścieżki; gdy logika zakresu zmian zażądałaby pełnego pokrycia przy pushu, workflow zachowuje szybki smoke Docker i pozostawia pełny install smoke walidacji nocnej albo wydaniowej. -Wolny smoke dostawcy obrazu z globalną instalacją Bun jest bramkowany osobno przez `run_bun_global_install_smoke`. Działa w harmonogramie nocnym i z workflow kontroli wydania, a ręczne uruchomienia `Install Smoke` mogą go włączyć, ale pull requesty i pushe do `main` nie. Testy Docker QR i instalatora zachowują własne Dockerfile skoncentrowane na instalacji. +Wolny smoke globalnej instalacji Bun dla image-provider jest osobno bramkowany przez `run_bun_global_install_smoke`. Uruchamia się w nocnym harmonogramie i z workflow kontroli wydań, a ręczne uruchomienia `Install Smoke` mogą go włączyć, ale pull requesty i push’e do `main` nie. Testy Docker QR i instalatora zachowują własne instalacyjne Dockerfile. ## Lokalne Docker E2E -`pnpm test:docker:all` wstępnie buduje jeden współdzielony obraz live-test, pakuje OpenClaw raz jako tarball npm i buduje dwa współdzielone obrazy `scripts/e2e/Dockerfile`: +`pnpm test:docker:all` prebuduje jeden współdzielony obraz live-test, pakuje OpenClaw raz jako tarball npm i buduje dwa współdzielone obrazy `scripts/e2e/Dockerfile`: -- czysty runner Node/Git dla ścieżek instalatora/aktualizacji/zależności pluginów; -- obraz funkcjonalny, który instaluje ten sam tarball w `/app` dla zwykłych ścieżek funkcjonalności. +- surowy runner Node/Git dla ścieżek instalatora/aktualizacji/zależności pluginów; +- funkcjonalny obraz, który instaluje ten sam tarball do `/app` dla normalnych ścieżek funkcjonalnych. -Definicje ścieżek Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`, logika planisty w `scripts/lib/docker-e2e-plan.mjs`, a runner wykonuje tylko wybrany plan. Scheduler wybiera obraz dla każdej ścieżki za pomocą `OPENCLAW_DOCKER_E2E_BARE_IMAGE` i `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, a następnie uruchamia ścieżki z `OPENCLAW_SKIP_DOCKER_BUILD=1`. +Definicje ścieżek Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`, logika planera w `scripts/lib/docker-e2e-plan.mjs`, a runner wykonuje tylko wybrany plan. Scheduler wybiera obraz dla ścieżki za pomocą `OPENCLAW_DOCKER_E2E_BARE_IMAGE` i `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, a następnie uruchamia ścieżki z `OPENCLAW_SKIP_DOCKER_BUILD=1`. ### Parametry dostrajania -| Zmienna | Domyślnie | Cel | -| -------------------------------------- | --------- | --------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Liczba slotów głównej puli dla zwykłych ścieżek. | -| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Liczba slotów puli końcowej wrażliwej na dostawców. | -| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Limit równoczesnych ścieżek live, aby dostawcy nie ograniczali przepustowości. | -| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Limit równoczesnych ścieżek instalacji npm. | -| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Limit równoczesnych ścieżek wielousługowych. | -| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Odstęp między startami ścieżek, aby uniknąć burz tworzenia przez demona Docker; ustaw `0`, aby wyłączyć odstęp. | -| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Zapasowy limit czasu na ścieżkę (120 minut); wybrane ścieżki live/końcowe używają ciaśniejszych limitów. | -| `OPENCLAW_DOCKER_ALL_DRY_RUN` | nieustawione | `1` wypisuje plan schedulera bez uruchamiania ścieżek. | -| `OPENCLAW_DOCKER_ALL_LANES` | nieustawione | Lista dokładnych ścieżek rozdzielona przecinkami; pomija smoke czyszczenia, aby agenci mogli odtworzyć jedną nieudaną ścieżkę. | +| Variable | Default | Purpose | +| -------------------------------------- | ------- | --------------------------------------------------------------------------------------------- | +| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Liczba slotów puli głównej dla normalnych ścieżek. | +| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Liczba slotów puli końcowej wrażliwej na dostawców. | +| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Limit równoczesnych ścieżek live, aby dostawcy nie throttlowali. | +| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Limit równoczesnych ścieżek instalacji npm. | +| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Limit równoczesnych ścieżek wielousługowych. | +| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Odstęp między startami ścieżek, aby uniknąć burz tworzenia w daemonie Docker; ustaw `0`, aby wyłączyć odstęp. | +| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Zapasowy limit czasu na ścieżkę (120 minut); wybrane ścieżki live/tail używają ciaśniejszych limitów. | +| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` wypisuje plan schedulera bez uruchamiania ścieżek. | +| `OPENCLAW_DOCKER_ALL_LANES` | unset | Rozdzielona przecinkami dokładna lista ścieżek; pomija cleanup smoke, aby agenci mogli odtworzyć jedną nieudaną ścieżkę. | -Ścieżka cięższa niż jej efektywny limit nadal może wystartować z pustej puli, a następnie działa sama, dopóki nie zwolni pojemności. Lokalny agregat wykonuje preflight Docker, usuwa przestarzałe kontenery OpenClaw E2E, emituje status aktywnych ścieżek, utrwala czasy ścieżek do porządkowania od najdłuższych i domyślnie zatrzymuje planowanie nowych ścieżek z puli po pierwszym niepowodzeniu. +Ścieżka cięższa niż jej efektywny limit może nadal wystartować z pustej puli, a następnie działa sama, dopóki nie zwolni pojemności. Lokalny agregat wykonuje preflight Docker, usuwa przestarzałe kontenery OpenClaw E2E, emituje status aktywnych ścieżek, utrwala czasy ścieżek dla kolejności od najdłuższych i domyślnie przestaje planować nowe ścieżki z puli po pierwszym błędzie. ### Wielokrotnego użytku workflow live/E2E -Wielokrotnego użytku workflow live/E2E pyta `scripts/test-docker-all.mjs --plan-json`, jaki pakiet, rodzaj obrazu, obraz live, ścieżka i pokrycie poświadczeń są wymagane. `scripts/docker-e2e.mjs` następnie konwertuje ten plan na wyjścia i podsumowania GitHub. Albo pakuje OpenClaw przez `scripts/package-openclaw-for-docker.mjs`, pobiera artefakt pakietu z bieżącego uruchomienia, albo pobiera artefakt pakietu z `package_artifact_run_id`; waliduje inwentarz tarballa; buduje i wypycha tagowane digestem pakietu obrazy GHCR Docker E2E bare/functional przez cache warstw Docker Blacksmith, gdy plan potrzebuje ścieżek z zainstalowanym pakietem; oraz ponownie używa podanych wejść `docker_e2e_bare_image`/`docker_e2e_functional_image` lub istniejących obrazów z digestem pakietu zamiast przebudowy. Pobierania obrazów Docker są ponawiane z ograniczonym 180-sekundowym limitem czasu na próbę, aby zablokowany strumień registry/cache był szybko ponawiany zamiast zużywać większość krytycznej ścieżki CI. +Wielokrotnego użytku workflow live/E2E pyta `scripts/test-docker-all.mjs --plan-json`, jaki pakiet, rodzaj obrazu, obraz live, ścieżka i pokrycie poświadczeń są wymagane. `scripts/docker-e2e.mjs` następnie konwertuje ten plan na wyjścia i podsumowania GitHub. Albo pakuje OpenClaw przez `scripts/package-openclaw-for-docker.mjs`, pobiera artefakt pakietu z bieżącego uruchomienia, albo pobiera artefakt pakietu z `package_artifact_run_id`; waliduje inventory tarballa; buduje i wypycha tagowane digestem pakietu obrazy bare/functional GHCR Docker E2E przez cache warstw Docker Blacksmith, gdy plan potrzebuje ścieżek z zainstalowanym pakietem; oraz ponownie używa podanych wejść `docker_e2e_bare_image`/`docker_e2e_functional_image` albo istniejących obrazów z digestem pakietu zamiast przebudowywać. Pobrania obrazów Docker są ponawiane z ograniczonym 180-sekundowym limitem czasu na próbę, aby zablokowany strumień registry/cache szybko ponowił próbę zamiast zużywać większość ścieżki krytycznej CI. ### Fragmenty ścieżki wydania -Pokrycie Docker wydania uruchamia mniejsze pofragmentowane zadania z `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby każdy fragment pobierał tylko potrzebny rodzaj obrazu i wykonywał wiele ścieżek przez ten sam ważony scheduler: +Pokrycie Docker wydania uruchamia mniejsze fragmentowane zadania z `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby każdy fragment pobierał tylko potrzebny rodzaj obrazu i wykonywał wiele ścieżek przez ten sam ważony scheduler: - `OPENCLAW_DOCKER_ALL_PROFILE=release-path` - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | bundled-channels` -Bieżące części wydania Docker to `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, od `plugins-runtime-install-a` do `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` oraz `bundled-channels-contracts`. Zbiorcza część `bundled-channels` pozostaje dostępna do ręcznych, jednorazowych ponownych uruchomień, a `plugins-runtime-core`, `plugins-runtime` i `plugins-integrations` pozostają zbiorczymi aliasami plugin/runtime. Alias linii `install-e2e` pozostaje zbiorczym aliasem ręcznego ponownego uruchomienia dla obu linii instalatorów dostawców. Część `bundled-channels` uruchamia podzielone linie `bundled-channel-*` i `bundled-channel-update-*` zamiast szeregowej, całościowej linii `bundled-channel-deps`. +Obecne fragmenty Docker wydania to `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, od `plugins-runtime-install-a` do `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` oraz `bundled-channels-contracts`. Zbiorczy fragment `bundled-channels` pozostaje dostępny do ręcznych, jednorazowych ponowień, a `plugins-runtime-core`, `plugins-runtime` i `plugins-integrations` pozostają zbiorczymi aliasami Plugin/runtime. Alias pasa `install-e2e` pozostaje zbiorczym aliasem ręcznego ponowienia dla obu pasów instalatora dostawców. Fragment `bundled-channels` uruchamia podzielone pasy `bundled-channel-*` i `bundled-channel-update-*` zamiast szeregowego pasa all-in-one `bundled-channel-deps`. -OpenWebUI jest włączany do `plugins-runtime-services`, gdy wymaga tego pełne pokrycie ścieżki wydania, i zachowuje samodzielną część `openwebui` tylko dla uruchomień dotyczących wyłącznie OpenWebUI. Linie aktualizacji kanałów w pakiecie ponawiają próbę raz w przypadku przejściowych awarii sieci npm. +OpenWebUI jest włączany do `plugins-runtime-services`, gdy wymaga tego pełne pokrycie ścieżki wydania, i zachowuje samodzielny fragment `openwebui` tylko dla wywołań dotyczących wyłącznie OpenWebUI. Pasy aktualizacji kanałów wbudowanych ponawiają próbę raz w przypadku przejściowych awarii sieci npm. -Każda część przesyła `.artifacts/docker-tests/` z dziennikami linii, czasami, `summary.json`, `failures.json`, czasami faz, JSON planu harmonogramu, tabelami wolnych linii i poleceniami ponownego uruchomienia dla poszczególnych linii. Wejście workflow `docker_lanes` uruchamia wybrane linie względem przygotowanych obrazów zamiast zadań części, dzięki czemu debugowanie nieudanych linii jest ograniczone do jednego ukierunkowanego zadania Docker i przygotowuje, pobiera albo ponownie używa artefaktu pakietu dla tego uruchomienia; jeśli wybrana linia jest linią live Docker, ukierunkowane zadanie buduje lokalnie obraz testów live na potrzeby tego ponownego uruchomienia. Wygenerowane polecenia GitHub ponownego uruchomienia dla poszczególnych linii zawierają `package_artifact_run_id`, `package_artifact_name` i wejścia przygotowanych obrazów, gdy te wartości istnieją, dzięki czemu nieudana linia może ponownie użyć dokładnie tego pakietu i tych obrazów z nieudanego uruchomienia. +Każdy fragment przesyła `.artifacts/docker-tests/` z logami pasów, czasami, `summary.json`, `failures.json`, czasami faz, JSON planu harmonogramu, tabelami wolnych pasów i poleceniami ponownego uruchomienia dla poszczególnych pasów. Wejście workflow `docker_lanes` uruchamia wybrane pasy względem przygotowanych obrazów zamiast zadań fragmentów, co ogranicza debugowanie pasa z błędem do jednego docelowego zadania Docker i przygotowuje, pobiera lub ponownie wykorzystuje artefakt pakietu dla tego uruchomienia; jeśli wybrany pas jest pasem live Docker, docelowe zadanie buduje lokalnie obraz live-test dla tego ponowienia. Wygenerowane polecenia GitHub do ponowienia dla poszczególnych pasów zawierają `package_artifact_run_id`, `package_artifact_name` i wejścia przygotowanych obrazów, gdy te wartości istnieją, dzięki czemu pas z błędem może ponownie użyć dokładnie tego pakietu i tych obrazów z nieudanego uruchomienia. ```bash pnpm test:docker:rerun # download Docker artifacts and print combined/per-lane targeted rerun commands pnpm test:docker:timings # slow-lane and phase critical-path summaries ``` -Zaplanowany workflow live/E2E uruchamia codziennie pełny zestaw Docker dla ścieżki wydania. +Zaplanowany workflow live/E2E codziennie uruchamia pełny zestaw Docker ścieżki wydania. -## Wersja przedpremierowa Plugin +## Przedpremiera Plugin -`Plugin Prerelease` zapewnia droższe pokrycie produktu/pakietu, więc jest osobnym workflow uruchamianym przez `Full Release Validation` albo przez jawnego operatora. Zwykłe pull requesty, wypchnięcia do `main` i samodzielne ręczne uruchomienia CI nie włączają tego zestawu. Równoważy testy Plugin w pakiecie między ośmioma workerami rozszerzeń; te zadania shardów rozszerzeń uruchamiają do dwóch grup konfiguracji Plugin naraz, z jednym workerem Vitest na grupę i większą stertą Node, aby partie Plugin intensywnie importujące moduły nie tworzyły dodatkowych zadań CI. +`Plugin Prerelease` zapewnia droższe pokrycie produktu/pakietu, dlatego jest osobnym workflow wywoływanym przez `Full Release Validation` albo jawnie przez operatora. Zwykłe pull requesty, wypchnięcia do `main` i samodzielne ręczne wywołania CI nie uruchamiają tego zestawu. Równoważy testy wbudowanych Plugin między ośmioma workerami rozszerzeń; te zadania shardów rozszerzeń uruchamiają do dwóch grup konfiguracji Plugin naraz, z jednym workerem Vitest na grupę i większą stertą Node, aby partie Plugin intensywnie używające importów nie tworzyły dodatkowych zadań CI. ## QA Lab -QA Lab ma dedykowane linie CI poza głównym workflow o inteligentnym zakresie. +QA Lab ma dedykowane pasy CI poza głównym workflow o inteligentnym zakresie. -- Workflow `Parity gate` uruchamia się przy pasujących zmianach PR i ręcznym uruchomieniu; buduje prywatne środowisko uruchomieniowe QA i porównuje agentowe pakiety mock GPT-5.5 oraz Opus 4.6. -- Workflow `QA-Lab - All Lanes` uruchamia się co noc na `main` i przy ręcznym uruchomieniu; rozdziela bramkę parytetu mock, linię live Matrix oraz linie live Telegram i Discord jako zadania równoległe. Zadania live używają środowiska `qa-live-shared`, a Telegram/Discord używają dzierżaw Convex. +- Workflow `Parity gate` uruchamia się przy pasujących zmianach PR i ręcznym wywołaniu; buduje prywatny runtime QA i porównuje mockowe pakiety agentowe GPT-5.5 oraz Opus 4.6. +- Workflow `QA-Lab - All Lanes` uruchamia się co noc na `main` i przy ręcznym wywołaniu; rozdziela mockową bramkę parzystości, live pas Matrix oraz live pasy Telegram i Discord jako równoległe zadania. Zadania live używają środowiska `qa-live-shared`, a Telegram/Discord używają dzierżaw Convex. -Kontrole wydania uruchamiają linie transportu live Matrix i Telegram z deterministycznym dostawcą mock oraz modelami kwalifikowanymi jako mock (`mock-openai/gpt-5.5` i `mock-openai/gpt-5.5-alt`), aby kontrakt kanału był odizolowany od opóźnień modelu live i normalnego uruchamiania Plugin dostawcy. Gateway transportu live wyłącza wyszukiwanie pamięci, ponieważ parytet QA obejmuje zachowanie pamięci osobno; łączność dostawcy jest obejmowana przez osobne zestawy modelu live, natywnego dostawcy i dostawcy Docker. +Kontrole wydania uruchamiają live pasy transportu Matrix i Telegram z deterministycznym mockowym dostawcą oraz modelami zakwalifikowanymi jako mock (`mock-openai/gpt-5.5` i `mock-openai/gpt-5.5-alt`), aby kontrakt kanału był odizolowany od opóźnień live modelu i normalnego uruchamiania provider-plugin. Live transport gateway wyłącza wyszukiwanie pamięci, ponieważ parzystość QA osobno obejmuje zachowanie pamięci; łączność dostawcy jest objęta osobnymi zestawami live model, native provider i Docker provider. -Matrix używa `--profile fast` dla zaplanowanych bramek i bramek wydania, dodając `--fail-fast` tylko wtedy, gdy sprawdzony CLI to obsługuje. Domyślna wartość CLI i ręczne wejście workflow pozostają `all`; ręczne uruchomienie `matrix_profile=all` zawsze dzieli pełne pokrycie Matrix na zadania `transport`, `media`, `e2ee-smoke`, `e2ee-deep` i `e2ee-cli`. +Matrix używa `--profile fast` dla zaplanowanych bramek i bramek wydania, dodając `--fail-fast` tylko wtedy, gdy obsługuje to sprawdzony CLI. Domyślna wartość CLI i ręczne wejście workflow pozostają `all`; ręczne wywołanie `matrix_profile=all` zawsze dzieli pełne pokrycie Matrix na zadania `transport`, `media`, `e2ee-smoke`, `e2ee-deep` i `e2ee-cli`. -`OpenClaw Release Checks` uruchamia też krytyczne dla wydania linie QA Lab przed zatwierdzeniem wydania; jego bramka parytetu QA uruchamia pakiety kandydujące i bazowe jako równoległe zadania linii, a następnie pobiera oba artefakty do małego zadania raportującego na potrzeby końcowego porównania parytetu. +`OpenClaw Release Checks` uruchamia również krytyczne dla wydania pasy QA Lab przed zatwierdzeniem wydania; jego bramka parzystości QA uruchamia pakiety kandydata i bazowe jako równoległe zadania pasów, a następnie pobiera oba artefakty do małego zadania raportu na potrzeby końcowego porównania parzystości. -Nie umieszczaj ścieżki lądowania PR za `Parity gate`, chyba że zmiana rzeczywiście dotyka środowiska uruchomieniowego QA, parytetu pakietów modeli albo powierzchni, którą posiada workflow parytetu. W przypadku zwykłych poprawek kanałów, konfiguracji, dokumentacji albo testów jednostkowych traktuj to jako opcjonalny sygnał i kieruj się dowodami z CI/kontroli o odpowiednim zakresie. +Nie umieszczaj ścieżki lądowania PR za `Parity gate`, chyba że zmiana rzeczywiście dotyka runtime QA, parzystości pakietów modeli albo powierzchni należącej do workflow parzystości. W przypadku zwykłych poprawek kanałów, konfiguracji, dokumentacji lub testów jednostkowych traktuj to jako opcjonalny sygnał i korzystaj z dowodów z właściwego zakresu CI/kontroli. ## CodeQL -Workflow `CodeQL` jest celowo wąskim skanerem bezpieczeństwa pierwszego przebiegu, a nie pełnym przeglądem repozytorium. Codzienne, ręczne i ochronne uruchomienia pull requestów innych niż wersje robocze skanują kod workflow Actions oraz powierzchnie JavaScript/TypeScript o najwyższym ryzyku, używając zapytań bezpieczeństwa o wysokiej pewności filtrowanych do wysokiego/krytycznego `security-severity`. +Workflow `CodeQL` jest celowo wąskim skanerem bezpieczeństwa pierwszego przejścia, a nie pełnym przeglądem repozytorium. Codzienne, ręczne oraz ochronne uruchomienia dla pull requestów innych niż szkic skanują kod workflow Actions oraz powierzchnie JavaScript/TypeScript najwyższego ryzyka za pomocą zapytań bezpieczeństwa o wysokiej pewności, filtrowanych do `security-severity` high/critical. -Ochrona pull requestów pozostaje lekka: uruchamia się tylko dla zmian w `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` lub `src` i uruchamia tę samą macierz bezpieczeństwa o wysokiej pewności co zaplanowany workflow. Android i macOS CodeQL pozostają poza domyślnymi ustawieniami PR. +Ochrona pull requestów pozostaje lekka: uruchamia się tylko dla zmian pod `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` lub `src` i wykonuje tę samą macierz bezpieczeństwa o wysokiej pewności co zaplanowany workflow. Android i macOS CodeQL pozostają poza domyślnymi PR. ### Kategorie bezpieczeństwa | Kategoria | Powierzchnia | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-security-high/core-auth-secrets` | Uwierzytelnianie, sekrety, piaskownica, cron i bazowy Gateway | -| `/codeql-security-high/channel-runtime-boundary` | Kontrakty implementacji kanałów core oraz środowisko uruchomieniowe Plugin kanałów, Gateway, Plugin SDK, sekrety, punkty styku audytu | -| `/codeql-security-high/network-ssrf-boundary` | Powierzchnie core SSRF, parsowanie IP, straż sieciowa, web-fetch oraz polityka SSRF Plugin SDK | -| `/codeql-security-high/mcp-process-tool-boundary` | Serwery MCP, pomocniki wykonywania procesów, dostarczanie wychodzące i bramki wykonywania narzędzi agentów | -| `/codeql-security-high/plugin-trust-boundary` | Instalacja Plugin, loader, manifest, rejestr, staging zależności runtime, ładowanie źródeł i powierzchnie zaufania kontraktu pakietu Plugin SDK | +| `/codeql-security-high/core-auth-secrets` | Auth, sekrety, sandbox, cron i bazowy gateway | +| `/codeql-security-high/channel-runtime-boundary` | Kontrakty implementacji kanałów core oraz runtime Plugin kanału, gateway, Plugin SDK, sekrety, punkty styku audytu | +| `/codeql-security-high/network-ssrf-boundary` | Powierzchnie core SSRF, parsowania IP, ochrony sieci, web-fetch i polityki SSRF Plugin SDK | +| `/codeql-security-high/mcp-process-tool-boundary` | Serwery MCP, helpery wykonywania procesów, dostarczanie wychodzące i bramki wykonywania narzędzi agenta | +| `/codeql-security-high/plugin-trust-boundary` | Instalacja Plugin, loader, manifest, registry, etapowanie zależności runtime, ładowanie źródeł i powierzchnie zaufania kontraktu pakietu Plugin SDK | ### Shardy bezpieczeństwa specyficzne dla platform - `CodeQL Android Critical Security` — zaplanowany shard bezpieczeństwa Android. Buduje aplikację Android ręcznie dla CodeQL na najmniejszym runnerze Blacksmith Linux akceptowanym przez workflow sanity. Przesyła pod `/codeql-critical-security/android`. -- `CodeQL macOS Critical Security` — tygodniowy/ręczny shard bezpieczeństwa macOS. Buduje aplikację macOS ręcznie dla CodeQL na Blacksmith macOS, filtruje wyniki budowania zależności z przesyłanego SARIF i przesyła pod `/codeql-critical-security/macos`. Trzymany poza codziennymi domyślnymi ustawieniami, ponieważ kompilacja macOS dominuje czas działania nawet wtedy, gdy jest czysta. +- `CodeQL macOS Critical Security` — tygodniowy/ręczny shard bezpieczeństwa macOS. Buduje aplikację macOS ręcznie dla CodeQL na Blacksmith macOS, odfiltrowuje wyniki budowania zależności z przesyłanego SARIF i przesyła pod `/codeql-critical-security/macos`. Utrzymywany poza codziennymi domyślnymi uruchomieniami, ponieważ budowanie macOS dominuje czas wykonania nawet przy czystym stanie. ### Kategorie jakości krytycznej -`CodeQL Critical Quality` to odpowiadający shard niezwiązany z bezpieczeństwem. Uruchamia tylko zapytania jakości JavaScript/TypeScript o ważności błędu, niezwiązane z bezpieczeństwem, na wąskich powierzchniach o wysokiej wartości na mniejszym runnerze Blacksmith Linux. Jego ochrona pull requestów jest celowo mniejsza niż zaplanowany profil: PR-y inne niż wersje robocze uruchamiają tylko odpowiadające shardy `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` i `plugin-sdk-reply-runtime` dla zmian w kodzie wykonywania poleceń/modeli/narzędzi agenta i wysyłania odpowiedzi, kodzie schematów/migracji/IO konfiguracji, kodzie uwierzytelniania/sekretów/piaskownicy/bezpieczeństwa, core kanału i środowisku uruchomieniowym Plugin kanałów w pakiecie, protokole Gateway/metodach serwera, spoiwie runtime/SDK pamięci, MCP/procesie/dostarczaniu wychodzącym, runtime dostawcy/katalogu modeli, diagnostyce sesji/kolejkach dostarczania, loaderze Plugin, kontrakcie Plugin SDK/pakietu albo runtime odpowiedzi Plugin SDK. Zmiany konfiguracji CodeQL i workflow jakości uruchamiają wszystkie dwanaście shardów jakości PR. +`CodeQL Critical Quality` to odpowiadający shard niezwiązany z bezpieczeństwem. Uruchamia tylko zapytania jakości JavaScript/TypeScript o poziomie błędu i niezwiązane z bezpieczeństwem, na wąskich powierzchniach o wysokiej wartości, na mniejszym runnerze Blacksmith Linux. Jego ochrona pull requestów jest celowo mniejsza niż profil zaplanowany: PR inne niż szkic uruchamiają tylko pasujące shardy `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` i `plugin-sdk-reply-runtime` dla zmian w kodzie poleceń/modeli/wykonywania narzędzi agenta i dyspozycji odpowiedzi, kodzie schematu/migracji/IO konfiguracji, kodzie auth/sekretów/sandboxu/bezpieczeństwa, core channel i runtime wbudowanych channel plugin, gateway protocol/server-method, runtime pamięci/spoiwie SDK, MCP/procesie/dostarczaniu wychodzącym, runtime dostawcy/katalogu modeli, diagnostyce sesji/kolejkach dostarczania, loaderze Plugin, Plugin SDK/kontrakcie pakietu albo runtime odpowiedzi Plugin SDK. Zmiany konfiguracji CodeQL i workflow jakości uruchamiają wszystkie dwanaście shardów jakości PR. -Ręczne uruchomienie akceptuje: +Ręczne wywołanie akceptuje: ``` profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary ``` -Wąskie profile są punktami zaczepienia do nauki/iteracji, służącymi do uruchamiania jednego sharda jakości w izolacji. +Wąskie profile są zaczepami szkoleniowymi/iteracyjnymi do uruchamiania jednego shardu jakości w izolacji. -| Kategoria | Powierzchnia | -| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-critical-quality/core-auth-secrets` | Uwierzytelnianie, sekrety, piaskownica, Cron oraz kod granicy zabezpieczeń Gateway | -| `/codeql-critical-quality/config-boundary` | Schemat konfiguracji, migracja, normalizacja oraz kontrakty IO | -| `/codeql-critical-quality/gateway-runtime-boundary` | Schematy protokołu Gateway oraz kontrakty metod serwera | -| `/codeql-critical-quality/channel-runtime-boundary` | Kontrakty implementacji kanału rdzenia oraz dołączonego Plugin kanału | -| `/codeql-critical-quality/agent-runtime-boundary` | Wykonywanie poleceń, dyspozycja modeli/dostawców, dyspozycja i kolejki automatycznych odpowiedzi oraz kontrakty środowiska wykonawczego płaszczyzny sterowania ACP | -| `/codeql-critical-quality/mcp-process-runtime-boundary` | Serwery MCP i mosty narzędzi, pomocniki nadzoru procesów oraz kontrakty dostarczania wychodzącego | -| `/codeql-critical-quality/memory-runtime-boundary` | SDK hosta pamięci, fasady środowiska wykonawczego pamięci, aliasy SDK Plugin pamięci, warstwa aktywacji środowiska wykonawczego pamięci oraz polecenia doctor pamięci | -| `/codeql-critical-quality/session-diagnostics-boundary` | Wewnętrzna logika kolejki odpowiedzi, kolejki dostarczania sesji, pomocniki wiązania/dostarczania sesji wychodzących, powierzchnie pakietów zdarzeń/logów diagnostycznych oraz kontrakty CLI doctor sesji | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Dyspozycja odpowiedzi przychodzących SDK Plugin, pomocniki ładunku odpowiedzi/fragmentacji/środowiska wykonawczego, opcje odpowiedzi kanału, kolejki dostarczania oraz pomocniki wiązania sesji/wątku | -| `/codeql-critical-quality/provider-runtime-boundary` | Normalizacja katalogu modeli, uwierzytelnianie i odkrywanie dostawców, rejestracja środowiska wykonawczego dostawców, domyślne ustawienia/katalogi dostawców oraz rejestry web/search/fetch/embedding | -| `/codeql-critical-quality/ui-control-plane` | Bootstrap interfejsu sterowania, lokalna trwałość danych, przepływy sterowania Gateway oraz kontrakty środowiska wykonawczego płaszczyzny sterowania zadań | -| `/codeql-critical-quality/web-media-runtime-boundary` | Kontrakty środowiska wykonawczego bazowego pobierania/wyszukiwania WWW, IO mediów, rozumienia mediów, generowania obrazów oraz generowania mediów | -| `/codeql-critical-quality/plugin-boundary` | Kontrakty punktów wejścia loadera, rejestru, powierzchni publicznej oraz SDK Plugin | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Opublikowane źródło SDK Plugin po stronie pakietu oraz pomocniki kontraktu pakietu Plugin | +| Kategoria | Powierzchnia | +| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `/codeql-critical-quality/core-auth-secrets` | Kod granicy bezpieczeństwa Auth, sekretów, piaskownicy, Cron i Gateway | +| `/codeql-critical-quality/config-boundary` | Schemat konfiguracji, migracja, normalizacja i kontrakty IO | +| `/codeql-critical-quality/gateway-runtime-boundary` | Schematy protokołu Gateway i kontrakty metod serwera | +| `/codeql-critical-quality/channel-runtime-boundary` | Kontrakty implementacji głównego kanału i dołączonego kanału Plugin | +| `/codeql-critical-quality/agent-runtime-boundary` | Wykonywanie poleceń, dyspozycja modeli/dostawców, dyspozycja i kolejki automatycznych odpowiedzi oraz kontrakty środowiska wykonawczego płaszczyzny sterowania ACP | +| `/codeql-critical-quality/mcp-process-runtime-boundary` | Serwery MCP i mosty narzędziowe, pomocniki nadzoru procesów oraz kontrakty dostarczania wychodzącego | +| `/codeql-critical-quality/memory-runtime-boundary` | SDK hosta pamięci, fasady środowiska wykonawczego pamięci, aliasy SDK pamięci Plugin, kod wiążący aktywację środowiska wykonawczego pamięci oraz polecenia doctor pamięci | +| `/codeql-critical-quality/session-diagnostics-boundary` | Wewnętrzne elementy kolejki odpowiedzi, kolejki dostarczania sesji, pomocniki wiązania/dostarczania sesji wychodzących, powierzchnie pakietów zdarzeń/logów diagnostycznych oraz kontrakty CLI doctor sesji | +| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Dyspozycja odpowiedzi przychodzących w SDK Plugin, pomocniki ładunków/kawałkowania/środowiska wykonawczego odpowiedzi, opcje odpowiedzi kanału, kolejki dostarczania oraz pomocniki wiązania sesji/wątków | +| `/codeql-critical-quality/provider-runtime-boundary` | Normalizacja katalogu modeli, uwierzytelnianie i wykrywanie dostawców, rejestracja środowiska wykonawczego dostawców, domyślne ustawienia/katalogi dostawców oraz rejestry web/search/fetch/embedding | +| `/codeql-critical-quality/ui-control-plane` | Inicjalizacja Control UI, lokalna trwałość danych, przepływy sterowania Gateway oraz kontrakty środowiska wykonawczego płaszczyzny sterowania zadaniami | +| `/codeql-critical-quality/web-media-runtime-boundary` | Kontrakty środowiska wykonawczego głównego pobierania/wyszukiwania w sieci, IO multimediów, rozumienia multimediów, generowania obrazów i generowania multimediów | +| `/codeql-critical-quality/plugin-boundary` | Kontrakty loadera, rejestru, powierzchni publicznej i punktów wejścia SDK Plugin | +| `/codeql-critical-quality/plugin-sdk-package-contract` | Opublikowane źródło SDK Plugin po stronie pakietu i pomocniki kontraktu pakietu Plugin | -Jakość pozostaje oddzielona od bezpieczeństwa, aby ustalenia jakościowe można było planować, mierzyć, wyłączać lub rozszerzać bez zaciemniania sygnału bezpieczeństwa. Rozszerzenie CodeQL dla Swift, Python i dołączonych Plugin należy dodać ponownie jako zawężone lub podzielone na odłamki prace następcze dopiero wtedy, gdy wąskie profile będą miały stabilne środowisko wykonawcze i sygnał. +Jakość pozostaje oddzielona od bezpieczeństwa, aby ustalenia jakościowe można było planować, mierzyć, wyłączać lub rozszerzać bez zaciemniania sygnału bezpieczeństwa. Rozszerzenie CodeQL dla Swift, Python i dołączonych Plugin powinno zostać ponownie dodane jako zakresowane lub shardowane prace następcze dopiero po ustabilizowaniu środowiska wykonawczego i sygnału w wąskich profilach. -## Przepływy prac utrzymaniowych +## Przepływy utrzymania -### Docs Agent +### Agent dokumentacji -Przepływ pracy `Docs Agent` to sterowana zdarzeniami ścieżka utrzymaniowa Codex służąca utrzymywaniu istniejącej dokumentacji w zgodności z niedawno wylądowanymi zmianami. Nie ma czystego harmonogramu: może go wyzwolić udane uruchomienie CI po wypchnięciu przez użytkownika innego niż bot do `main`, a ręczne wywołanie może uruchomić go bezpośrednio. Wywołania przez workflow-run są pomijane, gdy `main` przesunął się dalej albo gdy w ostatniej godzinie utworzono inne niepominięte uruchomienie Docs Agent. Gdy działa, przegląda zakres commitów od poprzedniego niepominiętego źródłowego SHA Docs Agent do bieżącego `main`, więc jedno godzinowe uruchomienie może objąć wszystkie zmiany w main nagromadzone od ostatniego przejścia przez dokumentację. +Workflow `Docs Agent` to sterowana zdarzeniami ścieżka utrzymania Codex, która utrzymuje istniejącą dokumentację w zgodności z niedawno wprowadzonymi zmianami. Nie ma czystego harmonogramu: udane uruchomienie CI dla wypchnięcia na `main` przez użytkownika innego niż bot może ją wyzwolić, a ręczne wywołanie może uruchomić ją bezpośrednio. Wywołania workflow-run są pomijane, gdy `main` przesunął się dalej albo gdy w ostatniej godzinie utworzono inne niepominięte uruchomienie Docs Agent. Gdy działa, przegląda zakres commitów od poprzedniego niepominiętego źródłowego SHA Docs Agent do bieżącego `main`, więc jedno godzinne uruchomienie może objąć wszystkie zmiany na main zgromadzone od ostatniego przebiegu dokumentacji. -### Test Performance Agent +### Agent wydajności testów -Przepływ pracy `Test Performance Agent` to sterowana zdarzeniami ścieżka utrzymaniowa Codex dla wolnych testów. Nie ma czystego harmonogramu: może go wyzwolić udane uruchomienie CI po wypchnięciu przez użytkownika innego niż bot do `main`, ale pomija się, jeśli tego dnia UTC inne wywołanie przez workflow-run już zostało uruchomione lub jest uruchomione. Ręczne wywołanie omija tę dzienną bramkę aktywności. Ścieżka buduje zgrupowany raport wydajności pełnego zestawu Vitest, pozwala Codex wprowadzać tylko niewielkie poprawki wydajności testów zachowujące pokrycie zamiast szerokich refaktoryzacji, następnie ponownie uruchamia raport pełnego zestawu i odrzuca zmiany, które zmniejszają bazową liczbę przechodzących testów. Jeśli baza ma testy kończące się niepowodzeniem, Codex może naprawiać tylko oczywiste awarie, a raport pełnego zestawu po agencie musi przejść, zanim cokolwiek zostanie zatwierdzone. Gdy `main` przesunie się przed wylądowaniem wypchnięcia bota, ścieżka wykonuje rebase zweryfikowanej poprawki, ponownie uruchamia `pnpm check:changed` i ponawia wypchnięcie; konfliktujące nieaktualne poprawki są pomijane. Używa Ubuntu hostowanego przez GitHub, aby akcja Codex mogła zachować tę samą bezpieczną postawę bez sudo co agent dokumentacji. +Workflow `Test Performance Agent` to sterowana zdarzeniami ścieżka utrzymania Codex dla wolnych testów. Nie ma czystego harmonogramu: udane uruchomienie CI dla wypchnięcia na `main` przez użytkownika innego niż bot może ją wyzwolić, ale jest pomijana, jeśli inne wywołanie workflow-run już działało lub działa danego dnia UTC. Ręczne wywołanie omija tę dzienną bramkę aktywności. Ścieżka buduje raport wydajności zgrupowanego pełnego zestawu Vitest, pozwala Codex wprowadzać tylko małe, zachowujące pokrycie poprawki wydajności testów zamiast szerokich refaktoryzacji, następnie ponownie uruchamia raport pełnego zestawu i odrzuca zmiany, które zmniejszają bazową liczbę przechodzących testów. Jeśli baza ma testy zakończone niepowodzeniem, Codex może naprawiać tylko oczywiste awarie, a raport pełnego zestawu po agencie musi przejść, zanim cokolwiek zostanie zatwierdzone. Gdy `main` posunie się naprzód, zanim wypchnięcie bota trafi do repozytorium, ścieżka wykonuje rebase zweryfikowanej poprawki, ponownie uruchamia `pnpm check:changed` i ponawia wypchnięcie; konfliktujące nieaktualne poprawki są pomijane. Używa GitHub-hosted Ubuntu, aby akcja Codex mogła zachować tę samą postawę bezpieczeństwa drop-sudo co agent dokumentacji. ### Zduplikowane PR po scaleniu -Przepływ pracy `Duplicate PRs After Merge` to ręczny przepływ pracy maintainerów do sprzątania duplikatów po wylądowaniu. Domyślnie działa w trybie dry-run i zamyka tylko jawnie wymienione PR, gdy `apply=true`. Przed mutacją GitHub weryfikuje, że wylądowany PR jest scalony oraz że każdy duplikat ma albo wspólny wskazywany problem, albo nakładające się zmienione fragmenty. +Workflow `Duplicate PRs After Merge` to ręczny workflow utrzymaniowy dla osób utrzymujących, służący do sprzątania duplikatów po wylądowaniu zmian. Domyślnie działa jako dry-run i zamyka tylko jawnie wymienione PR, gdy `apply=true`. Przed modyfikacją GitHub weryfikuje, że PR, który wylądował, został scalony oraz że każdy duplikat ma albo wspólne przywołane zgłoszenie, albo nakładające się zmienione hunki. ```bash gh workflow run duplicate-after-merge.yml \ @@ -392,27 +392,27 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Lokalne bramki sprawdzania i trasowanie zmian +## Lokalne bramki sprawdzania i routing zmian -Lokalna logika changed-lane znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka sprawdzania jest bardziej rygorystyczna wobec granic architektury niż szeroki zakres platformy CI: +Logika lokalnych ścieżek zmian znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka sprawdzania jest surowsza wobec granic architektury niż szeroki zakres platformy CI: -- zmiany produkcyjne rdzenia uruchamiają typecheck produkcji rdzenia i testów rdzenia oraz lint/strażników rdzenia; -- zmiany wyłącznie w testach rdzenia uruchamiają tylko typecheck testów rdzenia oraz lint rdzenia; +- zmiany produkcyjne core uruchamiają typecheck produkcji core i testów core oraz lint/guardy core; +- zmiany wyłącznie w testach core uruchamiają tylko typecheck testów core oraz lint core; - zmiany produkcyjne rozszerzeń uruchamiają typecheck produkcji rozszerzeń i testów rozszerzeń oraz lint rozszerzeń; - zmiany wyłącznie w testach rozszerzeń uruchamiają typecheck testów rozszerzeń oraz lint rozszerzeń; -- zmiany publicznego SDK Plugin lub kontraktu Plugin rozszerzają się do typecheck rozszerzeń, ponieważ rozszerzenia zależą od tych kontraktów rdzenia (przemiatania rozszerzeń Vitest pozostają jawną pracą testową); -- zmiany wersji obejmujące wyłącznie metadane wydań uruchamiają ukierunkowane sprawdzenia wersji/konfiguracji/zależności katalogu głównego; -- nieznane zmiany katalogu głównego/konfiguracji dla bezpieczeństwa przechodzą do wszystkich ścieżek sprawdzania. +- publiczne zmiany SDK Plugin lub kontraktu Plugin rozszerzają zakres do typecheck rozszerzeń, ponieważ rozszerzenia zależą od tych kontraktów core (przebiegi rozszerzeń Vitest pozostają jawną pracą testową); +- wersjonowania obejmujące tylko metadane wydania uruchamiają ukierunkowane sprawdzenia wersji/konfiguracji/zależności root; +- nieznane zmiany root/konfiguracji przechodzą bezpiecznie na wszystkie ścieżki sprawdzania. -Lokalne trasowanie changed-test znajduje się w `scripts/test-projects.test-support.mjs` i jest celowo tańsze niż `check:changed`: bezpośrednie edycje testów uruchamiają same siebie, edycje źródeł preferują jawne mapowania, a potem testy siostrzane i zależności z grafu importów. Współdzielona konfiguracja dostarczania do pokoju grupowego jest jednym z jawnych mapowań: zmiany konfiguracji odpowiedzi widocznych dla grupy, trybu dostarczania odpowiedzi źródłowych lub systemowego promptu narzędzia wiadomości przechodzą przez bazowe testy odpowiedzi oraz regresje dostarczania Discord i Slack, aby zmiana współdzielonej wartości domyślnej zakończyła się niepowodzeniem przed pierwszym wypchnięciem PR. Używaj `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` tylko wtedy, gdy zmiana jest na tyle szeroka dla harnessu, że tani zmapowany zestaw nie jest wiarygodnym przybliżeniem. +Lokalny routing zmienionych testów znajduje się w `scripts/test-projects.test-support.mjs` i celowo jest tańszy niż `check:changed`: bezpośrednie edycje testów uruchamiają same siebie, edycje źródeł preferują jawne mapowania, następnie testy siostrzane i zależności z grafu importów. Wspólna konfiguracja dostarczania group-room jest jednym z jawnych mapowań: zmiany w konfiguracji widocznych odpowiedzi grupowych, trybie dostarczania odpowiedzi źródłowych lub systemowym prompcie narzędzia wiadomości przechodzą przez główne testy odpowiedzi oraz regresje dostarczania Discord i Slack, aby wspólna zmiana domyślna zakończyła się niepowodzeniem przed pierwszym wypchnięciem PR. Używaj `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` tylko wtedy, gdy zmiana jest na tyle szeroka dla całego harnessu, że tani zmapowany zestaw nie jest wiarygodnym przybliżeniem. ## Walidacja Testbox -Uruchamiaj Testbox z katalogu głównego repozytorium i preferuj świeżo rozgrzany box dla szerokiego dowodu. Przed poświęceniem wolnej bramki na box, który został użyty ponownie, wygasł lub właśnie zgłosił nieoczekiwanie dużą synchronizację, uruchom najpierw `pnpm testbox:sanity` wewnątrz boxa. +Uruchamiaj Testbox z katalogu głównego repozytorium i preferuj świeżo rozgrzane pudełko do szerokiego dowodu. Przed przeznaczeniem wolnej bramki na pudełko, które zostało ponownie użyte, wygasło albo właśnie zgłosiło nieoczekiwanie dużą synchronizację, najpierw uruchom `pnpm testbox:sanity` wewnątrz pudełka. -Sprawdzenie sanity szybko kończy się niepowodzeniem, gdy wymagane pliki katalogu głównego, takie jak `pnpm-lock.yaml`, zniknęły albo gdy `git status --short` pokazuje co najmniej 200 śledzonych usunięć. Zwykle oznacza to, że zdalny stan synchronizacji nie jest wiarygodną kopią PR; zatrzymaj ten box i rozgrzej świeży zamiast debugować awarię testu produktu. Dla celowych PR z dużymi usunięciami ustaw `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` dla tego uruchomienia sanity. +Sprawdzenie sanity szybko kończy się niepowodzeniem, gdy wymagane pliki root, takie jak `pnpm-lock.yaml`, zniknęły albo gdy `git status --short` pokazuje co najmniej 200 śledzonych usunięć. Zwykle oznacza to, że zdalny stan synchronizacji nie jest wiarygodną kopią PR; zatrzymaj to pudełko i rozgrzej świeże zamiast debugować awarię testu produktu. Dla celowych PR z dużą liczbą usunięć ustaw `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` dla tego przebiegu sanity. -`pnpm testbox:run` kończy również lokalne wywołanie Blacksmith CLI, które pozostaje w fazie synchronizacji przez ponad pięć minut bez wyjścia po synchronizacji. Ustaw `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, aby wyłączyć tę osłonę, albo użyj większej wartości w milisekundach dla nietypowo dużych lokalnych różnic. +`pnpm testbox:run` kończy także lokalne wywołanie Blacksmith CLI, które pozostaje w fazie synchronizacji przez ponad pięć minut bez danych wyjściowych po synchronizacji. Ustaw `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, aby wyłączyć tę osłonę, albo użyj większej wartości w milisekundach dla wyjątkowo dużych lokalnych różnic. ## Powiązane diff --git a/docs/pl/concepts/agent-loop.md b/docs/pl/concepts/agent-loop.md index 70648aa6e..13fd807ce 100644 --- a/docs/pl/concepts/agent-loop.md +++ b/docs/pl/concepts/agent-loop.md @@ -1,184 +1,185 @@ --- read_when: - - Potrzebujesz dokładnego omówienia krok po kroku pętli agenta lub zdarzeń cyklu życia - - Zmieniasz kolejkowanie sesji, zapisy transkryptu albo zachowanie blokady zapisu sesji + - Potrzebujesz dokładnego przewodnika po pętli agenta lub zdarzeniach cyklu życia + - Zmieniasz kolejkowanie sesji, zapisywanie transkrypcji lub działanie blokady zapisu sesji summary: Cykl życia pętli agenta, strumienie i semantyka oczekiwania title: Pętla agenta x-i18n: - generated_at: "2026-04-30T09:46:17Z" + generated_at: "2026-04-30T18:39:00Z" model: gpt-5.5 provider: openai - source_hash: 902d543bd71dd517a810d825cbe92e244fe89230f47eeada72477c657a2bec32 + source_hash: 5466893253e1f82482284ff82db56f4c3fca018bf12e4114fad76d37cad954df source_path: concepts/agent-loop.md workflow: 16 --- -Pętla agentowa to pełne „rzeczywiste” uruchomienie agenta: przyjęcie danych wejściowych → złożenie kontekstu → inferencja modelu → +Pętla agentowa to pełny „rzeczywisty” przebieg agenta: przyjęcie danych wejściowych → złożenie kontekstu → inferencja modelu → wykonanie narzędzi → strumieniowanie odpowiedzi → utrwalenie. To autorytatywna ścieżka, która zamienia wiadomość -w działania i końcową odpowiedź, jednocześnie utrzymując spójny stan sesji. +w działania i końcową odpowiedź, utrzymując spójny stan sesji. -W OpenClaw pętla to pojedyncze, serializowane uruchomienie na sesję, które emituje zdarzenia cyklu życia i strumienia, -gdy model myśli, wywołuje narzędzia i strumieniuje dane wyjściowe. Ten dokument wyjaśnia, jak ta autentyczna pętla jest -połączona od końca do końca. +W OpenClaw pętla jest pojedynczym, serializowanym przebiegiem na sesję, który emituje zdarzenia cyklu życia i strumienia, +gdy model rozumuje, wywołuje narzędzia i strumieniuje wynik. Ten dokument wyjaśnia, jak ta autentyczna pętla jest +połączona od początku do końca. ## Punkty wejścia -- RPC Gateway: `agent` i `agent.wait`. +- Gateway RPC: `agent` i `agent.wait`. - CLI: polecenie `agent`. -## Jak to działa (wysoki poziom) +## Jak to działa (ogólnie) -1. RPC `agent` waliduje parametry, rozwiązuje sesję (sessionKey/sessionId), utrwala metadane sesji i natychmiast zwraca `{ runId, acceptedAt }`. +1. RPC `agent` weryfikuje parametry, rozwiązuje sesję (`sessionKey`/`sessionId`), utrwala metadane sesji i natychmiast zwraca `{ runId, acceptedAt }`. 2. `agentCommand` uruchamia agenta: - - rozwiązuje model oraz domyślne ustawienia myślenia/verbose/trace - - wczytuje migawkę Skills - - wywołuje `runEmbeddedPiAgent` (środowisko uruchomieniowe pi-agent-core) - - emituje **koniec/błąd cyklu życia**, jeśli osadzona pętla go nie wyemituje + - rozwiązuje model oraz domyślne wartości myślenia/szczegółowości/śledzenia + - ładuje migawkę Skills + - wywołuje `runEmbeddedPiAgent` (środowisko uruchomieniowe `pi-agent-core`) + - emituje **zakończenie/błąd cyklu życia**, jeśli osadzona pętla tego nie zrobi 3. `runEmbeddedPiAgent`: - - serializuje uruchomienia przez kolejki na sesję i globalne - - rozwiązuje model oraz profil uwierzytelniania i buduje sesję Pi - - subskrybuje zdarzenia Pi i strumieniuje delty asystenta/narzędzi - - wymusza limit czasu -> przerywa uruchomienie po jego przekroczeniu - - zwraca payloady oraz metadane użycia -4. `subscribeEmbeddedPiSession` łączy zdarzenia pi-agent-core ze strumieniem `agent` OpenClaw: + - serializuje przebiegi przez kolejki na sesję i kolejki globalne + - rozwiązuje model oraz profil uwierzytelniania i buduje sesję pi + - subskrybuje zdarzenia pi i strumieniuje delty asystenta/narzędzi + - wymusza limit czasu -> przerywa przebieg po jego przekroczeniu + - dla tur serwera aplikacji Codex przerywa zaakceptowaną turę, która przestaje generować postęp serwera aplikacji przed zdarzeniem końcowym + - zwraca ładunki i metadane użycia +4. `subscribeEmbeddedPiSession` łączy zdarzenia `pi-agent-core` ze strumieniem `agent` OpenClaw: - zdarzenia narzędzi => `stream: "tool"` - delty asystenta => `stream: "assistant"` - zdarzenia cyklu życia => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`) 5. `agent.wait` używa `waitForAgentRun`: - - czeka na **koniec/błąd cyklu życia** dla `runId` + - czeka na **zakończenie/błąd cyklu życia** dla `runId` - zwraca `{ status: ok|error|timeout, startedAt, endedAt, error? }` -## Kolejkowanie + współbieżność +## Kolejkowanie i współbieżność -- Uruchomienia są serializowane według klucza sesji (pas sesji) i opcjonalnie przez pas globalny. +- Przebiegi są serializowane według klucza sesji (ścieżka sesji) i opcjonalnie przez ścieżkę globalną. - Zapobiega to wyścigom narzędzi/sesji i utrzymuje spójną historię sesji. -- Kanały komunikacji mogą wybierać tryby kolejek (collect/steer/followup), które zasilają ten system pasów. +- Kanały komunikacji mogą wybierać tryby kolejkowania (zbieranie/sterowanie/kontynuacja), które zasilają ten system ścieżek. Zobacz [Kolejka poleceń](/pl/concepts/queue). -- Zapisy transkrypcji są także chronione przez blokadę zapisu sesji na pliku sesji. Blokada jest - świadoma procesu i oparta na pliku, więc wychwytuje zapisujących, którzy omijają kolejkę w procesie lub pochodzą +- Zapisy transkrypcji są także chronione blokadą zapisu sesji na pliku sesji. Blokada jest + świadoma procesów i oparta na plikach, więc wychwytuje zapisujących, którzy omijają kolejkę w procesie albo pochodzą z innego procesu. -- Blokady zapisu sesji domyślnie nie są reentrantne. Jeśli helper celowo zagnieżdża pozyskanie - tej samej blokady, zachowując jednego logicznego zapisującego, musi jawnie się na to zdecydować przez +- Blokady zapisu sesji domyślnie nie są reentrantne. Jeśli pomocnik celowo zagnieżdża pozyskanie + tej samej blokady, zachowując jednego logicznego zapisującego, musi jawnie się na to zdecydować za pomocą `allowReentrant: true`. -## Przygotowanie sesji + obszaru roboczego +## Przygotowanie sesji i przestrzeni roboczej -- Obszar roboczy jest rozwiązywany i tworzony; uruchomienia w piaskownicy mogą przekierować do katalogu głównego obszaru roboczego piaskownicy. -- Skills są wczytywane (lub ponownie używane z migawki) i wstrzykiwane do env oraz promptu. -- Pliki bootstrap/kontekstowe są rozwiązywane i wstrzykiwane do raportu promptu systemowego. +- Przestrzeń robocza jest rozwiązywana i tworzona; przebiegi w piaskownicy mogą przekierować do katalogu głównego przestrzeni roboczej piaskownicy. +- Skills są ładowane (albo ponownie używane z migawki) i wstrzykiwane do środowiska oraz promptu. +- Pliki rozruchowe/kontekstowe są rozwiązywane i wstrzykiwane do raportu promptu systemowego. - Pozyskiwana jest blokada zapisu sesji; `SessionManager` jest otwierany i przygotowywany przed strumieniowaniem. Każda - późniejsza ścieżka przepisywania transkrypcji, Compaction lub obcinania musi uzyskać tę samą blokadę przed otwarciem lub + późniejsza ścieżka przepisywania, Compaction albo skracania transkrypcji musi pozyskać tę samą blokadę przed otwarciem albo modyfikacją pliku transkrypcji. -## Składanie promptu + prompt systemowy +## Składanie promptu i prompt systemowy -- Prompt systemowy jest budowany z bazowego promptu OpenClaw, promptu Skills, kontekstu bootstrap i nadpisań na uruchomienie. -- Limity specyficzne dla modelu i tokeny rezerwowe Compaction są wymuszane. +- Prompt systemowy jest budowany z bazowego promptu OpenClaw, promptu Skills, kontekstu rozruchowego i nadpisań dla danego przebiegu. +- Wymuszane są limity specyficzne dla modelu oraz tokeny rezerwy Compaction. - Zobacz [Prompt systemowy](/pl/concepts/system-prompt), aby sprawdzić, co widzi model. -## Punkty hooków (gdzie możesz przechwytywać) +## Punkty zaczepienia (gdzie można przechwycić) OpenClaw ma dwa systemy hooków: - **Hooki wewnętrzne** (hooki Gateway): skrypty sterowane zdarzeniami dla poleceń i zdarzeń cyklu życia. -- **Hooki Plugin**: punkty rozszerzeń wewnątrz cyklu życia agenta/narzędzia i potoku Gateway. +- **Hooki Plugin**: punkty rozszerzeń wewnątrz cyklu życia agenta/narzędzia i potoku gateway. ### Hooki wewnętrzne (hooki Gateway) -- **`agent:bootstrap`**: działa podczas budowania plików bootstrap, zanim prompt systemowy zostanie sfinalizowany. - Użyj tego, aby dodać/usunąć pliki kontekstu bootstrap. -- **Hooki poleceń**: `/new`, `/reset`, `/stop` i inne zdarzenia poleceń (zobacz dokument o Hookach). +- **`agent:bootstrap`**: działa podczas budowania plików rozruchowych, zanim prompt systemowy zostanie sfinalizowany. + Użyj tego, aby dodać/usunąć pliki kontekstu rozruchowego. +- **Hooki poleceń**: `/new`, `/reset`, `/stop` i inne zdarzenia poleceń (zobacz dokumentację hooków). Zobacz [Hooki](/pl/automation/hooks), aby poznać konfigurację i przykłady. -### Hooki Plugin (cykl życia agenta + Gateway) +### Hooki Plugin (cykl życia agenta i gateway) -Działają wewnątrz pętli agenta lub potoku Gateway: +Działają wewnątrz pętli agenta albo potoku gateway: - **`before_model_resolve`**: działa przed sesją (bez `messages`), aby deterministycznie nadpisać dostawcę/model przed rozwiązaniem modelu. -- **`before_prompt_build`**: działa po wczytaniu sesji (z `messages`), aby wstrzyknąć `prependContext`, `systemPrompt`, `prependSystemContext` lub `appendSystemContext` przed wysłaniem promptu. Użyj `prependContext` dla dynamicznego tekstu na turę, a pól kontekstu systemowego dla stabilnych wskazówek, które powinny znajdować się w przestrzeni promptu systemowego. -- **`before_agent_start`**: starszy hook kompatybilności, który może działać w dowolnej fazie; preferuj jawne hooki powyżej. -- **`before_agent_reply`**: działa po działaniach inline i przed wywołaniem LLM, pozwalając Plugin przejąć turę i zwrócić syntetyczną odpowiedź albo całkowicie wyciszyć turę. -- **`agent_end`**: sprawdza końcową listę wiadomości i metadane uruchomienia po zakończeniu. -- **`before_compaction` / `after_compaction`**: obserwuje lub adnotuje cykle Compaction. +- **`before_prompt_build`**: działa po załadowaniu sesji (z `messages`), aby wstrzyknąć `prependContext`, `systemPrompt`, `prependSystemContext` albo `appendSystemContext` przed wysłaniem promptu. Użyj `prependContext` dla dynamicznego tekstu na turę, a pól kontekstu systemowego dla stabilnych wskazówek, które powinny znaleźć się w przestrzeni promptu systemowego. +- **`before_agent_start`**: starszy hook zgodności, który może działać w obu fazach; preferuj jawne hooki powyżej. +- **`before_agent_reply`**: działa po akcjach wbudowanych i przed wywołaniem LLM, pozwalając Plugin przejąć turę i zwrócić syntetyczną odpowiedź albo całkowicie wyciszyć turę. +- **`agent_end`**: sprawdza końcową listę wiadomości i metadane przebiegu po zakończeniu. +- **`before_compaction` / `after_compaction`**: obserwuje albo adnotuje cykle Compaction. - **`before_tool_call` / `after_tool_call`**: przechwytuje parametry/wyniki narzędzi. -- **`before_install`**: sprawdza wbudowane wyniki skanowania i opcjonalnie blokuje instalacje Skills lub Plugin. -- **`tool_result_persist`**: synchronicznie przekształca wyniki narzędzi, zanim zostaną zapisane w transkrypcji sesji należącej do OpenClaw. +- **`before_install`**: sprawdza wbudowane wyniki skanowania i opcjonalnie blokuje instalacje Skills albo Plugin. +- **`tool_result_persist`**: synchronicznie przekształca wyniki narzędzi przed zapisaniem ich do transkrypcji sesji należącej do OpenClaw. - **`message_received` / `message_sending` / `message_sent`**: hooki wiadomości przychodzących i wychodzących. - **`session_start` / `session_end`**: granice cyklu życia sesji. -- **`gateway_start` / `gateway_stop`**: zdarzenia cyklu życia Gateway. +- **`gateway_start` / `gateway_stop`**: zdarzenia cyklu życia gateway. -Reguły decyzyjne hooków dla strażników wychodzących/narzędzi: +Reguły decyzji hooków dla zabezpieczeń wychodzących/narzędzi: - `before_tool_call`: `{ block: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie. -- `before_tool_call`: `{ block: false }` nic nie robi i nie usuwa wcześniejszej blokady. +- `before_tool_call`: `{ block: false }` jest operacją bez efektu i nie usuwa wcześniejszej blokady. - `before_install`: `{ block: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie. -- `before_install`: `{ block: false }` nic nie robi i nie usuwa wcześniejszej blokady. +- `before_install`: `{ block: false }` jest operacją bez efektu i nie usuwa wcześniejszej blokady. - `message_sending`: `{ cancel: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie. -- `message_sending`: `{ cancel: false }` nic nie robi i nie usuwa wcześniejszego anulowania. +- `message_sending`: `{ cancel: false }` jest operacją bez efektu i nie usuwa wcześniejszego anulowania. Zobacz [Hooki Plugin](/pl/plugins/hooks), aby poznać API hooków i szczegóły rejestracji. -Harnessy mogą różnie adaptować te hooki. Harness serwera aplikacji Codex zachowuje -hooki Plugin OpenClaw jako kontrakt kompatybilności dla udokumentowanych powierzchni lustrzanych, -podczas gdy natywne hooki Codex pozostają oddzielnym, niższopoziomowym mechanizmem Codex. +Uprzęże mogą dostosowywać te hooki inaczej. Uprząż serwera aplikacji Codex zachowuje +hooki Plugin OpenClaw jako kontrakt zgodności dla udokumentowanych powierzchni lustrzanych, +podczas gdy natywne hooki Codex pozostają osobnym mechanizmem Codex niższego poziomu. -## Strumieniowanie + częściowe odpowiedzi +## Strumieniowanie i częściowe odpowiedzi -- Delty asystenta są strumieniowane z pi-agent-core i emitowane jako zdarzenia `assistant`. -- Strumieniowanie bloków może emitować częściowe odpowiedzi na `text_end` albo `message_end`. -- Strumieniowanie rozumowania może być emitowane jako oddzielny strumień albo jako odpowiedzi blokowe. -- Zobacz [Strumieniowanie](/pl/concepts/streaming), aby poznać zachowanie fragmentowania i odpowiedzi blokowych. +- Delty asystenta są strumieniowane z `pi-agent-core` i emitowane jako zdarzenia `assistant`. +- Strumieniowanie blokowe może emitować częściowe odpowiedzi przy `text_end` albo `message_end`. +- Strumieniowanie rozumowania może być emitowane jako osobny strumień albo jako odpowiedzi blokowe. +- Zobacz [Strumieniowanie](/pl/concepts/streaming), aby poznać dzielenie na fragmenty i zachowanie odpowiedzi blokowych. -## Wykonywanie narzędzi + narzędzia komunikacji +## Wykonywanie narzędzi i narzędzia wiadomości -- Zdarzenia start/update/end narzędzi są emitowane w strumieniu `tool`. -- Wyniki narzędzi są oczyszczane pod kątem rozmiaru i payloadów obrazów przed logowaniem/emitowaniem. -- Wysyłki narzędzi komunikacji są śledzone, aby tłumić zduplikowane potwierdzenia asystenta. +- Zdarzenia rozpoczęcia/aktualizacji/zakończenia narzędzia są emitowane w strumieniu `tool`. +- Wyniki narzędzi są oczyszczane pod kątem rozmiaru i ładunków obrazów przed logowaniem/emitowaniem. +- Wysłania narzędzi wiadomości są śledzone, aby tłumić zduplikowane potwierdzenia asystenta. -## Kształtowanie odpowiedzi + tłumienie +## Kształtowanie i tłumienie odpowiedzi -- Końcowe payloady są składane z: +- Końcowe ładunki są składane z: - tekstu asystenta (i opcjonalnego rozumowania) - - podsumowań narzędzi inline (gdy verbose + dozwolone) - - tekstu błędu asystenta, gdy model zgłasza błąd + - wbudowanych podsumowań narzędzi (gdy szczegółowość jest włączona i dozwolona) + - tekstu błędu asystenta, gdy model zwraca błąd - Dokładny cichy token `NO_REPLY` / `no_reply` jest filtrowany z wychodzących - payloadów. -- Duplikaty narzędzi komunikacji są usuwane z końcowej listy payloadów. -- Jeśli nie pozostaną żadne renderowalne payloady, a narzędzie zwróciło błąd, emitowana jest zastępcza odpowiedź błędu narzędzia - (chyba że narzędzie komunikacji już wysłało widoczną dla użytkownika odpowiedź). + ładunków. +- Duplikaty narzędzi wiadomości są usuwane z końcowej listy ładunków. +- Jeśli nie pozostaną żadne renderowalne ładunki, a narzędzie zwróciło błąd, emitowana jest zastępcza odpowiedź błędu narzędzia + (chyba że narzędzie wiadomości już wysłało odpowiedź widoczną dla użytkownika). -## Compaction + ponowne próby +## Compaction i ponowne próby -- Auto-Compaction emituje zdarzenia strumienia `compaction` i może wywołać ponowną próbę. -- Przy ponownej próbie bufory w pamięci i podsumowania narzędzi są resetowane, aby uniknąć zduplikowanych danych wyjściowych. +- Automatyczna Compaction emituje zdarzenia strumienia `compaction` i może wywołać ponowną próbę. +- Przy ponownej próbie bufory w pamięci i podsumowania narzędzi są resetowane, aby uniknąć zduplikowanego wyniku. - Zobacz [Compaction](/pl/concepts/compaction), aby poznać potok Compaction. ## Strumienie zdarzeń (obecnie) -- `lifecycle`: emitowany przez `subscribeEmbeddedPiSession` (i awaryjnie przez `agentCommand`) -- `assistant`: strumieniowane delty z pi-agent-core -- `tool`: strumieniowane zdarzenia narzędzi z pi-agent-core +- `lifecycle`: emitowany przez `subscribeEmbeddedPiSession` (oraz awaryjnie przez `agentCommand`) +- `assistant`: strumieniowane delty z `pi-agent-core` +- `tool`: strumieniowane zdarzenia narzędzi z `pi-agent-core` -## Obsługa kanału czatu +## Obsługa kanałów czatu - Delty asystenta są buforowane w wiadomościach czatu `delta`. -- Chat `final` jest emitowany przy **końcu/błędzie cyklu życia**. +- `final` czatu jest emitowane przy **zakończeniu/błędzie cyklu życia**. ## Limity czasu -- Domyślnie `agent.wait`: 30 s (tylko oczekiwanie). Parametr `timeoutMs` nadpisuje tę wartość. -- Środowisko uruchomieniowe agenta: domyślne `agents.defaults.timeoutSeconds` to 172800 s (48 godzin); wymuszane przez timer przerwania w `runEmbeddedPiAgent`. -- Środowisko uruchomieniowe Cron: izolowane `timeoutSeconds` tury agenta należy do cron. Harmonogram uruchamia ten timer, gdy wykonanie się zaczyna, przerywa bazowe uruchomienie w skonfigurowanym terminie, a następnie wykonuje ograniczone sprzątanie przed zapisaniem limitu czasu, aby nieaktualna sesja potomna nie mogła zablokować pasa. -- Odzyskiwanie zablokowanej sesji: przy włączonej diagnostyce `diagnostics.stuckSessionWarnMs` wykrywa długie sesje `processing`. Aktywne osadzone uruchomienia, aktywne operacje odpowiedzi i aktywne zadania pasa sesji domyślnie pozostają tylko ostrzeżeniami; jeśli diagnostyka nie pokazuje aktywnej pracy dla sesji, watchdog zwalnia dotknięty pas sesji, aby zakolejkowana praca startowa mogła się opróżnić. -- Limit bezczynności modelu: OpenClaw przerywa żądanie modelu, gdy przed upływem okna bezczynności nie przyjdą żadne fragmenty odpowiedzi. `models.providers..timeoutSeconds` wydłuża ten watchdog bezczynności dla wolnych lokalnych/samodzielnie hostowanych dostawców; w przeciwnym razie OpenClaw używa `agents.defaults.timeoutSeconds`, gdy jest skonfigurowane, domyślnie z limitem 120 s. Uruchomienia wyzwalane przez Cron bez jawnego limitu czasu modelu lub agenta wyłączają watchdog bezczynności i polegają na zewnętrznym limicie czasu cron. -- Limit czasu żądania HTTP dostawcy: `models.providers..timeoutSeconds` stosuje się do pobrań HTTP modelu tego dostawcy, w tym połączenia, nagłówków, treści, limitu czasu żądania SDK, całkowitej obsługi przerwania chronionego fetch oraz watchdog bezczynności strumienia modelu. Używaj tego dla wolnych lokalnych/samodzielnie hostowanych dostawców, takich jak Ollama, zanim zwiększysz limit czasu całego środowiska uruchomieniowego agenta. +- Domyślne `agent.wait`: 30 s (tylko oczekiwanie). Parametr `timeoutMs` nadpisuje tę wartość. +- Środowisko uruchomieniowe agenta: domyślne `agents.defaults.timeoutSeconds` wynosi 172800 s (48 godzin); wymuszane w timerze przerwania `runEmbeddedPiAgent`. +- Środowisko uruchomieniowe Cron: izolowany `timeoutSeconds` tury agenta jest własnością cron. Harmonogram uruchamia ten timer, gdy rozpoczyna się wykonanie, przerywa bazowy przebieg przy skonfigurowanym terminie, a następnie uruchamia ograniczone sprzątanie przed zapisaniem limitu czasu, aby przestarzała sesja podrzędna nie mogła zablokować ścieżki. +- Odzyskiwanie zablokowanej sesji: przy włączonej diagnostyce `diagnostics.stuckSessionWarnMs` wykrywa długo trwające sesje `processing`. Aktywne osadzone przebiegi, aktywne operacje odpowiedzi i aktywne zadania ścieżki sesji domyślnie pozostają tylko ostrzeżeniami; jeśli diagnostyka nie pokazuje aktywnej pracy dla sesji, watchdog zwalnia dotkniętą ścieżkę sesji, aby zakolejkowana praca startowa mogła się opróżnić. +- Limit bezczynności modelu: OpenClaw przerywa żądanie modelu, gdy przed upływem okna bezczynności nie nadejdą żadne fragmenty odpowiedzi. `models.providers..timeoutSeconds` wydłuża ten watchdog bezczynności dla wolnych lokalnych/samohostowanych dostawców; w przeciwnym razie OpenClaw używa `agents.defaults.timeoutSeconds`, gdy jest skonfigurowane, domyślnie ograniczone do 120 s. Przebiegi wyzwalane przez Cron bez jawnego limitu czasu modelu lub agenta wyłączają watchdog bezczynności i polegają na zewnętrznym limicie czasu cron. +- Limit czasu żądania HTTP dostawcy: `models.providers..timeoutSeconds` dotyczy żądań HTTP fetch modelu tego dostawcy, w tym połączenia, nagłówków, treści, limitu czasu żądania SDK, całkowitej obsługi przerwania chronionego fetch oraz watchdoga bezczynności strumienia modelu. Użyj tego dla wolnych lokalnych/samohostowanych dostawców, takich jak Ollama, zanim zwiększysz limit czasu całego środowiska uruchomieniowego agenta. ## Gdzie rzeczy mogą zakończyć się wcześniej - Limit czasu agenta (przerwanie) - AbortSignal (anulowanie) -- Rozłączenie Gateway lub limit czasu RPC +- Rozłączenie Gateway albo limit czasu RPC - Limit czasu `agent.wait` (tylko oczekiwanie, nie zatrzymuje agenta) ## Powiązane diff --git a/docs/pl/concepts/queue.md b/docs/pl/concepts/queue.md index 951c311db..33e8db4b1 100644 --- a/docs/pl/concepts/queue.md +++ b/docs/pl/concepts/queue.md @@ -5,28 +5,28 @@ read_when: summary: Tryby kolejki automatycznych odpowiedzi, wartości domyślne i nadpisania dla poszczególnych sesji title: Kolejka poleceń x-i18n: - generated_at: "2026-04-30T09:49:53Z" + generated_at: "2026-04-30T18:39:00Z" model: gpt-5.5 provider: openai - source_hash: 2ac0c0ded9558b080714fa4b8be0d552f985911bf19b427020f9654ae4955b2d + source_hash: fbf1bb1ffd4ce06fa138f63e31651b8821226d9c95dd6b93d68326a5fb91fdd0 source_path: concepts/queue.md workflow: 16 --- -Serializujemy przychodzące uruchomienia automatycznych odpowiedzi (wszystkie kanały) przez małą kolejkę w procesie, aby zapobiec kolizjom wielu uruchomień agenta, jednocześnie nadal pozwalając na bezpiełą równoległość między sesjami. +Serializujemy przychodzące uruchomienia automatycznych odpowiedzi (wszystkie kanały) przez niewielką kolejkę w procesie, aby zapobiec kolizjom między wieloma uruchomieniami agenta, jednocześnie nadal pozwalając na bezpieczną równoległość między sesjami. ## Dlaczego -- Uruchomienia automatycznych odpowiedzi mogą być kosztowne (wywołania LLM) i mogą kolidować, gdy wiele przychodzących wiadomości pojawia się blisko siebie. -- Serializacja pozwala uniknąć rywalizacji o współdzielone zasoby (pliki sesji, logi, stdin CLI) i zmniejsza ryzyko limitów szybkości po stronie dostawcy. +- Uruchomienia automatycznych odpowiedzi mogą być kosztowne (wywołania LLM) i mogą kolidować, gdy wiele wiadomości przychodzących nadejdzie w krótkim odstępie czasu. +- Serializacja pozwala uniknąć rywalizacji o współdzielone zasoby (pliki sesji, dzienniki, stdin CLI) i zmniejsza ryzyko limitów szybkości po stronie upstream. ## Jak to działa -- Kolejka FIFO świadoma pasów opróżnia każdy pas z konfigurowalnym limitem współbieżności (domyślnie 1 dla nieskonfigurowanych pasów; main domyślnie 4, subagent 8). -- `runEmbeddedPiAgent` dodaje zadania do kolejki według **klucza sesji** (pas `session:`), aby zagwarantować tylko jedno aktywne uruchomienie na sesję. -- Każde uruchomienie sesji jest następnie dodawane do **globalnego pasa** (domyślnie `main`), więc ogólna równoległość jest ograniczona przez `agents.defaults.maxConcurrent`. -- Gdy włączone jest szczegółowe logowanie, uruchomienia w kolejce emitują krótkie powiadomienie, jeśli czekały ponad około 2 s przed startem. -- Wskaźniki pisania nadal uruchamiają się natychmiast po dodaniu do kolejki (gdy kanał to obsługuje), więc doświadczenie użytkownika pozostaje bez zmian, gdy czekamy na swoją kolej. +- Kolejka FIFO świadoma torów opróżnia każdy tor z konfigurowalnym limitem współbieżności (domyślnie 1 dla nieskonfigurowanych torów; główny domyślnie 4, subagent 8). +- `runEmbeddedPiAgent` dodaje zadania do kolejki według **klucza sesji** (tor `session:`), aby zagwarantować tylko jedno aktywne uruchomienie na sesję. +- Każde uruchomienie sesji jest następnie kolejkowane do **globalnego toru** (domyślnie `main`), więc ogólna równoległość jest ograniczana przez `agents.defaults.maxConcurrent`. +- Gdy włączone jest szczegółowe logowanie, zakolejkowane uruchomienia emitują krótkie powiadomienie, jeśli czekały ponad ~2 s przed startem. +- Wskaźniki pisania nadal uruchamiają się natychmiast po dodaniu do kolejki (gdy kanał to obsługuje), więc doświadczenie użytkownika pozostaje niezmienione podczas oczekiwania na swoją kolej. ## Domyślne wartości @@ -37,30 +37,30 @@ Gdy nie ustawiono inaczej, wszystkie powierzchnie kanałów przychodzących uży - `cap: 20` - `drop: "summarize"` -`steer` jest domyślne, ponieważ utrzymuje aktywną turę modelu responsywną bez -uruchamiania drugiego przebiegu sesji. Opróżnia wszystkie wiadomości sterujące, -które dotarły przed następną granicą modelu. Jeśli bieżące uruchomienie nie może -przyjąć sterowania, OpenClaw wraca do wpisu kolejki follow-up. +`steer` jest ustawieniem domyślnym, ponieważ utrzymuje aktywną turę modelu responsywną bez +uruchamiania drugiego przebiegu sesji. Opróżnia wszystkie wiadomości sterujące, które dotarły +przed następną granicą modelu. Jeśli bieżące uruchomienie nie może przyjąć sterowania, +OpenClaw przechodzi awaryjnie do wpisu kolejki followup. ## Tryby kolejki -Wiadomości przychodzące mogą sterować bieżącym uruchomieniem, czekać na turę follow-up albo robić jedno i drugie: +Wiadomości przychodzące mogą sterować bieżącym uruchomieniem, czekać na turę followup albo robić jedno i drugie: -- `steer`: dodaje wiadomości sterujące do aktywnego środowiska uruchomieniowego. Pi dostarcza wszystkie oczekujące wiadomości sterujące **po zakończeniu wykonywania wywołań narzędzi przez bieżącą turę asystenta**, przed następnym wywołaniem LLM; serwer aplikacji Codex otrzymuje jedno zbiorcze `turn/steer`. Jeśli uruchomienie nie przesyła aktywnie strumienia lub sterowanie jest niedostępne, OpenClaw wraca do wpisu kolejki follow-up. -- `queue` (starszy tryb): dawne sterowanie pojedynczo. Pi dostarcza jedną wiadomość sterującą z kolejki na każdej granicy modelu; serwer aplikacji Codex otrzymuje osobne żądania `turn/steer`. Preferuj `steer`, chyba że potrzebujesz poprzedniego serializowanego zachowania. +- `steer`: kolejkuje wiadomości sterujące do aktywnego środowiska wykonawczego. Pi dostarcza wszystkie oczekujące wiadomości sterujące **po zakończeniu wykonywania wywołań narzędzi przez bieżącą turę asystenta**, przed następnym wywołaniem LLM; serwer aplikacji Codex otrzymuje jedno zbiorcze `turn/steer`. Jeśli uruchomienie nie prowadzi aktywnie streamingu albo sterowanie jest niedostępne, OpenClaw przechodzi awaryjnie do wpisu kolejki followup. +- `queue` (starsze): stare sterowanie po jednej wiadomości naraz. Pi dostarcza jedną zakolejkowaną wiadomość sterującą przy każdej granicy modelu; serwer aplikacji Codex otrzymuje osobne żądania `turn/steer`. Preferuj `steer`, chyba że potrzebujesz poprzedniego serializowanego zachowania. - `followup`: dodaje każdą wiadomość do kolejki na późniejszą turę agenta po zakończeniu bieżącego uruchomienia. -- `collect`: scala wiadomości z kolejki w **pojedynczą** turę follow-up po okresie ciszy. Jeśli wiadomości kierują do różnych kanałów/wątków, są opróżniane osobno, aby zachować trasowanie. -- `steer-backlog` (czyli `steer+backlog`): steruje teraz **i** zachowuje tę samą wiadomość na turę follow-up. -- `interrupt` (starszy tryb): przerywa aktywne uruchomienie dla tej sesji, a następnie uruchamia najnowszą wiadomość. +- `collect`: scala zakolejkowane wiadomości w **pojedynczą** turę followup po oknie ciszy. Jeśli wiadomości są kierowane do różnych kanałów/wątków, są opróżniane pojedynczo, aby zachować routing. +- `steer-backlog` (alias `steer+backlog`): steruje teraz **i** zachowuje tę samą wiadomość na turę followup. +- `interrupt` (starsze): przerywa aktywne uruchomienie dla tej sesji, a następnie uruchamia najnowszą wiadomość. -Steer-backlog oznacza, że możesz otrzymać odpowiedź follow-up po sterowanym -uruchomieniu, więc powierzchnie strumieniowe mogą wyglądać jak duplikaty. -Preferuj `collect`/`steer`, jeśli chcesz jedną odpowiedź na wiadomość przychodzącą. +Steer-backlog oznacza, że po sterowanym uruchomieniu możesz otrzymać odpowiedź followup, więc +powierzchnie streamingowe mogą wyglądać jak duplikaty. Preferuj `collect`/`steer`, jeśli chcesz +jednej odpowiedzi na wiadomość przychodzącą. -Informacje o czasie i zachowaniu zależności specyficznych dla środowiska uruchomieniowego znajdziesz w -[Kolejce sterowania](/pl/concepts/queue-steering). +Informacje o czasie działania i zachowaniu zależności specyficznym dla środowiska wykonawczego znajdziesz w +[Kolejka sterowania](/pl/concepts/queue-steering). -Konfiguruj globalnie lub per kanał przez `messages.queue`: +Skonfiguruj globalnie lub dla kanału przez `messages.queue`: ```json5 { @@ -78,31 +78,30 @@ Konfiguruj globalnie lub per kanał przez `messages.queue`: ## Opcje kolejki -Opcje mają zastosowanie do `followup`, `collect` i `steer-backlog` (oraz do `steer` lub starszego `queue`, gdy sterowanie wraca do follow-up): +Opcje dotyczą `followup`, `collect` i `steer-backlog` (oraz `steer` lub starszego `queue`, gdy sterowanie przechodzi awaryjnie do followup): -- `debounceMs`: okres ciszy przed opróżnieniem follow-upów w kolejce. Same liczby oznaczają milisekundy; jednostki `ms`, `s`, `m`, `h` i `d` są akceptowane przez opcje `/queue`. -- `cap`: maksymalna liczba wiadomości w kolejce na sesję. Wartości poniżej `1` są ignorowane. -- `drop: "summarize"`: domyślne. Usuwa najstarsze wpisy z kolejki według potrzeb, zachowuje zwięzłe podsumowania i wstrzykuje je jako syntetyczny prompt follow-up. -- `drop: "old"`: usuwa najstarsze wpisy z kolejki według potrzeb, bez zachowywania podsumowań. +- `debounceMs`: okno ciszy przed opróżnieniem zakolejkowanych followupów. Same liczby oznaczają milisekundy; jednostki `ms`, `s`, `m`, `h` i `d` są akceptowane przez opcje `/queue`. +- `cap`: maksymalna liczba zakolejkowanych wiadomości na sesję. Wartości poniżej `1` są ignorowane. +- `drop: "summarize"`: domyślne. Odrzuca najstarsze zakolejkowane wpisy w razie potrzeby, zachowuje kompaktowe podsumowania i wstrzykuje je jako syntetyczny prompt followup. +- `drop: "old"`: odrzuca najstarsze zakolejkowane wpisy w razie potrzeby, bez zachowywania podsumowań. - `drop: "new"`: odrzuca najnowszą wiadomość, gdy kolejka jest już pełna. Domyślne wartości: `debounceMs: 500`, `cap: 20`, `drop: summarize`. ## Pierwszeństwo -Przy wyborze trybu OpenClaw rozstrzyga: +Przy wyborze trybu OpenClaw rozstrzyga kolejno: 1. Wbudowane lub zapisane nadpisanie `/queue` dla sesji. 2. `messages.queue.byChannel.`. 3. `messages.queue.mode`. 4. Domyślne `steer`. -Dla opcji wbudowane lub zapisane opcje `/queue` mają pierwszeństwo nad konfiguracją. Następnie -stosowane są opóźnienie specyficzne dla kanału (`messages.queue.debounceMsByChannel`), domyślne -opóźnienia Plugin, globalne opcje `messages.queue` oraz wbudowane wartości domyślne. -`cap` i `drop` są opcjami globalnymi/sesyjnymi, a nie kluczami konfiguracji per kanał. +Dla opcji wbudowane lub zapisane opcje `/queue` mają pierwszeństwo przed konfiguracją. Następnie +stosowane są opóźnienie debounce specyficzne dla kanału (`messages.queue.debounceMsByChannel`), domyślne wartości +debounce Plugin, globalne opcje `messages.queue` i wbudowane wartości domyślne. `cap` i `drop` są opcjami globalnymi/sesyjnymi, a nie kluczami konfiguracji dla kanału. -## Nadpisania per sesja +## Nadpisania dla sesji - Wyślij `/queue ` jako samodzielne polecenie, aby zapisać tryb dla bieżącej sesji. - Opcje można łączyć: `/queue collect debounce:0.5s cap:25 drop:summarize` @@ -111,19 +110,20 @@ opóźnienia Plugin, globalne opcje `messages.queue` oraz wbudowane wartości do ## Zakres i gwarancje - Dotyczy uruchomień agentów automatycznych odpowiedzi we wszystkich kanałach przychodzących, które używają potoku odpowiedzi Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat itd.). -- Domyślny pas (`main`) obejmuje cały proces dla ruchu przychodzącego i głównych Heartbeat; ustaw `agents.defaults.maxConcurrent`, aby zezwolić na wiele sesji równolegle. -- Mogą istnieć dodatkowe pasy (np. `cron`, `cron-nested`, `nested`, `subagent`), aby zadania w tle mogły działać równolegle bez blokowania odpowiedzi przychodzących. Izolowane tury agentów Cron trzymają slot `cron`, podczas gdy ich wewnętrzne wykonanie agenta używa `cron-nested`; oba używają `cron.maxConcurrentRuns`. Współdzielone przepływy nie-Cron `nested` zachowują własne zachowanie pasa. Te odłączone uruchomienia są śledzone jako [zadania w tle](/pl/automation/tasks). -- Pasy per sesja gwarantują, że tylko jedno uruchomienie agenta naraz dotyka danej sesji. -- Brak zewnętrznych zależności lub wątków roboczych w tle; czysty TypeScript + obietnice. +- Domyślny tor (`main`) jest ogólny dla procesu dla przychodzących + głównych Heartbeat; ustaw `agents.defaults.maxConcurrent`, aby pozwolić na wiele sesji równolegle. +- Mogą istnieć dodatkowe tory (np. `cron`, `cron-nested`, `nested`, `subagent`), aby zadania w tle mogły działać równolegle bez blokowania odpowiedzi przychodzących. Izolowane tury agenta Cron zajmują slot `cron`, podczas gdy ich wewnętrzne wykonanie agenta używa `cron-nested`; oba używają `cron.maxConcurrentRuns`. Współdzielone przepływy `nested` inne niż cron zachowują własne zachowanie toru. Te odłączone uruchomienia są śledzone jako [zadania w tle](/pl/automation/tasks). +- Tory dla sesji gwarantują, że tylko jedno uruchomienie agenta dotyka danej sesji naraz. +- Brak zewnętrznych zależności lub wątków workerów w tle; czysty TypeScript + obietnice. ## Rozwiązywanie problemów - Jeśli polecenia wydają się zablokowane, włącz szczegółowe logi i szukaj wierszy „queued for …ms”, aby potwierdzić, że kolejka się opróżnia. -- Jeśli potrzebujesz głębokości kolejki, włącz szczegółowe logi i obserwuj wiersze czasu kolejki. -- Gdy diagnostyka jest włączona, sesje pozostające w `processing` dłużej niż `diagnostics.stuckSessionWarnMs` zapisują ostrzeżenie o zablokowanej sesji. Aktywne uruchomienia osadzone, aktywne operacje odpowiedzi i aktywne zadania pasa domyślnie pozostają tylko ostrzeżeniami; nieaktualna ewidencja startowa bez aktywnej pracy sesji może zwolnić dotknięty pas sesji, aby praca w kolejce mogła się opróżnić. +- Jeśli potrzebujesz głębokości kolejki, włącz szczegółowe logi i obserwuj wiersze z czasem kolejki. +- Uruchomienia serwera aplikacji Codex, które akceptują turę, a potem przestają emitować postęp, są przerywane przez adapter Codex, aby aktywny tor sesji mógł zostać zwolniony zamiast czekać na limit czasu zewnętrznego uruchomienia. +- Gdy diagnostyka jest włączona, sesje pozostające w `processing` po `diagnostics.stuckSessionWarnMs` logują ostrzeżenie o zablokowanej sesji. Aktywne osadzone uruchomienia, aktywne operacje odpowiedzi i aktywne zadania toru domyślnie pozostają wyłącznie ostrzeżeniami; przestarzała ewidencja startowa bez aktywnej pracy sesji może zwolnić dotknięty tor sesji, aby zakolejkowana praca została opróżniona. ## Powiązane -- [Zarządzanie sesją](/pl/concepts/session) +- [Zarządzanie sesjami](/pl/concepts/session) - [Kolejka sterowania](/pl/concepts/queue-steering) -- [Zasady ponawiania](/pl/concepts/retry) +- [Polityka ponawiania](/pl/concepts/retry) diff --git a/docs/pl/help/testing.md b/docs/pl/help/testing.md index 7cdd0f63a..1a9b5578c 100644 --- a/docs/pl/help/testing.md +++ b/docs/pl/help/testing.md @@ -1,35 +1,35 @@ --- read_when: - Uruchamianie testów lokalnie lub w CI - - Dodawanie testów regresyjnych dla błędów modeli/dostawców + - Dodawanie testów regresji dla błędów modeli/dostawców - Debugowanie zachowania Gateway + agenta -summary: 'Zestaw do testowania: zestawy testów jednostkowych/e2e/live, uruchamianie w Dockerze i zakres każdego testu' +summary: 'Zestaw testowy: zestawy testów jednostkowych/e2e/live, runnery Docker oraz zakres każdego testu' title: Testowanie x-i18n: - generated_at: "2026-04-30T09:59:26Z" + generated_at: "2026-04-30T18:39:13Z" model: gpt-5.5 provider: openai - source_hash: c7b506350f11431195cb55c84cb10e99efb5f43b934079528b982627024d1ffc + source_hash: 470a96c6b47c2708950d05adc4a4efba5fe290f0675a131e2888d2d0032d5953 source_path: help/testing.md workflow: 16 --- -OpenClaw ma trzy zestawy Vitest (jednostkowy/integracyjny, e2e, live) oraz mały zestaw +OpenClaw ma trzy zestawy testów Vitest (jednostkowe/integracyjne, e2e, live) i mały zestaw runnerów Docker. Ten dokument jest przewodnikiem „jak testujemy”: - Co obejmuje każdy zestaw (i czego celowo _nie_ obejmuje). -- Które polecenia uruchamiać w typowych przepływach pracy (lokalnie, przed push, podczas debugowania). -- Jak testy live odnajdują poświadczenia i wybierają modele/dostawców. +- Które polecenia uruchamiać dla typowych przepływów pracy (lokalnie, przed push, debugowanie). +- Jak testy live wykrywają dane uwierzytelniające oraz wybierają modele/dostawców. - Jak dodawać regresje dla rzeczywistych problemów z modelami/dostawcami. -**Stos QA (qa-lab, qa-channel, ścieżki transportu live)** jest udokumentowany osobno: +**Stos QA (qa-lab, qa-channel, live transport lanes)** jest udokumentowany oddzielnie: -- [Omówienie QA](/pl/concepts/qa-e2e-automation) — architektura, powierzchnia poleceń, tworzenie scenariuszy. -- [Matrix QA](/pl/concepts/qa-matrix) — dokumentacja referencyjna dla `pnpm openclaw qa matrix`. -- [Kanał QA](/pl/channels/qa-channel) — syntetyczny Plugin transportowy używany przez scenariusze oparte na repozytorium. +- [Przegląd QA](/pl/concepts/qa-e2e-automation) — architektura, powierzchnia poleceń, tworzenie scenariuszy. +- [Matrix QA](/pl/concepts/qa-matrix) — referencja dla `pnpm openclaw qa matrix`. +- [Kanał QA](/pl/channels/qa-channel) — syntetyczny Plugin transportu używany przez scenariusze wspierane przez repozytorium. -Ta strona opisuje uruchamianie standardowych zestawów testów oraz runnerów Docker/Parallels. Sekcja runnerów specyficznych dla QA poniżej ([Runnery specyficzne dla QA](#qa-specific-runners)) wymienia konkretne wywołania `qa` i odsyła do powyższych materiałów referencyjnych. +Ta strona opisuje uruchamianie zwykłych zestawów testów oraz runnerów Docker/Parallels. Sekcja dotycząca runnerów specyficznych dla QA poniżej ([Runnery specyficzne dla QA](#qa-specific-runners)) wymienia konkretne wywołania `qa` i odsyła do powyższych referencji. ## Szybki start @@ -37,69 +37,69 @@ Ta strona opisuje uruchamianie standardowych zestawów testów oraz runnerów Do W większość dni: - Pełna bramka (oczekiwana przed push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- Szybsze lokalne uruchomienie pełnego zestawu na maszynie z dużymi zasobami: `pnpm test:max` -- Bezpośrednia pętla obserwacji Vitest: `pnpm test:watch` +- Szybsze lokalne uruchomienie pełnego zestawu na maszynie z dużą ilością zasobów: `pnpm test:max` +- Bezpośrednia pętla obserwowania Vitest: `pnpm test:watch` - Bezpośrednie wskazywanie plików obsługuje teraz także ścieżki rozszerzeń/kanałów: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Gdy iterujesz nad pojedynczą awarią, najpierw preferuj uruchomienia ukierunkowane. -- Witryna QA oparta na Docker: `pnpm qa:lab:up` -- Ścieżka QA oparta na maszynie wirtualnej Linux: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- Gdy iterujesz nad pojedynczą awarią, najpierw preferuj uruchomienia zawężone. +- Witryna QA wspierana przez Docker: `pnpm qa:lab:up` +- Lane QA wspierana przez maszynę wirtualną Linux: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Gdy dotykasz testów albo chcesz dodatkowej pewności: +Gdy dotykasz testów albo chcesz większej pewności: - Bramka pokrycia: `pnpm test:coverage` - Zestaw E2E: `pnpm test:e2e` -Podczas debugowania rzeczywistych dostawców/modeli (wymaga prawdziwych poświadczeń): +Podczas debugowania prawdziwych dostawców/modeli (wymaga prawdziwych danych uwierzytelniających): - Zestaw live (modele + sondy narzędzi/obrazów Gateway): `pnpm test:live` -- Ciche ukierunkowanie jednego pliku live: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Ciche uruchomienie jednego pliku live: `pnpm test:live -- src/agents/models.profiles.live.test.ts` - Przegląd modeli live w Docker: `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ą także małą turę obrazową. - Wyłącz dodatkowe sondy za pomocą `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` lub + Wyłącz dodatkowe sondy za pomocą `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` albo `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0` podczas izolowania awarii dostawcy. - - Pokrycie CI: codzienne `OpenClaw Scheduled Live And E2E Checks` oraz ręczne - `OpenClaw Release Checks` wywołują współużywany przepływ pracy live/E2E z - `include_live_suites: true`, co obejmuje osobne zadania macierzy modeli live - Docker podzielone według dostawcy. - - Dla ukierunkowanych ponownych uruchomień CI wyślij `OpenClaw Live And E2E Checks (Reusable)` + - Pokrycie CI: codzienny `OpenClaw Scheduled Live And E2E Checks` oraz ręczny + `OpenClaw Release Checks` wywołują wielokrotnego użytku przepływ live/E2E z + `include_live_suites: true`, co obejmuje osobne zadania macierzy modeli live w Docker + podzielone według dostawcy. + - Dla zawężonych ponownych uruchomień CI wywołaj `OpenClaw Live And E2E Checks (Reusable)` z `include_live_suites: true` i `live_models_only: true`. - Dodaj nowe, wysokosygnałowe sekrety dostawców do `scripts/ci-hydrate-live-auth.sh` oraz `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` i jego - wywołujących dla harmonogramu/wydania. -- Smoke natywnego czatu Codex z wiązaniem: `pnpm test:docker:live-codex-bind` - - Uruchamia ścieżkę Docker live względem ścieżki serwera aplikacji Codex, wiąże syntetyczną - wiadomość bezpośrednią Slack za pomocą `/codex bind`, wykonuje `/codex fast` i - `/codex permissions`, a następnie weryfikuje zwykłą odpowiedź i załącznik obrazu - przechodzące przez natywne wiązanie Plugin zamiast ACP. -- Smoke uprzęży serwera aplikacji Codex: `pnpm test:docker:live-codex-harness` - - Uruchamia tury agenta Gateway przez należącą do Plugin uprząż serwera aplikacji Codex, - weryfikuje `/codex status` i `/codex models`, a domyślnie wykonuje sondy obrazu, - cron MCP, subagenta i Guardian. Wyłącz sondę subagenta za pomocą + wywołań harmonogramu/wydania. +- Natywny smoke Codex dla powiązanego czatu: `pnpm test:docker:live-codex-bind` + - Uruchamia lane Docker live przeciwko ścieżce app-server Codex, wiąże syntetyczny + Slack DM z `/codex bind`, ćwiczy `/codex fast` i + `/codex permissions`, a następnie weryfikuje, że zwykła odpowiedź i załącznik obrazowy + przechodzą przez natywne powiązanie Pluginu zamiast ACP. +- Smoke harnessa app-server Codex: `pnpm test:docker:live-codex-harness` + - Uruchamia tury agenta Gateway przez harness app-server Codex należący do Pluginu, + weryfikuje `/codex status` i `/codex models`, a domyślnie ćwiczy sondy obrazu, + cron MCP, sub-agenta i Guardian. Wyłącz sondę sub-agenta za pomocą `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0` podczas izolowania innych awarii - serwera aplikacji Codex. Aby wykonać ukierunkowane sprawdzenie subagenta, wyłącz pozostałe sondy: + app-server Codex. Dla zawężonego sprawdzenia sub-agenta wyłącz pozostałe sondy: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`. - To kończy działanie po sondzie subagenta, chyba że ustawiono + To kończy działanie po sondzie sub-agenta, chyba że ustawiono `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`. - Smoke polecenia ratunkowego Crestodian: `pnpm test:live:crestodian-rescue-channel` - - Opcjonalne, dodatkowe sprawdzenie powierzchni polecenia ratunkowego kanału wiadomości. - Wykonuje `/crestodian status`, kolejkuje trwałą zmianę modelu, + - Opcjonalne sprawdzenie „pas i szelki” dla powierzchni polecenia ratunkowego kanału wiadomości. + Ćwiczy `/crestodian status`, kolejkuje trwałą zmianę modelu, odpowiada `/crestodian yes` i weryfikuje ścieżkę zapisu audytu/konfiguracji. -- Smoke planisty Crestodian w Docker: `pnpm test:docker:crestodian-planner` +- Smoke planera Crestodian w Docker: `pnpm test:docker:crestodian-planner` - Uruchamia Crestodian w kontenerze bez konfiguracji z fałszywym Claude CLI w `PATH` - i weryfikuje, że przybliżony fallback planisty przekłada się na audytowany typowany + i weryfikuje, że rozmyty fallback planera przekłada się na audytowany, typowany zapis konfiguracji. - Smoke pierwszego uruchomienia Crestodian w Docker: `pnpm test:docker:crestodian-first-run` - - Zaczyna od pustego katalogu stanu OpenClaw, kieruje gołe `openclaw` do - Crestodian, stosuje zapisy setup/model/agent/Plugin Discord + SecretRef, + - Zaczyna od pustego katalogu stanu OpenClaw, kieruje samo `openclaw` do + Crestodian, stosuje zapisy konfiguracji/setup/model/agent/Pluginu Discord + SecretRef, waliduje konfigurację i weryfikuje wpisy audytu. Ta sama ścieżka konfiguracji Ring 0 jest także pokryta w QA Lab przez `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. - Smoke kosztów Moonshot/Kimi: przy ustawionym `MOONSHOT_API_KEY` uruchom `openclaw models list --provider moonshot --json`, a następnie uruchom izolowane `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 zgłasza Moonshot/K2.6, a - transkrypcja asystenta zapisuje znormalizowane `usage.cost`. + przeciwko `moonshot/kimi-k2.6`. Zweryfikuj, że JSON raportuje Moonshot/K2.6, a + transkrypt asystenta zapisuje znormalizowane `usage.cost`. Gdy potrzebujesz tylko jednego przypadku awarii, preferuj zawężanie testów live za pomocą zmiennych środowiskowych allowlist opisanych poniżej. @@ -107,103 +107,104 @@ Gdy potrzebujesz tylko jednego przypadku awarii, preferuj zawężanie testów li ## Runnery specyficzne dla QA -Te polecenia znajdują się obok głównych zestawów testów, gdy potrzebujesz realizmu QA Lab: +Te polecenia są obok głównych zestawów testów, gdy potrzebujesz realizmu QA-lab: -CI uruchamia QA Lab w dedykowanych przepływach pracy. `Parity gate` uruchamia się na pasujących PR-ach oraz -z ręcznego dispatch z dostawcami mock. `QA-Lab - All Lanes` uruchamia się nocą na -`main` oraz z ręcznego dispatch z bramką zgodności mock, ścieżką Matrix live, -zarządzaną przez Convex ścieżką live Telegram i zarządzaną przez Convex ścieżką live Discord jako -zadaniami równoległymi. Zaplanowane QA i kontrole wydania przekazują Matrix `--profile fast` -jawnie, podczas gdy CLI Matrix i domyślna wartość wejścia ręcznego przepływu pracy pozostają -`all`; ręczny dispatch może podzielić `all` na zadania `transport`, `media`, `e2ee-smoke`, -`e2ee-deep` i `e2ee-cli`. `OpenClaw Release Checks` uruchamia zgodność oraz -szybkie ścieżki Matrix i Telegram przed zatwierdzeniem wydania, używając +CI uruchamia QA Lab w dedykowanych przepływach pracy. `Parity gate` działa na pasujących PR-ach i +z ręcznego wywołania z mockowanymi dostawcami. `QA-Lab - All Lanes` działa co noc na +`main` i z ręcznego wywołania z mockowaną bramką parytetu, lane live Matrix, +zarządzaną przez Convex lane live Telegram i zarządzaną przez Convex lane live Discord jako +zadaniami równoległymi. Zaplanowane QA i kontrole wydań przekazują Matrix `--profile fast` +jawnie, podczas gdy domyślne wartości CLI Matrix i ręcznego wejścia przepływu pracy pozostają +`all`; ręczne wywołanie może podzielić `all` na zadania `transport`, `media`, `e2ee-smoke`, +`e2ee-deep` i `e2ee-cli`. `OpenClaw Release Checks` uruchamia parytet oraz +szybkie lane Matrix i Telegram przed zatwierdzeniem wydania, używając `mock-openai/gpt-5.5` dla kontroli transportu wydania, aby pozostały deterministyczne -i unikały normalnego startu Plugin dostawcy. Te Gatewaye transportu live wyłączają -wyszukiwanie pamięci; zachowanie pamięci pozostaje pokryte przez zestawy zgodności QA. +i unikały normalnego uruchamiania Pluginu dostawcy. Te Gatewaye transportu live wyłączają +wyszukiwanie pamięci; zachowanie pamięci pozostaje pokryte przez zestawy parytetu QA. -Pełne shardy mediów live dla wydania używają -`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, który ma już -`ffmpeg` i `ffprobe`. Shardy modeli/backendów live Docker używają współużywanego obrazu -`ghcr.io/openclaw/openclaw-live-test:` zbudowanego raz na wybrany -commit, a następnie pobierają go z `OPENCLAW_SKIP_DOCKER_BUILD=1` zamiast przebudowywać +Pełne shardy live media dla wydania używają +`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, który już ma +`ffmpeg` i `ffprobe`. Shardy modeli/backendów live w Docker używają wspólnego obrazu +`ghcr.io/openclaw/openclaw-live-test:` zbudowanego raz dla wybranego +commita, a następnie pobierają go z `OPENCLAW_SKIP_DOCKER_BUILD=1` zamiast przebudowywać wewnątrz każdego sharda. - `pnpm openclaw qa suite` - - Uruchamia scenariusze QA oparte na repozytorium bezpośrednio na hoście. + - Uruchamia scenariusze QA wspierane przez repozytorium 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 ścieżki szeregowej. - - Kończy się kodem niezerowym, gdy dowolny scenariusz zawiedzie. Użyj `--allow-failures`, gdy - chcesz artefaktów bez kodu wyjścia oznaczającego niepowodzenie. + workerów, albo `--concurrency 1` dla starszej lane szeregowej. + - Kończy z kodem niezerowym, gdy dowolny scenariusz się nie powiedzie. Użyj `--allow-failures`, gdy + chcesz artefakty bez kodu wyjścia oznaczającego awarię. - Obsługuje tryby dostawcy `live-frontier`, `mock-openai` i `aimock`. `aimock` uruchamia lokalny serwer dostawcy oparty na AIMock dla eksperymentalnego - pokrycia fikstur i mocków protokołu bez zastępowania świadomej scenariuszy - ścieżki `mock-openai`. + pokrycia fixture i mocków protokołu bez zastępowania świadomej scenariuszy + lane `mock-openai`. - `pnpm test:gateway:cpu-scenarios` - - Uruchamia benchmark startu Gateway oraz mały pakiet scenariuszy mock QA Lab + - Uruchamia benchmark startu Gateway oraz mały pakiet mockowanych scenariuszy QA Lab (`channel-chat-baseline`, `memory-failure-fallback`, `gateway-restart-inflight-run`) i zapisuje połączone podsumowanie obserwacji CPU w `.artifacts/gateway-cpu-scenarios/`. - Domyślnie flaguje tylko utrzymujące się obserwacje gorącego CPU (`--cpu-core-warn` - plus `--hot-wall-warn-ms`), więc krótkie skoki startowe są zapisywane jako metryki - bez wyglądania jak minutowa regresja przybijająca Gateway. + plus `--hot-wall-warn-ms`), więc krótkie skoki podczas startu są zapisywane jako metryki + bez wyglądania jak regresja wielominutowego obciążenia Gateway. - Używa zbudowanych artefaktów `dist`; najpierw uruchom build, gdy checkout nie ma - już świeżego wyjścia runtime. + jeszcze świeżego wyniku runtime. - `pnpm openclaw qa suite --runner multipass` - - Uruchamia ten sam zestaw QA wewnątrz jednorazowej maszyny wirtualnej Multipass Linux. + - Uruchamia ten sam zestaw QA wewnątrz jednorazowej maszyny wirtualnej Linux Multipass. - Zachowuje to samo zachowanie wyboru scenariuszy co `qa suite` na hoście. - Używa tych samych flag wyboru dostawcy/modelu co `qa suite`. - Uruchomienia live przekazują obsługiwane wejścia uwierzytelniania QA, które są praktyczne dla gościa: - klucze dostawców oparte na env, ścieżkę konfiguracji dostawcy live QA oraz `CODEX_HOME`, + klucze dostawców oparte na env, ścieżkę konfiguracji dostawcy QA live oraz `CODEX_HOME`, gdy jest obecne. - - Katalogi wyjściowe muszą pozostać pod katalogiem głównym repozytorium, aby gość mógł zapisywać z powrotem przez + - Katalogi wyjściowe muszą pozostać pod korzeniem repozytorium, aby gość mógł zapisywać z powrotem przez zamontowany workspace. - - Zapisuje normalny raport + podsumowanie QA oraz logi Multipass w + - Zapisuje normalny raport QA + podsumowanie oraz logi Multipass w `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Uruchamia opartą na Docker witrynę QA dla pracy QA w stylu operatorskim. + - Uruchamia witrynę QA wspieraną przez Docker do pracy QA w stylu operatorskim. - `pnpm test:docker:npm-onboard-channel-agent` - Buduje tarball npm z bieżącego checkoutu, instaluje go globalnie w Docker, uruchamia nieinteraktywny onboarding klucza API OpenAI, domyślnie konfiguruje Telegram, - weryfikuje, że włączenie Plugin instaluje zależności runtime 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ą ścieżkę instalacji pakietowej + weryfikuje, że włączenie Pluginu instaluje zależności runtime na żądanie, + uruchamia doctor i uruchamia jedną lokalną turę agenta przeciwko mockowanemu + endpointowi OpenAI. + - Użyj `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, aby uruchomić tę samą lane instalacji pakietu z Discord. - `pnpm test:docker:session-runtime-context` - - Uruchamia deterministyczny smoke zbudowanej aplikacji w Docker dla transkrypcji osadzonego kontekstu runtime. + - Uruchamia deterministyczny smoke zbudowanej aplikacji w Docker dla osadzonych transkryptów kontekstu runtime. Weryfikuje, że ukryty kontekst runtime OpenClaw jest utrwalany jako niewyświetlana wiadomość niestandardowa zamiast wyciekać do widocznej tury użytkownika, - następnie zasiewa dotknięty problemem uszkodzony session JSONL i weryfikuje, że - `openclaw doctor --fix` przepisuje go do aktywnej gałęzi z kopią zapasową. + następnie zasiewa dotknięty problemem uszkodzony JSONL sesji i weryfikuje, że + `openclaw doctor --fix` przepisuje go na aktywną gałąź z kopią zapasową. - `pnpm test:docker:npm-telegram-live` - - Instaluje kandydujący pakiet OpenClaw w Docker, uruchamia onboarding zainstalowanego pakietu, + - Instaluje kandydata pakietu OpenClaw w Docker, uruchamia onboarding zainstalowanego pakietu, konfiguruje Telegram przez zainstalowane CLI, a następnie ponownie używa - ścieżki live Telegram QA z tym zainstalowanym pakietem jako Gateway SUT. + lane QA live Telegram z tym zainstalowanym pakietem jako SUT Gateway. - Domyślnie używa `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; ustaw - `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` lub - `OPENCLAW_CURRENT_PACKAGE_TGZ`, aby testować rozwiązany lokalny tarball zamiast - instalowania z rejestru. - - Używa tych samych poświadczeń env Telegram lub źródła poświadczeń Convex co + `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` albo + `OPENCLAW_CURRENT_PACKAGE_TGZ`, aby przetestować rozwiązany lokalny tarball zamiast + instalować z rejestru. + - Używa tych samych danych uwierzytelniających env Telegram albo źródła danych uwierzytelniających Convex co `pnpm openclaw qa telegram`. Dla automatyzacji CI/wydania ustaw - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` plus + `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` oraz `OPENCLAW_QA_CONVEX_SITE_URL` i sekret roli. Jeśli `OPENCLAW_QA_CONVEX_SITE_URL` i sekret roli Convex są obecne w CI, wrapper Docker wybiera Convex automatycznie. - - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` nadpisuje współużywane - `OPENCLAW_QA_CREDENTIAL_ROLE` tylko dla tej ścieżki. - - GitHub Actions udostępnia tę ścieżkę jako ręczny przepływ pracy maintainer - `NPM Telegram Beta E2E`. Nie uruchamia się przy merge. Przepływ pracy używa - środowiska `qa-live-shared` i dzierżaw poświadczeń Convex CI. -- GitHub Actions udostępnia także `Package Acceptance` dla bocznego dowodu produktu - względem jednego kandydującego pakietu. Przyjmuje zaufany ref, opublikowaną specyfikację npm, - URL tarballa HTTPS plus SHA-256 albo artefakt tarballa z innego uruchomienia, przesyła + - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` nadpisuje współdzielone + `OPENCLAW_QA_CREDENTIAL_ROLE` tylko dla tej lane. + - GitHub Actions udostępnia tę lane jako ręczny przepływ pracy maintainerów + `NPM Telegram Beta E2E`. Nie uruchamia się przy merge. Przepływ pracy używa środowiska + `qa-live-shared` i dzierżaw danych uwierzytelniających CI z Convex. +- GitHub Actions udostępnia także `Package Acceptance` dla pobocznego dowodu produktu + względem jednego kandydata pakietu. Akceptuje zaufany ref, opublikowaną specyfikację npm, + URL tarballa HTTPS wraz z SHA-256 albo artefakt tarballa z innego uruchomienia, przesyła znormalizowany `openclaw-current.tgz` jako `package-under-test`, a następnie uruchamia - istniejący scheduler Docker E2E z profilami ścieżek smoke, package, product, full albo custom. - Ustaw `telegram_mode=mock-openai` lub `live-frontier`, aby uruchomić przepływ pracy - Telegram QA względem tego samego artefaktu `package-under-test`. - - Najnowszy dowód produktu beta: + istniejący scheduler Docker E2E z profilami lane smoke, package, product, full albo custom. + Ustaw `telegram_mode=mock-openai` albo `live-frontier`, aby uruchomić przepływ pracy QA Telegram + względem tego samego artefaktu `package-under-test`. + - Dowód produktu dla najnowszej beta: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -223,7 +224,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- Dowód artefaktu pobiera artefakt tarballa z innego uruchomienia Actions: +- Dowód artefaktu pobiera artefakt tarball z innego uruchomienia Actions: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -235,78 +236,79 @@ gh workflow run package-acceptance.yml --ref main \ - `pnpm test:docker:bundled-channel-deps` - Pakuje i instaluje bieżącą kompilację 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 nieobecne nieskonfigurowane - zależności uruchomieniowe plugin, pierwszy skonfigurowany Gateway lub uruchomienie - doctor instaluje zależności uruchomieniowe każdego dołączonego plugin na żądanie, - a drugi restart nie instaluje ponownie zależności, które zostały już aktywowane. - - Instaluje też znaną starszą bazę npm, włącza Telegram przed uruchomieniem + ze skonfigurowanym OpenAI, a następnie włącza dołączone kanały/pluginy przez edycje + konfiguracji. + - Weryfikuje, że wykrywanie konfiguracji pozostawia nieskonfigurowane zależności wykonawcze pluginów + nieobecne, pierwsze skonfigurowane uruchomienie Gateway lub doctor instaluje na żądanie zależności + wykonawcze każdego dołączonego pluginu, a drugi restart nie + reinstaluje zależności, które zostały już aktywowane. + - Instaluje także znaną starszą bazę npm, włącza Telegram przed uruchomieniem `openclaw update --tag ` i weryfikuje, że doctor po aktualizacji kandydata - naprawia dołączone zależności uruchomieniowe kanału bez naprawy postinstall po stronie - uprzęży testowej. + naprawia zależności wykonawcze dołączonego kanału bez naprawy postinstall + po stronie uprzęży. - `pnpm test:parallels:npm-update` - - Uruchamia natywny smoke aktualizacji instalacji pakietowej na gościach Parallels. Każda + - Uruchamia natywny smoke aktualizacji spakowanej instalacji na gościach Parallels. Każda wybrana platforma najpierw instaluje żądany pakiet bazowy, następnie uruchamia zainstalowane polecenie `openclaw update` w tym samym gościu i weryfikuje - zainstalowaną wersję, status aktualizacji, gotowość Gateway oraz jedną turę lokalnego agenta. - - Użyj `--platform macos`, `--platform windows` lub `--platform linux` podczas + zainstalowaną wersję, status aktualizacji, gotowość Gateway oraz jedną lokalną turę agenta. + - Używaj `--platform macos`, `--platform windows` albo `--platform linux` podczas iteracji na jednym gościu. Użyj `--json`, aby uzyskać ścieżkę artefaktu podsumowania i - status dla poszczególnych ścieżek. - - Ścieżka OpenAI domyślnie używa `openai/gpt-5.5` do dowodu tury agenta na żywo. - Przekaż `--model ` lub ustaw - `OPENCLAW_PARALLELS_OPENAI_MODEL`, gdy celowo walidujesz inny + status dla każdej lane. + - Lane OpenAI domyślnie używa `openai/gpt-5.5` do dowodu tury agenta na żywo. + Przekaż `--model ` albo ustaw + `OPENCLAW_PARALLELS_OPENAI_MODEL`, gdy celowo weryfikujesz inny model OpenAI. - - Owiń długie lokalne uruchomienia limitem czasu hosta, aby zacięcia transportu Parallels nie mogły - zużyć reszty okna testowego: + - Owijaj długie lokalne uruchomienia limitem czasu hosta, aby zacięcia transportu Parallels nie + zużyły reszty okna testowego: ```bash timeout --foreground 150m pnpm test:parallels:npm-update -- --json timeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json ``` - - Skrypt zapisuje zagnieżdżone logi ścieżek w `/tmp/openclaw-parallels-npm-update.*`. - Sprawdź `windows-update.log`, `macos-update.log` lub `linux-update.log` - przed założeniem, że zewnętrzny wrapper się zawiesił. - - Aktualizacja Windows może spędzić od 10 do 15 minut na naprawie doctor/zależności - uruchomieniowych po aktualizacji na zimnym gościu; nadal jest to zdrowy stan, gdy zagnieżdżony - log debug npm postępuje. - - Nie uruchamiaj tego zbiorczego wrappera równolegle z pojedynczymi ścieżkami smoke Parallels - dla macOS, Windows lub Linux. Współdzielą stan VM i mogą kolidować podczas - przywracania migawki, serwowania pakietów lub stanu Gateway gościa. - - Dowód po aktualizacji uruchamia normalną powierzchnię dołączonego plugin, ponieważ - fasady możliwości, takie jak mowa, generowanie obrazów i rozumienie mediów, - są ładowane przez dołączone API uruchomieniowe nawet wtedy, gdy sama tura agenta + - Skrypt zapisuje zagnieżdżone logi lane pod `/tmp/openclaw-parallels-npm-update.*`. + Sprawdź `windows-update.log`, `macos-update.log` albo `linux-update.log`, + zanim założysz, że zewnętrzny wrapper się zawiesił. + - Aktualizacja Windows może spędzić od 10 do 15 minut w naprawie doctor/zależności + wykonawczych po aktualizacji na zimnym gościu; to nadal zdrowy stan, gdy zagnieżdżony + log debugowania npm postępuje. + - Nie uruchamiaj tego zbiorczego wrappera równolegle z pojedynczymi lane smoke Parallels + dla macOS, Windows albo Linux. Współdzielą stan VM i mogą kolidować przy + przywracaniu migawki, serwowaniu pakietów albo stanie Gateway gościa. + - Dowód po aktualizacji uruchamia normalną powierzchnię dołączonych pluginów, ponieważ + fasady zdolności, takie jak mowa, generowanie obrazów i rozumienie mediów, + są ładowane przez dołączone API wykonawcze nawet wtedy, gdy sama tura agenta sprawdza tylko prostą odpowiedź tekstową. - `pnpm openclaw qa aimock` - - Uruchamia tylko lokalny serwer dostawcy AIMock do bezpośredniego testowania smoke protokołu. + - Uruchamia tylko lokalny serwer dostawcy AIMock do bezpośredniego testu smoke + protokołu. - `pnpm openclaw qa matrix` - - Uruchamia ścieżkę QA na żywo Matrix względem jednorazowego homeservera Tuwunel opartego na Dockerze. Tylko checkout źródeł — instalacje pakietowe nie dostarczają `qa-lab`. - - Pełne CLI, katalog profili/scenariuszy, zmienne env i układ artefaktów: [QA Matrix](/pl/concepts/qa-matrix). + - Uruchamia lane QA Matrix na żywo przeciwko jednorazowemu homeserverowi Tuwunel opartemu na Dockerze. Tylko checkout źródeł — spakowane instalacje nie dostarczają `qa-lab`. + - Pełny CLI, katalog profili/scenariuszy, zmienne środowiskowe i układ artefaktów: [QA Matrix](/pl/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Uruchamia ścieżkę QA na żywo Telegram względem prawdziwej prywatnej grupy, używając tokenów bota sterownika i SUT z env. + - Uruchamia lane QA Telegram na żywo przeciwko prawdziwej prywatnej grupie, używając tokenów bota sterownika i SUT z env. - Wymaga `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` i `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Identyfikator grupy musi być numerycznym identyfikatorem czatu Telegram. - 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ć pulowane dzierżawy. - - Kończy się niezerowym kodem, gdy dowolny scenariusz się nie powiedzie. Użyj `--allow-failures`, gdy - chcesz uzyskać artefakty bez błędnego kodu wyjścia. - - Wymaga dwóch różnych botów w tej samej prywatnej grupie, przy czym bot SUT musi udostępniać nazwę użytkownika Telegram. - - Aby zapewnić stabilną obserwację bot-bot, włącz Bot-to-Bot Communication Mode w `@BotFather` dla obu botów i upewnij się, że bot sterownika może obserwować ruch botów w grupie. - - Zapisuje raport QA Telegram, podsumowanie i artefakt zaobserwowanych wiadomości w `.artifacts/qa-e2e/...`. Scenariusze odpowiedzi obejmują RTT od żądania wysłania sterownika do zaobserwowanej odpowiedzi SUT. + - Kończy się kodem niezerowym, gdy dowolny scenariusz zakończy się niepowodzeniem. Użyj `--allow-failures`, gdy + chcesz artefaktów bez niezerowego kodu wyjścia. + - Wymaga dwóch odrębnych botów w tej samej prywatnej grupie, przy czym bot SUT musi ujawniać nazwę użytkownika Telegram. + - Aby uzyskać stabilną obserwację między botami, włącz Bot-to-Bot Communication Mode w `@BotFather` dla obu botów i upewnij się, że bot sterownika może obserwować ruch botów w grupie. + - Zapisuje raport QA Telegram, podsumowanie i artefakt zaobserwowanych wiadomości pod `.artifacts/qa-e2e/...`. Scenariusze odpowiedzi obejmują RTT od żądania wysłania przez sterownik do zaobserwowanej odpowiedzi SUT. -Ścieżki transportu na żywo współdzielą jeden standardowy kontrakt, aby nowe transporty się nie rozjeżdżały; macierz pokrycia dla poszczególnych ścieżek znajduje się w [przeglądzie QA → Pokrycie transportu na żywo](/pl/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` to szeroki zestaw syntetyczny i nie jest częścią tej macierzy. +Lane transportu na żywo współdzielą jeden standardowy kontrakt, aby nowe transporty się nie rozjeżdżały; macierz pokrycia dla poszczególnych lane znajduje się w [przeglądzie QA → Pokrycie transportu na żywo](/pl/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` to szeroki syntetyczny zestaw i nie jest częścią tej macierzy. ### 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`, laboratorium QA uzyskuje wyłączną dzierżawę z puli opartej na Convex, wysyła Heartbeat -tej dzierżawy, gdy ścieżka działa, i zwalnia dzierżawę przy zamykaniu. +Gdy `--credential-source convex` (albo `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) jest włączone dla +`openclaw qa telegram`, QA lab pozyskuje wyłączną dzierżawę z puli opartej na Convex, wysyła Heartbeat +tej dzierżawy podczas działania lane i zwalnia dzierżawę przy zamknięciu. Referencyjny szkielet projektu Convex: - `qa/convex-credential-broker/` -Wymagane zmienne env: +Wymagane zmienne środowiskowe: - `OPENCLAW_QA_CONVEX_SITE_URL` (na przykład `https://your-deployment.convex.site`) - Jeden sekret dla wybranej roli: @@ -314,9 +316,9 @@ Wymagane zmienne env: - `OPENCLAW_QA_CONVEX_SECRET_CI` dla `ci` - Wybór roli poświadczeń: - CLI: `--credential-role maintainer|ci` - - Domyślne env: `OPENCLAW_QA_CREDENTIAL_ROLE` (domyślnie `ci` w CI, w przeciwnym razie `maintainer`) + - Domyślna wartość env: `OPENCLAW_QA_CREDENTIAL_ROLE` (domyślnie `ci` w CI, w przeciwnym razie `maintainer`) -Opcjonalne zmienne env: +Opcjonalne zmienne środowiskowe: - `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (domyślnie `1200000`) - `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (domyślnie `30000`) @@ -324,14 +326,14 @@ Opcjonalne zmienne env: - `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 identyfikator śledzenia) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` zezwala na loopback URL-e Convex `http://` wyłącznie do lokalnego rozwoju. +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` zezwala na adresy URL Convex `http://` przez local loopback wyłącznie do lokalnego rozwoju. -`OPENCLAW_QA_CONVEX_SITE_URL` powinien używać `https://` podczas normalnej pracy. +`OPENCLAW_QA_CONVEX_SITE_URL` powinien używać `https://` podczas normalnego działania. -Polecenia administracyjne maintainer (dodawanie/usuwanie/listowanie puli) wymagają +Polecenia administratora maintainerów (dodawanie/usuwanie/listowanie puli) wymagają konkretnie `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -Pomocnicze polecenia CLI dla maintainerów: +Pomocnicy CLI dla maintainerów: ```bash pnpm openclaw qa credentials doctor @@ -340,33 +342,32 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Użyj `doctor` przed uruchomieniami na żywo, aby sprawdzić URL witryny Convex, sekrety brokera, -prefiks punktu końcowego, limit czasu HTTP oraz dostępność admin/list bez wypisywania -wartości sekretów. Użyj `--json`, aby uzyskać wyjście czytelne maszynowo w skryptach i -narzędziach CI. +Użyj `doctor` przed uruchomieniami na żywo, aby sprawdzić adres URL witryny Convex, sekrety brokera, +prefiks endpointu, limit czasu HTTP oraz osiągalność admin/list bez wypisywania +wartości sekretów. Użyj `--json` dla wyjścia czytelnego maszynowo w skryptach i narzędziach CI. -Domyślny kontrakt punktu końcowego (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): +Domyślny kontrakt endpointu (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Żądanie: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` - - Powodzenie: `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` - - Wyczerpane/możliwe do ponowienia: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` + - Sukces: `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` + - Wyczerpane/ponawialne: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - Żądanie: `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - - Powodzenie: `{ status: "ok" }` (lub puste `2xx`) + - Sukces: `{ status: "ok" }` (albo puste `2xx`) - `POST /release` - Żądanie: `{ kind, ownerId, actorRole, credentialId, leaseToken }` - - Powodzenie: `{ status: "ok" }` (lub puste `2xx`) -- `POST /admin/add` (tylko sekret maintainer) + - Sukces: `{ status: "ok" }` (albo puste `2xx`) +- `POST /admin/add` (tylko sekret maintainera) - Żądanie: `{ kind, actorId, payload, note?, status? }` - - Powodzenie: `{ status: "ok", credential }` -- `POST /admin/remove` (tylko sekret maintainer) + - Sukces: `{ status: "ok", credential }` +- `POST /admin/remove` (tylko sekret maintainera) - Żądanie: `{ credentialId, actorId }` - - Powodzenie: `{ status: "ok", changed, credential }` + - Sukces: `{ status: "ok", changed, credential }` - Ochrona aktywnej dzierżawy: `{ status: "error", code: "LEASE_ACTIVE", ... }` -- `POST /admin/list` (tylko sekret maintainer) +- `POST /admin/list` (tylko sekret maintainera) - Żądanie: `{ kind?, status?, includePayload?, limit? }` - - Powodzenie: `{ status: "ok", credentials, count }` + - Sukces: `{ status: "ok", credentials, count }` Kształt payloadu dla rodzaju Telegram: @@ -376,229 +377,232 @@ Kształt payloadu dla rodzaju Telegram: ### Dodawanie kanału do QA -Architektura i nazwy pomocników scenariuszy dla nowych adapterów kanałów znajdują się w [przeglądzie QA → Dodawanie kanału](/pl/concepts/qa-e2e-automation#adding-a-channel). Minimalny próg: zaimplementuj runner transportu na współdzielonej seam hosta `qa-lab`, zadeklaruj `qaRunners` w manifeście plugin, zamontuj jako `openclaw qa ` i napisz scenariusze w `qa/scenarios/`. +Architektura i nazwy pomocników scenariuszy dla nowych adapterów kanałów znajdują się w [przeglądzie QA → Dodawanie kanału](/pl/concepts/qa-e2e-automation#adding-a-channel). Minimalny próg: zaimplementuj runner transportu na współdzielonym styku hosta `qa-lab`, zadeklaruj `qaRunners` w manifeście pluginu, zamontuj jako `openclaw qa ` i napisz scenariusze pod `qa/scenarios/`. -## Zestawy testów (co uruchamia się gdzie) +## Zestawy testów (co działa gdzie) -Traktuj zestawy jako „coraz większy realizm” (oraz rosnącą niestabilność/koszt): +Myśl o zestawach jak o „rosnącym realizmie” (i rosnącej niestabilności/koszcie): ### Jednostkowe / integracyjne (domyślne) - Polecenie: `pnpm test` -- Konfiguracja: nieukierunkowane uruchomienia używają zestawu shardów `vitest.full-*.config.ts` i mogą rozwijać wieloprojektowe shardy do konfiguracji per projekt w celu równoległego harmonogramowania -- Pliki: inwentarze core/jednostkowe w `src/**/*.test.ts`, `packages/**/*.test.ts` i `test/**/*.test.ts`; testy jednostkowe UI działają w dedykowanym shardzie `unit-ui` +- Konfiguracja: nieukierunkowane uruchomienia używają zestawu shardów `vitest.full-*.config.ts` i mogą rozwijać shardy wieloprojektowe do konfiguracji per projekt dla równoległego planowania +- Pliki: inwentarze core/jednostkowe pod `src/**/*.test.ts`, `packages/**/*.test.ts` i `test/**/*.test.ts`; testy jednostkowe UI działają w dedykowanym shardzie `unit-ui` - Zakres: - Czyste testy jednostkowe - - Testy integracyjne w procesie (uwierzytelnianie gateway, routing, narzędzia, parsowanie, konfiguracja) + - Testy integracyjne w procesie (uwierzytelnianie Gateway, routing, narzędzia, parsowanie, konfiguracja) - Deterministyczne regresje dla znanych błędów - Oczekiwania: - - Uruchamia się w CI + - Działa w CI - Nie wymaga prawdziwych kluczy - Powinno być szybkie i stabilne - - Testy resolvera i loadera powierzchni publicznej muszą dowodzić szerokiego zachowania fallback `api.js` i - `runtime-api.js` przy użyciu wygenerowanych małych fixture plugin, a nie - prawdziwych API źródłowych dołączonego plugin. Prawdziwe ładowania API plugin należą do - kontraktowych/integracyjnych zestawów należących do plugin. + - Testy resolvera i loadera powierzchni publicznej muszą udowodnić szerokie zachowanie fallbacków `api.js` i + `runtime-api.js` z wygenerowanymi małymi fixturami pluginów, a nie + prawdziwymi źródłowymi API dołączonych pluginów. Ładowania prawdziwego API pluginów należą do + należących do pluginów zestawów kontraktowych/integracyjnych. - + - - Niekierunkowe `pnpm test` uruchamia 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. Zmniejsza to szczytowe RSS na obciążonych maszynach i zapobiega zagłodzeniu niepowiązanych zestawów przez zadania auto-reply/extension. - - `pnpm test --watch` nadal używa natywnego głównego grafu projektu `vitest.config.ts`, ponieważ pętla obserwowania z wieloma shardami nie jest praktyczna. - - `pnpm test`, `pnpm test:watch` i `pnpm test:perf:imports` kierują jawne cele plików/katalogów najpierw przez zakresowe ścieżki, więc `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` pozwala uniknąć pełnego kosztu startowego projektu głównego. - - `pnpm test:changed` domyślnie rozwija zmienione ścieżki git na tanie zakresowe ścieżki: bezpośrednie edycje testów, sąsiednie pliki `*.test.ts`, jawne mapowania źródeł i zależne lokalnego grafu importów. Edycje konfiguracji/setupu/pakietu nie uruchamiają szeroko testów, chyba że jawnie użyjesz `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. - - `pnpm check:changed` to standardowa inteligentna lokalna bramka sprawdzania dla wąskich prac. Klasyfikuje diff na core, testy core, extensions, testy extension, aplikacje, dokumentację, metadane wydania, narzędzia live Docker i narzędzia, a następnie uruchamia pasujące polecenia sprawdzania typów, lintowania i strażników. Nie uruchamia testów Vitest; użyj `pnpm test:changed` albo jawnego `pnpm test ` jako dowodu testowego. Zmiany wersji dotyczące wyłącznie metadanych wydania uruchamiają ukierunkowane kontrole wersji/konfiguracji/zależności głównych, ze strażnikiem odrzucającym zmiany pakietu poza polem wersji najwyższego poziomu. - - Edycje harnessa live Docker ACP uruchamiają ukierunkowane kontrole: składnię powłoki dla skryptów uwierzytelniania live Docker i przebieg próbny harmonogramu live Docker. Zmiany `package.json` są uwzględniane tylko wtedy, gdy diff ogranicza się do `scripts["test:docker:live-*"]`; edycje zależności, eksportów, wersji i innych powierzchni pakietu nadal używają szerszych strażników. - - Lekkie importowo testy jednostkowe agentów, poleceń, plugins, pomocników auto-reply, `plugin-sdk` i podobnych czystych obszarów narzędziowych są kierowane przez ścieżkę `unit-fast`, która pomija `test/setup-openclaw-runtime.ts`; pliki stanowe i mocno runtime’owe pozostają na istniejących ścieżkach. - - Wybrane pliki źródłowe pomocników `plugin-sdk` i `commands` również mapują uruchomienia trybu changed na jawne sąsiednie testy w tych lekkich ścieżkach, więc edycje pomocników unikają ponownego uruchamiania pełnego ciężkiego zestawu dla tego katalogu. - - `auto-reply` ma dedykowane kubełki dla pomocników core najwyższego poziomu, testów integracyjnych `reply.*` najwyższego poziomu oraz poddrzewa `src/auto-reply/reply/**`. CI dodatkowo dzieli poddrzewo reply na shardy agent-runner, dispatch i commands/state-routing, aby jeden kubełek z ciężkimi importami nie obejmował całego ogona Node. - - Normalne CI dla PR/main celowo pomija zbiorczy sweep extension i shard `agentic-plugins` tylko dla wydań. Pełna walidacja wydania uruchamia osobny workflow podrzędny `Plugin Prerelease` dla tych ciężkich zestawów plugin/extension na kandydatach do wydania. + - Nieukierunkowane `pnpm test` uruchamia dwanaście mniejszych konfiguracji fragmentó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. Zmniejsza to szczytowe RSS na obciążonych maszynach i zapobiega temu, by praca auto-reply/rozszerzeń zagłodziła niepowiązane zestawy testów. + - `pnpm test --watch` nadal używa natywnego grafu projektu głównego `vitest.config.ts`, ponieważ pętla obserwacji wielu fragmentów nie jest praktyczna. + - `pnpm test`, `pnpm test:watch` i `pnpm test:perf:imports` kierują jawne cele plików/katalogów najpierw przez zakresowe ścieżki, więc `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` unika płacenia pełnego kosztu startu projektu głównego. + - `pnpm test:changed` domyślnie rozwija zmienione ścieżki git do tanich zakresowych ścieżek: bezpośrednie edycje testów, sąsiednie pliki `*.test.ts`, jawne mapowania źródeł i lokalne zależności grafu importów. Edycje konfiguracji/setupu/pakietów nie uruchamiają szerokiego zestawu testów, chyba że jawnie użyjesz `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. + - `pnpm check:changed` to normalna inteligentna lokalna bramka sprawdzania dla wąskiej pracy. Klasyfikuje diff na core, testy core, rozszerzenia, testy rozszerzeń, aplikacje, dokumentację, metadane wydania, narzędzia live Docker i tooling, a następnie uruchamia pasujące polecenia typecheck, lint i guard. Nie uruchamia testów Vitest; wywołaj `pnpm test:changed` albo jawne `pnpm test ` jako dowód testowy. Zmiany wersji obejmujące wyłącznie metadane wydania uruchamiają ukierunkowane kontrole wersji/konfiguracji/zależności głównych, z guardem odrzucającym zmiany pakietu poza polem wersji najwyższego poziomu. + - Edycje harnessu live Docker ACP uruchamiają skupione kontrole: składnię powłoki dla skryptów uwierzytelniania live Docker oraz próbne uruchomienie harmonogramu live Docker. Zmiany `package.json` są uwzględniane tylko wtedy, gdy diff jest ograniczony do `scripts["test:docker:live-*"]`; edycje zależności, eksportów, wersji i innych powierzchni pakietu nadal używają szerszych guardów. + - Lekkie importowo testy jednostkowe z agentów, poleceń, plugins, pomocników auto-reply, `plugin-sdk` i podobnych obszarów czysto użytkowych są kierowane przez ścieżkę `unit-fast`, która pomija `test/setup-openclaw-runtime.ts`; pliki stanowe/ciężkie runtime pozostają na istniejących ścieżkach. + - Wybrane pliki źródłowe pomocników `plugin-sdk` i `commands` mapują również uruchomienia w trybie zmienionym na jawne sąsiednie testy w tych lekkich ścieżkach, więc edycje pomocników unikają ponownego uruchamiania pełnego ciężkiego zestawu dla tego katalogu. + - `auto-reply` ma dedykowane koszyki dla pomocników core najwyższego poziomu, testów integracyjnych najwyższego poziomu `reply.*` oraz poddrzewa `src/auto-reply/reply/**`. CI dodatkowo dzieli poddrzewo reply na fragmenty agent-runner, dispatch i commands/state-routing, aby jeden koszyk ciężki importowo nie posiadał całego ogona Node. + - Normalne CI dla PR/main celowo pomija wsadowy przegląd rozszerzeń i przeznaczony tylko dla wydań fragment `agentic-plugins`. Full Release Validation uruchamia osobny podrzędny workflow `Plugin Prerelease` dla tych ciężkich od plugins/rozszerzeń zestawów na kandydatach do wydania. - + - - Gdy zmieniasz wejścia wykrywania narzędzi wiadomości albo kontekst runtime compaction, utrzymuj oba poziomy pokrycia. - - Dodawaj ukierunkowane regresje pomocników dla czystych granic routingu i normalizacji. + - Gdy zmieniasz dane wejściowe wykrywania narzędzi wiadomości albo kontekst runtime Compaction, zachowaj oba poziomy pokrycia. + - Dodaj skupione regresje pomocników dla granic czystego routingu i normalizacji. - Utrzymuj w dobrym stanie zestawy integracyjne osadzonego runnera: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, - `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` i + `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 zakresowe identyfikatory i zachowanie compaction nadal przepływają przez rzeczywiste ścieżki `run.ts` / `compact.ts`; testy tylko pomocników nie są wystarczającym zamiennikiem tych ścieżek integracyjnych. + - Te zestawy sprawdzają, że zakresowe identyfikatory i zachowanie Compaction nadal przepływają przez rzeczywiste ścieżki `run.ts` / `compact.ts`; testy wyłącznie pomocników nie są wystarczającym zamiennikiem tych ścieżek integracyjnych. - + - Bazowa konfiguracja Vitest domyślnie używa `threads`. - - Wspólna konfiguracja Vitest ustawia `isolate: false` i używa nieizolowanego runnera w projektach głównych, konfiguracjach e2e i live. - - Główna ścieżka UI zachowuje swój setup i optymalizator `jsdom`, ale również działa na wspólnym nieizolowanym runnerze. - - Każdy shard `pnpm test` dziedziczy te same domyślne ustawienia `threads` + `isolate: false` ze wspólnej konfiguracji Vitest. - - `scripts/run-vitest.mjs` domyślnie dodaje `--no-maglev` dla procesów podrzędnych Vitest Node, aby zmniejszyć narzut kompilacji V8 podczas dużych lokalnych uruchomień. Ustaw `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, aby porównać ze standardowym zachowaniem V8. + - Współdzielona konfiguracja Vitest ustawia `isolate: false` i używa nieizolowanego runnera w projektach głównych, konfiguracjach e2e i live. + - Główna ścieżka UI zachowuje swój setup i optymalizator `jsdom`, ale także działa na współdzielonym nieizolowanym runnerze. + - Każdy fragment `pnpm test` dziedziczy te same domyślne ustawienia `threads` + `isolate: false` ze współdzielonej konfiguracji Vitest. + - `scripts/run-vitest.mjs` domyślnie dodaje `--no-maglev` dla procesów podrzędnych Node Vitest, aby ograniczyć narzut kompilacji V8 podczas dużych lokalnych uruchomień. + Ustaw `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, aby porównać ze standardowym zachowaniem V8. - + - - `pnpm changed:lanes` pokazuje, które ścieżki architektoniczne wywołuje diff. - - Hook pre-commit dotyczy tylko formatowania. Ponownie stage’uje sformatowane pliki i nie uruchamia lintowania, sprawdzania typów ani testów. - - Uruchom jawnie `pnpm check:changed` przed przekazaniem lub pushem, gdy potrzebujesz inteligentnej lokalnej bramki sprawdzania. - - `pnpm test:changed` domyślnie kieruje przez tanie zakresowe ścieżki. Użyj `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` tylko wtedy, gdy agent uzna, że edycja harnessa, konfiguracji, pakietu lub kontraktu naprawdę wymaga szerszego pokrycia Vitest. + - `pnpm changed:lanes` pokazuje, które ścieżki architektoniczne wyzwala diff. + - Hook pre-commit służy wyłącznie do formatowania. Ponownie stage’uje sformatowane pliki i nie uruchamia lint, typecheck ani testów. + - Uruchom jawnie `pnpm check:changed` przed przekazaniem lub push, gdy potrzebujesz inteligentnej lokalnej bramki sprawdzania. + - `pnpm test:changed` domyślnie kieruje przez tanie zakresowe ścieżki. Używaj `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` tylko wtedy, gdy agent uzna, że edycja harnessu, konfiguracji, pakietu lub kontraktu naprawdę wymaga szerszego pokrycia Vitest. - `pnpm test:max` i `pnpm test:changed:max` zachowują to samo zachowanie routingu, tylko z wyższym limitem workerów. - - Lokalne automatyczne skalowanie workerów jest celowo konserwatywne i 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 projekty/pliki konfiguracji jako `forceRerunTriggers`, aby ponowne uruchomienia w trybie changed pozostawały poprawne, gdy zmienia się okablowanie 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 jedną jawną lokalizację cache dla bezpośredniego profilowania. + - Lokalne automatyczne skalowanie workerów jest celowo konserwatywne i wycofuje się, gdy średnie obciążenie hosta jest już wysokie, więc wiele współbieżnych uruchomień Vitest domyślnie wyrządza mniej szkód. + - Bazowa konfiguracja Vitest oznacza projekty/pliki konfiguracji jako `forceRerunTriggers`, aby ponowne uruchomienia w trybie zmienionym pozostawały poprawne, gdy zmienia się okablowanie 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 jedną jawną lokalizację cache do bezpośredniego profilowania. - + - `pnpm test:perf:imports` włącza raportowanie czasu trwania importów Vitest oraz wyjście import-breakdown. - `pnpm test:perf:imports:changed` zawęża ten sam widok profilowania do plików zmienionych od `origin/main`. - - Dane czasów shardów są zapisywane do `.artifacts/vitest-shard-timings.json`. Uruchomienia całej konfiguracji używają ścieżki konfiguracji jako klucza; shardy CI z wzorcami include dodają nazwę sharda, aby filtrowane shardy można było śledzić osobno. - - Gdy jeden gorący test nadal spędza większość czasu na importach startowych, trzymaj ciężkie zależności za wąskim lokalnym szwem `*.runtime.ts` i mockuj ten szew bezpośrednio, zamiast głęboko importować pomocniki runtime tylko po to, aby przepuścić je przez `vi.mock(...)`. - - `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 zegarowy oraz maksymalne RSS macOS. - - `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 narzutu startowego i transformacji Vitest/Vite. - - `pnpm test:perf:profile:runner` zapisuje profile CPU+heap runnera dla zestawu jednostkowego z wyłączonym paralelizmem plików. + - Dane czasów fragmentów są zapisywane do `.artifacts/vitest-shard-timings.json`. + Uruchomienia całej konfiguracji używają ścieżki konfiguracji jako klucza; fragmenty CI z wzorcem include dopisują nazwę fragmentu, aby odfiltrowane fragmenty można było śledzić osobno. + - Gdy jeden gorący test nadal spędza większość czasu w importach startowych, trzymaj ciężkie zależności za wąską lokalną granicą `*.runtime.ts` i mockuj tę granicę bezpośrednio zamiast głęboko importować pomocniki runtime tylko po to, by przepuścić je przez `vi.mock(...)`. + - `pnpm test:perf:changed:bench -- --ref ` porównuje routowane `test:changed` z natywną ścieżką projektu głównego dla tego zatwierdzonego diffa i wypisuje czas rzeczywisty oraz maksymalne RSS macOS. + - `pnpm test:perf:changed:bench -- --worktree` benchmarkuje bieżące brudne drzewo, routują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 narzutów startu i transformacji Vitest/Vite. + - `pnpm test:perf:profile:runner` zapisuje profile CPU+heap runnera dla zestawu jednostkowego z wyłączoną równoległością plików. -### Stabilność (gateway) +### Stabilność (Gateway) - Polecenie: `pnpm test:stability:gateway` -- Konfiguracja: `vitest.gateway.config.ts`, wymuszone na jednego workera +- Konfiguracja: `vitest.gateway.config.ts`, wymuszona na jednego workera - Zakres: - - Uruchamia prawdziwy loopback Gateway z domyślnie włączoną diagnostyką + - Domyślnie uruchamia rzeczywisty Gateway loopback z 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 pomocniki trwałości pakietu stabilności diagnostycznej - - Asercje sprawdzają, że recorder pozostaje ograniczony, syntetyczne próbki RSS mieszczą się w budżecie presji, a głębokości kolejek na sesję wracają do zera + - Obejmuje pomocniki utrwalania pakietu stabilności diagnostycznej + - Sprawdza, że recorder pozostaje ograniczony, syntetyczne próbki RSS mieszczą się w budżecie presji, a głębokości kolejek na sesję spadają z powrotem do zera - Oczekiwania: - Bezpieczne dla CI i bez kluczy - - Wąska ścieżka dla dalszej pracy nad regresją stabilności, nie zamiennik pełnego zestawu Gateway + - Wąska ścieżka do dalszego śledzenia regresji stabilności, nie zamiennik pełnego zestawu Gateway -### E2E (gateway smoke) +### E2E (smoke Gateway) - Polecenie: `pnpm test:e2e` - Konfiguracja: `vitest.e2e.config.ts` -- Pliki: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` oraz testy E2E bundled-plugin w `extensions/` +- Pliki: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` oraz testy E2E bundled-plugin pod `extensions/` - Domyślne ustawienia runtime: - - Używa Vitest `threads` z `isolate: false`, zgodnie z resztą repozytorium. + - 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 cichym, aby ograniczyć narzut I/O konsoli. + - Domyślnie działa w trybie silent, aby zmniejszyć narzut I/O konsoli. - Przydatne nadpisania: - - `OPENCLAW_E2E_WORKERS=` aby wymusić liczbę workerów (limit 16). - - `OPENCLAW_E2E_VERBOSE=1` aby ponownie włączyć szczegółowe wyjście konsoli. + - `OPENCLAW_E2E_WORKERS=`, aby wymusić liczbę workerów (ograniczoną do 16). + - `OPENCLAW_E2E_VERBOSE=1`, aby ponownie włączyć szczegółowe wyjście konsoli. - Zakres: - - Zachowanie wielu instancji gateway end-to-end - - Powierzchnie WebSocket/HTTP, parowanie node i cięższe sieciowanie + - Zachowanie end-to-end wieloinstancyjnego gateway + - Powierzchnie WebSocket/HTTP, parowanie node i cięższa sieć - Oczekiwania: - - Działa w CI (gdy włączone w pipeline) + - Działa w CI (gdy jest włączone w pipeline) - Nie wymaga prawdziwych kluczy - Więcej ruchomych części niż testy jednostkowe (może być wolniejsze) -### E2E: OpenShell backend smoke +### 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 - - Tworzy sandbox z tymczasowego lokalnego pliku Dockerfile - - Testuje backend OpenShell OpenClaw przez prawdziwe `sandbox ssh-config` + wykonanie SSH - - Weryfikuje zachowanie systemu plików remote-canonical przez most sandbox fs + - Tworzy sandbox z tymczasowego lokalnego Dockerfile + - Ćwiczy backend OpenShell OpenClaw przez rzeczywiste `sandbox ssh-config` + SSH exec + - Weryfikuje zachowanie systemu plików w formie remote-canonical przez most sandbox fs - 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 izolowanych `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ć niestandardowy binarny CLI lub skrypt wrappera + - `OPENCLAW_E2E_OPENSHELL=1`, aby włączyć test podczas ręcznego uruchamiania szerszego zestawu e2e + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, aby wskazać niedomyślny binarny plik CLI lub skrypt opakowujący ### Live (prawdziwi dostawcy + prawdziwe modele) - Polecenie: `pnpm test:live` - Konfiguracja: `vitest.live.config.ts` -- Pliki: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` oraz testy live bundled-plugin w `extensions/` +- Pliki: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` oraz testy live bundled-plugin pod `extensions/` - Domyślnie: **włączone** przez `pnpm test:live` (ustawia `OPENCLAW_LIVE_TEST=1`) - Zakres: - „Czy ten dostawca/model faktycznie działa _dzisiaj_ z prawdziwymi danymi uwierzytelniającymi?” - - Wyłapywanie zmian formatu dostawców, osobliwości tool-calling, problemów z auth i zachowania limitów szybkości + - Wychwytywanie zmian formatu dostawców, osobliwości tool-calling, problemów z uwierzytelnianiem i zachowania limitów szybkości - Oczekiwania: - Z założenia niestabilne w CI (prawdziwe sieci, prawdziwe polityki dostawców, limity, awarie) - Kosztuje pieniądze / zużywa limity szybkości - Preferuj uruchamianie zawężonych podzbiorów zamiast „wszystkiego” -- Uruchomienia live źródłują `~/.profile`, aby pobrać brakujące klucze API. -- Domyślnie uruchomienia live nadal izolują `HOME` i kopiują materiały konfiguracji/auth do tymczasowego testowego katalogu domowego, aby fixture’y jednostkowe nie mogły zmienić prawdziwego `~/.openclaw`. -- Ustaw `OPENCLAW_LIVE_USE_REAL_HOME=1` tylko wtedy, gdy celowo potrzebujesz, aby testy live używały prawdziwego katalogu domowego. -- `pnpm test:live` domyślnie działa teraz w cichszym trybie: zachowuje wyjście postępu `[live] ...`, ale wycisza dodatkowy komunikat `~/.profile` oraz logi startowe gateway/szum Bonjour. Ustaw `OPENCLAW_LIVE_TEST_QUIET=0`, jeśli chcesz odzyskać pełne logi startowe. -- Rotacja kluczy API (specyficzna dla dostawcy): ustaw `*_API_KEYS` w formacie z przecinkami/średnikami 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 limitu szybkości. +- Uruchomienia live wczytują `~/.profile`, aby pobrać brakujące klucze API. +- Domyślnie uruchomienia live nadal izolują `HOME` i kopiują materiały konfiguracji/uwierzytelniania do tymczasowego testowego home, aby fixture’y jednostkowe nie mogły zmodyfikować twojego prawdziwego `~/.openclaw`. +- Ustaw `OPENCLAW_LIVE_USE_REAL_HOME=1` tylko wtedy, gdy celowo potrzebujesz, aby testy live używały twojego prawdziwego katalogu home. +- `pnpm test:live` teraz domyślnie używa cichszego trybu: zachowuje wyjście postępu `[live] ...`, ale ukrywa dodatkowe powiadomienie `~/.profile` i wycisza logi bootstrap Gateway/szum 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 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ą przy odpowiedziach limitu szybkości. - Wyjście postępu/heartbeat: - Zestawy live emitują teraz linie postępu do stderr, więc długie wywołania dostawców są 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 streamują natychmiast podczas uruchomień live. - - Dostrój heartbeat modeli bezpośrednich za pomocą `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Dostrój heartbeat gateway/probe za pomocą `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - `vitest.live.config.ts` wyłącza przechwytywanie konsoli Vitest, więc linie postępu dostawcy/gateway strumieniują natychmiast podczas uruchomień live. + - Dostrój heartbeats modeli bezpośrednich za pomocą `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Dostrój heartbeats gateway/probe za pomocą `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Który zestaw uruchomić? +## Który zestaw mam uruchomić? Użyj tej tabeli decyzyjnej: - Edycja logiki/testów: uruchom `pnpm test` (oraz `pnpm test:coverage`, jeśli zmieniono dużo) -- Zmiany w sieci Gateway / protokole WS / parowaniu: dodaj `pnpm test:e2e` +- Dotykanie sieci Gateway / protokołu WS / parowania: dodaj `pnpm test:e2e` - Debugowanie „mój bot nie działa” / awarii specyficznych dla dostawcy / wywoływania narzędzi: uruchom zawężone `pnpm test:live` -## Testy live (korzystające z sieci) +## Testy live (dotykające sieci) -Informacje o macierzy modeli live, testach smoke backendu CLI, testach smoke ACP, uprzęży serwera aplikacji Codex oraz wszystkich testach live dostawców mediów (Deepgram, BytePlus, ComfyUI, obraz, muzyka, wideo, uprząż mediów) — a także o obsłudze poświadczeń dla przebiegów live — znajdziesz w [Testowanie — zestawy live](/pl/help/testing-live). +Macierz modeli live, testy dymne backendu CLI, testy dymne ACP, harness serwera aplikacji Codex oraz wszystkie testy live dostawców mediów (Deepgram, BytePlus, ComfyUI, obraz, muzyka, wideo, media harness) — a także obsługę poświadczeń dla uruchomień live — opisuje [Testowanie — zestawy live](/pl/help/testing-live). -## Runner’y Docker (opcjonalne kontrole „działa w Linuksie”) +## Runnery Docker (opcjonalne sprawdzenia „działa w Linuksie”) -Te runner’y Docker dzielą się na dwie grupy: +Te runnery Docker dzielą się na dwie grupy: -- Runner’y modeli live: `test:docker:live-models` i `test:docker:live-gateway` uruchamiają tylko odpowiadający im plik live z kluczem profilu w obrazie Docker repozytorium (`src/agents/models.profiles.live.test.ts` i `src/gateway/gateway-models.profiles.live.test.ts`), montując lokalny katalog konfiguracji i obszar roboczy (oraz wczytując `~/.profile`, jeśli jest zamontowany). Odpowiadające lokalne punkty wejścia to `test:live:models-profiles` i `test:live:gateway-profiles`. -- Runner’y Docker live domyślnie używają mniejszego limitu smoke, aby pełny przebieg Docker pozostał praktyczny: +- Runnery modeli live: `test:docker:live-models` i `test:docker:live-gateway` uruchamiają tylko odpowiadający im plik live klucza profilu wewnątrz obrazu Docker repozytorium (`src/agents/models.profiles.live.test.ts` i `src/gateway/gateway-models.profiles.live.test.ts`), montując lokalny katalog konfiguracji i obszar roboczy (oraz źródłując `~/.profile`, jeśli jest zamontowany). Odpowiadające lokalne punkty wejścia to `test:live:models-profiles` i `test:live:gateway-profiles`. +- Runnery Docker live domyślnie używają mniejszego limitu testów dymnych, aby pełny przebieg Docker pozostał 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`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` oraz `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Nadpisz te zmienne środowiskowe, gdy - wyraźnie potrzebujesz większego, wyczerpującego skanowania. -- `test:docker:all` buduje obraz Docker live raz przez `test:docker:live-build`, pakuje OpenClaw raz jako tarball npm przez `scripts/package-openclaw-for-docker.mjs`, a następnie buduje/ponownie używa dwóch obrazów `scripts/e2e/Dockerfile`. Obraz podstawowy jest tylko runnerem Node/Git dla ścieżek instalacji/aktualizacji/zależności Plugin; te ścieżki montują wstępnie zbudowany tarball. Obraz funkcjonalny instaluje ten sam tarball w `/app` dla ścieżek funkcjonalności zbudowanej aplikacji. Definicje ścieżek Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`; logika planera znajduje się w `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` wykonuje wybrany plan. Agregat używa ważonego lokalnego harmonogramu: `OPENCLAW_DOCKER_ALL_PARALLELISM` kontroluje sloty procesów, a limity zasobów zapobiegają jednoczesnemu startowi ciężkich ścieżek live, instalacji npm i wielu usług. Jeśli pojedyncza ścieżka jest cięższa niż aktywne limity, harmonogram nadal może ją uruchomić, gdy pula jest pusta, a następnie utrzymuje ją jako jedyną działającą, aż pojemność znów będzie dostępna. Domyślne wartości to 10 slotów, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` oraz `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; dostrajaj `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` lub `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` tylko wtedy, gdy host Docker ma większy zapas. Runner domyślnie wykonuje wstępną kontrolę Docker, usuwa nieaktualne kontenery E2E OpenClaw, wypisuje status co 30 sekund, zapisuje czasy zakończonych powodzeniem ścieżek w `.artifacts/docker-tests/lane-timings.json` i używa tych czasów, aby w kolejnych przebiegach najpierw uruchamiać dłuższe ścieżki. Użyj `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, aby wypisać ważony manifest ścieżek bez budowania lub uruchamiania Docker, albo `node scripts/test-docker-all.mjs --plan-json`, aby wypisać plan CI dla wybranych ścieżek, potrzeb pakietów/obrazów i poświadczeń. -- `Package Acceptance` to natywna dla GitHub bramka pakietu sprawdzająca „czy ten instalowalny tarball działa jako produkt?”. Rozwiązuje jeden pakiet kandydujący z `source=npm`, `source=ref`, `source=url` lub `source=artifact`, przesyła go jako `package-under-test`, a następnie uruchamia wielokrotnego użytku ścieżki Docker E2E względem dokładnie tego tarballa zamiast ponownie pakować wybrany ref. `workflow_ref` wybiera zaufane skrypty workflow/uprzęży, a `package_ref` wybiera commit/gałąź/tag źródłowy do spakowania, gdy `source=ref`; pozwala to bieżącej logice akceptacji walidować starsze zaufane commity. Profile są uporządkowane według zakresu: `smoke` to szybka instalacja/kanał/agent plus Gateway/konfiguracja, `package` to kontrakt pakietu/aktualizacji/Plugin i domyślny natywny zamiennik dla większości pokrycia pakietu/aktualizacji Parallels, `product` dodaje kanały MCP, czyszczenie cron/subagent, wyszukiwanie internetowe OpenAI i OpenWebUI, a `full` uruchamia fragmenty Docker ze ścieżki wydania z OpenWebUI. Walidacja wydania uruchamia niestandardową deltę pakietu (`bundled-channel-deps-compat plugins-offline`) plus QA pakietu Telegram, ponieważ fragmenty Docker ze ścieżki wydania już pokrywają nakładające się ścieżki pakietu/aktualizacji/Plugin. Docelowe polecenia ponownego uruchomienia Docker w GitHub, generowane z artefaktów, zawierają wcześniejszy artefakt pakietu i przygotowane wejścia obrazów, gdy są dostępne, dzięki czemu nieudane ścieżki mogą uniknąć ponownego budowania pakietu i obrazów. -- Kontrole budowania i wydania uruchamiają `scripts/check-cli-bootstrap-imports.mjs` po tsdown. Strażnik przechodzi po statycznym zbudowanym grafie od `dist/entry.js` i `dist/cli/run-main.js` i kończy się niepowodzeniem, jeśli uruchomienie przed dyspozycją importuje zależności pakietów, takie jak Commander, interfejs promptów, undici lub logowanie, przed dyspozycją polecenia; utrzymuje też zbudowany fragment uruchomienia Gateway w limicie i odrzuca statyczne importy znanych zimnych ścieżek Gateway. Smoke spakowanego CLI obejmuje też pomoc root, pomoc onboard, pomoc doctor, status, schemat konfiguracji i polecenie listy modeli. -- Zgodność wsteczna Package Acceptance jest ograniczona do `2026.4.25` (włącznie z `2026.4.25-beta.*`). Do tej granicy uprząż toleruje tylko luki w metadanych wysłanych pakietów: pominięte prywatne wpisy inwentarza QA, brak `gateway install --wrapper`, brak plików poprawek w fixture git pochodzącej z tarballa, brak utrwalonego `update.channel`, starsze lokalizacje rekordów instalacji Plugin, brak utrwalania rekordów instalacji marketplace oraz migrację metadanych konfiguracji podczas `plugins update`. Dla pakietów po `2026.4.25` te ścieżki są ścisłymi niepowodzeniami. -- Runner’y smoke kontenerów: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `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. + jawnie chcesz wykonać większy, wyczerpujący skan. +- `test:docker:all` buduje obraz Docker live raz przez `test:docker:live-build`, pakuje OpenClaw raz jako tarball npm przez `scripts/package-openclaw-for-docker.mjs`, a następnie buduje/ponownie wykorzystuje dwa obrazy `scripts/e2e/Dockerfile`. Obraz podstawowy jest tylko runnerem Node/Git dla ścieżek instalacji/aktualizacji/zależności Plugin; te ścieżki montują wstępnie zbudowany tarball. Obraz funkcjonalny instaluje ten sam tarball w `/app` dla ścieżek funkcjonalności zbudowanej aplikacji. Definicje ścieżek Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`; logika planera znajduje się w `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` wykonuje wybrany plan. Agregat używa ważonego lokalnego schedulera: `OPENCLAW_DOCKER_ALL_PARALLELISM` steruje slotami procesów, a limity zasobów zapobiegają jednoczesnemu startowi ciężkich ścieżek live, npm-install i wielousługowych. Jeśli pojedyncza ścieżka jest cięższa niż aktywne limity, scheduler nadal może ją uruchomić, gdy pula jest pusta, a potem utrzymuje ją jako jedyną uruchomioną, aż pojemność znów będzie dostępna. Wartości domyślne to 10 slotów, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` i `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; dostrajaj `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` lub `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` tylko wtedy, gdy host Docker ma większy zapas. Runner domyślnie wykonuje preflight Docker, usuwa nieaktualne kontenery OpenClaw E2E, wypisuje status co 30 sekund, zapisuje czasy udanych ścieżek w `.artifacts/docker-tests/lane-timings.json` i używa tych czasów, aby w późniejszych uruchomieniach najpierw startować dłuższe ścieżki. Użyj `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, aby wypisać ważony manifest ścieżek bez budowania lub uruchamiania Docker, albo `node scripts/test-docker-all.mjs --plan-json`, aby wypisać plan CI dla wybranych ścieżek, potrzeb pakietów/obrazów i poświadczeń. +- `Package Acceptance` jest natywną dla GitHub bramką pakietu dla pytania „czy ten instalowalny tarball działa jako produkt?”. Rozwiązuje jeden pakiet kandydujący z `source=npm`, `source=ref`, `source=url` lub `source=artifact`, przesyła go jako `package-under-test`, a następnie uruchamia wielokrotnego użytku ścieżki Docker E2E względem dokładnie tego tarballa zamiast ponownie pakować wybraną referencję. `workflow_ref` wybiera zaufane skrypty workflow/harness, a `package_ref` wybiera commit/branch/tag źródłowy do spakowania, gdy `source=ref`; pozwala to bieżącej logice akceptacji walidować starsze zaufane commity. Profile są uporządkowane według zakresu: `smoke` to szybka instalacja/kanał/agent plus gateway/konfiguracja, `package` to kontrakt pakietu/aktualizacji/Plugin plus fixture keyless upgrade-survivor i domyślny natywny zamiennik większości pokrycia pakietu/aktualizacji w Parallels, `product` dodaje kanały MCP, czyszczenie cron/subagenta, wyszukiwanie WWW OpenAI i OpenWebUI, a `full` uruchamia fragmenty Docker ścieżki wydania z OpenWebUI. Walidacja wydania uruchamia niestandardową deltę pakietu (`bundled-channel-deps-compat plugins-offline`) plus QA pakietu Telegram, ponieważ fragmenty Docker ścieżki wydania już pokrywają nakładające się ścieżki pakietu/aktualizacji/Plugin. Docelowe polecenia ponownego uruchomienia GitHub Docker wygenerowane z artefaktów obejmują wcześniejszy artefakt pakietu i przygotowane wejścia obrazów, gdy są dostępne, dzięki czemu nieudane ścieżki mogą uniknąć ponownego budowania pakietu i obrazów. +- Sprawdzenia budowania i wydania uruchamiają `scripts/check-cli-bootstrap-imports.mjs` po tsdown. Strażnik przechodzi statyczny zbudowany graf od `dist/entry.js` i `dist/cli/run-main.js` i kończy się niepowodzeniem, jeśli start przed dispatch importuje zależności pakietu, takie jak Commander, prompt UI, undici lub logowanie przed dispatch polecenia; utrzymuje też zbudowany fragment uruchomienia Gateway poniżej budżetu i odrzuca statyczne importy znanych zimnych ścieżek Gateway. Test dymny spakowanego CLI obejmuje też pomoc główną, pomoc onboard, pomoc doctor, status, schemat konfiguracji i polecenie listy modeli. +- Zgodność wsteczna Package Acceptance jest ograniczona do `2026.4.25` (w tym `2026.4.25-beta.*`). Do tej granicy harness toleruje tylko luki metadanych wysłanego pakietu: pominięte prywatne wpisy inwentarza QA, brak `gateway install --wrapper`, brak plików patchy w fixture git pochodzącej z tarballa, brak utrwalonego `update.channel`, starsze lokalizacje rekordów instalacji Plugin, brak utrwalania rekordów instalacji marketplace oraz migrację metadanych konfiguracji podczas `plugins update`. Dla pakietów po `2026.4.25` te ścieżki są ścisłymi niepowodzeniami. +- Runnery testów dymnych kontenerów: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` i `test:docker:config-reload` uruchamiają jeden lub więcej rzeczywistych kontenerów i weryfikują ścieżki integracji wyższego poziomu. -Runner’y Docker modeli live montują też tylko potrzebne katalogi domowe uwierzytelniania CLI (albo wszystkie obsługiwane, gdy przebieg nie jest zawężony), a następnie kopiują je do katalogu domowego kontenera przed przebiegiem, aby OAuth zewnętrznego CLI mógł odświeżać tokeny bez modyfikowania magazynu uwierzytelniania hosta: +Runnery Docker modeli live montują też tylko potrzebne katalogi domowe uwierzytelniania CLI (lub wszystkie obsługiwane, gdy uruchomienie nie jest zawężone), a następnie kopiują je do katalogu domowego kontenera przed uruchomieniem, aby OAuth zewnętrznego CLI mógł odświeżać tokeny bez modyfikowania magazynu uwierzytelniania hosta: - Modele bezpośrednie: `pnpm test:docker:live-models` (skrypt: `scripts/test-live-models-docker.sh`) - Smoke test wiązania ACP: `pnpm test:docker:live-acp-bind` (skrypt: `scripts/test-live-acp-bind-docker.sh`; domyślnie obejmuje Claude, Codex i Gemini, ze ścisłym pokryciem Droid/OpenCode przez `pnpm test:docker:live-acp-bind:droid` i `pnpm test:docker:live-acp-bind:opencode`) - Smoke test backendu CLI: `pnpm test:docker:live-cli-backend` (skrypt: `scripts/test-live-cli-backend-docker.sh`) -- Smoke test harnessu serwera aplikacji Codex: `pnpm test:docker:live-codex-harness` (skrypt: `scripts/test-live-codex-harness-docker.sh`) +- Smoke test uprzęży serwera aplikacji Codex: `pnpm test:docker:live-codex-harness` (skrypt: `scripts/test-live-codex-harness-docker.sh`) - Gateway + agent deweloperski: `pnpm test:docker:live-gateway` (skrypt: `scripts/test-live-gateway-models-docker.sh`) -- Smoke test obserwowalności: `pnpm qa:otel:smoke` to prywatna ścieżka QA z checkoutu źródeł. Celowo nie jest częścią ścieżek wydania pakietu Docker, ponieważ tarball npm pomija QA Lab. -- Live smoke test 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 test tarballa npm dla onboardingu/kanału/agenta: `pnpm test:docker:npm-onboard-channel-agent` instaluje spakowany tarball OpenClaw globalnie w Dockerze, konfiguruje OpenAI przez onboarding z odwołaniem do env oraz domyślnie Telegram, sprawdza, czy doctor naprawił aktywowane zależności środowiska runtime Plugin, i uruchamia jedną zamockowaną turę agenta OpenAI. Użyj ponownie wstępnie zbudowanego tarballa przez `OPENCLAW_CURRENT_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`. -- Smoke test przełączania kanału aktualizacji: `pnpm test:docker:update-channel-switch` instaluje spakowany tarball OpenClaw globalnie w Dockerze, przełącza z pakietowego `stable` na gitowy `dev`, weryfikuje utrwalony kanał i działanie Plugin po aktualizacji, a następnie przełącza z powrotem na pakietowy `stable` i sprawdza status aktualizacji. -- Smoke test kontekstu runtime sesji: `pnpm test:docker:session-runtime-context` weryfikuje utrwalanie transkryptu ukrytego kontekstu runtime oraz naprawę doctor dla dotkniętych zduplikowanych gałęzi przepisywania promptu. -- Smoke test globalnej instalacji Bun: `bash scripts/e2e/bun-global-install-smoke.sh` pakuje bieżące drzewo, instaluje je przez `bun install -g` w izolowanym katalogu domowym i weryfikuje, że `openclaw infer image providers --json` zwraca wbudowanych dostawców obrazów zamiast zawieszać się. Użyj ponownie wstępnie zbudowanego tarballa przez `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, pomiń build hosta przez `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` albo skopiuj `dist/` ze zbudowanego obrazu Dockera przez `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. -- Smoke test instalatora Docker: `bash scripts/test-install-sh-docker.sh` współdzieli jeden cache npm między kontenerami root, update i direct-npm. Smoke test aktualizacji domyślnie używa npm `latest` jako stabilnej bazowej wersji przed aktualizacją do kandydującego tarballa. Nadpisz lokalnie przez `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` albo w GitHubie przez wejście `update_baseline_version` workflow Install Smoke. Testy instalatora bez roota zachowują izolowany cache npm, aby wpisy cache należące do roota nie maskowały zachowania instalacji lokalnej dla użytkownika. Ustaw `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, aby ponownie używać cache root/update/direct-npm między lokalnymi ponownymi uruchomieniami. -- Install Smoke CI pomija zduplikowaną globalną aktualizację direct-npm przez `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; uruchom skrypt lokalnie bez tej zmiennej env, gdy potrzebne jest pokrycie bezpośredniego `npm install -g`. -- Smoke test CLI usuwania współdzielonego workspace przez agentów: `pnpm test:docker:agents-delete-shared-workspace` (skrypt: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) domyślnie buduje główny obraz Dockerfile, zasila dwóch agentów jednym workspace w izolowanym katalogu domowym kontenera, uruchamia `agents delete --json` i weryfikuje poprawny JSON oraz zachowanie zachowanego workspace. Użyj ponownie obrazu install-smoke przez `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. -- Sieć Gateway (dwa kontenery, uwierzytelnianie WS + health): `pnpm test:docker:gateway-network` (skrypt: `scripts/e2e/gateway-network-docker.sh`) -- Smoke test snapshotu CDP przeglądarki: `pnpm test:docker:browser-cdp-snapshot` (skrypt: `scripts/e2e/browser-cdp-snapshot-docker.sh`) buduje obraz źródłowy E2E oraz warstwę Chromium, uruchamia Chromium z surowym CDP, uruchamia `browser doctor --deep` i weryfikuje, że snapshoty ról CDP obejmują adresy URL linków, elementy klikalne promowane kursorem, referencje iframe i metadane ramek. -- Regresja OpenAI Responses web_search z minimalnym reasoning: `pnpm test:docker:openai-web-search-minimal` (skrypt: `scripts/e2e/openai-web-search-minimal-docker.sh`) uruchamia zamockowany serwer OpenAI przez Gateway, weryfikuje, że `web_search` podnosi `reasoning.effort` z `minimal` do `low`, a następnie wymusza odrzucenie schematu dostawcy i sprawdza, czy surowe szczegóły pojawiają się w logach Gateway. -- Most kanałów MCP (zasiany Gateway + most stdio + smoke test surowej ramki powiadomienia Claude): `pnpm test:docker:mcp-channels` (skrypt: `scripts/e2e/mcp-channels-docker.sh`) -- Narzędzia MCP pakietu Pi (rzeczywisty serwer stdio MCP + smoke test allow/deny osadzonego profilu Pi): `pnpm test:docker:pi-bundle-mcp-tools` (skrypt: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Czyszczenie MCP Cron/subagenta (rzeczywisty Gateway + wygaszanie procesu potomnego stdio MCP po izolowanych uruchomieniach cron i jednorazowego subagenta): `pnpm test:docker:cron-mcp-cleanup` (skrypt: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Pluginy (smoke test instalacji, instalacja/odinstalowanie typu kitchen-sink w ClawHub, aktualizacje marketplace oraz włączanie/inspekcja pakietu Claude): `pnpm test:docker:plugins` (skrypt: `scripts/e2e/plugins-docker.sh`) - Ustaw `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, aby pominąć blok ClawHub, albo nadpisz domyślną parę pakiet/runtime kitchen-sink przez `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` i `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Bez `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` test używa hermetycznego lokalnego serwera fixture ClawHub. -- Smoke test niezmienionej aktualizacji Plugin: `pnpm test:docker:plugin-update` (skrypt: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Smoke test obserwowalności: `pnpm qa:otel:smoke` to prywatna ścieżka QA z checkoutem źródeł. Celowo nie jest częścią ścieżek wydania pakietu Docker, ponieważ tarball npm pomija QA Lab. +- Smoke test Open WebUI na żywo: `pnpm test:docker:openwebui` (skrypt: `scripts/e2e/openwebui-docker.sh`) +- Kreator onboardingu (TTY, pełne rusztowanie): `pnpm test:docker:onboard` (skrypt: `scripts/e2e/onboard-docker.sh`) +- Smoke test onboardingu/kanału/agenta z tarballa npm: `pnpm test:docker:npm-onboard-channel-agent` instaluje spakowany tarball OpenClaw globalnie w Dockerze, konfiguruje OpenAI przez onboarding z odwołaniami do zmiennych środowiskowych oraz domyślnie Telegram, sprawdza, czy doctor naprawił aktywowane zależności runtime Plugin, i uruchamia jeden zamockowany obrót agenta OpenAI. Użyj ponownie wstępnie zbudowanego tarballa za pomocą `OPENCLAW_CURRENT_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`. +- Smoke test przełączania kanału aktualizacji: `pnpm test:docker:update-channel-switch` instaluje spakowany tarball OpenClaw globalnie w Dockerze, przełącza z pakietu `stable` na git `dev`, sprawdza utrwalony kanał oraz działanie Plugin po aktualizacji, a następnie przełącza z powrotem na pakiet `stable` i sprawdza status aktualizacji. +- Smoke test przetrwania aktualizacji: `pnpm test:docker:upgrade-survivor` instaluje spakowany tarball OpenClaw na zabrudzonym fixture starego użytkownika z agentami, konfiguracją kanałów, listami dozwolonych Plugin, nieaktualnym stanem zależności runtime Plugin oraz istniejącymi plikami przestrzeni roboczej/sesji. Uruchamia aktualizację pakietu oraz nieinteraktywny doctor bez kluczy dostawcy ani kanału na żywo, następnie uruchamia Gateway przez loopback i sprawdza zachowanie konfiguracji/stanu oraz budżety uruchamiania/statusu. +- Smoke test kontekstu runtime sesji: `pnpm test:docker:session-runtime-context` sprawdza utrwalanie ukrytego kontekstu runtime w transkrypcie oraz naprawę doctor dla dotkniętych zduplikowanych gałęzi przepisywania promptu. +- Smoke test globalnej instalacji Bun: `bash scripts/e2e/bun-global-install-smoke.sh` pakuje bieżące drzewo, instaluje je przez `bun install -g` w izolowanym katalogu domowym i sprawdza, czy `openclaw infer image providers --json` zwraca dołączonych dostawców obrazów zamiast się zawieszać. Użyj ponownie wstępnie zbudowanego tarballa za pomocą `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, pomiń budowanie na hoście przez `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` albo skopiuj `dist/` ze zbudowanego obrazu Docker za pomocą `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Smoke test instalatora Docker: `bash scripts/test-install-sh-docker.sh` współdzieli jedną pamięć podręczną npm między kontenerami root, update i direct-npm. Smoke test aktualizacji domyślnie używa npm `latest` jako stabilnej bazy przed aktualizacją do kandydującego tarballa. Nadpisz lokalnie przez `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` albo na GitHubie przez wejście `update_baseline_version` workflow Install Smoke. Kontrole instalatora bez uprawnień root zachowują izolowaną pamięć podręczną npm, aby wpisy pamięci podręcznej należące do roota nie maskowały zachowania instalacji lokalnej użytkownika. Ustaw `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, aby ponownie używać pamięci podręcznej root/update/direct-npm między lokalnymi ponownymi uruchomieniami. +- Install Smoke CI pomija zduplikowaną globalną aktualizację direct-npm przez `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; uruchom skrypt lokalnie bez tej zmiennej środowiskowej, gdy potrzebne jest pokrycie bezpośredniego `npm install -g`. +- Smoke test CLI usuwania współdzielonej przestrzeni roboczej agentów: `pnpm test:docker:agents-delete-shared-workspace` (skrypt: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) domyślnie buduje obraz z głównego Dockerfile, zasiewa dwóch agentów z jedną przestrzenią roboczą w izolowanym katalogu domowym kontenera, uruchamia `agents delete --json` i sprawdza poprawny JSON oraz zachowanie zachowanej przestrzeni roboczej. Użyj ponownie obrazu install-smoke przez `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. +- Sieć Gateway (dwa kontenery, uwierzytelnianie WS + zdrowie): `pnpm test:docker:gateway-network` (skrypt: `scripts/e2e/gateway-network-docker.sh`) +- Smoke test zrzutu przeglądarki CDP: `pnpm test:docker:browser-cdp-snapshot` (skrypt: `scripts/e2e/browser-cdp-snapshot-docker.sh`) buduje źródłowy obraz E2E oraz warstwę Chromium, uruchamia Chromium z surowym CDP, uruchamia `browser doctor --deep` i sprawdza, czy zrzuty ról CDP obejmują URL-e linków, elementy klikalne promowane kursorem, referencje iframe oraz metadane ramek. +- Regresja minimalnego rozumowania OpenAI Responses web_search: `pnpm test:docker:openai-web-search-minimal` (skrypt: `scripts/e2e/openai-web-search-minimal-docker.sh`) uruchamia zamockowany serwer OpenAI przez Gateway, sprawdza, czy `web_search` podnosi `reasoning.effort` z `minimal` do `low`, następnie wymusza odrzucenie schematu dostawcy i sprawdza, czy surowy szczegół pojawia się w logach Gateway. +- Most kanałów MCP (zasiany Gateway + most stdio + surowy smoke test ramki powiadomienia Claude): `pnpm test:docker:mcp-channels` (skrypt: `scripts/e2e/mcp-channels-docker.sh`) +- Narzędzia MCP pakietu Pi (rzeczywisty serwer MCP stdio + smoke test 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 + demontaż procesu potomnego MCP stdio po izolowanym cron i jednorazowych uruchomieniach subagenta): `pnpm test:docker:cron-mcp-cleanup` (skrypt: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Pluginy (smoke test instalacji, instalacja/dezinstalacja ClawHub kitchen-sink, aktualizacje marketplace oraz włączanie/inspekcja pakietu Claude): `pnpm test:docker:plugins` (skrypt: `scripts/e2e/plugins-docker.sh`) + Ustaw `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, aby pominąć blok ClawHub, albo nadpisz domyślną parę pakiet/runtime kitchen-sink za pomocą `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` i `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Bez `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` test używa hermetycznego lokalnego serwera fixture ClawHub. +- Smoke test braku zmian przy aktualizacji Plugin: `pnpm test:docker:plugin-update` (skrypt: `scripts/e2e/plugin-update-unchanged-docker.sh`) - Smoke test metadanych przeładowania konfiguracji: `pnpm test:docker:config-reload` (skrypt: `scripts/e2e/config-reload-source-docker.sh`) -- Zależności runtime wbudowanego Plugin: `pnpm test:docker:bundled-channel-deps` domyślnie buduje mały obraz runnera Dockera, buduje i pakuje OpenClaw raz na hoście, a następnie montuje ten tarball w każdym scenariuszu instalacji Linuksa. 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_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Pełny agregat Docker i fragmenty ścieżki wydania bundled-channel wstępnie pakują ten tarball raz, a następnie dzielą kontrole wbudowanych kanałów na niezależne ścieżki, w tym osobne ścieżki aktualizacji dla Telegram, Discord, Slack, Feishu, memory-lancedb i ACPX. Fragmenty wydania dzielą smoke testy kanałów, cele aktualizacji oraz kontrakty setup/runtime na `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` i `bundled-channels-contracts`; agregat `bundled-channels` pozostaje dostępny do ręcznych ponownych uruchomień. Workflow wydania dzieli też fragmenty instalatora dostawców oraz fragmenty instalacji/odinstalowania wbudowanego Plugin; starsze fragmenty `package-update`, `plugins-runtime` i `plugins-integrations` pozostają aliasami agregatów do ręcznych ponownych uruchomień. Użyj `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, aby zawęzić macierz kanałów przy bezpośrednim uruchamianiu tej ścieżki, albo `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, aby zawęzić scenariusz aktualizacji. Uruchomienia Dockera dla poszczególnych scenariuszy domyślnie używają `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s`; scenariusz aktualizacji wielu celów domyślnie używa `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. Ścieżka weryfikuje też, że `channels..enabled=false` i `plugins.entries..enabled=false` blokują naprawę doctor/zależności runtime. -- Zawężaj zależności runtime wbudowanego Plugin podczas iteracji, wyłączając niepowiązane scenariusze, na przykład: +- Zależności runtime dołączonych Plugin: `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 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_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Pełny agregat Docker oraz części bundled-channel ścieżki wydania pakują ten tarball wstępnie raz, a następnie dzielą kontrole dołączonych kanałów na niezależne ścieżki, w tym osobne ścieżki aktualizacji dla Telegram, Discord, Slack, Feishu, memory-lancedb i ACPX. Części wydania dzielą smoke testy kanałów, cele aktualizacji oraz kontrakty setup/runtime na `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` i `bundled-channels-contracts`; agregat `bundled-channels` pozostaje dostępny do ręcznych ponownych uruchomień. Workflow wydania dzieli też części instalatora dostawców oraz części instalacji/dezinstalacji dołączonych Plugin; starsze części `package-update`, `plugins-runtime` i `plugins-integrations` pozostają aliasami agregatów do ręcznych ponownych uruchomień. Użyj `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, aby zawęzić macierz kanałów przy bezpośrednim uruchamianiu dołączonej ścieżki, albo `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, aby zawęzić scenariusz aktualizacji. Uruchomienia Docker dla poszczególnych scenariuszy domyślnie używają `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s`; scenariusz aktualizacji wielu celów domyślnie używa `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. Ścieżka sprawdza też, czy `channels..enabled=false` i `plugins.entries..enabled=false` wyłączają naprawę doctor/zależności runtime. +- Zawęź zależności runtime dołączonych Plugin podczas iteracji, wyłączając niepowią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 ponownie użyć współdzielonego obrazu funkcjonalnego: @@ -608,110 +612,110 @@ OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker: OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Nadpisania obrazów właściwe dla pakietów, 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 jest jeszcze lokalny. Testy QR i instalatora Docker zachowują własne Dockerfile, ponieważ weryfikują zachowanie pakietu/instalacji, a nie współdzielony runtime zbudowanej aplikacji. +Nadpisania obrazów 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 jest już lokalny. Testy Docker QR i instalatora zachowują własne pliki Dockerfile, ponieważ walidują zachowanie pakietu/instalacji, a nie współdzielony runtime zbudowanej aplikacji. -Runnery Dockera live-model montują też bieżący checkout tylko do odczytu i -etapują go w tymczasowym katalogu roboczym wewnątrz kontenera. Dzięki temu obraz -runtime pozostaje mały, a Vitest nadal działa na dokładnie lokalnym źródle/konfiguracji. -Krok etapowania pomija duże lokalne cache i wyniki buildów aplikacji, takie jak -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` oraz lokalne dla aplikacji katalogi wyników `.build` lub +Runnery Docker dla modeli live również montują bieżący checkout w trybie tylko do odczytu i +przenoszą go do tymczasowego katalogu roboczego wewnątrz kontenera. Dzięki temu obraz +runtime pozostaje lekki, a Vitest nadal działa na dokładnie Twoim lokalnym źródle/konfiguracji. +Krok przygotowania pomija duże lokalne pamięci podręczne i wyjścia buildów aplikacji, takie jak +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` oraz lokalne dla aplikacji katalogi wyjściowe `.build` lub Gradle, aby uruchomienia live w Dockerze nie spędzały minut na kopiowaniu artefaktów specyficznych dla maszyny. Ustawiają też `OPENCLAW_SKIP_CHANNELS=1`, aby sondy live Gateway nie uruchamiały -rzeczywistych workerów kanałów Telegram/Discord/itd. wewnątrz kontenera. +prawdziwych workerów kanałów Telegram/Discord/itd. wewnątrz kontenera. `test:docker:live-models` nadal uruchamia `pnpm test:live`, więc przekaż także `OPENCLAW_LIVE_GATEWAY_*`, gdy musisz zawęzić lub wykluczyć pokrycie live Gateway z tej ścieżki Docker. -`test:docker:openwebui` to smoke test zgodności wyższego poziomu: uruchamia +`test:docker:openwebui` to smoke test kompatybilności wyższego poziomu: uruchamia kontener Gateway OpenClaw z włączonymi endpointami HTTP zgodnymi z OpenAI, uruchamia przypięty kontener Open WebUI względem tego Gateway, loguje się przez -Open WebUI, weryfikuje, że `/api/models` eksponuje `openclaw/default`, a następnie wysyła -rzeczywiste żądanie czatu przez proxy `/api/chat/completions` Open WebUI. +Open WebUI, sprawdza, że `/api/models` udostępnia `openclaw/default`, a następnie wysyła +prawdziwe żądanie czatu przez proxy `/api/chat/completions` Open WebUI. Pierwsze uruchomienie może być zauważalnie wolniejsze, ponieważ Docker może musieć pobrać -obraz Open WebUI, a Open WebUI może musieć dokończyć własny zimny start. +obraz Open WebUI, a Open WebUI może musieć dokończyć własną konfigurację zimnego startu. Ta ścieżka oczekuje użytecznego klucza modelu live, a `OPENCLAW_PROFILE_FILE` -(domyślnie `~/.profile`) jest podstawowym sposobem przekazania go w uruchomieniach zdockeryzowanych. +(domyślnie `~/.profile`) jest podstawowym sposobem dostarczenia go w uruchomieniach w Dockerze. Udane uruchomienia wypisują mały payload JSON, taki jak `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` jest celowo deterministyczny i nie wymaga -rzeczywistego konta Telegram, Discord ani iMessage. Uruchamia zasiany kontener Gateway, +prawdziwego konta Telegram, Discord ani iMessage. Uruchamia wstępnie zasilony kontener Gateway, uruchamia drugi kontener, który spawnuje `openclaw mcp serve`, a następnie -weryfikuje wykrywanie trasowanych rozmów, odczyty transkryptów, metadane załączników, -zachowanie kolejki zdarzeń live, trasowanie wysyłki wychodzącej oraz powiadomienia kanałów w stylu Claude + -uprawnienia przez rzeczywisty most stdio MCP. Kontrola powiadomień -bezpośrednio sprawdza surowe ramki stdio MCP, więc smoke test waliduje to, co -most faktycznie emituje, a nie tylko to, co akurat eksponuje konkretny SDK klienta. +weryfikuje wykrywanie routowanych konwersacji, odczyty transkryptów, metadane załączników, +zachowanie kolejki zdarzeń live, routowanie wysyłania wychodzącego oraz powiadomienia kanału + +uprawnień w stylu Claude przez prawdziwy most MCP stdio. Sprawdzenie powiadomień +inspektuje bezpośrednio surowe ramki MCP stdio, dzięki czemu smoke test weryfikuje to, co +most faktycznie emituje, a nie tylko to, co przypadkowo eksponuje konkretny SDK klienta. `test:docker:pi-bundle-mcp-tools` jest deterministyczny i nie wymaga klucza modelu live. -Buduje obraz Dockera repozytorium, uruchamia rzeczywisty serwer sondy stdio MCP -wewnątrz kontenera, materializuje ten serwer przez osadzony runtime MCP pakietu Pi, -wykonuje narzędzie, a następnie weryfikuje, że `coding` i `messaging` zachowują +Buduje obraz Docker repozytorium, uruchamia prawdziwy serwer sondy MCP stdio +wewnątrz kontenera, materializuje ten serwer przez osadzony runtime pakietu Pi +MCP, wykonuje narzędzie, a następnie sprawdza, ż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 wymaga klucza modelu live. -Uruchamia zasiany Gateway z rzeczywistym serwerem sondy stdio MCP, wykonuje -izolowaną turę cron oraz jednorazową turę potomną `/subagents spawn`, a następnie weryfikuje, -że proces potomny MCP kończy działanie po każdym uruchomieniu. +Uruchamia wstępnie zasilony Gateway z prawdziwym serwerem sondy MCP stdio, wykonuje +izolowaną turę Cron oraz jednorazową turę potomną `/subagents spawn`, a następnie sprawdza, +że proces potomny MCP kończy się po każdym uruchomieniu. Ręczny smoke test wątku ACP w języku naturalnym (nie CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Zachowaj ten skrypt dla przepływów regresji/debugowania. Może być ponownie potrzebny do walidacji routingu wątków ACP, więc go nie usuwaj. +- Zachowaj ten skrypt dla przepływów regresji/debugowania. Może być ponownie potrzebny do walidacji routowania wątków ACP, więc nie usuwaj go. Przydatne zmienne środowiskowe: - `OPENCLAW_CONFIG_DIR=...` (domyślnie: `~/.openclaw`) montowane do `/home/node/.openclaw` - `OPENCLAW_WORKSPACE_DIR=...` (domyślnie: `~/.openclaw/workspace`) montowane do `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (domyślnie: `~/.profile`) montowane do `/home/node/.profile` i ładowane przed uruchomieniem testów -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, aby zweryfikować tylko zmienne środowiskowe ładowane z `OPENCLAW_PROFILE_FILE`, z użyciem tymczasowych katalogów konfiguracji/obszaru roboczego i bez zewnętrznych montowań uwierzytelniania CLI -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (domyślnie: `~/.cache/openclaw/docker-cli-tools`) montowane do `/home/node/.npm-global` dla buforowanych instalacji CLI wewnątrz Dockera -- Zewnętrzne katalogi/pliki uwierzytelniania CLI pod `$HOME` są montowane tylko do odczytu pod `/host-auth...`, a następnie kopiowane do `/home/node/...` przed startem testów +- `OPENCLAW_PROFILE_FILE=...` (domyślnie: `~/.profile`) montowane do `/home/node/.profile` i source'owane przed uruchomieniem testów +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, aby zweryfikować tylko zmienne środowiskowe source'owane z `OPENCLAW_PROFILE_FILE`, przy użyciu tymczasowych katalogów konfiguracji/przestrzeni roboczej i bez zewnętrznych montowań auth CLI +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (domyślnie: `~/.cache/openclaw/docker-cli-tools`) montowane do `/home/node/.npm-global` dla buforowanych instalacji CLI wewnątrz Docker +- Zewnętrzne katalogi/pliki auth CLI pod `$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 uruchomienia dostawców montują tylko potrzebne katalogi/pliki wywnioskowane z `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Nadpisz ręcznie za pomocą `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` albo listy rozdzielonej przecinkami, takiej jak `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` + - Nadpisz ręcznie za pomocą `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` lub listy rozdzielonej 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` dla ponownych uruchomień, które nie wymagają przebudowy -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby upewnić się, że dane uwierzytelniające pochodzą z magazynu profilu (nie ze zmiennych środowiskowych) -- `OPENCLAW_OPENWEBUI_MODEL=...`, aby wybrać model wystawiany przez Gateway dla testu smoke Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...`, aby nadpisać prompt sprawdzania nonce używany przez test smoke Open WebUI +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby ponownie użyć istniejącego obrazu `openclaw:local-live` dla powtórzeń, które nie wymagają przebudowy +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby upewnić się, że poświadczenia pochodzą z magazynu profilu (nie z env) +- `OPENCLAW_OPENWEBUI_MODEL=...`, aby wybrać model udostępniany przez Gateway dla smoke testu Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, aby nadpisać prompt sprawdzający nonce używany przez smoke test Open WebUI - `OPENWEBUI_IMAGE=...`, aby nadpisać przypięty tag obrazu Open WebUI -## Kontrola poprawności dokumentacji +## Kontrola spójności dokumentacji -Uruchom kontrole dokumentacji po edycjach dokumentów: `pnpm check:docs`. -Uruchom pełną walidację kotwic Mintlify, gdy potrzebujesz także kontroli nagłówków na stronie: `pnpm docs:check-links:anchors`. +Uruchamiaj kontrole dokumentacji po edycjach dokumentów: `pnpm check:docs`. +Uruchom pełną walidację anchorów Mintlify, gdy potrzebujesz także kontroli nagłówków na stronie: `pnpm docs:check-links:anchors`. ## Regresja offline (bezpieczna dla CI) -To są regresje „prawdziwego potoku” bez prawdziwych dostawców: +To są regresje „prawdziwego pipeline'u” bez prawdziwych 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`, zapisuje konfigurację + wymuszone uwierzytelnianie): `src/gateway/gateway.test.ts` (przypadek: "runs wizard over ws and writes auth token config") +- 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`, zapisuje konfigurację + wymuszone auth): `src/gateway/gateway.test.ts` (przypadek: "runs wizard over ws and writes auth token config") ## Ewaluacje niezawodności agenta (Skills) -Mamy już kilka bezpiecznych dla CI testów, które zachowują się jak „ewaluacje niezawodności agenta”: +Mamy już kilka testów bezpiecznych dla CI, które zachowują się jak „ewaluacje niezawodności agenta”: -- Mock wywoływania narzędzi przez prawdziwy gateway + pętlę agenta (`src/gateway/gateway.test.ts`). +- Mockowane wywoływanie narzędzi przez prawdziwy Gateway + pętlę agenta (`src/gateway/gateway.test.ts`). - Przepływy kreatora end-to-end, które walidują okablowanie sesji i efekty konfiguracji (`src/gateway/gateway.test.ts`). Czego nadal brakuje dla Skills (zobacz [Skills](/pl/tools/skills)): -- **Podejmowanie decyzji:** gdy Skills są wymienione w prompcie, czy agent wybiera właściwą Skill (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 piaskownicy. +- **Kontrakty workflow:** scenariusze wieloturowe, które asercjami sprawdzają kolejność narzędzi, przeniesienie historii sesji i granice sandboxa. Przyszłe ewaluacje powinny najpierw pozostać deterministyczne: -- Uruchamiacz scenariuszy używający mockowanych dostawców do sprawdzania wywołań narzędzi + kolejności, odczytów plików Skills i okablowania sesji. -- Mały zestaw scenariuszy skoncentrowanych na Skills (użycie kontra unikanie, bramkowanie, prompt injection). -- Opcjonalne ewaluacje live (opt-in, bramkowane zmiennymi środowiskowymi) dopiero po wdrożeniu zestawu bezpiecznego dla CI. +- Runner scenariuszy używający mockowanych dostawców do asercji wywołań narzędzi + kolejności, odczytów plików skill i okablowania sesji. +- Mały zestaw scenariuszy skoncentrowanych na skillach (użyj vs unikaj, bramkowanie, prompt injection). +- Opcjonalne ewaluacje live (opt-in, bramkowane env) dopiero po wdrożeniu zestawu bezpiecznego dla CI. ## Testy kontraktowe (kształt pluginu i kanału) Testy kontraktowe weryfikują, że każdy zarejestrowany plugin i kanał jest zgodny ze swoim kontraktem interfejsu. Iterują po wszystkich wykrytych pluginach i uruchamiają zestaw -asercji kształtu i zachowania. Domyślna jednostkowa ścieżka `pnpm test` celowo +asercji kształtu oraz zachowania. Domyślna ścieżka jednostkowa `pnpm test` celowo pomija te współdzielone pliki seam i smoke; uruchamiaj polecenia kontraktowe jawnie, gdy dotykasz współdzielonych powierzchni kanałów lub dostawców. @@ -732,8 +736,8 @@ Znajdują się w `src/channels/plugins/contracts/*.contract.test.ts`: - **inbound** - Obsługa wiadomości przychodzących - **actions** - Handlery akcji kanału - **threading** - Obsługa ID wątku -- **directory** - API katalogu/listy osób -- **group-policy** - Egzekwowanie polityki grupowej +- **directory** - API katalogu/listy +- **group-policy** - Wymuszanie zasad grupy ### Kontrakty statusu dostawców @@ -746,8 +750,8 @@ Znajdują się w `src/plugins/contracts/*.contract.test.ts`. Znajdują się w `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Kontrakt przepływu uwierzytelniania -- **auth-choice** - Wybór/selekcja uwierzytelniania +- **auth** - Kontrakt przepływu auth +- **auth-choice** - Wybór/selekcja auth - **catalog** - API katalogu modeli - **discovery** - Wykrywanie pluginów - **loader** - Ładowanie pluginów @@ -758,23 +762,23 @@ Znajdują się w `src/plugins/contracts/*.contract.test.ts`: ### Kiedy uruchamiać - Po zmianie eksportów lub podścieżek plugin-sdk -- Po dodaniu lub zmodyfikowaniu kanału albo pluginu dostawcy +- Po dodaniu lub modyfikacji kanału albo pluginu dostawcy - Po refaktoryzacji rejestracji lub wykrywania pluginów Testy kontraktowe działają w CI i nie wymagają prawdziwych kluczy API. ## Dodawanie regresji (wskazówki) -Gdy naprawiasz problem dostawcy/modelu wykryty w trybie live: +Gdy naprawiasz problem dostawcy/modelu wykryty live: - Dodaj regresję bezpieczną dla CI, jeśli to możliwe (mock/stub dostawcy albo uchwycenie dokładnej transformacji kształtu żądania) -- Jeśli to z natury tylko live (limity szybkości, polityki uwierzytelniania), utrzymaj test live wąski i opt-in przez zmienne środowiskowe -- Preferuj celowanie w najmniejszą warstwę, która wykrywa błąd: +- Jeśli z natury jest to tylko live (limity szybkości, zasady auth), utrzymaj test live wąski i opt-in przez zmienne środowiskowe +- Preferuj celowanie w najmniejszą warstwę, która łapie błąd: - błąd konwersji/odtwarzania żądania dostawcy → bezpośredni test modeli - - błąd potoku sesji/historii/narzędzi gateway → smoke live gateway albo bezpieczny dla CI mock test gateway -- Bariera ochronna 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 sprawdza, że identyfikatory exec z segmentami 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 nowe klasy nie mogły być pomijane po cichu. + - błąd pipeline'u sesji/historii/narzędzi Gateway → smoke live Gateway albo bezpieczny dla CI mock test Gateway +- Guardrail przechodzenia SecretRef: + - `src/secrets/exec-secret-ref-id-parity.test.ts` wyprowadza po jednym próbkowanym celu na klasę SecretRef z metadanych rejestru (`listSecretTargetRegistryEntries()`), a następnie sprawdza, że exec ids z segmentem 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ę niepowodzeniem na niesklasyfikowanych id celów, aby nowych klas nie dało się po cichu pominąć. ## Powiązane diff --git a/docs/pl/reference/test.md b/docs/pl/reference/test.md index 32ce987ed..03fbec509 100644 --- a/docs/pl/reference/test.md +++ b/docs/pl/reference/test.md @@ -4,55 +4,56 @@ read_when: summary: Jak uruchamiać testy lokalnie (vitest) i kiedy używać trybów force/coverage title: Testy x-i18n: - generated_at: "2026-04-30T10:17:40Z" + generated_at: "2026-04-30T18:38:59Z" model: gpt-5.5 provider: openai - source_hash: 9328d6f0383b5067fa8bb5d0f1bf22a3b9048a267908bf85167842ddc3d12e42 + source_hash: 131f2bad3b2806d28394213cec38d632d106ddbf8ff04d06345ab8046fb8bcf2 source_path: reference/test.md workflow: 16 --- -- Pełny zestaw testowy (zestawy testów, testy na żywo, Docker): [Testowanie](/pl/help/testing) +- Pełny zestaw testowy (zestawy, na żywo, Docker): [Testowanie](/pl/help/testing) -- `pnpm test:force`: Zabija każdy zaległy proces Gateway zajmujący domyślny port kontrolny, a następnie uruchamia pełny zestaw Vitest z izolowanym portem Gateway, aby testy serwera nie kolidowały z działającą instancją. Użyj tego, gdy wcześniejsze uruchomienie Gateway pozostawiło port 18789 zajęty. -- `pnpm test:coverage`: Uruchamia zestaw testów jednostkowych z pokryciem V8 (przez `vitest.unit.config.ts`). To bramka pokrycia jednostkowego dla wczytanych plików, a nie pokrycie wszystkich plików w całym repozytorium. Progi wynoszą 70% dla linii/funkcji/instrukcji i 55% dla gałęzi. Ponieważ `coverage.all` ma wartość false, bramka mierzy pliki wczytane przez zestaw pokrycia jednostkowego zamiast traktować każdy plik źródłowy z podzielonej ścieżki jako niepokryty. +- `pnpm test:force`: Zabija wszelkie pozostające procesy Gateway trzymające domyślny port kontrolny, a następnie uruchamia pełny zestaw Vitest z odizolowanym portem Gateway, aby testy serwera nie kolidowały z uruchomioną instancją. Użyj tego, gdy wcześniejsze uruchomienie Gateway pozostawiło port 18789 zajęty. +- `pnpm test:coverage`: Uruchamia zestaw jednostkowy z pokryciem V8 (przez `vitest.unit.config.ts`). To bramka pokrycia jednostkowego załadowanych plików, a nie pokrycie wszystkich plików w całym repozytorium. Progi wynoszą 70% dla wierszy/funkcji/instrukcji i 55% dla gałęzi. Ponieważ `coverage.all` ma wartość false, bramka mierzy pliki załadowane przez zestaw pokrycia jednostkowego zamiast traktować każdy plik źródłowy z podzielonych torów jako niepokryty. - `pnpm test:coverage:changed`: Uruchamia pokrycie jednostkowe tylko dla plików zmienionych od `origin/main`. -- `pnpm test:changed`: tani, inteligentny przebieg testów zmian. Uruchamia precyzyjne cele z bezpośrednich edycji testów, sąsiadujących plików `*.test.ts`, jawnych mapowań źródeł i lokalnego grafu importów. Szerokie zmiany konfiguracji/pakietów są pomijane, chyba że mapują się na precyzyjne testy. -- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: jawny szeroki przebieg testów zmian. Użyj go, gdy edycja uprzęży testowej/konfiguracji/pakietu powinna wrócić do szerszego zachowania Vitest dla zmienionych testów. -- `pnpm changed:lanes`: pokazuje ścieżki architektoniczne wyzwalane przez różnicę względem `origin/main`. -- `pnpm check:changed`: uruchamia inteligentną bramkę sprawdzania zmian dla różnicy względem `origin/main`. Uruchamia typecheck, lint i komendy ochronne dla dotkniętych ścieżek architektonicznych, ale nie uruchamia testów Vitest. Użyj `pnpm test:changed` albo jawnego `pnpm test ` jako dowodu testowego. -- `pnpm test`: kieruje jawne cele plików/katalogów przez zakresowe ścieżki Vitest. Przebiegi bez celu używają stałych grup shardów i rozwijają się do konfiguracji liści dla lokalnego wykonania równoległego; grupa rozszerzeń zawsze rozwija się do konfiguracji shardów dla poszczególnych rozszerzeń zamiast jednego ogromnego procesu projektu głównego. -- Przebiegi wrappera testów kończą się krótkim podsumowaniem `[test] passed|failed|skipped ... in ...`. Własna linia czasu trwania Vitest pozostaje szczegółem dla shardu. -- Wspólny stan testowy OpenClaw: używaj `src/test-utils/openclaw-test-state.ts` z Vitest, gdy test potrzebuje izolowanego `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, fixture konfiguracji, workspace, katalogu agenta albo magazynu profili uwierzytelniania. -- Pomocniki E2E procesów: używaj `test/helpers/openclaw-test-instance.ts`, gdy test E2E na poziomie procesu Vitest potrzebuje działającego Gateway, środowiska CLI, przechwytywania logów i sprzątania w jednym miejscu. -- Pomocniki Docker/Bash E2E: ścieżki, które źródłują `scripts/lib/docker-e2e-image.sh`, mogą przekazać `docker_e2e_test_state_shell_b64