Data & Systems

Postgres no es "una hoja de cálculo con SQL". Es un motor relacional con un sistema de tipos serio, y tu primer trabajo como operador de datos es usar ese sistema de tipos para que estados imposibles sean literalmente irrepresentables. Antes de escribir un solo CREATE TABLE, enumera las entidades del dominio y las relaciones entre ellas. En MOONKEY LAB las entidades reales son: un usuario (profiles), su avance por módulo (progress), las pruebas que sube (proofs), el feedback que deja (feedback) y los leads de captación. Cada una es una tabla. Cada relación 1-a-N entre ellas es una foreign key. No empieces por las columnas; empieza por las flechas entre cajas.

El identificador. En Supabase la tabla profiles cuelga de auth.users, así que su clave primaria NO es un id autogenerado nuevo: es `id uuid primary key references auth.users(id) on delete cascade`. Esto es el patrón canónico de Supabase y es deliberado — el uuid del usuario autenticado ES la identidad en toda tu app, y `auth.uid()` (que usarás en cada policy RLS) devuelve exactamente ese uuid. Para tablas hijas como progress o proofs sí usas una clave propia: `id uuid primary key default gen_random_uuid()`, más una columna `user_id uuid not null references auth.users(id) on delete cascade`. Fíjate en `not null` y en `on delete cascade`: si borras un usuario, sus pruebas se van con él; si permitieras user_id nulo, tendrías filas huérfanas que ninguna policy `user_id = auth.uid()` podría ni mostrar ni proteger.

Los tipos importan y son baratos de acertar al principio. Para timestamps usa SIEMPRE `timestamptz` (with time zone), nunca `timestamp` a secas — un proyecto con usuarios en Chiang Mai, Mallorca y Madrid no puede permitirse ambigüedad de zona horaria, y `timestamptz` guarda en UTC y convierte en la frontera. Para dinero, `numeric`, jamás `float` (los flotantes binarios no representan 0.10 exacto). Para un campo con un conjunto cerrado de valores —el rango del operador: monkey, gorilla, eagle— tienes dos opciones honestas: un `enum` de Postgres, o `text` con un `check (role in ('monkey','gorilla','eagle'))`. Prefiero el CHECK sobre el enum en proyectos jóvenes: añadir un valor a un enum requiere `ALTER TYPE` y tiene fricción transaccional, mientras que cambiar un CHECK es un ALTER de tabla ordinario. Para datos semiestructurados —el payload de una proof, metadatos flexibles— usa `jsonb`, no `json`: jsonb es binario, indexable con GIN y deduplica claves.

Defaults y NOT NULL son tu primera línea de validación, antes que cualquier RLS o cualquier check de la app. `created_at timestamptz not null default now()` significa que es imposible insertar una fila sin fecha. `status text not null default 'forming'` significa que el estado nunca es nulo y por tanto tu código nunca necesita ramas `if status is null`. Cada columna que dejas nullable es una rama condicional que pagas para siempre en el código que la lee. La regla: una columna es NOT NULL por defecto, y solo la haces nullable cuando la ausencia de valor es un estado de dominio legítimo y distinto de un valor vacío.

Unicidad e índices. La relación "un usuario tiene exactamente un registro de progreso por módulo" no es un comentario: es `unique (user_id, module_code)`. Esa restricción única además te da el índice que necesitas para el upsert (`insert ... on conflict (user_id, module_code) do update`), que es justo como MOONKEY persiste el avance. Aparte de las claves, crea índices sobre las columnas por las que filtras de verdad: si consultas proofs por `user_id` constantemente, `create index on proofs (user_id)`. Pero no índices por reflejo — cada índice ralentiza los INSERT y ocupa espacio; índexa lo que mides que se consulta, no lo que imaginas que se consultará.

