Redactor de PR de Astro

¿Qué hace Redactor de PR de Astro?

Redacta descripciones de solicitudes de extracción (PR) de Astro que ayuden a los revisores a entender rápidamente la intención, los cambios de comportamiento y la validación.

Usa esta habilidad siempre que el usuario solicite cualquier tarea de escritura de PR, incluyendo:

• crear/abrir una solicitud de extracción
• crear/abrir un borrador de solicitud de extracción
• actualizar el título de un PR
• actualizar el cuerpo/descripción de un PR
• escribir notas/resumen de PR

Principio Fundamental

Describe el cambio, cómo funciona y por qué es importante.

• Changes explica qué hace la corrección/nueva funcionalidad.
• Testing enumera qué código de prueba se añadió o modificó.
• Docs explica si se necesitan cambios en la documentación para el usuario.

No uses las secciones del PR como un registro de tareas.

Reglas para el Título del PR

Usa un título humano y amigable para el revisor.

• Describe el resultado en lenguaje sencillo.
• Mantenlo conciso y específico.
• Prefiere una redacción que una persona escribiría naturalmente en una cola de revisión.

No uses:

• prefijos de commit convencionales en los títulos de PR (fix:, feat:, docs:, etc.)
• títulos con alcance estilo commit (fix(cloudflare): ...)

Reglas para el Cuerpo del PR

Usa esta estructura:

## Changes

- <Cambio de comportamiento y por qué es importante>
- <Detalle de implementación e impacto>

## Testing

- <Prueba nueva o modificada y qué cubre>
- <Por qué cambió una aserción existente>

## Docs

- <No se necesita actualización de documentación, porque ...>

Changes

Concéntrate en el comportamiento, el enfoque de implementación y el impacto.

Incluye:

• qué funciona ahora que antes no funcionaba
• cómo funciona la corrección/nueva funcionalidad (a un nivel útil para el revisor)
• cambios de comportamiento en fiabilidad/compatibilidad/rendimiento visibles para el usuario

No incluyas:

• "se añadió una prueba" o "se actualizó un fixture" (pertenecen a Testing)
• "se añadió un changeset"
• notas de proceso interno sin impacto en el comportamiento

Testing

Enumera qué código de prueba se añadió o modificó, y por qué. Los revisores leen esta sección para entender los cambios en la cobertura de pruebas, no para saber que ejecutaste un conjunto de pruebas.

Incluye:

• archivos de prueba nuevos o casos de prueba añadidos, con una breve descripción de lo que cubren
• pruebas existentes que se actualizaron, y por qué cambió la aserción

No incluyas:

• que las pruebas pasan (CI lo muestra; es ruido)
• qué comandos ejecutaste
• cuántas pruebas pasaron

Docs

Explica el impacto en la documentación con claridad.

• Si no se necesita documentación, di por qué en una oración.
• Si se necesita documentación, enlaza el PR de documentación.

Guía de Brevedad

Por defecto, sé breve. 1-2 viñetas por sección es normal; añade más solo cuando el cambio sea realmente complejo. Un revisor que escanea una cola de PR debería poder leer el cuerpo completo en menos de 30 segundos para un parche típico.

Demasiado verboso:

• Mueve .optional().prefault({}) fuera de z.preprocess() para la propiedad de configuración server tanto en base.ts como en relative.ts, coincidiendo con la corrección de integraciones de #16531. Zod 4.4.0 rechaza propiedades faltantes envueltas en z.preprocess() antes de que el preprocesador o los valores predeterminados internos puedan ejecutarse — mover .optional().prefault({}) fuera de la llamada a preprocess resuelve esto. Corrige el problema de la propiedad server reportado allí por @rururux.
• Añade los manejadores invalid_key, invalid_element y options de unión discriminada a los mapas de error de Astro y DB para compatibilidad con Zod 4.4.0. Zod 4.4.0 expone fallos de refinamiento de clave de registro (por ejemplo, nombres de variables de esquema de entorno) como problemas estructurados invalid_key con errores anidados en lugar de un mensaje plano. Los manejadores extraen el mensaje de refinamiento real para errores claros para el usuario.
• Todos los cambios son compatibles con versiones anteriores de Zod 4.3.x. Las nuevas ramas del mapa de error solo se activan en códigos de problema que 4.4.0 comienza a emitir.

Mejor:

• Mueve .optional().prefault({}) fuera de z.preprocess() para la configuración server, coincidiendo con la corrección de integraciones de #16531. Corrige el problema reportado allí por @rururux.
• Añade los manejadores invalid_key, invalid_element y options de unión discriminada a ambos mapas de error para compatibilidad con Zod 4.4.0.
• Compatible con versiones anteriores de Zod 4.3.x.

Changesets

Cada PR que modifica un paquete requiere un changeset. Solo los cambios en examples/* están exentos.

Carga la habilidad changeset para crear el archivo de changeset y escribir el mensaje. Cubre la creación de archivos, el formato, los tipos de bump y las convenciones de mensajes.

Al escribir el cuerpo del PR:

• Antes de publicar, verifica si existe un changeset. Si el PR modifica un paquete y no existe ninguno, críalo ahora usando la habilidad changeset — no publiques el PR sin uno.
• No menciones "se añadió el changeset" en la sección Changes — es ruido de proceso, no un cambio de comportamiento

Autoverificación Antes de Publicar

• El título es amigable para el revisor (no estilo commit)
• Las viñetas de Changes describen comportamiento/implementación/impacto
• Testing enumera el código de prueba añadido/modificado, no los resultados de la ejecución de pruebas
• La decisión de Docs es explícita
• El archivo de changeset existe en .changeset/ para cualquier PR que modifique paquetes — si falta, créalo antes de publicar