Backbone · esqueleto de extremo a extremo

Walking Skeleton

Llega la archivera con un legajo y se identifica con su DNI en el registro civil (Keycloak).

  1. Entra por la puerta de la muralla (APISIX), que comprueba el DNI y la dirige a la sala de lectura.
  2. La sala de lectura (adaptador IIIF) guarda las imágenes y las inscribe en el catastro.
  3. El catastro (Scorpio) crea la ficha del nuevo legajo y avisa de la inscripción.
  4. Correos (puente y Kafka) reparte la carta "ha llegado un legajo" a todos los apuntados:
    • la gestoría abre el expediente;
    • el notario levanta acta.
  5. La gestoría encarga la copia al taller (HTR), que hace la transcripción automática y la inscribe también en el catastro, que avisa de nuevo con "copia terminada".
  6. La paleógrafa revisa y valida la copia. La gestoría cierra el expediente.
  7. Con la copia validada, la editorial prepara la edición y ya es posible la lectura cercana.

Qué es y cómo se comprueba

1 · Una pieza mínima de cada servicioSe monta lo justo de cada servicio del núcleo: identidad, entrada, catastro, correo, gestoría, notario… Ninguna está terminada.
2 · Un test que hace de usuariosUn programa automático hace de archivera y de paleógrafa y recorre la plataforma de punta a punta: 16 tramos.
3 · Si pasa, el esqueleto caminaSe ejecuta en cada cambio de código. Si algo se rompe, el test dice en qué tramo. Pulsa «Ejecutar el test» o rompe una pieza para verlo.
8 · Versionado y modelos

Walking skeleton del backbone Contratos arriba; cliente de pruebas, Keycloak y APISIX a la izquierda; módulos IIIF y HTR simulado con Temporal en el centro; abajo a la izquierda, Git, datos versionados con DVC y laboratorio de modelos; Scorpio, puente y Kafka a la derecha; procedencia y Fuseki al extremo; OpenTelemetry abajo. Contratos contracts/ · @context JSON-LD · esquemas CloudEvents · claims del token (tenant, proyecto, roles) · ARK · OpenAPI los usan todos los servicios 0 platform/docker-compose.yml MÓDULOS · SDK Test e2e (CI) tests/e2e/ · pytest hace de cliente y de paleógrafa Keycloak realm · organizaciones mappers de claims 1 APISIX openid-connect · X-Tenant límite por tenant 1 Adaptador IIIF modules/iiif-adapter código propio · usa el SDK 6 HTR simulado modules/htr-mock código propio 4 Temporal + worker TranscripcionEstandar espera signal de validación 4 Scorpio + PostgreSQL NGSI-LD · NGSILD-Tenant suscripciones 2 Puente de eventos services/puente · NGSI→CE código propio 3 Kafka (KRaft) topics: activos · htr CloudEvents + tenant 3 Procedencia services/procedencia código propio 5 Jena Fuseki grafo PROV-O · SPARQL 5 OpenTelemetry → Jaeger / Tempo todos los servicios exportan trazas; el contexto viaja por HTTP y por las cabeceras de Kafka · el flujo 1–16 se ve como una sola traza 7 Git + CI código y contratos versión = commit SHA 0 Datos versionados DVC · remoto S3 por institución o comunidad 8 Lab. de modelos MLflow · pipeline dvc.yaml entrena y registra versiones 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Componente de terceros Código propio Contratos Flujo del test e2e Validación humana simulada

El código del test

Este es el test de extremo a extremo, escrito en Python (simplificado). Vive en tests/e2e/ y se ejecuta en cada cambio de código. La línea del tramo en curso se resalta.


  


  

    

      
El flujo del test de extremo a extremo

      

        
#Qué pasa

        
          
1El test pide un token a Keycloak con tenant, proyecto y roles.

          
2Sube un legajo de prueba a POST /api/v1/ingestas con ese token.

          
3APISIX valida el token y enruta al adaptador IIIF con X-Tenant.

          
4El adaptador crea el ActivoPatrimonial en Scorpio con NGSILD-Tenant.

          
5La suscripción de Scorpio notifica al puente por HTTP.

          
6El puente publica legajo.ingestado como CloudEvent en Kafka.

          
7Un consumidor arranca el workflow TranscripcionEstandar en Temporal.

          
8El workflow ejecuta la actividad del HTR simulado.

          
9El HTR simulado registra la Transcripcion en Scorpio.

          
10Publica htr.completado en Kafka.

          
11Procedencia consume los eventos.

          
12Escribe las trazas PROV-O en Fuseki.

          
13El test envía la signal de validación y el workflow termina. Comprueba estado y procedencia.

          
14El commit del pipeline fija qué versión de los datos se usa: el fichero .dvc guarda su hash.

          
15El laboratorio entrena con ese dataset versionado y registra el modelo en MLflow con su CER, el hash de datos y el commit.

          
16Al promover una versión (modelo.promovido), el HTR la carga; cada Transcripcion guarda qué versión la produjo y procedencia enlaza modelo → dataset → commit.

        
      

    


    

      
Qué queda funcionando en cada paso

      

        
PasoSemanaHecho cuando