@fayz-ai/db 0.18.2 → 0.20.1

package/migrations/136_a_baixa_do_espelho_e_do_porte_nao_do_v2.sql

@@ -0,0 +1,204 @@
+-- A baixa do espelho é do porte, não do V2.
+--
+-- O espelho D-1 desliga o próprio reap na primeira vez que ele funciona, e
+-- depois disso nunca mais propaga uma exclusão. Medido em 28/09/2026, os dois
+-- tenants em regime de espelho estão travados:
+--
+--                      mirror_since              first_v2_write_at        is_mirroring
+--     Espaço Facial    2026-09-19 03:04:20       2026-09-19 22:17:18      false
+--     Pertinho do Céu  2026-09-18 15:15:30       2026-09-20 14:21:58      false
+--
+-- O carimbo do Espaço Facial cai DOIS SEGUNDOS antes da própria rodada do
+-- espelho gravar o cursor do reap (`fayz_etl_meta.mirror_reap_cursor`,
+-- 22:17:20). Não foi ninguém usando o V2: foi o reap.
+--
+-- ── O mecanismo ────────────────────────────────────────────────────────────
+--
+-- `migration.trg_ponr_stamp` existe em `public.orders` e `public.people`, e a
+-- primeira linha dele é a escotilha que todo writer do porte usa:
+--
+--     IF coalesce(current_setting('migration.writer', true), '') = 'on'
+--       THEN RETURN NULL; END IF;
+--
+-- Os 30 e tantos `migration.upsert_*` declaram essa flag. `migration.retire_row`
+-- não declara — e ele escreve: a escada de baixa faz `UPDATE ... SET
+-- cancelled_at` / `deleted_at` / `is_active = false` e, quando a tabela não tem
+-- nenhuma dessas colunas, `DELETE`. Numa venda ou numa pessoa, qualquer um dos
+-- dois acorda o gatilho.
+--
+-- A partir daí o laço fecha sozinho:
+--
+--     reap baixa uma venda  →  ponr carimba first_v2_write_at = now()
+--                           →  is_mirroring(tenant) = false
+--                           →  a rodada seguinte recusa TODA baixa
+--                              ('tenant is not in mirror mode')
+--
+-- E o custo aparece longe da causa, como saldo que não fecha. Medido em
+-- 28/09/2026, exclusões do V1 pendentes desde que cada tenant travou:
+--
+--     Espaço Facial      324 financial_movements, 16 invoice_items,
+--                        13 payment_allocations, 26 recurring_bill_occurrences
+--     Pertinho do Céu    244 financial_movements
+--
+-- Numa semana do Pertinho do Céu (unidade 58, 2026-W38) isso são 14 contas a
+-- pagar que o V1 já não tem e o V2 ainda mostra — R$ 18.181,92 de fantasma numa
+-- semana só, e a conferência A × B acusa o V2 com MAIS dinheiro que a origem.
+--
+-- ── O conserto ─────────────────────────────────────────────────────────────
+--
+-- Uma linha: `retire_row` declara o que ele é. A baixa é o porte agindo sobre
+-- uma linha que o porte trouxe, e o ponto-sem-retorno é sobre o V2 assumir a
+-- escrita — duas coisas diferentes que hoje se confundem.
+--
+-- O que este arquivo NÃO faz: rearmar os dois tenants que já travaram. Empurrar
+-- `mirror_since` para depois de um carimbo é decidir que nada escrito naquela
+-- janela vale mais que a origem, e isso é decisão de quem é dono do tenant, não
+-- de uma migration. O operador a toma com o relatório na mão (fayz-etl:
+-- `mirror-rearm`, que lista o que nasceu no V2 antes de mexer na cerca).
+--
+-- Idempotente.
+
+CREATE OR REPLACE FUNCTION migration.retire_row(p_batch uuid, p_source_table text, p_source_numeric_id bigint, p_source_uuid uuid, p_reason text DEFAULT 'apagada na origem'::text)
+ RETURNS jsonb
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  b migration.batches%ROWTYPE;
+  l migration.ledger%ROWTYPE;
+  pol migration.retire_policy%ROWTYPE;
+  v_mirror boolean;
+  v_col text; v_val text; v_type text;
+  v_n integer := 0;
+  v_done integer := 0;
+  v_first jsonb;
+BEGIN
+  SELECT * INTO b FROM migration.batches WHERE id = p_batch;
+  IF NOT FOUND THEN RAISE EXCEPTION 'retire_row: unknown batch %', p_batch USING ERRCODE = 'P0002'; END IF;
+  IF b.status <> 'running' THEN
+    RAISE EXCEPTION 'retire_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);
+
+  -- A baixa É o porte agindo, e o gatilho do ponto-sem-retorno precisa saber
+  -- disso antes de qualquer escrita. Sem esta linha, o primeiro DELETE numa
+  -- `public.orders` (ou o `deleted_at` numa `public.people`) carimba
+  -- `first_v2_write_at = now()`, `is_mirroring` passa a devolver false, e a
+  -- rodada SEGUINTE recusa baixar qualquer coisa — o espelho desliga o próprio
+  -- reap na primeira vez que ele funciona. Transaction-local: não vaza.
+  PERFORM set_config('migration.writer', 'on', true);
+
+  v_mirror := coalesce(migration.is_mirroring(b.tenant_id), false);
+  IF NOT v_mirror THEN
+    -- Baixar fora do regime de espelho seria apagar do V2 um dado que o V2 pode
+    -- já ter adotado como seu. A recusa é a trava, não um detalhe de permissão.
+    RETURN jsonb_build_object('status', 'refused', 'reason',
+      'tenant is not in mirror mode; a retirement outside the mirror regime would '
+      'delete data the V2 may already own');
+  END IF;
+
+  -- Uma linha da origem pode ter mais de um destino (a Venda e o seu título).
+  -- Baixar um e deixar o outro deixaria o financeiro apontando para nada.
+  FOR l IN
+    SELECT * FROM migration.ledger
+     WHERE source_project = b.source_project
+       AND source_table = p_source_table
+       AND tenant_id = b.tenant_id
+       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 status = 'migrated'
+       AND target_table IS NOT NULL
+       AND target_id IS NOT NULL
+     FOR UPDATE
+  LOOP
+    v_n := v_n + 1;
+    SELECT * INTO pol FROM migration.retire_policy WHERE target_table = l.target_table;
+
+    IF pol.mode = 'keep' THEN
+      UPDATE migration.ledger
+         SET status = 'retired', reason = 'retire_policy=keep: ' || pol.reason,
+             batch_id = p_batch, updated_at = now()
+       WHERE id = l.id;
+      v_done := v_done + 1;
+      CONTINUE;
+    END IF;
+
+    -- A escada. `deleted_at` e `cancelled_at` primeiro porque preservam a linha
+    -- e a história; `is_active` depois; o DELETE só quando não há nada que
+    -- signifique "não vale mais" naquela tabela.
+    v_col := NULL;
+    IF pol.mode = 'soft' THEN
+      v_col := pol.column_name; v_val := pol.value;
+    ELSIF pol.mode IS NULL THEN
+      IF    migration._has_column(l.target_table, 'deleted_at')   THEN v_col := 'deleted_at';   v_val := NULL;
+      ELSIF migration._has_column(l.target_table, 'cancelled_at') THEN v_col := 'cancelled_at'; v_val := NULL;
+      ELSIF migration._has_column(l.target_table, 'is_active')    THEN v_col := 'is_active';    v_val := 'false';
+      ELSIF migration._has_column(l.target_table, 'active')       THEN v_col := 'active';       v_val := 'false';
+      END IF;
+    END IF;
+
+    BEGIN
+      IF v_col IS NOT NULL THEN
+        IF v_val IS NULL THEN
+          EXECUTE format('UPDATE %s SET %I = now() WHERE id = $1', l.target_table, v_col)
+            USING l.target_id;
+        ELSE
+          SELECT a.atttypid::regtype::text INTO v_type
+            FROM pg_attribute a
+           WHERE a.attrelid = to_regclass(l.target_table) AND a.attname = v_col;
+          EXECUTE format('UPDATE %s SET %I = $1::%s WHERE id = $2', l.target_table, v_col, v_type)
+            USING v_val, l.target_id;
+        END IF;
+      ELSE
+        EXECUTE format('DELETE FROM %s WHERE id = $1', l.target_table) USING l.target_id;
+      END IF;
+
+      -- O carimbo é o que faz a baixa auditável depois que o ledger for lido por
+      -- outra pessoa: sem ele, uma linha desativada é indistinguível de uma que o
+      -- usuário desativou à mão.
+      IF v_col IS NOT NULL AND migration._has_column(l.target_table, 'metadata') THEN
+        EXECUTE format(
+          'UPDATE %s SET metadata = coalesce(metadata, ''{}''::jsonb) || $1 WHERE id = $2',
+          l.target_table)
+          USING jsonb_build_object('migration', jsonb_build_object(
+                  'retired_at', now(), 'reason', p_reason, 'batch_id', p_batch)),
+                l.target_id;
+      END IF;
+
+      UPDATE migration.ledger
+         SET status = 'retired',
+             reason = p_reason || coalesce(' (' || v_col || ')', ' (delete)'),
+             batch_id = p_batch, updated_at = now()
+       WHERE id = l.id;
+      PERFORM migration._audit(b.tenant_id, l.target_table, l.target_id,
+        jsonb_build_object('action', 'migration.retire', 'reason', p_reason,
+                           'source_table', p_source_table, 'batch_id', p_batch));
+      v_done := v_done + 1;
+    EXCEPTION WHEN OTHERS THEN
+      -- O caso concreto: uma venda apagada no V1 cujo movimento financeiro no V2
+      -- aponta para ela com FK NO ACTION. Cascatear seria apagar o razão junto
+      -- por causa de uma exclusão na origem — o motor recusa e escreve o porquê.
+      v_first := coalesce(v_first, migration._quarantine(l.id, p_batch, 'state',
+        format('não foi possível dar baixa em %s: %s: %s', l.target_table, SQLSTATE, SQLERRM),
+        jsonb_build_object('source_table', p_source_table,
+                           'source_numeric_id', p_source_numeric_id,
+                           'source_uuid', p_source_uuid, 'reason', p_reason),
+        l.target_table));
+    END;
+  END LOOP;
+
+  IF v_n = 0 THEN
+    -- Exclusão de linha que nunca foi migrada. É o caso NORMAL — tudo que foi
+    -- criado e apagado entre duas rodadas, e toda tabela cujo domínio o V2 ainda
+    -- não tem. Silencioso de propósito: contá-lo como erro afogaria o relatório.
+    RETURN jsonb_build_object('status', 'absent', 'source_table', p_source_table);
+  END IF;
+  IF v_done = 0 AND v_first IS NOT NULL THEN
+    RETURN v_first;
+  END IF;
+  PERFORM migration._count(p_batch, 'retired');
+  RETURN jsonb_build_object('status', 'retired', 'source_table', p_source_table,
+                            'rows', v_done, 'refused', v_n - v_done);
+END $function$;

