Política de versiones

OpenClaw actualmente expone tres canales de actualización orientados al usuario:

stable: el canal de versiones promocionadas existente, que todavía se resuelve mediante npm latest hasta que llegue el hito independiente de CLI/canal
beta: etiquetas de versión preliminar que se publican en npm beta
dev: la cabecera móvil de main

Por separado, los operadores de lanzamiento pueden publicar en npm extended-stable el paquete core del último mes completado, a partir del parche 33. La línea final regular del mes actual continúa en npm latest; esta división de publicación del lado del operador no cambia por sí sola la resolución de canales de actualización de la CLI. Las compilaciones alfa de Tideclaw son una pista interna separada de versiones preliminares (dist-tag de npm alpha), cubierta en entradas del flujo de trabajo de NPM y cajas de prueba de lanzamiento.

Nomenclatura de versiones

Versión mensual de lanzamiento extended-stable de npm: YYYY.M.PATCH, con PATCH >= 33, etiqueta git vYYYY.M.PATCH
Versión diaria/regular final de lanzamiento: YYYY.M.PATCH, con PATCH < 33, etiqueta git vYYYY.M.PATCH
Versión regular de lanzamiento de corrección de respaldo: YYYY.M.PATCH-N, etiqueta git vYYYY.M.PATCH-N
Versión preliminar beta: YYYY.M.PATCH-beta.N, etiqueta git vYYYY.M.PATCH-beta.N
Versión preliminar alfa: YYYY.M.PATCH-alpha.N, etiqueta git vYYYY.M.PATCH-alpha.N
Nunca rellenes con ceros el mes ni el parche
PATCH es un número secuencial mensual del tren de lanzamientos, no un día calendario. Las versiones finales regulares y beta avanzan el tren actual; las etiquetas solo alfa nunca consumen ni avanzan el número de parche beta/regular, así que ignora las etiquetas heredadas solo alfa con números de parche mayores al seleccionar un tren beta o regular.
Las compilaciones alfa/nocturnas usan el siguiente tren de parches no publicado e incrementan solo alpha.N para compilaciones repetidas. Una vez que ese parche tiene una beta, las nuevas compilaciones alfa pasan al parche siguiente.
Las versiones de npm son inmutables: nunca elimines, vuelvas a publicar ni reutilices una etiqueta publicada. Corta el siguiente número de versión preliminar o el siguiente parche mensual en su lugar.
latest continúa siguiendo la línea npm regular/diaria actual; beta es el destino de instalación beta actual
extended-stable significa el paquete npm compatible del mes anterior, a partir del parche 33; el parche 34 y posteriores son lanzamientos de mantenimiento en esa línea mensual
Las versiones finales regulares y las correcciones regulares se publican en npm beta de forma predeterminada; los operadores de lanzamiento pueden apuntar explícitamente a latest o promocionar más tarde una compilación beta validada
La ruta mensual dedicada extended-stable publica el paquete core de npm y cada Plugin oficial publicable en npm en la misma versión exacta. No publica plugins en ClawHub ni publica artefactos de macOS o Windows, una GitHub Release, dist-tags de repositorios privados, imágenes Docker, artefactos móviles ni descargas del sitio web.
Cada versión final regular entrega conjuntamente el paquete npm, la app macOS y los instaladores firmados de Windows Hub. Las versiones beta normalmente validan y publican primero la ruta npm/paquete, con la compilación/firma/notarización/promoción de apps nativas reservada para la versión final regular salvo que se solicite explícitamente.

Cadencia de lanzamientos

Los lanzamientos avanzan primero por beta; stable sigue solo después de validar la beta más reciente
Los mantenedores normalmente cortan lanzamientos desde una rama release/YYYY.M.PATCH creada desde el main actual, para que la validación y las correcciones del lanzamiento no bloqueen el nuevo desarrollo en main
Si una etiqueta beta se ha subido o publicado y necesita una corrección, los mantenedores cortan la siguiente etiqueta -beta.N en lugar de eliminar o recrear la anterior
El procedimiento detallado de lanzamiento, aprobaciones, credenciales y notas de recuperación son solo para mantenedores

Publicación mensual extended-stable solo de npm

Esta es una excepción dedicada al procedimiento regular de lanzamiento que aparece abajo. Para un mes completado YYYY.M, crea extended-stable/YYYY.M.33; publica vYYYY.M.33 y parches de mantenimiento posteriores desde esa misma rama. La etiqueta de lanzamiento, la punta de la rama, el checkout, la versión del paquete, la preflight de npm y la ejecución de Full Release Validation deben identificar todos el mismo commit. El main protegido ya debe contener la versión final de un mes calendario estrictamente posterior por debajo del parche 33; los parches de mantenimiento siguen siendo elegibles después de que main avance más de un mes. En la rama exacta extended-stable, sube el paquete raíz a YYYY.M.P, ejecuta pnpm release:prep y verifica que cada paquete de extensión publicable tenga la misma versión. Haz commit y push de todos los cambios generados, crea y sube la etiqueta inmutable vYYYY.M.P en ese commit, y registra el SHA completo resultante. Los flujos de trabajo consumen este árbol preparado; no suben ni sincronizan versiones por ti. Ejecuta la preflight de npm y Full Release Validation desde esa punta exacta de la rama preparada, luego guarda ambos ID de ejecución:

gh workflow run openclaw-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f tag=vYYYY.M.P \
  -f preflight_only=true \
  -f npm_dist_tag=extended-stable

gh workflow run full-release-validation.yml \
  --ref extended-stable/YYYY.M.33 \
  -f ref=extended-stable/YYYY.M.33 \
  -f release_profile=stable

release_profile=stable es el perfil existente de profundidad de validación; es independiente del dist-tag de npm extended-stable y se mantiene intencionalmente sin cambios. Después de que ambas ejecuciones tengan éxito, publica cada Plugin oficial publicable en npm desde la misma punta exacta de la rama. El parche P debe ser 33 o mayor. Pasa el SHA completo del lanzamiento como ref, espera la matriz completa y la lectura del registro, y luego guarda el ID de ejecución exitoso de Plugin NPM Release:

RELEASE_SHA="$(git rev-parse HEAD)"
gh workflow run plugin-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f publish_scope=all-publishable \
  -f ref="$RELEASE_SHA" \
  -f npm_dist_tag=extended-stable

El flujo de trabajo usa el inventario regular preparado de paquetes all-publishable, incluidos los paquetes cuyo código fuente no cambió. Verifica cada paquete exacto y cada etiqueta de Plugin extended-stable antes de tener éxito. Si falla una ejecución parcial, vuelve a ejecutar el mismo comando: los paquetes ya publicados se reutilizan, las etiquetas de Plugin faltantes o obsoletas se concilian bajo el entorno de lanzamiento de npm, y la lectura final todavía cubre el conjunto completo de paquetes. Después de que el flujo de trabajo de plugins tenga éxito y el entorno de lanzamiento de npm esté listo, publica el tarball exacto de preflight del core. La publicación del core verifica que la ejecución de plugins referenciada esté completed/success en la misma rama canónica y el SHA exacto de origen:

gh workflow run openclaw-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f tag=vYYYY.M.P \
  -f preflight_only=false \
  -f npm_dist_tag=extended-stable \
  -f preflight_run_id=<npm-preflight-run-id> \
  -f full_release_validation_run_id=<full-validation-run-id> \
  -f plugin_npm_run_id=<plugin-npm-run-id>

Para un fork o ensayo no productivo que intencionalmente no pueda satisfacer la política mensual .33 o de mes de main protegido, añade -f bypass_extended_stable_guard=true tanto a los dispatches de preflight como de publicación de npm. El valor predeterminado es false. El bypass solo se acepta con npm_dist_tag=extended-stable y se registra en el resumen del flujo de trabajo. No omite la ref canónica del flujo de trabajo extended-stable/YYYY.M.33, la igualdad de punta de rama/etiqueta/checkout, la sintaxis de etiqueta final, la igualdad de versión de paquete/etiqueta, la identidad de ejecución y manifiesto referenciada, la procedencia del tarball, la aprobación del entorno, la lectura del registro ni la evidencia de reparación de selector. El flujo de trabajo de publicación verifica las identidades de las ejecuciones referenciadas de preflight, validación y plugins, el digest del tarball preparado y los selectores del registro core. Confirma independientemente el resultado después de que el flujo de trabajo tenga éxito:

npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"
npm view openclaw@extended-stable version --userconfig "$(mktemp)"

Ambos comandos deben devolver YYYY.M.P. Si la publicación tiene éxito pero falla la lectura del selector, no vuelvas a publicar la versión inmutable del paquete. Usa el único comando de reparación npm dist-tag add openclaw@YYYY.M.P extended-stable impreso en el resumen always-run del flujo de trabajo fallido, y luego repite ambas lecturas independientes. Revertir al selector anterior es una decisión de operador separada, no la ruta de reparación de lectura. La documentación de soporte pública designa inicialmente Slack, Discord y Codex como superficies de Plugin cubiertas por extended-stable. Esa lista es una declaración de soporte, no una lista de permitidos del código de lanzamiento: cada Plugin oficial publicable en npm sigue la misma ruta de publicación de versión exacta. La lista de comprobación regular de abajo sigue siendo dueña de beta, latest, GitHub Release, plugins, macOS, Windows y otras publicaciones de plataforma. No ejecutes esos pasos para esta ruta extended-stable solo de npm.

Lista de comprobación regular para operadores de lanzamiento

Esta lista de comprobación es la forma pública del flujo de lanzamiento. Las credenciales privadas, la firma, la notarización, la recuperación de dist-tags y los detalles de reversión de emergencia permanecen en el runbook de lanzamiento solo para mantenedores.

Empieza desde el main actual: trae lo último, confirma que el commit objetivo se haya subido y confirma que la CI de main esté lo suficientemente verde para crear una rama desde ahí.
Genera la sección superior de CHANGELOG.md a partir de los PR fusionados y todos los commits directos desde la última etiqueta de lanzamiento alcanzable. Mantén las entradas orientadas al usuario, elimina duplicados entre entradas solapadas de PR/commit directo, haz commit, sube los cambios y vuelve a hacer rebase/pull una vez más antes de crear la rama.
Revisa los registros de compatibilidad de lanzamiento en src/plugins/compat/registry.ts y src/commands/doctor/shared/deprecation-compat.ts. Elimina la compatibilidad vencida solo cuando la ruta de actualización siga cubierta, o registra por qué se conserva intencionalmente.
Crea release/YYYY.M.PATCH desde el main actual. No hagas trabajo normal de lanzamiento directamente en main.
Sube cada ubicación de versión requerida para la etiqueta y luego ejecuta pnpm release:prep. Esto actualiza en orden versiones de plugins, shrinkwraps de npm, inventario de plugins, esquema de configuración base, metadatos de configuración de canales incluidos, línea base de documentos de configuración, exportaciones del SDK de Plugin y línea base de API del SDK de Plugin. Haz commit de cualquier deriva generada antes de etiquetar, luego ejecuta la preflight determinista local: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build y pnpm release:check.
Ejecuta OpenClaw NPM Release con preflight_only=true. Antes de que exista una etiqueta, se permite un SHA completo de 40 caracteres de la rama de lanzamiento para preflight solo de validación. La preflight genera evidencia de lanzamiento de dependencias para el grafo exacto de dependencias en checkout y la almacena en el artefacto de preflight de npm. Guarda el preflight_run_id exitoso.
Inicia todas las pruebas previas al lanzamiento con Full Release Validation para la rama de lanzamiento, etiqueta o SHA completo de commit. Este es el único punto de entrada manual para las cuatro grandes cajas de prueba de lanzamiento: Vitest, Docker, QA Lab y Package. Guarda el full_release_validation_run_id; es una entrada requerida tanto para OpenClaw NPM Release como para OpenClaw Release Publish.
Si la validación falla, corrige en la rama de lanzamiento y vuelve a ejecutar el archivo, lane, job de flujo de trabajo, perfil de paquete, proveedor o lista de permitidos de modelo fallidos más pequeños que prueben la corrección. Vuelve a ejecutar el paraguas completo solo cuando la superficie cambiada haga obsoleta la evidencia previa.
Para un candidato beta etiquetado, ejecuta pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N desde la rama release/YYYY.M.PATCH correspondiente. Para stable, pasa también el lanzamiento fuente requerido de Windows: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z. El helper ejecuta las comprobaciones locales de lanzamiento generado, despacha o verifica la evidencia de validación completa de lanzamiento y preflight de npm, ejecuta prueba fresca/de actualización de Parallels contra el tarball exacto preparado más prueba del paquete de Telegram, registra planes de npm de plugins y ClawHub, e imprime el comando exacto OpenClaw Release Publish solo después de que el paquete de evidencia esté verde. OpenClaw Release Publish despacha los paquetes de plugins seleccionados o todos los publicables a npm y el mismo conjunto a ClawHub en paralelo; luego promociona el artefacto de preflight de npm de OpenClaw preparado con la dist-tag correspondiente una vez que la publicación de plugins en npm se realiza correctamente. Después de que el proceso hijo de publicación de OpenClaw en npm se realiza correctamente, crea o actualiza la página de lanzamiento/prelanzamiento de GitHub correspondiente desde la sección completa coincidente de CHANGELOG.md: los lanzamientos estables publicados en npm latest pasan a ser el lanzamiento más reciente de GitHub, y los lanzamientos estables de mantenimiento mantenidos en npm beta se crean con GitHub latest=false. El workflow también sube al lanzamiento de GitHub la evidencia de dependencias de preflight, el manifiesto de validación completa y la evidencia de verificación del registro posterior a la publicación para la respuesta a incidentes posterior al lanzamiento. Imprime los ID de ejecución de procesos hijos inmediatamente, aprueba automáticamente las compuertas de entorno de lanzamiento que el token del workflow tiene permiso para aprobar, resume los trabajos hijos fallidos con los finales de registros, cierra el lanzamiento de GitHub y la evidencia de dependencias en cuanto la publicación de OpenClaw en npm se realiza correctamente, espera a ClawHub siempre que OpenClaw se esté publicando en npm, luego ejecuta pnpm release:verify-beta y sube evidencia posterior a la publicación para el lanzamiento de GitHub, el paquete npm, los paquetes npm de plugins seleccionados, los paquetes de ClawHub seleccionados, los ID de ejecución de workflows hijos y el ID opcional de ejecución NPM Telegram. La ruta de ClawHub reintenta fallos transitorios de instalación de dependencias de la CLI, publica plugins que superan la vista previa incluso cuando una celda de vista previa falla de forma intermitente, y termina con verificación del registro para cada versión esperada de Plugin, de modo que las publicaciones parciales permanezcan visibles y reintentables. Luego ejecuta la aceptación de paquetes posterior a la publicación contra el paquete publicado openclaw@YYYY.M.PATCH-beta.N u openclaw@beta. Si un prelanzamiento enviado o publicado necesita una corrección, crea el siguiente número de prelanzamiento correspondiente; nunca elimines ni reescribas el anterior.
Para estable, continúa solo después de que la beta o candidata de lanzamiento evaluada tenga la evidencia de validación requerida. La publicación estable en npm también pasa por OpenClaw Release Publish, reutilizando el artefacto de preflight exitoso mediante preflight_run_id. La preparación del lanzamiento estable de macOS también requiere los .zip, .dmg, .dSYM.zip empaquetados y el appcast.xml actualizado en main; el workflow de publicación de macOS publica el appcast firmado en main público automáticamente después de verificar los recursos del lanzamiento, o abre/actualiza un PR de appcast si la protección de rama bloquea el envío directo. La preparación estable de Windows Hub requiere los recursos firmados OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe y OpenClawCompanion-SHA256SUMS.txt en el lanzamiento de GitHub de OpenClaw. Pasa la etiqueta exacta de lanzamiento firmada de openclaw/openclaw-windows-node como windows_node_tag y su mapa de resúmenes de instaladores aprobado como candidato como windows_node_installer_digests; OpenClaw Release Publish mantiene el borrador de lanzamiento, despacha Windows Node Release y verifica los tres recursos antes de la publicación.
Después de publicar, ejecuta el verificador posterior a la publicación de npm, el E2E opcional independiente de Telegram con npm publicado cuando necesites prueba de canal posterior a la publicación, la promoción de dist-tag cuando sea necesario, verifica la página de lanzamiento de GitHub generada, ejecuta los pasos de anuncio de lanzamiento y luego completa Cierre estable de main antes de considerar terminado un lanzamiento estable.

