# 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 prácticas que se marcan solas' 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 prácticas se encienden con la evidencia de lo que hizo y no por autodeclaración, sabe por qué la práctica del endpoint puede quedarse apagada 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 las nueve prácticas y los cinco casos borde. En el centro, el taller de la práctica en la 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: Las nueve prácticas narracion: >- El rail es la columna vertebral, y cada práctica 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 práctica se enciende cuando el simulador observa el evento que la 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. Las dos últimas prácticas ni siquiera tienen regla propia: se derivan de las 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. La práctica 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, la sexta práctica 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, la novena práctica genera un informe listo para pegar en una revisión de código: las nueve prácticas 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