Get started

Mantis

Mantis est le système de vérification de bout en bout d'OpenClaw pour les bogues qui nécessitent un véritable environnement d'exécution, un véritable transport et une preuve visible. Il exécute un scénario sur une référence connue comme défectueuse, capture des preuves, exécute le même scénario sur une référence candidate, puis publie la comparaison sous forme d'artefacts qu'un mainteneur peut inspecter depuis une PR ou depuis une commande locale.

Mantis commence par Discord, car Discord nous donne une première voie à forte valeur : authentification de bot réelle, canaux de guilde réels, réactions, fils, commandes natives et une interface de navigateur où les humains peuvent confirmer visuellement ce que le transport a montré.

Objectifs

Reproduire un bogue issu d'une issue ou d'une PR GitHub avec la même forme de transport que celle que les utilisateurs voient.
Capturer un artefact avant sur la référence de base avant d'appliquer le correctif.
Capturer un artefact après sur la référence candidate après avoir appliqué le correctif.
Utiliser un oracle déterministe chaque fois que possible, comme une lecture de réaction via l'API REST Discord ou une vérification de transcription de canal.
Capturer des captures d'écran lorsque le bogue a une surface d'interface visible.
S'exécuter localement depuis une CLI contrôlée par un agent et à distance depuis GitHub.
Préserver suffisamment d'état machine pour un sauvetage VNC lorsque la connexion, l'automatisation du navigateur ou l'authentification du fournisseur se bloque.
Publier un statut concis dans un canal Discord d'opérateur lorsque l'exécution est bloquée, nécessite une aide VNC manuelle ou se termine.

Non-objectifs

Mantis ne remplace pas les tests unitaires. Une exécution Mantis devrait généralement devenir un test de régression plus petit une fois le correctif compris.
Mantis n'est pas la porte CI rapide normale. Il est plus lent, utilise des identifiants réels et est réservé aux bogues où l'environnement réel compte.
Mantis ne devrait pas nécessiter d'humain pour un fonctionnement normal. Le VNC manuel est un chemin de sauvetage, pas le chemin nominal.
Mantis ne stocke pas de secrets bruts dans les artefacts, les journaux, les captures d'écran, les rapports Markdown ou les commentaires de PR.

Propriété

Mantis vit dans la pile QA d'OpenClaw.

OpenClaw possède l'environnement d'exécution des scénarios, les adaptateurs de transport, le schéma de preuves et la CLI locale sous pnpm openclaw qa mantis.
QA Lab possède les composants de harnais de transport réel, les assistants de capture de navigateur et les rédacteurs d'artefacts.
Crabbox possède les machines Linux préchauffées lorsqu'une VM distante est nécessaire.
GitHub Actions possède le point d'entrée du workflow distant et la rétention des artefacts.
ClawSweeper possède le routage des commentaires GitHub : analyse des commandes mainteneur, dispatch du workflow et publication du commentaire final de PR.
Les agents OpenClaw pilotent Mantis via Codex lorsqu'un scénario nécessite une configuration agentique, du débogage ou un signalement d'état bloqué.

Cette frontière garde la connaissance du transport dans OpenClaw, la planification des machines dans Crabbox et le raccordement du workflow mainteneur dans ClawSweeper.

Forme de commande

La première commande locale vérifie le bot Discord, la guilde, le canal, l'envoi de message, l'envoi de réaction et le chemin d'artefact :

pnpm openclaw qa mantis discord-smoke \
  --output-dir .artifacts/qa-e2e/mantis/discord-smoke

L'exécuteur local avant et après accepte cette forme :

pnpm openclaw qa mantis run \
  --transport discord \
  --scenario discord-status-reactions-tool-only \
  --baseline origin/main \
  --candidate HEAD \
  --output-dir .artifacts/qa-e2e/mantis/local-discord-status-reactions

L'exécuteur crée des worktrees de base et candidats détachés sous le répertoire de sortie, installe les dépendances, construit chaque référence, exécute le scénario avec --allow-failures, puis écrit baseline/, candidate/, comparison.json et mantis-report.md. Pour le premier scénario Discord, une vérification réussie signifie que le statut de base est fail et que le statut candidat est pass.