Cierre estable de main

La publicación estable no está completa hasta que main contiene el estado real del lanzamiento enviado.

Comienza desde el main más reciente y limpio. Audita release/YYYY.M.PATCH contra él y aplica hacia adelante las correcciones reales ausentes de main. No fusiones a ciegas adaptadores de compatibilidad, pruebas o validación exclusivos del lanzamiento en el main más nuevo.
Establece main en la versión estable enviada, no en un tren siguiente especulativo. Ejecuta pnpm release:prep después del cambio de versión raíz y luego pnpm deps:shrinkwrap:generate.
Haz que la sección ## YYYY.M.PATCH de CHANGELOG.md en main coincida exactamente con la rama de lanzamiento etiquetada. Incluye la actualización estable de appcast.xml cuando el lanzamiento de mac la haya publicado.
No agregues YYYY.M.PATCH+1, una versión beta ni una sección vacía de changelog futuro a main hasta que el operador inicie explícitamente ese tren de lanzamiento.
Ejecuta pnpm release:generated:check, pnpm deps:shrinkwrap:check y OPENCLAW_TESTBOX=1 pnpm check:changed. Envía los cambios y luego verifica que origin/main contenga la versión enviada y el changelog antes de dar por terminado el lanzamiento estable.
Mantén actualizadas las variables del repositorio RELEASE_ROLLBACK_DRILL_ID y RELEASE_ROLLBACK_DRILL_DATE después de cada simulacro privado de reversión.

OpenClaw Stable Main Closeout comienza desde el push a main que contiene la versión enviada, el changelog y el appcast después de la publicación estable. Lee evidencia inmutable posterior a la publicación para vincular la etiqueta enviada con sus ejecuciones de Validación completa de lanzamiento y Publicación, y luego verifica el estado estable de main, el lanzamiento, la espera estable obligatoria y la evidencia de rendimiento bloqueante. Adjunta al lanzamiento de GitHub un manifiesto de cierre inmutable y una suma de comprobación. El disparador automático por push omite lanzamientos heredados anteriores a la evidencia inmutable posterior a la publicación y nunca trata esa omisión como un cierre completado. Un cierre completo requiere tanto recursos como una suma de comprobación coincidente. Un manifiesto parcial reproduce su SHA de main registrado y el simulacro de reversión para regenerar bytes idénticos, y luego adjunta la suma de comprobación faltante; un par inválido, o una suma de comprobación sin manifiesto, sigue siendo bloqueante. Una ejecución disparada por push sin variables de repositorio de simulacro de reversión se omite sin completar el cierre; un registro de simulacro faltante o con más de 90 días de antigüedad sigue bloqueando el cierre manual respaldado por evidencia. Los comandos privados de recuperación permanecen en el runbook solo para mantenedores. Usa el despacho manual solo para reparar o reproducir un cierre estable respaldado por evidencia. Una etiqueta de corrección de fallback heredada puede reutilizar evidencia del paquete base solo cuando la etiqueta de corrección se resuelve al mismo commit de origen que la etiqueta estable base. Una corrección con origen diferente debe publicar y verificar su propia evidencia de paquete.

Preflight de lanzamiento

