Historias del borde de canal (:BFFWeb, :BFFMovil) para que cliente L1 y back-office (asesor / operador) no hablen con el núcleo a pelo. Una HU BFF = un slice de recorrido que el canal puede terminar; no es un endpoint, un DTO ni una tabla.

No reescribe Backlog refinado · Semana 3 ni Backlog UI · Cliente L1. HU-72 y HU-73 siguen siendo el contrato paraguas (PF2: 3 SP c/u, solo los recorridos comprometidos). Las HU de esta página refinan esos contratos; no se suman a los 5 + 5 SP del catálogo S3 ni a la velocidad del plan PF2.

JWT y RBAC ya están: HU-74–HU-77. Aquí se citan, no se reescriben.

Wiki only. No se crean issues en Jira desde este documento.

Caso: files/MISW4501-202614-Proyecto.pdf §§2.3, 5.1–5.2. Patrón BFF: Tácticas y patrones §2. Hueco Clientes en BO: Cumplimiento Axe y Nielsen · prototipo back-office. Cuerpos JSON de cada slice: Contratos BFF.

• Convención de nombres
• Labels
• Story point estimate
• Relación con HU-72 / HU-73
• Borde de canal
• Historias BFF
  • E4 · Identidad
  • E1 · Cotización
  • E2 · Suscripción y emisión
  • E3 · Siniestro y paramétrico
  • E5 · Hipotecario
  • E6 · Ciclo de vida
  • Agregación de canal
  • Clientes CRUD
  • Dispositivo §5.2
• Catálogo de API services
• Matriz canal → BFF → servicios
• Fuera de alcance

Igual que Semana 3. IDs de este catálogo continúan después de HU-120 (último id de Backlog UI · Cliente L1).

Texto Como …, quiero …, para … alineado al PDF. El p95 / caudal viven en SBA. Las HU no fijan el JSON de un banco, una pasarela o un proveedor de clima: el BFF expone el contrato de Solventa; el stub ok / fallo / lento basta para estimar y probar.

Cada historia lleva al menos un label de plataforma y un label de alcance. En este catálogo el label api marca que el incremento vive en el BFF, no en la UI ni en el núcleo.

HU-141 es canal (web mvp), no BFF: lista y ficha de clientes. Va en esta página porque sin esa vista el CRUD (HU-140) queda huérfano. No lleva api.

Una HU BFF = un canal. Gemelos web/móvil son tickets distintos (mismo núcleo, payload distinto: HA-31).

Fibonacci 1 · 2 · 3 · 5 · 8. Mismo significado que Semana 3. Slices BFF 2–3; CRUD BFF 5; UI Clientes 5.

Estos SP son el desglose de HU-72 / HU-73 (y de la capacidad Clientes que el prototipo no cubre). No se suman a la velocidad de producto ni al compromiso PF2.

Si estas HU se importan a Jira, HU-72 / HU-73 quedan como feature o se cierran al completar los slices del recorrido comprometido. No duplicar SP.

:APISocios queda fuera (canal socio, no cliente/BO). Los adaptadores OF / OD / KYC / pasarela / firma / telemetría los llama el núcleo, no el BFF.

flowchart LR
  subgraph canales [Canales]
    AppMovil[App_Movil]
    WebCliente[Web_Cliente]
    BackOffice[Back_Office]
  end
  subgraph borde [Borde]
    BFFMovil[BFFMovil]
    BFFWeb[BFFWeb]
  end
  subgraph nucleo [Nucleo]
    Identidad[ms_identidad]
    Consent[ms_consentimiento]
    Cotiz[ms_cotizacion]
    Perfil[ms_perfilamiento]
    Suscrip[ms_suscripcion]
    Polizas[ms_polizas]
    Siniestros[ms_siniestros]
    Pagos[ms_pagos]
    Param[ms_parametrico]
    Notif[notificaciones]
  end
  AppMovil --> BFFMovil
  WebCliente --> BFFWeb
  BackOffice --> BFFWeb
  BFFMovil --> Identidad
  BFFMovil --> Consent
  BFFMovil --> Cotiz
  BFFMovil --> Perfil
  BFFMovil --> Suscrip
  BFFMovil --> Polizas
  BFFMovil --> Siniestros
  BFFMovil --> Pagos
  BFFMovil --> Param
  BFFMovil --> Notif
  BFFWeb --> Identidad
  BFFWeb --> Consent
  BFFWeb --> Cotiz
  BFFWeb --> Perfil
  BFFWeb --> Suscrip
  BFFWeb --> Polizas
  BFFWeb --> Siniestros
  BFFWeb --> Pagos
  BFFWeb --> Param