La deuxième sonde Discord avant/après cible les pièces jointes dans les fils :

pnpm openclaw qa mantis run \
  --transport discord \
  --scenario discord-thread-reply-filepath-attachment \
  --baseline <bug-ref> \
  --candidate <fix-ref> \
  --output-dir .artifacts/qa-e2e/mantis/local-discord-thread-attachment

Ce scénario publie un message parent avec le bot pilote, crée un véritable fil Discord, appelle l'action message.thread-reply d'OpenClaw avec un filePath local au dépôt, puis interroge le fil pour trouver la réponse du SUT et le nom du fichier joint. La capture d'écran de base montre la réponse sans pièce jointe ; la capture d'écran candidate montre la pièce jointe mantis-thread-report.md attendue.

La première primitive VM/navigateur est le smoke desktop :

pnpm openclaw qa mantis desktop-browser-smoke \
  --output-dir .artifacts/qa-e2e/mantis/desktop-browser

Elle loue ou réutilise une machine desktop Crabbox, lance un navigateur visible dans la session VNC, capture le bureau, rapatrie les artefacts vers le répertoire de sortie local et écrit la commande de reconnexion dans le rapport. La commande utilise par défaut le fournisseur Hetzner, car c'est le premier fournisseur avec une couverture desktop/VNC fonctionnelle dans la voie Mantis. Remplacez-le avec --provider, --crabbox-bin ou OPENCLAW_MANTIS_CRABBOX_PROVIDER lors de l'exécution contre une autre flotte Crabbox.

Indicateurs utiles pour le smoke desktop :

--lease-id <cbx_...> ou OPENCLAW_MANTIS_CRABBOX_LEASE_ID réutilise un desktop préchauffé.
--browser-url <url> change la page ouverte dans le navigateur visible.
--html-file <path> affiche un artefact HTML local au dépôt dans le navigateur visible. Mantis l'utilise pour capturer la chronologie générée des réactions de statut Discord via un véritable desktop Crabbox.
--browser-profile-dir <remote-path> réutilise un user-data-dir Chrome distant afin qu'un desktop Mantis persistant puisse rester connecté entre les exécutions. Utilisez-le pour le profil durable du visionneur Discord Web.
--browser-profile-archive-env <name> restaure une archive user-data-dir Chrome .tgz base64 depuis la variable d'environnement nommée avant de lancer le navigateur. Utilisez-le pour des témoins connectés tels que Discord Web. La variable d'environnement par défaut est OPENCLAW_MANTIS_BROWSER_PROFILE_TGZ_B64.
--video-duration <seconds> contrôle la durée de capture MP4. Utilisez une durée plus longue pour les applications web lentes et connectées qui ont besoin de temps pour se stabiliser.
--keep-lease ou OPENCLAW_MANTIS_KEEP_VM=1 garde ouverte une nouvelle location réussie pour inspection VNC. Les exécutions échouées gardent la location par défaut lorsqu'elle a été créée afin qu'un opérateur puisse se reconnecter.
--class, --idle-timeout et --ttl ajustent la taille de la machine et la durée de vie de la location.

Pour les preuves Discord Web, Mantis utilise un compte visionneur dédié au lieu d'un jeton de bot. Le scénario API Discord réel reste l'oracle : il crée le vrai fil, envoie le thread-reply du SUT et vérifie la pièce jointe via l'API REST Discord. Lorsque OPENCLAW_QA_DISCORD_CAPTURE_UI_METADATA=1 est défini, le scénario écrit aussi un artefact d'URL Discord Web. Lorsque OPENCLAW_QA_DISCORD_KEEP_THREADS=1 est défini, il laisse ce fil disponible assez longtemps pour qu'un navigateur connecté l'ouvre et l'enregistre.

Le workflow GitHub ouvre l'URL du fil candidat dans Discord Web, capture une capture d'écran, enregistre un MP4 et génère un aperçu GIF élagué lorsque les outils média Crabbox sont disponibles. Préférez un chemin de profil visionneur persistant configuré via MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR, car les archives de profil Chrome complètes peuvent dépasser la limite de taille des secrets GitHub. Pour les petits profils ou les profils d'amorçage, le workflow peut aussi restaurer une archive .tgz base64 depuis MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64. Si aucune source de profil n'est configurée, le workflow publie tout de même les captures d'écran déterministes des pièces jointes de base/candidate et consigne un avis indiquant que le témoin Discord Web connecté a été ignoré.

