@fayz-ai/db 0.17.0 → 0.18.1

package/migrations/125_a_data_que_fecha_nao_e_a_data_que_so_lembra.sql

@@ -0,0 +1,160 @@
+-- ============================================================================
+-- 125 — A DATA QUE FECHA NÃO É A DATA QUE SÓ LEMBRA.
+--
+-- O V1 guarda as duas coisas na mesma tabela e as separa por UMA coluna,
+-- `holidays.is_holiday`, que o formulário chama de *Tipo*:
+--
+--   Feriado            "Afeta agenda e funcionamento"
+--   Data Comemorativa  "Usada no módulo de marketing"
+--
+-- O V2 herdou a tabela e PERDEU a coluna: o ETL trouxe 179 linhas para o Espaço
+-- Facial sem nenhum traço de `is_holiday` (o `metadata.migration` guarda só o
+-- batch e a origem). Sem ela, "Dia do Sorvete" e "Independência do Brasil" são
+-- a mesma coisa para quem lê a tabela — e uma agenda que tratasse as duas
+-- igualmente fecharia a casa no Dia do Sorvete ou abriria no dia 7 de setembro.
+--
+-- `kind` NÃO resolve isso: national|state|city|company é ALCANCE GEOGRÁFICO, e
+-- de fato as 177 linhas importadas estão todas em 'national', comemorativas
+-- inclusive. São eixos ortogonais.
+--
+-- ── O backfill, e o que ele deliberadamente não decide ──────────────────────
+--
+-- Marca como fechamento APENAS o que é feriado nacional por lei (Lei 662/1949,
+-- 6.802/1980 e 14.759/2024, mais a Sexta-feira Santa). Tudo o mais nasce
+-- comemorativo.
+--
+-- Carnaval, Quarta-feira de Cinzas e Corpus Christi ficam de FORA de propósito:
+-- são ponto facultativo, não feriado — quem fecha nesses dias é a casa, e o V1
+-- deixava isso por linha. Adivinhar aqui fecharia três dias do ano de 179
+-- tenants sem ninguém ter pedido. A tela permite virar a chave numa linha.
+--
+-- Idempotente: o UPDATE só toca linhas que ainda estão no padrão.
+-- ============================================================================
+
+ALTER TABLE public.holidays
+  ADD COLUMN IF NOT EXISTS closes boolean NOT NULL DEFAULT true;
+
+COMMENT ON COLUMN public.holidays.closes IS
+  'true = fecha/altera o funcionamento (o "Feriado" do V1); false = data comemorativa, só marketing.';
+
+-- Os nomes exatos com que o calendário oficial do V1 escreve os feriados
+-- nacionais. Comparação sem acento e sem caixa: a mesma data chega escrita
+-- "Nossa Senhora Aparecida" e "Nossa Senhora da Aparecida" no mesmo tenant.
+DO $$
+DECLARE
+  v_fechamentos text[] := ARRAY[
+    'confraternizacao universal',
+    'tiradentes',
+    'dia do trabalho',
+    'dia do trabalhador',
+    'sexta-feira santa',
+    'independencia do brasil',
+    'nossa senhora aparecida',
+    'nossa senhora da aparecida',
+    'finados',
+    'proclamacao da republica',
+    'consciencia negra',
+    'natal'
+  ];
+BEGIN
+  -- `translate` e não `unaccent`: a extensão não está garantida em todo pool, e
+  -- um corpo com search_path vazio só estoura na PRIMEIRA chamada.
+  UPDATE public.holidays h
+     SET closes = false
+   WHERE h.closes                      -- só o que ainda está no padrão
+     AND translate(lower(btrim(h.name)), 'áàâãéêíóôõúüç', 'aaaaeeiooouuc') <> ALL (v_fechamentos);
+END $$;
+
+-- ---------------------------------------------------------------------------
+-- A porta por onde a agenda lê. Sem `closes` aqui, o eixo existiria na tabela e
+-- não chegaria a tela nenhuma.
+-- ---------------------------------------------------------------------------
+-- DROP antes: `CREATE OR REPLACE` não muda a forma do RETURNS TABLE, e uma
+-- coluna nova é forma nova.
+DROP FUNCTION IF EXISTS public.holidays_for_unit(uuid, date, date);
+CREATE FUNCTION public.holidays_for_unit(p_unit uuid, p_from date, p_to date)
+RETURNS TABLE (id uuid, occurs_on date, name text, kind text, unit_id uuid,
+               recurring boolean, description text, closes boolean)
+LANGUAGE sql STABLE SET search_path = ''
+AS $$
+  WITH years AS (
+    SELECT generate_series(extract(year FROM p_from)::int, extract(year FROM p_to)::int) AS y
+  ),
+  scoped AS (
+    SELECT h.* FROM public.holidays h
+     WHERE h.tenant_id = app.current_tenant_id()
+       AND h.is_active
+       AND (h.unit_id IS NULL OR h.unit_id = p_unit)
+       AND (p_unit IS NULL OR EXISTS (SELECT 1 FROM app.units u WHERE u.tenant_id = h.tenant_id AND u.id = p_unit))
+  )
+  SELECT s.id, s.date AS occurs_on, s.name, s.kind, s.unit_id, s.recurring, s.description, s.closes
+    FROM scoped s
+   WHERE NOT s.recurring AND s.date BETWEEN p_from AND p_to
+  UNION ALL
+  SELECT s.id, (s.date + make_interval(years => (y.y - extract(year FROM s.date)::int)))::date,
+         s.name, s.kind, s.unit_id, s.recurring, s.description, s.closes
+    FROM scoped s CROSS JOIN years y
+   WHERE s.recurring
+     AND (s.date + make_interval(years => (y.y - extract(year FROM s.date)::int)))::date BETWEEN p_from AND p_to
+   ORDER BY 2, 3;
+$$;
+
+-- O DROP leva as concessões junto, e o padrão do Postgres é EXECUTE para
+-- PUBLIC — o que abriria o calendário da casa ao anon.
+REVOKE ALL ON FUNCTION public.holidays_for_unit(uuid, date, date) FROM PUBLIC;
+REVOKE ALL ON FUNCTION public.holidays_for_unit(uuid, date, date) FROM anon;
+GRANT EXECUTE ON FUNCTION public.holidays_for_unit(uuid, date, date) TO authenticated, service_role;
+
+-- ---------------------------------------------------------------------------
+-- E o writer do ETL, para que a próxima carga traga o eixo em vez de perdê-lo
+-- de novo. `closes` ausente no payload mantém o que está gravado: uma casa que
+-- virou a chave à mão não a perde na reimportação.
+-- ---------------------------------------------------------------------------
+CREATE OR REPLACE FUNCTION migration.upsert_holiday(p_tenant uuid, p_id uuid, p_row jsonb, p_args jsonb DEFAULT '{}'::jsonb)
+RETURNS jsonb LANGUAGE plpgsql SECURITY DEFINER SET search_path = ''
+AS $$
+DECLARE
+  v_meta jsonb := coalesce(p_row -> 'metadata', '{}'::jsonb);
+  v_kind text := coalesce(p_args ->> 'kind', 'company');
+  v_date date;
+  v_name text := nullif(btrim(coalesce(p_row ->> 'name', '')), '');
+  v_existing_tenant uuid;
+  v_created boolean := false;
+  v_standalone boolean := migration._standalone();
+BEGIN
+  IF v_standalone THEN PERFORM migration._assert_fence(p_tenant); PERFORM set_config('migration.writer', 'on', true); END IF;
+  BEGIN
+    v_date := (p_row ->> 'date')::date;
+  EXCEPTION WHEN OTHERS THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'value', 'reason', format('%L is not a date', p_row ->> 'date'));
+  END;
+  IF p_id IS NULL OR v_date IS NULL OR v_name IS NULL THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'state', 'reason', 'a holiday needs an id, a date and a name');
+  END IF;
+  IF v_kind NOT IN ('national', 'state', 'city', 'company') THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'value', 'reason', format('unknown holiday kind %L', v_kind));
+  END IF;
+  SELECT tenant_id INTO v_existing_tenant FROM public.holidays WHERE id = p_id;
+  IF v_existing_tenant IS NOT NULL AND v_existing_tenant <> p_tenant THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'tenant', 'reason', format('holiday %s already exists in another tenant', p_id));
+  END IF;
+  IF v_existing_tenant IS NULL THEN
+    INSERT INTO public.holidays (id, tenant_id, unit_id, date, name, kind, recurring, description, is_active, closes, metadata)
+    VALUES (p_id, p_tenant, (p_row ->> 'unit_id')::uuid, v_date, v_name, v_kind,
+            coalesce((p_row ->> 'recurring')::boolean, false), p_row ->> 'description',
+            coalesce((p_row ->> 'is_active')::boolean, true),
+            coalesce((p_row ->> 'closes')::boolean, true), v_meta);
+    v_created := true;
+  ELSE
+    UPDATE public.holidays SET
+      unit_id = CASE WHEN p_row ? 'unit_id' THEN (p_row ->> 'unit_id')::uuid ELSE unit_id END,
+      date = v_date, name = v_name, kind = v_kind,
+      recurring = CASE WHEN p_row ? 'recurring' THEN coalesce((p_row ->> 'recurring')::boolean, false) ELSE recurring END,
+      description = CASE WHEN p_row ? 'description' THEN p_row ->> 'description' ELSE description END,
+      closes = CASE WHEN p_row ? 'closes' THEN coalesce((p_row ->> 'closes')::boolean, true) ELSE closes END,
+      metadata = migration._merge_meta(metadata, v_meta)
+    WHERE id = p_id;
+  END IF;
+  IF v_standalone THEN PERFORM migration._audit(p_tenant, 'public.holidays', p_id, jsonb_build_object('reason', CASE WHEN v_created THEN 'created' ELSE 'updated' END)); END IF;
+  RETURN jsonb_build_object('status', 'migrated', 'target_id', p_id, 'reason', CASE WHEN v_created THEN 'created' ELSE 'updated' END);
+END $$;

