2026-09-07 — surtido-mesh: cauces tesis × radio

Contexto: rama surtido-mesh (MESH.md). Tesis: ¿hasta qué punto distribuir procesamiento/almacenamiento reduce la dependencia del gateway bajo conectividad intermitente? Métrica EME. Radio hecha: parrilla Bloomberg con TTS Google Cloud (dependencia total del gateway para la voz).

## Cauces (detalle en MESH.md de la rama)
 
1. Radio como servicio canónico local-first: la parrilla (guion+MP3+
   playlist) es la carga útil de los datasets B/C; métrica =
   disponibilidad sin gateway.
2. Guion por la mesh, voz en el borde: transmitir guion.json (KB), no
   audio (MB); TTS local Piper/Coqui. pronunciacion.py ya es cómputo
   de borde. Es semantic communication medible en bytes/latencia/energía.
3. guion.json como semilla del event-log: extender a mesh-log.json por
   nodo (TX/RX/STORE/RELAY/GATEWAY_OFFLINE) = primer dataset propio.
4. EME del broadcast: centralizado expone guion+audio+tokens GCP; mesh+
   borde casi nada. Uno-a-muchos ideal para LoRa.
5. Radio como salida: hallazgos EDA entran como notas TECH al aire.
 
## Orden
 
EDA1 CAIDA → simular parrilla en mesh → prototipo TTS local → dataset
4 casas → recién ahí edge AI. No comprar radios antes del EDA1.
 
## Primer paso ejecutable
 
Se añadió `scripts/mesh_experimento.py` en la rama `surtido-mesh`. Compara
un escenario de gateway offline durante la distribución:
 
- centralizado: distribuye MP3 y los nodos no reciben la nueva edición;
- mesh+borde: A recibe `guion.json`, B-D lo replican y sintetizan localmente.
 
Genera `mesh-log.json` con `TX`, `RELAY`, `STORE` y `PLAY`, junto con los
bytes y supuestos del experimento. El modo `--demo` ya fue ejecutado con
éxito. La reducción observada (100% en la demo) no es resultado científico;
es solo una línea base porque el audio se estima a 96 kbps y la caída es
total. El próximo cambio metodológico debe sustituir esa caída total por
trazas de CAIDA o una matriz explícita de disponibilidad.