Ops & Security

Empieza por la regla mental que nunca falla: todo lo que compila en un sitio estático es público. MOONKEY LAB es Astro 4 en modo SSG — el build genera HTML+JS plano que se sirve desde Cloudflare Pages. No hay servidor que guarde secretos en runtime. Cualquier string que importes en un componente .astro que llegue al cliente acaba, literalmente, en un archivo que cualquiera descarga con `view-source` o abriendo DevTools → Sources. Por eso `src/lib/supabase.ts` SOLO contiene la anon key. La anon key está DISEÑADA para ser pública: es un identificador de proyecto + un token con permisos de rol `anon`, cuya autoridad real la limita Postgres RLS. No es un secreto; es una dirección con un portero.

Ahora el contraste que tienes que interiorizar. Hay dos claves Supabase con el mismo aspecto (un JWT largo) pero universos opuestos de poder. La `anon` key opera bajo el rol `anon`/`authenticated` y está SOMETIDA a RLS: ve solo lo que las policies permiten. La `service_role` key opera con `BYPASSRLS`: ignora todas las policies, lee y escribe cualquier fila de cualquier tabla — incluidas las de XHUB IRON (`iron_*`, `world_*`) que comparten la misma instancia `wuchsslgbqlhyxljsmxi`. Si la `service_role` aparece en el cliente, un atacante no solo compromete MOONKEY: pivota a todos los proyectos que viven en esa DB. Regla dura: la `service_role` NUNCA entra en un repo de frontend, ni en un `.astro`, ni en un `import.meta.env.PUBLIC_*`. Su sitio es un backend con sesión (una Edge Function, un proceso server) o tu llavero local — nunca el bundle.

El vector de fuga más común no es pegar la clave en el código: es el prefijo de variable de entorno. En Astro, `import.meta.env.PUBLIC_X` se INLINEA en el bundle del cliente en build-time; `import.meta.env.X` (sin `PUBLIC_`) solo existe en contexto server/build y NO se expone. Vite/Astro hacen esto por diseño. El error clásico: nombrar `PUBLIC_SUPABASE_SERVICE_KEY` 'para que el componente la vea'. Lo logras — y se la regalas al mundo. Tu árbol de decisión para nombrar una env var: ¿esta clave puede ser pública? Sí → `PUBLIC_`. No → sin prefijo, y además pregúntate qué hace en un proyecto SSG (probablemente no debería estar ahí).

Construye el inventario. Abre tu proyecto y clasifica cada credencial en una tabla de tres columnas: nombre · clase (pública/privada) · dónde vive hoy. En MOONKEY las entradas reales son: `PUBLIC_SUPABASE_URL` (pública, identificador), `PUBLIC_SUPABASE_ANON_KEY` (pública, limitada por RLS), y la `service_role` (privada — NO debe existir en este repo en absoluto; si la necesitas para un script de migración, vive en tu shell local o en un secret de CI, jamás en `src/`). Añade cualquier token de terceros que toques: claves de email transaccional, webhooks, tokens de analytics server-side. Cada fila privada que esté en el lado equivocado es un incidente esperando a pasar.

El control que cierra el ciclo es la detección automática, porque la disciplina humana falla. Antes de cada commit quieres que algo grite si una clave privada se cuela. El patrón mínimo: un grep en pre-commit que busque el patrón de una `service_role` (los JWT de Supabase service llevan `"role":"service_role"` en el payload base64) y palabras como `service_role`, `BEGIN PRIVATE KEY`, `sk-`. Para los repos reales usa `gitleaks` o `trufflehog` como hook. Y si una clave YA se filtró en un commit pasado: no basta con borrarla del código — sigue en el historial de git. Hay que ROTARLA en el panel de Supabase (Settings → API → roll key) y reescribir historial si era un secreto duro. Rotar es obligatorio; borrar el archivo no revoca nada.

Cierra con el caso Espejo, que añade un eje ético, no solo técnico. Espejo es multi-tenant: cada influencer-tenant tiene sus datos. Ahí la pregunta 'pública vs privada' se duplica: además de claves de infraestructura, manejas datos personales/consentidos de usuarios finales. La clave de servicio que pudiera leer ACROSS tenants es el secreto más sensible del producto — su fuga no es solo técnica, viola la frontera de datos que la memoria de proyecto marca como innegociable. Lección transversal: una credencial privada no se define por su formato, se define por lo que desbloquea. Mídela siempre por su blast radius.

