Commits
Plantillas en la base de datos: la primera mejora post-MVP de Auto Magazine
Primer día de mejoras post-MVP: las plantillas del PDF pasan del sistema de archivos a la base de datos y el panel gana un CRUD completo verificado en producción.
Este lunes he iniciado la primera mejora post-MVP: una sección de Plantillas en el panel. Hasta ahora, las plantillas del PDF solo se modificaban mediante el sistema de archivos, y la carpeta estaba horneada en la imagen Docker: cualquier edición hecha desde el panel se habría perdido con el siguiente docker compose up --build. La decisión central, cerrada con el interrogatorio (ADR 0002), es que la fuente de verdad pase a ser las filas de la base de datos.
Antes de tocar código
La mañana ha servido para preparar el terreno. He instalado el paquete de habilidades de mattpocock y he definido cómo trabaja el agente: el sistema de seguimiento es GitHub Issues, con etiquetas de clasificación por defecto (needs-triage, needs-info, ready-for-agent, ready-for-human), y las decisiones de dominio se leen del glosario y de los ADR antes de explorar nada. El glosario ha cambiado de nombre (CONTEXT.md → GLOSSARY.md) y de contenido: Edición es la pieza canónica —el documento era anterior a la multi-edición y se había desviado del producto, con Número como correlativo—, y se incorporan la Cabecera como marca madre, el Esqueleto y la Hoja de estilo maestra.
También me he llevado tres correcciones de proceso en una sola sesión: el interrogatorio debe preguntar de forma interactiva (la recomendación es una opción marcada, no la respuesta), la especificación y los tickets son pasos que requieren autorización individual —publicé seis incidencias antes de tener el visto bueno de la especificación—, y cuando hay una habilidad del paquete para un paso, se sigue al pie de la letra: la auditoría encontró la especificación sin el formato obligatorio y los tickets por capas en lugar de balas trazadoras verticales.
Cuatro tickets en un día
La primera bala trazadora (incidencia n.º 2, TDD, suite de 171 en verde) ha llevado las plantillas a la base de datos: un proceso de inicialización idempotente al arrancar que importa las 7 de fábrica que faltan sin romper nada, un renderizado que materializa las filas en un directorio temporal para WeasyPrint y una firma de maqueta sellada con el hash de las filas. El panel ha ganado la sección «07 Plantillas», con listado por rol y ficha completa, y se ha desplegado en producción (commit 1b97e3e) comprobando contra la base de datos real del volumen datos/: las 7 plantillas de fábrica y las 2 ediciones existentes, intactas.
Mientras tanto, un problema que vi yo mismo al probar el ticket: el contenido de la ficha desbordaba la tarjeta (un pre de 1.989 px contra 954 disponibles). Se corrigió globalmente en el sistema de diseño (pre-wrap, overflow-wrap: anywhere) y con la tipografía aumentada a 1rem para que el código se pudiera leer.
Después entró el resto de la familia: el editor de plantillas con referencia de variables, errores de Jinja con el archivo y la línea y errores de sintaxis CSS detectados con tinycss2 y presentados en el panel (commit 6aeb386); el botón «Restaurar original» en las fichas de fábrica, que ofrece una vía para que las mejoras de una actualización lleguen a una edición ya montada (fe1f687); y plantillas libres con eliminación en Limpieza (26b0c38). La revisión de código de este último detectó tres fallos de fondo: el proceso de inicialización reimportaba una plantilla de fábrica borrada y la entrada de la papelera quedaba atascada; una plantilla libre podía adoptar el nombre de una de fábrica que el motor selecciona por su nombre fijo; y cualquier plantilla libre invalidaba la maqueta sin cambiar el PDF, porque la firma sellaba todas las filas y no solo las que usa el motor.
Verificación de extremo a extremo
El último ticket ha sido el recorrido completo en Chromium, con informe visual y capturas. Docker no está disponible en el equipo local, así que el flujo se realizó mediante HTTP con datos temporales (crear la Edición, subir un .docx, extraer, maquetar), y la prueba crítica —que una reconstrucción no perdiera lo que se había editado— se hizo en fxserver: fila de portada.html comparada con el archivo de fábrica, edición de prueba, reconstrucción de la imagen, fila intacta y producción restaurada a su estado. El CRUD completo de Plantillas queda verificado y en producción, sobre una fuente de verdad que ya no se pierde durante las reconstrucciones.