Política de lanzamientos

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

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

Por separado, los operadores de lanzamiento pueden publicar el paquete principal del mes completado anterior en npm extended-stable, comenzando en el 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 del canal de actualización de la CLI.

Nombres de versiones

• Versión mensual de lanzamiento extended-stable en npm: YYYY.M.PATCH, con PATCH >= 33
  • Etiqueta de Git: vYYYY.M.PATCH
• Versión diaria/regular final: YYYY.M.PATCH, con PATCH < 33
  • Etiqueta de Git: vYYYY.M.PATCH
• Versión regular de corrección de fallback: YYYY.M.PATCH-N
  • Etiqueta de Git: vYYYY.M.PATCH-N
• Versión beta de prelanzamiento: YYYY.M.PATCH-beta.N
  • Etiqueta de Git: vYYYY.M.PATCH-beta.N
• No rellenes con ceros el mes ni el parche
• A partir de la actualización del proceso de lanzamiento de junio de 2026, el tercer componente es un número secuencial mensual del tren de lanzamiento, no un día calendario. Las versiones stable y beta determinan el tren actual; las etiquetas solo alpha no consumen ni avanzan el número de parche beta/stable. Las etiquetas y versiones de npm anteriores a la actualización conservan sus nombres existentes y siguen siendo válidas; la automatización de lanzamiento continúa comparándolas por año, mes, parche, canal y número de prelanzamiento o corrección.
• Las compilaciones alpha/nightly usan el siguiente tren de parche no publicado e incrementan solo alpha.N para compilaciones repetidas. Una vez que ese parche tiene una beta, las nuevas compilaciones alpha pasan al parche siguiente. Ignora las etiquetas heredadas solo alpha con números de parche más altos al seleccionar un tren beta o stable.
• Las versiones de npm son inmutables. Si una etiqueta beta ya se publicó, no la elimines, vuelvas a publicar ni reutilices; corta el siguiente número beta o el siguiente parche mensual. Como 2026.6.5-beta.1 ya se publicó durante la transición, los trenes de lanzamiento de junio de 2026 deben usar el parche 5 o superior. No publiques nuevos trenes stable o beta de junio de 2026 como 2026.6.2, 2026.6.3 ni 2026.6.4.
• Después de la final regular 2026.6.5, el siguiente nuevo tren beta es 2026.6.6-beta.1, incluso si ya existen etiquetas automatizadas solo alpha con números de parche más altos.
• latest continúa siguiendo la línea actual regular/diaria de npm
• beta significa el destino de instalación beta actual
• extended-stable significa el paquete de npm compatible del mes anterior, comenzando en el parche 33; el parche 34 y posteriores son versiones de mantenimiento en esa línea mensual
• La ruta mensual dedicada extended-stable publica solo el paquete principal de npm. No publica plugins, artefactos de macOS o Windows, una GitHub Release, dist-tags de repositorio privado, imágenes de Docker, artefactos móviles ni descargas del sitio web.

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 a partir del main actual, de modo que la validación y las correcciones de lanzamiento no bloqueen el nuevo desarrollo en main
• Si una etiqueta beta se ha enviado o publicado y necesita una corrección, los mantenedores cortan la siguiente etiqueta -beta.N en lugar de eliminar o recrear la etiqueta beta anterior
• El procedimiento detallado de lanzamiento, aprobaciones, credenciales y notas de recuperación son solo para mantenedores

Publicación mensual extended-stable solo en 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 los 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 una 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.

Ejecuta la preflight de npm y Full Release Validation desde la rama exacta extended-stable, y 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 y el entorno de lanzamiento de npm esté listo, promueve el tarball exacto de la preflight. El parche P debe ser 33 o superior:

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>

Para un fork o ensayo no productivo que intencionalmente no pueda satisfacer la política mensual .33 o de mes de main protegido, agrega -f bypass_extended_stable_guard=true tanto a los dispatches de preflight como de publicación de npm. El valor predeterminado es false. La omisión se acepta solo con npm_dist_tag=extended-stable y se registra en el resumen del workflow. No omite la ref de workflow canónica extended-stable/YYYY.M.33, la igualdad entre punta de rama/etiqueta/checkout, la sintaxis de etiqueta final, la igualdad entre versión de paquete/etiqueta, la identidad del manifiesto y de las ejecuciones referenciadas, la procedencia del tarball, la aprobación de entorno, la lectura de vuelta del registro ni la evidencia de reparación del selector.

El workflow de publicación verifica las identidades de las ejecuciones referenciadas, el digest del tarball preparado y ambos selectores del registro npm. Confirma de forma independiente el resultado después de que el workflow 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 la lectura de vuelta del selector falla, 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 workflow fallido, y luego repite ambas lecturas de vuelta independientes. Revertir al selector anterior es una decisión separada del operador, no la ruta de reparación de lectura de vuelta.

La lista de verificació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 en npm.

Lista de verificación regular para operadores de lanzamiento

Esta lista de verificació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 rollback de emergencia permanecen en el runbook de lanzamiento solo para mantenedores.