INVEST: independiente en lo posible (orden: identidad → catálogo/prima → oferta → aceptar → póliza; consentimiento de perfil antes del adaptador hipotecario; JWT antes de cualquier slice autenticado). Valiosa para que el canal cierre un recorrido §5.1. Testeable con un hecho cuando claro (oferta con prima/moneda/venceEn, siniestroId, ficha de cliente). No se parte en tabla/DTO/endpoint.

Columna Consume = HU de canal (S3 o UI L1). Columna Servicios = microservicios que el BFF llama en ese slice.

PDF §2.3 KYC · §5.2 onboarding. El JWT se emite en ms-identidad y se valida en el BFF (ms-identidad).

PDF §5.1 #1. Envelope: ramo + DatosRiesgo → oferta (prima, moneda, venceEn). Móvil: payload ligero. Web: mismo núcleo para cliente y asesor.

PDF §5.1 #2. El BFF orquesta suscripción + cobro stub + póliza. No PCI: el contrato mínimo es cobro ok / fallo / idempotente.

PDF §5.1 #3 y #4. Lectura de estado por el modelo CQRS de ms-siniestros (HA-08), no por el comando de aviso.

PDF §5.1 #5 · §2.4. Consentimiento de perfil antes de llamar al adaptador (el stub OF/OD vive en el núcleo, no en el BFF).

PDF §5.1 #6. Un verbo = un comando en el núcleo; el BFF solo lo expone al canal.

El valor del patrón BFF: un fan-in en el borde para que el cliente no encadene llamadas contra el presupuesto de EC-LAT-05 (1,5 s aceptación → póliza) ni contra el Inicio.

Hoy el tab Clientes del TopNavAdmin pinta Mi cartera (cola de cotizaciones y pólizas), no un CRM. HU-139 cubre esa cartera; el CRUD de personas es HU-140.

El destino Clientes del TopNavAdmin no administra clientes: no hay lista, ficha, alta ni búsqueda (auditoría 20 sep 2026). No existen frames lista-clientes ni detalle-cliente. Esta capacidad no está en Semana 3; se añade para que el asesor opere personas, no solo objetos de cartera.

ms-identidad es dueño del usuario. La ficha puede leer cartera en ms-polizas / ms-cotizacion (agregación BFF); no crea pólizas. RBAC asesor/operador: HU-75.

PDF §5.2. No sustituyen a HU-121 ni a HU-135. La biometría de acceso sigue en el dispositivo. HU-135 sigue siendo el aviso in-app, sin payload de un proveedor de push. Estos dos slices son el contrato que las pantallas nuevas llaman. No están en el corte de 1 SP del plan PF2.

Tres anillos. El BFF solo conoce el 1. El 2 lo invoca el núcleo detrás de adaptadores. El 3 no entra en cliente L1 ni en este BO.

Stubs y adaptadores: :AdaptadorOF, :AdaptadorOD, :AdaptadorKYC, :AdaptadorPasarela, :AdaptadorFirma, :AdaptadorTelemetria. Caché: :CacheOF, :CacheOD. Mensajería: :BusEventos, :ColaPagos, :TopicoTelemetria.

El BFF no conoce el esquema del banco, de la pasarela ni del feed paramétrico. Un stub ok / fallo / lento detrás del adaptador basta (Semana 3).

Para que un dev web o móvil no llame al núcleo. Pantallas L1: Backlog UI · Cliente L1. BO: Prototipo web/móvil §6.

• OpenAPI / JSON de proveedores. Contrato de Solventa; stub ok / fallo / lento.
• Redibujar Figma lista-clientes / detalle-cliente. Solo se declara el hueco y HU-140 / HU-141.
• Import a Jira y cambio de SP del plan PF2.
• Gherkin largo. Vive en Backlog UI y en Jira; aquí Como / quiero / para + servicios.
• Canal socio (:APISocios), SAST y tableros (post-mvp). La prueba de vida, la relectura de la billetera, el push y el mapa de prestadores entran en HU-123, HU-127, HU-142 y HU-143. La biometría de acceso no es un contrato BFF.