Mantis - OpenClaw

Mantis es el sistema de verificación de extremo a extremo de OpenClaw para errores que necesitan un runtime real, un transporte real y evidencia visible. Ejecuta un escenario contra una ref conocida como defectuosa, captura evidencia, ejecuta el mismo escenario contra una ref candidata y publica la comparación como artefactos que un maintainer puede inspeccionar desde un PR o desde un comando local. Mantis empieza con Discord porque Discord nos da un primer carril de alto valor: autenticación real de bot, canales reales de guild, reacciones, hilos, comandos nativos y una interfaz de navegador donde los humanos pueden confirmar visualmente lo que mostró el transporte.

Objetivos

Reproducir un error desde un issue o PR de GitHub con la misma forma de transporte que ven los usuarios.
Capturar un artefacto antes en la ref base antes de aplicar la corrección.
Capturar un artefacto después en la ref candidata después de aplicar la corrección.
Usar un oráculo determinista siempre que sea posible, como una lectura de reacción de Discord REST o una comprobación de transcript del canal.
Capturar capturas de pantalla cuando el error tenga una superficie de interfaz visible.
Ejecutarse localmente desde una CLI controlada por agente y remotamente desde GitHub.
Preservar suficiente estado de la máquina para rescate por VNC cuando el inicio de sesión, la automatización del navegador o la autenticación del proveedor se bloqueen.
Publicar estado conciso en un canal de operador de Discord cuando la ejecución esté bloqueada, necesite ayuda manual por VNC o finalice.

No objetivos

Mantis no reemplaza las pruebas unitarias. Una ejecución de Mantis normalmente debería convertirse en una prueba de regresión más pequeña después de entender la corrección.
Mantis no es la puerta rápida normal de CI. Es más lento, usa credenciales reales y está reservado para errores donde importa el entorno real.
Mantis no debería requerir una persona para la operación normal. VNC manual es una ruta de rescate, no el camino esperado.
Mantis no almacena secretos sin procesar en artefactos, logs, capturas de pantalla, informes Markdown ni comentarios de PR.

Propiedad

Mantis vive en la pila de QA de OpenClaw.

OpenClaw posee el runtime de escenarios, los adaptadores de transporte, el esquema de evidencia y la CLI local bajo pnpm openclaw qa mantis.
QA Lab posee las piezas del arnés de transporte real, los helpers de captura de navegador y los escritores de artefactos.
Crabbox posee las máquinas Linux preparadas cuando se necesita una VM remota.
GitHub Actions posee el punto de entrada del workflow remoto y la retención de artefactos.
ClawSweeper posee el enrutamiento de comentarios de GitHub: analizar comandos de maintainers, despachar el workflow y publicar el comentario final del PR.
Los agentes de OpenClaw conducen Mantis mediante Codex cuando un escenario necesita configuración agéntica, depuración o informes de estado bloqueado.

Este límite mantiene el conocimiento de transporte en OpenClaw, la programación de máquinas en Crabbox y el pegamento de workflow de maintainers en ClawSweeper.

Forma de comando

El primer comando local verifica el bot de Discord, guild, canal, envío de mensaje, envío de reacción y ruta de artefactos:

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

El runner local de antes y después acepta esta forma:

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

El runner crea worktrees desconectados de base y candidata bajo el directorio de salida, instala dependencias, compila cada ref, ejecuta el escenario con --allow-failures y luego escribe baseline/, candidate/, comparison.json y mantis-report.md. Para el primer escenario de Discord, una verificación exitosa significa que el estado de base es fail y el estado candidato es pass. La segunda sonda de antes/después de Discord apunta a adjuntos en hilos:

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

Ese escenario publica un mensaje padre con el bot controlador, crea un hilo real de Discord, llama a la acción message.thread-reply de OpenClaw con un filePath local del repo y luego sondea el hilo para encontrar la respuesta del SUT y el nombre de archivo adjunto. La captura de pantalla de base muestra la respuesta sin adjunto; la captura de pantalla candidata muestra el adjunto esperado mantis-thread-report.md. La primera primitiva de VM/navegador es el smoke de escritorio:

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