1. Empieza desde el main actual: trae los últimos cambios, confirma que el commit objetivo se haya enviado, y confirma que el CI actual de main esté lo bastante verde como para crear una rama desde él.
2. 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 de PR y commits directos que se solapen, confirma la reescritura, envíala, y haz rebase/pull una vez más antes de crear la rama.
3. Revisa los registros de compatibilidad de lanzamiento en src/plugins/compat/registry.ts y src/commands/doctor/shared/deprecation-compat.ts. Elimina la compatibilidad expirada solo cuando la ruta de actualización siga cubierta, o registra por qué se conserva intencionalmente.
4. Crea release/YYYY.M.PATCH desde el main actual; no hagas el trabajo normal de lanzamiento directamente en main.
5. Incrementa cada ubicación de versión requerida para la etiqueta prevista y luego ejecuta pnpm release:prep. Esto actualiza las versiones de plugins, el inventario de plugins, el esquema de configuración, los metadatos de configuración de canales incluidos, la línea base de documentación de configuración, las exportaciones del SDK de plugins y la línea base de la API del SDK de plugins en el orden correcto. Confirma cualquier deriva generada antes de etiquetar. Luego ejecuta la verificación previa determinista local: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build, y pnpm release:check.
6. 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 una verificación previa solo de validación. La verificación previa genera evidencia de lanzamiento de dependencias para el grafo de dependencias exacto extraído y la almacena en el artefacto de verificación previa de npm. Guarda el preflight_run_id exitoso.
7. Inicia todas las pruebas previas al lanzamiento con Full Release Validation para la rama de lanzamiento, etiqueta o SHA completo del commit. Este es el único punto de entrada manual para las cuatro cajas grandes de pruebas de lanzamiento: Vitest, Docker, QA Lab y Package.
8. Si la validación falla, corrige en la rama de lanzamiento y vuelve a ejecutar el archivo, lane, job de workflow, perfil de paquete, proveedor o lista de permitidos de modelos fallidos más pequeño que demuestre la corrección. Vuelve a ejecutar el contenedor completo solo cuando la superficie modificada deje obsoleta la evidencia previa.
9. Para un candidato beta etiquetado, ejecuta pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N desde la rama release/YYYY.M.PATCH correspondiente. Para estable, pasa también el lanzamiento fuente de Windows requerido: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z. El ayudante ejecuta las comprobaciones locales de lanzamiento generado, despacha o verifica la validación completa de lanzamiento y la evidencia de verificación previa de npm, ejecuta la prueba fresh/update de Parallels contra el tarball preparado exacto más la prueba del paquete de Telegram, registra los 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, y luego promociona el artefacto preparado de verificación previa de npm de OpenClaw con el dist-tag correspondiente tan pronto como la publicación de plugins en npm tenga éxito. Después de que el proceso hijo de publicación de OpenClaw en npm tenga éxito, crea o actualiza la página de lanzamiento/prelanzamiento de GitHub correspondiente a partir de la sección completa coincidente de CHANGELOG.md. Los lanzamientos estables publicados en npm latest se convierten en el último lanzamiento de GitHub; los lanzamientos estables de mantenimiento mantenidos en npm beta se crean con GitHub latest=false. El workflow también sube la evidencia de dependencias de la verificación previa, el manifiesto de validación completa y la evidencia de verificación de registro posterior a la publicación al lanzamiento de GitHub para la respuesta a incidentes posteriores al lanzamiento. El workflow de publicación imprime los ID de ejecuciones hijas inmediatamente, aprueba automáticamente las puertas de entorno de lanzamiento que el token del workflow tiene permiso para aprobar, resume los jobs hijos fallidos con colas de logs, cierra el lanzamiento de GitHub y la evidencia de dependencias tan pronto como la publicación de OpenClaw en npm tiene éxito, espera a ClawHub siempre que se esté publicando OpenClaw 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 ejecuciones de workflows hijos y el ID opcional de ejecución de NPM Telegram. La ruta de ClawHub reintenta fallos transitorios de instalación de dependencias de la CLI, publica plugins que pasan la vista previa incluso cuando una celda de vista previa falla de forma intermitente, y termina con verificación de registro para cada versión de plugin esperada, de modo que las publicaciones parciales sigan siendo visibles y reintentables. Luego ejecuta la aceptación de paquete posterior a la publicación contra el paquete publicado openclaw@YYYY.M.PATCH-beta.N o openclaw@beta. Si un prelanzamiento enviado o publicado necesita una corrección, crea el siguiente número de prelanzamiento correspondiente; no elimines ni reescribas el prelanzamiento anterior.
10. Para estable, continúa solo después de que la beta o el candidato de lanzamiento evaluado tenga la evidencia de validación requerida. La publicación estable de npm también pasa por OpenClaw Release Publish, reutilizando el artefacto exitoso de verificación previa mediante preflight_run_id; la preparación del lanzamiento estable de macOS también requiere el .zip, .dmg, .dSYM.zip empaquetados y el appcast.xml actualizado en main. El workflow de publicación de macOS publica el appcast firmado en el main público automáticamente después de verificar los activos de lanzamiento; si la protección de rama bloquea el push directo, abre o actualiza un PR de appcast. La preparación de Windows Hub estable requiere los activos firmados OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe y OpenClawCompanion-SHA256SUMS.txt en el lanzamiento de GitHub de OpenClaw. Pasa la etiqueta exacta del lanzamiento firmado openclaw/openclaw-windows-node como windows_node_tag y su mapa de resúmenes de instaladores aprobado por el candidato como windows_node_installer_digests; OpenClaw Release Publish mantiene el borrador de lanzamiento, despacha Windows Node Release y verifica los tres activos antes de la publicación.
11. Después de publicar, ejecuta el verificador de npm posterior a la publicación, el E2E independiente opcional 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 generada de lanzamiento de GitHub, ejecuta los pasos del anuncio de lanzamiento, y luego completa Cierre estable de main antes de dar por terminado un lanzamiento estable.

