@fayz-ai/db 0.14.0 → 0.16.0

package/migrations/069_a_sondagem_de_irma_usa_indice.sql

@@ -0,0 +1,293 @@
+-- A sondagem de irmã usa índice.
+--
+-- Com o índice da 065 no lugar, a carga do Espaço Facial passou a andar a
+-- **21 linhas por segundo** — 18 horas para 1,4 milhão. O índice novo estava
+-- sendo usado; o problema era outra consulta, dentro do mesmo
+-- `migration._upsert_row_impl`, e ela é a que roda no caminho MAIS COMUM de
+-- todos: o da linha que já migrou e não mudou.
+--
+-- ── A consulta ──────────────────────────────────────────────────────────────
+--
+-- Toda vez que a origem reoferece uma linha com `status = 'migrated'`, o motor
+-- pergunta se existe uma IRMÃ — a mesma linha da origem gravada com outro
+-- destino, ainda `pending` ou `skipped`. É o que faz a fatura de uma Venda
+-- nascer numa segunda passada, quando o writer dela não existia na primeira.
+-- A pergunta é necessária. A forma dela não era:
+--
+--     AND s.source_numeric_id IS NOT DISTINCT FROM l.source_numeric_id
+--     AND s.source_uuid       IS NOT DISTINCT FROM l.source_uuid
+--
+-- `IS NOT DISTINCT FROM` não é um operador indexável. O planejador não tem como
+-- transformá-lo em condição de índice, então ele desce os dois como FILTRO
+-- sobre tudo o que a tabela e o projeto delimitam. Medido em 19/09/2026, com
+-- 298 mil linhas na ledger:
+--
+--     Index Scan using ledger_tenant_source_idx
+--       Index Cond: (source_project = … AND source_table = 'clients')
+--       Filter: ((NOT (source_numeric_id IS DISTINCT FROM 12345)) AND …)
+--       Rows Removed by Filter: 123535          ← a tabela inteira
+--       Buffers: shared hit=8467
+--     Execution Time: 83.592 ms
+--
+-- **83 ms e 66 MB por linha oferecida.** Em `clients` isso é 123.535 linhas
+-- lidas para responder uma pergunta cuja resposta é quase sempre "não".
+--
+-- ── O conserto ──────────────────────────────────────────────────────────────
+--
+-- Duas formas da mesma pergunta, escolhidas por qual chave a linha tem. Cada
+-- ramo é um qual simples, e cada um cai num índice que já existia:
+--
+--     numérica → ledger_source_numeric_key (source_project, source_table, source_numeric_id, …)
+--     uuid     → ledger_source_uuid_idx    (source_project, source_table, source_uuid)
+--
+-- O ramo numérico deixa de repetir o casamento de uuid, e isso NÃO muda o
+-- conjunto: dentro de (projeto, tabela) o id numérico já identifica a linha da
+-- origem — as irmãs no ledger são essa mesma linha com outro `target_table`.
+--
+-- A mesma correção vale para a segunda consulta com o mesmo operador, a que
+-- procura a linha de ledger de cada destino extra depois que o writer devolve
+-- `extra` (o caminho da fatura da Venda).
+--
+-- Nada muda no que o motor decide. O que muda é o preço de decidir.
+--
+-- Idempotente: substitui a função inteira.
+
+CREATE OR REPLACE FUNCTION migration._upsert_row_impl(p_batch uuid, p_source_table text, p_source_numeric_id bigint, p_source_uuid uuid, p_cursor text, p_row jsonb)
+ RETURNS jsonb
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  b migration.batches%ROWTYPE;
+  a migration.allowlist%ROWTYPE;
+  l migration.ledger%ROWTYPE;
+  v_checksum text := md5(p_row::text);
+  v_target_table text;
+  v_target_id uuid;
+  v_mapped jsonb; v_row jsonb; v_meta jsonb; v_unres jsonb;
+  v_dest jsonb; v_fin jsonb;
+  v_res jsonb; v_status text; v_col text; v_excl text;
+  v_retry_split boolean := false;
+  -- O V1 manda: ver migration.is_mirroring() e o cabeçalho deste arquivo.
+  v_mirror boolean := false;
+  x jsonb; v_xid bigint;
+BEGIN
+  SELECT * INTO b FROM migration.batches WHERE id = p_batch;
+  IF NOT FOUND THEN RAISE EXCEPTION 'upsert_row: unknown batch %', p_batch USING ERRCODE = 'P0002'; END IF;
+  IF b.status <> 'running' THEN
+    RAISE EXCEPTION 'upsert_row: batch % is % (only a running batch accepts rows)', p_batch, b.status USING ERRCODE = '55000';
+  END IF;
+  PERFORM migration._assert_fence(b.tenant_id);
+
+  v_mirror := coalesce(migration.is_mirroring(b.tenant_id), false);
+
+  SELECT * INTO a FROM migration.allowlist WHERE source_table = p_source_table;
+  v_target_table := a.target_table;
+
+  SELECT * INTO l FROM migration.ledger
+   WHERE source_project = b.source_project AND source_table = p_source_table
+     AND ((p_source_numeric_id IS NOT NULL AND source_numeric_id = p_source_numeric_id)
+       OR (p_source_numeric_id IS NULL AND source_uuid = p_source_uuid))
+     AND coalesce(target_table, '') = coalesce(v_target_table, '')
+   FOR UPDATE;
+  IF NOT FOUND THEN
+    INSERT INTO migration.ledger (source_project, source_table, source_numeric_id, source_uuid, tenant_id, target_table, checksum, cursor, batch_id, status)
+    VALUES (b.source_project, p_source_table, p_source_numeric_id, p_source_uuid, b.tenant_id, v_target_table, v_checksum, p_cursor, p_batch, 'pending')
+    RETURNING * INTO l;
+  ELSIF l.tenant_id <> b.tenant_id THEN
+    RETURN migration._quarantine(l.id, p_batch, 'tenant',
+      format('source row already belongs to tenant %s; this batch migrates tenant %s', l.tenant_id, b.tenant_id), p_row);
+  END IF;
+
+  -- allowlist
+  IF p_source_table LIKE 'import\_ef\_%' OR EXISTS (SELECT 1 FROM migration.excluded_tables e WHERE e.source_table = p_source_table) THEN
+    SELECT reason INTO v_excl FROM migration.excluded_tables e WHERE e.source_table = CASE WHEN p_source_table LIKE 'import\_ef\_%' THEN 'import_ef_*' ELSE p_source_table END;
+    RETURN migration._quarantine(l.id, p_batch, 'allowlist', 'source table is explicitly excluded: ' || coalesce(v_excl, 'no reason recorded'), p_row,
+      NULL, 'recorded decision: the table is in migration.excluded_tables');
+  END IF;
+  IF a.source_table IS NULL THEN
+    RETURN migration._quarantine(l.id, p_batch, 'allowlist', format('source table %s is not in the core-A allowlist', p_source_table), p_row);
+  END IF;
+  -- tenant identity of the source row vs the batch
+  IF b.source_tenant_id IS NOT NULL AND (p_row ->> 'tenant_id') ~ '^\d+$' AND (p_row ->> 'tenant_id')::bigint <> b.source_tenant_id THEN
+    RETURN migration._quarantine(l.id, p_batch, 'tenant',
+      format('source row tenant_id %s differs from the batch source_tenant_id %s', p_row ->> 'tenant_id', b.source_tenant_id), p_row);
+  END IF;
+
+  -- idempotency + delta
+  IF EXISTS (SELECT 1 FROM migration.quarantine q WHERE q.ledger_id = l.id AND q.resolved_at IS NULL AND md5(q.payload::text) = v_checksum) THEN
+    PERFORM migration._count(p_batch, 'skipped');
+    RETURN jsonb_build_object('status', 'skipped', 'reason', 'quarantined and unresolved: ' || coalesce(l.reason, ''),
+                              'target_table', l.target_table, 'target_id', l.target_id, 'ledger_id', l.id);
+  END IF;
+  IF l.status = 'migrated' THEN
+    -- a split destination that did not exist on the first offer (invoice) and exists now: run the writer again
+    -- Duas formas da MESMA pergunta, e não uma com IS NOT DISTINCT FROM: esse
+    -- operador não vira condição de índice, então a sondagem virava varredura
+    -- da ledger inteira daquela tabela — 83 ms e 66 MB POR LINHA oferecida,
+    -- medido com 123.535 linhas de `clients`. Aqui cada ramo é um qual simples
+    -- sobre a chave que existe, e os dois têm índice:
+    --   numérica → ledger_source_numeric_key (source_project, source_table, source_numeric_id, …)
+    --   uuid     → ledger_source_uuid_idx    (source_project, source_table, source_uuid)
+    -- O ramo numérico não repete o casamento de uuid porque não precisa: dentro
+    -- de (projeto, tabela) o id numérico JÁ identifica a linha da origem, e as
+    -- irmãs no ledger são a mesma linha com outro destino.
+    IF l.source_numeric_id IS NOT NULL THEN
+      SELECT EXISTS (SELECT 1 FROM migration.ledger s
+                      WHERE s.source_project = l.source_project AND s.source_table = l.source_table
+                        AND s.source_numeric_id = l.source_numeric_id
+                        AND s.id <> l.id AND s.status IN ('pending', 'skipped') AND to_regclass(s.target_table) IS NOT NULL) INTO v_retry_split;
+    ELSE
+      SELECT EXISTS (SELECT 1 FROM migration.ledger s
+                      WHERE s.source_project = l.source_project AND s.source_table = l.source_table
+                        AND s.source_uuid = l.source_uuid
+                        AND s.id <> l.id AND s.status IN ('pending', 'skipped') AND to_regclass(s.target_table) IS NOT NULL) INTO v_retry_split;
+    END IF;
+    IF l.checksum = v_checksum AND NOT v_retry_split THEN
+      PERFORM migration._count(p_batch, 'skipped');
+      RETURN jsonb_build_object('status', 'skipped', 'reason', 'unchanged', 'target_table', l.target_table, 'target_id', l.target_id, 'ledger_id', l.id);
+    END IF;
+    IF l.checksum <> v_checksum AND migration.cursor_cmp(p_cursor, l.cursor) < 0 THEN
+      PERFORM migration._count(p_batch, 'skipped');
+      RETURN jsonb_build_object('status', 'skipped', 'reason', format('stale cursor: %s < %s already migrated', p_cursor, l.cursor),
+                                'target_table', l.target_table, 'target_id', l.target_id, 'ledger_id', l.id);
+    END IF;
+  END IF;
+
+  -- no writer yet: recorded, re-offered later
+  IF a.writer IS NULL THEN
+    UPDATE migration.ledger SET status = 'pending', reason = format('no destination writer for %s yet', v_target_table),
+           checksum = v_checksum, cursor = p_cursor, batch_id = p_batch WHERE id = l.id;
+    PERFORM migration._count(p_batch, 'pending');
+    RETURN jsonb_build_object('status', 'pending', 'reason', format('no destination writer for %s yet', v_target_table),
+                              'target_table', v_target_table, 'target_id', l.target_id, 'ledger_id', l.id);
+  END IF;
+
+  -- map + references
+  v_mapped := migration.map_row(b.source_project, p_source_table, p_row);
+  v_row := v_mapped -> 'row'; v_meta := v_mapped -> 'metadata'; v_unres := v_mapped -> 'unresolved';
+  IF jsonb_array_length(v_unres) > 0 THEN
+    RETURN migration._quarantine(l.id, p_batch, 'fk', 'unresolved reference(s): ' || v_unres::text, p_row);
+  END IF;
+
+  -- destination id (ADR 0007): the source uuid, else the id minted on the first offer
+  v_target_id := coalesce(l.target_id, p_source_uuid, gen_random_uuid());
+  v_meta := jsonb_set(v_meta, '{migration}', coalesce(v_meta -> 'migration', '{}'::jsonb) || jsonb_build_object(
+              'source_project', b.source_project, 'source_table', p_source_table, 'source_numeric_id', p_source_numeric_id,
+              'source_uuid', p_source_uuid, 'batch_id', p_batch), true);
+  v_row := v_row || jsonb_build_object('metadata', v_meta);
+  SELECT coalesce(jsonb_object_agg(c, v_row -> c), '{}'::jsonb) INTO v_fin FROM unnest(a.financial_columns) c WHERE v_row ? c;
+
+  -- As duas travas do corte. Em regime de espelho elas ficam de fora, e é a única
+  -- diferença de comportamento deste arquivo:
+  --
+  --   valor financeiro   o V1 é a fonte da verdade enquanto o V2 não escreveu;
+  --                      recusar a atualização deixaria o V2 com o preço velho de
+  --                      uma venda que foi corrigida ontem, em silêncio.
+  --   linha apagada      quem apaga no V2 durante o espelho é o retire_row, e ele
+  --                      marca o ledger como `retired`. Uma linha ainda
+  --                      `migrated` cujo destino sumiu foi apagada por fora — e
+  --                      recriá-la é justamente refletir o V1, que ainda a tem.
+  IF l.status = 'migrated' AND NOT v_mirror THEN
+    IF cardinality(a.financial_columns) > 0 THEN
+      v_dest := migration._destination_values(v_target_table, l.target_id, a.financial_columns);
+      IF v_dest IS NULL THEN
+        RETURN migration._quarantine(l.id, p_batch, 'state', 'target row no longer exists in the destination (deleted after migration); not re-created', p_row);
+      END IF;
+      FOREACH v_col IN ARRAY a.financial_columns LOOP
+        IF (v_row ? v_col) AND round(coalesce((v_row ->> v_col)::numeric, 0), 2) IS DISTINCT FROM round(coalesce((v_dest ->> v_col)::numeric, 0), 2) THEN
+          RETURN migration._quarantine(l.id, p_batch, 'value',
+            format('financial column %s: destination %s, incoming %s — an existing financial value is never overwritten', v_col, coalesce(v_dest ->> v_col, 'null'), coalesce(v_row ->> v_col, 'null')), p_row);
+        END IF;
+      END LOOP;
+    ELSIF migration._destination_values(v_target_table, l.target_id, ARRAY['id']) IS NULL THEN
+      RETURN migration._quarantine(l.id, p_batch, 'state', 'target row no longer exists in the destination (deleted after migration); not re-created', p_row);
+    END IF;
+  END IF;
+
+  -- delegate; any error is a state quarantine, never a partial write
+  BEGIN
+    -- Dispatch by name rather than by a CASE arm per writer. The CASE meant every
+    -- new destination writer had to re-emit this whole function, and a row naming
+    -- a writer the CASE did not list fell through to NULL — silently, which is
+    -- the failure mode this schema exists to prevent. The allowlist's CHECK is
+    -- the vocabulary, `migration` is definer-only, and the name is verified to
+    -- exist before it is called, so an allowlist row naming a writer nobody built
+    -- quarantines with that sentence instead of vanishing.
+    IF to_regprocedure(format('migration.upsert_%s(uuid,uuid,jsonb,jsonb)', a.writer)) IS NULL THEN
+      RETURN migration._quarantine(l.id, p_batch, 'state',
+        format('the allowlist names writer %L for %s, and migration.upsert_%s does not exist', a.writer, p_source_table, a.writer),
+        p_row, v_target_table);
+    END IF;
+    -- %I on the whole identifier, not on the suffix: format('upsert_%I', 'order')
+    -- yields upsert_"order", which is not the function's name.
+    EXECUTE format('SELECT migration.%I($1, $2, $3, $4)', 'upsert_' || a.writer)
+      INTO v_res USING b.tenant_id, v_target_id, v_row, a.writer_args;
+  EXCEPTION WHEN OTHERS THEN
+    v_res := jsonb_build_object('status', 'quarantined', 'kind', 'state', 'reason', format('%s: %s', SQLSTATE, SQLERRM));
+  END;
+  v_status := coalesce(v_res ->> 'status', 'quarantined');
+
+  IF v_status = 'quarantined' THEN
+    RETURN migration._quarantine(l.id, p_batch, coalesce(v_res ->> 'kind', 'state'), coalesce(v_res ->> 'reason', 'writer refused'), p_row);
+  END IF;
+  IF v_status = 'skipped' THEN
+    UPDATE migration.ledger SET status = 'skipped', reason = v_res ->> 'reason', checksum = v_checksum, cursor = p_cursor, batch_id = p_batch,
+           target_id = coalesce((v_res ->> 'target_id')::uuid, target_id) WHERE id = l.id;
+    PERFORM migration._count(p_batch, 'skipped');
+    RETURN jsonb_build_object('status', 'skipped', 'reason', v_res ->> 'reason', 'target_table', v_target_table, 'target_id', v_res ->> 'target_id', 'ledger_id', l.id);
+  END IF;
+
+  v_target_id := coalesce((v_res ->> 'target_id')::uuid, v_target_id);
+  UPDATE migration.ledger
+     SET status = 'migrated', target_table = v_target_table, target_id = v_target_id, checksum = v_checksum, cursor = p_cursor,
+         batch_id = p_batch, reason = v_res ->> 'reason', financial = nullif(v_fin, '{}'::jsonb)
+   WHERE id = l.id;
+  UPDATE migration.quarantine SET resolved_at = now(), resolution = 'row migrated on a later offer' WHERE ledger_id = l.id AND resolved_at IS NULL;
+
+  -- split rows (a Venda's invoice): one more ledger row per extra destination
+  FOR x IN SELECT value FROM jsonb_array_elements(coalesce(v_res -> 'extra', '[]'::jsonb)) LOOP
+    -- Mesma correção da sondagem de irmã, pelo mesmo motivo: com
+    -- IS NOT DISTINCT FROM nenhum dos dois índices da ledger é usado, e esta
+    -- busca acontece uma vez por destino extra de cada Venda.
+    IF p_source_numeric_id IS NOT NULL THEN
+      SELECT id INTO v_xid FROM migration.ledger
+       WHERE source_project = b.source_project AND source_table = p_source_table
+         AND source_numeric_id = p_source_numeric_id
+         AND target_table = x ->> 'target_table';
+    ELSE
+      SELECT id INTO v_xid FROM migration.ledger
+       WHERE source_project = b.source_project AND source_table = p_source_table
+         AND source_numeric_id IS NULL AND source_uuid = p_source_uuid
+         AND target_table = x ->> 'target_table';
+    END IF;
+    IF v_xid IS NULL THEN
+      INSERT INTO migration.ledger (source_project, source_table, source_numeric_id, source_uuid, tenant_id, target_table, target_id, checksum, cursor, batch_id, status, reason, financial)
+      VALUES (b.source_project, p_source_table, p_source_numeric_id, p_source_uuid, b.tenant_id, x ->> 'target_table', (x ->> 'target_id')::uuid,
+              v_checksum, p_cursor, p_batch, x ->> 'status', x ->> 'reason', nullif(x -> 'financial', 'null'::jsonb));
+    ELSE
+      UPDATE migration.ledger SET target_id = (x ->> 'target_id')::uuid, checksum = v_checksum, cursor = p_cursor, batch_id = p_batch,
+             status = x ->> 'status', reason = x ->> 'reason', financial = coalesce(nullif(x -> 'financial', 'null'::jsonb), financial) WHERE id = v_xid;
+    END IF;
+  END LOOP;
+
+  INSERT INTO public.audit_logs (tenant_id, user_id, action, entity_type, entity_id, metadata)
+  VALUES (b.tenant_id, NULL, 'migration.upsert', v_target_table, v_target_id::text,
+          jsonb_build_object('batch_id', p_batch, 'source_project', b.source_project, 'source_table', p_source_table,
+                             'source_numeric_id', p_source_numeric_id, 'source_uuid', p_source_uuid, 'reason', v_res ->> 'reason'));
+  PERFORM migration._count(p_batch, 'migrated');
+  RETURN jsonb_build_object('status', 'migrated', 'reason', v_res ->> 'reason', 'target_table', v_target_table, 'target_id', v_target_id,
+                            'ledger_id', l.id, 'merged', coalesce((v_res ->> 'merged')::boolean, false), 'extra', coalesce(v_res -> 'extra', '[]'::jsonb));
+END $function$
+
+;
+
+
+-- ── 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._upsert_row_impl(uuid, text, bigint, uuid, text, jsonb) FROM PUBLIC, anon, authenticated;
+GRANT EXECUTE ON FUNCTION migration._upsert_row_impl(uuid, text, bigint, uuid, text, jsonb) TO service_role;

package/migrations/071_o_sdr_trabalha_o_funil_e_mais_nada.sql

@@ -0,0 +1,110 @@
+-- ---------------------------------------------------------------------------
+-- 071_o_sdr_trabalha_o_funil_e_mais_nada.sql — o papel que faltava entre o
+-- gerente e o operador de loja.
+--
+-- Quem trabalha uma lista de leads não é nenhum dos quatro que o template
+-- `generic` oferece hoje:
+--
+--   Administrator  lê o catálogo inteiro menos o que é do dono (029)
+--   Manager        44 permissões, incluindo financeiro, estoque e catálogo
+--   Staff          chão de operação — agenda, pedidos, catálogo. ZERO de CRM
+--   Viewer         só leitura, e de tudo
+--
+-- O sintoma que trouxe esta migration: um vendedor entrou como `Staff` e a
+-- tela de CRM respondeu "Acesso restrito". A saída à mão foi promovê-lo a
+-- Administrator — 211 permissões para quem precisa de dezenove, incluindo
+-- apagar conta a pagar e mexer em configuração de unidade.
+--
+-- A alternativa errada seria dar CRM ao `Staff`. `Staff` é o papel do balcão em
+-- TODA casa do cluster; acrescentar `crm.leads.read` ali entrega a lista de
+-- leads a todo operador de loja de todo cliente.
+--
+-- ── por que uma lista, e não o catálogo ─────────────────────────────────
+--
+-- A 029 dividiu os papéis em dois regimes e a divisão continua valendo: Owner e
+-- Administrator leem o CATÁLOGO, e crescem sozinhos quando um plugin novo
+-- registra permissões; manager, staff e viewer são RECORTES, escritos à mão,
+-- que precisam de decisão a cada plugin. O SDR é recorte pela mesma razão que
+-- o viewer é: um SDR que enxerga tudo o que existe deixou de ser SDR.
+--
+-- O preço é o que a 029 já nomeou — quando o CRM ganhar uma tela nova, alguém
+-- precisa lembrar deste papel. É o preço de um recorte ser deliberado.
+--
+-- ── o que ele pode, e o porquê de cada grupo ────────────────────────────
+--
+--   sales.read/edit            a rota `/sales` pede `sales.read`; sem ela a
+--                              tela inteira responde "Acesso restrito"
+--   crm.leads.*                ler, criar e editar. NÃO apagar, NÃO `manage`:
+--                              arquivar em massa é decisão de quem responde
+--                              pela base, não de quem trabalha ela
+--   crm.pipeline.read/edit     mover o card entre etapas. Criar e apagar ETAPA
+--                              é desenhar o processo — vocabulário do gerente
+--   crm.quotes.read/create     o SDR levanta o orçamento; aprovar e apagar não
+--   people.read/create/edit    um lead É uma linha de `people`. Sem isto a
+--                              lista não carrega. Sem `read_all` de propósito:
+--                              é a chave que abre a base inteira de pessoas
+--   conversations.read/create  falar com o lead é o trabalho, não um extra
+--   dashboard.read             o painel de onde ele vê o próprio dia
+--   config/tenancy/tenant/units .read   a casca: sem elas o shell não desenha
+--
+-- E o que ele NÃO pode, dito por extenso porque é o ponto do papel: financeiro,
+-- estoque, catálogo, pedidos, agenda, marketing, relatórios, membros, papéis,
+-- configurações. Nada fora do funil.
+--
+-- ── só no template `generic` ────────────────────────────────────────────
+--
+-- `restaurant`, `salon` e `clinic` têm vocabulários próprios — Garçom, Recepção,
+-- Profissional — e um SDR não é papel de nenhuma dessas casas. Se um dia for,
+-- é outra linha, tomada por quem conhece a operação delas.
+-- ---------------------------------------------------------------------------
+
+-- ── o recorte ──────────────────────────────────────────────────────────────
+INSERT INTO app.role_templates (template, role_key, role_name, sort_order, permission)
+SELECT 'generic', 'sdr', 'SDR', 3, p
+  FROM unnest(ARRAY[
+    'sales.read', 'sales.edit',
+    'crm.leads.read', 'crm.leads.create', 'crm.leads.edit',
+    'crm.pipeline.read', 'crm.pipeline.edit',
+    'crm.quotes.read', 'crm.quotes.create',
+    'people.read', 'people.create', 'people.edit',
+    'conversations.read', 'conversations.create',
+    'dashboard.read',
+    'config.read', 'tenancy.read', 'tenant.read', 'units.read'
+  ]) AS p
+ -- Só o que o catálogo realmente tem. Uma chave inventada aqui vira uma
+ -- permissão que nenhuma tela consulta: silenciosa, e por isso pior que um erro.
+ WHERE EXISTS (SELECT 1 FROM app.permissions perm WHERE perm.key = p)
+ON CONFLICT DO NOTHING;
+
+-- ── as casas que já existem ────────────────────────────────────────────────
+--
+-- A tabela acima serve quem nascer daqui para frente: `seed_role_template` lê
+-- dela. Quem já nasceu precisa da mesma conta agora, e pelo mesmo caminho que a
+-- 029 usou — criar o papel, depois conceder.
+--
+-- O alvo é quem TEM o recorte `generic`, reconhecido pela presença do papel
+-- `staff`. Uma clínica não ganha um SDR por causa desta migration.
+DO $$
+DECLARE v_roles integer; v_perms integer;
+BEGIN
+  INSERT INTO app.roles (tenant_id, key, name, is_system)
+  SELECT DISTINCT r.tenant_id, 'sdr', 'SDR', true
+    FROM app.roles r
+   WHERE r.key = 'staff'
+     AND EXISTS (SELECT 1 FROM app.roles a WHERE a.tenant_id = r.tenant_id AND a.key = 'admin')
+  ON CONFLICT (tenant_id, key) DO NOTHING;
+  GET DIAGNOSTICS v_roles = ROW_COUNT;
+
+  INSERT INTO app.role_permissions (tenant_id, role_id, permission)
+  SELECT r.tenant_id, r.id, t.permission
+    FROM app.roles r
+    JOIN app.role_templates t ON t.template = 'generic' AND t.role_key = 'sdr'
+   WHERE r.key = 'sdr'
+  ON CONFLICT DO NOTHING;
+  GET DIAGNOSTICS v_perms = ROW_COUNT;
+
+  RAISE NOTICE '071: % papel(is) SDR criado(s), % permissão(ões) concedida(s)', v_roles, v_perms;
+END $$;
+
+COMMENT ON TABLE app.role_templates IS
+  'Os recortes deliberados de cada template. Owner e admin leem o catálogo (029); manager, sdr, staff e viewer são listas, e cada plugin novo pede uma decisão sobre elas (071).';

package/migrations/072_o_porte_nao_avisa_a_plataforma_de_uma_venda_antiga.sql

@@ -0,0 +1,91 @@
+-- O porte não avisa a plataforma de uma venda de dois anos atrás.
+--
+-- `trg_orders_emit_completed` emite `order.completed` toda vez que um pedido
+-- fecha. Está certo: é assim que a automação, a notificação e a integração
+-- ficam sabendo que houve uma venda.
+--
+-- Só que o porte também fecha pedidos — 166.301 deles no Espaço Facial, todos
+-- de vendas que aconteceram entre 2025 e ontem. O gatilho não distinguia, e a
+-- plataforma foi informada de que **166 mil vendas acabaram de acontecer**.
+--
+-- ── Duas consequências, e a segunda é pior ──────────────────────────────────
+--
+-- A visível é o custo. Medido em 20/09/2026:
+--
+--     event_log          11.981 linhas  →  157.642 linhas (113 MB)
+--     pendentes (`recorded`)              101.225
+--     vazão do runner (`event_runner_tick`)  200/minuto
+--
+-- Oito horas de escrita contínua num disco que já estava sem crédito de
+-- rajada — e foi essa fila, somada à carga, que manteve a instância
+-- inoperante mesmo depois de o porte ser interrompido.
+--
+-- A invisível é o significado. Um evento não é um registro: é um AVISO. Quem
+-- assina `order.completed` pode mandar mensagem para o cliente, lançar
+-- comissão, chamar um webhook. Um porte que dispara esse aviso 166 mil vezes
+-- não está sendo lento — está mentindo sobre o presente.
+--
+-- ── A regra ─────────────────────────────────────────────────────────────────
+--
+-- O motor já marca as escritas dele: `migration.writer = 'on'`, um GUC local
+-- que todo `upsert_*` liga antes de escrever e que morre com a transação. O
+-- gatilho passa a olhar para ele.
+--
+-- Isso não silencia o evento para sempre nem "desliga trigger na carga": o
+-- fato continua gravado em `public.orders`, e qualquer fechamento feito pelo
+-- APP — que nunca liga esse GUC — emite como antes. O que sai é só o aviso
+-- sobre um fato que já era passado quando chegou aqui.
+--
+-- ── E a fila que já se formou ───────────────────────────────────────────────
+--
+-- Os eventos pendentes que vieram do porte são descartados, e só eles: a
+-- condição exige que o pedido tenha linha no `migration.ledger`. Um evento de
+-- venda feita no app não tem, e fica onde está. Marcados como `skipped` com o
+-- motivo escrito — não apagados, porque a fila é um registro do que a
+-- plataforma viu, e apagar esconderia esta própria decisão.
+--
+-- Idempotente.
+
+CREATE OR REPLACE FUNCTION public.trg_orders_emit_completed()
+ RETURNS trigger
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+BEGIN
+  -- O porte escreve com `migration.writer = 'on'`. Um pedido que ele fecha é
+  -- um fato ANTIGO chegando agora; avisar a plataforma seria descrever o
+  -- passado como se fosse o presente.
+  IF coalesce(current_setting('migration.writer', true), '') = 'on' THEN
+    RETURN NULL;
+  END IF;
+
+  IF NEW.status IS DISTINCT FROM 'completed' THEN
+    RETURN NULL;
+  END IF;
+  IF TG_OP = 'UPDATE' AND OLD.status IS NOT DISTINCT FROM 'completed' THEN
+    RETURN NULL;
+  END IF;
+
+  PERFORM public.plg_emit_event(
+    'order.completed',
+    jsonb_build_object(
+      'order_id',  NEW.id,
+      'kind',      NEW.kind,
+      'unit_id',   NEW.unit_id,
+      'party_id',  NEW.party_id,
+      'total',     NEW.total
+    ),
+    'order',
+    NEW.id::text,
+    NEW.tenant_id,
+    NULL
+  );
+  RETURN NULL;
+END $function$;
+
+COMMENT ON FUNCTION public.trg_orders_emit_completed() IS
+  'Avisa a plataforma que uma venda fechou. Silencioso quando quem fecha é o '
+  'porte (migration.writer = on): a venda migrada é um fato antigo, e emitir '
+  'o aviso faria a automação tratar 166 mil vendas de 2025 como se tivessem '
+  'acabado de acontecer.';