Arrienda o reutiliza una máquina de escritorio de Crabbox, inicia un navegador visible dentro de la sesión VNC, captura el escritorio, trae los artefactos de vuelta al directorio de salida local y escribe el comando de reconexión en el informe. El comando usa por defecto el proveedor Hetzner porque es el primer proveedor con cobertura funcional de escritorio/VNC en el carril Mantis. Sobrescríbelo con --provider, --crabbox-bin u OPENCLAW_MANTIS_CRABBOX_PROVIDER cuando ejecutes contra otra flota de Crabbox. Flags útiles del smoke de escritorio:

--lease-id <cbx_...> u OPENCLAW_MANTIS_CRABBOX_LEASE_ID reutiliza un escritorio preparado.
--browser-url <url> cambia la página abierta en el navegador visible.
--html-file <path> renderiza un artefacto HTML local del repo en el navegador visible. Mantis usa esto para capturar la línea de tiempo generada de reacciones de estado de Discord mediante un escritorio real de Crabbox.
--browser-profile-dir <remote-path> reutiliza un Chrome user-data-dir remoto para que un escritorio persistente de Mantis pueda permanecer con sesión iniciada entre ejecuciones. Usa esto para el perfil de visor de Discord Web de larga duración.
--browser-profile-archive-env <name> restaura un archivo .tgz base64 de Chrome user-data-dir desde la variable de entorno nombrada antes de iniciar el navegador. Usa esto para testigos con sesión iniciada como Discord Web. La variable de entorno predeterminada es OPENCLAW_MANTIS_BROWSER_PROFILE_TGZ_B64.
--video-duration <seconds> controla la duración de la captura MP4. Usa una duración mayor para apps web lentas con sesión iniciada que necesitan tiempo para estabilizarse.
--keep-lease u OPENCLAW_MANTIS_KEEP_VM=1 mantiene abierta para inspección por VNC una lease recién creada que pasó. Las ejecuciones fallidas mantienen la lease por defecto cuando se creó una para que un operador pueda reconectarse.
--class, --idle-timeout y --ttl ajustan el tamaño de máquina y la vida útil de la lease.

Para evidencia de Discord Web, Mantis usa una cuenta de visor dedicada en lugar de un token de bot. El escenario de API real de Discord sigue siendo el oráculo: crea el hilo real, envía el thread-reply del SUT y comprueba el adjunto mediante Discord REST. Cuando OPENCLAW_QA_DISCORD_CAPTURE_UI_METADATA=1 está configurado, el escenario también escribe un artefacto de URL de Discord Web. Cuando OPENCLAW_QA_DISCORD_KEEP_THREADS=1 está configurado, deja ese hilo disponible el tiempo suficiente para que un navegador con sesión iniciada lo abra y lo grabe. El workflow de GitHub abre la URL del hilo candidato en Discord Web, captura una captura de pantalla, graba un MP4 y genera una vista previa GIF recortada por movimiento cuando las herramientas de medios de Crabbox están disponibles. Prefiere una ruta de perfil de visor persistente configurada mediante MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR, porque los archivos de perfil completo de Chrome pueden superar el límite de tamaño de secretos de GitHub. Para perfiles pequeños/de arranque, el workflow también puede restaurar un archivo .tgz base64 desde MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64. Si no se configura ninguna fuente de perfil, el workflow igualmente publica las capturas de pantalla deterministas de adjuntos de base/candidato y registra un aviso de que se omitió el testigo de Discord Web con sesión iniciada. La primera primitiva completa de transporte de escritorio es el smoke de escritorio de Slack:

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

