@fayz-ai/db 0.14.0 → 0.16.0

package/migrations/064_um_arquivo_anexado_a_dezenove_contas.sql

@@ -0,0 +1,178 @@
+-- ---------------------------------------------------------------------------
+-- 064_um_arquivo_anexado_a_dezenove_contas.sql — a identidade do ledger de bytes
+-- era o objeto de origem, e ela não basta.
+--
+-- Medido em 19/09/2026 no Pertinho do Céu, logo depois da 063:
+--
+--     1.192 registros de anexo apontam para 681 arquivos distintos
+--     41 arquivos estão anexados a mais de uma conta
+--     `payroll/8/1781889562635_RECIBO_DE_PAGAMENTO_05.2026.pdf` está em 19
+--
+-- E faz sentido: um recibo de folha cobre dezenove funcionários, então o V1
+-- anexou o MESMO arquivo às dezenove contas. Não é sujeira — é como a casa
+-- trabalha.
+--
+-- ── O que quebrava ────────────────────────────────────────────────────────
+--
+-- A 054 chaveia o ledger de bytes por `(projeto, 'storage:<bucket>', md5 do
+-- caminho de origem)`. Para o avatar e a foto de ponto isso é exato: um objeto,
+-- um registro. Para o anexo não, e o efeito é silencioso — a primeira das
+-- dezenove sobe e fica `migrated`; as outras dezoito batem no mesmo ledger,
+-- voltam `skipped` por "bytes iguais", e ficam `v1-pending` **para sempre**,
+-- apontando para um V1 que vai sair do ar.
+--
+-- São **511 dos 1.192** registros nessa situação. E o pior: a rodada termina
+-- verde. `skipped` é a resposta certa para "já atravessou", e nada distingue
+-- "já atravessou" de "atravessou para OUTRO registro".
+--
+-- ── A identidade certa ────────────────────────────────────────────────────
+--
+-- Um byte que atravessa tem DUAS pontas, e o ledger precisa das duas: de onde
+-- veio, e para qual registro foi. Quando o backlog nomeia um `document_id`, ele
+-- entra na chave. Quando não nomeia — avatar, foto de ponto —, a chave é a de
+-- antes, porque ali o registro é derivado do objeto e a segunda ponta não
+-- acrescenta nada.
+--
+-- Cada um dos dezenove ganha a sua linha de ledger, o seu objeto no bucket e o
+-- seu checksum. Dezenove cópias do mesmo PDF é o preço, e é o preço certo:
+-- registros independentes, um apagado não cega os outros dezoito, e a conta de
+-- "quantos arquivos eu tenho desta pessoa" continua fechando.
+--
+-- ── As cinco linhas já gravadas ───────────────────────────────────────────
+--
+-- O ensaio da 063 gravou cinco linhas com a chave antiga. Elas não são
+-- apagadas: a chave nova não as encontra, o backlog reoferece os registros, e o
+-- upload vai com `x-upsert`. O que sobra é cinco linhas de ledger órfãs
+-- apontando para objetos que existem — inofensivas, e preferíveis a um DELETE
+-- num ledger de produção para arrumar aparência.
+--
+-- Idempotente e replay-safe.
+-- ---------------------------------------------------------------------------
+
+CREATE OR REPLACE FUNCTION migration._attach_asset_impl(
+  p_batch uuid, p_kind text, p_source_path text, p_row jsonb)
+RETURNS jsonb
+LANGUAGE plpgsql SECURITY DEFINER SET search_path = ''
+AS $$
+DECLARE
+  b migration.batches%ROWTYPE;
+  k migration.asset_kinds%ROWTYPE;
+  l migration.ledger%ROWTYPE;
+  v_source_table text;
+  v_source_uuid  uuid;
+  v_checksum text := p_row ->> 'checksum';
+  v_doc uuid;
+  v_person uuid := nullif(p_row ->> 'person_id', '')::uuid;
+  v_adotado uuid := nullif(p_row ->> 'document_id', '')::uuid;
+BEGIN
+  SELECT * INTO b FROM migration.batches WHERE id = p_batch;
+  IF NOT FOUND THEN RAISE EXCEPTION 'attach_asset: lote % desconhecido', p_batch USING ERRCODE = 'P0002'; END IF;
+  IF b.status <> 'running' THEN
+    RAISE EXCEPTION 'attach_asset: o lote % está %  (só um lote em execução aceita arquivo)', p_batch, b.status USING ERRCODE = '55000';
+  END IF;
+  PERFORM migration._assert_fence(b.tenant_id);
+
+  SELECT * INTO k FROM migration.asset_kinds WHERE kind = p_kind;
+  IF NOT FOUND THEN
+    RAISE EXCEPTION 'attach_asset: espécie % não está em migration.asset_kinds', p_kind USING ERRCODE = '22023';
+  END IF;
+  IF v_checksum IS NULL OR p_row ->> 'target_path' IS NULL THEN
+    RAISE EXCEPTION 'attach_asset: preciso de checksum e target_path' USING ERRCODE = '22023';
+  END IF;
+
+  v_source_table := 'storage:' || k.source_bucket;
+  -- As duas pontas do byte. O `document_id` só entra quando existe: sem ele a
+  -- chave é a da 054, e um avatar já migrado continua sendo reconhecido.
+  v_source_uuid  := md5(v_source_table || ':' || p_source_path
+                        || coalesce('::' || v_adotado::text, ''))::uuid;
+
+  SELECT * INTO l FROM migration.ledger
+   WHERE source_project = b.source_project AND source_table = v_source_table
+     AND source_uuid = v_source_uuid AND coalesce(target_table, '') = 'public.documents'
+   FOR UPDATE;
+  IF NOT FOUND THEN
+    INSERT INTO migration.ledger (source_project, source_table, source_uuid, tenant_id,
+                                  target_table, checksum, cursor, batch_id, status)
+    VALUES (b.source_project, v_source_table, v_source_uuid, b.tenant_id,
+            'public.documents', v_checksum, p_source_path, p_batch, 'pending')
+    RETURNING * INTO l;
+  ELSIF l.tenant_id <> b.tenant_id THEN
+    RETURN migration._quarantine(l.id, p_batch, 'tenant',
+      format('o objeto %s já é do tenant %s; este lote migra o %s', p_source_path, l.tenant_id, b.tenant_id), p_row);
+  ELSIF l.status = 'migrated' AND l.checksum = v_checksum THEN
+    PERFORM migration._count(p_batch, 'skipped');
+    RETURN jsonb_build_object('status', 'skipped', 'reason', 'bytes iguais',
+                              'target_table', 'public.documents', 'target_id', l.target_id, 'ledger_id', l.id);
+  END IF;
+
+  -- O registro ADOTADO vem primeiro: quando o backlog nomeia um documento,
+  -- aquela linha é o anexo, e cunhar outra deixaria o mesmo arquivo duas vezes
+  -- na conta (063).
+  v_doc := coalesce(v_adotado, l.target_id, md5('document:' || p_kind || ':' || (p_row ->> 'target_path'))::uuid);
+
+  IF v_adotado IS NOT NULL AND NOT EXISTS (
+       SELECT 1 FROM public.documents d WHERE d.id = v_adotado AND d.tenant_id = b.tenant_id) THEN
+    RETURN migration._quarantine(l.id, p_batch, 'fk',
+      format('o registro %s não existe neste tenant — o backlog está apontando para um documento que sumiu', v_adotado), p_row);
+  END IF;
+
+  INSERT INTO public.documents (
+    id, tenant_id, kind, person_id, subject_type, subject_id, title, status,
+    file_url, file_name, file_size, mime_type,
+    storage_provider, storage_bucket, storage_path, checksum, metadata)
+  VALUES (
+    v_doc, b.tenant_id, p_kind, v_person,
+    p_row ->> 'subject_type', nullif(p_row ->> 'subject_id', '')::uuid,
+    p_row ->> 'title', 'active',
+    p_row ->> 'public_url', p_row ->> 'file_name',
+    nullif(p_row ->> 'file_size', '')::integer, p_row ->> 'mime_type',
+    'supabase', k.target_bucket, p_row ->> 'target_path', v_checksum,
+    jsonb_build_object('migration', jsonb_build_object(
+      'source_project', b.source_project, 'source_bucket', k.source_bucket,
+      'source_path', p_source_path, 'batch_id', p_batch)))
+  ON CONFLICT (id) DO UPDATE SET
+    person_id        = coalesce(EXCLUDED.person_id, public.documents.person_id),
+    -- Num registro adotado, quem sabe o sujeito e o nome é a linha que já está
+    -- lá: ela veio do de-para. O que o transporte tem a dizer é onde os bytes
+    -- foram parar.
+    subject_type     = coalesce(public.documents.subject_type, EXCLUDED.subject_type),
+    subject_id       = coalesce(public.documents.subject_id, EXCLUDED.subject_id),
+    title            = coalesce(public.documents.title, EXCLUDED.title),
+    file_url         = EXCLUDED.file_url,
+    file_name        = coalesce(public.documents.file_name, EXCLUDED.file_name),
+    file_size        = EXCLUDED.file_size,
+    mime_type        = coalesce(EXCLUDED.mime_type, public.documents.mime_type),
+    storage_provider = EXCLUDED.storage_provider,
+    storage_bucket   = EXCLUDED.storage_bucket,
+    storage_path     = EXCLUDED.storage_path,
+    checksum         = EXCLUDED.checksum,
+    is_active        = true,
+    metadata         = migration._merge_meta(public.documents.metadata, EXCLUDED.metadata),
+    updated_at       = now();
+
+  IF k.pointer_fn IS NOT NULL THEN
+    EXECUTE format('SELECT %s($1, $2, $3)', k.pointer_fn)
+      USING b.tenant_id, v_doc, p_row || jsonb_build_object('bucket', k.target_bucket);
+  END IF;
+
+  UPDATE migration.ledger
+     SET status = 'migrated', target_id = v_doc, checksum = v_checksum,
+         cursor = p_source_path, batch_id = p_batch, reason = NULL
+   WHERE id = l.id;
+  PERFORM migration._count(p_batch, 'migrated');
+
+  RETURN jsonb_build_object('status', 'migrated', 'target_table', 'public.documents',
+                            'target_id', v_doc, 'ledger_id', l.id);
+END $$;
+
+COMMENT ON FUNCTION migration._attach_asset_impl(uuid, text, text, jsonb) IS
+  'Um arquivo que atravessou. A identidade no ledger é o OBJETO DE ORIGEM mais o REGISTRO de destino quando há um (064): sem a segunda ponta, um arquivo anexado a dezenove contas dava bytes a uma e deixava dezoito apontando para o V1, com a rodada terminando verde.';
+
+
+-- ── quem pode executar ────────────────────────────────────────────────────
+--
+-- Função nova nasce executável por PUBLIC, e `anon`/`authenticated` herdam
+-- dali. Estas são de PORTE: SECURITY DEFINER, escrevem dados de qualquer
+-- inquilino. Só o service_role, que é quem roda a onda.
+REVOKE ALL ON FUNCTION migration._attach_asset_impl(uuid, text, text, jsonb) FROM PUBLIC, anon, authenticated;
+GRANT EXECUTE ON FUNCTION migration._attach_asset_impl(uuid, text, text, jsonb) TO service_role;