Ejecuta pnpm check:test-types antes del preflight de lanzamiento para que el TypeScript de pruebas permanezca cubierto fuera de la compuerta local más rápida de pnpm check.
Ejecuta pnpm check:architecture antes del preflight de lanzamiento para que las comprobaciones más amplias de ciclos de importación y límites de arquitectura estén en verde fuera de la compuerta local más rápida.
Ejecuta pnpm build && pnpm ui:build antes de pnpm release:check para que los artefactos de lanzamiento esperados de dist/* y el paquete de Control UI existan para el paso de validación de empaquetado.
Ejecuta pnpm release:prep después del incremento de versión raíz y antes de etiquetar. Ejecuta todos los generadores deterministas de lanzamiento que suelen desviarse después de un cambio de versión/configuración/API: versiones de plugins, shrinkwraps de npm, inventario de plugins, esquema de configuración base, metadatos de configuración de canales incluidos, línea base de documentación de configuración, exportaciones del SDK de plugins y línea base de API del SDK de plugins. pnpm release:check vuelve a ejecutar esas guardas en modo de comprobación (más una comprobación de presupuesto de superficie del SDK de plugins) e informa todos los fallos de desviación generada en una sola pasada antes de ejecutar las comprobaciones de lanzamiento de paquetes.
La sincronización de versiones de plugins actualiza el paquete publicable de runtime @openclaw/ai, las versiones de paquetes de plugins oficiales y los pisos existentes de openclaw.compat.pluginApi a la versión de lanzamiento de OpenClaw de forma predeterminada. Trata ese campo como el piso de API del SDK/runtime de plugins, no solo como una copia de la versión del paquete: para lanzamientos solo de plugins que intencionalmente siguen siendo compatibles con hosts de OpenClaw más antiguos, mantén el piso en la API de host compatible más antigua y documenta esa decisión en la prueba de lanzamiento del Plugin.
Ejecuta el workflow manual Full Release Validation antes de la aprobación de lanzamiento para iniciar todos los test boxes previos al lanzamiento desde un único punto de entrada. Acepta una rama, etiqueta o SHA completo de commit, despacha CI manual y despacha OpenClaw Release Checks para smoke de instalación, aceptación de paquetes, comprobaciones de paquetes entre sistemas operativos, paridad de QA Lab, Matrix y carriles de Telegram. Las ejecuciones estables y completas siempre incluyen live/E2E exhaustivo y espera de ruta de lanzamiento Docker; run_release_soak=true se conserva para una espera beta explícita. Package Acceptance proporciona el E2E canónico de Telegram de paquete durante la validación de candidatos, evitando un segundo sondeador live concurrente. Proporciona release_package_spec después de publicar una beta para reutilizar el paquete npm enviado entre las comprobaciones de lanzamiento, Package Acceptance y el E2E de Telegram de paquete sin reconstruir el tarball de lanzamiento. Proporciona npm_telegram_package_spec solo cuando Telegram deba usar un paquete publicado diferente del resto de la validación de lanzamiento. Proporciona package_acceptance_package_spec cuando Package Acceptance deba usar un paquete publicado diferente de la especificación de paquete de lanzamiento. Proporciona evidence_package_spec cuando el informe de evidencia de lanzamiento deba probar que la validación coincide con un paquete npm publicado sin forzar E2E de Telegram.
```
gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.PATCH
```
Ejecuta el workflow manual Package Acceptance cuando quieras prueba por canal lateral para un candidato de paquete mientras continúa el trabajo de lanzamiento. Usa source=npm para openclaw@beta, openclaw@latest o una versión exacta de lanzamiento; source=ref para empaquetar una rama/etiqueta/SHA confiable de package_ref con el arnés actual de workflow_ref; source=url para un tarball HTTPS público con un SHA-256 requerido y política estricta de URL pública; source=trusted-url para una política de origen confiable con nombre usando trusted_source_id y SHA-256 requeridos; o source=artifact para un tarball subido por otra ejecución de GitHub Actions. El workflow resuelve el candidato a package-under-test, reutiliza el programador de lanzamiento Docker E2E contra ese tarball y puede ejecutar QA de Telegram contra el mismo tarball con telegram_mode=mock-openai o telegram_mode=live-frontier. Cuando los carriles Docker seleccionados incluyen published-upgrade-survivor, el artefacto de paquete es el candidato y published_upgrade_survivor_baseline selecciona la línea base publicada. update-restart-auth usa el paquete candidato tanto como CLI instalada como package-under-test, de modo que ejercita la ruta de reinicio gestionado del comando de actualización del candidato. Ejemplo:
```
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 published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai
```
Perfiles comunes:
- smoke: carriles de instalación/canal/agente, red de gateway y recarga de configuración
- package: carriles nativos del artefacto para paquete/actualización/reinicio/Plugin sin OpenWebUI ni ClawHub live
- product: perfil de paquete más canales MCP, limpieza de cron/subagente, búsqueda web de OpenAI y OpenWebUI
- full: fragmentos de ruta de lanzamiento Docker con OpenWebUI
- custom: selección exacta de docker_lanes para una repetición enfocada
Ejecuta directamente el workflow manual CI cuando solo necesites cobertura normal determinista de CI para el candidato de lanzamiento. Los despachos manuales de CI omiten el alcance por cambios y fuerzan los shards de Linux Node, shards de plugins incluidos, shards de contratos de plugins y canales, compatibilidad con Node 22, check-*, check-additional-*, comprobaciones smoke de artefactos construidos, comprobaciones de documentación, Python skills, Windows, macOS y carriles de i18n de Control UI. Las ejecuciones manuales independientes de CI ejecutan Android solo cuando se despachan con include_android=true; Full Release Validation pasa esa entrada a su proceso hijo de CI.
```
gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
```
Ejecuta pnpm qa:otel:smoke al validar la telemetría de lanzamiento. Ejercita QA-lab mediante un receptor OTLP/HTTP local y verifica la exportación de trazas, métricas y registros, además de atributos de traza acotados y la censura de contenido/identificadores sin requerir Opik, Langfuse ni otro recopilador externo.
Ejecuta pnpm qa:otel:collector-smoke al validar la compatibilidad con recopiladores. Enruta la misma exportación OTLP de QA-lab a través de un contenedor Docker real de OpenTelemetry Collector antes de las aserciones del receptor local.
Ejecuta pnpm qa:prometheus:smoke al validar el scraping protegido de Prometheus. Ejercita QA-lab, rechaza scrapes no autenticados y verifica que las familias de métricas críticas para el lanzamiento no contengan contenido de prompts, identificadores sin procesar, tokens de autenticación ni rutas locales.
Ejecuta pnpm qa:observability:smoke para ejecutar consecutivamente las vías de smoke de OpenTelemetry y Prometheus desde un checkout de código fuente.
Ejecuta pnpm release:check antes de cada lanzamiento etiquetado.
La comprobación previa OpenClaw NPM Release genera evidencia de lanzamiento de dependencias antes de empaquetar el tarball de npm. La puerta de vulnerabilidades de avisos de npm bloquea el lanzamiento. Los informes de riesgo del manifiesto transitivo, superficie de propiedad/instalación de dependencias y cambios de dependencias son solo evidencia de lanzamiento. El informe de cambios de dependencias compara el candidato de lanzamiento con la etiqueta de lanzamiento alcanzable anterior. La comprobación previa sube la evidencia de dependencias como openclaw-release-dependency-evidence-<tag> y también la incrusta en dependency-evidence/ dentro del artefacto preparado de comprobación previa de npm. La ruta de publicación real reutiliza ese artefacto de comprobación previa y luego adjunta la misma evidencia al lanzamiento de GitHub como openclaw-<version>-dependency-evidence.zip.
Ejecuta OpenClaw Release Publish para la secuencia de publicación con mutaciones después de que exista la etiqueta. Dispáralo desde release/YYYY.M.PATCH (o main al publicar una etiqueta alcanzable desde main), pasa la etiqueta de lanzamiento, el preflight_run_id exitoso de npm de OpenClaw y el full_release_validation_run_id exitoso, y conserva el alcance predeterminado de publicación de plugins all-publishable salvo que estés ejecutando deliberadamente una reparación enfocada. El workflow serializa la publicación npm de plugins, la publicación de plugins en ClawHub y la publicación npm de OpenClaw para que el paquete core no se publique antes que sus plugins externalizados.
La publicación estable de OpenClaw Release Publish requiere un windows_node_tag exacto después de que exista el lanzamiento openclaw/openclaw-windows-node no preliminar correspondiente, además del mapa windows_node_installer_digests aprobado para el candidato. Antes de disparar cualquier hijo de publicación, verifica que ese lanzamiento fuente esté publicado, no sea preliminar, contenga los instaladores x64/ARM64 requeridos y siga coincidiendo con ese mapa aprobado. Luego dispara Windows Node Release mientras el lanzamiento de OpenClaw todavía es un borrador, llevando sin cambios el mapa fijado de resúmenes de instaladores. El workflow hijo descarga los instaladores firmados de Windows Hub desde esa etiqueta exacta, los compara con los resúmenes fijados, verifica en un runner de Windows que sus firmas Authenticode usen el firmante esperado OpenClaw Foundation, escribe un manifiesto SHA-256 y sube los instaladores y el manifiesto al lanzamiento canónico de GitHub de OpenClaw; después vuelve a descargar los activos promovidos y verifica la pertenencia al manifiesto y los hashes. El padre verifica el contrato actual de activos x64, ARM64 y de checksum antes de la publicación. La recuperación directa rechaza nombres de activos OpenClawCompanion-* inesperados antes de reemplazar los activos de contrato esperados con los bytes fuente fijados. Despacha manualmente Windows Node Release solo para recuperación, y pasa siempre una etiqueta exacta, nunca latest, además del mapa JSON explícito expected_installer_digests del lanzamiento fuente aprobado. Los enlaces de descarga del sitio web deben apuntar a URLs exactas de activos del lanzamiento de OpenClaw para el lanzamiento estable actual, o a releases/latest/download/... solo después de verificar que la redirección latest de GitHub apunte a ese mismo lanzamiento; no enlaces solo a la página de lanzamiento del repositorio companion.
Las comprobaciones de lanzamiento ahora se ejecutan en un workflow manual separado: OpenClaw Release Checks. También ejecuta la vía de paridad mock de QA Lab, además del perfil rápido Matrix en vivo y la vía QA de Telegram antes de la aprobación del lanzamiento. Las vías en vivo usan el entorno qa-live-shared; Telegram también usa leases de credenciales de CI de Convex. Ejecuta el workflow manual QA-Lab - All Lanes con matrix_profile=all y matrix_shards=true cuando quieras el inventario completo de transporte Matrix, medios y E2EE en paralelo.
La validación de runtime de instalación y actualización entre sistemas operativos forma parte de OpenClaw Release Checks y Full Release Validation públicos, que llaman directamente al workflow reutilizable .github/workflows/openclaw-cross-os-release-checks-reusable.yml. Esta separación es intencional: mantener la ruta real de lanzamiento npm corta, determinista y centrada en artefactos, mientras que las comprobaciones en vivo más lentas permanecen en su propia vía para que no detengan ni bloqueen la publicación.
Las comprobaciones de lanzamiento que portan secretos deben despacharse mediante Full Release Validation o desde la ref de workflow main/release para que la lógica de workflow y los secretos permanezcan controlados.
OpenClaw Release Checks acepta una rama, etiqueta o SHA completo de commit siempre que el commit resuelto sea alcanzable desde una rama o etiqueta de lanzamiento de OpenClaw.
La comprobación previa solo de validación de OpenClaw NPM Release también acepta el SHA actual completo de 40 caracteres del commit de la rama del workflow sin requerir una etiqueta subida. Esa ruta SHA es solo de validación y no puede promoverse a una publicación real. En modo SHA, el workflow sintetiza v<package.json version> solo para la comprobación de metadatos del paquete; la publicación real sigue requiriendo una etiqueta de lanzamiento real.
Ambos workflows mantienen la ruta real de publicación y promoción en runners hospedados por GitHub, mientras que la ruta de validación sin mutaciones puede usar los runners Linux más grandes de Blacksmith.
Ese workflow ejecuta OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache usando los secretos de workflow OPENAI_API_KEY y ANTHROPIC_API_KEY.
La comprobación previa de lanzamiento npm ya no espera a la vía separada de comprobaciones de lanzamiento.
Antes de etiquetar localmente un candidato de lanzamiento, ejecuta RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check. El ayudante ejecuta las protecciones rápidas de lanzamiento, las comprobaciones de lanzamiento npm/ClawHub de plugins, la compilación, la compilación de UI y release:openclaw:npm:check en el orden que detecta errores comunes que bloquean la aprobación antes de que empiece el workflow de publicación de GitHub.
Ejecuta RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (o la etiqueta preliminar/corrección correspondiente) antes de la aprobación.
Después de la publicación npm, ejecuta node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (o la versión beta/corrección correspondiente) para verificar la ruta de instalación del registro publicado en un prefijo temporal nuevo.
Después de una publicación beta, ejecuta OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live para verificar el onboarding del paquete instalado, la configuración de Telegram y E2E real de Telegram contra el paquete npm publicado usando el pool compartido de credenciales arrendadas de Telegram. Las ejecuciones locales puntuales de mantenedores pueden omitir las variables de Convex y pasar directamente las tres credenciales de entorno OPENCLAW_QA_TELEGRAM_*.
Para ejecutar el smoke beta completo posterior a la publicación desde una máquina de mantenedor, usa pnpm release:beta-smoke -- --beta betaN. El ayudante ejecuta la validación de actualización npm/fresh-target de Parallels, despacha NPM Telegram Beta E2E, consulta la ejecución exacta del workflow, descarga el artefacto e imprime el informe de Telegram.
Los mantenedores pueden ejecutar la misma comprobación posterior a la publicación desde GitHub Actions mediante el workflow manual NPM Telegram Beta E2E. Es intencionalmente solo manual y no se ejecuta en cada merge.
La automatización de lanzamientos de mantenedores usa comprobación previa y luego promoción:
- La publicación npm real debe pasar un preflight_run_id de npm exitoso.
- La publicación real debe despacharse desde la misma rama main o release/YYYY.M.PATCH que la ejecución exitosa de comprobación previa (se permite una rama alpha de Tideclaw para lanzamientos preliminares alpha).
- Los lanzamientos npm estables usan beta de forma predeterminada; la publicación npm estable puede apuntar explícitamente a latest mediante la entrada del workflow.
- La mutación de dist-tag de npm basada en token vive en openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml porque npm dist-tag add todavía necesita NPM_TOKEN mientras que el repositorio fuente mantiene publicación solo con OIDC.
- macOS Release público es solo de validación; cuando una etiqueta vive solo en una rama de lanzamiento pero el workflow se despacha desde main, define public_release_branch=release/YYYY.M.PATCH.
- La publicación real de macOS debe pasar un preflight_run_id y un validate_run_id de macOS exitosos.
- Las rutas de publicación reales promueven artefactos preparados en vez de recompilarlos otra vez.
Para lanzamientos de corrección estables como YYYY.M.PATCH-N, el verificador posterior a la publicación también comprueba la misma ruta de actualización con prefijo temporal de YYYY.M.PATCH a YYYY.M.PATCH-N para que las correcciones de lanzamiento no puedan dejar silenciosamente instalaciones globales antiguas en la carga estable base.
La comprobación previa de lanzamiento npm falla de forma cerrada salvo que el tarball incluya tanto dist/control-ui/index.html como una carga no vacía en dist/control-ui/assets/, para no volver a enviar un dashboard de navegador vacío.
La verificación posterior a la publicación también comprueba que los entrypoints de plugins publicados y los metadatos de paquetes estén presentes en el layout instalado del registro. Un lanzamiento que envía cargas faltantes de runtime de plugins falla el verificador posterior a la publicación y no puede promoverse a latest.
pnpm test:install:smoke también aplica el presupuesto unpackedSize de npm pack sobre el tarball candidato de actualización, para que el e2e del instalador detecte crecimiento accidental del paquete antes de la ruta de publicación del lanzamiento.
Si el trabajo de lanzamiento tocó planificación de CI, manifiestos de tiempos de extensiones o matrices de tests de extensiones, regenera y revisa las salidas de matriz plugin-prerelease-extension-shard propiedad del planificador desde .github/workflows/plugin-prerelease.yml antes de la aprobación para que las notas de lanzamiento no describan un layout de CI obsoleto.
La preparación para lanzamientos estables de macOS también incluye las superficies del actualizador: el lanzamiento de GitHub debe terminar con los .zip, .dmg y .dSYM.zip empaquetados; appcast.xml en main debe apuntar al nuevo zip estable después de publicar (el workflow de publicación de macOS lo commitea automáticamente, o abre un PR de appcast cuando el push directo está bloqueado); la app empaquetada debe mantener un bundle id que no sea de depuración, una URL no vacía de feed de Sparkle y un CFBundleVersion igual o superior al piso canónico de build de Sparkle para esa versión de lanzamiento.

Cajas de pruebas de lanzamiento

Full Release Validation es la forma en que los operadores inician todas las pruebas previas al lanzamiento desde un único entrypoint. Para una prueba de commit fijado en una rama que avanza rápido, usa el ayudante para que cada workflow hijo se ejecute desde una rama temporal fijada al SHA objetivo:

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

El ayudante sube release-ci/<sha>-..., despacha Full Release Validation desde esa rama con ref=<sha>, verifica que cada headSha de workflow hijo coincida con el objetivo y luego elimina la rama temporal. Esto evita probar accidentalmente una ejecución hija de un main más nuevo. Para la validación de una rama o etiqueta de lanzamiento, ejecútala desde la ref de workflow main confiable y pasa la rama o etiqueta de lanzamiento como ref:

gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.PATCH \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable \
  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N

El workflow resuelve la ref de destino, despacha manualmente CI con target_ref=<release-ref> y luego despacha OpenClaw Release Checks. OpenClaw Release Checks distribuye install smoke, verificaciones de release entre sistemas operativos, cobertura live/E2E de la ruta de release en Docker cuando soak está habilitado, Package Acceptance con el E2E canónico del paquete Telegram, paridad de QA Lab, Matrix live y Telegram live. Una ejecución full/all solo es aceptable cuando el resumen de Full Release Validation muestra normal_ci, plugin_prerelease y release_checks como exitosos, salvo que una repetición enfocada haya omitido intencionalmente el hijo separado Plugin Prerelease. Usa el hijo independiente npm-telegram solo para una repetición enfocada de paquete publicado con release_package_spec o npm_telegram_package_spec. El resumen final del verificador incluye tablas de los trabajos más lentos para cada ejecución hija, de modo que el responsable de la release pueda ver la ruta crítica actual sin descargar logs. Consulta Validación de release completa para ver la matriz completa de etapas, los nombres exactos de jobs del workflow, las diferencias entre los perfiles stable y full, los artefactos y los identificadores de repeticiones enfocadas. Los workflows hijos se despachan desde la ref de confianza que ejecuta Full Release Validation, normalmente --ref main, incluso cuando la ref de destino apunta a una rama o etiqueta de release anterior. No hay una entrada separada de ref de workflow para Full Release Validation; elige el arnés de confianza eligiendo la ref de ejecución del workflow. No uses --ref main -f ref=<sha> para prueba de commit exacto en una main móvil; los SHA de commit sin procesar no pueden ser refs de dispatch de workflow, así que usa pnpm ci:full-release --sha <sha> para crear la rama temporal fijada. Usa release_profile para seleccionar la amplitud live/provider:

minimum: la ruta live y Docker más rápida y crítica para la release de OpenAI/core
stable: minimum más cobertura estable de provider/backend para aprobación de release
full: stable más cobertura amplia de provider/media de asesoría

La validación stable y full siempre ejecuta el barrido exhaustivo live/E2E, de ruta de release Docker y acotado de supervivencia a upgrades publicados antes de la promoción. Usa run_release_soak=true para solicitar ese mismo barrido para una beta. Ese barrido cubre los últimos cuatro paquetes stable más las líneas base fijadas 2026.4.23 y 2026.5.2 más la cobertura anterior 2026.4.15, con líneas base duplicadas eliminadas y cada línea base dividida en shards en su propio job de ejecutor Docker. OpenClaw Release Checks usa la ref de workflow de confianza para resolver la ref de destino una vez como release-package-under-test y reutiliza ese artefacto en las verificaciones entre sistemas operativos, Package Acceptance y Docker de ruta de release cuando se ejecuta soak. Esto mantiene todas las cajas orientadas a paquetes en los mismos bytes y evita builds repetidas del paquete. Después de que una beta ya esté en npm, configura release_package_spec=openclaw@YYYY.M.PATCH-beta.N para que las verificaciones de release descarguen el paquete publicado una vez, extraigan su SHA de origen de build desde dist/build-info.json y reutilicen ese artefacto para las líneas entre sistemas operativos, Package Acceptance, Docker de ruta de release y Telegram de paquete. El install smoke de OpenAI entre sistemas operativos usa OPENCLAW_CROSS_OS_OPENAI_MODEL cuando la variable de repo/org está configurada; de lo contrario, openai/gpt-5.5, porque esta línea prueba la instalación del paquete, el onboarding, el arranque del Gateway y un turno live de agente, no compara el modelo predeterminado más lento. La matriz live más amplia de providers sigue siendo el lugar para la cobertura específica de modelos. Usa estas variantes según la etapa de release:

# Validate an unpublished release candidate branch.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.PATCH \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable

# Validate an exact pushed commit.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=<40-char-sha> \
  -f provider=openai \
  -f mode=both

# After publishing a beta, add published-package Telegram E2E.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.PATCH \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \
  -f npm_telegram_provider_mode=mock-openai

No uses el paraguas full como la primera repetición después de una corrección enfocada. Si una caja falla, usa el workflow hijo, job, línea Docker, perfil de paquete, provider de modelo o línea de QA que falló para la siguiente prueba. Ejecuta el paraguas full de nuevo solo cuando la corrección haya cambiado la orquestación compartida de release o haya vuelto obsoleta la evidencia previa de todas las cajas. El verificador final del paraguas vuelve a comprobar los ids registrados de ejecuciones de workflows hijos, así que después de que un workflow hijo se repita correctamente, vuelve a ejecutar solo el job padre Verify full validation que falló. Para recuperación acotada, pasa rerun_group al paraguas. all es la ejecución real de candidato de release, ci ejecuta solo el hijo de CI normal, plugin-prerelease ejecuta solo el hijo de plugin exclusivo de release, release-checks ejecuta todas las cajas de release y los grupos de release más estrechos son install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live y npm-telegram. Las repeticiones enfocadas de npm-telegram requieren release_package_spec o npm_telegram_package_spec; las ejecuciones full/all usan el E2E canónico de Telegram de paquete dentro de Package Acceptance. Las repeticiones enfocadas entre sistemas operativos pueden añadir cross_os_suite_filter=windows/packaged-upgrade u otro filtro de sistema operativo/suite. Las fallas de release-checks de QA bloquean la validación normal de release, incluida la deriva obligatoria de herramientas dinámicas de OpenClaw en el nivel estándar. Las ejecuciones alpha de Tideclaw aún pueden tratar las líneas de release-check que no son de seguridad de paquete como de asesoría. Cuando live_suite_filter solicita explícitamente una línea live de QA con compuerta como Discord, WhatsApp o Slack, la variable de repo OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED correspondiente debe estar habilitada; de lo contrario, la captura de entrada falla en vez de omitir la línea silenciosamente.

Vitest

La caja Vitest es el workflow hijo manual CI. La CI manual omite intencionalmente el acotamiento por cambios y fuerza el grafo normal de pruebas para el candidato de release: shards de Linux Node, shards de plugins incluidos, shards de contratos de plugins y canales, compatibilidad con Node 22, check-*, check-additional-*, verificaciones smoke de artefactos construidos, verificaciones de docs, Skills de Python, Windows, macOS y Control UI i18n. Android se incluye cuando Full Release Validation ejecuta la caja porque el paraguas pasa include_android=true; la CI manual independiente requiere include_android=true para la cobertura de Android. Usa esta caja para responder “¿el árbol de origen pasó la suite normal completa de pruebas?”. No es lo mismo que la validación de producto de la ruta de release. Evidencia que conservar:

resumen de Full Release Validation que muestra la URL de la ejecución CI despachada
ejecución CI en verde en el SHA de destino exacto
nombres de shards fallidos o lentos de los jobs de CI al investigar regresiones
artefactos de tiempos de Vitest como .artifacts/vitest-shard-timings.json cuando una ejecución necesita análisis de rendimiento

Ejecuta la CI manual directamente solo cuando la release necesite CI normal determinista, pero no las cajas Docker, QA Lab, live, entre sistemas operativos o de paquete. Usa el primer comando para CI directa sin Android. Añade include_android=true cuando la CI directa del candidato de release deba cubrir Android:

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true

Docker

La caja Docker vive en OpenClaw Release Checks mediante openclaw-live-and-e2e-checks-reusable.yml, además del workflow install-smoke en modo release. Valida el candidato de release mediante entornos Docker empaquetados en vez de solo pruebas a nivel de código fuente. La cobertura Docker de release incluye:

install smoke completo con el smoke lento de instalación global de Bun habilitado
preparación/reutilización de imagen smoke del Dockerfile raíz por SHA de destino, con jobs smoke de QR, root/gateway e installer/Bun ejecutándose como shards separados de install-smoke
líneas E2E de repositorio
fragmentos Docker de ruta de release: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a hasta plugins-runtime-install-h
cobertura de OpenWebUI dentro del fragmento plugins-runtime-services cuando se solicita
líneas divididas de instalación/desinstalación de plugins incluidos bundled-plugin-install-uninstall-0 hasta bundled-plugin-install-uninstall-23
suites live/E2E de providers y cobertura de modelos live en Docker cuando las verificaciones de release incluyen suites live

Usa los artefactos Docker antes de repetir ejecuciones. El scheduler de ruta de release sube .artifacts/docker-tests/ con logs de línea, summary.json, failures.json, tiempos de fases, JSON del plan del scheduler y comandos de repetición. Para recuperación enfocada, usa docker_lanes=<lane[,lane]> en el workflow reutilizable live/E2E en vez de repetir todos los fragmentos de release. Los comandos de repetición generados incluyen package_artifact_run_id previo y entradas de imágenes Docker preparadas cuando están disponibles, para que una línea fallida pueda reutilizar el mismo tarball y las mismas imágenes GHCR.

QA Lab

La caja QA Lab también forma parte de OpenClaw Release Checks. Es la compuerta de release de comportamiento agéntico y nivel de canal, separada de Vitest y de la mecánica de paquetes Docker. La cobertura QA Lab de release incluye:

línea de paridad simulada que compara la línea candidata de OpenAI con la línea base anthropic/claude-opus-4-8 usando el paquete de paridad agéntica
perfil rápido de QA live Matrix usando el entorno qa-live-shared
línea QA live de Telegram usando leases de credenciales CI de Convex
pnpm qa:otel:smoke, pnpm qa:otel:collector-smoke, pnpm qa:prometheus:smoke o pnpm qa:observability:smoke cuando la telemetría de release necesita prueba local explícita

Usa esta caja para responder “¿la release se comporta correctamente en escenarios de QA y flujos live de canales?”. Conserva las URL de artefactos de las líneas de paridad, Matrix y Telegram al aprobar la release. La cobertura completa de Matrix sigue disponible como una ejecución manual de QA-Lab dividida en shards, en vez de la línea predeterminada crítica para la release.

Paquete

La caja Package es la compuerta del producto instalable. Está respaldada por Package Acceptance y el resolver scripts/resolve-openclaw-package-candidate.mjs. El resolver normaliza un candidato en el tarball package-under-test consumido por Docker E2E, valida el inventario del paquete, registra la versión del paquete y el SHA-256, y mantiene la ref del arnés de workflow separada de la ref de origen del paquete. Fuentes de candidato compatibles:

source=npm: openclaw@beta, openclaw@latest o una versión exacta de release de OpenClaw
source=ref: empaqueta una rama, etiqueta o SHA de commit completo de confianza de package_ref con el arnés workflow_ref seleccionado
source=url: descarga un .tgz HTTPS público con package_sha256 requerido; se rechazan credenciales de URL, puertos HTTPS no predeterminados, nombres de host o direcciones resueltas privadas/internas/de uso especial y redirecciones inseguras
source=trusted-url: descarga un .tgz HTTPS con package_sha256 requerido y trusted_source_id desde una política con nombre en .github/package-trusted-sources.json; usa esto para mirrors empresariales mantenidos por maintainers o repositorios de paquetes privados en vez de añadir una omisión de red privada a nivel de entrada para source=url
source=artifact: reutiliza un .tgz subido por otra ejecución de GitHub Actions

OpenClaw Release Checks ejecuta Package Acceptance con source=artifact, el artefacto del paquete de lanzamiento preparado, 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

, telegram_mode=mock-openai. Package Acceptance mantiene la QA de migración, actualización, actualización de VPS gestionado desde la raíz, reinicio de actualización con autenticación configurada, instalación de Skills de ClawHub en vivo, limpieza de dependencias obsoletas de plugins, fixtures de plugins sin conexión, actualización de plugins, endurecimiento del escape de enlace de comandos de plugins y paquete de Telegram contra el mismo tarball resuelto. Las comprobaciones de lanzamiento bloqueantes usan la línea base predeterminada del paquete publicado más reciente; el perfil beta con run_release_soak=true, release_profile=stable o release_profile=full amplía el barrido de published-upgrade-survivor a last-stable-4 más las líneas base fijadas 2026.4.23, 2026.5.2 y 2026.4.15 con escenarios reported-issues. Usa Package Acceptance con source=npm para un candidato ya publicado, source=ref para un tarball npm local respaldado por un SHA antes de publicar, source=trusted-url para un mirror empresarial/privado propiedad de un mantenedor, o source=artifact para un tarball preparado subido por otra ejecución de GitHub Actions. Es el reemplazo nativo de GitHub para la mayor parte de la cobertura de paquete/actualización que antes requería Parallels. Las comprobaciones de lanzamiento entre sistemas operativos siguen siendo importantes para el onboarding específico del SO, el instalador y el comportamiento de plataforma, pero la validación del producto de paquete/actualización debe preferir Package Acceptance. La lista de comprobación canónica para la validación de actualizaciones y plugins es Probar actualizaciones y plugins. Úsala al decidir qué carril local, Docker, Package Acceptance o de comprobación de lanzamiento demuestra un cambio de instalación/actualización de plugins, limpieza de doctor o migración de paquetes publicados. La migración exhaustiva de actualizaciones publicadas desde cada paquete estable 2026.4.23+ es un flujo de trabajo manual separado Update Migration, no parte de Full Release CI. La tolerancia heredada de package-acceptance está intencionalmente limitada en el tiempo. Los paquetes hasta 2026.4.25 pueden usar la ruta de compatibilidad para huecos de metadatos ya publicados en npm: entradas de inventario de QA privadas ausentes del tarball, falta de gateway install --wrapper, falta de archivos de parche en el fixture de git derivado del tarball, falta de update.channel persistido, ubicaciones heredadas de registros de instalación de plugins, falta de persistencia de registros de instalación de marketplace y migración de metadatos de configuración durante plugins update. El paquete publicado 2026.4.26 puede advertir sobre archivos de sello de metadatos de compilación local que ya se publicaron. Los paquetes posteriores deben cumplir los contratos modernos de paquetes; esos mismos huecos fallan la validación de lanzamiento. Usa perfiles más amplios de Package Acceptance cuando la pregunta de lanzamiento sea sobre un paquete instalable real:

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 published_upgrade_survivor_baseline=openclaw@2026.4.26

Perfiles comunes de paquetes:

smoke: carriles rápidos de instalación de paquete/canal/agente, red de Gateway y recarga de configuración
package: contratos de instalación/actualización/reinicio/paquete de Plugin más prueba de instalación de Skills de ClawHub en vivo; este es el valor predeterminado de comprobación de lanzamiento
product: package más canales MCP, limpieza de cron/subagente, búsqueda web de OpenAI y OpenWebUI
full: fragmentos de ruta de lanzamiento de Docker con OpenWebUI
custom: lista exacta de docker_lanes para reejecuciones enfocadas

Para la prueba de Telegram de un candidato de paquete, habilita telegram_mode=mock-openai o telegram_mode=live-frontier en Package Acceptance. El flujo de trabajo pasa el tarball resuelto package-under-test al carril de Telegram; el flujo de trabajo independiente de Telegram todavía acepta una especificación npm publicada para comprobaciones posteriores a la publicación.

Automatización regular de publicación de lanzamientos

Para beta, latest, plugins, GitHub Release y publicación de plataformas, OpenClaw Release Publish es el punto de entrada mutante normal. La ruta mensual .33+ de extended-stable solo para npm no usa este orquestador. El flujo de trabajo regular orquesta los flujos de trabajo de publicador confiable en el orden que necesita el lanzamiento:

Comprobar la etiqueta de lanzamiento y resolver su SHA de commit.
Verificar que la etiqueta sea alcanzable desde main o release/* (o una rama alfa de Tideclaw para prelanzamientos alfa).
Ejecutar pnpm plugins:sync:check.
Despachar Plugin NPM Release con publish_scope=all-publishable y ref=<release-sha>.
Despachar Plugin ClawHub Release con el mismo alcance y SHA.
Despachar OpenClaw NPM Release con la etiqueta de lanzamiento, la dist-tag de npm y el preflight_run_id guardado después de verificar el full_release_validation_run_id guardado.
Para lanzamientos estables, crear o actualizar el lanzamiento de GitHub como borrador, despachar Windows Node Release con el windows_node_tag explícito y los windows_node_installer_digests aprobados para el candidato, y verificar los activos canónicos del instalador/suma de comprobación antes de publicar el borrador.

Ejemplo de publicación beta:

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

Publicación estable en la dist-tag beta predeterminada:

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH \
  -f windows_node_tag=vX.Y.Z \
  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \
  -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

La promoción estable directamente a latest es explícita:

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH \
  -f windows_node_tag=vX.Y.Z \
  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \
  -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=latest

Usa los flujos de trabajo de nivel inferior Plugin NPM Release y Plugin ClawHub Release solo para trabajos enfocados de reparación o republicación. OpenClaw Release Publish rechaza plugin_publish_scope=selected cuando publish_openclaw_npm=true para que el paquete principal no pueda publicarse sin todos los plugins oficiales publicables, incluido @openclaw/diffs-language-pack. Para una reparación de Plugin seleccionado, establece publish_openclaw_npm=false con plugin_publish_scope=selected y plugins=@openclaw/name, o despacha el flujo de trabajo hijo directamente.

Entradas del flujo de trabajo NPM

OpenClaw NPM Release acepta estas entradas controladas por el operador:

tag: etiqueta de lanzamiento requerida, como v2026.4.2, v2026.4.2-1, v2026.4.2-beta.1 o v2026.4.2-alpha.1; cuando preflight_only=true, también puede ser el SHA de commit actual completo de 40 caracteres de la rama del flujo de trabajo para preflight solo de validación
preflight_only: true para solo validación/compilación/paquete, false para la ruta de publicación real
preflight_run_id: id de ejecución de preflight exitoso existente, requerido en la ruta de publicación real para que el flujo de trabajo reutilice el tarball preparado en lugar de reconstruirlo
full_release_validation_run_id: id de ejecución exitosa de Full Release Validation para esta etiqueta/SHA, requerido para la publicación real. Las publicaciones beta pueden continuar solo con preflight con una advertencia, pero la promoción estable/latest aún lo requiere.
release_publish_run_id: id de ejecución aprobado de OpenClaw Release Publish; requerido cuando este flujo de trabajo lo despacha ese padre (llamadas de publicación real del actor bot)
plugin_npm_run_id: id de ejecución exitosa de Plugin NPM Release de cabecera exacta; requerido para una publicación central extended-stable real
npm_dist_tag: etiqueta npm de destino para la ruta de publicación; acepta alpha, beta, latest o extended-stable y por defecto es beta. El parche final 33 y posteriores deben usar extended-stable; de forma predeterminada, extended-stable rechaza parches anteriores, y siempre rechaza etiquetas no finales.
bypass_extended_stable_guard: booleano solo para pruebas, predeterminado false; con npm_dist_tag=extended-stable, omite la elegibilidad mensual de extended-stable mientras conserva las comprobaciones de identidad de lanzamiento, artefacto, aprobación y lectura posterior.

Plugin NPM Release acepta npm_dist_tag=default para el comportamiento de lanzamiento existente o npm_dist_tag=extended-stable para la ruta mensual protegida. La opción extended-stable requiere publish_scope=all-publishable, una entrada plugins vacía, un parche final igual o superior a 33, y la rama canónica extended-stable/YYYY.M.33 en su punta exacta. Nunca mueve latest ni beta de plugins. Las nuevas versiones de paquetes reciben extended-stable atómicamente mediante publicación confiable OIDC (npm publish --tag extended-stable); este flujo de trabajo de origen no usa npm dist-tag add autenticado por token. Los reintentos omiten las versiones exactas ya presentes en npm, y luego fallan de forma cerrada salvo que la lectura posterior completa confirme que cada paquete exacto y etiqueta extended-stable convergieron. OpenClaw Release Publish acepta estas entradas controladas por el operador:

tag: etiqueta de lanzamiento requerida; ya debe existir
preflight_run_id: id de ejecución exitosa de preflight de OpenClaw NPM Release; requerido cuando publish_openclaw_npm=true
full_release_validation_run_id: id de ejecución exitosa de Full Release Validation; requerido cuando publish_openclaw_npm=true
windows_node_tag: etiqueta exacta no preliminar de lanzamiento de openclaw/openclaw-windows-node; requerida para publicación estable de OpenClaw
windows_node_installer_digests: mapa JSON compacto aprobado para el candidato de los nombres actuales de instaladores de Windows a sus resúmenes sha256: fijados; requerido para publicación estable de OpenClaw
npm_telegram_run_id: id opcional de ejecución exitosa de NPM Telegram Beta E2E para incluir en la evidencia final de lanzamiento
npm_dist_tag: etiqueta npm de destino para el paquete OpenClaw, una de alpha, beta o latest
plugin_publish_scope: por defecto es all-publishable; usa selected solo para trabajo enfocado de reparación exclusiva de plugins con publish_openclaw_npm=false
plugins: nombres de paquetes @openclaw/* separados por comas cuando plugin_publish_scope=selected
publish_openclaw_npm: por defecto es true; establece false solo cuando uses el flujo de trabajo como orquestador de reparación exclusiva de plugins
release_profile: perfil de cobertura de lanzamiento usado para resúmenes de evidencia de lanzamiento; por defecto es from-validation, que lo lee del manifiesto de validación, o sobrescríbelo con beta, stable o full
wait_for_clawhub: por defecto es false para que la disponibilidad de npm no sea bloqueada por el sidecar de ClawHub; establece true solo cuando la finalización del flujo de trabajo deba incluir la finalización de ClawHub

OpenClaw Release Checks acepta estas entradas controladas por el operador:

ref: rama, etiqueta o SHA de commit completo para validar. Las comprobaciones con secretos requieren que el commit resuelto sea alcanzable desde una rama de OpenClaw o una etiqueta de lanzamiento.
run_release_soak: optar por el soak exhaustivo en vivo/E2E, ruta de lanzamiento de Docker y upgrade-survivor desde todos para comprobaciones de lanzamiento beta. Es forzado por release_profile=stable y release_profile=full.

Reglas:

Las versiones finales regulares y de corrección por debajo del parche 33 pueden publicarse en beta o latest. Las versiones finales en el parche 33 o superior deben publicarse en extended-stable, y las versiones con sufijo de corrección en ese límite se rechazan.
Las etiquetas de prelanzamiento beta solo pueden publicarse en beta; las etiquetas de prelanzamiento alpha solo pueden publicarse en alpha
Para OpenClaw NPM Release, la entrada de SHA de commit completo solo se permite cuando preflight_only=true
OpenClaw Release Checks y Full Release Validation siempre son solo de validación
La ruta de publicación real debe usar el mismo npm_dist_tag usado durante la comprobación previa; el flujo de trabajo verifica esos metadatos antes de que continúe la publicación

Secuencia regular de lanzamiento estable beta/latest

Esta secuencia heredada es para el lanzamiento orquestado regular que también gestiona plugins, GitHub Release, Windows y otro trabajo de plataforma. No es la ruta mensual .33+ npm-only extended-stable documentada al principio de esta página. Al preparar un lanzamiento estable orquestado regular:

Ejecuta OpenClaw NPM Release con preflight_only=true. Antes de que exista una etiqueta, puedes usar el SHA de commit completo actual de la rama del flujo de trabajo para una ejecución de prueba de validación de la comprobación previa.
Elige npm_dist_tag=beta para el flujo normal beta-first, o latest solo cuando quieras intencionadamente una publicación estable directa.
Ejecuta Full Release Validation en la rama de lanzamiento, la etiqueta de lanzamiento o el SHA de commit completo cuando quieras CI normal más cobertura de live prompt cache, Docker, QA Lab, Matrix y Telegram desde un solo flujo de trabajo manual. Si intencionadamente solo necesitas el grafo de pruebas normal determinista, ejecuta en su lugar el flujo de trabajo manual CI en la referencia de lanzamiento.
Selecciona la etiqueta de lanzamiento exacta no preliminar de openclaw/openclaw-windows-node cuyos instaladores firmados x64 y ARM64 deben distribuirse. Guárdala como windows_node_tag y guarda su mapa de resúmenes validado como windows_node_installer_digests. El asistente de release-candidate registra ambos y los incluye en el comando de publicación que genera.
Guarda los valores correctos de preflight_run_id y full_release_validation_run_id.
Ejecuta OpenClaw Release Publish con el mismo tag, el mismo npm_dist_tag, el windows_node_tag seleccionado, sus windows_node_installer_digests guardados, el preflight_run_id guardado y el full_release_validation_run_id guardado. Publica plugins externalizados en npm y ClawHub antes de promocionar el paquete npm de OpenClaw.
Si el lanzamiento llegó a beta, usa el flujo de trabajo openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml para promocionar esa versión estable de beta a latest.
Si el lanzamiento se publicó intencionadamente directamente en latest y beta debe seguir de inmediato la misma compilación estable, usa ese mismo flujo de trabajo de lanzamiento para apuntar ambas dist-tags a la versión estable, o deja que su sincronización programada de autorreparación mueva beta más tarde.

La mutación de dist-tag vive en el repositorio del libro mayor de lanzamientos porque aún requiere NPM_TOKEN, mientras que el repositorio fuente mantiene la publicación solo con OIDC. Eso mantiene tanto la ruta de publicación directa como la ruta de promoción beta-first documentadas y visibles para el operador. Si un mantenedor debe recurrir a la autenticación npm local, ejecuta cualquier comando de la CLI de 1Password (op) solo dentro de una sesión tmux dedicada. No llames a op directamente desde la shell principal del agente; mantenerlo dentro de tmux hace que las indicaciones, alertas y gestión de OTP sean observables y evita alertas repetidas del host.

Referencias públicas

Los mantenedores usan la documentación privada de lanzamientos en openclaw/maintainers/release/README.md para el procedimiento operativo real.

Relacionado

Canales de lanzamiento

​Nomenclatura de versiones

​Cadencia de lanzamientos

​Publicación mensual extended-stable solo de npm

​Lista de comprobación regular para operadores de lanzamiento

​Cierre estable de main

​Preflight de lanzamiento

​Cajas de pruebas de lanzamiento

​Vitest

​Docker

​QA Lab

​Paquete

​Automatización regular de publicación de lanzamientos

​Entradas del flujo de trabajo NPM

​Secuencia regular de lanzamiento estable beta/latest

​Referencias públicas

​Relacionado