@nextblock-cms/db 0.15.10 → 0.16.2

package/supabase/migrations/00000000000028_interaction_replies.sql

@@ -1,86 +1,86 @@
--- Staff replies on reviews and post comments, and the indexes cms_interactions never had.
---
--- WHY THIS IS A DIFFERENT SHAPE FROM MIGRATION 27, AND WHY IT NEEDS NO TOKEN.
--- `cms_interactions.user_id` is NOT NULL with a foreign key to `profiles`: every review
--- and comment already comes from a signed-in account with a reachable address, and the
--- content already renders publicly on /product/{slug} and /article/{slug}. A staff
--- answer there is PUBLISHED CONTENT plus moderation, not a private conversation.
--- Routing it through the tokenised thread page would hide a public reply behind a
--- secret link. So: one inbox in the CMS, two storage models underneath.
---
--- THE ONE CONSTRAINT THAT DICTATES THE MODELLING.
--- `check_rating_only_for_review` is an exhaustive OR over ('review','comment'):
---     (type='review' AND rating IS NOT NULL AND rating BETWEEN 1 AND 5)
---  OR (type='comment' AND rating IS NULL)
--- A type='review' row with a NULL rating is rejected, so a reply to a review cannot be
--- a 'review' row. Adding a 'reply' value to interaction_type would ALSO violate it —
--- the OR covers no third value — and PostgreSQL forbids using an enum value in the
--- transaction that added it, which is exactly one migration file.
---
--- THEREFORE a reply is a `type='comment'` row carrying the PARENT's target and a NULL
--- rating: a combination the existing constraints already accept, unchanged. The bonus
--- is decisive — `update_product_ratings()` aggregates only
---   WHERE product_id = ? AND type='review' AND status='approved'
--- so a reply can never move products.average_rating or products.total_reviews. The new
--- CHECK below pins that invariant in the schema instead of trusting the action to
--- remember it.
---
--- No new policies are needed. `cms_interactions_insert_policy` already admits an
--- ADMIN/WRITER self-insert with status='approved'
---   (auth.uid() = user_id AND (status='pending' OR role IN ('ADMIN','WRITER')))
--- which is precisely a published staff reply.
---
--- Forward-only and idempotent.
-
-ALTER TABLE public.cms_interactions ADD COLUMN IF NOT EXISTS parent_id uuid;
-
-COMMENT ON COLUMN public.cms_interactions.parent_id IS 'Set on a staff reply: points at the review or comment being answered. Replies are always type=comment with a NULL rating, and carry the parent''s product_id/post_id so check_product_or_post still holds.';
-
-DO $rb$ BEGIN
-  IF NOT EXISTS (SELECT 1 FROM pg_constraint
-                 WHERE conname = 'cms_interactions_parent_id_fkey'
-                   AND conrelid = 'public.cms_interactions'::regclass) THEN
-    ALTER TABLE ONLY public.cms_interactions
-      ADD CONSTRAINT cms_interactions_parent_id_fkey FOREIGN KEY (parent_id)
-      REFERENCES public.cms_interactions(id) ON DELETE CASCADE;
-  END IF;
-END $rb$;
-
--- One level only, never itself, no rating, always a comment. Keeps the reply
--- invisible to the ratings trigger and to the existing storefront review query.
-DO $rb$ BEGIN
-  IF NOT EXISTS (SELECT 1 FROM pg_constraint
-                 WHERE conname = 'cms_interactions_reply_check'
-                   AND conrelid = 'public.cms_interactions'::regclass) THEN
-    ALTER TABLE public.cms_interactions
-      ADD CONSTRAINT cms_interactions_reply_check CHECK (
-        ((parent_id IS NULL) OR
-         ((parent_id <> id) AND (rating IS NULL) AND (type = 'comment'::public.interaction_type))));
-  END IF;
-END $rb$;
-
--- Fetch every reply for a page of parents in one probe.
-CREATE INDEX IF NOT EXISTS cms_interactions_parent_idx
-    ON public.cms_interactions USING btree (parent_id, created_at)
-    WHERE (parent_id IS NOT NULL);
-
--- cms_interactions has had ZERO secondary indexes since the baseline, while both
--- public renderers filter on exactly these predicates on every product and article
--- page. The inbox multiplies read volume on this table, so they go in now.
-CREATE INDEX IF NOT EXISTS cms_interactions_product_type_status_idx
-    ON public.cms_interactions USING btree (product_id, type, status, created_at DESC)
-    WHERE (product_id IS NOT NULL);
-
-CREATE INDEX IF NOT EXISTS cms_interactions_post_type_status_idx
-    ON public.cms_interactions USING btree (post_id, type, status, created_at DESC)
-    WHERE (post_id IS NOT NULL);
-
--- Inbox listing: newest top-level items, replies excluded.
-CREATE INDEX IF NOT EXISTS cms_interactions_inbox_idx
-    ON public.cms_interactions USING btree (created_at DESC)
-    WHERE (parent_id IS NULL);
-
-INSERT INTO public.translations (key, translations, created_at, updated_at) VALUES
-  ('interactions.staff_reply', '{"en": "Reply from the team", "fr": "Réponse de l''équipe"}', now(), now()),
-  ('interactions.staff_badge', '{"en": "Staff", "fr": "Équipe"}', now(), now())
-ON CONFLICT (key) DO NOTHING;
+-- Staff replies on reviews and post comments, and the indexes cms_interactions never had.
+--
+-- WHY THIS IS A DIFFERENT SHAPE FROM MIGRATION 27, AND WHY IT NEEDS NO TOKEN.
+-- `cms_interactions.user_id` is NOT NULL with a foreign key to `profiles`: every review
+-- and comment already comes from a signed-in account with a reachable address, and the
+-- content already renders publicly on /product/{slug} and /article/{slug}. A staff
+-- answer there is PUBLISHED CONTENT plus moderation, not a private conversation.
+-- Routing it through the tokenised thread page would hide a public reply behind a
+-- secret link. So: one inbox in the CMS, two storage models underneath.
+--
+-- THE ONE CONSTRAINT THAT DICTATES THE MODELLING.
+-- `check_rating_only_for_review` is an exhaustive OR over ('review','comment'):
+--     (type='review' AND rating IS NOT NULL AND rating BETWEEN 1 AND 5)
+--  OR (type='comment' AND rating IS NULL)
+-- A type='review' row with a NULL rating is rejected, so a reply to a review cannot be
+-- a 'review' row. Adding a 'reply' value to interaction_type would ALSO violate it —
+-- the OR covers no third value — and PostgreSQL forbids using an enum value in the
+-- transaction that added it, which is exactly one migration file.
+--
+-- THEREFORE a reply is a `type='comment'` row carrying the PARENT's target and a NULL
+-- rating: a combination the existing constraints already accept, unchanged. The bonus
+-- is decisive — `update_product_ratings()` aggregates only
+--   WHERE product_id = ? AND type='review' AND status='approved'
+-- so a reply can never move products.average_rating or products.total_reviews. The new
+-- CHECK below pins that invariant in the schema instead of trusting the action to
+-- remember it.
+--
+-- No new policies are needed. `cms_interactions_insert_policy` already admits an
+-- ADMIN/WRITER self-insert with status='approved'
+--   (auth.uid() = user_id AND (status='pending' OR role IN ('ADMIN','WRITER')))
+-- which is precisely a published staff reply.
+--
+-- Forward-only and idempotent.
+
+ALTER TABLE public.cms_interactions ADD COLUMN IF NOT EXISTS parent_id uuid;
+
+COMMENT ON COLUMN public.cms_interactions.parent_id IS 'Set on a staff reply: points at the review or comment being answered. Replies are always type=comment with a NULL rating, and carry the parent''s product_id/post_id so check_product_or_post still holds.';
+
+DO $rb$ BEGIN
+  IF NOT EXISTS (SELECT 1 FROM pg_constraint
+                 WHERE conname = 'cms_interactions_parent_id_fkey'
+                   AND conrelid = 'public.cms_interactions'::regclass) THEN
+    ALTER TABLE ONLY public.cms_interactions
+      ADD CONSTRAINT cms_interactions_parent_id_fkey FOREIGN KEY (parent_id)
+      REFERENCES public.cms_interactions(id) ON DELETE CASCADE;
+  END IF;
+END $rb$;
+
+-- One level only, never itself, no rating, always a comment. Keeps the reply
+-- invisible to the ratings trigger and to the existing storefront review query.
+DO $rb$ BEGIN
+  IF NOT EXISTS (SELECT 1 FROM pg_constraint
+                 WHERE conname = 'cms_interactions_reply_check'
+                   AND conrelid = 'public.cms_interactions'::regclass) THEN
+    ALTER TABLE public.cms_interactions
+      ADD CONSTRAINT cms_interactions_reply_check CHECK (
+        ((parent_id IS NULL) OR
+         ((parent_id <> id) AND (rating IS NULL) AND (type = 'comment'::public.interaction_type))));
+  END IF;
+END $rb$;
+
+-- Fetch every reply for a page of parents in one probe.
+CREATE INDEX IF NOT EXISTS cms_interactions_parent_idx
+    ON public.cms_interactions USING btree (parent_id, created_at)
+    WHERE (parent_id IS NOT NULL);
+
+-- cms_interactions has had ZERO secondary indexes since the baseline, while both
+-- public renderers filter on exactly these predicates on every product and article
+-- page. The inbox multiplies read volume on this table, so they go in now.
+CREATE INDEX IF NOT EXISTS cms_interactions_product_type_status_idx
+    ON public.cms_interactions USING btree (product_id, type, status, created_at DESC)
+    WHERE (product_id IS NOT NULL);
+
+CREATE INDEX IF NOT EXISTS cms_interactions_post_type_status_idx
+    ON public.cms_interactions USING btree (post_id, type, status, created_at DESC)
+    WHERE (post_id IS NOT NULL);
+
+-- Inbox listing: newest top-level items, replies excluded.
+CREATE INDEX IF NOT EXISTS cms_interactions_inbox_idx
+    ON public.cms_interactions USING btree (created_at DESC)
+    WHERE (parent_id IS NULL);
+
+INSERT INTO public.translations (key, translations, created_at, updated_at) VALUES
+  ('interactions.staff_reply', '{"en": "Reply from the team", "fr": "Réponse de l''équipe"}', now(), now()),
+  ('interactions.staff_badge', '{"en": "Staff", "fr": "Équipe"}', now(), now())
+ON CONFLICT (key) DO NOTHING;