package/migrations/065_apagar_o_sobrevivente_nao_apaga_o_tenant.sql

@@ -0,0 +1,59 @@
+-- 065_apagar_o_sobrevivente_nao_apaga_o_tenant.sql — quem foi fundido volta a
+-- poder ser apagado.
+--
+-- `person_erase()` é o RPC de apagamento da LGPD. Ele faz `DELETE FROM
+-- public.people` e confia nas chaves estrangeiras, como diz o próprio
+-- comentário dele: "What references it with ON DELETE SET NULL keeps its shape
+-- (a sale still happened) and loses the person".
+--
+-- Uma dessas chaves é a de `people` para ela mesma:
+--
+--     people_merged_into_fk
+--       FOREIGN KEY (tenant_id, merged_into_id)
+--       REFERENCES people(tenant_id, id) ON DELETE SET NULL
+--
+-- SET NULL composto SEM lista de colunas anula TODAS as colunas da chave. E
+-- `tenant_id` é NOT NULL. Então apagar alguém que é SOBREVIVENTE de um merge
+-- tenta anular o `tenant_id` da lápide e morre:
+--
+--     23502: null value in column "tenant_id" of relation "people"
+--            violates not-null constraint
+--
+-- O efeito é preciso e ruim: **um pedido de exclusão de titular falha
+-- exatamente para quem já apareceu duas vezes no cadastro** — que é, por
+-- construção, a pessoa mais provável de ter duas fichas e de pedir para sumir.
+--
+-- Não aparecia porque outra coisa barrava o DELETE antes: quatro chaves do CRM
+-- estavam em NO ACTION e faziam `person_erase` falhar mais cedo, com outro
+-- erro. Corrigidas aquelas (plugin-crm/017), este defeito ficou na frente.
+--
+-- É o MESMO erro que plugin-crm/013 já tinha documentado ao criar
+-- `plg_crm_deals.company_id`, e lá a lista de colunas foi escrita desde o
+-- começo justamente por causa disto. Aqui faltou.
+--
+-- A correção é a lista de colunas — `SET NULL (merged_into_id)`, suportada
+-- desde o Postgres 15. A lápide perde o ponteiro para quem foi apagado e
+-- continua sendo uma linha do seu tenant, que é o que ela sempre deveria ter
+-- sido: registro de que aquelas duas fichas eram a mesma pessoa.
+
+DO $$
+BEGIN
+  IF EXISTS (
+    SELECT 1 FROM pg_constraint
+     WHERE conname = 'people_merged_into_fk'
+       AND conrelid = 'public.people'::regclass
+       -- Só recria se ainda estiver na forma antiga. `confdelsetcols` vazio é
+       -- "anula a chave inteira"; preenchido é a lista que queremos.
+       AND coalesce(array_length(confdelsetcols, 1), 0) = 0
+  ) THEN
+    ALTER TABLE public.people DROP CONSTRAINT people_merged_into_fk;
+    ALTER TABLE public.people
+      ADD CONSTRAINT people_merged_into_fk
+      FOREIGN KEY (tenant_id, merged_into_id)
+      REFERENCES public.people (tenant_id, id)
+      ON DELETE SET NULL (merged_into_id);
+  END IF;
+END $$;
+
+COMMENT ON CONSTRAINT people_merged_into_fk ON public.people IS
+  'A lápide aponta para o sobrevivente. SET NULL com LISTA DE COLUNAS: sem ela o Postgres anula tambem o tenant_id, que é NOT NULL, e apagar um sobrevivente de merge passa a ser impossível (23502). Ver o cabeçalho de 065.';

