@fayz-ai/db 0.14.0 → 0.15.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;

package/migrations/043_fiscalcontrol_joins_the_family.sql

@@ -0,0 +1,75 @@
+-- ---------------------------------------------------------------------------
+-- 043_fiscalcontrol_joins_the_family.sql — a contabilidade ganha uma linha.
+--
+-- O oitavo produto do registro, e o segundo que é FUNÇÃO e não trade (como o
+-- LeadControl, 011): FiscalControl é o escritório de contabilidade da família.
+-- Todo tenant que opera um Control já produz o material contábil sem saber —
+-- partida dobrada em plg_financial_movements, balancete em
+-- v_financial_trial_balance, imposto por linha em plg_financial_invoice_item_taxes.
+-- O que falta é o app que olha esse material como um contador olha: plano de
+-- contas, lançamento, DRE, apuração. Com a reforma tributária tornando o
+-- destaque de IBS/CBS obrigatório em agosto/2026, esse olhar deixa de ser
+-- opcional para qualquer tenant fora do Simples.
+--
+-- ── `serves_verticals` fica VAZIO, de propósito ────────────────────────────
+-- Contabilidade não é um ramo, é uma função que atravessa todos. Semear por
+-- vertical (010) daria um app de contador para todo restaurante novo — uma tela
+-- de balancete que ninguém pediu. Este é opt-in: quem liga é `tenant_app_set`
+-- ou a mão da casa.
+--
+-- ── `requires` nomeia um plugin só ─────────────────────────────────────────
+-- `financial` é o razão inteiro: invoices, movimentos, plano de contas, caixa.
+-- Sem ele o rail é Painel e placeholders. `reports` e `fiscal-br` entram como
+-- opt-in quando os marcos M3/M4 fecharem — a migration que criar as telas é a
+-- que atualiza este array (mesma regra da 031).
+-- ---------------------------------------------------------------------------
+
+-- ── §1  a linha do registro ────────────────────────────────────────────────
+--
+-- #334155 (slate): o único setor sóbrio ainda livre na roda — os oito vizinhos
+-- já tomaram vermelho, ouro, verde, dois roxos, azul e teal. Combina com o que
+-- o app é: o produto sério da família. Branco sobre ele dá 9,6:1.
+--
+-- `url` é a origem de dev enquanto o app não é publicado; a coluna é a
+-- allow-list do handoff, e o coalesce impede que uma reaplicação devolva uma
+-- frota publicada para localhost (regra da 028/031).
+INSERT INTO app.apps (id, name, icon, accent_color, url, requires, serves_verticals, active) VALUES
+  ('fiscal', 'FiscalControl', 'Calculator', '#334155', 'http://localhost:5313',
+   ARRAY['financial'],
+   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,
+      url = coalesce(app.apps.url, EXCLUDED.url);
+
+-- ── §2  quem recebe agora ──────────────────────────────────────────────────
+--
+-- Só as contas do dogfood que JÁ têm o financeiro ativo — a evidência honesta
+-- de que existe um razão para o contador ler. O app está em M0; distribuir para
+-- o cluster inteiro seria entregar um produto pela metade (regra da 031). O
+-- tenant ControlGroup, criado fora desta migration por platform_tenant_create,
+-- entra pelo p_apps da própria chamada.
+INSERT INTO app.tenant_apps (tenant_id, app_id, status, source)
+SELECT DISTINCT m.tenant_id, 'fiscal', '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 = 'financial'
+        AND tp.facet = '' AND tp.status = 'active'
+   )
+ON CONFLICT (tenant_id, app_id) DO NOTHING;
+
+-- E o plugin que ele precisa, para exatamente essas contas. O teto do plano
+-- ganha do padrão, sempre.
+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 = 'fiscal'
+   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/044_o_teste_gratis_dura_trinta_dias.sql