package/migrations/126_o_telefone_procurado_nao_tem_parenteses.sql

@@ -0,0 +1,62 @@
+-- ============================================================================
+-- 126 — O TELEFONE PROCURADO NÃO TEM PARÊNTESES.
+--
+-- O V1 procura cliente por NOME, TELEFONE OU CPF ("a busca pede pelo menos 2
+-- caracteres e procura por nome, telefone ou CPF"). O V2 procura só por nome —
+-- e a recepção, com a cliente ao telefone, digita o número e não acha ninguém.
+--
+-- Por que não bastou trocar a consulta: dos 120.808 contatos do Espaço Facial,
+-- 100.322 têm o telefone GRAVADO COM FORMATO — "(21) 99999-9999" — e 19.689 em
+-- dígitos puros. Quem digita "21999999999" não casa com o primeiro grupo; quem
+-- digita "(21)" não casa com o segundo. Comparar texto com texto aqui é uma
+-- loteria sobre como o dado foi digitado anos atrás.
+--
+-- `phone_digits` é a mesma informação sem a pontuação, calculada pelo banco.
+-- GERADA, não copiada: uma coluna que alguém precisa lembrar de atualizar
+-- envelhece em silêncio, e uma busca que envelhece devolve "não encontrado"
+-- para quem está cadastrado.
+--
+-- `document_number` não precisa disto — os 114.476 preenchidos já estão em
+-- dígitos puros neste tenant.
+--
+-- ── Custo ──────────────────────────────────────────────────────────────────
+--
+-- Coluna gerada REESCREVE a tabela (565 MB, 123.483 linhas) com ACCESS
+-- EXCLUSIVE: `public.people` fica indisponível por dezenas de segundos. É uma
+-- janela curta, mas é uma janela — vale rodar fora do horário de balcão.
+--
+-- Os índices de trigrama são o outro lado: hoje CADA TECLA da busca faz varredura
+-- sequencial em 123 mil linhas, porque `ilike '%texto%'` não usa índice comum.
+-- `extensions.gin_trgm_ops` qualificado de propósito: a extensão não mora em
+-- `public`, e um nome sem esquema só falha na primeira chamada.
+-- ============================================================================
+
+ALTER TABLE public.people
+  ADD COLUMN IF NOT EXISTS phone_digits text
+  GENERATED ALWAYS AS (nullif(regexp_replace(coalesce(phone, ''), '[^0-9]', '', 'g'), '')) STORED;
+
+COMMENT ON COLUMN public.people.phone_digits IS
+  'O telefone só com dígitos, gerado a partir de `phone`. É por onde a busca procura.';
+
+CREATE INDEX IF NOT EXISTS people_phone_digits_trgm
+  ON public.people USING gin (phone_digits extensions.gin_trgm_ops);
+
+CREATE INDEX IF NOT EXISTS people_document_number_trgm
+  ON public.people USING gin (document_number extensions.gin_trgm_ops);
+
+CREATE INDEX IF NOT EXISTS people_name_trgm
+  ON public.people USING gin (name extensions.gin_trgm_ops);
+
+-- A VISTA MASCARADA TAMBÉM PRECISA SABER DA COLUNA NOVA.
+--
+-- `public.people` é a única tabela com leitura mascarada (`v_people`), e a
+-- vista é GERADA: coluna acrescentada à tabela e ausente da vista chega ao
+-- cliente como "não existe esse campo" — não como erro. O portão N16d do pgTAP
+-- existe exatamente para isto, e foi ele que pegou.
+DO $$
+BEGIN
+  IF to_regprocedure('app.masked_view_refresh(regclass,text,text)') IS NOT NULL
+     AND EXISTS (SELECT 1 FROM app.masked_views WHERE table_name = 'people') THEN
+    PERFORM app.masked_view_refresh('public.people', 'person', 'person');
+  END IF;
+END $$;

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;