La première primitive complète de transport desktop est le smoke desktop Slack :

pnpm openclaw qa mantis slack-desktop-smoke \
  --output-dir .artifacts/qa-e2e/mantis/slack-desktop \
  --gateway-setup \
  --scenario slack-canary \
  --keep-lease

Elle loue ou réutilise une machine desktop Crabbox, synchronise le checkout courant dans la VM, exécute pnpm openclaw qa slack dans cette VM, ouvre Slack Web dans le navigateur VNC, capture le bureau visible et copie à la fois les artefacts QA Slack et la capture d'écran VNC vers le répertoire de sortie local. C'est la première forme Mantis où le Gateway OpenClaw SUT et le navigateur vivent tous deux dans la même VM desktop Linux.

Avec --gateway-setup, la commande prépare un répertoire personnel OpenClaw jetable persistant dans $HOME/.openclaw-mantis/slack-openclaw, corrige la configuration Slack Socket Mode pour le canal sélectionné, démarre openclaw gateway run sur le port 38973 et garde Chrome en cours d'exécution dans la session VNC. C'est le mode « laissez-moi un desktop Linux avec Slack et une griffe en cours d'exécution » ; la voie QA Slack bot-à-bot reste la valeur par défaut lorsque --gateway-setup est omis.

Entrées requises pour --credential-source env :

OPENCLAW_QA_SLACK_CHANNEL_ID
OPENCLAW_QA_SLACK_DRIVER_BOT_TOKEN
OPENCLAW_QA_SLACK_SUT_BOT_TOKEN
OPENCLAW_QA_SLACK_SUT_APP_TOKEN
OPENCLAW_LIVE_OPENAI_KEY pour la voie de modèle distante. Si seul OPENAI_API_KEY est défini localement, Mantis le mappe vers OPENCLAW_LIVE_OPENAI_KEY avant d'invoquer Crabbox afin que le transfert d'environnement OPENCLAW_* de Crabbox puisse le transporter dans la VM.

Avec --gateway-setup --credential-source convex, Mantis loue l'identifiant Slack SUT depuis le pool partagé avant de créer la VM et transmet l'identifiant du canal loué, le jeton d'application Socket Mode et le jeton de bot comme environnement d'exécution OPENCLAW_MANTIS_SLACK_* dans le desktop. Cela garde les workflows GitHub légers : ils n'ont besoin que du secret du broker Convex, pas de jetons bruts de bot ou d'application Slack.

Indicateurs utiles pour le desktop Slack :

--lease-id <cbx_...> réexécute contre une machine où un opérateur s'est déjà connecté à Slack Web via VNC.
--gateway-setup démarre un Gateway Slack OpenClaw persistant dans la VM au lieu d'exécuter seulement la voie QA bot-à-bot.
--keep-lease garde la VM Gateway ouverte pour inspection VNC après succès ; --no-keep-lease l'arrête après la collecte des artefacts.
--slack-url <url> ouvre une URL Slack Web spécifique. Sans cela, Mantis dérive https://app.slack.com/client/<team>/<channel> depuis Slack auth.test lorsque le jeton de bot SUT est disponible.
--slack-channel-id <id> contrôle la liste d'autorisation des canaux Slack utilisée par la configuration du Gateway.
OPENCLAW_MANTIS_SLACK_BROWSER_PROFILE_DIR contrôle le profil Chrome persistant dans la VM. La valeur par défaut est $HOME/.config/openclaw-mantis/slack-chrome-profile, afin qu'une connexion Slack Web manuelle survive aux réexécutions sur la même location.
--credential-source convex --credential-role ci utilise le pool d'identifiants partagé au lieu de jetons d'environnement Slack directs.
--provider-mode, --model, --alt-model et --fast sont transmis à la voie Slack réelle.

Le workflow smoke GitHub est Mantis Discord Smoke. Le workflow GitHub avant et après pour le premier scénario réel est Mantis Discord Status Reactions. Il accepte :

