Cierre y entrega final del Proyecto Final 1: documento final de arquitectura, historias de usuario detalladas del Sprint 1 del Proyecto Final 2, presentación del prototipo final (web, móvil y back-office) con su documentación técnica y guías de usuario, documento de lecciones aprendidas, plan de trabajo y tablero cerrados, y video con evidencias.

1. Documento final de arquitectura Proyecto I
2. Historias de usuario detalladas del Sprint 1 del Proyecto 2
3. Presentación del prototipo web/móvil final
   • 3.1 Se incluye el prototipo final
   • 3.2 Se incluye la documentación técnica
   • 3.3 Se incluye la guía de usuario
4. Documento de lecciones aprendidas Proyecto I
5. Plan de trabajo y tablero cerrados
   • 5.1 Plan de trabajo
   • 5.2 Tablero cerrado
6. Video con evidencias

Diagramas embebidos de las tres vistas actualizadas (funcional, despliegue, información). Si el embebido no se ve bien en tu navegador (los SVG grandes a veces se recortan en la vista de wiki), usa el link "Abrir el SVG completo" debajo de cada uno para verlo en tamaño real con zoom/scroll.

• 1.1.1 Modelo de contexto
• 1.1.2 Vista funcional — Modelo de componentes
• 1.1.3 Vista de despliegue — AWS
• 1.1.4 Vista de información
• 1.1.5 Arquitectura del portal web (MVVM)
• 1.1.6 Arquitectura del cliente móvil (Android)

Convención

Actores por canal

Incluye :Consentimiento como precondición de la salida a Open Finance —conectado a :AdaptadorOF—, el Dominio · Transversal (Documentos, Analítica, Notificaciones) separado de Venta y Operación, interfaces nombradas (ICotizacion, IPerfilamiento, IPublicacion, ISuscripcion, etc.) y los almacenes replicados de :MsPolizas y :MsSiniestros (Principal), que hacen visible sobre el modelo C&C la política de redundancia que se razona en §1.1.4.3.

Abrir el SVG completo: files/componentes_semana5.svg

La decisión de invocar los dos adaptadores en paralelo se declara aquí, sobre el conector; la asignación de ese fan-out a nodos de ejecución y la aritmética que la obliga se documentan en §1.1.3.1.

Lo que este modelo hace evidente es el conector asíncrono y la dirección de sus interfaces (IPublicacion / ISuscripcion). El grupo de consumidores no está dibujado aquí porque es una decisión de asignación: vive en §1.1.3.2, junto a las réplicas y los nodos de ejecución.

Junto con la introducción de concurrencia de §1.1.2.1, son las dos tácticas que se hacen evidentes en dos modelos a la vez: el conector en el modelo C&C, su asignación en el de despliegue.

Los patrones de §1.2.7 aterrizan mayoritariamente tácticas de modificabilidad, no de desempeño. Se documentan sobre este modelo para que la trazabilidad táctica → patrón quede completa. No son los atributos priorizados, pero sostienen a los que sí lo son — el bajo acoplamiento, en particular, es precondición del escalamiento selectivo. Se suman aquí las dos tácticas de disponibilidad que el diagrama hace explícitas con componentes propios: las dos políticas de redundancia sobre los almacenes de pólizas y de siniestros.

Las dos tácticas de redundancia se catalogan sobre este modelo —y no sobre el de despliegue— porque :Sincronizador y las réplicas son componentes con conectores propios, no instancias de un mismo nodo. El razonamiento de por qué son dos políticas distintas, y no una sola, está en §1.1.4.3. El detector de fallas (Monitor, heartbeat / ping-echo) que promueve la réplica pasiva no aparece en este diagrama: se documenta en ese mismo apartado.

Por qué :MsCotización y :MsPerfilamiento son componentes separados. No es modularidad estética: sus curvas de carga no coinciden. :MsCotización escala con la campaña de un socio (EC-ESC-01, pico inducido y previsible); :MsPerfilamiento escala con el cierre de mes de los bancos aliados (EC-LAT-04, pico de originación). Escalarlos juntos obliga a dimensionar por el máximo de ambos. Esta es la justificación de fondo del estilo de microservicios en este caso.

Respuesta a la pregunta 3 del enunciado (¿cómo se protege el presupuesto de latencia de la cotización cuando depende de Open Finance?): no con el :ApiGateway —que añade un salto—, sino porque :CacheOF ya tiene el perfil y la llamada a :AdaptadorOF es una actualización oportunista, no una dependencia bloqueante. EC-LAT-08 corta a 700 ms y :MsCotización resuelve con el respaldo.

Por qué las réplicas de datos son componentes de este modelo y no solo del de despliegue. :DBPolizas (Replica) y :DBSiniestros (Replica) no son la misma decisión repetida en dos servicios: son dos políticas de redundancia distintas, y lo que las separa es el conector, no el nodo. En pólizas se aplica redundancia activa: la réplica cuelga directamente de :DBPolizas y queda dentro del camino de lectura, atendiendo tráfico en producción. En siniestros se aplica redundancia pasiva: aparece un componente intermedio, :Sincronizador, precisamente porque la réplica no debe servir tráfico y solo se promueve ante la caída de la zona. Un modelo de despliegue mostraría en ambos casos dos instancias en zonas distintas y perdería esa diferencia, que es justo la decisión relevante.

Por qué activa en pólizas y pasiva en siniestros. El criterio no es la criticidad del dato sino la naturaleza del problema. En pólizas el problema es de volumen de lectura —la consulta de cobertura vigente llega desde web y desde móvil sobre el mismo dato—, así que una réplica ociosa sería capacidad pagada y desaprovechada: se pone a trabajar y se acepta el desfase acotado del RPO. En siniestros el problema es de continuidad, no de volumen: poner la réplica a servir lecturas introduciría staleness sobre un dato que el cliente lee como el estado vigente de su reclamación, así que se mantiene fuera del tráfico. Los mecanismos, las medidas y el disparador de la promoción están en §1.1.4.3.

Por qué el bajo acoplamiento no es un tema secundario aquí. Solo se puede replicar de forma independiente aquello que no arrastra a sus vecinos. Si :MsCotización dependiera de la implementación de sus colaboradores, escalarla obligaría a escalarlos con ella y desaparecería la ventaja de tener curvas de carga separadas. Es decir: la táctica de modificabilidad es la que hace posible la de escalabilidad.

VPC con subred pública (ALB, WAF, CloudFront) y subredes privadas multi-AZ (EKS con grupos de escalado independientes, RDS PostgreSQL Multi-AZ, ElastiCache Redis, MSK/Kafka), más KMS y Secrets Manager para gestión de credenciales.

Abrir el SVG completo: files/DiagramaDespliegueSolventa.svg

Las dos primeras son decisiones de la familia de asignación: su evidencia se documenta en este modelo de despliegue, no en el de componentes.

El detalle de por qué pólizas usa redundancia activa y siniestros pasiva —incluyendo la tabla comparativa completa y el rol del :Sincronizador— está desarrollado en §1.1.4.3, porque es una decisión sobre el dato, no sobre el nodo de cómputo que lo aloja.

Aritmética que justifica la concurrencia. EC-LAT-07 fija ≤ 120 ms por dependencia externa y EC-LAT-03 fija 400 ms para todo el perfilamiento. Invocar :AdaptadorOF y :AdaptadorOD en serie consume 240 ms de los 400; en paralelo, 120 ms. El fan-out paralelo es, por tanto, condición necesaria para cumplir el escenario con los proveedores sanos.

Corrección tras HA-01 (18/09/2026). Esta aritmética suponía que EC-LAT-07 se cumple, y el experimento demostró que no se cumple frente a un proveedor degradado: el p95 del adaptador con proveedor lento es de 495,6 ms y el 99,78 % de sus llamadas supera los 120 ms (informe detallado). El paralelo sigue siendo mejor que el serie, pero ya no basta como justificación: con un proveedor degradado el fan-out cuesta hasta el timeout duro de 700 ms, que por sí solo excede los 400 ms de EC-LAT-03.

HA-01 validó el desacople oportunista sólo sobre el camino de cotización (:MsCotización → :CacheOF → :AdaptadorOF). El camino de perfilamiento comparte :AdaptadorOF y no se ejercitó: EC-LAT-03 y EC-LAT-04 quedan sin evidencia frente a dependencia degradada, y su cumplimiento depende de que :CacheOD/:CacheOF apliquen allí la misma táctica de actualización oportunista, lo que no está medido. Es candidato a experimento propio.

Cómo se combinan los dos escalamientos. El horizontal es la decisión por defecto, porque aporta elasticidad y tolerancia a la falla de una zona. El vertical se emplea sobre los motores de cálculo para ganar los primeros segundos de la rampa, donde el aprovisionamiento horizontal aún no ha terminado.

Por qué la disponibilidad no se resuelve con una sola política de redundancia. El diagrama de despliegue por sí solo mostraría dos instancias en zonas distintas para pólizas y para siniestros, y esa vista perdería la decisión relevante: cuál de las dos réplicas sirve tráfico. En pólizas el problema es de volumen de lectura (web y móvil consultando la misma cobertura vigente), así que la réplica se pone a trabajar y se acepta el desfase acotado del RPO — es redundancia activa. En siniestros el problema es de continuidad, no de volumen: dejar que la réplica sirva lecturas introduciría staleness sobre un dato que el cliente interpreta como el estado vigente de su reclamación, así que se mantiene fuera del tráfico y solo se promueve cuando el :Monitor detecta la caída de la zona — es redundancia pasiva. El :Sincronizador es el componente que hace esa diferencia visible en el despliegue: sin él, ambas réplicas se verían idénticas.

Qué no resuelve esta redundancia. La disponibilidad ante falla de zona (este modelo) y la latencia de consulta del estado de siniestro (EC-LAT-11, resuelta con CQRS en el experimento HA-08 de §1.3) son dos problemas distintos que comparten componente pero no solución: la réplica pasiva de :DBSiniestros no está diseñada para servir el p95 ≤ 150 ms que exige la consulta de estado, solo para sobrevivir a la caída de la zona.

Convención

Formato del diagrama

Modelo entidad-relación por microservicio (ms_identidad, ms_consentimiento, ms_cotizacion, ms_perfilamiento, ms_suscripcion, ms_polizas, ms_siniestros, ms_pagos, ms_parametrico, ms_socios, analitica, notificaciones), con claves foráneas cruzando límites de servicio donde aplica.

Abrir el SVG completo: files/ModeloDatosSolventa.svg

Convención

Abrir la imagen completa: out/images/vista_informacion_flujo_control/Solventa_Vista_Informacion_Flujo_Control.png · Fuente PlantUML: images/vista_informacion_flujo_control.puml

Recorrido 1 — Cotización y perfilamiento (pasos 1 a 13). El control entra por el API Gateway / BFF y baja al microservicio de Cotización & Rating, que primero consulta la caché de perfiles. Con acierto de caché (perfil válido < 24 h) el recorrido termina ahí y no hay salida a la red externa. Con fallo o perfil desactualizado se invoca al Adaptador Open Finance contra el proveedor, con timeout duro de 700 ms; si el proveedor responde dentro del presupuesto de ≤ 120 ms por dependencia externa, el perfil se enriquece, y si falla o excede el corte, el adaptador devuelve un perfil estándar por defecto y el flujo continúa. En ambas ramas el perfil calculado se reescribe en caché con TTL de 24 h antes de calcular la prima. Es el mismo comportamiento que fija EC-LAT-09 y que se argumenta en §1.1.4.4.