Adopta el marco mental correcto: en una SSG, el cliente no es tu aplicación, es territorio enemigo. El atacante tiene tu bundle completo (es público), tu `PUBLIC_SUPABASE_URL`, tu anon key, y conocimiento de que detrás hay Postgres. No necesita 'hackear' tu JavaScript: lo lee. Puede instanciar su propio cliente Supabase con TU anon key desde una consola de Node y hablar directo con tu DB, sin pasar jamás por tu HTML. Por tanto, toda lógica de seguridad que viva en `.astro` o en JS de cliente — un `if (user.role === 'admin')`, un componente que se oculta — es UX, no seguridad. CLAUDE.md de MOONKEY lo dice literal: `admin.astro` es UX; la seguridad NO depende de ese gate.

Enumera la superficie de ataque concreta. Para MOONKEY hay cinco tablas alcanzables con la anon key: `profiles, progress, feedback, leads, proofs`. El atacante, con un cliente autenticado vía magic-link (cualquiera puede registrarse), intentará lo evidente: `supabase.from('profiles').select('*')` para volcar TODOS los perfiles; `supabase.from('leads').select('*')` para robar la lista de leads; un `update` sobre su propia fila de `profiles` poniendo `role = 'admin'` o `founder_badge = true` para auto-escalar; un `insert` en `proofs` con `user_id` ajeno para falsear progreso de otro. Cada una de estas es una hipótesis de ataque que TÚ debes refutar con una policy. Si no la has refutado explícitamente, asume que funciona.

Entiende por qué RLS es la autoridad y cómo se compone la defensa real de MOONKEY. SELECT en `profiles/progress/feedback/proofs` es self-or-admin: la policy permite la fila solo si `user_id = auth.uid()` O `is_admin()`. `is_admin()` es SECURITY DEFINER — corre con los permisos del dueño, consulta si el llamante es admin sin que el llamante pueda manipular esa decisión. Resultado: un no-admin que pide `select('*')` no recibe un error, recibe SUS filas y nada más — el dump masivo devuelve una sola fila, la suya. La escalada de privilegios la corta un trigger (`guard_privileged_profile_columns`): `role` y `founder_badge` son inmutables para no-admins, así que el `update role='admin'` se rechaza a nivel de DB. El insert ajeno lo corta `proofs_insert_self`: exige sesión y liga `user_id = auth.uid()`.

La consecuencia operativa del modelo: verifica por impersonación, no por lectura de código. Una policy que 'parece' correcta puede tener un agujero (un OR mal puesto, un USING sin WITH CHECK que deja pasar updates). La única prueba que vale es ponerte en los zapatos del atacante: autentícate como un usuario normal y EJECUTA los ataques enumerados arriba contra la DB real, confirmando que cada uno devuelve vacío o error. CLAUDE.md menciona que el aislamiento de lectura está 'verificado por impersonación' — ese es el estándar. 'Escribí la policy' no es evidencia; 'intenté el ataque como usuario X y no leyó la fila de usuario Y' sí lo es.

No olvides los vectores que no son RLS. El modelo de amenaza de una SSG incluye también: (a) la diferencia USING vs WITH CHECK — USING filtra qué filas ves/afectas, WITH CHECK valida el estado resultante de un INSERT/UPDATE; olvidar WITH CHECK en un UPDATE deja que muevas una fila a un user_id ajeno. (b) Las RPC: una función SECURITY DEFINER mal escrita es un boquete que ignora RLS por diseño — MOONKEY las restringe a `authenticated` y revoca operaciones peligrosas. (c) TRUNCATE: revocado de anon/authenticated, porque RLS no protege contra TRUNCATE (borra la tabla entera sin evaluar policies por fila). (d) Fuga por errores y por columnas: un SELECT que devuelve una columna sensible que olvidaste excluir.

Aterriza con el contraste de proyectos para fijar el principio. XNLAB es un sitio de marca casi sin backend: su superficie es mínima — formularios de contacto, cabeceras, quizá un endpoint de captación. Ahí el modelo de amenaza es 'spam y XSS en lo poco que acepta input', no escalada de DB. XHUB IRON vive en la MISMA DB que MOONKEY pero es un panel operativo del fundador: sus tablas `iron_*` no deben ser legibles por un usuario de MOONKEY — el mismo motor RLS tiene que mantener DOS productos que comparten Postgres sin que uno lea al otro (eso es OS-05). El modelo de amenaza no es genérico: se deriva de QUÉ datos hay, QUIÉN puede autenticarse, y QUÉ comparten la infraestructura. Empieza siempre por inventariar esos tres ejes.

