El televisor no es un equipo dedicado: es una ventana de un computador de uso
mixto. Si esa ventana queda tapada o minimizada, Chrome congela sus relojes a
~1 tic por minuto, el sondeo se paraliza y los llamados intermedios no suenan
(reproducido y documentado en la bitácora el 23/08 a las 12:11).
Los eventos de red no se congelan. La pantalla se suscribe ahora al canal SSE
que ya existía —todos los caminos de llamado actualizan sse_ping_at: llamar,
rellamar, cambiar_estado y llamar_desde_espera— y cada cola_update dispara un
refresco inmediato, aunque la pestaña esté de fondo. El sondeo de 1 s queda
de respaldo, y el vigía de congelamiento anota en la bitácora si ambos fallan.
Al verificar en producción (sin dar por hecho que el canal servía), el SSE
resultó estar MUDO: cero bytes en 17 segundos, ni el keep-alive. Causa: el
arranque del ERP deja un búfer de salida activo —los jsonOk() de _helpers
hacen ob_clean(), que lo confirma— y sse_turno.php usaba flush() a secas, que
no lo atraviesa: todo lo emitido quedaba atrapado. Se drena el búfer al
iniciar el stream (ob_end_clean + ob_implicit_flush). Verificado ejecutándolo
contra la base real: emite cola_update de inmediato.
La suite vigila que la suscripción exista (17 verificaciones de voz).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
El vigía de congelamiento escucha visibilitychange, y el arnés no proveía
document: la suite entera se caía al cargar. Fue mi error de proceso además
del de código: empujé el commit anterior sin mirar el resultado de la suite,
que es exactamente lo que la suite existe para impedir.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Revisión de lo entregado ayer sin dar nada por hecho. Aparecieron dos
defectos reales y un vacío en las pruebas que los dejaba pasar.
1. DOBLE ANUNCIO (voz). En Chrome, cancel() dispara 'error' (interrupted)
sobre la locución vieja, y ese handler volvía a lanzar el reintento: dos
voces superpuestas diciendo lo mismo, intermitente — otra fuente del
"entrecortado". Cada locución toma ahora un token de generación; si al
dispararse un evento ya no es la vigente (la superó un reintento o el
anuncio siguiente), sus handlers solo sueltan el anclaje y callan. De paso
la bitácora deja de registrar 'end' falsos de locuciones canceladas.
2. FUGA ENTRE FICHAS (RIPS). La respuesta del sondeo puede llegar después de
que la recepcionista cambió de paciente: los exámenes de uno se cargaban
en la ficha del siguiente. Ahora se compara la cédula de la respuesta con
la de quien está en pantalla y, si no coincide, se descarta y se detiene.
3. EL SIMULADOR MENTÍA POR OMISIÓN. No imitaba que cancel() interrumpe con
'error', por eso el defecto 1 pasó las pruebas. Ahora sí lo hace, y además
modela los dos modos reales de fallo de Chrome: el speak descartado en
silencio (se reintenta) y la voz eternamente en pending (se tolera: es
indistinguible de una voz remota lenta, y cortarla fue el defecto del
entrecortado original).
Batería completa: 62 verificaciones en 4 suites, todas en verde.
test_tv_voz.js 16 incluye: exactamente 1 reintento, sin fantasmas
test_rips_sondeo.js 9 incluye: el guardián de ficha existe y corre antes
test_rips_ventana.php 6
test_bsuid.php 31
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
La suite probaba los fallos (recolector, motor pausado, bloqueo, voz lenta)
pero no que HABLE BIEN: qué texto dice exactamente, con qué voz, y cómo
pronuncia. Un anuncio que suena pero dice «MaríA GóMez» o elige la voz remota
teniendo la local también es un fallo, y no estaba vigilado.
Cuatro casos nuevos: el texto deletrea el código y cierra con el destino, las
tildes capitalizan bien, se prefiere la voz local sobre la remota es-CO, y sin
nombre de paciente igual habla. 13 verificaciones en total.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
── Voz que a veces no suena o se corta ──
Dos causas nuevas, ambas intermitentes por naturaleza:
1. Defecto conocido de Chrome: si nada referencia la SpeechSynthesisUtterance,
el recolector de basura puede llevársela A MITAD DE FRASE. El audio se corta
en seco y 'end' no llega. Depende de cuándo pase el recolector, así que
nunca se reproduce a voluntad. Cada locución queda anclada en un Set hasta
terminar (_uttAncladas).
2. Tras un cancel(), en Windows y ChromeOS el motor puede quedar en pausa:
speak() encola y jamás suena, sin error alguno. resume() antes de cada
speak() lo destranca, y sobre un motor sano no hace nada.
Y porque lo intermitente no se depura mirando la pantalla, queda una bitácora:
cada intento de hablar registra voz elegida, si es local, cuánto tardó en
arrancar y cómo terminó — en localStorage.tvVozLog (últimos 200) y en la tabla
turnero_tv_log vía sendBeacon (endpoint log_tv.php, insert-only, eventos de
lista cerrada). La próxima vez que reporten "ayer a las 10 no sonó", se
consulta la tabla y se ve qué pasó exactamente.
── Servicios de RIPS que "se demoran" ──
Medido en datos, no en hipótesis: la facturación en el sistema del laboratorio
ocurre MIENTRAS la recepcionista atiende. La consulta a RIPS se hacía UNA sola
vez, al vincular al paciente — y en 7 días, 547 de 549 registros llegaron
DESPUÉS de esa única consulta. Nadie volvía a preguntar: eso es lo que se
percibía como lentitud de RIPS. (El scheduler en sí tarda segundos; de paso:
el reloj del equipo legado está ~1 hora atrasado, visible en hora_recepcion.)
Ahora la ficha sondea cada 10 s hasta 10 minutos y se detiene al encontrar,
al limpiar la ficha o al agotar los intentos. Si la recepcionista ya marcó
exámenes a mano, no se le pisan: se le ofrece el banner en vez de autocargar.
── Pruebas (22, todas contra el código real extraído de las vistas) ──
scripts/test_tv_voz.js 9 anclaje GC, resume(), bloqueo, voz lenta, bitácora
scripts/test_rips_sondeo.js 7 reintentos, paradas, tope, sin duplicar
scripts/test_rips_ventana.php 6 ventana SQL en tabla TEMPORARY, sin tocar datos
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