package/migrations/066_the_port_machinery_closes_its_doors.sql

@@ -0,0 +1,51 @@
+-- ---------------------------------------------------------------------------
+-- 066_the_port_machinery_closes_its_doors.sql — the V1 port's new pieces get
+-- the posture the rest of schema `migration` already has.
+--
+-- 045 (the mirror) and 054 (migrated files get their bytes) added two tables
+-- and a set of functions to schema `migration` and gave them none of the
+-- contract 090_migration_ledger/001 grades:
+--
+--   · `migration.asset_kinds` and `migration.retire_policy` had row security
+--     off and no grant to service_role — the one role that is supposed to
+--     write them, and the only one that should.
+--   · every function the two files created kept PostgreSQL's default
+--     `EXECUTE TO PUBLIC`, which on Supabase means `anon`. Among them
+--     `retire_row`, `attach_asset` and `register_asset_kind`: writers of the
+--     port's own ledger, callable by anyone holding the anon key.
+--
+-- 045 and 054 are applied on the cluster and their checksums are in the
+-- ledger, so the fix is this file and not an edit to them.
+--
+-- The function sweep is by schema, not by name: whatever `migration` holds
+-- when this runs loses PUBLIC/anon/authenticated and keeps service_role. The
+-- plugins that add functions to this schema after the spine (plugin-financial)
+-- run the same sweep at the end of their own chain.
+-- ---------------------------------------------------------------------------
+
+DO $$
+DECLARE t text;
+BEGIN
+  FOREACH t IN ARRAY ARRAY['asset_kinds', 'retire_policy'] LOOP
+    IF to_regclass(format('migration.%I', t)) IS NOT NULL THEN
+      EXECUTE format('ALTER TABLE migration.%I ENABLE ROW LEVEL SECURITY', t);
+      EXECUTE format('GRANT SELECT, INSERT, UPDATE, DELETE ON migration.%I TO service_role', t);
+    END IF;
+  END LOOP;
+END $$;
+
+DO $$
+DECLARE f regprocedure;
+BEGIN
+  FOR f IN
+    SELECT p.oid::regprocedure
+      FROM pg_proc p
+      JOIN pg_namespace n ON n.oid = p.pronamespace
+     WHERE n.nspname = 'migration'
+       AND (has_function_privilege('anon', p.oid, 'EXECUTE')
+            OR has_function_privilege('authenticated', p.oid, 'EXECUTE'))
+  LOOP
+    EXECUTE format('REVOKE ALL ON FUNCTION %s FROM PUBLIC, anon, authenticated', f);
+    EXECUTE format('GRANT EXECUTE ON FUNCTION %s TO service_role', f);
+  END LOOP;
+END $$;