Arrienda o reutiliza una máquina de escritorio de Crabbox, sincroniza el checkout actual en la VM, ejecuta pnpm openclaw qa slack dentro de esa VM, abre Slack Web en el navegador VNC, captura el escritorio visible y copia tanto los artefactos de Slack QA como la captura de pantalla VNC de vuelta al directorio de salida local. Esta es la primera forma de Mantis donde el Gateway de OpenClaw del SUT y el navegador viven ambos dentro de la misma VM de escritorio Linux. Con --gateway-setup, el comando prepara un home persistente y desechable de OpenClaw en $HOME/.openclaw-mantis/slack-openclaw, parchea la configuración de Slack Socket Mode para el canal seleccionado, inicia openclaw gateway run en el puerto 38973 y mantiene Chrome ejecutándose en la sesión VNC. Este es el modo “déjame un escritorio Linux con Slack y un claw ejecutándose”; el carril Slack QA bot-a-bot sigue siendo el predeterminado cuando se omite --gateway-setup. Entradas requeridas para --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 para el carril de modelo remoto. Si solo OPENAI_API_KEY está configurado localmente, Mantis lo mapea a OPENCLAW_LIVE_OPENAI_KEY antes de invocar Crabbox para que el reenvío de entorno OPENCLAW_* de Crabbox pueda llevarlo a la VM.

Con --gateway-setup --credential-source convex, Mantis arrienda la credencial del SUT de Slack desde el pool compartido antes de crear la VM y reenvía el id de canal arrendado, el token de app de Socket Mode y el token de bot como el entorno de runtime OPENCLAW_MANTIS_SLACK_* dentro del escritorio. Eso mantiene los workflows de GitHub ligeros: solo necesitan el secreto del broker de Convex, no tokens sin procesar de bot o app de Slack. Flags útiles del escritorio de Slack:

--lease-id <cbx_...> vuelve a ejecutar contra una máquina donde un operador ya inició sesión en Slack Web mediante VNC.
--gateway-setup inicia un Gateway persistente de OpenClaw para Slack en la VM en lugar de ejecutar solo el carril QA bot-a-bot.
--keep-lease mantiene abierta la VM del Gateway para inspección por VNC después del éxito; --no-keep-lease la detiene después de recopilar artefactos.
--slack-url <url> abre una URL específica de Slack Web. Sin ella, Mantis deriva https://app.slack.com/client/<team>/<channel> desde auth.test de Slack cuando el token de bot del SUT está disponible.
--slack-channel-id <id> controla la allowlist de canales de Slack usada por la configuración del Gateway.
OPENCLAW_MANTIS_SLACK_BROWSER_PROFILE_DIR controla el perfil persistente de Chrome dentro de la VM. El valor predeterminado es $HOME/.config/openclaw-mantis/slack-chrome-profile, por lo que un inicio de sesión manual en Slack Web sobrevive a nuevas ejecuciones en la misma lease.
--credential-source convex --credential-role ci usa el pool de credenciales compartido en lugar de tokens directos de entorno de Slack.
--provider-mode, --model, --alt-model y --fast se pasan al carril live de Slack.

El workflow smoke de GitHub es Mantis Discord Smoke. El workflow de antes y después de GitHub para el primer escenario real es Mantis Discord Status Reactions. Acepta:

baseline_ref: la ref que se espera que reproduzca el comportamiento solo en cola.
candidate_ref: la ref que se espera que muestre queued -> thinking -> done.