Aplica el esquema como una migración versionada, nunca a mano en el editor SQL. En Supabase eso es `apply_migration` (un archivo .sql con nombre y timestamp), no `execute_sql` suelto. La diferencia es auditoría: dentro de seis meses querrás saber por qué proofs tiene esa columna, y la respuesta está en el historial de migraciones, no en tu memoria. Tras aplicar, corre `generate_typescript_types` para que el tipo de TypeScript del cliente derive del esquema real — así la DB es la fuente única de verdad y el front no puede mentir sobre la forma del dato.

Un ejemplo concreto y completo para proofs, la tabla donde un operador sube la prueba de que completó un entregable: una clave propia uuid, un user_id NOT NULL con FK y cascade, un module_code con CHECK contra la lista de códigos válidos, un payload jsonb, un created_at timestamptz NOT NULL default now(), y un índice por user_id. Ese diseño hace que (a) toda fila pertenezca a un usuario existente, (b) ninguna fila quede huérfana, (c) ningún module_code inventado entre, y (d) la consulta "mis pruebas" sea rápida. Sobre esa base —y solo sobre ella— tiene sentido poner RLS en el módulo siguiente.

Interioriza el modelo de amenaza antes de tocar una policy. En una SSG con Supabase, el atacante NO usa tu interfaz. Abre la consola del navegador, coge la anon key (que está en el bundle, porque tiene que estar), instancia su propio cliente Supabase y llama `supabase.from('profiles').select('*')`. Tu archivo admin.astro que "oculta" el panel no existe para él. El botón deshabilitado no existe para él. Lo único que se interpone entre su SELECT y todas las filas de todos los usuarios es la Row Level Security de Postgres. Por eso la frase del módulo: el gate del cliente es UX (mejora la experiencia del usuario legítimo), la RLS es la seguridad (detiene al ilegítimo).

RLS se activa por tabla y por defecto es deny-all. `alter table profiles enable row level security` — y en ese instante, sin ninguna policy, NADIE (salvo el rol de servicio y el dueño de la tabla) puede leer ni escribir nada. Esto es lo correcto: empiezas desde cero permisos y abres exactamente lo que necesitas. El error catastrófico es habilitar RLS y olvidar una operación: si pones policies de SELECT pero ninguna de INSERT, los INSERT fallan silenciosamente; peor, si NO habilitas RLS en una tabla nueva, está completamente abierta a la anon key. Por eso DS-06 introduce los advisors: detectan exactamente la tabla sin RLS que se te olvidó.

Una policy tiene dos cláusulas que confunde todo el mundo: USING y WITH CHECK. USING filtra qué filas existentes ve o toca la operación (SELECT, UPDATE, DELETE). WITH CHECK valida qué filas nuevas o modificadas se permiten escribir (INSERT, UPDATE). Para SELECT solo hay USING. Para INSERT solo hay WITH CHECK. Para UPDATE hay AMBAS: USING dice qué filas puedes actualizar, WITH CHECK dice en qué pueden convertirse. Un error clásico es poner USING en un INSERT y que no haga nada, o poner solo USING en un UPDATE y permitir que el usuario mueva su fila a otro user_id. El patrón self-or-admin de MOONKEY: `using (user_id = auth.uid() or is_admin())`.

El patrón canónico self. Para proofs, la policy de inserción real de MOONKEY es `proofs_insert_self`: `create policy proofs_insert_self on proofs for insert to authenticated with check (user_id = auth.uid())`. Léela en voz alta: un usuario autenticado puede insertar una proof solo si el user_id de la fila que inserta es igual a su propia identidad. No puede crear una proof a nombre de otro, porque WITH CHECK rechazaría cualquier fila con user_id ≠ auth.uid(). Fíjate en `to authenticated`: la policy ni siquiera aplica al rol anon, así que un visitante sin sesión no puede insertar nada. Para SELECT, el patrón self-or-admin: `using (id = auth.uid() or is_admin())` en profiles — ves tu fila, o todas si eres admin.

