extensions/qa-channel: syntetyczny kanał wiadomości z powierzchniami DM, kanału, wątku, reakcji, edycji i usuwania.extensions/qa-lab: UI debuggera i magistrala QA do obserwowania transkryptu, wstrzykiwania wiadomości przychodzących i eksportowania raportu Markdown.qa/: zasoby seedowane oparte na repozytorium dla zadania kickoff i bazowych scenariuszy QA.
- Lewy: dashboard Gateway (Control UI) z agentem.
- Prawy: QA Lab, pokazujący transkrypt w stylu Slack i plan scenariusza.
qa:lab:up:fast utrzymuje usługi Docker na wcześniej zbudowanym obrazie i montuje przez bind mount
extensions/qa-lab/web/dist do kontenera qa-lab. qa:lab:watch
przebudowuje ten bundel przy zmianach, a przeglądarka automatycznie się przeładowuje, gdy hash zasobu QA Lab się zmieni.
Dla ścieżki smoke Matrix z rzeczywistym transportem uruchom:
qa-channel w konfiguracji podrzędnej. Zapisuje ustrukturyzowane artefakty raportu i
połączony log stdout/stderr do wybranego katalogu wyjściowego Matrix QA. Aby
przechwycić także zewnętrzne wyjście builda/launchera scripts/run-node.mjs, ustaw
OPENCLAW_RUN_NODE_OUTPUT_LOG=<path> na plik logu lokalny dla repozytorium.
Dla ścieżki smoke Telegram z rzeczywistym transportem uruchom:
OPENCLAW_QA_TELEGRAM_GROUP_ID,
OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN i
OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN, plus dwóch różnych botów w tej samej
prywatnej grupie. Bot SUT musi mieć nazwę użytkownika Telegram, a obserwacja bot-do-bot
działa najlepiej, gdy oba boty mają włączony tryb Bot-to-Bot Communication Mode
w @BotFather.
Polecenie kończy się kodem niezerowym, gdy którykolwiek scenariusz zawiedzie. Użyj --allow-failures, gdy
chcesz uzyskać artefakty bez kończenia z błędnym kodem wyjścia.
Raport i podsumowanie Telegram zawierają RTT per odpowiedź od żądania
wysłania wiadomości drivera do zaobserwowanej odpowiedzi SUT, zaczynając od canary.
Dla ścieżki smoke Discord z rzeczywistym transportem uruchom:
OPENCLAW_QA_DISCORD_GUILD_ID, OPENCLAW_QA_DISCORD_CHANNEL_ID,
OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN, OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN
oraz OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID przy użyciu poświadczeń env.
Ścieżka weryfikuje obsługę wzmianek kanału i sprawdza, czy bot SUT
zarejestrował natywne polecenie /help w Discord.
Polecenie kończy się kodem niezerowym, gdy którykolwiek scenariusz zawiedzie. Użyj --allow-failures, gdy
chcesz uzyskać artefakty bez kończenia z błędnym kodem wyjścia.
Ścieżki transportu na żywo współdzielą teraz jeden mniejszy kontrakt zamiast tworzyć
własny kształt listy scenariuszy dla każdej z nich:
qa-channel pozostaje szerokim syntetycznym zestawem zachowań produktu i nie jest częścią
macierzy pokrycia transportów na żywo.
| Ścieżka | Canary | Bramkowanie wzmianką | Blokada allowlist | Odpowiedź najwyższego poziomu | Wznowienie po restarcie | Dalszy ciąg wątku | Izolacja wątku | Obserwacja reakcji | Polecenie help | Rejestracja natywnego polecenia |
|---|---|---|---|---|---|---|---|---|---|---|
| Matrix | x | x | x | x | x | x | x | x | ||
| Telegram | x | x | x | |||||||
| Discord | x | x | x |
qa-channel jako szeroki zestaw zachowań produktu, podczas gdy Matrix,
Telegram i przyszłe transporty na żywo współdzielą jedną jawną checklistę kontraktu transportowego.
Dla jednorazowej ścieżki z Linux VM bez wprowadzania Dockera do ścieżki QA uruchom:
qa suite, a następnie kopiuje zwykły raport QA i
podsumowanie z powrotem do .artifacts/qa-e2e/... na hoście.
Ponownie używa tego samego zachowania wyboru scenariuszy co qa suite na hoście.
Uruchomienia hosta i Multipass suite domyślnie wykonują wiele wybranych scenariuszy równolegle
z izolowanymi workerami gateway. qa-channel domyślnie używa współbieżności 4,
ograniczonej liczbą wybranych scenariuszy. Użyj --concurrency <count>, aby dostroić
liczbę workerów, albo --concurrency 1 dla wykonania seryjnego.
Polecenie kończy się kodem niezerowym, gdy którykolwiek scenariusz zawiedzie. Użyj --allow-failures, gdy
chcesz uzyskać artefakty bez kończenia z błędnym kodem wyjścia.
Uruchomienia na żywo przekazują obsługiwane wejścia uwierzytelniania QA, które są praktyczne dla
gościa: klucze dostawców oparte na env, ścieżkę konfiguracji QA live provider i
CODEX_HOME, gdy jest obecne. Zachowaj --output-dir pod katalogiem głównym repozytorium, aby gość
mógł zapisywać z powrotem przez zamontowany workspace.
Seedy oparte na repozytorium
Zasoby seedowane znajdują się wqa/:
qa/scenarios/index.mdqa/scenarios/<theme>/*.md
qa-lab powinno pozostać generycznym runnerem Markdown. Każdy plik scenariusza Markdown jest
źródłem prawdy dla jednego uruchomienia testowego i powinien definiować:
- metadane scenariusza
- opcjonalne metadane kategorii, możliwości, ścieżki i ryzyka
- odwołania do dokumentacji i kodu
- opcjonalne wymagania Pluginów
- opcjonalną łatkę konfiguracji gateway
- wykonywalny
qa-flow
qa-flow może pozostać generyczna
i przekrojowa. Na przykład scenariusze Markdown mogą łączyć helpery po stronie
transportu z helperami po stronie przeglądarki, które sterują osadzonym Control UI przez
łącze Gateway browser.request, bez dodawania runnera specjalnie dla danego przypadku.
Pliki scenariuszy powinny być grupowane według możliwości produktu, a nie folderu drzewa
źródeł. Zachowuj stabilne identyfikatory scenariuszy przy przenoszeniu plików; używaj docsRefs i codeRefs
dla identyfikowalności implementacji.
Lista bazowa powinna pozostać wystarczająco szeroka, aby obejmować:
- czat DM i kanałowy
- zachowanie wątków
- cykl życia akcji wiadomości
- callbacki Cron
- przypominanie pamięci
- przełączanie modeli
- handoff subagentów
- czytanie repozytorium i dokumentacji
- jedno małe zadanie builda, takie jak Lobster Invaders
Ścieżki mock dostawców
qa suite ma dwie lokalne ścieżki mock dostawców:
mock-openaito świadomy scenariuszy mock OpenClaw. Pozostaje domyślną deterministyczną ścieżką mock dla QA opartego na repozytorium i bramek parzystości.aimockuruchamia serwer dostawcy oparty na AIMock dla eksperymentalnego pokrycia protokołu, fixture, record/replay i chaos. Jest dodatkiem i nie zastępuje dispatcher-a scenariuszymock-openai.
extensions/qa-lab/src/providers/.
Każdy dostawca zarządza swoimi ustawieniami domyślnymi, uruchamianiem lokalnego serwera,
konfiguracją modelu gateway, potrzebami przygotowania auth-profile oraz flagami możliwości live/mock. Wspólny kod suite i gateway powinien kierować ruch przez rejestr dostawców zamiast rozgałęziać się po nazwach dostawców.
Adaptery transportu
qa-lab zarządza generycznym łączem transportowym dla scenariuszy Markdown QA.
qa-channel jest pierwszym adapterem na tym łączu, ale docelowy projekt jest szerszy:
przyszłe rzeczywiste lub syntetyczne kanały powinny podłączać się do tego samego runnera suite
zamiast dodawać runner QA specyficzny dla transportu.
Na poziomie architektury podział wygląda następująco:
qa-labzarządza generycznym wykonywaniem scenariuszy, współbieżnością workerów, zapisem artefaktów i raportowaniem.- adapter transportu zarządza konfiguracją gateway, gotowością, obserwacją ruchu przychodzącego i wychodzącego, akcjami transportu i znormalizowanym stanem transportu.
- pliki scenariuszy Markdown w
qa/scenarios/definiują uruchomienie testu;qa-labudostępnia wielokrotnego użytku powierzchnię runtime, która je wykonuje.
Raportowanie
qa-lab eksportuje raport protokołu Markdown z obserwowanej osi czasu magistrali.
Raport powinien odpowiadać na pytania:
- Co zadziałało
- Co się nie udało
- Co pozostało zablokowane
- Jakie scenariusze uzupełniające warto dodać
SOUL.md, a następnie uruchamiać zwykłe tury użytkownika,
takie jak czat, pomoc dotyczącą workspace i małe zadania na plikach. Modelowi kandydującemu
nie należy mówić, że jest oceniany. Polecenie zachowuje każdy pełny
transkrypt, rejestruje podstawowe statystyki uruchomienia, a następnie prosi modele oceniające w trybie fast z
rozumowaniem xhigh, gdzie jest obsługiwane, o uszeregowanie uruchomień według naturalności, klimatu i humoru.
Użyj --blind-judge-models przy porównywaniu dostawców: prompt oceniający nadal otrzymuje
każdy transkrypt i status uruchomienia, ale odwołania kandydatów są zastępowane neutralnymi
etykietami takimi jak candidate-01; raport mapuje rankingi z powrotem na rzeczywiste odwołania po
parsowaniu.
Uruchomienia kandydatów domyślnie używają rozumowania high, z medium dla GPT-5.4 i xhigh
dla starszych odwołań ewaluacyjnych OpenAI, które to obsługują. Nadpisz konkretnego kandydata inline przez
--model provider/model,thinking=<level>. --thinking <level> nadal ustawia
globalny fallback, a starsza forma --model-thinking <provider/model=level> jest
zachowana dla kompatybilności.
Odwołania kandydatów OpenAI domyślnie używają trybu fast, aby korzystać z przetwarzania priorytetowego tam,
gdzie dostawca to obsługuje. Dodaj inline ,fast, ,no-fast albo ,fast=false, gdy pojedynczy
kandydat albo sędzia potrzebuje nadpisania. Przekaż --fast tylko wtedy, gdy chcesz
wymusić tryb fast dla każdego modelu kandydującego. Czasy trwania kandydatów i sędziów są
rejestrowane w raporcie do analizy benchmarków, ale prompty sędziowskie wyraźnie mówią,
aby nie ustawiać rankingu według szybkości.
Uruchomienia modeli kandydatów i sędziów domyślnie używają współbieżności 16. Zmniejsz
--concurrency albo --judge-concurrency, gdy limity dostawcy albo obciążenie lokalnego gateway
powodują, że uruchomienie staje się zbyt zaszumione.
Gdy nie zostanie przekazany żaden kandydat --model, character eval domyślnie używa
openai/gpt-5.4, openai/gpt-5.2, openai/gpt-5, anthropic/claude-opus-4-6,
anthropic/claude-sonnet-4-6, zai/glm-5.1,
moonshot/kimi-k2.5 oraz
google/gemini-3.1-pro-preview, gdy nie przekazano --model.
Gdy nie zostanie przekazany --judge-model, sędziowie domyślnie używają
openai/gpt-5.4,thinking=xhigh,fast oraz
anthropic/claude-opus-4-6,thinking=high.