Hace checkout de la ref del arnés de workflow, compila worktrees separados de base y candidato, ejecuta discord-status-reactions-tool-only contra cada worktree y sube baseline/, candidate/, comparison.json y mantis-report.md como artefactos de Actions. También renderiza el HTML de línea de tiempo de cada carril en un navegador de escritorio de Crabbox y publica esas capturas de pantalla VNC junto a los PNG deterministas de línea de tiempo en el comentario del PR. El mismo comentario de PR incrusta vistas previas GIF ligeras recortadas por movimiento generadas por crabbox media preview, enlaza los clips MP4 correspondientes recortados por movimiento y conserva los archivos MP4 completos del escritorio para inspección profunda. Las capturas de pantalla permanecen inline para revisión rápida. El workflow compila la CLI de Crabbox desde openclaw/crabbox main para poder usar las flags actuales de lease de escritorio/navegador antes de que se publique la siguiente versión binaria de Crabbox. Mantis Scenario es el punto de entrada manual genérico. Toma un scenario_id, candidate_ref, un baseline_ref opcional y un pr_number opcional, y luego despacha el workflow propiedad del escenario. El wrapper es intencionalmente delgado: los workflows de escenario siguen siendo dueños de su configuración de transporte, credenciales, clase de VM, oráculo esperado y manifiesto de artefactos. Mantis Slack Desktop Smoke es el primer flujo de trabajo de VM de Slack. Comprueba la referencia candidata de confianza en un worktree separado, arrienda un escritorio Linux de Crabbox, ejecuta pnpm openclaw qa mantis slack-desktop-smoke --gateway-setup contra ese candidato, abre Slack Web en el navegador VNC, graba el escritorio, genera una vista previa recortada por movimiento con crabbox media preview, sube el directorio completo de artefactos y, opcionalmente, publica el comentario de evidencia en línea en la PR de destino. Usa AWS de forma predeterminada para el arrendamiento del escritorio y expone una entrada manual de proveedor para que los operadores puedan cambiar a Hetzner cuando la capacidad de AWS sea lenta o no esté disponible. Usa este carril cuando quieras “un escritorio Linux con Slack y un claw ejecutándose” en lugar de solo una transcripción de Slack de bot a bot. Mantis Telegram Live envuelve el carril de QA en vivo existente de Telegram en la misma canalización de evidencia de PR. Comprueba la referencia candidata de confianza en un worktree separado, ejecuta pnpm openclaw qa telegram --credential-source convex --credential-role ci, escribe un manifiesto mantis-evidence.json a partir del resumen de QA de Telegram y el artefacto de mensaje observado, renderiza el HTML de la transcripción redactada mediante un navegador de escritorio de Crabbox, genera un GIF recortado por movimiento con crabbox media preview y publica el comentario de evidencia en línea de la PR cuando hay disponible un número de PR. Este carril es visual de transcripción, no una prueba de Telegram Web con sesión iniciada: la API de Bot de Telegram proporciona evidencia estable de mensajes en vivo, pero el estado de inicio de sesión de Telegram Web no es necesario para la automatización normal de Mantis. Mantis Telegram Desktop Proof es el wrapper agentic nativo de Telegram Desktop de antes/después. Un mantenedor puede activarlo desde un comentario de PR con @Mantis telegram desktop proof, desde la interfaz de Actions con instrucciones de formato libre, o mediante el despachador genérico Mantis Scenario. El flujo de trabajo entrega a Codex la PR, la referencia de baseline, la referencia candidata y las instrucciones del mantenedor. El agente lee la PR, decide qué comportamiento visible en Telegram prueba el cambio, ejecuta el carril de prueba real de Telegram Desktop en Crabbox con usuario real para baseline y candidato, itera hasta que los GIF nativos sean útiles, escribe artefactos motionPreview emparejados en mantis-evidence.json, sube el paquete y publica una tabla de evidencia de PR de 2 columnas cuando hay disponible un número de PR. Para la configuración de escritorio de Telegram con intervención humana, usa el constructor de escenarios:

pnpm openclaw qa mantis telegram-desktop-builder \
  --credential-source convex \
  --credential-role maintainer \
  --keep-lease

El constructor arrienda o reutiliza un escritorio de Crabbox, instala el binario nativo de Telegram Desktop para Linux, opcionalmente restaura un archivo de sesión de usuario, configura OpenClaw con el token del bot SUT de Telegram arrendado, inicia openclaw gateway run en el puerto 38974, publica un mensaje de preparación del bot controlador en el grupo privado arrendado y luego captura una captura de pantalla y un MP4 desde el escritorio VNC visible. Un token de bot nunca inicia sesión en Telegram Desktop; solo configura OpenClaw. El visor de escritorio es una sesión de usuario de Telegram independiente restaurada desde --telegram-profile-archive-env <name> o creada manualmente mediante VNC y mantenida activa con --keep-lease. Indicadores útiles del constructor de escritorio de Telegram:

--lease-id <cbx_...> vuelve a ejecutar contra una VM donde un operador ya inició sesión en Telegram Desktop.
--telegram-profile-archive-env <name> lee un archivo de perfil de Telegram Desktop .tgz en base64 desde esa variable de entorno y lo restaura antes del inicio.
--telegram-profile-dir <remote-path> controla el directorio remoto del perfil de Telegram Desktop. El valor predeterminado es $HOME/.local/share/TelegramDesktop.
--no-gateway-setup instala y abre Telegram Desktop sin configurar OpenClaw.
--credential-source convex --credential-role ci usa el broker de credenciales compartido en lugar de tokens directos de Telegram en el entorno.

Cada escenario que publica en PR escribe mantis-evidence.json junto a su informe. Este esquema es el traspaso entre el código del escenario y los comentarios de 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
    }
  ]
}

Los valores path de artefacto son relativos al directorio del manifiesto. Los valores targetPath son rutas relativas bajo el directorio de publicación de la rama qa-artifacts. El publicador rechaza el recorrido de rutas y omite las entradas marcadas como "required": false cuando las vistas previas o videos opcionales no están disponibles. Tipos de artefactos admitidos:

timeline: captura de pantalla determinista del escenario, normalmente antes/después.
desktopScreenshot: captura de pantalla del escritorio VNC/navegador.
motionPreview: GIF animado en línea generado a partir de la grabación del escritorio.
motionClip: MP4 recortado por movimiento que elimina la entrada y la cola estáticas.
fullVideo: grabación MP4 completa para inspección detallada.
metadata: archivo complementario JSON/log.
report: informe Markdown.

El publicador reutilizable es scripts/mantis/publish-pr-evidence.mjs. Los flujos de trabajo lo llaman con el manifiesto, la PR de destino, la raíz de destino de qa-artifacts, el marcador de comentario, la URL del artefacto de Actions, la URL de la ejecución y la fuente de la solicitud. Copia los artefactos declarados a la rama qa-artifacts, construye un comentario de PR con resumen primero con imágenes/vistas previas en línea y videos enlazados, y luego actualiza el comentario de marcador existente o crea uno. También puedes activar la ejecución de reacciones de estado directamente desde un comentario de PR:

@Mantis discord status reactions

El disparador de comentario es intencionadamente estrecho. Solo se ejecuta en comentarios de pull request de usuarios con acceso de escritura, mantenimiento o administración, y solo reconoce solicitudes de reacciones de estado de Discord. De forma predeterminada usa la referencia de baseline conocida como mala y el SHA actual de la cabecera de la PR como candidato. Los mantenedores pueden sobrescribir cualquiera de las referencias:

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

La QA en vivo de Telegram también puede activarse desde un comentario de PR:

@Mantis telegram
@Mantis telegram scenario=telegram-status-command
@Mantis telegram scenarios=telegram-status-command,telegram-mentioned-message-reply

De forma predeterminada usa el SHA actual de la cabecera de la PR como candidato y ejecuta telegram-status-command. Los mantenedores pueden sobrescribir candidate=..., provider=aws|hetzner y lease=<cbx_...> cuando necesitan una referencia específica o un escritorio de Crabbox precalentado. Ejemplos de comandos de ClawSweeper:

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

El primer comando es explícito y centrado en el escenario. El segundo puede posteriormente mapear una PR o issue a escenarios de Mantis recomendados a partir de etiquetas, archivos cambiados y hallazgos de revisión de ClawSweeper.

Ciclo de vida de ejecución

Adquirir credenciales.
Asignar o reutilizar una VM.
Preparar el perfil de escritorio/navegador cuando el escenario necesite evidencia de UI.
Preparar un checkout limpio para la referencia de baseline.
Instalar dependencias y compilar solo lo que el escenario necesita.
Iniciar un Gateway de OpenClaw hijo con un directorio de estado aislado.
Configurar el transporte en vivo, el proveedor, el modelo y el perfil del navegador.
Ejecutar el escenario y capturar evidencia de baseline.
Detener el Gateway y conservar los logs.
Preparar la referencia candidata en la misma VM.
Ejecutar el mismo escenario y capturar evidencia candidata.
Comparar los resultados del oráculo y la evidencia visual.
Escribir Markdown, JSON, logs, capturas de pantalla y artefactos de traza opcionales.
Subir artefactos de GitHub Actions.
Publicar un mensaje de estado conciso en la PR o en Discord.