baseline_ref : la référence censée reproduire le comportement uniquement en file d'attente.
candidate_ref : la référence censée afficher queued -> thinking -> done.

Il récupère la référence du harnais de workflow, construit des worktrees de base et candidats séparés, exécute discord-status-reactions-tool-only contre chaque worktree et téléverse baseline/, candidate/, comparison.json et mantis-report.md comme artefacts Actions. Il rend aussi le HTML de chronologie de chaque voie dans un navigateur desktop Crabbox et publie ces captures d'écran VNC à côté des PNG de chronologie déterministes dans le commentaire de PR. Le même commentaire de PR intègre des aperçus GIF légers élagués par mouvement générés par crabbox media preview, lie les clips MP4 correspondants élagués par mouvement et conserve les fichiers MP4 desktop complets pour une inspection approfondie. Les captures d'écran restent intégrées pour un examen rapide. Le workflow construit la CLI Crabbox depuis la branche main de openclaw/crabbox afin de pouvoir utiliser les indicateurs actuels de location desktop/navigateur avant que la prochaine version binaire de Crabbox ne soit publiée.

Mantis Scenario est le point d'entrée manuel générique. Il prend un scenario_id, un candidate_ref, un baseline_ref facultatif et un pr_number facultatif, puis déclenche le workflow possédé par le scénario. Le wrapper est intentionnellement léger : les workflows de scénario possèdent toujours leur configuration de transport, leurs identifiants, leur classe de VM, leur oracle attendu et leur manifeste d'artefacts.

Mantis Slack Desktop Smoke est le premier workflow VM Slack. Il extrait la référence candidate de confiance dans un worktree séparé, loue un bureau Linux Crabbox, exécute pnpm openclaw qa mantis slack-desktop-smoke --gateway-setup sur ce candidat, ouvre Slack Web dans le navigateur VNC, enregistre le bureau, génère un aperçu recadré sur le mouvement avec crabbox media preview, téléverse le répertoire complet des artefacts, et publie éventuellement le commentaire de preuve intégré sur la PR cible. Il utilise AWS par défaut pour la location du bureau et expose une entrée manuelle de fournisseur afin que les opérateurs puissent passer à Hetzner lorsque la capacité AWS est lente ou indisponible. Utilisez cette voie lorsque vous voulez « un bureau Linux avec Slack et une griffe en cours d’exécution » au lieu d’une simple transcription Slack de bot à bot.

Chaque scénario qui publie sur une PR écrit mantis-evidence.json à côté de son rapport. Ce schéma est le passage de relais entre le code du scénario et les commentaires GitHub :

{
  "schemaVersion": 1,
  "id": "discord-status-reactions",
  "title": "Mantis Discord Status Reactions QA",
  "summary": "Human-readable top summary for the PR comment.",
  "scenario": "discord-status-reactions-tool-only",
  "comparison": {
    "baseline": { "sha": "...", "status": "fail", "expected": "queued-only" },
    "candidate": { "sha": "...", "status": "pass", "expected": "queued -> thinking -> done" },
    "pass": true
  },
  "artifacts": [
    {
      "kind": "timeline",
      "lane": "baseline",
      "label": "Baseline queued-only",
      "path": "baseline/timeline.png",
      "targetPath": "baseline.png",
      "alt": "Baseline Discord timeline",
      "width": 420
    }
  ]
}

Les valeurs d’artefact path sont relatives au répertoire du manifeste. Les valeurs targetPath sont des chemins relatifs sous le répertoire de publication de la branche qa-artifacts. Le publieur refuse les traversées de chemin et ignore les entrées marquées "required": false lorsque les aperçus ou vidéos facultatifs sont indisponibles.

Types d’artefacts pris en charge :

timeline : capture d’écran déterministe du scénario, généralement avant/après.
desktopScreenshot : capture d’écran du bureau VNC/navigateur.
motionPreview : GIF animé intégré généré depuis l’enregistrement du bureau.
motionClip : MP4 recadré sur le mouvement qui supprime l’amorce et la fin statiques.
fullVideo : enregistrement MP4 complet pour inspection approfondie.
metadata : fichier auxiliaire JSON/journal.
report : rapport Markdown.