package/migrations/067_the_erp_keeps_the_front_door.sql

@@ -0,0 +1,56 @@
+-- ---------------------------------------------------------------------------
+-- 067_the_erp_keeps_the_front_door.sql — FullControl requires `marketing`
+-- again.
+--
+-- 053 took `marketing` out of the app's `requires` on the reading that "the
+-- acquisition machine is LeadControl's product". But 052 §3 retired the
+-- LeadControl row (`active = false`, `url = NULL`): there is no LeadControl
+-- left to own it. Read together, the two files left campaigns, the funnel and
+-- the landing page with its capture form — the only public door a lead comes
+-- through — without an app.
+--
+-- FullControl is where that work lives now. The ERP is the wider house; the
+-- sales engine built as LeadControl (company model, identity, economic group,
+-- more than one funnel, cadences, the cascading offer) is its commercial
+-- module, and a commercial module whose leads cannot arrive is a list someone
+-- has to type into by hand. So the app mounts plugin-marketing again, and
+-- `requires` has to say so: it is the list a tenant is seeded with when it
+-- ACTIVATES the app, and a plugin the bundle mounts but the tenant never got
+-- renders as a dead rail entry.
+--
+-- `inventory` stays out, as 053 decided.
+--
+-- ── Why a new file ──────────────────────────────────────────────────────────
+--
+-- 052 and 053 are applied and the ledger holds their sha256. And 052's
+-- ON CONFLICT only ever GROWS `requires` on a reapply, so it cannot be the
+-- vehicle either. This is the explicit step, the same way 053 was.
+--
+-- ── Who gets the plugin now ─────────────────────────────────────────────────
+--
+-- Every tenant that carried LeadControl already has `marketing` lit: 011 put
+-- it in `requires` and 011 §3 seeded it, and `app.tenant_plugins` has no
+-- app_id, so 052's rename did not touch it. §2 below only reaches a tenant
+-- that activated `full` between 053 and this file — and, as in 052 §5, the
+-- plan ceiling wins over the default: a plan that does not permit `marketing`
+-- does not get it lit, and the seeding does not fail because of it.
+-- ---------------------------------------------------------------------------
+
+-- ── §1  the seeding list ──────────────────────────────────────────────────
+--
+-- Additive on purpose: a later milestone may have appended a plugin after
+-- this file was written, and overwriting the array here would undo it
+-- silently.
+UPDATE app.apps
+   SET requires = (SELECT array_agg(DISTINCT p ORDER BY p)
+                     FROM unnest(requires || ARRAY['marketing']) AS p)
+ WHERE id = 'full';
+
+-- ── §2  the tenants that activated FullControl without it ───────────────────
+INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+SELECT DISTINCT ta.tenant_id, 'marketing', '', 'active', 'default'
+  FROM app.tenant_apps ta
+ WHERE ta.app_id = 'full'
+   AND ta.status = 'active'
+   AND public.plan_permits('marketing', '', ta.tenant_id)
+ON CONFLICT (tenant_id, plugin_id, facet) DO NOTHING;

