@fayz-ai/db 0.16.0 → 0.18.0

package/migrations/127_a_configuracao_tambem_se_pergunta_por_unidade.sql

@@ -0,0 +1,250 @@
+-- A configuração também se pergunta por unidade.
+--
+-- O registro de configuração do spine já é o mecanismo certo: uma chave nova é
+-- um `app.seed_setting_keys`, que é DADO — não migration, não coluna, não
+-- tabela de duas linhas. 17 chaves vivem assim hoje, de core e de plugin.
+--
+-- Só que ele para no tenant. E o hábito de abrir tabela para configuração
+-- nasceu exatamente aí: quem precisou de valor POR FILIAL não teve como pedir.
+-- É a origem de `plg_tables_settings`, `plg_reservations_settings` e
+-- `plg_shop_shipping_settings` — as três têm `unit_id` e, tirando isso, não
+-- fazem nada que o registro não faria.
+--
+-- ── A porta já estava aberta ────────────────────────────────────────────────
+--
+-- Isto não é ideia nova: é a metade que faltava. `tenant_setting_keys` já
+-- declara `scope` com CHECK `('tenant','unit')`, e `tenant_setting_set` já
+-- recusa o que não é do tenant:
+--
+--     IF k.scope <> 'tenant' THEN
+--       RAISE EXCEPTION 'tenant_setting_set: key % is unit-scoped', p_key
+--
+-- Quem escreveu aquilo previu este arquivo. As 17 chaves de hoje dizem
+-- `scope = 'tenant'` porque o outro lado nunca existiu.
+--
+-- ── Onde o valor da unidade mora ────────────────────────────────────────────
+--
+-- Em `app.units.settings`, irmã de `tenants.settings`. A linha da unidade já
+-- existe, já tem RLS por unidade, e o resolvedor vira um coalesce de três.
+-- Nenhuma tabela nova — que é o ponto: se a resposta para "configuração por
+-- filial" fosse mais uma tabela, este arquivo não teria razão de existir.
+--
+-- ── A cascata, e por que o tenant continua podendo escrever ────────────────
+--
+--     unidade  →  tenant  →  default_value do registro
+--
+-- Uma chave `scope='unit'` gravada no TENANT é o padrão da casa; gravada na
+-- UNIDADE é a exceção daquela filial. Por isso a trava do `tenant_setting_set`
+-- afrouxa aqui em vez de endurecer: sem o nível do tenant, ligar uma opção para
+-- uma rede de 127 unidades seria 127 escritas, e a 128ª filial nasceria com o
+-- padrão errado.
+--
+-- Escrever `null` na unidade APAGA a exceção e devolve a filial ao padrão da
+-- casa — `app.jsonb_set_path` já trata null como remoção. É o único jeito de
+-- desfazer uma exceção sem inventar um terceiro estado.
+--
+-- Idempotente.
+
+-- ═══════════════════════════════════════════════════════════════════════════
+-- 1. A unidade ganha onde guardar
+-- ═══════════════════════════════════════════════════════════════════════════
+
+ALTER TABLE app.units
+  ADD COLUMN IF NOT EXISTS settings jsonb DEFAULT '{}'::jsonb NOT NULL;
+
+COMMENT ON COLUMN app.units.settings IS
+  'A exceção desta filial sobre o padrão da casa. Irmã de tenants.settings; lida pela cascata em app.unit_setting_value. Só chave com scope=''unit'' desce até aqui.';
+
+-- ═══════════════════════════════════════════════════════════════════════════
+-- 2. O resolvedor com cascata
+-- ═══════════════════════════════════════════════════════════════════════════
+--
+-- `app.tenant_setting_value(tenant, key)` fica como está: 17 chaves e várias
+-- telas dependem dela, e o nível do tenant continua sendo o que ela responde.
+-- A cascata é uma função NOVA, e quem quer filial pede filial.
+
+CREATE OR REPLACE FUNCTION app.unit_setting_value(p_tenant uuid, p_unit uuid, p_key text)
+RETURNS jsonb
+LANGUAGE sql
+STABLE SECURITY DEFINER
+SET search_path TO ''
+AS $function$
+  SELECT coalesce(
+    -- a exceção da filial
+    (SELECT u.settings #> string_to_array(p_key, '.')
+       FROM app.units u
+      WHERE u.id = p_unit AND u.tenant_id = p_tenant),
+    -- o padrão da casa
+    (SELECT t.settings #> string_to_array(p_key, '.')
+       FROM public.tenants t
+      WHERE t.id = p_tenant),
+    -- o padrão declarado no registro
+    (SELECT k.default_value FROM app.tenant_setting_keys k WHERE k.key = p_key)
+  );
+$function$;
+
+COMMENT ON FUNCTION app.unit_setting_value(uuid, uuid, text) IS
+  'unidade → tenant → default_value. p_unit nulo devolve o nível do tenant.';
+
+-- ═══════════════════════════════════════════════════════════════════════════
+-- 3. Ler
+-- ═══════════════════════════════════════════════════════════════════════════
+--
+-- `p_unit` nulo = a unidade da sessão. Quem não está em unidade nenhuma lê o
+-- nível do tenant, que é o padrão da casa — e não um erro.
+
+CREATE OR REPLACE FUNCTION public.unit_setting(p_key text, p_unit uuid DEFAULT NULL)
+RETURNS jsonb
+LANGUAGE plpgsql
+STABLE SECURITY DEFINER
+SET search_path TO ''
+AS $function$
+DECLARE
+  v_tenant uuid := app.current_tenant_id();
+  v_unit   uuid := coalesce(p_unit, app.current_unit_id());
+BEGIN
+  IF v_tenant IS NULL THEN
+    RAISE EXCEPTION 'unit_setting: no active tenant' USING ERRCODE = '42501';
+  END IF;
+  IF NOT EXISTS (SELECT 1 FROM app.tenant_setting_keys k WHERE k.key = p_key) THEN
+    RAISE EXCEPTION 'unit_setting: unknown key %', coalesce(p_key, '<null>') USING ERRCODE = '22023';
+  END IF;
+  -- Ler a configuração de uma filial que a pessoa não alcança seria vazar o
+  -- recorte da franquia por um caminho lateral.
+  IF v_unit IS NOT NULL AND NOT app.has_unit(v_unit) THEN
+    RAISE EXCEPTION 'unit_setting: unit is out of reach' USING ERRCODE = '42501';
+  END IF;
+  RETURN app.unit_setting_value(v_tenant, v_unit, p_key);
+END $function$;
+
+-- Todas as chaves resolvidas para uma filial, de uma vez — o que a tela de
+-- /settings lê quando abre. Mesma forma do `tenant_settings()`.
+CREATE OR REPLACE FUNCTION public.unit_settings(p_unit uuid DEFAULT NULL)
+RETURNS jsonb
+LANGUAGE plpgsql
+STABLE SECURITY DEFINER
+SET search_path TO ''
+AS $function$
+DECLARE
+  v_tenant uuid := app.current_tenant_id();
+  v_unit   uuid := coalesce(p_unit, app.current_unit_id());
+BEGIN
+  IF v_tenant IS NULL THEN
+    RAISE EXCEPTION 'unit_settings: no active tenant' USING ERRCODE = '42501';
+  END IF;
+  IF v_unit IS NOT NULL AND NOT app.has_unit(v_unit) THEN
+    RAISE EXCEPTION 'unit_settings: unit is out of reach' USING ERRCODE = '42501';
+  END IF;
+  RETURN coalesce(
+    (SELECT jsonb_object_agg(k.key, app.unit_setting_value(v_tenant, v_unit, k.key))
+       FROM app.tenant_setting_keys k),
+    '{}'::jsonb);
+END $function$;
+
+-- ═══════════════════════════════════════════════════════════════════════════
+-- 4. Escrever a exceção da filial
+-- ═══════════════════════════════════════════════════════════════════════════
+
+CREATE OR REPLACE FUNCTION public.unit_setting_set(p_key text, p_value jsonb, p_unit uuid DEFAULT NULL)
+RETURNS jsonb
+LANGUAGE plpgsql
+SECURITY DEFINER
+SET search_path TO ''
+AS $function$
+DECLARE
+  v_tenant uuid := app.current_tenant_id();
+  v_unit   uuid := coalesce(p_unit, app.current_unit_id());
+  k record;
+BEGIN
+  IF v_tenant IS NULL OR auth.uid() IS NULL THEN
+    RAISE EXCEPTION 'unit_setting_set: no session or no active tenant' USING ERRCODE = '42501';
+  END IF;
+  IF v_unit IS NULL THEN
+    RAISE EXCEPTION 'unit_setting_set: no unit — use tenant_setting_set for the house default' USING ERRCODE = '22023';
+  END IF;
+  -- A permissão se pergunta NA UNIDADE: quem administra uma filial não
+  -- administra as outras.
+  IF NOT app.has_permission('settings.manage', v_unit) THEN
+    RAISE EXCEPTION 'unit_setting_set: settings.manage is required on this unit' USING ERRCODE = '42501';
+  END IF;
+  SELECT * INTO k FROM app.tenant_setting_keys x WHERE x.key = p_key;
+  IF NOT FOUND THEN
+    RAISE EXCEPTION 'unit_setting_set: unknown key %', coalesce(p_key, '<null>') USING ERRCODE = '22023';
+  END IF;
+  -- O espelho da trava que o tenant_setting_set já tinha: chave de tenant não
+  -- se excepciona por filial, senão o mesmo valor passa a ter dois donos.
+  IF k.scope <> 'unit' THEN
+    RAISE EXCEPTION 'unit_setting_set: key % is tenant-scoped', p_key USING ERRCODE = '22023';
+  END IF;
+  IF NOT app.setting_type_ok(k.type, p_value) THEN
+    RAISE EXCEPTION 'unit_setting_set: key % expects %, got %', p_key, k.type, coalesce(jsonb_typeof(p_value), 'null') USING ERRCODE = '22023';
+  END IF;
+  -- Valor nulo REMOVE a exceção e devolve a filial ao padrão da casa —
+  -- app.jsonb_set_path já trata isso como remoção do caminho.
+  UPDATE app.units u
+     SET settings = app.jsonb_set_path(coalesce(u.settings, '{}'::jsonb), string_to_array(p_key, '.'), p_value)
+   WHERE u.id = v_unit AND u.tenant_id = v_tenant;
+  IF NOT FOUND THEN
+    RAISE EXCEPTION 'unit_setting_set: unit does not belong to this tenant' USING ERRCODE = '42501';
+  END IF;
+  RETURN app.unit_setting_value(v_tenant, v_unit, p_key);
+END $function$;
+
+-- ═══════════════════════════════════════════════════════════════════════════
+-- 5. O tenant volta a poder escrever chave de unidade — como PADRÃO
+-- ═══════════════════════════════════════════════════════════════════════════
+--
+-- A trava original estava certa enquanto não havia cascata: sem ela, gravar uma
+-- chave de unidade no tenant era gravar num lugar que ninguém lia. Com a
+-- cascata o nível do tenant passa a significar "o padrão da casa", e recusá-lo
+-- obrigaria a escrever unidade por unidade — e deixaria a filial nova nascendo
+-- sem valor nenhum.
+--
+-- O resto da função é idêntico ao que já estava aplicado.
+
+CREATE OR REPLACE FUNCTION public.tenant_setting_set(p_key text, p_value jsonb)
+RETURNS jsonb
+LANGUAGE plpgsql
+SECURITY DEFINER
+SET search_path TO ''
+AS $function$
+DECLARE
+  v_tenant uuid := app.current_tenant_id();
+  k record;
+BEGIN
+  IF v_tenant IS NULL OR auth.uid() IS NULL THEN
+    RAISE EXCEPTION 'tenant_setting_set: no session or no active tenant' USING ERRCODE = '42501';
+  END IF;
+  IF NOT app.has_permission('settings.manage') THEN
+    RAISE EXCEPTION 'tenant_setting_set: settings.manage is required' USING ERRCODE = '42501';
+  END IF;
+  SELECT * INTO k FROM app.tenant_setting_keys x WHERE x.key = p_key;
+  IF NOT FOUND THEN
+    RAISE EXCEPTION 'tenant_setting_set: unknown key %', coalesce(p_key, '<null>') USING ERRCODE = '22023';
+  END IF;
+  IF NOT app.setting_type_ok(k.type, p_value) THEN
+    RAISE EXCEPTION 'tenant_setting_set: key % expects %, got %', p_key, k.type, coalesce(jsonb_typeof(p_value), 'null') USING ERRCODE = '22023';
+  END IF;
+  UPDATE public.tenants t
+     SET settings = app.jsonb_set_path(coalesce(t.settings, '{}'::jsonb), string_to_array(p_key, '.'), p_value)
+   WHERE t.id = v_tenant;
+  RETURN app.tenant_setting_value(v_tenant, p_key);
+END $function$;
+
+-- ═══════════════════════════════════════════════════════════════════════════
+-- 6. Quem pode chamar
+-- ═══════════════════════════════════════════════════════════════════════════
+
+-- A cascata interna não é superfície de ninguém: sem este REVOKE ela fica com o
+-- EXECUTE que o PostgreSQL dá a PUBLIC por padrão — e PUBLIC inclui `anon`. Os
+-- três invólucros públicos abaixo são SECURITY DEFINER e a chamam como dono, de
+-- modo que ninguém perde acesso ao que deveria ter. O portão N15c do pgTAP
+-- ("anon não executa nada em `app`") foi quem pegou.
+REVOKE ALL ON FUNCTION app.unit_setting_value(uuid, uuid, text) FROM public, anon;
+
+REVOKE ALL ON FUNCTION public.unit_setting(text, uuid) FROM public;
+REVOKE ALL ON FUNCTION public.unit_settings(uuid) FROM public;
+REVOKE ALL ON FUNCTION public.unit_setting_set(text, jsonb, uuid) FROM public;
+GRANT EXECUTE ON FUNCTION public.unit_setting(text, uuid) TO authenticated, service_role;
+GRANT EXECUTE ON FUNCTION public.unit_settings(uuid) TO authenticated, service_role;
+GRANT EXECUTE ON FUNCTION public.unit_setting_set(text, jsonb, uuid) TO authenticated, service_role;

