# Flujos demostrativos T14

| Archivo | Recorrido |
| --- | --- |
| credito-v1.json | Cliente → INE → estado de cuenta → buró → PASO_N/PASO_M/REVISION_MANUAL |
| credito-v2-licencia.json | Mismo recorrido; agrega licencia antes del buró |
| compra-v1.json | Cliente → confirmación → COMPRA_CONFIRMADA/COMPRA_CANCELADA |

Compra demuestra un segundo tipo; no cobra ni reserva inventario. Score >70 lleva
a PASO_N; >60 y <=70 a PASO_M; <=60 a REVISION_MANUAL. Score ausente/no numérico
es fallo técnico. INVALID documental conserva tarea y reasonCodes; cliente ausente
conserva CREADA.

Usar el [catálogo completo](../integrations/publication-catalog.json). Los perfiles
INE, ESTADO_CUENTA y LICENCIA_CONDUCIR de DOCUMENTO_VALIDA están fijados en versión 1.
Máximo documental: 5 MiB; estado de cuenta solo PDF; INE/licencia PDF, JPEG o PNG.
El API recibe documentId; verifica metadata del proveedor, no recibe archivos.
consentimientoId es obligatorio; la validez real debe verificarse con el proveedor.

## Prueba reproducible

Con JDK 21 y MIGRATION_TEST_DB_URL/USER/PASSWORD apuntando a una base de pruebas:

```powershell
./mvnw.cmd --batch-mode --no-transfer-progress verify -Pmigration-tests-external '-Dtest=DemoFlowTest' '-Dit.test=DemoFlowsIT'
```

Inicia API con JWT/JWKS local, publica los JSON exactos, activa ambos tipos, crea
solicitudes y ejecuta eventos/worker/SQL. Cuatro proveedores HTTP loopback exclusivos
de test devuelven datos sintéticos. Crea y elimina esquemas/roles temporales.
Cubre coexistencia v1/v2, licencia inválida/válida, score 71/70/61/60, cliente ausente,
score mal formado y ambos finales de compra. No requiere Keycloak ni buró real.

## Recorrido manual en entorno de demo

1. Configurar FLOW_CATALOG_PATH con el catálogo de ejemplo, FLOW_ADMIN_ENABLED,
   REQUEST_API_ENABLED y WORKER_ENABLED, JWT y ADMIN_BUSINESS_SCOPES según README.
   Usar usuario DB runtime restringido y rutas de proveedores de demo confiables.
   integration-routes.example.json contiene hosts .invalid, no servicios operativos.
2. Crear tipos con [seed-request-types.sql](seed-request-types.sql) como dueño del
   esquema. Ajustar el esquema al configurado; no es una migración automática.
3. [demo-flows.http](../http/demo-flows.http) contiene publicación, activación y
   recorridos. Copiar IDs/ETags de respuestas y proporcionar tokens de cada rol.
4. Crear crédito con v1, activar v2 y crear otro. Cada solicitud conserva su flowId;
   después del estado de cuenta solo la nueva exige REGISTRAR_LICENCIA.
5. Para cada evento usar If-Match de la consulta actual. Esperar SUCCEEDED antes de
   continuar: 202 solo significa aceptado. Reintento de transporte conserva clave;
   nueva operación de negocio usa una clave nueva. DocumentId debe existir en el
   proveedor documental de demo y pertenecer a la solicitud/ámbito correspondiente.

No invoca /simulate: recorre la API operativa contra mocks. No modifica Java de
producción, migraciones ni columnas. Proveedores reales pendientes de contrato y
verificación independiente. Docker permanece con un servicio y PostgreSQL externo.