​

Pruebas

• Qué cubre cada suite (y qué no cubre deliberadamente)
• Qué comandos ejecutar para flujos de trabajo comunes (local, antes de hacer push, depuración)
• Cómo las pruebas live detectan credenciales y seleccionan modelos/proveedores
• Cómo agregar regresiones para problemas reales de modelos/proveedores

​

Inicio rápido

• Puerta completa (esperada antes de hacer push): pnpm build && pnpm check && pnpm test
• Ejecución local más rápida de la suite completa en una máquina con buenos recursos: pnpm test:max
• Bucle directo de Vitest en modo watch: pnpm test:watch
• El direccionamiento directo a archivos ahora también enruta rutas de extensiones/canales: pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts
• Prefiere primero ejecuciones dirigidas cuando estés iterando sobre un único fallo.
• Sitio de QA con respaldo de Docker: pnpm qa:lab:up
• Carril de QA con VM de Linux: pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline

• Puerta de cobertura: pnpm test:coverage
• Suite E2E: pnpm test:e2e

• Suite live (sondeos de modelos + herramientas/imágenes de Gateway): pnpm test:live
• Ejecutar silenciosamente un único archivo live: pnpm test:live -- src/agents/models.profiles.live.test.ts

​

Ejecutores específicos de QA

• pnpm openclaw qa suite
  • Ejecuta escenarios de QA respaldados por el repositorio directamente en el host.
  • Ejecuta varios escenarios seleccionados en paralelo de forma predeterminada con workers de Gateway aislados, hasta 64 workers o la cantidad de escenarios seleccionados. Usa --concurrency <count> para ajustar la cantidad de workers, o --concurrency 1 para el carril serial anterior.
• pnpm openclaw qa suite --runner multipass
  • Ejecuta la misma suite de QA dentro de una VM Linux desechable de Multipass.
  • Mantiene el mismo comportamiento de selección de escenarios que qa suite en el host.
  • Reutiliza las mismas banderas de selección de proveedor/modelo que qa suite.
  • Las ejecuciones live reenvían las entradas de autenticación de QA admitidas que son prácticas para el invitado: claves de proveedor basadas en entorno, la ruta de configuración del proveedor live de QA y CODEX_HOME cuando está presente.
  • Los directorios de salida deben permanecer bajo la raíz del repositorio para que el invitado pueda escribir de vuelta a través del espacio de trabajo montado.
  • Escribe el informe + resumen normales de QA, además de los registros de Multipass, en .artifacts/qa-e2e/....
• pnpm qa:lab:up
  • Inicia el sitio de QA con respaldo de Docker para trabajo de QA estilo operador.
• pnpm openclaw qa matrix
  • Ejecuta el carril de QA live de Matrix contra un homeserver Tuwunel desechable con respaldo de Docker.
  • Aprovisiona tres usuarios temporales de Matrix (driver, sut, observer) además de una sala privada, y luego inicia un proceso hijo de Gateway de QA con el plugin real de Matrix como transporte SUT.
  • Usa la imagen estable fijada de Tuwunel ghcr.io/matrix-construct/tuwunel:v1.5.1 de forma predeterminada. Sustitúyela con OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE cuando necesites probar una imagen distinta.
  • Matrix actualmente solo admite --credential-source env porque el carril aprovisiona usuarios desechables localmente.
  • Escribe un informe de QA de Matrix, un resumen y un artefacto de eventos observados en .artifacts/qa-e2e/....
• pnpm openclaw qa telegram
  • Ejecuta el carril de QA live de Telegram contra un grupo privado real usando los tokens del bot driver y del bot SUT desde el entorno.
  • Requiere OPENCLAW_QA_TELEGRAM_GROUP_ID, OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN y OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN. El id del grupo debe ser el id numérico del chat de Telegram.
  • Admite --credential-source convex para credenciales compartidas agrupadas. Usa el modo env de forma predeterminada, o configura OPENCLAW_QA_CREDENTIAL_SOURCE=convex para optar por leases agrupados.
  • Requiere dos bots distintos en el mismo grupo privado, con el bot SUT exponiendo un nombre de usuario de Telegram.
  • Para una observación estable entre bots, habilita el modo de comunicación bot a bot en @BotFather para ambos bots y asegúrate de que el bot driver pueda observar el tráfico de bots en el grupo.
  • Escribe un informe de QA de Telegram, un resumen y un artefacto de mensajes observados en .artifacts/qa-e2e/....

​

Credenciales compartidas de Telegram mediante Convex (v1)

• qa/convex-credential-broker/

