latentDos tareas con criterios distintos
ReActReel tiene modos de cine y música. Una frase o descripción recordada termina en un resultado de YouTube. Identificar consiste en encontrar un video con la obra correcta. Localizar consiste en iniciar cerca del pasaje solicitado. El título puede ser correcto y el segundo de inicio estar equivocado.
Las búsquedas grabadas encontraron una escena de Star Wars en el segundo 107 y una interpretación de Hotel California en el 112. Ambas mostraron reproducción dentro de la aplicación con Quick apagado. Son dos ejemplos exitosos, no una tasa de acierto sobre peticiones nuevas.
Arquitectura y estado de ejecución
Petición Next.js → FastAPI /api/run/stream → reactreel-core
→ búsqueda → observación → siguiente acción
→ comprensión de video → tiempo propuesto → URL
→ evento de finalización → reproducción en YouTube
El agente compartido produce eventos durante la ejecución. La traza muestra argumentos, observaciones e iteraciones. La acción de terminar y el agotamiento del límite de iteraciones son desenlaces distintos; el evento final puede indicar reached_max_iterations.
El despacho comprueba que la herramienta elegida tenga su objeto de argumentos. Si falta, devuelve una observación de error. Así se puede inspeccionar la acción incorrecta y darle información al siguiente paso. Una evaluación debe conservar estos fallos aunque la respuesta final funcione.
Localización y construcción de la URL
get_timestamp_from_text envía la URL y la frase a la interfaz de comprensión de video de Gemini. No busca en una transcripción local. Solicita start_seconds, end_seconds, confidence y matched_text.
La conversión de minutos importa: 1:47 equivale a 107 segundos. La ruta de error puede devolver un intervalo predeterminado con confianza cero y un error. Comprobar únicamente que existe start_seconds convertiría ese fallo en un supuesto pasaje al inicio del video.
process_video convierte el tiempo y construye una URL de YouTube. No descarga ni renderiza un clip. Hay que comprobar disponibilidad, permiso de reproducción integrada y comienzo del pasaje. Una URL válida no demuestra esas tres propiedades.
Modo Quick y errores durante la transmisión
Quick agrega una instrucción para terminar al identificar el video y omitir la búsqueda de tiempo. No retira esas herramientas del despachador. Para evaluar el recorrido corto hay que inspeccionar las llamadas reales y comparar latencia y consumo con las mismas peticiones.
El backend transmite eventos SSE de inicio, resultados y finalización, y archiva los eventos. Un fallo después de iniciar la transmisión se representa como loop.errored; el código HTTP inicial ya no describe ese desenlace. La interfaz debe conservar la traza y distinguir interrupción de finalización.
Antes de comenzar, el controlador comprueba sesión y presupuestos de uso. Esos controles limitan acceso y consumo; el límite de iteraciones acota el ciclo. Ninguno mide la calidad de la búsqueda.
Revisión y límites de la evidencia
Revisa los ejemplos en la página del proyecto: resultado de búsqueda, respuesta de localización, URL final y pasaje audible. Un video que posteriormente deje de estar disponible cambia la utilidad actual del enlace, aunque la grabación conserve lo ocurrido.
Una evaluación más amplia necesita descripciones fijas, identificadores aceptados e intervalos revisados manualmente. Debe medir identificación sobre todas las peticiones, error temporal cuando la identificación acierta, fallos de herramientas, agotamiento de iteraciones, reproducción, latencia y consumo. Es una propuesta de evaluación hasta que existan esas ejecuciones.
El artículo técnico identifica reactreel_core/agent.py, skills/transcript_search.py, skills/youtube_manager.py y routers/run.py como puntos de revisión. Documenta el comportamiento grabado y los formatos de respuesta. Este informe no agrega un benchmark ni demuestra calibración de confianza.