package/migrations/128_a_biblioteca_de_midia_tambem_precisa_de_porta.sql

@@ -0,0 +1,97 @@
+-- ---------------------------------------------------------------------------
+-- 128_a_biblioteca_de_midia_tambem_precisa_de_porta.sql
+-- ---------------------------------------------------------------------------
+-- Quatro buckets de mídia existem desde sempre e NENHUM tem política.
+--
+-- `shop-images`, `inventory-images`, `mkt-media` e `course-media` são públicos,
+-- então a URL de leitura funciona — e foi por isso que o buraco ficou invisível
+-- por tanto tempo: a foto do produto aparece na vitrine, o catálogo parece
+-- inteiro, e ninguém suspeita.
+--
+-- O que NÃO funciona é tudo que passa por `storage.objects` com o JWT do
+-- usuário: `storage.list` e o upload. A tela Conteúdo do StoreControl lista a
+-- biblioteca com `bucket.list(...)`, e sem política de SELECT a lista volta
+-- VAZIA — não com erro. Medido na Zedek Pizzas em 2026-09-22: sete banners
+-- gravados no bucket, "0 arquivos | Nenhum arquivo ainda" na tela. O botão
+-- "Enviar arquivos" está do outro lado do mesmo buraco: sem política de INSERT
+-- ele recusa todo envio.
+--
+-- Isto vale para TODO tenant da frota, não para esta conta.
+--
+-- ── O recorte ──────────────────────────────────────────────────────────────
+-- O mesmo de `core_attachments_*` (063) e da foto de ponto: a pasta do topo é
+-- o tenant, e é ela que decide. Um bucket público já é legível por URL, então
+-- a política de SELECT não abre nada que não estivesse aberto — ela só ensina
+-- o `list` a enxergar o que o dono já pode ver.
+--
+-- DELETE entra aqui, ao contrário dos anexos: uma imagem de produto trocada é
+-- rotina de catálogo, e a tela oferece o botão. O que ela não pode é sair do
+-- pé da própria conta.
+-- ---------------------------------------------------------------------------
+
+DO $$
+DECLARE
+  v_bucket text;
+BEGIN
+  FOREACH v_bucket IN ARRAY ARRAY['shop-images', 'inventory-images', 'mkt-media', 'course-media'] LOOP
+    -- O nome da política carrega o bucket: quatro conjuntos independentes, e
+    -- desligar um não mexe nos outros.
+    EXECUTE format('DROP POLICY IF EXISTS %I ON storage.objects', 'core_media_' || replace(v_bucket, '-', '_') || '_read');
+    EXECUTE format('DROP POLICY IF EXISTS %I ON storage.objects', 'core_media_' || replace(v_bucket, '-', '_') || '_insert');
+    EXECUTE format('DROP POLICY IF EXISTS %I ON storage.objects', 'core_media_' || replace(v_bucket, '-', '_') || '_update');
+    EXECUTE format('DROP POLICY IF EXISTS %I ON storage.objects', 'core_media_' || replace(v_bucket, '-', '_') || '_delete');
+
+    EXECUTE format($f$
+      CREATE POLICY %I ON storage.objects
+        FOR SELECT TO authenticated
+        USING (
+          bucket_id = %L
+          AND (storage.foldername(name))[1] IN (SELECT public.user_tenant_ids()::text)
+        )
+    $f$, 'core_media_' || replace(v_bucket, '-', '_') || '_read', v_bucket);
+
+    EXECUTE format($f$
+      CREATE POLICY %I ON storage.objects
+        FOR INSERT TO authenticated
+        WITH CHECK (
+          bucket_id = %L
+          AND (storage.foldername(name))[1] IN (SELECT public.user_tenant_ids()::text)
+        )
+    $f$, 'core_media_' || replace(v_bucket, '-', '_') || '_insert', v_bucket);
+
+    EXECUTE format($f$
+      CREATE POLICY %I ON storage.objects
+        FOR UPDATE TO authenticated
+        USING (
+          bucket_id = %L
+          AND (storage.foldername(name))[1] IN (SELECT public.user_tenant_ids()::text)
+        )
+        WITH CHECK (
+          bucket_id = %L
+          AND (storage.foldername(name))[1] IN (SELECT public.user_tenant_ids()::text)
+        )
+    $f$, 'core_media_' || replace(v_bucket, '-', '_') || '_update', v_bucket, v_bucket);
+
+    EXECUTE format($f$
+      CREATE POLICY %I ON storage.objects
+        FOR DELETE TO authenticated
+        USING (
+          bucket_id = %L
+          AND (storage.foldername(name))[1] IN (SELECT public.user_tenant_ids()::text)
+        )
+    $f$, 'core_media_' || replace(v_bucket, '-', '_') || '_delete', v_bucket);
+  END LOOP;
+END $$;
+
+-- A vistoria: dezesseis políticas, quatro por bucket. Zero significa que o
+-- laço acima não rodou, e aí a tela Conteúdo continua vazia em silêncio — que
+-- é exatamente o defeito que esta migration existe para fechar.
+DO $$
+DECLARE v_n int;
+BEGIN
+  SELECT count(*) INTO v_n FROM pg_policy
+   WHERE polrelid = 'storage.objects'::regclass AND polname LIKE 'core_media_%';
+  IF v_n <> 16 THEN
+    RAISE EXCEPTION '128: esperava 16 políticas core_media_*, encontrei %', v_n;
+  END IF;
+END $$;

