Prompt-Motion/ReaReverse

Actualización de changelog REA

Utilícelo para la preparación de notas de publicación y atribución de colaboradores. Lea docs/releasing.md desde la raíz del repositorio para conocer la autoridad de publicación y las comprobaciones de checkpoint existentes. Esta habilidad prepara notas; no autoriza fusiones, etiquetado ni publicación.

Inventario antes de la prosa

Obtenga el historial completo y las etiquetas. Seleccione la etiqueta de línea base publicada de .release-please-manifest.json en la rama base del PR de publicación, y fije el SHA exacto de esa rama como el objetivo editorial. Las etiquetas REA son rea-agents-VERSION. Use la versión propuesta, incluido su sufijo de prelanzamiento; no cambie la estrategia always-bump-minor para imitar las versiones de calendario de OpenClaw.

node scripts/release-notes.mjs inventory \
  --repository morluto/rea --base rea-agents-PREVIOUS \
  --target FULL_BASE_BRANCH_SHA --version VERSION \
  --manifest /tmp/rea-VERSION.contributions.json
node scripts/release-notes.mjs record \
  --manifest /tmp/rea-VERSION.contributions.json \
  --summary \
  --output /tmp/rea-VERSION.record.md

Lea el inventario, no solo el borrador existente del bot. Incluye commits de ramas laterales, PRs asociados de GitHub cuyos commits de fusión están en el rango, autores/coautores de commits, e issues cerradas confirmadas con sus reportadores. Las conexiones de GitHub están paginadas. Los errores de red detienen la generación; vuelva a ejecutar en un nuevo archivo de salida después de la recuperación. Los archivos de salida existentes nunca se sobrescriben.

Las identidades de commits no resueltas se conservan como nombres/correos electrónicos con user: null; nunca adivine un identificador ni agradezca al fusionador como sustituto. El informe preserva los desconocidos. Esta es una instantánea de metadatos revisada, no una prueba independiente de que un humano haya creado un parche. Para identidades no atribuidas, estrategias de fusión inusuales, backports, reversiones o referencias que GitHub no asoció, inspeccione los PRs fuente y los diffs, e informe la limitación. El recolector actual utiliza relaciones confirmadas de cierre de PR para el crédito del reportador de issues; las menciones de issues no relacionadas no se acreditan automáticamente. No afirme que el trabajo simplemente inventariado aún se envía después de una reversión.

Escribir para los usuarios y retener el crédito

Reescriba solo la sección más nueva ## [VERSION] en CHANGELOG.md, preservando su encabezado de versión/fecha/enlace. Use elementos de lista de Markdown de una sola línea bajo:

• ### Destacados: algunos resultados de usuario que definen la versión; sin cuota para versiones pequeñas.
• ### Cambios: capacidades y cambios de comportamiento significativos.
• ### Correcciones: correcciones de fiabilidad, corrección, compatibilidad y seguridad.
• ### ⚠ CAMBIOS RUPTURISTAS: conserve cuando corresponda, con migraciones y referencias originales de PR/commit requeridas por el validador de checkpoint existente.

Agrupe el trabajo relacionado por flujo de trabajo del analista o impacto en el usuario. Explique el comportamiento resultante en entradas cortas y concretas. Los destacados resumen la versión; evite repetir sus descripciones completas en Cambios. La limpieza interna, pruebas, CI y documentación rutinaria generalmente pertenecen solo al archivo de procedencia. Lea PRs/diffs ambiguos antes de hacer afirmaciones. Distinga las comprobaciones de proveedores simulados de la verificación de proveedores reales.