El principio rector es popperiano: un hallazgo de seguridad no es verdadero porque lo afirmes, es verdadero porque INTENTASTE refutarlo y no pudiste. Invierte el flujo natural. Cuando crees haber encontrado una vulnerabilidad ('cualquiera puede leer `leads`'), tu siguiente paso no es reportarla — es intentar demostrar que estás equivocado: ¿hay una policy que lo impide? ¿la probé como el rol correcto? ¿el `select` devolvió datos reales o vacío? Solo cuando tu intento de refutación falla, el hallazgo asciende a confirmado. Y al revés: cuando crees que algo es seguro ('la policy self-or-admin protege `profiles`'), tu trabajo es atacarlo hasta que se rompa o sobreviva.

Define los dos errores que persigues con nombres claros. Falso positivo: reportas una vulnerabilidad que no existe — p.ej. gritas 'la anon key está expuesta en el bundle' cuando la anon key es pública por diseño y la DB está protegida por RLS (ver OS-01). Quemas confianza; la próxima vez nadie te cree. Falso negativo: das por seguro algo que no lo es — p.ej. 'el panel admin está oculto, estamos bien' sin probar el acceso directo a la DB. Dejas la brecha abierta. La auditoría adversarial existe para minimizar AMBOS, y la herramienta para ambos es la misma: la prueba ejecutable.

El método concreto: por cada hallazgo, produce una prueba reproducible, no una afirmación. 'Reproducible' significa: un comando o snippet que cualquiera puede correr y ver el mismo resultado. Para confirmar que `profiles` NO se puede dumpear: un script que se autentica como user_A, hace `.from('profiles').select('*')`, e imprime el conteo de filas — esperado 1 (solo la suya). Para confirmar que la escalada de privilegios está cerrada: como user_A, `.from('profiles').update({ role: 'admin' }).eq('id', myId)` e imprimir el error que devuelve el trigger guard. Si el ataque devuelve lo que esperabas (vacío/error), el control está verificado. Si devuelve datos, tienes un hallazgo REAL — y ya viene con su PoC adjunto.

Trabaja con la herramienta del propio Supabase pero sin rendirte a ella. `get_advisors` (security lints) te señala tablas sin RLS, policies permisivas, funciones SECURITY DEFINER sin search_path fijo. Trátalo como generador de HIPÓTESIS, no de veredictos. Un advisor que dice 'función X es SECURITY DEFINER mutable search_path' es una hipótesis de riesgo: ve a la función, mira si un atacante puede plantar un objeto en un schema que ella resuelva primero. A veces es explotable, a veces no por el contexto. El advisor te ahorra el barrido inicial; la refutación la haces tú. CLAUDE.md ya lo institucionaliza: cambios de RLS = migración versionada + `get_advisors` después. Esa segunda parte es la auditoría adversarial hecha rutina.

Cuida los falsos negativos del propio método: el ataque que 'pasa' puede pasar por la razón equivocada. Si tu `select('*')` sobre `profiles` devuelve vacío, ¿es porque RLS lo bloqueó, o porque tu sesión de prueba caducó / no estabas autenticado / la tabla estaba vacía? Un control nunca se da por bueno sin un caso de CONTRASTE: prueba que el mismo query SÍ devuelve datos cuando debe (como admin, o como el dueño de la fila). Una prueba de seguridad sin su control positivo es un falso negativo disfrazado de éxito. Siempre verifica que tu arma funciona antes de concluir que el blanco es inmune.

Aterriza el rigor en los proyectos donde más duele equivocarse. En XCAP la auditoría adversarial es doctrina central: la memoria del proyecto lo describe como 'anti-fabricación por construcción' — un sistema que registra forecasts y los calibra contra resultados reales, refutando sus propias predicciones en vez de creérselas. Ese mismo músculo aplicas a seguridad: no firmes 'el ledger es read-only' hasta que un intento de escritura con la credencial de ingest falle ante tus ojos. En Espejo, donde la frontera de datos personales es ética además de técnica, una auditoría que dice 'no hay fuga entre tenants' sin un PoC de un tenant intentando leer a otro NO es una auditoría: es un deseo. Refutar primero, siempre, especialmente cuando el resultado que esperas es el cómodo.

