NNNN. Título corto de la decisión¶

Fecha: AAAA-MM-DD Estado: Propuesto | Aceptado | Rechazado | Reemplazado por 000X | Obsoleto Módulo(s) afectado(s): (ej. auth, facturación, integración-sigfapro)

Contexto¶

¿Qué problema hay? Describe la situación técnica o de negocio que obliga a decidir algo. 2-4 líneas, sin rodeos: qué está pasando, qué restricción o fuerza está en juego (rendimiento, plazos, compatibilidad con el sistema legado, convivencia de escrituras, etc.).

Decisión¶

¿Qué se eligió? Una o dos frases directas, en modo afirmativo ("Se usará...", "Cada tabla tendrá..."). Si aplica, incluye el detalle mínimo necesario para que el patrón sea reproducible por otro desarrollador (ej. nombre del header, formato del endpoint, nombre de la tabla de control).

Alternativas descartadas¶

Alternativa A — por qué no: 1 línea.
Alternativa B — por qué no: 1 línea.

(2-3 alternativas suele bastar; si solo hubo una alternativa obvia, está bien listar solo esa.)

Consecuencias¶

Qué implica esta decisión hacia adelante (positivo y negativo): qué se vuelve más fácil, qué se vuelve más rígido, qué deuda técnica queda pendiente, qué hay que recordar la próxima vez que alguien toque este módulo. 2-3 líneas.

Media página como máximo. Si el ADR crece más que eso, probablemente estás documentando el diseño completo del módulo, no una decisión puntual — separa.