Recorrido 2 — Emisión, persistencia y consistencia eventual (pasos 14 a 20). Emisión & Pólizas escribe la póliza en su propio almacén y espera el commit; solo después publica PolizaEmitidaEvent en el broker y responde al socio. Notificación legal, conciliación de recaudo y auditoría regulatoria (SFC) quedan del lado asíncrono, fuera del camino crítico de la respuesta — es la táctica limitar la respuesta a los eventos de §1.1.2.1 vista desde los datos, y sostiene tanto EC-LAT-05 como la trazabilidad que exige EC-SEG-04.

Estructuras de datos que atraviesan el flujo

Cada almacén propio se replica sobre las subredes privadas multi-AZ de §1.1.3, pero no con la misma política en todos los servicios: la decisión se fija en este modelo.

Abrir la imagen completa: out/images/DiagramaRedundanciaPolizasSiniestros/DiagramaRedundanciaPolizasSiniestros.png · Fuente PlantUML: images/DiagramaRedundanciaPolizasSiniestros.puml

Por qué dos políticas de redundancia y no una sola. En pólizas el problema es de volumen de lectura: la consulta de cobertura vigente llega desde web y desde móvil sobre el mismo dato, y mantener una réplica ociosa sería pagar capacidad que hoy alivia al nodo de escritura. Por eso la réplica está en el camino de lectura y se acepta el desfase acotado del RPO. En siniestros el problema no es volumen sino continuidad: poner una réplica a servir lecturas ahí introduciría staleness sobre un dato que el cliente interpreta como estado vigente de su reclamación, así que la réplica se mantiene fuera del tráfico y solo se promueve cuando el Monitor (heartbeat / ping-echo) detecta la caída de la zona.

Qué no resuelve esta réplica. La lectura de baja latencia del estado de siniestro (EC-LAT-11) no se atiende con la réplica de disponibilidad: se atiende con un modelo de lectura separado (CQRS), que es precisamente la hipótesis que valida el experimento de §1.3 sobre la historia HA-08. Separar los dos problemas —disponibilidad de la zona por un lado, latencia de consulta por el otro— es la decisión de fondo de este modelo: mezclarlos habría llevado a exigirle a una réplica de failover un objetivo de desempeño que no está diseñada para cumplir.

Dónde queda el detector de fallas. Las dos políticas de redundancia sí quedan catalogadas como tácticas sobre el modelo C&C, en §1.1.2.3, porque las réplicas y el Sincronizador son componentes del diagrama de componentes. El Monitor que emite heartbeat / ping-echo hacia :MsPolizas, :MsSiniestros y el Sincronizador solo aparece en este modelo de replicación: es una táctica de disponibilidad, no de desempeño, y por eso no figura en el catálogo de §1.2.4 ni de §1.2.5.

Este modelo no aporta tácticas propias: el catálogo clasifica como Modelo C&C la única táctica que actúa sobre los datos (múltiples copias de datos), de modo que su ficha vive en §1.1.2.1. Lo que sigue es el razonamiento sobre las decisiones de información que ese reparto implica. La estrategia de replicación entre zonas se desarrolla en el apartado anterior, §1.1.4.3.

Un almacén por servicio, no un esquema compartido. El estilo de microservicios de §1.2.3 define cada unidad desplegable con almacén propio; por eso el modelo entidad-relación está agrupado por microservicio (ms_identidad, ms_consentimiento, ms_cotizacion, ms_perfilamiento, ms_suscripcion, ms_polizas, ms_siniestros, ms_pagos, ms_parametrico, ms_socios, analitica, notificaciones) y no como un esquema único. Lo que se paga a cambio está declarado en el mismo estilo: consistencia distribuida. Las claves foráneas que cruzan límites de servicio son la excepción explícita del modelo, no la regla.

Dónde se acepta consistencia eventual y dónde no. Aplica la regla de reparto de §1.2.3: es síncrono lo que el usuario espera mirando la pantalla (cotizar, perfilar, suscribir, emitir) y asíncrono lo que puede converger después (notificar, analizar, conciliar, telemetría paramétrica). Por eso la información que alimenta a :Analitica, :Notificaciones y :Documentos se propaga por :BusEventos y se lee con consistencia eventual, mientras que la cadena cotización → póliza → siniestro / pago mantiene consistencia inmediata dentro de su propio almacén. El costo declarado del estilo publicador-suscriptor —consistencia eventual e idempotencia— se paga solo de ese lado, y es el mismo requisito de procesamiento exactamente una vez que fija EC-ESC-03.

Copias hacia proveedores externos. Además de la replicación entre zonas (§1.1.4.3), :CacheOF y :CacheOD conservan una copia local con valor de respaldo del perfil de Open Finance / Open Data: la llamada al adaptador es una actualización oportunista y no una dependencia bloqueante, que es lo que permite resolver EC-LAT-09 sin depender de la disponibilidad del tercero.

Diagrama de componentes del portal web Angular: View (componentes standalone, sin lógica de negocio) → ViewModel (estado observable con signals, expone loading / ready / degraded / error) → Model (dominio puro, casos de uso y puertos, arquitectura hexagonal en el front). Cada uno de los cinco recorridos críticos (cotización, suscripción y emisión, perfilamiento hipotecario, siniestro asistido, ciclo de vida de póliza) es un feature module con lazy loading.

Abrir en tamaño completo: files/Diagram-web/solventa-portal-web-mvvm.png · Fuente PlantUML: files/Diagram-web/solventa-portal-web-componentes_1.puml · Documento completo (razonamiento, código de ejemplo, convenciones de carpetas, riesgos): files/Diagram-web/mvvm-portal-web-solventa_1.md

Diagrama de capas en tiempo de ejecución de la app Android (Kotlin / Jetpack). No describe el sistema Solventa completo: cubre el canal móvil (login, póliza, siniestro con evidencia, pagos y renovación) y cómo el cliente se conecta al Mobile BFF y a Room en modo offline-first. El bloque Identidad (derecha) concentra biometría, tokens y el interceptor JWT.

Capas (izquierda → derecha)

Abrir el SVG completo: images/android-arquitectura-runtime.svg

Catálogo de desempeño del curso. Desempeño = habilidad de cumplir requerimientos de tiempo; se subdivide en latencia (tiempo entre evento y respuesta) y escalabilidad (incrementar la carga sin perjudicar los tiempos de respuesta).

La utilización de un API gateway está catalogada por el material como táctica de disponibilidad (ocultar localización e instancias, enmascarar fallas), con uso complementario en seguridad.

Las decisiones de este documento se sustentan sobre los siguientes modelos:

Regla de reparto. Es síncrono lo que el usuario espera mirando la pantalla (cotizar, perfilar, suscribir, emitir). Es asíncrono lo que puede converger después (notificar, analizar, conciliar, telemetría paramétrica). Esa frontera es la decisión que más pesa sobre latencia y escalabilidad a la vez.

Esta sección queda como índice de trazabilidad: cada táctica se detalla ahora dentro del modelo que la hace evidente, junto al diagrama correspondiente.

Razonamiento asociado: §1.1.2.4 — protección del presupuesto de latencia frente a Open Finance — y §1.1.3.4 — aritmética que justifica la concurrencia.

Esta sección queda como índice de trazabilidad: cada táctica se detalla ahora dentro del modelo que la hace evidente, junto al diagrama correspondiente.

Razonamiento asociado: §1.1.2.4 — por qué :MsCotización y :MsPerfilamiento son componentes separados — y §1.1.3.4 — cómo se combinan los dos escalamientos.

Esta sección queda como índice de trazabilidad: cada táctica se detalla ahora dentro del modelo que la hace evidente, junto al diagrama correspondiente.

Razonamiento asociado: §1.1.2.4 — por qué el bajo acoplamiento no es un tema secundario aquí, y por qué la redundancia es activa en pólizas y pasiva en siniestros — §1.1.4.3 — mecanismos, medidas y disparador de la promoción — y §1.1.4.4 — consecuencias sobre el modelo de información.

Cada patrón se presenta con la táctica que aterriza (descrita en §1.2.4, §1.2.5 o §1.2.6), el componente donde vive, el modelo que lo hace evidente, el escenario que sostiene y la razón por la que se tomó la decisión — no solo qué hace, sino qué alternativa se descartó y qué se aceptó a cambio.

Por qué esta decisión. Solventa expone su núcleo a cuatro canales con ciclos de vida independientes: una app móvil que queda instalada en el dispositivo del cliente, un portal web, más de treinta socios que integran una vez y no vuelven a tocar el código, y un flujo de telemetría. Sin un punto de entrada único, cada canal quedaría atado a la topología interna del backend: dividir un microservicio o cambiar su dirección obligaría a coordinar el redespliegue de apps ya instaladas y de integraciones de terceros que Solventa no controla. La alternativa —exponer los microservicios directamente— era más simple y más rápida, pero congelaba la estructura interna. Se aceptó un salto de red adicional en el camino crítico a cambio de poder reorganizar el backend sin romper contratos externos, y como beneficio secundario el punto único es donde se concentran el control de acceso y el enmascaramiento de fallas.

Por qué esta decisión. Los tres canales no piden lo mismo. La web cubre la gestión completa del negocio; el móvil un subconjunto de tareas rápidas con evidencia, biometría y modo offline; los socios solo cotización y emisión embebidas. Una API única para los tres obligaría a servir el máximo común denominador, y el cliente compensaría la diferencia con varias llamadas encadenadas — un costo que se paga directamente contra el presupuesto de 1,5 s de EC-LAT-05. La alternativa era una sola API y clientes más gordos; se descartó porque traslada al canal un trabajo de composición que el borde hace mejor y más cerca de los datos. Se aceptó mantener tres piezas de borde en vez de una a cambio de que cada canal evolucione a su propio ritmo y de que la agregación ocurra donde no cuesta latencia.

Por qué esta decisión. El enunciado es explícito en que gran parte del valor del negocio depende de integraciones fuera del control de Solventa, y que la regulación de Finanzas Abiertas sigue madurando. Sin una capa de traducción, el esquema de cada proveedor se filtraría hasta el dominio: los campos de Open Finance aparecerían dentro del motor de riesgo y los de la pasarela dentro de pagos. Ese acoplamiento convierte un cambio de proveedor —o un cambio normativo del proveedor— en un cambio transversal que toca varios componentes. Se aceptó una indirección adicional por llamada a cambio de que la sustitución de un tercero quede contenida en un solo módulo, que es exactamente lo que EC-MOD-05 exige medir.

