@fayz-ai/db 0.14.0 → 0.16.0

package/migrations/097_o_oficio_diz_o_que_oferece_e_a_conta_o_que_usa.sql

@@ -0,0 +1,137 @@
+-- ---------------------------------------------------------------------------
+-- 079_o_oficio_diz_o_que_oferece_e_a_conta_o_que_usa.sql
+-- ---------------------------------------------------------------------------
+-- Uma clínica abria mostrando módulo de restaurante, de loja e de escola ao
+-- mesmo tempo. Não era dado sujo: era a regra.
+--
+-- ── Por que o aplicativo central mostra tudo ────────────────────────────────
+-- `resolvePluginRuntime` é ADITIVO: uma linha `active` liga, uma linha
+-- `disabled` desliga, e o silêncio cai no padrão do manifesto. Hoje 24 dos 29
+-- plugins publicados nascem `defaultEnabled: true`.
+--
+-- Num aplicativo de OFÍCIO isso está certo: o resto-saas importa doze pacotes,
+-- e a curadoria já aconteceu no `import`. O aplicativo central importa os vinte
+-- e cinco — e ali o mesmo padrão quer dizer "toda conta recebe todo ofício,
+-- a menos que escreva uma linha `disabled` para cada um que não quer".
+--
+-- A Clinica de Teste tem catorze linhas, todas `active`, nenhuma `disabled`.
+-- Ela nunca disse que não era um restaurante. Ninguém nunca disse.
+--
+-- ── O que faltava: a OFERTA ────────────────────────────────────────────────
+-- A 077 deu ao aplicativo um `preset` com `shell` e `nav` — como DESENHAR. Não
+-- havia onde dizer o que ele OFERECE. Sem essa lista, o catálogo do aplicativo
+-- central é a união de tudo que foi compilado, que não é catálogo nenhum.
+--
+--   app.apps.preset.modules   o ofício    — o que este ofício oferece
+--   app.tenant_plugins        a conta     — o que esta casa ligou ou desligou
+--   app.roles                 o papel     — quem, dentro dela, enxerga
+--
+-- Com `modules`, o silêncio deixa de significar "ligado": um plugin que o
+-- ofício não oferece está FORA, mesmo nascendo `defaultEnabled: true`. E um que
+-- ele oferece continua obedecendo a conta — que é como o Artorius, sendo food,
+-- não tem Balcão: o ChefControl OFERECE o PDV, e a conta dele diz que não usa.
+--
+-- O ofício propõe; a conta dispõe.
+--
+-- ── E o ramo (`vertical_id`)? Ele era quatro vocabulários ──────────────────
+-- Quatro lugares diziam o ramo de uma conta, e nenhum concordava com o outro:
+--
+--   tenants.vertical_id           food, restaurant, beauty, salon, clinic,
+--                                 commerce, ecommerce, retail, null  — 9 grafias
+--   app.vertical_defaults         agency, ecommerce, restaurant, salon, school
+--                                                                     — 5 grafias
+--   app.tenant_apps.app_id        resto, beauty, shop, full, fiscal, school
+--   PluginManifest.verticalId     nunca preenchido (é `options?.verticalId`, e
+--                                 o aplicativo central não passa nada)
+--
+-- A interseção das duas primeiras é de TRÊS nomes. Pertinho do Céu é `food`; a
+-- tabela de defaults só conhece `restaurant`. Catorze das vinte e duas contas
+-- têm um ramo que a tabela de ramos nunca ouviu falar — e é por isso que nada
+-- específico de ofício jamais disparou.
+--
+-- A saída não é uma quinta grafia. É reconhecer qual das quatro tem dono:
+-- `tenant_apps` é escrita pelo provisionamento, tem chave estrangeira para
+-- `app.apps` e já viaja no `app_config()`. O RAMO DE UMA CONTA É O OFÍCIO DO
+-- APLICATIVO QUE ELA RODA. `tenants.vertical_id` passa a ser consequência —
+-- rótulo para relatório e para o onboarding, nunca portão.
+-- ---------------------------------------------------------------------------
+
+-- ── 1. O aplicativo declara seu ofício, uma vez ────────────────────────────
+ALTER TABLE app.apps ADD COLUMN IF NOT EXISTS vertical_id text;
+
+COMMENT ON COLUMN app.apps.vertical_id IS
+  'O ofício deste aplicativo, em UM vocabulário: food, beauty, commerce, education, events, accounting, generic. NULL = não é ofício (control-admin). `tenants.vertical_id` é derivada daqui — ver 079.';
+
+UPDATE app.apps SET vertical_id = v.vertical FROM (VALUES
+  ('resto',  'food'),
+  ('beauty', 'beauty'),     -- salão E clínica: os dois rodam o StudioControl
+  ('shop',   'commerce'),
+  ('school', 'education'),
+  ('ticket', 'events'),
+  ('fiscal', 'accounting'),
+  ('full',   'generic'),
+  ('crm',    'generic')
+) AS v(id, vertical) WHERE app.apps.id = v.id;
+
+-- ── 2. O ofício declara o que oferece ──────────────────────────────────────
+-- Extraído do que cada aplicativo REALMENTE compõe hoje (o array `plugins` de
+-- `src/config/app.tsx` de cada repositório), não de uma lista desejada.
+-- `::jsonb` e nao so `m.modules`: num VALUES o literal `$$[...]$$` e TEXTO, e
+-- `jsonb_build_object` com texto guarda uma STRING, nao um array. A diferenca
+-- so aparece tres migrations adiante, quando a invariante da 101 chama
+-- `jsonb_array_length` e recebe um escalar.
+UPDATE app.apps SET preset = preset || jsonb_build_object('modules', m.modules::jsonb) FROM (VALUES
+  ('resto', $$["dashboard","admin","notifications","menu","orders","tables","reservations","kitchen",
+               "resto-counter","resto-module-toggles","resto-printing","agenda","inventory","crm",
+               "financial","fiscal-br","custom_forms","marketing","automations","conversations",
+               "tasks","workforce","reports","openbanking"]$$),
+  ('beauty', $$["dashboard","admin","notifications","agenda","crm","financial","inventory","marketing",
+                "automations","custom_forms","tasks","scribe","workforce","reports","openbanking"]$$),
+  ('shop', $$["dashboard","admin","notifications","shop","orders","inventory","crm","marketing",
+              "financial","automations","reports","blog","sites"]$$),
+  ('full', $$["dashboard","admin","notifications","crm","conversations","financial","inventory",
+              "marketing","automations","reports","tasks","custom_forms"]$$),
+  ('school', $$["dashboard","admin","notifications","courses","agenda","crm","financial","marketing",
+                "automations","reports","custom_forms"]$$),
+  ('fiscal', $$["dashboard","admin","notifications","financial","fiscal-br","reports","openbanking"]$$),
+  ('ticket', $$["dashboard","admin","notifications","orders","crm","financial","marketing",
+                "automations","reports"]$$)
+) AS m(id, modules) WHERE app.apps.id = m.id;
+
+-- ── 3. A conta que rodava cinco ofícios volta a rodar o seu ────────────────
+-- Resíduo do backfill que deu todos os aplicativos a todas as contas. Já
+-- corrigido para os restaurantes; a clínica ficou para trás.
+DELETE FROM app.tenant_apps ta
+ USING public.tenants t
+ WHERE ta.tenant_id = t.id
+   AND t.name = 'Clinica de Teste'
+   AND ta.app_id <> 'beauty';
+
+-- ── 4. O ramo passa a ser consequência do ofício ───────────────────────────
+-- Onde a conta roda um ofício, a coluna repete o que `tenant_apps` já diz. Onde
+-- ela roda mais de um (Papa Léguas: resto + shop), vence o mais específico —
+-- `fiscal` é retaguarda e nunca é o produto principal; `full` é o ERP sem ofício.
+UPDATE public.tenants t SET vertical_id = d.vertical
+  FROM (
+    SELECT ta.tenant_id,
+           (array_agg(a.vertical_id ORDER BY (a.vertical_id = 'accounting'), (a.vertical_id = 'generic'), a.id))[1] AS vertical
+      FROM app.tenant_apps ta
+      JOIN app.apps a ON a.id = ta.app_id
+     WHERE ta.status = 'active' AND a.vertical_id IS NOT NULL
+     GROUP BY ta.tenant_id
+  ) d
+ WHERE d.tenant_id = t.id AND t.vertical_id IS DISTINCT FROM d.vertical;
+
+-- Sem aplicativo nenhum não há ofício a derivar. `generic` é a resposta honesta:
+-- a conta existe e ainda não disse o que faz.
+UPDATE public.tenants t SET vertical_id = 'generic'
+ WHERE NOT EXISTS (SELECT 1 FROM app.tenant_apps ta WHERE ta.tenant_id = t.id AND ta.status = 'active');
+
+-- Fecha o vocabulário. Sem isto a próxima conta criada à mão reabre o problema.
+ALTER TABLE public.tenants DROP CONSTRAINT IF EXISTS tenants_vertical_id_check;
+ALTER TABLE public.tenants ADD CONSTRAINT tenants_vertical_id_check
+  CHECK (vertical_id IS NULL OR vertical_id IN
+    ('food','beauty','commerce','education','events','accounting','generic'));
+
+COMMENT ON COLUMN public.tenants.vertical_id IS
+  'O ramo desta conta, DERIVADO do ofício do aplicativo que ela roda (079). Rótulo para relatório e onboarding — quem decide o que aparece é app.apps.preset.modules cruzado com app.tenant_plugins, nunca esta coluna.';

