Asistente Judicial en Línea

App Flutter de misión crítica para asistentes judiciales cubanos — caché SQLite write-first + REST contract-first + sincronización de deltas con checkpoints — para que un día offline en zonas de baja conectividad termine con cero pérdida de datos.

Cliente
Tribunal Supremo Popular (Sistema Judicial Cubano)
Rol
Líder de Proyecto — Mobile
Año
2025
Período
Proyecto multi-trimestre
Flutter Dart SQLite ERPNext / Frappe Python REST
Asistente Judicial en Línea

Problema

El sistema judicial cubano necesitaba una herramienta de campo para los asistentes judiciales que monitorean la reinserción social de personas sancionadas — presentaciones, controles, evaluaciones, informes sobre situación familiar — y devolver esas observaciones a un sistema central ERPNext (Frappe) en el Tribunal Supremo Popular.

La restricción dura era la conectividad. Los trabajadores de campo operan en todo el país, incluyendo municipios donde la conexión móvil es poco confiable por horas o por días enteros. Una sincronización fallida en el momento equivocado puede significar un control perdido o una evaluación sin guardar — y en este dominio, perder datos no es solo un inconveniente: tiene consecuencias legales para la persona monitoreada. El sistema tenía que comportarse correctamente SIN red y recuperarse cuando la red volviera, con cero pérdida.

Enfoque

Arquitecté el cliente móvil como una app Flutter local-first respaldada por SQLite que trata la red como una mejora, no una dependencia. Cada escritura — una presentación registrada, una evaluación completada, una notificación abierta — se guarda en la base SQLite local primero, antes de cualquier llamada de red. Un motor de sincronización en segundo plano reconcilia con el backend ERPNext vía REST cuando hay conectividad. Los conflictos se resuelven con last-write-wins con timestamp.

La decisión no obvia fue el contrato de la API, no la capa de almacenamiento. Lideré un esfuerzo de documentación REST contract-first con el equipo backend: endpoints versionados, paginación explícita y semántica de delta-fetch con checkpoint resume — para que la cola de sincronización pudiera retomar exactamente donde quedó después de una desconexión larga, en vez de resincronizar el dataset completo en cada reconexión. Esa única decisión de diseño fue la que mantuvo ventanas offline de horas plenamente operativas.

Loading diagram…
SQLite local con write-first + cola de sincronización con delta fetch checkpointed — la red es opcional, nunca bloqueante

Resultado

Los trabajadores de campo pueden operar un día completo offline — registrar presentaciones, completar evaluaciones, recibir notificaciones — y la cola reconcilia transparentemente la próxima vez que llegan a señal. No se perdió data en los meses observados post-rollout. La visualización de sincronización (la pantalla arriba, pausada al 30%) se convirtió en una señal de confianza reconocible para los operadores: podían ver la cola drenando y saber que nada quedaba colgado.

La disciplina de contract-first en la API redujo la fricción de integración entre equipos al punto que una segunda superficie móvil (una herramienta admin interna) se levantó contra los mismos endpoints sin reescribir el backend.

La mayoría de los campos e identificadores en las capturas están borrosos o son datos de prueba — el sistema en producción es operado por el Tribunal Supremo Popular y no es de acceso público.

Tecnologías usadas

Flutter Dart SQLite ERPNext / Frappe Python REST
Visual

Pantallas

Lista de sancionados con el modal de sincronización offline-first en progreso al 30%Perfil detallado de un sancionado con dirección y período de cumplimientoDetalle del caso con Agenda vacía y Acciones Disponibles (presentaciones y controles)Formulario de calificación con selector de rating, lugar y entrevistas influyentesFeed de notificaciones con número de expediente, acción, razón, tribunalPantalla de login con el emblema del Tribunal Supremo Popular y el título Asistente Judicial en Línea
Seguir explorando

Más proyectos