package/migrations/068_o_ledger_encontra_a_linha_pelo_caminho_que_o_writer_usa.sql

@@ -0,0 +1,55 @@
+-- O ledger encontra a linha pelo caminho que o writer usa.
+--
+-- Todo writer que resolve uma referência pergunta ao ledger a mesma coisa:
+--
+--     SELECT target_id FROM migration.ledger
+--      WHERE tenant_id = … AND source_table = … AND source_numeric_id = …
+--        AND target_table = … AND status = 'migrated'
+--
+-- Nenhum índice cobre essa forma. O que existe —
+-- `ledger_source_numeric_key (source_project, source_table, source_numeric_id, …)`
+-- — começa por `source_project`, que a consulta não informa. Sem a coluna da
+-- frente, o Postgres faz varredura.
+--
+-- Medido em 19/09/2026 no tenant Espaço Facial, UMA busca:
+--
+--     Index Scan using ledger_source_numeric_key  (actual time=5416.611..5416.634 rows=0)
+--       Buffers: shared hit=11 read=6891
+--     Execution Time: 5423.387 ms
+--
+-- **5,4 segundos e 55 MB lidos, por linha.** E o custo cresce com a ledger: o
+-- porte do Espaço Facial a levou de ~60 mil para 298 mil linhas numa noite, e
+-- `account_central` sozinha paga essa conta 125.945 vezes. É O(n) por registro
+-- num porte de 1,4 milhão — a razão de a carga não terminar.
+--
+-- Ninguém escreveu essa consulta errada; ela é a pergunta certa. O que faltava
+-- era o índice que a responde.
+--
+-- ── Por que estas colunas, nesta ordem ──────────────────────────────────────
+--
+-- `tenant_id` primeiro porque é o recorte que sempre existe e o que mais
+-- elimina. Depois `source_table` e `source_numeric_id`, que juntos identificam
+-- a linha da origem. `target_table` por último, porque a mesma linha do V1 tem
+-- mais de um destino — uma `invoice` vira pedido E título — e é ela que separa
+-- os dois.
+--
+-- `status` fica FORA: ele muda (`pending` → `migrated` → `retired`), e uma
+-- coluna que muda dentro do índice faz cada transição reescrever a entrada. O
+-- filtro por status sobre as duas ou três linhas que sobram é grátis.
+--
+-- O índice é PARCIAL em `source_numeric_id IS NOT NULL` porque a origem que se
+-- identifica por uuid não usa este caminho — e um índice parcial que cobre o
+-- caso real é menor e mais rápido que um completo que carrega o resto.
+--
+-- Idempotente.
+
+CREATE INDEX IF NOT EXISTS ledger_tenant_table_numeric_idx
+  ON migration.ledger (tenant_id, source_table, source_numeric_id, target_table)
+  WHERE source_numeric_id IS NOT NULL;
+
+COMMENT ON INDEX migration.ledger_tenant_table_numeric_idx IS
+  'A forma exata em que os writers consultam o ledger para resolver uma '
+  'referência. Sem ele a busca é varredura: 5,4 s e 55 MB por linha, medido '
+  'com 298 mil linhas de ledger — o que torna impossível um porte de milhão.';
+
+ANALYZE migration.ledger;