# Registro de decisiones arquitectónicas (ADR)

Formato: contexto, decisión, consecuencias. Estado: **Aceptada** salvo indicación.

## ADR-001. Monolito modular
**Decisión:** un único proyecto Laravel con módulos separados (Domain / Application / Infrastructure / Http).
**Consecuencias:** operación simple en hosting compartido; los módulos pueden externalizarse después. Se exige no mezclar capas.

## ADR-002. MariaDB
**Decisión:** MariaDB 10.6+ como base principal, acceso vía PDO.
**Consecuencias:** sin funciones específicas no verificadas. Pruebas locales con SQLite solo si el comportamiento es equivalente; las pruebas de concurrencia y restricciones corren contra MariaDB/MySQL.

## ADR-003. Cola persistente en base de datos
**Decisión:** driver `database`, drenado por cron con `--stop-when-empty` y tiempo máximo.
**Consecuencias:** latencia de 5 a 10 min; sin Redis ni demonios.

## ADR-004. Documentos fuera de la raíz pública
**Decisión:** `DocumentStorage` con implementación `PrivateLocalDocumentStorage` en `storage_private/`.
**Consecuencias:** si el plan no permite garantizarlo, no se habilitan cargas.

## ADR-005. Workflows publicados inmutables
**Decisión:** cada cambio genera una versión nueva; la instancia guarda la versión exacta.

## ADR-006. Reglas declarativas
**Decisión:** reglas como JSON validado con operadores permitidos. Prohibido `eval`, SQL libre y scripts.

## ADR-007. Auditoría con hash encadenado
**Decisión:** SHA-256 sobre serialización canónica (claves ordenadas, UTF-8, fechas ISO 8601 UTC) enlazado al evento previo.
**Consecuencias:** detecta alteraciones; **no** es almacenamiento inmutable certificado (FR-AUD-006).

## ADR-008. Adaptadores para servicios externos
**Decisión:** OCR, firma, correo e integraciones detrás de interfaces. Sin proveedor configurado, el estado es "no configurado", nunca simulado.

## ADR-009. Solo datos de prueba en el MVP
**Decisión:** prohibido cargar documentación real sensible hasta completar la evaluación del apartado 17 del SRS.
**Consecuencias:** refuerza el perfil Stellar, cuyos backups propios no están garantizados.

## ADR-010. Perfil de despliegue Namecheap Stellar
**Contexto:** 1 GB RAM, 20 procesos de entrada, 300.000 inodos, cron ≥ 5 min, sin procesos persistentes, SSH no confirmado. Ver `docs/deployment/perfil-stellar.md`.
**Decisión:**
1. Despliegue por **artefacto** (`vendor/` y assets incluidos) como vía principal; SSH es opcional.
2. **Cuotas de inodos** por organización, con alertas.
3. Descargas, hashes y cargas **por flujo**, sin cargar archivos completos en memoria.
4. Un solo cron `schedule:run` cada 5 min; trabajos acotados a 45 s y 10 elementos.
5. Backup propio nocturno con copia fuera de Namecheap.
6. Sin dependencias de CDN: tipografías del sistema y activos locales.
**Consecuencias:** el producto funciona dentro de Stellar y migra sin cambios de código a un VPS o nube modificando configuración.

## ADR-011. Identidad de producto
**Decisión:** nombre **Minka**; eslogan *Todo conectado. Cada decisión trazable.* El léxico de interfaz prioriza *expediente, decisión, trazabilidad, flujo*; evita *carpeta, archivo, nube* como protagonistas.
**Consecuencias:** ver `docs/brand/minka-marca.md`.