Plan de Implementacion — Plataforma Imagy

Contexto

Este plan define el orden de implementacion de los servicios de la plataforma Imagy. El orden se basa en dependencias tecnicas (que servicio necesita que otro exista primero) y prioridad de negocio (ImagLend es el modulo de entrega mas urgente).

Estado actual:

• Imagy Identity (Gateway + Tenant Management): Funcional
• Todos los demas servicios: En diseno (documentacion completa)

Fases de Implementacion

---

Fase 0: Fundamentos (3 semanas)

Objetivo: Crear la infraestructura compartida, librerias base, y servicios transversales (notificaciones y auditoria) que todos los servicios necesitan.

Repos: imagy-shared, imagy-infra, imagy-notifications, imagy-audit

Sprint 0.1 (Semana 1-2): Librerias + Infraestructura

#	Tarea	Repo	Responsable	Dependencia
0.1	Crear proyecto Imagy.Shared con estructura de librerias	imagy-shared	Team Platform	-
0.2	Implementar Imagy.Shared.Identity (IIdentityContext, JwtPropagationHandler)	imagy-shared	Team Platform	0.1
0.3	Implementar Imagy.Shared.Persistence (TenantRlsInterceptor, BaseReadRepository)	imagy-shared	Team Platform	0.1
0.4	Implementar Imagy.Shared.Messaging (BaseConsumer, event signing, idempotency)	imagy-shared	Team Platform	0.1
0.5	Implementar Imagy.Shared.Api (Envelope responses, error middleware, idempotency middleware, ETag middleware)	imagy-shared	Team Platform	0.1
0.6	Publicar paquetes NuGet internos (GitHub Packages)	imagy-shared	Team Platform	0.2-0.5
0.7	Crear proyecto CDK con stacks base (VPC, Aurora, ElastiCache, MQ)	imagy-infra	Team Platform	-
0.8	Crear docker-compose.infra.yml compartido	imagy-infra	Team Platform	-
0.9	Configurar CI/CD base (GitHub Actions template reutilizable)	imagy-infra	Team Platform	0.7
0.10	Crear template de servicio (cookiecutter o script)	imagy-infra	Team Platform	0.6

Sprint 0.2 (Semana 2-3): Servicios Compartidos (Notifications + Audit)

#	Tarea	Repo	Responsable	Dependencia
0.11	Crear proyecto imagy-notifications con estructura Clean Architecture	imagy-notifications	Team Platform	0.10
0.12	Implementar modelo de dominio (NotificationTemplate, NotificationChannel, NotificationRequest)	imagy-notifications	Team Platform	0.11
0.13	Crear migraciones DbUp (notification_templates, notification_logs, channel_configs)	imagy-notifications	Team Platform	0.12
0.14	Implementar canales: SMS (Twilio/SNS), Email (SES), WhatsApp (Meta API), Push (FCM), Webhook	imagy-notifications	Team Platform	0.12
0.15	Implementar API de envio (POST /notifications/send) con template rendering	imagy-notifications	Team Platform	0.14
0.16	Implementar consumer de eventos para notificaciones automaticas	imagy-notifications	Team Platform	0.15
0.17	Crear proyecto imagy-audit con estructura Clean Architecture	imagy-audit	Team Platform	0.10
0.18	Implementar modelo OCSF (Open Cybersecurity Schema Framework) para eventos de auditoria	imagy-audit	Team Platform	0.17
0.19	Crear migraciones DbUp (audit_events, audit_actors, audit_resources) con particionamiento por fecha	imagy-audit	Team Platform	0.18
0.20	Implementar API de registro (POST /audit/events) y consulta (GET /audit/events con filtros)	imagy-audit	Team Platform	0.19
0.21	Implementar consumer de eventos para auditoria automatica (escucha todos los dominios)	imagy-audit	Team Platform	0.20
0.22	Implementar API de reportes (GET /audit/reports con agregaciones por actor, recurso, periodo)	imagy-audit	Team Platform	0.20
0.23	Tests de integracion para notifications y audit	imagy-notifications, imagy-audit	Team Platform	0.15-0.22

Entregables

