Decisiones de Arquitectura (ADRs)¶
Los ADRs (Architecture Decision Records) documentan las decisiones técnicas importantes: qué se decidió, por qué, y qué alternativas se descartaron.
Los archivos completos están en docs/es/adr/.
Índice¶
| ADR | Título | Estado |
|---|---|---|
| ADR-001 | Arquitectura de microservicios con FastAPI | Aceptado |
| ADR-002 | Multi-tenancy con schema isolation en PostgreSQL | Aceptado |
| ADR-003 | asyncpg directo en lugar de SQLAlchemy ORM | Aceptado |
| ADR-005 | API de operaciones por lotes (batch) | Aceptado |
| ADR-006 | Proveedor de IA configurable (multi-proveedor, global) para la capa de conocimiento | Propuesto |
| ADR-007 | Metadatos documentales con JSONB validado por plantilla | Propuesto |
| ADR-008 | Auditoría inmutable con audit_log encadenado por hash |
Propuesto |
| ADR-009 | Historial de flujos como eventos append-only + proyección | Propuesto |
| ADR-010 | Librería compartida orpycamcp_common (auditoría y eventos) |
Aceptado |
| ADR-011 | Frontend SvelteKit (SSR) como app de presentación en el monorepo | Propuesto |
| ADR-012 | Migraciones por tenant (runner global/ + tenant/) |
Aceptado |
| ADR-013 | Autorización resuelta en la BD por request (Keycloak autentica, la BD autoriza) | Aceptado |
| ADR-014 | Búsqueda con PostgreSQL FTS (tsvector + pg_trgm + JSONB), no Elasticsearch | Aceptado |
| ADR-015 | Modelo TRD/CCD: jerarquía serie↔subserie, retención en dos fases, disposición AGN (CT/E/S/M) | Aceptado |
| ADR-016 | Firma electrónica nativa (hash SHA-256 + identidad + sello de tiempo), PKI/PDF diferida | Aceptado |
| ADR-017 | Archivo físico: ubicación (dirección recursiva) ≠ unidad de conservación (contenedor móvil), patrón ArchivesSpace | Aceptado |
| ADR-018 | Interoperabilidad saliente por webhooks HTTP firmados (HMAC-SHA256) sobre el bus de eventos, suscritos por tenant | Aceptado |
| ADR-019 | Capa MCP como fachada fina cliente del gateway (catálogo de tools declarativo, sin lógica ni BD) | Aceptado |
| ADR-020 | Sistema de diseño Orpyca (tokens Sass + custom properties, branding por tenant) y asistente conversacional (texto/voz) como traductor a tools MCP con IA local opt-in | Propuesto |
| ADR-021 | Reclamación de PEL y dead-letter por grupo consumidor en Redis Streams (signature/workflow/notification-service) | Aceptado |
| ADR-022 | Perfil v2 del índice electrónico — metadatos RT-15 por documento (formato, tamaño, foliación) | Aceptado |
| ADR-023 | WORM / Object-Lock de preservación (MinIO) y hoja de ruta AIP/PREMIS | Aceptado (Increment A) |
| ADR-024 | USUA_PERM_ROOT no se concede desde la API — el administrador de entidad no es el techo de su entidad; ROOT solo se aprovisiona fuera de banda |
Aceptado |
| ADR-025 | La TRD es un instrumento convalidado, no una tabla de configuración: versionado append-only y fijación de la versión que gobierna cada expediente | Implementado (Increment 1+2) |
| ADR-026 | La TVD es el mismo instrumento con otro contenido: discriminador tipo_instrumento sobre trd_series, no tabla propia (registro y circuito de convalidación de fondo acumulado) |
Implementado (Increment 1) |
Cómo proponer un nuevo ADR¶
- Crea el archivo
docs/es/adr/ADR-{NNN}-{slug}.md - Usa el formato estándar: Contexto, Decisión, Consecuencias, Alternativas
- Actualiza esta página con el nuevo ADR
- Abre un MR para discusión antes de marcar como "Aceptado"