@fayz-ai/db 0.14.0 → 0.16.0

package/migrations/011_leadcontrol_joins_the_family.sql

@@ -52,7 +52,11 @@
 -- publishes these apps elsewhere updates the row; nothing in code hardcodes a
 -- port.
 INSERT INTO app.apps (id, name, icon, accent_color, url, requires, serves_verticals) VALUES
-  ('crm', 'LeadControl', 'Target', '#2563EB', 'http://localhost:5307',
+  -- Megafone e não alvo: o alvo diz PONTARIA — a casa mira e acerta uma pessoa.
+  -- O megafone diz ALCANCE: a casa fala e muita gente ouve. É o que este app
+  -- faz — origem, segmento, campanha e porta pública existem para a casa ser
+  -- OUVIDA, e o lead é a resposta de quem ouviu.
+  ('crm', 'LeadControl', 'Megaphone', '#2563EB', 'http://localhost:5307',
    ARRAY['crm', 'conversations', 'marketing', 'automations'],
    ARRAY[]::text[])
 ON CONFLICT (id) DO UPDATE

package/migrations/029_o_administrador_enxerga_o_que_existe.sql

@@ -0,0 +1,167 @@
+-- 029_o_administrador_enxerga_o_que_existe.sql
+--
+-- O rail do LeadControl abria com duas linhas — Painel e Análises — enquanto o
+-- painel logo abaixo mostrava "Total de Leads: 20". Os dados estavam lá, os
+-- plugins montados, o console limpo. Só o MENU estava vazio.
+--
+-- A causa não é do app. É esta assimetria, no `app.seed_role_template`:
+--
+--     -- o Owner recebe o CATÁLOGO, e o catálogo cresce sozinho
+--     INSERT INTO app.role_permissions
+--     SELECT p_tenant, v_owner, p.key FROM app.permissions p;
+--
+--     -- todos os outros recebem uma LISTA, escrita à mão, que não cresce
+--     INSERT INTO app.role_permissions
+--     SELECT p_tenant, r.id, t.permission FROM app.role_templates t ...
+--
+-- Um plugin publicado depois que aquela lista foi escrita registra as suas
+-- permissões em `app.permissions` e, a partir daí, chega ao Owner de graça e
+-- **a mais ninguém, nunca**. Não há aviso: `AdminShell` esconde a linha do rail
+-- quando a negação é por PAPEL (negação por PLANO manteria a linha com a coroa),
+-- então o sintoma é um menu curto, que parece escolha de produto.
+--
+-- Medido no cluster antes desta migration, em 10 tenants:
+--
+--     Administrator/Manager que enxergam crm.*            0 de 10
+--     Administrator/Manager que enxergam conversations.*  0 de 10
+--
+-- E não são só esses dois. Comparando Owner com Administrator num tenant real,
+-- faltavam ao Administrator DEZENOVE features: appointments, automations, blog,
+-- config, conversations, courses, crm, custom_forms, dashboard, marketing,
+-- menu, reputation, sales, scribe, shop, sites, tables e mais. Ou seja: quase
+-- todo plugin que o SDK ganhou desde que a lista foi escrita.
+--
+-- Por isso a correção NÃO é acrescentar quatro linhas à lista. Acrescentar
+-- quatro linhas conserta a queixa de hoje e reprograma a mesma queixa para o
+-- próximo plugin. A correção é tirar o Administrador da lista e colocá-lo no
+-- CATÁLOGO, como o Owner — menos o que é do dono.
+--
+-- O que continua sendo lista, de propósito: manager, staff e viewer. Esses são
+-- recortes deliberados — um "Viewer" que enxerga tudo o que existe deixou de
+-- ser viewer. Eles vão continuar precisando de decisão a cada plugin novo; a
+-- diferença é que agora ALGUÉM abaixo do dono enxerga o plugin no dia em que
+-- ele registra as permissões, e o buraco aparece na hora em vez de meses depois.
+
+-- ── o que é do dono ────────────────────────────────────────────────────────
+--
+-- Precisa ser uma marca no catálogo, não uma lista no meio de uma função: quem
+-- registra uma permissão nova é o plugin, e é ele que sabe se ela é do dono.
+ALTER TABLE app.permissions
+  ADD COLUMN IF NOT EXISTS owner_only boolean DEFAULT false NOT NULL;
+
+COMMENT ON COLUMN app.permissions.owner_only IS
+  'Permissão que só o Owner recebe. O Administrador recebe todo o resto do catálogo automaticamente (029).';
+
+-- Assinatura, cartão e cancelamento são do dono. E `admin.*` é o painel da
+-- PLATAFORMA — não é papel de tenant nenhum, nem do dono da loja.
+--
+-- `owner_only` governa o que se CONCEDE daqui para frente; não revoga o que já
+-- foi concedido. Um Administrador que hoje tem `billing.read` porque a lista
+-- antiga o deu continua tendo: tirar permissão de quem já trabalha com ela é
+-- uma quebra, e esta migration veio consertar um menu vazio, não estreitar
+-- ninguém.
+UPDATE app.permissions SET owner_only = true
+ WHERE key ~ '^(billing|admin)\.' AND owner_only = false;
+
+-- ── o administrador passa a ler o catálogo ─────────────────────────────────
+CREATE OR REPLACE FUNCTION app.seed_role_template(p_tenant uuid, p_template text DEFAULT 'generic'::text) RETURNS uuid
+    LANGUAGE plpgsql SECURITY DEFINER
+    SET search_path TO ''
+    AS $$
+DECLARE v_owner uuid;
+BEGIN
+  IF NOT EXISTS (SELECT 1 FROM app.role_templates WHERE template = p_template) THEN
+    RAISE EXCEPTION 'seed_role_template: unknown template %', p_template;
+  END IF;
+
+  INSERT INTO app.roles (tenant_id, key, name, is_system)
+  VALUES (p_tenant, 'owner', 'Owner', true)
+  ON CONFLICT (tenant_id, key) DO NOTHING;
+  SELECT id INTO v_owner FROM app.roles WHERE tenant_id = p_tenant AND key = 'owner';
+
+  INSERT INTO app.role_permissions (tenant_id, role_id, permission)
+  SELECT p_tenant, v_owner, p.key FROM app.permissions p
+  ON CONFLICT DO NOTHING;
+
+  INSERT INTO app.roles (tenant_id, key, name, is_system)
+  SELECT DISTINCT ON (t.role_key) p_tenant, t.role_key, t.role_name, true
+    FROM app.role_templates t WHERE t.template = p_template
+   ORDER BY t.role_key
+  ON CONFLICT (tenant_id, key) DO NOTHING;
+
+  INSERT INTO app.role_permissions (tenant_id, role_id, permission)
+  SELECT p_tenant, r.id, t.permission
+    FROM app.role_templates t
+    JOIN app.roles r ON r.tenant_id = p_tenant AND r.key = t.role_key
+   WHERE t.template = p_template
+  ON CONFLICT DO NOTHING;
+
+  -- A linha que faltava. O papel `admin` ganha o catálogo menos o que é do
+  -- dono, DEPOIS da lista — o que a lista já deu continua dado, e o que ela
+  -- esqueceu deixa de importar. Só age se o template realmente tiver um papel
+  -- `admin`: um template sem administrador não passa a ter um por isto.
+  INSERT INTO app.role_permissions (tenant_id, role_id, permission)
+  SELECT p_tenant, r.id, p.key
+    FROM app.roles r
+    CROSS JOIN app.permissions p
+   WHERE r.tenant_id = p_tenant AND r.key = 'admin' AND p.owner_only = false
+  ON CONFLICT DO NOTHING;
+
+  RETURN v_owner;
+END $$;
+
+COMMENT ON FUNCTION app.seed_role_template(uuid, text) IS
+  'Semeia os papéis do template. Owner e Administrador leem o CATÁLOGO (o admin sem o que é do dono); manager/staff/viewer seguem sendo recortes deliberados (029).';
+
+-- ── as casas que já nasceram cegas ─────────────────────────────────────────
+--
+-- A função acima conserta quem nascer daqui para frente. Os dez tenants que já
+-- existem precisam da mesma conta, aplicada agora.
+DO $$
+DECLARE v_admin integer; v_mgr integer;
+BEGIN
+  INSERT INTO app.role_permissions (tenant_id, role_id, permission)
+  SELECT r.tenant_id, r.id, p.key
+    FROM app.roles r
+    CROSS JOIN app.permissions p
+   WHERE r.key = 'admin' AND p.owner_only = false
+  ON CONFLICT DO NOTHING;
+  GET DIAGNOSTICS v_admin = ROW_COUNT;
+
+  -- O gerente é recorte, não catálogo: ele opera a casa, não a administra.
+  -- Recebe ler/criar/editar do que o LeadControl põe no rail, e não recebe
+  -- apagar nem gerir — apagar conversa e gerir integração continuam acima
+  -- dele. `regexp_replace` pega o último segmento porque as chaves têm dois
+  -- formatos no catálogo: `sales.read` e `crm.leads.read`.
+  INSERT INTO app.role_permissions (tenant_id, role_id, permission)
+  SELECT r.tenant_id, r.id, p.key
+    FROM app.roles r
+    CROSS JOIN app.permissions p
+   WHERE r.key = 'manager'
+     AND p.owner_only = false
+     AND p.key ~ '^(crm|sales|conversations|marketing|automations)\.'
+     AND regexp_replace(p.key, '^.*\.', '') IN ('read', 'create', 'edit')
+  ON CONFLICT DO NOTHING;
+  GET DIAGNOSTICS v_mgr = ROW_COUNT;
+
+  RAISE NOTICE '029: % permissões devolvidas ao Administrador, % ao Gerente', v_admin, v_mgr;
+END $$;
+
+-- E o mesmo recorte entra no TEMPLATE do gerente, para o próximo tenant nascer
+-- com ele. O administrador não precisa de linha aqui: ele passou a ler o
+-- catálogo, e uma linha de template para ele seria a lista voltando pela porta
+-- dos fundos.
+INSERT INTO app.role_templates (template, role_key, role_name, sort_order, permission)
+SELECT m.template, 'manager', m.role_name, m.sort_order, p.key
+  FROM (SELECT DISTINCT ON (template) template, role_name, sort_order
+          FROM app.role_templates WHERE role_key = 'manager'
+         ORDER BY template) m
+  CROSS JOIN app.permissions p
+ WHERE p.owner_only = false
+   AND p.key ~ '^(crm|sales|conversations|marketing|automations)\.'
+   AND regexp_replace(p.key, '^.*\.', '') IN ('read', 'create', 'edit')
+   -- NOT EXISTS em vez de ON CONFLICT: esta tabela é um catálogo sem chave
+   -- única declarada, e ali ON CONFLICT DO NOTHING não protege de nada.
+   AND NOT EXISTS (
+     SELECT 1 FROM app.role_templates x
+      WHERE x.template = m.template AND x.role_key = 'manager' AND x.permission = p.key);

package/migrations/031_ticketcontrol_joins_the_family.sql

@@ -0,0 +1,109 @@
+-- ---------------------------------------------------------------------------
+-- 031_ticketcontrol_joins_the_family.sql — a casa de shows ganha uma linha.
+--
+-- O registro tem seis produtos: quatro TRADES (cozinha, loja, estúdio, escola),
+-- uma FUNÇÃO que transbordou de aba para app (LeadControl, 011) e o painel da
+-- própria casa (control-admin, 028). Este é o sétimo, e é um trade — mas um
+-- trade que o ChefControl já toca pela metade.
+--
+-- ── Por que não é uma aba do ChefControl ───────────────────────────────────
+-- Um bar que faz evento já cadastra o cardápio, o estoque e o caixa no Chef. O
+-- que ele NÃO tem lá é o evento: a noite com data, capacidade por setor, lote
+-- que vira lote, ingresso que precisa ser recusado na porta quando já entrou.
+-- Isso não é uma tela a mais num app de restaurante — é outro turno, outra
+-- equipe (guichê, portaria, promoter) e outro fechamento.
+--
+-- E é justamente por serem o MESMO TENANT que os dois convivem: `people`,
+-- `orders`, `items` e o financeiro são os mesmos dos dois lados do switcher. A
+-- pessoa que comprou o ingresso é a que abre comanda no bar, na mesma linha.
+-- Nenhum concorrente brasileiro entrega isso porque nenhum é dono dos dois
+-- lados: a bilheteria (Sympla, Ingresse) larga na porta, e o cashless (Zig)
+-- começa nela.
+--
+-- ── `serves_verticals` fica VAZIO, de propósito ────────────────────────────
+-- A 010 fez dessa coluna o gatilho de semeadura automática: um tenant que
+-- declara um ramo ganha todo app que serve aquele ramo. Listar 'food' e
+-- 'restaurant' aqui seria quase verdade — muito bar faz evento — e significaria
+-- que TODO restaurante criado a partir de amanhã cresceria um segundo produto
+-- no switcher que ninguém pediu e ninguém configurou. Um app que chega sem ser
+-- convidado não é uma funcionalidade, é um chamado de suporte sobre uma tela
+-- vazia. Este é opt-in: `tenant_app_set('ticket', ...)`.
+--
+-- ── `requires` nomeia cinco plugins ────────────────────────────────────────
+-- `menu` e `inventory` são o bar; `orders` é o pedido (do ingresso E da
+-- comanda, na mesma tabela); `financial` é o caixa onde a noite fecha;
+-- `conversations` é por onde o público pergunta a hora de abrir. Sem esses
+-- cinco o app abre num rail com Painel e placeholders.
+--
+-- O que NÃO está aqui: um plugin `events`. Ele nasce em M1 (ver
+-- fayz-app/ticket-control/docs/ROADMAP.md) e é quando esta linha ganha o sexto
+-- nome — a migration que criar as tabelas de evento é a mesma que atualiza este
+-- array.
+-- ---------------------------------------------------------------------------
+
+-- ── §1  a linha do registro ────────────────────────────────────────────────
+--
+-- O nome é o nome de FORA (ADR: "Control" é a família, não o app). O rail
+-- dentro diz só "Ticket"; a lista do switcher é de fora, então carrega inteiro.
+--
+-- #820AD1 e não outro roxo: a ficha É o produto num lançador, e o violeta claro
+-- (#7C3AED) já é do StudioControl. Este é 18° adiante na roda e 23 pontos mais
+-- escuro — lado a lado eles leem como duas cores, não como dois degraus de uma.
+-- O dividendo prático de escolher o degrau ESCURO: branco sobre ele dá 7,2:1, e
+-- a marca pode simplesmente ser o botão (o ouro do Chef não pode).
+--
+-- `url` é a origem de dev enquanto o app não é publicado, e é deliberadamente
+-- visível: a coluna É a allow-list do handoff de sessão, então trocá-la é o
+-- passo de deploy, não um detalhe.
+INSERT INTO app.apps (id, name, icon, accent_color, url, requires, serves_verticals, active) VALUES
+  ('ticket', 'TicketControl', 'Ticket', '#820AD1', 'http://localhost:5308',
+   ARRAY['menu', 'inventory', 'orders', 'financial', 'conversations'],
+   ARRAY[]::text[], true)
+ON CONFLICT (id) DO UPDATE
+  SET name = EXCLUDED.name, icon = EXCLUDED.icon, accent_color = EXCLUDED.accent_color,
+      requires = EXCLUDED.requires, active = true,
+      -- A URL NÃO é sobrescrita numa reaplicação: quem publicar o app aponta a
+      -- coluna para o endereço real, e uma migration que reaplica não pode
+      -- devolver a frota para localhost. (Mesma regra da 028.)
+      url = coalesce(app.apps.url, EXCLUDED.url);
+
+-- ── §2  quem recebe agora ──────────────────────────────────────────────────
+--
+-- Só as contas de creators@fayalabs.com que JÁ têm cardápio ativo — ou seja, as
+-- casas que já operam um bar nesta plataforma, que é a evidência honesta de que
+-- "o bar que também faz evento" é a história delas.
+--
+-- Restrito ao dono do dogfood de propósito, e isto é o que difere da 011: a
+-- LeadControl estava pronta quando ganhou a linha. Este app está em M0 — o rail
+-- é real, metade das telas ainda é placeholder que diz de qual marco é. Ligá-lo
+-- para todo restaurante do cluster seria distribuir um produto pela metade.
+-- Quando M2 fechar (o ingresso vira dinheiro), a regra geral entra numa
+-- migration própria, que é onde ela pode ser revista sozinha.
+INSERT INTO app.tenant_apps (tenant_id, app_id, status, source)
+SELECT DISTINCT m.tenant_id, 'ticket', 'active', 'manual'
+  FROM app.memberships m
+  JOIN auth.users u ON u.id = m.user_id
+ WHERE u.email = 'creators@fayalabs.com'
+   AND m.active
+   AND EXISTS (
+     SELECT 1 FROM app.tenant_plugins tp
+      WHERE tp.tenant_id = m.tenant_id AND tp.plugin_id = 'menu'
+        AND tp.facet = '' AND tp.status = 'active'
+   )
+ON CONFLICT (tenant_id, app_id) DO NOTHING;
+
+-- E os plugins que ele precisa, para exatamente essas contas — senão o app abre
+-- num rail com Painel e nada mais, porque a shell monta o rail com o que
+-- app_config() devolve em `plugins`.
+--
+-- O teto do plano ganha do padrão, sempre: uma conta cujo plano não inclui o
+-- plugin não o acende, e a semeadura não falha por isso.
+INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+SELECT DISTINCT ta.tenant_id, r.plugin_id, '', 'active', 'default'
+  FROM app.tenant_apps ta
+  JOIN app.apps a ON a.id = ta.app_id
+  CROSS JOIN LATERAL unnest(a.requires) AS r(plugin_id)
+ WHERE ta.app_id = 'ticket'
+   AND ta.status = 'active'
+   AND public.plan_permits(r.plugin_id, '', ta.tenant_id)
+ON CONFLICT (tenant_id, plugin_id, facet) DO NOTHING;

package/migrations/032_a_marca_e_um_conjunto_de_tokens.sql

@@ -0,0 +1,291 @@
+-- 032_a_marca_e_um_conjunto_de_tokens.sql
+--
+-- A marca de um tenant tinha DUAS fontes de verdade e TRÊS grafias, e nenhuma
+-- das três conversava com as outras.
+--
+--   `ConnectedBrandingSettings` GRAVA  settings.branding.primaryColor  (camelo)
+--   `admin-app.tsx`             LÊ     settings.branding.primaryColor  (camelo)
+--   `app.branding_of()`         LÊ     settings.branding.primary_color (cobra)
+--
+-- Medido antes desta migration: **nenhum** tenant tinha a chave em camelo, e um
+-- tinha a em cobra (posta por script). Ou seja: a cor que o lojista escolhe em
+-- Configurações nunca chegou ao switcher nem à página pública, e a que existia
+-- nunca chegou ao tema. A tela funcionava; o dado ia para uma gaveta que
+-- ninguém abria.
+--
+-- E, por cima disso, o porte de CRM criou uma SEGUNDA marca — `plg_marketing_brand`
+-- — com nome, tom de voz e palavras proibidas, dentro de um plugin. Duas marcas
+-- para uma casa é pior que nenhuma: mudar a cor num lugar não muda no outro, e
+-- ninguém sabe qual das duas o site está usando.
+--
+-- ── O QUE ESTA MIGRATION ESTABELECE ───────────────────────────────────────
+--
+-- Uma marca é UM CONJUNTO DE TOKENS com três camadas, e a terceira é a que
+-- costuma ficar de fora:
+--
+--   identity  quem a marca é      nome, assinatura, posicionamento, logo
+--   tokens    como ela se parece  cor e tipografia
+--   voice     como ela FALA       tom, léxico, chamadas, palavras proibidas
+--
+-- Voz não é "uma funcionalidade de marketing" — é a dimensão VERBAL do mesmo
+-- conjunto. Um sistema de design que descreve a cor do botão e não descreve o
+-- que o produto pode dizer está descrevendo metade da marca. É por isso que ela
+-- sai do plugin e entra aqui, ao lado da cor.
+--
+-- RETROCOMPATIBILIDADE É OBRIGATÓRIA, e não por educação: `app.branding_of` é
+-- lida por `tenant_branding_public(slug, domain)`, que serve loja pública e
+-- domínio próprio a visitante ANÔNIMO. Uma troca de forma que derrube isso tira
+-- o site do ar de quem já vendeu hoje. Por isso o leitor passa a aceitar as
+-- TRÊS grafias e a saída antiga continua idêntica — o documento em camadas vem
+-- ao lado, não no lugar.
+
+-- ── o leitor tolerante ─────────────────────────────────────────────────────
+--
+-- Uma chave, três lugares onde ela pode estar. A ordem é deliberada: o formato
+-- NOVO primeiro, porque é para onde tudo caminha; depois cobra, que é o que o
+-- resolvedor sempre leu; por último camelo, que é o que a tela sempre gravou.
+CREATE OR REPLACE FUNCTION app.brand_token(p_branding jsonb, p_path text[], p_snake text, p_camel text)
+RETURNS text
+  LANGUAGE sql
+  IMMUTABLE
+  SET search_path TO ''
+AS $$
+  SELECT coalesce(
+    nullif(p_branding #>> p_path, ''),
+    nullif(p_branding ->> p_snake, ''),
+    nullif(p_branding ->> p_camel, '')
+  )
+$$;
+
+COMMENT ON FUNCTION app.brand_token(jsonb, text[], text, text) IS
+  'Lê um token de marca aceitando as três grafias que existiram: o caminho em camadas, cobra e camelo. A tolerância é o que permite mudar a forma sem derrubar a loja pública (032).';
+
+-- ── a marca inteira, normalizada ───────────────────────────────────────────
+CREATE OR REPLACE FUNCTION app.brand_of(p_tenant uuid)
+RETURNS jsonb
+  LANGUAGE plpgsql
+  STABLE
+  SECURITY DEFINER
+  SET search_path TO ''
+AS $$
+DECLARE t record; b jsonb;
+BEGIN
+  SELECT x.id, x.name, x.slug, x.logo_url, x.settings INTO t
+    FROM public.tenants x WHERE x.id = p_tenant;
+  IF t.id IS NULL THEN RETURN NULL; END IF;
+
+  b := coalesce(t.settings -> 'branding', '{}'::jsonb);
+
+  RETURN jsonb_strip_nulls(jsonb_build_object(
+    'identity', jsonb_build_object(
+      'name',      coalesce(app.brand_token(b, '{identity,name}', 'app_name', 'appName'), t.name),
+      'tagline',   app.brand_token(b, '{identity,tagline}', 'tagline', 'tagline'),
+      'mission',   app.brand_token(b, '{identity,mission}', 'mission', 'mission'),
+      'logoUrl',   coalesce(app.brand_token(b, '{identity,logoUrl}', 'logo_url', 'logoUrl'), t.logo_url),
+      'faviconUrl',app.brand_token(b, '{identity,faviconUrl}', 'favicon_url', 'faviconUrl'),
+      'customDomain', app.brand_token(b, '{identity,customDomain}', 'custom_domain', 'customDomain')
+    ),
+    'tokens', jsonb_build_object(
+      'color', jsonb_strip_nulls(jsonb_build_object(
+        'primary', app.brand_token(b, '{tokens,color,primary}', 'primary_color', 'primaryColor'),
+        'accent',  app.brand_token(b, '{tokens,color,accent}',  'accent_color',  'accentColor')
+      )),
+      'font', jsonb_strip_nulls(jsonb_build_object(
+        'heading', app.brand_token(b, '{tokens,font,heading}', 'heading_font', 'headingFont'),
+        'body',    app.brand_token(b, '{tokens,font,body}',    'body_font',    'bodyFont')
+      ))
+    ),
+    -- A camada verbal. Arrays e não texto livre: o agente compara termo a
+    -- termo, e "evite gírias" não é comparável.
+    'voice', jsonb_strip_nulls(jsonb_build_object(
+      'tone',     app.brand_token(b, '{voice,tone}', 'tone_of_voice', 'toneOfVoice'),
+      'lexicon',  b #> '{voice,lexicon}',
+      'avoid',    b #> '{voice,avoid}',
+      'ctas',     b #> '{voice,ctas}',
+      'hashtags', b #> '{voice,hashtags}'
+    ))
+  ));
+END $$;
+
+COMMENT ON FUNCTION app.brand_of(uuid) IS
+  'A marca como conjunto de tokens em três camadas: identity, tokens (cor/tipografia) e voice. Voz é a dimensão VERBAL do mesmo conjunto, não uma funcionalidade de marketing (032).';
+
+REVOKE ALL ON FUNCTION app.brand_of(uuid) FROM PUBLIC, anon;
+
+-- ── o resolvedor antigo continua idêntico por fora ─────────────────────────
+--
+-- Mesmas chaves, mesma forma. O que muda é que ele passa a ENXERGAR o que a
+-- tela sempre gravou: antes lia só `primary_color`, e a tela gravava
+-- `primaryColor`. É esta linha que faz a cor escolhida em Configurações chegar
+-- ao switcher e à loja pública pela primeira vez.
+CREATE OR REPLACE FUNCTION app.branding_of(p_tenant uuid) RETURNS jsonb
+    LANGUAGE plpgsql STABLE SECURITY DEFINER
+    SET search_path TO ''
+    AS $$
+DECLARE t record; b jsonb;
+BEGIN
+  SELECT x.id, x.name, x.slug, x.logo_url, x.settings INTO t FROM public.tenants x WHERE x.id = p_tenant;
+  IF t.id IS NULL THEN
+    RETURN jsonb_build_object('tenant_id', NULL, 'name', NULL, 'slug', NULL, 'logo_url', NULL, 'primary_color', NULL, 'custom_domain', NULL);
+  END IF;
+  b := coalesce(t.settings -> 'branding', '{}'::jsonb);
+  RETURN jsonb_build_object(
+    'tenant_id', t.id,
+    'name',  coalesce(app.brand_token(b, '{identity,name}', 'app_name', 'appName'), t.name),
+    'slug',  t.slug,
+    'logo_url', coalesce(app.brand_token(b, '{identity,logoUrl}', 'logo_url', 'logoUrl'), t.logo_url),
+    'primary_color', app.brand_token(b, '{tokens,color,primary}', 'primary_color', 'primaryColor'),
+    'custom_domain', app.brand_token(b, '{identity,customDomain}', 'custom_domain', 'customDomain')
+  );
+EXCEPTION WHEN OTHERS THEN
+  RETURN jsonb_build_object('tenant_id', p_tenant, 'name', NULL, 'slug', NULL, 'logo_url', NULL, 'primary_color', NULL, 'custom_domain', NULL,
+                            'error', 'branding unavailable');
+END $$;
+
+-- ── a marca, para quem está dentro ─────────────────────────────────────────
+CREATE OR REPLACE FUNCTION public.tenant_brand() RETURNS jsonb
+  LANGUAGE plpgsql STABLE SECURITY DEFINER
+  SET search_path TO ''
+AS $$
+BEGIN
+  RETURN coalesce(app.brand_of(app.current_tenant_id()), '{}'::jsonb);
+EXCEPTION WHEN OTHERS THEN
+  RETURN '{}'::jsonb;
+END $$;
+
+COMMENT ON FUNCTION public.tenant_brand() IS
+  'A marca em camadas do tenant da sessão. Consumidores: tema da shell (tokens.color), agente (voice), páginas públicas (tudo) (032).';
+
+REVOKE ALL ON FUNCTION public.tenant_brand() FROM PUBLIC, anon;
+GRANT EXECUTE ON FUNCTION public.tenant_brand() TO authenticated;
+GRANT EXECUTE ON FUNCTION public.tenant_brand() TO service_role;
+
+-- ── escrever uma camada sem apagar as outras ───────────────────────────────
+--
+-- A tela salva por SEÇÃO — cores, ou voz, ou identidade. Um `update` que troca
+-- `settings.branding` inteiro faria salvar a aba de cores apagar o tom de voz
+-- que outra pessoa acabou de escrever. Fundir por caminho é o que impede isso.
+CREATE OR REPLACE FUNCTION public.tenant_brand_patch(p_patch jsonb)
+RETURNS jsonb
+  LANGUAGE plpgsql
+  SECURITY DEFINER
+  SET search_path TO ''
+AS $$
+DECLARE v_tenant uuid := app.current_tenant_id();
+BEGIN
+  IF v_tenant IS NULL THEN
+    RAISE EXCEPTION 'tenant_brand_patch: sem tenant na sessão' USING ERRCODE = '42501';
+  END IF;
+  -- `settings.edit` e não `tenant.edit`: a marca é configuração da casa, e quem
+  -- mexe nela é quem mexe nas configurações.
+  IF NOT app.has_permission('settings.edit', NULL::uuid) THEN
+    RAISE EXCEPTION 'tenant_brand_patch: exige settings.edit' USING ERRCODE = '42501';
+  END IF;
+
+  UPDATE public.tenants t
+     SET settings = jsonb_set(
+           coalesce(t.settings, '{}'::jsonb),
+           '{branding}',
+           -- `||` funde raso, e é o que se quer POR CAMADA: mandar
+           -- {"voice":{...}} troca a voz inteira e não toca em tokens. Mandar
+           -- {"tokens":{"color":{...}}} trocaria `tokens` inteiro, então a tela
+           -- manda a camada `tokens` completa quando mexe em qualquer cor.
+           coalesce(t.settings -> 'branding', '{}'::jsonb) || coalesce(p_patch, '{}'::jsonb)
+         ),
+         updated_at = now()
+   WHERE t.id = v_tenant;
+
+  RETURN coalesce(app.brand_of(v_tenant), '{}'::jsonb);
+END $$;
+
+COMMENT ON FUNCTION public.tenant_brand_patch(jsonb) IS
+  'Funde uma camada da marca sem apagar as outras — salvar a aba de cores não pode apagar o tom de voz de quem escreveu antes (032).';
+
+REVOKE ALL ON FUNCTION public.tenant_brand_patch(jsonb) FROM PUBLIC, anon;
+GRANT EXECUTE ON FUNCTION public.tenant_brand_patch(jsonb) TO authenticated;
+GRANT EXECUTE ON FUNCTION public.tenant_brand_patch(jsonb) TO service_role;
+
+-- ── a segunda marca vem para casa ──────────────────────────────────────────
+--
+-- `plg_marketing_brand` durou uma onda. Ela nasceu com o kit de marca do porte
+-- do V1, num plugin, sem saber que o núcleo já tinha uma marca com resolvedor e
+-- três consumidores. As linhas dela entram na camada certa e a tabela sai — não
+-- fica como view: uma segunda porta para a mesma coisa é justamente o que esta
+-- migration existe para desfazer.
+--
+-- A fusão preserva o que já estivesse em `settings.branding`: o kit do plugin
+-- perde para a configuração do núcleo em caso de conflito, porque é a do núcleo
+-- que o tema e a loja pública leem hoje.
+DO $$
+DECLARE r record; v_patch jsonb; v_n integer := 0;
+BEGIN
+  IF to_regclass('public.plg_marketing_brand') IS NULL THEN RETURN; END IF;
+
+  FOR r IN SELECT * FROM public.plg_marketing_brand LOOP
+    v_patch := jsonb_strip_nulls(jsonb_build_object(
+      'identity', jsonb_strip_nulls(jsonb_build_object(
+        'name', nullif(btrim(coalesce(r.name, '')), ''),
+        'tagline', nullif(btrim(coalesce(r.tagline, '')), ''),
+        'mission', nullif(btrim(coalesce(r.mission, '')), ''),
+        'logoUrl', nullif(btrim(coalesce(r.logo_url, '')), '')
+      )),
+      -- A COR DO PLUGIN SÓ ENTRA SE O NÚCLEO NÃO TIVER UMA.
+      --
+      -- `||` funde raso e não sobrescreve caminho diferente: com a cor do
+      -- núcleo em `branding.primaryColor` (plana) e a do plugin em
+      -- `branding.tokens.color.primary` (em camadas), AS DUAS sobrevivem — e o
+      -- leitor tolerante prefere a forma nova, então a do plugin venceria.
+      -- Isto foi pego no container: `#FF0000` do plugin passou na frente do
+      -- `#2563EB` do núcleo. Quem manda é o núcleo, porque é o que o tema e a
+      -- loja pública leem hoje.
+      'tokens', jsonb_strip_nulls(jsonb_build_object(
+        'color', CASE
+          WHEN app.brand_token((SELECT x.settings -> 'branding' FROM public.tenants x WHERE x.id = r.tenant_id),
+                               '{tokens,color,primary}', 'primary_color', 'primaryColor') IS NULL
+          THEN nullif(coalesce(r.colors, '{}'::jsonb), '{}'::jsonb)
+        END,
+        'font',  nullif(coalesce(r.fonts,  '{}'::jsonb), '{}'::jsonb)
+      )),
+      'voice', jsonb_strip_nulls(jsonb_build_object(
+        'tone', nullif(btrim(coalesce(r.tone_of_voice, '')), ''),
+        'lexicon',  to_jsonb(coalesce(r.keywords,    ARRAY[]::text[])),
+        'avoid',    to_jsonb(coalesce(r.avoid_words, ARRAY[]::text[])),
+        'ctas',     to_jsonb(coalesce(r.ctas,        ARRAY[]::text[])),
+        'hashtags', to_jsonb(coalesce(r.hashtags,    ARRAY[]::text[]))
+      ))
+    ));
+
+    UPDATE public.tenants t
+       SET settings = jsonb_set(
+             coalesce(t.settings, '{}'::jsonb), '{branding}',
+             -- `patch || existente` deixa o que já estava vencer NO MESMO
+             -- caminho. Para caminhos diferentes (plana × camadas) a defesa é
+             -- o CASE acima, na montagem do patch.
+             v_patch || coalesce(t.settings -> 'branding', '{}'::jsonb))
+     WHERE t.id = r.tenant_id;
+    v_n := v_n + 1;
+  END LOOP;
+
+  RAISE NOTICE '032: % kit(s) de marca trazidos do plugin para o núcleo', v_n;
+END $$;
+
+DROP TABLE IF EXISTS public.plg_marketing_brand;
+DELETE FROM app.scaffold_registry WHERE table_name = 'plg_marketing_brand';
+
+-- ── a grafia velha, normalizada de uma vez ─────────────────────────────────
+--
+-- O leitor tolera as três grafias para sempre — é o que protege quem tiver dado
+-- antigo. Mas os tenants que existem HOJE ganham a forma nova agora, para que a
+-- tela edite e leia o mesmo lugar desde o primeiro clique.
+UPDATE public.tenants t
+   SET settings = jsonb_set(
+         coalesce(t.settings, '{}'::jsonb), '{branding}',
+         jsonb_strip_nulls(jsonb_build_object(
+           'tokens', jsonb_build_object('color', jsonb_strip_nulls(jsonb_build_object(
+             'primary', app.brand_token(t.settings -> 'branding', '{tokens,color,primary}', 'primary_color', 'primaryColor'),
+             'accent',  app.brand_token(t.settings -> 'branding', '{tokens,color,accent}',  'accent_color',  'accentColor')
+           )))
+         )) || coalesce(t.settings -> 'branding', '{}'::jsonb))
+ WHERE t.settings -> 'branding' IS NOT NULL
+   AND app.brand_token(t.settings -> 'branding', '{tokens,color,primary}', 'primary_color', 'primaryColor') IS NOT NULL
+   AND t.settings #>> '{branding,tokens,color,primary}' IS NULL;

package/migrations/041_a_entrega_tem_onde_guardar_a_politica.sql

@@ -0,0 +1,53 @@
+-- ---------------------------------------------------------------------------
+-- 041_a_entrega_tem_onde_guardar_a_politica.sql — o quadro de Delivery existe
+-- desde sempre e a política dele não tinha onde morar.
+--
+-- ── O defeito ──────────────────────────────────────────────────────────────
+-- Taxa de entrega, pedido mínimo, tempo estimado e raio são decisões da CASA:
+-- mudam com a estação, com o combustível e com o bairro. Não estavam em lugar
+-- nenhum — o app desenhava um interruptor de Delivery em `useState`, que volta
+-- ao padrão a cada F5, e o resto era combinado por telefone.
+--
+-- ── A escolha ──────────────────────────────────────────────────────────────
+-- `tenants.settings` (150/ADR 0023) já é onde a conta guarda o que muda sem
+-- deploy, com `tenant_setting_set` cobrando `settings.manage` e conferindo o
+-- tipo. Só faltava a chave existir: a função recusa chave não registrada, de
+-- propósito, para que um erro de digitação no cliente não vire uma
+-- configuração fantasma que ninguém lê.
+--
+-- Registradas com `reader = 'plugin:orders'`: quem as lê é o plugin de
+-- pedidos, e é ele quem some junto se um dia o app não montar delivery.
+-- ---------------------------------------------------------------------------
+
+SELECT app.seed_setting_keys($$[
+  {
+    "key": "delivery.enabled", "type": "boolean", "default": true,
+    "reader": "plugin:orders",
+    "description": "Se a casa entrega. Desligado, o quadro de despacho segue existindo para o histórico e nenhum canal novo nasce como entrega."
+  },
+  {
+    "key": "delivery.fee", "type": "number", "default": 0,
+    "reader": "plugin:orders",
+    "description": "Taxa de entrega padrão, na moeda da casa. Zero = entrega sem taxa."
+  },
+  {
+    "key": "delivery.free_over", "type": "number", "default": null,
+    "reader": "plugin:orders",
+    "description": "Acima deste valor de pedido a taxa é zerada. Nulo = a taxa vale sempre."
+  },
+  {
+    "key": "delivery.min_order", "type": "number", "default": 0,
+    "reader": "plugin:orders",
+    "description": "Pedido mínimo para entregar. Zero = sem mínimo."
+  },
+  {
+    "key": "delivery.eta_minutes", "type": "integer", "default": 45,
+    "reader": "plugin:orders",
+    "description": "Tempo estimado de entrega, em minutos — o que o cliente ouve quando pergunta."
+  },
+  {
+    "key": "delivery.radius_km", "type": "number", "default": 0,
+    "reader": "plugin:orders",
+    "description": "Raio de entrega em quilômetros. Zero = sem limite declarado."
+  }
+]$$::jsonb);

package/migrations/042_o_token_de_marca_fecha_a_porta_anon.sql

@@ -0,0 +1,17 @@
+-- ---------------------------------------------------------------------------
+-- 042_o_token_de_marca_fecha_a_porta_anon.sql
+--
+-- A 032 criou app.brand_token como helper interno, mas funções novas do
+-- PostgreSQL nascem executáveis por PUBLIC. Isso deixou `anon` chamar uma
+-- função do schema privado `app` e fez a postura N15c ficar vermelha.
+--
+-- A correção não pode morar retroativamente na 032: os clusters ChefControl
+-- já registraram o checksum original dela em public._migrations. Editar um
+-- arquivo aplicado produz drift e faz `fayz db apply` parar antes de alcançar
+-- qualquer correção posterior. Por isso a 032 mantém seus bytes históricos e
+-- esta migration nova fecha a permissão nos bancos existentes.
+-- ---------------------------------------------------------------------------
+
+REVOKE ALL
+  ON FUNCTION app.brand_token(jsonb, text[], text, text)
+  FROM PUBLIC, anon;