Por qué esta decisión. Un mismo hecho de negocio —una póliza emitida, un siniestro aprobado, un pago aplicado— le interesa a varios consumidores a la vez: analítica, notificaciones, documentos, y mañana fraude o reportes al regulador. Con comunicación punto a punto, cada consumidor nuevo obliga a modificar y redesplegar al productor, y la lista de consumidores solo crece con el negocio. El mediador invierte esa dependencia: el productor publica el hecho y deja de saber quién lo escucha. Se aceptó consistencia eventual —y la obligación de resolver idempotencia y trazabilidad— a cambio de poder sumar consumidores sin tocar productores y de absorber picos con contrapresión en lugar de propagarlos.

Por qué esta decisión. No es una elección estética: es la consecuencia obligada de haber adoptado concurrencia. La táctica de introducción de concurrencia multiplica los hilos dentro de cada réplica, y la de múltiples copias de computación multiplica las réplicas. Si cada hilo abriera su propio pool, las conexiones contra el almacén crecerían como hilos × réplicas — con 4 hilos y 20 réplicas son 80 pools golpeando la misma base. La contienda que se eliminó en el cómputo reaparecería en la persistencia, y las dos tácticas de escalamiento se anularían entre sí. Una única instancia por proceso acota las conexiones y deja que el paralelismo escale sin castigar el almacén.

Por qué esta decisión. En una arquitectura distribuida cada decisión que se toma lejos de su dato cuesta un viaje de red, y ese viaje se descuenta de un presupuesto de 400 ms del que 120 ms ya están comprometidos por dependencia externa. La alternativa natural —un motor de reglas central que decidiera por todos los dominios— habría sido más fácil de gobernar, pero obligaría a que perfilamiento le enviara el perfil completo y esperara, y convertiría ese motor en cuello de botella común y en punto único de acoplamiento. Se prefirió pagar en gobierno (dos motores en vez de uno) para no pagar en latencia, poniendo cada decisión pegada al componente que ya tiene la información para tomarla.

Por qué esta decisión. El precio y la política de aceptación de riesgo cambian con una frecuencia que dicta actuaría, no ingeniería, y cambian por razones distintas entre sí. Si esa lógica viviera dentro de los orquestadores, cada ajuste de fórmula obligaría a redesplegar la cotización completa y a arrastrar en el mismo despliegue código que no cambió. Se separó el motor de quien lo orquesta para que la unidad de cambio coincida con la unidad de despliegue, que es la condición que EC-MOD-03 mide: el 100 % del cambio se despliega sin tocar componentes ajenos al motor de rating.

Por qué esta decisión. El bajo acoplamiento se suele justificar solo por modificabilidad, pero en este caso es precondición de los dos atributos priorizados: solo se puede replicar de forma independiente aquello que no arrastra a sus vecinos. Si :MsCotización dependiera de la implementación de sus colaboradores, escalarla obligaría a escalarlos con ella y desaparecería la ventaja de tener curvas de carga separadas. Por eso se aplicaron los tres mecanismos del catálogo a la vez —interfaz, intermediario orientado a mensajes y adaptador— en lugar de conformarse con uno. Se aceptó más piezas y más contratos que mantener a cambio de que el escalamiento selectivo sea realmente posible.

Por qué esta decisión. Tener adaptadores no basta: si el dominio conociera al adaptador concreto y controlara su creación, seguiría atado a una implementación y el beneficio se perdería en el primer cambio de proveedor. Invertir la dependencia significa que el dominio declara qué necesita y recibe una abstracción ya construida, sin saber quién la implementa ni gestionar su ciclo de vida. Ese detalle es lo que convierte la contención del cambio en una propiedad verificable: por eso EC-MOD-05 puede exigir que el 100 % del cambio quede dentro del módulo de integración, y EC-INT-03 que el 100 % de los consumidores existentes siga operando sin modificación.

Por qué esta decisión. En una arquitectura de microservicios con base de datos por servicio, la pregunta de quién instancia cada entidad no es un detalle de código: determina qué servicio es dueño de su ciclo de vida y, por lo tanto, de su almacén. Si un componente ajeno creara la evidencia de un siniestro, tendría que conocer el estado de la reclamación y quedaría acoplado al servicio que la gobierna, rompiendo la frontera del dato. Aplicar la regla de que crea quien contiene y usa estrechamente al objeto confina el ciclo de vida de cada entidad a su microservicio, que es la precondición del almacén propio por servicio y de la trazabilidad entre las tres vistas: componente que crea → entidad de dominio → esquema propietario.

Por qué esta decisión. El negocio de Solventa crece incorporando ramos: viaje, dispositivos, microseguros de vida, paramétricos, protección de pagos. Si cada ramo nuevo obligara a modificar los orquestadores, el costo de crecer aumentaría con el tamaño del portafolio y la meta de expansión regional se volvería inviable. Al concentrar la variabilidad del negocio en los motores, cada motor tiene una sola razón de cambio (SRP) y a la vez es el único punto por donde el producto se extiende (OCP). Son las dos caras de la misma decisión: lo que hace barato modificar es exactamente lo que hace barato extender. Que el patrón aparezca tres veces, y no una, es lo que lo convierte en principio aplicado y no en coincidencia.

Un trade-off es lo que se sacrifica para conseguir algo. Ninguna decisión mejora todos los atributos a la vez; lo que sigue no son defectos ni deuda pendiente, sino decisiones conscientes con su mitigación.

• Enunciado del caso: files/MISW4501-202614-Proyecto.pdf — §4 Ecosistema de integraciones, §6.1 Latencia, §6.2 Escalabilidad, §8 Decisiones de arquitectura, §9 Preguntas de discusión.
• Hoja de trabajo — objetivos de negocio y escenarios de calidad EC-*.
• Visión de arquitectura — modelos de contexto, dominio, componentes, datos y despliegue.

Los dos experimentos de arquitectura quedan ejecutados y cerrados. En la semana 6, HA-01 estaba al 60 % —montaje implementado, sin corridas—; en esta semana se ejecutó la campaña completa y ambos experimentos llegan al 100 %.

Trazabilidad de la evidencia cruda. En ambos experimentos cada cifra citada es recalculable sin reproducir las corridas: los datos crudos por corrida están versionados en el repositorio de código (métricas finales, configuración efectiva, verificaciones de sanidad, resumen de k6 y series temporales segundo a segundo), junto con el consolidado en CSV y las figuras del informe. En HA-01 se versiona además una instantánea completa de la base de Prometheus (raspado de 1 s, 20 MB comprimidos) que cubre toda la campaña, de modo que cualquier percentil puede recalcularse por fase sin volver a correr nada.

Dictamen global

Detalle por sub-hipótesis — HA-08 (informe completo: Informe HA-08 · detallado)

Detalle por sub-hipótesis — HA-01 (informe completo: Informe HA-01)

Restricciones de presupuesto evaluadas en HA-01

El incumplimiento de EC-LAT-07 no debilita HD-01, la refuerza. Si la dependencia cupiera en 120 ms cabría preguntar para qué hace falta la actualización oportunista. Lo que muestra la evidencia es lo contrario: con el proveedor degradado la dependencia no cabe, y por eso el desacople no es una optimización sino la condición para cumplir el ASR de cotización. El brazo C cumple justamente porque abandona al agotar el presupuesto, que es el mecanismo bajo prueba.

El hallazgo principal de HA-01: el mérito del interruptor y el del desacople son separables

Con fallos intermitentes del 30 %, el circuit breaker no llega a abrir en ningún brazo —no se alcanzan diez fallos consecutivos ni el 50 % de la ventana, breaker_max = 0 en las ocho corridas— y aun así B incumple (1,10–1,25 %) y C cumple (0,00 %). Como el interruptor no interviene en ninguno de los dos, la diferencia es atribuible solo al desacople. Es el argumento más fuerte del experimento porque elimina la explicación alternativa, y se verificó bajo los dos modelos de fallo posibles (fallo atado al cliente y fallo derivado de un contador por petición), con el resultado manteniéndose en ambos.

Decisiones que merecen ser corregidas o revisadas (se materializan en Hoja de trabajo semana 7 · §3.1)

Backlog / tablero Jira: SOLV — Backlog · Sprint 1

Backlog del Sprint 1 en Jira: SOLV — Sprint 1

Criterio de «historia refinada». Una HU está refinada cuando su descripción en Jira trae las 7 piezas del modelo de referencia (SOLV-215 · HU-90 Login):

Las 69 historias comprometidas están refinadas, incluidas las 14 del Sprint 1. Cada una tiene en Jira su lista de criterios de aceptación, Gherkin con camino feliz y camino alterno, dependencias y bloque Fuera; las 24 que tienen pantalla traen además navegación, prototipo, enlace de Figma e imagen del frame, y los 13 slices de BFF declaran los servicios que consumen y la historia de canal que los usa.

Las historias que pertenecen a un recorrido medido citan además el escenario de calidad con su meta: HU-6 y HU-7 el presupuesto de la cotización (EC-LAT-01 / EC-LAT-02), HU-13 el de suscripción y emisión (EC-LAT-05 / EC-LAT-06), HU-18 y HU-31 el de consulta (EC-LAT-10 / EC-LAT-11), HU-33 el pico paramétrico (EC-ESC-03 / EC-ESC-04), HU-53 la revocación del consentimiento (EC-SEG-03) y HU-55 el perfilamiento en línea (EC-LAT-03 / EC-LAT-04) junto con la reconstrucción de decisiones (EC-SEG-04).

La evidencia viva, historia por historia, está en el tablero de Jira.

El prototipo navegable en Figma se cierra en esta semana. La versión final del cliente es Screens · S7 validación (web y Android). Screens de S6 no se toca. Frente al avance de la semana 6, S7 incorpora el contexto de ramo y estado de la validación del 18 sep, y el archivo web suma el back-office de asesor y operador.

Página completa del entregable: Prototipo web/móvil · Cliente y back-office

Versión final (S7): Abrir y recorrer el prototipo web · Abrir y recorrer el prototipo móvil · Abrir y recorrer el back-office · Design web S7 · Design Android S7 · Design back-office

Navegación a la funcionalidad definida

• Abrir y recorrer el prototipo web — S7, inicia en Login (1440). Clickeable de punta a punta, sin cuenta de Figma.
• Screens · S7 validación · web — archivo de diseño de la versión final.
• Detalle del prototipo web · pantallas y navegación — recorridos, TopNav y trazabilidad pantalla ↔ HU.
• Recorridos críticos cubiertos — paridad con los seis recorridos del enunciado §5.1.

Condiciones de usabilidad

Navegación sobre la funcionalidad definida

• Abrir y recorrer el prototipo móvil — S7, inicia en Splash (390). BottomNav y sheets.
• Screens · S7 validación · Android — archivo de diseño de la versión final.
• Detalle del prototipo móvil · pantallas y navegación — recorridos y trazabilidad pantalla ↔ HU.

Condiciones de usabilidad

Herramienta de escritorio para asesor y operador. Vive en la página Back-office · Asesor / Operador del archivo web (127:2); no se clona a Screens · S7. Cierra las 8 HU del grupo A que en Lucid figuraban como Falta UI.

Navegación a la funcionalidad definida

