verify-release

Verify Release

Úsalo cuando se pregunte si una versión de OpenClaw está completamente lanzada, publicada, promocionada, probada con smoke tests o verificada en vivo. Esta es una habilidad de verificación, no de publicación; usa $release-openclaw-maintainer antes de cambiar el estado de la release.

Reglas

• Resuelve sufijos cortos como .27 a la versión CalVer concreta a partir de la fecha/contexto actual, luego di la versión resuelta.
• Resuelve el track primero. Ambos tracks usan el libro de contabilidad de evidencia de GitHub Release compartido. Regular beta/stable también usa el grafo de la plataforma; extended-stable usa su rama canónica, selector npm y superficies de Gateway. No exijas artefactos nativos o de ClawHub de un track al otro.
• Verifica el estado en vivo. No confíes en el estado del checkout local, las notas de la release o la memoria antigua como verdad actual.
• Si el checkout está sucio o divergente, úsalo solo para scripts/referencia. Para los metadatos de versión, obténlos de GitHub release/tag o desempaqueta el tarball del tag en /tmp.
• Nunca imprimas secretos. Usa las claves vivas heredadas solo para comandos de smoke test acotados.
• Mantén el resultado final escueto: sí/no, viñetas de evidencia, caveats, limpieza.

Comprobaciones de regular beta/stable

Usa estas comprobaciones solo para el track de release orquestado regular.

1. GitHub Release:
   • gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
   • Confirma que las releases estables no sean draft/prerelease.
   • Confirma que el cuerpo de la release tenga enlaces de evidencia npm, CI, plugin npm, ClawHub, mac/appcast cuando se esperen.
   • Confirma que los activos esperados para releases estables de mac estén subidos: zip, dmg, dSYM, evidencia de dependencias, manifiesto de validación completa inmutable, evidencia post-publicación y manifiesto de cierre de stable-main.
   • Descarga cada activo de evidencia inmutable y su acompañante .sha256, luego verifica el checksum antes de confiar en el registro de la release.
2. npm raíz:
   • npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
   • latest debe ser igual a <VERSION> para stable.
   • Registra tarball, integridad, hora de publicación.
   • Confirma que la evidencia post-publicación de la release registre npmRegistrySignaturesVerified: true y npmProvenanceAttestationMatched: true.
3. Conjunto de publicación de plugins:
   • Obtén los metadatos exactos del tag desde GitHub, no del checkout local cuando esté sucio: descarga https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION> en /tmp/openclaw-v<VERSION>-src.
   • Deriva el conjunto completo esperado de paquetes npm y ClawHub para el track de release con los planificadores/colectores de publicación canónicos a partir del SHA de Tooling registrado en la release, usando los metadatos exactos del tag. No cuentes las banderas de publicación en bruto: openclaw.build.bundledDist === true difiere explícitamente la publicación externa incluso cuando las banderas de publicación están configuradas. Registra los nombres de los paquetes diferidos y sus razones por separado.
   • Reconcilla las identidades, versiones y cantidades esperadas de paquetes entre la publicación original, las versiones publicadas previamente y las ejecuciones de recuperación seleccionadas usando planes de publicación inmutables, lectura del registro y trabajos del flujo de trabajo. Un subconjunto de recuperación seleccionado no debe reducir el conjunto completo esperado de la release: gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate.
   • Cada plugin npm esperado debe tener la versión <VERSION> y dist-tags.latest === <VERSION>.
4. ClawHub:
   • Verifica la conclusión del flujo de trabajo de Plugin ClawHub Release y el recuento de trabajos de publicación.
   • Usa el propio OpenClaw para la prueba en vivo del registro: openclaw plugins search <known-plugin> --json.
   • Instala un plugin oficial en la versión de release exacta solicitada desde ClawHub en un HOME aislado: openclaw plugins install clawhub:@openclaw/matrix@<VERSION>. Prefiere matrix a menos que ese plugin no esté en el conjunto esperado. Las versiones de ClawHub pertenecen al spec; --pin solo es compatible con instalaciones npm.
5. Flujos de trabajo de release:
   • Verifica las conclusiones de los enlaces de evidencia de las notas de release: Full Release Validation, OpenClaw Release Checks, OpenClaw NPM Release, Plugin NPM Release, Plugin ClawHub Release, mac preflight/validation/publish cuando se esperen activos estables de mac.
   • Para stable, verifica que OpenClaw Stable Main Closeout haya tenido éxito y que su manifiesto registre el tag de release coincidente, el drill de rollback actual, el soak estable y la evidencia de rendimiento bloqueante.
   • Resume solo los trabajos relevantes exitosos/fallidos; ignora los carriles opcionales omitidos de forma rutinaria a menos que el cuerpo de la release los haya prometido.

Comprobaciones de extended-stable

Extended-stable tiene un GitHub Release con evidencia de release compartida pero sin artefactos nativos ni de ClawHub. Verifícalo junto con el tag en vivo, el flujo de trabajo, el registro, la procedencia y el estado de la imagen.