El escenario debe poder fallar de dos maneras diferentes:

Bug reproducido: baseline falló de la forma esperada.
Fallo del arnés: la configuración del entorno, las credenciales, la API de Discord, el navegador o el proveedor fallaron antes de que el oráculo del bug fuera significativo.

El informe final debe separar estos casos para que los mantenedores no confundan un entorno inestable con el comportamiento del producto.

MVP de Discord

El primer escenario debe apuntar a reacciones de estado de Discord en canales de servidor donde el modo de entrega de respuesta de origen sea message_tool_only. Por qué es una buena semilla para Mantis:

Es visible en Discord como reacciones en el mensaje disparador.
Tiene un oráculo REST sólido mediante el estado de reacciones del mensaje de Discord.
Ejercita un Gateway de OpenClaw real, autenticación de bot de Discord, despacho de mensajes, modo de entrega de respuesta de origen, estado de reacciones de estado y ciclo de vida del turno del modelo.
Es lo bastante estrecho como para mantener honesta la primera implementación.

Forma esperada del escenario:

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

La evidencia de baseline debe mostrar la reacción de confirmación en cola, pero ninguna transición de ciclo de vida en modo solo herramienta. La evidencia candidata debe mostrar reacciones de estado de ciclo de vida ejecutándose cuando messages.statusReactions.enabled está explícitamente en true. La primera porción ejecutable es el escenario de QA en vivo de Discord con activación explícita:

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

Configura el SUT con manejo de servidor siempre activo, visibleReplies: "message_tool", ackReaction: "👀" y reacciones de estado explícitas. El oráculo sondea el mensaje disparador real de Discord y espera la secuencia observada 👀 -> 🤔 -> 👍. Los artefactos incluyen discord-qa-reaction-timelines.json, discord-status-reactions-tool-only-timeline.html y discord-status-reactions-tool-only-timeline.png.

Piezas de QA existentes

Mantis debe construirse sobre la pila privada de QA existente en lugar de empezar desde cero:

pnpm openclaw qa discord ya ejecuta un carril de Discord en vivo con bots controlador y SUT.
El runner de transporte en vivo ya escribe informes y artefactos de mensajes observados bajo .artifacts/qa-e2e/.
Los arrendamientos de credenciales de Convex ya proporcionan acceso exclusivo a credenciales compartidas de transporte en vivo.
El servicio de control de navegador ya admite capturas de pantalla, snapshots, perfiles administrados headless y perfiles CDP remotos.
QA Lab ya tiene una UI de depurador y bus para pruebas con forma de transporte.

La primera implementación de Mantis puede ser un runner ligero de antes/después sobre estas piezas, más una capa de evidencia visual.

Modelo de evidencia

Cada ejecución escribe un directorio estable de artefactos:

.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 debe ser la fuente de verdad legible por máquina. El informe Markdown es para comentarios de PR y revisión humana. El resumen debe incluir:

referencias y SHA probados
transporte e id del escenario
proveedor de máquina e id de máquina o id de arrendamiento
fuente de credenciales sin valores secretos
resultado de baseline
resultado candidato
si el bug se reprodujo en baseline
si el candidato lo corrigió
rutas de artefactos
problemas de configuración o limpieza saneados

Las capturas de pantalla son evidencia, no secretos. Aun así necesitan disciplina de censura: pueden aparecer nombres de canales privados, nombres de usuario o contenido de mensajes. Para PR públicos, prefiere enlaces a artefactos de GitHub Actions en lugar de imágenes insertadas hasta que la estrategia de censura sea más sólida.

Navegador y VNC

La vía del navegador tiene dos modos:

Automatización sin interfaz gráfica: predeterminada para CI. Chrome se ejecuta con CDP habilitado, y Playwright o el control de navegador de OpenClaw captura capturas de pantalla.
Rescate con VNC: habilitado en la misma VM cuando el inicio de sesión, MFA, la anti-automatización de Discord o la depuración visual necesitan a una persona.