• Paquetes NuGet: Imagy.Shared.Identity, Imagy.Shared.Persistence, Imagy.Shared.Messaging, Imagy.Shared.Api
• Infraestructura local funcionando (PostgreSQL, Valkey, RabbitMQ, Keycloak)
• CDK desplegable a AWS (staging)
• Template para crear nuevos servicios
• imagy-notifications funcional: SMS, email, WhatsApp, push, webhook con templates configurables
• imagy-audit funcional: registro OCSF, consulta con filtros, reportes agregados

---

Fase 1: ImagFlow — Motor de Flujos (4 semanas)

Objetivo: Implementar el motor de flujos que sera usado por ImagLend e ImagSign.

Repo: imagy-flow-engine

Sprint 1.1 (Semana 1-2): Core del Flow Service

#	Tarea	Dependencia
1.1	Crear proyecto con estructura Clean Architecture	0.10
1.2	Implementar entidades de dominio (Flow, FlowVersion, FlowStep, FlowRule)	1.1
1.3	Crear migraciones DbUp (tablas flows, flow_versions, flow_steps, flow_rules, provider_configs)	1.2
1.4	Habilitar RLS en todas las tablas con tenant_id	1.3
1.5	Implementar CRUD de flujos (crear, listar, obtener, actualizar)	1.2
1.6	Implementar versionamiento (crear draft, publicar, archivar, descartar)	1.5
1.7	Implementar CRUD de pasos (agregar, actualizar, eliminar, reordenar)	1.6
1.8	Implementar CRUD de reglas (agregar, actualizar, eliminar)	1.6
1.9	Implementar asignacion de flujos a tenants/orgs	1.6
1.10	Tests unitarios de dominio (versionamiento, validaciones)	1.2-1.9

Sprint 1.2 (Semana 3-4): Execution Engine + Provider Gateway

#	Tarea	Dependencia
1.11	Implementar Request Service (crear solicitud, generar access_token, ciclo de vida)	1.6
1.12	Implementar sesion de ejecucion en Valkey	1.11
1.13	Implementar Execution Engine (GET /execute/{token}, POST /execute/{token}/steps/{id})	1.12
1.14	Implementar Provider Gateway (IProviderAdapter interface, ProviderRouter) con storage adapter configurable (S3, Azure Blob, GCS, MinIO)	1.1
1.15	Implementar FailoverHandler con circuit breaker (Polly)	1.14
1.16	Crear al menos 1 adapter mock para testing	1.14
1.17	Implementar Rules Engine (evaluacion de condiciones simples y compuestas)	1.8
1.18	Implementar publicacion de eventos (flow.execution.completed, flow.execution.failed, flow.step.completed)	1.13
1.19	Implementar endpoint interno POST /executions/trigger (para ImagLend)	1.13
1.20	Tests de integracion con Testcontainers	1.11-1.19

Entregables

• Flow Service funcional (CRUD + versionamiento)
• Execution Engine funcional (ejecucion de pasos con sesion en Valkey)
• Provider Gateway con failover, circuit breaker y storage adapter configurable (S3/Azure Blob/GCS/MinIO)
• Rules Engine basico
• Eventos publicados en RabbitMQ
• Endpoint interno para trigger programatico

---

Fase 2: ImagSign — Firma Digital (3 semanas)

Objetivo: Implementar el servicio de firma que sera usado por ImagLend para firma de contratos.

Repo: imagy-sign

Sprint 2.1 (Semana 1-2): Core de Firma

#	Tarea	Dependencia
2.1	Crear proyecto con estructura Clean Architecture	0.10
2.2	Crear migraciones DbUp (signature_requests, documents, signature_providers, signature_certificates, signature_audit)	2.1
2.3	Implementar CRUD de solicitudes de firma (crear, listar, obtener, cancelar)	2.1
2.4	Implementar gestion de documentos (upload presigned URL, download, status) via Provider Gateway storage adapter	2.3
2.5	Implementar generacion de signing_token y signing_url	2.3
2.6	Implementar endpoints publicos de firma (GET /sign/{token}, POST /sign/{token}/execute)	2.5
2.7	Implementar firma electronica con OTP via imagy-notifications (send, verify)	2.6, 0.15
2.8	Implementar ISignatureProvider interface	2.1
2.9	Implementar adapter para firma electronica generica (OTP + acceptance)	2.8
2.10	Implementar publicacion de eventos (sign.signature.completed, sign.signature.rejected)	2.6