package/migrations/137_a_retirada_e_um_canal_de_venda.sql

@@ -0,0 +1,43 @@
+-- A retirada é um canal de venda.
+--
+-- O PDV do V1 lista quatro canais na trilha, e o operador escolhe entre eles a
+-- cada venda: Salão · Balcão · Retirada · Delivery. Três deles já existem em
+-- `orders.channel`; o quarto, não.
+--
+--     CHECK (channel IS NULL OR channel = ANY (ARRAY[
+--       'balcao', 'shop', 'dine_in', 'delivery', 'ticketing']))
+--
+-- Sem `retirada` a trilha do V2 pode até desenhar a linha, mas ela nunca terá
+-- conteúdo: toda tentativa de abrir uma comanda nesse canal morre no CHECK —
+-- e morre como violação de constraint, que na tela vira uma comanda que
+-- simplesmente não nasce. É o mesmo formato de falha que a chave estrangeira
+-- de `assignee_id` produziu no porte do PDV: a tela marcava a posição ocupada
+-- e o banco não tinha linha nenhuma.
+--
+-- ── Por que `retirada` e não `takeaway`/`pickup` ───────────────────────────
+--
+-- Os valores que já estão lá são o vocabulário que a casa usa em português
+-- (`balcao`, `dine_in` herdado, `delivery`), e a tela do V1 diz "Retirada".
+-- Introduzir um quinto idioma no mesmo enum faria o filtro do painel de turno
+-- casar com nada — é a armadilha do vocabulário duplo (`cash_register` ×
+-- `cash_physical`) que já custou tempo neste repositório.
+--
+-- ── O que isto NÃO faz ─────────────────────────────────────────────────────
+--
+-- Não converte nenhuma linha existente. Venda antiga não tinha como ser
+-- retirada, e adivinhar a partir de "delivery sem endereço" inventaria fato
+-- que ninguém registrou.
+--
+-- Idempotente: derruba o CHECK pelo nome e recria com a lista inteira, que é a
+-- única forma de ALTER em CHECK no Postgres. Rodar duas vezes deixa o mesmo
+-- constraint de pé.
+
+alter table public.orders
+  drop constraint if exists orders_channel_check;
+
+alter table public.orders
+  add constraint orders_channel_check
+  check (
+    channel is null
+    or channel = any (array['balcao', 'shop', 'dine_in', 'delivery', 'ticketing', 'retirada'])
+  );