Cierre estable de main

La publicación estable no está completa hasta que main contiene el estado de lanzamiento realmente distribuido.

1. Empieza desde el último main recién actualizado. Audita release/YYYY.M.PATCH contra él y reenvía a main las correcciones reales que falten. No fusiones a ciegas en el main más nuevo adaptadores de compatibilidad, pruebas o validación exclusivos del lanzamiento.
2. Ajusta main a la versión estable distribuida, no a un tren siguiente especulativo. Ejecuta pnpm release:prep después del cambio de versión raíz y luego pnpm deps:shrinkwrap:generate.
3. 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.
4. 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.
5. 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 distribuida y el changelog antes de dar por terminado el lanzamiento estable.
6. Mantén actualizadas las variables de repositorio RELEASE_ROLLBACK_DRILL_ID y RELEASE_ROLLBACK_DRILL_DATE después de cada simulacro privado de reversión. OpenClaw Stable Main Closeout empieza desde el push de main que contiene la versión distribuida, el changelog y el appcast después de la publicación estable. Lee evidencia inmutable posterior a la publicación para vincular la etiqueta distribuida con sus ejecuciones de Full Release Validation y Publish, luego verifica el estado estable de main, el lanzamiento, el periodo de observación estable obligatorio y la evidencia de rendimiento bloqueante. Adjunta un manifiesto inmutable de cierre y una suma de comprobación al lanzamiento de GitHub. El disparador automático por push omite lanzamientos heredados que preceden la evidencia inmutable posterior a la publicación; nunca trata esa omisión como un cierre completado. Un cierre completo requiere tanto los activos 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 bloqueando. Una ejecución disparada por push sin variables de repositorio del 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 exclusivo de mantenedores. Usa el despacho manual solo para reparar o reproducir un cierre estable respaldado por evidencia. Una etiqueta heredada de corrección alternativa puede reutilizar evidencia del paquete base solo cuando la etiqueta de corrección resuelve al mismo commit fuente que la etiqueta estable base. Una corrección con una fuente diferente debe publicar y verificar su propia evidencia de paquete.

Verificación previa de lanzamiento

