Vue d’ensemble de l’assurance qualité

La pile d’assurance qualité privée teste OpenClaw de manière réaliste, selon une structure proche de celle des canaux, ce qu’un test unitaire ne peut pas faire.

Éléments :

• extensions/qa-channel : canal de messages synthétique avec des surfaces de messages privés, de canaux, de fils de discussion, de réactions, de modification et de suppression.
• extensions/qa-lab : interface utilisateur de débogage et bus d’assurance qualité permettant d’observer la transcription, d’injecter des messages entrants et d’exporter un rapport Markdown.
• extensions/qa-matrix : adaptateur de transport en conditions réelles qui pilote le Plugin Matrix réel dans un Gateway d’assurance qualité enfant.
• qa/ : ressources initiales adossées au dépôt pour la tâche de lancement et les scénarios d’assurance qualité de référence.
• Mantis : vérification en conditions réelles avant/après pour les bogues qui nécessitent de vrais transports, des captures d’écran du navigateur, l’état de la machine virtuelle et des preuves pour la PR.

Surface de commandes

Chaque flux d’assurance qualité s’exécute sous pnpm openclaw qa <subcommand>. Beaucoup disposent d’alias de scripts pnpm qa:* ; les deux formes fonctionnent.

qa matrix est enregistré en tant que Plugin d’exécution (extensions/qa-matrix) ; chaque autre voie ci-dessus est directement intégrée à qa-lab.

qa run basé sur un profil

qa run basé sur un profil lit l’appartenance dans taxonomy.yaml, puis distribue les scénarios résolus via qa suite. --surface et --category filtrent le profil sélectionné au lieu de définir des voies distinctes. Le fichier qa-evidence.json obtenu comprend un résumé de la fiche d’évaluation du profil avec le nombre de catégories sélectionnées et les ID de couverture manquants ; les entrées de preuve individuelles restent la source de vérité pour les tests, les rôles de couverture et les résultats. Les ID de couverture des fonctionnalités de la taxonomie sont des cibles de preuve exactes, et non des alias : la couverture du scénario principal satisfait les ID correspondants, tandis que la couverture secondaire reste indicative. Les ID de couverture utilisent la forme pointée namespace.behavior avec des segments alphanumériques en minuscules pouvant contenir des tirets ; les ID de profil, de surface et de catégorie peuvent toujours utiliser les ID de taxonomie existants avec tirets ou points.

Les preuves allégées omettent le champ execution de chaque entrée et définissent evidenceMode: "slim" ; smoke-ci utilise le mode allégé par défaut, et --evidence-mode full rétablit les entrées complètes :

pnpm openclaw qa run \  --qa-profile smoke-ci \  --category channel-framework.conversation-routing-and-delivery \  --provider-mode mock-openai \  --output-dir .artifacts/qa-e2e/smoke-ci-profile-dispatch

Utilisez smoke-ci pour obtenir une preuve de profil déterministe avec des fournisseurs de modèles simulés et des serveurs de fournisseurs locaux Crabline. Utilisez release pour la preuve Stable/LTS avec des canaux en production. Utilisez all uniquement pour les exécutions explicites de preuve couvrant toute la taxonomie ; il sélectionne chaque catégorie de maturité active et peut être distribué via le workflow GitHub Actions QA Profile Evidence avec qa_profile=all. Lorsqu’une commande nécessite également un profil racine OpenClaw, placez le profil racine avant la commande QA :

pnpm openclaw --profile work qa run --qa-profile smoke-ci

Flux opérateur

Le flux opérateur actuel de QA est un site QA à deux volets :

• À gauche : tableau de bord du Gateway (interface de contrôle) avec l’agent.
• À droite : QA Lab, affichant la transcription de type Slack et le plan du scénario.

Exécutez-le avec :

pnpm qa:lab:up

Cette commande construit le site QA, démarre le flux Gateway reposant sur Docker et expose la page QA Lab, où un opérateur ou une boucle d’automatisation peut confier à l’agent une mission de QA, observer le comportement réel du canal et consigner ce qui a fonctionné, échoué ou est resté bloqué.

Pour itérer plus rapidement sur l’interface de QA Lab sans reconstruire l’image Docker à chaque fois, démarrez la pile avec un bundle QA Lab monté par liaison :

pnpm openclaw qa docker-build-imagepnpm qa:lab:buildpnpm qa:lab:up:fastpnpm qa:lab:watch

qa:lab:up:fast maintient les services Docker sur une image préconstruite et monte par liaison extensions/qa-lab/web/dist dans le conteneur qa-lab. qa:lab:watch reconstruit ce bundle lors des modifications, et le navigateur se recharge automatiquement lorsque le hachage des ressources de QA Lab change.

Tests rapides d’observabilité

qa:otel:smoke démarre un récepteur OTLP/HTTP local, exécute un tour d’agent minimal sur le canal d’assurance qualité, puis vérifie que les traces, métriques et journaux sont exportés. Il décode les segments de trace protobuf exportés et vérifie leur structure critique pour la publication : openclaw.run, openclaw.harness.run, un segment d’appel de modèle conforme à la dernière convention sémantique GenAI, openclaw.context.assembled et openclaw.message.delivery doivent tous être présents. Le test rapide impose OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental ; le segment d’appel de modèle doit donc utiliser le nom {gen_ai.operation.name} {gen_ai.request.model} ; les appels de modèle ne doivent pas exporter StreamAbandoned lors des tours réussis ; les identifiants de diagnostic bruts et les attributs openclaw.content.* doivent rester hors de la trace. L’invite du scénario demande au modèle de répondre avec un marqueur fixe et de ne pas divulguer une chaîne secrète fixe ; les charges utiles OTLP brutes ne doivent contenir ni l’un ni l’autre, ni la clé de session d’assurance qualité dérivée de l’identifiant du scénario. Il écrit otel-smoke-summary.json à côté des artefacts de la suite d’assurance qualité.

qa:prometheus:smoke vérifie que les extractions non authentifiées sont rejetées, puis vérifie que l’extraction authentifiée inclut les familles de métriques critiques pour la publication, sans contenu d’invite, contenu de réponse, identifiants de diagnostic bruts, jetons d’authentification ni chemins locaux.

Voies de test rapide Matrix

Pour une voie de test rapide Matrix utilisant un transport réel et ne nécessitant pas d’identifiants de fournisseur de modèles, exécutez le profil rapide avec le faux fournisseur OpenAI déterministe :

OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000 \  pnpm openclaw qa matrix --provider-mode mock-openai --profile fast --fail-fast

Pour la voie du fournisseur de pointe en direct, fournissez explicitement des identifiants compatibles avec OpenAI :

OPENCLAW_LIVE_OPENAI_KEY="${OPENAI_API_KEY}" \OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000 \  pnpm openclaw qa matrix --provider-mode live-frontier --profile fast --fail-fast

La référence complète de la CLI, le catalogue des profils/scénarios, les variables d’environnement et la disposition des artefacts pour cette voie se trouvent dans Assurance qualité Matrix. En bref, elle provisionne un serveur domestique Tuwunel jetable dans Docker, inscrit des utilisateurs temporaires de pilote/SUT/observateur, exécute le véritable Plugin Matrix dans un Gateway d’assurance qualité enfant limité à ce transport (sans qa-channel), puis écrit un rapport Markdown, un résumé JSON, un artefact des événements observés et un journal de sortie combiné sous .artifacts/qa-e2e/matrix-<timestamp>/.

