Task Scheduler como SPOF del bib-reindex

Cuándo

Descubierto y resuelto el 21 de abril de 2026 durante Sesión 3 del Supercontexto (Fase 1 Backbone). Problema existía desde antes: script de reindexación de la Biblioteca (bib-reindex.ps1) vivía en Windows de Edu y dependía del Task Scheduler del PC personal.

Síntomas (Grafo estancado cuando el PC estaba apagado)

Cuando el PC de Edu estaba apagado, suspendido o sin sesión activa, Task Scheduler no lanzaba el job y el grafo dejaba de actualizarse. Consecuencias silenciosas: ningún error visible, pero nodos y comunidades progresivamente desactualizados. Cualquier commit nuevo a CreaRack-Pro no se reflejaba en el índice hasta que Edu encendiese el PC y el siguiente ciclo se disparase. En sesiones con PC apagado toda la noche o durante viajes, desfase de horas o días.

Causa raíz

Script original (scripts/bib-reindex.ps1) era PowerShell diseñado para Windows. Ejecución dependía exclusivamente del Task Scheduler del SO del PC personal de Edu, equipo de usuario final sin garantías de disponibilidad continua. Convirtió al PC en SPOF (Single Point of Failure) directo para la pipeline de reindexación. Cualquier evento cotidiano — apagar equipo, dormir sistema, pérdida de red doméstica, Windows Update con reinicio — interrumpía el ciclo sin alerta ni fallback.

Fix aplicado (migración a Hetzner Staging cron)

Se desarrolló scripts/cron-bib-reindex.sh, port bash del script PowerShell original, diseñado para correr en servidor Hetzner Staging bajo /etc/cron.d/bib-reindex cada 10 minutos. El nuevo script:

• Hace git pull --rebase origin main sobre repo clonado en /opt/crearack-pro.
• Ejecuta bib_ast.py --push para las 7 apps Django.
• Llama bib_compute_communities via MCP si todas las apps indexan sin error.
• Lee token desde /opt/bib-reindex/.token (chmod 600).
• Rota log en /opt/bib-reindex/cron-bib-reindex.log cuando supera 5 MB.

Staging es servidor Linux de disponibilidad continua, sin dependencia de ningún PC personal.

Lecciones (feedback_infra_not_on_personal_pc)

Cualquier proceso de mantenimiento periódico del sistema — reindexación, backups, health checks — no debe depender jamás de hardware de usuario final. El PC personal no es infraestructura: no tiene SLA, no tiene monitorización, su disponibilidad es impredecible por diseño. Regla concreta: si un cron necesita correr mientras duermes, no puede vivir en tu máquina.

Preventivos futuros

• Todo job periódico nuevo se despliega directamente en Staging o Producción desde el primer día, nunca como script local temporal.
• cron-bib-reindex.sh incluye pre-flight checks explícitos (repo presente, token legible, script Python accesible) que fallan rápido y loguean motivo antes de ejecutar.
• Log estructurado con niveles OK/INFO/WARN/ERROR/STDERR permite detectar degradación parcial (apps fallidas) sin que cron pase desapercibido como exitoso.
• Considerar añadir alerta MCP (create_alert) si total_failed > 0 al final del ciclo, para visibilidad activa en dashboard.

Véase también

• [[concept—biblioteca—supercontexto]]