package/migrations/129_o_login_diz_de_quem_ele_e.sql

@@ -0,0 +1,83 @@
+-- ============================================================================
+-- O login diz de QUEM ele é
+--
+-- SINTOMA: a régua do atendimento do V1 só é montada para quem está VINCULADO A
+-- UM PROFISSIONAL — quem entra como admin da licença vê a ficha do cliente sem
+-- botão nenhum. O V2 não conseguia nem fazer a pergunta: `public.tenant_members`
+-- devolve (id, tenant_id, user_id, role, active, created_at, updated_at) e mais
+-- nada.
+--
+-- E o dado ESTÁ LÁ. `app.memberships.person_id` existe e está preenchido: 4 de 4
+-- no Espaço Facial, 88 no cluster. O que falta é a porta — a vista pública, que
+-- é por onde todo o TypeScript lê, não publica a coluna. O contrato em
+-- `packages/core/src/types/org.ts` fala dela ("um `tenant_members` ligado por
+-- `person_id`"), e ninguém nunca leu nada porque ela não atravessa.
+--
+-- Não é migração de dado: é uma vista alargada e a pergunta virando função.
+--
+-- ⚠ Uma vista alargada volta a estreitar se uma migration mais antiga for
+-- reaplicada fora de ordem — foi o que já aconteceu neste repositório. Se
+-- `person_id` sumir da vista de novo, procure quem recriou `tenant_members`
+-- depois desta.
+-- ============================================================================
+
+-- DUAS FORMAS, UM CONTRATO.
+--
+-- Em pool novo `public.tenant_members` é TABELA, criada pelo baseline já com
+-- `person_id`: não há o que alargar. No cluster que veio do ETL ela é VISTA
+-- sobre `app.memberships`, e é lá que a coluna não atravessa. `CREATE OR
+-- REPLACE VIEW` sobre a tabela não falha por acaso — falha com "tenant_members
+-- is not a view", e derruba a corrente inteira num banco do zero.
+DO $$
+BEGIN
+  IF (SELECT c.relkind FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
+       WHERE n.nspname = 'public' AND c.relname = 'tenant_members') = 'v' THEN
+    EXECUTE $v$
+      CREATE OR REPLACE VIEW public.tenant_members AS
+      SELECT m.id,
+             m.tenant_id,
+             m.user_id,
+             COALESCE(r.key, 'staff'::text) AS role,
+             m.active,
+             m.created_at,
+             m.updated_at,
+             -- A pessoa que É este login. Nulo é legítimo: o dono que criou o
+             -- espaço nunca ganha ficha, e metade de uma equipe de salão nunca
+             -- faz login.
+             --
+             -- POR ÚLTIMO, e não ao lado de `role`, onde ela faria sentido de
+             -- ler: `CREATE OR REPLACE VIEW` só aceita ACRESCENTAR coluna no
+             -- fim. Movê-la exigiria derrubar a vista, e derrubar leva junto os
+             -- grants e tudo que depende dela.
+             m.person_id
+        FROM app.memberships m
+        LEFT JOIN app.roles r ON r.id = m.role_id
+    $v$;
+  END IF;
+END $$;
+
+-- A pergunta que a tela faz — "eu sou profissional aqui?" — numa função só,
+-- para não ser remontada com um `join` diferente em cada lugar.
+CREATE OR REPLACE FUNCTION public.current_person_id()
+RETURNS uuid LANGUAGE plpgsql STABLE SECURITY DEFINER SET search_path TO 'public', 'app'
+AS $fn$
+DECLARE
+  v uuid;
+BEGIN
+  -- `EXECUTE` e não SQL direto: o corpo de uma função `LANGUAGE sql` é
+  -- validado na CRIAÇÃO, e `app.memberships` não existe num pool novo — a
+  -- migration morreria ali, num banco onde a pergunta nem precisa dessa tabela.
+  -- Onde ela existe (o cluster que veio do ETL) é a fonte; onde não existe, a
+  -- própria `public.tenant_members`, que lá é tabela e já tem a coluna.
+  IF to_regclass('app.memberships') IS NOT NULL THEN
+    EXECUTE 'SELECT m.person_id FROM app.memberships m
+              WHERE m.user_id = auth.uid() AND m.tenant_id = app.current_tenant_id()
+                AND coalesce(m.active, true) LIMIT 1' INTO v;
+  ELSE
+    EXECUTE 'SELECT tm.person_id FROM public.tenant_members tm
+              WHERE tm.user_id = auth.uid() AND tm.tenant_id = app.current_tenant_id() LIMIT 1' INTO v;
+  END IF;
+  RETURN v;
+END $fn$;
+
+GRANT EXECUTE ON FUNCTION public.current_person_id() TO authenticated;

package/migrations/130_o_aviso_leva_a_algum_lugar.sql

@@ -0,0 +1,31 @@
+-- ============================================================================
+-- O aviso leva a ALGUM LUGAR
+--
+-- `public.notifications` guarda título, corpo, tipo e lido — e mais nada. Um
+-- aviso que diz "a conta de Fulana está aberta" e não leva até ela obriga a
+-- recepção a procurar o nome numa lista, que é o caminho que o aviso existia
+-- para evitar.
+--
+-- Duas colunas: para ONDE ir, e SOBRE O QUE é (o par polimórfico que o resto do
+-- schema já usa em `documents.subject_type/subject_id`). Com o assunto dá para
+-- não avisar duas vezes sobre o mesmo atendimento.
+-- ============================================================================
+
+ALTER TABLE public.notifications
+  ADD COLUMN IF NOT EXISTS link text,
+  ADD COLUMN IF NOT EXISTS subject_type text,
+  ADD COLUMN IF NOT EXISTS subject_id uuid;
+
+COMMENT ON COLUMN public.notifications.link IS
+  'Rota do app para onde o aviso leva (ex.: #/checkin). Sem isto o aviso informa e abandona.';
+COMMENT ON COLUMN public.notifications.subject_type IS
+  'Sobre o que é o aviso (appointment, order…), no mesmo par polimórfico de documents.';
+
+-- Um aviso por assunto e por pessoa: o mesmo atendimento finalizado duas vezes
+-- (reabrir e fechar de novo) não enche o sino.
+CREATE UNIQUE INDEX IF NOT EXISTS notifications_subject_user_uidx
+  ON public.notifications (user_id, subject_type, subject_id, type)
+  WHERE subject_id IS NOT NULL;
+
+CREATE INDEX IF NOT EXISTS notifications_user_unread_idx
+  ON public.notifications (user_id, created_at DESC) WHERE NOT read;

package/migrations/131_o_salao_fala_o_vocabulario_do_v1.sql

@@ -0,0 +1,81 @@
+-- ---------------------------------------------------------------------------
+-- 117_o_salao_fala_o_vocabulario_do_v1.sql — o rail do StudioControl passa a
+-- dizer o que o BeautySoft dizia.
+-- ---------------------------------------------------------------------------
+-- Estes clientes usam o V1 ha anos e vao receber o V2 com a mesma equipe, sem
+-- treinamento. Um rail que espalha Confirmacoes e Check-in como linhas soltas
+-- onde la eles sao filhos de Agenda, e que deixa Fornecedores fora de Cadastros
+-- tendo Cadastros logo abaixo, faz cada pessoa reaprender um menu que ela ja
+-- sabe de cor. Esse custo nao aparece em teste nenhum; aparece no chamado.
+--
+-- -- O que foi medido, dos dois lados, em 21/09/2026 --------------------------
+--
+-- V1 (Espaco Facial, unidade Treinamento, perfil dono):
+--
+--     Dashboard . Agenda v . Clientes v . Estoque . CRM . Financeiro .
+--     Cadastros v . Configuracoes . Relatorios
+--
+--     Agenda    v  Agendamentos . Confirmacoes . Check-in . Comunicacao
+--     Cadastros v  Contatos . Contas . Equipamentos . Fornecedores .
+--                  Funcionarios . Locais Operacionais . Origens . Parcerias .
+--                  Servicos . Profissionais . Recursos Humanos
+--
+-- V2 (`beauty`, lido do proprio rail):
+--
+--     / . /agenda . /agenda/confirmations . /checkin . /sales . /customers .
+--     /suppliers . /financial . /inventory . /marketing . /analytics .
+--     /clients . /registry . /settings
+--
+--     /registry v  services . categories . locations . location-groups .
+--                  staff . contacts . suppliers . partnerships . equipment
+--
+-- Tres diferencas de FORMA saltam dessa comparacao, e sao o que este arquivo
+-- conserta:
+--
+--   1. "Clientes" sai DUAS vezes  -- `/customers` e `/clients` sao a mesma
+--      linha do ponto de vista de quem usa. O ofício fica com `/clients`, que
+--      e a ficha que o salao abre; `/customers` some do rail.
+--   2. "Fornecedores" sai DUAS vezes -- solto em `/suppliers` e dentro de
+--      Cadastros em `/registry/suppliers`. No V1 ele mora em Cadastros e so.
+--   3. Agenda, Confirmacoes e Check-in sao tres linhas soltas onde o V1 tem
+--      uma gaveta.
+--
+-- -- O que o preset pode e o que ele nao pode --------------------------------
+-- Ele AGRUPA e ORDENA; quem NOMEIA e o plugin (083/101). Entao este arquivo
+-- nao escreve "Agendamentos" nem "Funcionarios" em lugar nenhum: diz quais
+-- PREFIXOS DE ROTA moram sob cada rubrica, e os rotulos continuam sendo os que
+-- cada plugin declara. Foi essa separacao que parou a briga entre a arvore de
+-- SQL e o catalogo, e ela nao vai ser reaberta por causa de um rotulo.
+--
+-- Fica, por isso, uma divergencia de VOCABULARIO que so o app resolve, anotada
+-- aqui para nao se perder: o V1 chama "Funcionarios" o que `/registry/staff`
+-- chama "Equipe", "Locais Operacionais" o que `/registry/locations` chama
+-- "Locais de Atendimento", e "CRM" o que `/sales` chama "Vendas".
+--
+-- `/resources` ja entra no `under` de Cadastros: a tabela de recursos (salas,
+-- macas, cadeiras) esta sendo criada agora, e no V1 esse cadastro mora em
+-- Cadastros. Prefixo que ainda nao serve rota nenhuma nao custa nada -- a
+-- rubrica simplesmente nao o recolhe ate a tela existir.
+--
+-- `hide` tira do rail o vocabulario que o V1 nao tem. NAO desliga modulo
+-- nenhum: as telas continuam existindo, roteadas e alcancaveis -- o que sai e
+-- a LINHA.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps SET preset = (preset - 'rail' - 'hide') || $$
+{
+  "rail": [
+    "dashboard",
+    { "label": "Agenda", "icon": "Calendar",
+      "under": ["/agenda", "/checkin", "/conversations"] },
+    { "label": "Clientes", "icon": "Users", "under": ["/clients"] },
+    "inventory",
+    "crm",
+    "financial",
+    { "label": "Cadastros", "icon": "ClipboardList",
+      "under": ["/registry", "/resources", "/company", "/staff"] },
+    "reports"
+  ],
+  "hide": ["/customers", "/suppliers", "/marketing", "/analytics", "/tasks"]
+}
+$$::jsonb WHERE id = 'beauty';

package/migrations/132_o_cadastro_do_salao_fala_como_o_v1.sql

@@ -0,0 +1,91 @@
+-- ---------------------------------------------------------------------------
+-- 118_o_cadastro_do_salao_fala_como_o_v1.sql — o Cadastros do Espaço Facial.
+-- ---------------------------------------------------------------------------
+-- A 117 pôs as telas de cadastro sob UMA rubrica, e foi metade do caminho. A
+-- outra metade é o que a recepcionista lê quando abre o menu: ela vem de sete
+-- anos de BeautySoft, e lá a lista se chama assim, nesta ordem —
+--
+--     Contatos · Contas · Equipamentos · Fornecedores · Funcionários ·
+--     Locais Operacionais · Origens · Parcerias · Serviços ·
+--     Profissionais · Recursos Humanos
+--
+-- Três coisas faltavam para dizer isso, e as três agora são dado:
+--
+--   ORDEM     `under` passa a ser lida como sequência, não como conjunto. O
+--             V1 abre em Contatos e fecha em Serviços; a ordem de POSIÇÃO dos
+--             plugins não tem como saber disso. Um prefixo largo no fim
+--             (`/registry`) continua sendo o pega-tudo.
+--
+--   NOME      `labels` é um dicionário rota → nome. Não é a árvore paralela
+--             que a 083 matou: não há rota, ícone nem posição aqui, então não
+--             há como uma entrada desenhar uma linha que não existe. É só o
+--             ofício dizendo que na casa DELE `/registry/staff` se chama
+--             "Funcionários" — renomear isso no plugin renomearia a mesma tela
+--             no restaurante e na loja.
+--
+--   ORIGENS   a rota existe desde sempre, com rótulo vazio, e por isso nunca
+--             desenhou: uma linha sem nome não tem como aparecer. Nomeada pelo
+--             preset, ela volta ao menu sem o aplicativo mudar uma linha.
+--
+-- ── O que continua faltando, e por que não está aqui ───────────────────────
+--   Contas             existe DENTRO do Financeiro, como aba do módulo, não
+--                      como rota própria. Puxá-la para cá a tiraria de lá.
+--   Profissionais      o V1 separa quem TRABALHA na casa (Funcionários) de
+--                      quem ATENDE (Profissionais). O V2 tem uma pessoa só.
+--                      Eixo não modelado — não se inventa rubrica para ele.
+--   Recursos Humanos   é o plugin `workforce`, que este aplicativo não monta.
+--
+-- `modules` ganha `registry` junto: quem NÃO é oferecido não entra, mesmo
+-- instalado — e uma rubrica sobre telas que não existem some em silêncio, que
+-- foi exatamente o que aconteceu no aplicativo central.
+--
+-- Idempotente: reescreve `rail`, `hide` e `labels` por inteiro.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps
+   SET preset = (preset - 'rail' - 'hide' - 'labels') || $$
+{
+  "rail": [
+    "dashboard",
+    { "label": "Agenda", "icon": "Calendar",
+      "under": ["/agenda", "/checkin", "/conversations"] },
+    { "label": "Clientes", "icon": "Users", "under": ["/clients"] },
+    "inventory",
+    "crm",
+    "financial",
+    { "label": "Cadastros", "icon": "ClipboardList",
+      "under": ["/registry/contacts",
+                "/registry/equipment",
+                "/registry/suppliers",
+                "/registry/staff",
+                "/registry/locations",
+                "/registry/location-groups",
+                "/registry/origins",
+                "/registry/partnerships",
+                "/registry/services",
+                "/registry/categories",
+                "/registry", "/resources", "/company", "/staff"] },
+    "reports"
+  ],
+  "hide": ["/customers", "/suppliers", "/marketing", "/analytics", "/tasks"],
+  "labels": {
+    "/": "Dashboard",
+    "/sales": "CRM",
+    "/registry/staff": "Funcionários",
+    "/registry/locations": "Locais Operacionais",
+    "/registry/origins": "Origens",
+    "/registry/services": "Serviços",
+    "/registry/categories": "Categorias"
+  }
+}
+$$::jsonb WHERE id = 'beauty';
+
+-- O ofício passa a OFERECER os Cadastros. Sem isto o plugin fica instalado e
+-- calado: `resolvePluginRuntime` só liga por padrão quem está na oferta.
+UPDATE app.apps
+   SET preset = jsonb_set(
+         preset, '{modules}',
+         (SELECT jsonb_agg(DISTINCT m)
+            FROM jsonb_array_elements(
+                   COALESCE(preset->'modules', '[]'::jsonb) || '["registry"]'::jsonb) AS m))
+ WHERE id = 'beauty';