package/supabase/migrations/00000000000029_form_endpoints_default_empty.sql

@@ -1,52 +1,52 @@
--- A contact form has no address of its own by default.
---
--- The starter content ships a contact page addressed to `contact@example.com`, and
--- migration 27 faithfully carried that placeholder into `form_endpoints`. Faithful was
--- the wrong call. `example.com` is reserved by RFC 2606 precisely so it can never be
--- registered, so the address is not merely unhelpful — it is guaranteed undeliverable,
--- while looking like a real setting to every layer downstream. The visitor is thanked,
--- the relay accepts the message, and nobody is ever notified. Nothing errors, so an
--- install can run that way indefinitely.
---
--- Since the messaging system arrived, a per-form address is not something an operator
--- needs to think about at all. Submissions are stored as threads and answered in
--- CMS → Messages; the notification address is a single site-wide setting, and a form
--- only carries its own address when someone deliberately wants that form routed
--- elsewhere (a careers form to HR, say).
---
--- So the default becomes NULL, meaning "use the site contact address", which resolves
--- to the address set in CMS → Messages and finally to the first admin's own login. An
--- install therefore reaches a real human out of the box without configuring anything.
---
--- The sandbox is unaffected: `resolveFormRecipient` overrides everything with
--- SANDBOX_CONTACT_EMAIL when NEXT_PUBLIC_IS_SANDBOX is set, so the hosted demo keeps
--- routing to the operator's own inbox without storing an address here.
---
--- Forward-only and idempotent.
-
--- Reserved domains from RFC 2606 / RFC 6761. Matching on the domain rather than the
--- exact seeded string also catches an operator who typed their own placeholder.
-UPDATE public.form_endpoints
-   SET recipient_email = NULL
- WHERE recipient_email IS NOT NULL
-   AND (
-     lower(recipient_email) LIKE '%@example.com'
-     OR lower(recipient_email) LIKE '%@example.org'
-     OR lower(recipient_email) LIKE '%@example.net'
-     OR lower(recipient_email) LIKE '%@example.edu'
-     OR lower(recipient_email) LIKE '%.example'
-     OR lower(recipient_email) LIKE '%.invalid'
-     OR lower(recipient_email) LIKE '%.test'
-     OR lower(recipient_email) LIKE '%.localhost'
-     OR lower(recipient_email) LIKE '%.local'
-   );
-
-COMMENT ON COLUMN public.form_endpoints.recipient_email IS 'Per-form override. NULL means "use the site contact address" (CMS -> Messages, falling back to the first admin), which is the default and the usual case.';
-
--- Same reasoning for the site-wide rows: a placeholder there is worse than an empty
--- value, because an empty one falls through to the first admin and actually arrives.
-UPDATE public.site_settings
-   SET value = jsonb_set(value, '{contactEmail}', '""'::jsonb)
- WHERE key IN ('forms_contact', 'store_contact')
-   AND value ? 'contactEmail'
-   AND lower(value->>'contactEmail') LIKE '%@example.%';
+-- A contact form has no address of its own by default.
+--
+-- The starter content ships a contact page addressed to `contact@example.com`, and
+-- migration 27 faithfully carried that placeholder into `form_endpoints`. Faithful was
+-- the wrong call. `example.com` is reserved by RFC 2606 precisely so it can never be
+-- registered, so the address is not merely unhelpful — it is guaranteed undeliverable,
+-- while looking like a real setting to every layer downstream. The visitor is thanked,
+-- the relay accepts the message, and nobody is ever notified. Nothing errors, so an
+-- install can run that way indefinitely.
+--
+-- Since the messaging system arrived, a per-form address is not something an operator
+-- needs to think about at all. Submissions are stored as threads and answered in
+-- CMS → Messages; the notification address is a single site-wide setting, and a form
+-- only carries its own address when someone deliberately wants that form routed
+-- elsewhere (a careers form to HR, say).
+--
+-- So the default becomes NULL, meaning "use the site contact address", which resolves
+-- to the address set in CMS → Messages and finally to the first admin's own login. An
+-- install therefore reaches a real human out of the box without configuring anything.
+--
+-- The sandbox is unaffected: `resolveFormRecipient` overrides everything with
+-- SANDBOX_CONTACT_EMAIL when NEXT_PUBLIC_IS_SANDBOX is set, so the hosted demo keeps
+-- routing to the operator's own inbox without storing an address here.
+--
+-- Forward-only and idempotent.
+
+-- Reserved domains from RFC 2606 / RFC 6761. Matching on the domain rather than the
+-- exact seeded string also catches an operator who typed their own placeholder.
+UPDATE public.form_endpoints
+   SET recipient_email = NULL
+ WHERE recipient_email IS NOT NULL
+   AND (
+     lower(recipient_email) LIKE '%@example.com'
+     OR lower(recipient_email) LIKE '%@example.org'
+     OR lower(recipient_email) LIKE '%@example.net'
+     OR lower(recipient_email) LIKE '%@example.edu'
+     OR lower(recipient_email) LIKE '%.example'
+     OR lower(recipient_email) LIKE '%.invalid'
+     OR lower(recipient_email) LIKE '%.test'
+     OR lower(recipient_email) LIKE '%.localhost'
+     OR lower(recipient_email) LIKE '%.local'
+   );
+
+COMMENT ON COLUMN public.form_endpoints.recipient_email IS 'Per-form override. NULL means "use the site contact address" (CMS -> Messages, falling back to the first admin), which is the default and the usual case.';
+
+-- Same reasoning for the site-wide rows: a placeholder there is worse than an empty
+-- value, because an empty one falls through to the first admin and actually arrives.
+UPDATE public.site_settings
+   SET value = jsonb_set(value, '{contactEmail}', '""'::jsonb)
+ WHERE key IN ('forms_contact', 'store_contact')
+   AND value ? 'contactEmail'
+   AND lower(value->>'contactEmail') LIKE '%@example.%';