package/migrations/098_a_arvore_do_oficio_nomeia_quem_ainda_desenha.sql

@@ -0,0 +1,22 @@
+-- ---------------------------------------------------------------------------
+-- 080_a_arvore_do_oficio_nomeia_quem_ainda_desenha.sql
+-- ---------------------------------------------------------------------------
+-- Quando o ofício traz árvore curada (`preset.nav`), quem mais pode pôr linha
+-- no rail?
+--
+-- "Ninguém" foi a primeira resposta, e custou o Painel e as Conversas: a árvore
+-- do ChefControl nunca teve essas duas linhas porque, no resto-saas, elas vêm
+-- da nav dos PRÓPRIOS plugins — lá só os de ofício levam `hideNav()`.
+--
+-- "Todos" é o erro oposto, e foi o que apareceu na tela seguinte: a Agenda
+-- desenhou "Agenda" ao lado de "Operação" sendo que, dentro dela, ela já é a
+-- linha "Reservas". Um módulo em dois lugares do mesmo menu.
+--
+-- `navExtras` é a exceção nomeada — o equivalente declarativo do `hideNav()`
+-- que o aplicativo de ofício escreve em código. Só vale onde há `nav`: um
+-- ofício que apenas ORDENA plugins (beauty, shop, full) não silencia ninguém, e
+-- para eles a lista não existe.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps SET preset = preset || '{"navExtras":["dashboard","conversations"]}'::jsonb
+ WHERE id = 'resto';