Les scénarios couvrent des comportements de transport que les tests unitaires ne peuvent pas prouver de bout en bout : filtrage des mentions, politiques d’autorisation des robots, listes d’autorisation, réponses de premier niveau et dans les fils de discussion, routage des messages privés, gestion des réactions, suppression des modifications entrantes, déduplication des répétitions après redémarrage, récupération après interruption du serveur domestique, livraison des métadonnées d’approbation, gestion des médias et flux d’amorçage, de récupération et de vérification du chiffrement de bout en bout Matrix. Le profil CLI de chiffrement de bout en bout exécute également openclaw matrix encryption setup et les commandes de vérification via le même serveur domestique jetable avant de vérifier les réponses du Gateway.

L’intégration continue utilise la même interface de commande dans .github/workflows/qa-live-transports-convex.yml. Les exécutions planifiées et manuelles par défaut exécutent le profil Matrix rapide avec les identifiants de fournisseur de pointe en direct fournis par l’assurance qualité, --fast et OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000. L’option manuelle matrix_profile=all se répartit en cinq fragments de profil : transport, media, e2ee-smoke, e2ee-deep et e2ee-cli.

Scénarios Discord Mantis

Discord dispose également de scénarios Mantis facultatifs réservés à la reproduction de bogues. Utilisez --scenario discord-status-reactions-tool-only pour la chronologie explicite des réactions d’état, ou --scenario discord-thread-reply-filepath-attachment pour créer un véritable fil de discussion Discord et vérifier que message.thread-reply préserve une pièce jointe filePath. Ces scénarios restent en dehors de la voie Discord en direct par défaut, car ce sont des sondes de reproduction avant/après plutôt qu’une couverture étendue de test rapide. Le flux de travail Mantis des pièces jointes aux fils de discussion peut également ajouter une vidéo témoin de Discord Web avec une session ouverte lorsque MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR ou MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64 est configuré dans l’environnement d’assurance qualité. Ce profil de visualisation sert uniquement à la capture visuelle ; la décision de réussite ou d’échec provient toujours de l’oracle REST de Discord.

Pour les voies de test rapide utilisant les transports réels Discord, Slack, Telegram et WhatsApp :

pnpm openclaw qa discordpnpm openclaw qa slackpnpm openclaw qa telegrampnpm openclaw qa whatsapp

Elles ciblent un canal réel préexistant avec deux robots ou comptes (pilote + SUT). Les variables d’environnement requises, les listes de scénarios, les artefacts de sortie et le pool d’identifiants Convex sont documentés dans la référence d’assurance qualité pour Discord, Slack, Telegram et WhatsApp ci-dessous.

Exécuteurs de bureau Slack et de tâches visuelles Mantis

Pour une exécution complète de Slack sur une VM de bureau avec récupération par VNC, exécutez :

pnpm openclaw qa mantis slack-desktop-smoke \  --gateway-setup \  --scenario slack-canary \  --keep-lease

Cette commande réserve une machine Crabbox avec environnement de bureau et navigateur, exécute le scénario Slack en conditions réelles dans la VM, ouvre Slack Web dans le navigateur VNC, capture le bureau et copie slack-qa/, slack-desktop-smoke.png et slack-desktop-smoke.mp4 (lorsque la capture vidéo est disponible) dans le répertoire d’artefacts Mantis. Les réservations Crabbox avec environnement de bureau et navigateur fournissent d’emblée les outils de capture ainsi que les paquets auxiliaires pour le navigateur et la compilation native ; le scénario ne devrait donc installer des solutions de repli que sur les réservations plus anciennes. Mantis consigne les durées totales et par phase dans mantis-slack-desktop-smoke-report.md, afin que les exécutions lentes indiquent si le temps a été consacré au préchauffage de la réservation, à l’acquisition des identifiants, à la configuration distante ou à la copie des artefacts. Réutilisez --lease-id <cbx_...> après vous être connecté manuellement à Slack Web via VNC ; les réservations réutilisées conservent également le cache du magasin pnpm de Crabbox préchauffé. Le mode par défaut --hydrate-mode source effectue la vérification depuis un checkout des sources et exécute l’installation et la compilation dans la VM. Utilisez --hydrate-mode prehydrated uniquement lorsque l’espace de travail distant réutilisé contient déjà node_modules et un répertoire dist/ compilé ; ce mode ignore l’étape coûteuse d’installation et de compilation et échoue de manière sécurisée lorsque l’espace de travail n’est pas prêt. Avec --gateway-setup, Mantis laisse un Gateway Slack OpenClaw persistant s’exécuter dans la VM sur le port 38973 ; sans cette option, la commande exécute le scénario QA Slack standard de bot à bot et se termine après la capture des artefacts.

Pour démontrer l’interface d’approbation Slack native avec des preuves issues du bureau, exécutez le mode de points de contrôle d’approbation de Mantis :

pnpm openclaw qa mantis slack-desktop-smoke \  --approval-checkpoints \  --credential-source convex \  --credential-role maintainer

Ce mode est mutuellement exclusif avec --gateway-setup. Il exécute les scénarios d’approbation Slack, rejette les identifiants de scénarios qui ne concernent pas l’approbation, attend chaque état d’approbation en attente et résolu, restitue le message observé de l’API Slack dans approval-checkpoints/<scenario>-pending.png et approval-checkpoints/<scenario>-resolved.png, puis échoue si un point de contrôle, une preuve de message, un accusé de réception ou une capture d’écran restituée est manquant ou vide. Les réservations CI à froid peuvent encore afficher la connexion à Slack dans slack-desktop-smoke.png ; les images des points de contrôle d’approbation constituent la preuve visuelle pour ce scénario.

L’exécution par défaut des points de contrôle conserve les deux scénarios d’approbation Slack standard. Pour capturer l’une des routes d’approbation Codex optionnelles, sélectionnez-la explicitement avec --scenario slack-codex-approval-exec-native ou --scenario slack-codex-approval-plugin-native ; Mantis accepte les deux et génère la même paire de captures d’écran des états en attente et résolu. Le programme d’exécution augmente les délais de ses points de contrôle et de ses commandes distantes pour chaque route Codex sélectionnée, afin que la séquence complète d’approbation, d’achèvement de l’agent et de mise à jour de l’état résolu puisse se terminer.

La liste de contrôle de l’opérateur, la commande de déclenchement du workflow GitHub, le contrat relatif aux commentaires de preuve, le tableau de décision du mode d’hydratation, l’interprétation des durées et les étapes de gestion des échecs sont disponibles dans le guide d’exploitation du bureau Slack avec Mantis.

Pour une tâche de bureau de type agent/vision par ordinateur, exécutez :

pnpm openclaw qa mantis visual-task \  --browser-url https://example.net \  --expect-text "Example Domain" \  --vision-model openai/gpt-5.6-luna

visual-task loue ou réutilise une machine de bureau avec navigateur Crabbox, lance crabbox record --while, pilote le navigateur visible au moyen d’un visual-driver imbriqué, capture visual-task.png, exécute openclaw infer image describe sur la capture d’écran lorsque --vision-mode image-describe est sélectionné, et écrit visual-task.mp4, mantis-visual-task-summary.json, mantis-visual-task-driver-result.json et mantis-visual-task-report.md. Lorsque --expect-text est défini, le prompt de vision demande un verdict JSON structuré (visible, evidence, reason) et ne réussit que si le modèle indique visible: true avec des preuves qui citent le texte attendu ; une réponse visible: false qui se contente de citer le texte cible échoue tout de même à l’assertion. Utilisez --vision-mode metadata pour un test de bon fonctionnement sans modèle qui valide le bureau, le navigateur, la capture d’écran et la chaîne de traitement vidéo sans appeler de fournisseur de compréhension d’images. L’enregistrement est un artefact obligatoire pour visual-task ; si Crabbox n’enregistre aucun fichier visual-task.mp4 non vide, la tâche échoue même si le pilote visuel a réussi. En cas d’échec, Mantis conserve la location pour VNC, sauf si la tâche avait déjà réussi et que --keep-lease n’était pas défini.