Interioriza la secuencia DCRP: Detectar → Contener → Recuperar (rollback) → Post-mortem. El error de la mayoría es saltar directo a 'arreglar', tocando producción a ciegas. El orden importa porque cada fase protege a la siguiente: si no detectas bien, contienes lo que no es; si no contienes, el daño crece mientras recuperas; si recuperas sin entender, repites el incidente. Y la regla cero, escrita en cualquier runbook serio: en un incidente NO improvisas sobre producción. Ejecutas pasos predefinidos. La creatividad es para el post-mortem, no para las 3am con el sitio caído.

Detectar es saber QUÉ está roto y desde CUÁNDO. En MOONKEY (Cloudflare Pages + Supabase) tus señales son: el deploy de Cloudflare (¿qué commit está live? ¿el último build pasó?), los logs de Supabase (`get_logs` por servicio: api, postgres, auth — ahí ves errores de policy, queries fallando, picos de 4xx/5xx), y la queja del usuario (a menudo la primera señal). Lo primero que estableces es la línea de tiempo: ¿qué cambió justo antes? Casi siempre el incidente correlaciona con un deploy o una migración reciente. 'Empezó tras el merge de las 16:20' acota el espacio de búsqueda de horas a minutos.

Contener es detener el sangrado antes de curar la herida. Pregunta clave: ¿esto está corrompiendo datos AHORA mismo? Si un bug está escribiendo filas malas en `proofs` o `progress`, cada minuto que tardas multiplica el cleanup. Opciones de contención según severidad: revertir el deploy de Cloudflare al anterior (un click — Cloudflare Pages guarda deploys previos y permite rollback instantáneo, esta es tu palanca más rápida y segura), deshabilitar la feature rota, o en el caso extremo de escritura destructiva, cortar el acceso a nivel de policy. Contener NO es arreglar: es congelar el daño en su estado actual para tener tiempo de pensar.

Recuperar exige distinguir DOS rollbacks que la gente confunde y que tienen riesgos opuestos. (1) Rollback de CÓDIGO: volver a un deploy/commit anterior. Es barato, reversible y casi siempre seguro — en Cloudflare Pages es inmediato. Esta es tu primera opción. (2) Rollback de SCHEMA/DATOS: revertir una migración o restaurar datos. Es PELIGROSO e irreversible: un `down` migration que hace `DROP COLUMN` borra datos que quizá solo estaban corruptos, no perdidos. Reglas: nunca corras un rollback de datos sin un backup/PITR confirmado primero; prefiere una migración FORWARD que corrija (un nuevo `UPDATE` que repara las filas malas) sobre un `down` destructivo; toda migración de Supabase es versionada (`apply_migration`) precisamente para que el estado sea reconstruible. Si la duda es 'rollback de código o de datos', empieza SIEMPRE por el de código: a menudo basta y no toca la DB.

El post-mortem es donde el incidente paga su deuda convirtiéndose en aprendizaje. Es SIN CULPA (blameless): el objetivo no es quién rompió, sino qué del SISTEMA permitió que un humano normal rompiera. Estructura: timeline (qué pasó y cuándo, minuto a minuto), impacto (a cuántos usuarios, qué datos, cuánto tiempo), causa raíz (los '5 por qués' hasta llegar al fallo de sistema, no de persona), y acciones correctivas con dueño y fecha. Cada incidente debe producir al menos un control que lo habría PREVENIDO o DETECTADO antes — un test, un advisor en CI, una alerta. Si el post-mortem no cambia nada del sistema, no fue un post-mortem, fue una confesión.

Ancla el runbook en la realidad de cada proyecto, porque la severidad y las palancas cambian. En XCAP existe una invariante de capital sagrada — el capital se acumula entre sesiones y solo se mueve en cierres realizados, nunca se resetea. Un incidente que toque esa invariante NO se arregla con un rollback de datos a ciegas: borrarías historia contable real. Ahí el runbook obliga a corrección forward y verificación de la invariante antes de tocar nada. En Espejo, multi-tenant, un incidente tiene una pregunta extra en la fase de detección: ¿el fallo cruzó la frontera entre tenants? Si un bug expuso datos de un tenant a otro, además del rollback hay obligación de contención de la fuga. El runbook genérico te da la espina dorsal; los invariantes de cada proyecto te dan las reglas que NUNCA violas durante el pánico.

Parte del hecho concreto: la instancia `wuchsslgbqlhyxljsmxi` aloja DOS productos. MOONKEY usa `profiles, progress, feedback, leads, proofs`. XHUB IRON usa `iron_*, world_*, focus_*, daily_focus_history`. Comparten el mismo Postgres, el mismo `auth.users`, y — clave — la MISMA anon key se usa para hablar con la DB. Esto significa que el cliente público de MOONKEY técnicamente PUEDE intentar `from('iron_command').select('*')`. La única razón de que no funcione tiene que ser una barrera dura en la DB, no la nota de CLAUDE.md que dice 'no las toques'. Esa nota protege contra que TÚ las edites por error escribiendo código; no protege contra un atacante que ya tiene tu anon key.

