diff --git a/docs/fr/concepts/qa-e2e-automation.md b/docs/fr/concepts/qa-e2e-automation.md index c25f00bd7..8a073b499 100644 --- a/docs/fr/concepts/qa-e2e-automation.md +++ b/docs/fr/concepts/qa-e2e-automation.md @@ -1,37 +1,37 @@ --- read_when: - - Étendre qa-lab ou qa-channel + - Extension de qa-lab ou qa-channel - Ajout de scénarios QA adossés au dépôt - - Créer une automatisation QA plus réaliste autour du tableau de bord Gateway -summary: Forme de l’automatisation QA privée pour qa-lab, qa-channel, les scénarios préconfigurés et les rapports de protocole -title: Automatisation QA E2E + - Création d’une automatisation QA plus réaliste autour du tableau de bord Gateway +summary: Forme de l’automatisation QA privée pour qa-lab, qa-channel, les scénarios initialisés et les rapports de protocole +title: Automatisation E2E de la QA x-i18n: - generated_at: "2026-04-13T07:04:03Z" + generated_at: "2026-04-16T21:51:24Z" model: gpt-5.4 provider: openai - source_hash: a4a4f5c765163565c95c2a071f201775fd9d8d60cad4ff25d71e4710559c1570 + source_hash: 7deefda1c90a0d2e21e2155ffd8b585fb999e7416bdbaf0ff57eb33ccc063afc source_path: concepts/qa-e2e-automation.md workflow: 15 --- -# Automatisation QA E2E +# Automatisation E2E de la QA -La pile QA privée est conçue pour exercer OpenClaw d’une manière plus réaliste, +La pile QA privée est conçue pour tester OpenClaw d’une manière plus réaliste, façonnée par les canaux, qu’un simple test unitaire ne peut le faire. Éléments actuels : - `extensions/qa-channel` : canal de messages synthétique avec des surfaces pour les MP, les canaux, les fils, les réactions, les modifications et les suppressions. -- `extensions/qa-lab` : UI de débogage et bus QA pour observer la transcription, +- `extensions/qa-lab` : interface de débogage et bus QA pour observer la transcription, injecter des messages entrants et exporter un rapport Markdown. -- `qa/` : ressources d’amorçage adossées au dépôt pour la tâche de lancement et les +- `qa/` : ressources de départ adossées au dépôt pour la tâche de lancement et les scénarios QA de référence. -Le flux actuel de l’opérateur QA est un site QA à deux volets : +Le flux opérateur QA actuel est un site QA à deux volets : - Gauche : tableau de bord Gateway (Control UI) avec l’agent. -- Droite : QA Lab, affichant la transcription de style Slack et le plan de scénario. +- Droite : QA Lab, affichant une transcription de type Slack et le plan du scénario. Lancez-le avec : @@ -40,12 +40,12 @@ pnpm qa:lab:up ``` Cela construit le site QA, démarre la voie Gateway adossée à Docker et expose la -page QA Lab où un opérateur ou une boucle d’automatisation peut donner à l’agent une mission -QA, observer le comportement réel du canal et consigner ce qui a fonctionné, échoué ou -est resté bloqué. +page QA Lab où un opérateur ou une boucle d’automatisation peut confier à l’agent une +mission QA, observer le comportement réel du canal et consigner ce qui a +fonctionné, échoué ou est resté bloqué. -Pour une itération plus rapide sur l’UI de QA Lab sans reconstruire l’image Docker à chaque fois, -démarrez la pile avec un bundle QA Lab monté en liaison : +Pour des itérations plus rapides sur l’interface QA Lab sans reconstruire l’image Docker à chaque fois, +démarrez la pile avec un bundle QA Lab monté par liaison : ```bash pnpm openclaw qa docker-build-image @@ -54,52 +54,55 @@ pnpm qa:lab:up:fast pnpm qa:lab:watch ``` -`qa:lab:up:fast` conserve les services Docker sur une image préconstruite et monte en liaison +`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 changements, et le navigateur se recharge automatiquement lorsque -le hachage de ressource QA Lab change. +reconstruit ce bundle à chaque modification, et le navigateur se recharge automatiquement lorsque le hachage +des ressources QA Lab change. -Pour une voie Matrix de smoke test sur transport réel, exécutez : +Pour une voie de validation Matrix avec transport réel, exécutez : ```bash pnpm openclaw qa matrix ``` -Cette voie provisionne un homeserver Tuwunel jetable dans Docker, enregistre des -utilisateurs temporaires pour le pilote, le SUT et l’observateur, crée un salon privé, puis exécute -le Plugin Matrix réel dans un enfant QA gateway. La voie à transport réel garde la -configuration enfant limitée au transport testé, afin que Matrix s’exécute sans -`qa-channel` dans la configuration enfant. +Cette voie provisionne un homeserver Tuwunel jetable dans Docker, enregistre +des utilisateurs temporaires pour le pilote, le SUT et l’observateur, crée une salle privée, +puis exécute le véritable plugin Matrix dans un enfant Gateway QA. La voie de transport en direct conserve +la configuration enfant limitée au transport testé, de sorte que Matrix s’exécute sans +`qa-channel` dans la configuration enfant. Elle écrit les artefacts de rapport structurés ainsi +qu’un journal combiné stdout/stderr dans le répertoire de sortie Matrix QA sélectionné. Pour +capturer également la sortie de construction/lancement externe de `scripts/run-node.mjs`, définissez +`OPENCLAW_RUN_NODE_OUTPUT_LOG=` vers un fichier journal local au dépôt. -Pour une voie Telegram de smoke test sur transport réel, exécutez : +Pour une voie de validation Telegram avec transport réel, exécutez : ```bash pnpm openclaw qa telegram ``` -Cette voie cible un groupe privé Telegram réel au lieu de provisionner un serveur -jetable. Elle nécessite `OPENCLAW_QA_TELEGRAM_GROUP_ID`, +Cette voie cible un groupe Telegram privé réel au lieu de provisionner un +serveur jetable. Elle nécessite `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` et `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, ainsi que deux bots distincts dans le même -groupe privé. Le bot SUT doit avoir un nom d’utilisateur Telegram, et -l’observation bot-à-bot fonctionne mieux lorsque les deux bots ont le mode -Bot-to-Bot Communication activé dans `@BotFather`. +groupe privé. Le bot SUT doit avoir un nom d’utilisateur Telegram, et l’observation +bot-à-bot fonctionne mieux lorsque les deux bots ont le mode de communication bot-à-bot +activé dans `@BotFather`. Les voies de transport en direct partagent désormais un contrat plus petit au lieu que chacune -invente sa propre forme de liste de scénarios : +invente sa propre forme de liste de scénarios. -`qa-channel` reste la suite large de comportements produit synthétiques et ne fait pas partie +`qa-channel` reste la suite large de comportements synthétiques du produit et ne fait pas partie de la matrice de couverture des transports en direct. -| Voie | Canary | Filtrage des mentions | Blocage par liste d’autorisation | Réponse de premier niveau | Reprise après redémarrage | Suivi de fil | Isolation du fil | Observation des réactions | Commande help | -| -------- | ------ | --------------------- | -------------------------------- | ------------------------- | ------------------------- | ------------ | ---------------- | ------------------------- | ------------- | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Voie | Canary | Filtrage des mentions | Blocage par liste d’autorisation | Réponse de niveau supérieur | Reprise après redémarrage | Suivi dans un fil | Isolation des fils | Observation des réactions | Commande d’aide | +| -------- | ------ | --------------------- | -------------------------------- | --------------------------- | ------------------------- | ----------------- | ------------------ | ------------------------- | --------------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | -Cela permet à `qa-channel` de rester la suite large de comportements produit tandis que Matrix, +Cela conserve `qa-channel` comme la suite large de comportements du produit, tandis que Matrix, Telegram et les futurs transports en direct partagent une checklist explicite de contrat de transport. -Pour une voie VM Linux jetable sans intégrer Docker au parcours QA, exécutez : +Pour une voie sur VM Linux jetable sans intégrer Docker dans le parcours QA, exécutez : ```bash pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline @@ -108,24 +111,24 @@ pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline Cela démarre un invité Multipass neuf, installe les dépendances, construit OpenClaw dans l’invité, exécute `qa suite`, puis copie le rapport QA normal et le résumé dans `.artifacts/qa-e2e/...` sur l’hôte. -Il réutilise le même comportement de sélection de scénarios que `qa suite` sur l’hôte. -Les exécutions sur l’hôte et sur Multipass exécutent plusieurs scénarios sélectionnés en parallèle -avec des workers Gateway isolés par défaut, jusqu’à 64 workers ou le nombre de -scénarios sélectionnés. Utilisez `--concurrency ` pour ajuster le nombre de workers, ou +Elle réutilise le même comportement de sélection de scénarios que `qa suite` sur l’hôte. +Les exécutions sur l’hôte et sur Multipass exécutent par défaut plusieurs scénarios sélectionnés en parallèle +avec des workers Gateway isolés, jusqu’à 64 workers ou au nombre de scénarios sélectionnés. +Utilisez `--concurrency ` pour ajuster le nombre de workers, ou `--concurrency 1` pour une exécution en série. -Les exécutions en direct transmettent les entrées d’auth QA prises en charge qui sont pratiques pour -l’invité : clés de fournisseur basées sur l’environnement, chemin de configuration du fournisseur QA live, et +Les exécutions en direct transmettent les entrées d’authentification QA prises en charge qui sont pratiques pour +l’invité : les clés de fournisseur basées sur l’environnement, le chemin de configuration du fournisseur QA live, et `CODEX_HOME` lorsqu’il est présent. Gardez `--output-dir` sous la racine du dépôt afin que l’invité -puisse réécrire via l’espace de travail monté. +puisse écrire en retour via l’espace de travail monté. -## Ressources d’amorçage adossées au dépôt +## Ressources de départ adossées au dépôt -Les ressources d’amorçage se trouvent dans `qa/` : +Les ressources de départ se trouvent dans `qa/` : - `qa/scenarios/index.md` - `qa/scenarios/*.md` -Elles sont intentionnellement dans git afin que le plan QA soit visible à la fois pour les humains et pour +Elles sont volontairement conservées dans git afin que le plan QA soit visible à la fois pour les humains et pour l’agent. `qa-lab` doit rester un exécuteur Markdown générique. Chaque fichier Markdown de scénario est @@ -133,22 +136,22 @@ la source de vérité pour une exécution de test et doit définir : - les métadonnées du scénario - les références de documentation et de code -- les exigences de Plugin facultatives +- les exigences de plugin facultatives - le correctif de configuration Gateway facultatif - le `qa-flow` exécutable La surface d’exécution réutilisable qui sous-tend `qa-flow` peut rester générique -et transversale. Par exemple, les scénarios Markdown peuvent combiner des helpers côté -transport avec des helpers côté navigateur qui pilotent la Control UI intégrée via la surface -Gateway `browser.request` sans ajouter d’exécuteur à cas particulier. +et transversale. Par exemple, les scénarios Markdown peuvent combiner des +helpers côté transport avec des helpers côté navigateur qui pilotent la Control UI intégrée via la +surface Gateway `browser.request` sans ajouter d’exécuteur spécialisé. La liste de référence doit rester suffisamment large pour couvrir : -- les MP et le chat de canal +- les conversations en MP et en canal - le comportement des fils - le cycle de vie des actions sur les messages - les rappels Cron -- le rappel mémoire +- le rappel de mémoire - le changement de modèle - le transfert à un sous-agent - la lecture du dépôt et de la documentation @@ -158,14 +161,14 @@ La liste de référence doit rester suffisamment large pour couvrir : `qa-lab` possède une interface de transport générique pour les scénarios QA Markdown. `qa-channel` est le premier adaptateur sur cette interface, mais l’objectif de conception est plus large : -les futurs canaux réels ou synthétiques doivent s’intégrer au même exécuteur de suite -au lieu d’ajouter un exécuteur QA spécifique à un transport. +les futurs canaux réels ou synthétiques devraient s’intégrer au même exécuteur de suite +au lieu d’ajouter un exécuteur QA spécifique au transport. -Au niveau de l’architecture, la répartition est la suivante : +Au niveau de l’architecture, la séparation est la suivante : -- `qa-lab` possède l’exécution générique des scénarios, la concurrence des workers, l’écriture des artefacts et le reporting. -- l’adaptateur de transport possède la configuration Gateway, l’état de préparation, l’observation entrante et sortante, les actions de transport et l’état de transport normalisé. -- les fichiers de scénarios Markdown sous `qa/scenarios/` définissent l’exécution de test ; `qa-lab` fournit la surface d’exécution réutilisable qui les exécute. +- `qa-lab` gère l’exécution générique des scénarios, la concurrence des workers, l’écriture des artefacts et le reporting. +- l’adaptateur de transport gère la configuration Gateway, l’état de préparation, l’observation des entrées et sorties, les actions de transport et l’état de transport normalisé. +- les fichiers de scénarios Markdown sous `qa/scenarios/` définissent l’exécution du test ; `qa-lab` fournit la surface d’exécution réutilisable qui les exécute. Les consignes d’adoption destinées aux mainteneurs pour les nouveaux adaptateurs de canal se trouvent dans [Testing](/fr/help/testing#adding-a-channel-to-qa). @@ -173,15 +176,15 @@ Les consignes d’adoption destinées aux mainteneurs pour les nouveaux adaptate ## Rapports `qa-lab` exporte un rapport de protocole Markdown à partir de la chronologie observée du bus. -Le rapport doit répondre à ces questions : +Le rapport doit répondre aux questions suivantes : - Ce qui a fonctionné - Ce qui a échoué - Ce qui est resté bloqué - Quels scénarios de suivi valent la peine d’être ajoutés -Pour les vérifications de caractère et de style, exécutez le même scénario sur plusieurs références de modèles live -et écrivez un rapport Markdown évalué : +Pour les vérifications de caractère et de style, exécutez le même scénario sur plusieurs +références de modèles en direct et écrivez un rapport Markdown évalué : ```bash pnpm openclaw qa character-eval \ @@ -200,31 +203,31 @@ pnpm openclaw qa character-eval \ --judge-concurrency 16 ``` -La commande exécute des processus enfants locaux QA gateway, pas Docker. Les scénarios -d’évaluation du caractère doivent définir la persona via `SOUL.md`, puis exécuter des tours utilisateur ordinaires -comme le chat, l’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 des statistiques d’exécution de base, puis demande aux modèles juges en mode fast avec +La commande exécute des processus enfants Gateway QA locaux, pas Docker. Les scénarios d’évaluation de caractère +doivent définir la persona via `SOUL.md`, puis exécuter des tours utilisateur ordinaires +comme la discussion, l’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 préserve chaque +transcription complète, enregistre des statistiques d’exécution de base, puis demande aux modèles juges en mode rapide avec un raisonnement `xhigh` de classer les exécutions selon leur naturel, leur ambiance et leur humour. Utilisez `--blind-judge-models` lors de la comparaison de fournisseurs : l’invite du juge reçoit toujours -chaque transcription et statut d’exécution, mais les références candidates sont remplacées par des étiquettes neutres -comme `candidate-01` ; le rapport remappe les classements vers les vraies références après +chaque transcription et le statut d’exécution, mais les références candidates sont remplacées par des +étiquettes neutres telles que `candidate-01` ; le rapport réassocie les classements aux références réelles après l’analyse. -Les exécutions candidates utilisent par défaut le niveau de réflexion `high`, avec `xhigh` pour les modèles OpenAI qui le -prennent en charge. Remplacez un candidat spécifique en ligne avec -`--model provider/model,thinking=`. `--thinking ` définit toujours une -valeur de repli globale, et l’ancienne forme `--model-thinking ` est +Les exécutions candidates utilisent par défaut le niveau de réflexion `high`, avec `xhigh` pour les modèles OpenAI qui +le prennent en charge. Remplacez un candidat spécifique en ligne avec +`--model provider/model,thinking=`. `--thinking ` définit toujours un +repli global, et l’ancienne forme `--model-thinking ` est conservée pour compatibilité. -Les références candidates OpenAI utilisent par défaut le mode fast afin que le traitement prioritaire soit utilisé là où +Les références candidates OpenAI utilisent par défaut le mode rapide afin que le traitement prioritaire soit utilisé lorsque le fournisseur le prend en charge. Ajoutez `,fast`, `,no-fast` ou `,fast=false` en ligne lorsqu’un -candidat ou juge unique a besoin d’un remplacement. Passez `--fast` uniquement si vous souhaitez -forcer le mode fast pour tous les modèles candidats. Les durées des candidats et des juges sont +candidat ou juge unique nécessite un remplacement. Passez `--fast` uniquement si vous souhaitez +forcer le mode rapide pour chaque modèle candidat. 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 classer selon la vitesse. +de ne pas classer en fonction de la vitesse. Les exécutions des modèles candidats et juges utilisent toutes deux par défaut une concurrence de 16. Réduisez -`--concurrency` ou `--judge-concurrency` lorsque les limites du fournisseur ou la pression sur la Gateway locale -rendent une exécution trop bruitée. -Lorsqu’aucun `--model` candidat n’est transmis, l’évaluation du caractère utilise par défaut +`--concurrency` ou `--judge-concurrency` lorsque les limites des fournisseurs ou la pression locale sur Gateway +rendent une exécution trop bruyante. +Lorsqu’aucun `--model` candidat n’est transmis, l’évaluation de caractère utilise par défaut `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` et diff --git a/docs/fr/help/testing.md b/docs/fr/help/testing.md index a95a5dced..8249211d8 100644 --- a/docs/fr/help/testing.md +++ b/docs/fr/help/testing.md @@ -1,50 +1,50 @@ --- read_when: - - Exécuter les tests en local ou dans la CI + - Exécuter les tests en local ou dans CI - Ajouter des tests de régression pour les bugs de modèle/fournisseur - - Déboguer le comportement de Gateway + agent + - Déboguer le comportement de Gateway et de l’agent summary: 'Kit de test : suites unitaires/e2e/live, exécuteurs Docker, et ce que couvre chaque test' -title: Test en cours +title: Testირება x-i18n: - generated_at: "2026-04-15T14:40:36Z" + generated_at: "2026-04-16T21:51:25Z" model: gpt-5.4 provider: openai - source_hash: ec3632cafa1f38b27510372391b84af744266df96c58f7fac98aa03763465db8 + source_hash: af2bc0e9b5e08ca3119806d355b517290f6078fda430109e7a0b153586215e34 source_path: help/testing.md workflow: 15 --- # Tests -OpenClaw dispose de trois suites Vitest (unit/integration, e2e, live) et d’un petit ensemble d’exécuteurs Docker. +OpenClaw propose trois suites Vitest (unitaire/intégration, e2e, live) et un petit ensemble d’exécuteurs Docker. Cette documentation est un guide « comment nous testons » : - Ce que couvre chaque suite (et ce qu’elle ne couvre délibérément _pas_) - Quelles commandes exécuter pour les workflows courants (local, avant push, débogage) -- Comment les tests live détectent les identifiants et sélectionnent les modèles/fournisseurs +- Comment les tests live découvrent les identifiants et sélectionnent les modèles/fournisseurs - Comment ajouter des tests de régression pour des problèmes réels de modèle/fournisseur ## Démarrage rapide La plupart du temps : -- Porte complète (attendue avant un push) : `pnpm build && pnpm check && pnpm test` +- Porte complète (attendue avant push) : `pnpm build && pnpm check && pnpm test` - Exécution locale plus rapide de la suite complète sur une machine bien dimensionnée : `pnpm test:max` - Boucle de surveillance Vitest directe : `pnpm test:watch` -- Le ciblage direct de fichiers prend désormais aussi en charge les chemins d’extension/canal : `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Le ciblage direct de fichier route maintenant aussi les chemins d’extension/de canal : `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` - Préférez d’abord les exécutions ciblées quand vous itérez sur un seul échec. - Site QA adossé à Docker : `pnpm qa:lab:up` - Voie QA adossée à une VM Linux : `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Quand vous modifiez des tests ou souhaitez plus de confiance : +Quand vous modifiez des tests ou voulez plus de confiance : - Porte de couverture : `pnpm test:coverage` - Suite E2E : `pnpm test:e2e` Quand vous déboguez de vrais fournisseurs/modèles (nécessite de vrais identifiants) : -- Suite live (modèles + sondes d’outil/image Gateway) : `pnpm test:live` +- Suite live (modèles + sondes d’outils/images Gateway) : `pnpm test:live` - Cibler silencieusement un seul fichier live : `pnpm test:live -- src/agents/models.profiles.live.test.ts` Astuce : quand vous n’avez besoin que d’un seul cas en échec, préférez restreindre les tests live via les variables d’environnement de liste d’autorisation décrites ci-dessous. @@ -55,48 +55,48 @@ Ces commandes se trouvent à côté des suites de test principales quand vous av - `pnpm openclaw qa suite` - Exécute directement sur l’hôte des scénarios QA adossés au dépôt. - - Exécute par défaut plusieurs scénarios sélectionnés en parallèle avec des workers Gateway isolés, jusqu’à 64 workers ou au nombre de scénarios sélectionnés. Utilisez `--concurrency ` pour ajuster le nombre de workers, ou `--concurrency 1` pour retrouver l’ancienne voie sérielle. + - Exécute par défaut plusieurs scénarios sélectionnés en parallèle avec des workers Gateway isolés, jusqu’à 64 workers ou au nombre de scénarios sélectionnés. Utilisez `--concurrency ` pour ajuster le nombre de workers, ou `--concurrency 1` pour l’ancienne voie sérielle. - `pnpm openclaw qa suite --runner multipass` - Exécute la même suite QA dans une VM Linux Multipass jetable. - Conserve le même comportement de sélection de scénarios que `qa suite` sur l’hôte. - - Réutilise les mêmes indicateurs de sélection fournisseur/modèle que `qa suite`. + - Réutilise les mêmes drapeaux de sélection de fournisseur/modèle que `qa suite`. - Les exécutions live transmettent les entrées d’authentification QA prises en charge qui sont pratiques pour l’invité : - les clés de fournisseur basées sur l’environnement, le chemin de configuration du fournisseur live QA, et `CODEX_HOME` lorsqu’il est présent. - - Les répertoires de sortie doivent rester sous la racine du dépôt afin que l’invité puisse écrire en retour via l’espace de travail monté. - - Écrit le rapport QA normal + le résumé ainsi que les journaux Multipass sous + clés de fournisseur basées sur l’environnement, chemin de configuration du fournisseur live QA, et `CODEX_HOME` si présent. + - Les répertoires de sortie doivent rester sous la racine du dépôt pour que l’invité puisse réécrire via l’espace de travail monté. + - Écrit le rapport QA normal + le résumé ainsi que les logs Multipass sous `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Démarre le site QA adossé à Docker pour un travail QA de type opérateur. + - Démarre le site QA adossé à Docker pour le travail QA de type opérateur. - `pnpm openclaw qa matrix` - Exécute la voie QA live Matrix contre un homeserver Tuwunel jetable adossé à Docker. - - Cet hôte QA est aujourd’hui réservé au dépôt/dev. Les installations OpenClaw packagées ne livrent pas `qa-lab`, elles n’exposent donc pas `openclaw qa`. - - Les checkouts du dépôt chargent directement l’exécuteur embarqué ; aucune étape séparée d’installation de Plugin n’est nécessaire. - - Provisionne trois utilisateurs Matrix temporaires (`driver`, `sut`, `observer`) plus un salon privé, puis démarre un processus enfant de Gateway QA avec le vrai Plugin Matrix comme transport du SUT. + - Cet hôte QA est pour le dépôt/le développement uniquement aujourd’hui. Les installations OpenClaw packagées n’incluent pas `qa-lab`, elles n’exposent donc pas `openclaw qa`. + - Les extractions du dépôt chargent directement l’exécuteur intégré ; aucune étape d’installation de plugin séparée n’est nécessaire. + - Approvisionne trois utilisateurs Matrix temporaires (`driver`, `sut`, `observer`) ainsi qu’une salle privée, puis démarre un processus enfant de Gateway QA avec le vrai plugin Matrix comme transport SUT. - Utilise par défaut l’image Tuwunel stable épinglée `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Remplacez-la avec `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE` quand vous devez tester une autre image. - - Matrix n’expose pas d’indicateurs partagés de source d’identifiants, car la voie provisionne localement des utilisateurs jetables. - - Écrit un rapport QA Matrix, un résumé et un artefact des événements observés sous `.artifacts/qa-e2e/...`. + - Matrix n’expose pas de drapeaux partagés de source d’identifiants, car la voie provisionne localement des utilisateurs jetables. + - Écrit un rapport QA Matrix, un résumé, un artefact observed-events, et un log de sortie combiné stdout/stderr sous `.artifacts/qa-e2e/...`. - `pnpm openclaw qa telegram` - - Exécute la voie QA live Telegram contre un vrai groupe privé en utilisant les jetons de bot du driver et du SUT depuis l’environnement. - - Nécessite `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` et `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. L’identifiant du groupe doit être l’identifiant numérique du chat Telegram. - - Prend en charge `--credential-source convex` pour des identifiants mutualisés en pool. Utilisez le mode env par défaut, ou définissez `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` pour utiliser des baux mutualisés. - - Nécessite deux bots distincts dans le même groupe privé, le bot SUT devant exposer un nom d’utilisateur Telegram. - - Pour une observation stable entre bots, activez le mode de communication bot à bot dans `@BotFather` pour les deux bots et assurez-vous que le bot driver peut observer le trafic des bots du groupe. - - Écrit un rapport QA Telegram, un résumé et un artefact des messages observés sous `.artifacts/qa-e2e/...`. + - Exécute la voie QA live Telegram contre un groupe privé réel en utilisant les jetons de bot du driver et du SUT depuis l’environnement. + - Nécessite `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN`, et `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. L’identifiant du groupe doit être l’identifiant numérique du chat Telegram. + - Prend en charge `--credential-source convex` pour des identifiants partagés mutualisés. Utilisez le mode env par défaut, ou définissez `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` pour utiliser des baux mutualisés. + - Nécessite deux bots distincts dans le même groupe privé, avec le bot SUT exposant un nom d’utilisateur Telegram. + - Pour une observation stable entre bots, activez le mode de communication bot-à-bot dans `@BotFather` pour les deux bots et assurez-vous que le bot driver peut observer le trafic des bots du groupe. + - Écrit un rapport QA Telegram, un résumé et un artefact observed-messages sous `.artifacts/qa-e2e/...`. -Les voies de transport live partagent un contrat standard afin que les nouveaux transports ne divergent pas : +Les voies de transport live partagent un contrat standard pour éviter que les nouveaux transports ne divergent : `qa-channel` reste la suite QA synthétique large et ne fait pas partie de la matrice de couverture des transports live. -| Voie | Canary | Filtrage des mentions | Blocage par liste d’autorisation | Réponse de premier niveau | Reprise après redémarrage | Suivi de fil | Isolation des fils | Observation des réactions | Commande d’aide | -| -------- | ------ | --------------------- | -------------------------------- | ------------------------- | ------------------------- | ------------ | ------------------ | ------------------------- | --------------- | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Voie | Canary | Filtrage des mentions | Blocage par liste d’autorisation | Réponse de premier niveau | Reprise après redémarrage | Suivi de fil | Isolation du fil | Observation des réactions | Commande d’aide | +| -------- | ------ | --------------------- | -------------------------------- | ------------------------- | ------------------------- | ------------ | ---------------- | ------------------------- | --------------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | ### Identifiants Telegram partagés via Convex (v1) Quand `--credential-source convex` (ou `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) est activé pour -`openclaw qa telegram`, QA lab acquiert un bail exclusif depuis un pool adossé à Convex, envoie des Heartbeat -pour ce bail pendant l’exécution de la voie, puis libère le bail à l’arrêt. +`openclaw qa telegram`, QA lab acquiert un bail exclusif depuis un pool adossé à Convex, envoie un Heartbeat pour +ce bail pendant l’exécution de la voie, puis libère le bail à l’arrêt. Squelette de projet Convex de référence : @@ -108,9 +108,9 @@ Variables d’environnement requises : - Un secret pour le rôle sélectionné : - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` pour `maintainer` - `OPENCLAW_QA_CONVEX_SECRET_CI` pour `ci` -- Sélection du rôle d’identifiant : +- Sélection du rôle des identifiants : - CLI : `--credential-role maintainer|ci` - - Valeur par défaut via l’environnement : `OPENCLAW_QA_CREDENTIAL_ROLE` (par défaut : `maintainer`) + - Valeur par défaut de l’environnement : `OPENCLAW_QA_CREDENTIAL_ROLE` (par défaut : `maintainer`) Variables d’environnement facultatives : @@ -119,15 +119,15 @@ Variables d’environnement facultatives : - `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (par défaut `90000`) - `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (par défaut `15000`) - `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (par défaut `/qa-credentials/v1`) -- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (identifiant de traçabilité facultatif) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` autorise les URL Convex `http://` en loopback uniquement pour le développement local. +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (identifiant de traçage facultatif) +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` autorise les URL Convex `http://` de loopback pour le développement strictement local. `OPENCLAW_QA_CONVEX_SITE_URL` doit utiliser `https://` en fonctionnement normal. -Les commandes d’administration pour mainteneurs (ajout/suppression/liste du pool) nécessitent +Les commandes d’administration mainteneur (ajout/suppression/liste du pool) nécessitent spécifiquement `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -Assistants CLI pour les mainteneurs : +Aides CLI pour les mainteneurs : ```bash pnpm openclaw qa credentials add --kind telegram --payload-file qa/telegram-credential.json @@ -142,7 +142,7 @@ Contrat de point de terminaison par défaut (`OPENCLAW_QA_CONVEX_SITE_URL` + `/q - `POST /acquire` - Requête : `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` - Succès : `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` - - Épuisé/réessayable : `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` + - Épuisé / réessayable : `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - Requête : `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - Succès : `{ status: "ok" }` (ou `2xx` vide) @@ -160,23 +160,23 @@ Contrat de point de terminaison par défaut (`OPENCLAW_QA_CONVEX_SITE_URL` + `/q - Requête : `{ kind?, status?, includePayload?, limit? }` - Succès : `{ status: "ok", credentials, count }` -Forme de payload pour le type Telegram : +Structure de payload pour le type Telegram : - `{ groupId: string, driverToken: string, sutToken: string }` -- `groupId` doit être une chaîne correspondant à un identifiant numérique de chat Telegram. -- `admin/add` valide cette forme pour `kind: "telegram"` et rejette les payloads malformés. +- `groupId` doit être une chaîne représentant un identifiant numérique de chat Telegram. +- `admin/add` valide cette structure pour `kind: "telegram"` et rejette les payloads mal formés. ### Ajouter un canal à la QA -Ajouter un canal au système QA markdown nécessite exactement deux choses : +Ajouter un canal au système QA Markdown nécessite exactement deux choses : 1. Un adaptateur de transport pour le canal. 2. Un pack de scénarios qui exerce le contrat du canal. N’ajoutez pas une nouvelle racine de commande QA de premier niveau quand l’hôte partagé `qa-lab` peut -prendre en charge le flux. +gérer le flux. -`qa-lab` gère les mécaniques hôtes partagées : +`qa-lab` gère les mécanismes d’hôte partagés : - la racine de commande `openclaw qa` - le démarrage et l’arrêt de la suite @@ -186,37 +186,37 @@ prendre en charge le flux. - l’exécution des scénarios - les alias de compatibilité pour les anciens scénarios `qa-channel` -Les Plugins d’exécuteur gèrent le contrat de transport : +Les plugins d’exécuteur gèrent le contrat de transport : - comment `openclaw qa ` est monté sous la racine partagée `qa` - comment Gateway est configuré pour ce transport -- comment l’état de préparation est vérifié +- comment l’état prêt est vérifié - comment les événements entrants sont injectés - comment les messages sortants sont observés - comment les transcriptions et l’état de transport normalisé sont exposés - comment les actions adossées au transport sont exécutées -- comment la réinitialisation ou le nettoyage spécifique au transport est géré +- comment la réinitialisation ou le nettoyage spécifiques au transport sont gérés -Le seuil d’adoption minimal pour un nouveau canal est le suivant : +Le seuil minimal d’adoption pour un nouveau canal est : -1. Garder `qa-lab` comme propriétaire de la racine partagée `qa`. -2. Implémenter l’exécuteur de transport sur la jonction hôte partagée `qa-lab`. -3. Garder les mécaniques spécifiques au transport dans le Plugin d’exécuteur ou le harnais du canal. -4. Monter l’exécuteur en tant que `openclaw qa ` au lieu d’enregistrer une racine de commande concurrente. - Les Plugins d’exécuteur doivent déclarer `qaRunners` dans `openclaw.plugin.json` et exporter un tableau `qaRunnerCliRegistrations` correspondant depuis `runtime-api.ts`. - Gardez `runtime-api.ts` léger ; le CLI paresseux et l’exécution de l’exécuteur doivent rester derrière des points d’entrée séparés. -5. Rédiger ou adapter les scénarios markdown sous `qa/scenarios/`. -6. Utiliser les assistants de scénarios génériques pour les nouveaux scénarios. -7. Garder les alias de compatibilité existants opérationnels sauf si le dépôt effectue une migration intentionnelle. +1. Conserver `qa-lab` comme propriétaire de la racine partagée `qa`. +2. Implémenter l’exécuteur de transport sur l’interface d’hôte partagée `qa-lab`. +3. Conserver les mécanismes spécifiques au transport dans le plugin d’exécuteur ou le harnais du canal. +4. Monter l’exécuteur sous `openclaw qa ` au lieu d’enregistrer une racine de commande concurrente. + Les plugins d’exécuteur doivent déclarer `qaRunners` dans `openclaw.plugin.json` et exporter un tableau `qaRunnerCliRegistrations` correspondant depuis `runtime-api.ts`. + Gardez `runtime-api.ts` léger ; l’exécution paresseuse de la CLI et de l’exécuteur doit rester derrière des points d’entrée séparés. +5. Rédiger ou adapter les scénarios Markdown sous `qa/scenarios/`. +6. Utiliser les aides de scénario génériques pour les nouveaux scénarios. +7. Conserver les alias de compatibilité existants en fonctionnement, 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`, mettez-le dans `qa-lab`. -- Si un comportement dépend d’un transport de canal, gardez-le dans ce Plugin d’exécuteur ou dans le harnais du Plugin. -- Si un scénario nécessite une nouvelle capacité que plus d’un canal peut utiliser, ajoutez un assistant générique au lieu d’une branche spécifique à un canal dans `suite.ts`. -- Si un comportement n’a de sens que pour un seul transport, gardez le scénario spécifique à ce transport et rendez cela explicite dans le contrat de scénario. +- Si un comportement peut être exprimé une seule fois dans `qa-lab`, placez-le dans `qa-lab`. +- Si un comportement dépend d’un transport de canal, conservez-le dans ce plugin d’exécuteur ou ce harnais de plugin. +- Si un scénario nécessite une nouvelle capacité que plusieurs canaux peuvent utiliser, ajoutez une aide générique plutôt qu’une branche spécifique à un canal dans `suite.ts`. +- Si un comportement n’a de sens que pour un seul transport, gardez le scénario spécifique à ce transport et rendez cela explicite dans le contrat du scénario. -Les noms d’assistants génériques préférés pour les nouveaux scénarios sont : +Les noms d’aides génériques préférés pour les nouveaux scénarios sont : - `waitForTransportReady` - `waitForChannelReady` @@ -231,7 +231,7 @@ Les noms d’assistants génériques préférés pour les nouveaux scénarios so - `formatTransportTranscript` - `resetTransport` -Les alias de compatibilité restent disponibles pour les scénarios existants, notamment : +Des alias de compatibilité restent disponibles pour les scénarios existants, notamment : - `waitForQaChannelReady` - `waitForOutboundMessage` @@ -239,102 +239,102 @@ Les alias de compatibilité restent disponibles pour les scénarios existants, n - `formatConversationTranscript` - `resetBus` -Les nouveaux travaux de canal doivent utiliser les noms d’assistants génériques. -Les alias de compatibilité existent pour éviter une migration « big bang », pas comme modèle pour +Les nouveaux travaux sur les canaux doivent utiliser les noms d’aide génériques. +Les alias de compatibilité existent pour éviter une migration brutale, pas comme modèle pour la rédaction de nouveaux scénarios. ## Suites de test (ce qui s’exécute où) -Considérez les suites comme un « réalisme croissant » (et une instabilité/un coût croissants) : +Considérez les suites comme un « réalisme croissant » (et une fragilité/un coût croissants) : ### Unitaire / intégration (par défaut) - Commande : `pnpm test` -- Configuration : dix exécutions séquentielles de fragments (`vitest.full-*.config.ts`) sur les projets Vitest ciblés existants -- Fichiers : inventaires core/unit sous `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts`, ainsi que les tests Node `ui` sur liste blanche couverts par `vitest.unit.config.ts` -- Périmètre : +- Configuration : dix exécutions de fragments séquentielles (`vitest.full-*.config.ts`) sur les projets Vitest ciblés existants +- Fichiers : inventaires core/unit sous `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts`, et les tests node `ui` autorisés couverts par `vitest.unit.config.ts` +- Portée : - Tests unitaires purs - Tests d’intégration en processus (auth Gateway, routage, outillage, parsing, configuration) - Régressions déterministes pour des bugs connus - Attentes : - - S’exécute en CI + - S’exécute dans CI - Aucune vraie clé requise - Doit être rapide et stable - Note sur les projets : - - `pnpm test` sans ciblage exécute désormais onze configurations fragmentées plus petites (`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`) au lieu d’un seul énorme processus de projet racine natif. Cela réduit le pic de RSS sur les machines chargées et évite que le travail auto-reply/extension n’affame les suites sans rapport. + - `pnpm test` sans ciblage exécute maintenant onze petites configurations fragmentées (`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`) au lieu d’un seul énorme processus projet-racine natif. Cela réduit le pic de RSS sur les machines chargées et évite que le travail auto-reply/extension n’affame les suites non liées. - `pnpm test --watch` utilise toujours le graphe de projets racine natif `vitest.config.ts`, car une boucle de surveillance multi-fragments n’est pas pratique. - - `pnpm test`, `pnpm test:watch` et `pnpm test:perf:imports` font passer en priorité les cibles de fichier/répertoire explicites par des voies ciblées, de sorte que `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` évite le coût de démarrage complet du projet racine. - - `pnpm test:changed` étend les chemins git modifiés vers ces mêmes voies ciblées lorsque le diff ne touche que des fichiers source/test routables ; les modifications de configuration/setup reviennent toujours à une relance large du projet racine. - - Les tests unitaires légers en importation provenant de agents, commands, plugins, des assistants auto-reply, de `plugin-sdk` et de zones utilitaires pures similaires passent par la voie `unit-fast`, qui ignore `test/setup-openclaw-runtime.ts` ; les fichiers riches en état ou lourds à l’exécution restent sur les voies existantes. - - Certains fichiers source assistants `plugin-sdk` et `commands` sélectionnés mappent aussi les exécutions en mode changed vers des tests voisins explicites dans ces voies légères, afin que les modifications d’assistants évitent de relancer toute la suite lourde pour ce répertoire. - - `auto-reply` dispose désormais de trois compartiments dédiés : les assistants core de premier niveau, les tests d’intégration `reply.*` de premier niveau, et le sous-arbre `src/auto-reply/reply/**`. Cela garde le travail le plus lourd du harnais reply hors des tests peu coûteux de statut/chunk/token. + - `pnpm test`, `pnpm test:watch`, et `pnpm test:perf:imports` font passer en priorité les cibles explicites de fichier/répertoire par des voies ciblées, donc `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` évite de payer le coût de démarrage complet du projet racine. + - `pnpm test:changed` étend les chemins git modifiés vers ces mêmes voies ciblées quand le diff ne touche que des fichiers source/test routables ; les modifications de config/setup reviennent toujours à une relance large du projet racine. + - Les tests unitaires légers à l’import depuis agents, commands, plugins, aides auto-reply, `plugin-sdk`, et zones utilitaires pures similaires passent par la voie `unit-fast`, qui ignore `test/setup-openclaw-runtime.ts` ; les fichiers stateful/lourds à l’exécution restent sur les voies existantes. + - Certains fichiers source utilitaires `plugin-sdk` et `commands` sélectionnés font aussi correspondre les exécutions en mode changed à des tests frères explicites dans ces voies légères, afin que les modifications d’aides évitent de relancer toute la suite lourde pour ce répertoire. + - `auto-reply` a maintenant trois compartiments dédiés : aides core de premier niveau, tests d’intégration `reply.*` de premier niveau, et le sous-arbre `src/auto-reply/reply/**`. Cela garde le travail de harnais de réponse le plus lourd à l’écart des tests bon marché de statut/bloc/token. - Note sur l’exécuteur embarqué : - - Lorsque vous modifiez les entrées de découverte des outils de message ou le contexte d’exécution de Compaction, + - Quand vous modifiez les entrées de découverte des outils de message ou le contexte d’exécution de Compaction, conservez les deux niveaux de couverture. - - Ajoutez des régressions d’assistants ciblées pour les limites pures de routage/normalisation. - - Conservez aussi en bon état les suites d’intégration de l’exécuteur embarqué : + - Ajoutez des régressions d’aides ciblées pour les frontières pures de routage/normalisation. + - Gardez également saines les suites d’intégration de l’exécuteur embarqué : `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts`, et `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Ces suites vérifient que les ids ciblés et le comportement de Compaction continuent - de circuler à travers les vrais chemins `run.ts` / `compact.ts` ; des tests d’assistants seuls ne constituent pas + - Ces suites vérifient que les identifiants ciblés et le comportement de Compaction passent toujours + par les vrais chemins `run.ts` / `compact.ts` ; des tests d’aides seuls ne sont pas un substitut suffisant à ces chemins d’intégration. - Note sur le pool : - - La configuration Vitest de base utilise maintenant `threads` par défaut. - - La configuration Vitest partagée fixe aussi `isolate: false` et utilise l’exécuteur non isolé à travers les projets racine, les configurations e2e et live. - - La voie UI racine conserve sa configuration `jsdom` et son optimiseur, mais s’exécute maintenant elle aussi sur l’exécuteur partagé non isolé. + - La configuration Vitest de base utilise désormais `threads` par défaut. + - La configuration Vitest partagée fixe aussi `isolate: false` et utilise l’exécuteur non isolé sur les projets racine, e2e et live. + - La voie UI racine conserve sa configuration `jsdom` et son optimiseur, mais s’exécute désormais aussi sur l’exécuteur partagé non isolé. - Chaque fragment `pnpm test` hérite des mêmes valeurs par défaut `threads` + `isolate: false` depuis la configuration Vitest partagée. - - Le lanceur partagé `scripts/run-vitest.mjs` ajoute désormais aussi `--no-maglev` par défaut aux processus Node enfants de Vitest afin de réduire le churn de compilation V8 pendant les grosses exécutions locales. Définissez `OPENCLAW_VITEST_ENABLE_MAGLEV=1` si vous devez comparer avec le comportement V8 standard. + - Le lanceur partagé `scripts/run-vitest.mjs` ajoute maintenant aussi `--no-maglev` par défaut pour les processus enfant Node de Vitest afin de réduire l’agitation de compilation V8 pendant les grosses exécutions locales. Définissez `OPENCLAW_VITEST_ENABLE_MAGLEV=1` si vous devez comparer avec le comportement V8 standard. - Note sur l’itération locale rapide : - - `pnpm test:changed` passe par des voies ciblées lorsque les chemins modifiés se mappent proprement à une suite plus petite. + - `pnpm test:changed` passe par des voies ciblées lorsque les chemins modifiés correspondent proprement à une suite plus petite. - `pnpm test:max` et `pnpm test:changed:max` conservent le même comportement de routage, simplement avec une limite de workers plus élevée. - - L’auto-dimensionnement local des workers est désormais volontairement conservateur et réduit aussi la charge quand la moyenne de charge de l’hôte est déjà élevée, de sorte que plusieurs exécutions Vitest simultanées fassent moins de dégâts par défaut. - - La configuration Vitest de base marque les projets/fichiers de configuration comme `forceRerunTriggers` afin que les relances en mode changed restent correctes lorsque le câblage des tests change. - - La configuration garde `OPENCLAW_VITEST_FS_MODULE_CACHE` activé sur les hôtes pris en charge ; définissez `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path` si vous souhaitez un emplacement de cache explicite pour le profilage direct. + - L’auto-dimensionnement local des workers est maintenant volontairement conservateur et réduit aussi la charge quand la moyenne de charge de l’hôte est déjà élevée, afin que plusieurs exécutions Vitest concurrentes fassent moins de dégâts par défaut. + - La configuration Vitest de base marque les fichiers de projet/configuration comme `forceRerunTriggers` afin que les relances en mode changed restent correctes quand le câblage des tests change. + - La configuration garde `OPENCLAW_VITEST_FS_MODULE_CACHE` activé sur les hôtes pris en charge ; définissez `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path` si vous voulez un emplacement de cache explicite pour du profilage direct. - Note de débogage des performances : - - `pnpm test:perf:imports` active le rapport de durée d’importation Vitest ainsi qu’une sortie de détail des importations. - - `pnpm test:perf:imports:changed` limite cette même vue de profilage aux fichiers modifiés depuis `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` compare `test:changed` routé au chemin natif du projet racine pour ce diff validé et affiche le temps mur ainsi que le RSS max macOS. -- `pnpm test:perf:changed:bench -- --worktree` mesure l’arbre de travail modifié actuel en faisant passer la liste des fichiers modifiés par `scripts/test-projects.mjs` et la configuration Vitest racine. - - `pnpm test:perf:profile:main` écrit un profil CPU du thread principal pour le démarrage de Vitest/Vite et la surcharge de transformation. - - `pnpm test:perf:profile:runner` écrit des profils CPU+heap de l’exécuteur pour la suite unitaire avec le parallélisme de fichiers désactivé. + - `pnpm test:perf:imports` active les rapports de durée d’import Vitest ainsi qu’une sortie détaillée des imports. + - `pnpm test:perf:imports:changed` applique cette même vue de profilage aux fichiers modifiés depuis `origin/main`. +- `pnpm test:perf:changed:bench -- --ref ` compare `test:changed` routé avec le chemin natif projet-racine pour ce diff validé et affiche le temps mur ainsi que le RSS max macOS. +- `pnpm test:perf:changed:bench -- --worktree` mesure l’arbre de travail courant en faisant passer la liste des fichiers modifiés par `scripts/test-projects.mjs` et la configuration Vitest racine. + - `pnpm test:perf:profile:main` écrit un profil CPU du thread principal pour les coûts de démarrage et de transformation Vitest/Vite. + - `pnpm test:perf:profile:runner` écrit des profils CPU+tas de l’exécuteur pour la suite unitaire avec le parallélisme de fichiers désactivé. ### E2E (smoke Gateway) - Commande : `pnpm test:e2e` - Configuration : `vitest.e2e.config.ts` - Fichiers : `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` -- Valeurs par défaut à l’exécution : - - Utilise les `threads` Vitest avec `isolate: false`, comme le reste du dépôt. +- Valeurs d’exécution par défaut : + - Utilise `threads` de Vitest avec `isolate: false`, comme le reste du dépôt. - Utilise des workers adaptatifs (CI : jusqu’à 2, local : 1 par défaut). - - S’exécute en mode silencieux par défaut pour réduire la surcharge d’E/S console. + - S’exécute en mode silencieux par défaut pour réduire le coût des E/S console. - Remplacements utiles : - `OPENCLAW_E2E_WORKERS=` pour forcer le nombre de workers (plafonné à 16). - `OPENCLAW_E2E_VERBOSE=1` pour réactiver la sortie console détaillée. -- Périmètre : - - Comportement end-to-end Gateway multi-instances +- Portée : + - Comportement end-to-end Gateway multi-instance - Surfaces WebSocket/HTTP, appairage de nœuds et réseau plus lourd - Attentes : - - S’exécute en CI (quand activé dans le pipeline) + - S’exécute dans CI (lorsqu’activé dans le pipeline) - Aucune vraie clé requise - - Plus d’éléments mobiles que les tests unitaires (peut être plus lent) + - Plus de pièces mobiles que les tests unitaires (peut être plus lent) ### E2E : smoke du backend OpenShell - Commande : `pnpm test:e2e:openshell` - Fichier : `test/openshell-sandbox.e2e.test.ts` -- Périmètre : - - Démarre sur l’hôte une Gateway OpenShell isolée via Docker - - Crée un bac à sable à partir d’un Dockerfile local temporaire - - Exerce le backend OpenShell d’OpenClaw via un vrai `sandbox ssh-config` + exécution SSH - - Vérifie le comportement canonique du système de fichiers distant via le pont fs du bac à sable +- Portée : + - Démarre un Gateway OpenShell isolé sur l’hôte via Docker + - Crée un sandbox à partir d’un Dockerfile local temporaire + - Exerce le backend OpenShell d’OpenClaw via de vrais `sandbox ssh-config` + exécution SSH + - Vérifie le comportement du système de fichiers canonique distant via le pont fs du sandbox - Attentes : - - Sur activation explicite uniquement ; ne fait pas partie de l’exécution par défaut `pnpm test:e2e` - - Nécessite un CLI local `openshell` ainsi qu’un démon Docker fonctionnel - - Utilise un `HOME` / `XDG_CONFIG_HOME` isolé, puis détruit la Gateway de test et le bac à sable + - Opt-in uniquement ; ne fait pas partie de l’exécution par défaut `pnpm test:e2e` + - Nécessite une CLI `openshell` locale ainsi qu’un démon Docker fonctionnel + - Utilise `HOME` / `XDG_CONFIG_HOME` isolés, puis détruit le Gateway de test et le sandbox - Remplacements utiles : - `OPENCLAW_E2E_OPENSHELL=1` pour activer le test lors de l’exécution manuelle de la suite e2e plus large - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` pour pointer vers un binaire CLI non par défaut ou un script wrapper + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` pour pointer vers un binaire CLI non standard ou un script wrapper ### Live (vrais fournisseurs + vrais modèles) @@ -342,21 +342,21 @@ Considérez les suites comme un « réalisme croissant » (et une instabilité - Configuration : `vitest.live.config.ts` - Fichiers : `src/**/*.live.test.ts` - Par défaut : **activé** par `pnpm test:live` (définit `OPENCLAW_LIVE_TEST=1`) -- Périmètre : - - « Est-ce que ce fournisseur/modèle fonctionne réellement _aujourd’hui_ avec de vrais identifiants ? » - - Détecter les changements de format fournisseur, les particularités d’appel d’outil, les problèmes d’authentification et le comportement face aux limites de débit +- Portée : + - « Est-ce que ce fournisseur/modèle fonctionne vraiment _aujourd’hui_ avec de vrais identifiants ? » + - Détecter les changements de format de fournisseur, les particularités d’appel d’outils, les problèmes d’authentification et le comportement de limite de débit - Attentes : - - Pas stable en CI par conception (vrais réseaux, vraies politiques fournisseur, quotas, pannes) + - Pas stable pour CI par conception (vrais réseaux, vraies politiques de fournisseur, quotas, pannes) - Coûte de l’argent / consomme des limites de débit - Préférez exécuter des sous-ensembles restreints plutôt que « tout » - Les exécutions live chargent `~/.profile` pour récupérer les clés API manquantes. -- Par défaut, les exécutions live isolent toujours `HOME` et copient le matériel de configuration/auth dans un home de test temporaire afin que les fixtures unitaires ne puissent pas modifier votre vrai `~/.openclaw`. -- Définissez `OPENCLAW_LIVE_USE_REAL_HOME=1` uniquement si vous avez intentionnellement besoin que les tests live utilisent votre vrai répertoire home. -- `pnpm test:live` passe désormais par défaut dans un mode plus silencieux : il conserve la sortie de progression `[live] ...`, mais supprime la notification supplémentaire `~/.profile` et coupe les journaux de démarrage Gateway / le bruit Bonjour. Définissez `OPENCLAW_LIVE_TEST_QUIET=0` si vous souhaitez récupérer les journaux complets de démarrage. -- Rotation de clés API (spécifique au fournisseur) : définissez `*_API_KEYS` avec un format virgule/point-virgule ou `*_API_KEY_1`, `*_API_KEY_2` (par exemple `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) ou un remplacement par live via `OPENCLAW_LIVE_*_KEY` ; les tests réessaient sur les réponses de limitation de débit. +- Par défaut, les exécutions live isolent toujours `HOME` et copient les éléments de configuration/authentification dans un home de test temporaire afin que les fixtures unitaires ne puissent pas modifier votre vrai `~/.openclaw`. +- Définissez `OPENCLAW_LIVE_USE_REAL_HOME=1` uniquement lorsque vous avez intentionnellement besoin que les tests live utilisent votre vrai répertoire home. +- `pnpm test:live` utilise maintenant par défaut un mode plus discret : il conserve la sortie de progression `[live] ...`, mais masque l’avis supplémentaire `~/.profile` et coupe les logs de bootstrap Gateway / le bruit Bonjour. Définissez `OPENCLAW_LIVE_TEST_QUIET=0` si vous voulez récupérer les logs complets de démarrage. +- Rotation des clés API (spécifique au fournisseur) : définissez `*_API_KEYS` avec un format virgule/point-virgule ou `*_API_KEY_1`, `*_API_KEY_2` (par exemple `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) ou un remplacement par live via `OPENCLAW_LIVE_*_KEY` ; les tests réessaient sur les réponses de limitation de débit. - Sortie de progression/Heartbeat : - - Les suites live émettent désormais des lignes de progression vers stderr afin que les longs appels fournisseur restent visiblement actifs même lorsque la capture console de Vitest est silencieuse. - - `vitest.live.config.ts` désactive l’interception de console Vitest afin que les lignes de progression fournisseur/Gateway soient diffusées immédiatement pendant les exécutions live. + - Les suites live émettent maintenant des lignes de progression vers stderr afin que les longs appels fournisseur soient visiblement actifs même lorsque la capture console Vitest est silencieuse. + - `vitest.live.config.ts` désactive l’interception console de Vitest afin que les lignes de progression fournisseur/Gateway soient diffusées immédiatement pendant les exécutions live. - Ajustez les Heartbeat de modèle direct avec `OPENCLAW_LIVE_HEARTBEAT_MS`. - Ajustez les Heartbeat Gateway/sonde avec `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. @@ -366,31 +366,31 @@ Utilisez ce tableau de décision : - Modification de logique/tests : exécutez `pnpm test` (et `pnpm test:coverage` si vous avez beaucoup modifié) - Modification du réseau Gateway / du protocole WS / de l’appairage : ajoutez `pnpm test:e2e` -- Débogage de « mon bot est hors service » / échecs spécifiques à un fournisseur / appel d’outil : exécutez un `pnpm test:live` restreint +- Débogage de « mon bot est en panne » / d’échecs spécifiques au fournisseur / d’appels d’outils : exécutez un `pnpm test:live` restreint -## Live : balayage des capacités de nœud Android +## Live : balayage des capacités du nœud Android - Test : `src/gateway/android-node.capabilities.live.test.ts` - Script : `pnpm android:test:integration` - Objectif : invoquer **chaque commande actuellement annoncée** par un nœud Android connecté et vérifier le comportement du contrat de commande. -- Périmètre : +- Portée : - Configuration préalable/manuelle (la suite n’installe pas, n’exécute pas et n’appaire pas l’application). - - Validation `node.invoke` Gateway commande par commande pour le nœud Android sélectionné. + - Validation Gateway `node.invoke` commande par commande pour le nœud Android sélectionné. - Préconfiguration requise : - - Application Android déjà connectée et appairée à la Gateway. + - Application Android déjà connectée et appairée à Gateway. - Application maintenue au premier plan. - - Permissions/consentements de capture accordés pour les capacités que vous attendez de voir réussir. -- Remplacements facultatifs de cible : + - Permissions/consentement de capture accordés pour les capacités que vous attendez de voir réussir. +- Remplacements de cible facultatifs : - `OPENCLAW_ANDROID_NODE_ID` ou `OPENCLAW_ANDROID_NODE_NAME`. - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`. -- Détails complets de la configuration Android : [Application Android](/fr/platforms/android) +- Détails complets de configuration Android : [Application Android](/fr/platforms/android) -## Live : smoke de modèle (clés de profil) +## Live : smoke des modèles (clés de profil) -Les tests live sont divisés en deux couches afin que nous puissions isoler les défaillances : +Les tests live sont divisés en deux couches afin d’isoler les échecs : -- Le « modèle direct » nous indique si le fournisseur/modèle peut répondre tout court avec la clé donnée. -- Le « smoke Gateway » nous indique si le pipeline complet gateway+agent fonctionne pour ce modèle (sessions, historique, outils, politique de bac à sable, etc.). +- « Modèle direct » nous indique si le fournisseur/modèle peut répondre tout court avec la clé donnée. +- « Smoke Gateway » nous indique si le pipeline complet Gateway+agent fonctionne pour ce modèle (sessions, historique, outils, politique sandbox, etc.). ### Couche 1 : complétion de modèle directe (sans Gateway) @@ -401,36 +401,36 @@ Les tests live sont divisés en deux couches afin que nous puissions isoler les - Exécuter une petite complétion par modèle (et des régressions ciblées si nécessaire) - Comment l’activer : - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement) -- Définissez `OPENCLAW_LIVE_MODELS=modern` (ou `all`, alias de modern) pour réellement exécuter cette suite ; sinon elle est ignorée afin de garder `pnpm test:live` centré sur le smoke Gateway +- Définissez `OPENCLAW_LIVE_MODELS=modern` (ou `all`, alias de modern) pour exécuter réellement cette suite ; sinon elle est ignorée afin de garder `pnpm test:live` centré sur le smoke Gateway - Comment sélectionner les modèles : - `OPENCLAW_LIVE_MODELS=modern` pour exécuter la liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - `OPENCLAW_LIVE_MODELS=all` est un alias de la liste d’autorisation moderne - ou `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (liste d’autorisation séparée par des virgules) - - Les balayages modern/all appliquent par défaut un plafond sélectionné de haute valeur informative ; définissez `OPENCLAW_LIVE_MAX_MODELS=0` pour un balayage moderne exhaustif ou une valeur positive pour un plafond plus petit. + - Les balayages modern/all utilisent par défaut une limite sélectionnée à fort signal ; définissez `OPENCLAW_LIVE_MAX_MODELS=0` pour un balayage modern exhaustif ou une valeur positive pour une limite plus petite. - Comment sélectionner les fournisseurs : - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (liste d’autorisation séparée par des virgules) - D’où viennent les clés : - - Par défaut : stockage de profils et replis via l’environnement - - Définissez `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer **uniquement** le stockage de profils + - Par défaut : magasin de profils et replis environnementaux + - Définissez `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer **uniquement le magasin de profils** - Pourquoi cela existe : - - Sépare « l’API fournisseur est cassée / la clé est invalide » de « le pipeline agent Gateway est cassé » - - Contient de petites régressions isolées (exemple : replay de raisonnement OpenAI Responses/Codex Responses + flux d’appels d’outils) + - Sépare « l’API fournisseur est cassée / la clé est invalide » de « le pipeline d’agent Gateway est cassé » + - Contient de petites régressions isolées (exemple : rejouage du raisonnement OpenAI Responses/Codex Responses + flux d’appels d’outils) -### Couche 2 : smoke Gateway + agent dev (ce que fait réellement "@openclaw") +### Couche 2 : smoke Gateway + agent de développement (ce que fait réellement "@openclaw") - Test : `src/gateway/gateway-models.profiles.live.test.ts` - Objectif : - - Démarrer une Gateway en processus - - Créer/patcher une session `agent:dev:*` (remplacement de modèle à chaque exécution) + - Démarrer un Gateway en processus + - Créer/modifier une session `agent:dev:*` (remplacement de modèle par exécution) - Itérer sur les modèles avec clés et vérifier : - - une réponse « significative » (sans outils) - - le fonctionnement d’une véritable invocation d’outil (sonde de lecture) - - des sondes d’outil supplémentaires facultatives (sonde exec+read) - - le bon fonctionnement continu des chemins de régression OpenAI (appel d’outil seul → suivi) + - réponse « pertinente » (sans outils) + - le fonctionnement d’une vraie invocation d’outil (sonde de lecture) + - des sondes d’outils supplémentaires facultatives (sonde exec+lecture) + - que les chemins de régression OpenAI (appel d’outil seul → suivi) continuent de fonctionner - Détails des sondes (pour pouvoir expliquer rapidement les échecs) : - sonde `read` : le test écrit un fichier nonce dans l’espace de travail et demande à l’agent de le `read` puis de renvoyer le nonce. - - sonde `exec+read` : le test demande à l’agent d’écrire un nonce dans un fichier temporaire via `exec`, puis de le relire avec `read`. - - sonde d’image : le test joint un PNG généré (chat + code aléatoire) et attend que le modèle renvoie `cat `. + - sonde `exec+read` : le test demande à l’agent d’écrire un nonce dans un fichier temporaire via `exec`, puis de le relire via `read`. + - sonde d’image : le test joint un PNG généré (chat + code aléatoire) et attend du modèle qu’il renvoie `cat `. - Référence d’implémentation : `src/gateway/gateway-models.profiles.live.test.ts` et `src/gateway/live-image-probe.ts`. - Comment l’activer : - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement) @@ -438,46 +438,46 @@ Les tests live sont divisés en deux couches afin que nous puissions isoler les - Par défaut : liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - `OPENCLAW_LIVE_GATEWAY_MODELS=all` est un alias de la liste d’autorisation moderne - Ou définissez `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (ou une liste séparée par des virgules) pour restreindre - - Les balayages Gateway modern/all appliquent par défaut un plafond sélectionné de haute valeur informative ; définissez `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` pour un balayage moderne exhaustif ou une valeur positive pour un plafond plus petit. -- Comment sélectionner les fournisseurs (éviter « OpenRouter partout ») : + - Les balayages Gateway modern/all utilisent par défaut une limite sélectionnée à fort signal ; définissez `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` pour un balayage moderne exhaustif ou une valeur positive pour une limite plus petite. +- Comment sélectionner les fournisseurs (éviter « tout OpenRouter ») : - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (liste d’autorisation séparée par des virgules) -- Les sondes d’outil + image sont toujours actives dans ce test live : +- Les sondes d’outil + d’image sont toujours activées dans ce test live : - sonde `read` + sonde `exec+read` (stress des outils) - - la sonde d’image s’exécute quand le modèle annonce la prise en charge d’entrée d’image + - la sonde d’image s’exécute quand le modèle annonce la prise en charge de l’entrée image - Flux (vue d’ensemble) : - - Le test génère un petit PNG avec « CAT » + code aléatoire (`src/gateway/live-image-probe.ts`) + - Le test génère un petit PNG avec « CAT » + un code aléatoire (`src/gateway/live-image-probe.ts`) - L’envoie via `agent` `attachments: [{ mimeType: "image/png", content: "" }]` - - Gateway analyse les pièces jointes dans `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) + - Gateway parse les pièces jointes dans `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) - L’agent embarqué transmet au modèle un message utilisateur multimodal - - Vérification : la réponse contient `cat` + le code (tolérance OCR : erreurs mineures autorisées) + - Vérification : la réponse contient `cat` + le code (tolérance OCR : de petites erreurs sont autorisées) -Astuce : pour voir ce que vous pouvez tester sur votre machine (et les ids exacts `provider/model`), exécutez : +Astuce : pour voir ce que vous pouvez tester sur votre machine (et les identifiants exacts `provider/model`), exécutez : ```bash openclaw models list openclaw models list --json ``` -## Live : smoke du backend CLI (Claude, Codex, Gemini ou autres CLI locaux) +## Live : smoke du backend CLI (Claude, Codex, Gemini, ou autres CLI locales) - Test : `src/gateway/gateway-cli-backend.live.test.ts` - Objectif : valider le pipeline Gateway + agent à l’aide d’un backend CLI local, sans toucher à votre configuration par défaut. -- Les valeurs par défaut du smoke spécifiques au backend se trouvent dans la définition `cli-backend.ts` de l’extension propriétaire. +- Les valeurs par défaut de smoke spécifiques au backend se trouvent dans la définition `cli-backend.ts` de l’extension propriétaire. - Activer : - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement) - `OPENCLAW_LIVE_CLI_BACKEND=1` - Valeurs par défaut : - Fournisseur/modèle par défaut : `claude-cli/claude-sonnet-4-6` - - Le comportement de commande/arguments/image provient des métadonnées du Plugin backend CLI propriétaire. + - Le comportement commande/arguments/image provient des métadonnées du plugin backend CLI propriétaire. - Remplacements facultatifs : - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"` - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"` - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'` - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` pour envoyer une vraie image en pièce jointe (les chemins sont injectés dans le prompt). - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` pour passer les chemins des fichiers image comme arguments CLI au lieu de les injecter dans le prompt. - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (ou `"list"`) pour contrôler la manière dont les arguments image sont passés lorsque `IMAGE_ARG` est défini. - - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` pour envoyer un second tour et valider le flux de reprise. - - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0` pour désactiver la sonde par défaut de continuité dans une même session Claude Sonnet -> Opus (définissez `1` pour la forcer quand le modèle sélectionné prend en charge une cible de bascule). + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` pour envoyer une vraie pièce jointe image (les chemins sont injectés dans le prompt). + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` pour transmettre les chemins de fichier image comme arguments CLI au lieu de l’injection dans le prompt. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (ou `"list"`) pour contrôler comment les arguments image sont transmis lorsque `IMAGE_ARG` est défini. + - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` pour envoyer un deuxième tour et valider le flux de reprise. + - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0` pour désactiver la sonde par défaut de continuité de même session Claude Sonnet -> Opus (définissez `1` pour la forcer lorsque le modèle sélectionné prend en charge une cible de bascule). Exemple : @@ -493,7 +493,7 @@ Recette Docker : pnpm test:docker:live-cli-backend ``` -Recettes Docker par fournisseur unique : +Recettes Docker à fournisseur unique : ```bash pnpm test:docker:live-cli-backend:claude @@ -502,21 +502,21 @@ pnpm test:docker:live-cli-backend:codex pnpm test:docker:live-cli-backend:gemini ``` -Remarques : +Notes : - L’exécuteur Docker se trouve dans `scripts/test-live-cli-backend-docker.sh`. - Il exécute le smoke live du backend CLI dans l’image Docker du dépôt en tant qu’utilisateur `node` non root. -- Il résout les métadonnées du smoke CLI depuis l’extension propriétaire, puis installe le paquet CLI Linux correspondant (`@anthropic-ai/claude-code`, `@openai/codex` ou `@google/gemini-cli`) dans un préfixe inscriptible mis en cache à `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (par défaut : `~/.cache/openclaw/docker-cli-tools`). -- `pnpm test:docker:live-cli-backend:claude-subscription` nécessite une authentification OAuth d’abonnement Claude Code portable via soit `~/.claude/.credentials.json` avec `claudeAiOauth.subscriptionType`, soit `CLAUDE_CODE_OAUTH_TOKEN` depuis `claude setup-token`. Il vérifie d’abord `claude -p` direct dans Docker, puis exécute deux tours Gateway backend CLI sans conserver les variables d’environnement de clé API Anthropic. Cette voie d’abonnement désactive par défaut les sondes Claude MCP/outil et image, car Claude route actuellement l’usage d’applications tierces via une facturation d’usage supplémentaire plutôt que via les limites normales du plan d’abonnement. -- Le smoke live du backend CLI exerce désormais le même flux end-to-end pour Claude, Codex et Gemini : tour texte, tour de classification d’image, puis appel de l’outil MCP `cron` vérifié via le CLI Gateway. -- Le smoke par défaut de Claude patche aussi la session de Sonnet vers Opus et vérifie que la session reprise se souvient toujours d’une note antérieure. +- Il résout les métadonnées de smoke CLI depuis l’extension propriétaire, puis installe le paquet CLI Linux correspondant (`@anthropic-ai/claude-code`, `@openai/codex`, ou `@google/gemini-cli`) dans un préfixe inscriptible en cache à `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (par défaut : `~/.cache/openclaw/docker-cli-tools`). +- `pnpm test:docker:live-cli-backend:claude-subscription` nécessite une authentification OAuth portable à l’abonnement Claude Code via soit `~/.claude/.credentials.json` avec `claudeAiOauth.subscriptionType`, soit `CLAUDE_CODE_OAUTH_TOKEN` depuis `claude setup-token`. Il prouve d’abord `claude -p` direct dans Docker, puis exécute deux tours Gateway backend CLI sans conserver les variables d’environnement de clé API Anthropic. Cette voie d’abonnement désactive par défaut l’outil Claude MCP et les sondes d’image, car Claude route actuellement l’usage d’applications tierces via une facturation d’usage supplémentaire plutôt que via les limites normales du plan d’abonnement. +- Le smoke live du backend CLI exerce maintenant le même flux end-to-end pour Claude, Codex et Gemini : tour texte, tour de classification d’image, puis appel d’outil MCP `cron` vérifié via la CLI Gateway. +- Le smoke par défaut de Claude modifie aussi la session de Sonnet vers Opus et vérifie que la session reprise se souvient toujours d’une note antérieure. -## Live : smoke ACP bind (`/acp spawn ... --bind here`) +## Live : smoke de liaison ACP (`/acp spawn ... --bind here`) - Test : `src/gateway/gateway-acp-bind.live.test.ts` - Objectif : valider le vrai flux de liaison de conversation ACP avec un agent ACP live : - envoyer `/acp spawn --bind here` - - lier en place une conversation synthétique de canal de messages + - lier sur place une conversation synthétique de canal de messages - envoyer un suivi normal sur cette même conversation - vérifier que le suivi arrive dans la transcription de session ACP liée - Activer : @@ -525,7 +525,7 @@ Remarques : - Valeurs par défaut : - Agents ACP dans Docker : `claude,codex,gemini` - Agent ACP pour `pnpm test:live ...` direct : `claude` - - Canal synthétique : contexte de conversation de type DM Slack + - Canal synthétique : contexte de conversation de type message privé Slack - Backend ACP : `acpx` - Remplacements : - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude` @@ -533,9 +533,9 @@ Remarques : - `OPENCLAW_LIVE_ACP_BIND_AGENT=gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@'` -- Remarques : - - Cette voie utilise la surface Gateway `chat.send` avec des champs synthétiques de route d’origine réservés à l’administration afin que les tests puissent attacher un contexte de canal de messages sans prétendre livrer à l’extérieur. - - Quand `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` n’est pas défini, le test utilise le registre intégré d’agents du Plugin `acpx` embarqué pour l’agent de harnais ACP sélectionné. +- Notes : + - Cette voie utilise la surface Gateway `chat.send` avec des champs `originating-route` synthétiques réservés à l’administrateur afin que les tests puissent attacher un contexte de canal de messages sans prétendre effectuer une livraison externe. + - Quand `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` n’est pas défini, le test utilise le registre d’agents intégré du plugin `acpx` embarqué pour l’agent de harnais ACP sélectionné. Exemple : @@ -551,7 +551,7 @@ Recette Docker : pnpm test:docker:live-acp-bind ``` -Recettes Docker par agent unique : +Recettes Docker à agent unique : ```bash pnpm test:docker:live-acp-bind:claude @@ -559,22 +559,22 @@ pnpm test:docker:live-acp-bind:codex pnpm test:docker:live-acp-bind:gemini ``` -Remarques Docker : +Notes Docker : - L’exécuteur Docker se trouve dans `scripts/test-live-acp-bind-docker.sh`. -- Par défaut, il exécute séquentiellement le smoke ACP bind sur tous les agents CLI live pris en charge : `claude`, `codex`, puis `gemini`. -- Utilisez `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` ou `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` pour restreindre la matrice. -- Il charge `~/.profile`, prépare dans le conteneur le matériel d’authentification CLI correspondant, installe `acpx` dans un préfixe npm inscriptible, puis installe le CLI live demandé (`@anthropic-ai/claude-code`, `@openai/codex` ou `@google/gemini-cli`) s’il manque. -- Dans Docker, l’exécuteur définit `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx` afin que acpx conserve pour le CLI enfant du harnais les variables d’environnement du fournisseur issues du profil chargé. +- Par défaut, il exécute le smoke de liaison ACP contre tous les agents CLI live pris en charge en séquence : `claude`, `codex`, puis `gemini`. +- Utilisez `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex`, ou `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` pour restreindre la matrice. +- Il charge `~/.profile`, prépare le matériel d’authentification CLI correspondant dans le conteneur, installe `acpx` dans un préfixe npm inscriptible, puis installe la CLI live demandée (`@anthropic-ai/claude-code`, `@openai/codex`, ou `@google/gemini-cli`) si elle est absente. +- Dans Docker, l’exécuteur définit `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx` afin que acpx conserve les variables d’environnement fournisseur du profil chargé disponibles pour la CLI harnais enfant. ## Live : smoke du harnais app-server Codex -- Objectif : valider le harnais Codex détenu par le Plugin via la méthode Gateway - `agent` normale : - - charger le Plugin `codex` embarqué +- Objectif : valider le harnais Codex appartenant au plugin via la méthode + Gateway `agent` normale : + - charger le plugin `codex` intégré - sélectionner `OPENCLAW_AGENT_RUNTIME=codex` - - envoyer un premier tour d’agent Gateway à `codex/gpt-5.4` - - envoyer un second tour à la même session OpenClaw et vérifier que le fil + - envoyer un premier tour d’agent Gateway vers `codex/gpt-5.4` + - envoyer un deuxième tour à la même session OpenClaw et vérifier que le fil app-server peut reprendre - exécuter `/codex status` et `/codex models` via le même chemin de commande Gateway @@ -583,9 +583,9 @@ Remarques Docker : - Modèle par défaut : `codex/gpt-5.4` - Sonde d’image facultative : `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` - Sonde MCP/outil facultative : `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` -- Le smoke définit `OPENCLAW_AGENT_HARNESS_FALLBACK=none` afin qu’un harnais Codex cassé - ne puisse pas réussir en revenant silencieusement sur PI. -- Auth : `OPENAI_API_KEY` depuis le shell/profil, plus éventuelle copie de +- Le smoke définit `OPENCLAW_AGENT_HARNESS_FALLBACK=none` afin qu’un harnais Codex + cassé ne puisse pas réussir en retombant silencieusement sur PI. +- Authentification : `OPENAI_API_KEY` depuis le shell/profil, plus éventuelle copie de `~/.codex/auth.json` et `~/.codex/config.toml` Recette locale : @@ -606,20 +606,19 @@ source ~/.profile pnpm test:docker:live-codex-harness ``` -Remarques Docker : +Notes Docker : - L’exécuteur Docker se trouve dans `scripts/test-live-codex-harness-docker.sh`. -- Il charge le `~/.profile` monté, transmet `OPENAI_API_KEY`, copie les fichiers d’auth CLI Codex lorsqu’ils sont présents, installe `@openai/codex` dans un préfixe npm monté et inscriptible, prépare l’arborescence source, puis exécute uniquement le test live du harnais Codex. -- Docker active par défaut les sondes image et MCP/outil. Définissez +- Il charge le `~/.profile` monté, transmet `OPENAI_API_KEY`, copie les fichiers d’authentification CLI Codex lorsqu’ils sont présents, installe `@openai/codex` dans un préfixe npm monté inscriptible, prépare l’arbre source, puis n’exécute que le test live du harnais Codex. +- Docker active par défaut les sondes d’image et MCP/outil. Définissez `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` ou - `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` quand vous avez besoin d’une exécution de débogage plus restreinte. -- Docker exporte aussi `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, comme la - configuration de test live, afin que le fallback `openai-codex/*` ou PI ne puisse pas masquer une - régression du harnais Codex. + `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` lorsque vous avez besoin d’une exécution de débogage plus restreinte. +- Docker exporte aussi `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, conformément à la + configuration du test live afin que le repli `openai-codex/*` ou PI ne puisse pas masquer une régression du harnais Codex. ### Recettes live recommandées -Des listes d’autorisation étroites et explicites sont les plus rapides et les moins instables : +Les listes d’autorisation restreintes et explicites sont les plus rapides et les moins fragiles : - Modèle unique, direct (sans Gateway) : - `OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts` @@ -634,22 +633,22 @@ Des listes d’autorisation étroites et explicites sont les plus rapides et les - Gemini (clé API) : `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Antigravity (OAuth) : `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -Remarques : +Notes : - `google/...` utilise l’API Gemini (clé API). -- `google-antigravity/...` utilise le pont OAuth Antigravity (point de terminaison d’agent de type Cloud Code Assist). -- `google-gemini-cli/...` utilise le CLI Gemini local sur votre machine (authentification séparée + particularités d’outillage). +- `google-antigravity/...` utilise le pont OAuth Antigravity (point de terminaison d’agent de style Cloud Code Assist). +- `google-gemini-cli/...` utilise la CLI Gemini locale sur votre machine (authentification séparée + particularités d’outillage). - API Gemini vs CLI Gemini : - - API : OpenClaw appelle l’API Gemini hébergée par Google via HTTP (authentification par clé API / profil) ; c’est ce que la plupart des utilisateurs entendent par « Gemini ». - - CLI : OpenClaw exécute un binaire local `gemini` ; il dispose de sa propre authentification et peut se comporter différemment (streaming/prise en charge des outils/décalage de version). + - API : OpenClaw appelle l’API Gemini hébergée par Google via HTTP (clé API / authentification de profil) ; c’est ce que la plupart des utilisateurs veulent dire par « Gemini ». + - CLI : OpenClaw exécute un binaire `gemini` local ; il a sa propre authentification et peut se comporter différemment (streaming/prise en charge des outils/décalage de version). ## Live : matrice de modèles (ce que nous couvrons) -Il n’existe pas de « liste de modèles CI » fixe (le live est opt-in), mais voici les modèles **recommandés** à couvrir régulièrement sur une machine de développement avec des clés. +Il n’existe pas de « liste de modèles CI » fixe (le live est opt-in), mais voici les modèles **recommandés** à couvrir régulièrement sur une machine de développement disposant de clés. -### Ensemble smoke moderne (appel d’outils + image) +### Ensemble de smoke moderne (appel d’outils + image) -C’est l’exécution des « modèles courants » que nous attendons de maintenir fonctionnelle : +C’est l’exécution « modèles courants » que nous nous attendons à maintenir opérationnelle : - OpenAI (hors Codex) : `openai/gpt-5.4` (facultatif : `openai/gpt-5.4-mini`) - OpenAI Codex : `openai-codex/gpt-5.4` @@ -659,12 +658,12 @@ C’est l’exécution des « modèles courants » que nous attendons de maint - Z.AI (GLM) : `zai/glm-4.7` - MiniMax : `minimax/MiniMax-M2.7` -Exécuter le smoke Gateway avec outils + image : +Exécutez le smoke Gateway avec outils + image : `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,openai-codex/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -### Référence : appel d’outils (Read + Exec facultatif) +### Référence de base : appel d’outils (Read + Exec facultatif) -Choisissez-en au moins un par famille de fournisseurs : +Choisissez au moins un modèle par famille de fournisseurs : - OpenAI : `openai/gpt-5.4` (ou `openai/gpt-5.4-mini`) - Anthropic : `anthropic/claude-opus-4-6` (ou `anthropic/claude-sonnet-4-6`) @@ -672,7 +671,7 @@ Choisissez-en au moins un par famille de fournisseurs : - Z.AI (GLM) : `zai/glm-4.7` - MiniMax : `minimax/MiniMax-M2.7` -Couverture additionnelle facultative (agréable à avoir) : +Couverture facultative supplémentaire (souhaitable) : - xAI : `xai/grok-4` (ou la dernière version disponible) - Mistral : `mistral/`… (choisissez un modèle compatible « tools » que vous avez activé) @@ -681,72 +680,72 @@ Couverture additionnelle facultative (agréable à avoir) : ### Vision : envoi d’image (pièce jointe → message multimodal) -Incluez au moins un modèle compatible image dans `OPENCLAW_LIVE_GATEWAY_MODELS` (variants compatibles vision de Claude/Gemini/OpenAI, etc.) afin d’exercer la sonde d’image. +Incluez au moins un modèle compatible image dans `OPENCLAW_LIVE_GATEWAY_MODELS` (variantes Claude/Gemini/OpenAI compatibles vision, etc.) afin d’exercer la sonde d’image. ### Agrégateurs / passerelles alternatives -Si vous avez des clés activées, nous prenons aussi en charge les tests via : +Si vous avez les clés activées, nous prenons aussi en charge des tests via : -- OpenRouter : `openrouter/...` (des centaines de modèles ; utilisez `openclaw models scan` pour trouver des candidats compatibles outils+image) +- OpenRouter : `openrouter/...` (des centaines de modèles ; utilisez `openclaw models scan` pour trouver des candidats compatibles outil+image) - OpenCode : `opencode/...` pour Zen et `opencode-go/...` pour Go (authentification via `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) Autres fournisseurs que vous pouvez inclure dans la matrice live (si vous avez les identifiants/la configuration) : - Intégrés : `openai`, `openai-codex`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot` -- Via `models.providers` (points de terminaison personnalisés) : `minimax` (cloud/API), plus tout proxy compatible OpenAI/Anthropic (LM Studio, vLLM, LiteLLM, etc.) +- Via `models.providers` (points de terminaison personnalisés) : `minimax` (cloud/API), ainsi que tout proxy compatible OpenAI/Anthropic (LM Studio, vLLM, LiteLLM, etc.) -Astuce : n’essayez pas de coder en dur « tous les modèles » dans la documentation. La liste faisant autorité est ce que `discoverModels(...)` renvoie sur votre machine + les clés disponibles. +Astuce : n’essayez pas de coder en dur « tous les modèles » dans la documentation. La liste faisant autorité est celle que `discoverModels(...)` renvoie sur votre machine + les clés disponibles. -## Identifiants (ne jamais committer) +## Identifiants (ne jamais commit) -Les tests live découvrent les identifiants de la même manière que le CLI. Implications pratiques : +Les tests live découvrent les identifiants de la même manière que la CLI. Implications pratiques : -- Si le CLI fonctionne, les tests live devraient trouver les mêmes clés. -- Si un test live indique « pas d’identifiants », déboguez-le comme vous débogueriez `openclaw models list` / la sélection de modèle. +- Si la CLI fonctionne, les tests live devraient trouver les mêmes clés. +- Si un test live indique « aucun identifiant », déboguez-le de la même manière que `openclaw models list` / la sélection de modèle. -- Profils d’authentification par agent : `~/.openclaw/agents//agent/auth-profiles.json` (c’est ce que « clés de profil » signifie dans les tests live) +- Profils d’authentification par agent : `~/.openclaw/agents//agent/auth-profiles.json` (c’est ce que signifient les « clés de profil » dans les tests live) - Configuration : `~/.openclaw/openclaw.json` (ou `OPENCLAW_CONFIG_PATH`) -- Répertoire d’état hérité : `~/.openclaw/credentials/` (copié dans le home live préparé lorsqu’il est présent, mais pas dans le stockage principal de clés de profil) -- Les exécutions live locales copient par défaut la configuration active, les fichiers `auth-profiles.json` par agent, le répertoire hérité `credentials/` et les répertoires d’auth CLI externes pris en charge dans un home de test temporaire ; les homes live préparés ignorent `workspace/` et `sandboxes/`, et les remplacements de chemin `agents.*.workspace` / `agentDir` sont retirés afin que les sondes restent en dehors de votre véritable espace de travail hôte. +- Répertoire d’état hérité : `~/.openclaw/credentials/` (copié dans le home live préparé quand il est présent, mais pas dans le magasin principal de clés de profil) +- Les exécutions live locales copient par défaut la configuration active, les fichiers `auth-profiles.json` par agent, le répertoire hérité `credentials/` et les répertoires d’authentification CLI externes pris en charge dans un home de test temporaire ; les homes live préparés ignorent `workspace/` et `sandboxes/`, et les remplacements de chemin `agents.*.workspace` / `agentDir` sont supprimés afin que les sondes restent hors de votre véritable espace de travail hôte. Si vous voulez vous appuyer sur des clés d’environnement (par exemple exportées dans votre `~/.profile`), exécutez les tests locaux après `source ~/.profile`, ou utilisez les exécuteurs Docker ci-dessous (ils peuvent monter `~/.profile` dans le conteneur). -## Live Deepgram (transcription audio) +## Deepgram live (transcription audio) - Test : `src/media-understanding/providers/deepgram/audio.live.test.ts` - Activer : `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts` -## Live BytePlus coding plan +## BytePlus coding plan live - Test : `src/agents/byteplus.live.test.ts` - Activer : `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts` -- Remplacement de modèle facultatif : `BYTEPLUS_CODING_MODEL=ark-code-latest` +- Remplacement facultatif du modèle : `BYTEPLUS_CODING_MODEL=ark-code-latest` -## Live média de workflow ComfyUI +## ComfyUI workflow media live - Test : `extensions/comfy/comfy.live.test.ts` - Activer : `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` -- Périmètre : - - Exerce les chemins image, vidéo et `music_generate` du comfy embarqué +- Portée : + - Exerce les chemins image, vidéo et `music_generate` du paquet comfy intégré - Ignore chaque capacité sauf si `models.providers.comfy.` est configuré - - Utile après des modifications de soumission de workflow comfy, polling, téléchargements ou enregistrement de Plugin + - Utile après avoir modifié l’envoi de workflow comfy, le polling, les téléchargements ou l’enregistrement du plugin -## Live génération d’images +## Génération d’image live - Test : `src/image-generation/runtime.live.test.ts` - Commande : `pnpm test:live src/image-generation/runtime.live.test.ts` - Harnais : `pnpm test:live:media image` -- Périmètre : - - Énumère tous les Plugins fournisseurs de génération d’images enregistrés - - Charge les variables d’environnement fournisseur manquantes depuis votre shell de connexion (`~/.profile`) avant la sonde - - Utilise par défaut les clés API live/env avant les profils d’auth stockés, afin que des clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants du shell - - Ignore les fournisseurs sans auth/profil/modèle exploitable - - Exécute les variantes standard de génération d’images via la capacité d’exécution partagée : +- Portée : + - Énumère chaque plugin fournisseur de génération d’image enregistré + - Charge les variables d’environnement fournisseur manquantes depuis votre shell de connexion (`~/.profile`) avant les sondes + - Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que d’anciennes clés de test dans `auth-profiles.json` ne masquent pas les vrais identifiants du shell + - Ignore les fournisseurs sans authentification/profil/modèle exploitable + - Exécute les variantes standard de génération d’image via la capacité runtime partagée : - `google:flash-generate` - `google:pro-generate` - `google:pro-edit` - `openai:default-generate` -- Fournisseurs embarqués actuellement couverts : +- Fournisseurs intégrés actuellement couverts : - `openai` - `google` - Restriction facultative : @@ -754,21 +753,21 @@ Si vous voulez vous appuyer sur des clés d’environnement (par exemple export - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-1,google/gemini-3.1-flash-image-preview"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit"` - Comportement d’authentification facultatif : - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l’authentification du stockage de profils et ignorer les remplacements par environnement uniquement + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification via le magasin de profils et ignorer les remplacements provenant uniquement de l’environnement -## Live génération de musique +## Génération de musique live - Test : `extensions/music-generation-providers.live.test.ts` - Activer : `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` - Harnais : `pnpm test:live:media music` -- Périmètre : - - Exerce le chemin partagé embarqué de fournisseur de génération de musique +- Portée : + - Exerce le chemin partagé des fournisseurs intégrés de génération de musique - Couvre actuellement Google et MiniMax - - Charge les variables d’environnement fournisseur depuis votre shell de connexion (`~/.profile`) avant la sonde - - Utilise par défaut les clés API live/env avant les profils d’auth stockés, afin que des clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants du shell - - Ignore les fournisseurs sans auth/profil/modèle exploitable - - Exécute les deux modes d’exécution déclarés lorsqu’ils sont disponibles : - - `generate` avec une entrée uniquement sous forme de prompt + - Charge les variables d’environnement fournisseur depuis votre shell de connexion (`~/.profile`) avant les sondes + - Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que d’anciennes clés de test dans `auth-profiles.json` ne masquent pas les vrais identifiants du shell + - Ignore les fournisseurs sans authentification/profil/modèle exploitable + - Exécute les deux modes runtime déclarés lorsqu’ils sont disponibles : + - `generate` avec entrée de type prompt uniquement - `edit` lorsque le fournisseur déclare `capabilities.edit.enabled` - Couverture actuelle de la voie partagée : - `google` : `generate`, `edit` @@ -778,179 +777,180 @@ Si vous voulez vous appuyer sur des clés d’environnement (par exemple export - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"` - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"` - Comportement d’authentification facultatif : - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l’authentification du stockage de profils et ignorer les remplacements par environnement uniquement + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification via le magasin de profils et ignorer les remplacements provenant uniquement de l’environnement -## Live génération de vidéo +## Génération de vidéo live - Test : `extensions/video-generation-providers.live.test.ts` - Activer : `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` - Harnais : `pnpm test:live:media video` -- Périmètre : - - Exerce le chemin partagé embarqué de fournisseur de génération de vidéo - - Utilise par défaut le chemin smoke sûr pour les versions : fournisseurs hors FAL, une requête texte-vers-vidéo par fournisseur, prompt lobster d’une seconde, et un plafond d’opération par fournisseur issu de `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` par défaut) - - Ignore FAL par défaut, car la latence de file d’attente côté fournisseur peut dominer le temps de release ; passez `--video-providers fal` ou `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"` pour l’exécuter explicitement - - Charge les variables d’environnement fournisseur depuis votre shell de connexion (`~/.profile`) avant la sonde - - Utilise par défaut les clés API live/env avant les profils d’auth stockés, afin que des clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants du shell - - Ignore les fournisseurs sans auth/profil/modèle exploitable +- Portée : + - Exerce le chemin partagé des fournisseurs intégrés de génération de vidéo + - Utilise par défaut le chemin de smoke sûr pour les versions : fournisseurs hors FAL, une requête texte-vers-vidéo par fournisseur, prompt lobster d’une seconde, et une limite d’opération par fournisseur depuis `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` par défaut) + - Ignore FAL par défaut car la latence de file d’attente côté fournisseur peut dominer le temps de release ; passez `--video-providers fal` ou `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"` pour l’exécuter explicitement + - Charge les variables d’environnement fournisseur depuis votre shell de connexion (`~/.profile`) avant les sondes + - Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que d’anciennes clés de test dans `auth-profiles.json` ne masquent pas les vrais identifiants du shell + - Ignore les fournisseurs sans authentification/profil/modèle exploitable - Exécute uniquement `generate` par défaut - - Définissez `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1` pour exécuter aussi les modes de transformation déclarés lorsqu’ils sont disponibles : - - `imageToVideo` lorsque le fournisseur déclare `capabilities.imageToVideo.enabled` et que le fournisseur/modèle sélectionné accepte une entrée image locale adossée à un buffer dans le balayage partagé - - `videoToVideo` lorsque le fournisseur déclare `capabilities.videoToVideo.enabled` et que le fournisseur/modèle sélectionné accepte une entrée vidéo locale adossée à un buffer dans le balayage partagé + - Définissez `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1` pour exécuter aussi les modes de transformation déclarés quand ils sont disponibles : + - `imageToVideo` lorsque le fournisseur déclare `capabilities.imageToVideo.enabled` et que le fournisseur/modèle sélectionné accepte une entrée image locale adossée à un tampon dans le balayage partagé + - `videoToVideo` lorsque le fournisseur déclare `capabilities.videoToVideo.enabled` et que le fournisseur/modèle sélectionné accepte une entrée vidéo locale adossée à un tampon dans le balayage partagé - Fournisseurs `imageToVideo` actuellement déclarés mais ignorés dans le balayage partagé : - - `vydra` parce que le `veo3` embarqué est texte uniquement et que le `kling` embarqué nécessite une URL d’image distante - - Couverture Vydra spécifique au fournisseur : + - `vydra` car le `veo3` intégré est uniquement texte et le `kling` intégré exige une URL d’image distante + - Couverture spécifique au fournisseur Vydra : - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts` - - ce fichier exécute `veo3` texte-vers-vidéo ainsi qu’une voie `kling` qui utilise par défaut un fixture d’URL d’image distante - - Couverture live actuelle `videoToVideo` : + - ce fichier exécute `veo3` en texte-vers-vidéo ainsi qu’une voie `kling` qui utilise par défaut une fixture d’URL d’image distante + - Couverture live `videoToVideo` actuelle : - `runway` uniquement lorsque le modèle sélectionné est `runway/gen4_aleph` - Fournisseurs `videoToVideo` actuellement déclarés mais ignorés dans le balayage partagé : - - `alibaba`, `qwen`, `xai` parce que ces chemins nécessitent actuellement des URL de référence distantes `http(s)` / MP4 - - `google` parce que la voie partagée Gemini/Veo actuelle utilise une entrée locale adossée à un buffer et que ce chemin n’est pas accepté dans le balayage partagé - - `openai` parce que la voie partagée actuelle n’offre pas de garanties d’accès spécifiques à l’organisation pour l’inpaint/remix vidéo + - `alibaba`, `qwen`, `xai` car ces chemins nécessitent actuellement des URL de référence distantes `http(s)` / MP4 + - `google` car la voie partagée Gemini/Veo actuelle utilise une entrée locale adossée à un tampon, et ce chemin n’est pas accepté dans le balayage partagé + - `openai` car la voie partagée actuelle ne garantit pas l’accès spécifique à l’organisation pour la retouche/remix vidéo - Restriction facultative : - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="google,openai,runway"` - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"` - - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""` pour inclure tous les fournisseurs dans le balayage par défaut, y compris FAL - - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000` pour réduire le plafond d’opération de chaque fournisseur lors d’un smoke agressif + - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""` pour inclure chaque fournisseur dans le balayage par défaut, y compris FAL + - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000` pour réduire la limite d’opération de chaque fournisseur lors d’un smoke agressif - Comportement d’authentification facultatif : - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l’authentification du stockage de profils et ignorer les remplacements par environnement uniquement + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification via le magasin de profils et ignorer les remplacements provenant uniquement de l’environnement -## Harnais live média +## Harnais media live - Commande : `pnpm test:live:media` -- Objectif : - - Exécute les suites live partagées image, musique et vidéo via un seul point d’entrée natif du dépôt +- But : + - Exécute les suites live partagées d’image, de musique et de vidéo via un point d’entrée natif du dépôt - Charge automatiquement les variables d’environnement fournisseur manquantes depuis `~/.profile` - - Restreint automatiquement chaque suite aux fournisseurs qui ont actuellement une authentification exploitable par défaut - - Réutilise `scripts/test-live.mjs`, de sorte que le comportement de Heartbeat et de mode silencieux reste cohérent + - Restreint automatiquement chaque suite aux fournisseurs qui disposent actuellement d’une authentification exploitable par défaut + - Réutilise `scripts/test-live.mjs`, afin que le comportement Heartbeat et le mode silencieux restent cohérents - Exemples : - `pnpm test:live:media` - `pnpm test:live:media image video --providers openai,google,minimax` - `pnpm test:live:media video --video-providers openai,runway --all-providers` - `pnpm test:live:media music --quiet` -## Exécuteurs Docker (vérifications facultatives « fonctionne sous Linux ») +## Exécuteurs Docker (vérifications facultatives « ça fonctionne sous Linux ») -Ces exécuteurs Docker se répartissent en deux catégories : +Ces exécuteurs Docker se divisent en deux catégories : -- Exécuteurs live de modèles : `test:docker:live-models` et `test:docker:live-gateway` n’exécutent que leur fichier live de clés de profil correspondant dans l’image Docker du dépôt (`src/agents/models.profiles.live.test.ts` et `src/gateway/gateway-models.profiles.live.test.ts`), en montant votre répertoire de configuration local et votre espace de travail (et en chargeant `~/.profile` s’il est monté). Les points d’entrée locaux correspondants sont `test:live:models-profiles` et `test:live:gateway-profiles`. -- Les exécuteurs Docker live utilisent par défaut un plafond de smoke plus petit afin qu’un balayage Docker complet reste pratique : +- Exécuteurs live de modèles : `test:docker:live-models` et `test:docker:live-gateway` n’exécutent que leur fichier live à clés de profil correspondant dans l’image Docker du dépôt (`src/agents/models.profiles.live.test.ts` et `src/gateway/gateway-models.profiles.live.test.ts`), en montant votre répertoire de configuration local et votre espace de travail (et en chargeant `~/.profile` s’il est monté). Les points d’entrée locaux correspondants sont `test:live:models-profiles` et `test:live:gateway-profiles`. +- Les exécuteurs live Docker utilisent par défaut une limite de smoke plus petite afin qu’un balayage Docker complet reste pratique : `test:docker:live-models` utilise par défaut `OPENCLAW_LIVE_MAX_MODELS=12`, et `test:docker:live-gateway` utilise par défaut `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000`, et - `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Remplacez ces variables d’environnement lorsque vous - souhaitez explicitement le balayage exhaustif plus large. -- `test:docker:all` construit l’image Docker live une fois via `test:docker:live-build`, puis la réutilise pour les deux voies Docker live. -- Exécuteurs smoke de conteneur : `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` et `test:docker:plugins` démarrent un ou plusieurs vrais conteneurs et vérifient des chemins d’intégration de plus haut niveau. + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Remplacez ces variables d’environnement quand vous + voulez explicitement un balayage exhaustif plus large. +- `test:docker:all` construit une fois l’image Docker live via `test:docker:live-build`, puis la réutilise pour les deux voies live Docker. +- Exécuteurs smoke de conteneur : `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels`, et `test:docker:plugins` démarrent un ou plusieurs vrais conteneurs et vérifient des chemins d’intégration de plus haut niveau. -Les exécuteurs Docker live de modèles montent également en bind uniquement les homes d’authentification CLI nécessaires (ou tous ceux pris en charge lorsque l’exécution n’est pas restreinte), puis les copient dans le home du conteneur avant l’exécution afin que l’OAuth des CLI externes puisse rafraîchir les jetons sans modifier le stockage d’authentification de l’hôte : +Les exécuteurs Docker live de modèles montent aussi uniquement les répertoires d’authentification CLI nécessaires (ou tous ceux pris en charge lorsque l’exécution n’est pas restreinte), puis les copient dans le home du conteneur avant l’exécution afin que l’OAuth des CLI externes puisse rafraîchir les jetons sans modifier le magasin d’authentification de l’hôte : - Modèles directs : `pnpm test:docker:live-models` (script : `scripts/test-live-models-docker.sh`) -- Smoke ACP bind : `pnpm test:docker:live-acp-bind` (script : `scripts/test-live-acp-bind-docker.sh`) -- Smoke backend CLI : `pnpm test:docker:live-cli-backend` (script : `scripts/test-live-cli-backend-docker.sh`) +- Smoke de liaison ACP : `pnpm test:docker:live-acp-bind` (script : `scripts/test-live-acp-bind-docker.sh`) +- Smoke du backend CLI : `pnpm test:docker:live-cli-backend` (script : `scripts/test-live-cli-backend-docker.sh`) - Smoke du harnais app-server Codex : `pnpm test:docker:live-codex-harness` (script : `scripts/test-live-codex-harness-docker.sh`) -- Gateway + agent dev : `pnpm test:docker:live-gateway` (script : `scripts/test-live-gateway-models-docker.sh`) +- Gateway + agent de développement : `pnpm test:docker:live-gateway` (script : `scripts/test-live-gateway-models-docker.sh`) - Smoke live Open WebUI : `pnpm test:docker:openwebui` (script : `scripts/e2e/openwebui-docker.sh`) -- Assistant d’onboarding (TTY, scaffolding complet) : `pnpm test:docker:onboard` (script : `scripts/e2e/onboard-docker.sh`) -- Réseau Gateway (deux conteneurs, auth WS + santé) : `pnpm test:docker:gateway-network` (script : `scripts/e2e/gateway-network-docker.sh`) -- Pont de canal MCP (Gateway préensemencé + pont stdio + smoke brut de trame de notification Claude) : `pnpm test:docker:mcp-channels` (script : `scripts/e2e/mcp-channels-docker.sh`) +- Assistant d’onboarding (TTY, échafaudage complet) : `pnpm test:docker:onboard` (script : `scripts/e2e/onboard-docker.sh`) +- Réseau Gateway (deux conteneurs, authentification WS + santé) : `pnpm test:docker:gateway-network` (script : `scripts/e2e/gateway-network-docker.sh`) +- Pont de canal MCP (Gateway amorcé + pont stdio + smoke brut de trame de notification Claude) : `pnpm test:docker:mcp-channels` (script : `scripts/e2e/mcp-channels-docker.sh`) - Plugins (smoke d’installation + alias `/plugin` + sémantique de redémarrage du bundle Claude) : `pnpm test:docker:plugins` (script : `scripts/e2e/plugins-docker.sh`) -Les exécuteurs Docker live de modèles montent aussi en bind le checkout courant en lecture seule et -le préparent dans un répertoire de travail temporaire à l’intérieur du conteneur. Cela garde l’image d’exécution -légère tout en exécutant Vitest sur vos sources/configurations locales exactes. -L’étape de préparation ignore les gros caches locaux uniquement et les sorties de build d’app telles que -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, ainsi que les répertoires de sortie `.build` ou -Gradle locaux à l’application, afin que les exécutions Docker live ne passent pas des minutes à copier +Les exécuteurs Docker live de modèles montent aussi l’extraction courante en lecture seule et +la préparent dans un répertoire de travail temporaire à l’intérieur du conteneur. Cela garde l’image d’exécution +légère tout en exécutant Vitest sur votre source/configuration locale exacte. +L’étape de préparation ignore les gros caches locaux et sorties de build d’application comme +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, et les répertoires locaux `.build` ou +de sortie Gradle afin que les exécutions live Docker ne passent pas des minutes à copier des artefacts spécifiques à la machine. Ils définissent aussi `OPENCLAW_SKIP_CHANNELS=1` afin que les sondes live Gateway ne démarrent pas de vrais workers de canal Telegram/Discord/etc. dans le conteneur. -`test:docker:live-models` exécute tout de même `pnpm test:live`, donc faites aussi passer -`OPENCLAW_LIVE_GATEWAY_*` lorsque vous devez restreindre ou exclure la couverture live Gateway de cette voie Docker. +`test:docker:live-models` exécute toujours `pnpm test:live`, donc transmettez aussi +`OPENCLAW_LIVE_GATEWAY_*` lorsque vous devez restreindre ou exclure la couverture +live Gateway de cette voie Docker. `test:docker:openwebui` est un smoke de compatibilité de plus haut niveau : il démarre un conteneur Gateway OpenClaw avec les points de terminaison HTTP compatibles OpenAI activés, -démarre un conteneur Open WebUI épinglé contre cette Gateway, se connecte via +démarre un conteneur Open WebUI épinglé contre ce Gateway, se connecte via Open WebUI, vérifie que `/api/models` expose `openclaw/default`, puis envoie une vraie requête de chat via le proxy `/api/chat/completions` d’Open WebUI. -La première exécution peut être sensiblement plus lente, car Docker peut devoir récupérer l’image -Open WebUI et Open WebUI peut devoir terminer sa propre configuration de démarrage à froid. +La première exécution peut être sensiblement plus lente car Docker peut devoir extraire l’image +Open WebUI et Open WebUI peut devoir terminer sa propre initialisation à froid. Cette voie attend une clé de modèle live exploitable, et `OPENCLAW_PROFILE_FILE` -(`~/.profile` par défaut) est le principal moyen de la fournir dans les exécutions Dockerisées. +(`~/.profile` par défaut) est le principal moyen de la fournir dans les exécutions Docker. Les exécutions réussies affichent une petite charge utile JSON comme `{ "ok": true, "model": "openclaw/default", ... }`. -`test:docker:mcp-channels` est volontairement déterministe et ne nécessite pas de +`test:docker:mcp-channels` est volontairement déterministe et n’a pas besoin d’un vrai compte Telegram, Discord ou iMessage. Il démarre un conteneur Gateway -préensemencé, démarre un second conteneur qui lance `openclaw mcp serve`, puis -vérifie la découverte de conversation routée, les lectures de transcription, les métadonnées des pièces jointes, -le comportement de la file d’événements live, le routage d’envoi sortant, et les notifications de canal + -autorisations de type Claude sur le vrai pont MCP stdio. La vérification des notifications -inspecte directement les trames MCP stdio brutes, afin que le smoke valide ce que le -pont émet réellement, et pas seulement ce qu’un SDK client donné expose par hasard. +amorcé, démarre un second conteneur qui lance `openclaw mcp serve`, puis +vérifie la découverte de conversation routée, la lecture des transcriptions, les métadonnées de pièce jointe, +le comportement de la file d’attente d’événements live, le routage d’envoi sortant, et les notifications de canal + +permissions de style Claude via le vrai pont MCP stdio. La vérification de notification +inspecte directement les trames MCP stdio brutes afin que le smoke valide ce que le +pont émet réellement, et pas seulement ce qu’un SDK client particulier choisit d’exposer. Smoke manuel ACP de fil en langage naturel (hors CI) : - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Conservez ce script pour les workflows de régression/débogage. Il pourrait être nécessaire à nouveau pour la validation du routage de fil ACP, donc ne le supprimez pas. +- Conservez ce script pour les workflows de régression/débogage. Il pourrait être de nouveau nécessaire pour la validation du routage des fils ACP, donc ne le supprimez pas. Variables d’environnement utiles : - `OPENCLAW_CONFIG_DIR=...` (par défaut : `~/.openclaw`) monté sur `/home/node/.openclaw` - `OPENCLAW_WORKSPACE_DIR=...` (par défaut : `~/.openclaw/workspace`) monté sur `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (par défaut : `~/.profile`) monté sur `/home/node/.profile` et chargé avant d’exécuter les tests -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` pour vérifier uniquement les variables d’environnement chargées depuis `OPENCLAW_PROFILE_FILE`, en utilisant des répertoires de config/espace de travail temporaires et sans montages d’authentification CLI externes -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (par défaut : `~/.cache/openclaw/docker-cli-tools`) monté sur `/home/node/.npm-global` pour les installations CLI mises en cache dans Docker -- Les répertoires/fichiers d’authentification CLI externes sous `$HOME` sont montés en lecture seule sous `/host-auth...`, puis copiés dans `/home/node/...` avant le démarrage des tests +- `OPENCLAW_PROFILE_FILE=...` (par défaut : `~/.profile`) monté sur `/home/node/.profile` et chargé avant l’exécution des tests +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` pour vérifier uniquement les variables d’environnement chargées depuis `OPENCLAW_PROFILE_FILE`, en utilisant des répertoires config/workspace temporaires et sans montage d’authentification CLI externe +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (par défaut : `~/.cache/openclaw/docker-cli-tools`) monté sur `/home/node/.npm-global` pour les installations CLI en cache dans Docker +- Les répertoires/fichiers d’authentification CLI externes sous `$HOME` sont montés en lecture seule sous `/host-auth...`, puis copiés vers `/home/node/...` avant le démarrage des tests - Répertoires par défaut : `.minimax` - Fichiers par défaut : `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - Les exécutions restreintes par fournisseur ne montent que les répertoires/fichiers nécessaires déduits de `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - Remplacement manuel avec `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none`, ou une liste séparée par des virgules comme `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` pour restreindre l’exécution - `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` pour filtrer les fournisseurs dans le conteneur -- `OPENCLAW_SKIP_DOCKER_BUILD=1` pour réutiliser une image `openclaw:local-live` existante lors de relances qui n’ont pas besoin d’une reconstruction -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour s’assurer que les identifiants proviennent du stockage de profils (et non de l’environnement) -- `OPENCLAW_OPENWEBUI_MODEL=...` pour choisir le modèle exposé par la Gateway pour le smoke Open WebUI +- `OPENCLAW_SKIP_DOCKER_BUILD=1` pour réutiliser une image `openclaw:local-live` existante lors de relances qui ne nécessitent pas de reconstruction +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour garantir que les identifiants proviennent du magasin de profils (et non de l’environnement) +- `OPENCLAW_OPENWEBUI_MODEL=...` pour choisir le modèle exposé par Gateway pour le smoke Open WebUI - `OPENCLAW_OPENWEBUI_PROMPT=...` pour remplacer le prompt de vérification de nonce utilisé par le smoke Open WebUI -- `OPENWEBUI_IMAGE=...` pour remplacer la balise d’image Open WebUI épinglée +- `OPENWEBUI_IMAGE=...` pour remplacer le tag d’image Open WebUI épinglé -## Vérification de cohérence de la documentation +## Vérification de la documentation Exécutez les vérifications de documentation après des modifications de doc : `pnpm check:docs`. -Exécutez la validation complète des ancres Mintlify lorsque vous avez aussi besoin de vérifier les titres dans la page : `pnpm docs:check-links:anchors`. +Exécutez la validation complète des ancres Mintlify quand vous avez aussi besoin de vérifier les titres dans la page : `pnpm docs:check-links:anchors`. -## Régression hors ligne (sans risque pour la CI) +## Régression hors ligne (compatible CI) -Il s’agit de régressions de « vrai pipeline » sans vrais fournisseurs : +Ce sont des régressions de « vrai pipeline » sans vrais fournisseurs : - Appel d’outils Gateway (OpenAI simulé, vraie boucle Gateway + agent) : `src/gateway/gateway.test.ts` (cas : "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Assistant Gateway (WS `wizard.start`/`wizard.next`, écriture de config + auth imposée) : `src/gateway/gateway.test.ts` (cas : "runs wizard over ws and writes auth token config") +- Assistant Gateway (WS `wizard.start`/`wizard.next`, écriture de config + authentification imposée) : `src/gateway/gateway.test.ts` (cas : "runs wizard over ws and writes auth token config") ## Évaluations de fiabilité d’agent (Skills) -Nous disposons déjà de quelques tests sans risque pour la CI qui se comportent comme des « évaluations de fiabilité d’agent » : +Nous avons déjà quelques tests compatibles CI qui se comportent comme des « évaluations de fiabilité d’agent » : -- Appel d’outils simulé à travers la vraie boucle Gateway + agent (`src/gateway/gateway.test.ts`). +- Appel d’outils simulé via la vraie boucle Gateway + agent (`src/gateway/gateway.test.ts`). - Flux d’assistant end-to-end qui valident le câblage de session et les effets de configuration (`src/gateway/gateway.test.ts`). Ce qui manque encore pour les Skills (voir [Skills](/fr/tools/skills)) : -- **Prise de décision :** lorsque les Skills sont listés dans le prompt, l’agent choisit-il le bon skill (ou évite-t-il ceux qui ne sont pas pertinents) ? +- **Prise de décision :** lorsque des Skills sont listées dans le prompt, l’agent choisit-il la bonne Skill (ou évite-t-il celles qui sont non pertinentes) ? - **Conformité :** l’agent lit-il `SKILL.md` avant utilisation et suit-il les étapes/arguments requis ? -- **Contrats de workflow :** scénarios multi-tours qui vérifient l’ordre des outils, le report de l’historique de session et les limites du bac à sable. +- **Contrats de workflow :** scénarios multi-tours qui vérifient l’ordre des outils, la conservation de l’historique de session, et les frontières du sandbox. Les futures évaluations doivent d’abord rester déterministes : -- Un exécuteur de scénarios utilisant des fournisseurs simulés pour vérifier les appels d’outils + leur ordre, les lectures de fichiers de skill et le câblage de session. -- Une petite suite de scénarios centrés sur les skills (utiliser vs éviter, gating, injection de prompt). -- Des évaluations live facultatives (opt-in, protégées par env) uniquement après la mise en place de la suite sans risque pour la CI. +- Un exécuteur de scénarios utilisant des fournisseurs simulés pour vérifier les appels d’outils + leur ordre, les lectures de fichiers de Skills, et le câblage de session. +- Une petite suite de scénarios ciblés sur les Skills (utiliser vs éviter, filtrage, injection de prompt). +- Des évaluations live facultatives (opt-in, filtrées par variables d’environnement) uniquement après la mise en place de la suite compatible CI. ## Tests de contrat (forme des plugins et des canaux) Les tests de contrat vérifient que chaque plugin et canal enregistré respecte son contrat d’interface. Ils parcourent tous les plugins découverts et exécutent une suite de vérifications de forme et de comportement. La voie unitaire par défaut `pnpm test` -ignore volontairement ces fichiers partagés de jonction et de smoke ; exécutez explicitement -les commandes de contrat lorsque vous touchez à des surfaces partagées de canal ou de fournisseur. +ignore volontairement ces fichiers partagés de seam et de smoke ; exécutez explicitement +les commandes de contrat quand vous touchez les surfaces partagées de canal ou de fournisseur. ### Commandes @@ -968,47 +968,47 @@ Situés dans `src/channels/plugins/contracts/*.contract.test.ts` : - **outbound-payload** - Structure de la charge utile du message - **inbound** - Gestion des messages entrants - **actions** - Gestionnaires d’actions de canal -- **threading** - Gestion des ids de fil -- **directory** - API de répertoire/liste +- **threading** - Gestion des identifiants de fil +- **directory** - API d’annuaire/de roster - **group-policy** - Application de la politique de groupe -### Contrats de statut des fournisseurs +### Contrats d’état des fournisseurs Situés dans `src/plugins/contracts/*.contract.test.ts`. -- **status** - Sondes de statut des canaux -- **registry** - Forme du registre de Plugin +- **status** - Sondes d’état du canal +- **registry** - Forme du registre de plugins -### Contrats des fournisseurs +### Contrats de fournisseurs Situés dans `src/plugins/contracts/*.contract.test.ts` : - **auth** - Contrat du flux d’authentification - **auth-choice** - Choix/sélection d’authentification - **catalog** - API du catalogue de modèles -- **discovery** - Découverte de Plugin -- **loader** - Chargement de Plugin -- **runtime** - Exécution du fournisseur -- **shape** - Forme/interface de Plugin +- **discovery** - Découverte de plugins +- **loader** - Chargement de plugin +- **runtime** - Runtime du fournisseur +- **shape** - Forme/interface du plugin - **wizard** - Assistant de configuration ### Quand les exécuter -- Après modification des exports ou sous-chemins de plugin-sdk -- Après ajout ou modification d’un Plugin de canal ou de fournisseur -- Après refactorisation de l’enregistrement ou de la découverte des Plugins +- Après une modification des exports ou sous-chemins de `plugin-sdk` +- Après l’ajout ou la modification d’un plugin de canal ou de fournisseur +- Après un refactoring de l’enregistrement ou de la découverte de plugins -Les tests de contrat s’exécutent en CI et ne nécessitent pas de vraies clés API. +Les tests de contrat s’exécutent dans CI et ne nécessitent pas de vraies clés API. -## Ajouter des régressions (recommandations) +## Ajouter des régressions (guide) -Lorsque vous corrigez un problème de fournisseur/modèle découvert en live : +Quand vous corrigez un problème de fournisseur/modèle découvert en live : -- Ajoutez si possible une régression sans risque pour la CI (fournisseur simulé/bouchonné, ou capture exacte de la transformation de forme de requête) -- Si le problème est intrinsèquement live uniquement (limites de débit, politiques d’authentification), gardez le test live étroit et opt-in via des variables d’environnement +- Ajoutez si possible une régression compatible CI (fournisseur simulé/mocké, ou capture exacte de la transformation de forme de requête) +- Si c’est intrinsèquement live-only (limitations de débit, politiques d’authentification), gardez le test live restreint et opt-in via des variables d’environnement - Préférez cibler la plus petite couche qui détecte le bug : - bug de conversion/rejeu de requête fournisseur → test de modèles directs - - bug de pipeline Gateway session/historique/outils → smoke live Gateway ou test simulé Gateway sans risque pour la CI -- Garde-fou de parcours SecretRef : - - `src/secrets/exec-secret-ref-id-parity.test.ts` dérive une cible échantillonnée par classe SecretRef à partir des métadonnées du registre (`listSecretTargetRegistryEntries()`), puis vérifie que les ids exec de segment de parcours sont rejetés. - - Si vous ajoutez une nouvelle famille de cibles SecretRef `includeInPlan` dans `src/secrets/target-registry-data.ts`, mettez à jour `classifyTargetClass` dans ce test. Le test échoue volontairement sur les ids de cible non classifiés afin que les nouvelles classes ne puissent pas être ignorées silencieusement. + - bug de pipeline Gateway session/historique/outils → smoke live Gateway ou test mock Gateway compatible CI +- Garde-fou de traversée SecretRef : + - `src/secrets/exec-secret-ref-id-parity.test.ts` dérive une cible échantillonnée par classe SecretRef à partir des métadonnées de registre (`listSecretTargetRegistryEntries()`), puis vérifie que les identifiants exec de segment de traversée sont rejetés. + - Si vous ajoutez une nouvelle famille cible SecretRef `includeInPlan` dans `src/secrets/target-registry-data.ts`, mettez à jour `classifyTargetClass` dans ce test. Le test échoue volontairement sur les identifiants de cible non classés afin qu’aucune nouvelle classe ne puisse être ignorée silencieusement.