Vérification de l’état du pool d’identifiants

Avant d’utiliser les identifiants actifs mutualisés, exécutez :

pnpm openclaw qa credentials doctor

Le diagnostic vérifie les variables d’environnement du courtier Convex (OPENCLAW_QA_CONVEX_SITE_URL, OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX), valide les paramètres des points de terminaison, indique uniquement l’état défini/manquant de OPENCLAW_QA_CONVEX_SECRET_CI et OPENCLAW_QA_CONVEX_SECRET_MAINTAINER, et vérifie l’accessibilité de l’administration et de la liste lorsque le secret de maintenance est présent.

Couverture des transports en conditions réelles

Les parcours de transport en conditions réelles partagent un contrat unique au lieu que chacun invente sa propre structure de liste de scénarios. qa-channel est la suite synthétique étendue couvrant le comportement du produit et ne fait pas partie de la matrice de couverture des transports en conditions réelles.

Les exécuteurs de transport en conditions réelles importent les identifiants de scénarios partagés, les assistants de couverture de référence et l’assistant de sélection de scénarios depuis openclaw/plugin-sdk/qa-live-transport-scenarios.

Cela conserve qa-channel comme suite générale couvrant le comportement du produit, tandis que Matrix, Telegram et les autres transports en direct partagent une liste de contrôle explicite unique du contrat de transport.

Pour utiliser une voie de VM Linux jetable sans introduire Docker dans le parcours d’assurance qualité, exécutez :

pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline

Cette commande démarre un nouvel invité Multipass, installe les dépendances, compile OpenClaw dans l’invité, exécute qa suite, puis recopie le rapport et le résumé d’assurance qualité habituels dans .artifacts/qa-e2e/... sur l’hôte. Elle réutilise le même comportement de sélection des scénarios que qa suite sur l’hôte.

Les exécutions des suites sur l’hôte et dans Multipass exécutent par défaut plusieurs scénarios sélectionnés en parallèle avec des workers Gateway isolés. qa-channel utilise par défaut une concurrence de 4, plafonnée par le nombre de scénarios sélectionnés. Utilisez --concurrency <count> pour ajuster le nombre de workers, ou --concurrency 1 pour une exécution séquentielle. Utilisez --pack personal-agent pour exécuter le pack de benchmarks de l’assistant personnel (10 scénarios). Le sélecteur de pack s’ajoute aux indicateurs --scenario répétés : les scénarios explicites sont exécutés en premier, puis ceux du pack dans leur ordre avec suppression des doublons. Utilisez --pack observability pour sélectionner ensemble les scénarios otel-trace-smoke et docker-prometheus-smoke lorsqu’un exécuteur d’assurance qualité personnalisé fournit déjà la configuration du collecteur OpenTelemetry.

La commande se termine avec un code différent de zéro lorsqu’un scénario échoue. Utilisez --allow-failures si vous souhaitez obtenir les artefacts sans code de sortie d’échec.

Les exécutions en direct transmettent les entrées d’authentification d’assurance qualité prises en charge qui sont utilisables dans l’invité : les clés de fournisseur définies par des variables d’environnement, le chemin de configuration du fournisseur en direct d’assurance qualité et CODEX_HOME lorsqu’il est présent. Conservez --output-dir sous la racine du dépôt afin que l’invité puisse réécrire les résultats via l’espace de travail monté.

Référence d’assurance qualité pour Discord, Slack, Telegram et WhatsApp

Matrix possède une page dédiée en raison du nombre de ses scénarios et du provisionnement de son serveur domestique reposant sur Docker. Discord, Slack, Telegram et WhatsApp s’exécutent sur des transports réels préexistants ; leur documentation de référence se trouve donc ici.

Indicateurs CLI communs

Ces voies sont enregistrées au moyen de extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts et acceptent les mêmes indicateurs :

Chaque voie se termine avec un code différent de zéro si un scénario échoue. --allow-failures écrit les artefacts sans définir de code de sortie d’échec. Telegram accepte également --list-scenarios pour afficher les identifiants des scénarios disponibles et quitter ; les autres voies n’exposent pas cet indicateur.

Assurance qualité de Telegram

pnpm openclaw qa telegram

Cible un groupe Telegram privé réel avec deux bots distincts (pilote + SUT). Le bot SUT doit disposer d’un nom d’utilisateur Telegram ; l’observation bot à bot fonctionne mieux lorsque le mode Bot-to-Bot Communication Mode est activé pour les deux bots dans @BotFather.

Variables d’environnement requises lorsque --credential-source env :

• OPENCLAW_QA_TELEGRAM_GROUP_ID - identifiant numérique de la discussion (chaîne).
• OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
• OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN

Scénarios (extensions/qa-lab/src/live-transports/telegram/telegram-live.runtime.ts) :

• telegram-canary
• telegram-mention-gating
• telegram-mentioned-message-reply
• telegram-help-command
• telegram-commands-command
• telegram-tools-compact-command
• telegram-whoami-command
• telegram-status-command
• telegram-repeated-command-authorization
• telegram-other-bot-command-gating
• telegram-context-command
• telegram-current-session-status-tool
• telegram-tool-only-usage-footer
• telegram-reply-chain-exact-marker
• telegram-stream-final-single-message
• telegram-long-final-reuses-preview
• telegram-long-final-three-chunks

L’ensemble implicite par défaut couvre toujours Canary, le filtrage des mentions, les réponses aux commandes natives, l’adressage des commandes et les réponses de groupe bot à bot. Les valeurs par défaut de mock-openai incluent également des vérifications déterministes des chaînes de réponses et de la diffusion en continu du message final. telegram-current-session-status-tool et telegram-tool-only-usage-footer restent facultatifs : le premier n’est stable que lorsqu’il est enchaîné directement après Canary, tandis que le second constitue une preuve sur Telegram réel du pied de page /usage dans les réponses constituées uniquement d’appels d’outils. Utilisez pnpm openclaw qa telegram --list-scenarios --provider-mode mock-openai pour afficher la répartition actuelle entre scénarios par défaut et facultatifs avec les références de régression.

Artefacts de sortie :

• telegram-qa-report.md
• qa-evidence.json - entrées de preuve pour les vérifications du transport en direct, notamment les champs de profil, de couverture, de fournisseur, de canal, d’artefacts, de résultat et de RTT.

Les exécutions Telegram du paquet utilisent le même contrat d’identifiants Telegram. La mesure répétée du RTT fait partie de la voie Telegram en direct normale du paquet ; la distribution du RTT est intégrée à qa-evidence.json sous result.timing pour la vérification RTT sélectionnée.

OPENCLAW_QA_CREDENTIAL_SOURCE=convex \pnpm test:docker:npm-telegram-live

Lorsque OPENCLAW_QA_CREDENTIAL_SOURCE=convex est défini, le wrapper d’exécution en direct du paquet loue un identifiant kind: "telegram", exporte les variables d’environnement du groupe, du pilote et du bot SUT loués dans l’exécution du paquet installé, envoie le Heartbeat du bail et le libère à l’arrêt. Le wrapper du paquet utilise par défaut 20 vérifications RTT de telegram-mentioned-message-reply, un délai d’expiration RTT de 30s et le rôle Convex maintainer hors CI lorsque Convex est sélectionné. Remplacez les valeurs de OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES, OPENCLAW_NPM_TELEGRAM_RTT_TIMEOUT_MS ou OPENCLAW_NPM_TELEGRAM_RTT_MAX_FAILURES pour ajuster la mesure du RTT sans créer de commande RTT distincte ni de format de résumé propre à Telegram.

