Roadmap del proyecto 1. Portal Ciudadano Esta es la aplicación principal que usan los ciudadanos. Es un proyecto en Next.js 16 con App Router, integrado con ORY Network para la gestión de identidades y AWS Rekognition para la verificación biométrica. Lo que ya se hizo El esqueleto de la aplicación está construido y funcional en ambiente de desarrollo. Se tomaron decisiones fundamentales de arquitectura que definen el rumbo del proyecto: Se eligió Next.js 16 como framework principal, aprovechando el App Router y los React Server Components para tener una separación clara entre lo que se ejecuta en el servidor y lo que llega al navegador del ciudadano. Esta decisión se tomó porque Next.js permite renderizar las páginas en el servidor, lo que mejora tanto el rendimiento como el SEO, algo importante para un portal gubernamental que debe ser accesible desde cualquier dispositivo y conexión. La integración con ORY Network está funcionando. Se implementaron los flujos de inicio de sesión, recuperación de contraseña, verificación de email y gestión de configuraciones del usuario, todos delegados a los componentes oficiales de ORY Elements React. Esto significa que no estamos reinventando la rueda en temas de seguridad: ORY maneja el almacenamiento de credenciales, la emisión de tokens OAuth 2.0 y los flujos de OpenID Connect. El flujo de registro de tres pasos ya está implementado en su forma base. El primer paso valida la cédula del ciudadano contra la API del Registro Civil dominicano. El segundo paso recoge el correo electrónico y la contraseña. El tercer paso realiza la verificación facial usando AWS Rekognition Face Liveness, que compara el rostro en vivo del ciudadano con la foto almacenada en la base de datos de la Junta Central Electoral. Este cambio de orden respecto a la versión anterior (donde la verificación facial era el segundo paso) fue intencional: permite que el ciudadano complete la información de su cuenta antes de pasar por el proceso biométrico, reduciendo la frustración en caso de que necesite corregir datos. Se configuró la internacionalización con next-intl, soportando español e inglés. Todas las cadenas de texto están externalizadas en archivos de traducción, lo que facilita agregar nuevos idiomas en el futuro. El sistema de componentes UI está basado en shadcn/ui con Radix UI y Tailwind CSS. Esto nos da componentes accesibles por defecto (cumplen con ARIA) y un sistema de diseño consistente. Se implementó soporte para modo oscuro usando next-themes. La validación de formularios usa Zod para esquemas de validación y React Hook Form para la gestión del estado de los formularios. Esto asegura que los datos se validen tanto en el cliente como en el servidor. Se crearon las rutas protegidas del dashboard ciudadano: página principal, perfil, configuraciones, historial, soporte y acerca de. Aunque varias de estas páginas aún son esqueletos, la estructura de navegación y el sistema de protección de rutas (que verifica la sesión de ORY antes de permitir el acceso) están completos. El pipeline de CI/CD está configurado con GitHub Actions para desplegar automáticamente a Google Cloud Run cuando se hace push a la rama staging. El Dockerfile usa una imagen base de Bun para builds rápidos y produce una imagen optimizada con el output standalone de Next.js. Las API routes del servidor están implementadas para todo el flujo de registro: búsqueda de ciudadano por cédula, creación de cuenta, creación de sesión de liveness, verificación de resultado de liveness, y reset de sesión de registro. También están las rutas para gestión de sesiones de ORY (obtener sesión actual, revocar sesiones, logout). Lo que está en progreso El diseño visual gubernamental está siendo refinado. Aunque la estructura está lista, se necesita pulir la experiencia visual para que se sienta institucional pero moderna. Esto incluye el landing page, las transiciones entre pasos del registro y la consistencia visual en todas las pantallas. Se está trabajando en la gestión de errores. El código tiene manejo básico de errores, pero falta una estrategia unificada que cubra todos los escenarios: errores de red, timeouts de ORY, fallos de Rekognition, problemas con la cámara del dispositivo, etc. Cada error debe mostrar un mensaje claro al ciudadano y, al mismo tiempo, registrarse internamente para que el equipo de soporte pueda diagnosticarlo. Lo que falta por hacer Funcionalidades del Dashboard Ciudadano.  Las páginas del dashboard están creadas como esqueletos pero necesitan contenido real. La página de perfil debe mostrar la información del ciudadano extraída de los traits de ORY (nombre, cédula, fecha de nacimiento, género). La página de historial debe mostrar las sesiones activas y el historial de actividad. La página de configuraciones necesita permitir el cambio de contraseña, la activación de segundo factor de autenticación (2FA) y la gestión de preferencias de notificación. Sistema de Notificaciones (Buzón Ciudadano).  Esta es una funcionalidad completamente nueva que no existía en CUC v1. La idea es que los ciudadanos puedan recibir notificaciones dentro de su cuenta: avisos de seguridad, comunicaciones gubernamentales, alertas de actividad sospechosa, recordatorios de trámites pendientes, entre otros. Se necesita definir la arquitectura del sistema de notificaciones (almacenamiento, entrega en tiempo real vs polling, tipos de notificación), diseñar la interfaz del buzón, implementar la API de notificaciones y conectarla con el backoffice para que los agentes puedan enviar notificaciones. Agente de Inteligencia Artificial.  Se planea incorporar un agente conversacional que ayude a los ciudadanos a resolver dudas sobre su cuenta, guiarlos en procesos y, cuando no pueda resolver un problema, escalar a un agente humano de Atención Ciudadana. La tecnología aún está en evaluación. Se debe definir qué modelo de lenguaje usar, cómo integrarlo en la interfaz, qué conocimiento base necesita, cómo manejar la escalación a humanos y cómo garantizar que las respuestas sean precisas y no generen confusión en temas gubernamentales. Mejoras en la Verificación Facial.  El flujo básico funciona, pero hay escenarios que necesitan mejor manejo: qué pasa cuando el ciudadano no tiene cámara, cuando la iluminación es mala, cuando el navegador no soporta la API de MediaDevices, cuando el rostro no coincide pero el ciudadano insiste en que es él. Se necesita una estrategia de fallback y un proceso claro de escalación para estos casos. Gestión de Dispositivos y Sesiones.  ORY maneja las sesiones, pero el ciudadano necesita poder ver en cuántos dispositivos tiene sesión activa y poder cerrar sesiones remotamente. Esto ya se ve en el código como un endpoint de revocación de sesión, pero la interfaz para que el ciudadano lo use aún no está construida. Accesibilidad.  Aunque shadcn/ui y Radix UI proporcionan componentes accesibles por defecto, se necesita una auditoría completa de accesibilidad (WCAG 2.1 AA como mínimo) en todos los flujos. Un portal gubernamental debe ser usable por personas con discapacidades visuales, motoras o cognitivas. Pruebas Automatizadas.  No hay tests en el proyecto actualmente. Se necesita implementar pruebas unitarias para la lógica de negocio (validaciones, servicios), pruebas de integración para las API routes, y pruebas end-to-end para los flujos críticos (registro, login, recuperación de contraseña). Dado que es un sistema de identidad, las pruebas son fundamentales para evitar regresiones que puedan afectar a miles de ciudadanos. Documentación del Proyecto Open Source.  Si el proyecto será open source, necesita un README completo, guías de contribución (CONTRIBUTING.md), código de conducta (CODE_OF_CONDUCT.md), documentación de la API interna, y guías para que desarrolladores externos puedan levantar el proyecto localmente. Seguridad: Rate Limiting y Protección contra Abuso.  La versión anterior usaba reCAPTCHA y Cloudflare. En la nueva versión, se necesita definir qué mecanismos de protección se van a implementar: rate limiting en las API routes, protección contra fuerza bruta en el login (ORY tiene esto incorporado, pero hay que configurarlo correctamente), y protección contra bots en el registro. Monitoreo y Observabilidad. La versión anterior usaba Sentry. Se necesita decidir si se continúa con Sentry o se migra a otra solución. Además, se deben implementar métricas de rendimiento (tiempos de respuesta, tasas de error), métricas de negocio (registros completados vs abandonados, pasos donde se pierden usuarios), y alertas automáticas cuando algo falle. 2. Backoffice El backoffice es una aplicación separada, también en Next.js 16, que le da herramientas al equipo de Atención Ciudadana y a los administradores para gestionar las cuentas de los ciudadanos y darles soporte. Lo que ya se hizo Se definió la arquitectura base en AWS: EventBridge recibe los eventos (webhooks) que emite ORY Network cada vez que ocurre algo relevante (un ciudadano se registra, inicia sesión, cambia su contraseña, falla un intento de login, etc.). Estos eventos son procesados por funciones Lambda que los transforman y almacenan en DynamoDB. Esta arquitectura permite escalar horizontalmente sin preocuparse por la infraestructura, ya que cada componente es serverless. Lo que está en progreso Se está trabajando en el diseño y la implementación de la aplicación web del backoffice. Las funcionalidades principales que se están construyendo incluyen la búsqueda y visualización de cuentas ciudadanas, la capacidad de realizar acciones sobre las cuentas (bloquear, desbloquear, restaurar, eliminar), y la visualización de métricas en tiempo real. Lo que falta por hacer Dashboard de Métricas en Tiempo Real.  Los administradores necesitan poder ver: cuántos ciudadanos se han registrado hoy, esta semana, este mes. Cuáles son las integraciones OAuth más populares (qué servicios gubernamentales reciben más tráfico desde CUC). En qué paso del registro se quedan los ciudadanos que no completan el proceso. Cuáles son los errores más frecuentes. Cuántas sesiones activas hay en este momento. Todo esto debe alimentarse de los eventos que llegan a EventBridge y se procesan con Lambda. Gestión de Cuentas Ciudadanas.  Los agentes de Atención Ciudadana necesitan poder buscar un ciudadano por cédula, correo o nombre. Ver toda la información de su cuenta. Ver el historial completo de actividad (cada login, cada cambio de contraseña, cada error). Realizar acciones administrativas como resetear la contraseña, desbloquear la cuenta, verificar manualmente una identidad cuando el proceso biométrico falle. Trazabilidad Completa del Journey del Ciudadano.  Esta es una de las funcionalidades más ambiciosas. La idea es que cuando un ciudadano llame a soporte diciendo "intenté registrarme y no pude", el agente pueda ver exactamente qué pasó: el ciudadano ingresó su cédula a las 10:15am, la validación fue exitosa, pasó al paso 2, ingresó su correo, pasó al paso 3, la verificación facial falló con un error de iluminación insuficiente a las 10:18am, el ciudadano lo intentó de nuevo y falló por timeout a las 10:19am, y luego abandonó el proceso. Para lograr esto, se necesita que el portal ciudadano envíe eventos detallados de cada acción del usuario, no solo los eventos que ORY emite naturalmente. Sistema de Tickets y Escalación.  Cuando el agente de IA no pueda resolver un problema del ciudadano, debe crear un ticket que un agente humano pueda gestionar desde el backoffice. Se necesita diseñar el flujo completo: cómo se crea el ticket, qué información incluye, cómo se asigna a un agente, cómo se le da seguimiento, y cómo se notifica al ciudadano cuando su caso se resuelve. Envío de Notificaciones.  Los agentes deben poder enviar notificaciones a ciudadanos individuales o grupos de ciudadanos desde el backoffice. Estas notificaciones llegan al buzón ciudadano del portal. Se necesita definir los tipos de notificación, las plantillas, y quién tiene permisos para enviar qué tipo de notificación. Control de Acceso Basado en Roles (RBAC). El backoffice tendrá diferentes tipos de usuarios: administradores con acceso total, agentes de Atención Ciudadana con acceso limitado a gestión de cuentas y soporte, y visualizadores que solo pueden ver métricas. Se necesita implementar este sistema de permisos. 3. Infraestructura y DevOps Lo que ya se hizo El CI/CD del portal ciudadano está configurado con GitHub Actions desplegando a Google Cloud Run. El Dockerfile está optimizado con multi-stage builds usando Bun como runtime. Las variables de entorno están separadas correctamente entre las de build time (NEXT_PUBLIC_*) y las de runtime. Lo que falta por hacer Ambientes de Desarrollo, Staging y Producción.  Actualmente solo hay configuración para staging. Se necesita definir y configurar los tres ambientes con sus respectivas variables de entorno, URLs de ORY, credenciales de AWS, y dominios. Infraestructura como Código.  Los recursos de AWS (EventBridge, Lambda, DynamoDB) y de GCP (Cloud Run, Artifact Registry) deben estar definidos en código, idealmente usando Terraform o AWS CDK para los recursos de AWS y Terraform para los de GCP. Esto permite replicar la infraestructura de forma determinística y mantener un historial de cambios. Monitoreo de Infraestructura.  Se necesitan dashboards de CloudWatch para los recursos de AWS y de Cloud Monitoring para Cloud Run. Alertas automáticas cuando hay errores, latencia alta, o recursos saturados. Dominio y SSL.  Definir cuál será el dominio de CUC v2 (si se mantiene cuentaunica.gob.do o se migra a algo bajo digital.gob.do), configurar los certificados SSL y la integración con Cloudflare o el servicio de protección DDoS que se elija. Backups y Recuperación ante Desastres.  Aunque ORY Network maneja las identidades en su infraestructura, se necesita una estrategia de respaldo para los datos en DynamoDB, los logs, y las configuraciones. También se necesita un plan de recuperación ante desastres que defina los tiempos máximos aceptables de inactividad (RTO) y de pérdida de datos (RPO). 4. Seguridad Lo que ya se hizo ORY Network proporciona cifrado en tránsito (HTTPS/TLS 1.2+), cifrado en reposo (AES-256), hash seguro de contraseñas (bcrypt con salt), y tokens de sesión con expiración configurable. AWS Rekognition maneja los datos biométricos bajo los estándares de cumplimiento de AWS (SOC 2, ISO 27001). La validación de cédulas incluye verificación de formato y checksum. Lo que falta por hacer Auditoría de Seguridad.  Antes del lanzamiento, se necesita una auditoría de seguridad completa: revisión del código, pruebas de penetración, y verificación de cumplimiento con las normativas dominicanas de protección de datos. Política de Contraseñas.  Definir y documentar la política de contraseñas: longitud mínima, complejidad requerida, verificación contra bases de datos de contraseñas filtradas (ORY soporta esto con HaveIBeenPwned), y política de expiración. Segundo Factor de Autenticación (2FA).  ORY soporta TOTP (Google Authenticator, Authy) y WebAuthn (llaves de seguridad, biometría del dispositivo). Se necesita implementar la interfaz para que los ciudadanos puedan activar y gestionar su 2FA. Manejo de Datos Sensibles.  Documentar qué datos personales se almacenan, dónde se almacenan, quién tiene acceso, por cuánto tiempo se retienen, y cómo se eliminan cuando el ciudadano lo solicita. Esto es especialmente importante para un proyecto open source donde el código es público. 5. Experiencia de Usuario e Investigación Lo que falta por hacer Pruebas de Usabilidad.  Antes del lanzamiento, se deben realizar pruebas de usabilidad con ciudadanos reales: personas de diferentes edades, niveles de educación, y familiaridad con tecnología. El registro con verificación facial es un proceso que puede intimidar a muchas personas, y necesitamos asegurarnos de que las instrucciones sean claras y el proceso sea lo más sencillo posible. Optimización del Flujo de Registro.  Medir la tasa de abandono en cada paso del registro e identificar oportunidades de mejora. Si muchos ciudadanos abandonan en la verificación facial, tal vez necesitamos mejorar las instrucciones o el manejo de errores en ese paso. Soporte para Dispositivos de Gama Baja.  Muchos ciudadanos dominicanos usan dispositivos Android de gama baja con cámaras de baja resolución. Se necesita probar el flujo de verificación facial en estos dispositivos y ajustar los umbrales de confianza si es necesario. Página de Estado del Servicio.  Crear una página pública donde los ciudadanos puedan verificar si CUC está funcionando correctamente. Esto reduce la carga de soporte cuando hay interrupciones planificadas o incidentes. Resumen del estado actual Para tener una vista rápida del progreso general: El portal ciudadano tiene su estructura base completa, con los flujos de autenticación y registro funcionando en desarrollo. Las decisiones de arquitectura están tomadas y validadas. Sin embargo, falta completar las funcionalidades del dashboard, el sistema de notificaciones, el agente de IA, las pruebas automatizadas, y la auditoría de seguridad y accesibilidad. El backoffice tiene su arquitectura AWS definida pero la aplicación web está en etapas tempranas de desarrollo. Las funcionalidades más ambiciosas como la trazabilidad completa del journey del ciudadano y el sistema de tickets requieren trabajo coordinado entre el equipo del portal y el del backoffice. La infraestructura necesita madurar en cuanto a ambientes, infraestructura como código, monitoreo, y planes de recuperación ante desastres. Este es un proyecto ambicioso, y reconocemos que hay mucho por hacer. Pero la base es sólida: las decisiones tecnológicas están tomadas, la integración con ORY funciona, la verificación biométrica está probada, y el equipo tiene claridad sobre hacia dónde vamos.