Ops & Security

Parti dalla regola mentale che non sbaglia mai: tutto ciò che viene compilato in un sito statico è pubblico. MOONKEY LAB è Astro 4 in modalità SSG — il build genera HTML+JS piatto servito da Cloudflare Pages. Non c'è un server che custodisca segreti a runtime. Qualsiasi stringa che importi in un componente .astro e che arriva al client finisce, letteralmente, in un file che chiunque scarica con `view-source` o aprendo DevTools → Sources. Per questo `src/lib/supabase.ts` contiene SOLO la anon key. La anon key è PROGETTATA per essere pubblica: è un identificatore di progetto + un token con permessi di ruolo `anon`, la cui autorità reale la limita Postgres RLS. Non è un segreto; è un indirizzo con un portiere.

Ora il contrasto che devi interiorizzare. Ci sono due chiavi Supabase con lo stesso aspetto (un JWT lungo) ma universi opposti di potere. La `anon` key opera sotto il ruolo `anon`/`authenticated` ed è SOTTOPOSTA a RLS: vede solo ciò che le policy permettono. La `service_role` key opera con `BYPASSRLS`: ignora tutte le policy, legge e scrive qualsiasi riga di qualsiasi tabella — incluse quelle di XHUB IRON (`iron_*`, `world_*`) che condividono la stessa istanza `wuchsslgbqlhyxljsmxi`. Se la `service_role` compare nel client, un attaccante non compromette solo MOONKEY: pivota verso tutti i progetti che vivono in quel DB. Regola dura: la `service_role` NON entra MAI in un repo di frontend, né in un `.astro`, né in un `import.meta.env.PUBLIC_*`. Il suo posto è un backend con sessione (una Edge Function, un processo server) o il tuo portachiavi locale — mai il bundle.

Il vettore di fuga più comune non è incollare la chiave nel codice: è il prefisso della variabile d'ambiente. In Astro, `import.meta.env.PUBLIC_X` viene INLINEato nel bundle del client a build-time; `import.meta.env.X` (senza `PUBLIC_`) esiste solo nel contesto server/build e NON viene esposto. Vite/Astro fanno questo per design. L'errore classico: chiamare una chiave `PUBLIC_SUPABASE_SERVICE_KEY` 'perché il componente la veda'. Ci riesci — e la regali al mondo. Il tuo albero decisionale per nominare una env var: questa chiave può essere pubblica? Sì → `PUBLIC_`. No → senza prefisso, e per giunta chiediti cosa ci fa in un progetto SSG (probabilmente non dovrebbe esserci).

Costruisci l'inventario. Apri il tuo progetto e classifica ogni credenziale in una tabella a tre colonne: nome · classe (pubblica/privata) · dove vive oggi. In MOONKEY le voci reali sono: `PUBLIC_SUPABASE_URL` (pubblica, identificatore), `PUBLIC_SUPABASE_ANON_KEY` (pubblica, limitata da RLS), e la `service_role` (privata — NON deve esistere affatto in questo repo; se ti serve per uno script di migrazione, vive nella tua shell locale o in un secret di CI, mai in `src/`). Aggiungi qualsiasi token di terze parti che tocchi: chiavi di email transazionale, webhook, token di analytics server-side. Ogni riga privata che si trova dal lato sbagliato è un incidente in attesa di accadere.

Il controllo che chiude il ciclo è la rilevazione automatica, perché la disciplina umana fallisce. Prima di ogni commit vuoi che qualcosa urli se una chiave privata si infila. Il pattern minimo: un grep in pre-commit che cerchi il pattern di una `service_role` (i JWT di Supabase service portano `"role":"service_role"` nel payload base64) e parole come `service_role`, `BEGIN PRIVATE KEY`, `sk-`. Per i repo reali usa `gitleaks` o `trufflehog` come hook. E se una chiave è GIÀ finita in un commit passato: non basta cancellarla dal codice — resta nella storia di git. Bisogna RUOTARLA nel pannello di Supabase (Settings → API → roll key) e riscrivere la storia se era un segreto vero. Ruotare è obbligatorio; cancellare il file non revoca nulla.