Le publieur réutilisable est scripts/mantis/publish-pr-evidence.mjs. Les workflows l’appellent avec le manifeste, la PR cible, la racine cible qa-artifacts, le marqueur de commentaire, l’URL de l’artefact Actions, l’URL d’exécution et la source de la demande. Il copie les artefacts déclarés vers la branche qa-artifacts, construit un commentaire de PR commençant par le résumé avec images/aperçus intégrés et vidéos liées, puis met à jour le commentaire marqué existant ou en crée un.

Vous pouvez aussi déclencher directement l’exécution status-reactions depuis un commentaire de PR :

@Mantis discord status reactions

Le déclencheur par commentaire est volontairement restreint. Il ne s’exécute que sur les commentaires de pull request provenant d’utilisateurs disposant d’un accès write, maintain ou admin, et ne reconnaît que les demandes de réactions de statut Discord. Par défaut, il utilise la référence de base connue comme mauvaise et le SHA de tête de la PR actuelle comme candidat. Les mainteneurs peuvent remplacer l’une ou l’autre référence :

@Mantis discord status reactions baseline=origin/main candidate=HEAD

Exemples de commandes ClawSweeper :

@clawsweeper mantis discord discord-status-reactions-tool-only
@clawsweeper verify e2e discord

La première commande est explicite et centrée sur le scénario. La seconde pourra ensuite associer une PR ou une issue à des scénarios Mantis recommandés à partir des labels, des fichiers modifiés et des résultats de revue ClawSweeper.

Cycle de vie de l’exécution

Acquérir les identifiants.
Allouer ou réutiliser une VM.
Préparer le profil bureau/navigateur lorsque le scénario nécessite une preuve UI.
Préparer un checkout propre pour la référence de base.
Installer les dépendances et construire uniquement ce dont le scénario a besoin.
Démarrer un Gateway OpenClaw enfant avec un répertoire d’état isolé.
Configurer le transport live, le fournisseur, le modèle et le profil navigateur.
Exécuter le scénario et capturer les preuves de base.
Arrêter le Gateway et conserver les journaux.
Préparer la référence candidate dans la même VM.
Exécuter le même scénario et capturer les preuves candidates.
Comparer les résultats de l’oracle et les preuves visuelles.
Écrire le Markdown, le JSON, les journaux, les captures d’écran et les artefacts de trace facultatifs.
Téléverser les artefacts GitHub Actions.
Publier un message d’état concis sur la PR ou Discord.

Le scénario doit pouvoir échouer de deux façons différentes :

Bug reproduit : la base a échoué de la façon attendue.
Échec du banc de test : la configuration de l’environnement, les identifiants, l’API Discord, le navigateur ou le fournisseur a échoué avant que l’oracle du bug soit significatif.

Le rapport final doit séparer ces cas afin que les mainteneurs ne confondent pas un environnement instable avec le comportement du produit.

MVP Discord

Le premier scénario doit cibler les réactions de statut Discord dans les canaux de guilde où le mode de livraison de la réponse source est message_tool_only.

Pourquoi c’est une bonne graine Mantis :

C’est visible dans Discord sous forme de réactions sur le message déclencheur.
Il dispose d’un oracle REST solide via l’état des réactions du message Discord.
Il exerce un vrai Gateway OpenClaw, l’authentification du bot Discord, l’envoi de messages, le mode de livraison de réponse source, l’état des réactions de statut et le cycle de vie du tour de modèle.
Il est suffisamment restreint pour garder la première implémentation honnête.

Forme attendue du scénario :

id: discord-status-reactions-tool-only
transport: discord
baseline:
  expect:
    reproduced: true
candidate:
  expect:
    fixed: true
config:
  messages:
    ackReaction: "👀"
    ackReactionScope: "group-mentions"
    groupChat:
      visibleReplies: "message_tool"
    statusReactions:
      enabled: true
      timing:
        debounceMs: 0
discord:
  requireMention: true
  notifyChannel: operator-notify
evidence:
  rest:
    messageReactions: true
  browser:
    screenshotMessageRow: true

Les preuves de base doivent montrer la réaction d’accusé de réception en file d’attente, mais aucune transition de cycle de vie en mode tool-only. Les preuves candidates doivent montrer l’exécution des réactions de statut de cycle de vie lorsque messages.statusReactions.enabled vaut explicitement true.

