@fayz-ai/db 0.13.0 → 0.15.0

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 $_$;