cargando matriz…
BDC Validator
· Readiness dashboard
Cada etapa exige la anterior: match banco → OpenAPI BDC → ejecutable (HTTP 2xx — endpoint vivo) → datos OK (escenario válido) → funcional (sin drift de contrato). Las dos últimas etapas separan precondición faltante de drift de contrato. Los porcentajes son “del paso previo”.
Flujo recomendado
bdc-swagger.json) corresponde a cada requisito del YAML. Sin esto no hay fila acá.seed.yaml. Si falta algo, el probe muestra «✎ sin seed».Columnas de la tabla
| ● | Semáforo — Resumen (verde / ámbar / rojo / gris) según spec, seed y último resultado de probe. |
| Capacidad | Nombre de la capacidad en el YAML; click para editar seed. |
| Endpoint BDC | Método y path del requisito en el YAML; la operación real del banco es la que elegiste en Match. |
| Docs | Enlace UI al Swagger del banco (si está configurada la URL en meta), para ver el contrato en el navegador. |
| En OpenAPI BDC | ✓ / ✗ — ¿La operación elegida en Match está en bdc-swagger.json? El tooltip indica si falta mapeo, si el path no está en el spec o si coincide. Docs abre el Swagger UI en esa operación (mismo criterio). |
| Sandbox echeq | Cruce opcional con el OpenAPI del sandbox echeq (artefacto distinto al gateway BDC). Sirve para ver si hay equivalente en el sandbox interno; no es el probe al banco. |
| Último probe | Última prueba HTTP al gateway: status, ms, y △ si el JSON de respuesta no encaja con el schema del Swagger BDC. |
| Consumer | Quién consume el requisito en el paquete: echeq, motor-riesgo o ambos. |