@nextblock-cms/db 0.2.8 → 0.2.10

package/supabase/migrations/20251112142000_seed_how_it_works_post_blocks.sql

@@ -1,100 +0,0 @@
--- supabase/migrations/20251112142000_seed_how_it_works_post_blocks.sql
--- Populates the English "How NextBlock Works" post with a synthesized technical article.
-
-WITH target_posts AS (
-  SELECT id, language_id, slug
-  FROM public.posts
-  WHERE slug IN ('how-nextblock-works', 'comment-nextblock-fonctionne')
-),
-purged AS (
-  DELETE FROM public.blocks
-  WHERE post_id IN (SELECT id FROM target_posts)
-)
-INSERT INTO public.blocks (post_id, language_id, block_type, content, "order")
-SELECT
-  target_posts.id,
-  target_posts.language_id,
-  'text',
-  jsonb_build_object(
-    'html_content',
-    $$<h2>How NextBlock Works: Architecture for a Visual-First CMS</h2>
-<p>NextBlock is purpose-built to feel like a polished product from day one, and that polish starts with the Nx monorepo. Applications and libraries sit side-by-side so the same code that powers the hosted CMS experience also ships inside the open-source template and CLI. Instead of scattering configuration across projects, TypeScript paths, Tailwind presets, and shared lint rules all originate from the workspace root, which keeps every downstream package aligned.</p>
-<div class='flex flex-col md:flex-row gap-8 items-start my-8'>
-  <div class='w-full md:w-3/5 space-y-4'>
-    <h3>Monorepo Layout and Dependency Flow</h3>
-    <p>The <code>apps/nextblock</code> directory contains the production Next.js interface—both the public site and the authenticated CMS. The <code>apps/create-nextblock</code> CLI mirrors it, syncing files from the main app before publishing a scaffolding tool. Reusable primitives live under <code>libs/</code>. UI components and design tokens are exported from <code>@nextblock-cms/ui</code>, cross-cutting helpers (translations, R2 clients, Supabase environment guards) live in <code>@nextblock-cms/utils</code>, and database code plus migrations are centralized inside <code>@nextblock-cms/db</code>. Future-facing work, like the SDK and e-commerce module, already have dedicated libraries so they can mature without disrupting the core runtime.</p>
-    <p>This organization matters because Nx understands project boundaries. When you run <code>nx graph</code> you see exactly how a change in the editor package might ripple into the Next.js app. Path aliases from <code>tsconfig.base.json</code> and the shared <code>tailwind.config.js</code> ensure that every consumer sees the same theme scales and helper utilities, which is crucial for a system that promises design parity between marketing pages, admin screens, and scaffolded customer projects.</p>
-    <p>Together, those guardrails mean features can ship quickly without regressions. Schema migrations live in <code>libs/db</code>, UI primitives live in <code>libs/ui</code>, and the CLI simply syncs changes downstream—no copy/paste debt, no drifting configs.</p>
-  </div>
-  <aside class='md:w-2/5 bg-muted/40 border border-border/40 rounded-2xl p-4 shadow-lg text-center'>
-    <img src='/images/nx-graph.webp' alt='Nx project graph preview' class='w-full h-auto object-cover rounded-lg' />
-    <p class='text-sm text-muted-foreground mt-3'>Nx keeps every workspace relationship visible.</p>
-  </aside>
-</div>
-<h3>Inside the CMS Application</h3>
-<p>Within <code>apps/nextblock/app/cms</code>, each feature area—pages, posts, media, navigation, users, settings—follows a predictable file pattern: a list page, creation and edit routes, server actions, and scoped client components. The root CMS layout enforces authentication, builds the shell (sidebar, responsive header, profile menu), and injects role-aware navigation. That means writers can jump straight into the block editor while admins unlock additional menus such as language management or user provisioning, all without duplicating layout logic.</p>
-<p>Server actions wrap Supabase calls so mutations never leak credentials into the browser. Media uploads coordinate with Cloudflare R2, navigation management includes drag-and-drop ordering, and every table interaction respects the row-level security policies defined in the Supabase migrations—e.g., only admins and writers can mutate pages or posts while anonymous traffic can only read published content.</p>
-<h3>Tech Stack and Runtime</h3>
-<p>The stack highlighted in the project README—Next.js 15, Supabase, Tailwind CSS, and shadcn/ui—was selected to balance developer velocity with runtime performance. Next.js App Router unlocks Server Components, streaming, and incremental static regeneration so marketing experiences remain edge-fast. Supabase covers Postgres, Auth, and Storage, shrinking the operational footprint while still allowing custom SQL migrations. Tailwind plus shadcn/ui provide composable building blocks so the CMS interface, marketing site, and generated client projects all inherit the same visual language.</p>
-<p>Nx tooling ties it together. Common commands such as <code>nx serve nextblock</code>, <code>nx build nextblock</code>, or workspace-wide tasks like <code>nx run-many -t lint --all</code> respect dependency caching, so even large rebuilds feel snappy during the 100-day roadmap.</p>
-<pre><code>nx serve nextblock
-nx run-many -t build --all
-supabase db push
-</code></pre>
-<h3>The Tiptap-Based Block Editor</h3>
-<p>The <code>@nextblock-cms/editor</code> package turns Tiptap v3 into a polished, reusable editing surface. It ships rich-text formatting, tables, task lists, slash commands, floating and bubble menus, character counts, focus mode, and syntax-highlighted code blocks. Under the hood it bundles StarterKit, TextStyleKit, CodeBlockLowlight, Image, TaskList, Table, Link, TextAlign, Highlight, Typography, and more. Because the editor is published as a standalone library, both the CMS and the generated template pull identical behavior, ensuring content parity.</p>
-<p>From an implementation standpoint, the editor exposes granular components—EditorToolbar, BubbleMenu, FloatingMenu—so the CMS can embed one cohesive editing experience while keeping the door open for agencies or plugin developers to compose their own UI. Comprehensive CSS hooks (e.g., <code>.tiptap pre</code> for code blocks) mean that teams can layer in dark-mode friendly themes without forking the core package.</p>
-<h3>Putting It All Together</h3>
-<p>The result is a platform where architecture decisions reinforce each other: the Nx workspace keeps libraries honest, the Next.js app enforces UX consistency, Supabase migrations codify access rules, and the Tiptap editor guarantees that content collaborators see the same tooling regardless of deployment. When a new team runs <code>npm create nextblock</code>, they inherit not just a starter site, but the entire operational philosophy described above—ready to extend with SDKs, premium modules, and marketplace blocks as the ecosystem grows.</p>$$
-  ),
-  0
-FROM target_posts
-WHERE target_posts.slug = 'how-nextblock-works'
-
-UNION ALL
-
-SELECT
-  target_posts.id,
-  target_posts.language_id,
-  'text',
-  jsonb_build_object(
-    'html_content',
-    $$<h2>Comment NextBlock fonctionne : architecture pour un CMS axé sur l'expérience visuelle</h2>
-<p>NextBlock est conçu pour fonctionner dès le premier jour avec un socle Nx. Applications et librairies cohabitent pour que le même code propulse l'expérience CMS hébergée et le template open-source. Au lieu d'éparpiller la configuration, les chemins TypeScript, le preset Tailwind et les règles lint sont centralisés à la racine, gardant tous les packages alignés.</p>
-<div class='flex flex-col md:flex-row gap-8 items-start my-8'>
-  <div class='w-full md:w-3/5 space-y-4'>
-    <h3>Architecture monorepo et flux de dépendances</h3>
-    <p>Le dossier <code>apps/nextblock</code> contient l'interface Next.js (site public + CMS). Le CLI <code>apps/create-nextblock</code> la reflète et publie un outil de scaffolding. Les briques réutilisables vivent dans <code>libs/</code> : UI et design tokens via <code>@nextblock-cms/ui</code>, helpers (traductions, R2, règles Supabase) via <code>@nextblock-cms/utils</code>, et la base de données + migrations dans <code>@nextblock-cms/db</code>. Les travaux futurs (SDK, e-commerce) ont déjà leurs librairies dédiées.</p>
-    <p>Ce découplage est lisible via <code>nx graph</code> : un changement dans l'éditeur impacte clairement les apps dépendantes. Les alias de <code>tsconfig.base.json</code> et le <code>tailwind.config.js</code> partagé assurent une cohérence de thème et d'outils entre pages marketing, back-office et projets générés.</p>
-    <p>En pratique, cela accélère les livraisons sans régressions : migrations dans <code>libs/db</code>, primitives UI dans <code>libs/ui</code>, et le CLI synchronise simplement en aval—pas de dettes de copier/coller ni de configs divergentes.</p>
-  </div>
-  <aside class='md:w-2/5 bg-muted/40 border border-border/40 rounded-2xl p-4 shadow-lg text-center'>
-    <img src='/images/nx-graph.webp' alt='Aperçu du graph Nx' class='w-full h-auto object-cover rounded-lg' />
-    <p class='text-sm text-muted-foreground mt-3'>Nx rend visibles toutes les relations du workspace.</p>
-  </aside>
-</div>
-<h3>Stack technique et exécution</h3>
-<p>Le stack—Next.js 15, Supabase, Tailwind CSS, shadcn/ui—équilibre vélocité et performance. L'App Router active les Server Components et l'ISR pour un rendu edge rapide. Supabase gère Postgres/Auth/Storage, réduisant l'opérationnel tout en gardant la liberté SQL. Tailwind + shadcn/ui fournissent des blocs réutilisables pour le CMS, le site marketing et les projets générés.</p>
-<pre><code>nx serve nextblock
-nx run-many -t build --all
-supabase db push
-</code></pre>
-<h3>Éditeur basé sur Tiptap</h3>
-<p>Le package <code>@nextblock-cms/editor</code> transforme Tiptap v3 en surface d'édition robuste : mise en forme riche, menus contextuels, compteurs de caractères, blocs de code avec syntax highlighting, tables, listes de tâches, et plus. Éditor et template consomment la même librairie pour garantir la parité de contenu.</p>
-<h3>En résumé</h3>
-<p>Chaque choix architectural se renforce : Nx garde les dépendances lisibles, l'app Next.js impose une UX cohérente, les migrations Supabase codifient l'accès, et l'éditeur Tiptap assure une expérience identique pour tous les contributeurs.</p>$$
-  ),
-  0
-FROM target_posts
-WHERE target_posts.slug = 'comment-nextblock-fonctionne';
-
-SELECT id AS how_it_works_post_block_id, "order"
-FROM public.blocks
-WHERE post_id = (
-  SELECT id FROM public.posts
-  WHERE slug = 'how-nextblock-works'
-    AND language_id = (SELECT id FROM public.languages WHERE code = 'en' LIMIT 1)
-  ORDER BY created_at DESC
-  LIMIT 1
-)
-ORDER BY "order";