El perfil del navegador observador de Discord debe ser lo bastante persistente para evitar iniciar sesión en cada ejecución, pero estar aislado del estado del navegador personal. Un perfil pertenece al conjunto de máquinas Mantis, no al portátil de un desarrollador. Cuando Mantis se atasca, publica un mensaje de estado de Discord con:

id de ejecución
id de escenario
proveedor de máquina
directorio de artefactos
instrucciones de conexión VNC o noVNC si están disponibles
texto breve del bloqueo

El primer despliegue privado puede publicar estos mensajes en el canal de operador existente y pasar más tarde a un canal dedicado de Mantis.

Máquinas

Mantis debe preferir AWS mediante Crabbox para la primera implementación remota. Crabbox nos da máquinas preparadas, seguimiento de asignaciones, hidratación, registros, resultados y limpieza. Si la capacidad de AWS es demasiado lenta o no está disponible, añade un proveedor de Hetzner detrás de la misma interfaz de máquina. Requisitos mínimos de la VM:

Linux con una instalación de Chrome o Chromium apta para escritorio
acceso CDP para automatización del navegador
VNC o noVNC para rescate
Node 22 y pnpm
checkout de OpenClaw y caché de dependencias
caché del navegador Chromium de Playwright cuando se use Playwright
CPU y memoria suficientes para un Gateway de OpenClaw, un navegador y una ejecución de modelo
acceso saliente a Discord, GitHub, proveedores de modelos y el broker de credenciales

La VM no debe conservar secretos sin procesar de larga duración fuera de los almacenes esperados de credenciales o perfiles de navegador.

Secretos

Los secretos viven en secretos de organización o repositorio de GitHub para ejecuciones remotas, y en un archivo local de secretos controlado por el operador para ejecuciones locales. Nombres de secretos recomendados:

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 para cargas públicas de artefactos de GitHub
OPENCLAW_QA_CONVEX_SITE_URL
OPENCLAW_QA_CONVEX_SECRET_CI
OPENCLAW_QA_MANTIS_CRABBOX_COORDINATOR
OPENCLAW_QA_MANTIS_CRABBOX_COORDINATOR_TOKEN

A largo plazo, el conjunto de credenciales de Convex debe seguir siendo la fuente normal para credenciales de transporte en vivo. Los secretos de GitHub inicializan el broker y las vías de respaldo. El flujo de trabajo de reacciones de estado de Discord asigna los secretos de Mantis Crabbox de vuelta a las variables de entorno CRABBOX_COORDINATOR y CRABBOX_COORDINATOR_TOKEN que espera la CLI de Crabbox. Los nombres de secretos de GitHub CRABBOX_* simples siguen aceptándose como respaldo de compatibilidad. El ejecutor de Mantis nunca debe imprimir:

tokens de bot de Discord
claves de API de proveedores
cookies del navegador
contenido de perfiles de autenticación
contraseñas de VNC
cargas útiles de credenciales sin procesar

Las cargas públicas de artefactos también deben censurar metadatos de destino de Discord como ids de bot, servidor, canal y mensaje. El flujo de trabajo de smoke de GitHub habilita OPENCLAW_QA_REDACT_PUBLIC_METADATA=1 por este motivo. Si un token se pega accidentalmente en una incidencia, PR, chat o registro, rótalo después de almacenar el nuevo secreto.

Artefactos de GitHub y comentarios de PR

Los flujos de trabajo de Mantis deben cargar el paquete completo de evidencia como un artefacto de Actions de corta duración. Cuando el flujo de trabajo se ejecute para un informe de error o un PR de corrección, también debe publicar las capturas de pantalla PNG censuradas en la rama qa-artifacts y actualizar o insertar un comentario en ese error o PR de corrección con capturas de pantalla antes/después insertadas. No publiques la prueba principal solo en un PR genérico de automatización de QA. Los registros sin procesar, los mensajes observados y otra evidencia voluminosa permanecen en el artefacto de Actions. Los flujos de trabajo de producción deben publicar esos comentarios con la GitHub App de Mantis, no con github-actions[bot]. Almacena el id de la aplicación y la clave privada como secretos de GitHub Actions MANTIS_GITHUB_APP_ID y MANTIS_GITHUB_APP_PRIVATE_KEY. El flujo de trabajo usa un marcador oculto como clave de actualización o inserción, actualiza ese comentario cuando el token puede editarlo, y crea un nuevo comentario propiedad de Mantis cuando no se puede editar un marcador antiguo propiedad de un bot. El comentario del PR debe ser breve y visual:

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> |