• Abrir y recorrer el back-office — inicia en Login del asesor (bo-login). Entrar abre Clientes.
• Back-office · Asesor / Operador — archivo de diseño (login, CRUD de clientes, colas COT/POL, avisos).
• Detalle del prototipo back-office · pantallas y navegación — TopNavAdmin, trazabilidad HU y estados alternos.
• Asesor · clientes (CRUD) — lista de personas (web/Android) → ficha → editar / dar de baja / cotizar.
• Asesor · nueva cotización — picker de ramo (Dispositivo · Viaje · Vida · Clima y vuelos · Pagos · Hipotecario); los datos de riesgo cambian como en el canal del asegurado.
• Operador · avisos — cola con filtros → detalle → aprobar o rechazar.

Condiciones de usabilidad

Fuera del alcance del prototipo, declarado explícitamente: portal de socio (aliados), back-office en 768/390 —es una herramienta de escritorio, solo se diseñó 1440— y el código Angular / Compose, que es objeto del Proyecto Final 2. Ver Fuera de este avance.

Documentación Técnica UX/UI — Solventa

Referencia de diseño para construir los canales de Solventa: tokens, componentes, pantallas y flujos, con el identificador exacto de cada frame en Figma.

Fuentes de diseño

Stack de implementación. Web: AngularJS + TypeScript, unitarias con Karma y E2E con Cucumber/Gherkin. Móvil: Android nativo (Kotlin + Jetpack Compose), Clean Architecture + MVVM + Repository, unitarias con JUnit. No es híbrido ni comparte código de UI entre canales. Detalle en Estrategia de pruebas §4.

Páginas relacionadas: Arquitectura de información · Prototipo navegable · Cumplimiento axe/Nielsen · cliente · · back-office · Validación con usuario

Índice

1. Guía de estilos (design tokens)
2. Catálogo de componentes UI
3. Inventario de pantallas por plataforma
4. Flujos de navegación
5. Consideraciones técnicas

Ambos archivos comparten paleta, tipografía y escala. La diferencia está en cómo se declaran: el archivo móvil usa cuatro colecciones de variables con primitives aliasados por rol semántico; el web usa una sola colección de color con modos Light/Dark.

Material 3 con primary #005050. Cada token existe en Light y Dark; en Android los roles apuntan a un primitivo mediante alias.

Regla de pares. Un fill primary siempre lleva texto on-primary; nunca texto primary sobre fill primary. Los pares verificados en S7 cumplen WCAG 2.2 §1.4.3 AA: on-surface / surface 16.4:1, on-surface-variant / surface 8.9:1, on-primary / primary 9.3:1.