package/migrations/099_o_estoque_mora_dentro_de_produtos.sql

@@ -0,0 +1,48 @@
+-- ---------------------------------------------------------------------------
+-- 081_o_estoque_mora_dentro_de_produtos.sql — o StoreControl ganha árvore.
+-- ---------------------------------------------------------------------------
+-- PULSE e Artorius mostravam "Produtos" e "Estoque" como duas linhas irmãs do
+-- rail. Duas entradas para a mesma coisa na cabeça de quem opera uma loja — e
+-- não é que uma esteja errada: o catálogo (o que vendo, preço, foto) e a
+-- posição (quanto tem, onde, a que custo) são fatos diferentes sobre o MESMO
+-- produto. O que estava errado era pedir que a pessoa escolhesse entre eles no
+-- menu, como se fossem assuntos separados.
+--
+-- O ChefControl já tinha resolvido isso: "Produtos ▸ Cardápio · Estoque". Aqui
+-- é a mesma forma, com o vocabulário da loja — e é a segunda vez que a árvore
+-- curada de um ofício responde uma pergunta que o rail montado de plugins
+-- soltos não sabia responder.
+--
+-- ── Por que a árvore precisa nomear TUDO ───────────────────────────────────
+-- Onde há `nav`, só quem está em `navExtras` ainda desenha linha própria (080).
+-- Então um módulo ausente da árvore desaparece do menu — Marketing, Financeiro
+-- e Relatórios entram aqui não por decoração, mas porque sem eles sumiriam.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps SET preset = preset || $$
+{
+  "navExtras": ["dashboard", "conversations"],
+  "nav": [
+    { "route": "/orders", "label": "Pedidos", "icon": "ShoppingBag", "position": 10, "children": [
+      { "route": "/orders", "label": "Pedidos", "icon": "ShoppingBag" },
+      { "route": "/orders/customers", "label": "Clientes", "icon": "Users" }
+    ]},
+    { "route": "/products", "label": "Produtos", "icon": "Package", "position": 20, "children": [
+      { "route": "/products", "label": "Catálogo", "icon": "Package" },
+      { "route": "/products/collections", "label": "Coleções", "icon": "Layers" },
+      { "route": "/products/categories", "label": "Categorias", "icon": "FolderTree" },
+      { "route": "/inventory", "label": "Estoque", "icon": "Boxes" }
+    ]},
+    { "route": "/discounts", "label": "Descontos", "icon": "Tag", "position": 25, "children": [
+      { "route": "/discounts", "label": "Descontos", "icon": "Tag" },
+      { "route": "/discounts/gift-cards", "label": "Gift Cards", "icon": "CreditCard" }
+    ]},
+    { "route": "/content", "label": "Conteúdo", "icon": "Image", "position": 28 },
+    { "route": "/sales", "label": "CRM", "icon": "Filter", "position": 30 },
+    { "route": "/marketing", "label": "Marketing", "icon": "Megaphone", "position": 35 },
+    { "route": "/financial", "label": "Financeiro", "icon": "DollarSign", "position": 40 },
+    { "route": "/automations", "label": "Automações", "icon": "Zap", "position": 45 },
+    { "route": "/analytics", "label": "Relatórios", "icon": "BarChart3", "position": 50 }
+  ]
+}
+$$::jsonb WHERE id = 'shop';

