| Caso de uso | CU-16Proyectar una presentación con el público en sincroníaCliente |
| Descripción | El administrador proyecta un deck y lo controla desde su celular; el público lo sigue en sus propios dispositivos entrando por un QR o un PIN de cuatro caracteres. |
| Precondición | Existe un deck en la biblioteca: un archivo HTML autónomo con un <deck-stage> del que se extrajeron sus slides al subirlo. |
| Secuencia normal | | Paso | Acción | | 1 | El administrador pulsa Presentar y confirma en una pantalla que muestra el deck, su número de slides y la caducidad de la sesión. | | 2 | El sistema crea la sesión en Redis en estado lobby, con slide 0 y un PIN de cuatro caracteres (dos letras y dos dígitos) comprobado contra las rutas reservadas del sitio y contra los PIN ya en uso. | | 3 | La pantalla de reparto ofrece las dos vistas: la pantalla principal para el proyector y el control remoto, este último también como QR para escanearlo con el celular. | | 4 | La pantalla principal muestra a pantalla completa el QR hacia codebymike.tech/{pin} y el PIN escrito en grande; es la única vista que los muestra. | | 5 | El público escanea o teclea la dirección y ve la pantalla de espera con el título del deck. | | 6 | El administrador inicia desde el control remoto, que exige sesión de administrador y valida además el secreto de la sesión. | | 7 | Cada comando (anterior, siguiente, salto directo) se valida en el servidor contra el rango de slides, se persiste en Redis y se publica al bus. | | 8 | Cada dispositivo del salón, suscrito directamente al bus, recibe el cambio y salta al slide correspondiente en menos de 300 ms. |
|
| Flujos alternos | Espectador que llega tarde - 1.Al conectar, el cliente pide el snapshot de la sesión y entra directamente al slide en curso, sin ver los anteriores.
Navegación directa - 1.El administrador abre el selector de slides del control remoto y salta a uno concreto por su número y rótulo, en lugar de avanzar de a uno.
Cierre con feedback - 1.Al pasar del último slide o pulsar Finalizar, las tres vistas muestran la misma pantalla de cierre con un QR hacia /feedback.
|
| Postcondición | Al terminar, la sesión pasa a estado ended y libera su PIN, que vuelve a quedar disponible para otra sesión. El estado efímero caduca solo por TTL sin dejar rastro en la base de datos. |
| Excepciones | | Paso | Acción | | 1 | Si se pierde la red del celular, al reconectar el control retoma el slide real: el servidor es la fuente de verdad y el cliente nunca impone su estado. | | 2 | Si un mensaje del bus se pierde (pub/sub no garantiza entrega), la resincronización periódica del snapshot corrige la pantalla en menos de diez segundos. | | 3 | Si el bus no llega a conectar, cada cliente cae a consultar el snapshot en bucle corto: se degrada la latencia, no la sincronía. | | 4 | Si el PIN no existe o la sesión terminó, la vista del público muestra la pantalla de cierre con el enlace de feedback, nunca un error crudo. | | 5 | Un texto de un segmento que no tenga forma de PIN devuelve el 404 normal del sitio sin llegar a consultar Redis. |
|