Cuando la ejecución falle porque falló el arnés, el comentario debe decir eso en lugar de insinuar que el candidato falló.

Notas de despliegue privado

Un despliegue privado puede tener ya una aplicación de Discord de Mantis. Reutiliza esa aplicación en lugar de crear otra cuando tenga los permisos de bot correctos y pueda rotarse de forma segura. Configura el canal inicial de notificaciones del operador mediante secretos o configuración de despliegue. Puede apuntar primero a un canal existente de mantenedores u operaciones, y luego moverse a un canal dedicado de Mantis cuando exista. No pongas ids de servidores, ids de canales, tokens de bot, cookies del navegador ni contraseñas de VNC en este documento. Guárdalos en secretos de GitHub, el broker de credenciales o el almacén local de secretos del operador.

Añadir un escenario

Un escenario de Mantis debe declarar:

id y título
transporte
credenciales requeridas
política de referencia de baseline
política de referencia de candidato
parche de configuración de OpenClaw
pasos de configuración
estímulo
oráculo de baseline esperado
oráculo de candidato esperado
objetivos de captura visual
presupuesto de tiempo de espera
pasos de limpieza

Los escenarios deben preferir oráculos pequeños y tipados:

estado de reacción de Discord para errores de reacciones
referencias de mensajes de Discord para errores de hilos
ts de hilo de Slack y estado de API de reacciones para errores de Slack
ids de mensajes de correo electrónico y encabezados para errores de correo electrónico
capturas de pantalla del navegador cuando la IU sea el único observable fiable

Las comprobaciones de visión deben ser aditivas. Si una API de plataforma puede probar el error, usa la API como oráculo de aprobado/fallido y conserva las capturas de pantalla para confianza humana.

Expansión de proveedores

Después de Discord, el mismo ejecutor puede añadir:

Slack: reacciones, hilos, menciones de aplicación, modales, cargas de archivos.
Correo electrónico: autenticación de Gmail e hilos de mensajes usando gog cuando los conectores no sean suficientes.
WhatsApp: inicio de sesión con QR, reidentificación, entrega de mensajes, medios, reacciones.
Telegram: control de menciones de grupo, comandos, reacciones cuando estén disponibles.
Matrix: salas cifradas, relaciones de hilo o respuesta, reanudación tras reinicio.

Cada transporte debe tener un escenario smoke barato y uno o más escenarios por clase de error. Los escenarios visuales costosos deben seguir siendo opcionales.

Preguntas abiertas

¿Qué bot de Discord debe ser el controlador y cuál debe ser el SUT cuando se reutilice el bot de Mantis existente?
¿Debe el inicio de sesión del navegador observador usar una cuenta humana de Discord, una cuenta de prueba, o solo evidencia REST legible por bot para la primera fase?
¿Durante cuánto tiempo debe GitHub conservar los artefactos de Mantis para PRs?
¿Cuándo debe ClawSweeper recomendar automáticamente Mantis en lugar de esperar a un comando de mantenedor?
¿Deben censurarse o recortarse las capturas de pantalla antes de cargarlas para PRs públicos?

Documentation Index

​Objetivos

​No objetivos

​Propiedad

​Forma de comando

​Ciclo de vida de ejecución

​MVP de Discord

​Piezas de QA existentes

​Modelo de evidencia

​Navegador y VNC

​Máquinas

​Secretos

​Artefactos de GitHub y comentarios de PR

​Notas de despliegue privado

​Añadir un escenario

​Expansión de proveedores

​Preguntas abiertas