# Decisiones técnicas

## D001 Aplicación local sin dependencias externas

- Estado: vigente.
- Decisión: usar Node.js, módulos nativos y SQLite para el piloto.
- Motivo: simplificar instalación, demostración y resguardo local.
- Consecuencia: el equipo anfitrión debe permanecer encendido y un despliegue remoto requerirá revisión arquitectónica.

## D002 Separación estricta de roles

- Estado: vigente.
- Decisión: la administración de cuentas no concede acceso financiero.
- Motivo: limitar la exposición de información de negocio.
- Consecuencia: la cuenta maestra y el gestor no utilizan endpoints financieros; el gestor solo administra usuarios normales.

## D003 Base demo independiente

- Estado: vigente.
- Decisión: usar `data-demo` para demostraciones y `data` para la instalación normal.
- Motivo: evitar que pruebas y presentaciones modifiquen información normal.
- Consecuencia: los iniciadores demo establecen `NEXOCAJA_DATA_DIR` y `NEXOCAJA_DEMO`.

## D004 Cálculos financieros en módulo puro

- Estado: vigente.
- Decisión: concentrar amortización y proyección en `src/finance.js`.
- Motivo: permitir pruebas deterministas y evitar fórmulas duplicadas en la interfaz.
- Consecuencia: cualquier nueva regla financiera debe implementarse y probarse en ese módulo.

## D005 Entidad crediticia de texto libre

- Estado: vigente.
- Decisión: el usuario escribe el nombre de la entidad en lugar de seleccionarla de una lista.
- Motivo: permitir bancos, cajas y cooperativas no incluidas previamente.
- Consecuencia: los registros antiguos con códigos conocidos siguen mostrándose de forma compatible.

## D006 Hojas de cálculo generadas en el navegador

- Estado: vigente.
- Decisión: leer y generar XLSX o CSV desde `public/spreadsheet.js`.
- Motivo: conservar una aplicación local sin servicio adicional de archivos.
- Consecuencia: la API recibe filas normalizadas y vuelve a validar permisos y contenido.

## D007 Acceso iOS mediante aplicación web local

- Estado: vigente.
- Decisión: usar la PC o Mac como anfitrión y Safari como cliente instalable en inicio.
- Motivo: iOS no ejecuta directamente el servidor Node.js del proyecto.
- Consecuencia: ambos equipos deben compartir una red de confianza y el anfitrión debe mantener el iniciador abierto.

## D008 Coordinación persistente basada en archivos

- Estado: vigente.
- Decisión: coordinar Codex, Antigravity y Gemini mediante hilos Markdown versionables en `documentacion/coordinacion/mensajes`, con una utilidad Node.js para consultar, responder y validar la bandeja.
- Motivo: conservar acuerdos, evidencia y revisiones aunque cambie la sesión de chat o el agente que continúa el trabajo.
- Consecuencia: cada cambio de código, configuración o documentación operativa debe crear o actualizar un hilo; los hallazgos no se resuelven sin revisión independiente.

## D009 Registro cronológico de solicitudes

- Estado: vigente.
- Decisión: registrar cada solicitud del responsable del proyecto en `SOLICITUDES_Y_ESTADO.md`, con ID, hora de Lima, estado, responsable y evidencia enlazada.
- Motivo: distinguir lo solicitado de lo implementado, ordenar prioridades y permitir que Codex, Antigravity y Gemini compartan el mismo estado operativo.
- Consecuencia: cada agente debe consultar y actualizar este registro al iniciar y cerrar una intervención; los eventos anteriores no se eliminan ni reescriben.

## D010 Recorrido guiado global versionado por cuenta

- Estado: vigente.
- Decisión: almacenar en `app_settings` la activación y versión global del recorrido, y en `users.guided_tour_seen_version` la última versión vista por cada cuenta.
- Motivo: permitir que el Administrador envíe o reinicie una guía para todos sin mostrarla repetidamente a quienes ya la completaron u omitieron.
- Consecuencia: solo el rol interno `master` puede activar, pausar o reiniciar la guía; cada rol recibe pasos compatibles con sus permisos y puede repetirlos manualmente sin modificar datos financieros.

## D011 Paquete de hosting por lista permitida

- Estado: vigente.
- Decisión: construir el artefacto de subdominio con `npm run build:host`, copiando únicamente los archivos de ejecución y generando una carpeta de datos vacía y un manifiesto SHA-256.
- Motivo: impedir que bases locales, el módulo y las credenciales de demostración, pruebas, archivos de coordinación o documentos de trabajo lleguen por accidente al servidor público.
- Consecuencia: el despliegue requiere un hosting con proceso Node.js 22.13 o superior, HTTPS y almacenamiento persistente; no funciona en un alojamiento limitado a WordPress/PHP. Las actualizaciones reemplazan código, pero preservan la ruta indicada por `NEXOCAJA_DATA_DIR`.

## Formato para una nueva decisión

- Identificador y título.
- Estado: propuesta, vigente, reemplazada o descartada.
- Decisión concreta.
- Motivo verificable.
- Consecuencias técnicas y operativas.
- Enlace a la entrada correspondiente del registro de cambios.