auth.uid() es el corazón del sistema y conviene saber qué es: una función SECURITY DEFINER de Supabase que extrae el `sub` del JWT que el cliente envía en cada petición. El cliente no puede falsificarlo porque el JWT está firmado por Supabase con un secreto que el cliente no tiene; manipularlo invalida la firma y Postgres rechaza la sesión. Por eso `user_id = auth.uid()` es confiable de un modo que `user_id = <valor que mandó el cliente>` jamás lo sería. La autoridad vive en la firma del token, no en la buena fe del front.

Verificación por impersonación — esto separa a un operador serio de uno que "cree" que su RLS funciona. No basta con leer la policy y asentir. En el editor SQL de Supabase puedes simular ser un usuario concreto fijando el rol y el claim: `set local role authenticated; set local request.jwt.claims to '{"sub":"<uuid-del-usuario-A>"}';` y entonces `select * from profiles`. Si ves filas de otros usuarios, tu RLS está rota. El modelo de seguridad de MOONKEY dice explícitamente "verificado por impersonación": un no-admin no puede leer filas ajenas, y eso se PROBÓ, no se asumió. Haz lo mismo: impersona al usuario A, intenta leer la fila del usuario B, y exige que el resultado sea cero filas.

Dos trampas finales. Primera: el rol `service_role` (la clave de servicio, NUNCA en el cliente) bypassa toda RLS — por eso jamás vive en una SSG y solo se usa en edge functions de confianza. Segunda: las policies son permisivas por defecto y se combinan con OR, no con AND. Si tienes dos policies de SELECT sobre la misma tabla, una fila visible para CUALQUIERA de las dos es visible. Esto sorprende: añadir una policy nunca restringe, solo amplía. Para restringir necesitas policies RESTRICTIVE explícitas, o —más simple y lo habitual— una sola policy bien escrita por operación.

Cómo funciona el magic-link, paso a paso. El cliente llama `supabase.auth.signInWithOtp({ email })`. Supabase genera un token de un solo uso, lo asocia al email y manda un correo con un enlace que apunta a tu app con ese token en el fragmento de URL. El usuario hace clic; tu app, al cargar, detecta el token, lo canjea con Supabase por un par access_token / refresh_token, y a partir de ahí el cliente está autenticado. El access_token es un JWT firmado con caducidad corta (por defecto una hora); el refresh_token es de larga duración y sirve para obtener nuevos access tokens sin que el usuario vuelva a hacer login. Todo esto lo orquesta el SDK; tu trabajo es entender el flujo, no reimplementarlo.

Dónde vive la sesión. Por defecto, el SDK de Supabase en el navegador persiste la sesión en localStorage. Esto tiene una consecuencia de seguridad que debes decir en voz alta: un token en localStorage es legible por cualquier JavaScript que corra en tu página. Eso significa que tu superficie de ataque número uno es el XSS — si un atacante consigue inyectar JS en tu sitio (un script de terceros comprometido, un innerHTML con input sin sanear), puede leer el token y robar la sesión. La defensa no es esconder el token; es no tener XSS: no metas HTML de usuario sin sanear, audita cada dependencia de front, y trata cada `<script>` de terceros como código que verá tus tokens.

La distinción honesta que da nombre al módulo: la sesión es identidad, no autorización. Que el cliente tenga un access_token válido prueba QUIÉN es (auth.uid() devolverá su uuid), pero NO le da permiso para nada por sí mismo. El permiso lo decide la RLS en cada query. Esto es liberador: no tienes que defender tus datos en el front. Aunque un atacante robe una sesión, solo puede hacer lo que la RLS permite a ESE usuario — ver sus propias filas, no las de otros. La sesión robada de un usuario normal no da acceso de admin, porque is_admin() revalida contra la fila de profiles, no contra una claim que el cliente pueda manipular.

