Emulación en vivo con el usuario escuchando (23/08, 12:36-12:44): rellamados
reales a los dos turnos en recepción, instrumentando la pestaña. El fallo
apareció a la primera y quedó fotografiado:
speaking: true ← el motor JURA estar hablando
'start' nunca disparó ← pero no suena, y no hay error alguno
usuario: «salió pero no habló»
Es el motor de voz durmiéndose tras el ocio: el primer speak() de ahí en
adelante queda atascado — finge hablar sin producir audio. El vigilante lo
toleraba porque speaking=true parece legítimo, y el keepalive pause/resume ni
lo prevenía ni podía correr (solo actúa con el motor en reposo). Por eso «el
primero no habla y el segundo sí»: el cancel() del segundo desatascaba.
Dos piezas, ambas validadas en vivo antes de entrar al repositorio:
1. PREVENIR: el keepalive ahora habla de verdad — una letra a volumen cero
cada 25 s con el motor ocioso. Trabajo inaudible que lo mantiene despierto.
En la ronda de validación, el llamado tras 30 s de ocio (el caso que
siempre fallaba) habló completo a la primera, y los cuatro de la ronda
también, sin un solo reintento.
2. CURAR: el vigilante distingue ahora tres estados en vez de dos:
pending sin speaking = voz remota descargando (prórroga de 6 s);
speaking sin 'start' = ATASCO (una locución que de verdad suena dispara
'start' de inmediato): se invalida la generación, cancel(), y se rehabla
tras 500 ms de respiro — rehablar de inmediato se volvía a atascar.
La bitácora lo registra como sin_start con atasco:1.
La primera versión del desatascador (probada en vivo) reintentaba por partida
doble: el cancel() dispara 'error' sobre la misma locución y ese handler
también reintentaba. Se invalida la generación ANTES de cancelar.
Suite: 24 verificaciones, incluyendo el atasco simulado (exactamente 2 speak,
un aviso, sin fugas) y el keepalive (existe, es inaudible, no interfiere).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
