Validación y Merge¶
Todo workflow — rápido o estructurado — termina en validación antes de que cualquier código llegue a tu rama protegida. Es el momento en que pruebas el cambio en una ejecución real antes de aprobar.
La etapa de validación¶
Cuando la ejecución termina, N45 se detiene y te pide validar. Tienes cuatro opciones:
| Opción | Qué pasa |
|---|---|
| Ejecutar la app | N45 inicia el runbook para que pruebes en vivo |
| Aprobado — listo para merge | Procede a merge o PR |
| Encontré un problema | Dispara una iteración de hot fix sin salir de validación |
| Quiero un ajuste | Dispara una iteración de quick feat para un retoque |
Durante la validación, N45 mantiene el foco: no cambia a otros workflows aunque hagas preguntas off-topic. Responde, y luego vuelve a presentar las mismas cuatro opciones hasta que apruebes.
Ajustes y correcciones durante la validación¶
Si ves un problema, no necesitas salir de la validación:
- Encontré un problema → describe qué está mal → N45 diagnostica y ejecuta una iteración de hot fix → vuelve a validación
- Quiero un ajuste → describe el cambio deseado → N45 ejecuta una iteración de quick feat → vuelve a validación
Se permiten hasta 3 iteraciones por categoría. Después N45 escala el trabajo a un fix o feature estructurado.
Las iteraciones quedan confinadas a la validación
Las iteraciones desde validación todavía pasan por las mismas comprobaciones de condiciones. Un cambio que requiera schema migration o nuevo contrato público es rechazado y empujado a un flujo estructurado tras el merge.
Merge o Pull Request¶
Una vez aprobado, N45 pregunta dónde entregar:
- Pull Request →
<rama protegida>— abre un PR usando el título del spec y un resumen - Merge →
<rama protegida>— hace merge directo en la rama protegida
La lista de ramas protegidas viene de la configuración de tu proyecto (default: main / master).
Para trabajo estructurado¶
El título y el body del PR vienen del spec — contenido que ya aprobaste durante la revisión.
Para hot fixes y ajustes rápidos¶
El título del PR es el mensaje del último commit; el body resume los archivos modificados y lo que el cambio hace.
Qué se commitea¶
| Origen | Formato del mensaje de commit | Tag |
|---|---|---|
| Roadmap estructurado | feat(work_id): <descripción de la task> |
(sin tag) |
| Quick Feat | feat(alcance): <descripción> |
[quick-feat] |
| Hot Fix | fix(alcance): <descripción> |
[hot-fix] |
Los tags permiten que N45 (y tú) rastrees qué cambios vinieron de cada camino al generar retrospectivas.