La première tranche exécutable est le scénario QA live Discord opt-in :

pnpm openclaw qa discord \
  --scenario discord-status-reactions-tool-only \
  --provider-mode live-frontier \
  --model openai/gpt-5.4 \
  --alt-model openai/gpt-5.4 \
  --fast \
  --output-dir .artifacts/qa-e2e/mantis/discord-status-reactions-candidate

Il configure le SUT avec une gestion de guilde toujours activée, visibleReplies: "message_tool", ackReaction: "👀" et des réactions de statut explicites. L’oracle interroge le vrai message déclencheur Discord et attend la séquence observée 👀 -> 🤔 -> 👍. Les artefacts incluent discord-qa-reaction-timelines.json, discord-status-reactions-tool-only-timeline.html et discord-status-reactions-tool-only-timeline.png.

Éléments QA existants

Mantis doit s’appuyer sur la pile QA privée existante au lieu de repartir de zéro :

pnpm openclaw qa discord exécute déjà une voie Discord live avec des bots pilote et SUT.
Le lanceur de transport live écrit déjà des rapports et des artefacts de messages observés sous .artifacts/qa-e2e/.
Les locations d’identifiants Convex fournissent déjà un accès exclusif aux identifiants de transport live partagés.
Le service de contrôle du navigateur prend déjà en charge les captures d’écran, les instantanés, les profils managés headless et les profils CDP distants.
QA Lab dispose déjà d’une UI de débogage et d’un bus pour les tests structurés comme des transports.

La première implémentation de Mantis peut être un lanceur avant/après léger au dessus de ces éléments, plus une couche de preuve visuelle.

Modèle de preuve

Chaque exécution écrit un répertoire d’artefacts stable :

.artifacts/qa-e2e/mantis/<run-id>/
  mantis-report.md
  mantis-summary.json
  baseline/
    summary.json
    discord-message.json
    screenshot-message-row.png
    gateway-debug/
  candidate/
    summary.json
    discord-message.json
    screenshot-message-row.png
    gateway-debug/
  comparison.json
  run.log

mantis-summary.json doit être la source de vérité lisible par machine. Le rapport Markdown est destiné aux commentaires de PR et à la revue humaine.

Le résumé doit inclure :

les refs et SHA testés
le transport et l’identifiant de scénario
le fournisseur de machine et l’identifiant de machine ou de location
la source des identifiants sans valeurs secrètes
le résultat de base
le résultat candidat
si le bug s’est reproduit sur la base
si le candidat l’a corrigé
les chemins d’artefacts
les problèmes de configuration ou de nettoyage assainis

Les captures d’écran sont des preuves, pas des secrets. Elles exigent néanmoins une discipline de caviardage : des noms de canaux privés, des noms d’utilisateurs ou le contenu de messages peuvent apparaître. Pour les PR publiques, préférez les liens d’artefacts GitHub Actions aux images intégrées tant que l’histoire du caviardage n’est pas plus solide.

Navigateur et VNC

La voie navigateur a deux modes :

Automatisation headless : par défaut pour la CI. Chrome s’exécute avec CDP activé, et Playwright ou le contrôle de navigateur OpenClaw capture les captures d’écran.
Secours VNC : activé sur la même VM lorsque la connexion, la MFA, l’anti-automatisation Discord ou le débogage visuel nécessite un humain.

Le profil navigateur d’observateur Discord doit être assez persistant pour éviter de se connecter à chaque exécution, mais isolé de l’état de navigateur personnel. Un profil appartient au pool de machines Mantis, pas à un ordinateur portable de développeur.

Lorsque Mantis se bloque, il publie un message d’état Discord avec :

l’identifiant d’exécution
l’identifiant de scénario
le fournisseur de machine
le répertoire d’artefacts
les instructions de connexion VNC ou noVNC si disponibles
un court texte de blocage

Le premier déploiement privé peut publier ces messages dans le canal opérateur existant et passer plus tard à un canal Mantis dédié.

Machines