• OPENCLAW_QA_CONVEX_SITE_URL (por ejemplo https://your-deployment.convex.site)
• Un secreto para el rol seleccionado:
  • OPENCLAW_QA_CONVEX_SECRET_MAINTAINER para maintainer
  • OPENCLAW_QA_CONVEX_SECRET_CI para ci
• Selección del rol de credencial:
  • CLI: --credential-role maintainer|ci
  • Valor predeterminado por entorno: OPENCLAW_QA_CREDENTIAL_ROLE (predeterminado: maintainer)

• OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS (predeterminado 1200000)
• OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS (predeterminado 30000)
• OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS (predeterminado 90000)
• OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS (predeterminado 15000)
• OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX (predeterminado /qa-credentials/v1)
• OPENCLAW_QA_CREDENTIAL_OWNER_ID (id de rastreo opcional)
• OPENCLAW_QA_ALLOW_INSECURE_HTTP=1 permite URLs de Convex http:// de loopback local solo para desarrollo local.

pnpm openclaw qa credentials add --kind telegram --payload-file qa/telegram-credential.json
pnpm openclaw qa credentials list --kind telegram
pnpm openclaw qa credentials remove --credential-id <credential-id>

• POST /acquire
  • Solicitud: { kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }
  • Éxito: { status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }
  • Agotado/reintentable: { status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }
• POST /heartbeat
  • Solicitud: { kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }
  • Éxito: { status: "ok" } (o 2xx vacío)
• POST /release
  • Solicitud: { kind, ownerId, actorRole, credentialId, leaseToken }
  • Éxito: { status: "ok" } (o 2xx vacío)
• POST /admin/add (solo secreto de maintainer)
  • Solicitud: { kind, actorId, payload, note?, status? }
  • Éxito: { status: "ok", credential }
• POST /admin/remove (solo secreto de maintainer)
  • Solicitud: { credentialId, actorId }
  • Éxito: { status: "ok", changed, credential }
  • Protección de lease activo: { status: "error", code: "LEASE_ACTIVE", ... }
• POST /admin/list (solo secreto de maintainer)
  • Solicitud: { kind?, status?, includePayload?, limit? }
  • Éxito: { status: "ok", credentials, count }

• { groupId: string, driverToken: string, sutToken: string }
• groupId debe ser una cadena con el id numérico del chat de Telegram.
• admin/add valida esta forma para kind: "telegram" y rechaza cargas útiles malformadas.

​

Agregar un canal a QA

1. Un adaptador de transporte para el canal.
2. Un paquete de escenarios que ejercite el contrato del canal.

• inicio y desmontaje de la suite
• concurrencia de workers
• escritura de artefactos
• generación de informes
• ejecución de escenarios
• alias de compatibilidad para escenarios antiguos de qa-channel

• cómo se configura Gateway para ese transporte
• cómo se verifica la preparación
• cómo se inyectan eventos entrantes
• cómo se observan los mensajes salientes
• cómo se exponen las transcripciones y el estado de transporte normalizado
• cómo se ejecutan las acciones respaldadas por el transporte
• cómo se gestiona el restablecimiento o la limpieza específicos del transporte

1. Implementar el adaptador de transporte en la interfaz compartida de qa-lab.
2. Registrar el adaptador en el registro de transportes.
3. Mantener la mecánica específica del transporte dentro del adaptador o del arnés del canal.
4. Crear o adaptar escenarios markdown bajo qa/scenarios/.
5. Usar los ayudantes genéricos de escenarios para los escenarios nuevos.
6. Mantener funcionando los alias de compatibilidad existentes, salvo que el repositorio esté realizando una migración intencional.

• Si el comportamiento puede expresarse una vez en qa-lab, colócalo en qa-lab.
• Si el comportamiento depende de un solo transporte de canal, mantenlo en ese adaptador o arnés del plugin.
• Si un escenario necesita una nueva capacidad que más de un canal puede usar, agrega un ayudante genérico en lugar de una rama específica de canal en suite.ts.
• Si un comportamiento solo tiene sentido para un transporte, mantén el escenario específico del transporte y hazlo explícito en el contrato del escenario.

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

• waitForQaChannelReady
• waitForOutboundMessage
• waitForNoOutbound
• formatConversationTranscript
• resetBus

​

Suites de prueba (qué se ejecuta y dónde)

​

Unitarias / integración (predeterminada)

• Comando: pnpm test
• Configuración: diez ejecuciones secuenciales de shards (vitest.full-*.config.ts) sobre los proyectos de Vitest con alcance existente
• Archivos: inventarios core/unit en src/**/*.test.ts, packages/**/*.test.ts, test/**/*.test.ts y las pruebas node permitidas de ui cubiertas por vitest.unit.config.ts
• Alcance:
  • Pruebas unitarias puras
  • Pruebas de integración en proceso (autenticación de Gateway, routing, herramientas, parsing, config)
  • Regresiones deterministas para errores conocidos
• Expectativas:
  • Se ejecuta en CI
  • No requiere claves reales
  • Debe ser rápida y estable
• Nota sobre proyectos:
  • pnpm test sin objetivo ahora ejecuta once configuraciones de shards más pequeñas (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) en lugar de un único proceso gigante del proyecto raíz nativo. Esto reduce el RSS máximo en máquinas cargadas y evita que el trabajo de auto-reply/extensiones deje sin recursos a suites no relacionadas.
  • pnpm test --watch sigue usando el grafo de proyectos nativo del root vitest.config.ts, porque un bucle watch con múltiples shards no es práctico.
  • pnpm test, pnpm test:watch y pnpm test:perf:imports enrutan primero los objetivos explícitos de archivo/directorio a través de carriles acotados, de modo que pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts evita pagar el costo de arranque completo del proyecto raíz.
  • pnpm test:changed expande las rutas git modificadas hacia esos mismos carriles acotados cuando el diff solo toca archivos de código fuente/pruebas enrutables; las ediciones de config/setup siguen recurriendo a la reejecución amplia del proyecto raíz.
  • Las pruebas unitarias ligeras en importaciones de agents, commands, plugins, ayudantes de auto-reply, plugin-sdk y áreas similares de utilidades puras se enrutan por el carril unit-fast, que omite test/setup-openclaw-runtime.ts; los archivos con mucho estado o con runtime pesado permanecen en los carriles existentes.
  • Determinados archivos fuente auxiliares de plugin-sdk y commands también asignan las ejecuciones en modo changed a pruebas hermanas explícitas en esos carriles ligeros, de modo que las ediciones de ayudantes evitan reejecutar la suite pesada completa para ese directorio.
  • auto-reply ahora tiene tres buckets dedicados: ayudantes core de nivel superior, pruebas de integración reply.* de nivel superior y el subárbol src/auto-reply/reply/**. Esto mantiene el trabajo más pesado del arnés de reply fuera de las pruebas baratas de estado/chunk/token.
• Nota sobre el ejecutor embebido:
  • Cuando cambies las entradas de descubrimiento de herramientas de mensajes o el contexto de runtime de Compaction, mantén ambos niveles de cobertura.
  • Agrega regresiones enfocadas de ayudantes para límites puros de routing/normalización.
  • Mantén también sanas las suites de integración del ejecutor embebido: src/agents/pi-embedded-runner/compact.hooks.test.ts, src/agents/pi-embedded-runner/run.overflow-compaction.test.ts y src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts.
  • Esas suites verifican que los ids con alcance y el comportamiento de Compaction sigan fluyendo por las rutas reales run.ts / compact.ts; las pruebas solo de ayudantes no son un sustituto suficiente para esas rutas de integración.
• Nota sobre pool:
  • La configuración base de Vitest ahora usa threads de forma predeterminada.
  • La configuración compartida de Vitest también fija isolate: false y usa el ejecutor no aislado en los proyectos root, e2e y live.
  • El carril root de UI mantiene su configuración y optimizador de jsdom, pero ahora también se ejecuta en el ejecutor compartido no aislado.
  • Cada shard de pnpm test hereda los mismos valores predeterminados threads + isolate: false de la configuración compartida de Vitest.
  • El lanzador compartido scripts/run-vitest.mjs ahora también agrega --no-maglev de forma predeterminada para los procesos Node hijos de Vitest a fin de reducir el churn de compilación de V8 durante ejecuciones locales grandes. Configura OPENCLAW_VITEST_ENABLE_MAGLEV=1 si necesitas comparar con el comportamiento estándar de V8.
• Nota sobre iteración local rápida:
  • pnpm test:changed se enruta por carriles acotados cuando las rutas modificadas se asignan limpiamente a una suite más pequeña.
  • pnpm test:max y pnpm test:changed:max mantienen el mismo comportamiento de enrutamiento, solo con un límite de workers más alto.
  • El autoescalado de workers locales ahora es intencionalmente conservador y también reduce la carga cuando el promedio de carga del host ya es alto, de modo que varias ejecuciones concurrentes de Vitest causan menos daño de forma predeterminada.
  • La configuración base de Vitest marca los archivos de proyectos/configuración como forceRerunTriggers para que las reejecuciones en modo changed sigan siendo correctas cuando cambie el cableado de pruebas.
  • La configuración mantiene OPENCLAW_VITEST_FS_MODULE_CACHE habilitado en hosts compatibles; configura OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path si quieres una ubicación de caché explícita para perfilado directo.
• Nota de depuración de rendimiento:
  • pnpm test:perf:imports habilita la generación de informes de duración de importaciones de Vitest, además de la salida del desglose de importaciones.
  • pnpm test:perf:imports:changed limita esa misma vista de perfilado a archivos modificados desde origin/main.
• pnpm test:perf:changed:bench -- --ref <git-ref> compara test:changed enrutado con la ruta nativa del proyecto raíz para ese diff confirmado e imprime el tiempo total más el RSS máximo en macOS.
• pnpm test:perf:changed:bench -- --worktree evalúa el árbol de trabajo actual con cambios al enrutar la lista de archivos modificados a través de scripts/test-projects.mjs y la configuración root de Vitest.
  • pnpm test:perf:profile:main escribe un perfil de CPU del hilo principal para la sobrecarga de inicio y transformación de Vitest/Vite.
  • pnpm test:perf:profile:runner escribe perfiles de CPU+heap del ejecutor para la suite unitaria con el paralelismo por archivo deshabilitado.

​

E2E (prueba de humo de Gateway)

• Comando: pnpm test:e2e
• Configuración: vitest.e2e.config.ts
• Archivos: src/**/*.e2e.test.ts, test/**/*.e2e.test.ts
• Valores predeterminados del runtime:
  • Usa threads de Vitest con isolate: false, en línea con el resto del repositorio.
  • Usa workers adaptativos (CI: hasta 2, local: 1 de forma predeterminada).
  • Se ejecuta en modo silencioso de forma predeterminada para reducir la sobrecarga de E/S de consola.
• Overrides útiles:
  • OPENCLAW_E2E_WORKERS=<n> para forzar la cantidad de workers (límite de 16).
  • OPENCLAW_E2E_VERBOSE=1 para volver a habilitar la salida detallada de consola.
• Alcance:
  • Comportamiento end-to-end de Gateway con múltiples instancias
  • Superficies WebSocket/HTTP, emparejamiento de nodos y redes más pesadas
• Expectativas:
  • Se ejecuta en CI (cuando está habilitado en la pipeline)
  • No requiere claves reales
  • Tiene más piezas móviles que las pruebas unitarias (puede ser más lento)

​

E2E: prueba de humo del backend OpenShell

• Comando: pnpm test:e2e:openshell
• Archivo: test/openshell-sandbox.e2e.test.ts
• Alcance:
  • Inicia un Gateway aislado de OpenShell en el host mediante Docker
  • Crea un sandbox a partir de un Dockerfile local temporal
  • Ejercita el backend OpenShell de OpenClaw mediante sandbox ssh-config + ejecución SSH reales
  • Verifica el comportamiento canónico remoto del sistema de archivos a través del puente fs del sandbox
• Expectativas:
  • Solo opt-in; no forma parte de la ejecución predeterminada de pnpm test:e2e
  • Requiere un CLI local de openshell además de un daemon Docker funcional
  • Usa HOME / XDG_CONFIG_HOME aislados y luego destruye el Gateway y el sandbox de prueba
• Overrides útiles:
  • OPENCLAW_E2E_OPENSHELL=1 para habilitar la prueba al ejecutar manualmente la suite e2e más amplia
  • OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell para apuntar a un binario CLI o script envoltorio no predeterminado

​

Live (proveedores reales + modelos reales)

• Comando: pnpm test:live
• Configuración: vitest.live.config.ts
• Archivos: src/**/*.live.test.ts
• Predeterminado: habilitado por pnpm test:live (establece OPENCLAW_LIVE_TEST=1)
• Alcance:
  • “¿Este proveedor/modelo realmente funciona hoy con credenciales reales?”
  • Detecta cambios de formato del proveedor, peculiaridades de llamada a herramientas, problemas de autenticación y comportamiento de límites de tasa
• Expectativas:
  • No es estable para CI por diseño (redes reales, políticas reales de proveedores, cuotas, interrupciones)
  • Cuesta dinero / consume límites de tasa
  • Prefiere ejecutar subconjuntos acotados en lugar de “todo”
• Las ejecuciones live cargan ~/.profile para recoger claves de API faltantes.
• De forma predeterminada, las ejecuciones live siguen aislando HOME y copian el material de config/auth a un home de prueba temporal para que los fixtures unitarios no puedan mutar tu ~/.openclaw real.
• Configura OPENCLAW_LIVE_USE_REAL_HOME=1 solo cuando necesites intencionalmente que las pruebas live usen tu directorio home real.
• pnpm test:live ahora usa por defecto un modo más silencioso: mantiene la salida de progreso [live] ..., pero suprime el aviso adicional de ~/.profile y silencia los logs de arranque de Gateway/el ruido de Bonjour. Configura OPENCLAW_LIVE_TEST_QUIET=0 si quieres recuperar los logs completos de inicio.
• Rotación de claves API (específica del proveedor): configura *_API_KEYS con formato de comas/punto y coma o *_API_KEY_1, *_API_KEY_2 (por ejemplo OPENAI_API_KEYS, ANTHROPIC_API_KEYS, GEMINI_API_KEYS) o el override por live OPENCLAW_LIVE_*_KEY; las pruebas reintentan ante respuestas de límite de tasa.
• Salida de progreso/Heartbeat:
  • Las suites live ahora emiten líneas de progreso a stderr para que las llamadas largas al proveedor se vean activas incluso cuando la captura de consola de Vitest está en modo silencioso.
  • vitest.live.config.ts deshabilita la interceptación de consola de Vitest para que las líneas de progreso de proveedor/Gateway se transmitan inmediatamente durante las ejecuciones live.
  • Ajusta los Heartbeat de modelo directo con OPENCLAW_LIVE_HEARTBEAT_MS.
  • Ajusta los Heartbeat de Gateway/sondeo con OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS.

​

¿Qué suite debería ejecutar?

• Editando lógica/pruebas: ejecuta pnpm test (y pnpm test:coverage si cambiaste mucho)
• Tocando redes de Gateway / protocolo WS / emparejamiento: agrega pnpm test:e2e
• Depurando “mi bot no funciona” / fallos específicos del proveedor / llamada a herramientas: ejecuta un pnpm test:live acotado

​

Live: barrido de capacidades del Node Android

• Prueba: src/gateway/android-node.capabilities.live.test.ts
• Script: pnpm android:test:integration
• Objetivo: invocar todos los comandos anunciados actualmente por un Node Android conectado y afirmar el comportamiento del contrato de comandos.
• Alcance:
  • Configuración previa/manual (la suite no instala/ejecuta/empareja la app).
  • Validación comando por comando de Gateway node.invoke para el Node Android seleccionado.
• Configuración previa requerida:
  • App Android ya conectada y emparejada con Gateway.
  • App mantenida en primer plano.
  • Permisos/consentimiento de captura otorgados para las capacidades que esperas que pasen.
• Overrides de destino opcionales:
  • OPENCLAW_ANDROID_NODE_ID o OPENCLAW_ANDROID_NODE_NAME.
  • OPENCLAW_ANDROID_GATEWAY_URL / OPENCLAW_ANDROID_GATEWAY_TOKEN / OPENCLAW_ANDROID_GATEWAY_PASSWORD.
• Detalles completos de configuración de Android: App Android

​

Live: prueba de humo de modelo (claves de perfil)

• “Modelo directo” nos indica si el proveedor/modelo puede responder en absoluto con la clave dada.
• “Prueba de humo de Gateway” nos indica si funciona el pipeline completo Gateway+agente para ese modelo (sesiones, historial, herramientas, política de sandbox, etc.).

​

Capa 1: finalización directa del modelo (sin Gateway)

• Prueba: src/agents/models.profiles.live.test.ts
• Objetivo:
  • Enumerar los modelos detectados
  • Usar getApiKeyForModel para seleccionar los modelos para los que tienes credenciales
  • Ejecutar una pequeña finalización por modelo (y regresiones dirigidas cuando sea necesario)
• Cómo habilitar:
  • pnpm test:live (o OPENCLAW_LIVE_TEST=1 si invocas Vitest directamente)
• Configura OPENCLAW_LIVE_MODELS=modern (o all, alias de modern) para ejecutar realmente esta suite; de lo contrario se omite para mantener pnpm test:live enfocado en la prueba de humo de Gateway
• Cómo seleccionar modelos:
  • OPENCLAW_LIVE_MODELS=modern para ejecutar la lista permitida moderna (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
  • OPENCLAW_LIVE_MODELS=all es un alias de la lista permitida moderna
  • o OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..." (lista permitida separada por comas)
  • Los barridos modern/all usan por defecto un límite seleccionado de alta señal; configura OPENCLAW_LIVE_MAX_MODELS=0 para un barrido moderno exhaustivo o un número positivo para un límite más pequeño.
• Cómo seleccionar proveedores:
  • OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli" (lista permitida separada por comas)
• De dónde vienen las claves:
  • De forma predeterminada: almacén de perfiles y fallbacks del entorno
  • Configura OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 para exigir solo el almacén de perfiles
• Por qué existe esto:
  • Separa “la API del proveedor está rota / la clave no es válida” de “el pipeline del agente de Gateway está roto”
  • Contiene regresiones pequeñas y aisladas (ejemplo: flujos de razonamiento replay + tool-call de OpenAI Responses/Codex Responses)

​

Capa 2: prueba de humo de Gateway + agente dev (lo que realmente hace “@openclaw”)

• Prueba: src/gateway/gateway-models.profiles.live.test.ts
• Objetivo:
  • Iniciar un Gateway en proceso
  • Crear/parchear una sesión agent:dev:* (override de modelo por ejecución)
  • Iterar modelos-con-claves y afirmar:
    • respuesta “significativa” (sin herramientas)
    • que funcione una invocación real de herramienta (sondeo de lectura)
    • sondeos opcionales de herramientas adicionales (sondeo de exec+read)
    • que sigan funcionando las rutas de regresión de OpenAI (solo tool-call → seguimiento)
• Detalles de los sondeos (para que puedas explicar fallos rápidamente):
  • Sondeo read: la prueba escribe un archivo nonce en el espacio de trabajo y le pide al agente que lo read y devuelva el nonce.
  • Sondeo exec+read: la prueba le pide al agente que escriba mediante exec un nonce en un archivo temporal y luego que lo lea con read.
  • Sondeo de imagen: la prueba adjunta un PNG generado (gato + código aleatorio) y espera que el modelo devuelva cat <CODE>.
  • Referencia de implementación: src/gateway/gateway-models.profiles.live.test.ts y src/gateway/live-image-probe.ts.
• Cómo habilitar:
  • pnpm test:live (o OPENCLAW_LIVE_TEST=1 si invocas Vitest directamente)
• Cómo seleccionar modelos:
  • Predeterminado: lista permitida moderna (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
  • OPENCLAW_LIVE_GATEWAY_MODELS=all es un alias para la lista permitida moderna
  • O configura OPENCLAW_LIVE_GATEWAY_MODELS="provider/model" (o una lista separada por comas) para acotar
  • Los barridos modern/all de Gateway usan por defecto un límite seleccionado de alta señal; configura OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0 para un barrido moderno exhaustivo o un número positivo para un límite más pequeño.
• Cómo seleccionar proveedores (evita “todo OpenRouter”):
  • OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax" (lista permitida separada por comas)
• Los sondeos de herramientas + imagen siempre están activados en esta prueba live:
  • sondeo read + sondeo exec+read (estrés de herramientas)
  • el sondeo de imagen se ejecuta cuando el modelo anuncia compatibilidad con entrada de imagen
  • Flujo (alto nivel):
    • La prueba genera un pequeño PNG con “CAT” + código aleatorio (src/gateway/live-image-probe.ts)
    • Lo envía mediante agent attachments: [{ mimeType: "image/png", content: "<base64>" }]
    • Gateway analiza los adjuntos en images[] (src/gateway/server-methods/agent.ts + src/gateway/chat-attachments.ts)
    • El agente embebido reenvía un mensaje de usuario multimodal al modelo
    • Afirmación: la respuesta contiene cat + el código (tolerancia OCR: se permiten errores menores)

openclaw models list
openclaw models list --json

​

Live: prueba de humo del backend CLI (Claude, Codex, Gemini u otros CLI locales)

• Prueba: src/gateway/gateway-cli-backend.live.test.ts
• Objetivo: validar el pipeline de Gateway + agente usando un backend CLI local, sin tocar tu configuración predeterminada.
• Los valores predeterminados de la prueba de humo específicos del backend están en la definición cli-backend.ts de la extensión propietaria.
• Habilitar:
  • pnpm test:live (o OPENCLAW_LIVE_TEST=1 si invocas Vitest directamente)
  • OPENCLAW_LIVE_CLI_BACKEND=1
• Predeterminados:
  • Proveedor/modelo predeterminado: claude-cli/claude-sonnet-4-6
  • El comportamiento de comando/args/imagen proviene de los metadatos del plugin propietario del backend CLI.
• Overrides opcionales:
  • OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"
  • OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"
  • OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'
  • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1 para enviar un adjunto de imagen real (las rutas se inyectan en el prompt).
  • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image" para pasar rutas de archivo de imagen como argumentos CLI en lugar de inyección en el prompt.
  • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat" (o "list") para controlar cómo se pasan los argumentos de imagen cuando IMAGE_ARG está configurado.
  • OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1 para enviar un segundo turno y validar el flujo de reanudación.
  • OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0 para deshabilitar el sondeo predeterminado de continuidad en la misma sesión Claude Sonnet -> Opus (configúralo en 1 para forzarlo cuando el modelo seleccionado admita un destino de cambio).

OPENCLAW_LIVE_CLI_BACKEND=1 \
  OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4" \
  pnpm test:live src/gateway/gateway-cli-backend.live.test.ts

pnpm test:docker:live-cli-backend

pnpm test:docker:live-cli-backend:claude
pnpm test:docker:live-cli-backend:claude-subscription
pnpm test:docker:live-cli-backend:codex
pnpm test:docker:live-cli-backend:gemini

• El ejecutor Docker está en scripts/test-live-cli-backend-docker.sh.
• Ejecuta la prueba de humo live del backend CLI dentro de la imagen Docker del repositorio como el usuario no root node.
• Resuelve los metadatos de la prueba de humo CLI desde la extensión propietaria y luego instala el paquete CLI Linux correspondiente (@anthropic-ai/claude-code, @openai/codex o @google/gemini-cli) en un prefijo grabable en caché en OPENCLAW_DOCKER_CLI_TOOLS_DIR (predeterminado: ~/.cache/openclaw/docker-cli-tools).
• pnpm test:docker:live-cli-backend:claude-subscription requiere OAuth portátil de suscripción de Claude Code mediante ~/.claude/.credentials.json con claudeAiOauth.subscriptionType o CLAUDE_CODE_OAUTH_TOKEN desde claude setup-token. Primero demuestra claude -p directo en Docker y luego ejecuta dos turnos de backend CLI de Gateway sin preservar las variables de entorno de clave API de Anthropic. Este carril de suscripción deshabilita por defecto los sondeos de MCP/herramientas e imagen de Claude porque Claude actualmente enruta el uso de apps de terceros mediante facturación por uso adicional en lugar de los límites normales del plan de suscripción.
• La prueba de humo live del backend CLI ahora ejercita el mismo flujo end-to-end para Claude, Codex y Gemini: turno de texto, turno de clasificación de imagen y luego llamada a la herramienta MCP cron verificada a través del CLI de Gateway.
• La prueba de humo predeterminada de Claude también parchea la sesión de Sonnet a Opus y verifica que la sesión reanudada aún recuerde una nota anterior.

​

Live: prueba de humo de vinculación ACP (/acp spawn ... --bind here)

• Prueba: src/gateway/gateway-acp-bind.live.test.ts
• Objetivo: validar el flujo real de vinculación de conversación ACP con un agente ACP live:
  • enviar /acp spawn <agent> --bind here
  • vincular en su lugar una conversación sintética de canal de mensajes
  • enviar un seguimiento normal en esa misma conversación
  • verificar que el seguimiento llegue a la transcripción de la sesión ACP vinculada
• Habilitar:
  • pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
  • OPENCLAW_LIVE_ACP_BIND=1
• Predeterminados:
  • Agentes ACP en Docker: claude,codex,gemini
  • Agente ACP para pnpm test:live ... directo: claude
  • Canal sintético: contexto de conversación estilo DM de Slack
  • Backend ACP: acpx
• Overrides:
  • OPENCLAW_LIVE_ACP_BIND_AGENT=claude
  • OPENCLAW_LIVE_ACP_BIND_AGENT=codex
  • OPENCLAW_LIVE_ACP_BIND_AGENT=gemini
  • OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini
  • OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@<version>'
• Notas:
  • Este carril usa la superficie chat.send de Gateway con campos sintéticos de originating-route solo para admin, de modo que las pruebas puedan adjuntar contexto de canal de mensajes sin fingir entrega externa.
  • Cuando OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND no está configurado, la prueba usa el registro de agentes integrado del plugin acpx embebido para el agente del arnés ACP seleccionado.

OPENCLAW_LIVE_ACP_BIND=1 \
  OPENCLAW_LIVE_ACP_BIND_AGENT=claude \
  pnpm test:live src/gateway/gateway-acp-bind.live.test.ts

pnpm test:docker:live-acp-bind

pnpm test:docker:live-acp-bind:claude
pnpm test:docker:live-acp-bind:codex
pnpm test:docker:live-acp-bind:gemini

• El ejecutor Docker está en scripts/test-live-acp-bind-docker.sh.
• De forma predeterminada, ejecuta la prueba de humo de vinculación ACP contra todos los agentes CLI live compatibles en secuencia: claude, codex y luego gemini.
• Usa OPENCLAW_LIVE_ACP_BIND_AGENTS=claude, OPENCLAW_LIVE_ACP_BIND_AGENTS=codex o OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini para acotar la matriz.
• Carga ~/.profile, prepara el material de autenticación CLI correspondiente en el contenedor, instala acpx en un prefijo npm grabable y luego instala el CLI live solicitado (@anthropic-ai/claude-code, @openai/codex o @google/gemini-cli) si falta.
• Dentro de Docker, el ejecutor configura OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx para que acpx mantenga disponibles para el CLI hijo del arnés las variables de entorno del proveedor procedentes del profile cargado.

​

Live: prueba de humo del arnés app-server de Codex

• Objetivo: validar el arnés de Codex propiedad del plugin mediante el método normal agent de Gateway:
  • cargar el plugin empaquetado codex
  • seleccionar OPENCLAW_AGENT_RUNTIME=codex
  • enviar un primer turno de agente de Gateway a codex/gpt-5.4
  • enviar un segundo turno a la misma sesión de OpenClaw y verificar que el hilo de app-server pueda reanudarse
  • ejecutar /codex status y /codex models a través de la misma ruta de comando de Gateway
• Prueba: src/gateway/gateway-codex-harness.live.test.ts
• Habilitar: OPENCLAW_LIVE_CODEX_HARNESS=1
• Modelo predeterminado: codex/gpt-5.4
• Sondeo opcional de imagen: OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1
• Sondeo opcional MCP/herramienta: OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1
• La prueba de humo configura OPENCLAW_AGENT_HARNESS_FALLBACK=none para que un arnés de Codex roto no pueda pasar recurriendo silenciosamente a un fallback a PI.
• Auth: OPENAI_API_KEY desde el shell/profile, más copia opcional de ~/.codex/auth.json y ~/.codex/config.toml

source ~/.profile
OPENCLAW_LIVE_CODEX_HARNESS=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_MODEL=codex/gpt-5.4 \
  pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts

source ~/.profile
pnpm test:docker:live-codex-harness

• El ejecutor Docker está en scripts/test-live-codex-harness-docker.sh.
• Carga el ~/.profile montado, pasa OPENAI_API_KEY, copia archivos de auth del CLI de Codex cuando están presentes, instala @openai/codex en un prefijo npm grabable montado, prepara el árbol fuente y luego ejecuta solo la prueba live del arnés de Codex.
• Docker habilita por defecto los sondeos de imagen y MCP/herramienta. Configura OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 o OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 cuando necesites una ejecución de depuración más acotada.
• Docker también exporta OPENCLAW_AGENT_HARNESS_FALLBACK=none, en línea con la configuración de la prueba live para que el fallback a openai-codex/* o a PI no pueda ocultar una regresión del arnés de Codex.

​

Recetas live recomendadas

• Modelo único, directo (sin Gateway):
  • OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts
• Modelo único, prueba de humo de Gateway:
  • OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
• Llamada a herramientas en varios proveedores:
  • OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
• Enfoque en Google (clave API de Gemini + Antigravity):
  • Gemini (clave API): OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
  • Antigravity (OAuth): OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts

• google/... usa la API de Gemini (clave API).
• google-antigravity/... usa el puente OAuth de Antigravity (endpoint de agente estilo Cloud Code Assist).
• google-gemini-cli/... usa el CLI local de Gemini en tu máquina (autenticación separada + peculiaridades de herramientas).
• API de Gemini vs CLI de Gemini:
  • API: OpenClaw llama a la API alojada de Gemini de Google por HTTP (clave API / auth de perfil); esto es lo que la mayoría de los usuarios quiere decir con “Gemini”.
  • CLI: OpenClaw ejecuta un binario gemini local; tiene su propia autenticación y puede comportarse de forma diferente (streaming/compatibilidad con herramientas/desfase de versión).

​

Live: matriz de modelos (qué cubrimos)

​

Conjunto moderno de pruebas de humo (llamada a herramientas + imagen)

• OpenAI (no Codex): openai/gpt-5.4 (opcional: openai/gpt-5.4-mini)
• OpenAI Codex: openai-codex/gpt-5.4
• Anthropic: anthropic/claude-opus-4-6 (o anthropic/claude-sonnet-4-6)
• Google (API de Gemini): google/gemini-3.1-pro-preview y google/gemini-3-flash-preview (evita los modelos Gemini 2.x más antiguos)
• Google (Antigravity): google-antigravity/claude-opus-4-6-thinking y google-antigravity/gemini-3-flash
• Z.AI (GLM): zai/glm-4.7
• MiniMax: minimax/MiniMax-M2.7

​

Base: llamada a herramientas (Read + Exec opcional)

• OpenAI: openai/gpt-5.4 (o openai/gpt-5.4-mini)
• Anthropic: anthropic/claude-opus-4-6 (o anthropic/claude-sonnet-4-6)
• Google: google/gemini-3-flash-preview (o google/gemini-3.1-pro-preview)
• Z.AI (GLM): zai/glm-4.7
• MiniMax: minimax/MiniMax-M2.7

• xAI: xai/grok-4 (o la última disponible)
• Mistral: mistral/… (elige un modelo con capacidad de herramientas que tengas habilitado)
• Cerebras: cerebras/… (si tienes acceso)
• LM Studio: lmstudio/… (local; la llamada a herramientas depende del modo de API)

​

Visión: envío de imagen (adjunto → mensaje multimodal)

​

Agregadores / gateways alternativos

• OpenRouter: openrouter/... (cientos de modelos; usa openclaw models scan para encontrar candidatos con capacidad de herramientas+imagen)
• OpenCode: opencode/... para Zen y opencode-go/... para Go (auth mediante OPENCODE_API_KEY / OPENCODE_ZEN_API_KEY)

• Integrados: openai, openai-codex, anthropic, google, google-vertex, google-antigravity, google-gemini-cli, zai, openrouter, opencode, opencode-go, xai, groq, cerebras, mistral, github-copilot
• Mediante models.providers (endpoints personalizados): minimax (cloud/API), además de cualquier proxy compatible con OpenAI/Anthropic (LM Studio, vLLM, LiteLLM, etc.)

​

Credenciales (nunca las confirmes)

• Si la CLI funciona, las pruebas live deberían encontrar las mismas claves.
• Si una prueba live dice “no creds”, depura del mismo modo en que depurarías openclaw models list / selección de modelo.
• Perfiles de auth por agente: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json (esto es lo que significa “profile keys” en las pruebas live)
• Configuración: ~/.openclaw/openclaw.json (o OPENCLAW_CONFIG_PATH)
• Directorio de estado heredado: ~/.openclaw/credentials/ (se copia al home live preparado cuando está presente, pero no es el almacén principal de claves de perfil)
• Las ejecuciones live locales copian por defecto la configuración activa, los archivos auth-profiles.json por agente, credentials/ heredado y los directorios de auth CLI externos compatibles a un home de prueba temporal; los homes live preparados omiten workspace/ y sandboxes/, y se eliminan los overrides de rutas agents.*.workspace / agentDir para que los sondeos no toquen tu espacio de trabajo real del host.

​

Live de Deepgram (transcripción de audio)

• Prueba: src/media-understanding/providers/deepgram/audio.live.test.ts
• Habilitar: DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts

​

Live de plan de codificación de BytePlus

• Prueba: src/agents/byteplus.live.test.ts
• Habilitar: BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts
• Override opcional de modelo: BYTEPLUS_CODING_MODEL=ark-code-latest

​

Live de medios de flujo de trabajo de ComfyUI

• Prueba: extensions/comfy/comfy.live.test.ts
• Habilitar: OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts
• Alcance:
  • Ejercita las rutas empaquetadas de imagen, video y music_generate de comfy
  • Omite cada capacidad a menos que models.providers.comfy.<capability> esté configurado
  • Útil después de cambiar el envío de flujos de trabajo de comfy, el polling, las descargas o el registro del plugin

​

Live de generación de imágenes

• Prueba: src/image-generation/runtime.live.test.ts
• Comando: pnpm test:live src/image-generation/runtime.live.test.ts
• Arnés: pnpm test:live:media image
• Alcance:
  • Enumera todos los plugins de proveedor de generación de imágenes registrados
  • Carga las variables de entorno de proveedor que faltan desde tu shell de inicio de sesión (~/.profile) antes de realizar sondeos
  • Usa por defecto claves API live/de entorno antes que los perfiles de auth almacenados, para que claves de prueba obsoletas en auth-profiles.json no oculten credenciales reales del shell
  • Omite proveedores sin auth/perfil/modelo utilizable
  • Ejecuta las variantes estándar de generación de imágenes mediante la capacidad compartida de runtime:
    • google:flash-generate
    • google:pro-generate
    • google:pro-edit
    • openai:default-generate
• Proveedores empaquetados actualmente cubiertos:
  • openai
  • google
• Acotación opcional:
  • OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google"
  • OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-1,google/gemini-3.1-flash-image-preview"
  • OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit"
• Comportamiento de auth opcional:
  • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 para forzar auth desde el almacén de perfiles e ignorar overrides solo de entorno

​

Live de generación de música

• Prueba: extensions/music-generation-providers.live.test.ts
• Habilitar: OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts
• Arnés: pnpm test:live:media music
• Alcance:
  • Ejercita la ruta compartida de proveedor de generación de música empaquetado
  • Actualmente cubre Google y MiniMax
  • Carga variables de entorno del proveedor desde tu shell de inicio de sesión (~/.profile) antes de realizar sondeos
  • Usa por defecto claves API live/de entorno antes que los perfiles de auth almacenados, para que claves de prueba obsoletas en auth-profiles.json no oculten credenciales reales del shell
  • Omite proveedores sin auth/perfil/modelo utilizable
  • Ejecuta ambos modos de runtime declarados cuando están disponibles:
    • generate con entrada solo de prompt
    • edit cuando el proveedor declara capabilities.edit.enabled
  • Cobertura actual del carril compartido:
    • google: generate, edit
    • minimax: generate
    • comfy: archivo live separado de Comfy, no este barrido compartido
• Acotación opcional:
  • OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"
  • OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"
• Comportamiento de auth opcional:
  • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 para forzar auth desde el almacén de perfiles e ignorar overrides solo de entorno

​

Live de generación de video

• Prueba: extensions/video-generation-providers.live.test.ts
• Habilitar: OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts
• Arnés: pnpm test:live:media video
• Alcance:
  • Ejercita la ruta compartida de proveedor de generación de video empaquetado
  • Carga variables de entorno del proveedor desde tu shell de inicio de sesión (~/.profile) antes de realizar sondeos
  • Usa por defecto claves API live/de entorno antes que los perfiles de auth almacenados, para que claves de prueba obsoletas en auth-profiles.json no oculten credenciales reales del shell
  • Omite proveedores sin auth/perfil/modelo utilizable
  • Ejecuta ambos modos de runtime declarados cuando están disponibles:
    • generate con entrada solo de prompt
    • imageToVideo cuando el proveedor declara capabilities.imageToVideo.enabled y el proveedor/modelo seleccionado acepta entrada de imagen local respaldada por búfer en el barrido compartido
    • videoToVideo cuando el proveedor declara capabilities.videoToVideo.enabled y el proveedor/modelo seleccionado acepta entrada de video local respaldada por búfer en el barrido compartido
  • Proveedores actualmente declarados pero omitidos de imageToVideo en el barrido compartido:
    • vydra porque el veo3 empaquetado es solo texto y el kling empaquetado requiere una URL de imagen remota
  • Cobertura específica de proveedor de Vydra:
    • OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts
    • ese archivo ejecuta veo3 de texto a video y además un carril kling que usa por defecto un fixture de URL de imagen remota
  • Cobertura live actual de videoToVideo:
    • runway solo cuando el modelo seleccionado es runway/gen4_aleph
  • Proveedores actualmente declarados pero omitidos de videoToVideo en el barrido compartido:
    • alibaba, qwen, xai porque esas rutas actualmente requieren URLs de referencia remotas http(s) / MP4
    • google porque el carril compartido actual de Gemini/Veo usa entrada local respaldada por búfer y esa ruta no se acepta en el barrido compartido
    • openai porque el carril compartido actual carece de garantías de acceso específicas de organización para inpaint/remix de video
• Acotación opcional:
  • OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="google,openai,runway"
  • OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"
• Comportamiento de auth opcional:
  • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 para forzar auth desde el almacén de perfiles e ignorar overrides solo de entorno

​

Arnés live de medios

• Comando: pnpm test:live:media
• Propósito:
  • Ejecuta las suites live compartidas de imagen, música y video mediante un único punto de entrada nativo del repositorio
  • Carga automáticamente las variables de entorno de proveedor que faltan desde ~/.profile
  • Acota automáticamente cada suite a proveedores que actualmente tengan auth utilizable, de forma predeterminada
  • Reutiliza scripts/test-live.mjs, de modo que el comportamiento de Heartbeat y modo silencioso siga siendo coherente
• Ejemplos:
  • pnpm test:live:media
  • pnpm test:live:media image video --providers openai,google,minimax
  • pnpm test:live:media video --video-providers openai,runway --all-providers
  • pnpm test:live:media music --quiet

​

Ejecutores Docker (comprobaciones opcionales de “funciona en Linux”)

• Ejecutores de modelos live: test:docker:live-models y test:docker:live-gateway ejecutan solo su archivo live de claves de perfil correspondiente dentro de la imagen Docker del repositorio (src/agents/models.profiles.live.test.ts y src/gateway/gateway-models.profiles.live.test.ts), montando tu directorio local de config y espacio de trabajo (y cargando ~/.profile si está montado). Los puntos de entrada locales correspondientes son test:live:models-profiles y test:live:gateway-profiles.
• Los ejecutores Docker live usan por defecto un límite de prueba de humo más pequeño para que un barrido Docker completo siga siendo práctico: test:docker:live-models usa por defecto OPENCLAW_LIVE_MAX_MODELS=12, y test:docker:live-gateway usa por defecto OPENCLAW_LIVE_GATEWAY_SMOKE=1, OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8, OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000 y OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000. Sustituye esas variables de entorno cuando quieras explícitamente el escaneo exhaustivo más grande.
• test:docker:all construye la imagen Docker live una vez mediante test:docker:live-build, y luego la reutiliza para los dos carriles Docker live.
• Ejecutores de prueba de humo de contenedor: test:docker:openwebui, test:docker:onboard, test:docker:gateway-network, test:docker:mcp-channels y test:docker:plugins arrancan uno o más contenedores reales y verifican rutas de integración de nivel superior.

• Modelos directos: pnpm test:docker:live-models (script: scripts/test-live-models-docker.sh)
• Prueba de humo de vinculación ACP: pnpm test:docker:live-acp-bind (script: scripts/test-live-acp-bind-docker.sh)
• Prueba de humo del backend CLI: pnpm test:docker:live-cli-backend (script: scripts/test-live-cli-backend-docker.sh)
• Prueba de humo del arnés app-server de Codex: pnpm test:docker:live-codex-harness (script: scripts/test-live-codex-harness-docker.sh)
• Gateway + agente dev: pnpm test:docker:live-gateway (script: scripts/test-live-gateway-models-docker.sh)
• Prueba de humo live de Open WebUI: pnpm test:docker:openwebui (script: scripts/e2e/openwebui-docker.sh)
• Asistente de onboarding (TTY, scaffolding completo): pnpm test:docker:onboard (script: scripts/e2e/onboard-docker.sh)
• Red de Gateway (dos contenedores, auth WS + health): pnpm test:docker:gateway-network (script: scripts/e2e/gateway-network-docker.sh)
• Puente de canal MCP (Gateway sembrado + puente stdio + prueba de humo de frame de notificación Claude sin procesar): pnpm test:docker:mcp-channels (script: scripts/e2e/mcp-channels-docker.sh)
• Plugins (prueba de humo de instalación + alias /plugin + semántica de reinicio del bundle de Claude): pnpm test:docker:plugins (script: scripts/e2e/plugins-docker.sh)

• bun scripts/dev/discord-acp-plain-language-smoke.ts --channel <discord-channel-id> ...
• Mantén este script para flujos de trabajo de regresión/depuración. Puede volver a ser necesario para validar el enrutamiento de hilos ACP, así que no lo elimines.

• OPENCLAW_CONFIG_DIR=... (predeterminado: ~/.openclaw) montado en /home/node/.openclaw
• OPENCLAW_WORKSPACE_DIR=... (predeterminado: ~/.openclaw/workspace) montado en /home/node/.openclaw/workspace
• OPENCLAW_PROFILE_FILE=... (predeterminado: ~/.profile) montado en /home/node/.profile y cargado antes de ejecutar las pruebas
• OPENCLAW_DOCKER_CLI_TOOLS_DIR=... (predeterminado: ~/.cache/openclaw/docker-cli-tools) montado en /home/node/.npm-global para instalaciones CLI en caché dentro de Docker
• Los directorios/archivos de auth CLI externos bajo $HOME se montan en solo lectura bajo /host-auth..., y luego se copian a /home/node/... antes de que comiencen las pruebas
  • Directorios predeterminados: .minimax
  • Archivos predeterminados: ~/.codex/auth.json, ~/.codex/config.toml, .claude.json, ~/.claude/.credentials.json, ~/.claude/settings.json, ~/.claude/settings.local.json
  • Las ejecuciones acotadas por proveedor montan solo los directorios/archivos necesarios inferidos de OPENCLAW_LIVE_PROVIDERS / OPENCLAW_LIVE_GATEWAY_PROVIDERS
  • Sustituye manualmente con OPENCLAW_DOCKER_AUTH_DIRS=all, OPENCLAW_DOCKER_AUTH_DIRS=none o una lista separada por comas como OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex
• OPENCLAW_LIVE_GATEWAY_MODELS=... / OPENCLAW_LIVE_MODELS=... para acotar la ejecución
• OPENCLAW_LIVE_GATEWAY_PROVIDERS=... / OPENCLAW_LIVE_PROVIDERS=... para filtrar proveedores dentro del contenedor
• OPENCLAW_SKIP_DOCKER_BUILD=1 para reutilizar una imagen existente openclaw:local-live en reejecuciones que no necesitan reconstrucción
• OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 para asegurar que las credenciales provengan del almacén de perfiles (no del entorno)
• OPENCLAW_OPENWEBUI_MODEL=... para elegir el modelo expuesto por Gateway para la prueba de humo de Open WebUI
• OPENCLAW_OPENWEBUI_PROMPT=... para sustituir el prompt de verificación de nonce usado por la prueba de humo de Open WebUI
• OPENWEBUI_IMAGE=... para sustituir la etiqueta fijada de imagen de Open WebUI

​

Verificación básica de la documentación

​

Regresión offline (segura para CI)

• Llamada a herramientas de Gateway (OpenAI simulado, Gateway real + bucle de agente): src/gateway/gateway.test.ts (caso: “runs a mock OpenAI tool call end-to-end via gateway agent loop”)
• Asistente de Gateway (WS wizard.start/wizard.next, escribe config + auth exigida): src/gateway/gateway.test.ts (caso: “runs wizard over ws and writes auth token config”)

​

Evaluaciones de confiabilidad del agente (Skills)

• Llamada a herramientas simulada mediante el bucle real de Gateway + agente (src/gateway/gateway.test.ts).
• Flujos end-to-end del asistente que validan el cableado de sesión y los efectos de config (src/gateway/gateway.test.ts).

• Toma de decisiones: cuando Skills aparece en el prompt, ¿el agente elige la skill correcta (o evita las irrelevantes)?
• Cumplimiento: ¿el agente lee SKILL.md antes de usarlo y sigue los pasos/args requeridos?
• Contratos de flujo de trabajo: escenarios de varios turnos que afirman el orden de herramientas, el arrastre del historial de sesión y los límites del sandbox.

• Un ejecutor de escenarios que use proveedores simulados para afirmar llamadas a herramientas + orden, lecturas de archivos de skill y cableado de sesión.
• Una pequeña suite de escenarios enfocados en skills (usar vs evitar, gating, inyección de prompt).
• Evaluaciones live opcionales (opt-in, controladas por entorno) solo después de que exista la suite segura para CI.

​

Pruebas de contrato (forma de plugin y canal)

​

Comandos

• Todos los contratos: pnpm test:contracts
• Solo contratos de canales: pnpm test:contracts:channels
• Solo contratos de proveedores: pnpm test:contracts:plugins

​

Contratos de canales

• plugin - Forma básica del plugin (id, name, capabilities)
• setup - Contrato del asistente de configuración
• session-binding - Comportamiento de vinculación de sesión
• outbound-payload - Estructura de la carga útil del mensaje
• inbound - Gestión de mensajes entrantes
• actions - Manejadores de acciones del canal
• threading - Gestión de ids de hilo
• directory - API de directorio/lista
• group-policy - Aplicación de políticas de grupo

​

Contratos de estado del proveedor

• status - Sondeos de estado del canal
• registry - Forma del registro de plugins

​

Contratos de proveedores

• auth - Contrato del flujo de autenticación
• auth-choice - Elección/selección de autenticación
• catalog - API de catálogo de modelos
• discovery - Detección de plugins
• loader - Carga de plugins
• runtime - Runtime del proveedor
• shape - Forma/interfaz del plugin
• wizard - Asistente de configuración

​

Cuándo ejecutarlas

• Después de cambiar exportaciones o subrutas de plugin-sdk
• Después de agregar o modificar un plugin de canal o proveedor
• Después de refactorizar el registro o la detección de plugins

​

Agregar regresiones (guía)

• Agrega una regresión segura para CI si es posible (proveedor simulado/stub, o captura de la transformación exacta de la forma de solicitud)
• Si es inherentemente solo live (límites de tasa, políticas de autenticación), mantén la prueba live acotada y opt-in mediante variables de entorno
• Prefiere apuntar a la capa más pequeña que detecte el error:
  • error de conversión/replay de solicitud del proveedor → prueba de modelos directos
  • error del pipeline de sesión/historial/herramientas de Gateway → prueba de humo live de Gateway o prueba segura para CI con simulación de Gateway
• Barrera de protección de recorrido de SecretRef:
  • src/secrets/exec-secret-ref-id-parity.test.ts deriva un objetivo de muestra por clase de SecretRef a partir de los metadatos del registro (listSecretTargetRegistryEntries()), y luego afirma que se rechazan los ids de exec de segmentos de recorrido.
  • Si agregas una nueva familia objetivo de SecretRef includeInPlan en src/secrets/target-registry-data.ts, actualiza classifyTargetClass en esa prueba. La prueba falla intencionalmente con ids objetivo no clasificados para que las clases nuevas no puedan omitirse silenciosamente.