Manejo de estado de sesión en la app. El SDK expone `supabase.auth.getSession()` (lee la sesión actual, posiblemente del localStorage) y `supabase.auth.onAuthStateChange((event, session) => ...)` (te notifica de SIGNED_IN, SIGNED_OUT, TOKEN_REFRESHED). En una SSG como MOONKEY no tienes server-side rendering del estado de auth, así que la página carga primero en estado "desconocido" y luego, en cliente, resuelves si hay sesión. Diseña para eso: muestra un estado neutro de carga, no parpadees entre "invitado" y "logueado". El gate visual (mostrar /cuenta solo si hay sesión) es UX legítima — recuerda DS-02: es UX, la seguridad sigue en la RLS.

El trigger que cierra el círculo. Cuando un usuario se registra por primera vez vía magic-link, Supabase crea una fila en auth.users. Pero tu app necesita una fila correspondiente en profiles. Eso NO lo hace el cliente (no debe poder elegir su propio role ni founder_badge). Lo hace un trigger SECURITY DEFINER en la base de datos: `handle_new_user`, que se dispara `after insert on auth.users` y crea la fila de profiles con valores por defecto seguros (role='monkey', nunca admin). Así la creación del perfil es autoritativa del servidor: el usuario no puede nacer admin porque el trigger, no el cliente, decide los valores iniciales. Este patrón lo desarrollas a fondo en DS-04.

Logout y expiración, hechos honestamente. `supabase.auth.signOut()` borra los tokens del localStorage y revoca el refresh_token en el servidor. Importante: si solo borras el localStorage a mano sin llamar signOut, el refresh_token sigue válido en el servidor — hazlo siempre por el SDK. Sobre expiración: no prometas "sesión para siempre". El access_token caduca en una hora y el SDK lo refresca con el refresh_token de forma transparente; si el refresh_token se revoca o caduca, el usuario vuelve a login. Comunica esto al usuario con honestidad en lugar de fingir persistencia eterna.

Configura las URLs de redirección en el panel de Supabase (Auth > URL Configuration). El magic-link redirige a una URL que DEBE estar en la allowlist, o Supabase rechaza el canje — esto previene que un atacante haga que el link redirija a un dominio que controle. En MOONKEY, las redirect URLs incluyen el dominio de producción (moonkeylab.pages.dev) y localhost para desarrollo, y nada más. Una allowlist de redirección laxa es un vector de phishing real.

Qué significa SECURITY DEFINER. Una función normal en Postgres corre con los permisos de quien la LLAMA (SECURITY INVOKER, el default). Una función SECURITY DEFINER corre con los permisos de quien la CREÓ (típicamente un rol con privilegios, dueño de las tablas). Esto le permite hacer cosas que el llamante no podría hacer directamente — por ejemplo, leer profiles para comprobar un rol, aunque la RLS le negaría al usuario ese SELECT. Es potente y es peligroso: una SECURITY DEFINER es un pequeño trozo de código que corre por encima de la RLS. Cada una es una excepción a tu modelo de seguridad, así que cada una debe ser auditada como tal.

El caso is_admin(). Necesitas saber si el usuario actual es admin para usarlo en policies (`using (... or is_admin())`). Pero si la policy de SELECT de profiles depende de leer profiles para saber el rol, tienes recursión infinita: para leer tu fila necesitas saber si eres admin, para saberlo lees profiles, lo que dispara la policy otra vez. La solución es is_admin() como SECURITY DEFINER: corre con privilegios del dueño, lee profiles SIN pasar por RLS, devuelve un booleano. Crucialmente, NO devuelve datos sensibles — solo true/false sobre el llamante (`select role = 'admin' from profiles where id = auth.uid()`). Una SECURITY DEFINER segura expone la mínima información: una decisión, no un dataset.

Blindar el search_path — esta es la vulnerabilidad clásica y la que los advisors marcan sin piedad. Una SECURITY DEFINER que no fija su search_path es explotable: un atacante crea una tabla o función con el mismo nombre que una que tu función usa, en un esquema que esté antes en el search_path, y tu función privilegiada ejecuta el código del atacante con permisos de dueño. La defensa es obligatoria: `create function is_admin() ... security definer set search_path = '' as $$ ... $$;` (o `set search_path = pg_catalog, public` cualificando explícitamente). Con search_path vacío, referencias toda tabla con su esquema completo: `public.profiles`, no `profiles`. Sin esto, tu función de seguridad ES el agujero.

