diff --git a/docs/fr/ci.md b/docs/fr/ci.md index 187cb1f8f..d12735a03 100644 --- a/docs/fr/ci.md +++ b/docs/fr/ci.md @@ -3,73 +3,73 @@ read_when: - Vous devez comprendre pourquoi une tâche CI s’est exécutée ou non - Vous déboguez une vérification GitHub Actions en échec - Vous coordonnez une exécution ou une réexécution de validation de version -summary: Graphe des jobs CI, garde-fous de périmètre, regroupements de publication et équivalents locaux des commandes +summary: Graphe des tâches CI, contrôles de périmètre, regroupements de publication et équivalents des commandes locales title: Pipeline CI x-i18n: - generated_at: "2026-04-30T07:16:33Z" + generated_at: "2026-04-30T18:38:52Z" model: gpt-5.5 provider: openai - source_hash: a9c18f0801864ca1030aac9ea81117b011bd7936388984a1809ce3ae6e906e62 + source_hash: a24afc27606ac7f4e9ead89acdd319bffa23336610f8a6cd8b576ea1a5b233dd source_path: ci.md workflow: 16 --- -OpenClaw CI s’exécute à chaque poussée vers `main` et pour chaque pull request. Le job `preflight` classe le diff et désactive les voies coûteuses lorsque seules des zones sans rapport ont changé. Les exécutions manuelles `workflow_dispatch` contournent volontairement le cadrage intelligent et déploient le graphe complet pour les versions candidates et la validation large. Les voies Android restent optionnelles via `include_android`. La couverture des plugins réservée aux releases se trouve dans le workflow séparé [`Plugin Préversion`](#plugin-prerelease) et ne s’exécute qu’à partir de [`Validation complète de release`](#full-release-validation) ou d’un dispatch manuel explicite. +OpenClaw CI s’exécute à chaque push vers `main` et pour chaque pull request. Le job `preflight` classe le diff et désactive les lanes coûteuses lorsque seules des zones sans rapport ont changé. Les exécutions manuelles `workflow_dispatch` contournent intentionnellement le périmétrage intelligent et déploient tout le graphe pour les release candidates et les validations larges. Les lanes Android restent opt-in via `include_android`. La couverture Plugin réservée aux releases se trouve dans le workflow séparé [`Plugin Prerelease`](#plugin-prerelease) et ne s’exécute qu’à partir de [`Full Release Validation`](#full-release-validation) ou d’un dispatch manuel explicite. ## Vue d’ensemble du pipeline -| Job | Objectif | Quand il s’exécute | -| -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------ | -| `preflight` | Détecter les changements limités aux docs, les portées modifiées, les extensions modifiées et construire le manifeste CI | Toujours sur les poussées et PR non brouillon | -| `security-scm-fast` | Détection de clés privées et audit des workflows via `zizmor` | Toujours sur les poussées et PR non brouillon | -| `security-dependency-audit` | Audit du lockfile de production sans dépendances par rapport aux avis npm | Toujours sur les poussées et PR non brouillon | -| `security-fast` | Agrégat requis pour les jobs de sécurité rapides | Toujours sur les poussées et PR non brouillon | -| `check-dependencies` | Passe Knip de production limitée aux dépendances, plus garde de la liste d’autorisation des fichiers inutilisés | Changements pertinents pour Node | -| `build-artifacts` | Construire `dist/`, la Control UI, les vérifications d’artefacts construits et les artefacts aval réutilisables | Changements pertinents pour Node | -| `checks-fast-core` | Voies rapides de correction Linux, comme les vérifications bundled/contrat de plugin/protocole | Changements pertinents pour Node | -| `checks-fast-contracts-channels` | Vérifications fragmentées des contrats de canaux avec un résultat de vérification agrégé stable | Changements pertinents pour Node | -| `checks-node-core-test` | Fragments de tests Node du cœur, hors voies canal, bundled, contrat et extension | Changements pertinents pour Node | -| `check` | Équivalent fragmenté de la porte locale principale : types prod, lint, gardes, types de tests et smoke strict | Changements pertinents pour Node | -| `check-additional` | Fragments d’architecture, de frontière, de gardes de surface d’extension, de frontière de package et de gateway-watch | Changements pertinents pour Node | -| `build-smoke` | Tests smoke de CLI construite et smoke de mémoire au démarrage | Changements pertinents pour Node | -| `checks` | Vérificateur pour les tests de canaux sur artefacts construits | Changements pertinents pour Node | -| `checks-node-compat-node22` | Voie de build et smoke de compatibilité Node 22 | Dispatch CI manuel pour les releases | -| `check-docs` | Formatage, lint et vérifications de liens brisés des docs | Docs modifiées | -| `skills-python` | Ruff + pytest pour les skills adossés à Python | Changements pertinents pour les Skills Python | -| `checks-windows` | Tests de processus/chemins spécifiques à Windows, plus régressions de spécificateurs d’import runtime partagés | Changements pertinents pour Windows | -| `macos-node` | Voie de tests TypeScript macOS utilisant les artefacts construits partagés | Changements pertinents pour macOS | -| `macos-swift` | Lint, build et tests Swift pour l’app macOS | Changements pertinents pour macOS | -| `android` | Tests unitaires Android pour les deux variantes, plus un build d’APK debug | Changements pertinents pour Android | -| `test-performance-agent` | Optimisation quotidienne des tests lents Codex après une activité approuvée | Succès de la CI principale ou dispatch manuel | +| Job | Objectif | Quand il s’exécute | +| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- | +| `preflight` | Détecter les changements limités aux docs, les scopes modifiés, les extensions modifiées, et construire le manifeste CI | Toujours sur les pushs et PRs non draft | +| `security-scm-fast` | Détection de clés privées et audit des workflows via `zizmor` | Toujours sur les pushs et PRs non draft | +| `security-dependency-audit` | Audit du lockfile de production sans dépendances par rapport aux avis npm | Toujours sur les pushs et PRs non draft | +| `security-fast` | Agrégat requis pour les jobs de sécurité rapides | Toujours sur les pushs et PRs non draft | +| `check-dependencies` | Passe Knip de production limitée aux dépendances plus garde de l’allowlist des fichiers inutilisés | Changements pertinents pour Node | +| `build-artifacts` | Construire `dist/`, Control UI, les vérifications d’artefacts construits, et les artefacts aval réutilisables | Changements pertinents pour Node | +| `checks-fast-core` | Lanes de correction Linux rapides telles que les vérifications groupées/contrat Plugin/protocole | Changements pertinents pour Node | +| `checks-fast-contracts-channels` | Vérifications fragmentées des contrats de channels avec un résultat de vérification agrégé stable | Changements pertinents pour Node | +| `checks-node-core-test` | Shards de tests Node du noyau, hors lanes channel, groupées, contrat et extension | Changements pertinents pour Node | +| `check` | Équivalent fragmenté de la porte locale principale : types prod, lint, gardes, types de tests et smoke strict | Changements pertinents pour Node | +| `check-additional` | Shards d’architecture, de frontières, de gardes de surface d’extension, de frontières de package et de gateway-watch | Changements pertinents pour Node | +| `build-smoke` | Tests smoke de CLI construite et smoke de mémoire au démarrage | Changements pertinents pour Node | +| `checks` | Vérificateur pour les tests de channels d’artefacts construits | Changements pertinents pour Node | +| `checks-node-compat-node22` | Lane de build et smoke de compatibilité Node 22 | Dispatch CI manuel pour les releases | +| `check-docs` | Vérifications de formatage, lint et liens cassés des docs | Docs modifiées | +| `skills-python` | Ruff + pytest pour les skills adossées à Python | Changements pertinents pour les skills Python | +| `checks-windows` | Tests spécifiques Windows de processus/chemins plus régressions de spécificateurs d’import runtime partagés | Changements pertinents pour Windows | +| `macos-node` | Lane de tests TypeScript macOS utilisant les artefacts construits partagés | Changements pertinents pour macOS | +| `macos-swift` | Lint, build et tests Swift pour l’app macOS | Changements pertinents pour macOS | +| `android` | Tests unitaires Android pour les deux flavors plus un build APK debug | Changements pertinents pour Android | +| `test-performance-agent` | Optimisation quotidienne des tests lents par Codex après une activité approuvée | Succès de la CI principale ou dispatch manuel | ## Ordre fail-fast -1. `preflight` décide quelles voies existent effectivement. La logique `docs-scope` et `changed-scope` correspond à des étapes dans ce job, et non à des jobs autonomes. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` et `skills-python` échouent rapidement sans attendre les jobs plus lourds de matrice d’artefacts et de plateformes. -3. `build-artifacts` se chevauche avec les voies Linux rapides afin que les consommateurs aval puissent démarrer dès que le build partagé est prêt. -4. Les voies plus lourdes de plateformes et de runtime se déploient ensuite : `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` et `android`. +1. `preflight` décide quelles lanes existent réellement. Les logiques `docs-scope` et `changed-scope` sont des étapes dans ce job, et non des jobs autonomes. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` et `skills-python` échouent rapidement sans attendre les jobs plus lourds d’artefacts et de matrice de plateformes. +3. `build-artifacts` chevauche les lanes Linux rapides afin que les consommateurs aval puissent commencer dès que le build partagé est prêt. +4. Les lanes de plateformes et de runtimes plus lourdes se déploient ensuite : `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` et `android`. -GitHub peut marquer des jobs remplacés comme `cancelled` lorsqu’une poussée plus récente arrive sur la même PR ou la même référence `main`. Traitez cela comme du bruit CI, sauf si l’exécution la plus récente pour la même référence échoue aussi. Les vérifications agrégées de fragments utilisent `!cancelled() && always()` afin de toujours signaler les échecs normaux de fragments, mais sans se mettre en file d’attente après que l’ensemble du workflow a déjà été remplacé. La clé de concurrence CI automatique est versionnée (`CI-v7-*`) afin qu’un zombie côté GitHub dans un ancien groupe de file d’attente ne puisse pas bloquer indéfiniment les nouvelles exécutions principales. Les exécutions manuelles de suite complète utilisent `CI-manual-v1-*` et n’annulent pas les exécutions en cours. +GitHub peut marquer les jobs remplacés comme `cancelled` lorsqu’un push plus récent arrive sur la même PR ou référence `main`. Traitez cela comme du bruit CI, sauf si la plus récente exécution pour la même référence échoue aussi. Les vérifications agrégées de shards utilisent `!cancelled() && always()` afin de toujours signaler les échecs normaux de shards, sans toutefois se mettre en file d’attente une fois tout le workflow déjà remplacé. La clé de concurrence automatique CI est versionnée (`CI-v7-*`) afin qu’un zombie côté GitHub dans un ancien groupe de file d’attente ne puisse pas bloquer indéfiniment les nouvelles exécutions main. Les exécutions manuelles de suite complète utilisent `CI-manual-v1-*` et n’annulent pas les exécutions en cours. -## Portée et routage +## Périmètre et routage -La logique de portée se trouve dans `scripts/ci-changed-scope.mjs` et est couverte par des tests unitaires dans `src/scripts/ci-changed-scope.test.ts`. Le dispatch manuel ignore la détection `changed-scope` et fait agir le manifeste preflight comme si chaque zone cadrée avait changé. +La logique de périmètre se trouve dans `scripts/ci-changed-scope.mjs` et est couverte par des tests unitaires dans `src/scripts/ci-changed-scope.test.ts`. Le dispatch manuel ignore la détection changed-scope et fait agir le manifeste preflight comme si chaque zone périmétrée avait changé. -- **Les modifications du workflow CI** valident le graphe CI Node ainsi que le lint des workflows, mais ne forcent pas à elles seules les builds natifs Windows, Android ou macOS ; ces voies de plateforme restent limitées aux changements de sources de plateforme. -- **Les modifications limitées au routage CI, certaines modifications peu coûteuses de fixtures de tests du cœur, ainsi que les modifications étroites d’aides/tests de routage de contrat de plugin** utilisent un chemin de manifeste rapide limité à Node : `preflight`, la sécurité et une seule tâche `checks-fast-core`. Ce chemin ignore les artefacts de build, la compatibilité Node 22, les contrats de canaux, les fragments complets du cœur, les fragments de plugins bundled et les matrices de gardes additionnelles lorsque le changement se limite aux surfaces de routage ou d’aide que la tâche rapide exerce directement. -- **Les vérifications Windows Node** sont limitées aux wrappers de processus/chemins spécifiques à Windows, aux aides d’exécution npm/pnpm/UI, à la configuration du gestionnaire de packages et aux surfaces du workflow CI qui exécutent cette voie ; les changements sans rapport de source, de plugin, d’install-smoke et uniquement de tests restent sur les voies Linux Node. +- **Les modifications du workflow CI** valident le graphe CI Node plus le lint des workflows, mais ne forcent pas à elles seules les builds natifs Windows, Android ou macOS ; ces lanes de plateformes restent limitées aux changements de sources de plateformes. +- **Les modifications limitées au routage CI, certaines modifications peu coûteuses de fixtures de tests core, et les modifications étroites de helpers/tests de routage de contrats Plugin** utilisent un chemin de manifeste rapide Node uniquement : `preflight`, sécurité, et une seule tâche `checks-fast-core`. Ce chemin ignore les artefacts de build, la compatibilité Node 22, les contrats de channels, les shards core complets, les shards de Plugins groupés, et les matrices de gardes supplémentaires lorsque le changement est limité aux surfaces de routage ou de helpers directement exercées par la tâche rapide. +- **Les vérifications Node Windows** sont limitées aux wrappers de processus/chemins spécifiques à Windows, aux helpers de runners npm/pnpm/UI, à la configuration du gestionnaire de packages, et aux surfaces du workflow CI qui exécutent cette lane ; les changements sans rapport de sources, Plugin, install-smoke et tests uniquement restent sur les lanes Node Linux. -Les familles de tests Node les plus lentes sont divisées ou équilibrées afin que chaque job reste petit sans sur-réserver les runners : les contrats de canaux s’exécutent en trois fragments pondérés, les petites voies unitaires du cœur sont appariées, auto-reply s’exécute avec quatre workers équilibrés (avec le sous-arbre reply divisé en fragments agent-runner, dispatch et commands/state-routing), et les configurations agentic de Gateway/plugin sont réparties dans les jobs Node agentic existants limités aux sources au lieu d’attendre les artefacts construits. Les tests larges de navigateur, QA, médias et plugins divers utilisent leurs configurations Vitest dédiées plutôt que le fourre-tout partagé des plugins. Les fragments par motifs d’inclusion enregistrent les entrées de durée avec le nom du fragment CI, afin que `.artifacts/vitest-shard-timings.json` puisse distinguer une configuration complète d’un fragment filtré. `check-additional` garde ensemble le travail de compilation/canary de frontière de package et sépare l’architecture de topologie runtime de la couverture gateway watch ; le fragment de garde de frontière exécute ses petits gardes indépendants simultanément dans un seul job. Gateway watch, les tests de canaux et le fragment de frontière de support du cœur s’exécutent simultanément dans `build-artifacts` après que `dist/` et `dist-runtime/` ont déjà été construits. +Les familles de tests Node les plus lentes sont divisées ou équilibrées afin que chaque job reste petit sans sur-réserver de runners : les contrats de channels s’exécutent en trois shards pondérés, les petites lanes d’unités core sont appairées, auto-reply s’exécute avec quatre workers équilibrés (avec le sous-arbre reply divisé en shards agent-runner, dispatch et commands/state-routing), et les configurations agentic gateway/Plugin sont réparties sur les jobs Node agentic existants limités aux sources au lieu d’attendre les artefacts construits. Les tests larges de navigateur, QA, médias et Plugins divers utilisent leurs configs Vitest dédiées au lieu du catch-all Plugin partagé. Les shards à motifs d’inclusion enregistrent les entrées de timing avec le nom de shard CI, afin que `.artifacts/vitest-shard-timings.json` puisse distinguer une config entière d’un shard filtré. `check-additional` conserve ensemble les travaux de compilation/canary de frontières de packages et sépare l’architecture de topologie runtime de la couverture gateway watch ; le shard de garde de frontières exécute ses petits gardes indépendants en parallèle dans un seul job. Gateway watch, les tests de channels et le shard core support-boundary s’exécutent en parallèle dans `build-artifacts` après que `dist/` et `dist-runtime/` ont déjà été construits. -La CI Android exécute à la fois `testPlayDebugUnitTest` et `testThirdPartyDebugUnitTest`, puis construit l’APK debug Play. La variante tierce n’a pas de source set ni de manifeste séparé ; sa voie de tests unitaires compile tout de même la variante avec les flags BuildConfig SMS/call-log, tout en évitant un job de packaging APK debug dupliqué à chaque poussée pertinente pour Android. +La CI Android exécute à la fois `testPlayDebugUnitTest` et `testThirdPartyDebugUnitTest`, puis construit l’APK debug Play. Le flavor tiers n’a pas de source set ni de manifeste séparé ; sa lane de tests unitaires compile tout de même le flavor avec les flags BuildConfig SMS/call-log, tout en évitant un job de packaging APK debug en double à chaque push pertinent pour Android. -Le fragment `check-dependencies` exécute `pnpm deadcode:dependencies` (une passe Knip de production limitée aux dépendances, épinglée à la dernière version de Knip, avec l’âge minimal de release de pnpm désactivé pour l’installation `dlx`) et `pnpm deadcode:unused-files`, qui compare les résultats de fichiers de production inutilisés trouvés par Knip à `scripts/deadcode-unused-files.allowlist.mjs`. Le garde des fichiers inutilisés échoue lorsqu’une PR ajoute un nouveau fichier inutilisé non revu ou laisse une entrée périmée dans la liste d’autorisation, tout en préservant les surfaces intentionnelles de plugin dynamique, générées, de build, de tests live et de ponts de packages que Knip ne peut pas résoudre statiquement. +Le shard `check-dependencies` exécute `pnpm deadcode:dependencies` (une passe Knip de production limitée aux dépendances, épinglée à la dernière version de Knip, avec l’âge minimal de publication de pnpm désactivé pour l’installation `dlx`) et `pnpm deadcode:unused-files`, qui compare les résultats de fichiers de production inutilisés de Knip à `scripts/deadcode-unused-files.allowlist.mjs`. Le garde des fichiers inutilisés échoue lorsqu’une PR ajoute un nouveau fichier inutilisé non revu ou laisse une entrée d’allowlist obsolète, tout en préservant les surfaces intentionnelles de Plugins dynamiques, générées, de build, de live-test et de ponts de packages que Knip ne peut pas résoudre statiquement. -## Dispatchs manuels +## Dispatches manuels -Les dispatchs CI manuels exécutent le même graphe de jobs que la CI normale, mais activent de force chaque voie cadrée non Android : fragments Linux Node, fragments de plugins bundled, contrats de canaux, compatibilité Node 22, `check`, `check-additional`, build smoke, vérifications des docs, Skills Python, Windows, macOS et i18n de la Control UI. Les dispatchs CI manuels autonomes exécutent Android uniquement avec `include_android=true` ; l’ombrelle de release complète active Android en passant `include_android=true`. Les vérifications statiques de préversion de plugins, le fragment `agentic-plugins` réservé aux releases, le balayage complet par lots des extensions et les voies Docker de préversion de plugins sont exclus de la CI. La suite Docker de préversion s’exécute uniquement lorsque `Validation complète de release` déclenche le workflow séparé `Plugin Préversion` avec la porte de validation de release activée. +Les dispatches CI manuels exécutent le même graphe de jobs que la CI normale mais forcent l’activation de chaque lane périmétrée non Android : shards Node Linux, shards de Plugins groupés, contrats de channels, compatibilité Node 22, `check`, `check-additional`, build smoke, vérifications docs, Skills Python, Windows, macOS et i18n Control UI. Les dispatches CI manuels autonomes exécutent Android uniquement avec `include_android=true` ; l’ombrelle de release complète active Android en passant `include_android=true`. Les vérifications statiques de prerelease Plugin, le shard `agentic-plugins` réservé aux releases, le balayage complet par lots des extensions, et les lanes Docker de prerelease Plugin sont exclus de la CI. La suite Docker de prerelease ne s’exécute que lorsque `Full Release Validation` déclenche le workflow séparé `Plugin Prerelease` avec la porte release-validation activée. -Les exécutions manuelles utilisent un groupe de concurrence unique afin qu’une suite complète de release candidate ne soit pas annulée par une autre poussée ou exécution de PR sur la même référence. L’entrée optionnelle `target_ref` permet à un appelant approuvé d’exécuter ce graphe sur une branche, un tag ou un SHA de commit complet, tout en utilisant le fichier de workflow depuis la référence de dispatch sélectionnée. +Les exécutions manuelles utilisent un groupe de concurrence unique afin qu’une suite complète de release candidate ne soit pas annulée par un autre push ou une autre exécution de PR sur la même référence. L’entrée facultative `target_ref` permet à un appelant approuvé d’exécuter ce graphe sur une branche, un tag ou un SHA de commit complet tout en utilisant le fichier de workflow de la référence de dispatch sélectionnée. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -80,14 +80,14 @@ gh workflow run full-release-validation.yml --ref main -f ref= ## Runners | Exécuteur | Tâches | -| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, tâches et agrégats de sécurité rapides (`security-scm-fast`, `security-dependency-audit`, `security-fast`), vérifications rapides de protocole/contrat/bundled, vérifications fragmentées des contrats de canaux, fragments `check` sauf lint, fragments et agrégats `check-additional`, vérificateurs d’agrégats de tests Node, vérifications de docs, Skills Python, workflow-sanity, labeler, auto-response ; le preflight install-smoke utilise aussi Ubuntu hébergé par GitHub afin que la matrice Blacksmith puisse être mise en file plus tôt | -| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, fragments d’extensions plus légers, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` et `check-test-types` | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, fragments de tests Node Linux, fragments de tests de Plugins bundled, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (assez sensible au CPU pour que 8 vCPU aient coûté plus qu’ils n’ont économisé) ; builds Docker install-smoke (le temps de file d’attente 32 vCPU a coûté plus qu’il n’a économisé) | +| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, tâches de sécurité rapides et agrégats (`security-scm-fast`, `security-dependency-audit`, `security-fast`), vérifications rapides de protocole/contrat/groupées, vérifications fragmentées de contrats de canaux, fragments `check` sauf lint, fragments et agrégats `check-additional`, vérificateurs d’agrégats de tests Node, vérifications de docs, Skills Python, workflow-sanity, labeler, auto-response ; le preflight install-smoke utilise aussi Ubuntu hébergé par GitHub afin que la matrice Blacksmith puisse se mettre en file plus tôt | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, fragments de Plugin à charge plus faible, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` et `check-test-types` | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, fragments de tests Node Linux, fragments de tests de Plugins groupés, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (assez sensible au CPU pour que 8 vCPU coûtent plus qu’ils n’économisent) ; builds Docker install-smoke (le temps de file de 32 vCPU coûtait plus qu’il n’économisait) | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `macos-node` sur `openclaw/openclaw` ; les forks se rabattent sur `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` sur `openclaw/openclaw` ; les forks se rabattent sur `macos-latest` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` sur `openclaw/openclaw` ; les forks se replient sur `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` sur `openclaw/openclaw` ; les forks se replient sur `macos-latest` | ## Équivalents locaux @@ -115,25 +115,25 @@ pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-per pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json ``` -## Validation complète de release +## Validation complète de publication -`Full Release Validation` est le workflow manuel englobant pour « tout exécuter avant la release ». Il accepte une branche, une balise ou un SHA de commit complet, déclenche le workflow manuel `CI` avec cette cible, déclenche `Plugin Prerelease` pour les preuves réservées à la release concernant Plugin/package/statique/Docker, et déclenche `OpenClaw Release Checks` pour les install smoke, l’acceptation de package, les suites de chemin de release Docker, live/E2E, OpenWebUI, la parité QA Lab, Matrix et les voies Telegram. Il peut aussi exécuter le workflow post-publication `NPM Telegram Beta E2E` lorsqu’une spécification de package publiée est fournie. +`Full Release Validation` est le workflow parapluie manuel pour « tout exécuter avant la publication ». Il accepte une branche, un tag ou un SHA de commit complet, déclenche le workflow manuel `CI` avec cette cible, déclenche `Plugin Prerelease` pour la preuve réservée à la publication des Plugins/packages/statiques/Docker, et déclenche `OpenClaw Release Checks` pour le smoke d’installation, l’acceptation de package, les suites de chemin de publication Docker, le live/E2E, OpenWebUI, la parité QA Lab, Matrix et les voies Telegram. Il peut aussi exécuter le workflow post-publication `NPM Telegram Beta E2E` lorsqu’une spécification de package publiée est fournie. -`release_profile` contrôle l’étendue live/fournisseur transmise aux vérifications de release : +`release_profile` contrôle l’étendue live/fournisseur transmise aux vérifications de publication : -- `minimum` conserve les voies critiques de release OpenAI/core les plus rapides. +- `minimum` conserve les voies OpenAI/core critiques pour la publication les plus rapides. - `stable` ajoute l’ensemble stable de fournisseurs/backends. -- `full` exécute la large matrice consultative fournisseurs/médias. +- `full` exécute la large matrice consultative fournisseur/médias. -L’englobant enregistre les ID d’exécution enfant déclenchées, et la tâche finale `Verify full validation` revérifie les conclusions actuelles des exécutions enfant et ajoute des tableaux des tâches les plus lentes pour chaque exécution enfant. Si un workflow enfant est relancé et passe au vert, relancez seulement la tâche de vérification parente pour actualiser le résultat englobant et le résumé des temps. +Le parapluie enregistre les identifiants des exécutions enfants déclenchées, et la tâche finale `Verify full validation` revérifie les conclusions actuelles des exécutions enfants et ajoute des tableaux des tâches les plus lentes pour chaque exécution enfant. Si un workflow enfant est relancé et passe au vert, relancez uniquement la tâche de vérification parente pour actualiser le résultat du parapluie et le résumé des temps. -Pour la récupération, `Full Release Validation` et `OpenClaw Release Checks` acceptent tous deux `rerun_group`. Utilisez `all` pour une release candidate, `ci` uniquement pour l’enfant CI complet normal, `release-checks` pour chaque enfant de release, ou un groupe plus étroit : `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` ou `npm-telegram` sur l’englobant. Cela garde bornée la relance d’une boîte de release échouée après un correctif ciblé. +Pour la récupération, `Full Release Validation` et `OpenClaw Release Checks` acceptent tous deux `rerun_group`. Utilisez `all` pour un candidat de publication, `ci` uniquement pour l’enfant CI complet normal, `release-checks` pour chaque enfant de publication, ou un groupe plus étroit : `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` ou `npm-telegram` sur le parapluie. Cela limite la relance d’une boîte de publication échouée après un correctif ciblé. -`OpenClaw Release Checks` utilise la ref de workflow de confiance pour résoudre une fois la ref sélectionnée en tarball `release-package-under-test`, puis transmet cet artefact à la fois au workflow Docker de chemin de release live/E2E et au fragment d’acceptation de package. Cela maintient les octets du package cohérents entre les boîtes de release et évite de reconditionner le même candidat dans plusieurs tâches enfant. +`OpenClaw Release Checks` utilise la référence de workflow de confiance pour résoudre une fois la référence sélectionnée en tarball `release-package-under-test`, puis transmet cet artefact à la fois au workflow Docker de chemin de publication live/E2E et au fragment d’acceptation de package. Cela maintient des octets de package cohérents entre les boîtes de publication et évite de réemballer le même candidat dans plusieurs tâches enfants. ## Fragments live et E2E -L’enfant live/E2E de release conserve une large couverture native `pnpm test:live`, mais l’exécute comme fragments nommés via `scripts/test-live-shard.mjs` au lieu d’une tâche sérielle unique : +L’enfant live/E2E de publication conserve une large couverture native `pnpm test:live`, mais l’exécute sous forme de fragments nommés via `scripts/test-live-shard.mjs` au lieu d’une seule tâche série : - `native-live-src-agents` - `native-live-src-gateway-core` @@ -145,57 +145,57 @@ L’enfant live/E2E de release conserve une large couverture native `pnpm test:l - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- fragments médias audio/vidéo séparés et fragments musicaux filtrés par fournisseur +- fragments médias audio/vidéo séparés et fragments musique filtrés par fournisseur -Cela conserve la même couverture de fichiers tout en rendant les échecs lents de fournisseurs live plus faciles à relancer et à diagnostiquer. Les noms de fragments agrégés `native-live-extensions-o-z`, `native-live-extensions-media` et `native-live-extensions-media-music` restent valides pour les relances manuelles ponctuelles. +Cela conserve la même couverture de fichiers tout en rendant les défaillances lentes des fournisseurs live plus faciles à relancer et à diagnostiquer. Les noms de fragments agrégés `native-live-extensions-o-z`, `native-live-extensions-media` et `native-live-extensions-media-music` restent valides pour les relances manuelles en une seule fois. -Les fragments médias live natifs s’exécutent dans `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, construit par le workflow `Live Media Runner Image`. Cette image préinstalle `ffmpeg` et `ffprobe` ; les tâches médias vérifient seulement les binaires avant la configuration. Gardez les suites live adossées à Docker sur les exécuteurs Blacksmith normaux — les tâches de conteneur ne sont pas le bon endroit pour lancer des tests Docker imbriqués. +Les fragments de médias live natifs s’exécutent dans `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, construit par le workflow `Live Media Runner Image`. Cette image préinstalle `ffmpeg` et `ffprobe` ; les tâches médias ne font que vérifier les binaires avant la configuration. Gardez les suites live adossées à Docker sur des exécuteurs Blacksmith normaux : les tâches conteneur sont le mauvais endroit pour lancer des tests Docker imbriqués. -Les fragments live modèle/backend adossés à Docker utilisent une image partagée distincte `ghcr.io/openclaw/openclaw-live-test:` par commit sélectionné. Le workflow live de release construit et pousse cette image une fois, puis les fragments modèle live Docker, Gateway, backend CLI, liaison ACP et harnais Codex s’exécutent avec `OPENCLAW_SKIP_DOCKER_BUILD=1`. Si ces fragments reconstruisent indépendamment la cible Docker source complète, l’exécution de release est mal configurée et gaspillera du temps réel sur des builds d’image en double. +Les fragments live de modèles/backends adossés à Docker utilisent une image partagée distincte `ghcr.io/openclaw/openclaw-live-test:` par commit sélectionné. Le workflow de publication live construit et pousse cette image une seule fois, puis les fragments du modèle live Docker, du Gateway, du backend CLI, de la liaison ACP et du harnais Codex s’exécutent avec `OPENCLAW_SKIP_DOCKER_BUILD=1`. Si ces fragments reconstruisent indépendamment la cible Docker source complète, l’exécution de publication est mal configurée et gaspillera du temps mural avec des builds d’image dupliqués. ## Acceptation de package -Utilisez `Package Acceptance` lorsque la question est « ce package OpenClaw installable fonctionne-t-il comme produit ? ». Elle diffère de la CI normale : la CI normale valide l’arborescence source, tandis que l’acceptation de package valide un seul tarball via le même harnais Docker E2E que les utilisateurs exercent après installation ou mise à jour. +Utilisez `Package Acceptance` lorsque la question est « ce package OpenClaw installable fonctionne-t-il comme un produit ? » C’est différent de la CI normale : la CI normale valide l’arborescence source, tandis que l’acceptation de package valide un tarball unique via le même harnais Docker E2E que les utilisateurs exercent après une installation ou une mise à jour. ### Tâches -1. `resolve_package` extrait `workflow_ref`, résout un candidat package, écrit `.artifacts/docker-e2e-package/openclaw-current.tgz`, écrit `.artifacts/docker-e2e-package/package-candidate.json`, téléverse les deux comme artefact `package-under-test`, et imprime la source, la ref de workflow, la ref de package, la version, le SHA-256 et le profil dans le résumé d’étape GitHub. -2. `docker_acceptance` appelle `openclaw-live-and-e2e-checks-reusable.yml` avec `ref=workflow_ref` et `package_artifact_name=package-under-test`. Le workflow réutilisable télécharge cet artefact, valide l’inventaire du tarball, prépare les images Docker à condensé de package si nécessaire, et exécute les voies Docker sélectionnées contre ce package au lieu de packager l’extraction du workflow. Lorsqu’un profil sélectionne plusieurs `docker_lanes` ciblées, le workflow réutilisable prépare le package et les images partagées une fois, puis déploie ces voies en tâches Docker ciblées parallèles avec des artefacts uniques. +1. `resolve_package` extrait `workflow_ref`, résout un candidat de package, écrit `.artifacts/docker-e2e-package/openclaw-current.tgz`, écrit `.artifacts/docker-e2e-package/package-candidate.json`, téléverse les deux en tant qu’artefact `package-under-test`, et affiche la source, la référence de workflow, la référence de package, la version, le SHA-256 et le profil dans le résumé d’étape GitHub. +2. `docker_acceptance` appelle `openclaw-live-and-e2e-checks-reusable.yml` avec `ref=workflow_ref` et `package_artifact_name=package-under-test`. Le workflow réutilisable télécharge cet artefact, valide l’inventaire du tarball, prépare les images Docker de digest de package lorsque nécessaire, et exécute les voies Docker sélectionnées contre ce package au lieu de packager l’extraction du workflow. Lorsqu’un profil sélectionne plusieurs `docker_lanes` ciblées, le workflow réutilisable prépare le package et les images partagées une seule fois, puis déploie ces voies en tâches Docker ciblées parallèles avec des artefacts uniques. 3. `package_telegram` appelle éventuellement `NPM Telegram Beta E2E`. Il s’exécute lorsque `telegram_mode` n’est pas `none` et installe le même artefact `package-under-test` lorsque Package Acceptance en a résolu un ; un déclenchement Telegram autonome peut toujours installer une spécification npm publiée. -4. `summary` fait échouer le workflow si la résolution de package, l’acceptation Docker ou la voie Telegram facultative a échoué. +4. `summary` fait échouer le workflow si la résolution du package, l’acceptation Docker ou la voie Telegram facultative a échoué. ### Sources candidates -- `source=npm` accepte uniquement `openclaw@beta`, `openclaw@latest` ou une version de publication OpenClaw exacte telle que `openclaw@2026.4.27-beta.2`. Utilisez cela pour l’acceptation publiée bêta/stable. -- `source=ref` empaquette une branche, une balise ou un SHA de commit complet `package_ref` de confiance. Le résolveur récupère les branches/balises OpenClaw, vérifie que le commit sélectionné est accessible depuis l’historique de branche du dépôt ou une balise de publication, installe les dépendances dans un worktree détaché, puis l’empaquette avec `scripts/package-openclaw-for-docker.mjs`. +- `source=npm` accepte uniquement `openclaw@beta`, `openclaw@latest` ou une version de publication OpenClaw exacte telle que `openclaw@2026.4.27-beta.2`. Utilisez ceci pour l’acceptation des versions bêta/stables publiées. +- `source=ref` empaquette une branche, une étiquette ou un SHA de commit complet `package_ref` de confiance. Le résolveur récupère les branches/étiquettes OpenClaw, vérifie que le commit sélectionné est atteignable depuis l’historique des branches du dépôt ou une étiquette de publication, installe les dépendances dans un worktree détaché et l’empaquette avec `scripts/package-openclaw-for-docker.mjs`. - `source=url` télécharge un `.tgz` HTTPS ; `package_sha256` est requis. -- `source=artifact` télécharge un `.tgz` depuis `artifact_run_id` et `artifact_name` ; `package_sha256` est facultatif mais devrait être fourni pour les artefacts partagés en externe. +- `source=artifact` télécharge un `.tgz` depuis `artifact_run_id` et `artifact_name` ; `package_sha256` est facultatif mais doit être fourni pour les artefacts partagés en externe. -Gardez `workflow_ref` et `package_ref` séparés. `workflow_ref` est le code de workflow/harnais de confiance qui exécute le test. `package_ref` est le commit source qui est empaqueté quand `source=ref`. Cela permet au harnais de test actuel de valider d’anciens commits source de confiance sans exécuter l’ancienne logique de workflow. +Gardez `workflow_ref` et `package_ref` séparés. `workflow_ref` est le code de workflow/harnais de confiance qui exécute le test. `package_ref` est le commit source qui est empaqueté lorsque `source=ref`. Cela permet au harnais de test actuel de valider d’anciens commits source de confiance sans exécuter l’ancienne logique de workflow. ### Profils de suite - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload` -- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update` +- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update` - `product` — `package` plus `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` - `full` — fragments complets du chemin de publication Docker avec OpenWebUI -- `custom` — `docker_lanes` exact ; requis quand `suite_profile=custom` +- `custom` — `docker_lanes` exact ; requis lorsque `suite_profile=custom` -Le profil `package` utilise une couverture de plugins hors ligne afin que la validation des packages publiés ne dépende pas de la disponibilité en direct de ClawHub. La voie Telegram facultative réutilise l’artefact `package-under-test` dans `NPM Telegram Beta E2E`, le chemin de spécification npm publié étant conservé pour les dispatches autonomes. +Le profil `package` utilise une couverture des plugins hors ligne afin que la validation des packages publiés ne dépende pas de la disponibilité en direct de ClawHub. Le lane Telegram facultatif réutilise l’artefact `package-under-test` dans `NPM Telegram Beta E2E`, avec le chemin de spécification npm publiée conservé pour les dispatchs autonomes. -Les vérifications de publication appellent Package Acceptance avec `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` et `telegram_mode=mock-openai`. Les fragments Docker du chemin de publication couvrent les voies package/update/plugin qui se chevauchent ; Package Acceptance conserve la compatibilité bundled-channel native de l’artefact, le plugin hors ligne et la preuve Telegram sur la même archive tar de package résolue. Les vérifications de publication inter-OS couvrent toujours l’onboarding, l’installateur et le comportement de plateforme propres à l’OS ; la validation produit package/update devrait commencer avec Package Acceptance. Les voies Windows packaged et installer fresh vérifient aussi qu’un package installé peut importer un remplacement browser-control depuis un chemin Windows absolu brut. Le smoke de tour d’agent OpenAI inter-OS utilise par défaut `OPENCLAW_CROSS_OS_OPENAI_MODEL` quand il est défini, sinon `openai/gpt-5.4-mini`, afin que la preuve d’installation et de Gateway reste rapide et déterministe. +Les vérifications de publication appellent Package Acceptance avec `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` et `telegram_mode=mock-openai`. Les fragments Docker du chemin de publication couvrent les lanes qui se chevauchent pour les packages/mises à jour/plugins ; Package Acceptance conserve la preuve de compatibilité des canaux groupés native de l’artefact, des plugins hors ligne et de Telegram contre le même tarball de package résolu. Les vérifications de publication multi-OS couvrent toujours l’onboarding propre au système d’exploitation, l’installeur et le comportement de plateforme ; la validation produit des packages/mises à jour doit commencer par Package Acceptance. Les lanes Windows de package et d’installation fraîche vérifient également qu’un package installé peut importer un remplacement de contrôle du navigateur depuis un chemin Windows absolu brut. Le smoke de tour d’agent multi-OS OpenAI utilise par défaut `OPENCLAW_CROSS_OS_OPENAI_MODEL` lorsqu’il est défini, sinon `openai/gpt-5.4-mini`, afin que la preuve d’installation et de Gateway reste rapide et déterministe. -### Fenêtres de compatibilité héritée +### Fenêtres de compatibilité héritées Package Acceptance dispose de fenêtres bornées de compatibilité héritée pour les packages déjà publiés. Les packages jusqu’à `2026.4.25`, y compris `2026.4.25-beta.*`, peuvent utiliser le chemin de compatibilité : -- les entrées QA privées connues dans `dist/postinstall-inventory.json` peuvent pointer vers des fichiers omis de l’archive tar ; -- `doctor-switch` peut ignorer le sous-cas de persistance `gateway install --wrapper` quand le package n’expose pas ce drapeau ; -- `update-channel-switch` peut élaguer les `pnpm.patchedDependencies` manquants depuis la fausse fixture git dérivée de l’archive tar et peut journaliser l’absence de `update.channel` persistant ; -- les smokes de plugins peuvent lire d’anciens emplacements d’enregistrement d’installation ou accepter l’absence de persistance de l’enregistrement d’installation de la marketplace ; +- les entrées QA privées connues dans `dist/postinstall-inventory.json` peuvent pointer vers des fichiers omis du tarball ; +- `doctor-switch` peut ignorer le sous-cas de persistance `gateway install --wrapper` lorsque le package n’expose pas cet indicateur ; +- `update-channel-switch` peut supprimer les `pnpm.patchedDependencies` manquantes du faux fixture git dérivé du tarball et peut journaliser l’absence du `update.channel` persistant ; +- les smokes de plugins peuvent lire les anciens emplacements d’enregistrements d’installation ou accepter l’absence de persistance de l’enregistrement d’installation marketplace ; - `plugin-update` peut autoriser la migration des métadonnées de configuration tout en exigeant que l’enregistrement d’installation et le comportement sans réinstallation restent inchangés. -Le package `2026.4.26` publié peut aussi avertir pour les fichiers d’horodatage de métadonnées de build local déjà livrés. Les packages ultérieurs doivent satisfaire les contrats modernes ; les mêmes conditions échouent au lieu d’avertir ou d’être ignorées. +Le package publié `2026.4.26` peut aussi avertir pour les fichiers d’horodatage de métadonnées de build local déjà livrés. Les packages ultérieurs doivent satisfaire les contrats modernes ; les mêmes conditions échouent au lieu d’émettre un avertissement ou d’être ignorées. ### Exemples @@ -238,60 +238,60 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Lors du débogage d’une exécution Package Acceptance échouée, commencez par le résumé `resolve_package` pour confirmer la source, la version et le SHA-256 du package. Inspectez ensuite l’exécution enfant `docker_acceptance` et ses artefacts Docker : `.artifacts/docker-tests/**/summary.json`, `failures.json`, les journaux de voie, les temps de phase et les commandes de réexécution. Préférez réexécuter le profil de package échoué ou les voies Docker exactes plutôt que de relancer toute la validation de publication. +Lors du débogage d’une exécution Package Acceptance échouée, commencez par le résumé `resolve_package` pour confirmer la source du package, la version et le SHA-256. Inspectez ensuite l’exécution enfant `docker_acceptance` et ses artefacts Docker : `.artifacts/docker-tests/**/summary.json`, `failures.json`, les journaux de lane, les minutages de phase et les commandes de réexécution. Préférez réexécuter le profil de package échoué ou les lanes Docker exacts plutôt que de relancer la validation complète de publication. ## Smoke d’installation -Le workflow `Install Smoke` séparé réutilise le même script de portée via sa propre tâche `preflight`. Il divise la couverture smoke entre `run_fast_install_smoke` et `run_full_install_smoke`. +Le workflow distinct `Install Smoke` réutilise le même script de portée via son propre job `preflight`. Il divise la couverture smoke entre `run_fast_install_smoke` et `run_full_install_smoke`. -- **Chemin rapide** s’exécute pour les pull requests touchant les surfaces Docker/package, les changements de package/manifeste de plugins groupés, ou les surfaces principales de plugin/canal/Gateway/Plugin SDK que les tâches de smoke Docker exercent. Les changements de plugins groupés limités au source, les modifications limitées aux tests et les modifications limitées à la documentation ne réservent pas de workers Docker. Le chemin rapide construit l’image Dockerfile racine une fois, vérifie la CLI, exécute le smoke CLI de suppression des agents dans l’espace de travail partagé, exécute l’e2e gateway-network du conteneur, vérifie un argument de build d’extension groupée, puis exécute le profil Docker borné de plugin groupé sous un délai global de commande de 240 secondes (chaque exécution Docker de scénario étant plafonnée séparément). -- **Chemin complet** conserve l’installation de package QR et la couverture Docker/update de l’installateur pour les exécutions planifiées nocturnes, les dispatches manuels, les vérifications de publication par workflow-call et les pull requests qui touchent réellement les surfaces installateur/package/Docker. En mode complet, install-smoke prépare ou réutilise une image de smoke Dockerfile racine GHCR pour le SHA cible, puis exécute l’installation de package QR, les smokes Dockerfile racine/Gateway, les smokes installateur/update et l’E2E Docker rapide de plugin groupé comme tâches séparées afin que le travail d’installation n’attende pas derrière les smokes de l’image racine. +- **Chemin rapide** s’exécute pour les pull requests touchant les surfaces Docker/package, les changements de package/manifeste de plugin groupé, ou les surfaces Plugin SDK de plugin/canal/Gateway cœur que les jobs smoke Docker exercent. Les changements de plugin groupé uniquement source, les modifications uniquement de tests et les modifications uniquement de documentation ne réservent pas de workers Docker. Le chemin rapide construit une fois l’image Dockerfile racine, vérifie la CLI, exécute le smoke CLI de suppression des agents pour l’espace de travail partagé, exécute l’e2e gateway-network du conteneur, vérifie un argument de build d’extension groupée et exécute le profil Docker borné des plugins groupés sous un délai global de commande de 240 secondes (chaque exécution Docker de scénario étant plafonnée séparément). +- **Chemin complet** conserve la couverture d’installation de package QR et d’installation/mise à jour Docker pour les exécutions nocturnes planifiées, les dispatchs manuels, les vérifications de publication workflow-call et les pull requests qui touchent réellement les surfaces d’installeur/package/Docker. En mode complet, install-smoke prépare ou réutilise une image smoke GHCR Dockerfile racine pour le SHA cible, puis exécute l’installation de package QR, les smokes Dockerfile racine/Gateway, les smokes installeur/mise à jour et l’E2E Docker rapide des plugins groupés comme jobs séparés afin que le travail d’installation n’attende pas derrière les smokes de l’image racine. -Les pushes sur `main` (y compris les commits de merge) ne forcent pas le chemin complet ; quand la logique de portée des changements demanderait une couverture complète sur un push, le workflow conserve le smoke Docker rapide et laisse le smoke d’installation complet à la validation nocturne ou de publication. +Les pushs vers `main` (y compris les commits de fusion) ne forcent pas le chemin complet ; lorsque la logique de portée des changements demanderait une couverture complète sur un push, le workflow conserve le smoke Docker rapide et laisse le smoke d’installation complet à la validation nocturne ou de publication. -Le smoke lent de fournisseur d’image par installation globale Bun est contrôlé séparément par `run_bun_global_install_smoke`. Il s’exécute selon le planning nocturne et depuis le workflow de vérifications de publication, et les dispatches manuels `Install Smoke` peuvent choisir de l’inclure, mais les pull requests et les pushes sur `main` ne le font pas. Les tests Docker QR et installateur conservent leurs propres Dockerfiles centrés sur l’installation. +Le smoke lent du fournisseur d’image d’installation globale Bun est contrôlé séparément par `run_bun_global_install_smoke`. Il s’exécute sur la planification nocturne et depuis le workflow de vérifications de publication, et les dispatchs manuels `Install Smoke` peuvent l’activer, mais pas les pull requests ni les pushs vers `main`. Les tests Docker QR et d’installeur conservent leurs propres Dockerfiles orientés installation. ## E2E Docker local -`pnpm test:docker:all` préconstruit une image de test en direct partagée, empaquette OpenClaw une fois sous forme d’archive tar npm, puis construit deux images `scripts/e2e/Dockerfile` partagées : +`pnpm test:docker:all` préconstruit une image de test en direct partagée, empaquette OpenClaw une fois comme tarball npm et construit deux images `scripts/e2e/Dockerfile` partagées : -- un exécuteur Node/Git minimal pour les voies installateur/update/dépendances de plugin ; -- une image fonctionnelle qui installe la même archive tar dans `/app` pour les voies de fonctionnalité normales. +- un exécuteur Node/Git minimal pour les lanes installeur/mise à jour/dépendance de plugin ; +- une image fonctionnelle qui installe le même tarball dans `/app` pour les lanes de fonctionnalité normale. -Les définitions de voies Docker se trouvent dans `scripts/lib/docker-e2e-scenarios.mjs`, la logique du planificateur dans `scripts/lib/docker-e2e-plan.mjs`, et l’exécuteur exécute uniquement le plan sélectionné. L’ordonnanceur sélectionne l’image par voie avec `OPENCLAW_DOCKER_E2E_BARE_IMAGE` et `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, puis exécute les voies avec `OPENCLAW_SKIP_DOCKER_BUILD=1`. +Les définitions de lanes Docker se trouvent dans `scripts/lib/docker-e2e-scenarios.mjs`, la logique du planificateur se trouve dans `scripts/lib/docker-e2e-plan.mjs`, et l’exécuteur n’exécute que le plan sélectionné. L’ordonnanceur sélectionne l’image par lane avec `OPENCLAW_DOCKER_E2E_BARE_IMAGE` et `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, puis exécute les lanes avec `OPENCLAW_SKIP_DOCKER_BUILD=1`. ### Paramètres ajustables | Variable | Par défaut | Objectif | | -------------------------------------- | ---------- | --------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Nombre de créneaux du pool principal pour les voies normales. | -| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Nombre de créneaux du pool final sensible aux fournisseurs. | -| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Plafond de voies en direct concurrentes pour éviter que les fournisseurs ne limitent le débit. | -| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Plafond de voies d’installation npm concurrentes. | -| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Plafond de voies multi-services concurrentes. | -| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Décalage entre les démarrages de voies pour éviter les tempêtes de création du démon Docker ; définissez `0` pour aucun décalage. | -| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Délai de secours par voie (120 minutes) ; certaines voies live/tail utilisent des plafonds plus stricts. | -| `OPENCLAW_DOCKER_ALL_DRY_RUN` | non défini | `1` affiche le plan de l’ordonnanceur sans exécuter les voies. | -| `OPENCLAW_DOCKER_ALL_LANES` | non défini | Liste exacte de voies séparées par des virgules ; ignore le smoke de nettoyage afin que les agents puissent reproduire une voie échouée. | +| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Nombre de slots du pool principal pour les lanes normales. | +| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Nombre de slots du pool de fin sensible aux fournisseurs. | +| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Plafond de lanes en direct concurrentes afin que les fournisseurs ne limitent pas le débit. | +| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Plafond de lanes d’installation npm concurrentes. | +| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Plafond de lanes multiservices concurrentes. | +| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Décalage entre les démarrages de lanes pour éviter les tempêtes de création du démon Docker ; définissez `0` pour aucun décalage. | +| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Délai de secours par lane (120 minutes) ; certaines lanes en direct/de fin utilisent des plafonds plus stricts. | +| `OPENCLAW_DOCKER_ALL_DRY_RUN` | non défini | `1` affiche le plan de l’ordonnanceur sans exécuter les lanes. | +| `OPENCLAW_DOCKER_ALL_LANES` | non défini | Liste exacte de lanes séparées par des virgules ; ignore le smoke de nettoyage afin que les agents puissent reproduire une lane échouée. | -Une voie plus lourde que son plafond effectif peut tout de même démarrer depuis un pool vide, puis s’exécuter seule jusqu’à libérer de la capacité. Le préflight agrégé local vérifie Docker, supprime les conteneurs E2E OpenClaw obsolètes, émet l’état des voies actives, persiste les temps de voie pour l’ordre du plus long au plus court, et cesse par défaut de planifier de nouvelles voies mutualisées après le premier échec. +Une lane plus lourde que son plafond effectif peut quand même démarrer depuis un pool vide, puis s’exécute seule jusqu’à libérer de la capacité. L’agrégat local effectue les prévalidations Docker, supprime les conteneurs E2E OpenClaw obsolètes, émet l’état des lanes actives, persiste les minutages de lanes pour l’ordre du plus long d’abord et arrête par défaut de planifier de nouvelles lanes groupées après le premier échec. -### Workflow live/E2E réutilisable +### Workflow en direct/E2E réutilisable -Le workflow live/E2E réutilisable demande à `scripts/test-docker-all.mjs --plan-json` quelle couverture de package, type d’image, image live, voie et identifiants est requise. `scripts/docker-e2e.mjs` convertit ensuite ce plan en sorties et résumés GitHub. Il empaquette OpenClaw via `scripts/package-openclaw-for-docker.mjs`, télécharge un artefact de package de l’exécution courante, ou télécharge un artefact de package depuis `package_artifact_run_id` ; valide l’inventaire de l’archive tar ; construit et pousse les images E2E Docker GHCR bare/fonctionnelles étiquetées par digest de package via le cache de couches Docker de Blacksmith quand le plan a besoin de voies avec package installé ; et réutilise les entrées `docker_e2e_bare_image`/`docker_e2e_functional_image` fournies ou les images existantes par digest de package au lieu de reconstruire. Les pulls d’images Docker sont retentés avec un délai borné de 180 secondes par tentative afin qu’un flux registre/cache bloqué retente rapidement au lieu de consommer la majeure partie du chemin critique CI. +Le workflow en direct/E2E réutilisable demande à `scripts/test-docker-all.mjs --plan-json` quels package, type d’image, image en direct, lane et couverture d’identifiants sont requis. `scripts/docker-e2e.mjs` convertit ensuite ce plan en sorties et résumés GitHub. Il empaquette OpenClaw via `scripts/package-openclaw-for-docker.mjs`, télécharge un artefact de package de l’exécution actuelle ou télécharge un artefact de package depuis `package_artifact_run_id` ; valide l’inventaire du tarball ; construit et pousse des images E2E Docker GHCR bare/fonctionnelles étiquetées par le digest du package via le cache de couches Docker de Blacksmith lorsque le plan nécessite des lanes avec package installé ; et réutilise les entrées `docker_e2e_bare_image`/`docker_e2e_functional_image` fournies ou des images existantes fondées sur le digest du package au lieu de reconstruire. Les extractions d’images Docker sont réessayées avec un délai borné de 180 secondes par tentative afin qu’un flux de registre/cache bloqué soit réessayé rapidement au lieu de consommer l’essentiel du chemin critique CI. ### Fragments du chemin de publication -La couverture Docker de publication exécute des tâches fragmentées plus petites avec `OPENCLAW_SKIP_DOCKER_BUILD=1`, afin que chaque fragment ne tire que le type d’image dont il a besoin et exécute plusieurs voies via le même ordonnanceur pondéré : +La couverture Docker de publication exécute des jobs fragmentés plus petits avec `OPENCLAW_SKIP_DOCKER_BUILD=1`, afin que chaque fragment ne récupère que le type d’image dont il a besoin et exécute plusieurs lanes via le même ordonnanceur pondéré : - `OPENCLAW_DOCKER_ALL_PROFILE=release-path` - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | bundled-channels` -Les fragments Docker de la version actuelle sont `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` à `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` et `bundled-channels-contracts`. Le fragment agrégé `bundled-channels` reste disponible pour les réexécutions manuelles ponctuelles, et `plugins-runtime-core`, `plugins-runtime` et `plugins-integrations` restent des alias agrégés de plugin/runtime. L’alias de voie `install-e2e` reste l’alias de réexécution manuelle agrégé pour les deux voies d’installation des fournisseurs. Le fragment `bundled-channels` exécute des voies scindées `bundled-channel-*` et `bundled-channel-update-*` plutôt que la voie série tout-en-un `bundled-channel-deps`. +Les fragments Docker de la version actuelle sont `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` à `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` et `bundled-channels-contracts`. Le fragment agrégé `bundled-channels` reste disponible pour les relances manuelles en une seule passe, et `plugins-runtime-core`, `plugins-runtime` et `plugins-integrations` restent des alias agrégés de Plugin/runtime. L’alias de voie `install-e2e` reste l’alias de relance manuelle agrégé pour les deux voies d’installation de fournisseur. Le fragment `bundled-channels` exécute les voies divisées `bundled-channel-*` et `bundled-channel-update-*` plutôt que la voie sérielle tout-en-un `bundled-channel-deps`. -OpenWebUI est intégré à `plugins-runtime-services` lorsque la couverture complète du chemin de publication le demande, et conserve un fragment autonome `openwebui` uniquement pour les dispatches limités à OpenWebUI. Les voies de mise à jour des canaux groupés réessaient une fois en cas d’échecs réseau npm transitoires. +OpenWebUI est intégré à `plugins-runtime-services` lorsque la couverture complète du chemin de publication le demande, et conserve un fragment autonome `openwebui` uniquement pour les dispatchs limités à OpenWebUI. Les voies de mise à jour des canaux groupés réessaient une fois en cas d’échecs réseau npm transitoires. -Chaque fragment téléverse `.artifacts/docker-tests/` avec les journaux de voie, les durées, `summary.json`, `failures.json`, les durées de phase, le JSON du planificateur, les tableaux de voies lentes et les commandes de réexécution par voie. L’entrée `docker_lanes` du workflow exécute les voies sélectionnées sur les images préparées au lieu des jobs de fragments, ce qui limite le débogage d’une voie en échec à un seul job Docker ciblé et prépare, télécharge ou réutilise l’artefact de package pour cette exécution ; si une voie sélectionnée est une voie Docker live, le job ciblé construit localement l’image de test live pour cette réexécution. Les commandes de réexécution GitHub générées par voie incluent `package_artifact_run_id`, `package_artifact_name` et les entrées d’images préparées lorsque ces valeurs existent, de sorte qu’une voie en échec puisse réutiliser exactement le package et les images de l’exécution échouée. +Chaque fragment téléverse `.artifacts/docker-tests/` avec les journaux de voie, les timings, `summary.json`, `failures.json`, les timings de phase, le JSON du plan d’ordonnancement, les tableaux des voies lentes et les commandes de relance par voie. L’entrée de workflow `docker_lanes` exécute les voies sélectionnées sur les images préparées au lieu des jobs de fragments, ce qui limite le débogage des voies en échec à un seul job Docker ciblé et prépare, télécharge ou réutilise l’artefact de package pour cette exécution ; si une voie sélectionnée est une voie Docker live, le job ciblé construit localement l’image de test live pour cette relance. Les commandes de relance GitHub générées par voie incluent `package_artifact_run_id`, `package_artifact_name` et les entrées d’images préparées lorsque ces valeurs existent, afin qu’une voie en échec puisse réutiliser exactement le package et les images de l’exécution échouée. ```bash pnpm test:docker:rerun # download Docker artifacts and print combined/per-lane targeted rerun commands @@ -302,47 +302,47 @@ Le workflow live/E2E planifié exécute quotidiennement la suite Docker complèt ## Préversion de Plugin -`Plugin Prerelease` offre une couverture produit/package plus coûteuse ; il s’agit donc d’un workflow distinct déclenché par `Full Release Validation` ou par un opérateur explicite. Les pull requests normales, les pushes sur `main` et les dispatches CI manuels autonomes gardent cette suite désactivée. Il répartit les tests des plugins groupés sur huit workers d’extension ; ces jobs de fragments d’extension exécutent jusqu’à deux groupes de configuration de plugin à la fois, avec un worker Vitest par groupe et un tas Node plus grand afin que les lots de plugins lourds en imports ne créent pas de jobs CI supplémentaires. +`Plugin Prerelease` offre une couverture produit/package plus coûteuse, c’est donc un workflow séparé déclenché par `Full Release Validation` ou par un opérateur explicite. Les pull requests normales, les poussées sur `main` et les dispatchs CI manuels autonomes laissent cette suite désactivée. Il répartit les tests des Plugins groupés sur huit workers d’extension ; ces jobs de shards d’extension exécutent jusqu’à deux groupes de configuration de Plugin à la fois, avec un worker Vitest par groupe et un tas Node plus grand, afin que les lots de Plugins lourds en imports ne créent pas de jobs CI supplémentaires. -## Labo QA +## Laboratoire QA -Le Labo QA dispose de voies CI dédiées en dehors du workflow principal à périmètre intelligent. +QA Lab dispose de voies CI dédiées en dehors du workflow principal à portée intelligente. -- Le workflow `Parity gate` s’exécute sur les changements de PR correspondants et par dispatch manuel ; il construit le runtime QA privé et compare les packs agentiques fictifs GPT-5.5 et Opus 4.6. -- Le workflow `QA-Lab - All Lanes` s’exécute chaque nuit sur `main` et par dispatch manuel ; il répartit en jobs parallèles la porte de parité fictive, la voie Matrix live, ainsi que les voies Telegram et Discord live. Les jobs live utilisent l’environnement `qa-live-shared`, et Telegram/Discord utilisent des baux Convex. +- Le workflow `Parity gate` s’exécute sur les changements de PR correspondants et par dispatch manuel ; il construit le runtime QA privé et compare les packs agentiques simulés GPT-5.5 et Opus 4.6. +- Le workflow `QA-Lab - All Lanes` s’exécute chaque nuit sur `main` et par dispatch manuel ; il distribue en jobs parallèles la porte de parité simulée, la voie Matrix live et les voies Telegram et Discord live. Les jobs live utilisent l’environnement `qa-live-shared`, et Telegram/Discord utilisent des baux Convex. -Les contrôles de publication exécutent les voies de transport live Matrix et Telegram avec le fournisseur fictif déterministe et des modèles qualifiés pour le mock (`mock-openai/gpt-5.5` et `mock-openai/gpt-5.5-alt`), afin que le contrat de canal soit isolé de la latence des modèles live et du démarrage normal des plugins fournisseurs. Le Gateway de transport live désactive la recherche mémoire, car la parité QA couvre séparément le comportement mémoire ; la connectivité fournisseur est couverte par les suites distinctes de modèles live, fournisseurs natifs et fournisseurs Docker. +Les vérifications de publication exécutent les voies de transport live Matrix et Telegram avec le fournisseur simulé déterministe et les modèles qualifiés mock (`mock-openai/gpt-5.5` et `mock-openai/gpt-5.5-alt`) afin que le contrat de canal soit isolé de la latence des modèles live et du démarrage normal des Plugins de fournisseur. Le gateway de transport live désactive la recherche mémoire parce que la parité QA couvre séparément le comportement mémoire ; la connectivité fournisseur est couverte par les suites séparées de modèles live, de fournisseurs natifs et de fournisseurs Docker. -Matrix utilise `--profile fast` pour les portes planifiées et de publication, en ajoutant `--fail-fast` uniquement lorsque la CLI extraite le prend en charge. La valeur par défaut de la CLI et l’entrée manuelle du workflow restent `all` ; un dispatch manuel `matrix_profile=all` fragmente toujours la couverture Matrix complète en jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` et `e2ee-cli`. +Matrix utilise `--profile fast` pour les portes planifiées et de publication, en ajoutant `--fail-fast` uniquement lorsque la CLI extraite le prend en charge. La valeur par défaut de la CLI et l’entrée de workflow manuelle restent `all` ; le dispatch manuel `matrix_profile=all` répartit toujours la couverture Matrix complète en jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` et `e2ee-cli`. -`OpenClaw Release Checks` exécute également les voies QA Lab critiques pour la publication avant l’approbation de publication ; sa porte de parité QA exécute les packs candidat et de référence comme jobs de voies parallèles, puis télécharge les deux artefacts dans un petit job de rapport pour la comparaison finale de parité. +`OpenClaw Release Checks` exécute également les voies QA Lab critiques pour la publication avant l’approbation de publication ; sa porte de parité QA exécute les packs candidat et de référence comme jobs de voie parallèles, puis télécharge les deux artefacts dans un petit job de rapport pour la comparaison de parité finale. -Ne placez pas le chemin d’intégration des PR derrière `Parity gate` sauf si le changement touche réellement au runtime QA, à la parité des packs de modèles ou à une surface appartenant au workflow de parité. Pour les correctifs normaux de canal, de configuration, de documentation ou de tests unitaires, traitez-le comme un signal facultatif et suivez plutôt les preuves CI/contrôles à périmètre défini. +Ne placez pas le chemin de landing de PR derrière `Parity gate` sauf si le changement touche réellement le runtime QA, la parité des packs de modèles ou une surface détenue par le workflow de parité. Pour les corrections normales de canal, de configuration, de documentation ou de tests unitaires, traitez-le comme un signal facultatif et suivez plutôt les preuves CI/vérifications à portée limitée. ## CodeQL -Le workflow `CodeQL` est intentionnellement un analyseur de sécurité étroit de premier passage, et non un balayage complet du dépôt. Les exécutions quotidiennes, manuelles et de garde sur pull requests non brouillons analysent le code des workflows Actions ainsi que les surfaces JavaScript/TypeScript les plus risquées, avec des requêtes de sécurité à haute confiance filtrées sur `security-severity` élevée/critique. +Le workflow `CodeQL` est volontairement un analyseur de sécurité de premier passage étroit, et non un balayage complet du dépôt. Les exécutions quotidiennes, manuelles et de garde des pull requests non brouillon analysent le code des workflows Actions ainsi que les surfaces JavaScript/TypeScript les plus à risque, avec des requêtes de sécurité à haute confiance filtrées sur les `security-severity` élevées/critiques. -La garde des pull requests reste légère : elle démarre uniquement pour les changements sous `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` ou `src`, et exécute la même matrice de sécurité à haute confiance que le workflow planifié. Android et macOS CodeQL restent exclus des valeurs par défaut des PR. +La garde des pull requests reste légère : elle ne démarre que pour les changements sous `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` ou `src`, et elle exécute la même matrice de sécurité à haute confiance que le workflow planifié. CodeQL Android et macOS restent exclus des valeurs par défaut des PR. ### Catégories de sécurité | Catégorie | Surface | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-security-high/core-auth-secrets` | Authentification, secrets, sandbox, Cron et référence du Gateway | -| `/codeql-security-high/channel-runtime-boundary` | Contrats d’implémentation du canal principal, plus runtime de plugin de canal, Gateway, SDK Plugin, secrets et points de contact d’audit | -| `/codeql-security-high/network-ssrf-boundary` | Surfaces SSRF principales, analyse IP, garde réseau, web-fetch et politique SSRF du SDK Plugin | -| `/codeql-security-high/mcp-process-tool-boundary` | Serveurs MCP, helpers d’exécution de processus, livraison sortante et portes d’exécution d’outils agent | -| `/codeql-security-high/plugin-trust-boundary` | Installation de Plugin, chargeur, manifeste, registre, préparation des dépendances runtime, chargement des sources et surfaces de confiance du contrat de package du SDK Plugin | +| `/codeql-security-high/core-auth-secrets` | Authentification, secrets, sandbox, cron et base de référence du Gateway | +| `/codeql-security-high/channel-runtime-boundary` | Contrats d’implémentation des canaux cœur, plus le runtime de Plugin de canal, le Gateway, le SDK Plugin, les secrets et les points de contact d’audit | +| `/codeql-security-high/network-ssrf-boundary` | Surfaces SSRF cœur, analyse IP, garde réseau, récupération web et politique SSRF du SDK Plugin | +| `/codeql-security-high/mcp-process-tool-boundary` | Serveurs MCP, assistants d’exécution de processus, livraison sortante et portes d’exécution d’outils agent | +| `/codeql-security-high/plugin-trust-boundary` | Surfaces de confiance de l’installation de Plugin, du chargeur, du manifeste, du registre, de la mise en attente des dépendances runtime, du chargement de source et du contrat de package du SDK Plugin | -### Fragments de sécurité spécifiques à la plateforme +### Shards de sécurité propres aux plateformes -- `CodeQL Android Critical Security` — fragment de sécurité Android planifié. Construit manuellement l’application Android pour CodeQL sur le plus petit runner Blacksmith Linux accepté par la vérification de cohérence du workflow. Téléverse sous `/codeql-critical-security/android`. -- `CodeQL macOS Critical Security` — fragment de sécurité macOS hebdomadaire/manuel. Construit manuellement l’application macOS pour CodeQL sur Blacksmith macOS, filtre les résultats de build de dépendances hors du SARIF téléversé et téléverse sous `/codeql-critical-security/macos`. Conservé hors des valeurs quotidiennes par défaut, car le build macOS domine la durée d’exécution même lorsqu’il est propre. +- `CodeQL Android Critical Security` — shard de sécurité Android planifié. Construit manuellement l’application Android pour CodeQL sur le plus petit runner Blacksmith Linux accepté par la vérification de cohérence du workflow. Téléverse sous `/codeql-critical-security/android`. +- `CodeQL macOS Critical Security` — shard de sécurité macOS hebdomadaire/manuel. Construit manuellement l’application macOS pour CodeQL sur Blacksmith macOS, filtre les résultats de build de dépendances hors du SARIF téléversé, et téléverse sous `/codeql-critical-security/macos`. Conservé hors des valeurs par défaut quotidiennes parce que le build macOS domine le temps d’exécution même lorsqu’il est propre. -### Catégories de qualité critiques +### Catégories de qualité critique -`CodeQL Critical Quality` est le fragment non lié à la sécurité correspondant. Il exécute uniquement des requêtes de qualité JavaScript/TypeScript de sévérité erreur et non liées à la sécurité sur des surfaces étroites à forte valeur, sur le plus petit runner Blacksmith Linux. Sa garde de pull request est intentionnellement plus réduite que le profil planifié : les PR non brouillons exécutent uniquement les fragments correspondants `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` et `plugin-sdk-reply-runtime` pour les changements de code d’exécution des commandes/modèles/outils d’agent et de dispatch de réponses, de code de schéma/migration/E/S de configuration, de code auth/secrets/sandbox/sécurité, de runtime des canaux principaux et des plugins de canaux groupés, de protocole Gateway/méthode serveur, de runtime mémoire/liaison SDK, de MCP/processus/livraison sortante, de runtime fournisseur/catalogue de modèles, de diagnostics de session/files de livraison, de chargeur de plugin, de SDK Plugin/contrat de package ou de runtime de réponse du SDK Plugin. Les changements de configuration CodeQL et de workflow qualité exécutent les douze fragments de qualité PR. +`CodeQL Critical Quality` est le shard non lié à la sécurité correspondant. Il exécute uniquement des requêtes de qualité JavaScript/TypeScript de sévérité erreur et non liées à la sécurité sur des surfaces étroites à forte valeur, sur le plus petit runner Blacksmith Linux. Sa garde de pull request est volontairement plus petite que le profil planifié : les PR non brouillon n’exécutent que les shards correspondants `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` et `plugin-sdk-reply-runtime` pour les changements concernant l’exécution de commandes/modèles/outils agent et le code de dispatch des réponses, le schéma/la migration/les E/S de configuration, le code d’authentification/secrets/sandbox/sécurité, le runtime des canaux cœur et des Plugins de canaux groupés, le protocole/la méthode serveur du Gateway, la colle runtime/SDK de mémoire, MCP/processus/livraison sortante, le runtime fournisseur/catalogue de modèles, les diagnostics de session/files de livraison, le chargeur de Plugin, le contrat SDK Plugin/package, ou le runtime de réponse du SDK Plugin. Les changements de configuration CodeQL et de workflow qualité exécutent les douze shards qualité de PR. Le dispatch manuel accepte : @@ -350,40 +350,40 @@ Le dispatch manuel accepte : profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary ``` -Les profils étroits sont des points d’entrée d’apprentissage et d’itération pour exécuter un fragment de qualité isolément. +Les profils étroits sont des points d’entrée d’apprentissage/itération pour exécuter un shard qualité isolément. -| Catégorie | Surface | -| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-critical-quality/core-auth-secrets` | Code de frontière de sécurité pour l’authentification, les secrets, le sandbox, Cron et le Gateway | -| `/codeql-critical-quality/config-boundary` | Schéma de configuration, migration, normalisation et contrats d’E/S | -| `/codeql-critical-quality/gateway-runtime-boundary` | Schémas du protocole Gateway et contrats des méthodes serveur | -| `/codeql-critical-quality/channel-runtime-boundary` | Contrats d’implémentation du canal principal et du plugin de canal groupé | -| `/codeql-critical-quality/agent-runtime-boundary` | Exécution des commandes, dispatch des modèles/fournisseurs, dispatch et files de réponse automatique, et contrats d’exécution du plan de contrôle ACP | -| `/codeql-critical-quality/mcp-process-runtime-boundary` | Serveurs MCP et ponts d’outils, assistants de supervision de processus, et contrats de livraison sortante | -| `/codeql-critical-quality/memory-runtime-boundary` | SDK de l’hôte mémoire, façades d’exécution mémoire, alias mémoire du Plugin SDK, logique d’activation de l’exécution mémoire, et commandes doctor de mémoire | -| `/codeql-critical-quality/session-diagnostics-boundary` | Internes de la file de réponses, files de livraison de session, assistants de liaison/livraison de session sortante, surfaces de bundle d’événements/journaux de diagnostic, et contrats CLI doctor de session | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Dispatch des réponses entrantes du Plugin SDK, assistants de charge utile/découpage/exécution des réponses, options de réponse de canal, files de livraison, et assistants de liaison session/fil | -| `/codeql-critical-quality/provider-runtime-boundary` | Normalisation du catalogue de modèles, authentification et découverte des fournisseurs, enregistrement de l’exécution des fournisseurs, valeurs par défaut/catalogues des fournisseurs, et registres web/recherche/récupération/embedding | -| `/codeql-critical-quality/ui-control-plane` | Amorçage de l’interface de contrôle, persistance locale, flux de contrôle du Gateway, et contrats d’exécution du plan de contrôle des tâches | -| `/codeql-critical-quality/web-media-runtime-boundary` | Contrats d’exécution pour la récupération/recherche web principale, les E/S média, la compréhension média, la génération d’images et la génération de médias | -| `/codeql-critical-quality/plugin-boundary` | Contrats du chargeur, du registre, de la surface publique et des points d’entrée du Plugin SDK | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Source du Plugin SDK côté package publié et assistants de contrat de package de plugin | +| Catégorie | Surface | +| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `/codeql-critical-quality/core-auth-secrets` | Code de limite de sécurité pour l’authentification, les secrets, le bac à sable, Cron et le Gateway | +| `/codeql-critical-quality/config-boundary` | Schéma de configuration, migration, normalisation et contrats d’E/S | +| `/codeql-critical-quality/gateway-runtime-boundary` | Schémas du protocole Gateway et contrats de méthodes serveur | +| `/codeql-critical-quality/channel-runtime-boundary` | Contrats d’implémentation du canal central et des Plugins de canal intégrés | +| `/codeql-critical-quality/agent-runtime-boundary` | Exécution des commandes, dispatch des modèles/fournisseurs, dispatch et files d’attente des réponses automatiques, et contrats d’exécution du plan de contrôle ACP | +| `/codeql-critical-quality/mcp-process-runtime-boundary` | Serveurs MCP et ponts d’outils, assistants de supervision de processus et contrats de livraison sortante | +| `/codeql-critical-quality/memory-runtime-boundary` | SDK hôte de mémoire, façades d’exécution de mémoire, alias du SDK de Plugin mémoire, liaison d’activation de l’exécution mémoire et commandes doctor de mémoire | +| `/codeql-critical-quality/session-diagnostics-boundary` | Internes de file de réponses, files de livraison de session, assistants de liaison/livraison de session sortante, surfaces d’événements diagnostiques/de bundles de journaux, et contrats CLI doctor de session | +| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Dispatch des réponses entrantes du SDK de Plugin, assistants de charge utile/segmentation/exécution des réponses, options de réponse de canal, files de livraison et assistants de liaison session/fil | +| `/codeql-critical-quality/provider-runtime-boundary` | Normalisation du catalogue de modèles, authentification et découverte des fournisseurs, enregistrement de l’exécution des fournisseurs, valeurs par défaut/catalogues des fournisseurs, et registres web/recherche/récupération/embeddings | +| `/codeql-critical-quality/ui-control-plane` | Amorçage de l’interface de contrôle, persistance locale, flux de contrôle du Gateway et contrats d’exécution du plan de contrôle des tâches | +| `/codeql-critical-quality/web-media-runtime-boundary` | Contrats d’exécution pour la récupération/recherche web centrale, les E/S média, la compréhension des médias, la génération d’images et la génération de médias | +| `/codeql-critical-quality/plugin-boundary` | Contrats du chargeur, du registre, de la surface publique et des points d’entrée du SDK de Plugin | +| `/codeql-critical-quality/plugin-sdk-package-contract` | Source du SDK de Plugin côté package publié et assistants de contrat de package de Plugin | -La qualité reste séparée de la sécurité afin que les constats de qualité puissent être planifiés, mesurés, désactivés ou étendus sans masquer le signal de sécurité. L’extension CodeQL pour Swift, Python et les plugins groupés ne doit être réintroduite sous forme de travail de suivi ciblé ou fragmenté qu’une fois que les profils restreints disposent d’une exécution et d’un signal stables. +La qualité reste séparée de la sécurité afin que les constats de qualité puissent être planifiés, mesurés, désactivés ou étendus sans masquer le signal de sécurité. L’extension CodeQL à Swift, Python et aux Plugins intégrés ne doit être réintégrée sous forme de travail de suivi limité ou partitionné qu’une fois que les profils étroits disposent d’une exécution et d’un signal stables. ## Workflows de maintenance ### Docs Agent -Le workflow `Docs Agent` est une voie de maintenance Codex pilotée par les événements pour garder la documentation existante alignée sur les changements récemment intégrés. Il n’a pas de planification pure : une exécution CI réussie issue d’un push non-bot sur `main` peut le déclencher, et un déclenchement manuel peut l’exécuter directement. Les invocations par workflow-run sont ignorées lorsque `main` a avancé ou lorsqu’une autre exécution non ignorée de Docs Agent a été créée au cours de la dernière heure. Lorsqu’il s’exécute, il examine la plage de commits allant du précédent SHA source non ignoré de Docs Agent jusqu’au `main` actuel, de sorte qu’une exécution horaire peut couvrir tous les changements de main accumulés depuis la dernière passe de documentation. +Le workflow `Docs Agent` est une voie de maintenance Codex pilotée par événements pour maintenir les docs existantes alignées avec les changements récemment intégrés. Il n’a pas de planification pure : une exécution CI réussie déclenchée par un push non-bot sur `main` peut le lancer, et un dispatch manuel peut l’exécuter directement. Les invocations par workflow-run sont ignorées lorsque `main` a avancé ou lorsqu’une autre exécution Docs Agent non ignorée a été créée dans la dernière heure. Lorsqu’il s’exécute, il examine la plage de commits allant du SHA source du précédent Docs Agent non ignoré jusqu’au `main` actuel, de sorte qu’une exécution horaire peut couvrir tous les changements de main accumulés depuis le dernier passage docs. ### Test Performance Agent -Le workflow `Test Performance Agent` est une voie de maintenance Codex pilotée par les événements pour les tests lents. Il n’a pas de planification pure : une exécution CI réussie issue d’un push non-bot sur `main` peut le déclencher, mais il s’interrompt si une autre invocation par workflow-run a déjà été exécutée ou est en cours ce jour UTC. Le déclenchement manuel contourne cette barrière d’activité quotidienne. La voie construit un rapport de performance Vitest groupé pour toute la suite, autorise Codex à n’apporter que de petites corrections de performance de tests préservant la couverture au lieu de larges refactorisations, puis réexécute le rapport de toute la suite et rejette les changements qui réduisent le nombre de tests de référence réussis. Si la référence contient des tests en échec, Codex ne peut corriger que les échecs évidents et le rapport de toute la suite après l’agent doit réussir avant que quoi que ce soit soit committé. Lorsque `main` avance avant que le push du bot n’atterrisse, la voie rebase le correctif validé, réexécute `pnpm check:changed`, puis retente le push ; les correctifs obsolètes en conflit sont ignorés. Elle utilise Ubuntu hébergé par GitHub afin que l’action Codex puisse conserver la même posture de sécurité sans sudo que l’agent de documentation. +Le workflow `Test Performance Agent` est une voie de maintenance Codex pilotée par événements pour les tests lents. Il n’a pas de planification pure : une exécution CI réussie déclenchée par un push non-bot sur `main` peut le lancer, mais il s’interrompt si une autre invocation par workflow-run a déjà été exécutée ou est en cours ce jour UTC. Le dispatch manuel contourne cette barrière d’activité quotidienne. Cette voie construit un rapport de performance Vitest groupé sur la suite complète, permet à Codex de n’effectuer que de petites corrections de performance de tests qui préservent la couverture au lieu de vastes refactorisations, puis relance le rapport sur la suite complète et rejette les changements qui réduisent le nombre de tests réussis dans la référence. Si la référence comporte des tests en échec, Codex ne peut corriger que les échecs évidents et le rapport de suite complète après agent doit réussir avant tout commit. Lorsque `main` avance avant que le push du bot n’atterrisse, la voie rebase le patch validé, relance `pnpm check:changed` et réessaie le push ; les patchs obsolètes en conflit sont ignorés. Elle utilise Ubuntu hébergé par GitHub afin que l’action Codex puisse conserver la même posture de sécurité sans sudo que l’agent docs. -### PR dupliquées après merge +### PRs dupliquées après fusion -Le workflow `Duplicate PRs After Merge` est un workflow mainteneur manuel pour le nettoyage des doublons après intégration. Il est en simulation par défaut et ne ferme que les PR explicitement listées lorsque `apply=true`. Avant de modifier GitHub, il vérifie que la PR intégrée est fusionnée et que chaque doublon possède soit une issue référencée en commun, soit des hunks modifiés qui se chevauchent. +Le workflow `Duplicate PRs After Merge` est un workflow mainteneur manuel destiné au nettoyage des doublons après intégration. Il utilise le mode simulation par défaut et ne ferme que les PRs explicitement listées lorsque `apply=true`. Avant de modifier GitHub, il vérifie que la PR intégrée est fusionnée et que chaque doublon possède soit une issue référencée commune, soit des hunks modifiés qui se chevauchent. ```bash gh workflow run duplicate-after-merge.yml \ @@ -394,25 +394,25 @@ gh workflow run duplicate-after-merge.yml \ ## Portes de vérification locales et routage des changements -La logique locale des voies modifiées se trouve dans `scripts/changed-lanes.mjs` et est exécutée par `scripts/check-changed.mjs`. Cette porte de vérification locale est plus stricte sur les frontières d’architecture que le périmètre large de la plateforme CI : +La logique locale des voies de changements se trouve dans `scripts/changed-lanes.mjs` et est exécutée par `scripts/check-changed.mjs`. Cette porte de vérification locale est plus stricte sur les limites d’architecture que le périmètre large de la plateforme CI : -- les changements de production du cœur exécutent la vérification de types prod du cœur et tests du cœur, plus le lint/les gardes du cœur ; -- les changements concernant uniquement les tests du cœur exécutent seulement la vérification de types des tests du cœur plus le lint du cœur ; -- les changements de production des plugins exécutent la vérification de types prod des plugins et tests des plugins, plus le lint des plugins ; -- les changements concernant uniquement les tests des plugins exécutent la vérification de types des tests des plugins plus le lint des plugins ; -- les changements du Plugin SDK public ou du contrat de plugin s’étendent à la vérification de types des plugins parce que les plugins dépendent de ces contrats du cœur (les balayages d’extensions Vitest restent un travail de test explicite) ; -- les augmentations de version limitées aux métadonnées de release exécutent des vérifications ciblées de version/configuration/dépendances racine ; -- les changements racine/configuration inconnus échouent prudemment vers toutes les voies de vérification. +- les changements de production du cœur exécutent le typecheck de production du cœur et des tests du cœur, ainsi que le lint/les gardes du cœur ; +- les changements limités aux tests du cœur n’exécutent que le typecheck des tests du cœur et le lint du cœur ; +- les changements de production d’extension exécutent le typecheck de production et de test des extensions, ainsi que le lint des extensions ; +- les changements limités aux tests d’extension exécutent le typecheck des tests d’extension et le lint des extensions ; +- les changements publics du SDK de Plugin ou des contrats de Plugin s’étendent au typecheck des extensions, car les extensions dépendent de ces contrats du cœur (les balayages Vitest d’extensions restent un travail de test explicite) ; +- les incréments de version limités aux métadonnées de release exécutent des vérifications ciblées de version/configuration/dépendances racine ; +- les changements racine/config inconnus échouent prudemment vers toutes les voies de vérification. -Le routage local des tests modifiés se trouve dans `scripts/test-projects.test-support.mjs` et est intentionnellement moins coûteux que `check:changed` : les modifications directes de tests s’exécutent elles-mêmes, les modifications de source privilégient les correspondances explicites, puis les tests frères et les dépendants du graphe d’import. La configuration partagée de livraison group-room fait partie des correspondances explicites : les changements apportés à la configuration des réponses visibles de groupe, au mode de livraison des réponses source ou au prompt système de l’outil de message passent par les tests de réponse du cœur, plus les régressions de livraison Discord et Slack, afin qu’un changement de valeur par défaut partagée échoue avant le premier push de PR. Utilisez `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` uniquement lorsque le changement est suffisamment global au harnais pour que l’ensemble mappé peu coûteux ne soit pas un proxy fiable. +Le routage local des tests modifiés se trouve dans `scripts/test-projects.test-support.mjs` et est volontairement moins coûteux que `check:changed` : les modifications directes de tests exécutent ces tests eux-mêmes, les modifications de source privilégient les mappings explicites, puis les tests voisins et les dépendants du graphe d’import. La configuration partagée de livraison de salle de groupe fait partie des mappings explicites : les changements apportés à la configuration de réponse visible du groupe, au mode de livraison des réponses source ou au prompt système de l’outil de messages passent par les tests de réponse du cœur ainsi que par les régressions de livraison Discord et Slack, afin qu’un changement de valeur par défaut partagée échoue avant le premier push de PR. Utilisez `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` uniquement lorsque le changement touche assez largement le harnais pour que l’ensemble mappé peu coûteux ne soit pas un proxy fiable. ## Validation Testbox -Exécutez Testbox depuis la racine du dépôt et privilégiez une boîte fraîche préchauffée pour les preuves larges. Avant de consacrer une porte lente à une boîte réutilisée, expirée ou qui vient de signaler une synchronisation inhabituellement volumineuse, exécutez d’abord `pnpm testbox:sanity` dans la boîte. +Exécutez Testbox depuis la racine du dépôt et privilégiez une box fraîche préchauffée pour les preuves larges. Avant de consacrer une porte lente à une box réutilisée, expirée ou venant de signaler une synchronisation anormalement volumineuse, exécutez d’abord `pnpm testbox:sanity` dans la box. -La vérification de cohérence échoue rapidement lorsque des fichiers racine requis comme `pnpm-lock.yaml` ont disparu ou lorsque `git status --short` affiche au moins 200 suppressions suivies. Cela signifie généralement que l’état de synchronisation distant n’est pas une copie fiable de la PR ; arrêtez cette boîte et préchauffez-en une nouvelle au lieu de déboguer l’échec du test produit. Pour les PR avec suppressions massives intentionnelles, définissez `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` pour cette exécution de cohérence. +La vérification de sanité échoue rapidement lorsque des fichiers racine requis comme `pnpm-lock.yaml` ont disparu ou lorsque `git status --short` affiche au moins 200 suppressions suivies. Cela signifie généralement que l’état de synchronisation distant n’est pas une copie fiable de la PR ; arrêtez cette box et préchauffez-en une nouvelle au lieu de déboguer l’échec du test produit. Pour les PRs comportant intentionnellement de nombreuses suppressions, définissez `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` pour cette exécution de sanité. -`pnpm testbox:run` termine également une invocation locale du CLI Blacksmith qui reste en phase de synchronisation plus de cinq minutes sans sortie post-synchronisation. Définissez `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` pour désactiver cette garde, ou utilisez une valeur plus grande en millisecondes pour des diffs locaux inhabituellement volumineux. +`pnpm testbox:run` termine également une invocation locale de la CLI Blacksmith qui reste en phase de synchronisation pendant plus de cinq minutes sans sortie post-synchronisation. Définissez `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` pour désactiver cette garde, ou utilisez une valeur en millisecondes plus élevée pour des diffs locaux exceptionnellement volumineux. ## Connexe diff --git a/docs/fr/concepts/agent-loop.md b/docs/fr/concepts/agent-loop.md index e10920087..87a4e3277 100644 --- a/docs/fr/concepts/agent-loop.md +++ b/docs/fr/concepts/agent-loop.md @@ -1,48 +1,49 @@ --- read_when: - - Vous avez besoin d’une procédure pas à pas exacte de la boucle d’agent ou des événements de cycle de vie - - Vous modifiez la mise en file d’attente des sessions, les écritures de transcription ou le comportement du verrou d’écriture de session -summary: Cycle de vie de la boucle de l’agent, flux et sémantique d’attente -title: Boucle de l’agent + - Vous avez besoin d’une procédure pas à pas exacte de la boucle de l’agent ou des événements du cycle de vie + - Vous modifiez la mise en file d’attente des sessions, les écritures dans la transcription ou le comportement du verrou d’écriture de session +summary: Cycle de vie de la boucle d’agent, flux et sémantique d’attente +title: Boucle d’agent x-i18n: - generated_at: "2026-04-30T07:20:37Z" + generated_at: "2026-04-30T18:38:49Z" model: gpt-5.5 provider: openai - source_hash: 902d543bd71dd517a810d825cbe92e244fe89230f47eeada72477c657a2bec32 + source_hash: 5466893253e1f82482284ff82db56f4c3fca018bf12e4114fad76d37cad954df source_path: concepts/agent-loop.md workflow: 16 --- -Une boucle agentique est l’exécution complète et « réelle » d’un agent : réception → assemblage du contexte → inférence du modèle → +Une boucle agentique est l’exécution « réelle » complète d’un agent : réception → assemblage du contexte → inférence du modèle → exécution d’outils → réponses en streaming → persistance. C’est le chemin faisant autorité qui transforme un message -en actions et en réponse finale, tout en maintenant l’état de session cohérent. +en actions et en réponse finale, tout en conservant un état de session cohérent. -Dans OpenClaw, une boucle est une exécution unique, sérialisée par session, qui émet des événements de cycle de vie et de flux -pendant que le modèle réfléchit, appelle des outils et diffuse la sortie. Ce document explique comment cette boucle authentique est +Dans OpenClaw, une boucle est une exécution unique et sérialisée par session, qui émet des événements de cycle de vie et de flux +pendant que le modèle raisonne, appelle des outils et diffuse la sortie. Ce document explique comment cette boucle authentique est câblée de bout en bout. ## Points d’entrée -- RPC du Gateway : `agent` et `agent.wait`. +- RPC Gateway : `agent` et `agent.wait`. - CLI : commande `agent`. ## Fonctionnement (vue d’ensemble) -1. Le RPC `agent` valide les paramètres, résout la session (sessionKey/sessionId), persiste les métadonnées de session, puis renvoie immédiatement `{ runId, acceptedAt }`. +1. Le RPC `agent` valide les paramètres, résout la session (sessionKey/sessionId), persiste les métadonnées de session, renvoie immédiatement `{ runId, acceptedAt }`. 2. `agentCommand` exécute l’agent : - - résout les valeurs par défaut du modèle + thinking/verbose/trace - - charge l’instantané des Skills + - résout le modèle et les valeurs par défaut de réflexion/verbosité/trace + - charge l’instantané Skills - appelle `runEmbeddedPiAgent` (runtime pi-agent-core) - - émet **lifecycle end/error** si la boucle intégrée n’en émet pas + - émet **lifecycle end/error** si la boucle embarquée n’en émet pas 3. `runEmbeddedPiAgent` : - - sérialise les exécutions via des files d’attente par session + globales - - résout le modèle + le profil d’authentification et construit la session Pi - - s’abonne aux événements Pi et diffuse les deltas assistant/outil - - applique le délai d’expiration -> abandonne l’exécution s’il est dépassé - - renvoie les payloads + les métadonnées d’utilisation -4. `subscribeEmbeddedPiSession` relie les événements pi-agent-core au flux `agent` d’OpenClaw : + - sérialise les exécutions via des files par session et globales + - résout le modèle et le profil d’authentification, puis construit la session pi + - s’abonne aux événements pi et diffuse les deltas assistant/outil + - applique le délai d’expiration -> interrompt l’exécution s’il est dépassé + - pour les tours app-server Codex, interrompt un tour accepté qui cesse de produire une progression app-server avant un événement terminal + - renvoie les payloads et les métadonnées d’utilisation +4. `subscribeEmbeddedPiSession` fait le pont entre les événements pi-agent-core et le flux `agent` d’OpenClaw : - événements d’outil => `stream: "tool"` - - deltas d’assistant => `stream: "assistant"` + - deltas assistant => `stream: "assistant"` - événements de cycle de vie => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`) 5. `agent.wait` utilise `waitForAgentRun` : - attend **lifecycle end/error** pour `runId` @@ -53,137 +54,138 @@ câblée de bout en bout. - Les exécutions sont sérialisées par clé de session (voie de session) et éventuellement via une voie globale. - Cela évite les courses entre outils/sessions et maintient l’historique de session cohérent. - Les canaux de messagerie peuvent choisir des modes de file d’attente (collect/steer/followup) qui alimentent ce système de voies. - Voir [File d’attente des commandes](/fr/concepts/queue). + Voir [File de commandes](/fr/concepts/queue). - Les écritures de transcript sont également protégées par un verrou d’écriture de session sur le fichier de session. Le verrou est - conscient des processus et basé sur un fichier ; il détecte donc les rédacteurs qui contournent la file en processus ou proviennent + conscient des processus et basé sur les fichiers, ce qui lui permet de détecter les rédacteurs qui contournent la file en processus ou proviennent d’un autre processus. -- Les verrous d’écriture de session ne sont pas réentrants par défaut. Si un assistant imbrique intentionnellement l’acquisition du +- Par défaut, les verrous d’écriture de session ne sont pas réentrants. Si un assistant imbrique intentionnellement l’acquisition du même verrou tout en préservant un seul rédacteur logique, il doit l’activer explicitement avec `allowReentrant: true`. ## Préparation de la session + de l’espace de travail - L’espace de travail est résolu et créé ; les exécutions en bac à sable peuvent être redirigées vers une racine d’espace de travail de bac à sable. -- Les Skills sont chargés (ou réutilisés depuis un instantané) et injectés dans l’environnement et le prompt. -- Les fichiers de bootstrap/contexte sont résolus et injectés dans le rapport du prompt système. -- Un verrou d’écriture de session est acquis ; `SessionManager` est ouvert et préparé avant le streaming. Tout chemin ultérieur de - réécriture, Compaction ou troncature du transcript doit prendre le même verrou avant d’ouvrir ou de modifier le fichier de transcript. +- Les Skills sont chargées (ou réutilisées depuis un instantané) et injectées dans l’environnement et le prompt. +- Les fichiers de bootstrap/contexte sont résolus et injectés dans le rapport de prompt système. +- Un verrou d’écriture de session est acquis ; `SessionManager` est ouvert et préparé avant le streaming. Tout + chemin ultérieur de réécriture, de Compaction ou de troncature du transcript doit prendre le même verrou avant d’ouvrir ou + de modifier le fichier de transcript. ## Assemblage du prompt + prompt système -- Le prompt système est construit à partir du prompt de base d’OpenClaw, du prompt des Skills, du contexte de bootstrap et des substitutions par exécution. +- Le prompt système est construit à partir du prompt de base d’OpenClaw, du prompt Skills, du contexte de bootstrap et des remplacements par exécution. - Les limites propres au modèle et les jetons de réserve de Compaction sont appliqués. - Voir [Prompt système](/fr/concepts/system-prompt) pour ce que voit le modèle. -## Points de hook (où intercepter) +## Points de hook (où vous pouvez intercepter) OpenClaw dispose de deux systèmes de hooks : -- **Hooks internes** (hooks Gateway) : scripts pilotés par événements pour les commandes et événements de cycle de vie. -- **Hooks de Plugin** : points d’extension dans le cycle de vie agent/outil et le pipeline du Gateway. +- **Hooks internes** (hooks Gateway) : scripts pilotés par événements pour les commandes et les événements de cycle de vie. +- **Hooks Plugin** : points d’extension dans le cycle de vie agent/outil et le pipeline Gateway. ### Hooks internes (hooks Gateway) - **`agent:bootstrap`** : s’exécute pendant la construction des fichiers de bootstrap, avant la finalisation du prompt système. Utilisez-le pour ajouter/supprimer des fichiers de contexte de bootstrap. -- **Hooks de commande** : `/new`, `/reset`, `/stop` et autres événements de commande (voir le document Hooks). +- **Hooks de commande** : `/new`, `/reset`, `/stop` et autres événements de commande (voir la documentation Hooks). -Voir [Hooks](/fr/automation/hooks) pour la configuration et des exemples. +Voir [Hooks](/fr/automation/hooks) pour la configuration et les exemples. -### Hooks de Plugin (cycle de vie agent + Gateway) +### Hooks Plugin (cycle de vie agent + Gateway) -Ceux-ci s’exécutent dans la boucle agent ou le pipeline du Gateway : +Ils s’exécutent dans la boucle de l’agent ou le pipeline Gateway : - **`before_model_resolve`** : s’exécute avant la session (sans `messages`) pour remplacer de manière déterministe le fournisseur/modèle avant la résolution du modèle. -- **`before_prompt_build`** : s’exécute après le chargement de la session (avec `messages`) pour injecter `prependContext`, `systemPrompt`, `prependSystemContext` ou `appendSystemContext` avant l’envoi du prompt. Utilisez `prependContext` pour du texte dynamique par tour et les champs de contexte système pour des directives stables qui doivent résider dans l’espace du prompt système. -- **`before_agent_start`** : hook de compatibilité hérité qui peut s’exécuter dans l’une ou l’autre phase ; privilégiez les hooks explicites ci-dessus. -- **`before_agent_reply`** : s’exécute après les actions en ligne et avant l’appel LLM, ce qui permet à un Plugin de revendiquer le tour et de renvoyer une réponse synthétique ou de réduire entièrement le tour au silence. -- **`agent_end`** : inspecte la liste finale des messages et les métadonnées d’exécution après la fin. +- **`before_prompt_build`** : s’exécute après le chargement de la session (avec `messages`) pour injecter `prependContext`, `systemPrompt`, `prependSystemContext` ou `appendSystemContext` avant l’envoi du prompt. Utilisez `prependContext` pour le texte dynamique par tour et les champs de contexte système pour les directives stables qui doivent résider dans l’espace du prompt système. +- **`before_agent_start`** : hook de compatibilité hérité qui peut s’exécuter dans l’une ou l’autre phase ; préférez les hooks explicites ci-dessus. +- **`before_agent_reply`** : s’exécute après les actions en ligne et avant l’appel au LLM, ce qui permet à un plugin de prendre en charge le tour et de renvoyer une réponse synthétique ou de réduire entièrement le tour au silence. +- **`agent_end`** : inspecte la liste finale des messages et les métadonnées d’exécution après l’achèvement. - **`before_compaction` / `after_compaction`** : observe ou annote les cycles de Compaction. - **`before_tool_call` / `after_tool_call`** : intercepte les paramètres/résultats d’outil. -- **`before_install`** : inspecte les résultats d’analyse intégrés et bloque éventuellement les installations de Skills ou de Plugin. +- **`before_install`** : inspecte les résultats d’analyse intégrés et bloque éventuellement les installations de skill ou de plugin. - **`tool_result_persist`** : transforme de manière synchrone les résultats d’outil avant leur écriture dans un transcript de session appartenant à OpenClaw. - **`message_received` / `message_sending` / `message_sent`** : hooks de messages entrants + sortants. - **`session_start` / `session_end`** : limites du cycle de vie de session. -- **`gateway_start` / `gateway_stop`** : événements du cycle de vie du Gateway. +- **`gateway_start` / `gateway_stop`** : événements du cycle de vie Gateway. -Règles de décision des hooks pour les protections sortantes/d’outils : +Règles de décision des hooks pour les garde-fous sortants/outils : - `before_tool_call` : `{ block: true }` est terminal et arrête les gestionnaires de priorité inférieure. -- `before_tool_call` : `{ block: false }` est un no-op et n’efface pas un blocage antérieur. +- `before_tool_call` : `{ block: false }` est une absence d’opération et n’efface pas un blocage antérieur. - `before_install` : `{ block: true }` est terminal et arrête les gestionnaires de priorité inférieure. -- `before_install` : `{ block: false }` est un no-op et n’efface pas un blocage antérieur. +- `before_install` : `{ block: false }` est une absence d’opération et n’efface pas un blocage antérieur. - `message_sending` : `{ cancel: true }` est terminal et arrête les gestionnaires de priorité inférieure. -- `message_sending` : `{ cancel: false }` est un no-op et n’efface pas une annulation antérieure. +- `message_sending` : `{ cancel: false }` est une absence d’opération et n’efface pas une annulation antérieure. -Voir [Hooks de Plugin](/fr/plugins/hooks) pour l’API de hook et les détails d’enregistrement. +Voir [Hooks Plugin](/fr/plugins/hooks) pour l’API de hook et les détails d’enregistrement. Les harnesses peuvent adapter ces hooks différemment. Le harness app-server Codex conserve -les hooks de Plugin OpenClaw comme contrat de compatibilité pour les surfaces miroir documentées, -tandis que les hooks natifs Codex restent un mécanisme Codex de plus bas niveau séparé. +les hooks Plugin OpenClaw comme contrat de compatibilité pour les surfaces miroirs documentées, +tandis que les hooks natifs Codex restent un mécanisme Codex de niveau inférieur distinct. ## Streaming + réponses partielles -- Les deltas d’assistant sont diffusés depuis pi-agent-core et émis comme événements `assistant`. -- Le streaming par blocs peut émettre des réponses partielles sur `text_end` ou `message_end`. -- Le streaming de raisonnement peut être émis comme flux distinct ou comme réponses par blocs. -- Voir [Streaming](/fr/concepts/streaming) pour le comportement de découpage et de réponse par blocs. +- Les deltas assistant sont diffusés depuis pi-agent-core et émis comme événements `assistant`. +- Le streaming par bloc peut émettre des réponses partielles soit sur `text_end`, soit sur `message_end`. +- Le streaming du raisonnement peut être émis comme flux séparé ou comme réponses par bloc. +- Voir [Streaming](/fr/concepts/streaming) pour le découpage en fragments et le comportement des réponses par bloc. ## Exécution d’outils + outils de messagerie - Les événements de début/mise à jour/fin d’outil sont émis sur le flux `tool`. - Les résultats d’outil sont assainis pour la taille et les payloads d’image avant journalisation/émission. -- Les envois d’outils de messagerie sont suivis afin de supprimer les confirmations d’assistant en double. +- Les envois d’outils de messagerie sont suivis pour supprimer les confirmations assistant dupliquées. ## Mise en forme des réponses + suppression - Les payloads finaux sont assemblés à partir de : - - texte de l’assistant (et raisonnement facultatif) - - résumés d’outils en ligne (quand verbose + autorisé) - - texte d’erreur de l’assistant quand le modèle échoue + - texte assistant (et raisonnement facultatif) + - résumés d’outils en ligne (quand verbeux + autorisé) + - texte d’erreur assistant quand le modèle échoue - Le jeton silencieux exact `NO_REPLY` / `no_reply` est filtré des payloads sortants. - Les doublons d’outils de messagerie sont supprimés de la liste finale des payloads. -- S’il ne reste aucun payload affichable et qu’un outil a échoué, une réponse d’erreur d’outil de secours est émise +- S’il ne reste aucun payload rendable et qu’un outil a échoué, une réponse de secours d’erreur d’outil est émise (sauf si un outil de messagerie a déjà envoyé une réponse visible par l’utilisateur). ## Compaction + nouvelles tentatives - La Compaction automatique émet des événements de flux `compaction` et peut déclencher une nouvelle tentative. -- Lors d’une nouvelle tentative, les tampons en mémoire et les résumés d’outils sont réinitialisés pour éviter les sorties en double. +- Lors de la nouvelle tentative, les tampons en mémoire et les résumés d’outils sont réinitialisés pour éviter une sortie dupliquée. - Voir [Compaction](/fr/concepts/compaction) pour le pipeline de Compaction. ## Flux d’événements (aujourd’hui) -- `lifecycle` : émis par `subscribeEmbeddedPiSession` (et en secours par `agentCommand`) +- `lifecycle` : émis par `subscribeEmbeddedPiSession` (et en repli par `agentCommand`) - `assistant` : deltas diffusés depuis pi-agent-core - `tool` : événements d’outil diffusés depuis pi-agent-core ## Gestion des canaux de chat -- Les deltas d’assistant sont mis en tampon dans des messages `delta` de chat. +- Les deltas assistant sont mis en tampon dans des messages de chat `delta`. - Un `final` de chat est émis sur **lifecycle end/error**. ## Délais d’expiration - Valeur par défaut de `agent.wait` : 30 s (seulement l’attente). Le paramètre `timeoutMs` remplace cette valeur. -- Runtime de l’agent : `agents.defaults.timeoutSeconds` vaut par défaut 172800 s (48 heures) ; appliqué dans le minuteur d’abandon de `runEmbeddedPiAgent`. -- Runtime Cron : le `timeoutSeconds` isolé du tour d’agent appartient à Cron. Le planificateur démarre ce minuteur au début de l’exécution, abandonne l’exécution sous-jacente à l’échéance configurée, puis exécute un nettoyage borné avant d’enregistrer le délai d’expiration afin qu’une session enfant obsolète ne puisse pas bloquer la voie. -- Récupération de session bloquée : avec les diagnostics activés, `diagnostics.stuckSessionWarnMs` détecte les longues sessions `processing`. Les exécutions intégrées actives, les opérations de réponse actives et les tâches de voie de session actives restent par défaut limitées à des avertissements ; si les diagnostics ne montrent aucun travail actif pour la session, le watchdog libère la voie de session affectée afin que le travail de démarrage en file d’attente puisse s’écouler. -- Délai d’inactivité du modèle : OpenClaw abandonne une requête de modèle quand aucun fragment de réponse n’arrive avant la fenêtre d’inactivité. `models.providers..timeoutSeconds` étend ce watchdog d’inactivité pour les fournisseurs locaux/auto-hébergés lents ; sinon OpenClaw utilise `agents.defaults.timeoutSeconds` quand il est configuré, plafonné à 120 s par défaut. Les exécutions déclenchées par Cron sans délai de modèle ou d’agent explicite désactivent le watchdog d’inactivité et s’appuient sur le délai externe de Cron. -- Délai d’expiration des requêtes HTTP fournisseur : `models.providers..timeoutSeconds` s’applique aux fetchs HTTP de modèle de ce fournisseur, y compris la connexion, les en-têtes, le corps, le délai de requête SDK, la gestion totale d’abandon de fetch protégé et le watchdog d’inactivité du flux du modèle. Utilisez-le pour les fournisseurs locaux/auto-hébergés lents comme Ollama avant d’augmenter le délai d’expiration de tout le runtime de l’agent. +- Runtime de l’agent : valeur par défaut de `agents.defaults.timeoutSeconds` à 172800 s (48 heures) ; appliquée dans le minuteur d’interruption `runEmbeddedPiAgent`. +- Runtime Cron : le `timeoutSeconds` de tour d’agent isolé appartient à cron. Le planificateur démarre ce minuteur au début de l’exécution, interrompt l’exécution sous-jacente à l’échéance configurée, puis lance un nettoyage borné avant d’enregistrer le délai d’expiration afin qu’une session enfant obsolète ne puisse pas bloquer la voie. +- Récupération de session bloquée : avec les diagnostics activés, `diagnostics.stuckSessionWarnMs` détecte les sessions longues en `processing`. Les exécutions embarquées actives, les opérations de réponse actives et les tâches actives de voie de session restent par défaut limitées aux avertissements ; si les diagnostics n’indiquent aucun travail actif pour la session, le watchdog libère la voie de session affectée afin que le travail de démarrage en file puisse s’écouler. +- Délai d’inactivité du modèle : OpenClaw interrompt une requête de modèle quand aucun fragment de réponse n’arrive avant la fenêtre d’inactivité. `models.providers..timeoutSeconds` étend ce watchdog d’inactivité pour les fournisseurs locaux/auto-hébergés lents ; sinon OpenClaw utilise `agents.defaults.timeoutSeconds` lorsqu’il est configuré, plafonné par défaut à 120 s. Les exécutions déclenchées par Cron sans délai explicite de modèle ou d’agent désactivent le watchdog d’inactivité et s’appuient sur le délai externe de Cron. +- Délai d’expiration des requêtes HTTP du fournisseur : `models.providers..timeoutSeconds` s’applique aux fetches HTTP de modèle de ce fournisseur, y compris la connexion, les en-têtes, le corps, le délai d’expiration des requêtes SDK, la gestion totale de l’interruption guarded-fetch et le watchdog d’inactivité du flux de modèle. Utilisez-le pour les fournisseurs locaux/auto-hébergés lents tels qu’Ollama avant d’augmenter le délai d’exécution global de l’agent. ## Où les choses peuvent se terminer tôt -- Délai d’expiration de l’agent (abandon) +- Délai d’expiration de l’agent (interruption) - AbortSignal (annulation) -- Déconnexion du Gateway ou délai d’expiration RPC +- Déconnexion Gateway ou délai d’expiration RPC - Délai d’expiration de `agent.wait` (attente uniquement, n’arrête pas l’agent) ## Connexe - [Outils](/fr/tools) — outils d’agent disponibles -- [Hooks](/fr/automation/hooks) — scripts pilotés par événements déclenchés par les événements du cycle de vie de l’agent +- [Hooks](/fr/automation/hooks) — scripts pilotés par événements déclenchés par les événements de cycle de vie de l’agent - [Compaction](/fr/concepts/compaction) — comment les longues conversations sont résumées -- [Approbations d’exécution](/fr/tools/exec-approvals) — portes d’approbation pour les commandes shell +- [Approbations Exec](/fr/tools/exec-approvals) — barrières d’approbation pour les commandes shell - [Réflexion](/fr/tools/thinking) — configuration du niveau de réflexion/raisonnement diff --git a/docs/fr/concepts/queue.md b/docs/fr/concepts/queue.md index 8816d17a3..24967afb8 100644 --- a/docs/fr/concepts/queue.md +++ b/docs/fr/concepts/queue.md @@ -1,19 +1,19 @@ --- read_when: - Modifier l’exécution ou la concurrence des réponses automatiques - - Explication des modes de /queue ou du comportement d’orientation des messages -summary: Modes de file d’attente de réponse automatique, valeurs par défaut et remplacements par session + - Explication des modes /queue ou du comportement d’orientation des messages +summary: Modes de la file d’attente de réponse automatique, valeurs par défaut et remplacements par session title: File d’attente des commandes x-i18n: - generated_at: "2026-04-30T07:23:47Z" + generated_at: "2026-04-30T18:38:41Z" model: gpt-5.5 provider: openai - source_hash: 2ac0c0ded9558b080714fa4b8be0d552f985911bf19b427020f9654ae4955b2d + source_hash: fbf1bb1ffd4ce06fa138f63e31651b8821226d9c95dd6b93d68326a5fb91fdd0 source_path: concepts/queue.md workflow: 16 --- -Nous sérialisons les exécutions de réponse automatique entrantes (tous les canaux) via une petite file d’attente en processus afin d’éviter les collisions entre plusieurs exécutions d’agent, tout en autorisant un parallélisme sûr entre les sessions. +Nous sérialisons les exécutions de réponse automatique entrantes (tous les canaux) via une petite file d’attente en processus afin d’empêcher plusieurs exécutions d’agent d’entrer en collision, tout en permettant un parallélisme sûr entre les sessions. ## Pourquoi @@ -22,11 +22,11 @@ Nous sérialisons les exécutions de réponse automatique entrantes (tous les ca ## Fonctionnement -- Une file d’attente FIFO consciente des voies vide chaque voie avec une limite de concurrence configurable (1 par défaut pour les voies non configurées ; la voie principale utilise 4 par défaut, les sous-agents 8). -- `runEmbeddedPiAgent` met en file d’attente par **clé de session** (voie `session:`) afin de garantir une seule exécution active par session. -- Chaque exécution de session est ensuite placée dans une **voie globale** (`main` par défaut), de sorte que le parallélisme global est limité par `agents.defaults.maxConcurrent`. +- Une file FIFO tenant compte des voies vide chaque voie avec un plafond de concurrence configurable (1 par défaut pour les voies non configurées ; la voie principale vaut 4 par défaut, les sous-agents 8). +- `runEmbeddedPiAgent` met en file par **clé de session** (voie `session:`) afin de garantir une seule exécution active par session. +- Chaque exécution de session est ensuite mise en file dans une **voie globale** (`main` par défaut) afin que le parallélisme global soit plafonné par `agents.defaults.maxConcurrent`. - Lorsque la journalisation détaillée est activée, les exécutions en file émettent un court avis si elles ont attendu plus d’environ 2 s avant de démarrer. -- Les indicateurs de saisie se déclenchent toujours immédiatement lors de la mise en file (lorsque le canal le prend en charge), de sorte que l’expérience utilisateur reste inchangée pendant l’attente de notre tour. +- Les indicateurs de saisie se déclenchent toujours immédiatement à la mise en file (lorsque le canal le prend en charge), de sorte que l’expérience utilisateur reste inchangée pendant l’attente de notre tour. ## Valeurs par défaut @@ -39,26 +39,26 @@ Lorsqu’elles ne sont pas définies, toutes les surfaces de canaux entrants uti `steer` est la valeur par défaut, car elle garde le tour du modèle actif réactif sans démarrer une seconde exécution de session. Elle vide tous les messages de pilotage arrivés -avant la prochaine limite du modèle. Si l’exécution actuelle ne peut pas accepter le pilotage, -OpenClaw revient à une entrée de file de suivi. +avant la prochaine frontière de modèle. Si l’exécution actuelle ne peut pas accepter le pilotage, +OpenClaw se replie sur une entrée de file de suivi. ## Modes de file d’attente Les messages entrants peuvent piloter l’exécution actuelle, attendre un tour de suivi, ou faire les deux : -- `steer` : met les messages de pilotage en file dans le runtime actif. Pi livre tous les messages de pilotage en attente **après la fin de l’exécution des appels d’outils du tour actuel de l’assistant**, avant le prochain appel LLM ; le serveur d’application Codex reçoit un `turn/steer` groupé. Si l’exécution n’est pas en diffusion active ou si le pilotage est indisponible, OpenClaw revient à une entrée de file de suivi. -- `queue` (hérité) : ancien pilotage un par un. Pi livre un message de pilotage en file à chaque limite du modèle ; le serveur d’application Codex reçoit des requêtes `turn/steer` distinctes. Préférez `steer`, sauf si vous avez besoin du comportement sérialisé précédent. +- `steer` : met en file les messages de pilotage dans le runtime actif. Pi livre tous les messages de pilotage en attente **après que le tour d’assistant actuel a fini d’exécuter ses appels d’outils**, avant le prochain appel LLM ; le serveur d’application Codex reçoit un `turn/steer` groupé. Si l’exécution n’est pas en diffusion active ou si le pilotage n’est pas disponible, OpenClaw se replie sur une entrée de file de suivi. +- `queue` (hérité) : ancien pilotage un par un. Pi livre un message de pilotage en file à chaque frontière de modèle ; le serveur d’application Codex reçoit des requêtes `turn/steer` séparées. Préférez `steer`, sauf si vous avez besoin du comportement sérialisé précédent. - `followup` : met chaque message en file pour un tour d’agent ultérieur après la fin de l’exécution actuelle. -- `collect` : fusionne les messages en file dans un **seul** tour de suivi après la fenêtre de silence. Si les messages ciblent des canaux/fils différents, ils sont vidés individuellement afin de préserver le routage. +- `collect` : regroupe les messages en file dans un **seul** tour de suivi après la fenêtre de silence. Si les messages ciblent différents canaux/fils, ils sont vidés individuellement afin de préserver le routage. - `steer-backlog` (alias `steer+backlog`) : pilote maintenant **et** conserve le même message pour un tour de suivi. - `interrupt` (hérité) : abandonne l’exécution active pour cette session, puis exécute le message le plus récent. -Steer-backlog signifie que vous pouvez obtenir une réponse de suivi après l’exécution pilotée, donc +Steer-backlog signifie que vous pouvez obtenir une réponse de suivi après l’exécution pilotée, de sorte que les surfaces de diffusion peuvent ressembler à des doublons. Préférez `collect`/`steer` si vous voulez une réponse par message entrant. Pour le minutage propre au runtime et le comportement des dépendances, consultez -[File d’attente de pilotage](/fr/concepts/queue-steering). +[File de pilotage](/fr/concepts/queue-steering). Configurez globalement ou par canal via `messages.queue` : @@ -78,21 +78,21 @@ Configurez globalement ou par canal via `messages.queue` : ## Options de file d’attente -Les options s’appliquent à `followup`, `collect` et `steer-backlog` (ainsi qu’à `steer` ou à l’ancien `queue` lorsque le pilotage revient à un suivi) : +Les options s’appliquent à `followup`, `collect` et `steer-backlog` (ainsi qu’à `steer` ou à l’ancien `queue` lorsque le pilotage se replie sur un suivi) : -- `debounceMs` : fenêtre de silence avant de vider les suivis en file. Les nombres nus sont des millisecondes ; les unités `ms`, `s`, `m`, `h` et `d` sont acceptées par les options `/queue`. +- `debounceMs` : fenêtre de silence avant de vider les suivis en file. Les nombres seuls sont en millisecondes ; les unités `ms`, `s`, `m`, `h` et `d` sont acceptées par les options `/queue`. - `cap` : nombre maximal de messages en file par session. Les valeurs inférieures à `1` sont ignorées. -- `drop: "summarize"` : valeur par défaut. Supprime les entrées les plus anciennes en file selon les besoins, conserve des résumés compacts et les injecte comme invite de suivi synthétique. -- `drop: "old"` : supprime les entrées les plus anciennes en file selon les besoins, sans conserver de résumés. +- `drop: "summarize"` : valeur par défaut. Supprime les entrées en file les plus anciennes selon les besoins, conserve des résumés compacts et les injecte comme invite de suivi synthétique. +- `drop: "old"` : supprime les entrées en file les plus anciennes selon les besoins, sans conserver de résumés. - `drop: "new"` : rejette le message le plus récent lorsque la file est déjà pleine. Valeurs par défaut : `debounceMs: 500`, `cap: 20`, `drop: summarize`. -## Précédence +## Priorité Pour la sélection du mode, OpenClaw résout : -1. Remplacement `/queue` par session, en ligne ou stocké. +1. Remplacement `/queue` en ligne ou stocké par session. 2. `messages.queue.byChannel.`. 3. `messages.queue.mode`. 4. Valeur par défaut `steer`. @@ -100,8 +100,8 @@ Pour la sélection du mode, OpenClaw résout : Pour les options, les options `/queue` en ligne ou stockées l’emportent sur la configuration. Ensuite, le debounce propre au canal (`messages.queue.debounceMsByChannel`), les valeurs par défaut de debounce du Plugin, les options globales `messages.queue` et les valeurs par défaut intégrées sont -appliqués. `cap` et `drop` sont des options globales/de session, pas des clés -de configuration par canal. +appliqués. `cap` et `drop` sont des options globales/de session, pas des clés de configuration +par canal. ## Remplacements par session @@ -111,20 +111,21 @@ de configuration par canal. ## Portée et garanties -- S’applique aux exécutions d’agents de réponse automatique sur tous les canaux entrants qui utilisent le pipeline de réponse du Gateway (web WhatsApp, Telegram, Slack, Discord, Signal, iMessage, webchat, etc.). -- La voie par défaut (`main`) s’applique à tout le processus pour les messages entrants et les Heartbeat principaux ; définissez `agents.defaults.maxConcurrent` pour autoriser plusieurs sessions en parallèle. -- Des voies supplémentaires peuvent exister (par exemple `cron`, `cron-nested`, `nested`, `subagent`) afin que les tâches en arrière-plan puissent s’exécuter en parallèle sans bloquer les réponses entrantes. Les tours d’agent Cron isolés occupent un emplacement `cron` pendant que leur exécution d’agent interne utilise `cron-nested` ; les deux utilisent `cron.maxConcurrentRuns`. Les flux `nested` non Cron partagés conservent leur propre comportement de voie. Ces exécutions détachées sont suivies comme des [tâches en arrière-plan](/fr/automation/tasks). +- S’applique aux exécutions d’agent de réponse automatique sur tous les canaux entrants qui utilisent le pipeline de réponse du Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat, etc.). +- La voie par défaut (`main`) est à l’échelle du processus pour les messages entrants et les Heartbeats principaux ; définissez `agents.defaults.maxConcurrent` pour autoriser plusieurs sessions en parallèle. +- Des voies supplémentaires peuvent exister (par exemple `cron`, `cron-nested`, `nested`, `subagent`) afin que les tâches d’arrière-plan puissent s’exécuter en parallèle sans bloquer les réponses entrantes. Les tours d’agent Cron isolés occupent un emplacement `cron` pendant que leur exécution d’agent interne utilise `cron-nested` ; les deux utilisent `cron.maxConcurrentRuns`. Les flux `nested` partagés non-Cron conservent leur propre comportement de voie. Ces exécutions détachées sont suivies comme [tâches d’arrière-plan](/fr/automation/tasks). - Les voies par session garantissent qu’une seule exécution d’agent touche une session donnée à la fois. -- Aucune dépendance externe ni thread de worker en arrière-plan ; TypeScript pur + promesses. +- Aucune dépendance externe ni thread de worker d’arrière-plan ; TypeScript pur + promesses. ## Dépannage - Si les commandes semblent bloquées, activez les journaux détaillés et recherchez les lignes « queued for …ms » pour confirmer que la file se vide. -- Si vous avez besoin de la profondeur de file, activez les journaux détaillés et surveillez les lignes de minutage de la file. -- Lorsque les diagnostics sont activés, les sessions qui restent en `processing` au-delà de `diagnostics.stuckSessionWarnMs` journalisent un avertissement de session bloquée. Les exécutions intégrées actives, les opérations de réponse actives et les tâches de voie actives restent uniquement des avertissements par défaut ; une comptabilité de démarrage périmée sans travail de session actif peut libérer la voie de session concernée afin que le travail en file se vide. +- Si vous avez besoin de la profondeur de file, activez les journaux détaillés et surveillez les lignes de minutage de file. +- Les exécutions du serveur d’application Codex qui acceptent un tour puis cessent d’émettre une progression sont interrompues par l’adaptateur Codex afin que la voie de session active puisse se libérer au lieu d’attendre le délai d’expiration de l’exécution externe. +- Lorsque les diagnostics sont activés, les sessions qui restent en `processing` au-delà de `diagnostics.stuckSessionWarnMs` journalisent un avertissement de session bloquée. Les exécutions intégrées actives, les opérations de réponse actives et les tâches de voie actives restent uniquement des avertissements par défaut ; une comptabilité de démarrage obsolète sans travail de session actif peut libérer la voie de session affectée afin que le travail en file se vide. -## Liens connexes +## Connexe - [Gestion des sessions](/fr/concepts/session) -- [File d’attente de pilotage](/fr/concepts/queue-steering) +- [File de pilotage](/fr/concepts/queue-steering) - [Politique de nouvelle tentative](/fr/concepts/retry) diff --git a/docs/fr/help/testing.md b/docs/fr/help/testing.md index 5d44a729f..78dd33adc 100644 --- a/docs/fr/help/testing.md +++ b/docs/fr/help/testing.md @@ -3,33 +3,33 @@ read_when: - Exécuter les tests localement ou en CI - Ajout de tests de régression pour les bogues de modèle/fournisseur - Débogage du comportement du Gateway + de l’agent -summary: 'Kit de test : suites unitaires/e2e/live, exécuteurs Docker et ce que couvre chaque test' +summary: 'Kit de test : suites unitaires, e2e et live, exécuteurs Docker et ce que couvre chaque test' title: Tests x-i18n: - generated_at: "2026-04-30T07:32:07Z" + generated_at: "2026-04-30T18:38:51Z" model: gpt-5.5 provider: openai - source_hash: c7b506350f11431195cb55c84cb10e99efb5f43b934079528b982627024d1ffc + source_hash: 470a96c6b47c2708950d05adc4a4efba5fe290f0675a131e2888d2d0032d5953 source_path: help/testing.md workflow: 16 --- -OpenClaw comporte trois suites Vitest (unitaire/intégration, e2e, en direct) et un petit ensemble +OpenClaw comporte trois suites Vitest (unitaires/intégration, e2e, live) et un petit ensemble d’exécuteurs Docker. Ce document est un guide « comment nous testons » : -- Ce que couvre chaque suite (et ce qu’elle ne couvre _délibérément_ pas). +- 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, pré-push, débogage). -- Comment les tests en direct découvrent 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 régressions pour des problèmes réels de modèles/fournisseurs. -**La pile QA (qa-lab, qa-channel, voies de transport en direct)** est documentée séparément : +**La pile QA (qa-lab, qa-channel, voies de transport live)** est documentée séparément : - [Vue d’ensemble QA](/fr/concepts/qa-e2e-automation) — architecture, surface de commande, création de scénarios. -- [QA matricielle](/fr/concepts/qa-matrix) — référence pour `pnpm openclaw qa matrix`. -- [Canal QA](/fr/channels/qa-channel) — le plugin de transport synthétique utilisé par les scénarios adossés au dépôt. +- [QA Matrix](/fr/concepts/qa-matrix) — référence pour `pnpm openclaw qa matrix`. +- [Canal QA](/fr/channels/qa-channel) — le Plugin de transport synthétique utilisé par les scénarios adossés au dépôt. -Cette page couvre l’exécution des suites de tests régulières et des exécuteurs Docker/Parallels. La section des exécuteurs spécifiques à QA ci-dessous ([exécuteurs spécifiques à QA](#qa-specific-runners)) liste les invocations `qa` concrètes et renvoie aux références ci-dessus. +Cette page couvre l’exécution des suites de tests régulières et des exécuteurs Docker/Parallels. La section des exécuteurs propres à la QA ci-dessous ([exécuteurs propres à la QA](#qa-specific-runners)) liste les invocations `qa` concrètes et renvoie aux références ci-dessus. ## Démarrage rapide @@ -37,10 +37,10 @@ Cette page couvre l’exécution des suites de tests régulières et des exécut La plupart du temps : - Gate complet (attendu avant un push) : `pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- Exécution locale plus rapide de la suite complète sur une machine spacieuse : `pnpm test:max` +- Exécution locale plus rapide de toute la suite sur une machine spacieuse : `pnpm test:max` - Boucle de surveillance Vitest directe : `pnpm test:watch` -- Le ciblage direct de fichiers achemine désormais aussi les chemins d’extensions/de canaux : `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Privilégiez d’abord les exécutions ciblées lorsque vous itérez sur un seul échec. +- Le ciblage direct de fichier route maintenant aussi les chemins d’extensions/canaux : `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Préférez d’abord les exécutions ciblées lorsque 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` @@ -51,159 +51,158 @@ Lorsque vous touchez aux tests ou voulez davantage de confiance : Lors du débogage de fournisseurs/modèles réels (nécessite de vrais identifiants) : -- Suite live (modèles + sondes Gateway outil/image) : `pnpm test:live` -- Cibler discrètement un fichier live : `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Balayage des modèles live Docker : `pnpm test:docker:live-models` - - Chaque modèle sélectionné exécute maintenant un tour texte plus une petite sonde de type lecture de fichier. - Les modèles dont les métadonnées annoncent une entrée `image` exécutent aussi un minuscule tour image. +- Suite live (modèles + sondes d’outils/images Gateway) : `pnpm test:live` +- Cibler silencieusement un fichier live : `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Balayage de modèles live Docker : `pnpm test:docker:live-models` + - Chaque modèle sélectionné exécute désormais un tour texte plus une petite sonde de type lecture de fichier. + Les modèles dont les métadonnées annoncent une entrée `image` exécutent aussi un petit tour image. Désactivez les sondes supplémentaires avec `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` ou - `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0` lors de l’isolation des échecs de fournisseur. - - Couverture CI : les contrôles quotidiens `OpenClaw Scheduled Live And E2E Checks` et manuels + `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0` lorsque vous isolez des échecs de fournisseur. + - Couverture CI : les workflows quotidiens `OpenClaw Scheduled Live And E2E Checks` et manuels `OpenClaw Release Checks` appellent tous deux le workflow live/E2E réutilisable avec - `include_live_suites: true`, ce qui inclut des tâches de matrice distinctes de modèles live Docker - partitionnées par fournisseur. - - Pour des relances CI ciblées, déclenchez `OpenClaw Live And E2E Checks (Reusable)` + `include_live_suites: true`, ce qui inclut des jobs distincts de matrice de modèles live Docker + répartis par fournisseur. + - Pour des réexécutions CI ciblées, déclenchez `OpenClaw Live And E2E Checks (Reusable)` avec `include_live_suites: true` et `live_models_only: true`. - - Ajoutez les nouveaux secrets de fournisseur à fort signal à `scripts/ci-hydrate-live-auth.sh` - ainsi qu’à `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` et à ses - appelants planifiés/de release. -- Smoke test de discussion liée native Codex : `pnpm test:docker:live-codex-bind` - - Exécute une voie live Docker sur le chemin du serveur d’app Codex, lie un DM Slack synthétique - avec `/codex bind`, exerce `/codex fast` et + - Ajoutez les nouveaux secrets fournisseur à fort signal dans `scripts/ci-hydrate-live-auth.sh` + ainsi que `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` et ses appelants + planifiés/de release. +- Smoke de discussion liée native Codex : `pnpm test:docker:live-codex-bind` + - Exécute une voie live Docker sur le chemin app-server Codex, lie un DM synthétique + Slack avec `/codex bind`, exerce `/codex fast` et `/codex permissions`, puis vérifie qu’une réponse simple et une pièce jointe image passent par la liaison native du Plugin au lieu d’ACP. -- Smoke test du harnais de serveur d’app Codex : `pnpm test:docker:live-codex-harness` - - Exécute les tours d’agent Gateway via le harnais de serveur d’app Codex possédé par le Plugin, +- Smoke du harnais app-server Codex : `pnpm test:docker:live-codex-harness` + - Exécute des tours d’agent Gateway via le harnais app-server Codex possédé par le Plugin, vérifie `/codex status` et `/codex models`, et exerce par défaut les sondes image, - MCP Cron, sous-agent et Guardian. Désactivez la sonde de sous-agent avec - `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0` lors de l’isolation d’autres échecs du - serveur d’app Codex. Pour un contrôle ciblé du sous-agent, désactivez les autres sondes : + cron MCP, sous-agent et Guardian. Désactivez la sonde de sous-agent avec + `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0` lorsque vous isolez d’autres échecs + app-server Codex. Pour une vérification ciblée du sous-agent, désactivez les autres sondes : `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`. Cela quitte après la sonde de sous-agent sauf si `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0` est défini. -- Smoke test de la commande de secours Crestodian : `pnpm test:live:crestodian-rescue-channel` - - Contrôle optionnel avec double sécurité pour la surface de commande de secours du canal de messages. - Il exerce `/crestodian status`, met en file d’attente un changement persistant de modèle, +- Smoke de commande de secours Crestodian : `pnpm test:live:crestodian-rescue-channel` + - Vérification opt-in redondante de la surface de commande de secours du canal de messages. + Elle exerce `/crestodian status`, met en file d’attente un changement de modèle persistant, répond `/crestodian yes`, et vérifie le chemin d’écriture audit/config. -- Smoke test Docker du planificateur Crestodian : `pnpm test:docker:crestodian-planner` - - Exécute Crestodian dans un conteneur sans configuration avec une fausse CLI Claude sur `PATH` - et vérifie que le repli du planificateur approximatif se traduit par une écriture de - configuration typée auditée. -- Smoke test Docker de première exécution Crestodian : `pnpm test:docker:crestodian-first-run` +- Smoke Docker du planificateur Crestodian : `pnpm test:docker:crestodian-planner` + - Exécute Crestodian dans un conteneur sans config avec une fausse CLI Claude dans `PATH` + et vérifie que le fallback de planificateur approximatif se traduit par une écriture de + config typée auditée. +- Smoke Docker de premier lancement Crestodian : `pnpm test:docker:crestodian-first-run` - Démarre depuis un répertoire d’état OpenClaw vide, route `openclaw` nu vers - Crestodian, applique les écritures setup/modèle/agent/Plugin Discord + SecretRef, - valide la configuration, et vérifie les entrées d’audit. Le même chemin de configuration Ring 0 est - aussi couvert dans QA Lab par + Crestodian, applique des écritures setup/modèle/agent/Plugin Discord + SecretRef, + valide la config et vérifie les entrées d’audit. Le même chemin de configuration Ring 0 est + également couvert dans QA Lab par `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. -- Smoke test de coût Moonshot/Kimi : avec `MOONSHOT_API_KEY` défini, exécutez +- Smoke de coût Moonshot/Kimi : avec `MOONSHOT_API_KEY` défini, exécutez `openclaw models list --provider moonshot --json`, puis exécutez un `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` - isolé avec `moonshot/kimi-k2.6`. Vérifiez que le JSON indique Moonshot/K2.6 et que la - transcription de l’assistant stocke le `usage.cost` normalisé. + isolé contre `moonshot/kimi-k2.6`. Vérifiez que le JSON indique Moonshot/K2.6 et que la + transcription assistant stocke `usage.cost` normalisé. -Lorsque 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. +Lorsque vous n’avez besoin que d’un cas en échec, préférez restreindre les tests live via les variables d’environnement de liste d’autorisation décrites ci-dessous. -## Exécuteurs propres à QA +## Exécuteurs propres à la QA -Ces commandes accompagnent les suites de test principales lorsque vous avez besoin du réalisme de QA Lab : +Ces commandes complètent les suites de tests principales lorsque vous avez besoin du réalisme QA-lab : La CI exécute QA Lab dans des workflows dédiés. `Parity gate` s’exécute sur les PR correspondantes et depuis un déclenchement manuel avec des fournisseurs simulés. `QA-Lab - All Lanes` s’exécute chaque nuit sur -`main` et depuis un déclenchement manuel avec la porte de parité simulée, la voie Matrix live, -la voie Telegram live gérée par Convex, et la voie Discord live gérée par Convex comme -tâches parallèles. Les contrôles QA planifiés et de release passent explicitement Matrix `--profile fast`, -tandis que la CLI Matrix et l’entrée de workflow manuelle restent par défaut à -`all` ; un déclenchement manuel peut partitionner `all` en tâches `transport`, `media`, `e2ee-smoke`, +`main` et depuis un déclenchement manuel avec le gate de parité simulé, la voie Matrix live, +la voie Telegram live gérée par Convex et la voie Discord live gérée par Convex comme +jobs parallèles. Les vérifications QA planifiées et de release passent explicitement Matrix `--profile fast`, +tandis que l’entrée par défaut de la CLI Matrix et du workflow manuel reste +`all` ; le déclenchement manuel peut répartir `all` en jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` et `e2ee-cli`. `OpenClaw Release Checks` exécute la parité ainsi que -les voies rapides Matrix et Telegram avant l’approbation de release, en utilisant -`mock-openai/gpt-5.5` pour les contrôles de transport de release afin qu’ils restent déterministes -et évitent le démarrage normal des Plugins de fournisseur. Ces Gateways de transport live désactivent +les voies Matrix rapide et Telegram avant l’approbation de release, en utilisant +`mock-openai/gpt-5.5` pour les vérifications de transport de release afin qu’elles restent déterministes +et évitent le démarrage normal du Plugin fournisseur. Ces Gateway de transport live désactivent la recherche mémoire ; le comportement mémoire reste couvert par les suites de parité QA. -Les partitions de médias live de release complète utilisent -`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, qui contient déjà -`ffmpeg` et `ffprobe`. Les partitions Docker de modèles/backends live utilisent l’image partagée +Les shards média live de release complète utilisent +`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, qui possède déjà +`ffmpeg` et `ffprobe`. Les shards live Docker de modèles/backends utilisent l’image partagée `ghcr.io/openclaw/openclaw-live-test:` construite une seule fois par commit sélectionné, -puis la récupèrent avec `OPENCLAW_SKIP_DOCKER_BUILD=1` au lieu de reconstruire -dans chaque partition. +puis la tirent avec `OPENCLAW_SKIP_DOCKER_BUILD=1` au lieu de reconstruire +dans chaque shard. - `pnpm openclaw qa suite` - Exécute les scénarios QA adossés au dépôt directement sur l’hôte. - - Exécute par défaut plusieurs scénarios sélectionnés en parallèle avec des workers + - Exécute plusieurs scénarios sélectionnés en parallèle par défaut avec des workers Gateway isolés. `qa-channel` utilise par défaut une concurrence de 4 (bornée par le - nombre de scénarios sélectionnés). Utilisez `--concurrency ` pour ajuster le nombre - de workers, ou `--concurrency 1` pour l’ancienne voie série. + nombre de scénarios sélectionnés). Utilisez `--concurrency ` pour ajuster le + nombre de workers, ou `--concurrency 1` pour l’ancienne voie série. - Quitte avec un code non nul si un scénario échoue. Utilisez `--allow-failures` lorsque vous voulez des artefacts sans code de sortie en échec. - - Prend en charge les modes de fournisseur `live-frontier`, `mock-openai` et `aimock`. - `aimock` démarre un serveur de fournisseur local adossé à AIMock pour une couverture - expérimentale des fixtures et des simulations de protocole sans remplacer la voie - `mock-openai` consciente des scénarios. + - Prend en charge les modes fournisseur `live-frontier`, `mock-openai` et `aimock`. + `aimock` démarre un serveur fournisseur local adossé à AIMock pour une couverture expérimentale + de fixtures et de simulations de protocole sans remplacer la voie `mock-openai` + consciente des scénarios. - `pnpm test:gateway:cpu-scenarios` - - Exécute le banc de démarrage Gateway plus un petit paquet de scénarios QA Lab simulés + - Exécute le bench de démarrage Gateway plus un petit pack de scénarios QA Lab simulés (`channel-chat-baseline`, `memory-failure-fallback`, - `gateway-restart-inflight-run`) et écrit un résumé combiné des observations CPU + `gateway-restart-inflight-run`) et écrit un résumé combiné d’observations CPU sous `.artifacts/gateway-cpu-scenarios/`. - - Ne signale par défaut que les observations de CPU chaud soutenu (`--cpu-core-warn` - plus `--hot-wall-warn-ms`), de sorte que les courtes rafales de démarrage sont enregistrées comme métriques - sans ressembler à la régression de Gateway saturée pendant plusieurs minutes. - - Utilise les artefacts `dist` construits ; exécutez d’abord un build lorsque le checkout ne - dispose pas déjà d’une sortie d’exécution fraîche. + - Signale uniquement les observations de CPU chaud soutenues par défaut (`--cpu-core-warn` + plus `--hot-wall-warn-ms`), afin que les courts pics de démarrage soient enregistrés comme métriques + sans ressembler à la régression de Gateway bloquée pendant plusieurs minutes. + - Utilise les artefacts `dist` construits ; lancez d’abord un build lorsque le checkout ne possède pas + déjà de sortie runtime fraîche. - `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 des scénarios que `qa suite` sur l’hôte. - - Réutilise les mêmes indicateurs de sélection 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é : - clés fournisseur basées sur l’environnement, chemin de configuration du fournisseur live QA, et `CODEX_HOME` + - Conserve le même comportement de sélection de scénarios que `qa suite` sur l’hôte. + - Réutilise les mêmes options de sélection fournisseur/modèle que `qa suite`. + - Les exécutions live transmettent les entrées d’auth QA prises en charge et pratiques pour l’invité : + clés fournisseur basées sur l’environnement, chemin de config 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 réécrire via l’espace de travail monté. - - Écrit le rapport et le résumé QA normaux plus les journaux Multipass sous + - Écrit le rapport + résumé QA normaux ainsi que les journaux Multipass sous `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - Démarre le site QA adossé à Docker pour le travail QA de type opérateur. - `pnpm test:docker:npm-onboard-channel-agent` - - Construit une archive npm tarball à partir du checkout actuel, l’installe globalement dans - Docker, exécute l’onboarding non interactif de clé d’API OpenAI, configure Telegram - par défaut, vérifie que l’activation du Plugin installe les dépendances d’exécution à la - demande, exécute doctor, et exécute un tour d’agent local contre un endpoint OpenAI simulé. - - Utilisez `OPENCLAW_NPM_ONBOARD_CHANNEL=discord` pour exécuter la même voie d’installation packagée + - Construit une archive tar npm depuis le checkout courant, l’installe globalement dans + Docker, exécute l’onboarding non interactif par clé API OpenAI, configure Telegram + par défaut, vérifie que l’activation du Plugin installe les dépendances runtime à la demande, + exécute doctor et lance un tour d’agent local contre un endpoint OpenAI simulé. + - Utilisez `OPENCLAW_NPM_ONBOARD_CHANNEL=discord` pour exécuter la même voie d’installation empaquetée avec Discord. - `pnpm test:docker:session-runtime-context` - - Exécute un smoke test Docker déterministe de l’app construite pour les transcriptions de contexte d’exécution - embarqué. Il vérifie que le contexte d’exécution OpenClaw masqué est conservé comme - message personnalisé non affiché au lieu de fuir dans le tour utilisateur visible, - puis ensemence une session JSONL cassée affectée et vérifie que - `openclaw doctor --fix` la réécrit vers la branche active avec une sauvegarde. + - Exécute un smoke Docker déterministe de l’application construite pour les transcriptions de contexte runtime embarqué. + Il vérifie que le contexte runtime OpenClaw caché est persisté comme message personnalisé non affiché + au lieu de fuir dans le tour utilisateur visible, puis amorce un JSONL de session cassée affectée et vérifie + que `openclaw doctor --fix` le réécrit vers la branche active avec une sauvegarde. - `pnpm test:docker:npm-telegram-live` - - Installe un package candidat OpenClaw dans Docker, exécute l’onboarding du package installé, - configure Telegram via la CLI installée, puis réutilise la voie QA Telegram live - avec ce package installé comme Gateway SUT. - - La valeur par défaut est `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta` ; définissez + - Installe un candidat de package OpenClaw dans Docker, exécute l’onboarding du package installé, + configure Telegram via la CLI installée, puis réutilise la voie QA Telegram live avec ce package + installé comme Gateway SUT. + - Utilise par défaut `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta` ; définissez `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` ou - `OPENCLAW_CURRENT_PACKAGE_TGZ` pour tester une archive tarball locale résolue au lieu de - l’installation depuis le registre. + `OPENCLAW_CURRENT_PACKAGE_TGZ` pour tester une archive tar locale résolue au lieu de + l’installer depuis le registre. - Utilise les mêmes identifiants d’environnement Telegram ou la même source d’identifiants Convex que `pnpm openclaw qa telegram`. Pour l’automatisation CI/release, définissez - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` plus + `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` ainsi que `OPENCLAW_QA_CONVEX_SITE_URL` et le secret de rôle. Si `OPENCLAW_QA_CONVEX_SITE_URL` et un secret de rôle Convex sont présents en CI, - le wrapper Docker sélectionne automatiquement Convex. + le wrapper Docker sélectionne Convex automatiquement. - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` remplace le - `OPENCLAW_QA_CREDENTIAL_ROLE` partagé uniquement pour cette voie. + `OPENCLAW_QA_CREDENTIAL_ROLE` partagé pour cette voie uniquement. - GitHub Actions expose cette voie comme workflow mainteneur manuel - `NPM Telegram Beta E2E`. Elle ne s’exécute pas lors d’un merge. Le workflow utilise l’environnement - `qa-live-shared` et des baux d’identifiants CI Convex. -- GitHub Actions expose aussi `Package Acceptance` pour une preuve produit exécutée en parallèle - contre un package candidat. Il accepte une ref de confiance, une spécification npm publiée, - une URL d’archive tarball HTTPS plus SHA-256, ou un artefact tarball d’une autre exécution, téléverse + `NPM Telegram Beta E2E`. Elle ne s’exécute pas à la fusion. Le workflow utilise l’environnement + `qa-live-shared` et les baux d’identifiants CI Convex. +- GitHub Actions expose également `Package Acceptance` pour une preuve produit exécutée à côté + contre un package candidat. Il accepte une ref approuvée, une spécification npm publiée, + une URL d’archive tar HTTPS plus SHA-256, ou un artefact d’archive tar d’une autre exécution, téléverse le `openclaw-current.tgz` normalisé comme `package-under-test`, puis exécute le - planificateur Docker E2E existant avec des profils de voie smoke, package, product, full ou custom. - Définissez `telegram_mode=mock-openai` ou `live-frontier` pour exécuter le - workflow QA Telegram contre le même artefact `package-under-test`. - - Dernière preuve produit beta : + planificateur Docker E2E existant avec les profils de voie smoke, package, product, full ou custom. + Définissez `telegram_mode=mock-openai` ou `live-frontier` pour exécuter le workflow QA Telegram + contre le même artefact `package-under-test`. + - Dernière preuve produit bêta : ```bash gh workflow run package-acceptance.yml --ref main \ @@ -213,7 +212,7 @@ gh workflow run package-acceptance.yml --ref main \ -f telegram_mode=mock-openai ``` -- La preuve par URL exacte d’archive tarball nécessite un condensat : +- La preuve par URL exacte d’archive tar nécessite un condensat : ```bash gh workflow run package-acceptance.yml --ref main \ @@ -223,7 +222,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- La preuve d’artefact télécharge une archive tarball depuis une autre exécution d’Actions : +- La preuve par artefact télécharge un artefact tarball depuis une autre exécution Actions : ```bash gh workflow run package-acceptance.yml --ref main \ @@ -234,78 +233,77 @@ gh workflow run package-acceptance.yml --ref main \ ``` - `pnpm test:docker:bundled-channel-deps` - - Empaquète et installe la build OpenClaw actuelle dans Docker, démarre le Gateway + - Empaquette et installe la version actuelle d’OpenClaw dans Docker, démarre le Gateway avec OpenAI configuré, puis active les canaux/plugins groupés via des modifications de configuration. - Vérifie que la découverte de configuration laisse absentes les dépendances - d’exécution des plugins non configurées, que le premier Gateway configuré - ou la première exécution de doctor installe à la demande les dépendances - d’exécution de chaque plugin groupé, et qu’un second redémarrage ne - réinstalle pas les dépendances déjà activées. - - Installe aussi une base de référence npm plus ancienne connue, active Telegram avant d’exécuter - `openclaw update --tag `, et vérifie que le doctor - post-mise à jour du candidat répare les dépendances d’exécution des canaux groupés sans - réparation postinstall côté harness. + d’exécution des plugins non configurés, que la première exécution configurée + du Gateway ou de doctor installe à la demande les dépendances d’exécution de + chaque plugin groupé, et qu’un second redémarrage ne réinstalle pas les + dépendances déjà activées. + - Installe aussi une base npm plus ancienne connue, active Telegram avant + d’exécuter `openclaw update --tag `, et vérifie que le doctor + post-mise à jour du candidat répare les dépendances d’exécution des canaux + groupés sans réparation post-installation côté harnais. - `pnpm test:parallels:npm-update` - - Exécute le smoke de mise à jour d’installation empaquetée native sur des invités Parallels. Chaque - plateforme sélectionnée installe d’abord le package de référence demandé, puis exécute + - Exécute le smoke test natif de mise à jour d’installation empaquetée sur des invités Parallels. Chaque + plateforme sélectionnée installe d’abord le paquet de base demandé, puis exécute la commande `openclaw update` installée dans le même invité et vérifie la - version installée, l’état de mise à jour, la disponibilité du gateway et un tour d’agent - local. + version installée, l’état de mise à jour, la disponibilité du Gateway, et un + tour d’agent local. - Utilisez `--platform macos`, `--platform windows` ou `--platform linux` pendant l’itération sur un invité. Utilisez `--json` pour le chemin de l’artefact de résumé et - l’état par lane. - - La lane OpenAI utilise `openai/gpt-5.5` par défaut pour la preuve live de tour d’agent. - Passez `--model ` ou définissez + l’état par voie. + - La voie OpenAI utilise `openai/gpt-5.5` par défaut pour la preuve live du tour + d’agent. Passez `--model ` ou définissez `OPENCLAW_PARALLELS_OPENAI_MODEL` lorsque vous validez délibérément un autre modèle OpenAI. - - Encadrez les longues exécutions locales avec un timeout hôte afin que les blocages du transport Parallels ne - consomment pas le reste de la fenêtre de test : + - Encapsulez les longues exécutions locales dans un délai d’expiration hôte afin que les + blocages de transport Parallels ne puissent pas consommer le reste de la fenêtre de test : ```bash timeout --foreground 150m pnpm test:parallels:npm-update -- --json timeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json ``` - - Le script écrit des journaux de lanes imbriqués sous `/tmp/openclaw-parallels-npm-update.*`. + - Le script écrit des journaux de voies imbriqués sous `/tmp/openclaw-parallels-npm-update.*`. Inspectez `windows-update.log`, `macos-update.log` ou `linux-update.log` - avant de supposer que le wrapper externe est bloqué. - - La mise à jour Windows peut passer 10 à 15 minutes dans la réparation doctor/dépendances - d’exécution post-mise à jour sur un invité froid ; cela reste sain quand le journal - de débogage npm imbriqué progresse. - - N’exécutez pas ce wrapper agrégé en parallèle avec les lanes smoke Parallels + avant de supposer que l’enveloppe extérieure est bloquée. + - La mise à jour Windows peut passer 10 à 15 minutes dans la réparation + post-mise à jour des dépendances doctor/runtime sur un invité froid ; cela reste + sain lorsque le journal de débogage npm imbriqué progresse. + - N’exécutez pas cette enveloppe agrégée en parallèle avec des voies smoke Parallels macOS, Windows ou Linux individuelles. Elles partagent l’état de VM et peuvent entrer en collision lors de - la restauration de snapshot, du service de package ou de l’état du gateway invité. + la restauration d’instantané, du service de paquets ou de l’état du gateway invité. - La preuve post-mise à jour exécute la surface normale des plugins groupés, car - les façades de capacités comme la parole, la génération d’images et la compréhension - des médias sont chargées via les API d’exécution groupées même lorsque le tour + les façades de capacités telles que la parole, la génération d’images et la + compréhension des médias sont chargées via les API d’exécution groupées même lorsque le tour d’agent lui-même vérifie seulement une réponse textuelle simple. - `pnpm openclaw qa aimock` - - Démarre uniquement le serveur fournisseur AIMock local pour les tests smoke - directs du protocole. + - Démarre uniquement le serveur fournisseur AIMock local pour des smoke tests directs du protocole. - `pnpm openclaw qa matrix` - - Exécute la lane QA live Matrix contre un homeserver Tuwunel jetable basé sur Docker. Checkout source uniquement — les installations empaquetées ne livrent pas `qa-lab`. + - Exécute la voie QA live Matrix contre un homeserver Tuwunel jetable adossé à Docker. Checkout source uniquement — les installations empaquetées n’expédient pas `qa-lab`. - CLI complète, catalogue de profils/scénarios, variables d’environnement et disposition des artefacts : [QA Matrix](/fr/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Exécute la lane QA live Telegram contre un vrai groupe privé avec les jetons de bot driver et 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’id de groupe doit être l’id numérique du chat Telegram. - - Prend en charge `--credential-source convex` pour des identifiants mutualisés partagés. Utilisez le mode env par défaut, ou définissez `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` pour opter pour les leases mutualisés. - - Se termine avec un code non nul si un scénario échoue. Utilisez `--allow-failures` lorsque vous - voulez des artefacts sans code de sortie d’échec. - - Nécessite deux bots distincts dans le même groupe privé, avec le bot SUT exposant un nom d’utilisateur Telegram. - - Pour une observation bot-à-bot stable, activez le mode Bot-to-Bot Communication Mode dans `@BotFather` pour les deux bots et assurez-vous que le bot driver peut observer le trafic de bots du groupe. - - Écrit un rapport QA Telegram, un résumé et un artefact de messages observés sous `.artifacts/qa-e2e/...`. Les scénarios avec réponse incluent le RTT entre la demande d’envoi du driver et la réponse SUT observée. + - Exécute la voie QA live Telegram contre un vrai groupe privé avec les jetons des bots pilote et SUT provenant de l’environnement. + - Requiert `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 les identifiants mutualisés partagés. Utilisez le mode environnement par défaut, ou définissez `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` pour opter pour des baux mutualisés. + - Termine avec un code non nul si un scénario échoue. Utilisez `--allow-failures` lorsque vous + voulez des artefacts sans code de sortie en échec. + - Requiert deux bots distincts dans le même groupe privé, le bot SUT exposant un nom d’utilisateur Telegram. + - Pour une observation bot-à-bot stable, activez le mode de communication bot-à-bot dans `@BotFather` pour les deux bots et assurez-vous que le bot pilote peut observer le trafic des bots du groupe. + - Écrit un rapport QA Telegram, un résumé et un artefact de messages observés sous `.artifacts/qa-e2e/...`. Les scénarios de réponse incluent le RTT entre la requête d’envoi du pilote et la réponse SUT observée. -Les lanes de transport live partagent un contrat standard afin que les nouveaux transports ne divergent pas ; la matrice de couverture par lane se trouve dans [Vue d’ensemble QA → Couverture du transport live](/fr/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` est la suite synthétique large et ne fait pas partie de cette matrice. +Les voies de transport live partagent un contrat standard afin que les nouveaux transports ne divergent pas ; la matrice de couverture par voie se trouve dans [Aperçu QA → Couverture des transports live](/fr/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` est la vaste suite synthétique et ne fait pas partie de cette matrice. ### Identifiants Telegram partagés via Convex (v1) Lorsque `--credential-source convex` (ou `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) est activé pour -`openclaw qa telegram`, le lab QA acquiert un lease exclusif depuis un pool basé sur Convex, envoie des heartbeats -pour ce lease pendant l’exécution de la lane, et libère le lease à l’arrêt. +`openclaw qa telegram`, le laboratoire QA acquiert un bail exclusif depuis un pool adossé à Convex, envoie des heartbeats +pour ce bail pendant l’exécution de la voie, et libère le bail à l’arrêt. -Scaffold de projet Convex de référence : +Échafaudage de référence du projet Convex : - `qa/convex-credential-broker/` @@ -317,7 +315,7 @@ Variables d’environnement requises : - `OPENCLAW_QA_CONVEX_SECRET_CI` pour `ci` - Sélection du rôle d’identifiants : - CLI : `--credential-role maintainer|ci` - - Valeur par défaut env : `OPENCLAW_QA_CREDENTIAL_ROLE` (par défaut `ci` en CI, sinon `maintainer`) + - Valeur par défaut de l’environnement : `OPENCLAW_QA_CREDENTIAL_ROLE` (par défaut `ci` en CI, sinon `maintainer`) Variables d’environnement facultatives : @@ -326,15 +324,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` (id de trace facultatif) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` autorise les URL Convex `http://` en loopback pour le développement local uniquement. +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (identifiant de trace facultatif) +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` autorise les URL Convex `http://` en local loopback pour le développement local uniquement. -`OPENCLAW_QA_CONVEX_SITE_URL` doit utiliser `https://` en fonctionnement normal. +`OPENCLAW_QA_CONVEX_SITE_URL` devrait utiliser `https://` en fonctionnement normal. -Les commandes d’administration maintainer (ajout/suppression/liste du pool) nécessitent +Les commandes d’administration mainteneur (ajout/suppression/liste du pool) requièrent spécifiquement `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -Helpers CLI pour les maintainers : +Assistants CLI pour les mainteneurs : ```bash pnpm openclaw qa credentials doctor @@ -344,11 +342,11 @@ pnpm openclaw qa credentials remove --credential-id ``` Utilisez `doctor` avant les exécutions live pour vérifier l’URL du site Convex, les secrets du courtier, -le préfixe d’endpoint, le timeout HTTP et l’accessibilité admin/liste sans imprimer -les valeurs secrètes. Utilisez `--json` pour une sortie lisible par machine dans les scripts et les utilitaires -CI. +le préfixe de point de terminaison, le délai d’expiration HTTP, et l’accessibilité admin/liste sans afficher +les valeurs secrètes. Utilisez `--json` pour une sortie lisible par machine dans les scripts et +les utilitaires CI. -Contrat d’endpoint par défaut (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`) : +Contrat de point de terminaison par défaut (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`) : - `POST /acquire` - Requête : `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` @@ -360,26 +358,26 @@ Contrat d’endpoint par défaut (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentia - `POST /release` - Requête : `{ kind, ownerId, actorRole, credentialId, leaseToken }` - Succès : `{ status: "ok" }` (ou `2xx` vide) -- `POST /admin/add` (secret maintainer uniquement) +- `POST /admin/add` (secret mainteneur uniquement) - Requête : `{ kind, actorId, payload, note?, status? }` - Succès : `{ status: "ok", credential }` -- `POST /admin/remove` (secret maintainer uniquement) +- `POST /admin/remove` (secret mainteneur uniquement) - Requête : `{ credentialId, actorId }` - Succès : `{ status: "ok", changed, credential }` - - Garde de lease actif : `{ status: "error", code: "LEASE_ACTIVE", ... }` -- `POST /admin/list` (secret maintainer uniquement) + - Garde de bail actif : `{ status: "error", code: "LEASE_ACTIVE", ... }` +- `POST /admin/list` (secret mainteneur uniquement) - Requête : `{ kind?, status?, includePayload?, limit? }` - Succès : `{ status: "ok", credentials, count }` -Forme du payload pour le type Telegram : +Forme de charge utile pour le type Telegram : - `{ groupId: string, driverToken: string, sutToken: string }` -- `groupId` doit être une chaîne d’id de chat Telegram numérique. -- `admin/add` valide cette forme pour `kind: "telegram"` et rejette les payloads mal formés. +- `groupId` doit être une chaîne d’identifiant numérique de chat Telegram. +- `admin/add` valide cette forme pour `kind: "telegram"` et rejette les charges utiles mal formées. -### Ajouter un canal à QA +### Ajouter un canal à la QA -L’architecture et les noms des helpers de scénario pour les nouveaux adaptateurs de canal se trouvent dans [Vue d’ensemble QA → Ajouter un canal](/fr/concepts/qa-e2e-automation#adding-a-channel). Le minimum requis : implémenter le runner de transport sur le seam hôte `qa-lab` partagé, déclarer `qaRunners` dans le manifeste du plugin, monter sous `openclaw qa `, et écrire les scénarios sous `qa/scenarios/`. +L’architecture et les noms des assistants de scénarios pour les nouveaux adaptateurs de canal se trouvent dans [Aperçu QA → Ajouter un canal](/fr/concepts/qa-e2e-automation#adding-a-channel). Le minimum requis : implémenter le runner de transport sur la couture hôte partagée `qa-lab`, déclarer `qaRunners` dans le manifeste du plugin, monter comme `openclaw qa `, et écrire des scénarios sous `qa/scenarios/`. ## Suites de tests (ce qui s’exécute où) @@ -388,226 +386,260 @@ Considérez les suites comme un « réalisme croissant » (et une instabilité/u ### Unitaire / intégration (par défaut) - Commande : `pnpm test` -- Config : les exécutions non ciblées utilisent l’ensemble de shards `vitest.full-*.config.ts` et peuvent étendre les shards multi-projets en configs par projet pour la planification parallèle -- Fichiers : inventaires core/unit sous `src/**/*.test.ts`, `packages/**/*.test.ts` et `test/**/*.test.ts` ; les tests unitaires d’UI s’exécutent dans le shard dédié `unit-ui` +- Configuration : les exécutions non ciblées utilisent l’ensemble de shards `vitest.full-*.config.ts` et peuvent étendre les shards multi-projets en configurations par projet pour la planification parallèle +- Fichiers : inventaires cœur/unitaires sous `src/**/*.test.ts`, `packages/**/*.test.ts` et `test/**/*.test.ts` ; les tests unitaires UI s’exécutent dans le shard dédié `unit-ui` - Portée : - Tests unitaires purs - - Tests d’intégration in-process (authentification gateway, routage, outillage, parsing, config) - - Régressions déterministes pour les bugs connus + - Tests d’intégration en processus (authentification du gateway, routage, outillage, analyse, configuration) + - Régressions déterministes pour les bogues connus - Attentes : - S’exécute en CI - Aucune vraie clé requise - - Doit être rapide et stable - - Les tests du résolveur et du chargeur de surface publique doivent prouver le comportement de fallback large de `api.js` et - `runtime-api.js` avec de minuscules fixtures de plugin générées, pas avec - les API source de vrais plugins groupés. Les chargements de vraies API de plugin appartiennent aux - suites de contrat/intégration possédées par les plugins. + - Devrait être rapide et stable + - Les tests du résolveur et du chargeur de surface publique doivent prouver le comportement de repli large de `api.js` et + `runtime-api.js` avec de minuscules fixtures de plugins générées, et non avec + les API sources réelles des plugins groupés. Les chargements réels d’API de plugin relèvent des + suites de contrat/intégration détenues par les plugins. - + - - Les exécutions non ciblées de `pnpm test` lancent douze configurations de fragments plus petites (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) au lieu d’un unique énorme processus natif de projet racine. Cela réduit le pic de RSS sur les machines chargées et évite que le travail auto-reply/extensions affame des suites sans rapport. - - `pnpm test --watch` utilise toujours le graphe de projet 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` acheminent d’abord les cibles explicites de fichiers/répertoires via des voies limitées au périmètre concerné, afin que `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` évite de payer le coût complet de démarrage du projet racine. - - `pnpm test:changed` développe par défaut les chemins git modifiés en voies limitées peu coûteuses : modifications directes de tests, fichiers frères `*.test.ts`, correspondances source explicites et dépendants du graphe d’import local. Les modifications de config/setup/package ne lancent pas largement les tests, sauf si vous utilisez explicitement `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. - - `pnpm check:changed` est la barrière normale de vérification locale intelligente pour les travaux étroits. Elle classe le diff en core, tests core, extensions, tests d’extension, apps, docs, métadonnées de release, outillage Docker live et outillage, puis exécute les commandes de typecheck, lint et garde correspondantes. Elle n’exécute pas les tests Vitest ; appelez `pnpm test:changed` ou un `pnpm test ` explicite pour fournir une preuve par test. Les montées de version limitées aux métadonnées de release exécutent des vérifications ciblées de version/config/dépendance racine, avec une garde qui rejette les modifications de package hors du champ de version de premier niveau. - - Les modifications du harnais ACP Docker live exécutent des vérifications ciblées : syntaxe shell pour les scripts d’auth Docker live et essai à blanc du planificateur Docker live. Les modifications de `package.json` ne sont incluses que lorsque le diff est limité à `scripts["test:docker:live-*"]` ; les modifications de dépendances, d’exports, de version et d’autres surfaces de package utilisent toujours les gardes plus larges. - - Les tests unitaires légers en import issus des agents, commandes, plugins, helpers auto-reply, `plugin-sdk` et zones utilitaires pures similaires passent par la voie `unit-fast`, qui ignore `test/setup-openclaw-runtime.ts` ; les fichiers à état ou fortement liés au runtime restent sur les voies existantes. - - Certains fichiers source helpers de `plugin-sdk` et `commands` associent aussi les exécutions en mode modifié à des tests frères explicites dans ces voies légères, afin que les modifications de helpers évitent de relancer toute la suite lourde de ce répertoire. - - `auto-reply` dispose de compartiments dédiés pour les helpers core de premier niveau, les tests d’intégration `reply.*` de premier niveau et le sous-arbre `src/auto-reply/reply/**`. La CI divise en plus le sous-arbre reply en fragments agent-runner, dispatch et commands/state-routing, afin qu’un compartiment lourd en imports ne possède pas toute la queue Node. - - La CI normale PR/main ignore volontairement le balayage groupé des extensions et le fragment réservé aux releases `agentic-plugins`. Full Release Validation déclenche le workflow enfant distinct `Plugin Prerelease` pour ces suites fortement axées plugins/extensions sur les release candidates. + - Les exécutions non ciblées de `pnpm test` utilisent douze configurations d’éclats plus petites (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) au lieu d’un unique énorme processus natif de projet racine. Cela réduit le RSS maximal sur les machines chargées et évite que le travail d’auto-réponse/extension n’affame des suites sans rapport. + - `pnpm test --watch` utilise toujours le graphe de projets racine natif `vitest.config.ts`, car une boucle de surveillance multi-éclats n’est pas pratique. + - `pnpm test`, `pnpm test:watch` et `pnpm test:perf:imports` acheminent d’abord les cibles explicites de fichiers/répertoires vers des voies ciblées, de sorte que `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 par défaut les chemins git modifiés en voies ciblées peu coûteuses : modifications directes de tests, fichiers frères `*.test.ts`, correspondances explicites de sources et dépendants locaux du graphe d’importation. Les modifications de configuration, d’initialisation ou de package ne lancent pas largement les tests, sauf si vous utilisez explicitement `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. + - `pnpm check:changed` est la barrière normale de vérification locale intelligente pour les travaux étroits. Elle classe le diff en noyau, tests du noyau, extensions, tests d’extension, applications, docs, métadonnées de publication, outillage Docker live et outillage, puis exécute les commandes de typecheck, lint et garde correspondantes. Elle n’exécute pas les tests Vitest ; appelez `pnpm test:changed` ou un `pnpm test ` explicite pour une preuve par les tests. Les montées de version limitées aux métadonnées de publication exécutent des vérifications ciblées de version/configuration/dépendances racine, avec une garde qui rejette les changements de package hors du champ de version de premier niveau. + - Les modifications du harnais ACP Docker live exécutent des vérifications ciblées : syntaxe shell pour les scripts d’authentification Docker live et essai à blanc du planificateur Docker live. Les changements de `package.json` ne sont inclus que lorsque le diff est limité à `scripts["test:docker:live-*"]` ; les modifications de dépendances, d’exportations, de version et d’autres surfaces de package utilisent toujours les gardes plus larges. + - Les tests unitaires légers à l’importation provenant des agents, commandes, plugins, assistants d’auto-réponse, de `plugin-sdk` et de zones utilitaires pures similaires passent par la voie `unit-fast`, qui ignore `test/setup-openclaw-runtime.ts` ; les fichiers avec état ou lourds en exécution restent sur les voies existantes. + - Certains fichiers source d’assistance `plugin-sdk` et `commands` sélectionnés mappent aussi les exécutions en mode modifié vers des tests frères 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 de compartiments dédiés pour les assistants du noyau de premier niveau, les tests d’intégration `reply.*` de premier niveau et le sous-arbre `src/auto-reply/reply/**`. La CI divise en outre le sous-arbre reply en éclats agent-runner, dispatch et commands/state-routing afin qu’un compartiment lourd en importations ne possède pas toute la queue Node. + - La CI normale PR/main ignore intentionnellement le balayage par lot des extensions et l’éclat `agentic-plugins` réservé aux publications. La validation complète de publication déclenche le workflow enfant séparé `Plugin Prerelease` pour ces suites lourdes en plugins/extensions sur les candidats de publication. - + - - Lorsque vous modifiez les entrées de découverte des outils de message ou le contexte runtime de Compaction, conservez les deux niveaux de couverture. - - Ajoutez des régressions helpers ciblées pour les limites de routage pur et de normalisation. - - Maintenez en bon état les suites d’intégration du runner intégré : + - Lorsque vous modifiez les entrées de découverte d’outils de message ou le contexte + d’exécution de Compaction, conservez les deux niveaux de couverture. + - Ajoutez des régressions ciblées d’assistants pour les frontières pures de routage + et de normalisation. + - Gardez les suites d’intégration du runner intégré en bon état : `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.test.ts` et `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Ces suites vérifient que les ids limités au périmètre concerné et le comportement de Compaction circulent toujours par les vrais chemins `run.ts` / `compact.ts` ; les tests limités aux helpers ne remplacent pas suffisamment ces chemins d’intégration. + - Ces suites vérifient que les ids ciblés et le comportement de Compaction continuent de circuler + par les vrais chemins `run.ts` / `compact.ts` ; les tests limités aux assistants ne sont + pas un substitut suffisant à ces chemins d’intégration. - + - La configuration Vitest de base utilise `threads` par défaut. - - La configuration Vitest partagée fixe `isolate: false` et utilise le runner non isolé dans les projets racine, les configs e2e et les configs live. - - La voie UI racine conserve son setup `jsdom` et son optimiseur, mais elle s’exécute aussi sur le runner 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. - - `scripts/run-vitest.mjs` ajoute par défaut `--no-maglev` aux processus Node enfants de Vitest pour réduire le churn de compilation V8 pendant les grandes exécutions locales. - Définissez `OPENCLAW_VITEST_ENABLE_MAGLEV=1` pour comparer au comportement V8 standard. + - La configuration Vitest partagée fixe `isolate: false` et utilise le + runner non isolé dans les projets racine, e2e et configurations live. + - La voie UI racine conserve sa configuration `jsdom` et son optimiseur, mais s’exécute aussi sur le + runner non isolé partagé. + - Chaque éclat `pnpm test` hérite des mêmes valeurs par défaut `threads` + `isolate: false` + depuis la configuration Vitest partagée. + - `scripts/run-vitest.mjs` ajoute `--no-maglev` par défaut pour les processus Node + enfants de Vitest afin de réduire le va-et-vient de compilation V8 pendant les grosses exécutions locales. + Définissez `OPENCLAW_VITEST_ENABLE_MAGLEV=1` pour comparer au comportement V8 + standard. - + - - `pnpm changed:lanes` indique quelles voies architecturales sont déclenchées par un diff. - - Le hook de pré-commit ne fait que du formatage. Il restage les fichiers formatés et n’exécute pas lint, typecheck ni tests. - - Exécutez explicitement `pnpm check:changed` avant une remise ou un push lorsque vous avez besoin de la barrière de vérification locale intelligente. - - `pnpm test:changed` passe par défaut par des voies limitées peu coûteuses. Utilisez `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` uniquement lorsque l’agent décide qu’une modification de harnais, de config, de package ou de contrat exige réellement une couverture Vitest plus large. - - `pnpm test:max` et `pnpm test:changed:max` conservent le même comportement de routage, simplement avec un plafond de workers plus élevé. - - La mise à l’échelle automatique des workers locaux est volontairement prudente et recule lorsque la charge moyenne de l’hôte est déjà élevée, de sorte que plusieurs exécutions Vitest concurrentes causent moins de dégâts par défaut. - - La configuration Vitest de base marque les projets/fichiers de config comme `forceRerunTriggers` afin que les réexécutions en mode modifié restent correctes lorsque le câblage des tests change. - - La config maintient `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 le profilage direct. + - `pnpm changed:lanes` montre quelles voies architecturales un diff déclenche. + - Le hook pre-commit ne fait que du formatage. Il remet en scène les fichiers formatés et + n’exécute ni lint, ni typecheck, ni tests. + - Exécutez explicitement `pnpm check:changed` avant le transfert ou le push lorsque vous + avez besoin de la barrière de vérification locale intelligente. + - `pnpm test:changed` passe par défaut par des voies ciblées peu coûteuses. Utilisez + `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` uniquement lorsque l’agent + décide qu’une modification de harnais, configuration, package ou contrat nécessite vraiment une couverture + Vitest plus large. + - `pnpm test:max` et `pnpm test:changed:max` conservent le même comportement de routage, + simplement avec une limite de workers plus élevée. + - La mise à l’échelle automatique locale des workers est volontairement conservatrice et recule + lorsque la charge moyenne de l’hôte est déjà élevée, de sorte que plusieurs exécutions Vitest + concurrentes font moins de dégâts par défaut. + - La configuration Vitest de base marque les projets/fichiers de configuration comme + `forceRerunTriggers` afin que les réexécutions en mode modifié 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 voulez + un emplacement de cache explicite pour le profilage direct. - + - - `pnpm test:perf:imports` active les rapports de durée d’import Vitest ainsi que la sortie de détail des imports. - - `pnpm test:perf:imports:changed` limite la même vue de profilage aux fichiers modifiés depuis `origin/main`. - - Les données de temps des fragments sont écrites dans `.artifacts/vitest-shard-timings.json`. - Les exécutions de configuration entière utilisent le chemin de config comme clé ; les fragments CI avec motif d’inclusion ajoutent le nom du fragment afin que les fragments filtrés puissent être suivis séparément. - - Lorsqu’un test chaud passe encore l’essentiel de son temps dans les imports de démarrage, gardez les dépendances lourdes derrière une liaison locale étroite `*.runtime.ts` et moquez directement cette liaison au lieu d’importer en profondeur des helpers runtime seulement pour les passer dans `vi.mock(...)`. - - `pnpm test:perf:changed:bench -- --ref ` compare le `test:changed` routé au chemin natif du projet racine pour ce diff commité et affiche le temps réel écoulé ainsi que le RSS max macOS. - - `pnpm test:perf:changed:bench -- --worktree` mesure l’arbre de travail sale actuel en acheminant la liste de fichiers modifiés via `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 Vitest/Vite et la surcharge de transformation. - - `pnpm test:perf:profile:runner` écrit des profils CPU+heap du runner pour la suite unitaire avec le parallélisme de fichiers désactivé. + - `pnpm test:perf:imports` active le rapport de durée d’importation Vitest ainsi que + la sortie de ventilation des importations. + - `pnpm test:perf:imports:changed` limite la même vue de profilage aux + fichiers modifiés depuis `origin/main`. + - Les données de chronométrage des éclats sont écrites dans `.artifacts/vitest-shard-timings.json`. + Les exécutions de configuration entière utilisent le chemin de configuration comme clé ; les éclats CI + par motif d’inclusion ajoutent le nom de l’éclat afin que les éclats filtrés puissent être suivis + séparément. + - Lorsqu’un test chaud passe encore la majeure partie de son temps dans les importations de démarrage, + gardez les dépendances lourdes derrière une frontière locale étroite `*.runtime.ts` et + moquez directement cette frontière au lieu d’importer en profondeur des assistants d’exécution uniquement + pour les faire passer par `vi.mock(...)`. + - `pnpm test:perf:changed:bench -- --ref ` compare le + `test:changed` routé au chemin natif du projet racine pour ce diff + commité et affiche le temps réel ainsi que le RSS maximal macOS. + - `pnpm test:perf:changed:bench -- --worktree` mesure l’arbre sale courant + en acheminant la liste des fichiers modifiés via + `scripts/test-projects.mjs` et la configuration Vitest racine. + - `pnpm test:perf:profile:main` écrit un profil CPU du thread principal pour + la surcharge de démarrage et de transformation Vitest/Vite. + - `pnpm test:perf:profile:runner` écrit des profils CPU+tas du runner pour la + suite unitaire avec le parallélisme de fichiers désactivé. -### Stabilité (Gateway) +### Stabilité (gateway) - Commande : `pnpm test:stability:gateway` -- Config : `vitest.gateway.config.ts`, forcée à un worker -- Périmètre : - - Démarre un vrai Gateway loopback avec les diagnostics activés par défaut - - Pilote un churn synthétique de messages Gateway, de mémoire et de grandes charges utiles via le chemin d’événements de diagnostic +- Configuration : `vitest.gateway.config.ts`, forcée à un seul worker +- Portée : + - Démarre un vrai Gateway local loopback avec les diagnostics activés par défaut + - Fait passer du churn synthétique de messages Gateway, de mémoire et de grandes charges utiles par le chemin d’événements de diagnostic - Interroge `diagnostics.stability` via le RPC WS du Gateway - - Couvre les helpers de persistance du bundle de stabilité de diagnostic - - Vérifie que l’enregistreur reste borné, que les échantillons RSS synthétiques restent sous le budget de pression et que les profondeurs de file par session redescendent à zéro + - Couvre les assistants de persistance du bundle de stabilité de diagnostic + - Vérifie que l’enregistreur reste borné, que les échantillons RSS synthétiques restent sous le budget de pression et que les profondeurs de file par session reviennent à zéro - Attentes : - - Compatible CI et sans clés - - Voie étroite pour le suivi des régressions de stabilité, pas un substitut à toute la suite Gateway + - Sûr pour la CI et sans clé + - Voie étroite pour le suivi de régressions de stabilité, pas un substitut à la suite Gateway complète -### E2E (smoke Gateway) +### E2E (smoke gateway) - Commande : `pnpm test:e2e` -- Config : `vitest.e2e.config.ts` +- Configuration : `vitest.e2e.config.ts` - Fichiers : `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` et tests E2E de plugins groupés sous `extensions/` -- Valeurs runtime par défaut : +- Valeurs par défaut d’exécution : - Utilise les `threads` 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 par défaut en mode silencieux pour réduire la surcharge d’E/S console. -- Overrides utiles : + - S’exécute en mode silencieux par défaut afin de réduire la surcharge d’E/S console. +- Surcharges 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 Gateway end-to-end multi-instance - - Surfaces WebSocket/HTTP, appairage de nodes et réseau plus lourd +- Portée : + - Comportement Gateway de bout en bout multi-instance + - Surfaces WebSocket/HTTP, appairage de nœuds et réseau plus lourd - Attentes : - - S’exécute en CI (lorsque c’est activé dans le pipeline) + - S’exécute en CI (lorsqu’activé dans le pipeline) - Aucune vraie clé requise - Plus de pièces mobiles que les tests unitaires (peut être plus lent) -### E2E : smoke backend OpenShell +### E2E : smoke du backend OpenShell - Commande : `pnpm test:e2e:openshell` - Fichier : `extensions/openshell/src/backend.e2e.test.ts` -- Périmètre : +- Portée : - Démarre un Gateway OpenShell isolé sur l’hôte via Docker - - Crée un bac à sable depuis un Dockerfile local temporaire - - Exerce le backend OpenShell d’OpenClaw via de vrais `sandbox ssh-config` + SSH exec - - Vérifie le comportement de système de fichiers canonique distant via le pont fs du bac à sable + - Crée un sandbox à partir d’un Dockerfile local temporaire + - Exerce le backend OpenShell d’OpenClaw via de vrais `sandbox ssh-config` + exécutions SSH + - Vérifie le comportement de système de fichiers distant canonique via le pont fs du sandbox - Attentes : - - Uniquement sur opt-in ; ne fait pas partie de l’exécution `pnpm test:e2e` par défaut - - Nécessite une CLI `openshell` locale ainsi qu’un daemon Docker fonctionnel - - Utilise des `HOME` / `XDG_CONFIG_HOME` isolés, puis détruit le Gateway et le bac à sable de test -- Overrides utiles : + - Sur adhésion uniquement ; ne fait pas partie de l’exécution par défaut de `pnpm test:e2e` + - Nécessite une CLI locale `openshell` ainsi qu’un démon Docker fonctionnel + - Utilise des `HOME` / `XDG_CONFIG_HOME` isolés, puis détruit le Gateway de test et le sandbox +- Surcharges 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 ou script wrapper non par défaut + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` pour pointer vers un binaire CLI non par défaut ou un script wrapper ### Live (vrais fournisseurs + vrais modèles) - Commande : `pnpm test:live` -- Config : `vitest.live.config.ts` +- Configuration : `vitest.live.config.ts` - Fichiers : `src/**/*.live.test.ts`, `test/**/*.live.test.ts` et tests live de plugins groupés sous `extensions/` - Par défaut : **activé** par `pnpm test:live` (définit `OPENCLAW_LIVE_TEST=1`) -- Périmètre : +- Portée : - « Ce fournisseur/modèle fonctionne-t-il réellement _aujourd’hui_ avec de vrais identifiants ? » - - Détecter les changements de format fournisseur, les particularités d’appels d’outils, les problèmes d’auth et le comportement des limites de débit + - Détecter les changements de format de fournisseur, les particularités d’appel d’outils, les problèmes d’authentification et le comportement des limites de débit - Attentes : - - Non stable en CI par conception (réseaux réels, politiques fournisseur réelles, quotas, pannes) + - Non stable en CI par conception (vrais réseaux, vraies politiques de fournisseurs, quotas, pannes) - Coûte de l’argent / utilise des limites de débit - - Préférer l’exécution de sous-ensembles restreints plutôt que « tout » -- Les exécutions live sourcent `~/.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 config/auth dans un home de test temporaire afin que les fixtures unitaires ne puissent pas modifier votre vrai `~/.openclaw`. + - Préférer l’exécution de sous-ensembles resserrés plutôt que « tout » +- Les exécutions live sourcent `~/.profile` pour récupérer les clés d’API manquantes. +- Par défaut, les exécutions live isolent toujours `HOME` et copient le matériel de configuration/authentification dans un répertoire 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 volontairement besoin que les tests live utilisent votre vrai répertoire home. -- `pnpm test:live` utilise désormais par défaut un mode plus silencieux : il conserve la sortie de progression `[live] ...`, mais supprime l’avis supplémentaire `~/.profile` et met en sourdine les logs de bootstrap Gateway/le bavardage Bonjour. Définissez `OPENCLAW_LIVE_TEST_QUIET=0` si vous voulez retrouver tous les logs de démarrage. -- Rotation des clés API (spécifique au fournisseur) : définissez `*_API_KEYS` au format virgule/point-virgule ou `*_API_KEY_1`, `*_API_KEY_2` (par exemple `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) ou un override live par `OPENCLAW_LIVE_*_KEY` ; les tests réessaient sur les réponses de limite de débit. -- Sortie progression/Heartbeat : - - 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 des modèles directs avec `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Ajustez les Heartbeat Gateway/probe avec `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. +- `pnpm test:live` utilise désormais par défaut un mode plus silencieux : il conserve la sortie de progression `[live] ...`, mais supprime l’avis supplémentaire `~/.profile` et coupe les journaux de bootstrap du Gateway/le bruit Bonjour. Définissez `OPENCLAW_LIVE_TEST_QUIET=0` si vous voulez récupérer tous les journaux de démarrage. +- Rotation des clés d’API (spécifique au fournisseur) : définissez `*_API_KEYS` au format virgule/point-virgule ou `*_API_KEY_1`, `*_API_KEY_2` (par exemple `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) ou une surcharge par live via `OPENCLAW_LIVE_*_KEY` ; les tests réessaient en cas de réponses de limite de débit. +- Sortie de progression/Heartbeat : + - Les suites live émettent désormais des lignes de progression vers stderr afin que les appels longs aux fournisseurs soient visiblement actifs même lorsque la capture console Vitest est silencieuse. + - `vitest.live.config.ts` désactive l’interception console Vitest afin que les lignes de progression fournisseur/Gateway soient diffusées immédiatement pendant les exécutions live. + - Ajustez les Heartbeats de modèle direct avec `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Ajustez les Heartbeats Gateway/sonde avec `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. ## Quelle suite dois-je exécuter ? Utilisez ce tableau de décision : -- Logique/tests de modification : exécutez `pnpm test` (et `pnpm test:coverage` si vous avez beaucoup changé) -- Modification de la mise en réseau du Gateway / du protocole WS / de l’appairage : ajoutez `pnpm test:e2e` -- Débogage de « mon bot est hors service » / échecs propres au fournisseur / appel d’outils : exécutez un `pnpm test:live` restreint +- Logique/tests modifiés : exécutez `pnpm test` (et `pnpm test:coverage` si vous avez beaucoup modifié) +- Réseau du gateway / protocole WS / appairage touchés : ajoutez `pnpm test:e2e` +- Débogage de « mon bot est hors service » / échecs propres à un fournisseur / appel d’outils : exécutez un `pnpm test:live` restreint -## Tests live (touchant le réseau) +## Tests en direct (qui touchent au réseau) -Pour la matrice de modèles live, les smokes de backend CLI, les smokes ACP, le -harness de serveur d’application Codex, et tous les tests live de fournisseurs de médias -(Deepgram, BytePlus, ComfyUI, image, musique, vidéo, harness média), ainsi que la -gestion des identifiants pour les exécutions live, consultez -[Tests — suites live](/fr/help/testing-live). +Pour la matrice de modèles en direct, les validations rapides du backend CLI, les validations rapides ACP, le +harnais du serveur d’application Codex et tous les tests en direct des fournisseurs multimédias (Deepgram, BytePlus, ComfyUI, image, +musique, vidéo, harnais multimédia), ainsi que la gestion des identifiants pour les exécutions en direct, consultez +[Tests — suites en direct](/fr/help/testing-live). -## Runners Docker (vérifications facultatives « fonctionne sous Linux ») +## Exécuteurs Docker (vérifications facultatives « fonctionne sous Linux ») -Ces runners Docker se répartissent en deux catégories : +Ces exécuteurs Docker se répartissent en deux catégories : -- Runners de modèles live : `test:docker:live-models` et `test:docker:live-gateway` exécutent uniquement leur fichier live à clé 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 workspace (et en sourçant `~/.profile` s’il est monté). Les points d’entrée locaux correspondants sont `test:live:models-profiles` et `test:live:gateway-profiles`. -- Les runners Docker live utilisent par défaut un plafond de smoke plus réduit afin qu’un balayage Docker complet reste pratique : +- Exécuteurs de modèles en direct : `test:docker:live-models` et `test:docker:live-gateway` exécutent uniquement leur fichier en direct correspondant à la clé de profil 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 en direct utilisent par défaut un plafond de validation rapide plus réduit afin qu’un balayage Docker complet reste praticable : `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 - voulez explicitement l’analyse exhaustive plus large. -- `test:docker:all` construit l’image Docker live une fois via `test:docker:live-build`, empaquette OpenClaw une fois comme tarball npm avec `scripts/package-openclaw-for-docker.mjs`, puis construit/réutilise deux images `scripts/e2e/Dockerfile`. L’image nue est uniquement le runner Node/Git pour les lanes d’installation/mise à jour/dépendances de plugins ; ces lanes montent le tarball préconstruit. L’image fonctionnelle installe le même tarball dans `/app` pour les lanes de fonctionnalité de l’application construite. Les définitions de lanes Docker se trouvent dans `scripts/lib/docker-e2e-scenarios.mjs` ; la logique de planification se trouve dans `scripts/lib/docker-e2e-plan.mjs` ; `scripts/test-docker-all.mjs` exécute le plan sélectionné. L’agrégat utilise un ordonnanceur local pondéré : `OPENCLAW_DOCKER_ALL_PARALLELISM` contrôle les emplacements de processus, tandis que les plafonds de ressources empêchent les lanes lourdes live, d’installation npm et multiservices de toutes démarrer en même temps. Si une seule lane est plus lourde que les plafonds actifs, l’ordonnanceur peut tout de même la démarrer lorsque le pool est vide, puis la laisser s’exécuter seule jusqu’à ce que de la capacité soit de nouveau disponible. Les valeurs par défaut sont 10 emplacements, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` et `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7` ; ajustez `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` ou `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` uniquement lorsque l’hôte Docker dispose de plus de marge. Le runner effectue un précontrôle Docker par défaut, supprime les conteneurs E2E OpenClaw obsolètes, affiche l’état toutes les 30 secondes, stocke les timings des lanes réussies dans `.artifacts/docker-tests/lane-timings.json` et utilise ces timings pour démarrer les lanes plus longues en premier lors des exécutions ultérieures. Utilisez `OPENCLAW_DOCKER_ALL_DRY_RUN=1` pour afficher le manifeste pondéré des lanes sans construire ni exécuter Docker, ou `node scripts/test-docker-all.mjs --plan-json` pour afficher le plan CI des lanes sélectionnées, des besoins de package/image et des identifiants. -- `Package Acceptance` est la gate de package native GitHub pour « ce tarball installable fonctionne-t-il comme produit ? ». Elle résout un package candidat depuis `source=npm`, `source=ref`, `source=url` ou `source=artifact`, l’envoie comme `package-under-test`, puis exécute les lanes Docker E2E réutilisables sur ce tarball exact au lieu de réempaqueter la ref sélectionnée. `workflow_ref` sélectionne les scripts de workflow/harness approuvés, tandis que `package_ref` sélectionne le commit/la branche/le tag source à empaqueter lorsque `source=ref` ; cela permet à la logique d’acceptation actuelle de valider d’anciens commits approuvés. Les profils sont classés par étendue : `smoke` est une vérification rapide installation/canal/agent plus Gateway/config, `package` est le contrat package/mise à jour/Plugin et le remplacement natif par défaut de la plupart de la couverture package/mise à jour Parallels, `product` ajoute les canaux MCP, le nettoyage cron/sous-agent, la recherche web OpenAI et OpenWebUI, et `full` exécute les fragments Docker du chemin de release avec OpenWebUI. La validation de release exécute un delta de package personnalisé (`bundled-channel-deps-compat plugins-offline`) plus la QA de package Telegram, car les fragments Docker du chemin de release couvrent déjà les lanes package/mise à jour/Plugin qui se chevauchent. Les commandes de relance Docker GitHub ciblées générées à partir des artefacts incluent l’artefact de package précédent et les entrées d’images préparées lorsqu’elles sont disponibles, afin que les lanes en échec puissent éviter de reconstruire le package et les images. -- Les vérifications de build et de release exécutent `scripts/check-cli-bootstrap-imports.mjs` après tsdown. La garde parcourt le graphe construit statique depuis `dist/entry.js` et `dist/cli/run-main.js` et échoue si le démarrage avant dispatch importe des dépendances de package telles que Commander, l’UI de prompt, undici ou la journalisation avant le dispatch de commande ; elle maintient aussi le fragment d’exécution du Gateway groupé sous le budget et rejette les imports statiques de chemins Gateway froids connus. Le smoke de CLI packagée couvre aussi l’aide racine, l’aide d’onboarding, l’aide doctor, l’état, le schéma de configuration et une commande de liste de modèles. -- La compatibilité héritée de Package Acceptance est plafonnée à `2026.4.25` (`2026.4.25-beta.*` inclus). Jusqu’à cette limite, le harness tolère uniquement les lacunes de métadonnées de packages livrés : entrées d’inventaire QA privées omises, `gateway install --wrapper` manquant, fichiers de patch manquants dans le fixture git dérivé du tarball, `update.channel` persistant manquant, anciens emplacements d’enregistrement d’installation de Plugin, persistance manquante d’enregistrement d’installation de marketplace, et migration des métadonnées de configuration pendant `plugins update`. Pour les packages après `2026.4.25`, ces chemins sont des échecs stricts. -- Runners de smoke de conteneur : `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` et `test:docker:config-reload` démarrent un ou plusieurs conteneurs réels et vérifient des chemins d’intégration de niveau supérieur. + souhaitez explicitement lancer l’analyse exhaustive plus large. +- `test:docker:all` construit l’image Docker en direct une fois via `test:docker:live-build`, empaquette OpenClaw une fois sous forme d’archive npm avec `scripts/package-openclaw-for-docker.mjs`, puis construit/réutilise deux images `scripts/e2e/Dockerfile`. L’image minimale est uniquement l’exécuteur Node/Git pour les voies d’installation, de mise à jour et de dépendances de plugins ; ces voies montent l’archive préconstruite. L’image fonctionnelle installe la même archive dans `/app` pour les voies de fonctionnalité de l’application construite. Les définitions de voies Docker se trouvent dans `scripts/lib/docker-e2e-scenarios.mjs` ; la logique du planificateur se trouve dans `scripts/lib/docker-e2e-plan.mjs` ; `scripts/test-docker-all.mjs` exécute le plan sélectionné. L’agrégat utilise un ordonnanceur local pondéré : `OPENCLAW_DOCKER_ALL_PARALLELISM` contrôle les emplacements de processus, tandis que des plafonds de ressources empêchent les voies lourdes en direct, d’installation npm et multiservice de toutes démarrer en même temps. Si une seule voie est plus lourde que les plafonds actifs, l’ordonnanceur peut quand même la démarrer lorsque le pool est vide, puis la laisse s’exécuter seule jusqu’à ce que de la capacité soit à nouveau disponible. Les valeurs par défaut sont 10 emplacements, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` et `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7` ; ajustez `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` ou `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` uniquement lorsque l’hôte Docker dispose de plus de marge. L’exécuteur effectue par défaut une vérification préalable Docker, supprime les conteneurs E2E OpenClaw obsolètes, affiche l’état toutes les 30 secondes, stocke les durées des voies réussies dans `.artifacts/docker-tests/lane-timings.json` et utilise ces durées pour démarrer les voies les plus longues en premier lors des exécutions suivantes. Utilisez `OPENCLAW_DOCKER_ALL_DRY_RUN=1` pour afficher le manifeste pondéré des voies sans construire ni exécuter Docker, ou `node scripts/test-docker-all.mjs --plan-json` pour afficher le plan CI des voies sélectionnées, des besoins en paquets/images et des identifiants. +- `Package Acceptance` est la barrière de paquet native GitHub pour « cette archive installable fonctionne-t-elle comme un produit ? ». Elle résout un paquet candidat depuis `source=npm`, `source=ref`, `source=url` ou `source=artifact`, le téléverse sous le nom `package-under-test`, puis exécute les voies Docker E2E réutilisables contre cette archive exacte au lieu de réempaqueter la référence sélectionnée. `workflow_ref` sélectionne les scripts de workflow/harnais approuvés, tandis que `package_ref` sélectionne le commit/la branche/l’étiquette source à empaqueter quand `source=ref` ; cela permet à la logique d’acceptation actuelle de valider d’anciens commits approuvés. Les profils sont ordonnés par étendue : `smoke` couvre rapidement installation/canal/agent ainsi que Gateway/configuration, `package` couvre le contrat de paquet/mise à jour/plugin ainsi que le dispositif de survivance à la mise à niveau sans clé et le remplacement natif par défaut pour la plupart de la couverture paquet/mise à jour Parallels, `product` ajoute les canaux MCP, le nettoyage cron/sous-agent, la recherche web OpenAI et OpenWebUI, et `full` exécute les blocs Docker du chemin de publication avec OpenWebUI. La validation de publication exécute un delta de paquet personnalisé (`bundled-channel-deps-compat plugins-offline`) ainsi que l’assurance qualité du paquet Telegram, car les blocs Docker du chemin de publication couvrent déjà les voies de paquet/mise à jour/plugin qui se chevauchent. Les commandes de relance Docker GitHub ciblées générées à partir des artefacts incluent l’artefact de paquet précédent et les entrées d’images préparées lorsqu’ils sont disponibles, afin que les voies échouées puissent éviter de reconstruire le paquet et les images. +- Les vérifications de construction et de publication exécutent `scripts/check-cli-bootstrap-imports.mjs` après tsdown. La garde parcourt le graphe statique construit à partir de `dist/entry.js` et `dist/cli/run-main.js` et échoue si le démarrage avant répartition importe des dépendances de paquet telles que Commander, l’interface d’invite, undici ou la journalisation avant la répartition de la commande ; elle maintient aussi le bloc groupé d’exécution du Gateway sous le budget et rejette les importations statiques de chemins Gateway froids connus. La validation rapide de la CLI empaquetée couvre aussi l’aide racine, l’aide d’intégration, l’aide doctor, l’état, le schéma de configuration et une commande de liste de modèles. +- La compatibilité héritée de Package Acceptance est plafonnée à `2026.4.25` (`2026.4.25-beta.*` inclus). Jusqu’à cette limite, le harnais ne tolère que les lacunes de métadonnées de paquets publiés : entrées d’inventaire QA privé omises, absence de `gateway install --wrapper`, fichiers de correctif manquants dans le dispositif Git dérivé de l’archive, absence de `update.channel` persistant, emplacements hérités des enregistrements d’installation de plugins, absence de persistance des enregistrements d’installation de la place de marché et migration des métadonnées de configuration pendant `plugins update`. Pour les paquets postérieurs à `2026.4.25`, ces chemins sont des échecs stricts. +- Exécuteurs de validation rapide de conteneurs : `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` et `test:docker:config-reload` démarrent un ou plusieurs vrais conteneurs et vérifient des chemins d’intégration de plus haut niveau. -Les runners Docker de modèles live 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 répertoire personnel du conteneur avant l’exécution afin que l’OAuth de CLI externe puisse actualiser les jetons sans muter le magasin d’authentification de l’hôte : +Les exécuteurs Docker de modèles en direct montent aussi en lecture-écriture 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 répertoire personnel du conteneur avant l’exécution, afin que l’OAuth des CLI externes puisse actualiser 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`) -- Test de fumée de liaison ACP : `pnpm test:docker:live-acp-bind` (script : `scripts/test-live-acp-bind-docker.sh` ; couvre Claude, Codex et Gemini par défaut, avec une couverture stricte de Droid/OpenCode via `pnpm test:docker:live-acp-bind:droid` et `pnpm test:docker:live-acp-bind:opencode`) -- Test de fumée du backend CLI : `pnpm test:docker:live-cli-backend` (script : `scripts/test-live-cli-backend-docker.sh`) -- Test de fumée du harnais app-server Codex : `pnpm test:docker:live-codex-harness` (script : `scripts/test-live-codex-harness-docker.sh`) +- Smoke test de liaison ACP : `pnpm test:docker:live-acp-bind` (script : `scripts/test-live-acp-bind-docker.sh` ; couvre Claude, Codex et Gemini par défaut, avec une couverture stricte Droid/OpenCode via `pnpm test:docker:live-acp-bind:droid` et `pnpm test:docker:live-acp-bind:opencode`) +- Smoke test du backend CLI : `pnpm test:docker:live-cli-backend` (script : `scripts/test-live-cli-backend-docker.sh`) +- Smoke test du harnais du serveur d’application Codex : `pnpm test:docker:live-codex-harness` (script : `scripts/test-live-codex-harness-docker.sh`) - Gateway + agent de développement : `pnpm test:docker:live-gateway` (script : `scripts/test-live-gateway-models-docker.sh`) -- Test de fumée d’observabilité : `pnpm qa:otel:smoke` est une voie QA privée d’extraction du code source. Elle ne fait intentionnellement pas partie des voies de publication Docker de paquet, car l’archive npm omet QA Lab. -- Test de fumée Open WebUI en direct : `pnpm test:docker:openwebui` (script : `scripts/e2e/openwebui-docker.sh`) -- Assistant d’intégration (TTY, échafaudage complet) : `pnpm test:docker:onboard` (script : `scripts/e2e/onboard-docker.sh`) -- Test de fumée d’intégration/canal/agent de l’archive npm : `pnpm test:docker:npm-onboard-channel-agent` installe globalement l’archive OpenClaw empaquetée dans Docker, configure OpenAI via l’intégration par référence d’environnement ainsi que Telegram par défaut, vérifie que doctor répare les dépendances d’exécution des Plugin activés, et exécute un tour d’agent OpenAI simulé. Réutilisez une archive préconstruite avec `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, ignorez la reconstruction hôte avec `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0`, ou changez de canal avec `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Test de fumée de changement de canal de mise à jour : `pnpm test:docker:update-channel-switch` installe globalement l’archive OpenClaw empaquetée dans Docker, passe du paquet `stable` à git `dev`, vérifie le canal persistant et le fonctionnement post-mise à jour du Plugin, puis revient au paquet `stable` et vérifie l’état de mise à jour. -- Test de fumée du contexte d’exécution de session : `pnpm test:docker:session-runtime-context` vérifie la persistance cachée de la transcription du contexte d’exécution ainsi que la réparation par doctor des branches dupliquées affectées de réécriture de prompt. -- Test de fumée de l’installation globale Bun : `bash scripts/e2e/bun-global-install-smoke.sh` empaquette l’arborescence actuelle, l’installe avec `bun install -g` dans un home isolé, et vérifie que `openclaw infer image providers --json` renvoie les fournisseurs d’images intégrés au lieu de se bloquer. Réutilisez une archive préconstruite avec `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, ignorez la construction hôte avec `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0`, ou copiez `dist/` depuis une image Docker construite avec `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. -- Test de fumée Docker de l’installateur : `bash scripts/test-install-sh-docker.sh` partage un même cache npm entre ses conteneurs root, update et direct-npm. Le test de fumée de mise à jour utilise par défaut npm `latest` comme base stable avant la mise à niveau vers l’archive candidate. Remplacez-la avec `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` localement, ou avec l’entrée `update_baseline_version` du workflow Install Smoke sur GitHub. Les vérifications d’installateur non-root conservent un cache npm isolé afin que les entrées de cache possédées par root ne masquent pas le comportement d’installation locale utilisateur. Définissez `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache` pour réutiliser le cache root/update/direct-npm entre les réexécutions locales. -- Install Smoke CI ignore la mise à jour globale direct-npm dupliquée avec `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1` ; exécutez le script localement sans cette variable d’environnement lorsque la couverture directe `npm install -g` est nécessaire. -- Test de fumée CLI de suppression d’un espace de travail partagé par les agents : `pnpm test:docker:agents-delete-shared-workspace` (script : `scripts/e2e/agents-delete-shared-workspace-docker.sh`) construit l’image Dockerfile racine par défaut, initialise deux agents avec un espace de travail dans un home de conteneur isolé, exécute `agents delete --json`, et vérifie du JSON valide ainsi que le comportement de conservation de l’espace de travail. Réutilisez l’image install-smoke avec `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. -- Réseau Gateway (deux conteneurs, authentification WS + santé) : `pnpm test:docker:gateway-network` (script : `scripts/e2e/gateway-network-docker.sh`) -- Test de fumée d’instantané CDP navigateur : `pnpm test:docker:browser-cdp-snapshot` (script : `scripts/e2e/browser-cdp-snapshot-docker.sh`) construit l’image E2E source avec une couche Chromium, démarre Chromium avec CDP brut, exécute `browser doctor --deep`, et vérifie que les instantanés de rôle CDP couvrent les URL de liens, les éléments cliquables promus par le curseur, les références d’iframe et les métadonnées de frame. +- Smoke test d’observabilité : `pnpm qa:otel:smoke` est une voie privée de QA sur une extraction des sources. Elle ne fait volontairement pas partie des voies de publication Docker du paquet, car l’archive npm omet QA Lab. +- Smoke test live Open WebUI : `pnpm test:docker:openwebui` (script : `scripts/e2e/openwebui-docker.sh`) +- Assistant d’onboarding (TTY, échafaudage complet) : `pnpm test:docker:onboard` (script : `scripts/e2e/onboard-docker.sh`) +- Smoke test de l’onboarding/canal/agent de l’archive npm : `pnpm test:docker:npm-onboard-channel-agent` installe globalement dans Docker l’archive OpenClaw empaquetée, configure OpenAI via l’onboarding par référence d’environnement ainsi que Telegram par défaut, vérifie que doctor a réparé les dépendances d’exécution du Plugin activé, puis exécute un tour d’agent OpenAI simulé. Réutilisez une archive préconstruite avec `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, ignorez la reconstruction côté hôte avec `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0`, ou changez de canal avec `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Smoke test de changement de canal de mise à jour : `pnpm test:docker:update-channel-switch` installe globalement dans Docker l’archive OpenClaw empaquetée, passe du paquet `stable` à git `dev`, vérifie le canal persistant et le fonctionnement post-mise à jour du Plugin, puis revient au paquet `stable` et contrôle l’état de mise à jour. +- Smoke test de survie à la mise à niveau : `pnpm test:docker:upgrade-survivor` installe l’archive OpenClaw empaquetée par-dessus une fixture d’ancien utilisateur en état sale avec des agents, une configuration de canal, des listes d’autorisation de Plugins, un état obsolète de dépendances d’exécution de Plugins, et des fichiers d’espace de travail/session existants. Il exécute la mise à jour du paquet ainsi que doctor non interactif sans fournisseur live ni clés de canal, puis démarre un Gateway local loopback et vérifie la préservation de la configuration/de l’état ainsi que les budgets de démarrage/statut. +- Smoke test du contexte d’exécution de session : `pnpm test:docker:session-runtime-context` vérifie la persistance cachée de la transcription du contexte d’exécution ainsi que la réparation par doctor des branches dupliquées de réécriture de prompt affectées. +- Smoke test d’installation globale Bun : `bash scripts/e2e/bun-global-install-smoke.sh` empaquette l’arborescence actuelle, l’installe avec `bun install -g` dans un répertoire personnel isolé, et vérifie que `openclaw infer image providers --json` retourne les fournisseurs d’images inclus au lieu de bloquer. Réutilisez une archive préconstruite avec `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, ignorez la construction côté hôte avec `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0`, ou copiez `dist/` depuis une image Docker construite avec `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Smoke test Docker de l’installateur : `bash scripts/test-install-sh-docker.sh` partage un cache npm unique entre ses conteneurs root, update et direct-npm. Le smoke test de mise à jour utilise par défaut npm `latest` comme base stable avant de passer à l’archive candidate. Remplacez-la avec `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` localement, ou avec l’entrée `update_baseline_version` du workflow Install Smoke sur GitHub. Les vérifications d’installateur non-root conservent un cache npm isolé afin que les entrées de cache appartenant à root ne masquent pas le comportement d’installation local utilisateur. Définissez `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache` pour réutiliser le cache root/update/direct-npm lors des relances locales. +- Install Smoke CI ignore la mise à jour globale direct-npm dupliquée avec `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1` ; exécutez le script localement sans cet env quand la couverture directe `npm install -g` est nécessaire. +- Smoke test CLI de suppression par des agents d’un espace de travail partagé : `pnpm test:docker:agents-delete-shared-workspace` (script : `scripts/e2e/agents-delete-shared-workspace-docker.sh`) construit par défaut l’image Dockerfile racine, amorce deux agents avec un espace de travail dans un répertoire personnel de conteneur isolé, exécute `agents delete --json`, et vérifie un JSON valide ainsi que le comportement de conservation de l’espace de travail. Réutilisez l’image install-smoke avec `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. +- Réseau Gateway (deux conteneurs, auth WS + santé) : `pnpm test:docker:gateway-network` (script : `scripts/e2e/gateway-network-docker.sh`) +- Smoke test d’instantané CDP navigateur : `pnpm test:docker:browser-cdp-snapshot` (script : `scripts/e2e/browser-cdp-snapshot-docker.sh`) construit l’image E2E source plus une couche Chromium, démarre Chromium avec CDP brut, exécute `browser doctor --deep`, et vérifie que les instantanés de rôles CDP couvrent les URL de liens, les éléments cliquables promus par curseur, les références d’iframe et les métadonnées de frames. - Régression de raisonnement minimal OpenAI Responses web_search : `pnpm test:docker:openai-web-search-minimal` (script : `scripts/e2e/openai-web-search-minimal-docker.sh`) exécute un serveur OpenAI simulé via Gateway, vérifie que `web_search` augmente `reasoning.effort` de `minimal` à `low`, puis force le rejet du schéma fournisseur et vérifie que le détail brut apparaît dans les journaux Gateway. -- Pont de canal MCP (Gateway initialisé + pont stdio + test de fumée de frame de notification Claude brute) : `pnpm test:docker:mcp-channels` (script : `scripts/e2e/mcp-channels-docker.sh`) -- Outils MCP du bundle Pi (serveur MCP stdio réel + test de fumée allow/deny du profil Pi intégré) : `pnpm test:docker:pi-bundle-mcp-tools` (script : `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Nettoyage Cron/sous-agent MCP (Gateway réel + arrêt de l’enfant MCP stdio après des exécutions cron isolées et sous-agent ponctuelles) : `pnpm test:docker:cron-mcp-cleanup` (script : `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (test de fumée d’installation, installation/désinstallation fourre-tout ClawHub, mises à jour de marketplace, et activation/inspection du bundle Claude) : `pnpm test:docker:plugins` (script : `scripts/e2e/plugins-docker.sh`) - Définissez `OPENCLAW_PLUGINS_E2E_CLAWHUB=0` pour ignorer le bloc ClawHub, ou remplacez la paire paquet/exécution fourre-tout par défaut avec `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` et `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Sans `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL`, le test utilise un serveur de fixture ClawHub local hermétique. -- Test de fumée de mise à jour Plugin inchangée : `pnpm test:docker:plugin-update` (script : `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Test de fumée des métadonnées de rechargement de configuration : `pnpm test:docker:config-reload` (script : `scripts/e2e/config-reload-source-docker.sh`) -- Dépendances d’exécution des Plugin intégrés : `pnpm test:docker:bundled-channel-deps` construit par défaut une petite image d’exécuteur Docker, construit et empaquette OpenClaw une fois sur l’hôte, puis monte cette archive dans chaque scénario d’installation Linux. Réutilisez l’image avec `OPENCLAW_SKIP_DOCKER_BUILD=1`, ignorez la reconstruction hôte après une construction locale fraîche avec `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0`, ou pointez vers une archive existante avec `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. L’agrégat Docker complet et les fragments bundled-channel du chemin de publication pré-empaquettent cette archive une fois, puis segmentent les vérifications de canaux intégrés en voies indépendantes, y compris des voies de mise à jour séparées pour Telegram, Discord, Slack, Feishu, memory-lancedb et ACPX. Les fragments de publication séparent les tests de fumée de canaux, les cibles de mise à jour et les contrats de configuration/exécution en `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` et `bundled-channels-contracts` ; le fragment agrégé `bundled-channels` reste disponible pour les réexécutions manuelles. Le workflow de publication sépare aussi les fragments d’installateur de fournisseurs et les fragments d’installation/désinstallation de Plugin intégrés ; les anciens fragments `package-update`, `plugins-runtime` et `plugins-integrations` restent des alias agrégés pour les réexécutions manuelles. Utilisez `OPENCLAW_BUNDLED_CHANNELS=telegram,slack` pour restreindre la matrice de canaux lors de l’exécution directe de la voie intégrée, ou `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx` pour restreindre le scénario de mise à jour. Les exécutions Docker par scénario utilisent par défaut `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s` ; le scénario de mise à jour multi-cible utilise par défaut `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. La voie vérifie également que `channels..enabled=false` et `plugins.entries..enabled=false` suppriment la réparation par doctor des dépendances d’exécution. -- Restreignez les dépendances d’exécution des Plugin intégrés pendant l’itération en désactivant les scénarios sans rapport, par exemple : +- Pont de canal MCP (Gateway amorcé + pont stdio + smoke test de trame de notification Claude brute) : `pnpm test:docker:mcp-channels` (script : `scripts/e2e/mcp-channels-docker.sh`) +- Outils MCP du bundle Pi (serveur MCP stdio réel + smoke test allow/deny du profil Pi intégré) : `pnpm test:docker:pi-bundle-mcp-tools` (script : `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Nettoyage Cron/sous-agent MCP (Gateway réel + arrêt du processus enfant MCP stdio après des exécutions cron isolées et de sous-agent ponctuel) : `pnpm test:docker:cron-mcp-cleanup` (script : `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (smoke test d’installation, installation/désinstallation ClawHub kitchen-sink, mises à jour de marketplace, et activation/inspection du bundle Claude) : `pnpm test:docker:plugins` (script : `scripts/e2e/plugins-docker.sh`) + Définissez `OPENCLAW_PLUGINS_E2E_CLAWHUB=0` pour ignorer le bloc ClawHub, ou remplacez la paire paquet/exécution kitchen-sink par défaut avec `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` et `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Sans `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL`, le test utilise un serveur fixture ClawHub local hermétique. +- Smoke test de mise à jour de Plugin inchangée : `pnpm test:docker:plugin-update` (script : `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Smoke test des métadonnées de rechargement de configuration : `pnpm test:docker:config-reload` (script : `scripts/e2e/config-reload-source-docker.sh`) +- Dépendances d’exécution des Plugins inclus : `pnpm test:docker:bundled-channel-deps` construit par défaut une petite image Docker d’exécution, construit et empaquette OpenClaw une fois sur l’hôte, puis monte cette archive dans chaque scénario d’installation Linux. Réutilisez l’image avec `OPENCLAW_SKIP_DOCKER_BUILD=1`, ignorez la reconstruction côté hôte après une construction locale fraîche avec `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0`, ou pointez vers une archive existante avec `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. L’agrégat Docker complet et les morceaux bundled-channel du chemin de publication pré-empaquettent cette archive une seule fois, puis partitionnent les vérifications des canaux inclus en voies indépendantes, y compris des voies de mise à jour séparées pour Telegram, Discord, Slack, Feishu, memory-lancedb et ACPX. Les morceaux de publication séparent les smoke tests de canal, les cibles de mise à jour et les contrats setup/runtime en `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` et `bundled-channels-contracts` ; le morceau agrégé `bundled-channels` reste disponible pour les relances manuelles. Le workflow de publication sépare aussi les morceaux d’installation des fournisseurs et les morceaux d’installation/désinstallation des Plugins inclus ; les anciens morceaux `package-update`, `plugins-runtime` et `plugins-integrations` restent des alias agrégés pour les relances manuelles. Utilisez `OPENCLAW_BUNDLED_CHANNELS=telegram,slack` pour restreindre la matrice des canaux lors de l’exécution directe de la voie incluse, ou `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx` pour restreindre le scénario de mise à jour. Les exécutions Docker par scénario utilisent par défaut `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s` ; le scénario de mise à jour multi-cibles utilise par défaut `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. La voie vérifie aussi que `channels..enabled=false` et `plugins.entries..enabled=false` suppriment la réparation des dépendances d’exécution par doctor. +- Restreignez les dépendances d’exécution des Plugins inclus pendant l’itération en désactivant les scénarios sans rapport, par exemple : `OPENCLAW_BUNDLED_CHANNEL_SCENARIOS=0 OPENCLAW_BUNDLED_CHANNEL_UPDATE_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_ROOT_OWNED_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_SETUP_ENTRY_SCENARIO=0 pnpm test:docker:bundled-channel-deps`. Pour préconstruire et réutiliser manuellement l’image fonctionnelle partagée : @@ -617,112 +649,107 @@ OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker: OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Les remplacements d’image propres aux suites, comme `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, restent prioritaires lorsqu’ils sont définis. Lorsque `OPENCLAW_SKIP_DOCKER_BUILD=1` pointe vers une image distante partagée, les scripts la téléchargent si elle n’est pas déjà locale. Les tests Docker QR et installateur conservent leurs propres Dockerfiles, car ils valident le comportement de paquet/installation plutôt que l’exécution partagée de l’application construite. +Les remplacements d’image propres à une suite, comme `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, restent prioritaires lorsqu’ils sont définis. Lorsque `OPENCLAW_SKIP_DOCKER_BUILD=1` pointe vers une image partagée distante, les scripts la téléchargent si elle n’est pas déjà locale. Les tests Docker QR et d’installateur conservent leurs propres Dockerfiles, car ils valident le comportement de paquet/d’installation plutôt que l’exécution de l’application construite partagée. -Les exécuteurs Docker live-model montent également l’extraction actuelle 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 contre votre source/configuration locale exacte. -L’étape de préparation ignore les grands caches purement locaux et les sorties de construction d’applications tels que -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, ainsi que les répertoires `.build` locaux à l’application ou -de sortie Gradle, afin que les exécutions live Docker ne passent pas des minutes à copier des artefacts -propres à la machine. -Ils définissent également `OPENCLAW_SKIP_CHANNELS=1` afin que les sondes Gateway en direct ne démarrent pas +Les runners Docker de modèles en direct montent également le checkout actuel en lecture seule et +le placent 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 uniquement et les sorties de compilation d’app +comme `.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, ainsi que les répertoires `.build` locaux aux apps ou les répertoires de sortie Gradle, afin que les exécutions Docker en direct ne passent pas des minutes à copier des artefacts propres à la machine. +Elles définissent aussi `OPENCLAW_SKIP_CHANNELS=1` afin que les sondes en direct du gateway ne démarrent pas de vrais workers de canaux Telegram/Discord/etc. dans le conteneur. `test:docker:live-models` exécute toujours `pnpm test:live`, donc transmettez aussi -`OPENCLAW_LIVE_GATEWAY_*` lorsque vous devez restreindre ou exclure la couverture -Gateway en direct de cette voie Docker. -`test:docker:openwebui` est un test de fumée 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 +`OPENCLAW_LIVE_GATEWAY_*` lorsque vous devez restreindre ou exclure la couverture en direct du gateway +de cette lane Docker. +`test:docker:openwebui` est un smoke test de compatibilité de plus haut niveau : il démarre un +conteneur gateway OpenClaw avec les endpoints HTTP compatibles OpenAI activés, +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 télécharger l’image +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. -Cette voie attend une clé de modèle en direct utilisable, et `OPENCLAW_PROFILE_FILE` -(`~/.profile` par défaut) est le moyen principal de la fournir dans les exécutions Dockerisées. +Cette lane attend une clé de modèle en direct utilisable, et `OPENCLAW_PROFILE_FILE` +(`~/.profile` par défaut) est le principal moyen de la fournir dans les exécutions Dockerisées. Les exécutions réussies affichent une petite charge utile JSON comme `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` est intentionnellement déterministe et ne nécessite pas de -vrai compte Telegram, Discord ou iMessage. Il démarre un conteneur Gateway initialisé, -démarre un second conteneur qui lance `openclaw mcp serve`, puis vérifie la découverte -des conversations routées, les lectures de transcriptions, les métadonnées de pièces jointes, -le comportement de la file d’événements en direct, le routage d’envoi sortant, ainsi que les notifications -de canal + permission de style Claude via le vrai pont MCP stdio. La vérification des notifications -inspecte directement les frames MCP stdio brutes afin que le test de fumée valide ce que le -pont émet réellement, et pas seulement ce qu’un SDK client donné expose par hasard. -`test:docker:pi-bundle-mcp-tools` est déterministe et ne nécessite pas de clé de modèle en direct. -Il construit l’image Docker du dépôt, démarre un vrai serveur de sonde MCP stdio -dans le conteneur, matérialise ce serveur via l’exécution MCP du bundle Pi intégré, +vrai compte Telegram, Discord ou iMessage. Il démarre un conteneur Gateway prérempli, +démarre un second conteneur qui lance `openclaw mcp serve`, puis vérifie la +découverte de conversations routées, les lectures de transcriptions, les métadonnées de pièces jointes, +le comportement de la file d’événements en direct, le routage des envois sortants, ainsi que les notifications de canal + +permission de style Claude via le vrai pont MCP stdio. La vérification des notifications +inspecte directement les trames MCP stdio brutes, afin que le smoke test valide ce que le +pont émet réellement, et pas seulement ce qu’un SDK client spécifique expose par hasard. +`test:docker:pi-bundle-mcp-tools` est déterministe et ne nécessite pas de clé de modèle en direct. Il compile l’image Docker du dépôt, démarre un vrai serveur de sonde MCP stdio +dans le conteneur, matérialise ce serveur via le runtime MCP du bundle Pi intégré, exécute l’outil, puis vérifie que `coding` et `messaging` conservent les outils `bundle-mcp` tandis que `minimal` et `tools.deny: ["bundle-mcp"]` les filtrent. -`test:docker:cron-mcp-cleanup` est déterministe et ne nécessite pas de clé de modèle en direct. -Il démarre une Gateway initialisée avec un vrai serveur de sonde MCP stdio, exécute un -tour cron isolé et un tour enfant ponctuel `/subagents spawn`, puis vérifie +`test:docker:cron-mcp-cleanup` est déterministe et ne nécessite pas de clé de modèle en direct. Il démarre un Gateway prérempli avec un vrai serveur de sonde MCP stdio, exécute un tour cron isolé et un tour enfant ponctuel `/subagents spawn`, puis vérifie que le processus enfant MCP se termine après chaque exécution. -Test de fumée manuel de fil ACP en langage naturel (hors CI) : +Smoke test manuel de thread ACP 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 à nouveau nécessaire pour la validation du routage des fils ACP, ne le supprimez donc pas. +- Conservez ce script pour les workflows de régression/débogage. Il pourrait être à nouveau nécessaire pour valider le routage des threads 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 sourcé avant l’exécution des tests -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` pour vérifier uniquement les variables d’environnement sourcées depuis `OPENCLAW_PROFILE_FILE`, avec des répertoires de configuration/espace de travail temporaires et aucun montage d’authentification CLI externe +- `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`, avec des répertoires de configuration/espace de travail temporaires et sans montages 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 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 +- Les répertoires/fichiers d’authentification CLI externe sous `$HOME` sont montés en lecture seule sous `/host-auth...`, puis copiés dans `/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 limitées à un fournisseur montent uniquement les répertoires/fichiers nécessaires déduits de `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` + - Les exécutions restreintes à un fournisseur ne montent que les répertoires/fichiers nécessaires inférés depuis `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - Remplacez manuellement 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 limiter l’exécution +- `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 pour les réexécutions 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 le Gateway pour le smoke Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...` pour remplacer le prompt de vérification du nonce utilisé par le smoke Open WebUI +- `OPENCLAW_SKIP_DOCKER_BUILD=1` pour réutiliser une image `openclaw:local-live` existante lors des réexécutions qui ne nécessitent pas de recompilation +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour garantir que les identifiants viennent du magasin de profils (et non de l’environnement) +- `OPENCLAW_OPENWEBUI_MODEL=...` pour choisir le modèle exposé par le gateway pour le smoke test Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...` pour remplacer le prompt de vérification par nonce utilisé par le smoke test Open WebUI - `OPENWEBUI_IMAGE=...` pour remplacer le tag d’image Open WebUI épinglé -## Vérification de cohérence de la documentation +## Vérification documentaire -Exécutez les vérifications de documentation après les modifications de docs : `pnpm check:docs`. -Exécutez la validation complète des ancres Mintlify lorsque vous avez aussi besoin des vérifications des titres dans la page : `pnpm docs:check-links:anchors`. +Exécutez les contrôles de documentation après les modifications de docs : `pnpm check:docs`. +Exécutez la validation complète des ancres Mintlify lorsque vous devez aussi vérifier les titres dans les pages : `pnpm docs:check-links:anchors`. ## Régression hors ligne (compatible CI) -Ce sont des régressions de « vrai pipeline » sans fournisseurs réels : +Voici des régressions de « vrai pipeline » sans vrais fournisseurs : -- Appel d’outil Gateway (OpenAI simulé, Gateway réel + boucle d’agent) : `src/gateway/gateway.test.ts` (cas : « exécute de bout en bout un appel d’outil OpenAI simulé via la boucle d’agent Gateway ») -- Assistant Gateway (`wizard.start`/`wizard.next` WS, écrit la configuration + authentification appliquée) : `src/gateway/gateway.test.ts` (cas : « exécute l’assistant via ws et écrit la configuration du jeton d’authentification ») +- Appel d’outil Gateway (OpenAI simulé, vrai gateway + boucle d’agent) : `src/gateway/gateway.test.ts` (cas : "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Assistant de configuration Gateway (WS `wizard.start`/`wizard.next`, écrit la configuration + auth appliquée) : `src/gateway/gateway.test.ts` (cas : "runs wizard over ws and writes auth token config") -## Évaluations de fiabilité des agents (Skills) +## Évaluations de fiabilité des agents (skills) Nous avons déjà quelques tests compatibles CI qui se comportent comme des « évaluations de fiabilité des agents » : -- Appel d’outil simulé via le Gateway réel + boucle d’agent (`src/gateway/gateway.test.ts`). -- Flux d’assistant de bout en bout qui valident le câblage de session et les effets de configuration (`src/gateway/gateway.test.ts`). +- Appel d’outil simulé via le vrai gateway + la boucle d’agent (`src/gateway/gateway.test.ts`). +- Flows d’assistant de configuration de bout en bout qui valident le câblage de session et les effets de configuration (`src/gateway/gateway.test.ts`). -Ce qui manque encore pour Skills (voir [Skills](/fr/tools/skills)) : +Ce qui manque encore pour les Skills (voir [Skills](/fr/tools/skills)) : -- **Prise de décision :** lorsque des Skills sont listés dans le prompt, l’agent choisit-il la bonne Skill (ou évite-t-il celles qui ne sont pas pertinentes) ? +- **Décision :** lorsque des skills sont listées dans le prompt, l’agent choisit-il la bonne skill (ou évite-t-il celles qui ne sont pas 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, la conservation 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 reprise de l’historique de session et les limites du sandbox. -Les futures évaluations doivent d’abord rester déterministes : +Les futures évaluations doivent rester déterministes en priorité : -- Un exécuteur de scénarios utilisant des fournisseurs simulés pour vérifier les appels d’outils + l’ordre, les lectures de fichiers de Skill et le câblage de session. -- Une petite suite de scénarios centrés sur Skills (utiliser ou éviter, garde-fous, injection de prompt). -- Évaluations live facultatives (sur activation, contrôlées par variables d’environnement) uniquement après la mise en place de la suite compatible CI. +- Un runner 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, gates, injection de prompt). +- Des évaluations en direct optionnelles (opt-in, protégées par variables d’environnement) seulement après la mise en place de la suite compatible CI. -## Tests de contrat (forme des plugins et des canaux) +## Tests de contrat (forme des plugins et canaux) -Les tests de contrat vérifient que chaque Plugin et chaque canal enregistré est conforme à son -contrat d’interface. Ils parcourent tous les plugins découverts et exécutent une suite -d’assertions de forme et de comportement. La voie unitaire `pnpm test` par défaut ignore intentionnellement -ces fichiers de smoke et de seams partagés ; exécutez explicitement les commandes de contrat -lorsque vous touchez aux surfaces partagées de canal ou de fournisseur. +Les tests de contrat vérifient que chaque plugin et chaque canal enregistré respecte son +contrat d’interface. Ils itèrent sur tous les plugins découverts et exécutent une suite +d’assertions de forme et de comportement. La lane unitaire `pnpm test` par défaut +ignore intentionnellement ces fichiers de smoke test et de seam partagés ; exécutez explicitement +les commandes de contrat lorsque vous touchez des surfaces partagées de canal ou de fournisseur. ### Commandes @@ -734,58 +761,58 @@ lorsque vous touchez aux surfaces partagées de canal ou de fournisseur. Situés dans `src/channels/plugins/contracts/*.contract.test.ts` : -- **plugin** - Forme de base du Plugin (id, nom, capacités) +- **plugin** - Forme de base du plugin (id, nom, capacités) - **setup** - Contrat de l’assistant de configuration - **session-binding** - Comportement de liaison de session -- **outbound-payload** - Structure de payload des messages +- **outbound-payload** - Structure de la charge utile des messages - **inbound** - Gestion des messages entrants - **actions** - Gestionnaires d’actions de canal -- **threading** - Gestion des ID de fil +- **threading** - Gestion des identifiants de thread - **directory** - API d’annuaire/liste -- **group-policy** - Application de la stratégie de groupe +- **group-policy** - Application de la politique de groupe ### Contrats de statut des fournisseurs Situés dans `src/plugins/contracts/*.contract.test.ts`. - **status** - Sondes de statut de canal -- **registry** - Forme du registre de Plugins +- **registry** - Forme du registre de plugins ### Contrats de fournisseurs Situés dans `src/plugins/contracts/*.contract.test.ts` : -- **auth** - Contrat de flux d’authentification +- **auth** - Contrat du flow d’authentification - **auth-choice** - Choix/sélection d’authentification -- **catalog** - API de catalogue de modèles -- **discovery** - Découverte de Plugins -- **loader** - Chargement de Plugins +- **catalog** - API du catalogue de modèles +- **discovery** - Découverte des plugins +- **loader** - Chargement des plugins - **runtime** - Runtime du fournisseur -- **shape** - Forme/interface du Plugin +- **shape** - Forme/interface du plugin - **wizard** - Assistant de configuration -### Quand exécuter +### Quand les exécuter - Après avoir modifié les exports ou sous-chemins de plugin-sdk -- Après avoir ajouté ou modifié un canal ou un Plugin fournisseur -- Après avoir refactorisé l’enregistrement ou la découverte de Plugins +- Après avoir ajouté ou modifié un canal ou un plugin fournisseur +- Après avoir refactorisé l’enregistrement ou la découverte des plugins Les tests de contrat s’exécutent en CI et ne nécessitent pas de vraies clés d’API. -## Ajouter des régressions (conseils) +## Ajout de régressions (conseils) -Lorsque vous corrigez un problème de fournisseur/modèle découvert en live : +Lorsque vous corrigez un problème de fournisseur/modèle découvert en direct : -- Ajoutez une régression compatible CI si possible (fournisseur mock/stub, ou capture de la transformation exacte de la forme de la requête) -- Si c’est intrinsèquement live uniquement (limites de débit, politiques d’authentification), gardez le test live limité et activable via variables d’environnement -- Préférez cibler la plus petite couche qui détecte le bogue : - - bogue de conversion/rejeu de requête fournisseur → test direct des modèles - - bogue de pipeline session/historique/outil Gateway → smoke Gateway live ou test mock Gateway compatible CI +- Ajoutez une régression compatible CI si possible (fournisseur simulé/stub, ou capture de la transformation exacte de la forme de requête) +- Si c’est intrinsèquement en direct uniquement (limites de débit, politiques d’authentification), gardez le test en direct 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 direct des modèles + - bug de pipeline de session/historique/outils gateway → smoke test gateway en direct ou test gateway simulé 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 du registre (`listSecretTargetRegistryEntries()`), puis vérifie que les identifiants d’exécution avec segment de traversée 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 intentionnellement sur les identifiants de cible non classés afin que les nouvelles classes ne puissent pas être ignorées silencieusement. + - `src/secrets/exec-secret-ref-id-parity.test.ts` dérive une cible échantillonnée par classe SecretRef depuis les métadonnées du registre (`listSecretTargetRegistryEntries()`), puis vérifie que les ids exec à segment de traversée 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 intentionnellement sur les ids de cible non classés afin que les nouvelles classes ne puissent pas être ignorées silencieusement. -## Connexe +## Liens associés -- [Tests live](/fr/help/testing-live) +- [Tests en direct](/fr/help/testing-live) - [CI](/fr/ci) diff --git a/docs/fr/reference/test.md b/docs/fr/reference/test.md index e5987bc20..138e4cf88 100644 --- a/docs/fr/reference/test.md +++ b/docs/fr/reference/test.md @@ -4,55 +4,56 @@ read_when: summary: Comment exécuter les tests localement (vitest) et quand utiliser les modes force/couverture title: Tests x-i18n: - generated_at: "2026-04-30T07:47:38Z" + generated_at: "2026-04-30T18:38:34Z" model: gpt-5.5 provider: openai - source_hash: 9328d6f0383b5067fa8bb5d0f1bf22a3b9048a267908bf85167842ddc3d12e42 + source_hash: 131f2bad3b2806d28394213cec38d632d106ddbf8ff04d06345ab8046fb8bcf2 source_path: reference/test.md workflow: 16 --- -- Kit de test complet (suites, en direct, Docker) : [Tests](/fr/help/testing) +- Kit de tests complet (suites, tests en direct, Docker) : [Tests](/fr/help/testing) -- `pnpm test:force` : tue tout processus Gateway persistant qui occupe le port de contrôle par défaut, puis exécute toute la suite Vitest avec un port Gateway isolé afin que les tests serveur n’entrent pas en conflit avec une instance en cours d’exécution. Utilisez cela lorsqu’une exécution Gateway précédente a laissé le port 18789 occupé. -- `pnpm test:coverage` : exécute la suite unitaire avec la couverture V8 (via `vitest.unit.config.ts`). Il s’agit d’un contrôle de couverture unitaire des fichiers chargés, pas d’une couverture de tous les fichiers de tout le dépôt. Les seuils sont 70 % pour les lignes/fonctions/instructions et 55 % pour les branches. Comme `coverage.all` vaut false, le contrôle mesure les fichiers chargés par la suite de couverture unitaire au lieu de traiter chaque fichier source de voie séparée comme non couvert. +- `pnpm test:force` : tue tout processus Gateway persistant qui occupe le port de contrôle par défaut, puis exécute la suite Vitest complète avec un port Gateway isolé afin que les tests serveur n’entrent pas en conflit avec une instance en cours d’exécution. Utilisez-le lorsqu’une exécution Gateway précédente a laissé le port 18789 occupé. +- `pnpm test:coverage` : exécute la suite unitaire avec la couverture V8 (via `vitest.unit.config.ts`). Il s’agit d’une porte de couverture unitaire des fichiers chargés, et non d’une couverture de tous les fichiers de tout le dépôt. Les seuils sont de 70 % pour les lignes/fonctions/instructions et de 55 % pour les branches. Comme `coverage.all` vaut false, la porte mesure les fichiers chargés par la suite de couverture unitaire au lieu de considérer chaque fichier source de voie fractionnée comme non couvert. - `pnpm test:coverage:changed` : exécute la couverture unitaire uniquement pour les fichiers modifiés depuis `origin/main`. -- `pnpm test:changed` : exécution de tests modifiés intelligente et peu coûteuse. Elle exécute des cibles précises à partir des modifications directes de tests, des fichiers frères `*.test.ts`, des correspondances source explicites et du graphe d’import local. Les modifications larges de configuration/paquet sont ignorées sauf si elles correspondent à des tests précis. -- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` : exécution large explicite des tests modifiés. Utilisez-la lorsqu’une modification de harnais de test/configuration/paquet doit revenir au comportement plus large de Vitest pour les tests modifiés. +- `pnpm test:changed` : exécution de tests modifiés intelligente et peu coûteuse. Elle exécute des cibles précises à partir des modifications directes de tests, des fichiers frères `*.test.ts`, des correspondances de sources explicites et du graphe d’import local. Les changements larges de configuration ou de package sont ignorés sauf s’ils correspondent à des tests précis. +- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` : exécution large explicite des tests modifiés. Utilisez-la lorsqu’une modification du harnais de test, de la configuration ou d’un package doit revenir au comportement plus large de Vitest pour les tests modifiés. - `pnpm changed:lanes` : affiche les voies architecturales déclenchées par le diff par rapport à `origin/main`. -- `pnpm check:changed` : exécute le contrôle intelligent des changements pour le diff par rapport à `origin/main`. Il exécute les commandes de typage, de lint et de garde pour les voies architecturales affectées, mais n’exécute pas les tests Vitest. Utilisez `pnpm test:changed` ou `pnpm test ` explicite pour la preuve par les tests. -- `pnpm test` : route les cibles de fichier/répertoire explicites vers des voies Vitest limitées. Les exécutions sans cible utilisent des groupes de partitions fixes et s’étendent aux configurations feuilles pour l’exécution parallèle locale ; le groupe d’extensions s’étend toujours aux configurations de partitions par extension au lieu d’un unique processus de projet racine géant. -- Les exécutions de l’enveloppe de test se terminent par un court résumé `[test] passed|failed|skipped ... in ...`. La ligne de durée propre à Vitest reste le détail par partition. +- `pnpm check:changed` : exécute la porte de vérification intelligente des changements pour le diff par rapport à `origin/main`. Elle exécute les commandes de vérification de types, de lint et de garde pour les voies architecturales affectées, mais n’exécute pas les tests Vitest. Utilisez `pnpm test:changed` ou un `pnpm test ` explicite comme preuve de test. +- `pnpm test` : achemine les cibles explicites de fichiers/répertoires via les voies Vitest limitées au périmètre. Les exécutions sans cible utilisent des groupes de fragments fixes et se développent en configurations feuilles pour l’exécution parallèle locale ; le groupe d’extensions se développe toujours en configurations de fragments par extension au lieu d’un seul énorme processus de projet racine. +- Les exécutions du wrapper de test se terminent par un court résumé `[test] passed|failed|skipped ... in ...`. La ligne de durée propre à Vitest reste le détail par fragment. - État de test OpenClaw partagé : utilisez `src/test-utils/openclaw-test-state.ts` depuis Vitest lorsqu’un test a besoin d’un `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, d’un fixture de configuration, d’un espace de travail, d’un répertoire d’agent ou d’un magasin de profils d’authentification isolé. -- Assistants E2E de processus : utilisez `test/helpers/openclaw-test-instance.ts` lorsqu’un test E2E au niveau processus Vitest a besoin d’un Gateway en cours d’exécution, d’un environnement CLI, d’une capture de journaux et du nettoyage au même endroit. -- Assistants E2E Docker/Bash : les voies qui sourcent `scripts/lib/docker-e2e-image.sh` peuvent passer `docker_e2e_test_state_shell_b64