Objetivo
El sistema pasa de reactivo a proactivo: un job programado envía cada mañana a
las 7am un briefing por Telegram con papers nuevos, noticias y un concepto.
Contexto
Hasta ahora el bot solo responde cuando se le pregunta. El briefing es el primer
comportamiento autónomo del sistema, y es lo que convierte ResearchOS de
"chatbot sobre papers" en "asistente de investigación".
Criterios de aceptación
Capas afectadas
application/services/briefing_service.py — nuevo, compone el briefinginfrastructure/scheduler/ — nuevo, APSchedulerscripts/run_telegram_bot.py — el scheduler arranca junto al bot
Decisiones a documentar
¿El scheduler corre en el mismo proceso que el bot? run_polling() gestiona
su propio event loop; APScheduler tiene versiones sync y async. Hay que decidir
si el scheduler vive dentro del proceso del bot (más simple, un solo despliegue)
o como proceso separado (más robusto, dos contenedores). Esta decisión condiciona
T23.
Cómo se decide "papers nuevos relevantes". Hace falta una lista de temas de
interés. ¿Hardcodeada, en config, o derivada de las queries que el usuario ha
hecho al bot? La tercera es la más interesante y conecta con T24.
Idempotencia. Si el job corre dos veces, no debe ingerir los mismos papers ni
enviar dos briefings. Definir cómo se garantiza.
Objetivo de aprendizaje
Comportamiento autónomo programado y sus problemas: timezone, idempotencia,
qué pasa si el proceso estaba caído a las 7am, cómo se prueba algo que depende
del reloj.
Fuera de alcance
Cloud Scheduler (V4). Personalización del briefing por usuario.
Estimación
5h
Depende de
T20 — el briefing usa las tools de noticias y conceptos.
Objetivo
El sistema pasa de reactivo a proactivo: un job programado envía cada mañana a
las 7am un briefing por Telegram con papers nuevos, noticias y un concepto.
Contexto
Hasta ahora el bot solo responde cuando se le pregunta. El briefing es el primer
comportamiento autónomo del sistema, y es lo que convierte ResearchOS de
"chatbot sobre papers" en "asistente de investigación".
Criterios de aceptación
apscheduleragregado como dependenciaconcepto explicado
telegram_chat_iddeconfig.py(ya existe elsetting)
solo se listan
caracteres ya manejado en T15
mockeadas
esperar las 7am
Capas afectadas
application/services/briefing_service.py— nuevo, compone el briefinginfrastructure/scheduler/— nuevo, APSchedulerscripts/run_telegram_bot.py— el scheduler arranca junto al botDecisiones a documentar
¿El scheduler corre en el mismo proceso que el bot?
run_polling()gestionasu propio event loop; APScheduler tiene versiones sync y async. Hay que decidir
si el scheduler vive dentro del proceso del bot (más simple, un solo despliegue)
o como proceso separado (más robusto, dos contenedores). Esta decisión condiciona
T23.
Cómo se decide "papers nuevos relevantes". Hace falta una lista de temas de
interés. ¿Hardcodeada, en config, o derivada de las queries que el usuario ha
hecho al bot? La tercera es la más interesante y conecta con T24.
Idempotencia. Si el job corre dos veces, no debe ingerir los mismos papers ni
enviar dos briefings. Definir cómo se garantiza.
Objetivo de aprendizaje
Comportamiento autónomo programado y sus problemas: timezone, idempotencia,
qué pasa si el proceso estaba caído a las 7am, cómo se prueba algo que depende
del reloj.
Fuera de alcance
Cloud Scheduler (V4). Personalización del briefing por usuario.
Estimación
5h
Depende de
T20 — el briefing usa las tools de noticias y conceptos.