RPCs: lógica de negocio invocable desde el cliente. Un RPC en Supabase es una función Postgres expuesta vía `supabase.rpc('nombre', args)`. En MOONKEY los RPCs reales son update_operator_rank (asciende el rango revalidando), my_referral_stats (devuelve estadísticas de referidos del usuario) e is_admin. El patrón de oro: el RPC NO confía en los argumentos del cliente para la identidad. update_operator_rank no recibe "qué usuario ascender" como parámetro libre — usa auth.uid() internamente. Si recibiera un user_id como argumento, un atacante llamaría rpc('update_operator_rank', { user_id: 'el de otro' }). La identidad SIEMPRE sale de auth.uid() dentro de la función, nunca de un parámetro que el cliente controle.

El RPC revalida, no obedece. update_operator_rank no es "pon mi rango a X porque lo pido". Revalida las reglas: ¿completó el usuario las pruebas requeridas para ese rango? El comentario del modelo de seguridad de MOONKEY es explícito — "Rangos solo vía update_operator_rank (revalida rol)". El cliente no puede saltar de monkey a admin pidiéndolo; el RPC comprueba las condiciones reales en la DB y solo entonces escribe. Esta es la diferencia entre un RPC que es una API de negocio (verifica invariantes) y uno que es un agujero (escribe lo que le digan). Otorga EXECUTE solo a `authenticated`, nunca a anon: `grant execute on function update_operator_rank to authenticated`.

Triggers: invariantes que se aplican pase lo que pase. Algunos invariantes no pueden depender de que la app los respete. "Un no-admin nunca puede cambiar su propio role ni su founder_badge" es uno: si dependiera de la app, cualquier UPDATE directo vía anon key lo saltaría. La solución de MOONKEY es el trigger guard_privileged_profile_columns, que se dispara `before update on profiles` y, si el llamante no es admin y está intentando cambiar role o founder_badge, lanza una excepción que aborta la transacción. Combinado con handle_new_user (after insert on auth.users, crea profiles con role='monkey'), el resultado es que un usuario NACE como monkey y NO PUEDE auto-promoverse — ni por la app, ni por un UPDATE crudo con la anon key. El trigger es la red bajo la RLS.

La disciplina de auditoría. Cada SECURITY DEFINER que escribas: ¿tiene search_path fijado? ¿devuelve la mínima información posible? ¿deriva la identidad de auth.uid() y no de un parámetro? ¿está su EXECUTE restringido al rol correcto? Tras crear o cambiar cualquiera de estas funciones, corre get_advisors (DS-06): el advisor de seguridad marca SECURITY DEFINER sin search_path y funciones con permisos laxos. Una SECURITY DEFINER es código privilegiado; trátala con la paranoia que merece código que corre por encima de tu propia seguridad.

El problema real no es "copiar datos". Es reconciliar dos fuentes de verdad que evolucionaron por separado: el localStorage de este navegador y la fila en Postgres (que pudo cambiar desde otro dispositivo). Antes de escribir código, decide la política de conflicto explícitamente, porque "lo que pase" es la receta de la pérdida de datos. Las opciones honestas: last-write-wins (gana el timestamp más reciente, simple pero puede perder ediciones concurrentes), merge por campo (combinas campo a campo según reglas), o append-only (nunca sobreescribes, solo añades, y derivas el estado). Para progreso de aprendizaje —que es monótono, solo avanza— la mejor política suele ser "el máximo gana": si local dice módulo 3 completado y nube dice módulo 5, el resultado es 5; nunca retrocedes.