• Ejecuta pnpm check:test-types antes de la comprobación previa del lanzamiento para que el TypeScript de las pruebas siga cubierto fuera de la puerta local más rápida de pnpm check
• Ejecuta pnpm check:architecture antes de la comprobación previa del 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 puerta local más rápida
• Ejecuta pnpm build && pnpm ui:build antes de pnpm release:check para que existan los artefactos de lanzamiento dist/* esperados y el paquete de Control UI para el paso de validación del 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, inventario de plugins, esquema de configuración base, metadatos de configuración de canales empaquetados, 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 esos resguardos en modo de comprobación e informa en una sola pasada de todos los fallos de desviación generada que encuentra antes de ejecutar las comprobaciones de lanzamiento de paquetes.
• La sincronización de versiones de plugins actualiza las versiones de paquetes de plugins oficiales y los pisos openclaw.compat.pluginApi existentes 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 permanecen intencionalmente compatibles con hosts OpenClaw anteriores, mantén el piso en la API de host más antigua compatible y documenta esa elección en la prueba de lanzamiento del plugin.
• Ejecuta el workflow manual Full Release Validation antes de aprobar el lanzamiento para iniciar todas las cajas de prueba previas 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 soak de ruta de lanzamiento Docker; run_release_soak=true se conserva para un soak beta explícito. Package Acceptance proporciona el E2E canónico de Telegram del paquete durante la validación del candidato, evitando un segundo sondeador live concurrente. Proporciona release_package_spec después de publicar una beta para reutilizar el paquete npm enviado en las comprobaciones de lanzamiento, Package Acceptance y el E2E de Telegram del paquete sin reconstruir el tarball de lanzamiento. Proporciona npm_telegram_package_spec solo cuando Telegram deba usar un paquete publicado distinto del resto de la validación de lanzamiento. Proporciona package_acceptance_package_spec cuando Package Acceptance deba usar un paquete publicado distinto de la especificación del paquete de lanzamiento. Proporciona evidence_package_spec cuando el informe de evidencia de lanzamiento deba demostrar que la validación coincide con un paquete npm publicado sin forzar el E2E de Telegram. Ejemplo: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.PATCH
• Ejecuta el workflow manual Package Acceptance cuando quieras prueba de 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 de lanzamiento exacta; source=ref para empaquetar una rama/etiqueta/SHA package_ref confiable con el arnés workflow_ref actual; source=url para un tarball HTTPS público con un SHA-256 requerido y una política estricta de URL pública; source=trusted-url para una política de fuente 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 del paquete es el candidato y published_upgrade_survivor_baseline selecciona la línea base publicada. update-restart-auth usa el paquete candidato como CLI instalada y como package-under-test para ejercitar 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 de 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 el workflow manual CI directamente cuando solo necesites cobertura de CI normal determinista 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 empaquetados, shards de contratos de plugins y canales, compatibilidad con Node 22, check-*, check-additional-*, comprobaciones smoke de artefactos construidos, comprobaciones de documentación, Skills de Python, 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 hijo de CI. Ejemplo con Android: 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 logs, además de atributos de traza acotados y redacción de contenido/identificadores sin requerir Opik, Langfuse u 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 permanezcan libres de contenido de prompts, identificadores sin procesar, tokens de autenticación y rutas locales.
• Ejecuta pnpm qa:observability:smoke cuando quieras los carriles smoke de OpenTelemetry y Prometheus del checkout fuente de forma consecutiva.
• Ejecuta pnpm release:check antes de cada lanzamiento etiquetado
• La comprobación previa de OpenClaw NPM Release genera evidencia de lanzamiento de dependencias antes de empaquetar el tarball de npm. La puerta de vulnerabilidades de avisos de npm es bloqueante para 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 bajo dependency-evidence/ dentro del artefacto de comprobación previa de npm preparado. La ruta real de publicación 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 mutante después de que exista la etiqueta. Despáchalo desde release/YYYY.M.PATCH (o main al publicar una etiqueta alcanzable desde main), pasa la etiqueta de lanzamiento, el preflight_run_id de npm de OpenClaw correcto y el full_release_validation_run_id correcto, 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 ClawHub de plugins y la publicación npm de OpenClaw para que el paquete central no se publique antes que sus plugins externalizados.
• OpenClaw Release Publish estable requiere un windows_node_tag exacto después de que exista el lanzamiento no preliminar correspondiente de openclaw/openclaw-windows-node. También requiere el mapa windows_node_installer_digests aprobado para el candidato. Antes de despachar cualquier hijo de publicación, verifica que el lanzamiento fuente esté publicado, no sea preliminar, contenga los instaladores x64/ARM64 requeridos y aún coincida con ese mapa aprobado. Luego despacha 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 que sus firmas Authenticode usen el firmante esperado de OpenClaw Foundation en un runner de Windows, escribe un manifiesto SHA-256 y sube los instaladores más el manifiesto al lanzamiento canónico de GitHub de OpenClaw; luego vuelve a descargar los recursos promocionados y verifica la pertenencia al manifiesto y los hashes. El padre verifica el contrato actual de recursos x64, ARM64 y checksum antes de la publicación. La recuperación directa rechaza nombres de recursos OpenClawCompanion-* inesperados antes de reemplazar los recursos 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 URL exactas de recursos 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 complementario.
• Las comprobaciones de lanzamiento ahora se ejecutan en un workflow manual separado: OpenClaw Release Checks
• OpenClaw Release Checks también ejecuta el carril de paridad mock de QA Lab más el perfil live rápido de Matrix y el carril de QA de Telegram antes de la aprobación del lanzamiento. Los carriles live usan el entorno qa-live-shared; Telegram también usa arrendamientos de credenciales de Convex CI. Ejecuta el workflow manual QA-Lab - All Lanes con matrix_profile=all y matrix_shards=true cuando quieras el inventario completo de transporte, medios y E2EE de Matrix 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 división es intencional: mantiene la ruta real de lanzamiento npm corta, determinista y centrada en artefactos, mientras las comprobaciones live más lentas permanecen en su propio carril para que no detengan ni bloqueen la publicación
• Las comprobaciones de lanzamiento con secretos deben despacharse mediante Full Release Validation o desde la ref del workflow main/release para que la lógica del 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 de OpenClaw o una etiqueta de lanzamiento
• La comprobación previa solo de validación de OpenClaw NPM Release también acepta el SHA de commit completo de 40 caracteres de la rama de workflow actual sin requerir una etiqueta publicada
• Esa ruta SHA es solo de validación y no puede promocionarse 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 todavía requiere una etiqueta de lanzamiento real
• Ambos workflows mantienen la ruta real de publicación y promoción en runners alojados por GitHub, mientras que la ruta de validación no mutante 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 al carril separado 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 helper ejecuta los resguardos rápidos de lanzamiento, comprobaciones de lanzamiento npm/ClawHub de plugins, build, build de UI y release:openclaw:npm:check en el orden que detecta errores comunes que bloquean la aprobación antes de que comience 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 beta/corrección correspondiente) antes de la aprobación
• Después de publicar en 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 publicar una 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 la incorporación del paquete instalado, la configuración de Telegram y el E2E real de Telegram contra el paquete npm publicado usando el conjunto compartido de credenciales de Telegram alquiladas. 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 helper ejecuta la validación de actualización npm/fresh-target en Parallels, despacha NPM Telegram Beta E2E, sondea la ejecución exacta del flujo de trabajo, 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 flujo de trabajo manual NPM Telegram Beta E2E. Es intencionadamente solo manual y no se ejecuta en cada fusión.
• La automatización de releases para mantenedores ahora usa preflight-then-promote:
  • la publicación npm real debe tener un preflight_run_id de npm correcto
  • la publicación npm real debe despacharse desde la misma rama main o release/YYYY.M.PATCH que la ejecución de preflight correcta
  • las releases npm estables usan beta por defecto
  • la publicación npm estable puede apuntar explícitamente a latest mediante una entrada del flujo de trabajo
  • la mutación de dist-tag de npm basada en token ahora 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 la publicación solo con OIDC
  • macOS Release público es solo de validación; cuando una etiqueta vive solo en una rama de release pero el flujo de trabajo se despacha desde main, define public_release_branch=release/YYYY.M.PATCH
  • la publicación macOS real debe tener un preflight_run_id de macOS y un validate_run_id correctos
  • las rutas de publicación real promocionan artefactos preparados en lugar de volver a reconstruirlos
• Para releases estables de corrección como YYYY.M.PATCH-N, el verificador posterior a la publicación también comprueba la misma ruta de actualización con prefijo temporal desde YYYY.M.PATCH a YYYY.M.PATCH-N para que las correcciones de release no puedan dejar silenciosamente instalaciones globales antiguas en la carga base estable
• El preflight de release npm falla de forma cerrada salvo que el tarball incluya tanto dist/control-ui/index.html como una carga no vacía de dist/control-ui/assets/, para que no volvamos a publicar un panel de navegador vacío
• La verificación posterior a la publicación también comprueba que los puntos de entrada de Plugin publicados y los metadatos del paquete estén presentes en la disposición del registro instalada. Una release que publica cargas de runtime de Plugin faltantes falla el verificador postpublish y no puede promocionarse a latest.
• pnpm test:install:smoke también aplica el presupuesto de unpackedSize del empaquetado npm en el tarball de actualización candidato, de modo que el e2e del instalador detecte aumentos accidentales del tamaño del paquete antes de la ruta de publicación de release
• Si el trabajo de release tocó la planificación de CI, manifiestos de tiempos de extensiones o matrices de pruebas 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 release no describan una disposición de CI obsoleta
• La preparación para la release estable de macOS también incluye las superficies del actualizador:
  • la release 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 la publicación; el flujo de trabajo de publicación macOS lo confirma automáticamente, o abre un PR de appcast cuando el push directo está bloqueado
  • la app empaquetada debe mantener un bundle id no debug, una URL de feed de Sparkle no vacía y un CFBundleVersion igual o superior al piso canónico de build de Sparkle para esa versión de release

Entornos de prueba de lanzamiento

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

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

El asistente sube release-ci/<sha>-..., despacha Full Release Validation desde esa rama con ref=<sha>, verifica que cada headSha de flujo de trabajo hijo coincida con el objetivo y luego elimina la rama temporal. Esto evita validar por accidente una ejecución hija más reciente de main.

Para validar una rama o etiqueta de lanzamiento, ejecútalo desde la referencia de flujo de trabajo confiable main 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 flujo de trabajo resuelve la referencia objetivo, despacha el CI manual con target_ref=<release-ref> y luego despacha OpenClaw Release Checks. OpenClaw Release Checks distribuye pruebas smoke de instalación, comprobaciones de lanzamiento entre sistemas operativos, cobertura live/E2E de la ruta de lanzamiento 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 completa/all solo es aceptable cuando el resumen de Full Release Validation muestra normal_ci, plugin_prerelease y release_checks como correctos, salvo que una repetición enfocada haya omitido intencionadamente 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 lanzamiento pueda ver la ruta crítica actual sin descargar registros. Consulta Validación completa de lanzamiento para ver la matriz de etapas completa, los nombres exactos de trabajos del flujo de trabajo, las diferencias entre los perfiles estable y completo, artefactos y controles de repetición enfocada. Los flujos de trabajo hijos se despachan desde la referencia confiable que ejecuta Full Release Validation, normalmente --ref main, incluso cuando la ref objetivo apunta a una rama o etiqueta de lanzamiento anterior. No hay una entrada separada de referencia de flujo de trabajo de Full Release Validation; elige el arnés confiable eligiendo la referencia de ejecución del flujo de trabajo. No uses --ref main -f ref=<sha> para una prueba exacta de commit en main móvil; los SHA de commit sin procesar no pueden ser referencias de despacho de flujo de trabajo, así que usa pnpm ci:full-release --sha <sha> para crear la rama temporal fijada.

Usa release_profile para seleccionar la amplitud live/proveedor:

• minimum: ruta OpenAI/core live y Docker más rápida y crítica para el lanzamiento
• stable: minimum más cobertura estable de proveedores/backends para la aprobación del lanzamiento
• full: stable más cobertura amplia consultiva de proveedores/medios

La validación estable y completa siempre ejecuta el barrido exhaustivo live/E2E, de ruta de lanzamiento en Docker y acotado de supervivencia de actualización publicada 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 estables más las líneas base fijadas 2026.4.23 y 2026.5.2 más cobertura anterior de 2026.4.15, con líneas base duplicadas eliminadas y cada línea base fragmentada en su propio trabajo ejecutor de Docker.

OpenClaw Release Checks usa la referencia confiable del flujo de trabajo para resolver la referencia objetivo una vez como release-package-under-test y reutiliza ese artefacto en comprobaciones entre sistemas operativos, Package Acceptance y comprobaciones Docker de ruta de lanzamiento cuando se ejecuta soak. Esto mantiene todos los entornos orientados al paquete sobre los mismos bytes y evita compilaciones repetidas del paquete. Después de que una beta ya esté en npm, establece release_package_spec=openclaw@YYYY.M.PATCH-beta.N para que las comprobaciones de lanzamiento descarguen una vez el paquete publicado, extraigan su SHA de origen de compilación de dist/build-info.json y reutilicen ese artefacto para rutas entre sistemas operativos, Package Acceptance, Docker de ruta de lanzamiento y Telegram de paquete. La prueba smoke de instalación OpenAI entre sistemas operativos usa OPENCLAW_CROSS_OS_OPENAI_MODEL cuando la variable de repo/organización está definida; de lo contrario usa openai/gpt-5.4, porque este carril valida la instalación del paquete, el onboarding, el arranque del Gateway y un turno live de agente en lugar de medir el modelo predeterminado más lento. La matriz live de proveedores más amplia sigue siendo el lugar para la cobertura específica por modelo.

Usa estas variantes según la etapa del lanzamiento:

# 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 completo como primera repetición después de una corrección enfocada. Si falla un entorno, usa el flujo de trabajo hijo, trabajo, carril Docker, perfil de paquete, proveedor de modelo o carril QA que falló para la siguiente prueba. Ejecuta el paraguas completo otra vez solo cuando la corrección haya cambiado la orquestación compartida de lanzamiento o haya vuelto obsoleta la evidencia anterior de todos los entornos. El verificador final del paraguas vuelve a comprobar los id de ejecución de flujos de trabajo hijos registrados, así que después de repetir correctamente un flujo de trabajo hijo, repite solo el trabajo padre fallido Verify full validation.

Para recuperación acotada, pasa rerun_group al paraguas. all es la ejecución real de candidato de lanzamiento, ci ejecuta solo el hijo de CI normal, plugin-prerelease ejecuta solo el hijo de Plugin exclusivo de lanzamiento, release-checks ejecuta todos los entornos de lanzamiento, y los grupos de lanzamiento 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 completas/all usan el E2E canónico del paquete Telegram 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. Los fallos de QA release-check bloquean la validación normal del lanzamiento, incluida la deriva requerida de herramientas dinámicas de OpenClaw en el nivel estándar. Las ejecuciones alpha de Tideclaw todavía pueden tratar los carriles release-check que no sean de seguridad de paquete como consultivos. Cuando live_suite_filter solicita explícitamente un carril QA live 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 lugar de omitir el carril silenciosamente.

Vitest

El entorno Vitest es el flujo de trabajo hijo manual CI. El CI manual omite intencionadamente el acotamiento por cambios y fuerza el grafo de pruebas normal para el candidato de lanzamiento: fragmentos Linux Node, fragmentos de plugins incluidos, fragmentos de contratos de Plugin y canal, compatibilidad con Node 22, check-*, check-additional-*, comprobaciones smoke de artefactos compilados, comprobaciones de documentación, Skills de Python, Windows, macOS e i18n de Control UI. Android se incluye cuando Full Release Validation ejecuta el entorno porque el paraguas pasa include_android=true; el CI manual independiente requiere include_android=true para cobertura de Android.

Usa este entorno para responder "¿pasó el árbol de código fuente la suite normal completa de pruebas?" No es lo mismo que la validación de producto por ruta de lanzamiento. Evidencia que conservar:

• resumen de Full Release Validation que muestre la URL de ejecución de CI despachada
• ejecución de CI en verde sobre el SHA objetivo exacto
• nombres de fragmentos fallidos o lentos de los trabajos 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 CI manual directamente solo cuando el lanzamiento necesite CI normal determinista pero no los entornos Docker, QA Lab, live, entre sistemas operativos o de paquete. Usa el primer comando para CI directo sin Android. Añade include_android=true cuando el CI directo de candidato de lanzamiento deba cubrir Android:

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

Docker

El entorno Docker vive en OpenClaw Release Checks mediante openclaw-live-and-e2e-checks-reusable.yml, además del flujo de trabajo install-smoke en modo de lanzamiento. Valida el candidato de lanzamiento mediante entornos Docker empaquetados en lugar de solo pruebas a nivel de código fuente.

La cobertura Docker de lanzamiento incluye:

• prueba smoke de instalación completa con la prueba smoke lenta de instalación global de Bun habilitada
• preparación/reutilización de imagen smoke del Dockerfile raíz por SHA objetivo, con trabajos de QR, raíz/Gateway e instalador/Bun smoke ejecutándose como fragmentos install-smoke separados
• carriles E2E de repositorio
• fragmentos Docker de ruta de lanzamiento: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a, plugins-runtime-install-b, plugins-runtime-install-c, plugins-runtime-install-d, plugins-runtime-install-e, plugins-runtime-install-f, plugins-runtime-install-g y plugins-runtime-install-h
• cobertura de OpenWebUI dentro del fragmento plugins-runtime-services cuando se solicita
• carriles divididos de instalación/desinstalación de plugins incluidos bundled-plugin-install-uninstall-0 hasta bundled-plugin-install-uninstall-23
• suites de proveedores live/E2E y cobertura Docker de modelos live cuando las comprobaciones de lanzamiento incluyen suites live

Usa los artefactos de Docker antes de repetir. El planificador de ruta de lanzamiento sube .artifacts/docker-tests/ con registros de carriles, summary.json, failures.json, tiempos de fases, JSON del plan del planificador y comandos de repetición. Para recuperación enfocada, usa docker_lanes=<lane[,lane]> en el flujo de trabajo reusable live/E2E en lugar de repetir todos los fragmentos de lanzamiento. Los comandos de repetición generados incluyen package_artifact_run_id previo y entradas de imagen Docker preparada cuando estén disponibles, para que un carril fallido pueda reutilizar el mismo tarball y las imágenes GHCR.

QA Lab

El entorno QA Lab también forma parte de OpenClaw Release Checks. Es la compuerta de lanzamiento de comportamiento agentivo y nivel de canal, separada de Vitest y de la mecánica de paquetes Docker.

La cobertura de QA Lab de lanzamiento incluye:

• carril de paridad mock que compara el carril candidato OpenAI con la línea base Opus 4.6 usando el paquete de paridad agentiva
• perfil QA de Matrix live rápido usando el entorno qa-live-shared
• carril QA live de Telegram usando concesiones de credenciales Convex CI
• pnpm qa:otel:smoke, pnpm qa:otel:collector-smoke, pnpm qa:prometheus:smoke o pnpm qa:observability:smoke cuando la telemetría de lanzamiento necesita prueba local explícita

Usa este entorno para responder "¿se comporta correctamente el lanzamiento en escenarios QA y flujos de canales live?" Conserva las URL de artefactos para los carriles de paridad, Matrix y Telegram al aprobar el lanzamiento. La cobertura completa de Matrix sigue disponible como una ejecución manual fragmentada de QA-Lab en lugar del carril crítico predeterminado del lanzamiento.

Paquete

El entorno Package es la compuerta de producto instalable. Está respaldado por Package Acceptance y el resolvedor scripts/resolve-openclaw-package-candidate.mjs. El resolvedor 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 SHA-256, y mantiene la referencia del arnés de flujo de trabajo separada de la referencia de origen del paquete.

Fuentes de candidato admitidas:

• source=npm: openclaw@beta, openclaw@latest o una versión exacta de lanzamiento de OpenClaw
• source=ref: empaqueta una rama, etiqueta o SHA de commit completo package_ref de confianza 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 y trusted_source_id requeridos desde una política nombrada en .github/package-trusted-sources.json; usa esto para espejos empresariales propiedad de mantenedores o repositorios de paquetes privados en lugar de agregar a source=url una omisión de red privada a nivel de entrada
• source=artifact: reutiliza un .tgz cargado por otra ejecución de GitHub Actions

OpenClaw Release Checks ejecuta Package Acceptance con source=artifact, el artefacto de paquete de lanzamiento preparado, suite_profile=custom, docker_lanes=doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor update-restart-auth plugins-offline plugin-update, telegram_mode=mock-openai. Package Acceptance mantiene la QA de migración, actualización, reinicio de actualización con autenticación configurada, instalación en vivo de Skills de ClawHub, limpieza de dependencias obsoletas de plugins, fixtures de plugins sin conexión, actualización 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 se expande a cada línea base estable publicada en npm desde 2026.4.23 hasta latest, más fixtures de incidencias reportadas. Usa Package Acceptance con source=npm para un candidato ya publicado, source=ref para un tarball local de npm respaldado por SHA antes de publicar, source=trusted-url para un espejo empresarial/privado propiedad de mantenedores, o source=artifact para un tarball preparado cargado 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, el instalador y el comportamiento de plataforma específicos del sistema operativo, pero la validación de producto de paquete/actualización debe preferir Package Acceptance.

La lista de comprobación canónica para 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 prueba un cambio de instalación/actualización de plugin, limpieza de doctor o migración de paquete publicado. La migración exhaustiva de actualización publicada desde cada paquete estable 2026.4.23+ es un flujo de trabajo manual Update Migration separado, no parte de Full Release CI.

La tolerancia heredada de package-acceptance está limitada intencionalmente en el tiempo. Los paquetes hasta 2026.4.25 pueden usar la ruta de compatibilidad para brechas de metadatos ya publicadas en npm: entradas privadas de inventario de QA faltantes en el tarball, falta de gateway install --wrapper, archivos de parche faltantes 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 del marketplace y migración de metadatos de configuración durante plugins update. El paquete publicado 2026.4.26 puede advertir por archivos de sello de metadatos de compilación local que ya se publicaron. Los paquetes posteriores deben cumplir los contratos de paquete modernos; esas mismas brechas fallan la validación de lanzamiento.

Usa perfiles más amplios de Package Acceptance cuando la pregunta de lanzamiento trate 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 en vivo de Skills de ClawHub; 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 repeticiones enfocadas

Para prueba de Telegram de 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 aún acepta una especificación de npm publicada para comprobaciones posteriores a la publicación.

Automatización regular de publicación de lanzamientos

Para publicación beta, latest, de plugins, GitHub Release y 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 de confianza en el orden que el lanzamiento necesita:

1. Extraer la etiqueta de lanzamiento y resolver su SHA de commit.
2. Verificar que la etiqueta sea alcanzable desde main o release/*.
3. Ejecutar pnpm plugins:sync:check.
4. Despachar Plugin NPM Release con publish_scope=all-publishable y ref=<release-sha>.
5. Despachar Plugin ClawHub Release con el mismo alcance y SHA.
6. Despachar OpenClaw NPM Release con la etiqueta de lanzamiento, dist-tag de npm y preflight_run_id guardado después de verificar el full_release_validation_run_id guardado.
7. 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 por el candidato, y verificar los artefactos canónicos de 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 al dist-tag beta predeterminado:

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 trabajo enfocado de reparación o republicación. OpenClaw Release Publish rechaza plugin_publish_scope=selected cuando publish_openclaw_npm=true para que el paquete central no pueda publicarse sin cada plugin oficial publicable, 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 directamente el flujo de trabajo hijo.

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 o v2026.4.2-beta.1; cuando preflight_only=true, también puede ser el SHA de commit completo actual de 40 caracteres de la rama del flujo de trabajo para preflight solo de validación
• preflight_only: true solo para validación/compilación/paquete, false para la ruta de publicación real
• preflight_run_id: requerido en la ruta de publicación real para que el flujo de trabajo reutilice el tarball preparado de la ejecución de preflight exitosa
• full_release_validation_run_id: requerido para publicación mensual real de extended-stable y regular no beta, para que el flujo de trabajo autentique la ejecución de validación exacta
• npm_dist_tag: etiqueta de destino de npm para la ruta de publicación; acepta alpha, beta, latest o extended-stable y el valor predeterminado 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 de vuelta.

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 de preflight exitosa 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 de lanzamiento exacta no preliminar de openclaw/openclaw-windows-node; requerida para publicación estable de OpenClaw
• windows_node_installer_digests: mapa JSON compacto aprobado por el candidato de los nombres actuales de instaladores de Windows a sus resúmenes sha256: fijados; requerido para publicación estable de OpenClaw
• npm_dist_tag: etiqueta de destino de npm para el paquete OpenClaw
• plugin_publish_scope: predeterminado all-publishable; usa selected solo para trabajo enfocado de reparación solo de plugins con publish_openclaw_npm=false
• plugins: nombres de paquetes @openclaw/* separados por comas cuando plugin_publish_scope=selected
• publish_openclaw_npm: predeterminado true; establece false solo al usar el flujo de trabajo como orquestador de reparación solo de plugins
• wait_for_clawhub: predeterminado false para que la disponibilidad de npm no quede 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 que contienen secretos requieren que el commit resuelto sea alcanzable desde una rama de OpenClaw o una etiqueta de lanzamiento.
• run_release_soak: optar por soak exhaustivo en vivo/E2E, ruta de lanzamiento de Docker y upgrade-survivor desde todos los paquetes para comprobaciones de lanzamiento beta. Se fuerza con 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 se rechazan las versiones con sufijo de corrección en ese límite.
• Las etiquetas de prelanzamiento beta solo pueden publicarse en beta
• 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 el preflight; el flujo de trabajo verifica que los metadatos antes de publicar sigan coincidiendo

Secuencia regular de lanzamiento estable beta/latest

Esta secuencia heredada es para el lanzamiento orquestado regular que también posee plugins, GitHub Release, Windows y otro trabajo de plataforma. No es la ruta mensual .33+ de extended-stable solo para npm documentada al inicio de esta página.

Al preparar un lanzamiento estable orquestado regular:

1. Ejecuta OpenClaw NPM Release con preflight_only=true
   • Antes de que exista una etiqueta, puedes usar el SHA actual completo del commit de la rama del workflow para una ejecución de prueba de solo validación del workflow de preflight
2. Elige npm_dist_tag=beta para el flujo normal de beta primero, o latest solo cuando quieras intencionalmente una publicación estable directa
3. Ejecuta Full Release Validation en la rama de lanzamiento, la etiqueta de lanzamiento o el SHA completo del commit cuando quieras CI normal más cobertura de caché de prompts en vivo, Docker, QA Lab, Matrix y Telegram desde un único workflow manual
4. Si intencionalmente solo necesitas el grafo de pruebas normal determinista, ejecuta el workflow manual CI en la referencia de lanzamiento en su lugar
5. Selecciona la etiqueta exacta de lanzamiento no preliminar de openclaw/openclaw-windows-node cuyos instaladores x64 y ARM64 firmados deben distribuirse. Guárdala como windows_node_tag, y guarda su mapa de resúmenes validado como windows_node_installer_digests. El asistente de candidato de lanzamiento registra ambos y los incluye en su comando de publicación generado.
6. Guarda los preflight_run_id y full_release_validation_run_id correctos
7. Ejecuta OpenClaw Release Publish con el mismo tag, el mismo npm_dist_tag, el windows_node_tag seleccionado, su windows_node_installer_digests guardado, el preflight_run_id guardado y el full_release_validation_run_id guardado; publica los plugins externalizados en npm y ClawHub antes de promover el paquete npm de OpenClaw
8. Si el lanzamiento llegó a beta, usa el workflow openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml para promover esa versión estable de beta a latest
9. Si el lanzamiento se publicó intencionalmente directamente en latest y beta debe seguir inmediatamente la misma compilación estable, usa ese mismo workflow de lanzamiento para apuntar ambos dist-tags a la versión estable, o deja que su sincronización programada de autorrecuperación mueva beta más tarde

La mutación de dist-tag vive en el repositorio del registro de lanzamientos porque todavía requiere NPM_TOKEN, mientras que el repositorio fuente conserva una publicación solo con OIDC.

Eso mantiene documentadas y visibles para el operador tanto la ruta de publicación directa como la ruta de promoción con beta primero.

Si un mantenedor debe recurrir a la autenticación local de npm, ejecuta cualquier comando de la CLI (op) de 1Password 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 los prompts, las alertas y el manejo de OTP sean observables y evita alertas repetidas del host.

Referencias públicas

• .github/workflows/full-release-validation.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-npm-release.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• scripts/resolve-openclaw-package-candidate.mjs
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

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

Relacionado

• Canales de lanzamiento