Actualización del Changelog de OpenClaw

¿Qué hace Actualización del Changelog de OpenClaw?

Úselo para reescrituras del changelog y texto fuente de notas de lanzamiento de GitHub. Para lanzamientos beta/estables regulares, prepare notas completas antes de la calificación final cuando sea posible; el SHA del código puede coincidir con el SHA del lanzamiento. El trabajo editorial puede superponerse con la validación del código. No lo ejecute de nuevo por cada retroportación de recuperación de validación; cuando las retroportaciones reemplacen el SHA del código, ejecútelo una vez después de que el SHA final del código esté en verde, como un descendiente genuino solo del CHANGELOG bajo la política de reutilización de evidencia del producto existente (sincronización). Para soporte extendido, ejecútelo antes de la validación y etiquetado final del HEAD exacto. No lo ejecute de nuevo para reintentos de herramientas, reanudación de publicación o promoción. Úselo con release-openclaw-maintainer; este skill es propietario del contenido, orden, agrupación y disciplina de atribución del changelog.

Objetivo

Reconstruir la sección de lanzamiento objetivo CHANGELOG/<version>.md a partir de un manifiesto de historial completo y generado, no de notas borrador obsoletas. Producir notas de lanzamiento agrupadas y orientadas al usuario, ordenadas por interés del usuario, preservando cada referencia relevante de issue/PR y cada atribución humana Thanks @....