Deuda registrada. El helper de campos (#6e7979 sobre #f7faf9) da 4.28:1 a 12 px; AA exige 4.5:1. Corregir subiendo el tamaño o oscureciendo el token. Ver Cumplimiento axe/Nielsen.

Hanken Grotesk para UI, JetBrains Mono para montos e identificadores. No se usa Inter.

Por qué mono en cifras. Los dígitos tabulares alinean verticalmente en tablas y listas, y distinguen POL-90102 de texto corrido. Todo monto pasa por el formateador de locale: el núcleo entrega prima y código de moneda, el canal formatea (PL-01).

El archivo móvil declara además padding/xs…xl con los mismos valores, para distinguir separación de relleno al bindear.

Breakpoint = ancho de canvas en el que cambia el layout web. No aplica a la app Android, que es nativa a 390.

El back-office solo existe a 1440: es herramienta de escritorio.

Material Symbols (Rounded). El archivo móvil publica 15 iconos como componentes individuales bajo Icon/*:

placeholder · back · home · description · emergency_home · person · check · cancel · info · chevron_right · visibility · add · lock · menu · error

Un icono nunca comunica estado por sí solo: siempre lleva texto asociado.

Cada uno vive en su propia página del archivo de design system, con variantes formales y slots de texto expuestos como propiedades.

Select con seis ramos. Las opciones son los ramos L1 renombrados tras la validación con usuario: Protección de dispositivo, Microseguro de vida, Clima y vuelos, Vida hipotecario, Pagos, Viaje. Reemplazan a «SOAT» y «Hogar», que no se entendían fuera de contexto colombiano.

Definidos en la página Chrome del archivo web.

Estados de campo documentados en la galería: DEFAULT, FOCUS, ERROR (con mensaje) y DISABLED (40 % de opacidad). Badges de cliente: Vigente · En curso · Oferta · Rechazada · Pendiente. El stepper de emisión marca Cotizar → Oferta → Emisión → Póliza → Aviso.

Cuatro sets propios en la página Back-office · Asesor / Operador. Nacen porque el cliente administra sus pólizas mientras el asesor opera carteras de terceros: la arquitectura de información es distinta, no una variante de la de cliente.

Todos reutilizan Button y Footer del cliente como instancias, y bindean la misma colección Color: el back-office hereda el design system, no lo duplica.

82 frames en total. El identificador abre el frame directamente en Figma.

Canvas 390 × 844. Página Screens del archivo de design system.

Estados de permiso y denegación (HU-101, HU-24) — misma ruta, otra UI:

Overlays (bottom sheets; cierran con Close y no empujan el NavHost): overlay-idioma-region [102:738] · overlay-permiso-ubicacion [102:782] · overlay-permiso-camara [102:811] · overlay-permiso-fotos [102:840] · overlay-consentimiento-datos [111:773] · overlay-consentimiento-vida-crediticia [111:784] · overlay-cerrar-sesion [54:768]

Canvas 1440. Página Screens.

Overlays web (diálogos que cierran con Close, no rutas): overlay-idioma-region [7:318] · overlay-consentimiento-datos [7:326] · overlay-consentimiento-vida-crediticia [7:334] · overlay-cerrar-sesion [7:342] · overlay-ubicacion-navegador [62:391]

Responsive (página Responsive) — demuestra que la IA se conserva y solo cambia el layout:

Canvas 1440, solo desktop. Página Back-office · Asesor / Operador.

Gestión de clientes y listas (ampliación posterior del equipo):

Cotización por ramo — cinco variantes del formulario, una por ramo L1: asesor-cotizacion-viaje [254:1191] · -vida [254:1289] · -clima [254:1387] · -pagos [254:1485] · -hipotecario [254:1583]

Asesor · cartera	Operador · cola de avisos

Ambos archivos tienen una página Screens · S7 validación con la versión revisada tras la inspección de accesibilidad y la prueba con usuario: 34 frames en web y 39 en móvil. Cada uno cierra con su propio tablero de hallazgos — web 178:382, móvil 216:811.

Esta es la versión vigente para implementar el canal cliente. Las páginas Screens originales quedan como historial del prototipo de la semana 6.

Qué cambió respecto a Screens

Galería de los seis recorridos críticos (PDF §5.1) en ambos canales. El resto de frames se consulta en Figma.

Web · login	Web · registro	Web · consentimiento-datos

Móvil · onboarding	Móvil · login

Web · idioma-region	Web · inicio	Móvil · idioma-region	Móvil · inicio

Web · nueva-cotizacion	Web · ver-oferta	Web · poliza-emitida

Móvil · nueva-cotizacion	Móvil · ver-oferta	Móvil · poliza-emitida

El indicador «paso N de 4» y el CTA de continuidad cierran el salto Aceptar → Ver mi póliza que detectó la validación.

Web · aviso-siniestro	Móvil · aviso-siniestro	Móvil · permiso-camara	Móvil · evidencia-siniestro

La diferencia de canal se ve aquí: el móvil pide permiso JIT al usar la cámara; el web adjunta archivo y usa el prompt del navegador.

Web · parametrico	Móvil · parametrico	Web · oferta-hipotecario	Móvil · oferta-hipotecario	Web · detalle-poliza

flowchart TB
  Splash["splash-solventa"] --> Idioma["idioma-region"]
  Idioma -->|"Mexico"| IdiomaMx["idioma-region-mx<br/>$1,234.56 MXN"]
  Idioma --> Onboarding["onboarding<br/>datos + documento"]
  IdiomaMx --> Onboarding
  Idioma -->|"Ya tengo cuenta"| Login["login"]
  Onboarding --> Consent["consentimiento-datos<br/>habeas data"]
  Consent --> Inicio["inicio"]
  Login -->|"credenciales invalidas"| LoginErr["login-error<br/>estado, no ruta"]
  LoginErr --> Login
  Login -->|"exito"| Inicio

  Inicio -->|"CTA Nueva cotizacion"| Cotizar["nueva-cotizacion<br/>paso 1 de 4"]
  Cotizar --> Oferta["ver-oferta<br/>prima, moneda, venceEn"]
  Oferta -->|"vencida"| Cotizar
  Oferta -->|"Aceptar"| Emision["emision-progreso"]
  Emision -->|"aprobada"| Emitida["poliza-emitida"]
  Emision -->|"rechazada HU-13"| Rechazo["suscripcion-rechazada<br/>motivo persistido"]
  Emitida -->|"Ver mi poliza"| Detalle["detalle-poliza"]
  Emitida -->|"Ir al inicio"| Inicio
  Rechazo --> Inicio

  classDef navOff fill:#ffdad6,stroke:#ba1a1a,color:#410002
  class Splash,Idioma,IdiomaMx,Onboarding,Consent,Login,LoginErr,Emision,Emitida,Rechazo navOff

Los nodos en rojo tienen la NavigationBar oculta: shell A pre-login y shell D/E durante la emisión. El cliente no puede cambiar de tab a mitad del proceso.

flowchart TB
  Lista["lista-siniestros<br/>destino raiz"] -->|"FAB Reportar"| Aviso["aviso-siniestro<br/>formulario + foto"]
  Aviso -->|"adjuntar foto"| PermCam{"permiso-camara<br/>dialogo del SO"}

  PermCam -->|"Permitir"| Evidencia["evidencia-siniestro"]
  PermCam -->|"Denegar"| PermFotos{"permiso-fotos<br/>galeria"}
  PermFotos -->|"Permitir"| Evidencia
  PermFotos -->|"Denegar"| SinCam["evidencia-camara-denegada<br/>misma ruta, otra UI"]

  Evidencia -->|"geoetiquetar"| PermGps{"permiso-ubicacion"}
  PermGps -->|"Permitir"| ConGps["evidencia con GPS"]
  PermGps -->|"No permitir"| SinGps["evidencia-geo-denegada<br/>misma ruta, otra UI"]

  ConGps --> Confirma["confirmacion-siniestro<br/>siniestroId"]
  SinGps --> Confirma
  SinCam --> Confirma
  Confirma --> Lista
  Confirma --> Inicio["inicio"]

  classDef permiso fill:#cce8e7,stroke:#005050,color:#00201f
  classDef degradado fill:#ffdad6,stroke:#ba1a1a,color:#410002
  class PermCam,PermFotos,PermGps permiso
  class SinCam,SinGps degradado

Tres reglas que el diagrama hace explícitas:

• El permiso se pide al usar la función, nunca en splash ni al instalar (PDF §5.2).
• Todos los caminos llegan a confirmacion-siniestro: ningún permiso denegado bloquea el envío del aviso.
• Denegar no crea una ruta nueva — es la misma pantalla con otra UI.

flowchart LR
  Inicio["inicio<br/>card Vida Crediticia"] --> Consent{"consentimiento-hipotecario<br/>perfilamiento"}
  Consent -->|"No otorgar"| Inicio
  Consent -->|"Otorgar"| Adaptador["HU-54 adaptadores<br/>Open Finance / Open Data"]
  Adaptador -->|"responde a tiempo"| OfertaOk["oferta-hipotecario"]
  Adaptador -->|"falla o excede el limite"| OfertaDeg["oferta-hipotecario<br/>banner de degradacion"]
  OfertaOk -->|"Aceptar"| Emision["emision HU-20"]
  OfertaDeg -->|"Aceptar"| Emision

  classDef degradado fill:#ffdad6,stroke:#ba1a1a,color:#410002
  class OfertaDeg degradado

Sin consentimiento no se invoca ningún adaptador. Si el perfilamiento se degrada (HU-56), la oferta se entrega igual con valor de respaldo y el banner lo advierte: la degradación nunca es silenciosa ni cancela la originación.

flowchart TB
  Login["login"] --> Inicio["inicio"]

  Inicio --> Polizas["lista-polizas"]
  Inicio --> Siniestros["lista-siniestros"]
  Inicio --> Perfil["hub-perfil"]
  Inicio -->|"CTA Nueva cotizacion"| Cotizar["nueva-cotizacion"]

  Polizas --> Detalle["detalle-poliza<br/>solo lectura"]
  Detalle --> AvisoV["aviso-vencimiento"]
  Detalle --> AvisoR["aviso-renovacion"]

  Siniestros --> AvisoS["aviso-siniestro"]
  AvisoS --> Evidencia["evidencia-siniestro<br/>archivo adjunto"]
  Evidencia -->|"Usar ubicacion del navegador"| Prompt{"overlay-ubicacion-navegador"}
  Prompt -->|"Permitir"| Geo["evidencia-siniestro-geo"]
  Prompt -->|"Bloquear"| Evidencia

  Perfil --> Overlays["overlays: idioma,<br/>consentimientos, cerrar sesion"]

  Cotizar --> Oferta["ver-oferta"]
  Oferta -->|"Aceptar"| Emision["emision-progreso"]
  Emision --> Emitida["poliza-emitida"]
  Emitida --> Detalle

  classDef navOff fill:#ffdad6,stroke:#ba1a1a,color:#410002
  classDef overlay fill:#ebeeee,stroke:#6e7979,color:#181c1c
  class Emision,Emitida navOff
  class Prompt,Overlays overlay

En 390 el TopNav colapsa a hamburger → nav-menu / 390, con los mismos cuatro destinos. Los overlays son diálogos que cierran con Close, no rutas: no empujan el historial.

Diferencia con Android: aquí la evidencia es un archivo adjunto y la ubicación usa el prompt del navegador, no el permiso del sistema operativo.

flowchart TB
  BoLogin["bo-login"] --> Shell["shell-asesor<br/>Mi cartera: KPIs + cola"]

  Shell --> Clientes["Clientes"]
  Shell --> Cotizaciones["Cotizaciones"]
  Shell --> PolizasBO["Polizas"]
  Shell --> Avisos["Avisos"]

  Clientes --> ListaCli["lista-clientes-vacia<br/>cliente-detalle"]
  ListaCli --> FormCli["cliente-form<br/>cliente-form-editar"]
  ListaCli --> Baja["cliente-baja"]

  Cotizaciones --> ListaCot["lista-cotizaciones"]
  ListaCot --> Cotiza["asesor-cotizacion<br/>5 variantes por ramo"]
  Cotiza -->|"dato invalido"| CotErr["asesor-cotizacion-error<br/>CTA bloqueado"]
  CotErr --> Cotiza
  Cotiza -->|"Continuar a emision"| EmisionBO["asesor-emision<br/>stepper"]
  EmisionBO -->|"aprobada"| PolizaOk["poliza emitida"]
  EmisionBO -->|"rechazada"| EmisionRech["asesor-emision-rechazo"]

  PolizasBO --> ListaPol["lista-polizas"]
  ListaPol --> Renovar["bo-renovar-poliza"]
  ListaPol --> Cancelar["bo-cancelar-poliza"]
  Renovar -->|"no vigente"| RenovarNo["bo-renovar-no-vigente<br/>bloqueo"]
  Cancelar -->|"ya cancelada"| CancelarNo["bo-cancelar-ya-cancelada<br/>bloqueo"]

  Avisos --> Cola["bo-cola-avisos<br/>bo-cola-avisos-vacia"]
  Cola -->|"Rechazar"| Decision{"bo-aviso-decision<br/>modal sobre la cola"}
  Decision -->|"sin motivo"| SinMotivo["bo-aviso-decision-sin-motivo<br/>CTA deshabilitado"]
  SinMotivo --> Decision
  Decision -->|"con motivo"| Cola
  Cola -->|"Aprobar"| Pago["bo-pago-parametrico"]
  Pago -->|"reintento misma clave"| Reintento["bo-pago-reintento<br/>mismo comprobante"]

  Shell -.->|"rol sin permiso"| SinPermiso["shell-asesor-sin-permiso<br/>conserva el shell"]

  classDef bloqueo fill:#ffdad6,stroke:#ba1a1a,color:#410002
  classDef modal fill:#ebeeee,stroke:#6e7979,color:#181c1c
  class CotErr,RenovarNo,CancelarNo,SinMotivo,SinPermiso bloqueo
  class Decision modal

Los nodos en rojo son bloqueos de negocio, no errores técnicos: el CTA queda deshabilitado y la pantalla explica por qué, con una salida alternativa. shell-asesor-sin-permiso conserva el TopNavAdmin y solo sustituye el contenido — es la consecuencia visible de la autorización del servidor (HU-75), no su implementación.

A diferencia del cliente, el asesor conserva la navegación durante la emisión: puede atender otro caso sin perder el progreso.

Los canales no son la misma interfaz redimensionada. Estas diferencias son deliberadas y se validan con pruebas de regresión visual.

Ni el cliente web ni el móvil tienen campana de notificaciones ni destinos Open Finance / Risk Analysis.

Tokens como código. La colección Color tiene modos Light/Dark: en Android se exporta a Theme.kt / colors.xml (values-night), y en web a custom properties bajo prefers-color-scheme. El valor nunca se escribe a mano en un componente.

1. El canal formatea, el núcleo no. El núcleo entrega prima y código de moneda; NumberFormat / Intl aplican el locale. Cambiar de locale no cambia la prima.
2. El canal no inventa estado. Emisión, suscripción y siniestro muestran el estado real del núcleo. Si el núcleo rechazó, nunca se muestra «emitida».
3. Idempotencia visible. Reintentar un pago o un aviso devuelve el mismo comprobante o siniestroId; la UI lo comunica en vez de ocultarlo.
4. Autorización en el servidor. Ocultar un botón no es un control: shell-asesor-sin-permiso refleja lo que el servidor ya denegó (HU-75).
5. Estado nunca solo por color, y contraste AA en los pares del design system.
6. Permisos JIT, nunca en splash, y denegar jamás bloquea el recorrido.

El canal web consume :BFFWeb y el móvil :BFFMovil; ninguno llama al núcleo directamente. Cada BFF valida el JWT que emite ms-identidad y expone payloads pensados para su pantalla — el móvil los lleva acotados por operar en redes variables. Ver Vista funcional y Backlog BFF.

• Portal de socio (aliados): no diseñado.
• Back-office en 768 / 390: es herramienta de escritorio.
• axe-core y TalkBack no corren sobre Figma; la verificación automatizada queda para el canal implementado (PF2).
• Modo oscuro: los tokens existen en ambos modos, pero las pantallas están compuestas en Light.

Manual de Usuario — Solventa Back-office

Herramienta de escritorio para asesor y operador

Guía de usuario de la Semana 8 (rúbrica Proyecto Final 1, §3.c). Explica el prototipo Back-office · Asesor / Operador, solo a 1440 px.

Recorrer el prototipo: Abrir el back-office — inicia en Login

Otras guías: Portal web del cliente · App móvil · Mapa del prototipo

Tabla de contenidos

1. Introducción
2. Requisitos y acceso
3. Cómo navegar
4. Cómo iniciar sesión
5. Cómo gestionar clientes
6. Cómo cotizar y emitir para un cliente
7. Cómo renovar o cancelar una póliza
8. Cómo trabajar la cola de avisos
9. Cómo decidir un aviso y registrar el pago
10. Mensajes, bloqueos y permisos
11. Accesibilidad y formato regional

Es la herramienta con la que Solventa atiende carteras y colas de otras personas. El cliente, en el portal o en la app, solo ve sus propias pólizas. Aquí el asesor crea clientes y cotiza por ellos; el operador resuelve avisos, pagos de bajo monto y el ciclo de vida de la póliza.

• Asesor. Administra clientes, cotizaciones y pólizas. No decide avisos.
• Operador. Trabaja la cola de avisos, el pago paramétrico y la renovación o cancelación. El rol lo asigna Solventa: no hay alta de cuenta en la pantalla de login.

• Entrar con correo corporativo y ver el rol activo.
• Consultar, crear, editar y dar de baja clientes del canal web o Android.
• Armar una cotización COT-* eligiendo el ramo y emitir o ver el rechazo de suscripción.
• Consultar la cola POL-*, renovar una póliza vigente y cancelarla con motivo.
• Filtrar avisos, aprobar con pago o rechazar con motivo obligatorio.
• Reintentar un pago de bajo monto sin generar un segundo desembolso.
• Reconocer colas vacías, cartera vacía y secciones sin permiso.

1. Abre Recorrer el back-office.
2. Empiezas en Iniciar sesión.
3. Si no ves las zonas activas, presiona la tecla E.

La barra de administración no es la del cliente. Identifica la herramienta con la etiqueta Back-office, el selector de rol y Cerrar sesión.

El destino activo queda subrayado. En una ficha, un formulario o un caso, la barra sigue en el destino padre y aparece ← Volver.

Los diálogos (dar de baja, rechazar un aviso, cancelar) se abren encima de la lista. El fondo queda visible y bloqueado hasta que confirmas o cierras.

Cada estado lleva texto. El color no es la única señal.

1. En Iniciar sesión escribe el correo corporativo y la contraseña.
2. Pulsa Entrar.
3. Llegas a Clientes.

No hay Crear cuenta. Si el rol visible no es el que necesitas, usa el selector de rol de la barra. Cerrar sesión vuelve al login.

La lista muestra documento, canal (web o Android), estado y consentimiento.

1. Abre Clientes.
2. Pulsa una fila para abrir la ficha.
3. Desde la ficha puedes Editar, Dar de baja o Cotizar.

1. Pulsa Nuevo cliente.
2. Completa el formulario de alta.
3. Guarda. La persona queda en la cartera y puede usarse en una cotización.

1. En la ficha, pulsa Dar de baja.
2. El diálogo pide el motivo. Sin motivo, la confirmación no sigue.
3. Al confirmar, la ficha pasa a Inactivo.

Si no hay terceros, la lista se sustituye por el estado vacío Sin clientes. El camino de salida es Nuevo cliente.

1. Abre Cotizaciones.
2. La cola lista referencias COT-* con el ramo (dispositivo, vida, clima y vuelos, hipotecario, y el resto del portafolio L1).
3. Pulsa Nueva cotización.

1. Elige el ramo: Dispositivo, Viaje, Vida, Clima y vuelos, Pagos o Hipotecario.
2. Los datos del riesgo cambian con el ramo. Los datos del cliente se mantienen.
3. El panel de la derecha muestra la oferta en firme: prima, moneda y vigencia.
4. Pulsa la acción de cotizar cuando los campos son válidos.

Si el valor asegurado queda fuera de rango (ejemplo de dispositivo):

• El campo se marca en error y el texto explica el problema.
• El botón de continuar queda deshabilitado.
• El panel de oferta pasa a Sin oferta.

Corrige el dato. La oferta vuelve cuando el valor entra en el rango.

El avance es Cotizar → Oferta → Emisión → Póliza.

Aprobada	Rechazada

1. Abre Pólizas.
2. Localiza la referencia POL-*.
3. En la fila, elige Renovar o Cancelar.

Vigente	No vigente

La cancelación es destructiva.

1. Pulsa Cancelar.
2. Escribe el motivo en el diálogo.
3. Confirma.

Cancelar	Ya cancelada

Esta sección es del operador.

1. Abre Avisos.
2. Filtra por estado.
3. Selecciona una fila. La fila muestra una barra de acento y el panel de detalle incluye la evidencia que cargó el cliente.
4. Entra al caso para decidir.

Si no hay pendientes, el contenido se sustituye por el estado Cola sin pendientes. No hay un caso que abrir.

Si entras como asesor a Avisos, la ruta es la misma y el contenido se sustituye por el estado Sin permiso. No ves la cola ni puedes aprobar o rechazar. Vuelve a Clientes, Cotizaciones o Pólizas.

El diálogo se abre sobre la cola, así el caso sigue visible.

1. Revisa evidencia, ramo y monto.
2. Pulsa la acción de aprobar.
3. Si el pago es de bajo monto (clima y vuelos u otro paramétrico bajo el umbral), registra el desembolso. Queda un comprobante y una clave de idempotencia, por ejemplo junto a referencias como POL-88421.

1. Pulsa rechazar.
2. Escribe el motivo.
3. Confirma.

Sin motivo, el botón de rechazo permanece bloqueado y el diálogo lo indica. El caso sigue en la cola.

Con motivo	Sin motivo

Si el primer intento no confirma:

1. Abre el pago pendiente.
2. Pulsa reintentar.
3. El sistema devuelve el mismo comprobante. La clave de idempotencia evita un segundo desembolso y el intento queda en la trazabilidad.

• Los pares de color claro y oscuro siguen el design system del cliente.
• Los controles se nombran como los lee un lector de pantalla.
• Cada estado (En revisión, Aprobada, Rechazada, Pagada, Cancelada, Activo, Inactivo) incluye texto. Los bloqueos suman una nota escrita al color del recuadro.
• El título visible de Clientes coincide con el encabezado de esa página.
• Montos y referencias usan un tipo monoespaciado ($148.900 COP, POL-88421). El formato regional lo aplica el canal; el núcleo entrega prima y código de moneda.
• En el visor de escritorio: Options → Accessibility settings → Adapt content for screen readers.

Detalle: Usabilidad del prototipo · Cumplimiento Axe y Nielsen · back-office.

Esta herramienta no incluye el portal del cliente ni el portal de socios. Tampoco tiene layout de tablet ni de teléfono.

Manual de Usuario — Solventa App Móvil

Seguros digitales para el cliente asegurado — Android

Guía de usuario de la Semana 8 (rúbrica Proyecto Final 1, §3.c). Explica el prototipo final de la app, Screens · S7 validación, a 390 px.

Recorrer el prototipo: Abrir la app — inicia en Splash

Otras guías: Portal web · Back-office · Mapa del prototipo

Tabla de contenidos

1. Introducción
2. Requisitos, permisos y acceso
3. Cómo navegar por la app
4. Cómo empezar: splash, idioma, registro y login
5. Cómo usar Inicio
6. Cómo cotizar un seguro
7. Cómo revisar la oferta y emitir la póliza
8. Cómo consultar tus pólizas y avisos
9. Cómo reportar un siniestro
10. Cómo consultar un pago automático
11. Cómo pedir protección ligada a un crédito
12. Cómo usar Perfil
13. Accesibilidad, idioma y ubicación

Es la aplicación Android para cotizar, aceptar una oferta, llevar tus pólizas y reportar un siniestro con foto. Hace el mismo trabajo de producto que el portal web, con la navegación y los permisos propios del teléfono.

Está dirigido a la persona asegurada que usa Solventa en un teléfono Android.

• Pasar por la pantalla de carga, elegir región y crear la cuenta o entrar con una existente.
• Aceptar el tratamiento de datos antes de llegar a Inicio.
• Moverte con la barra inferior: Inicio, Pólizas, Siniestros y Perfil.
• Cotizar por ramo. Los datos del riesgo cambian con el producto.
• Aceptar la oferta y ver la póliza emitida o el rechazo de suscripción.
• Leer vencimiento y renovación desde el detalle de la póliza.
• Reportar un siniestro con cámara o galería. El GPS se pide al geoetiquetar la foto.
• Consultar un pago automático y el flujo de vida hipotecaria.
• Cambiar idioma y revisar permisos en hojas que se cierran sobre Perfil.

Esta guía describe el prototipo navegable. La publicación en una tienda de aplicaciones corresponde al canal ya programado.

1. Abre Recorrer la app.
2. El recorrido empieza en el Splash.
3. Si no ves las zonas activas, presiona la tecla E.
4. Toca los controles como lo harías en el teléfono.

La app no pide cámara, fotos ni ubicación en el splash ni al instalar. El diálogo aparece cuando usas esa función (justo a tiempo).

Desde Perfil puedes abrir la explicación de cada permiso. Esas hojas se cierran y vuelven al hub. No disparan la cámara ni el GPS por sí solas. Para cambiar un permiso ya decidido, el camino es Abrir ajustes.

Al abrir la app ves el splash de Solventa con el indicador de avance. No pide permisos ni muestra la barra inferior.

Después de entrar, cuatro destinos permanecen en la parte baja. El activo usa el contenedor secundario y el ícono relleno. Los demás quedan al mismo nivel visual.

Cotización, oferta, detalle, aviso, evidencia e hipotecario mantienen visible la barra, con el destino padre seleccionado. Arriba aparece la flecha Volver.

En Emitiendo tu póliza y en Póliza emitida la barra inferior se oculta. No cambias de destino a mitad de la emisión. Sales con Ver mi póliza o Ir al inicio.

Emitiendo tu póliza	Póliza emitida

Idioma, permisos y consentimientos se abren como hoja inferior. Perfil sigue detrás. Cerrar, Listo, Guardar, Revocar o Entendido vuelven al hub. No abren el registro ni una oferta.

El alta es un paso a paso numerado. La barra inferior permanece oculta.

Splash → Idioma y región → Onboarding | Login → Consentimiento de datos → Inicio

Es el paso 1 y solo se muestra completo en el primer arranque. Elige Colombia, México, Chile o Perú. La selección lleva borde, check y el nombre de la región.

1. Toca la región. El ejemplo de monto y fecha cambia (en México, $1,234.56 MXN y 09/07/2026).
2. Toca Continuar.
3. Sigues al onboarding.

Colombia · es-CO	México · es-MX

El onboarding presenta para qué sirve la app, en lenguaje de seguros.

1. Completa el registro.
2. Si ya tienes cuenta, entra por Login (Ya tengo cuenta / Ingresar).
3. Un inicio de sesión fallido es un estado de la misma pantalla de login.

Registro	Iniciar sesión	Error de acceso

Paso 3, antes de Inicio. Lee el texto legal enlazado y otorga el tratamiento de datos personales (habeas data). Al confirmar entras a Inicio y aparece la barra inferior.

Inicio saluda y agrupa tarjetas por objeto. Cada una muestra ramo, estado y el siguiente paso:

• Oferta vigente, con acceso a verla y aceptarla.
• Póliza activa, con acceso al detalle.
• Siniestro en curso.
• Vida hipotecaria, si hay una originación.

Nueva cotización es el botón de la pantalla. No es una quinta pestaña. También aparece si abres Pólizas y todavía no tienes ninguna.

1. En Inicio, toca Nueva cotización (o Ver oferta si ya hay una cotización vigente).
2. Elige el ramo. La descripción y los campos cambian; no se reutiliza el formulario de dispositivo para vida, viaje o crédito.

3. Toca Cotizar.
4. La oferta muestra la prima, la moneda y hasta cuándo vale. La prima es el precio del seguro, no el valor del bien.

La pestaña seleccionada sigue siendo Inicio. Volver regresa al resumen.

1. En el detalle de la oferta revisa ramo, estado, prima y vigencia.
2. Toca Aceptar.
3. Emitiendo tu póliza muestra el avance. La barra inferior no está.

1. Toca Pólizas.
2. Cada tarjeta muestra ramo, estado y un resumen del tipo, más recomendaciones de siniestro de ese ramo.
3. Toca una póliza para ver coberturas, vigencia y estado.

Desde el detalle, en modo lectura:

Activar la renovación automática no está en esta versión. Volver regresa a la billetera y la pestaña activa sigue siendo Pólizas.

Lista	Detalle	Vencimiento	Renovación

Hace falta una póliza vigente. Los campos del aviso son los del ramo de esa póliza.

1. Toca Siniestros.
2. Toca Reportar (acción principal de la lista).
3. Completa el formulario y continúa a la evidencia.

Siniestros	Reportar

1. Para tomar la foto, la app pide cámara en ese momento.
2. Para elegir una imagen existente, pide fotos.
3. Cuando la imagen está lista, puedes geoetiquetarla. Ahí aparece el diálogo de ubicación del sistema.

4. Confirma. Vuelves a la lista, donde el caso muestra su estado.
5. Ver avance abre el detalle. La aprobación y el pago los resuelve el operador, no la app.

Cámara	Fotos	Ubicación	Sin GPS	Evidencia

En clima y vuelos el cliente no arma un aviso con foto. El evento, al superar el umbral, produce un Pago automático.

1. Abre Siniestros o el aviso correspondiente.
2. Revisa el resumen y los montos.
3. El título en la app es Pago automático.

1. En Inicio, abre la tarjeta de crédito o entra a Nueva cotización y elige Hipotecario o Pagos.
2. En hipotecario, acepta el consentimiento de perfilamiento y consulta el texto legal. Es un paso de este flujo, no una fila de Perfil.
3. Revisa la oferta (factores y prima).
4. Toca Aceptar. Sigues a la emisión y al resultado (póliza o rechazo).

Consentimiento	Oferta

1. Toca Perfil.
2. El encabezado muestra tu identidad. Debajo están idioma, ubicación, cámara, fotos, consentimiento de datos, consentimiento de vida crediticia y Cerrar sesión.

Perfil	Cerrar sesión

• El destino seleccionado de la barra usa el contenedor secundario, no un relleno primario sobre texto primario.
• Los controles se nombran como se pronuncian (Continuar, Volver, Español · México).
• El estado elegido combina borde, check y texto.
• En el visor de escritorio puedes activar Adapt content for screen readers. TalkBack y VoiceOver del teléfono no leen un prototipo de Figma abierto en el dispositivo; esa prueba queda para la app compilada.

Detalle: Usabilidad del prototipo · Cumplimiento Axe y Nielsen · cliente.

• No hay campana de notificaciones ni favoritos. Los avisos de la póliza están en Pólizas.
• No hay mapa, billetera offline, escáner, biometría ni pago con pasarela dentro de la app.
• No se pide la ubicación en segundo plano.
• El menú hamburguesa del sitio estrecho no existe aquí: en el teléfono la navegación es la barra inferior.

Manual de Usuario — Solventa Portal Web

Seguros digitales para el cliente asegurado — navegador

Guía de usuario de la Semana 8 (rúbrica Proyecto Final 1, §3.c). Explica el prototipo final del canal web, Screens · S7 validación.

Recorrer el prototipo: Abrir el portal web — inicia en Login

Otras guías: App móvil · Back-office · Mapa del prototipo

Tabla de contenidos

1. Introducción
2. Requisitos y acceso
3. Cómo navegar por el portal
4. Cómo elegir idioma, registrarte e iniciar sesión
5. Cómo usar Inicio
6. Cómo cotizar un seguro
7. Cómo revisar la oferta y emitir la póliza
8. Cómo consultar tus pólizas y avisos
9. Cómo reportar un siniestro
10. Cómo consultar un pago automático
11. Cómo pedir protección ligada a un crédito
12. Cómo usar Perfil
13. Accesibilidad, idioma y ubicación

El portal web es el canal en el navegador para cotizar, aceptar una oferta, consultar tus pólizas y reportar un siniestro. Administras tus seguros. La cartera de terceros, las colas de avisos y la decisión de pago pertenecen al back-office.

Está dirigido a la persona asegurada que usa Solventa en el navegador, en computador, tablet o teléfono.

• Elegir idioma y región (es-CO, es-MX, es-CL, es-PE) y ver montos y fechas en ese formato.
• Crear una cuenta, aceptar el tratamiento de datos (habeas data) e iniciar sesión.
• Cotizar por ramo. Los datos del riesgo cambian según el producto: dispositivo, viaje, vida, clima y vuelos, pagos o hipotecario.
• Revisar la prima, aceptar la oferta y ver el resultado de la emisión o el rechazo.
• Consultar la lista y el detalle de tus pólizas, y leer avisos de vencimiento y renovación.
• Reportar un siniestro adjuntando un archivo. La ubicación del navegador es opcional.
• Consultar un pago automático de clima o vuelos.
• Pedir protección de pagos o vida hipotecario, con el consentimiento de perfilamiento como paso de ese flujo.
• Cambiar idioma, revisar consentimientos y cerrar sesión desde Perfil.

1. Abre el enlace Recorrer el portal web.
2. El recorrido empieza en Login a 1440 px.
3. Si no ves las zonas activas, presiona la tecla E.
4. Haz clic en botones y enlaces para avanzar. La flecha del visor de Figma también cambia de pantalla.

Otros puntos de entrada:

Login, idioma y región, registro y consentimiento de datos se muestran sin la barra de destinos. En escritorio el panel de marca queda a un lado y el formulario al otro. En 390 el bloque de marca queda arriba y el formulario abajo.

En Inicio, Pólizas, Siniestros y Perfil la barra muestra:

El destino activo queda subrayado. Nueva cotización no se subraya como destino.

En pantallas anidadas (cotización, oferta, detalle, aviso, evidencia) la barra sigue mostrando el destino padre y aparece ← Volver.

La barra se compacta: logo, botón de menú y avatar. El menú abre la lista de destinos. Ciérralo para volver al contenido. No hay barra inferior: esa navegación es de la app Android.

Mientras la póliza se emite, y en la pantalla de póliza emitida, la barra de destinos se oculta. Sales con Ver mi póliza o Ir al inicio.

Emitiendo	Póliza emitida

Es el paso 1 de 3. Elige una región. La opción seleccionada se marca con borde, check y texto.

1. Toca la región. El ejemplo de fecha y monto cambia en la misma pantalla.
2. Pulsa Continuar. El siguiente paso es el registro.

Puedes cambiar la región después desde Perfil. El núcleo entrega la prima y el código de moneda; el portal aplica el formato.

Colombia · es-CO	México · es-MX

1. Completa el alta (paso 2). Si ya tienes cuenta, usa Ya tengo cuenta para ir al login.
2. En el consentimiento de datos (paso 3) lee el texto legal enlazado y otorga el tratamiento de datos personales.
3. Al terminar entras a Inicio.

Registro	Consentimiento de datos

1. En Login ingresa correo y contraseña.
2. Pulsa el botón de ingreso.
3. Con sesión válida llegas a Inicio.

Si los datos no son válidos, el login muestra el estado de error en la misma pantalla. No es otra sección del menú.

Inicio agrupa lo que ya tienes, con ramo, estado y siguiente paso:

• Oferta vigente, si hay una cotización por aceptar.
• Póliza, con acceso al detalle.
• Siniestro en curso, si hay un caso.
• Protección ligada a crédito, si hay una originación hipotecaria.

Nueva cotización está en Inicio y también en Pólizas cuando la lista está vacía (primera póliza).

1. Pulsa Nueva cotización en Inicio, o el mismo llamado en Pólizas si aún no tienes pólizas.
2. Elige el ramo. Hay un solo formulario: al cambiar el ramo cambian la descripción y los datos del riesgo. Los datos de identidad se mantienen.

1. Revisa la descripción corta del ramo.
2. Completa los datos de ese riesgo.
3. Pulsa Cotizar.
4. La oferta en firme muestra la prima (el precio del seguro), la moneda y la vigencia. La prima no es el valor del bien.

1. En Ver oferta confirma ramo, estado, prima y vigencia.
2. Pulsa Aceptar.
3. La pantalla Emisión en progreso oculta la navegación mientras se procesa la suscripción.

Si la suscripción aprueba:

• Ves el ramo y el número de la póliza. La cotización queda creada como póliza.
• Ver mi póliza abre el detalle en Pólizas.
• Ir al inicio vuelve al resumen.

Si el núcleo rechaza:

• La pantalla explica el motivo.
• No se crea póliza.
• Volver al inicio regresa al resumen para cotizar otro producto.

1. Pulsa Pólizas en la barra superior.
2. Cada fila o tarjeta muestra ramo, estado y un resumen del tipo.
3. También verás recomendaciones de siniestro propias de ese ramo.
4. Si la lista está vacía, usa Nueva cotización.

Abre una póliza para ver coberturas, vigencia y estado. Desde ahí puedes leer:

Usa ← Volver para regresar a la lista. El destino subrayado sigue siendo Pólizas.

Detalle	Vencimiento	Renovación

Necesitas una póliza vigente. El formulario usa los campos y las recomendaciones del ramo de esa póliza.

1. Pulsa Siniestros.
2. Pulsa Reportar.
3. Completa el aviso. En dispositivo, la evidencia es la foto del daño. Otros ramos no reutilizan ese mismo formulario.
4. Continúa a la evidencia.

Lista de siniestros	Aviso

La evidencia en la web es una zona para soltar o elegir un archivo. No se abre la cámara del teléfono.

1. Arrastra el archivo o selecciónalo desde el equipo.
2. Escribe la dirección. Ese dato siempre está disponible.
3. Si quieres geoetiquetar, pulsa Usar ubicación del navegador.

El navegador pregunta en ese momento, no al entrar al portal.

Confirma el envío. El caso vuelve a la lista de siniestros, donde puedes ver el avance. La decisión de aprobar, rechazar o pagar la toma el operador en el back-office.

Clima y vuelos no se reportan como un siniestro asistido. Cuando el evento supera el umbral, el resultado aparece como Pago automático en Siniestros.

1. Abre Siniestros.
2. Abre el caso de pago automático.
3. Revisa el resumen del evento y el monto. El título en el canal es Pago automático.

La vida hipotecaria y la protección de pagos no se inician desde Perfil.

1. En Inicio, abre la tarjeta de crédito o pulsa Nueva cotización y elige Hipotecario o Pagos.
2. En hipotecario, el paso siguiente es el consentimiento de perfilamiento. Lee el texto legal y continúa.
3. Revisa la oferta hipotecaria (factores y prima).
4. Pulsa Aceptar. El resto es el mismo camino de emisión: progreso, póliza emitida o rechazo.

Consentimiento de perfilamiento	Oferta hipotecaria

1. Pulsa Perfil.
2. Cada fila abre un diálogo encima de la página. No es una pantalla nueva de registro.

Cierra el diálogo para seguir en Perfil. El diálogo no te lleva al onboarding ni a una oferta.

Perfil	Idioma y región

• Los colores de botón usan el par de contraste del design system: fondo primario con texto sobre primario.
• El foco por teclado sigue el orden visual. Un enlace navega; el resto de controles son botones.
• Una opción elegida se indica con borde, check y texto, no solo con color.
• En el visor de Figma en escritorio: Options → Accessibility settings → Adapt content for screen readers. VoiceOver, NVDA y JAWS pueden leer el prototipo.
• La validación automática con axe sobre el sitio publicado corresponde al canal ya programado.

Detalle: Usabilidad del prototipo · Cumplimiento Axe y Nielsen · cliente.

• No hay campana de notificaciones. Los avisos de la póliza se leen en Pólizas.
• No hay cámara del sistema ni permisos de Android. La evidencia es un archivo.
• No hay destinos de Open Finance ni de análisis de riesgo.
• No se instala desde una tienda de aplicaciones.

Índice

• 4.1 Propósito y alcance
• 4.2 Formato adoptado y cómo se llena
• 4.3 Contexto de la iteración
• 4.4 Métricas de la iteración
• 4.5 Registro de lecciones aprendidas
  • 4.5.1 Índice del registro
  • 4.5.2 Experimentación y validación de ASR
  • 4.5.3 Arquitectura y diseño
  • 4.5.4 Gestión de alcance y estimación
  • 4.5.5 Diseño de experiencia y prototipo
  • 4.5.6 Equipo, proceso y herramientas
  • 4.5.7 Documentación y trazabilidad
• 4.6 Retrospectiva del equipo
• 4.7 Plan de acción para el Proyecto Final 2
• 4.8 Riesgos y brechas que se trasladan al PF2
• 4.9 Preguntas de la sesión de retrospectiva
• 4.10 Validación del equipo
• 4.11 Trazabilidad y fuentes
• 4.12 Control de versiones

Este documento registra el conocimiento adquirido por el equipo durante la primera iteración del entregable (Proyecto Final 1) con dos fines explícitos: mejorar la ejecución del Proyecto Final 2, cuyo plan ya está comprometido en tres sprints, y dejar constancia verificable de por qué el equipo decidió lo que decidió, de modo que las decisiones sean auditables después de que se pierda el contexto conversacional.

Dentro del alcance. Las siete semanas del PF1: definición de alcance, requisitos de calidad y ASR, escenarios de calidad y árbol de utilidad, diseño de la arquitectura y del diseño detallado, catálogo de historias de arquitectura HA-01–HA-31, diseño y ejecución de los dos experimentos de arquitectura (HA-01 y HA-08), prototipo navegable web/móvil/back-office, refinamiento del backlog y versión inicial del plan de trabajo del PF2.

Fuera del alcance. La ejecución de los sprints del PF2 (aún no ha empezado), la evaluación individual de desempeño de los integrantes y cualquier juicio sobre personas. El registro documenta situaciones y decisiones, no responsables de fallas.

Una lección aprendida no es una queja ni un pendiente. Para que una entrada figure en §4.5 tiene que cumplir tres condiciones: describe una situación que efectivamente ocurrió y está respaldada por un artefacto; permite extraer un enunciado reutilizable más allá de este proyecto; y se traduce en una acción concreta para la iteración siguiente. Lo que no cumple las tres cosas va a §4.8 (riesgo o brecha abierta) o al backlog, no aquí.

El formato es un híbrido deliberado de dos estándares, porque ninguno de los dos cubre solo el caso:

Por qué este híbrido y no otro. Un post-mortem técnico puro habría dejado fuera la gestión de alcance y de equipo, que es donde está la mitad del aprendizaje de esta iteración. Una retrospectiva ágil pura no habría dejado registro de causa raíz ni trazabilidad a la evidencia, que es justamente lo que el curso evalúa. Un informe de cierre de fase estilo ISO/IEC/IEEE 15288 habría sido desproporcionado para un equipo de cuatro personas en siete semanas.

El registro se validó en la sesión de retrospectiva del equipo: se recorrió el índice de §4.5.1 y se decidió ☑ o ✖ por lección. Las 19 lecciones quedaron validadas; ninguna fue rechazada ni se añadieron lecciones nuevas. Cada acción de §4.7 salió con responsable nombrado y criterio de verificación, y el documento quedó cerrado en su versión 1.0 con la firma de los cuatro integrantes en §4.10. A partir de aquí se revisa al cierre de cada sprint del PF2.

El PF1 no produjo software de producción: produjo una arquitectura con evidencia empírica detrás y un plan de ejecución calibrado. Esa distinción explica la naturaleza de casi todas las lecciones que siguen — el aprendizaje de la iteración es sobre cómo se decide y cómo se evidencia, no sobre cómo se construye.

Trayectoria de las siete semanas

Los dos experimentos y su dictamen

El resultado más útil de la iteración fue un experimento que refutó su propia hipótesis. HA-08 no falló: demostró que la complejidad propuesta no hacía falta al volumen ensayado, y ese dictamen ahorró tres componentes y un nodo de despliegue. Es el hecho del que se derivan las lecciones LA-01 y LA-02, y conviene tenerlo presente al leer el resto del registro.

Las métricas de producto (velocidad real, cumplimiento del compromiso, defectos) no existen todavía: el PF1 no ejecutó sprints de construcción. Lo que sigue son las métricas de la iteración de arquitectura y la línea base contra la cual se medirá el PF2.

Situación. El experimento HA-08 se diseñó para demostrar que la separación del modelo de lectura (CQRS con proyección materializada y caché) era necesaria para cumplir EC-LAT-11 (p95 ≤ 150 ms en la consulta de estado de siniestro). El resultado fue el contrario: el brazo A —lectura directa sobre el modelo normalizado, sin CQRS— midió p95 = 7,86 ms, 19× por debajo del umbral, con 0 % de error en las nueve corridas contrabalanceadas. Tres de las cuatro sub-hipótesis quedaron refutadas, y una de ellas en la dirección contraria: el caché (brazo C) resultó 9 % peor que la proyección sola, porque con el hit-rate real de 7,6 % la mayoría de las peticiones paga la serialización y la escritura a Redis sin beneficiarse de un acierto.

Impacto. El dictamen descartó introducir proyector, almacén de proyección desnormalizado (siniestros_r) y una instancia de Redis para este camino de lectura. La arquitectura publicada quedó confirmada sin cambios, no porque nadie la revisara, sino porque se puso a prueba y resistió.

Causa raíz del acierto. Tres decisiones tomadas antes de medir: se declararon las sub-hipótesis por separado (HD-08.1 a HD-08.4) en lugar de una sola afirmación global; se incluyó un brazo de línea base sin la táctica propuesta; y el criterio de éxito se fijó contra el umbral del ASR, no contra la mejora relativa entre brazos. Sin el brazo A no habría habido nada con lo que comparar, y la mejora del 21 % del brazo B sobre A —que es real— habría parecido un argumento de necesidad cuando representa menos del 1,2 % del umbral.

Lección aprendida. Un experimento de arquitectura se diseña para decidir, no para confirmar lo que ya se decidió. La refutación de una hipótesis de diseño es un resultado de primera clase: ahorra complejidad que habría entrado al sistema sin que nadie pudiera después justificar por qué está ahí. Corolario operativo: todo experimento debe incluir un brazo de línea base sin la táctica bajo prueba, y el criterio de éxito debe ser el umbral del ASR y no la mejora relativa entre brazos.

Recomendación. Incorporar a la plantilla de diseño de experimentos del PF2 dos casillas obligatorias: brazo de línea base y umbral del ASR como criterio de decisión. Aplicar a HA-02, HA-07, HA-09 y HA-10 (Sprint 2) y a HA-03–HA-06, HA-11 y HA-12 (Sprint 3).

Situación. HA-01 tenía que distinguir el mérito de dos tácticas que actúan sobre el mismo escenario: el circuit breaker y el desacople por actualización oportunista. El hallazgo decisivo apareció en la celda de fallos intermitentes del 30 %: allí el interruptor no llega a abrir en ningún brazo —no se alcanzan diez fallos consecutivos ni el 50 % de la ventana, breaker_max = 0 en las ocho corridas— y aun así el brazo B incumple (1,10–1,25 % de cotizaciones sobre 475 ms) y el brazo C cumple (0,00 %). Como el interruptor no interviene en ninguno de los dos, la diferencia es atribuible únicamente al desacople.

Impacto. Ese resultado elimina la explicación alternativa y convierte una correlación en una atribución. Además se verificó bajo los dos modelos de fallo posibles —fallo atado al cliente y fallo derivado de un contador por petición— con el resultado manteniéndose en ambos, lo que descarta que el hallazgo sea un artefacto del doble del proveedor.

Causa raíz del acierto. El diseño del experimento previó la necesidad de aislar factores: seis estados del proveedor en lugar de dos, protocolo de tres fases (sana / degradada / recuperación), corridas contrabalanceadas, y celdas específicas —la de estampida, la de sensibilidad al acierto, la de política del interruptor a dos niveles de tráfico— construidas cada una para aislar una variable. La celda que produjo el hallazgo existe porque alguien previó que el interruptor podía no abrir.

Lección aprendida. Cuando dos mecanismos actúan sobre el mismo escenario de calidad, la única forma de saber cuál sostiene el ASR es diseñar una condición experimental en la que uno de los dos esté inactivo. Esa condición se diseña antes de medir; después de medir solo se puede argumentar, y un argumento no es evidencia. El costo de prever esa celda es bajo; el costo de no tenerla es no poder defender la decisión.

Recomendación. En el diseño de cada experimento del PF2, incluir explícitamente la pregunta ¿qué otra cosa podría explicar este resultado? y, por cada respuesta, la celda que la descarta. Documentarlo en la sección de amenazas a la validez, que en HA-08 ya existe y debe volverse obligatoria.

Situación. Al cierre de la semana 6, HA-01 reportaba 60 % de avance: montaje implementado y validado sintácticamente —:MsCotización con sus cuatro brazos, :AdaptadorOF con interruptor y aislamiento, doble del proveedor con latencia log-normal, Toxiproxy, Redis, PostgreSQL, Prometheus, Grafana y escenarios k6— y cero corridas ejecutadas. Las 56 corridas del protocolo de tres fases, su análisis y la redacción del dictamen se ejecutaron enteramente en la semana 7, en paralelo con el cierre del prototipo, el ajuste del documento de arquitectura y la elaboración del plan del PF2.

Impacto. El entregable se cerró completo, pero sin margen. Cualquier hallazgo que hubiera obligado a rediseñar el montaje —y HA-01 produjo varios hallazgos inesperados— habría llegado sin tiempo de reacción. La semana 7 absorbió simultáneamente el trabajo de dos semanas de experimentación y el cierre de tres entregables más.

Causa raíz. La estimación del experimento trató «montaje listo» como el hito relevante, y el porcentaje de avance se reportó contra la implementación. Pero un experimento con 56 corridas sobre seis estados del proveedor, cinco tasas de acierto, dos políticas de interruptor y cuatro escalones de llegada tiene su esfuerzo repartido en al menos cuatro actividades de tamaño comparable: montaje, ejecución de la campaña, análisis de los datos y redacción del dictamen con su trazabilidad. Reportar 60 % con el montaje terminado sobreestimó el avance real.

Lección aprendida. En un experimento de arquitectura, el montaje es la parte más visible y no la más costosa. El hito que se debe planificar y comprometer es la fecha de la primera corrida válida, no la de montaje terminado, porque es la primera corrida la que revela si el montaje mide lo que se pretende medir. Corolario: el porcentaje de avance de un experimento no debe calcularse sobre la implementación.

Recomendación. Estimar cada experimento del PF2 desglosado en cuatro actividades con esfuerzo propio (montaje · campaña · análisis · dictamen y trazabilidad) y comprometer la fecha de la primera corrida. Como los experimentos del PF2 están repartidos entre S2 y S3 sobre las HU que ya están en el sprint, fijar esa fecha en la mitad del sprint, no al final.

Situación. En ambos experimentos se versionaron, por corrida, las métricas finales, la configuración efectiva, las verificaciones de sanidad, el resumen de k6 y las series temporales segundo a segundo, junto con el consolidado en CSV y las figuras del informe. En HA-01 se versionó además una instantánea completa de la base de Prometheus (raspado de 1 s, 20 MB comprimidos) cubriendo toda la campaña.

Impacto. Cualquier cifra citada en los informes es recalculable sin reproducir las corridas, y los percentiles pueden recalcularse por fase del protocolo. Eso fue lo que permitió producir, después de terminada la campaña, análisis que no estaban previstos en el diseño original: el corte del p95 del adaptador por fase que reveló el incumplimiento de EC-LAT-07, y la verificación del hallazgo bajo los dos modelos de fallo.

Causa raíz del acierto. Se decidió versionar la evidencia cruda durante la campaña y no al final, cuando ya se sabe qué figuras irán al informe. Los análisis más valiosos del experimento fueron los que no estaban planeados, y solo fueron posibles porque el dato seguía ahí.

Lección aprendida. El dato crudo de un experimento vale más después de terminarlo que durante. Veinte megabytes comprimidos son un costo despreciable frente a reejecutar una campaña de 56 corridas, y la disponibilidad del dato crudo es lo que permite responder la pregunta que nadie previó — que, en esta iteración, resultó ser la pregunta decisiva.

Recomendación. Mantener como práctica obligatoria en el PF2: instantánea de la serie temporal completa por campaña, configuración efectiva por corrida y consolidado en CSV, versionados en el repositorio del experimento. Incluirlo en la definición de terminado de las historias de arquitectura.