Entiende las capas de aislamiento de menor a mayor fuerza. (1) Convención (nombres `iron_*` vs sin prefijo): organiza, no aísla — un atacante ignora convenciones. (2) RLS por tabla: cada tabla de XHUB debe tener policies que solo concedan acceso a su propio rol/usuario; una tabla `iron_*` sin RLS o con una policy permisiva es una fuga directa. (3) Schemas separados: poner XHUB en su propio schema Postgres y NO exponerlo en la API de PostgREST (la `db.schema` que Supabase publica) es una barrera más fuerte — lo que no está en el schema expuesto, el cliente ni lo ve. (4) Roles/grants: REVOKE de `anon`/`authenticated` sobre las tablas/objetos ajenos. La defensa robusta APILA estas capas; no confíes en una sola.

Para el caso MOONKEY↔XHUB, la pregunta de auditoría es directa: ¿puede un usuario autenticado de MOONKEY leer una fila de `iron_*`? Refútalo (OS-03): autentícate como user normal de MOONKEY y ejecuta `supabase.from('iron_command').select('*')`. Lo correcto es que devuelva error de permiso o vacío por RLS. Si devuelve datos, tienes una fuga de aislamiento crítica. La memoria de proyecto dice que la salud se computa y que el modelo es 'open RLS, computed health' para el HUB — eso significa que debes verificar EXPLÍCITAMENTE que 'open' para el HUB no significa 'abierto a clientes de MOONKEY'. Aislamiento entre proyectos = cada tabla solo responde a su dueño legítimo, probado por impersonación cruzada.

El segundo eje es el multi-tenant DENTRO de un proyecto, que es Espejo. Aquí no son dos productos, son N tenants (cada influencer) en las mismas tablas. El aislamiento se vuelve por-fila: cada fila lleva un `tenant_id`, y la policy RLS exige que `tenant_id` coincida con el tenant del llamante. El ataque a refutar: el tenant A intenta leer/escribir filas con el `tenant_id` de B. La trampa clásica es el UPDATE sin WITH CHECK: USING limita qué filas A ve, pero sin WITH CHECK, A podría reasignar una fila a B o crear una con `tenant_id` ajeno. Otra trampa: una RPC SECURITY DEFINER que recibe `tenant_id` como parámetro y no valida que coincide con `auth.uid()` — boquete que cruza todos los tenants. El aislamiento multi-tenant solo es real si CADA policy de cada operación (SELECT/INSERT/UPDATE/DELETE) ancla el tenant al identidad del llamante, no a un parámetro que el cliente controla.

Hay vectores de cruce que no son SELECT y que la gente olvida. `auth.users` es compartido: un usuario es el mismo en MOONKEY y en XHUB — asegúrate de que tener cuenta en uno no concede roles en el otro (en MOONKEY, `role` y `founder_badge` son inmutables para no-admins precisamente para que registrarse no escale privilegios cruzados). Las RPC y funciones SECURITY DEFINER son objetos globales: una función de XHUB ejecutable por `authenticated` es invocable desde el cliente de MOONKEY — restríngela por rol o valida el contexto dentro. Triggers y secuencias compartidas, vistas que hacen JOIN entre tablas de ambos productos, y `get_advisors` que señala RLS faltante en cualquier tabla del proyecto: todo eso es superficie de cruce. El aislamiento no es una policy, es una propiedad del sistema entero.

Cierra con la disciplina operativa que mantiene el aislamiento vivo en el tiempo. Cada cambio de schema entra como migración versionada (`apply_migration`), nunca como edición manual en el panel — así el estado de seguridad es reconstruible y auditable. Tras cada migración que toque tablas o policies, corre `get_advisors` para cazar RLS desactivado o policies permisivas introducidas sin querer. Y mantén un test de aislamiento como parte del runbook: un script que, como usuario de MOONKEY, intenta leer cada prefijo ajeno (`iron_*`, `world_*`) y falla el build si alguno devuelve filas. El aislamiento entre proyectos no se 'configura una vez'; se re-verifica en cada cambio, porque una migración inocente puede abrir una puerta que llevaba meses cerrada.