Assurance qualité de Discord

pnpm openclaw qa discord

Cible un canal de serveur Discord privé réel avec deux bots : un bot pilote contrôlé par le harnais et un bot SUT démarré par le Gateway OpenClaw enfant au moyen du Plugin Discord intégré. Vérifie la gestion des mentions dans le canal, que le bot SUT a enregistré la commande native /help auprès de Discord, ainsi que les scénarios de preuve Mantis facultatifs.

Variables d’environnement requises lorsque --credential-source env :

• OPENCLAW_QA_DISCORD_GUILD_ID
• OPENCLAW_QA_DISCORD_CHANNEL_ID
• OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN
• OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN
• OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID - doit correspondre à l’identifiant utilisateur du bot SUT renvoyé par Discord (sinon, la voie échoue immédiatement).

Facultatif :

• OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1 conserve le corps des messages dans les artefacts des messages observés.
• OPENCLAW_QA_DISCORD_VOICE_CHANNEL_ID sélectionne le canal vocal/de scène pour discord-voice-autojoin ; sans cette variable, le scénario sélectionne le premier canal vocal/de scène visible par le bot SUT.

Scénarios (extensions/qa-lab/src/live-transports/discord/discord-live.runtime.ts:36) :

• discord-canary
• discord-mention-gating
• discord-native-help-command-registration
• discord-voice-autojoin - scénario vocal facultatif. S’exécute seul, active channels.discord.voice.autoJoin et vérifie que l’état vocal Discord actuel du bot SUT correspond au canal vocal/de scène cible. Les identifiants Discord Convex peuvent inclure un voiceChannelId facultatif ; sinon, l’exécuteur découvre le premier canal vocal/de scène visible dans le serveur.
• discord-status-reactions-tool-only - scénario Mantis facultatif. S’exécute seul, car il configure le SUT pour répondre en permanence dans le serveur uniquement par des appels d’outils, avec messages.statusReactions.enabled=true, puis capture une chronologie des réactions REST ainsi que des artefacts visuels HTML/PNG. Les rapports Mantis avant/après conservent également les artefacts MP4 fournis par le scénario sous les noms baseline.mp4 et candidate.mp4.
• discord-thread-reply-filepath-attachment - scénario Mantis facultatif ; consultez Scénarios Mantis de Discord.

Exécutez explicitement le scénario de connexion automatique à un canal vocal Discord :

pnpm openclaw qa discord \  --scenario discord-voice-autojoin \  --provider-mode mock-openai

Exécutez explicitement le scénario Mantis des réactions de statut :

pnpm openclaw qa discord \  --scenario discord-status-reactions-tool-only \  --provider-mode live-frontier \  --model openai/gpt-5.6-luna \  --alt-model openai/gpt-5.6-luna \  --fast

Artefacts de sortie :

• discord-qa-report.md
• qa-evidence.json - entrées de preuve pour les vérifications du transport en direct.
• discord-qa-observed-messages.json - corps expurgés sauf si OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1.
• discord-qa-reaction-timelines.json et discord-status-reactions-tool-only-timeline.png lors de l’exécution du scénario de réactions d’état.

QA Slack

pnpm openclaw qa slack

Cible un véritable canal Slack privé avec deux bots distincts : un bot pilote contrôlé par le harnais et un bot SUT démarré par le Gateway OpenClaw enfant via le plugin Slack intégré.

Variables d’environnement requises avec --credential-source env :

• OPENCLAW_QA_SLACK_CHANNEL_ID
• OPENCLAW_QA_SLACK_DRIVER_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_APP_TOKEN

Facultatif :

• OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1 conserve le corps des messages dans les artefacts de messages observés.
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR active les points de contrôle visuels d’approbation pour Mantis. L’exécuteur écrit <scenario>.pending.json et <scenario>.resolved.json, puis attend les fichiers .ack.json correspondants.
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_TIMEOUT_MS remplace le délai d’expiration de l’accusé de réception du point de contrôle. La valeur par défaut est 120000.

Scénarios YAML canoniques exposés par l’adaptateur Slack en direct :

• thread-follow-up
• thread-isolation

Scénarios Slack impératifs (extensions/qa-lab/src/live-transports/slack/slack-live.runtime.ts) :

• slack-canary
• slack-mention-gating
• slack-allowlist-block
• slack-top-level-reply-shape
• slack-restart-resume
• slack-progress-commentary-true, slack-progress-commentary-false, slack-progress-commentary-omitted et slack-progress-commentary-verbose-dedupe - sondes Slack réelles facultatives pour les contrôles indépendants des commentaires et de la progression des outils, la valeur par défaut héritée lorsque la clé est omise, et le comportement de livraison unique lorsque la progression détaillée persistante est activée.
• slack-reaction-glyph-native - scénario facultatif de réaction en direct de l’outil de messagerie. Demande à l’agent de transmettre le glyphe exact ✅ et confirme que Slack a stocké white_check_mark pour le bot SUT sur le message cible.
• slack-chart-presentation-native - scénario facultatif de graphique portable qui vérifie le bloc natif data_visualization et le texte accessible exact.
• slack-table-presentation-native - scénario facultatif de tableau portable qui vérifie le bloc natif data_table, les lignes exactes et le texte accessible.
• slack-table-invalid-blocks-fallback - scénario facultatif de transport direct qui envoie un tableau brut structurellement lisible dépassant la limite, avec 101 lignes de données plus son en-tête, via le chemin d’envoi Slack de production, prouve que Slack lui-même renvoie invalid_blocks et vérifie que la solution de repli stockée sans mise en forme est complète et ne contient aucun bloc de données natif. Le rapport ne conserve que des preuves sûres sous forme de code d’erreur, de nombre et de valeur booléenne ; le texte brut du tableau synthétique suit OPENCLAW_QA_SLACK_CAPTURE_CONTENT.
• slack-approval-exec-native - scénario facultatif d’approbation d’exécution native Slack. Demande une approbation d’exécution via le Gateway, vérifie que le message Slack comporte des boutons d’approbation natifs, la résout et vérifie la mise à jour Slack une fois résolue.
• slack-approval-plugin-native - scénario facultatif d’approbation native de plugin Slack. Active conjointement le transfert des approbations d’exécution et de plugin afin que les événements de plugin ne soient pas supprimés par le routage des approbations d’exécution, puis vérifie le même parcours d’interface utilisateur Slack native en attente/résolu.
• slack-codex-approval-exec-native - scénario facultatif d’approbation de commande Codex Guardian. Active le plugin Codex en mode Guardian, achemine un tour d’agent Gateway provenant de Slack via le harnais du serveur d’application Codex, attend l’invite d’approbation native du plugin Slack pour openclaw-codex-app-server, la résout et vérifie que le tour Codex se termine avec les marqueurs attendus de sortie de commande et d’assistant.
• slack-codex-approval-plugin-native - scénario facultatif d’approbation de fichier Codex Guardian. Utilise une instruction apply_patch hors de l’espace de travail afin que Codex émette le parcours d’approbation de modification de fichier du serveur d’application, puis vérifie le même parcours d’approbation Slack natif en attente/résolu, le marqueur final de l’assistant et le contenu exact du fichier avant le nettoyage.