package/migrations/100_o_chefcontrol_desenha_abas_de_modulo.sql

@@ -0,0 +1,24 @@
+-- ---------------------------------------------------------------------------
+-- 082_o_chefcontrol_desenha_abas_de_modulo.sql
+-- ---------------------------------------------------------------------------
+-- O Estoque abria sem Produtos, Movimentações, Contagens e Receitas.
+--
+-- `ModulePage` com variante `sidebar` não desenha sub-navegação nenhuma — e a
+-- razão é boa: nessa variante o RAIL é que lista as sub-telas do módulo como
+-- filhas da linha dele. Só que aqui o rail não lista: as filhas de "Produtos"
+-- são Cardápio e Estoque, que são MÓDULOS irmãos, não as abas de dentro do
+-- Estoque. A promessa não era cumprida por ninguém, e as abas deixavam de
+-- existir.
+--
+-- A 077 semeou `moduleNav: "sidebar"` no preset do ChefControl. Foi engano:
+-- essa é a escolha do FullControl, que a declara em `src/config/app.tsx`. Os
+-- três aplicativos de referência — resto-saas, beauty-saas e marketplace-saas —
+-- não declaram `moduleNav` nenhum e caem no padrão do shell para
+-- `layout: 'sidebar'`, que é `tabs`.
+--
+-- O preset volta a dizer o que o aplicativo de referência faz.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps
+   SET preset = jsonb_set(preset, '{shell,moduleNav}', '"tabs"'::jsonb)
+ WHERE id = 'resto';

package/migrations/101_o_oficio_agrupa_o_plugin_nomeia.sql

@@ -0,0 +1,93 @@
+-- ---------------------------------------------------------------------------
+-- 083_o_oficio_agrupa_o_plugin_nomeia.sql — o preset para de redesenhar o rail.
+-- ---------------------------------------------------------------------------
+-- A 077 deu ao ofício uma ÁRVORE: cada linha com rota, rótulo, ícone e posição,
+-- escrita à mão em SQL. Mas o plugin já diz tudo isso — e duas fontes para o
+-- mesmo fato brigam. Brigaram quatro vezes, e todas as quatro chegaram como
+-- defeito de tela:
+--
+--   o Painel sumiu          a árvore não o listava, e ela calava os plugins
+--   a Agenda duplicou       a árvore a chamava "Reservas"; o plugin, "Agenda"
+--   "Pedidos" saiu 2x       a rubrica e o primeiro filho tinham o mesmo rótulo
+--   o Cardápio ficou solto  o `menu` não estava na árvore da loja
+--
+-- Nenhum era erro de renderização. Todos eram a árvore discordando do catálogo.
+--
+-- ── A forma nova ───────────────────────────────────────────────────────────
+-- O preset passa a declarar só o AGRUPAMENTO, numa lista única que se lê de
+-- cima para baixo como o próprio rail:
+--
+--   "rail": [
+--     "dashboard",                                   ← as linhas deste plugin
+--     { "label": "Produtos", "icon": "Package",
+--       "under": ["/menu", "/inventory"] },          ← uma rubrica
+--     "financial"
+--   ]
+--
+-- Uma string é o plugin, com os rótulos DELE. Um objeto é a rubrica, e `under`
+-- são prefixos de rota — o mesmo casamento por prefixo que o rail já usa para
+-- aninhar. O preset nunca diz como uma linha se chama, então não tem como
+-- discordar.
+--
+-- Quem não foi nomeado vai para o FIM, não some: é a regra do ByDesign — uma
+-- pergunta que ninguém respondeu cai no padrão, não em "não". O contrário faria
+-- do dia em que um aplicativo publica um plugin novo o dia em que ele
+-- desaparece de toda conta, em silêncio.
+--
+-- `nav` e `navExtras` saem junto. `order` também: a ordem agora é a da lista.
+-- ---------------------------------------------------------------------------
+
+-- ── ChefControl ────────────────────────────────────────────────────────────
+-- As sete rubricas do resto-saas, agora sem repetir o nome de nenhuma tela.
+UPDATE app.apps SET preset = (preset - 'nav' - 'navExtras' - 'order') || $$
+{
+  "rail": [
+    "dashboard",
+    "conversations",
+    { "label": "Operação", "icon": "Utensils",
+      "under": ["/orders", "/kitchen", "/clients", "/reservations", "/tables"] },
+    { "label": "Delivery", "icon": "Bike", "under": ["/delivery"] },
+    { "label": "Produtos", "icon": "Package", "under": ["/menu", "/inventory"] },
+    "financial",
+    "workforce",
+    { "label": "Cadastros", "icon": "Database", "under": ["/company", "/staff"] },
+    "reports"
+  ]
+}
+$$::jsonb WHERE id = 'resto';
+
+-- ── StoreControl ───────────────────────────────────────────────────────────
+-- "Produtos" junta o catálogo da loja, o estoque e — quando a casa tiver — o
+-- cardápio. É a resposta à redundância Produtos × Estoque, agora sem inventar
+-- rótulo nenhum.
+UPDATE app.apps SET preset = (preset - 'nav' - 'navExtras' - 'order') || $$
+{
+  "rail": [
+    "dashboard",
+    "conversations",
+    { "label": "Vendas", "icon": "ShoppingBag", "under": ["/orders"] },
+    { "label": "Produtos", "icon": "Package",
+      "under": ["/products", "/inventory", "/menu"] },
+    { "label": "Descontos", "icon": "Tag", "under": ["/discounts"] },
+    "shop",
+    "crm",
+    "marketing",
+    "financial",
+    "automations",
+    "reports"
+  ]
+}
+$$::jsonb WHERE id = 'shop';
+
+-- ── StudioControl e FullControl ────────────────────────────────────────────
+-- Eles nunca desenharam rail à mão: ordenam os plugins, e é só isso que o
+-- preset guarda. A lista vira `rail` para que exista UM vocabulário.
+UPDATE app.apps SET preset = (preset - 'order') || $$
+{ "rail": ["dashboard", "conversations", "agenda", "crm", "financial",
+           "inventory", "marketing", "workforce", "reports"] }
+$$::jsonb WHERE id = 'beauty';
+
+UPDATE app.apps SET preset = (preset - 'order') || $$
+{ "rail": ["dashboard", "conversations", "crm", "financial", "inventory",
+           "marketing", "automations", "reports"] }
+$$::jsonb WHERE id = 'full';

