===============================================================
  OPCIONES DE AUTOMATIZACIÓN — Comparativa
===============================================================

OPCIÓN A — CRON + CLAUDE HEADLESS (SIMPLE)
==========================================
Un cron semanal en Debian. Un único script que invoca claude
con un prompt grande pidiendo que lo haga todo de cabo a rabo.

PROS:
  - Setup en 30 minutos
  - Sin infra extra (solo cron)
  - Cero costes adicionales

CONTRAS:
  - Un único punto de fallo
  - Si claude se atasca en un conflicto, todo se queda colgado
  - Sin recuperación parcial
  - Difícil debuggear cuándo va mal

CUÁNDO USARLA:
  - Cuando solo se quiere probar el concepto
  - Cuando los cambios upstream son pequeños y predecibles


OPCIÓN B — MULTI-AGENTE (RECOMENDADA)
=====================================
Tres agentes especializados en cron. Cada uno con su prompt
corto, su contexto, y su responsabilidad clara.

  scout    | Lun 03:00 | git fetch + analiza diff + reporta
  merger   | Lun 04:00 | aplica cambios safe + abre PR
  builder  | Lun 05:00 | build APK + sube + notifica

PROS:
  - Fallo aislado (si scout falla, merger no se ejecuta)
  - Prompts cortos = menos tokens = más barato y fiable
  - Logs separados por agente
  - Recuperable: puedes re-ejecutar solo el que falló
  - Auditable: cada agente deja su reporte en disco

CONTRAS:
  - Más setup inicial (3 crons, 3 prompts)
  - Hay que orquestar dependencias (merger depende de scout)

CUÁNDO USARLA:
  - Cuando los cambios upstream son frecuentes y variados
  - Cuando quieres ver QUÉ va a aplicar antes de aplicarlo


OPCIÓN C — GITHUB ACTIONS
=========================
Workflow en .github/workflows/weekly-merge.yml del repo
oasis_mobile. Trigger en cron + manual dispatch.

PROS:
  - Gratis (2000 min/mes en repo público o privado básico)
  - Histórico completo de runs visible
  - Artifacts descargables (la APK)
  - Logs públicos si lo quieres
  - Cero infraestructura propia

CONTRAS:
  - Timeout máximo 6h por job
  - Build APK consume bastante (10-15 min)
  - El repo debe estar en GitHub (no en Gitea code.03c8.net)
  - Secrets: ANTHROPIC_API_KEY visible para todos los maintainers

CUÁNDO USARLA:
  - Si planeas mover el repo a GitHub
  - Si no tienes VPS o no quieres gestionarlo


OPCIÓN D — WEBHOOK REACTIVO
===========================
Webhook de GitHub apuntando a un endpoint en tu VPS. Cuando
epsylon publica un release, dispara inmediatamente el pipeline.

PROS:
  - Reacción casi en tiempo real (segundos)
  - No esperas al cron del lunes
  - El pipeline puede ser tan complejo como quieras

CONTRAS:
  - Requiere VPS público con dominio + HTTPS
  - Hay que mantener el endpoint
  - Si el webhook falla, hay que tener un cron de respaldo

CUÁNDO USARLA:
  - Cuando quieres lo más rápido posible
  - Cuando tienes ya un VPS funcionando


COMBINACIÓN RECOMENDADA: B + D
==============================
- Webhook (D) dispara scout (de B)
- Cron de seguridad cada lunes 03:00 también ejecuta scout
  (por si el webhook falla)
- Resto del pipeline (merger + builder) es B

Mejor de los dos mundos: rápido pero con respaldo, modular,
auditable, recuperable.