1. Identidad: exige el v<VERSION> final en el parche 33+, sin sufijo, contenido en extended-stable/YYYY.M.33. Solo un candidato activo debe ser igual al tip. La raíz y cada plugin oficial publicable deben declarar <VERSION>. Exige el tag Git y un GitHub Release público y no preliminar cuyo título y cuerpo canónico coincidan con el tag. Exige isLatest=false, la evidencia de dependencias, el manifiesto inmutable de Full Release Validation, la evidencia post-publicación y sus checksums. No exijas activos nativos ni de ClawHub.
2. Cadena de flujo de trabajo: encuentra la ejecución de release padre exitosa más sus ejecuciones hijas de preflight, validación completa, plugin npm y publicación del núcleo. Exige un padre protegido release-publish/* y un productor de validación canónico release-ci/* con verificación de procedencia SHA del flujo de trabajo. La validación debe usar rerun_group=all, release_profile=stable, soak/rendimiento bloqueantes y el intento guardado. La publicación del núcleo debe hacer referencia a los tres ID de ejecución y vincular su manifiesto, ref de flujo de trabajo y digest del tarball al SHA de la release.
3. Registro: exige que los selectores exacto y extended-stable devuelvan <VERSION> para la raíz, cada entrada corePackageTarballs de preflight y cada plugin oficial con publishToNpm === true derivado del tag. Compara el plan de plugins, los trabajos y la lectura completa; nunca infieras el inventario a partir de diffs.
4. Procedencia: desde las herramientas actuales de confianza, ejecuta node --import tsx scripts/openclaw-npm-postpublish-verify.ts <VERSION>. Exige firmas, procedencia de rama canónica y vinculación del digest de publicación/preflight con el SHA de la release. Conserva la salida y las URL del flujo de trabajo.
5. Docker: verifica las imágenes exactas default, slim, browser y de arquitectura, y sus atestaciones en ambos registros. Solo los tres alias extended-stable* pueden resolverse a esos digests. Exige la ejecución padre exitosa de OpenClaw Release Publish y su verificación Docker completada. La ruta normal finaliza después; una ruta rápida solicitada explícitamente puede activar GitHub primero. Repara los alias a través de Docker Channel Promotion del main actual para el tag exacto, sin reconstruir.
6. Recuperación: nunca republices. Usa promote_extended_stable en el flujo de trabajo de dist-tag openclaw/releases para el selector raíz (un parche final 33+ sin sufijo) y herramientas aisladas de credenciales aprobadas para otros, luego repite la lectura completa. No exijas ClawHub, aplicaciones nativas/móviles, sitio web, dist-tags privados ni latest regular. Exige evidencia de release compartida, pero no exijas activos nativos regulares ni de ClawHub.

Smoke tests en vivo compartidos

Después de que las comprobaciones de publicación específicas del track pasen:

1. Smoke del paquete publicado:
   • En /tmp, HOME aislado: npm exec --yes --package openclaw@<VERSION> -- openclaw --version.
   • Ejecuta al menos un comando inofensivo que toque la superficie CLI publicada, por ejemplo plugins --help o gateway --help.
2. Smoke del modelo vivo de Dev Gateway:
   • Usa HOME/workspace temporal, no el estado normal del usuario: HOME=/tmp/openclaw-release-smoke/home OPENCLAW_WORKSPACE=/tmp/openclaw-release-smoke/work pnpm openclaw --dev gateway run --auth none --force --verbose.
   • Resuelve el puerto enlazado del Gateway lanzado desde su salida de inicio o registro.
   • Para --auth none, exige que GET http://127.0.0.1:<PORT>/healthz no autenticado devuelva HTTP 200 con el objeto JSON exacto {"ok":true,"status":"live"}.
   • Reserva gateway health --json para smoke test intencionalmente con credenciales o emparejado con dispositivo, pasando la credencial explícita requerida por ese Gateway.
   • Ejecuta un turno de agente respaldado por Gateway con OPENAI_API_KEY heredada, prompt corto, clave de sesión explícita, salida JSON y un modelo conocido como disponible.
   • Si el modelo predeterminado configurado falla por no estar disponible, registra ese caveat y reintenta con el modelo OpenAI más nuevo conocido como bueno en lugar de declarar que la release falló.
   • Detén el gateway y verifica que el puerto no esté escuchando.

Caveats a reportar

• Caveat de dist-tag: el latest estable es la verdad de la release; si los mirrors opcionales de beta todavía apuntan a una versión beta, repórtalo como un caveat, no como un bloqueador de la release estable, a menos que el usuario haya solicitado verificar la promoción beta.
• Caveat de track: nombra el track y las superficies intencionalmente ausentes. No llames a la falta de artefactos de release regular como un fallo de extended-stable.
• Caveat de checkout divergente: di cuándo el SHA local del código fuente difiere del tag de release o del origen y qué fuentes en vivo se usaron en su lugar.
• Caveat de smoke: distingue el éxito del agente respaldado por Gateway del fallback local embebido. Un smoke test en vivo válido con auth-none tiene el resultado exacto de /healthz más un turno exitoso del agente respaldado por Gateway y el ID de registro/ejecución del Gateway para esa llamada.