Les scénarios d’approbation Codex nécessitent un --model openai/* ou codex/*, les identifiants habituels du modèle en direct, ainsi qu’une authentification Codex ou une authentification par clé API acceptée par le plugin Codex. Le rapport Slack inclut la méthode du serveur d’application Codex, la clé du modèle Codex sélectionné, l’état final du tour Codex et la vérification du marqueur d’opération, ainsi que les métadonnées d’approbation Slack expurgées.

Artefacts de sortie :

• slack-qa-report.md
• qa-evidence.json - entrées de preuve pour les vérifications du transport en direct.
• slack-qa-observed-messages.json - corps expurgés sauf si OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1.
• approval-checkpoints/ - uniquement lorsque Mantis définit OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR ; contient les fichiers JSON des points de contrôle, les fichiers JSON d’accusé de réception et les captures d’écran en attente/résolues.

Configuration de l’espace de travail Slack

Ce circuit nécessite deux applications Slack distinctes dans un même espace de travail, ainsi qu’un canal dont les deux bots sont membres :

• channelId - l’identifiant Cxxxxxxxxxx d’un canal auquel les deux bots ont été invités. Utilisez un canal dédié ; le circuit publie à chaque exécution.
• driverBotToken - jeton du bot (xoxb-...) de l’application Driver.
• sutBotToken - jeton du bot (xoxb-...) de l’application SUT, qui doit être une application Slack distincte de l’application pilote afin que son identifiant d’utilisateur de bot soit différent.
• sutAppToken - jeton de niveau application (xapp-...) de l’application SUT avec connections:write, utilisé par Socket Mode afin que l’application SUT puisse recevoir des événements.

Préférez un espace de travail Slack consacré à la QA plutôt que de réutiliser un espace de travail de production.

Le manifeste SUT ci-dessous restreint intentionnellement l’installation de production du plugin Slack intégré (extensions/slack/src/setup-shared.ts:12) aux autorisations et événements couverts par la suite de QA Slack en direct. Pour la configuration du canal de production telle que les utilisateurs la voient, consultez Configuration rapide du canal Slack ; la paire QA Driver/SUT est volontairement distincte, car le circuit nécessite deux identifiants d’utilisateur de bot différents dans un même espace de travail.

1. Créer l’application Driver

Accédez à api.slack.com/apps → Create New App → From a manifest → choisissez l’espace de travail de QA, collez le manifeste suivant, puis Install to Workspace :

{  "display_information": {    "name": "OpenClaw QA Driver",    "description": "Bot pilote de test pour le circuit Slack en direct de la QA OpenClaw"  },  "features": {    "bot_user": {      "display_name": "OpenClaw QA Driver",      "always_online": true    }  },  "oauth_config": {    "scopes": {      "bot": ["chat:write", "channels:history", "groups:history", "users:read"]    }  },  "settings": {    "socket_mode_enabled": false  }}

Copiez le Bot User OAuth Token (xoxb-...) : il devient driverBotToken. Le pilote doit seulement publier des messages et s’identifier ; aucun événement ni Socket Mode n’est nécessaire.

2. Créer l’application SUT

Répétez Create New App → From a manifest dans le même espace de travail. Cette application de QA utilise intentionnellement une version plus restrictive du manifeste de production du plugin Slack intégré (extensions/slack/src/setup-shared.ts:12) : les portées et les événements de réaction sont omis, car la suite de QA Slack en direct ne couvre pas encore la gestion des réactions.

{  "display_information": {    "name": "OpenClaw QA SUT",    "description": "Connecteur SUT de QA OpenClaw pour OpenClaw"  },  "features": {    "bot_user": {      "display_name": "OpenClaw QA SUT",      "always_online": true    },    "app_home": {      "home_tab_enabled": true,      "messages_tab_enabled": true,      "messages_tab_read_only_enabled": false    }  },  "oauth_config": {    "scopes": {      "bot": [        "app_mentions:read",        "assistant:write",        "channels:history",        "channels:read",        "chat:write",        "commands",        "emoji:read",        "files:read",        "files:write",        "groups:history",        "groups:read",        "im:history",        "im:read",        "im:write",        "mpim:history",        "mpim:read",        "mpim:write",        "pins:read",        "pins:write",        "usergroups:read",        "users:read"      ]    }  },  "settings": {    "socket_mode_enabled": true,    "event_subscriptions": {      "bot_events": [        "app_home_opened",        "app_mention",        "channel_rename",        "member_joined_channel",        "member_left_channel",        "message.channels",        "message.groups",        "message.im",        "message.mpim",        "pin_added",        "pin_removed"      ]    }  }}

Après que Slack a créé l’application, effectuez deux opérations sur sa page de paramètres :

• Install to Workspace → copiez le Bot User OAuth Token → il devient sutBotToken.
• Basic Information → App-Level Tokens → Generate Token and Scopes → ajoutez la portée connections:write → enregistrez → copiez la valeur xapp-... → elle devient sutAppToken.

Vérifiez que les deux bots possèdent des identifiants d’utilisateur distincts en appelant auth.test pour chaque jeton. L’environnement d’exécution distingue le pilote et le SUT par leur identifiant d’utilisateur ; réutiliser une même application pour les deux fera immédiatement échouer le filtrage des mentions.

3. Créer le canal

Dans l’espace de travail de QA, créez un canal (par exemple #openclaw-qa) et invitez les deux bots depuis le canal :

/invite @OpenClaw QA Driver/invite @OpenClaw QA SUT

Copiez l’identifiant Cxxxxxxxxxx depuis channel info → About → Channel ID : il devient channelId. Un canal public convient ; si vous utilisez un canal privé, les deux applications disposent déjà de groups:history, de sorte que les lectures de l’historique par le harnais réussiront également.

4. Enregistrer les identifiants

Deux options sont disponibles. Utilisez des variables d’environnement pour le débogage sur une seule machine (définissez les quatre variables OPENCLAW_QA_SLACK_* et transmettez --credential-source env), ou alimentez le pool Convex partagé afin que la CI et les autres responsables puissent les louer.

Pour le pool Convex, écrivez les quatre champs dans un fichier JSON :

{  "channelId": "Cxxxxxxxxxx",  "driverBotToken": "xoxb-...",  "sutBotToken": "xoxb-...",  "sutAppToken": "xapp-..."}

Avec OPENCLAW_QA_CONVEX_SITE_URL et OPENCLAW_QA_CONVEX_SECRET_MAINTAINER exportés dans votre shell, enregistrez et vérifiez :

pnpm openclaw qa credentials add \  --kind slack \  --payload-file slack-creds.json \  --note "Amorçage du pool Slack de QA" pnpm openclaw qa credentials list --kind slack --status all --json

Attendez-vous à count: 1, status: "active" et à l’absence de champ lease.

5. Vérifier de bout en bout

Exécutez le circuit localement pour confirmer que les deux bots peuvent communiquer entre eux via le courtier :

pnpm openclaw qa slack \  --credential-source convex \  --credential-role maintainer \  --output-dir .artifacts/qa-e2e/slack-local

Une exécution réussie se termine en nettement moins de 30 secondes et slack-qa-report.md indique l’état pass pour slack-canary et slack-mention-gating. Si le circuit reste bloqué pendant environ 90 secondes et se termine avec Convex credential pool exhausted for kind "slack", soit le pool est vide, soit toutes les lignes sont louées : qa credentials list --kind slack --status all --json vous indiquera lequel de ces cas s’applique.

QA WhatsApp

pnpm openclaw qa whatsapp

Cible deux comptes WhatsApp Web dédiés : un compte pilote contrôlé par le harnais et un compte SUT démarré par le Gateway OpenClaw enfant via le plugin WhatsApp intégré.

Variables d’environnement requises avec --credential-source env :

• OPENCLAW_QA_WHATSAPP_DRIVER_PHONE_E164
• OPENCLAW_QA_WHATSAPP_SUT_PHONE_E164
• OPENCLAW_QA_WHATSAPP_DRIVER_AUTH_ARCHIVE_BASE64
• OPENCLAW_QA_WHATSAPP_SUT_AUTH_ARCHIVE_BASE64

Facultatif :

• OPENCLAW_QA_WHATSAPP_GROUP_JID active les scénarios de groupe tels que whatsapp-mention-gating, whatsapp-group-pending-history-context, whatsapp-broadcast-group-fanout, whatsapp-group-activation-always, whatsapp-group-reply-to-bot-triggers, les scénarios d’action, de média et de sondage de groupe, ainsi que whatsapp-group-allowlist-block.
• OPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1 conserve le corps des messages dans les artefacts de messages observés.

Catalogue des scénarios (extensions/qa-lab/src/live-transports/whatsapp/whatsapp-live.runtime.ts) :

• Contrôles de référence et de groupe : whatsapp-canary, whatsapp-pairing-block, whatsapp-mention-gating, whatsapp-group-pending-history-context, whatsapp-group-activation-always, whatsapp-group-reply-to-bot-triggers, whatsapp-top-level-reply-shape, whatsapp-restart-resume, whatsapp-group-allowlist-block.
• Commandes natives : whatsapp-help-command, whatsapp-status-command, whatsapp-commands-command, whatsapp-tools-compact-command, whatsapp-whoami-command, whatsapp-context-command, whatsapp-native-new-command.
• Comportement des réponses et de la sortie finale : whatsapp-tool-only-usage-footer, whatsapp-reply-to-message, whatsapp-group-reply-to-message, whatsapp-reply-to-mode-batched, whatsapp-reply-context-isolation, whatsapp-reply-delivery-shape, whatsapp-stream-final-message-accounting.
• Actions sur les messages dans le parcours utilisateur : whatsapp-agent-message-action-react part d’un véritable message privé du pilote, permet au modèle d’appeler l’outil message et observe la réaction WhatsApp native. whatsapp-agent-message-action-upload-file adopte la même approche pour message(action=upload-file) et observe le média WhatsApp natif. whatsapp-group-agent-message-action-react et whatsapp-group-agent-message-action-upload-file démontrent les mêmes actions visibles par l’utilisateur dans un véritable groupe WhatsApp.
• Diffusion aux groupes : whatsapp-broadcast-group-fanout part d’un message de groupe WhatsApp comportant une mention et vérifie des réponses visibles distinctes de main et qa-second.
• Activation de groupe : whatsapp-group-activation-always fait passer une véritable session de groupe à /activation always, démontre qu’un message de groupe sans mention réveille l’agent, puis rétablit /activation mention. whatsapp-group-reply-to-bot-triggers initialise une réponse du bot, lui envoie une réponse native avec citation sans mention explicite et vérifie que l’agent se réveille à partir de ce contexte de réponse.
• Médias entrants et messages structurés : whatsapp-inbound-image-caption, whatsapp-audio-preflight, whatsapp-inbound-structured-messages, whatsapp-group-audio-gating, whatsapp-inbound-reaction-no-trigger. Ces scénarios envoient par l’intermédiaire du pilote de véritables événements WhatsApp d’image, d’audio, de document, de localisation, de contact, d’autocollant et de réaction.
• Sondes directes du contrat du Gateway : whatsapp-outbound-media-matrix, whatsapp-outbound-document-preserves-filename, whatsapp-outbound-poll, whatsapp-outbound-send-serialization, whatsapp-group-outbound-media, whatsapp-group-outbound-poll, whatsapp-message-actions, whatsapp-reply-context-isolation, whatsapp-reply-delivery-shape. Ces scénarios contournent volontairement l’invite du modèle et démontrent les contrats déterministes send, poll et message.action du Gateway et du canal.
• Couverture du contrôle d’accès : whatsapp-access-control-dm-open, whatsapp-access-control-dm-disabled, whatsapp-access-control-group-open, whatsapp-access-control-group-disabled, whatsapp-group-allowlist-block.
• Approbations natives : whatsapp-approval-exec-deny-native, whatsapp-approval-exec-native, whatsapp-approval-exec-reaction-native, whatsapp-approval-exec-group-reaction-native, whatsapp-approval-plugin-native.
• Réactions de statut : whatsapp-status-reactions, whatsapp-status-reaction-lifecycle.

Le catalogue contient actuellement 52 scénarios. Le parcours live-frontier par défaut reste limité à 10 scénarios pour fournir rapidement une couverture de vérification élémentaire. Le parcours mock-openai par défaut exécute 45 scénarios de manière déterministe via le véritable transport WhatsApp, tout en simulant uniquement la sortie du modèle ; les scénarios d’approbation et quelques vérifications plus lourdes ou bloquantes restent explicitement sélectionnables par identifiant de scénario.

Le pilote QA WhatsApp observe des événements en direct structurés (text, media, location, reaction et poll) et peut envoyer activement des médias, des sondages, des contacts, des emplacements et des autocollants. QA Lab importe ce pilote via la surface du package @openclaw/whatsapp/api.js au lieu d’accéder aux fichiers privés du runtime WhatsApp. Pour les observations de groupe, fromJid est le JID du groupe, tandis que participantJid et fromPhoneE164 identifient le participant expéditeur. Le contenu des messages est masqué par défaut. Les sondes directes du Gateway portant sur les sondages, l’envoi de fichiers, les médias, les sondages de groupe, les médias de groupe et la forme des réponses sont des vérifications du contrat de transport/API ; elles ne sont pas considérées comme la preuve qu’une invite utilisateur a conduit l’agent à choisir la même action. La preuve des actions effectuées via le parcours utilisateur provient de scénarios tels que whatsapp-agent-message-action-react et whatsapp-group-agent-message-action-react, dans lesquels le pilote envoie un message WhatsApp normal et QA Lab observe l’artefact WhatsApp natif qui en résulte. Les rapports WhatsApp incluent la posture de chaque scénario (user-path, direct-gateway ou native-approval) afin que les éléments de preuve ne puissent pas être interprétés à tort comme démontrant un contrat plus fort qu’ils ne le font réellement.

Artefacts de sortie :

• whatsapp-qa-report.md
• qa-evidence.json - entrées de preuve pour les vérifications du transport en direct.
• whatsapp-qa-observed-messages.json - corps masqués sauf si OPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1.

Pool d’identifiants Convex

Les voies Discord, Slack, Telegram et WhatsApp peuvent louer des identifiants depuis un pool Convex partagé au lieu de lire les variables d’environnement ci-dessus. Passez --credential-source convex (ou définissez OPENCLAW_QA_CREDENTIAL_SOURCE=convex) ; QA Lab acquiert un bail exclusif, envoie des heartbeats pendant toute la durée de l’exécution et le libère à l’arrêt. Les types du pool sont "discord", "slack", "telegram" et "whatsapp".

Formes de payload que le broker valide sur admin/add :

• Discord (kind: "discord") : { guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }.
• Telegram (kind: "telegram") : { groupId: string, driverToken: string, sutToken: string } — groupId doit être une chaîne d’identifiant numérique de discussion.
• Utilisateur Telegram réel (kind: "telegram-user") : { groupId: string, sutToken: string, testerUserId: string, testerUsername: string, telegramApiId: string, telegramApiHash: string, tdlibDatabaseEncryptionKey: string, tdlibArchiveBase64: string, tdlibArchiveSha256: string, desktopTdataArchiveBase64: string, desktopTdataArchiveSha256: string } — réservé aux preuves Mantis avec Telegram Desktop. Les parcours génériques du QA Lab ne doivent pas acquérir ce type.
• WhatsApp (kind: "whatsapp") : { driverPhoneE164: string, sutPhoneE164: string, driverAuthArchiveBase64: string, sutAuthArchiveBase64: string, groupJid?: string } — les numéros de téléphone doivent être des chaînes E.164 distinctes.

Le workflow de preuve Mantis avec Telegram Desktop conserve un bail Convex telegram-user exclusif à la fois pour le pilote CLI TDLib et le témoin Telegram Desktop, puis le libère après la publication de la preuve.

Lorsqu’une PR nécessite une comparaison visuelle déterministe, Mantis peut utiliser la même réponse du modèle simulé sur main et sur la tête de la PR pendant que le formateur Telegram ou la couche de livraison change. Les valeurs par défaut de capture sont optimisées pour les commentaires de PR : classe Crabbox standard, enregistrement du bureau à 24fps, GIF animé à 24fps et largeur d’aperçu de 1920px. Les commentaires avant/après doivent publier un ensemble propre contenant uniquement les GIF prévus.

Les parcours Slack peuvent également utiliser le pool. Les vérifications de forme du payload Slack se trouvent actuellement dans l’exécuteur QA Slack plutôt que dans le broker ; utilisez { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string }, avec un identifiant de canal Slack tel que Cxxxxxxxxxx. Consultez Configuration de l’espace de travail Slack pour le provisionnement de l’application et des portées.

Les variables d’environnement opérationnelles et le contrat du point de terminaison du broker Convex se trouvent dans Tests → Identifiants Telegram partagés via Convex (le nom de la section est antérieur au pool multicanal ; la sémantique des baux est commune à tous les types).

Données d’amorçage intégrées au dépôt

Les ressources d’amorçage se trouvent dans qa/ :

• qa/scenarios/index.yaml
• qa/scenarios/<theme>/*.yaml

Elles sont intentionnellement conservées dans git afin que le plan QA soit visible à la fois par les humains et par l’agent.

qa-lab reste un exécuteur générique de scénarios YAML. Chaque fichier YAML de scénario est la source de vérité pour une exécution de test et doit définir :

• un title de premier niveau
• les métadonnées scenario
• des métadonnées facultatives de catégorie, de capacité, de lane et de risque dans scenario
• les références à la documentation et au code dans scenario
• les exigences facultatives relatives aux plugins dans scenario
• un correctif facultatif de configuration du Gateway dans scenario
• un flow exécutable de premier niveau pour les scénarios de flux, ou scenario.execution.kind / scenario.execution.path pour les scénarios Vitest et Playwright

La surface d’exécution réutilisable sur laquelle repose flow reste générique et transversale. Par exemple, les scénarios YAML peuvent combiner des assistants côté transport avec des assistants côté navigateur qui pilotent l’interface Control UI intégrée via le point d’intégration browser.request du Gateway sans ajouter d’exécuteur spécifique.

Les fichiers de scénario doivent être regroupés par capacité du produit plutôt que par dossier de l’arborescence source. Conservez des identifiants de scénario stables lorsque les fichiers sont déplacés ; utilisez docsRefs et codeRefs pour assurer la traçabilité de l’implémentation.

La liste de référence doit rester suffisamment large pour couvrir :

• les discussions par message privé et dans les canaux
• le comportement des fils de discussion
• le cycle de vie des actions sur les messages
• les rappels cron
• le rappel depuis la mémoire
• le changement de modèle
• le transfert à un sous-agent
• la lecture du dépôt et de la documentation
• une petite tâche de build telle que Lobster Invaders

Lanes de simulation des fournisseurs

qa suite comporte deux lanes locales de simulation des fournisseurs :

• mock-openai est la simulation OpenClaw tenant compte des scénarios. Elle reste la lane de simulation déterministe par défaut pour l’assurance qualité adossée au dépôt et les contrôles de parité.
• aimock démarre un serveur fournisseur reposant sur AIMock pour une couverture expérimentale des protocoles, des fixtures, de l’enregistrement/relecture et des perturbations. Cette lane est complémentaire et ne remplace pas le répartiteur de scénarios mock-openai.

L’implémentation des lanes de fournisseurs se trouve sous extensions/qa-lab/src/providers/. Chaque fournisseur gère ses valeurs par défaut, le démarrage de son serveur local, la configuration du modèle du Gateway, les besoins de préparation des profils d’authentification et les indicateurs de capacités réelles/simulées. Le code partagé de la suite et du Gateway passe par le registre des fournisseurs au lieu d’effectuer des branchements sur leurs noms.

Adaptateurs de transport

qa-lab fournit un point d’intégration de transport générique pour les scénarios d’assurance qualité YAML. qa-channel est le transport synthétique par défaut. crabline démarre des serveurs locaux qui reproduisent la forme des fournisseurs et exécute les plugins de canaux normaux d’OpenClaw avec ceux-ci. live est réservé aux identifiants réels des fournisseurs et aux canaux externes.

Au niveau de l’architecture, la répartition est la suivante :

• qa-lab gère l’exécution générique des scénarios, la concurrence des workers, l’écriture des artefacts et la génération de rapports.
• L’adaptateur de transport gère la configuration du Gateway, l’état de préparation, l’observation des flux entrants et sortants, les actions de transport et l’état normalisé du transport.
• Les fichiers YAML de scénario sous qa/scenarios/ définissent l’exécution du test ; qa-lab fournit la surface d’exécution réutilisable qui les exécute.

Ajout d’un canal

L’ajout d’un canal au système d’assurance qualité YAML nécessite l’implémentation du canal ainsi qu’un ensemble de scénarios qui exerce le contrat du canal. Pour une couverture des tests de fumée en CI, ajoutez le serveur fournisseur local Crabline correspondant et exposez-le via le pilote crabline.

N’ajoutez pas de nouvelle racine de commande d’assurance qualité de premier niveau lorsque l’hôte partagé qa-lab peut prendre en charge le flux.

qa-lab gère les mécanismes partagés de l’hôte :

• la racine de commande openclaw qa
• le démarrage et l’arrêt de la suite
• la concurrence des workers
• l’écriture des artefacts
• la génération de rapports
• l’exécution des scénarios
• les alias de compatibilité pour les anciens scénarios qa-channel

Les plugins d’exécution gèrent le contrat de transport :

• comment openclaw qa <runner> est monté sous la racine partagée qa
• comment le Gateway est configuré pour ce transport
• comment la disponibilité est vérifiée
• comment les événements entrants sont injectés
• comment les messages sortants sont observés
• comment les transcriptions et l'état normalisé du transport sont exposés
• comment les actions reposant sur le transport sont exécutées
• comment la réinitialisation ou le nettoyage propre au transport est géré

Le seuil minimal d'adoption pour un nouveau canal est le suivant :

1. Conserver qa-lab comme propriétaire de la racine partagée qa.
2. Implémenter l'exécuteur de transport sur l'interface hôte partagée de qa-lab.
3. Conserver les mécanismes propres au transport dans le Plugin d'exécution ou le harnais du canal.
4. Monter l'exécuteur sous la forme openclaw qa <runner> au lieu d'enregistrer une commande racine concurrente. Les Plugins d'exécution doivent déclarer qaRunners dans openclaw.plugin.json et exporter un tableau qaRunnerCliRegistrations correspondant depuis runtime-api.ts. Gardez runtime-api.ts léger ; la CLI chargée à la demande et l'exécution de l'exécuteur doivent rester derrière des points d'entrée distincts. Un adapterFactory facultatif expose le transport aux scénarios partagés sans modifier le catalogue de scénarios existant de la commande.
5. Créer ou adapter des scénarios YAML dans les répertoires thématiques qa/scenarios/.
6. Utiliser les fonctions auxiliaires génériques de scénario pour les nouveaux scénarios.
7. Maintenir le fonctionnement des alias de compatibilité existants, sauf si le dépôt effectue une migration intentionnelle.

La règle de décision est stricte :

• Si un comportement peut être exprimé une seule fois dans qa-lab, placez-le dans qa-lab.
• Si un comportement dépend du transport d'un seul canal, conservez-le dans ce Plugin d'exécution ou dans le harnais du Plugin.
• Si un scénario nécessite une nouvelle capacité utilisable par plusieurs canaux, ajoutez une fonction auxiliaire générique plutôt qu'une branche propre à un canal dans suite.ts.
• Si un comportement n'a de sens que pour un seul transport, conservez le scénario propre à ce transport et rendez-le explicite dans le contrat du scénario.

Noms des fonctions auxiliaires de scénario

Fonctions auxiliaires génériques privilégiées pour les nouveaux scénarios :

• waitForTransportReady
• waitForChannelReady
• injectInboundMessage
• injectOutboundMessage
• waitForTransportOutboundMessage
• waitForChannelOutboundMessage
• waitForNoTransportOutbound
• getTransportSnapshot
• readTransportMessage
• readTransportTranscript
• formatTransportTranscript
• resetTransport

Les alias de compatibilité restent disponibles pour les scénarios existants : waitForQaChannelReady, waitForOutboundMessage, waitForNoOutbound, formatConversationTranscript, resetBus ; toutefois, les nouveaux scénarios doivent utiliser les noms génériques. Les alias servent à éviter une migration simultanée, et ne constituent pas le modèle à suivre.

Rapports

qa-lab exporte un rapport de protocole Markdown à partir de la chronologie observée du bus. Le rapport doit répondre aux questions suivantes :

• Ce qui a fonctionné
• Ce qui a échoué
• Ce qui est resté bloqué
• Les scénarios de suivi qu’il serait utile d’ajouter

Pour obtenir l’inventaire des scénarios disponibles — utile pour dimensionner les travaux de suivi ou intégrer un nouveau transport — exécutez pnpm openclaw qa coverage (ajoutez --json pour obtenir une sortie lisible par une machine). Pour choisir une preuve ciblée concernant un comportement ou un chemin de fichier modifié, exécutez pnpm openclaw qa coverage --match <query>. Le rapport de correspondance recherche dans les métadonnées des scénarios, les références de documentation, les références de code, les identifiants de couverture, les plugins et les exigences relatives aux fournisseurs, puis affiche les cibles qa suite --scenario ... correspondantes.

Chaque exécution de qa suite écrit les artefacts de premier niveau qa-evidence.json, qa-suite-summary.json et qa-suite-report.md pour l’ensemble de scénarios sélectionné. Les scénarios qui déclarent execution.kind: vitest ou execution.kind: playwright exécutent le chemin de test correspondant et écrivent également des journaux propres à chaque scénario. Les scénarios qui déclarent execution.kind: script exécutent le producteur de preuves situé à execution.path via node --import tsx (avec ${outputDir} et ${scenarioId} développés dans execution.args) ; le producteur écrit son propre fichier qa-evidence.json, dont les entrées sont importées dans la sortie de la suite et dont les chemins d’artefacts sont résolus par rapport à ce fichier qa-evidence.json du producteur. Lorsque qa suite est lancé via qa run --qa-profile, le même fichier qa-evidence.json inclut également le résumé du tableau de bord du profil pour les catégories taxonomiques sélectionnées.

Considérez la sortie de couverture comme une aide à la découverte, et non comme un remplacement des contrôles ; le scénario sélectionné nécessite toujours le mode fournisseur, le transport en direct, Multipass, Testbox ou le circuit de publication approprié au comportement testé. Pour le contexte du tableau de bord, consultez Tableau de bord de maturité.

Pour les vérifications de personnalité et de style, exécutez le même scénario avec plusieurs références de modèles en direct et rédigez un rapport Markdown évalué :

pnpm openclaw qa character-eval \  --model openai/gpt-5.6-luna,thinking=medium,fast \  --model openai/gpt-5.2,thinking=xhigh \  --model openai/gpt-5,thinking=xhigh \  --model anthropic/claude-opus-4-8,thinking=high \  --model anthropic/claude-sonnet-4-6,thinking=high \  --model zai/glm-5.1,thinking=high \  --model moonshot/kimi-k2.5,thinking=high \  --model google/gemini-3.1-pro-preview,thinking=high \  --judge-model openai/gpt-5.6-sol,thinking=xhigh,fast \  --judge-model anthropic/claude-opus-4-8,thinking=high \  --blind-judge-models \  --concurrency 16 \  --judge-concurrency 16

La commande exécute des processus enfants locaux du Gateway d’assurance qualité, et non Docker. Les scénarios d’évaluation du caractère doivent définir le persona via SOUL.md, puis exécuter des tours utilisateur ordinaires, tels qu’une conversation, une aide sur l’espace de travail et de petites tâches sur des fichiers. Le modèle candidat ne doit pas être informé qu’il est en cours d’évaluation. La commande conserve chaque transcription complète, enregistre les statistiques d’exécution de base, puis demande aux modèles juges, en mode rapide avec un raisonnement xhigh lorsque celui-ci est pris en charge, de classer les exécutions selon leur naturel, leur ambiance et leur humour. Utilisez --blind-judge-models lorsque vous comparez des fournisseurs : l’invite du juge reçoit toujours chaque transcription et chaque statut d’exécution, mais les références des candidats sont remplacées par des libellés neutres tels que candidate-01 ; le rapport réassocie les classements aux références réelles après l’analyse.

Les exécutions des candidats utilisent par défaut un niveau de raisonnement high, avec medium pour GPT-5.6 Luna et xhigh pour les anciennes références d’évaluation OpenAI qui le prennent en charge. Remplacez le réglage d’un candidat particulier directement avec --model provider/model,thinking=<level> ; les options directes prennent également en charge fast, no-fast et fast=<bool>. --thinking <level> définit toujours une valeur de repli globale, et l’ancienne forme --model-thinking <provider/model=level> est conservée à des fins de compatibilité. Les références de candidats OpenAI utilisent par défaut le mode rapide afin que le traitement prioritaire soit employé lorsque le fournisseur le prend en charge. Transmettez --fast uniquement lorsque vous souhaitez imposer le mode rapide à tous les modèles candidats. Les durées des candidats et des juges sont enregistrées dans le rapport pour l’analyse comparative, mais les invites des juges indiquent explicitement de ne pas effectuer le classement selon la vitesse. Les exécutions des modèles candidats et juges utilisent toutes deux une concurrence de 16 par défaut. Réduisez --concurrency ou --judge-concurrency lorsque les limites du fournisseur ou la charge du Gateway local rendent une exécution trop bruitée.

Lorsqu’aucun candidat --model n’est fourni, l’évaluation du caractère utilise par défaut openai/gpt-5.6-luna, openai/gpt-5.2, openai/gpt-5, anthropic/claude-opus-4-8, anthropic/claude-sonnet-4-6, zai/glm-5.1, moonshot/kimi-k2.5 et google/gemini-3.1-pro-preview. Lorsqu’aucun --judge-model n’est fourni, les modèles juges utilisent par défaut openai/gpt-5.6-sol,thinking=xhigh,fast et anthropic/claude-opus-4-8,thinking=high.

Documentation associée

• AQ Matrix
• Tableau de maturité
• Pack de benchmarks pour agent personnel
• Canal AQ
• Tests
• Tableau de bord