El localStorage como capa, no como verdad. El patrón del seam Store de Espejo es la abstracción correcta: tu app no llama a localStorage ni a Supabase directamente, llama a un Store con una interfaz (get, set, list). Hay una implementación LocalStore (localStorage) y una SupabaseStore (Postgres). La app no sabe cuál usa. Esto convierte "pasar a la nube" de una reescritura a un cambio de implementación detrás de la misma interfaz. La sync, entonces, es una operación entre dos Stores: leer todo de LocalStore, reconciliar con SupabaseStore, escribir el resultado en ambos. Construye el seam ANTES de necesitar la nube; es barato al principio y carísimo de retrofitear.

Idempotencia es la propiedad que te salva. La sync se va a interrumpir: el usuario cierra la pestaña a mitad, la red cae, el SDK reintenta. Si tu sync no es idempotente, una segunda ejecución crea duplicados. La herramienta es el upsert con clave natural: `insert into progress (user_id, module_code, completed_at) values (...) on conflict (user_id, module_code) do update set completed_at = greatest(progress.completed_at, excluded.completed_at)`. Esa unique (user_id, module_code) de DS-01 es justo lo que hace el upsert posible. Ejecuta la sync dos veces seguidas: si el estado final es idéntico, es idempotente. Si la segunda vez duplica filas o cambia algo, tienes un bug que en producción se manifiesta como datos corruptos a medianoche.

El momento crítico: el primer login tras trabajar como invitado. El usuario avanzó en localStorage sin sesión, luego hace magic-link (DS-03) y obtiene un auth.uid(). Ahora hay que adoptar el estado anónimo bajo su identidad. El flujo seguro: al disparar onAuthStateChange con SIGNED_IN, lees el progreso de LocalStore, lo subes con upsert ligando user_id = auth.uid(), y solo entonces marcas el local como sincronizado. NO borres el local hasta confirmar que la nube lo recibió (la confirmación es la respuesta sin error del upsert). Si borras antes y la subida falla, perdiste el dato. Orden: subir, confirmar, marcar sincronizado, opcionalmente limpiar.

La RLS sigue mandando durante la sync. Cuando subes el progreso con la sesión del usuario, el upsert va con su JWT, así que la policy `with check (user_id = auth.uid())` aplica: no puedes subir progreso a nombre de otro, aunque el localStorage dijera otra cosa. Esto es bueno — la sync no es una puerta trasera a la seguridad. Significa que debes ligar user_id a auth.uid() en el momento de subir, no usar un user_id que arrastrabas del estado anónimo (que no tenía identidad real). La sync respeta el modelo: el servidor sigue siendo la autoridad sobre de quién es cada fila.

Conflictos entre dispositivos, el caso que la gente olvida. Usuario avanza en el móvil (sube a nube), luego abre el portátil que tenía estado local viejo. Sin cuidado, el portátil sobreescribe la nube con datos atrasados. La defensa: la reconciliación NO es "local pisa nube", es "reconciliar ambos según la política". Para progreso monótono, traes la nube, haces el merge "máximo gana" con el local, y escribes el resultado a ambos. Así el portátil aprende lo que hizo el móvil en vez de borrarlo. Para datos no monótonos necesitas timestamps por campo (updated_at) y last-write-wins por campo, lo que exige guardar esos timestamps desde el principio — otra razón para los timestamptz de DS-01.

Estados de la sync, visibles y honestos. Modela explícitamente: synced (local == nube), pending (hay cambios locales sin subir), syncing (en curso), error (falló, reintentar). No mientas al usuario con un check verde si la subida falló. Un indicador honesto de "cambios sin guardar" evita que el usuario cierre la pestaña creyendo que estaba a salvo. La sync silenciosa que falla en silencio es peor que no tener sync: el usuario confía y pierde datos sin saberlo.

Migraciones: la base de datos como código versionado. Cada cambio de esquema —una tabla, una columna, una policy, una función— es un archivo .sql con timestamp en supabase/migrations/, aplicado con apply_migration, nunca con execute_sql a mano. La diferencia es la misma que entre commitear y editar archivos en producción por SSH: una te da historial, revisión y rollback; la otra te da amnesia. El nombre del archivo (`<timestamp>_create_proofs.sql`, `<timestamp>_add_proofs_rls.sql`) cuenta la historia del esquema. Cuando dentro de seis meses te preguntes por qué una columna existe, la respuesta está en la migración que la introdujo, con su nombre y su fecha — no en tu memoria ni en la de nadie.