CHANGELOG.md es el índice de lanzamiento generado. El propietario compartido scripts/lib/release-changelog.mjs resuelve secciones de lanzamiento y registros de contribución desde un árbol de trabajo o una referencia de Git fijada, incluyendo referencias históricas que aún contienen un monolito. Use node scripts/release-changelog.mjs read --version <version> [--ref <sha-o-tag>] para una sección, o agregue --record para su registro de contribución. Un artefacto dividido faltante no debe recurrir al índice raíz. Los lanzamientos históricos sin registros no obtienen procedencia inventada. Los archivos generados CHANGELOG/** retienen bytes migrados o reflejados exactos y se excluyen del formateo genérico, como el changelog raíz. Valídelos a través de su propietario con pnpm changelog:check.

Los escritos actuales usan el diseño dividido. Para guardar una sección inicial completa, use node scripts/release-changelog.mjs write --version <version> --file <section.md>; actualiza la entrada de lanzamiento, coincidiendo con CHANGELOG/records/<version>.md cuando esté presente, y el índice juntos. La generación inicial retiene el formato de sección a continuación. Los espejos de documentación publicados siguen la ruta posterior al lanzamiento al final de este skill; la generación inicial nunca debe sobrescribirlos.

Entradas

• Versión objetivo: YYYY.M.PATCH-beta.N exacto para un delta beta; YYYY.M.PATCH para notas estables acumulativas. Las entradas y registros beta son artefactos separados congelados, nunca copias de la sección base estable.
• Etiqueta base beta: capture la versión actualmente seleccionada por el npm público openclaw@beta antes de la publicación, no el último prerelease de GitHub ni la versión beta más alta con sufijo. El selector puede nombrar una versión estable también seleccionada por latest. Omita --base (o use --base npm-beta) con una versión beta exacta para resolverla una vez; preserve la etiqueta resuelta del manifiesto generado y reutilice ese --base explícito para ediciones, verificación y recuperación. Si npm ya selecciona el candidato o una versión más nueva, la generación se niega a adivinar el estado histórico del selector; proporcione la etiqueta capturada previamente. Cuando esa etiqueta no es un ancestro (por ejemplo, un cierre estable forward-port), el verificador usa su base de fusión alcanzable y resta el registro acumulativo de PR de la etiqueta enviada capturada a través de la semántica --shipped-ref. El manifiesto y el registro retienen ambos límites; reproduzca con la etiqueta capturada para resolver el mismo rango, nunca seleccione una beta anterior de GitHub en su lugar.
• Etiqueta base estable: última etiqueta de lanzamiento estable enviada y alcanzable. Debe ser un ancestro del objetivo; una etiqueta más nueva pero divergente no es un límite de historial válido. Use un SHA explícito de envío/cierre principal solo cuando también sea alcanzable desde el objetivo.
• Referencia objetivo: el historial exacto de producto completo que se documenta. El objetivo de su registro de contribución debe ser un ancestro del objetivo de lanzamiento final; no necesita nombrar un commit de changelog aún no creado. Incluya cualquier corrección posterior antes de finalizar las notas. Las notas finales pueden ser cometidas antes de la calificación, o después como un descendiente solo del CHANGELOG de un SHA de código verde.
• Referencia principal canónica: origin/main actual, obtenido antes de la verificación. Las notas de lanzamiento citan el PR principal fusionado original cuando el mismo trabajo es transportado por una retroportación. Un PR de rama de lanzamiento se usa solo mientras no exista un forward-port en el main actual.

Flujo de trabajo

1. Confirme la rama de lanzamiento y el objetivo de historial exacto:

   • git fetch --tags origin
   • confirme limpio git status -sb
   • registre git rev-parse HEAD como el objetivo de historial
   • registre el id de ejecución y el intento de Validación de Lanzamiento Completo si la calificación ya existe
   • termine los cambios pendientes de producto/versión/retroportación antes de congelar la fuente final; actualice el inventario para cambios reales

2. Audite el historial, incluyendo commits directos:

   • git log --topo-order --date=iso-strict --pretty=format:'%h%x09%ad%x09%s' <base-tag>..<target-ref>
   • git log --topo-order --grep='(#' --date=short --pretty=format:'%h%x09%ad%x09%s' <base-tag>..<target-ref>
   • Incluya cada commit alcanzable desde el objetivo pero no desde la base, incluyendo ramas laterales fusionadas. Resuelva las asociaciones de PR antes de deduplicar y restar registros enviados; retenga las exclusiones de reversión existentes.
   • también inspeccione --since='24 hours ago' cuando el main se movió durante el lanzamiento.

3. Genere el registro de contribución completo y el manifiesto editorial antes de escribir prosa agrupada:

   node --import tsx .agents/skills/openclaw-changelog-update/scripts/verify-release-notes.mjs \
     --base <base-tag> \
     --target <target-ref> \
     --main-ref origin/main \
     --version <YYYY.M.PATCH> \
     --manifest /tmp/openclaw-release-<YYYY.M.PATCH>.json \
     --write-ledger
   

   Para generación beta, use --version YYYY.M.PATCH-beta.N y omita --base en la primera ejecución de inventario. Inicie una sección de versión exacta con Destacados, Cambios y Correcciones usando el escritor compartido; genere el manifiesto delta, luego escriba prosa solo para ese rango. Las ejecuciones posteriores usan la etiqueta base npm capturada explícitamente (no solo el SHA de base de fusión de un rango divergente). No consulte npm nuevamente después de la publicación ni sobrescriba la entrada estable acumulativa. Regenera notas estables acumulativas en la preparación estable.

   Agregue entradas repetibles --release-provenance '<40sha> -> #PR[, #PR]' cuando los commits de lanzamiento no puedan transportar metadatos de procedencia. Estos usan la misma gramática de marcador exacto y validación de main actual que los marcadores de cuerpo de commit.

   El verificador reutiliza automáticamente las respuestas públicas de GraphQL de GitHub a partir de una instantánea SHA base/objetivo exacta bajo los metadatos git del árbol de trabajo. Las reescrituras iterativas en el mismo objetivo evitan el descubrimiento repetido de red. Use --refresh-github-snapshot después de datos de API sospechosos, --github-snapshot <path> para un artefacto explícito, o --no-github-snapshot para una auditoría solo en vivo. Los cuerpos de lanzamiento de GitHub siempre se leen en vivo. Las referencias explícitas CI #, CI run #, Actions run # y workflow run # en fuente activa se clasifican por separado solo cuando la resolución de issue/PR falla y una búsqueda en vivo de Actions del mismo repositorio confirma el ID de ejecución exacto. Cualquier ocurrencia ordinaria de ese número en la fuente activa, notas o el registro de contribución sigue siendo un requisito estricto de issue/PR. Las ejecuciones confirmadas aparecen como workflowRuns en la salida de verificación y el manifiesto, nunca como asociaciones de PR o crédito de contribuyente. Solo las referencias NOT_FOUND de GitHub confinadas al texto de cuerpo de commit contextual, ausentes de asuntos, referencias de cierre, procedencia y notas/registros, y por debajo del número resuelto más alto pueden omitirse e informarse como unavailableReferences del manifiesto sin crédito.

   • el manifiesto es la entrada requerida para la reescritura, no una auditoría posterior al hecho; contiene cada PR referenciado, crédito de contribuyente elegible, contexto de issue en línea, cada commit directo y una clasificación de elegibilidad editorial para PRs y commits directos
   • la versión 3 del esquema es el contrato de manifiesto efímero requerido. Regenera manifiestos antiguos; la versión 2 no es un límite de lector descendente compatible
   • para un backfill histórico, agregue --seed-ref <pre-backfill-ref> una vez para que los registros de contribución del changelog anterior se retengan incluso cuando un commit fusionado anterior omitió su número de PR; el verificador excluye registros de trabajo revertido después de la etiqueta base, incluyendo trabajo beta revertido antes del lanzamiento estable
   • la procedencia generada informa PRs dentro del rango por separado de los PRs solo de semilla retenidos, luego indica el total de filas único. Un PR presente en ambos inventarios cuenta como dentro del rango; nunca describa el total inclusivo de semillas como trabajo fusionado en el rango de lanzamiento actual
   • agregue --shipped-ref <prior-shipped-tag> repetible cuando el cierre principal alcanzable difiera de la etiqueta enviada o commits posteriores de forward-port reasocien PRs que ya fueron lanzados. Cada etiqueta es un límite enviado acumulativo: el verificador une filas de PR explícitas de registros de contribución completos en secciones de lanzamiento numeradas, excluye solo PRs superpuestos e ignora Unreleased. Nunca infiera este límite del SHA base, la prosa objetivo o el registro objetivo. El manifiesto y la procedencia generada retienen cada etiqueta más el inventario exacto de PR excluido y el recuento para la validación determinista del candidato
   • el descubrimiento de PR fuente limita las asociaciones de commit de GitHub al historial objetivo seleccionado, o al historial principal congelado para transportadores canónicos. Una referencia fuente contextual se convierte en una contribución solo cuando su commit fusionado es alcanzable en el historial objetivo y su tiempo de fusión está dentro del objetivo. Mantenga todas las referencias resolubles, pero no promueva PRs no relacionados simplemente porque se fusionan mientras la preparación del lanzamiento continúa. Las semillas explícitas retienen su membresía histórica y permanecen solo de semilla a menos que se prueben independientemente dentro del rango. Resuelva cada página de asociación; los contratos canónicos, cherry-pick y de procedencia existentes siguen siendo autoritativos.
   • las reversiones explícitas de múltiples commits requieren un asunto de reversión y una declaración independiente Reverts <SHA completo> y <SHA completo>. (las listas separadas por comas con y final también funcionan). El final exacto para restaurar el comportamiento anterior. es aceptado. Las declaraciones duplicadas, abreviadas, incrustadas o repetidas no establecen la reversión. Cada commit nombrado debe ser un ancestro de un solo padre, y la aplicación inversa de todos los parches nombrados debe reproducir el árbol de reversión completo. Las declaraciones reconocidas que fallan esta prueba detienen la verificación. La prueba utiliza almacenamiento privado de índice/objeto de Git sin enganches ni diffs externos; la contabilidad canónica de reversión única y reversión de reversión permanece intacta.
   • canonicalice las retroportaciones al PR fusionado original en main: los orígenes explícitos de cherry-pick ganan, luego una coincidencia única de asunto normalizado requiere el mismo autor y una ruta modificada superpuesta. Suprima los PRs de lanzamiento/retroportación siempre que el PR principal correspondiente exista en origin/main actual. Mantenga un PR de rama de lanzamiento solo cuando ese cambio aterrizó allí primero y aún no ha sido forward-porteado a main
   • lea el manifiesto antes de editar ### Destacados, ### Cambios o ### Correcciones; no lleve prosa agrupada antigua sin re-auditarla
   • inspeccione PRs/issues o diffs vinculados para commits ambiguos. Los commits directos son entrada editorial, no filas de libro mayor público; infiera resultados materiales para el usuario del asunto, cuerpo, archivos tocados, pruebas y commits cercanos

4. Reescriba solo una sección de lanzamiento seleccionada:

   • beta: ## YYYY.M.PATCH-beta.N, que contiene solo cambios desde la línea base npm beta capturada
   • estable: ## YYYY.M.PATCH, acumulativo desde la línea base estable anterior
   • no deje una sección obsoleta ## No liberado arriba del lanzamiento objetivo
   • si No liberado contiene notas vinculadas al lanzamiento, incorpórelas en la sección objetivo en lugar de eliminarlas

5. Forma de la sección:

   • ### Destacados: 5-8 viñetas para estable, 0-8 para un delta beta; no invente destacados para betas pequeñas de corrección rápida
     • incluya solo una capacidad clara visible para el usuario o un desbloqueo de flujo de trabajo, una corrección material de fiabilidad/seguridad, una mejora amplia en múltiples superficies o un hito de integración/compatibilidad que defina el lanzamiento
     • cada destacado debe decir qué cambió para un usuario en una oración; use una historia de usuario por viñeta y agrupe sus PRs de soporte
     • excluya pruebas, CI, refactorizaciones, documentación, cambios de catálogo y detalle de implementación a menos que el resultado sea una instalación/actualización material, seguridad de datos o una mejora de usuario ampliamente visible
   • ### Cambios: nuevas capacidades y cambios de comportamiento
   • ### Correcciones: correcciones orientadas al usuario primero, agrupadas por impacto y superficie
   • agrupe cambios/correcciones relacionados por superficie e impacto en el usuario; evite una viñeta por commit pequeño cuando varios commits cuenten una historia orientada al usuario
   • ### Registro de contribución completo: registro generado primero por PR después de la prosa agrupada; es la superficie de contabilidad exhaustiva, no un segundo resumen de lanzamiento

6. Preserve la atribución:

   • mantenga #issue, (#PR), Corrige #... y Gracias @...
   • cada PR fusionado de autor humano representado por una entrada orientada al usuario necesita su ref de PR y Gracias @autor, incluso cuando el PR no tuvo un issue vinculado
   • cada reportero de issue humano para un Corrige #... o issue de error referenciado representado por una entrada orientada al usuario necesita Gracias @reportero a menos que el mismo identificador ya esté agradecido en esa viñeta
   • cada contribuyente Co-escrito por humano en trabajo orientado al usuario representado necesita Gracias @identificador cuando se conoce un identificador de GitHub
   • cuando agrupe múltiples PRs/issues en una viñeta, incluya cada ref de PR/issue relevante y cada humano

...[truncado para traducción]