Status: accepted (stack Java derivado del pack; motor de base decidido por el
operador en devloop: SQL Server — reemplaza la propuesta inicial PostgreSQL)
Context: El módulo qrtoken existe validado en C89 + espejo Java y la
CONSTITUTION obliga a reusarlo, no reimplementarlo. El servidor destino es una máquina
del cliente (sin nube), con backup diario y servicio con reinicio automático. WorkDone
(referencia de la casa) es una webapp Java (src/main/webapp).
Alternatives:
Node/TypeScript end-to-end: unifica lenguaje con los frontends, pero obliga a
portar qrtoken (violación de REUSE-FIRST) o a un bridge frágil.
Java + Spring Boot 3 (elegida): consume el espejo Java de qrtoken tal cual,
stack conocido por LaEmpresa, despliegue single-jar como servicio.
Decision:backend/ en Java 17 + Spring Boot 3 (single jar), SQL Server 2022
como base (instancia de LaEmpresa; DB SistemaPremios), Flyway (módulo
flyway-sqlserver) para migraciones versionadas con rollback documentado, Maven como
build. El módulo qrtoken (espejo Java) se integra como fuente vendoreada con marcador
de procedencia.
Tests contra el motor real: la suite corre contra la misma instancia SQL Server
local (DB SistemaPremios_test), NO contra H2/HSQLDB — los invariantes viven en
constraints dialecto-específicos (unique filtrado de "única campaña vigente", consumo
atómico) y un motor sustituto no los prueba.
Consequences: Validación de token idéntica a la de caja (verificación cruzada C↔Java
ya hecha en prototipo); constraints e idempotencia (ADR-011) sobre SQL Server (índices
filtrados + unique constraints); un solo artefacto desplegable + dos bundles estáticos.
Credenciales de DB SOLO por variables de entorno / config local no trackeada
(CONSTITUTION: secrets nunca en repo).