package/migrations/102_tres_marcas_ganham_fundo_e_contraste.sql

@@ -0,0 +1,73 @@
+-- ---------------------------------------------------------------------------
+-- 084_tres_marcas_ganham_fundo_e_contraste.sql
+-- ---------------------------------------------------------------------------
+-- Três contas passam a pintar a casa inteira, não só o rail. Os valores são os
+-- que o founder passou; o que este arquivo guarda é a decisão de onde cada um
+-- entra.
+--
+-- ── Espaço Renova Rio ──────────────────────────────────────────────────────
+-- O fundo vira o marrom escuro da própria marca — antes a página era clara e só
+-- a trilha era escura, o que lia como duas casas. O botão vai para uma pele
+-- clara: sobre marrom escuro, um botão marrom não é um botão.
+-- O rail fica um degrau ABAIXO da página (#100C0A contra #17120E) para ler como
+-- recuo, não como uma segunda página encostada.
+--
+-- ── Clínica Sol ────────────────────────────────────────────────────────────
+-- O laranja #FF7B05 da marca contra os azuis que ela já tinha. É o único par de
+-- complementares aqui, e por isso o rail guarda o laranja só para o item ativo.
+--
+-- ── PULSE ──────────────────────────────────────────────────────────────────
+-- Verde #83CA17 sobre preto — no RAIL. A página segue clara.
+--
+-- A primeira versão pintou a casa inteira de preto e o resultado foi ilegível:
+-- carta #151515 sobre fundo #0B0B0B é contraste de 1.2:1, e todo número do
+-- painel sumiu. "Preto" era a cor da trilha, não do sistema — e a diferença
+-- entre uma marca escura e um tema escuro é que a segunda decisão precisa de
+-- uma paleta inteira, não de duas cores.
+--
+-- ── O que isto expôs no código ─────────────────────────────────────────────
+-- O vocabulário da marca sabe dizer a cor do BOTÃO e não a do TEXTO dentro
+-- dele: `primaryForeground` cai em branco quando ninguém diz, e ninguém pode
+-- dizer. Serviu enquanto toda marca era escura; verde-limão e bege com texto
+-- branco são ilegíveis. A correção não é um campo novo — é derivar por
+-- luminância (ver `readableOn` em packages/admin/src/app/admin-app.tsx), que
+-- não tem como ser preenchido errado e já vale para a marca que ainda não
+-- existe.
+-- ---------------------------------------------------------------------------
+
+UPDATE public.tenants SET settings = jsonb_set(settings, '{branding,tokens}', $$
+{
+  "color":   { "primary": "#E3B591", "accent": "#E8A46A" },
+  "surface": { "background": "#17120E", "card": "#211A15", "foreground": "#F5F1ED" },
+  "rail":    { "background": "#100C0A", "foreground": "#F5F1ED", "border": "#2A2018",
+               "accent": "#2A2018", "accentForeground": "#E3B591", "muted": "#9B8B7C" },
+  "radius":  "0.75rem"
+}
+$$::jsonb), updated_at = now()
+ WHERE name = 'Espaco Renova Rio';
+
+UPDATE public.tenants SET settings = jsonb_set(settings, '{branding,tokens}', $$
+{
+  "color":   { "primary": "#FF7B05", "accent": "#FF9633" },
+  "surface": { "background": "#F6F8FC", "card": "#FFFFFF", "foreground": "#111620" },
+  "rail":    { "background": "#121826", "foreground": "#EEF1F7", "border": "#1F2A40",
+               "accent": "#26324C", "accentForeground": "#FF9633", "muted": "#8A96AC" },
+  "radius":  "0.75rem"
+}
+$$::jsonb), updated_at = now()
+ WHERE name = 'Clínica Sol - Espaço Terapêutico';
+
+-- `jsonb_set` exige que o caminho pai exista, e a PULSE não tinha `tokens`:
+-- por isso a mesclagem sobre `branding` em vez do caminho fundo.
+UPDATE public.tenants
+   SET settings = jsonb_set(coalesce(settings,'{}'::jsonb), '{branding}',
+         coalesce(settings->'branding','{}'::jsonb) || $$
+{ "tokens": {
+    "color":   { "primary": "#83CA17", "accent": "#6FAE12" },
+    "surface": { "background": "#F7F8F5", "card": "#FFFFFF", "foreground": "#14160F" },
+    "rail":    { "background": "#0B0B0B", "foreground": "#F2F4F0", "border": "#1E1E1E",
+                 "accent": "#1C2612", "accentForeground": "#9BDB3A", "muted": "#8A8A8A" },
+    "radius":  "0.5rem" } }
+$$::jsonb, true),
+       updated_at = now()
+ WHERE name = 'PULSE';

package/migrations/103_great_djs_e_iam_club_entram_na_frota.sql

@@ -0,0 +1,75 @@
+-- ---------------------------------------------------------------------------
+-- 085_great_djs_e_iam_club_entram_na_frota.sql
+-- ---------------------------------------------------------------------------
+-- As duas existiam como APLICATIVOS com backend próprio — Great DJs no projeto
+-- `fayz-calendar`, IAM no `iam-community-app` — e não como CONTA no cluster do
+-- Control, que é o único que o aplicativo central lê. Sem linha aqui elas não
+-- apareciam no seletor, por mais que o produto existisse.
+--
+--   Great DJs  →  CourseControl (education). O produto dela é aula de DJ, e a
+--                 agenda de booking é consequência disso, não o contrário.
+--   IAM Club   →  TicketControl (events). Clube é porta, lista e ingresso.
+--
+-- Os ids são os que `platform_tenant_create` sorteou; este arquivo reencena o
+-- estado, não o recria — daí o `WHERE slug` em vez de `INSERT`.
+--
+-- ── Sobre os ladrilhos ─────────────────────────────────────────────────────
+-- Os dois logos vieram com fundo branco chapado. Recortar por limiar comeria o
+-- brilho de neon do IAM junto — ele é lavanda clarinho perto das letras. A
+-- chave é tratar branco como TRANSPARÊNCIA e não como cor: alfa = 1 − brancura,
+-- e a cor restante renormalizada. O que era halo sobre branco vira halo sobre
+-- preto, que é como um neon se comporta de verdade.
+--
+-- Caminho `<tenant>/branding/tile.png` e não `branding/<tenant>/...` como as
+-- marcas antigas: a política do bucket exige o id do tenant na PRIMEIRA pasta.
+-- As antigas entraram por service_role, contornando a política — este caminho
+-- é o que o próprio dono da conta consegue escrever.
+-- ---------------------------------------------------------------------------
+
+UPDATE public.tenants t SET settings = jsonb_set(coalesce(t.settings,'{}'::jsonb), '{branding}',
+  coalesce(t.settings->'branding','{}'::jsonb) || $$
+{
+  "identity": { "name": "IAM Club",
+    "logoUrl": "https://klvfxzreepavcpyjiwla.supabase.co/storage/v1/object/public/avatars/d6ba2252-7807-4d25-895c-b6945a2a8171/branding/tile.png",
+    "markUrl": "https://klvfxzreepavcpyjiwla.supabase.co/storage/v1/object/public/avatars/d6ba2252-7807-4d25-895c-b6945a2a8171/branding/tile.png" },
+  "tokens": {
+    "color":   { "primary": "#8F6CF5", "accent": "#A387F7" },
+    "surface": { "background": "#F8F7FD", "card": "#FFFFFF", "foreground": "#15121F" },
+    "rail":    { "background": "#0B0912", "foreground": "#F1EEFB", "border": "#241E3A",
+                 "accent": "#241E3A", "accentForeground": "#B6A0FA", "muted": "#8B84A6" },
+    "radius":  "0.75rem" }
+}
+$$::jsonb, true), updated_at = now()
+ WHERE t.slug = 'iam-club';
+
+UPDATE public.tenants t SET settings = jsonb_set(coalesce(t.settings,'{}'::jsonb), '{branding}',
+  coalesce(t.settings->'branding','{}'::jsonb) || $$
+{
+  "identity": { "name": "Great DJs",
+    "logoUrl": "https://klvfxzreepavcpyjiwla.supabase.co/storage/v1/object/public/avatars/973e8465-09f8-41a9-93fb-a906d9667a1f/branding/tile.png",
+    "markUrl": "https://klvfxzreepavcpyjiwla.supabase.co/storage/v1/object/public/avatars/973e8465-09f8-41a9-93fb-a906d9667a1f/branding/tile.png" },
+  "tokens": {
+    "color":   { "primary": "#F39A21", "accent": "#FFB44D" },
+    "surface": { "background": "#FAF8F4", "card": "#FFFFFF", "foreground": "#1A1611" },
+    "rail":    { "background": "#0E0C09", "foreground": "#F7F3EC", "border": "#2A2114",
+                 "accent": "#2A2114", "accentForeground": "#FFB44D", "muted": "#968B79" },
+    "radius":  "0.75rem" }
+}
+$$::jsonb, true), updated_at = now()
+ WHERE t.slug = 'great-djs';
+
+-- ── Correção de duas marcas da rodada anterior ─────────────────────────────
+-- PULSE e Espaço Renova receberam a casa INTEIRA escura, e as duas ficaram
+-- ilegíveis: carta sobre fundo quase da mesma cor. "Preto" e "marrom escuro"
+-- eram a cor da TRILHA. Uma marca escura e um tema escuro são decisões
+-- diferentes — a segunda precisa de uma paleta inteira, não de duas cores.
+UPDATE public.tenants SET settings = jsonb_set(settings, '{branding,tokens}', $$
+{
+  "color":   { "primary": "#B4632A", "accent": "#C97B3C" },
+  "surface": { "background": "#FBF8F5", "card": "#FFFFFF", "foreground": "#1A1512" },
+  "rail":    { "background": "#171310", "foreground": "#F5F1ED", "border": "#2A2018",
+               "accent": "#2A2018", "accentForeground": "#E3B591", "muted": "#9B8B7C" },
+  "radius":  "0.75rem"
+}
+$$::jsonb), updated_at = now()
+ WHERE name = 'Espaco Renova Rio';

package/migrations/104_o_curso_e_a_bilheteria_ganham_preset.sql

@@ -0,0 +1,29 @@
+-- ---------------------------------------------------------------------------
+-- 086_o_curso_e_a_bilheteria_ganham_preset.sql
+-- ---------------------------------------------------------------------------
+-- CourseControl e TicketControl tinham `modules` (079) e nada mais. Sem `shell`
+-- eles herdavam o `moduleNav: 'sidebar'` do pacote central — e nessa variante
+-- `ModulePage` não desenha sub-navegação, na promessa de que o rail lista as
+-- sub-telas do módulo. O rail não lista. Mesmo defeito que tirou as abas do
+-- Estoque (082), só que estas duas contas nasceram hoje e já nasceriam assim.
+--
+-- O `rail` é curto de propósito: nenhum dos dois tem aplicativo de referência
+-- com rail curado, então o preset ordena e não agrupa. Agrupar é uma decisão
+-- que se toma olhando a tela cheia de dados, e elas ainda estão vazias.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps SET preset = preset || $$
+{
+  "shell": { "layout": "sidebar", "moduleNav": "tabs", "contentFrame": true },
+  "rail":  ["dashboard", "conversations", "courses", "agenda", "crm",
+            "marketing", "financial", "automations", "reports"]
+}
+$$::jsonb WHERE id = 'school';
+
+UPDATE app.apps SET preset = preset || $$
+{
+  "shell": { "layout": "sidebar", "moduleNav": "tabs", "contentFrame": true },
+  "rail":  ["dashboard", "conversations", "orders", "crm",
+            "marketing", "financial", "automations", "reports"]
+}
+$$::jsonb WHERE id = 'ticket';

package/migrations/105_o_que_o_oficio_exige_ele_tambem_oferece.sql

@@ -0,0 +1,78 @@
+-- ---------------------------------------------------------------------------
+-- 087_o_que_o_ofício_exige, ele também oferece.
+-- ---------------------------------------------------------------------------
+-- O IAM Club abriu com "Estoque" e "Cardápio" no rail de uma bilheteria. Não
+-- foi a oferta falhando: foi `app.apps.requires` e `app.apps.preset.modules`
+-- dizendo coisas diferentes sobre o mesmo aplicativo.
+--
+--   requires  →  menu, inventory, orders, financial, conversations
+--   modules   →  ...orders, crm, financial, marketing, automations, reports
+--
+-- `platform_tenant_create` semeia linhas `active` a partir de `requires`, e uma
+-- linha explícita vence a oferta — corretamente, é assim que o módulo vendido à
+-- parte funciona. Só que aqui não havia venda nenhuma: havia duas listas
+-- discordando, e a provisão obedeceu a que estava errada.
+--
+-- ── Qual das duas estava errada ────────────────────────────────────────────
+-- Nenhuma, e é essa a parte interessante: um clube TEM bar. `requires` estava
+-- certo sobre o negócio e `modules` é que estava incompleto — eu escrevi a
+-- lista da 079 olhando os plugins que o app-shell do TicketControl importa, e
+-- não o que a operação de um clube precisa.
+--
+-- Então a oferta cresce, e o rail ganha a rubrica que faltava: "Bar".
+--
+-- ── A invariante ───────────────────────────────────────────────────────────
+-- `requires ⊆ modules`, sempre. Um aplicativo não pode EXIGIR o que não
+-- OFERECE — seria pedir que a conta ligue algo que o catálogo dela não tem. A
+-- checagem no fim deste arquivo é o que impede a próxima divergência de chegar
+-- na tela em vez de na aplicação da migration.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps SET preset = preset || $$
+{
+  "modules": ["dashboard","admin","notifications","conversations","orders","menu","inventory",
+              "crm","financial","marketing","automations","reports"],
+  "rail": ["dashboard", "conversations",
+           { "label": "Bilheteria", "icon": "Ticket", "under": ["/orders"] },
+           { "label": "Bar", "icon": "Beer", "under": ["/menu", "/inventory"] },
+           "crm", "marketing", "financial", "automations", "reports"]
+}
+$$::jsonb WHERE id = 'ticket';
+
+-- O `requires` do CourseControl cabe na oferta dele; só falta `conversations`,
+-- que a oferta esqueceu e o rail já nomeia.
+UPDATE app.apps SET preset = jsonb_set(preset, '{modules}',
+  (preset->'modules') || '["conversations"]'::jsonb)
+ WHERE id = 'school' AND NOT (preset->'modules' ? 'conversations');
+
+-- Mesma falta no ChefControl e no StoreControl: `requires` não os inclui, mas
+-- o rail deles nomeia `conversations` — e um nome no rail que não está na
+-- oferta nunca desenha.
+UPDATE app.apps SET preset = jsonb_set(preset, '{modules}',
+  (preset->'modules') || '["conversations"]'::jsonb)
+ WHERE id IN ('shop','full','fiscal') AND NOT (preset->'modules' ? 'conversations');
+
+-- A checagem abaixo pegou esta linha enquanto eu a escrevia: a lista nova do
+-- TicketControl tinha derrubado `conversations`, que o `requires` dele exige. É
+-- o tipo de omissão que só aparece na tela três telas depois.
+
+-- ── A invariante, verificada ───────────────────────────────────────────────
+DO $$
+DECLARE v_bad text;
+BEGIN
+  SELECT string_agg(a.id || ' exige ' || r.m || ' e não oferece', '; ')
+    INTO v_bad
+    FROM app.apps a
+    CROSS JOIN LATERAL unnest(a.requires) AS r(m)
+   WHERE a.active
+     -- `jsonb_typeof` antes de `jsonb_array_length`: uma verificação que
+     -- ESTOURA numa forma inesperada é pior que a divergência que ela procura —
+     -- ela derruba a cadeia inteira em vez de nomear a linha errada. Um ofício
+     -- sem oferta declarada simplesmente não é verificado.
+     AND jsonb_typeof(a.preset->'modules') = 'array'
+     AND jsonb_array_length(a.preset->'modules') > 0
+     AND NOT (a.preset->'modules' ? r.m);
+  IF v_bad IS NOT NULL THEN
+    RAISE EXCEPTION 'requires fora da oferta: %', v_bad;
+  END IF;
+END $$;