@@ -0,0 +1,15 @@
+-- ---------------------------------------------------------------------------
+-- 044_o_teste_gratis_dura_trinta_dias.sql
+--
+-- A família Control abre para signup público e a promessa comercial passa a
+-- ser "30 dias grátis" — 7 dias não dão para um restaurante montar cardápio,
+-- treinar a equipe e rodar um mês de pedidos.
+--
+-- O prazo vive num único lugar: o DEFAULT da coluna. Só tenants NOVOS são
+-- afetados; quem já tem data estampada mantém a sua, e quem nasceu antes do
+-- trial (NULL) continua sem trial — nunca "expirado". O trigger
+-- tenants_trial_is_readonly segue impedindo escrita client-side na data.
+-- ---------------------------------------------------------------------------
+
+ALTER TABLE public.tenants
+  ALTER COLUMN trial_ends_at SET DEFAULT (now() + interval '30 days');

package/migrations/046_the_tick_advances_the_flows.sql

@@ -0,0 +1,77 @@
+-- 046_the_tick_advances_the_flows.sql
+--
+-- A cadence needs a clock, and the database already has one: `fayz_event_runner`
+-- is a pg_cron job calling `event_runner_tick(200)` every minute. What it does
+-- not have is a call to the thing that advances a multi-step flow.
+--
+-- Fifth call, same shape as the other four: guarded by `to_regprocedure`, so a
+-- pool without plugin-automations ticks exactly as it does today. The guard is
+-- the whole reason this belongs in the spine rather than in the plugin — the
+-- tick is one function, and a plugin cannot append to it.
+--
+-- ORDER MATTERS, AND IT IS DELIBERATE. The flows run AFTER `notifications_drain`
+-- and not before. A step enqueues with `scheduled_for = now()`, so draining
+-- first means a step enqueued on this tick waits for the next one — sixty
+-- seconds, once, at the start of a cadence that spans days. Running the flows
+-- first would instead let a step be enqueued and drained in the same tick,
+-- which sounds better and is not: the drain would be doing work the advisory
+-- lock is already holding the whole database's tick for, and a slow provider
+-- would then delay every other plugin's due work behind it. Cheap latency,
+-- bought with predictable tick length.
+--
+-- The limit is 50 rather than the caller's `p_limit`. A cadence step is a write
+-- plus an enqueue; two hundred of them in one tick is a long transaction under
+-- an advisory lock that stops everything else. `marketing_run_due(20)` made the
+-- same trade for the same reason.
+
+CREATE OR REPLACE FUNCTION public.event_runner_tick(p_limit integer DEFAULT 200) RETURNS jsonb
+    LANGUAGE plpgsql SECURITY DEFINER
+    SET search_path TO ''
+    AS $_$
+DECLARE
+  v_lock    boolean;
+  v_events  record;
+  v_notif   record;
+  v_out     jsonb := '{}'::jsonb;
+  v_extra   jsonb;
+  v_start   timestamptz := clock_timestamp();
+BEGIN
+  -- 1 tick at a time per database. A second caller returns immediately rather
+  -- than waiting, so a cron that fires while the previous one is still going
+  -- does not queue up behind it.
+  SELECT pg_try_advisory_xact_lock(hashtextextended('fayz.event_runner', 0)) INTO v_lock;
+  IF NOT v_lock THEN
+    RETURN jsonb_build_object('skipped', 'another tick is running');
+  END IF;
+
+  SELECT * INTO v_events FROM public.consume_event_log(p_limit);
+  v_out := v_out || jsonb_build_object('events', to_jsonb(v_events));
+
+  -- The notification queue drains in its OWN pass. A provider timing out costs
+  -- a retry there and must never hold up the event log — which is why these are
+  -- two functions and not one loop.
+  IF to_regprocedure('public.notifications_drain(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT * FROM public.notifications_drain($1)' INTO v_notif USING p_limit;
+    v_out := v_out || jsonb_build_object('notifications', to_jsonb(v_notif));
+  END IF;
+
+  -- Campaigns, scheduled reports and cadence flows ENQUEUE; they never send. So
+  -- they run on the same tick as the log and drain through the same
+  -- notification queue.
+  IF to_regprocedure('public.marketing_run_due(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT public.marketing_run_due(20)' INTO v_extra;
+    v_out := v_out || jsonb_build_object('marketing', v_extra);
+  END IF;
+
+  IF to_regprocedure('public.reports_deliver_due(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT public.reports_deliver_due(50)' INTO v_extra;
+    v_out := v_out || jsonb_build_object('reports', v_extra);
+  END IF;
+
+  IF to_regprocedure('public.automations_flows_run_due(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT public.automations_flows_run_due(50)' INTO v_extra;
+    v_out := v_out || jsonb_build_object('flows', v_extra);
+  END IF;
+
+  RETURN v_out || jsonb_build_object('took_ms', (extract(epoch FROM clock_timestamp() - v_start) * 1000)::integer);
+END $_$;

package/migrations/047_the_tick_sweeps_the_offers.sql

@@ -0,0 +1,74 @@
+-- 047_the_tick_sweeps_the_offers.sql
+--
+-- Sixth call on the minute tick: expiring a lead offer that nobody took.
+--
+-- A five-minute window means the sweep's resolution has to be finer than the
+-- window, and one minute is what the runner already gives. A rep therefore gets
+-- their full five minutes and loses the lead within sixty seconds of the window
+-- closing — which is the behaviour the rota is sold on.
+--
+-- It runs LAST, after the flows. Both write, and the offer sweep can cascade —
+-- one expiry creating the next offer — so it is the call most likely to be slow
+-- on a busy tenant. Last means a slow sweep delays nothing but itself.
+--
+-- The whole function is restated because a plugin cannot append to it, and
+-- `CREATE OR REPLACE` needs the entire body. Migration 046 added the flows call
+-- immediately before this one; if this file is ever reordered ahead of it, the
+-- flows call disappears.
+
+CREATE OR REPLACE FUNCTION public.event_runner_tick(p_limit integer DEFAULT 200) RETURNS jsonb
+    LANGUAGE plpgsql SECURITY DEFINER
+    SET search_path TO ''
+    AS $_$
+DECLARE
+  v_lock    boolean;
+  v_events  record;
+  v_notif   record;
+  v_out     jsonb := '{}'::jsonb;
+  v_extra   jsonb;
+  v_start   timestamptz := clock_timestamp();
+BEGIN
+  -- 1 tick at a time per database. A second caller returns immediately rather
+  -- than waiting, so a cron that fires while the previous one is still going
+  -- does not queue up behind it.
+  SELECT pg_try_advisory_xact_lock(hashtextextended('fayz.event_runner', 0)) INTO v_lock;
+  IF NOT v_lock THEN
+    RETURN jsonb_build_object('skipped', 'another tick is running');
+  END IF;
+
+  SELECT * INTO v_events FROM public.consume_event_log(p_limit);
+  v_out := v_out || jsonb_build_object('events', to_jsonb(v_events));
+
+  -- The notification queue drains in its OWN pass. A provider timing out costs
+  -- a retry there and must never hold up the event log — which is why these are
+  -- two functions and not one loop.
+  IF to_regprocedure('public.notifications_drain(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT * FROM public.notifications_drain($1)' INTO v_notif USING p_limit;
+    v_out := v_out || jsonb_build_object('notifications', to_jsonb(v_notif));
+  END IF;
+
+  -- Campaigns, scheduled reports and cadence flows ENQUEUE; they never send. So
+  -- they run on the same tick as the log and drain through the same
+  -- notification queue.
+  IF to_regprocedure('public.marketing_run_due(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT public.marketing_run_due(20)' INTO v_extra;
+    v_out := v_out || jsonb_build_object('marketing', v_extra);
+  END IF;
+
+  IF to_regprocedure('public.reports_deliver_due(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT public.reports_deliver_due(50)' INTO v_extra;
+    v_out := v_out || jsonb_build_object('reports', v_extra);
+  END IF;
+
+  IF to_regprocedure('public.automations_flows_run_due(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT public.automations_flows_run_due(50)' INTO v_extra;
+    v_out := v_out || jsonb_build_object('flows', v_extra);
+  END IF;
+
+  IF to_regprocedure('public.crm_offers_sweep(integer)') IS NOT NULL THEN
+    EXECUTE 'SELECT public.crm_offers_sweep(100)' INTO v_extra;
+    v_out := v_out || jsonb_build_object('offers', v_extra);
+  END IF;
+
+  RETURN v_out || jsonb_build_object('took_ms', (extract(epoch FROM clock_timestamp() - v_start) * 1000)::integer);
+END $_$;

package/migrations/052_fullcontrol_joins_the_family.sql

@@ -0,0 +1,213 @@
+-- ---------------------------------------------------------------------------
+-- 052_fullcontrol_joins_the_family.sql — o funil vira a casa inteira.
+--
+-- A 011 deu uma linha ao LeadControl porque o funil tinha transbordado de uma
+-- aba dentro do app do ofício. O que transbordou agora é o app inteiro: a
+-- mesma base que guarda o lead guarda o título, o saldo de estoque e a nota, e
+-- o produto que olha tudo isso de uma vez não é um CRM — é um ERP. Este
+-- arquivo é o registro admitindo isso.
+--
+-- O recorte também mudou de público. Os outros Controls são OFÍCIOS (cozinha,
+-- loja, estúdio, escola, bilheteria, escritório de contabilidade). Este é para
+-- a empresa cujo RAMO não é o assunto do software — a distribuidora, a
+-- confecção, a prestadora, a indústria pequena. Elas não precisam de um app
+-- que entenda de comida; precisam de um que entenda de conta a pagar.
+--
+-- ── Por que um ID NOVO e não um UPDATE no 'crm' ────────────────────────────
+--
+-- `app.apps.id` é chave, e `app.tenant_apps.app_id` é a única FK que aponta
+-- para ela (001 §2, ON DELETE RESTRICT) — então trocar o id é ADITIVO e
+-- reversível, e custa as poucas linhas do §2. O que não é reversível é o que
+-- sobra se não trocarmos: um app cujo id é o nome de UM dos seus módulos,
+-- numa linha que passaria a ler `id = 'crm' … requires ARRAY['crm', …]` — um
+-- app que exige a si mesmo. `tenant_app_set('crm')`, `tenant_plugin_set('crm')`
+-- e `plan_permits('crm')` continuariam querendo dizer três coisas diferentes.
+--
+-- Hoje é o dia mais barato para fazer isso: `url` ainda é `localhost`, nenhum
+-- domínio de cliente aponta para cá, e não existe união de ids em TypeScript
+-- (packages/admin/src/directory/app-id.ts é explícito: "a rename is a row, not
+-- a release"). O que o app lê é `VITE_APP_ID`, e ele acompanha este arquivo.
+--
+-- A linha antiga NÃO é apagada — é APOSENTADA (§3). A FK a protege, as linhas
+-- de `app.tenant_apps` com app_id='crm' são o histórico de quem teve o produto,
+-- e enquanto elas existirem a volta atrás é um UPDATE e não um INSERT.
+--
+-- ── `serves_verticals` fica VAZIO, e agora o argumento é o OPOSTO ──────────
+--
+-- Nas 011/031/043 o array ficou vazio porque aquele app servia a um recorte.
+-- Aqui ele fica vazio porque o app serve a TODOS — e é exatamente por isso que
+-- semear por vertical (010) seria o pior erro possível: todo restaurante criado
+-- amanhã acordaria com um segundo produto no switcher, com financeiro e estoque
+-- acesos que ninguém configurou. Um app que chega sem ser convidado não é
+-- funcionalidade, é chamado de suporte. Opt-in via `tenant_app_set('full', …)`.
+--
+-- ── `requires` cresce em DEGRAUS, um marco por vez ─────────────────────────
+--
+-- Regra da 031/043: o array ganha um plugin no arquivo que traz as telas dele.
+-- Aqui ele nomeia o que o bundle do app JÁ monta hoje (src/config/app.tsx):
+-- crm, conversations, marketing, automations, notifications, reports,
+-- financial e inventory.
+--
+-- E há um motivo mais duro para não listar o resto de uma vez:
+-- **app.tenant_plugins não tem app_id**. Um plugin exigido aqui acende para o
+-- TENANT, e aparece em qualquer outro Control que aquele tenant rode e que
+-- empacote o mesmo plugin. Agenda, tasks, forms e orders entram quando este app
+-- desenhar as telas deles.
+--
+-- Os addons ficam de fora por definição: `fiscal-br` e `banking-br` são opt-in
+-- contratados, e o que entra em `requires` é ligado para todo mundo.
+--
+-- ── O que a 011 dizia sobre `financial`, e por que caiu ────────────────────
+--
+-- A 011 recusou `financial` com o argumento certo para o produto de então:
+-- "um negócio ganho neste produto passa a bola para o app que é dono do
+-- dinheiro; duplicar o razão aqui daria duas portas de entrada para a mesma
+-- fatura." O argumento não mudou — mudou de lado. **O FullControl É o app que
+-- é dono do dinheiro.** O orçamento aprovado no CRM vira título e aterrissa em
+-- /financial/receivables/detail/:id sem sair do app, e é a mesma linha de
+-- `plg_financial_invoices` que o ChefControl do mesmo tenant leria.
+-- ---------------------------------------------------------------------------
+
+-- ── §1  a linha nova ───────────────────────────────────────────────────────
+--
+-- #1E3A8A (blue-900) e não o teal que este arquivo carregou por uma tarde: o
+-- CourseControl está com #0D9488 no cluster — a linha divergiu do âmbar que a
+-- 001 deu a ele —, e dois teais no launcher leem como um produto em dois tons.
+-- Também não é o #2563EB do LeadControl por acaso: é ele um degrau mais grave.
+-- Para as nove contas que já tinham o ladrilho azul, o produto CRESCEU; a cor
+-- diz produção onde a antiga dizia vendas. Branco sobre ele dá 10,4:1.
+--
+-- 'Layers' existe no registro CURADO de ícones (packages/ui/src/icons.ts) —
+-- conferido, e não é zelo: 'Scissors', que a 001 deu ao StudioControl, NÃO
+-- existe lá, e aquele ladrilho desenha iniciais desde então, sem erro nenhum.
+-- Camadas sobre uma base é a figura literal de um ERP: vários módulos sobre um
+-- tenant só. Um FullControlMark próprio entra quando existir marca em livro —
+-- inventar um SVG que todos os irmãos passam a desenhar é pior que um glifo
+-- bem escolhido (foi o que a 012 pagou para o ChefControl, e só depois do
+-- brand book).
+--
+-- `url` é a origem de dev; a coluna é a allow-list do handoff, e o coalesce
+-- impede que uma reaplicação devolva uma frota publicada para localhost
+-- (regra da 031/043).
+INSERT INTO app.apps (id, name, icon, accent_color, url, requires, serves_verticals, active) VALUES
+  ('full', 'FullControl', 'Layers', '#1E3A8A', 'http://localhost:5307',
+   ARRAY['crm', 'conversations', 'marketing', 'automations', 'notifications',
+         'reports', 'financial', 'inventory'],
+   ARRAY[]::text[], true)
+ON CONFLICT (id) DO UPDATE
+  SET name = EXCLUDED.name, icon = EXCLUDED.icon, accent_color = EXCLUDED.accent_color,
+      active = true,
+      -- `requires` só CRESCE numa reaplicação: um marco posterior pode ter
+      -- somado um plugin depois deste arquivo, e sobrescrever aqui desfaria
+      -- aquele marco em silêncio.
+      requires = (SELECT array_agg(DISTINCT p ORDER BY p)
+                    FROM unnest(app.apps.requires || EXCLUDED.requires) AS p),
+      url = coalesce(app.apps.url, EXCLUDED.url);
+
+COMMENT ON TABLE app.apps IS
+  'Which applications exist on this cluster (001, 011, 043, 052). The registry the app switcher reads. An app is a LENS over a tenant''s rows — it never scopes them; two apps on one tenant share public.people by design. `requires` names the plugins the app cannot work without, and it is a SEEDING list, not a dependency check — app.tenant_plugins has no app_id, so a plugin required here is lit for the whole tenant. `url` doubles as the allow-list for the session handoff; NULL takes the app off every switcher. `active = false` retires a row without breaking the FK from app.tenant_apps.';
+
+-- ── §2  quem recebe: exatamente quem tinha o LeadControl ───────────────────
+--
+-- Carrega `status`, `source` e `added_by` da linha antiga: uma conta que tinha
+-- DESLIGADO o LeadControl não pode acordar com o FullControl aceso, e uma linha
+-- semeada pela plataforma ('default', 011 §3) não pode virar escolha de gente.
+INSERT INTO app.tenant_apps (tenant_id, app_id, status, source, added_by)
+SELECT ta.tenant_id, 'full', ta.status, ta.source, ta.added_by
+  FROM app.tenant_apps ta
+ WHERE ta.app_id = 'crm'
+ON CONFLICT (tenant_id, app_id) DO NOTHING;
+
+-- ── §3  a linha antiga é aposentada, não apagada ───────────────────────────
+--
+-- `active = false` já a tira do `app_config()` (008 filtra `a.active`), e
+-- `url = NULL` é o segundo cinto: o cliente também descarta app sem url
+-- (packages/admin/src/directory/directory.store.ts, normalize()). O nome fica,
+-- para que uma consulta de suporte sobre uma linha antiga ainda leia.
+UPDATE app.apps
+   SET active = false,
+       url    = NULL
+ WHERE id = 'crm';
+
+-- ── §4  o teto do plano passa a ter a linha do PLUGIN, não só das facets ───
+--
+-- Este bloco conserta um defeito que existia ANTES deste app e que só não
+-- apareceu porque as contas do dogfood não têm plano.
+--
+-- `plan_permits(plugin, facet, tenant)` casa a facet EXATAMENTE
+-- (000_baseline.sql), e "o plugin é a facet de nome vazio"
+-- (packages/core/src/types/plugins.ts). Todo caminho de semeadura chama com
+-- `facet = ''`: tenant_app_set (001), tenant_apply_vertical_defaults (010) e os
+-- backfills das migrations de app. Mas o seed de `app.plan_grants` só escreveu
+-- linhas de FACET (`financial.ledger`, `crm.contacts`, `inventory.stock`,
+-- `agenda.scheduling`) — com `facet = ''` existem apenas `tasks`, `forms` e
+-- `scale/marketing`.
+--
+-- Consequência: qualquer tenant COM plano é recusado no próprio plugin cujas
+-- facets o plano dele inclui, e `tenant_apply_plan` acende facets órfãs que a
+-- casca corretamente não lê como plugin (packages/core/src/app/app-config.ts).
+-- Sem este §4, o FullControl acende hoje (contas sem plano) e para de acender
+-- no dia em que alguém vender o primeiro plano — que é a pior hora possível
+-- para descobrir.
+--
+-- `included` só onde o plano JÁ inclui uma facet daquele plugin: ali a linha
+-- que falta é um defeito, não uma decisão de produto (é o "defeito 2" que a
+-- 010 §2 nomeia). Todo o resto entra como `optional`, e isso é deliberado:
+-- `plan_permits` NÃO lê o `mode`, então `optional` levanta o teto sem que
+-- `tenant_apply_plan` imponha o módulo a quem não pediu.
+DO $$
+DECLARE p text;
+BEGIN
+  IF to_regprocedure('public.register_plan_grant(text,text,text,text,text)') IS NULL THEN
+    RAISE NOTICE '052: register_plan_grant ausente — §4 pulado';
+    RETURN;
+  END IF;
+
+  -- 4.1 a linha do plugin para cada plugin cujas facets os planos já incluem.
+  FOREACH p IN ARRAY ARRAY['financial', 'inventory', 'crm', 'agenda'] LOOP
+    PERFORM public.register_plan_grant('essential', p, '', 'included',
+      'O plugin é a facet de nome vazio: sem esta linha o teto recusa o plugin cujas facets este plano inclui (052 §4).');
+    PERFORM public.register_plan_grant('pro',   p, '', 'included', NULL);
+    PERFORM public.register_plan_grant('scale', p, '', 'included', NULL);
+  END LOOP;
+
+  -- 4.2 o que o ERP soma, por plano. `optional` = permitido, não imposto.
+  -- No essential entram só os dois que atendem e cobram — um ERP inteiro não é
+  -- produto de plano básico.
+  PERFORM public.register_plan_grant('essential', 'conversations', '', 'optional', 'Onde o cliente e o fornecedor falam.');
+  PERFORM public.register_plan_grant('essential', 'notifications', '', 'optional', 'Toda cobrança e toda confirmação saem por aqui.');
+
+  FOREACH p IN ARRAY ARRAY['conversations', 'notifications', 'marketing', 'automations',
+                           'reports', 'tasks', 'forms'] LOOP
+    PERFORM public.register_plan_grant('pro',   p, '', 'optional', NULL);
+    PERFORM public.register_plan_grant('scale', p, '', 'optional', NULL);
+  END LOOP;
+
+  -- 4.3 os addons: permitidos só no topo, e nunca `included`.
+  PERFORM public.register_plan_grant('scale', 'fiscal-br',  '', 'optional', 'Addon: a emissão fiscal é contratada, não incluída.');
+  PERFORM public.register_plan_grant('scale', 'banking-br', '', 'optional', 'Addon: a conciliação bancária é contratada.');
+END $$;
+
+-- ── §5  os plugins que o app exige, com o teto do plano respeitado ─────────
+--
+-- DISTINCT porque um tenant que chega por dois caminhos faria o ON CONFLICT
+-- recusar tocar a linha duas vezes; `plan_permits` porque o teto do plano vence
+-- sempre sobre um padrão — uma conta cujo plano não inclui o plugin não o
+-- ganha aceso, e a semeadura não falha por isso (011 §3, mesma regra).
+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 = 'full'
+   AND ta.status = 'active'
+   AND public.plan_permits(r.plugin_id, '', ta.tenant_id)
+ON CONFLICT (tenant_id, plugin_id, facet) DO NOTHING;
+
+-- ── §6  (comentado) o ramo órfão ───────────────────────────────────────────
+--
+-- 'agency' está em app.vertical_defaults desde o baseline e NENHUM app o serve:
+-- um tenant criado com vertical_id='agency' ganha plugins e zero apps. Se
+-- alguém decidir que o ERP genérico é a resposta honesta para esse ramo, é UMA
+-- linha — e ela merece uma migration própria, para poder ser revista sozinha:
+--   UPDATE app.apps SET serves_verticals = ARRAY['agency'] WHERE id = 'full';

package/migrations/053_o_erp_para_de_exigir_o_que_nao_desenha.sql

@@ -0,0 +1,37 @@
+-- ---------------------------------------------------------------------------
+-- 053_o_erp_para_de_exigir_o_que_nao_desenha.sql — o FullControl encolhe o
+-- `requires` para o que ele realmente monta.
+--
+-- A 052 registrou o app com oito plugins, e naquele dia ele montava os oito. No
+-- mesmo dia o recorte apertou: o FullControl é para a empresa que vende SERVIÇO
+-- e SOFTWARE — agência, software house, consultoria —, e duas coisas saíram do
+-- bundle por não existirem nessa casa:
+--
+--   `inventory`  prateleira. Quem tem estoque é atendido pelo StoreControl e
+--                pelo ChefControl, e um ERP que oferece contagem de inventário
+--                a quem não tem depósito é um formulário a mais.
+--   `marketing`  campanha e canal de aquisição. O funil fica (o orçamento é o
+--                começo do título), mas a máquina de aquisição é produto do
+--                LeadControl, que é justamente de onde este app veio.
+--
+-- ── Por que isso é uma migration, e não uma edição na 052 ──────────────────
+--
+-- A 052 já foi aplicada e o ledger guarda o sha256 dela; arquivo aplicado é
+-- congelado. E a 052 tem, de propósito, um `ON CONFLICT` que só faz `requires`
+-- CRESCER numa reaplicação — então nem reaplicá-la desfaria isto. Encolher é um
+-- ato explícito, e é este arquivo.
+--
+-- ── O que este arquivo NÃO faz: desligar plugin de ninguém ─────────────────
+--
+-- `requires` é lista de SEMEADURA, não de dependência: ele decide o que um
+-- tenant ganha ao ATIVAR o app daqui para a frente. As contas que já receberam
+-- `inventory` e `marketing` ficam com eles acesos, e isso está certo — a
+-- 052 §5 os acendeu para o TENANT (app.tenant_plugins não tem app_id), e o
+-- ChefControl e o StoreControl das mesmas contas estão de pé sobre `inventory`
+-- neste exato momento. Apagar a linha aqui apagaria o estoque do restaurante.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps
+   SET requires = ARRAY['crm', 'conversations', 'automations', 'notifications',
+                        'reports', 'financial']
+ WHERE id = 'full';

package/package.json

@@ -3,7 +3,7 @@
   "fayz": {
     "status": "beta"
   },
-  "version": "0.14.0",
+  "version": "0.15.0",
   "description": "Fayz SDK database layer — Drizzle schema primitives, spine references, and migration helpers shared across plugins.",
   "type": "module",
   "sideEffects": false,