Acredite cada contribución representada una vez en las notas públicas con su enlace y Gracias @... por su autor humano verificado, coautores conocidos y reportadores de issues cerradas confirmados. La agrupación preserva todos esos créditos en una línea. Cuando los Destacados, entradas detalladas o migraciones referencian el mismo trabajo, coloque su agradecimiento en una de esas entradas, no en todas. Incluya enlaces a issues. Los elementos de commit directo llevan el enlace del commit y el crédito humano conocido. Excluya bots de GitHub y cuentas de agentes conocidas. Los trailers de coautores observados de Anthropic, Cursor y Codex de REA se resuelven a @claude, @cursoragent y @codex con tipo User de GitHub; la política de crédito los excluye mientras retiene sus metadatos. A solicitud del mantenedor de REA, omita los autoagradecimientos de @morluto mientras preserva la autoría en el inventario. Otros contribuyentes humanos siguen siendo elegibles. Use enlaces explícitos de GitHub para referencias entre repositorios para evitar números #NNN ambiguos. Los identificadores desconocidos permanecen desconocidos; no se fabrican créditos.

Adjunte el enlace de procedencia record --summary generado textualmente al final de esta publicación. El inventario enlazado da cuenta de cada PR descubierto en el rango y contribución directa, incluido el trabajo interno omitido de la prosa. No pegue la salida completa de record en las notas públicas: duplica agradecimientos y oscurece los cambios visibles para el usuario. Los registros completos permanecen disponibles para su revisión. No edite manualmente los créditos generados para que la validación pase. Actualice el inventario cuando el historial del producto cambie; una corrección solo de prosa puede reutilizar la instantánea.

Finalizar con Release Please

Antes de cambiar el PR de publicación activo, tenga autorización para esa actualización del PR. La preparación local y la validación pueden continuar de forma independiente.

1. Agregue rea:release-notes-finalized al PR de publicación abierto seleccionado antes de editar su rama/cuerpo. Las propuestas de main push respetan esta etiqueta. Esta es nuestra protección de flujo de trabajo, no el mecanismo autorelease: snooze de Release Please. Una propuesta ya en ejecución debe terminar antes de editar. No despache preparación manual sobre notas finalizadas.

2. En esa rama de publicación, guarde el inventario revisado como docs/releases/VERSION.contributions.json. Esta es una procedencia de publicación pública duradera, no un archivo de planificación temporal. No agregue credenciales ni volcados de entorno local. Mantenga los artefactos de versión existentes alineados.

3. Ejecute el validador de checkpoint existente y el nuevo verificador:

   node scripts/release-notes.mjs check \
     --manifest docs/releases/VERSION.contributions.json
   node scripts/release-notes.mjs render \
     --manifest docs/releases/VERSION.contributions.json \
     --output /tmp/rea-VERSION.notes.md
   

   El verificador admite cuerpos de PR en línea, incluidos sus metadatos circundantes, hasta el límite de 65,536 caracteres de GitHub. Fallará en notas más grandes en lugar de truncar créditos; los cuerpos de enlace de desbordamiento de Release Please no están integrados.

4. Actualice el cuerpo del PR de publicación con la sección renderizada mientras preserva su encabezado/pie de página de Release Please y la estructura de componente/versión. Use un archivo de cuerpo para gh pr edit --body-file; cambiar solo CHANGELOG.md no cambia el cuerpo de publicación de Release Please. Haga push solo de cambios autorizados.

5. Obtenga el cuerpo del PR nuevamente a un archivo y ejecute check --pr-body FILE. Revise el diff completo y espere la CI actual. La publicación verifica el cuerpo nuevamente antes de la creación de la publicación. Evite más ediciones del cuerpo mientras se publica.

La etiqueta de finalización congela las actualizaciones del bot, no main. Los nuevos cambios de producto después del objetivo del inventario requieren actualizar las notas antes de la publicación. El flujo de trabajo verifica la ascendencia del objetivo y permite solo rutas de metadatos de publicación después de ese objetivo. También requiere que el objetivo del inventario sea igual al primer padre del merge revisado, por lo que los commits intermedios en main requieren un nuevo inventario. Revise los diffs dentro de las rutas de metadatos de publicación permitidas también: el guardián de ruta no demuestra que las ediciones de dependencias/scripts del paquete sean cambios solo de versión. Para reanudar las propuestas automáticas, elimine la etiqueta de finalización y deje que el bot regenerar; espere que los cambios editoriales sean reemplazados.

Las versiones existentes sin un inventario de contribuciones conservan su ruta de publicación actual. Nunca reetiquete o vuelva a publicar un paquete para corregir la prosa de publicación.