Chiudi con il caso Espejo, che aggiunge un asse etico, non solo tecnico. Espejo è multi-tenant: ogni influencer-tenant ha i suoi dati. Lì la domanda 'pubblica vs privata' si sdoppia: oltre alle chiavi di infrastruttura, gestisci dati personali/consentiti di utenti finali. La chiave di servizio capace di leggere ACROSS tenant è il segreto più sensibile del prodotto — la sua fuga non è solo tecnica, viola la frontiera di dati che la memoria di progetto marca come innegoziabile. Lezione trasversale: una credenziale privata non si definisce dal suo formato, si definisce da ciò che sblocca. Misurala sempre dal suo blast radius.

Adotta il giusto quadro mentale: in una SSG, il client non è la tua applicazione, è territorio nemico. L'attaccante ha il tuo bundle completo (è pubblico), il tuo `PUBLIC_SUPABASE_URL`, la tua anon key, e sa che dietro c'è Postgres. Non ha bisogno di 'hackerare' il tuo JavaScript: lo legge. Può istanziare il proprio client Supabase con la TUA anon key da una console di Node e parlare diretto con il tuo DB, senza passare mai dal tuo HTML. Perciò ogni logica di sicurezza che vive in `.astro` o in JS di client — un `if (user.role === 'admin')`, un componente che si nasconde — è UX, non sicurezza. Il CLAUDE.md di MOONKEY lo dice letterale: `admin.astro` è UX; la sicurezza NON dipende da quel gate.

Enumera la superficie d'attacco concreta. Per MOONKEY ci sono cinque tabelle raggiungibili con la anon key: `profiles, progress, feedback, leads, proofs`. L'attaccante, con un client autenticato via magic-link (chiunque può registrarsi), proverà l'ovvio: `supabase.from('profiles').select('*')` per scaricare TUTTI i profili; `supabase.from('leads').select('*')` per rubare la lista di lead; un `update` sulla propria riga di `profiles` mettendo `role = 'admin'` o `founder_badge = true` per auto-scalare; un `insert` in `proofs` con `user_id` altrui per falsificare il progresso di un altro. Ognuna di queste è un'ipotesi d'attacco che TU devi confutare con una policy. Se non l'hai confutata esplicitamente, dai per scontato che funzioni.

Capisci perché RLS è l'autorità e come si compone la difesa reale di MOONKEY. SELECT su `profiles/progress/feedback/proofs` è self-or-admin: la policy permette la riga solo se `user_id = auth.uid()` O `is_admin()`. `is_admin()` è SECURITY DEFINER — gira con i permessi del proprietario, verifica se il chiamante è admin senza che il chiamante possa manipolare quella decisione. Risultato: un non-admin che chiede `select('*')` non riceve un errore, riceve LE SUE righe e nient'altro — il dump massivo restituisce una sola riga, la sua. L'escalation di privilegi la taglia un trigger (`guard_privileged_profile_columns`): `role` e `founder_badge` sono immutabili per i non-admin, quindi l'`update role='admin'` viene rifiutato a livello di DB. L'insert altrui lo taglia `proofs_insert_self`: esige sessione e lega `user_id = auth.uid()`.

La conseguenza operativa del modello: verifica per impersonazione, non per lettura del codice. Una policy che 'sembra' corretta può avere un buco (un OR mal posto, un USING senza WITH CHECK che lascia passare gli update). L'unica prova che vale è metterti nei panni dell'attaccante: autenticati come un utente normale ed ESEGUI gli attacchi enumerati sopra contro il DB reale, confermando che ognuno restituisce vuoto o errore. Il CLAUDE.md menziona che l'isolamento di lettura è 'verificato per impersonazione' — questo è lo standard. 'Ho scritto la policy' non è prova; 'ho provato l'attacco come utente X e non ha letto la riga dell'utente Y' lo è.