package/supabase/migrations/00000000000030_seo_redirects_and_robots.sql

@@ -0,0 +1,149 @@
+-- SEO engine: managed 301/302 redirects and operator-configurable robots directives.
+--
+-- Two unrelated-looking things ship in one migration because they are the same
+-- feature from an operator's point of view: the `/cms/settings/seo` screen is where
+-- someone goes to say "this URL moved" and "do not crawl that". Splitting them
+-- across two migrations would only mean two files that must always be applied
+-- together.
+--
+-- WHY A TABLE AND NOT next.config.js redirects(). Redirects are content, not
+-- configuration. An editor who renames a page's slug needs the old URL to keep
+-- working immediately, without a redeploy and without touching source control.
+-- That rules out the build-time array; it has to be data.
+--
+-- WHY THE PROXY READS THIS WITH THE ANON KEY. apps/nextblock/proxy.ts (Next 16's
+-- renamed middleware) resolves redirects before rendering, and it holds a Supabase
+-- client built from the anon key. So the public SELECT policy below is load-bearing:
+-- without an explicit `TO authenticated, anon` grant the proxy's lookup would return
+-- zero rows for every anonymous visitor -- silently, with no error -- and no redirect
+-- would ever fire. Only is_active rows are exposed, so a half-written rule is never
+-- live.
+--
+-- WHY status_code IS AN integer AND NOT AN ENUM. The same reasoning migration 27
+-- recorded for `source`: a Postgres enum cannot be extended and used inside the same
+-- transaction, which is exactly the scope of one migration file. A CHECK constraint
+-- is replaceable in a single statement. 301 and 302 are the only two values the
+-- admin UI offers; 307/308 are deliberately not exposed, because their
+-- method-preserving semantics surprise operators who just want "this page moved".
+--
+-- LOOP SAFETY is enforced in application code (wouldCreateLoop in
+-- @nextblock-cms/utils, called by the admin server actions) rather than by a
+-- constraint, because detecting a cycle requires walking the whole table and a CHECK
+-- constraint can only see one row. The self-redirect case IS cheap to check per row,
+-- so that one is a constraint -- it is the cycle operators actually hit.
+--
+-- SECURITY POSTURE. A redirect can send every visitor of a path to an arbitrary
+-- external origin, which makes this table an open-redirect surface and a phishing
+-- lever. Writes are therefore ADMIN-only -- WRITER is deliberately excluded, matching
+-- site_scripts rather than the content tables. Reads are public but limited to active
+-- rows. The robots settings live in site_settings, whose existing read policy is
+-- already public for non-secret keys; nothing here is secret.
+--
+-- Forward-only and idempotent.
+
+CREATE TABLE IF NOT EXISTS public.cms_redirects (
+    id uuid DEFAULT gen_random_uuid() NOT NULL,
+    -- The incoming site-relative path to match, normalized by the application to a
+    -- leading slash with no trailing slash (except root). Matching is exact: prefix
+    -- and wildcard rules are deliberately not supported, because they are the usual
+    -- way an operator builds an accidental loop.
+    source_path text NOT NULL,
+    -- Where to send the visitor. Either another site-relative path or a fully
+    -- qualified https URL for an off-site move.
+    destination_path text NOT NULL,
+    -- 301 permanent (the SEO-meaningful one: search engines transfer ranking signals
+    -- and browsers cache it aggressively) or 302 temporary.
+    status_code integer DEFAULT 301 NOT NULL,
+    is_active boolean DEFAULT true NOT NULL,
+    created_at timestamp with time zone DEFAULT now() NOT NULL,
+    updated_at timestamp with time zone DEFAULT now() NOT NULL,
+    CONSTRAINT cms_redirects_pkey PRIMARY KEY (id),
+    -- One rule per source. This UNIQUE constraint also provides the index the proxy
+    -- lookup relies on, so no separate plain index on source_path is needed.
+    CONSTRAINT cms_redirects_source_path_key UNIQUE (source_path),
+    CONSTRAINT cms_redirects_status_code_check
+        CHECK ((status_code = ANY (ARRAY[301, 302]))),
+    -- A source is always a path on this site; accepting an absolute URL here would
+    -- silently never match, since the proxy only ever compares pathnames.
+    CONSTRAINT cms_redirects_source_path_check
+        CHECK ((source_path ~ '^/')),
+    -- A destination is either a site-relative path or an https URL. Plain http is
+    -- refused so a redirect can never downgrade a visitor to cleartext.
+    CONSTRAINT cms_redirects_destination_path_check
+        CHECK (((destination_path ~ '^/') OR (destination_path ~ '^https://'))),
+    -- The one cycle a single row can express, and the one operators actually create.
+    CONSTRAINT cms_redirects_no_self_redirect_check
+        CHECK ((source_path <> destination_path))
+);
+
+COMMENT ON TABLE public.cms_redirects IS
+    'Operator-managed 301/302 redirects resolved by apps/nextblock/proxy.ts before rendering. Only is_active rows are publicly readable; only ADMIN may write, because a redirect rule is an open-redirect surface.';
+COMMENT ON COLUMN public.cms_redirects.source_path IS
+    'Exact site-relative path to match, normalized to a leading slash and no trailing slash (except root). No wildcards, by design.';
+COMMENT ON COLUMN public.cms_redirects.destination_path IS
+    'Site-relative path or absolute https URL to send the visitor to.';
+COMMENT ON COLUMN public.cms_redirects.status_code IS
+    '301 permanent or 302 temporary. 307/308 are not offered by the admin UI.';
+COMMENT ON COLUMN public.cms_redirects.is_active IS
+    'Only active rows are readable by anon, and only active rows are matched by the proxy.';
+
+-- The proxy loads the whole active set once per cache window rather than querying per
+-- request, so the hot query is "all active rows" and this partial index is what serves
+-- it. Carrying source_path in the index keeps that read index-only.
+CREATE INDEX IF NOT EXISTS cms_redirects_active_source_idx
+    ON public.cms_redirects USING btree (source_path) WHERE (is_active);
+
+DROP TRIGGER IF EXISTS set_cms_redirects_updated_at ON public.cms_redirects;
+CREATE TRIGGER set_cms_redirects_updated_at
+    BEFORE UPDATE ON public.cms_redirects
+    FOR EACH ROW EXECUTE FUNCTION public.set_current_timestamp_updated_at();
+
+ALTER TABLE public.cms_redirects ENABLE ROW LEVEL SECURITY;
+
+GRANT ALL ON TABLE public.cms_redirects TO anon;
+GRANT ALL ON TABLE public.cms_redirects TO authenticated;
+GRANT ALL ON TABLE public.cms_redirects TO service_role;
+
+-- The proxy runs as anon for a logged-out visitor, which is the overwhelming majority
+-- of traffic and the only traffic redirects really matter for. Without this policy the
+-- lookup returns zero rows and the feature is silently dead.
+DROP POLICY IF EXISTS "Public read active redirects" ON public.cms_redirects;
+CREATE POLICY "Public read active redirects" ON public.cms_redirects
+    FOR SELECT TO authenticated, anon USING (is_active);
+
+DROP POLICY IF EXISTS "Admins read all redirects" ON public.cms_redirects;
+CREATE POLICY "Admins read all redirects" ON public.cms_redirects
+    FOR SELECT TO authenticated
+    USING (((SELECT public.get_current_user_role()) = 'ADMIN'::public.user_role));
+
+DROP POLICY IF EXISTS "Admins insert redirects" ON public.cms_redirects;
+CREATE POLICY "Admins insert redirects" ON public.cms_redirects
+    FOR INSERT TO authenticated
+    WITH CHECK (((SELECT public.get_current_user_role()) = 'ADMIN'::public.user_role));
+
+DROP POLICY IF EXISTS "Admins update redirects" ON public.cms_redirects;
+CREATE POLICY "Admins update redirects" ON public.cms_redirects
+    FOR UPDATE TO authenticated
+    USING (((SELECT public.get_current_user_role()) = 'ADMIN'::public.user_role))
+    WITH CHECK (((SELECT public.get_current_user_role()) = 'ADMIN'::public.user_role));
+
+DROP POLICY IF EXISTS "Admins delete redirects" ON public.cms_redirects;
+CREATE POLICY "Admins delete redirects" ON public.cms_redirects
+    FOR DELETE TO authenticated
+    USING (((SELECT public.get_current_user_role()) = 'ADMIN'::public.user_role));
+
+-- Robots directives live in site_settings rather than a table of their own: there is
+-- exactly one robots.txt per install, so a dedicated table would only ever hold one
+-- row, and site_settings already carries the public-read / staff-write policy this
+-- needs. The stored shape matches `RobotsSettings` in @nextblock-cms/utils, and
+-- `normalizeRobotsSettings` tolerates a missing or malformed value -- so this seed is
+-- a convenience for the settings screen, not a correctness requirement for rendering.
+--
+-- ON CONFLICT DO NOTHING because an install that has already configured robots must
+-- not have its rules reset by a replay of this migration.
+INSERT INTO public.site_settings (key, value)
+VALUES (
+    'seo_robots_settings',
+    '{"customRules": "", "isIndexingEnabled": true, "sitemapEnabled": true, "userAgentRules": [{"allow": ["/"], "disallow": [], "userAgent": "*"}]}'::jsonb
+)
+ON CONFLICT (key) DO NOTHING;

