[review] Playlist bot: fallback keys off participant presence, not live audio

[nicoechaniz]

[review] Playlist bot: fallback keys off participant presence, not live audio

Local reference: R7

Status: Deferred; review finding only. Requires LiveKit-native integration
verification and is not safe to change without the rehearsal environment.

What was found

• services/playlist-bot/src/index.ts fades the playlist out whenever identity
  beacon01 is present, even if that participant has not published an audio
  track or its track has ended.
• The app health check sees the bot's published track, but cannot tell that its
  captured frames have faded to silence.

Why it matters

A connected-but-silent primary source can make both the live source and fallback
silent while health appears green.

Proposed change

Drive fallback state from the primary source's actual audio publication/mute
lifecycle, and expose a bot state signal that distinguishes publishing audio
frames from merely holding a LiveKit track.

Acceptance criteria

• The playlist remains audible when beacon01 is connected without live audio.
• Track publish/unpublish/mute transitions crossfade exactly once.
• Reconnect reconstructs the correct state from current publications.
• Health turns red when neither source is producing audio.
• Behavior is verified against the deployed @livekit/rtc-node version.

---

Filed by watchdog from fallback markdown. Deferred finding — see status above.

[nicoechaniz]

Claim 2026-08-05 after rechecking open PRs, Project #7 and current Annie/Mariano ownership: Nico+Codex takes the isolated playlist-bot investigation. Scope for now is read-only lifecycle analysis, a LiveKit-version-pinned behavioral contract and regression-test design. No codec/gain/buffer/routing change and no audible fallback behavior will be merged or deployed without Nico’s explicit audio review.

[nicoechaniz]

Auditoría completada sin cambiar señal ni runtime:

• El hallazgo principal ya fue corregido en 2b95934 (fix playlist fallback availability): disponibilidad depende de una publicación de audio de beacon01 no muteada y se reevalúa en publish/unpublish/mute/unmute/reconnect.
• Ese commit está contenido en main, release y en el SHA de producción observado 9fdad45c8f19; no era una implementación pendiente como sugería el cuerpo histórico.
• Verificación actual sobre el checkout: playlist-bot 6/6 tests y TypeScript build verdes; lockfile fija @livekit/rtc-node 0.13.32.

No cierro la tarjeta: faltan pruebas de wiring que demuestren transición exactamente una vez y reconstrucción tras reconnect, el health explícito “ninguna fuente produce audio”, y una verificación LiveKit-native controlada. Esos pasos afectan el fallback audible y quedan sujetos al guardrail/revisión acústica específica. Se devuelve a Todo con Responsable Nico y alcance residual preciso; no hay branch ni cambio de comportamiento activo.

[nicoechaniz]

Retomo el claim residual en rama aislada test/playlist-fallback-lifecycle sobre main 360952a. Alcance: pruebas exact-once/reconnect y observabilidad control-plane del estado de fuente, sin cambiar codec, formato, ganancia, buffer, crossfade ni reglas acústicas. La rama/PR quedará pendiente de revisión explícita y no se mergeará ni desplegará autónomamente.

[nicoechaniz]

Draft PR #150 (2e39600) publica el slice residual behavior-preserving: reconciliación desde snapshot completo, transiciones exact-once ante eventos duplicados/stale, publicación paralela obsoleta y reconstrucción tras reconnect. Evidencia local: 12/12 tests playlist-bot, TypeScript build y diff-check verdes. Está marcado audio-touching, permanece draft y no se mergeará/desplegará sin revisión explícita. Health de producción de frames y rehearsal LiveKit-native siguen fuera de este slice.

[nicoechaniz]

PR #150 follow-up 1922042 closes the remaining stale participant-replacement lifecycle case: an obsolete ParticipantDisconnected now rebuilds availability from the current room snapshot instead of forcing fallback on. A live replacement beacon01 therefore suppresses a duplicate fade-in. Local evidence: playlist-bot 13/13 + TypeScript build; CI rerunning. Card remains In Progress and audio-guarded pending explicit Nico review and live rehearsal.

[nicoechaniz]

Estado final del draft audio-touching #150: head 1922042, todos los gates remotos verdes (E2E 8m, full tests, lint/build y frozen-audio). Incluye la corrección adversarial para que un ParticipantDisconnected obsoleto reevalúe el snapshot actual en vez de silenciar una fuente reemplazada. Permanece draft/In Progress: no merge ni deploy sin aprobación acústica explícita de Nico y ensayo vivo del fallback.

[nicoechaniz]

LiveKit-native lifecycle verification is now committed to draft PR #150 as 9ef9b28. Against disposable LiveKit v1.13.4 and the pinned rtc-node 0.13.32, the opt-in test passed identity-without-track, publish, mute, unmute, unpublish and same-identity replacement using real SDK snapshots (14/14 service tests; TypeScript green). The lab-only server enabled remote unmute solely to exercise that event; production keeps remote unmute disabled. No runtime/audio/deploy change. Remaining card acceptance: truthful frame-production health plus audible controlled rehearsal and explicit audio approval.

[nicoechaniz]

Reconciliación de Kanban 2026-08-05: el slice técnico está preservado en draft PR #150 con gates verdes y verificación LiveKit-native, pero no hay implementación activa. Restan health de producción de frames, ensayo audible controlado y aprobación audio-touching explícita. Se mueve a Todo; PR y issue permanecen abiertos, sin merge/deploy ni cambio de señal.