YouTube va bannejar el meu VPS

El matí del 17 d'abril, el cronjob noticias-ilustradas em va mandar un missatge diferent al d'habitual:

He localitzat el vídeo d'avui de NOTICIASILUSTRADAS però no he pogut extreure la transcripció. Tots els camins han fallat — la skill de Hermes, yt-dlp amb cookies, curl directe. La IP del VPS està bannada per YouTube per a transcripcions.

Fins a aquest missatge pensava que el digest matutí era robust. Havia estat funcionant durant setmanes. Però un canvi silenciós en la política de YouTube (rate limit? heurística del centre de dades?) l'havia deixat fora.

Ese dia vaig acabar fent tres fixes en paral·lel. Els tres es redueixen a la mateixa lliçó: un sistema que "funciona" i un sistema que "és robust" són coses diferents.

Fix 1: Del transcript de YouTube a Brave Search API

La ruta antiga

Cron → buscar el vídeo del dia de NOTICIASILUSTRADAS
     → yt-dlp descarrega + extreu subtítols
     → LLM resumeix
     → TTS → voice message Telegram

Depenia de YouTube en dos llocs: llistar vídeos del canal i extreure transcript. Tots dos passos sensibles a la IP.

La pregunta que em vaig fer

Abans de muntar res, em vaig aturar un segon: realment necessito YouTube? L'objectiu real és rebre un resum de les notícies del dia en àudio a les 06:57. YouTube era el com, no el què.

La ruta nova

Cron → Brave Search API amb query d'actualitat
     → LLM resumeix els titulars
     → TTS → voice message Telegram

Brave Search API no baneeja IPs de centre de dades. No necessita cookies. No necessita transcript. I a l'hora del digest, els titulars frescos són més útils que un vídeo de 15 minuts pujat anit.

Vaig canviar audio_matutino.py, la vaig executar manualment, va sortir el voice message de 407KB, vaig reinstal·lar el cron (57 6 * * *). 20 minuts.

La pregunta "realment ho necessito?" estalvia més codi que qualsevol refactor.

Fix 2: El RPi residencial com a xarxa de seguretat

Encara que Brave va resoldre el cas concret, el problema de fons segueix: qualsevol servei que baneegi IPs de Hostinger em deixa sense aquest cron. I això passarà de nou.

Ja tenia el proxy residencial del RPi (muntat el 12 d'abril, 100.78.170.78:8888 via Tailscale). Ese dia el vaig deixar documentat com a "opció B per quan faci falta". Doncs feia falta ja.

Vaig afegir el proxy com a fallback opcional als scripts sensibles: si detecto blocatge, pivotar a salida residencial. No vaig reescriure tot — només vaig marcar els punts on podria reengantxar-se fàcil.

Lliçó: tenir la infra preparada no és suficient. Has de marcar explícitament on s'utilitzarà quan faci falta, o quan arribi la fallida estarás reinventant la roda.

Havia muntat el proxy RPi feia 5 dies "per si de cas". Esse "per si de cas" va arribar a les 72 hores. El "per si de cas" sempre arriba abans del que penses.

Fix 3: Política drafts-only en el sender de correus

El mateix dia vaig endurir quelcom que venia arrossegant: el script send_via_gmail.py que usa Diana Ferrer (desenvolupament de negoci de OhanaSmart) per mandar outreach.

La por

Tinc un cronjob diari que prepara un batch de prospects per enviar. Si esse cron, per un bug o un prompt mal afinat, decidís enviar 50 emails a decisors del sector hoteler amb un to cutre — no hi ha volta enrere. Això crema el negoci sencer.

La solució

send_via_gmail.py ja no envia. Crea esborrany a Gmail.

# Abans:
service.users().messages().send(userId='me', body=message)

# Ara:
service.users().drafts().create(userId='me', body={'message': message})

Una crida diferent a la Gmail API. Zero canvi de flux per a mi: cada matí obro Gmail, repaso la columna "Esborranys", i mano els que tenen sentit. Els que no, els edito o els borro.

Essa línia de codi és més robust que qualsevol governance toolkit. No depèn d'un runtime de seguretat, no es pot bypassejar, és arquitectònic. Si el meu agent es torna boig demà, el pitjor que pot fer és deixar-me 50 esborranys rars. Res surt fora sense el meu click.

Regla: per a decisions irreversibles (email a un client, commit a main, pagament, envío real), posar un humà al mig no és fricció — és l'única defensa que no es pot hackear.

Fix 4 (bonus): Els templates de Diana en divs, no tables

El mateix dia vaig descobrir que els templates HTML dels emails de Diana es trencaven a Gmail al enviar-los com esborranys. La <table> es transformava en columnes aleatòries al obrir l'esborrany des de la UI de Gmail.

Vaig reescriure tots els templates a <div> amb max-width: 80% i estilos inline. Signatura a 14px, sense centrat, imatge inline via Content-ID.

No és glamorós. Però la diferència entre un email que es veu professional a Gmail i un que sembla un formulari de 2003 és esse detall del <div> vs <table>.

El fil comú

Els quatre canvis del dia (YouTube → Brave, RPi com a fallback, drafts-only, templates amb divs) responen a la mateixa pregunta:

"Quan açò falli — perquè fallarà — quins passa?"

Quan YouTube baneeja → el digest canvia a Brave Search, zero intervenció.
Quan un altre servei baneeja → el RPi és allà com a salida residencial.
Quan el meu agent es descontrola → el pitjor és un esborrany, no un envío.
Quan Gmail trenca una <table> → el <div> aguanta.

Cada un tanca una modalitat de fallida. Cap és sofisticat. Cap necessita arquitectura nova. Els quatre són decisions petites amb conseqüències grans.

El que vaig aprendre

"Funciona" no és "és robust". Un sistema que funciona fins que canvia quelcom extern (política de IP, rate limit, format HTML) és fràgil per disseny. Robust és el que aguanta el canvi.
Pregunta't si ho necessites abans d'arreglar-ho. El fix de YouTube no va ser arreglar YouTube. Va ser adonar-me que YouTube era la implementació, no el requisit.
La infra preparada val zero fins que la uses. El RPi portava 5 dies muntat com a "per si de cas". Fins que no l'enganxí a un script real, era un adorn.
Els controls arquitectònics guanyen als controls de runtime. Drafts-only és una sola línia de codi que fa el que cap governance toolkit pot fer: impossiblilitar la fallida catastròfica.
Els detalls cutres maten la credibilitat. Un email a un director de residència amb un template trencata és pitjor que no haver-lo enviat. Invertir una tarda en templates que no reventen a Gmail val més que un dia de prospecció.

Què ve

Enganxar el proxy RPi com a fallback automàtic quan un request falla per IP (avui és manual)
Monitor del cron noticias-ilustradas que avisi si l'output baixa de X KB (proxy per a "quelcom es va trencar")
Replicar la política drafts-only a qualsevol script que envií quelcom extern — Telegram també hauria de ser revisable abans d'enviar en casos sensibles

Cap canvi gran. Molts canvis petits. Essa és la diferència entre un sistema que funciona un mes i un que aguanta un any.

— jo, Johnny — agent configurat: Harvie. La robustesa no s'afegeix al final. Es descobreix cada vegada que quelcom es trenca.