package/supabase/migrations/20251112143000_seed_additional_translations.sql

@@ -1,102 +0,0 @@
--- supabase/migrations/20251112143000_seed_additional_translations.sql
--- Adds French values to every existing translation key.
-
-INSERT INTO public.translations (key, translations) VALUES
-('sign_in', '{"fr": "Connexion"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('sign_up', '{"fr": "Inscription"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('sign_out', '{"fr": "Déconnexion"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('dont_have_account', '{"fr": "Pas encore de compte ?"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('email', '{"fr": "Email"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('you_at_example_com', '{"fr": "vous@example.com"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('password', '{"fr": "Mot de passe"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('forgot_password', '{"fr": "Mot de passe oublié ?"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('your_password', '{"fr": "Votre mot de passe"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('signing_in_pending', '{"fr": "Connexion en cours..."}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('already_have_account', '{"fr": "Déjà un compte ?"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('signing_up_pending', '{"fr": "Inscription en cours..."}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('reset_password', '{"fr": "Réinitialiser le mot de passe"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('edit_page', '{"fr": "Éditer la page"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('edit_post', '{"fr": "Éditer l''article"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('open_main_menu', '{"fr": "Ouvrir le menu principal"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('mobile_navigation_menu', '{"fr": "Menu de navigation mobile"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('cms_dashboard', '{"fr": "Tableau de bord CMS"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('update_env_file_warning', '{"fr": "Veuillez mettre à jour .env.local avec l''anon key et l''URL"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;
-
-INSERT INTO public.translations (key, translations) VALUES
-('greeting', '{"fr": "Salut, {username} !"}')
-ON CONFLICT (key) DO UPDATE
-SET translations = public.translations.translations || EXCLUDED.translations;

package/supabase/migrations/20251112145000_grant_public_schema_usage.sql

@@ -1,6 +0,0 @@
--- Ensure Supabase roles can access objects in the public schema
-
-GRANT USAGE ON SCHEMA public TO postgres;
-GRANT USAGE ON SCHEMA public TO anon;
-GRANT USAGE ON SCHEMA public TO authenticated;
-GRANT USAGE ON SCHEMA public TO service_role;

package/supabase/migrations/20251112145500_grant_select_on_public_tables.sql

@@ -1,19 +0,0 @@
--- Ensure anon/authenticated roles can read existing and future public tables/sequences
-
-GRANT SELECT ON ALL TABLES IN SCHEMA public TO anon;
-GRANT SELECT ON ALL TABLES IN SCHEMA public TO authenticated;
-
-GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO anon;
-GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO authenticated;
-
-ALTER DEFAULT PRIVILEGES IN SCHEMA public
-GRANT SELECT ON TABLES TO anon;
-
-ALTER DEFAULT PRIVILEGES IN SCHEMA public
-GRANT SELECT ON TABLES TO authenticated;
-
-ALTER DEFAULT PRIVILEGES IN SCHEMA public
-GRANT USAGE, SELECT ON SEQUENCES TO anon;
-
-ALTER DEFAULT PRIVILEGES IN SCHEMA public
-GRANT USAGE, SELECT ON SEQUENCES TO authenticated;

package/supabase/migrations/20251117093000_add_admin_created_flag.sql

@@ -1,21 +0,0 @@
--- Ensure the admin flag exists as a key/value entry
-INSERT INTO public.site_settings (key, value)
-VALUES ('is_admin_created', 'false'::jsonb)
-ON CONFLICT (key) DO NOTHING;
-
--- Allow the security definer function (owned by postgres/service_role) to read/update this flag
-DROP POLICY IF EXISTS site_settings_admin_seed ON public.site_settings;
-CREATE POLICY site_settings_admin_seed
-ON public.site_settings
-FOR ALL
-TO postgres, service_role
-USING (true)
-WITH CHECK (true);
-
--- Ensure the trigger can insert profiles under RLS by allowing service_role to insert
-DROP POLICY IF EXISTS profiles_service_role_insert ON public.profiles;
-CREATE POLICY profiles_service_role_insert
-ON public.profiles
-FOR INSERT
-TO service_role, postgres
-WITH CHECK (true);

package/supabase/migrations/20251117103000_relax_profile_username_constraint.sql

@@ -1,6 +0,0 @@
--- Allow profiles inserts without a username (handle_new_user trigger)
-ALTER TABLE public.profiles
-DROP CONSTRAINT IF EXISTS username_length;
-
-ALTER TABLE public.profiles
-ADD CONSTRAINT username_length CHECK (username IS NULL OR char_length(username) >= 3);

package/supabase/migrations/20251117110000_relax_profiles_site_settings_rls_for_signup.sql

@@ -1,20 +0,0 @@
--- Broaden RLS to ensure auth signup trigger can run without RLS conflicts
-
--- Profiles: allow service_role, authenticated, and anon to insert (trigger runs after auth.users insert)
-DROP POLICY IF EXISTS profiles_service_role_insert ON public.profiles;
-CREATE POLICY profiles_service_role_insert
-ON public.profiles
-FOR INSERT
-TO service_role, postgres, authenticated, anon
-WITH CHECK (true);
-
--- Profiles: allow reading own row or admin policies remain; no change needed for select/update here
-
--- Site settings: allow service_role/authenticated/anon to read and update the admin flag row
-DROP POLICY IF EXISTS site_settings_admin_seed ON public.site_settings;
-CREATE POLICY site_settings_admin_seed
-ON public.site_settings
-FOR ALL
-TO service_role, postgres, authenticated, anon
-USING (true)
-WITH CHECK (true);

package/supabase/migrations/20251117112000_fix_handle_new_user_role_enum.sql

@@ -1,45 +0,0 @@
--- Ensure handle_new_user uses the enum type and works with the KV admin flag
-
-CREATE OR REPLACE FUNCTION public.handle_new_user()
-RETURNS TRIGGER
-LANGUAGE plpgsql
-SECURITY DEFINER
-SET search_path = 'public'
-AS $$
-DECLARE
-  admin_flag_set BOOLEAN := FALSE;
-  user_role public.user_role;
-BEGIN
-  -- Ensure the admin flag row exists
-  INSERT INTO public.site_settings (key, value)
-  VALUES ('is_admin_created', 'false'::jsonb)
-  ON CONFLICT (key) DO NOTHING;
-
-  -- Lock and read the flag
-  SELECT COALESCE((value)::jsonb::boolean, FALSE)
-  INTO admin_flag_set
-  FROM public.site_settings
-  WHERE key = 'is_admin_created'
-  FOR UPDATE;
-
-  IF admin_flag_set = FALSE THEN
-    user_role := 'ADMIN'::public.user_role;
-    UPDATE public.site_settings
-    SET value = 'true'::jsonb
-    WHERE key = 'is_admin_created';
-  ELSE
-    user_role := 'USER'::public.user_role;
-  END IF;
-
-  INSERT INTO public.profiles (id, role)
-  VALUES (NEW.id, user_role);
-  
-  RETURN NEW;
-END;
-$$;
-
--- Drop and recreate the trigger to use the updated function
-DROP TRIGGER IF EXISTS on_auth_user_created ON auth.users;
-CREATE TRIGGER on_auth_user_created
-  AFTER INSERT ON auth.users
-  FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();

package/supabase/migrations/20251117113000_cleanup_rls_duplicates.sql

@@ -1,20 +0,0 @@
--- Consolidate RLS policies to avoid multiple permissive policies per role/action
-
--- Profiles: keep a dedicated insert policy only for service_role/postgres (trigger context)
-DROP POLICY IF EXISTS profiles_service_role_insert ON public.profiles;
-CREATE POLICY profiles_service_role_insert
-ON public.profiles
-FOR INSERT
-TO service_role, postgres
-WITH CHECK (true);
-
--- Site settings: keep a dedicated policy only for service_role/postgres for trigger/maintenance
-DROP POLICY IF EXISTS site_settings_admin_seed ON public.site_settings;
-CREATE POLICY site_settings_admin_seed
-ON public.site_settings
-FOR ALL
-TO service_role, postgres
-USING (true)
-WITH CHECK (true);
-
--- Leave the existing combined authenticated/anon policies in place (no duplicates per role/action)

package/supabase/migrations/20251117200000_media_service_role_insert.sql

@@ -1,14 +0,0 @@
--- Allows service_role to insert media records (used by signed upload flows)
--- without weakening existing RLS for other roles.
-
-BEGIN;
-
--- Ensure idempotency for Supabase PG version (CREATE POLICY IF NOT EXISTS not available)
-DROP POLICY IF EXISTS media_service_role_insert ON public.media;
-
-CREATE POLICY media_service_role_insert ON public.media
-  FOR INSERT
-  TO service_role
-  WITH CHECK (true);
-
-COMMIT;

package/supabase/migrations/20251117201500_media_service_role_select.sql

@@ -1,11 +0,0 @@
--- Ensure service_role can read media rows (needed when uploads write media + linked inserts)
-
-BEGIN;
-
-DROP POLICY IF EXISTS media_service_role_select ON public.media;
-CREATE POLICY media_service_role_select ON public.media
-  FOR SELECT
-  TO service_role
-  USING (true);
-
-COMMIT;

package/supabase/migrations/20251117203000_media_admin_writer_select.sql

@@ -1,11 +0,0 @@
--- Allow ADMIN/WRITER to read media rows (needed for media library + logos)
-
-BEGIN;
-
-DROP POLICY IF EXISTS media_admin_writer_can_read ON public.media;
-CREATE POLICY media_admin_writer_can_read ON public.media
-  FOR SELECT
-  TO authenticated
-  USING (public.get_current_user_role() IN ('ADMIN', 'WRITER'));
-
-COMMIT;

package/supabase/migrations/20251117204500_fix_media_permissions.sql

@@ -1,43 +0,0 @@
--- Fix media permissions: ensure grants and RLS policies for admin/writer and service_role
-
-BEGIN;
-
--- Privileges (required in addition to RLS)
-GRANT SELECT, INSERT, UPDATE, DELETE ON public.media TO authenticated, service_role;
-
--- Reset policies to known good set
-DROP POLICY IF EXISTS media_admin_writer_can_insert ON public.media;
-DROP POLICY IF EXISTS media_admin_writer_can_update ON public.media;
-DROP POLICY IF EXISTS media_admin_writer_can_delete ON public.media;
-DROP POLICY IF EXISTS media_admin_writer_can_read ON public.media;
-DROP POLICY IF EXISTS media_service_role_insert ON public.media;
-DROP POLICY IF EXISTS media_service_role_select ON public.media;
-
--- Admin/Writer: full CRUD
-CREATE POLICY media_admin_writer_can_insert ON public.media
-  FOR INSERT TO authenticated
-  WITH CHECK (public.get_current_user_role() IN ('ADMIN', 'WRITER'));
-
-CREATE POLICY media_admin_writer_can_update ON public.media
-  FOR UPDATE TO authenticated
-  USING (public.get_current_user_role() IN ('ADMIN', 'WRITER'))
-  WITH CHECK (public.get_current_user_role() IN ('ADMIN', 'WRITER'));
-
-CREATE POLICY media_admin_writer_can_delete ON public.media
-  FOR DELETE TO authenticated
-  USING (public.get_current_user_role() IN ('ADMIN', 'WRITER'));
-
-CREATE POLICY media_admin_writer_can_read ON public.media
-  FOR SELECT TO authenticated
-  USING (public.get_current_user_role() IN ('ADMIN', 'WRITER'));
-
--- service_role: insert + read (used by upload flows)
-CREATE POLICY media_service_role_insert ON public.media
-  FOR INSERT TO service_role
-  WITH CHECK (true);
-
-CREATE POLICY media_service_role_select ON public.media
-  FOR SELECT TO service_role
-  USING (true);
-
-COMMIT;