# Guion del vídeo, para comentar o para lo que necesites.
# Es una PROYECCIÓN del nuestro: lleva el contenido —qué se dice, qué se ve, en
# qué orden y cuánto dura— y no la maquinaria que lo convierte en vídeo.
id: herramientas-simulador-consola
title: 'La consola del simulador: nueve hitos que se marcan solos'
audience: Desarrollador que quiere ver su integración avanzar y depurar lo que no llega
objetivo: >
  Al terminar, el espectador sabe cómo está montada la consola, entiende que los hitos se encienden
  con la evidencia de lo que hizo y no por autodeclaración, sabe por qué el hito del endpoint puede
  quedarse apagado con entregas verdes, conoce el reto de firma corrupta y sus tres veredictos, y
  sabe para qué sirve el informe.
cta: 'Siguiente: ''El simulador como API'' o ''Conducir el ciclo''.'
target_duration_s: 223
storyboard:
  - 'n': 1
    on_screen: Un espejo con memoria
    narracion: >-
      El simulador se puede usar entero por HTTP. La consola es la otra mitad: una interfaz para ver
      lo que tu integración ya probó, y lo que le falta. No es un panel de administración ni
      sustituye a tu código. Es un espejo con memoria: tú integras desde tu editor, y ella te va
      diciendo, con la evidencia en la mano, hasta dónde llegaste de verdad.
    visual: >-
      Un espejo que, en vez de reflejar a quien se asoma, devuelve una escalera de peldaños
      encendidos y apagados.
    duracion_s: 25
  - 'n': 2
    on_screen: Rail · Trabajo · Traza
    narracion: >-
      Con esa idea, mira cómo está montada. Tres zonas fijas, y la disposición es el mensaje. A la
      izquierda el rail, con los nueve hitos y los cinco casos borde. En el centro, el taller del
      hito en el que estés. Y a la derecha, la traza de tus eventos, en vivo y siempre visible. La
      traza no es una pantalla aparte a la que se va: mirar lo que pasó no es una tarea distinta de
      integrar, es parte de integrar.
    visual: >-
      La pantalla partida en tres zonas fijas: franja estrecha a la izquierda, área ancha al centro,
      panel a la derecha con eventos cayendo.
    duracion_s: 32
  - 'n': 3
    on_screen: Los nueve hitos
    narracion: >-
      El rail es la columna vertebral, y cada hito es una cosa concreta que tu integración tiene que
      haber hecho. Conectado. Acuerdo creado. Sesión abierta. Pago recibido. Tu endpoint contestó.
      Firma verificada. Acreditación. Casos borde. Y listo para producción. Cada uno tiene su
      taller: qué es, por qué importa, el código que lo consigue, y qué mirar en la traza cuando
      ocurra.
    visual: >-
      Una escalera de nueve peldaños numerados, cada uno con su etiqueta corta, ascendiendo hacia
      una bandera.
    duracion_s: 24
  - 'n': 4
    on_screen: No hay casilla que marcar
    narracion: >-
      Y aquí está lo que separa esto de una lista de tareas: no hay una casilla que puedas marcar
      tú. Cada hito se enciende cuando el simulador observa el evento que lo prueba. Una respuesta
      correcta del API enciende conectado. La transición real de la sesión enciende el pago. Y la
      transición del segunda fase enciende la acreditación. Los dos últimos hitos ni siquiera tienen
      regla propia: se derivan de los demás, así que no hay vía rápida.
    visual: >-
      Una casilla de verificación tachada y prohibida, frente a un ojo que observa eventos pasar y
      enciende un peldaño.
    duracion_s: 30
  - 'n': 5
    on_screen: Verde no siempre es probado
    narracion: >-
      De ahí sale la regla más importante del rail. El hito de tu endpoint no cuenta con loopback.
      Si tu URL de aviso apunta a los receptores de prueba del propio simulador, la respuesta
      correcta la produce él contestándose a sí mismo: no prueba nada sobre tu servidor. Por eso ese
      peldaño puede quedarse apagado aunque veas entregas verdes en la traza. Está apagado con
      razón.
    visual: >-
      Una fila de entregas todas en verde, y junto a ellas un peldaño que sigue apagado, con una
      lupa señalando la etiqueta de enrutado.
    duracion_s: 25
  - 'n': 6
    on_screen: 4xx pasa · 2xx no · timeout, inconcluso
    narracion: >-
      Con esa idea clara, el sexto hito merece aparte, porque no se deduce mirando eventos. El
      simulador ve que contestaste correctamente, pero no si de verdad comprobaste la firma. Así que
      no lo deduce: lo provoca. Te manda un aviso legítimo con la firma corrompida en un solo
      carácter, y mira qué contestas. Si la rechazas, pasas. Si la aceptas, cualquiera puede
      fabricar ese aviso sin conocer tu secreto. Y si hay un tiempo agotado o un error de red, queda
      inconcluso: no pasa, pero tampoco te acusa de nada que no se haya observado.
    visual: >-
      Un sobre con el sello alterado en un solo carácter saliendo hacia un servidor, y tres puertas
      de respuesta: una que rechaza, una que acepta, y una entreabierta.
    duracion_s: 37
  - 'n': 7
    on_screen: 'El informe: herramienta, no medalla'
    narracion: >-
      Y al final del rail, el noveno hito genera un informe listo para pegar en una revisión de
      código: los nueve hitos y los cinco casos borde, con la fecha en que se probó cada uno. Lo
      importante es que funciona aunque no estés listo, y entonces lo que falta aparece por su
      nombre. Un informe que solo se puede generar cuando ya está todo bien no sirve para nada,
      porque justo entonces es cuando nadie lo necesita.
    visual: >-
      Un documento en formato de informe con filas marcadas y filas vacías, listo para pegarse en
      una revisión de código.
    duracion_s: 30
  - 'n': 8
    on_screen: Míralo, y luego automatízalo
    narracion: >-
      Eso es la consola. Y no sabe nada que la API no cuente: todo lo que ves aquí lo puedes pedir
      por HTTP con tu token de consola, así que si prefieres automatizarlo, no pierdes nada. Sigue
      con el simulador como API, o con conducir el ciclo para el camino paso a paso.
    visual: >-
      Cierre de marca; una flecha apunta hacia la escalera completa encendida y hacia una terminal
      al lado.
    duracion_s: 20