Sprint 2.2 (Semana 3): Multi-firmante + Proveedores Reales

#	Tarea	Dependencia
2.11	Implementar soporte multi-firmante (array de signers, signing_token por firmante)	2.6
2.12	Implementar estrategias multi-signer (evidence_package, sequential_copies)	2.11
2.13	Implementar tracking de completitud parcial (partial_signed)	2.11
2.14	Implementar adapter para Firmalo (Ecuador)	2.8
2.15	Implementar adapter para Certicamara (Colombia)	2.8
2.16	Implementar webhook de callback de proveedores	2.14-2.15
2.17	Implementar audit trail (signature_audit) con integracion a imagy-audit	2.6, 0.20
2.18	Tests de integracion	2.3-2.17

Entregables

• Solicitudes de firma standalone funcionales
• Firma electronica con OTP via imagy-notifications
• Multi-firmante con estrategias
• Al menos 2 proveedores reales integrados
• Eventos publicados
• Audit trail completo integrado con imagy-audit

---

Fase 3: ImagLend — Creditos (6 semanas)

Objetivo: Implementar el modulo de creditos con pipeline de originacion configurable, productos versionados, cartera y pagos.

Repo: imagy-lending

Sprint 3.1 (Semana 1-2): Productos + Simulador

#	Tarea	Dependencia
3.1	Crear proyecto con estructura Clean Architecture	0.10
3.2	Crear migraciones DbUp (credit_products, product_versions, pipeline_configs, pipeline_steps, credit_applications, credits, etc.)	3.1
3.3	Implementar entidades de dominio (CreditProduct, ProductVersion, PipelineConfig, PipelineStep, CreditApplication, Credit)	3.1
3.4	Implementar CRUD de productos con versionamiento inmutable (como ImagFlow versions: draft, published, archived)	3.3
3.5	Implementar fee_config flexible (array de items con type percentage/fixed)	3.4
3.6	Implementar maker-checker (change_requests) para productos	3.4
3.7	Implementar endpoint publico de simulador (GET /public/products/{code}/simulator-config)	3.4
3.8	Implementar logica de calculo de credito (funcion pura: intereses, fees, impuestos)	3.3
3.9	Property-based tests para calculos financieros	3.8
3.10	Tests unitarios de dominio	3.3-3.8

Sprint 3.2 (Semana 3-4): Pipeline de Originacion Configurable

#	Tarea	Dependencia
3.11	Implementar motor de pipeline configurable (PipelineEngine con steps ordenados y condicionales)	3.3
3.12	Implementar step: landing (pagina de aterrizaje configurable por producto)	3.11
3.13	Implementar step: user_registration (crea usuario en Keycloak realm del tenant, retorna credenciales)	3.11
3.14	Implementar step: legal_consent (documentos versionados con evidencia: version, hash, IP, device fingerprint, timestamp)	3.11
3.15	Implementar step: contact_verification (OTP via imagy-notifications SMS/WhatsApp/email + validacion de unicidad)	3.11, 0.15
3.16	Implementar step: form (campos configurables por producto, validacion dinamica)	3.11
3.17	Implementar step: compliance_check (integracion con buro de credito y AML via ImagFlow)	3.11, Fase 1
3.18	Implementar step: manual_review (cola de revision con auto-aprobacion configurable: score threshold, amount threshold)	3.11
3.19	Implementar step: identity_validation (POST-aprobacion para ahorro de costos de proveedor, via ImagFlow)	3.11, Fase 1
3.20	Implementar step: document_signature (integracion con ImagSign para firma de contrato)	3.11, Fase 2
3.21	Implementar step: disbursement (desembolso configurable por canal)	3.11
3.22	Implementar CRUD de pipeline configs por producto (activar/desactivar steps, reordenar, configurar)	3.11
3.23	Publicar eventos (lending.application.created, lending.pipeline.step_completed, lending.application.decided)	3.11-3.21

Sprint 3.3 (Semana 5-6): Cartera + Pagos + Mora