Mantis doit privilégier AWS via Crabbox pour la première implémentation distante. Crabbox nous fournit des machines préchauffées, le suivi des locations, l’hydratation, les journaux, les résultats et le nettoyage. Si la capacité AWS est trop lente ou indisponible, ajoutez un fournisseur Hetzner derrière la même interface de machine.

Exigences minimales de la VM :

Linux avec une installation Chrome ou Chromium capable d’afficher un bureau
accès CDP pour l’automatisation du navigateur
VNC ou noVNC pour le secours
Node 22 et pnpm
checkout OpenClaw et cache de dépendances
cache de navigateur Chromium Playwright lorsque Playwright est utilisé
assez de CPU et de mémoire pour un Gateway OpenClaw, un navigateur et une exécution de modèle
accès sortant vers Discord, GitHub, les fournisseurs de modèles et le courtier d’identifiants

La VM ne doit pas conserver de secrets bruts à longue durée de vie en dehors des magasins d’identifiants ou de profils navigateur attendus.

Secrets

Les secrets vivent dans les secrets d’organisation ou de dépôt GitHub pour les exécutions distantes, et dans un fichier secret local contrôlé par l’opérateur pour les exécutions locales.

Noms de secrets recommandés :

OPENCLAW_QA_DISCORD_MANTIS_BOT_TOKEN
OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN
OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN
OPENCLAW_QA_DISCORD_GUILD_ID
OPENCLAW_QA_DISCORD_CHANNEL_ID
OPENCLAW_QA_DISCORD_NOTIFY_CHANNEL_ID
OPENCLAW_QA_REDACT_PUBLIC_METADATA=1 pour les téléversements d’artefacts GitHub publics
OPENCLAW_QA_CONVEX_SITE_URL
OPENCLAW_QA_CONVEX_SECRET_CI
OPENCLAW_QA_MANTIS_CRABBOX_COORDINATOR
OPENCLAW_QA_MANTIS_CRABBOX_COORDINATOR_TOKEN

À long terme, le pool d’identifiants Convex doit rester la source normale pour les identifiants de transport live. Les secrets GitHub amorcent le courtier et les voies de secours. Le workflow de réactions de statut Discord remappe les secrets Mantis Crabbox vers les variables d’environnement CRABBOX_COORDINATOR et CRABBOX_COORDINATOR_TOKEN attendues par la CLI Crabbox. Les noms de secrets GitHub simples CRABBOX_* restent acceptés comme solution de compatibilité.

Le lanceur Mantis ne doit jamais afficher :

les jetons de bots Discord
les clés API des fournisseurs
les cookies de navigateur
le contenu des profils d’authentification
les mots de passe VNC
les charges utiles d’identifiants brutes

Les téléversements d’artefacts publics doivent également caviarder les métadonnées de cible Discord comme les identifiants de bot, guilde, canal et message. Le workflow smoke GitHub active OPENCLAW_QA_REDACT_PUBLIC_METADATA=1 pour cette raison.

Si un jeton est accidentellement collé dans une issue, une PR, une discussion ou un journal, faites-le tourner après avoir stocké le nouveau secret.

Artefacts GitHub et commentaires de PR

Les workflows Mantis doivent téléverser le lot complet de preuves sous forme d’artefact Actions à courte durée de vie. Lorsque le workflow est exécuté pour un rapport de bug ou une PR de correctif, il doit également publier les captures d’écran PNG expurgées dans la branche qa-artifacts et upsert un commentaire sur ce bug ou cette PR de correctif avec des captures d’écran avant/après intégrées. Ne publiez pas la preuve principale uniquement sur une PR générique d’automatisation QA. Les journaux bruts, les messages observés et les autres preuves volumineuses restent dans l’artefact Actions.

Les workflows de production doivent publier ces commentaires avec la GitHub App Mantis, et non avec github-actions[bot]. Stockez l’identifiant de l’application et la clé privée comme secrets GitHub Actions MANTIS_GITHUB_APP_ID et MANTIS_GITHUB_APP_PRIVATE_KEY. Le workflow utilise un marqueur masqué comme clé d’upsert, met à jour ce commentaire lorsque le jeton peut le modifier, et crée un nouveau commentaire appartenant à Mantis lorsqu’un ancien marqueur appartenant au bot ne peut pas être modifié.

Le commentaire de PR doit être court et visuel :

