Resumen ejecutivo
- Problema
- Conservar, deduplicar y trazar datos personales sin construir una arquitectura ficticia.
- Contribución
- Arquitectura y entrega incremental por cortes verticales con pruebas.
- Resultado
- Adaptador de objetos y catálogo PostgreSQL implementados y verificados.
- Alcance
- Base de implementación; la ingesta automatizada y la operación programada permanecen pendientes.
- Verificación
- 162 pruebas de host y 39 con PostgreSQL real. Verificado el 26/08/2026.
Problema
Los datos personales provenientes de múltiples servicios necesitan conservación, deduplicación, catálogo y trazabilidad. Crear de inmediato toda la arquitectura objetivo habría producido módulos sin comportamiento y señales de avance engañosas.
Responsabilidad
Definí el repositorio canónico privado, el paquete inicial, el stack de desarrollo, los límites de almacenamiento y una secuencia de hitos donde cada incremento termina con pruebas.
Restricciones
- Sin datos personales ni secretos en Git.
- Almacenamiento de objetos de desarrollo no autoritativo.
- Hashes criptográficos para integridad.
- Servicios internos sin exposición innecesaria.
- Sin workers, conectores o catálogos ficticios antes de implementarlos.
Arquitectura y enfoque
El núcleo actual es una aplicación Python con endpoints de salud que comprueban dependencias, un adaptador genérico de almacenamiento de objetos con integridad SHA-256 y un catálogo PostgreSQL para ubicaciones verificadas, deduplicación y auditoría. La arquitectura futura mantiene separados los conectores, la ingesta, la reconciliación, la cuarentena y la retención.
Decisiones y compromisos
- Repositorio privado canónico. Evita fragmentar el proyecto; un repositorio público anterior permanece no canónico.
- Desarrollo por cortes. Reduce arquitectura especulativa, aunque mantiene visible una lista amplia de capacidades pendientes.
- Frontera intercambiable. Un adaptador genérico mantiene las particularidades del almacenamiento fuera del dominio.
- Migraciones que fallan de forma segura. Sumas de comprobación, bloqueo de concurrencia y transacciones impiden aplicar cambios ante deriva o estados incompatibles.
- Preparación honesta. El punto de salud comprueba dependencias reales y reporta su estado sin exponer detalles internos.
Implementación
La base incluye fábrica de aplicación, puntos de salud con verificación de dependencias, configuración tipada, un adaptador genérico con SHA-256 en streaming y un catálogo PostgreSQL de cinco tablas. El repositorio usa consultas parametrizadas, distingue ubicaciones creadas y duplicadas, rechaza inconsistencias de tamaño o pertenencia y conserva una auditoría separada tras revertir la transacción. La búsqueda por hash devuelve ubicaciones en orden determinista.
Verificación
Incidentes y aprendizajes
La existencia de un punto de preparación no basta: en el primer corte solo demostraba que la aplicación respondía. Evolucionarlo hasta consultar dependencias reales, con salidas sanitizadas, mantuvo la honestidad entre la interfaz y la implementación.
Estado de implementación
Verificado el 26/08/2026: el adaptador genérico cuenta con verificación de contrato sobre almacenamiento real y el catálogo PostgreSQL fue comprobado mediante integración continua y pruebas contra una base real aislada. Esta evidencia demuestra capacidad de implementación, no estado operativo actual ni un catálogo desplegado en producción. Los conectores, la ingesta automatizada, la reconciliación, la retención, los workers y el scheduler aún no están implementados.
Siguiente paso
Integrar el registro de ubicaciones verificadas con el primer corte de ingesta, manteniendo la automatización y la operación programada como trabajo futuro hasta contar con pruebas equivalentes.