#	Tarea	Dependencia
3.24	Implementar creacion de credito post-desembolso (Credit entity con estado activo)	3.21
3.25	Implementar generacion de tabla de amortizacion	3.24
3.26	Implementar registro de pagos (POST /credits/{id}/payments)	3.24
3.27	Implementar logica de aplicacion de pagos (cuota, prepago, parcial)	3.26
3.28	Implementar job de deteccion de mora	3.25
3.29	Implementar consumer de subject.profile.blacklisted (rechazar solicitudes pendientes)	3.11
3.30	Publicar eventos (lending.credit.disbursed, lending.payment.received, lending.credit.defaulted)	3.24-3.28
3.31	Implementar endpoints /my/* para Client Portal (GET /my/credits, /my/applications, /my/documents) filtrados por user_id del JWT	3.24
3.32	Implementar notificaciones automaticas via imagy-notifications (aprobacion, rechazo, desembolso, mora)	3.23, 0.15
3.33	Tests de integracion completos	3.11-3.32
3.34	Tests E2E del flujo completo (landing a desembolso via pipeline)	3.33

Entregables

• Productos configurables con versionamiento inmutable y maker-checker
• Simulador publico funcional
• Pipeline de originacion configurable con steps: landing, user_registration, legal_consent, contact_verification, form, compliance_check, manual_review, identity_validation, document_signature, disbursement
• Registro de usuario en Keycloak (realm del tenant) — usuario puede re-ingresar a ver estado
• Consentimiento legal con evidencia completa (version, hash, IP, fingerprint, timestamp)
• Validacion de identidad POST-aprobacion (ahorro de costos)
• Auto-aprobacion configurable por producto (score threshold, amount threshold)
• Desembolso con tabla de amortizacion
• Pagos y deteccion de mora
• Endpoints /my/* para Client Portal
• Notificaciones automaticas multi-canal
• Todos los eventos publicados

---

Fase 4: ImagID — Subject 360 (3 semanas)

Objetivo: Implementar la vista unificada del sujeto que consume eventos de todos los dominios.

Repo: imagy-subject

Sprint 4.1 (Semana 1-2): Core + Consumers

#	Tarea	Dependencia
4.1	Crear proyecto con estructura Clean Architecture	0.10
4.2	Crear migraciones DbUp (subject_profiles SIN RLS, subject_tenant_views, subject_events, subject_devices, subject_list_entries, subject_alerts CON RLS)	4.1
4.3	Implementar ProfileService (get or create, lookup by document)	4.1
4.4	Implementar TenantViewService (metricas agregadas, trust score)	4.3
4.5	Implementar consumers de ImagFlow (flow.execution.completed, failed, step.completed)	4.4
4.6	Implementar consumers de ImagLend (application.created, credit.disbursed, payment.received, credit.defaulted)	4.4
4.7	Implementar consumer de ImagSign (sign.signature.completed)	4.4
4.8	Implementar consumer de Identity (identity.user.created)	4.3
4.9	Implementar calculo de trust score (factores, pesos, umbrales)	4.4
4.10	Implementar cache de trust score en Valkey	4.9

Sprint 4.2 (Semana 3): APIs + Listas + Alertas

#	Tarea	Dependencia
4.11	Implementar APIs publicas (GET /subjects, /subjects/{id}, /subjects/{id}/events)	4.3
4.12	Implementar APIs de dispositivos (GET /subjects/{id}/devices)	4.3
4.13	Implementar CRUD de listas (blacklist, whitelist, watchlist)	4.3
4.14	Implementar APIs internas (GET /internal/subjects/{id}/metrics, /trust-score, /lists/check)	4.9
4.15	Implementar Alert Service (deteccion de patrones, generacion de alertas)	4.9
4.16	Implementar publicacion de eventos (subject.profile.flagged, subject.profile.blacklisted)	4.13, 4.15
4.17	Implementar dispositivos certificados (campos is_certified, public_key en subject_devices)	4.12
4.18	Implementar endpoints /my/* para Client Portal (GET /my/devices, /my/validations) filtrados por user_id del JWT	4.12
4.19	Tests de integracion	4.5-4.18

Entregables

• Perfil unificado cross-tenant
• Consumers de todos los dominios funcionando
• Trust score calculado y cacheado
• Listas de control (CRUD + verificacion)
• Alertas automaticas
• APIs internas para ImagFlow y ImagLend
• Dispositivos certificados registrados
• Endpoints /my/* para Client Portal

---

Fase 5: Frontend — Console + Public + Client Portal (4 semanas)

Objetivo: Implementar las interfaces de usuario para administracion, usuarios finales, y el portal de cliente cross-dominio.

Repos: imagy-console, imagy-console-public

Sprint 5.1 (Semana 1-2): Console Admin

#	Tarea	Repo	Dependencia
5.1	Extender panel admin existente con modulo de ImagLend	imagy-console	Fase 3
5.2	Implementar CRUD de productos de credito (con maker-checker UI)	imagy-console	5.1
5.3	Implementar editor de pipeline (drag-and-drop de steps, configuracion por step)	imagy-console	5.1
5.4	Implementar vista de solicitudes (listado, filtros, detalle, cola de revision manual)	imagy-console	5.1
5.5	Implementar vista de cartera (creditos activos, pagos, mora)	imagy-console	5.1
5.6	Implementar editor de landing page (builder visual)	imagy-console	5.1
5.7	Implementar vista de Subject 360 (perfil, timeline, dispositivos, listas)	imagy-console	Fase 4
5.8	Implementar vista de firmas (solicitudes, estado, documentos)	imagy-console	Fase 2
5.9	Implementar vista de notificaciones (templates, logs, configuracion de canales)	imagy-console	0.15
5.10	Implementar vista de auditoria (busqueda de eventos, reportes)	imagy-console	0.20

Sprint 5.2 (Semana 3-4): Console Public + Client Portal

#	Tarea	Repo	Dependencia
5.11	Crear proyecto imagy-console-public con estructura base	imagy-console-public	0.10
5.12	Implementar TenantResolver (resolucion de contexto por hostname)	imagy-console-public	5.11
5.13	Implementar landing page dinamica (renderiza desde config del backend)	imagy-console-public	5.12, 3.12
5.14	Implementar simulador de credito (sliders, calculo en tiempo real)	imagy-console-public	5.13
5.15	Implementar UI de pipeline de originacion (renderiza steps dinamicos segun config del producto)	imagy-console-public	5.14
5.16	Implementar integracion con ImagFlow (paso de validacion, polling)	imagy-console-public	5.15
5.17	Implementar integracion con ImagSign (paso de firma, iframe/redirect)	imagy-console-public	5.15
5.18	Implementar pagina de ejecucion de flujos (para ImagFlow standalone)	imagy-console-public	5.12
5.19	Implementar pagina de firma (para ImagSign standalone)	imagy-console-public	5.12
5.20	Implementar Client Portal en /{tenant}.reimaginetech.io/mi-cuenta	imagy-console-public	5.12
5.21	Client Portal: vista de creditos (estado, tabla de amortizacion, pagos) — consume /my/* de ImagLend	imagy-console-public	5.20, 3.31
5.22	Client Portal: vista de firmas y documentos — consume /my/* de ImagSign	imagy-console-public	5.20, Fase 2
5.23	Client Portal: vista de dispositivos y validaciones — consume /my/* de ImagID	imagy-console-public	5.20, 4.18
5.24	Client Portal: vista de notificaciones recibidas	imagy-console-public	5.20, 0.15
5.25	Tests E2E del flujo completo (landing a confirmacion + portal)	imagy-console-public	5.15-5.24

Entregables

• Panel admin con modulos de Lending (con editor de pipeline), Sign, Subject 360, Notifications y Audit
• Editor visual de landing pages
• Console publica con landing configurable y white-label
• Pipeline de originacion dinamico (renderiza steps segun configuracion)
• Paginas publicas de ejecucion de flujos y firma
• Client Portal en /{tenant}.reimaginetech.io/mi-cuenta con:
  • Creditos (Fase 3): estado, amortizacion, pagos
  • Firmas y documentos (Fase 2): solicitudes, documentos firmados
  • Dispositivos y validaciones (Fase 4): dispositivos registrados, historial
  • Notificaciones (Fase 0): historial de comunicaciones
• El portal crece con cada fase (Fase 3: creditos, Fase 4: dispositivos/firmas)

---

Fase 6: Post-MVP — Plataforma Avanzada (8-12 semanas)

Objetivo: Evolucionar la plataforma con capacidades enterprise: billing/metering, gestión de proveedores, internacionalización, webhooks para integradores, developer portal, observability avanzada y compliance GDPR.

Repos: imagy-billing, imagy-shared, imagy-infra, servicios existentes

Sprint 6.1 (Semana 1-3): Billing, Metering y Gestión de Proveedores

#	Tarea	Repo	Dependencia
6.1	Crear proyecto imagy-billing con estructura Clean Architecture	imagy-billing	0.10
6.2	Implementar modelo de dominio (Plan, PlanTier, UsageMetric, Invoice, BillingCycle)	imagy-billing	6.1
6.3	Crear migraciones DbUp (plans, plan_tiers, usage_metrics, invoices, billing_cycles, tenant_subscriptions)	imagy-billing	6.2
6.4	Implementar consumers de metering (escucha eventos de todos los dominios: lending.application.created, sign.signature.completed, flow.execution.completed, etc.)	imagy-billing	6.3
6.5	Implementar motor de facturación automática (ciclos mensuales, cálculo por tiers, prorratas)	imagy-billing	6.4
6.6	Implementar alertas de límites (80%, 90%, 100% del plan) via imagy-notifications	imagy-billing	6.5, 0.15
6.7	Implementar dashboards de consumo (GET /billing/usage, /billing/invoices, /billing/projections)	imagy-billing	6.5
6.8	Implementar gestión de proveedores: tarifario por volumen (ProviderContract, ProviderRate, VolumeDiscount)	imagy-billing	6.2
6.9	Implementar contratos de proveedores (vigencia, SLA, documentos adjuntos, renovación automática)	imagy-billing	6.8
6.10	Implementar alertas de margen negativo (costo proveedor vs precio al tenant)	imagy-billing	6.8, 0.15
6.11	Implementar historial de incidentes por proveedor (downtime, errores, SLA breaches)	imagy-billing	6.9
6.12	Tests de integración billing + metering	imagy-billing	6.4-6.11

Sprint 6.2 (Semana 4-6): Internacionalización, Multi-Moneda y Webhooks

#	Tarea	Repo	Dependencia
6.13	Implementar i18n en imagy-shared: resource bundles, locale resolver, fallback chain	imagy-shared	0.6
6.14	Implementar i18n en templates de notificaciones (templates multi-idioma por tenant)	imagy-notifications	6.13
6.15	Implementar i18n en mensajes de error y validaciones de todos los servicios	Todos	6.13
6.16	Implementar soporte multi-moneda: CurrencyConfig por tenant, formatos por país (ISO 4217)	imagy-shared	6.13
6.17	Implementar conversiones de moneda (rate provider adapter, cache en Valkey, reportes en moneda base)	imagy-lending	6.16
6.18	Implementar reportes consolidados multi-moneda (moneda base configurable por tenant)	imagy-lending	6.17
6.19	Crear servicio de webhooks salientes en imagy-shared: WebhookDispatcher, firma HMAC-SHA256, reintentos exponenciales	imagy-shared	0.6
6.20	Implementar configuración de webhooks por tenant (CRUD endpoints, secret rotation, event filtering)	imagy-shared	6.19
6.21	Implementar dashboard de delivery status (entregas exitosas, fallidas, reintentos, latencia)	imagy-shared	6.20
6.22	Integrar webhooks en todos los dominios (lending events, sign events, flow events, subject events)	Todos	6.20
6.23	Tests de integración i18n + multi-moneda + webhooks	Todos	6.13-6.22

Sprint 6.3 (Semana 7-9): Developer Portal y SDK

#	Tarea	Repo	Dependencia
6.24	Implementar API Key management (generación, rotación, revocación, scopes por dominio)	imagy-shared	0.6
6.25	Implementar rate limiting por API key (sliding window en Valkey, límites por plan)	imagy-shared	6.24
6.26	Generar documentación OpenAPI consolidada (todos los servicios, versionada)	imagy-infra	Fase 5
6.27	Crear Developer Portal (documentación interactiva, playground, API explorer)	imagy-console-public	6.26
6.28	Implementar sandbox de testing por tenant (datos aislados, proveedores mock, reset automático)	imagy-infra	6.24
6.29	Crear SDK JavaScript/TypeScript (wrapper tipado sobre REST APIs)	imagy-sdk-js	6.26
6.30	Crear SDK Python (wrapper tipado sobre REST APIs)	imagy-sdk-python	6.26
6.31	Implementar onboarding wizard para integradores (guía paso a paso en Developer Portal)	imagy-console-public	6.27
6.32	Tests E2E del Developer Portal + SDKs	imagy-sdk-js, imagy-sdk-python	6.29-6.31

Sprint 6.4 (Semana 10-12): Observability, Data Retention y GDPR

#	Tarea	Repo	Dependencia
6.33	Implementar observability avanzada: métricas custom por servicio (CloudWatch EMF)	imagy-infra	Fase 5
6.34	Crear dashboards operacionales por servicio (latencia, errores, throughput, saturación — RED/USE)	imagy-infra	6.33
6.35	Definir SLOs/SLAs por servicio y endpoint (error budget, burn rate alerts)	imagy-infra	6.34
6.36	Implementar alertas inteligentes (anomaly detection, composite alarms, PagerDuty/OpsGenie integration)	imagy-infra	6.35
6.37	Crear runbooks operacionales (incident response, rollback procedures, escalamiento)	imagy-infra	6.36
6.38	Implementar políticas de data retention por tipo de dato (configurable por tenant)	imagy-shared	0.6
6.39	Implementar derecho al olvido (GDPR Art. 17): proceso de eliminación/anonimización cross-servicio	imagy-shared	6.38
6.40	Implementar registro de consentimiento GDPR (consent registry, withdrawal, audit trail)	imagy-shared	6.39
6.41	Implementar data export (GDPR Art. 20): portabilidad de datos del sujeto en formato estándar	imagy-subject	6.39
6.42	Implementar DPO dashboard (solicitudes de eliminación, estado, compliance metrics)	imagy-console	6.39-6.41
6.43	Implementar job de purga automática (ejecuta retention policies, genera reportes de cumplimiento)	imagy-shared	6.38
6.44	Tests de integración observability + GDPR	Todos	6.33-6.43

Entregables

• imagy-billing funcional: metering automático, facturación por ciclos, planes con tiers, alertas de límites
• Gestión de proveedores: tarifarios, contratos, SLA tracking, alertas de margen
• Internacionalización: i18n cross-plataforma (backend + templates), multi-moneda con conversiones
• Webhooks salientes: configuración por tenant, firma HMAC, reintentos, dashboard de delivery
• Developer Portal: documentación OpenAPI interactiva, sandbox, API keys, rate limiting
• SDKs: JavaScript/TypeScript y Python con tipos
• Observability: dashboards RED/USE, SLOs, alertas inteligentes, runbooks
• GDPR compliance: data retention configurable, derecho al olvido, portabilidad, consent registry, DPO dashboard

---

Resumen de Timeline

Mapa de Dependencias

Dependencias Criticas

Servicio	Depende de	Para que
ImagLend	ImagFlow	Compliance check y identity validation via flujos
ImagLend	ImagSign	Firma de contrato (step document_signature)
ImagLend	imagy-notifications	OTP en contact_verification, notificaciones de estado
ImagSign	imagy-notifications	Envio de OTP para firma electronica
ImagID	ImagFlow, ImagLend, ImagSign	Consume eventos de todos los dominios
ImagID	imagy-audit	Registra eventos de auditoria
Console Public	ImagLend, ImagFlow, ImagSign	Renderiza pipeline dinamico, flujos, firma
Client Portal	ImagLend, ImagSign, ImagID	Consume endpoints /my/* de cada backend
imagy-billing	Todos los dominios	Consume eventos para metering de uso
imagy-billing	imagy-notifications	Alertas de limites y margen negativo
Developer Portal	Console Public, imagy-shared	Documentacion OpenAPI, API keys
SDKs	imagy-shared	Wrappers tipados sobre REST APIs
GDPR/Retention	imagy-subject, imagy-shared	Eliminacion/anonimizacion cross-servicio
Todos	imagy-shared	Librerias base (identity, persistence, messaging, api)
Todos	imagy-audit	Registro de auditoria OCSF

Equipo Sugerido

Equipo	Fases	Personas
Team Platform	Fase 0 (shared + notifications + audit), Fase 5, Fase 6 (billing, infra, observability, GDPR)	2 backend + 2 frontend
Team Flow	Fase 1, Fase 2	2 backend
Team Lending	Fase 3	3 backend + 1 frontend
Team Subject	Fase 4	1 backend
Team DX	Fase 6 (Developer Portal, SDKs, i18n)	1 backend + 1 frontend

Total estimado MVP (Fases 0-5): ~17 semanas (4 meses) con equipos trabajando en paralelo donde las dependencias lo permiten.

Total estimado con Post-MVP (Fases 0-6): ~29 semanas (7 meses). La Fase 6 puede iniciar 1-2 semanas después de completar Fase 5, con sprints priorizables independientemente.

Servicios del Ecosistema

Servicio	Tipo	Descripcion
imagy-shared	Libreria NuGet	Paquetes compartidos (Identity, Persistence, Messaging, Api, Webhooks, i18n)
imagy-infra	CDK/IaC	Infraestructura como codigo, templates y observability
imagy-notifications	Servicio compartido	Notificaciones multi-canal: SMS, email, WhatsApp, push, webhook
imagy-audit	Servicio compartido	Auditoria OCSF con APIs de consulta y reportes
imagy-billing	Servicio compartido	Metering, facturacion, planes, gestion de proveedores
imagy-flow-engine	Servicio de dominio	Motor de flujos configurable con Provider Gateway
imagy-sign	Servicio de dominio	Firma digital multi-proveedor
imagy-lending	Servicio de dominio	Creditos con pipeline de originacion configurable
imagy-subject	Servicio de dominio	Subject 360 — vista unificada del sujeto
imagy-console	Frontend admin	Panel de administracion multi-modulo
imagy-console-public	Frontend publico	Landing, pipeline de originacion, Client Portal, Developer Portal
imagy-sdk-js	SDK	Cliente JavaScript/TypeScript tipado
imagy-sdk-python	SDK	Cliente Python tipado

Notas

• Las Fases 1 y 2 pueden ejecutarse en paralelo (no dependen entre si)
• La Fase 3 requiere que Fases 1 y 2 esten completas (integraciones con Flow y Sign)
• La Fase 4 puede empezar en paralelo con Fase 3 Sprint 3.2 (cuando los eventos empiezan a publicarse)
• La Fase 5 requiere que los backends esten funcionales
• La Fase 6 puede ejecutarse en sprints independientes — cada sprint (billing, i18n, DevPortal, GDPR) es autocontenido y priorizable por separado
• La Fase 6 Sprint 6.1 (billing) puede iniciar en paralelo con Fase 5 Sprint 5.2 (solo necesita eventos publicados)
• La Fase 6 Sprint 6.3 (Developer Portal) requiere Fase 5 completa (APIs estables)
• Cada fase incluye tests (unit + integration) como parte de las tareas
• El deployment a staging es continuo (cada merge a main despliega)
• Storage NO es un servicio separado — es un adapter configurable dentro del Provider Gateway (S3, Azure Blob, GCS, MinIO)
• imagy-notifications es transversal: lo usan ImagSign (OTP), ImagLend (contact_verification, alertas de estado), y el Client Portal
• imagy-audit es transversal: todos los servicios publican eventos de auditoria en formato OCSF
• imagy-billing es transversal: consume eventos de todos los dominios para metering automatico
• El Client Portal crece incrementalmente: Fase 3 agrega creditos, Fase 4 agrega dispositivos/validaciones
• La validacion de identidad ocurre POST-aprobacion para ahorrar costos de proveedor
• El versionamiento de productos es inmutable (igual que ImagFlow versions)
• El pipeline de originacion es configurable por producto — cada producto define que steps incluye y en que orden
• Los webhooks salientes permiten a tenants integrar sus propios sistemas sin polling
• El Developer Portal es el punto de entrada para integradores externos (API keys, docs, sandbox)
• GDPR compliance es cross-servicio: la eliminacion/anonimizacion debe propagarse a todos los servicios que almacenan datos del sujeto