Los tres flujos de un sistema vivo. Logs = el diario de qué ocurre (peticiones, queries, auth). Errores = lo que se rompe en silencio del lado del cliente, donde tus logs de servidor no llegan. Coste = el contador que corre aunque nadie use el sistema. Son tres tuberías distintas con tres herramientas distintas; confundirlas es por qué la gente cree estar monitorizando y no lo está.

Observabilidad en una SSG no es lo mismo que en un servidor. MOONKEY es estático: NO hay handler server-side donde poner un logger. Tu telemetría vive en tres sitios ajenos a tu HTML: (1) Cloudflare Pages Analytics (requests, ancho de banda, errores de edge), (2) los logs de Supabase (Dashboard → Logs: API, Postgres, Auth — cada query que pasa por PostgREST y cada login deja rastro), y (3) el navegador del usuario (errores de JS que solo tú no ves). Acéptalo: en una SSG, gran parte de lo que falla ocurre en una máquina que no controlas.

Qué vigilar de verdad, no todo. La tentación es loguearlo todo y no leer nada. Define un puñado de señales que importan: tasa de error 4xx/5xx en el edge (un pico de 401/403 = RLS rechazando o un atacante probando), errores de Auth en Supabase (intentos fallidos de magic-link), latencia de las queries lentas (Supabase marca las que tardan), y volumen de filas leídas (una query sin filtro que de pronto devuelve 10.000 filas es un bug de coste). Una métrica que no dispara ninguna decisión es ruido; bórrala.

Error tracking del lado del cliente: el punto ciego. En un sitio estático, un TypeError en tu JS rompe la experiencia del usuario y a ti no te llega NADA — ni log de servidor ni alerta. Necesitas capturar errores en el navegador y mandarlos fuera. Lo mínimo honesto: un window.addEventListener('error', ...) y ('unhandledrejection', ...) que haga un fetch a un endpoint propio (una Edge Function de Supabase que inserta en una tabla de logs con RLS de solo-insert). Lo robusto: Sentry o similar con su SDK gratuito hasta cierto volumen. La regla: si no capturas errores de cliente, estás operando a ciegas en la mitad de tu sistema.

El coste real de operar, desglosado. Supabase free tier tiene techos concretos que, al cruzarlos, o te cortan o te cobran: filas de DB, ancho de banda de egreso, almacenamiento, Monthly Active Users de Auth, e invocaciones de Edge Functions. Cloudflare Pages es generoso pero tiene límites de builds/mes y de requests en funciones. Y el gasto que más escala y menos se ve: los tokens de IA. Cada llamada a la API de Claude se factura por tokens de entrada y de salida, con tarifas distintas; un prompt con un CLAUDE.md gigante o un bucle de agente sin tope puede multiplicar el coste sin que cambie 'lo que hace' la app. El operador conoce sus tres facturas: DB, edge y tokens.

Por qué llegan las facturas sorpresa, y cómo no recibirlas. Tres causas clásicas: (1) un endpoint o Edge Function sin rate-limit que alguien descubre y martillea — uso = dinero; (2) una query sin LÍMITE ni índice que escanea toda la tabla en cada carga; (3) un loop de agente IA sin tope de tokens ni de iteraciones (el XCAP capital invariant existe en parte por esto: bucles que acumulan aprendizaje, no coste). La defensa no es vigilar la factura a fin de mes, es poner los frenos ANTES: presupuestos con alerta al 50/80/100%, límites duros donde la plataforma los ofrezca, y techos explícitos de max_tokens y de iteraciones en cada llamada de IA.

Alertar sobre lo que importa, sin fatiga de alertas. Una alerta que salta cada hora se ignora a la semana. El criterio: alerta solo lo accionable y lo urgente. Bueno: 'el gasto del mes superó el 80% del presupuesto', 'la tasa de 5xx pasó del 1%', 'errores de cliente > X en 10 min'. Malo: 'hubo una petición'. Configura los budget alerts que ya te dan Supabase, Cloudflare y la consola de Anthropic — son gratis y son tu primera línea. Cada alerta debe responder a 'qué hago cuando salta'; si no hay acción, no es una alerta, es ansiedad.

Cerrar el bucle con la respuesta a incidentes (OS-04). Observar sin un plan de reacción es solo mirar arder. El panel y las alertas de este módulo son los sensores; el rollback y el incident response de OS-04 son los actuadores. Un sistema bien operado conecta los dos: la alerta te despierta, los logs te dicen qué pasó, y el plan de respuesta te dice qué hacer. Observabilidad + coste + respuesta = operar de verdad, no rezar.