Mantis Discord Status Reactions QA

Summary: Mantis reran the reported Discord status-reaction bug against the known
bad baseline and the candidate fix. The baseline reproduced the bug, while the
candidate showed the expected queued -> thinking -> done sequence.

- Scenario: `discord-status-reactions-tool-only`
- Run: <workflow run link>
- Artifact: <artifact link>
- Baseline: `<status>` at `<sha>`
- Candidate: `<status>` at `<sha>`

| Baseline            | Candidate           |
| ------------------- | ------------------- |
| <inline screenshot> | <inline screenshot> |

Lorsque l’exécution échoue parce que le harnais a échoué, le commentaire doit le dire au lieu d’impliquer que le candidat a échoué.

Notes de déploiement privé

Un déploiement privé peut déjà avoir une application Discord Mantis. Réutilisez cette application au lieu de créer une autre app lorsqu’elle dispose des bonnes permissions de bot et peut faire l’objet d’une rotation en toute sécurité.

Définissez le canal initial de notification des opérateurs via les secrets ou la configuration de déploiement. Il peut d’abord pointer vers un canal existant de maintenance ou d’opérations, puis être déplacé vers un canal Mantis dédié une fois qu’il existe.

Ne mettez pas d’identifiants de serveur, d’identifiants de canal, de jetons de bot, de cookies de navigateur ni de mots de passe VNC dans ce document. Stockez-les dans les secrets GitHub, le courtier d’identifiants ou le magasin local de secrets de l’opérateur.

Ajouter un scénario

Un scénario Mantis doit déclarer :

id et titre
transport
identifiants requis
politique de référence de baseline
politique de référence de candidat
correctif de configuration OpenClaw
étapes de configuration
stimulus
oracle de baseline attendu
oracle de candidat attendu
cibles de capture visuelle
budget de délai d’expiration
étapes de nettoyage

Les scénarios doivent privilégier de petits oracles typés :

état de réaction Discord pour les bugs de réactions
références de messages Discord pour les bugs de fils de discussion
ts de fil Slack et état de l’API de réaction pour les bugs Slack
identifiants et en-têtes de messages e-mail pour les bugs d’e-mail
captures d’écran du navigateur lorsque l’interface utilisateur est le seul observable fiable

Les vérifications visuelles doivent être additives. Si une API de plateforme peut prouver le bug, utilisez l’API comme oracle de réussite/échec et conservez les captures d’écran pour donner confiance aux humains.

Extension des fournisseurs

Après Discord, le même exécuteur peut ajouter :

Slack : réactions, fils de discussion, mentions d’app, modales, téléversements de fichiers.
E-mail : authentification Gmail et fils de messages avec gog lorsque les connecteurs ne suffisent pas.
WhatsApp : connexion par QR code, ré-identification, livraison de messages, médias, réactions.
Telegram : contrôle des mentions de groupe, commandes, réactions lorsque disponibles.
Matrix : salons chiffrés, relations de fil ou de réponse, reprise après redémarrage.

Chaque transport doit avoir un scénario de smoke peu coûteux et un ou plusieurs scénarios par classe de bug. Les scénarios visuels coûteux doivent rester optionnels.

Questions ouvertes

Quel bot Discord doit être le pilote, et lequel doit être le SUT, lorsque le bot Mantis existant est réutilisé ?
La connexion du navigateur observateur doit-elle utiliser un compte Discord humain, un compte de test, ou uniquement des preuves REST lisibles par le bot pour la première phase ?
Combien de temps GitHub doit-il conserver les artefacts Mantis pour les PR ?
Quand ClawSweeper doit-il recommander automatiquement Mantis au lieu d’attendre une commande d’un mainteneur ?
Les captures d’écran doivent-elles être expurgées ou recadrées avant le téléversement pour les PR publiques ?

# Objectifs

# Non-objectifs

# Propriété

# Forme de commande

# Cycle de vie de l’exécution

# MVP Discord

# Éléments QA existants

# Modèle de preuve

# Navigateur et VNC

# Machines

# Secrets

# Artefacts GitHub et commentaires de PR

# Notes de déploiement privé

# Ajouter un scénario

# Extension des fournisseurs

# Questions ouvertes