Canalización de CI

OpenClaw CI se ejecuta en los envíos a main (las rutas de Markdown y docs/** se ignoran en el disparador), en solicitudes de extracción que no son borrador (se ignoran los diffs solo de CHANGELOG), y en despachos manuales. Los envíos canónicos a main primero pasan por una ventana de admisión de 90 segundos en hosted-runner; el grupo de concurrencia CI cancela esa ejecución en espera cuando llega un commit más reciente, de modo que las fusiones secuenciales no registren cada una una matriz Blacksmith completa. Las solicitudes de extracción y los despachos manuales omiten la espera. El trabajo preflight luego clasifica el diff y desactiva los carriles costosos cuando solo cambiaron áreas no relacionadas. Las ejecuciones manuales de workflow_dispatch omiten intencionalmente el alcance inteligente y despliegan el grafo completo para candidatos de lanzamiento y validación amplia. Los carriles de Android siguen siendo opcionales mediante include_android (o la entrada release_gate). La cobertura de plugins solo de lanzamiento vive en el flujo de trabajo separado Prelanzamiento de plugins y solo se ejecuta desde Validación completa de lanzamiento o un despacho manual explícito.

Resumen de la canalización

Trabajo	Propósito	Cuándo se ejecuta
`preflight`	Detectar cambios solo de documentación, alcances modificados, extensiones modificadas y construir el manifiesto de CI	Siempre en envíos y PR que no son borrador
`runner-admission`	Antirrebote hospedado de 90 segundos para envíos canónicos a `main` antes de que se registre el trabajo de Blacksmith	Cada ejecución de CI; espera solo en envíos canónicos a `main`
`security-fast`	Detección de claves privadas, auditoría de flujos de trabajo modificados mediante `zizmor` y auditoría del lockfile de producción	Siempre en envíos y PR que no son borrador
`pnpm-store-warmup`	Preparar la caché del almacén de pnpm fijada por el lockfile sin bloquear los shards de Linux Node	Carriles de Node o comprobación de docs seleccionados
`build-artifacts`	Construir `dist/`, Control UI, comprobaciones rápidas de CLI compilada, memoria de arranque y comprobaciones de artefactos compilados incrustados	Cambios relevantes para Node
`checks-fast-core`	Carriles rápidos de corrección en Linux: empaquetado + protocolo, lanzador Bun y la tarea rápida de enrutamiento de CI	Cambios relevantes para Node
`checks-fast-contracts-plugins-*`	Dos shards ponderados de contratos de plugins	Cambios relevantes para Node
`checks-fast-contracts-channels-*`	Dos shards ponderados de contratos de canales	Cambios relevantes para Node
`checks-node-*`	Shards de pruebas centrales de Node, excluyendo carriles de canal, empaquetado, contrato y extensión	Cambios relevantes para Node
`check-*`	Equivalente fragmentado de la puerta local principal: guardas, shrinkwrap, metadatos de configuración de canales empaquetados, tipos de producción, lint, dependencias, tipos de prueba	Cambios relevantes para Node
`check-additional-*`	Franjas de comprobación de límites (incluida la deriva de snapshots de prompts), límites de accessor de sesión/lector de transcripciones, grupos de lint de extensiones, compilación/canary de límites de paquetes y arquitectura de topología de runtime	Cambios relevantes para Node
`checks-node-compat-node22`	Carril de compilación y comprobación rápida de compatibilidad con Node 22	Despacho manual de CI para lanzamientos
`check-docs`	Formato de documentación, lint y comprobaciones de enlaces rotos	Docs modificadas (PR y despacho manual)
`native-i18n`	Comprobaciones de inventario de i18n de app nativa, Android y Apple	Cambios relevantes para i18n nativo
`skills-python`	Ruff + pytest para Skills respaldadas por Python	Cambios relevantes para Skills de Python
`checks-windows`	Pruebas específicas de procesos/rutas de Windows más regresiones compartidas de especificadores de importación de runtime	Cambios relevantes para Windows
`macos-node`	Pruebas enfocadas de TypeScript en macOS: launchd, Homebrew, rutas de runtime, scripts de empaquetado, wrapper de grupos de procesos	Cambios relevantes para macOS
`macos-swift`	Lint, compilación y pruebas de Swift para la app de macOS	Cambios relevantes para macOS
`ios-build`	Generación del proyecto Xcode más compilación de la app de iOS en simulador	App de iOS, kit de app compartido o cambios de Swabble
`android`	Pruebas unitarias de Android para ambos sabores más una compilación de APK de depuración	Cambios relevantes para Android
`test-performance-agent`	Flujo de trabajo separado: optimización diaria de pruebas lentas de Codex tras actividad confiable	Éxito de CI principal o despacho manual
`openclaw-performance`	Flujo de trabajo separado: informes diarios/bajo demanda de rendimiento del runtime Kova con carriles de proveedor simulado, perfil profundo y GPT 5.5 en vivo	Programado y despacho manual

Orden de fallo rápido

runner-admission espera solo para envíos canónicos a main; un envío más reciente cancela la ejecución antes del registro en Blacksmith.
preflight decide qué carriles existen. La lógica de docs-scope y changed-scope son pasos dentro de este trabajo, no trabajos independientes.
security-fast, check-*, check-additional-*, check-docs y skills-python fallan rápidamente sin esperar los trabajos más pesados de artefactos y matriz de plataformas.
build-artifacts se solapa con los carriles rápidos de Linux para que los consumidores descendentes puedan empezar en cuanto la compilación compartida esté lista.
Los carriles más pesados de plataforma y runtime se despliegan después: checks-fast-core, checks-fast-contracts-plugins-*, checks-fast-contracts-channels-*, checks-node-*, checks-windows, macos-node, macos-swift, ios-build y android.

GitHub puede marcar trabajos sustituidos como cancelled cuando llega un envío más reciente al mismo PR o ref de main. Trátalo como ruido de CI salvo que la ejecución más reciente para el mismo ref también esté fallando. Los trabajos de matriz usan fail-fast: false, y build-artifacts informa directamente los fallos incrustados de canal, límite de soporte central y gateway-watch en lugar de poner en cola pequeños trabajos verificadores. La clave automática de concurrencia de CI tiene versión (CI-v7-*) para que un zombi del lado de GitHub en un grupo de cola antiguo no pueda bloquear indefinidamente ejecuciones más recientes de main. Las ejecuciones manuales de suite completa usan CI-manual-v1-* y no cancelan ejecuciones en curso. Usa pnpm ci:timings, pnpm ci:timings:recent o node scripts/ci-run-timings.mjs <run-id> para resumir el tiempo de pared, el tiempo en cola, los trabajos más lentos, los fallos y la barrera de despliegue de pnpm-store-warmup desde GitHub Actions. El trabajo integrado en el flujo ci-timings-summary existe en ci.yml pero actualmente está deshabilitado (if: false); ejecuta el ayudante de tiempos localmente en su lugar. Para tiempos de compilación, revisa el paso Build dist del trabajo build-artifacts: pnpm build:ci-artifacts imprime [build-all] phase timings: e incluye ui:build; el trabajo también sube el artefacto startup-memory.

Contexto y evidencia de PR

Los PR de colaboradores externos ejecutan una puerta de contexto y evidencia de PR desde .github/workflows/real-behavior-proof.yml. El flujo de trabajo extrae la revisión confiable del flujo (github.workflow_sha) y evalúa solo el cuerpo del PR; no ejecuta código de la rama del colaborador. La puerta se aplica a autores de PR que no son propietarios, miembros, colaboradores ni bots del repositorio. Pasa cuando el cuerpo del PR contiene secciones redactadas por el autor Qué problema resuelve esto y Evidencia. La evidencia puede ser una prueba enfocada, resultado de CI, captura de pantalla, grabación, salida de terminal, observación en vivo, registro redactado o enlace a artefacto. El cuerpo proporciona intención y validación útil; los revisores inspeccionan el código, las pruebas y CI para evaluar la corrección. Cuando la comprobación falla, actualiza el cuerpo del PR en lugar de enviar otro commit de código.

Alcance y enrutamiento

La lógica de alcance vive en scripts/ci-changed-scope.mjs y está cubierta por pruebas unitarias en src/scripts/ci-changed-scope.test.ts. El despacho manual omite la detección de alcance modificado y hace que el manifiesto de preflight actúe como si todas las áreas con alcance hubieran cambiado.

Las ediciones de flujos de trabajo de CI validan el grafo de CI de Node, el linting de flujos de trabajo y el carril de Windows (ci.yml lo ejecuta), pero no fuerzan por sí solas compilaciones nativas de iOS, Android o macOS; esos carriles de plataforma permanecen limitados a cambios en el código fuente de la plataforma.
Workflow Sanity ejecuta actionlint, zizmor sobre todos los archivos YAML de flujos de trabajo, la guarda de interpolación de acciones compuestas y la guarda de marcadores de conflicto. El trabajo security-fast limitado al PR también ejecuta zizmor sobre los archivos de flujo de trabajo modificados para que los hallazgos de seguridad de flujos de trabajo fallen pronto en el grafo principal de CI.
La documentación en pushes a main se comprueba mediante el flujo de trabajo independiente Docs con el mismo espejo de documentación de ClawHub que usa CI, por lo que los pushes mixtos de código y documentación no ponen también en cola el fragmento check-docs de CI. Las solicitudes de extracción y la CI manual siguen ejecutando check-docs desde CI cuando la documentación cambia.
TUI PTY se ejecuta en el fragmento de Linux Node checks-node-core-runtime-tui-pty para cambios de TUI. El fragmento ejecuta test/vitest/vitest.tui-pty.config.ts con OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1, por lo que cubre tanto el carril determinista de fixture TuiBackend como el smoke más lento tui --local, que simula solo el endpoint externo del modelo.
Las ediciones solo de enrutamiento de CI, el pequeño conjunto de fixtures de pruebas core que la tarea rápida ejecuta directamente y las ediciones acotadas de helpers de contrato de plugins usan una ruta rápida de manifiesto solo Node: preflight, security-fast y solo los carriles rápidos que toca el cambio — una única tarea de enrutamiento de CI checks-fast-core, los dos fragmentos de contrato de plugins o ambos. Esa ruta omite artefactos de compilación, compatibilidad con Node 22, contratos de canales, fragmentos core completos, fragmentos de plugins empaquetados y matrices de guardas adicionales.
Las comprobaciones de Windows Node se limitan a envoltorios de procesos/rutas específicos de Windows, helpers de ejecutores npm/pnpm/UI, configuración del gestor de paquetes y las superficies de flujos de trabajo de CI que ejecutan ese carril; los cambios no relacionados de código fuente, plugins, smoke de instalación y solo pruebas permanecen en los carriles de Linux Node.

Las familias de pruebas Node más lentas están divididas o equilibradas para que cada trabajo permanezca pequeño sin reservar ejecutores en exceso:

Los contratos de plugins y los contratos de canales se ejecutan cada uno como dos fragmentos ponderados respaldados por Blacksmith con el fallback estándar de ejecutor de GitHub.
Los carriles core unitarios rápidos/de soporte se ejecutan por separado; la infraestructura de runtime core se divide en fragmentos de proceso, compartido, hooks, secretos y tres dominios cron.
La respuesta automática se ejecuta como workers equilibrados, con el subárbol de respuestas dividido en fragmentos de agent-runner, comandos, despacho, sesión y enrutamiento de estado.
Las configuraciones de Gateway/servidor agéntico (plano de control) se dividen entre carriles de chat, auth, modelo, HTTP/plugin, runtime y arranque, en lugar de esperar a los artefactos compilados.
La CI normal empaqueta solo fragmentos aislados por patrones de inclusión de infraestructura en paquetes deterministas de como máximo 64 archivos de prueba, lo que reduce la matriz de Node sin fusionar suites no aisladas de comandos/cron, agents-core con estado ni Gateway/servidor. Las suites fijas pesadas permanecen en 8 vCPU, mientras que los carriles empaquetados y de menor peso usan 4 vCPU.
Las solicitudes de extracción en el repositorio canónico usan un plan de admisión compacto: los mismos grupos por configuración se ejecutan en subprocesos aislados, actualmente 18 trabajos de prueba Node en lugar de la matriz completa de 74 trabajos. Los pushes a main, los despachos manuales y las puertas de lanzamiento conservan la matriz completa.
Las pruebas amplias de navegador, QA, medios y plugins misceláneos usan sus configuraciones de Vitest dedicadas en lugar del catch-all compartido de plugins. Los fragmentos por patrones de inclusión registran entradas de tiempos usando el nombre del fragmento de CI, por lo que .artifacts/vitest-shard-timings.json puede distinguir una configuración completa de un fragmento filtrado.
check-additional-* divide la lista suplementaria de guardas de límites (scripts/run-additional-boundary-checks.mjs) en un fragmento con alta carga de prompts (check-additional-boundaries-a, que incluye la comprobación de deriva de snapshots de prompts de Codex) y un fragmento combinado para las divisiones restantes (check-additional-boundaries-bcd), cada uno ejecutando guardas independientes en paralelo e imprimiendo tiempos por comprobación. El trabajo de compilación/canary de límites de paquetes permanece junto, y la arquitectura de topología de runtime se ejecuta por separado de la cobertura de observación del Gateway incrustada en build-artifacts.
Las pruebas de observación del Gateway, canales y el fragmento de límites de soporte core se ejecutan en paralelo dentro de build-artifacts después de que dist/ y dist-runtime/ ya estén compilados.

Una vez admitida, la CI canónica de Linux permite hasta 24 trabajos de prueba Node simultáneos y 12 para los carriles rápidos/de comprobación más pequeños; Windows y Android permanecen en dos porque esos grupos de ejecutores son más reducidos. Los lotes compactos de configuraciones completas se ejecutan con un timeout de lote de 120 minutos, mientras que los grupos por patrones de inclusión comparten el mismo presupuesto acotado de trabajos. La CI de Android ejecuta tanto testPlayDebugUnitTest como testThirdPartyDebugUnitTest y luego compila el APK de depuración de Play. El sabor de terceros no tiene un source set ni manifiesto separado; su carril de pruebas unitarias sigue compilando el sabor con las banderas BuildConfig de SMS/registro de llamadas, mientras evita un trabajo duplicado de empaquetado de APK de depuración en cada push relevante para Android. El fragmento check-dependencies ejecuta pnpm deadcode:dependencies (un pase de Knip solo de dependencias de producción fijado a una versión exacta de Knip, con la edad mínima de publicación de pnpm deshabilitada para la instalación dlx) y pnpm deadcode:unused-files, que compara los hallazgos de archivos de producción no usados de Knip con scripts/deadcode-unused-files.allowlist.mjs, además de un informe consultivo pnpm deadcode:report:ci:ts-unused subido como artefacto deadcode-reports. La guarda de archivos no usados falla cuando un PR añade un nuevo archivo no usado sin revisar o deja una entrada obsoleta en la allowlist, mientras preserva superficies intencionales de plugins dinámicos, generadas, de compilación, de pruebas en vivo y puentes de paquetes que Knip no puede resolver estáticamente.

Reenvío de actividad de ClawSweeper

.github/workflows/clawsweeper-dispatch.yml es el puente del lado de destino desde la actividad del repositorio OpenClaw hacia ClawSweeper. No hace checkout ni ejecuta código no confiable de solicitudes de extracción. El flujo de trabajo crea un token de GitHub App a partir de CLAWSWEEPER_APP_PRIVATE_KEY y luego despacha payloads compactos repository_dispatch a openclaw/clawsweeper. El flujo de trabajo tiene cuatro carriles:

clawsweeper_item para solicitudes exactas de revisión de issues y solicitudes de extracción;
clawsweeper_comment para comandos explícitos de ClawSweeper en comentarios de issues;
clawsweeper_commit_review para solicitudes de revisión a nivel de commit en pushes a main;
github_activity para actividad general de GitHub que el agente ClawSweeper puede inspeccionar.

El carril github_activity reenvía solo metadatos normalizados: tipo de evento, acción, actor, repositorio, número de elemento, URL, título, estado y extractos breves para comentarios o revisiones cuando están presentes. Evita intencionalmente reenviar el cuerpo completo del Webhook. El flujo de trabajo receptor en openclaw/clawsweeper es .github/workflows/github-activity.yml, que publica el evento normalizado en el hook del Gateway de OpenClaw para el agente ClawSweeper. La actividad general es observación, no entrega por defecto. El agente ClawSweeper recibe el destino de Discord en su prompt y debe publicar en #clawsweeper solo cuando el evento sea sorprendente, accionable, riesgoso u operativamente útil. Aperturas rutinarias, ediciones, ruido de bots, ruido duplicado de webhooks y tráfico normal de revisiones deben dar como resultado NO_REPLY. Trata los títulos, comentarios, cuerpos, texto de revisiones, nombres de ramas y mensajes de commit de GitHub como datos no confiables en toda esta ruta. Son entrada para resumen y triage, no instrucciones para el flujo de trabajo ni para el runtime del agente.

Despachos manuales

Los despachos manuales de CI ejecutan el mismo grafo de trabajos que la CI normal, pero fuerzan todos los carriles acotados no Android: fragmentos de Linux Node, fragmentos de plugins empaquetados, fragmentos de contratos de plugins y canales, compatibilidad con Node 22, check-*, check-additional-*, comprobaciones smoke de artefactos compilados, comprobaciones de documentación, Skills de Python, Windows, macOS, compilación de iOS y i18n de Control UI. Los despachos manuales independientes de CI ejecutan Android solo con include_android=true (la entrada release_gate también fuerza Android); el paraguas de lanzamiento completo habilita Android pasando include_android=true. Las comprobaciones estáticas de prelanzamiento de plugins, el fragmento solo de lanzamiento agentic-plugins, el barrido completo por lotes de extensiones y los carriles Docker de prelanzamiento de plugins están excluidos de CI. La suite Docker de prelanzamiento se ejecuta solo cuando Full Release Validation despacha el flujo de trabajo separado Plugin Prerelease con la puerta de validación de lanzamiento habilitada. Las ejecuciones manuales usan un grupo de concurrencia único para que una suite completa de candidato de lanzamiento no sea cancelada por otra ejecución de push o PR en la misma ref. La entrada opcional target_ref permite que un llamador confiable ejecute ese grafo contra una rama, etiqueta o SHA completo de commit mientras usa el archivo de flujo de trabajo de la ref de despacho seleccionada. La entrada release_gate es un fallback de mantenedor con SHA exacto para CI de PR detenida por capacidad: requiere que target_ref sea un SHA completo de commit que coincida con la cabeza de la rama despachada.

gh workflow run ci.yml --ref release/YYYY.M.PATCH
gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_android=true
gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>

La ruta mensual extended-stable solo npm es la excepción: despacha tanto el preflight de OpenClaw NPM Release como Full Release Validation desde la rama exacta extended-stable/YYYY.M.33, conserva sus ID de ejecución y pasa ambos ID a la ejecución directa de publicación npm. Consulta Publicación mensual extended-stable solo npm para los comandos, los requisitos exactos de identidad, la lectura posterior del registro y el procedimiento de reparación de selectores. Esta ruta no despacha publicaciones de plugins, macOS, Windows, GitHub Release, dist-tag privado ni otras plataformas.

Ejecutores

Ejecutor	Trabajos
`ubuntu-24.04`	Despacho manual de CI y fallbacks de repositorios no canónicos, análisis de seguridad y calidad de CodeQL, workflow-sanity, labeler, auto-response, el flujo de trabajo Docs independiente y todo el flujo de trabajo Install Smoke
`blacksmith-4vcpu-ubuntu-2404`	`preflight`, `security-fast`, `pnpm-store-warmup`, `native-i18n`, `checks-fast-core`, fragmentos de contrato de plugins/canales, la mayoría de los fragmentos Linux Node incluidos/de menor peso, carriles `check-` excepto `check-lint`, fragmentos `check-additional-` seleccionados, `check-docs` y `skills-python`
`blacksmith-8vcpu-ubuntu-2404`	Suites Linux Node pesadas conservadas, fragmentos `check-additional-*` con mucha carga de límites/extensiones, y `android`
`blacksmith-16vcpu-ubuntu-2404`	`build-artifacts` en CI y Testbox, y `check-lint` (lo bastante sensible a CPU como para que 8 vCPU costaran más de lo que ahorraban)
`blacksmith-8vcpu-windows-2025`	`checks-windows`
`blacksmith-6vcpu-macos-15`	`macos-node` en `openclaw/openclaw`; los forks hacen fallback a `macos-15`
`blacksmith-12vcpu-macos-26`	`macos-swift` e `ios-build` en `openclaw/openclaw`; los forks hacen fallback a `macos-26`

Presupuesto de registro de ejecutores

El bucket actual de registro de ejecutores de GitHub de OpenClaw informa 10.000 registros de ejecutores autohospedados cada 5 minutos en ghx api rate_limit. Vuelve a comprobar actions_runner_registration antes de cada pasada de ajuste porque GitHub puede cambiar este bucket. El límite lo comparten todos los registros de ejecutores Blacksmith en la organización openclaw, por lo que añadir otra instalación de Blacksmith no añade un bucket nuevo. Trata las etiquetas de Blacksmith como el recurso escaso para el control de ráfagas. Los trabajos que solo enrutan, notifican, resumen, seleccionan fragmentos o ejecutan análisis breves de CodeQL deben permanecer en ejecutores hospedados por GitHub, salvo que tengan necesidades específicas de Blacksmith medidas. Cualquier matriz nueva de Blacksmith, max-parallel mayor o flujo de trabajo de alta frecuencia debe mostrar su recuento de registros en el peor caso y mantener el objetivo de nivel de organización por debajo de aproximadamente el 60% del bucket activo. Con el bucket actual de 10.000 registros, eso significa un objetivo operativo de 6.000 registros, dejando margen para repositorios concurrentes, reintentos y solapamiento de ráfagas. La CI del repositorio canónico mantiene Blacksmith como la ruta de ejecutor predeterminada para ejecuciones normales de push y pull request. workflow_dispatch y las ejecuciones de repositorios no canónicos usan ejecutores hospedados por GitHub, pero las ejecuciones canónicas normales no sondean actualmente la salud de la cola de Blacksmith ni hacen fallback automáticamente a etiquetas hospedadas por GitHub cuando Blacksmith no está disponible.

Equivalentes locales

pnpm changed:lanes                            # inspect the local changed-lane classifier for origin/main...HEAD
pnpm check:changed                            # smart local check gate: changed typecheck/lint/guards by boundary lane
pnpm check                                    # fast local gate: prod tsgo + sharded lint + parallel fast guards
pnpm check:test-types
pnpm check:timed                              # same gate with per-stage timings
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.ts
pnpm test                                     # vitest tests
pnpm test:changed                             # cheap smart changed Vitest targets
pnpm test:channels
pnpm test:contracts:channels
pnpm check:docs                               # docs format + lint + broken links
pnpm build                                    # build dist when CI artifact/smoke checks matter
pnpm ios:build                                # generate and build the iOS app project
pnpm ci:timings                               # summarize the latest origin/main push CI run
pnpm ci:timings:recent                        # compare recent successful main CI runs
node scripts/ci-run-timings.mjs <run-id>      # summarize wall time, queue time, and slowest jobs
node scripts/ci-run-timings.mjs --latest-main # ignore issue/comment noise and choose origin/main push CI
node scripts/ci-run-timings.mjs --recent 10   # compare recent successful main CI runs
pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json
pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json
pnpm test:startup:memory
pnpm test:extensions:memory -- --json .artifacts/openclaw-performance/source/mock-provider/extension-memory.json
pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md

Rendimiento de OpenClaw

OpenClaw Performance es el flujo de trabajo de rendimiento del producto/runtime. Se ejecuta a diario en main y puede despacharse manualmente:

gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_openai_candidate=true
gh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3

El despacho manual normalmente mide el rendimiento del ref del flujo de trabajo. Define target_ref para medir una etiqueta de release u otra rama con la implementación actual del flujo de trabajo. Las rutas de informes publicados y los punteros latest se indexan por el ref probado, y cada index.md registra el ref/SHA probado, el ref/SHA del flujo de trabajo, el ref de Kova, el perfil, el modo de autenticación del carril, el modelo, el recuento de repeticiones y los filtros de escenario. El flujo de trabajo instala OCM desde una release fijada y Kova desde openclaw/Kova en la entrada kova_ref fijada, y luego ejecuta tres carriles:

mock-provider: escenarios de diagnóstico de Kova contra un runtime de compilación local con autenticación falsa determinista compatible con OpenAI.
mock-deep-profile: perfilado de CPU/heap/trazas para puntos críticos de arranque, Gateway y turnos de agente. Se ejecuta por programación, o por despacho con deep_profile=true.
live-openai-candidate: un turno de agente real de OpenAI openai/gpt-5.5, omitido cuando OPENAI_API_KEY no está disponible. Se ejecuta por programación, o por despacho con live_openai_candidate=true.

El carril mock-provider también ejecuta sondeos de fuente nativos de OpenClaw después de la pasada de Kova: tiempos de arranque y memoria del Gateway en casos de inicio predeterminado, canal omitido, hook interno y cincuenta plugins; RSS de importación de plugins incluidos, bucles de saludo repetidos de mock-OpenAI channel-chat-baseline, comandos de inicio de CLI contra el Gateway arrancado y el sondeo de rendimiento smoke de estado SQLite. Cuando el informe de fuente mock-provider publicado anteriormente está disponible para el ref probado, el resumen de fuente compara los valores actuales de RSS y heap contra esa línea base y marca los grandes aumentos de RSS como watch. El resumen Markdown del sondeo de fuente vive en source/index.md dentro del paquete del informe, con JSON sin procesar junto a él. Cada carril sube artefactos de GitHub. Cuando CLAWGRIT_REPORTS_TOKEN está configurado, el flujo de trabajo también confirma report.json, report.md, paquetes, index.md y artefactos de sondeos de fuente en openclaw/clawgrit-reports bajo openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/. El puntero actual del ref probado se escribe como openclaw-performance/<tested-ref>/latest-<lane>.json.

Validación completa de release

Full Release Validation es el flujo de trabajo paraguas manual para “ejecutar todo antes de la release”. Acepta una rama, etiqueta o SHA completo de commit, despacha el flujo de trabajo manual CI con ese objetivo (incluido Android), despacha Plugin Prerelease para prueba solo de release de plugin/paquete/estático/Docker, despacha OpenClaw Performance contra el SHA objetivo y despacha OpenClaw Release Checks para install smoke, aceptación de paquetes, comprobaciones de paquetes entre sistemas operativos, paridad de QA Lab, Matrix y carriles de Telegram (la renderización de la tarjeta de puntuación de madurez consultiva es opcional mediante run_maturity_scorecard). Los perfiles stable y full siempre incluyen cobertura exhaustiva live/E2E y de soak de la ruta de release de Docker; el perfil beta puede optar por incluirla con run_release_soak=true. El E2E canónico de Telegram del paquete se ejecuta dentro de Package Acceptance, por lo que un candidato completo no inicia un sondeador live duplicado. Después de publicar, pasa release_package_spec para reutilizar el paquete npm enviado en release checks, Package Acceptance, Docker, entre sistemas operativos y Telegram sin recompilar. Usa npm_telegram_package_spec solo para una repetición enfocada de Telegram con paquete publicado. El carril de paquete live del Plugin de Codex usa el mismo estado seleccionado de forma predeterminada: release_package_spec=openclaw@<tag> publicado deriva codex_plugin_spec=npm:@openclaw/codex@<tag>, mientras que las ejecuciones por SHA/artefacto empaquetan extensions/codex desde el ref seleccionado. Define codex_plugin_spec explícitamente para fuentes de plugin personalizadas como especificaciones npm:, npm-pack: o git:. Consulta Validación completa de release para la matriz de etapas, los nombres exactos de trabajos de flujo de trabajo, las diferencias de perfil, los artefactos y los identificadores de repetición enfocada. OpenClaw Release Publish es el flujo de trabajo manual mutador de release. Despáchalo desde release/YYYY.M.PATCH o main después de que exista la etiqueta de release y después de que el preflight npm de OpenClaw haya tenido éxito (el preflight ejecuta pnpm plugins:sync:check entre sus comprobaciones). Requiere el preflight_run_id guardado y un full_release_validation_run_id exitoso, despacha Plugin NPM Release para todos los paquetes de plugin publicables, despacha Plugin ClawHub Release para el mismo SHA de release, y solo entonces despacha OpenClaw NPM Release. La publicación stable también requiere un windows_node_tag exacto; el flujo de trabajo verifica la release de fuente de Windows y compara sus instaladores x64/ARM64 con la entrada windows_node_installer_digests aprobada por el candidato antes de cualquier hijo de publicación, y luego promueve y verifica esos mismos resúmenes de instalador fijados más el contrato exacto de activo acompañante y suma de comprobación antes de publicar el borrador de release de GitHub.

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f npm_dist_tag=beta

Para prueba de commit fijado en una rama de movimiento rápido, usa el helper en lugar de gh workflow run ... --ref main -f ref=<sha>:

pnpm ci:full-release --sha <full-sha>

Las refs de dispatch de flujos de trabajo de GitHub deben ser ramas o etiquetas, no SHA de commits sin procesar. El ayudante sube una rama temporal release-ci/<sha>-... en el SHA de destino, lanza Full Release Validation desde esa ref fijada, verifica que cada headSha de flujo de trabajo secundario coincida con el destino y elimina la rama temporal cuando la ejecución termina. El verificador paraguas también falla si algún flujo de trabajo secundario se ejecutó en un SHA diferente. release_profile controla la amplitud live/de proveedores que se pasa a las comprobaciones de release. Los flujos de trabajo manuales de release usan stable de forma predeterminada; usa full solo cuando quieras intencionalmente la matriz amplia consultiva de proveedores/medios. Las comprobaciones de release stable y full siempre ejecutan el soak exhaustivo live/E2E y Docker de la ruta de release; el perfil beta puede optar por incluirlo con run_release_soak=true.

minimum mantiene las rutas OpenAI/core críticas de release más rápidas.
stable agrega el conjunto estable de proveedores/backends.
full ejecuta la matriz amplia consultiva de proveedores/medios.

El paraguas registra los ids de ejecución secundarios lanzados, y el trabajo final Verify full validation vuelve a comprobar las conclusiones actuales de las ejecuciones secundarias y añade tablas de trabajos más lentos para cada ejecución secundaria. Si un flujo de trabajo secundario se vuelve a ejecutar y pasa a verde, vuelve a ejecutar solo el trabajo verificador padre para actualizar el resultado paraguas y el resumen de tiempos. Para recuperación, tanto Full Release Validation como OpenClaw Release Checks aceptan rerun_group. Usa all para un candidato de release, ci solo para el secundario normal de CI completo, plugin-prerelease solo para el secundario de prerelease de plugins, performance solo para el secundario de OpenClaw Performance, release-checks para cada secundario de release, o un grupo más acotado: install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live o npm-telegram en el paraguas. Esto mantiene acotada la repetición de una caja de release fallida después de una corrección enfocada. Para una sola ruta cross-OS fallida, combina rerun_group=cross-os con cross_os_suite_filter, por ejemplo windows/packaged-upgrade; los comandos cross-OS largos emiten líneas de Heartbeat y los resúmenes de packaged-upgrade incluyen tiempos por fase. Las rutas QA de release-check son consultivas excepto la puerta estándar de cobertura de herramientas de runtime, que bloquea cuando las herramientas dinámicas requeridas de OpenClaw derivan o desaparecen del resumen del nivel estándar. OpenClaw Release Checks usa la ref confiable del flujo de trabajo para resolver la ref seleccionada una sola vez en un tarball release-package-under-test, y luego pasa ese artefacto a las comprobaciones cross-OS y a Package Acceptance, además del flujo de trabajo Docker live/E2E de la ruta de release cuando se ejecuta la cobertura soak. Eso mantiene consistentes los bytes del paquete entre cajas de release y evita volver a empaquetar el mismo candidato en varios trabajos secundarios. Para la ruta live del plugin npm de Codex, las comprobaciones de release pasan una especificación de plugin publicada coincidente derivada de release_package_spec, pasan el codex_plugin_spec proporcionado por el operador o dejan la entrada en blanco para que el script Docker empaquete el plugin Codex del checkout seleccionado. Las ejecuciones duplicadas de Full Release Validation para ref=main y rerun_group=all reemplazan al paraguas anterior. El monitor padre cancela cualquier flujo de trabajo secundario que ya haya lanzado cuando se cancela el padre, por lo que una validación de main más nueva no queda detrás de una ejecución obsoleta de release-check de dos horas. La validación de ramas/etiquetas de release y los grupos de repetición enfocados mantienen cancel-in-progress: false.

Shards live y E2E

El secundario live/E2E de release conserva una cobertura nativa amplia de pnpm test:live, pero la ejecuta como shards con nombre mediante scripts/test-live-shard.mjs en lugar de un único trabajo serial:

native-live-src-agents y native-live-src-agents-zai-coding
native-live-src-gateway-core
trabajos native-live-src-gateway-profiles filtrados por proveedor
native-live-src-gateway-backends
native-live-src-infra
native-live-test
native-live-extensions-a-k
native-live-extensions-l-n
native-live-extensions-moonshot
native-live-extensions-openai
native-live-extensions-o-z-other
native-live-extensions-xai
shards divididos de audio/video de medios y shards de música filtrados por proveedor

Eso mantiene la misma cobertura de archivos y facilita repetir y diagnosticar fallos lentos de proveedores live. Los nombres agregados de shard native-live-src-gateway, native-live-extensions-o-z, native-live-extensions-media y native-live-extensions-media-music siguen siendo válidos para repeticiones manuales de una sola ejecución. Los shards nativos live de medios se ejecutan en ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04, construido por el flujo de trabajo Live Media Runner Image. Esa imagen preinstala ffmpeg y ffprobe; los trabajos de medios solo verifican los binarios antes de la configuración. Mantén las suites live respaldadas por Docker en runners Blacksmith normales; los trabajos en contenedores no son el lugar correcto para lanzar pruebas Docker anidadas. Los shards live de modelo/backend respaldados por Docker usan una imagen compartida separada ghcr.io/openclaw/openclaw-live-test:<sha>-<extensions> por commit seleccionado. El flujo de trabajo live de release construye y sube esa imagen una vez, y luego los shards live Docker de modelo, Gateway dividido por proveedor, backend CLI, enlace ACP y arnés Codex se ejecutan con OPENCLAW_SKIP_DOCKER_BUILD=1. Los shards Docker de Gateway llevan límites explícitos de timeout a nivel de script por debajo del timeout del trabajo de flujo de trabajo, para que un contenedor atascado o una ruta de limpieza falle rápido en lugar de consumir todo el presupuesto de release-check. Si esos shards reconstruyen de forma independiente el destino Docker completo de fuente, la ejecución de release está mal configurada y desperdiciará tiempo de reloj en builds de imagen duplicados.

Aceptación de paquetes

Usa Package Acceptance cuando la pregunta sea “¿funciona este paquete instalable de OpenClaw como producto?”. Es diferente de la CI normal: la CI normal valida el árbol de fuente, mientras que la aceptación de paquetes valida un único tarball mediante el mismo arnés Docker E2E que los usuarios ejercitan después de instalar o actualizar.

Trabajos

resolve_package hace checkout de workflow_ref, resuelve un candidato de paquete, escribe .artifacts/docker-e2e-package/openclaw-current.tgz, escribe .artifacts/docker-e2e-package/package-candidate.json, sube ambos como el artefacto package-under-test e imprime la fuente, la ref de flujo de trabajo, la ref de paquete, la versión, el SHA-256 y el perfil en el resumen de pasos de GitHub.
package_integrity descarga el artefacto package-under-test y aplica el contrato público del tarball de paquete con scripts/check-openclaw-package-tarball.mjs.
docker_acceptance llama a openclaw-live-and-e2e-checks-reusable.yml con el SHA de fuente del paquete resuelto (con fallback a workflow_ref) y package_artifact_name=package-under-test. El flujo de trabajo reutilizable descarga ese artefacto, valida el inventario del tarball, prepara imágenes Docker con digest de paquete cuando es necesario y ejecuta las rutas Docker seleccionadas contra ese paquete en lugar de empaquetar el checkout del flujo de trabajo. Cuando un perfil selecciona múltiples docker_lanes dirigidas, el flujo de trabajo reutilizable prepara el paquete y las imágenes compartidas una vez, y luego distribuye esas rutas como trabajos Docker dirigidos paralelos con artefactos únicos.
package_telegram llama opcionalmente a NPM Telegram Beta E2E. Se ejecuta cuando telegram_mode no es none e instala el mismo artefacto package-under-test cuando Package Acceptance resolvió uno; un dispatch independiente de Telegram aún puede instalar una especificación npm publicada.
summary falla el flujo de trabajo si falló la resolución del paquete, la integridad, la aceptación Docker o la ruta opcional de Telegram. La entrada advisory degrada los fallos de aceptación a advertencias para llamadores consultivos.

Fuentes candidatas

source=npm acepta solo openclaw@extended-stable, openclaw@beta, openclaw@latest o una versión exacta de release de OpenClaw como openclaw@2026.4.27-beta.2. Usa esto para aceptación de extended-stable, prerelease o stable publicados.
source=ref empaqueta una rama, etiqueta o SHA de commit completo confiable de package_ref. El resolvedor obtiene ramas/etiquetas de OpenClaw, verifica que el commit seleccionado sea alcanzable desde el historial de ramas del repositorio o desde una etiqueta de release, instala dependencias en un worktree separado y lo empaqueta con scripts/package-openclaw-for-docker.mjs.
source=url descarga un .tgz HTTPS público; package_sha256 es obligatorio. Esta ruta rechaza credenciales en URL, puertos HTTPS no predeterminados, nombres de host o IP resueltas privadas/internas/de uso especial, y redirecciones fuera de la misma política pública de seguridad.
source=trusted-url descarga un .tgz HTTPS desde una política de fuente confiable con nombre en .github/package-trusted-sources.json; package_sha256 y trusted_source_id son obligatorios. Usa esto solo para espejos empresariales propiedad de mantenedores o repositorios privados de paquetes que necesiten hosts, puertos, prefijos de ruta, hosts de redirección o resolución de red privada configurados. Si la política declara autenticación bearer, el flujo de trabajo usa el secreto fijo OPENCLAW_TRUSTED_PACKAGE_TOKEN; las credenciales incrustadas en URL se siguen rechazando.
source=artifact descarga un .tgz desde artifact_run_id y artifact_name; package_sha256 es opcional, pero debería proporcionarse para artefactos compartidos externamente.

Mantén workflow_ref y package_ref separados. workflow_ref es el código confiable de flujo de trabajo/arnés que ejecuta la prueba. package_ref es el commit de fuente que se empaqueta cuando source=ref. Esto permite que el arnés de pruebas actual valide commits de fuente confiables más antiguos sin ejecutar lógica antigua de flujo de trabajo.

Perfiles de suite

smoke — npm-onboard-channel-agent, gateway-network, config-reload
package — npm-onboard-channel-agent, doctor-switch, update-channel-switch, skill-install, update-corrupt-plugin, upgrade-survivor, published-upgrade-survivor, root-managed-vps-upgrade, update-restart-auth, plugins-offline, plugin-update
product — el conjunto package con cobertura live de plugins en lugar de plugins-offline, además de mcp-channels, cron-mcp-cleanup, openai-web-search-minimal, openwebui
full — fragmentos completos Docker de la ruta de release con OpenWebUI
custom — docker_lanes exactas; obligatorio cuando suite_profile=custom

El perfil package usa cobertura offline de plugins para que la validación de paquetes publicados no dependa de la disponibilidad live de ClawHub. La ruta opcional de Telegram reutiliza el artefacto package-under-test en NPM Telegram Beta E2E, y la ruta de especificación npm publicada se conserva para dispatches independientes. Para la política dedicada de pruebas de actualización y plugins, incluidos comandos locales, rutas Docker, entradas de Package Acceptance, valores predeterminados de release y triage de fallos, consulta Pruebas de actualizaciones y plugins. Las comprobaciones de release llaman a Package Acceptance con source=artifact, el artefacto preparado del paquete de release, suite_profile=custom,

docker_lanes='doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape'

y telegram_mode=mock-openai. Esto mantiene la prueba de migración de paquetes, actualización, instalación live de Skills de ClawHub, limpieza de dependencias de plugins obsoletas, reparación de instalación de plugins configurados, plugin offline, plugin-update y Telegram en el mismo tarball de paquete resuelto. Define release_package_spec en Full Release Validation u OpenClaw Release Checks después de publicar una beta para ejecutar la misma matriz contra el paquete npm enviado sin reconstruir; define package_acceptance_package_spec solo cuando Package Acceptance necesita un paquete diferente del resto de la validación de release. Las comprobaciones cross-OS de release aún cubren onboarding, instalador y comportamiento de plataforma específicos del sistema operativo; la validación de producto de paquetes/actualizaciones debería empezar con Package Acceptance. La lane de Docker published-upgrade-survivor valida una referencia base de paquete publicado por ejecución en la ruta de lanzamiento bloqueante. En Package Acceptance, el tarball package-under-test resuelto siempre es el candidato y published_upgrade_survivor_baseline selecciona la referencia base publicada alternativa, con openclaw@latest como valor predeterminado; los comandos de repetición de lanes fallidas conservan esa referencia base. Full Release Validation con run_release_soak=true o release_profile=full define published_upgrade_survivor_baselines='last-stable-4 2026.4.23 2026.5.2 2026.4.15' y published_upgrade_survivor_scenarios=reported-issues para expandirse por las cuatro versiones estables más recientes de npm, además de versiones fijadas de frontera de compatibilidad de plugins y fixtures con forma de incidencias para la configuración de Feishu, archivos de arranque/persona conservados, instalaciones configuradas de plugins de OpenClaw, rutas de logs con tilde y raíces obsoletas de dependencias de plugins heredados. Las selecciones de superviviente de actualización publicada con varias referencias base se fragmentan por referencia base en trabajos de runner Docker dirigidos independientes. El workflow Update Migration independiente usa la lane de Docker update-migration con referencias base all-since-2026.4.23 y escenarios plugin-deps-cleanup cuando la cuestión es la limpieza exhaustiva de actualizaciones publicadas, no la amplitud normal de Full Release CI. Las ejecuciones agregadas locales pueden pasar especificaciones exactas de paquetes con OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS, mantener una sola lane con OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC como openclaw@2026.4.15, o definir OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS para la matriz de escenarios. La lane publicada configura la referencia base con una receta de comando openclaw config set integrada, registra los pasos de la receta en summary.json y sondea /healthz, /readyz, además del estado RPC después del inicio del Gateway. Las lanes frescas empaquetadas y de instalador de Windows también verifican que un paquete instalado pueda importar una sobrescritura de control del navegador desde una ruta absoluta sin procesar de Windows. El smoke de turno de agente de OpenAI entre sistemas operativos usa de forma predeterminada OPENCLAW_CROSS_OS_OPENAI_MODEL cuando está definido; si no, usa openai/gpt-5.5, por lo que la prueba de instalación y Gateway permanece en un modelo de prueba GPT-5 y evita los valores predeterminados de GPT-4.x.

Ventanas de compatibilidad heredada

Package Acceptance tiene ventanas acotadas de compatibilidad heredada para paquetes ya publicados. Los paquetes hasta 2026.4.25, incluido 2026.4.25-beta.*, pueden usar la ruta de compatibilidad:

las entradas privadas conocidas de QA en dist/postinstall-inventory.json pueden apuntar a archivos omitidos del tarball;
doctor-switch puede omitir el subcaso de persistencia gateway install --wrapper cuando el paquete no expone esa marca;
update-channel-switch puede podar patchedDependencies de pnpm faltantes del fixture de git falso derivado del tarball y puede registrar update.channel persistido faltante;
los smokes de plugins pueden leer ubicaciones heredadas de registros de instalación o aceptar que falte la persistencia del registro de instalación del marketplace;
plugin-update puede permitir la migración de metadatos de configuración mientras sigue exigiendo que el registro de instalación y el comportamiento sin reinstalación permanezcan sin cambios.

El paquete publicado 2026.4.26 también puede advertir sobre archivos de marca de metadatos de compilación local que ya se habían enviado, y los paquetes hasta 2026.5.20 pueden advertir en vez de fallar cuando falta npm-shrinkwrap.json. Los paquetes posteriores deben satisfacer los contratos modernos; las mismas condiciones fallan en vez de advertir u omitirse.

Ejemplos

# Validate the current beta package with product-level coverage.
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f telegram_mode=mock-openai

# Validate the published extended-stable package with package coverage.
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@extended-stable \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

# Pack and validate a release branch with the current harness.
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=release/YYYY.M.PATCH \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

# Validate a tarball URL. SHA-256 is mandatory for source=url.
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=url \
  -f package_url=https://example.com/openclaw-current.tgz \
  -f package_sha256=<64-char-sha256> \
  -f suite_profile=smoke

# Validate a tarball from a named trusted private mirror policy.
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=trusted-url \
  -f trusted_source_id=enterprise-artifactory \
  -f package_url=https://packages.example.internal:8443/artifactory/openclaw/openclaw-current.tgz \
  -f package_sha256=<64-char-sha256> \
  -f suite_profile=smoke

# Reuse a tarball uploaded by another Actions run.
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=artifact \
  -f artifact_run_id=<run-id> \
  -f artifact_name=package-under-test \
  -f suite_profile=custom \
  -f docker_lanes='install-e2e plugin-update'

Al depurar una ejecución fallida de aceptación de paquetes, empieza por el resumen resolve_package para confirmar el origen, la versión y el SHA-256 del paquete. Luego inspecciona la ejecución hija docker_acceptance y sus artefactos de Docker: .artifacts/docker-tests/**/summary.json, failures.json, logs de lanes, tiempos de fases y comandos de repetición. Prefiere volver a ejecutar el perfil de paquete fallido o las lanes de Docker exactas en vez de volver a ejecutar la validación completa de lanzamiento.

Smoke de instalación

El workflow Install Smoke independiente ya no se ejecuta en pull requests ni en pushes a main. Se ejecuta en una programación nocturna, por despacho manual y como llamada de workflow desde la validación de lanzamiento, y cada ejecución toma la ruta completa de install-smoke en runners alojados por GitHub:

La imagen smoke del Dockerfile raíz se construye una vez por SHA objetivo (o se reutiliza desde GHCR como ghcr.io/openclaw/openclaw-dockerfile-smoke:<sha>); luego se ejecutan contra ella el smoke de CLI, el smoke de CLI de eliminación de workspace compartido de agentes, el E2E de gateway-network en contenedor y el smoke de argumento de compilación del plugin matrix incluido. El smoke de plugin verifica la duplicación de instalación de dependencias en tiempo de ejecución y que el plugin se cargue sin diagnósticos de escape de entrada.
La instalación del paquete QR y los smokes de Docker de instalador/actualización (incluidas las lanes de instalador de Rocky Linux y una lane de actualización contra una referencia base npm configurable update_baseline_version) se ejecutan como trabajos independientes para que el trabajo de instalador no espere detrás de los smokes de imagen raíz.

El smoke lento de proveedor de imágenes de instalación global de Bun se controla por separado mediante run_bun_global_install_smoke. Se ejecuta en la programación nocturna, está activado de forma predeterminada para llamadas de workflow desde comprobaciones de lanzamiento, y los despachos manuales de Install Smoke pueden optar por incluirlo. La CI normal de PR sigue ejecutando la lane rápida de regresión del lanzador Bun para cambios relevantes para Node. Las pruebas Docker de QR e instalador mantienen sus propios Dockerfiles centrados en instalación.

Docker E2E local

pnpm test:docker:all preconstruye una imagen compartida de pruebas en vivo, empaqueta OpenClaw una vez como tarball npm y construye dos imágenes compartidas de scripts/e2e/Dockerfile:

un runner básico de Node/Git para lanes de instalador/actualización/dependencias de plugins;
una imagen funcional que instala el mismo tarball en /app para lanes de funcionalidad normal.

Las definiciones de lanes de Docker viven en scripts/lib/docker-e2e-scenarios.mjs, la lógica del planificador vive en scripts/lib/docker-e2e-plan.mjs, y el runner solo ejecuta el plan seleccionado. El programador selecciona la imagen por lane con OPENCLAW_DOCKER_E2E_BARE_IMAGE y OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE, y luego ejecuta lanes con OPENCLAW_SKIP_DOCKER_BUILD=1.

Ajustables

Variable	Predeterminado	Propósito
`OPENCLAW_DOCKER_ALL_PARALLELISM`	10	Recuento de ranuras del pool principal para lanes normales.
`OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`	10	Recuento de ranuras del pool de cola sensible a proveedores.
`OPENCLAW_DOCKER_ALL_LIVE_LIMIT`	9	Límite de lanes en vivo concurrentes para que los proveedores no apliquen throttling.
`OPENCLAW_DOCKER_ALL_NPM_LIMIT`	5	Límite de lanes concurrentes de instalación npm.
`OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`	7	Límite de lanes concurrentes multiservicio.
`OPENCLAW_DOCKER_ALL_START_STAGGER_MS`	2000	Escalonamiento entre inicios de lanes para evitar tormentas de creación del demonio Docker; define `0` para no escalonar.
`OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`	7200000	Tiempo de espera alternativo por lane (120 minutos); lanes en vivo/de cola seleccionadas usan límites más estrictos.
`OPENCLAW_DOCKER_ALL_DRY_RUN`	sin definir	`1` imprime el plan del programador sin ejecutar lanes.
`OPENCLAW_DOCKER_ALL_LANES`	sin definir	Lista exacta de lanes separada por comas; omite el smoke de limpieza para que los agentes puedan reproducir una lane fallida.

Una lane más pesada que su límite efectivo aún puede iniciar desde un pool vacío, y luego se ejecuta sola hasta que libera capacidad. El agregado local realiza preflights de Docker, elimina contenedores E2E obsoletos de OpenClaw, emite el estado de lanes activas, persiste los tiempos de lanes para ordenarlas de mayor a menor duración y deja de programar nuevas lanes agrupadas después del primer fallo de forma predeterminada.

Workflow reutilizable en vivo/E2E

El workflow reutilizable en vivo/E2E pregunta a scripts/test-docker-all.mjs --plan-json qué paquete, tipo de imagen, imagen en vivo, lane y cobertura de credenciales se requieren. Luego scripts/docker-e2e.mjs convierte ese plan en salidas y resúmenes de GitHub. Empaqueta OpenClaw mediante scripts/package-openclaw-for-docker.mjs, descarga un artefacto de paquete de la ejecución actual o descarga un artefacto de paquete desde package_artifact_run_id; valida el inventario del tarball; construye y publica imágenes bare/functional de Docker E2E de GHCR etiquetadas por digest de paquete mediante la caché de capas Docker de Blacksmith cuando el plan necesita lanes con paquete instalado; y reutiliza entradas docker_e2e_bare_image/docker_e2e_functional_image proporcionadas o imágenes existentes por digest de paquete en vez de reconstruir. Las descargas de imágenes Docker se reintentan con un tiempo de espera acotado de 180 segundos por intento para que una transmisión bloqueada de registro/caché reintente rápidamente en vez de consumir la mayor parte de la ruta crítica de CI.

Fragmentos de la ruta de lanzamiento

La cobertura Docker de lanzamiento ejecuta trabajos fragmentados más pequeños con OPENCLAW_SKIP_DOCKER_BUILD=1 para que cada fragmento descargue solo el tipo de imagen que necesita y ejecute varias lanes mediante el mismo programador ponderado:

OPENCLAW_DOCKER_ALL_PROFILE=release-path
OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h

Los fragmentos Docker de lanzamiento actuales son core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, y plugins-runtime-install-a hasta plugins-runtime-install-h. package-update-openai incluye la lane de paquete en vivo del plugin Codex, que instala el paquete candidato de OpenClaw, instala el plugin Codex desde codex_plugin_spec o un tarball de la misma ref con aprobación explícita de instalación de Codex CLI, ejecuta el preflight de Codex CLI y luego ejecuta varios turnos de agente de OpenClaw en la misma sesión contra OpenAI. plugins-runtime-core, plugins-runtime y plugins-integrations siguen siendo alias agregados de plugins/runtime. El alias de lane install-e2e sigue siendo el alias agregado de repetición manual para ambas lanes de instalador de proveedores. OpenWebUI se incorpora en plugins-runtime-services cuando la cobertura completa de la ruta de lanzamiento lo solicita, y conserva un fragmento independiente openwebui solo para despachos exclusivos de OpenWebUI. Los carriles de actualización de canales incluidos reintentan una vez ante fallos transitorios de red de npm. Cada fragmento sube .artifacts/docker-tests/ con registros de carril, tiempos, summary.json, failures.json, tiempos por fase, JSON del planificador, tablas de carriles lentos y comandos de repetición por carril. La entrada docker_lanes del flujo de trabajo ejecuta los carriles seleccionados contra las imágenes preparadas en lugar de los trabajos de fragmento, lo que mantiene la depuración de carriles fallidos acotada a un trabajo Docker dirigido y prepara, descarga o reutiliza el artefacto de paquete para esa ejecución; si un carril seleccionado es un carril Docker en vivo, el trabajo dirigido compila localmente la imagen de pruebas en vivo para esa repetición. Los comandos generados de repetición por carril de GitHub incluyen package_artifact_run_id, package_artifact_name y entradas de imagen preparada cuando esos valores existen, para que un carril fallido pueda reutilizar el paquete y las imágenes exactos de la ejecución fallida.

pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summaries

El flujo de trabajo programado en vivo/E2E ejecuta diariamente la suite Docker completa de la ruta de lanzamiento.

Prelanzamiento de Plugin

Plugin Prerelease es una cobertura de producto/paquete más costosa, por lo que es un flujo de trabajo separado despachado por Full Release Validation o por un operador explícito. Las solicitudes de cambios normales, los envíos a main y los despachos manuales independientes de CI mantienen esa suite desactivada. Equilibra las pruebas de Plugins incluidos entre ocho workers de extensiones; esos trabajos de fragmento de extensiones ejecutan hasta dos grupos de configuración de Plugin a la vez, con un worker de Vitest por grupo y un heap de Node más grande para que los lotes de Plugins con muchas importaciones no creen trabajos de CI adicionales. La ruta de prelanzamiento Docker solo para lanzamientos (habilitada por la entrada full_release_validation) agrupa carriles Docker dirigidos en grupos de cuatro para evitar reservar decenas de runners para trabajos de uno a tres minutos. El flujo de trabajo también sube un artefacto informativo plugin-inspector-advisory desde @openclaw/plugin-inspector; los hallazgos del inspector son entrada de triaje y no cambian la puerta bloqueante de Plugin Prerelease.

QA Lab

QA Lab tiene carriles de CI dedicados fuera del flujo de trabajo principal con alcance inteligente. La paridad agéntica está anidada bajo los arneses amplios de QA y lanzamiento, no en un flujo de trabajo independiente de PR. Usa Full Release Validation con rerun_group=qa-parity cuando la paridad deba ir junto con una ejecución de validación amplia.

El flujo de trabajo QA-Lab - All Lanes se ejecuta cada noche en main y mediante despacho manual; distribuye el carril de paridad simulada, el carril Matrix en vivo y los carriles Telegram y Discord en vivo como trabajos paralelos. Los trabajos en vivo usan el entorno qa-live-shared, y Telegram/Discord usan arrendamientos Convex.

Las comprobaciones de lanzamiento ejecutan los carriles de transporte en vivo de Matrix y Telegram con el proveedor simulado determinista y modelos calificados como simulados (mock-openai/gpt-5.5 y mock-openai/gpt-5.5-alt) para que el contrato del canal quede aislado de la latencia del modelo en vivo y del arranque normal del Plugin de proveedor. El Gateway de transporte en vivo desactiva la búsqueda de memoria porque la paridad de QA cubre el comportamiento de memoria por separado; la conectividad de proveedores está cubierta por las suites separadas de modelo en vivo, proveedor nativo y proveedor Docker. Matrix usa --profile fast para puertas programadas y de lanzamiento, y añade --fail-fast solo cuando la CLI extraída lo admite. El valor predeterminado de la CLI y la entrada manual del flujo de trabajo siguen siendo all; el despacho manual matrix_profile=all siempre divide la cobertura completa de Matrix en trabajos transport, media, e2ee-smoke, e2ee-deep y e2ee-cli. OpenClaw Release Checks también ejecuta los carriles críticos de lanzamiento de QA Lab antes de la aprobación del lanzamiento; su puerta de paridad de QA ejecuta los paquetes candidato y base como trabajos de carril paralelos, y luego descarga ambos artefactos en un pequeño trabajo de informe para la comparación final de paridad. Para PR normales, sigue la evidencia de CI/comprobación con alcance en lugar de tratar la paridad como un estado obligatorio.

CodeQL

El flujo de trabajo CodeQL es intencionadamente un escáner de seguridad estrecho de primera pasada, no el barrido completo del repositorio. Las ejecuciones diarias, manuales, por envío a main y de protección para solicitudes de cambios no borrador escanean código de flujos de trabajo de Actions y las superficies JavaScript/TypeScript de mayor riesgo con consultas de seguridad de alta confianza filtradas a security-severity alta/crítica. La protección de solicitudes de cambios se mantiene ligera: solo arranca para cambios bajo .github/actions, .github/codeql, .github/workflows, packages, scripts, src o rutas de runtime de Plugins incluidos que poseen procesos, y ejecuta la misma matriz de seguridad de alta confianza que el flujo de trabajo programado. CodeQL de Android y macOS quedan fuera de los valores predeterminados de PR.

Categorías de seguridad

Categoría	Superficie
`/codeql-security-high/core-auth-secrets`	Autenticación, secretos, sandbox, cron y línea base de gateway
`/codeql-security-high/channel-runtime-boundary`	Contratos de implementación de canales centrales más el runtime del Plugin de canal, gateway, Plugin SDK, secretos y puntos de auditoría
`/codeql-security-high/network-ssrf-boundary`	Superficies centrales de SSRF, análisis de IP, protección de red, web-fetch y política SSRF del Plugin SDK
`/codeql-security-high/mcp-process-tool-boundary`	Servidores MCP, helpers de ejecución de procesos, entrega saliente y puertas de ejecución de herramientas del agente
`/codeql-security-high/process-exec-boundary`	Shell local, helpers de lanzamiento de procesos, runtimes de Plugins incluidos que poseen subprocesos y unión de scripts de flujo de trabajo
`/codeql-security-high/plugin-trust-boundary`	Instalación de Plugins, cargador, manifiesto, registro, instalación con gestor de paquetes, carga de código fuente y superficies de confianza del contrato de paquete del Plugin SDK

Fragmentos de seguridad específicos de plataforma

CodeQL Android Critical Security — fragmento programado de seguridad de Android. Compila la app de Android manualmente para CodeQL en el runner Linux de Blacksmith más pequeño aceptado por la comprobación de sanidad del flujo de trabajo. Sube bajo /codeql-critical-security/android.
CodeQL macOS Critical Security — fragmento semanal/manual de seguridad de macOS. Compila la app de macOS manualmente para CodeQL en Blacksmith macOS, filtra los resultados de compilación de dependencias fuera del SARIF subido y sube bajo /codeql-critical-security/macos. Se mantiene fuera de los valores predeterminados diarios porque la compilación de macOS domina el tiempo de ejecución incluso cuando está limpia.

Categorías de calidad crítica

CodeQL Critical Quality es el fragmento no relacionado con seguridad correspondiente. Ejecuta solo consultas de calidad JavaScript/TypeScript sin seguridad y con severidad de error sobre superficies estrechas de alto valor en runners Linux alojados por GitHub, para que los escaneos de calidad no consuman el presupuesto de registro de runners de Blacksmith. Su protección de solicitudes de cambios es intencionadamente más pequeña que el perfil programado: las PR no borrador ejecutan solo los fragmentos correspondientes para las superficies que tocan, de entre trece fragmentos enrutable por PR: agent-runtime-boundary, channel-runtime-boundary, config-boundary, core-auth-secrets, gateway-runtime-boundary, mcp-process-runtime-boundary, memory-runtime-boundary, network-runtime-boundary, plugin-boundary, plugin-sdk-package-contract, plugin-sdk-reply-runtime, provider-runtime-boundary y session-diagnostics-boundary. ui-control-plane y web-media-runtime-boundary quedan fuera de las ejecuciones de PR. Los cambios de configuración de CodeQL y del flujo de trabajo de calidad ejecutan el conjunto completo de fragmentos de PR (el fragmento de runtime de red se activa con sus propios archivos de configuración de CodeQL y rutas de código fuente que poseen la red). El despacho manual acepta:

profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|network-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary

Los perfiles estrechos son ganchos de enseñanza/iteración para ejecutar un fragmento de calidad de forma aislada.

Categoría	Superficie
`/codeql-critical-quality/core-auth-secrets`	Código de límite de seguridad de autenticación, secretos, sandbox, Cron y Gateway
`/codeql-critical-quality/config-boundary`	Esquema de configuración, migración, normalización y contratos de E/S
`/codeql-critical-quality/gateway-runtime-boundary`	Esquemas de protocolo de Gateway y contratos de métodos de servidor
`/codeql-critical-quality/channel-runtime-boundary`	Contratos de implementación de canales principales y Plugin de canal incluido
`/codeql-critical-quality/agent-runtime-boundary`	Ejecución de comandos, despacho de modelos/proveedores, despacho y colas de respuesta automática, y contratos de tiempo de ejecución del plano de control ACP
`/codeql-critical-quality/mcp-process-runtime-boundary`	Servidores MCP y puentes de herramientas, auxiliares de supervisión de procesos y contratos de entrega saliente
`/codeql-critical-quality/memory-runtime-boundary`	SDK de host de memoria, fachadas de tiempo de ejecución de memoria, alias del SDK de Plugin de memoria, enlace de activación del tiempo de ejecución de memoria y comandos doctor de memoria
`/codeql-critical-quality/network-runtime-boundary`	Paquete de política de red, tiempo de ejecución de socket sin procesar y captura de proxy, túnel SSH, bloqueo de gateway, socket JSONL y superficies de transporte push
`/codeql-critical-quality/session-diagnostics-boundary`	Internos de cola de respuestas, colas de entrega de sesiones, auxiliares de vinculación/entrega de sesiones salientes, superficies de eventos de diagnóstico/paquetes de logs y contratos CLI de doctor de sesiones
`/codeql-critical-quality/plugin-sdk-reply-runtime`	Despacho de respuestas entrantes del SDK de Plugin, auxiliares de carga útil/fragmentación/tiempo de ejecución de respuestas, opciones de respuesta de canal, colas de entrega y auxiliares de vinculación de sesión/hilo
`/codeql-critical-quality/provider-runtime-boundary`	Normalización del catálogo de modelos, autenticación y descubrimiento de proveedores, registro de tiempo de ejecución de proveedores, valores predeterminados/catálogos de proveedores y registros de web/búsqueda/obtención/embeddings
`/codeql-critical-quality/ui-control-plane`	Bootstrap de la interfaz de control, persistencia local, flujos de control de gateway y contratos de tiempo de ejecución del plano de control de tareas
`/codeql-critical-quality/web-media-runtime-boundary`	Obtención/búsqueda web principal, E/S de medios, comprensión de medios, generación de imágenes y contratos de tiempo de ejecución de generación de medios
`/codeql-critical-quality/plugin-boundary`	Contratos de cargador, registro, superficie pública y puntos de entrada del SDK de Plugin
`/codeql-critical-quality/plugin-sdk-package-contract`	Fuente publicada del SDK de Plugin del lado del paquete y auxiliares de contrato de paquete de Plugin

La calidad se mantiene separada de la seguridad para que los hallazgos de calidad puedan programarse, medirse, deshabilitarse o ampliarse sin ocultar la señal de seguridad. La expansión de CodeQL para Swift, Python y Plugin incluidos debe volver a agregarse como trabajo de seguimiento acotado o fragmentado solo después de que los perfiles estrechos tengan un tiempo de ejecución y una señal estables.

Flujos de mantenimiento

Agente de documentación

El flujo de trabajo Docs Agent es una vía de mantenimiento de Codex dirigida por eventos para mantener la documentación existente alineada con los cambios incorporados recientemente. No tiene una programación pura: una ejecución de CI correcta de un push no bot en main puede activarlo, y el despacho manual puede ejecutarlo directamente. Las invocaciones por workflow-run se omiten cuando main ya avanzó o cuando se creó otra ejecución no omitida de Docs Agent en la última hora. Cuando se ejecuta, revisa el rango de commits desde el SHA de origen del Docs Agent no omitido anterior hasta el main actual, de modo que una ejecución horaria puede cubrir todos los cambios de main acumulados desde la última pasada de documentación.

Agente de rendimiento de pruebas

El flujo de trabajo Test Performance Agent es una vía de mantenimiento de Codex dirigida por eventos para pruebas lentas. No tiene una programación pura: una ejecución de CI correcta de un push no bot en main puede activarlo, pero se omite si otra invocación por workflow-run ya se ejecutó o se está ejecutando ese día UTC. El despacho manual omite esa puerta de actividad diaria. La vía genera un informe de rendimiento de Vitest agrupado de la suite completa, permite que Codex haga solo pequeñas correcciones de rendimiento de pruebas que preserven la cobertura en lugar de refactorizaciones amplias, luego vuelve a ejecutar el informe de la suite completa y rechaza cambios que reduzcan el recuento base de pruebas aprobadas. El informe agrupado registra el tiempo de pared por configuración y el RSS máximo en Linux y macOS, por lo que la comparación antes/después muestra los deltas de memoria de pruebas junto a los deltas de duración. Si la línea base tiene pruebas fallidas, Codex puede corregir solo fallas obvias y el informe posterior del agente de la suite completa debe aprobar antes de que se confirme algo. Cuando main avanza antes de que llegue el push del bot, la vía rebasea el parche validado, vuelve a ejecutar pnpm check:changed y reintenta el push; los parches obsoletos con conflictos se omiten. Usa Ubuntu hospedado en GitHub para que la acción de Codex pueda mantener la misma postura de seguridad drop-sudo que el agente de documentación.

PR duplicados después de la fusión

El flujo de trabajo Duplicate PRs After Merge es un flujo manual de mantenedor para limpieza de duplicados posterior a la integración. Por defecto es dry-run y solo cierra PRs listados explícitamente cuando apply=true. Antes de modificar GitHub, verifica que el PR incorporado esté fusionado y que cada duplicado tenga un issue referenciado compartido o hunks modificados superpuestos.

gh workflow run duplicate-after-merge.yml \
  -f landed_pr=70532 \
  -f duplicate_prs='70530,70592' \
  -f apply=true

Puertas de comprobación locales y enrutamiento de cambios

La lógica local de carriles modificados vive en scripts/changed-lanes.mjs y la ejecuta scripts/check-changed.mjs. Esa puerta de comprobación local es más estricta sobre los límites de arquitectura que el alcance amplio de la plataforma de CI:

los cambios de producción del núcleo ejecutan typecheck de producción del núcleo y de pruebas del núcleo, más lint/guards del núcleo;
los cambios solo de pruebas del núcleo ejecutan solo typecheck de pruebas del núcleo más lint del núcleo;
los cambios de producción de extensiones ejecutan typecheck de producción de extensiones y de pruebas de extensiones, más lint de extensiones;
los cambios solo de pruebas de extensiones ejecutan typecheck de pruebas de extensiones más lint de extensiones;
los cambios públicos del SDK de Plugin o de contratos de Plugin se expanden al typecheck de extensiones porque las extensiones dependen de esos contratos del núcleo (los barridos de extensiones de Vitest siguen siendo trabajo de pruebas explícito);
los incrementos de versión solo de metadatos de lanzamiento ejecutan comprobaciones dirigidas de versión/configuración/dependencias raíz;
los cambios raíz/configuración desconocidos fallan de forma segura hacia todos los carriles de comprobación.

El enrutamiento local de pruebas modificadas vive en scripts/test-projects.test-support.mjs y es intencionalmente más barato que check:changed: las ediciones directas de pruebas se ejecutan a sí mismas, las ediciones de código fuente prefieren mapeos explícitos, luego pruebas hermanas y dependientes del grafo de importación. La configuración compartida de entrega de salas de grupo es uno de los mapeos explícitos: los cambios en la configuración de respuesta visible del grupo, el modo de entrega de respuestas de origen o el prompt del sistema de la herramienta de mensajes pasan por las pruebas principales de respuesta más regresiones de entrega de Discord y Slack, para que un cambio de valor predeterminado compartido falle antes del primer push del PR. Usa OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed solo cuando el cambio sea lo bastante amplio en el arnés como para que el conjunto mapeado barato no sea un proxy confiable.

Validación de Testbox

Crabbox es el envoltorio de caja remota propio del repositorio para pruebas de mantenedor en Linux. Las sesiones de agente lo usan por defecto para pruebas y trabajo computacionalmente intensivo, incluidas compilaciones, typechecks, fan-out de lint, Docker, carriles de paquetes, E2E, prueba en vivo y paridad con CI. El código de mantenedor confiable usa por defecto blacksmith-testbox, y .crabbox.yaml ahora lo usa por defecto. Su flujo configurado hidrata credenciales de proveedores y agentes, por lo que el código de contribuidor no confiable o de forks debe usar CI de fork sin secretos o Crabbox de AWS directo y sanitizado en su lugar. Las ejecuciones de AWS sanitizadas establecen CRABBOX_ENV_ALLOW=CI, pasan --no-hydrate y usan un HOME remoto temporal nuevo; esto evita que la allowlist OPENCLAW_* del repositorio y los perfiles de autenticación existentes lleguen a código no confiable. Usan un lease recién calentado dedicado a esa fuente no confiable, nunca un lease confiable o previamente hidratado. Lanza un binario Crabbox confiable instalado desde un checkout limpio y confiable de main y obtén solo el PR remoto con --fresh-pr; nunca ejecutes localmente el wrapper o la configuración del checkout no confiable. Desconfigura CRABBOX_AWS_INSTANCE_PROFILE y falla cerrado a menos que el aws.instanceProfile resuelto esté vacío. Antes de cualquier instalación/prueba, usa herramientas confiables de ruta absoluta para requerir un token IMDSv2, demostrar que el endpoint de credenciales IAM devuelve 404 y comparar el git rev-parse HEAD remoto con el SHA completo del head del PR revisado. Vincula el lease a ese SHA y detén/recalienta ante un cambio de head. Sube scripts/crabbox-untrusted-bootstrap.sh confiable desde main limpio junto con --fresh-pr; instala Node/pnpm fijados, verifica el SHA y el pin del package manager, aísla HOME, instala dependencias y luego ejecuta la prueba solicitada. Desconfigura todas las anulaciones CRABBOX_TAILSCALE*, fuerza --network public --tailscale=false, borra flags de exit-node/LAN y exige que crabbox inspect informe red pública sin estado de Tailscale antes de subir cualquier script. La capacidad propia de AWS/Hetzner también sigue siendo el fallback para caídas de Blacksmith, problemas de cuota o pruebas explícitas con capacidad propia. Al inicio de una tarea de código confiable que probablemente necesite pruebas o prueba pesada, los agentes deben precalentar de inmediato en una sesión de comandos en segundo plano, continuar la inspección y edición mientras se ejecuta la hidratación, reutilizar el id tbx_... devuelto, sincronizar el checkout actual en cada ejecución y detenerlo antes del traspaso:

node scripts/crabbox-wrapper.mjs warmup --provider blacksmith-testbox --keep --timing-json

Las ejecuciones de Blacksmith respaldadas por Crabbox calientan, reclaman, sincronizan, ejecutan, informan y limpian Testboxes de un solo uso. La comprobación de cordura de sincronización integrada falla rápido cuando git status --short en la caja sincronizada muestra al menos 200 eliminaciones rastreadas, lo que detecta archivos raíz desaparecidos como pnpm-lock.yaml. Para PRs intencionales con grandes eliminaciones, establece CRABBOX_ALLOW_MASS_DELETIONS=1 para el comando remoto. Crabbox también termina una invocación local de la CLI de Blacksmith que permanece en la fase de sincronización durante más de cinco minutos sin salida posterior a la sincronización. Establece CRABBOX_BLACKSMITH_SYNC_TIMEOUT_MS=0 para deshabilitar esa guarda, o usa un valor mayor en milisegundos para diffs locales inusualmente grandes. Antes de una primera ejecución, comprueba el wrapper desde la raíz del repositorio:

pnpm crabbox:run -- --help | sed -n '1,120p'

El wrapper del repositorio rechaza un binario Crabbox obsoleto que no anuncie el proveedor seleccionado, y las ejecuciones respaldadas por Blacksmith requieren Crabbox 0.22.0 o más reciente para que el wrapper obtenga el comportamiento actual de sincronización, cola y limpieza de Testbox. En worktrees de Codex o checkouts enlazados/dispersos, evita el script local pnpm crabbox:run porque pnpm puede reconciliar dependencias antes de que Crabbox inicie; invoca directamente el wrapper de node en su lugar:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --timing-json --shell -- "pnpm test <path-or-filter>"

Cuando uses el checkout hermano, recompila el binario local ignorado antes del trabajo de medición o prueba:

version="$(git -C ../crabbox describe --tags --always --dirty | sed 's/^v//')" \
  && go build -C ../crabbox -trimpath -ldflags "-s -w -X github.com/openclaw/crabbox/internal/cli.version=${version}" -o bin/crabbox ./cmd/crabbox

El bloque blacksmith: en .crabbox.yaml ya fija los valores predeterminados de org, workflow, job y ref, por lo que las marcas explícitas siguientes son opcionales. Puerta de cambios:

pnpm crabbox:run -- --provider blacksmith-testbox \
  --blacksmith-org openclaw \
  --blacksmith-workflow .github/workflows/ci-check-testbox.yml \
  --blacksmith-job check \
  --blacksmith-ref main \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm check:changed"

Reejecución de prueba enfocada:

pnpm crabbox:run -- --provider blacksmith-testbox \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm test <path-or-filter>"

Suite completa:

pnpm crabbox:run -- --provider blacksmith-testbox \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm test"

Lee el resumen JSON final. Los campos útiles son provider, leaseId, syncDelegated, exitCode, commandMs y totalMs. Para ejecuciones delegadas de Blacksmith Testbox, el código de salida del envoltorio de Crabbox y el resumen JSON son el resultado del comando. La ejecución de GitHub Actions enlazada se encarga de la hidratación y del keepalive; puede terminar como cancelled cuando el Testbox se detiene externamente después de que el comando SSH ya haya devuelto el control. Trata eso como un artefacto de limpieza/estado, salvo que el exitCode del envoltorio sea distinto de cero o que la salida del comando muestre una prueba fallida. Las ejecuciones únicas de Crabbox respaldadas por Blacksmith deberían detener el Testbox automáticamente; si una ejecución se interrumpe o la limpieza no está clara, inspecciona las cajas activas y detén solo las cajas que creaste:

blacksmith testbox list --all
blacksmith testbox status --id <tbx_id>
blacksmith testbox stop --id <tbx_id>

Usa la reutilización solo cuando necesites intencionadamente varios comandos en la misma caja hidratada:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --id <tbx_id> --timing-json --shell -- "corepack pnpm test <path-or-filter>"
pnpm crabbox:stop -- <tbx_id>

Reutiliza el arrendamiento, no una fuente obsoleta. Omite --no-sync para que cada ejecución cargue el checkout actual; úsalo solo para volver a ejecutar intencionalmente un árbol sin cambios y ya sincronizado. El código de colaboradores o forks no confiables debe usar CRABBOX_ENV_ALLOW=CI, --provider aws --no-hydrate y un HOME remoto temporal nuevo para cada comando; instala las dependencias dentro de ese comando saneado antes de probar. Reutiliza solo un arrendamiento recién preparado dedicado a la misma fuente no confiable; nunca un arrendamiento confiable o previamente hidratado. Nunca ejecutes localmente el wrapper ni la configuración del checkout no confiable: inicia el binario Crabbox confiable instalado desde un main confiable limpio y pasa --fresh-pr en cada ejecución. Mantén CRABBOX_AWS_INSTANCE_PROFILE sin definir, rechaza un perfil de instancia resuelto que no esté vacío, exige una prueba IMDS remota confiable sin rol y verifica el SHA del encabezado revisado antes de instalar/probar. Vincula el arrendamiento a ese SHA; detén y vuelve a preparar después de cualquier cambio de encabezado. Si no existe un PR remoto, usa CI de fork sin secretos. Nunca selecciones hydrate-github ni el flujo de trabajo Blacksmith hidratado con credenciales para una fuente no confiable. Si Crabbox es la capa rota pero Blacksmith en sí funciona, usa Blacksmith directo solo para diagnósticos como list, status y limpieza. Corrige la ruta de Crabbox antes de tratar una ejecución directa de Blacksmith como prueba de mantenedor. Si blacksmith testbox list --all y blacksmith testbox status funcionan, pero las nuevas preparaciones quedan en queued sin IP ni URL de ejecución de Actions después de un par de minutos, trátalo como presión del proveedor Blacksmith, cola, facturación o límite de organización. Detén los ids en cola que creaste, evita iniciar más Testboxes y mueve la prueba a la ruta de capacidad Crabbox propia que aparece abajo mientras alguien revisa el panel de Blacksmith, la facturación y los límites de la organización. Escala a capacidad Crabbox propia solo cuando Blacksmith esté caído, limitado por cuota, no tenga el entorno necesario o la capacidad propia sea explícitamente el objetivo:

CRABBOX_CAPACITY_REGIONS=eu-west-1,eu-west-2,eu-central-1,us-east-1,us-west-2 \
  pnpm crabbox:warmup -- --provider aws --class standard --market on-demand --idle-timeout 90m
pnpm crabbox:hydrate -- --provider aws --id <cbx_id-or-slug>
pnpm crabbox:run -- --provider aws --id <cbx_id-or-slug> --timing-json --shell -- "pnpm check:changed"
pnpm crabbox:stop -- --provider aws <cbx_id-or-slug>

Bajo presión de AWS, evita class=beast a menos que la tarea realmente necesite CPU de clase 48xlarge. Una solicitud beast comienza en 192 vCPU y es la forma más fácil de activar la cuota regional de EC2 Spot o Standard On-Demand. El .crabbox.yaml propiedad del repositorio usa de forma predeterminada class: standard, mercado on-demand y capacity.hints: true, de modo que los arrendamientos AWS intermediados imprimen la región/mercado seleccionados, presión de cuota, fallback Spot y advertencias de clase de alta presión. Usa fast para comprobaciones amplias más pesadas, large solo después de que standard/fast no sean suficientes y beast solo para lanes excepcionales dependientes de CPU, como matrices Docker de suite completa o todos los plugins, validación explícita de release/bloqueador o perfilado de rendimiento con muchos núcleos. No uses beast para pnpm check:changed, pruebas enfocadas, trabajo solo de documentación, lint/typecheck ordinarios, pequeñas reproducciones E2E ni triaje de caída de Blacksmith. Usa --market on-demand para el diagnóstico de capacidad, de modo que la volatilidad del mercado Spot no se mezcle en la señal. .crabbox.yaml controla los valores predeterminados de proveedor, sincronización e hidratación de GitHub Actions. La sincronización de Crabbox nunca transfiere .git, por lo que el checkout hidratado de Actions conserva sus propios metadatos Git remotos en lugar de sincronizar remotos y almacenes de objetos locales del mantenedor, y la configuración del repositorio además excluye artefactos locales de runtime/compilación (como .artifacts e informes de prueba) que nunca deben transferirse. .github/workflows/crabbox-hydrate.yml controla el checkout, la configuración de Node/pnpm, la recuperación de origin/main y el traspaso del entorno sin secretos para comandos crabbox run --id <cbx_id> en nube propia.

​Resumen de la canalización

​Orden de fallo rápido

​Contexto y evidencia de PR

​Alcance y enrutamiento

​Reenvío de actividad de ClawSweeper

​Despachos manuales

​Ejecutores

​Presupuesto de registro de ejecutores

​Equivalentes locales

​Rendimiento de OpenClaw

​Validación completa de release

​Shards live y E2E

​Aceptación de paquetes

​Trabajos

​Fuentes candidatas

​Perfiles de suite

​Ventanas de compatibilidad heredada

​Ejemplos

​Smoke de instalación

​Docker E2E local

​Ajustables

​Workflow reutilizable en vivo/E2E

​Fragmentos de la ruta de lanzamiento

​Prelanzamiento de Plugin

​QA Lab

​CodeQL

​Categorías de seguridad

​Fragmentos de seguridad específicos de plataforma

​Categorías de calidad crítica

​Flujos de mantenimiento

​Agente de documentación

​Agente de rendimiento de pruebas

​PR duplicados después de la fusión

​Puertas de comprobación locales y enrutamiento de cambios

​Validación de Testbox

​Relacionado