package/supabase/migrations/00000000000031_seo_robots_settings_admin_only.sql

@@ -0,0 +1,35 @@
+-- Restrict writes to the robots.txt settings row to ADMIN only.
+--
+-- `site_settings.seo_robots_settings` is the row that decides whether the whole site
+-- is crawlable: app/robots.ts reads it on every /robots.txt hit and serves a blanket
+-- `Disallow: /` when `isIndexingEnabled` is false. The CMS only offers that switch
+-- under /cms/settings/seo, and `saveRobotsSettings` re-checks for ADMIN before it
+-- writes — but RLS is the independent boundary, and it did not agree. The baseline
+-- write policies let ADMIN *or* WRITER write any key outside the sensitive array, so
+-- a WRITER holding a normal session could PATCH this row through PostgREST and take
+-- the entire site out of Google. That failure is quiet (nothing in the CMS shows it),
+-- slow to notice (search traffic decays over weeks) and hard to attribute after the
+-- fact, which is why the database has to refuse it rather than trusting the one
+-- server action that happens to guard it today.
+--
+-- The SELECT policy is deliberately NOT touched. This key must stay anon-READABLE:
+-- app/robots.ts reads it with the anon (SSG) client on every crawl, and adding the key
+-- to the read policy's sensitive array would make robots.txt fall back to its
+-- permissive defaults for every crawler. Only INSERT/UPDATE/DELETE move to ADMIN-only,
+-- matching the UI boundary — exactly the shape migration 00000000000011 used for
+-- language_detection_settings, which is anon-readable for the same reason.
+--
+-- Every key already present in each policy's array is preserved (dropping one would
+-- silently widen write access back to WRITER for that key); `seo_robots_settings` is
+-- appended to the three write policies only.
+
+DROP POLICY IF EXISTS site_settings_insert_policy ON public.site_settings;
+CREATE POLICY site_settings_insert_policy ON public.site_settings FOR INSERT TO authenticated WITH CHECK ((((key <> ALL (ARRAY['cortex_ai_openrouter_api_key'::text, 'bot_protection_secret'::text, 'email_secret'::text, 'payment_secret'::text, 'language_detection_settings'::text, 'cortex_ai_pexels_api_key'::text, 'cortex_ai_unsplash_access_key'::text, 'cortex_ai_mcp_settings'::text, 'seo_robots_settings'::text])) AND (( SELECT public.get_current_user_role() AS get_current_user_role) = ANY (ARRAY['ADMIN'::public.user_role, 'WRITER'::public.user_role]))) OR ((key = ANY (ARRAY['cortex_ai_openrouter_api_key'::text, 'bot_protection_secret'::text, 'email_secret'::text, 'payment_secret'::text, 'language_detection_settings'::text, 'cortex_ai_pexels_api_key'::text, 'cortex_ai_unsplash_access_key'::text, 'cortex_ai_mcp_settings'::text, 'seo_robots_settings'::text])) AND (( SELECT public.get_current_user_role() AS get_current_user_role) = 'ADMIN'::public.user_role))));
+
+DROP POLICY IF EXISTS site_settings_update_policy ON public.site_settings;
+CREATE POLICY site_settings_update_policy ON public.site_settings FOR UPDATE TO authenticated USING ((((key <> ALL (ARRAY['cortex_ai_openrouter_api_key'::text, 'bot_protection_secret'::text, 'email_secret'::text, 'payment_secret'::text, 'language_detection_settings'::text, 'cortex_ai_pexels_api_key'::text, 'cortex_ai_unsplash_access_key'::text, 'cortex_ai_mcp_settings'::text, 'seo_robots_settings'::text])) AND (( SELECT public.get_current_user_role() AS get_current_user_role) = ANY (ARRAY['ADMIN'::public.user_role, 'WRITER'::public.user_role]))) OR ((key = ANY (ARRAY['cortex_ai_openrouter_api_key'::text, 'bot_protection_secret'::text, 'email_secret'::text, 'payment_secret'::text, 'language_detection_settings'::text, 'cortex_ai_pexels_api_key'::text, 'cortex_ai_unsplash_access_key'::text, 'cortex_ai_mcp_settings'::text, 'seo_robots_settings'::text])) AND (( SELECT public.get_current_user_role() AS get_current_user_role) = 'ADMIN'::public.user_role)))) WITH CHECK ((((key <> ALL (ARRAY['cortex_ai_openrouter_api_key'::text, 'bot_protection_secret'::text, 'email_secret'::text, 'payment_secret'::text, 'language_detection_settings'::text, 'cortex_ai_pexels_api_key'::text, 'cortex_ai_unsplash_access_key'::text, 'cortex_ai_mcp_settings'::text, 'seo_robots_settings'::text])) AND (( SELECT public.get_current_user_role() AS get_current_user_role) = ANY (ARRAY['ADMIN'::public.user_role, 'WRITER'::public.user_role]))) OR ((key = ANY (ARRAY['cortex_ai_openrouter_api_key'::text, 'bot_protection_secret'::text, 'email_secret'::text, 'payment_secret'::text, 'language_detection_settings'::text, 'cortex_ai_pexels_api_key'::text, 'cortex_ai_unsplash_access_key'::text, 'cortex_ai_mcp_settings'::text, 'seo_robots_settings'::text])) AND (( SELECT public.get_current_user_role() AS get_current_user_role) = 'ADMIN'::public.user_role))));
+
+DROP POLICY IF EXISTS site_settings_delete_policy ON public.site_settings;
+CREATE POLICY site_settings_delete_policy ON public.site_settings FOR DELETE TO authenticated USING ((((key <> ALL (ARRAY['cortex_ai_openrouter_api_key'::text, 'bot_protection_secret'::text, 'email_secret'::text, 'payment_secret'::text, 'language_detection_settings'::text, 'cortex_ai_pexels_api_key'::text, 'cortex_ai_unsplash_access_key'::text, 'cortex_ai_mcp_settings'::text, 'seo_robots_settings'::text])) AND (( SELECT public.get_current_user_role() AS get_current_user_role) = ANY (ARRAY['ADMIN'::public.user_role, 'WRITER'::public.user_role]))) OR ((key = ANY (ARRAY['cortex_ai_openrouter_api_key'::text, 'bot_protection_secret'::text, 'email_secret'::text, 'payment_secret'::text, 'language_detection_settings'::text, 'cortex_ai_pexels_api_key'::text, 'cortex_ai_unsplash_access_key'::text, 'cortex_ai_mcp_settings'::text, 'seo_robots_settings'::text])) AND (( SELECT public.get_current_user_role() AS get_current_user_role) = 'ADMIN'::public.user_role))));
+
+-- Forward-only and idempotent.