Come costruire un signals bus in markdown per N automazioni

Il problema

69 job schedulati su 5 piattaforme. Nessuno sa cosa sta facendo l'altro.

Questo era il sistema a febbraio 2026. Un reel pubblicato, un articolo scritto, un competitor monitorato: ognuno su una piattaforma diversa, ignaro del resto.

Ho considerato due soluzioni:

1. Un database condiviso (PostgreSQL o qualcosa del genere)
2. Webhook diretti tra i job: A chiama B quando finisce

Entrambe sbagliate, per motivi diversi.

Il database richiedeva che ogni job sapesse dove connettersi, come autenticarsi, cosa leggere. Overhead per ogni job aggiunto. Il webhook diretto creava accoppiamento: ogni cambio in A rischia di rompere B.

La soluzione: un file con sezioni

L'alternativa è un file di testo strutturato che tutti possono leggere e scrivere, con una regola sola: ogni job scrive solo nella propria sezione.

Lo chiamo signals bus. Non è un concetto nuovo: è una variante del pattern message bus semplificata al massimo per sistemi piccoli.

Come funziona:

1. Il file ha N sezioni, una per ogni owner (job o gruppo di job con lo stesso obiettivo)
2. Ogni sezione ha un header con last_updated: <ISO datetime>Z e owner: <nome>
3. La Routine owner sovrascrive tutta la propria sezione a ogni run: non appende, sostituisce
4. Tutte le Routine possono leggere tutte le sezioni prima di agire

Nel mio sistema il file si chiama system-signals.md e ha 14 sezioni. Il brain che decide il topic del reel, prima di scegliere, legge la sezione ## instagram-publish per sapere cos'è già uscito questa settimana.

Un esempio concreto

La sezione ## instagram-publish tiene traccia di ogni reel pubblicato:

## instagram-publish
last_updated: 2026-08-12T10:00:00Z
owner: reel-content-brain

2026-08-11 | claude-hooks | triggered (filone: valore)
2026-08-10 | claude-code-automode | triggered (filone: news)

Il brain legge questa sezione e conta: quante news ho fatto negli ultimi 7 giorni? Ho sforato la quota? Se la quota è piena, cambia topic.

Nessuna chiamata diretta tra job. Il brain legge, il bus risponde.

Come costruirne uno

Se hai 3 o più automazioni che dovrebbero coordinarsi, bastano questi passaggi:

1. Crea un file signals-bus.md in un repo condiviso raggiungibile da tutti i job
2. Aggiungi una sezione per ogni automazione: ## nome-automazione
3. Nell'header di ogni sezione metti last_updated: e owner:
4. Ogni automazione, al suo run, sovrascrive tutta la propria sezione con lo stato corrente
5. Le altre automazioni leggono le sezioni prima di agire

Per sovrascrivere la propria sezione senza toccare le altre: leggi il file corrente, individua i confini della sezione (da ## nome al prossimo ## o EOF), sostituisci solo quella parte, riscrivi il file.

Funziona bene se

• I job girano con cadenza regolare (cron, scheduler)
• Lo stato che si scambiano è leggibile da un umano
• Il numero di Routine è gestibile (io ne ho 14; oltre, il file potrebbe diventare rumoroso)

Non è la soluzione giusta se

• Hai bisogno di eventi in tempo reale (usa un webhook diretto)
• Le Routine devono aspettarsi a vicenda (usa una coda)
• Il volume di dati è grande (usa un database)

Nel mio caso, ogni Routine gira con frequenza variabile: da ogni ora a ogni settimana. E non ha bisogno di risposta immediata. Il file markdown regge.

Il risultato

Da febbraio 2026, 14 Routine scrivono e leggono dallo stesso file. Zero conflitti di scrittura: ogni Routine possiede solo la propria sezione. Zero database da mantenere. Zero webhook da aggiornare se cambia un job.

Il sistema funziona perché le Routine non si parlano: parlano al file, e il file parla a tutti.