Non dimenticare i vettori che non sono RLS. Il modello di minaccia di una SSG include anche: (a) la differenza USING vs WITH CHECK — USING filtra quali righe vedi/colpisci, WITH CHECK valida lo stato risultante di un INSERT/UPDATE; dimenticare WITH CHECK in un UPDATE ti lascia spostare una riga a un user_id altrui. (b) Le RPC: una funzione SECURITY DEFINER scritta male è una falla che ignora RLS per design — MOONKEY le restringe ad `authenticated` e revoca le operazioni pericolose. (c) TRUNCATE: revocato da anon/authenticated, perché RLS non protegge contro TRUNCATE (cancella l'intera tabella senza valutare le policy riga per riga). (d) Fuga per errori e per colonne: un SELECT che restituisce una colonna sensibile che hai dimenticato di escludere.

Atterra con il contrasto tra progetti per fissare il principio. XNLAB è un sito di brand quasi senza backend: la sua superficie è minima — moduli di contatto, intestazioni, forse un endpoint di acquisizione. Lì il modello di minaccia è 'spam e XSS nel poco che accetta input', non escalation di DB. XHUB IRON vive nella STESSA DB di MOONKEY ma è un pannello operativo del fondatore: le sue tabelle `iron_*` non devono essere leggibili da un utente di MOONKEY — lo stesso motore RLS deve mantenere DUE prodotti che condividono Postgres senza che uno legga l'altro (è OS-05). Il modello di minaccia non è generico: si deriva da QUALI dati ci sono, CHI può autenticarsi, e COSA condividono dell'infrastruttura. Parti sempre dall'inventariare quei tre assi.

Il principio guida è popperiano: un risultato di sicurezza non è vero perché lo affermi, è vero perché hai PROVATO a confutarlo e non ci sei riuscito. Inverti il flusso naturale. Quando credi di aver trovato una vulnerabilità ('chiunque può leggere `leads`'), il tuo passo successivo non è segnalarla — è provare a dimostrare che ti sbagli: c'è una policy che lo impedisce? L'ho provato con il ruolo corretto? Il `select` ha restituito dati reali o vuoto? Solo quando il tuo tentativo di confutazione fallisce, il risultato sale a confermato. E viceversa: quando credi che qualcosa sia sicuro ('la policy self-or-admin protegge `profiles`'), il tuo lavoro è attaccarlo finché non si rompe o sopravvive.

Definisci i due errori che insegui con nomi chiari. Falso positivo: segnali una vulnerabilità che non esiste — es. urli 'la anon key è esposta nel bundle' quando la anon key è pubblica per design e il DB è protetto da RLS (vedi OS-01). Bruci fiducia; la prossima volta nessuno ti crede. Falso negativo: dai per sicuro qualcosa che non lo è — es. 'il pannello admin è nascosto, siamo a posto' senza provare l'accesso diretto al DB. Lasci la breccia aperta. La verifica avversariale esiste per minimizzare ENTRAMBI, e lo strumento per entrambi è lo stesso: la prova eseguibile.

Il metodo concreto: per ogni risultato, produci una prova riproducibile, non un'affermazione. 'Riproducibile' significa: un comando o snippet che chiunque può eseguire vedendo lo stesso risultato. Per confermare che `profiles` NON si può dumpare: uno script che si autentica come user_A, fa `.from('profiles').select('*')`, e stampa il conteggio di righe — atteso 1 (solo la sua). Per confermare che l'escalation di privilegi è chiusa: come user_A, `.from('profiles').update({ role: 'admin' }).eq('id', myId)` e stampa l'errore che restituisce il trigger guard. Se l'attacco restituisce ciò che ti aspettavi (vuoto/errore), il controllo è verificato. Se restituisce dati, hai un risultato REALE — e viene già con la sua PoC allegata.

Lavora con lo strumento di Supabase ma senza arrenderti ad esso. `get_advisors` (security lints) ti segnala tabelle senza RLS, policy permissive, funzioni SECURITY DEFINER senza search_path fisso. Trattalo come generatore di IPOTESI, non di verdetti. Un advisor che dice 'funzione X è SECURITY DEFINER con search_path mutabile' è un'ipotesi di rischio: vai alla funzione, guarda se un attaccante può piazzare un oggetto in uno schema che essa risolve per prima. A volte è sfruttabile, a volte no per via del contesto. L'advisor ti risparmia la scansione iniziale; la confutazione la fai tu. Il CLAUDE.md già lo istituzionalizza: cambi di RLS = migrazione versionata + `get_advisors` dopo. Quella seconda parte è la verifica avversariale resa routine.

Bada ai falsi negativi del metodo stesso: l'attacco che 'passa' può passare per la ragione sbagliata. Se il tuo `select('*')` su `profiles` restituisce vuoto, è perché RLS l'ha bloccato, o perché la tua sessione di prova è scaduta / non eri autenticato / la tabella era vuota? Un controllo non si dà mai per buono senza un caso di CONTRASTO: prova che la stessa query SÌ restituisce dati quando deve (come admin, o come proprietario della riga). Una prova di sicurezza senza il suo controllo positivo è un falso negativo travestito da successo. Verifica sempre che la tua arma funzioni prima di concludere che il bersaglio è immune.

Atterra il rigore nei progetti dove sbagliare fa più male. In XCAP la verifica avversariale è dottrina centrale: la memoria del progetto la descrive come 'anti-fabbricazione per costruzione' — un sistema che registra forecast e li calibra contro risultati reali, confutando le proprie previsioni invece di crederci. Quello stesso muscolo lo applichi alla sicurezza: non firmare 'il ledger è read-only' finché un tentativo di scrittura con la credenziale di ingest non fallisce davanti ai tuoi occhi. In Espejo, dove la frontiera di dati personali è etica oltre che tecnica, una verifica che dice 'non c'è fuga tra tenant' senza una PoC di un tenant che prova a leggerne un altro NON è una verifica: è un desiderio. Confutare per primo, sempre, specialmente quando il risultato che ti aspetti è quello comodo.

Interiorizza la sequenza DCRP: Rilevare → Contenere → Recuperare (rollback) → Post-mortem. L'errore dei più è saltare direttamente a 'sistemare', toccando la produzione alla cieca. L'ordine conta perché ogni fase protegge la successiva: se non rilevi bene, contieni ciò che non è; se non contieni, il danno cresce mentre recuperi; se recuperi senza capire, ripeti l'incidente. E la regola zero, scritta in qualsiasi runbook serio: in un incidente NON improvvisi sulla produzione. Esegui passi predefiniti. La creatività è per il post-mortem, non per le 3 di notte con il sito giù.

Rilevare è sapere COSA è rotto e da QUANDO. In MOONKEY (Cloudflare Pages + Supabase) i tuoi segnali sono: il deploy di Cloudflare (quale commit è live? l'ultimo build è passato?), i log di Supabase (`get_logs` per servizio: api, postgres, auth — lì vedi errori di policy, query che falliscono, picchi di 4xx/5xx), e la lamentela dell'utente (spesso il primo segnale). La prima cosa che stabilisci è la timeline: cosa è cambiato proprio prima? Quasi sempre l'incidente correla con un deploy o una migrazione recente. 'È iniziato dopo il merge delle 16:20' restringe lo spazio di ricerca da ore a minuti.

Contenere è fermare l'emorragia prima di curare la ferita. Domanda chiave: questo sta corrompendo dati ADESSO? Se un bug sta scrivendo righe sbagliate in `proofs` o `progress`, ogni minuto che impieghi moltiplica il cleanup. Opzioni di contenimento secondo la gravità: ripristinare il deploy di Cloudflare al precedente (un click — Cloudflare Pages conserva i deploy precedenti e permette un rollback istantaneo, questa è la tua leva più rapida e sicura), disabilitare la feature rotta, o nel caso estremo di scrittura distruttiva, tagliare l'accesso a livello di policy. Contenere NON è sistemare: è congelare il danno nel suo stato attuale per avere tempo di pensare.

Recuperare esige di distinguere DUE rollback che la gente confonde e che hanno rischi opposti. (1) Rollback di CODICE: tornare a un deploy/commit precedente. È economico, reversibile e quasi sempre sicuro — in Cloudflare Pages è immediato. Questa è la tua prima opzione. (2) Rollback di SCHEMA/DATI: revertire una migrazione o ripristinare dati. È PERICOLOSO e irreversibile: un `down` migration che fa `DROP COLUMN` cancella dati che forse erano solo corrotti, non persi. Regole: non eseguire mai un rollback di dati senza un backup/PITR confermato prima; preferisci una migrazione FORWARD che corregge (un nuovo `UPDATE` che ripara le righe sbagliate) a un `down` distruttivo; ogni migrazione di Supabase è versionata (`apply_migration`) proprio perché lo stato sia ricostruibile. Se il dubbio è 'rollback di codice o di dati', parti SEMPRE da quello di codice: spesso basta e non tocca il DB.

Il post-mortem è dove l'incidente paga il suo debito trasformandosi in apprendimento. È SENZA COLPA (blameless): l'obiettivo non è chi ha rotto, ma cosa del SISTEMA ha permesso a un umano normale di rompere. Struttura: timeline (cosa è successo e quando, minuto per minuto), impatto (a quanti utenti, quali dati, per quanto tempo), causa radice (i '5 perché' fino ad arrivare al guasto di sistema, non di persona), e azioni correttive con responsabile e data. Ogni incidente deve produrre almeno un controllo che lo avrebbe PREVENUTO o RILEVATO prima — un test, un advisor in CI, un alert. Se il post-mortem non cambia nulla del sistema, non era un post-mortem, era una confessione.

Ancora il runbook alla realtà di ogni progetto, perché la gravità e le leve cambiano. In XCAP esiste un'invariante di capitale sacra — il capitale si accumula tra sessioni e si muove solo nei chiusi realizzati, mai si resetta. Un incidente che tocchi quell'invariante NON si sistema con un rollback di dati alla cieca: cancelleresti storia contabile reale. Lì il runbook obbliga a correzione forward e verifica dell'invariante prima di toccare qualsiasi cosa. In Espejo, multi-tenant, un incidente ha una domanda in più nella fase di rilevazione: il guasto ha attraversato la frontiera tra tenant? Se un bug ha esposto dati di un tenant a un altro, oltre al rollback c'è obbligo di contenimento della fuga. Il runbook generico ti dà la spina dorsale; gli invarianti di ogni progetto ti danno le regole che NON violi MAI durante il panico.

Parti dal fatto concreto: l'istanza `wuchsslgbqlhyxljsmxi` ospita DUE prodotti. MOONKEY usa `profiles, progress, feedback, leads, proofs`. XHUB IRON usa `iron_*, world_*, focus_*, daily_focus_history`. Condividono lo stesso Postgres, lo stesso `auth.users`, e — punto chiave — la STESSA anon key si usa per parlare con il DB. Questo significa che il client pubblico di MOONKEY tecnicamente PUÒ provare `from('iron_command').select('*')`. L'unica ragione per cui non funziona deve essere una barriera dura nel DB, non la nota del CLAUDE.md che dice 'non toccarle'. Quella nota protegge dal fatto che TU le modifichi per errore scrivendo codice; non protegge da un attaccante che ha già la tua anon key.

Capisci i livelli di isolamento dal più debole al più forte. (1) Convenzione (nomi `iron_*` vs senza prefisso): organizza, non isola — un attaccante ignora le convenzioni. (2) RLS per tabella: ogni tabella di XHUB deve avere policy che concedano accesso solo al proprio ruolo/utente; una tabella `iron_*` senza RLS o con una policy permissiva è una fuga diretta. (3) Schema separati: mettere XHUB nel proprio schema Postgres e NON esporlo nell'API di PostREST (il `db.schema` che Supabase pubblica) è una barriera più forte — ciò che non è nello schema esposto, il client nemmeno lo vede. (4) Ruoli/grant: REVOKE da `anon`/`authenticated` sulle tabelle/oggetti altrui. La difesa robusta IMPILA questi livelli; non fidarti di uno solo.

Per il caso MOONKEY↔XHUB, la domanda di verifica è diretta: un utente autenticato di MOONKEY può leggere una riga di `iron_*`? Confutalo (OS-03): autenticati come utente normale di MOONKEY ed esegui `supabase.from('iron_command').select('*')`. Il corretto è che restituisca errore di permesso o vuoto per via di RLS. Se restituisce dati, hai una fuga di isolamento critica. La memoria di progetto dice che la salute è computata e che il modello è 'open RLS, computed health' per l'HUB — questo significa che devi verificare ESPLICITAMENTE che 'open' per l'HUB non significhi 'aperto ai client di MOONKEY'. Isolamento tra progetti = ogni tabella risponde solo al suo proprietario legittimo, provato per impersonazione incrociata.

Il secondo asse è il multi-tenant DENTRO un progetto, ed è Espejo. Qui non sono due prodotti, sono N tenant (ogni influencer) nelle stesse tabelle. L'isolamento diventa per-riga: ogni riga porta un `tenant_id`, e la policy RLS esige che `tenant_id` coincida con il tenant del chiamante. L'attacco da confutare: il tenant A prova a leggere/scrivere righe con il `tenant_id` di B. La trappola classica è l'UPDATE senza WITH CHECK: USING limita quali righe A vede, ma senza WITH CHECK, A potrebbe riassegnare una riga a B o crearne una con `tenant_id` altrui. Un'altra trappola: una RPC SECURITY DEFINER che riceve `tenant_id` come parametro e non valida che coincida con `auth.uid()` — falla che attraversa tutti i tenant. L'isolamento multi-tenant è reale solo se OGNI policy di ogni operazione (SELECT/INSERT/UPDATE/DELETE) ancora il tenant all'identità del chiamante, non a un parametro che il client controlla.

Ci sono vettori di incrocio che non sono SELECT e che la gente dimentica. `auth.users` è condiviso: un utente è lo stesso in MOONKEY e in XHUB — assicurati che avere un account in uno non conceda ruoli nell'altro (in MOONKEY, `role` e `founder_badge` sono immutabili per i non-admin proprio perché registrarsi non scali privilegi incrociati). Le RPC e le funzioni SECURITY DEFINER sono oggetti globali: una funzione di XHUB eseguibile da `authenticated` è invocabile dal client di MOONKEY — restringila per ruolo o valida il contesto al suo interno. Trigger e sequenze condivise, viste che fanno JOIN tra tabelle di entrambi i prodotti, e `get_advisors` che segnala RLS mancante in qualsiasi tabella del progetto: tutto questo è superficie di incrocio. L'isolamento non è una policy, è una proprietà del sistema intero.

Chiudi con la disciplina operativa che mantiene vivo l'isolamento nel tempo. Ogni cambio di schema entra come migrazione versionata (`apply_migration`), mai come modifica manuale nel pannello — così lo stato di sicurezza è ricostruibile e verificabile. Dopo ogni migrazione che tocchi tabelle o policy, esegui `get_advisors` per cacciare RLS disattivato o policy permissive introdotte senza volerlo. E mantieni un test di isolamento come parte del runbook: uno script che, come utente di MOONKEY, prova a leggere ogni prefisso altrui (`iron_*`, `world_*`) e fa fallire il build se qualcuno restituisce righe. L'isolamento tra progetti non si 'configura una volta'; si ri-verifica a ogni cambio, perché una migrazione innocente può aprire una porta che era chiusa da mesi.

I tre flussi di un sistema vivo. Log = il diario di cosa accade (richieste, query, auth). Errori = ciò che si rompe in silenzio dal lato client, dove i tuoi log di server non arrivano. Costo = il contatore che corre anche se nessuno usa il sistema. Sono tre tubature distinte con tre strumenti distinti; confonderle è il motivo per cui la gente crede di stare monitorando e non lo fa.

L'osservabilità in una SSG non è la stessa cosa che in un server. MOONKEY è statico: NON c'è un handler server-side dove mettere un logger. La tua telemetria vive in tre posti estranei al tuo HTML: (1) Cloudflare Pages Analytics (request, banda, errori di edge), (2) i log di Supabase (Dashboard → Logs: API, Postgres, Auth — ogni query che passa per PostREST e ogni login lascia traccia), e (3) il browser dell'utente (errori di JS che solo tu non vedi). Accettalo: in una SSG, gran parte di ciò che fallisce avviene su una macchina che non controlli.

Cosa sorvegliare davvero, non tutto. La tentazione è loggare tutto e non leggere niente. Definisci una manciata di segnali che contano: tasso di errore 4xx/5xx all'edge (un picco di 401/403 = RLS che rifiuta o un attaccante che prova), errori di Auth in Supabase (tentativi falliti di magic-link), latenza delle query lente (Supabase segna quelle che tardano), e volume di righe lette (una query senza filtro che di colpo restituisce 10.000 righe è un bug di costo). Una metrica che non innesca nessuna decisione è rumore; cancellala.

Error tracking dal lato client: il punto cieco. In un sito statico, un TypeError nel tuo JS rompe l'esperienza dell'utente e a te non arriva NULLA — né log di server né alert. Devi catturare gli errori nel browser e mandarli fuori. Il minimo onesto: un window.addEventListener('error', ...) e ('unhandledrejection', ...) che faccia un fetch a un endpoint tuo (una Edge Function di Supabase che inserisce in una tabella di log con RLS di solo-insert). Il robusto: Sentry o simili con il suo SDK gratuito fino a un certo volume. La regola: se non catturi gli errori di client, stai operando alla cieca sulla metà del tuo sistema.

Il costo reale di operare, scomposto. Il free tier di Supabase ha tetti concreti che, una volta superati, o ti tagliano o ti addebitano: righe di DB, banda di egresso, storage, Monthly Active Users di Auth, e invocazioni di Edge Functions. Cloudflare Pages è generoso ma ha limiti di build/mese e di request nelle funzioni. E la spesa che più scala e meno si vede: i token di IA. Ogni chiamata all'API di Claude si fattura per token di input e di output, con tariffe diverse; un prompt con un CLAUDE.md gigantesco o un loop di agente senza tetto può moltiplicare il costo senza che cambi 'ciò che fa' la app. L'operatore conosce le sue tre fatture: DB, edge e token.

Perché arrivano le fatture a sorpresa, e come non riceverle. Tre cause classiche: (1) un endpoint o Edge Function senza rate-limit che qualcuno scopre e martella — uso = denaro; (2) una query senza LIMIT né indice che scansiona tutta la tabella a ogni caricamento; (3) un loop di agente IA senza tetto di token né di iterazioni (l'invariante di capitale di XCAP esiste in parte per questo: loop che accumulano apprendimento, non costo). La difesa non è sorvegliare la fattura a fine mese, è mettere i freni PRIMA: budget con alert al 50/80/100%, limiti duri dove la piattaforma li offre, e tetti espliciti di max_tokens e di iterazioni in ogni chiamata di IA.

Alertare su ciò che conta, senza fatica da alert. Un alert che scatta ogni ora viene ignorato nel giro di una settimana. Il criterio: alerta solo ciò che è azionabile e urgente. Buono: 'la spesa del mese ha superato l'80% del budget', 'il tasso di 5xx è passato dell'1%', 'errori di client > X in 10 min'. Cattivo: 'c'è stata una richiesta'. Configura i budget alert che già ti danno Supabase, Cloudflare e la console di Anthropic — sono gratuiti e sono la tua prima linea. Ogni alert deve rispondere a 'cosa faccio quando scatta'; se non c'è un'azione, non è un alert, è ansia.

Chiudere il loop con la risposta agli incidenti (OS-04). Osservare senza un piano di reazione è solo guardare bruciare. Il pannello e gli alert di questo modulo sono i sensori; il rollback e l'incident response di OS-04 sono gli attuatori. Un sistema ben operato collega i due: l'alert ti sveglia, i log ti dicono cosa è successo, e il piano di risposta ti dice cosa fare. Osservabilità + costo + risposta = operare davvero, non pregare.