execute_sql es para LEER, apply_migration es para CAMBIAR. Esta regla operativa evita el error más común. Usa execute_sql para inspeccionar (select, explain, comprobar el estado), para impersonar y verificar RLS (DS-02), para exploración. En el momento en que el SQL altera el esquema o las policies de forma que quieres que persista, va en una migración. Un cambio de seguridad aplicado con execute_sql que funciona pero no está versionado es deuda: nadie sabe que existe, nadie puede revisarlo, y al recrear el proyecto desaparece.

Branches de Supabase para no romper producción. Antes de aplicar una migración con impacto, créala en una branch (create_branch), pruébala allí —incluida la verificación por impersonación de DS-02 y el get_advisors de DS-04— y solo entonces hazle merge a producción (merge_branch). La branch tiene su propia base de datos efímera; rompes lo que quieras sin tocar a usuarios reales. Esto es especialmente crítico en MOONKEY porque la DB es compartida: una migración que toca por error una tabla iron_* o world_* de XHUB se prueba y se descarta en la branch, no en la base viva que da servicio a dos proyectos.

Los advisors son tu linter de seguridad. get_advisors(type='security') corre un conjunto de comprobaciones que detectan exactamente los agujeros que estos módulos enseñan a evitar: tablas con RLS deshabilitada (DS-02), funciones SECURITY DEFINER con search_path mutable (DS-04), policies que exponen datos, columnas sin protección. get_advisors(type='performance') marca lo otro: foreign keys sin índice, índices duplicados, queries sin cubrir. La disciplina no negociable del CLAUDE.md de MOONKEY: 'Cambios de RLS/seguridad: aplicar como migración versionada + get_advisors después'. Cada vez que tocas seguridad, el advisor es el cierre del bucle — no asumes que está bien, lo verificas con la herramienta.

Cómo leer un advisor y actuar. Un warning del advisor no es ruido para silenciar; es una vulnerabilidad concreta con remedio concreto. 'RLS disabled on public.proofs' significa que cualquiera con la anon key lee la tabla — el remedio es enable row level security + policies, en una migración. 'Function public.is_admin has a role mutable search_path' significa que la función es secuestrable — el remedio es `alter function ... set search_path = ''`, en una migración. La rutina madura: tocas algo → migración → get_advisors → si hay warning, otra migración que lo cierra → get_advisors limpio. No hay 'lo arreglo luego' en advisors de seguridad; luego es después de la brecha.

Aislamiento en la DB compartida, el riesgo específico de MOONKEY. La base aloja tablas de MOONKEY (profiles, progress, feedback, leads, proofs) y de XHUB IRON (iron_*, world_*, focus_*, daily_focus_history). Tu disciplina de migraciones debe respetar esa frontera: una migración de MOONKEY NUNCA debe alterar, ni por descuido de un DROP o un ALTER demasiado amplio, una tabla del otro proyecto. Antes de aplicar, lee el diff de la migración como un adversario: ¿toca solo las tablas que dije? El advisor y la revisión del SQL son las dos redes. En una DB compartida, un cambio mal acotado no es un bug tuyo, es un incidente de otro proyecto.

Auditoría como hábito, no como evento. La auditoría no es una cosa que haces antes de un launch; es el estado por defecto de operar datos en serio. list_migrations te da el historial completo de cómo llegó el esquema a donde está. get_logs te muestra qué está fallando en tiempo real. get_advisors es el chequeo de salud que corres tras cada cambio y periódicamente aunque no cambies nada (porque Supabase añade nuevas comprobaciones y porque el contexto cambia). El operador que trata la base de datos como un sistema vivo que se audita continuamente es el que no tiene la llamada de las 3am — porque vio el warning en la branch, una semana antes, con get_advisors.