release-openclaw-announcement

Anuncio de lanzamiento de OpenClaw

Usar con release-openclaw-maintainer después de que un lanzamiento esté activo. Usar con $discord-user-post al publicar realmente en Discord como el usuario conectado.

Evidencia primero

Antes de redactar áreas de enfoque, lee la evidencia real del lanzamiento:

1. El cuerpo de la release de GitHub y el tag inmutable; para extendido-estable, confirma también el ámbito solo npm/contenedor y la clasificación no-Latest.
2. El CHANGELOG/<version>.md de la versión base lanzada y el registro de contribuciones, resuelto con node scripts/release-changelog.mjs read --version <version> [--ref <sha-or-tag>] (añade --record para contabilidad). El resolvedor compartido lee tags monolíticos históricos; el CHANGELOG.md actual es un índice. Tras la publicación aprobada de la documentación, lee el mirror completo de la documentación y el registro congelado en lugar de tratar el cuerpo compacto de GitHub como notas completas.
3. Commits desde la versión enviada anterior o la base especificada por el operador.
4. Metadatos del registro/paquete para la versión exacta y el dist-tag actual.
5. Estado de validación relevante para la confianza del usuario.

No afirmes una auditoría completa del changelog a menos que la hayas realizado. Si solo lees las notas de lanzamiento generadas o una sección seleccionada del changelog, dilo y audita adecuadamente o redacta con esa limitación.

Para áreas de enfoque beta, prioriza los cambios observables por el usuario sobre los mecanismos internos de prueba o CI:

• rutas de instalación/actualización
• comportamiento específico del SO/plataforma
• inicio/reinicio de Gateway, configuración y comportamiento en tiempo de ejecución
• enrutamiento de proveedor/modelo/tiempo de ejecución
• carga de plugins y desarrollo local de plugins
• canales y rutas multimedia
• correcciones de seguridad/pérdida de datos/impacto al usuario

No permitas que las correcciones tardías de la rama de lanzamiento dominen automáticamente el anuncio. Si la versión incluye un delta grande respecto a la versión enviada anterior, clasifica las áreas de enfoque según el delta total del lanzamiento y el impacto esperado en el usuario; menciona las correcciones tardías en su categoría natural.

Copia requerida

Cada anuncio beta debe hacer explícito el estado beta e incluir:

• la versión exacta, p. ej., OpenClaw 2026.5.25-beta.1
• una frase de marco de riesgo de una oración: beta, útil para pruebas, no promoción estable
• áreas de prueba enfocadas derivadas de la evidencia, no de suposiciones
• comando de actualización promovido cerca de la parte superior:

  openclaw update --channel beta --yes
  openclaw --version
  

• ruta de instalación nueva: Instalar desde https://openclaw.ai
• enlace a la release de GitHub
• nota de validación concisa, sin convertir la CI en el titular

No sugieras comandos de instalación npm en anuncios beta a menos que el operador lo solicite explícitamente para copia específica de npm o texto de solución de problemas. Está bien usar los metadatos del registro como evidencia; no conviertas eso en una guía de instalación pública.

Para anuncios estables, usa la redacción del canal estable:

openclaw update --channel stable --yes
openclaw --version

Las instalaciones nuevas siguen apuntando a https://openclaw.ai.

Para extendido-estable, nombra la versión exacta y el mes final. Menciona solo backports observables, y usa:

openclaw update --channel extended-stable
openclaw --version

No añadas --yes: los usuarios que migran desde estable regular más nuevo deben ver la advertencia de degradación porque las versiones anteriores pueden no entender la configuración más nueva. Enlaza la Release de GitHub, pero no heredes afirmaciones sobre macOS, Windows, ClawHub, latest o sitio web del estable regular.

Estilo

• Markdown de Discord, sin tablas.
• Mantenlo escaneable: introducción corta, viñetas, comandos, enlaces.
• Lidera con lo que los usuarios pueden sentir o probar, no con la plomería de prueba.
• Menciona la validación solo después de las instrucciones de instalación/actualización.
• Sé específico sobre dónde es útil la retroalimentación.
• No menciones rutas de prueba local privadas en anuncios públicos.
• No exageres plataformas, canales o comportamiento de proveedores no verificados.

Publicación

Cuando se te pida publicar, usa $discord-user-post para operar la aplicación de escritorio de Discord conectada como el usuario. Resuelve y verifica visiblemente el servidor/canal exacto, inspecciona el cuerpo final y solicita confirmación en el momento de la acción antes de ingresar o enviarlo. Nunca uses envíos de canal de OpenClaw, bots, webhooks, relays o tokens.