@fayz-ai/db 0.11.0 → 0.13.0

package/migrations/143_a_professional_has_a_rate.sql

@@ -0,0 +1,75 @@
+-- ============================================================================
+-- 143_a_professional_has_a_rate.sql — a commission rate belongs to the hat, not
+-- to a table that no longer exists.
+--
+-- plugin-agenda's financial bridge computes a professional's commission like
+-- this:
+--
+--     .from('v_staff').select('commission_rate').eq('id', order.assignee_id)
+--
+-- and its own comment says "per-professional rate lives on staff_members,
+-- surfaced via v_staff". Neither half is true. `v_staff` is not declared by any
+-- file in this chain — it survives on two pools as a leftover and is simply
+-- absent on the other two — and where it DOES survive, its definition has no
+-- `commission_rate` column. Nor does `staff_members`. Nor does anything else in
+-- any of the four pools.
+--
+-- So the feature has been dead across the whole fleet, and quietly: PostgREST
+-- answers with an error, the bridge reads `staff?.commission_rate` off a null,
+-- `Number(undefined) || 0` gives 0, the amount is 0, and it returns null as if
+-- the professional simply had no rate configured. Nobody sees a failure; the
+-- commissions just never accrue. Found by asking each pool whether the objects
+-- the code calls are actually there (scripts/check-pool-objects.mjs) — the
+-- check that exists because reading the repo cannot answer that question.
+--
+-- WHERE IT GOES. `person_roles` is where a Person's professional hat lives, and
+-- a commission rate is an attribute OF THAT HAT, not of the human: the same
+-- person can be a professional in one unit at one rate and an employee in
+-- another. A row per (person, role, unit) is already exactly that shape.
+--
+-- A PROMOTED COLUMN, NOT metadata. The same reasoning ADR 0009 used for
+-- service_kind: money logic reasons about this value, so it gets a type, a
+-- CHECK and a name — not a JSONB key that any writer can misspell into silence.
+--
+-- NULL means "no rate configured", which is what every professional in every
+-- pool has today. Behaviour is therefore unchanged until someone sets one; what
+-- changes is that setting one now works.
+-- ============================================================================
+
+ALTER TABLE public.person_roles
+  ADD COLUMN IF NOT EXISTS commission_rate numeric(7,4);
+
+-- A rate, not an amount: 0.15 is fifteen percent. Bounded because a commission
+-- above the sale is not a configuration anyone means, and below zero is a
+-- deduction wearing the wrong name.
+ALTER TABLE public.person_roles DROP CONSTRAINT IF EXISTS person_roles_commission_rate_check;
+ALTER TABLE public.person_roles
+  ADD CONSTRAINT person_roles_commission_rate_check
+  CHECK (commission_rate IS NULL OR (commission_rate >= 0 AND commission_rate <= 1));
+
+COMMENT ON COLUMN public.person_roles.commission_rate IS
+  'Commission this person earns wearing THIS role in THIS unit, as a rate (0.15 = 15%). NULL = none configured. Promoted column, not metadata (ADR 0009): the financial bridge computes money from it.';
+
+-- The read the bridge makes, named once so it does not re-derive "who is the
+-- professional on this order" in TypeScript. One row per person: a professional
+-- hat in a specific unit wins over a tenant-wide one, because the more specific
+-- assignment is the one someone actually decided.
+CREATE OR REPLACE VIEW public.v_professional_rates
+WITH (security_invoker = true) AS
+SELECT DISTINCT ON (r.person_id)
+  r.person_id AS id,
+  r.tenant_id,
+  r.unit_id,
+  r.role,
+  p.name,
+  r.commission_rate
+FROM public.person_roles r
+JOIN public.people p ON p.id = r.person_id
+WHERE r.role IN ('professional', 'employee')
+  AND (r.valid_to IS NULL OR r.valid_to > now())
+ORDER BY r.person_id, (r.unit_id IS NULL), r.is_primary DESC, r.created_at;
+
+GRANT SELECT ON public.v_professional_rates TO authenticated;
+
+COMMENT ON VIEW public.v_professional_rates IS
+  'A professional and the commission rate of the role they wear (143). Replaces the undeclared v_staff the agenda bridge used to ask.';

package/migrations/144_a_product_can_be_sold_in_sizes.sql

@@ -0,0 +1,57 @@
+-- ============================================================================
+-- 144_a_product_can_be_sold_in_sizes.sql — a linha do pedido aprende a variante.
+--
+-- O ARQUÉTIPO JÁ EXISTE, e isso é a descoberta que este arquivo registra.
+-- `public.product_variants` foi criada pela 086 na Fase 0 — com sku, preço
+-- absoluto ou delta, `attributes` jsonb, o scaffold de authz e a regra de
+-- liberação por unidade. Está completa, está correta, e está VAZIA nas quatro
+-- pools, enquanto a loja carrega 121 variantes numa tabela paralela sua.
+--
+-- Então este arquivo não cria nada de catálogo. Ele acrescenta as duas únicas
+-- coisas que faltavam para o arquétipo ser usável por quem precisa dele:
+--
+--   §1  is_default — a variante que responde quando ninguém escolheu
+--   §2  order_items.variant_id — a linha do pedido dizendo qual foi vendida
+--
+-- A SEGUNDA É O MOTIVO DE TUDO. Sem ela, uma FK de public.order_items para
+-- public.plg_shop_product_variants faria a BASE depender de um plugin
+-- instalável, atravessando o prefixo que o ADR 0015 define como fronteira. Na
+-- direção plugin → base isso é permitido e comum; nesta, não — um cluster sem a
+-- loja instalada ficaria com uma coluna apontando para o nada.
+--
+-- E é o que destrava o estoque: enquanto o saldo não puder ser contado por
+-- variante, duas camisetas de tamanhos diferentes são o mesmo saldo, e a loja
+-- continua precisando do livro dela.
+--
+-- O backfill das 121 linhas NÃO está aqui: a spine roda antes dos plugins e
+-- plg_shop_product_variants ainda não existe neste ponto da cadeia. Ele vive em
+-- packages/shop/migrations/0075, que é o lado que pode conhecer os dois.
+-- ============================================================================
+
+-- §1 ── a variante padrão ────────────────────────────────────────────────────
+-- Produto é variante com uma só, e é esta coluna que faz a frase valer no dado
+-- em vez de só no discurso: um produto sem variação real ainda tem uma linha em
+-- product_variants, marcada aqui, e todo leitor que pergunta "qual variante?"
+-- recebe resposta sem precisar saber se aquele produto varia.
+ALTER TABLE public.product_variants
+  ADD COLUMN IF NOT EXISTS is_default boolean NOT NULL DEFAULT false;
+
+COMMENT ON COLUMN public.product_variants.is_default IS
+  'A variante que responde quando ninguém escolheu (144). Um produto sem variação real tem uma linha, e é esta.';
+
+-- Uma padrão por produto. Parcial, porque a regra é sobre as que SÃO padrão.
+CREATE UNIQUE INDEX IF NOT EXISTS product_variants_one_default_uidx
+  ON public.product_variants (tenant_id, product_id) WHERE is_default;
+
+-- §2 ── a linha do pedido aprende qual variante foi vendida ─────────────────
+-- Nullable, e NULL é o significado que toda linha de hoje já tem: o produto
+-- inteiro. Nenhum backfill é obrigatório — as 1.422 linhas do ecommerce seguem
+-- válidas sem tocar em nenhuma, e um salão nunca preenche a coluna.
+ALTER TABLE public.order_items
+  ADD COLUMN IF NOT EXISTS variant_id uuid REFERENCES public.product_variants(id) ON DELETE SET NULL;
+
+COMMENT ON COLUMN public.order_items.variant_id IS
+  'Qual variação foi vendida (144). NULL = o produto inteiro, que é o caso de todo negócio que não vende por tamanho.';
+
+CREATE INDEX IF NOT EXISTS order_items_variant_idx
+  ON public.order_items (variant_id) WHERE variant_id IS NOT NULL;

package/migrations/145_the_app_says_which_tenant_it_is_in.sql

@@ -0,0 +1,123 @@
+-- ============================================================================
+-- 145_the_app_says_which_tenant_it_is_in.sql — o arquétipo volta a ser legível
+-- por quem tem mais de uma conta.
+--
+-- O DEFEITO, encontrado em produção. O tenant Artorius Steakhouse parou de
+-- listar pedidos e clientes assim que uma tela passou a ler o arquétipo. A
+-- causa não era a tela: é que as duas camadas resolvem tenant de jeitos
+-- diferentes.
+--
+--   plg_shop_customers   tenant_id IN (SELECT user_tenant_ids())
+--   people               tenant_id = app.current_tenant_id() AND …
+--
+-- A do plugin é por FILIAÇÃO: qualquer membro logado passa, e a consulta se
+-- estreita sozinha com o `.eq('tenant_id', …)` que o app já manda. A do
+-- arquétipo é por CONTEXTO, e `app.current_tenant_id()` só sabe responder de
+-- duas formas: a claim `tenant_id` do JWT, ou — se não houver claim — o único
+-- tenant do usuário. Se ele tem dois, ela devolve NULL, e NULL nega tudo.
+--
+-- NENHUM APP DA FROTA EMITE ESSA CLAIM. O token é um token comum do Supabase.
+-- Então o arquétipo inteiro só era legível para quem pertence a exatamente uma
+-- conta — e isso funcionou por acidente: no salão, 11 de 12 usuários têm uma
+-- conta só. No ecommerce, três donos têm quatro e cinco, e para esses três
+-- `public.people`, `public.orders` e `public.products` sempre responderam vazio.
+-- O defeito é anterior a qualquer tela nova; ela só o tornou visível.
+--
+-- A SAÍDA JÁ EXISTE NESTE REPOSITÓRIO. `x-fayz-unit` viaja em toda requisição
+-- desde 039 e `public.requested_unit()` a lê, sob uma regra que o cliente
+-- enuncia melhor do que eu conseguiria:
+--
+--     "a header cannot be trusted to narrow, and it must never be able to
+--      widen: the policies resolve unit access through user_unit_ids(), never
+--      through what was sent here"
+--
+-- `x-fayz-tenant` entra pela mesma porta e sob a mesma regra. O cabeçalho não
+-- concede nada: ele ESCOLHE entre as contas que o usuário já tem, e a escolha é
+-- validada contra app.memberships exatamente como a claim do JWT já era. Um
+-- cabeçalho forjado só alcança o que `user_tenant_ids()` — a política que as
+-- tabelas de plugin usam hoje — já alcançava. Ele estreita; nunca alarga.
+--
+-- A ORDEM IMPORTA e é a de confiança: claim do JWT primeiro (é assinada), depois
+-- o cabeçalho, depois o recuo de conta única. Quem já emite a claim não muda de
+-- comportamento.
+-- ============================================================================
+
+CREATE OR REPLACE FUNCTION app.requested_tenant()
+RETURNS uuid
+LANGUAGE plpgsql STABLE
+SET search_path = ''
+AS $$
+DECLARE v text;
+BEGIN
+  v := nullif(current_setting('request.headers', true), '')::json ->> 'x-fayz-tenant';
+  RETURN nullif(v, '')::uuid;
+-- Engole a falha de parse pela mesma razão que requested_unit(): uma função
+-- vizinha da RLS não é lugar de levantar exceção.
+EXCEPTION WHEN OTHERS THEN
+  RETURN NULL;
+END $$;
+
+REVOKE ALL ON FUNCTION app.requested_tenant() FROM public;
+GRANT EXECUTE ON FUNCTION app.requested_tenant() TO authenticated, service_role;
+
+CREATE OR REPLACE FUNCTION app.current_tenant_id()
+RETURNS uuid
+LANGUAGE plpgsql STABLE SECURITY DEFINER
+SET search_path = ''
+AS $$
+DECLARE
+  v_uid    uuid := auth.uid();
+  v_jwt    jsonb := coalesce(auth.jwt(), '{}'::jsonb);
+  v_raw    text;
+  v_tenant uuid;
+  v_n      integer;
+BEGIN
+  -- ① a claim assinada, se existir. Inalterado desde 051.
+  IF jsonb_exists(v_jwt, 'tenant_id') THEN
+    v_raw := v_jwt ->> 'tenant_id';
+    -- Presença expressa intenção de estreitar; valor ilegível é nenhum tenant.
+    IF v_raw IS NULL OR v_raw !~* '^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$' THEN
+      RETURN NULL;
+    END IF;
+    v_tenant := v_raw::uuid;
+    IF v_uid IS NULL THEN
+      RETURN v_tenant;
+    END IF;
+    IF EXISTS (SELECT 1 FROM app.memberships m
+                WHERE m.tenant_id = v_tenant AND m.user_id = v_uid AND m.active) THEN
+      RETURN v_tenant;
+    END IF;
+    RETURN NULL;
+  END IF;
+
+  IF v_uid IS NULL THEN
+    RETURN NULL;
+  END IF;
+
+  -- ② o cabeçalho da requisição. A MESMA validação de filiação de ①: ele
+  -- escolhe entre as contas do usuário, não concede nenhuma. Sem sessão não há
+  -- o que validar, então este braço exige v_uid — que já está garantido acima.
+  v_tenant := app.requested_tenant();
+  IF v_tenant IS NOT NULL THEN
+    IF EXISTS (SELECT 1 FROM app.memberships m
+                WHERE m.tenant_id = v_tenant AND m.user_id = v_uid AND m.active) THEN
+      RETURN v_tenant;
+    END IF;
+    -- Cabeçalho apontando para conta que não é sua: nega, não recua. Recuar
+    -- para "sua única conta" transformaria um pedido explícito e errado numa
+    -- resposta silenciosa sobre outra conta.
+    RETURN NULL;
+  END IF;
+
+  -- ③ o recuo: conta única. Quem tem duas e não disse qual continua sem tenant,
+  -- que é a resposta correta — só que agora ela é evitável.
+  SELECT count(*), (array_agg(m.tenant_id))[1] INTO v_n, v_tenant
+    FROM app.memberships m WHERE m.user_id = v_uid AND m.active;
+  IF v_n = 1 THEN
+    RETURN v_tenant;
+  END IF;
+  RETURN NULL;
+END $$;
+
+COMMENT ON FUNCTION app.current_tenant_id() IS
+  'Em qual conta esta requisição está agindo: claim assinada do JWT, senão o cabeçalho x-fayz-tenant, senão a única conta do usuário (145). Os três caminhos validam filiação — nenhum concede acesso, todos escolhem entre o que já é do usuário.';

package/migrations/146_products_stock_has_one_writer.sql

@@ -0,0 +1,67 @@
+-- ============================================================================
+-- 146_products_stock_has_one_writer.sql — quem manda no estoque do produto.
+--
+-- O último item da Fase 0 com forma de loja. A #143 registrou assim:
+-- "products.stock has two independent writers (inventory positions vs shop
+-- inventory_count) with no arbitration". Dois gatilhos escrevem a mesma coluna:
+--
+--   plugin-inventory 014   UPDATE products SET stock = Σ posições
+--   shop        0009       UPDATE products SET stock = NEW.inventory_count
+--
+-- Sem árbitro, quem dispara por último ganha. E não é hipótese: medido em
+-- 25/08, restaurant tem 20 unidades de diferença entre os dois números e salon
+-- tem 29. No ecommerce, products.stock vale 1.200.449 (o número da loja) contra
+-- 12 em posições — se o espelho do inventory disparasse para aqueles produtos,
+-- o estoque da loja colapsaria de um milhão para uma dúzia.
+--
+-- POR QUE UM REGISTRO E NÃO UMA REGRA INFERIDA. A tentação é decidir na hora:
+-- "o inventory ganha se tiver movimento". Só o Artorius Steakhouse tem os dois
+-- livros — 2 movimentos do inventory contra 24 da loja — e essa regra o
+-- entregaria ao inventory, colapsando exatamente o estoque que o lojista vê.
+-- Uma coluna que muda de dono conforme o dado do dia não tem dono.
+--
+-- O PADRÃO É O CONTRATO DECLARADO. O 012 do inventory já diz que products.stock
+-- "become one-way MIRRORS maintained by 007", então a ausência de registro
+-- significa inventory. A loja registra a EXCEÇÃO onde ela é, de fato, quem
+-- mantém o número — e registra por linha, não por DDL, que é a mesma forma que
+-- 080 usou para as espécies de venda.
+--
+-- Este arquivo não conhece nenhum plugin: declara a mesa e a pergunta. Quem
+-- responde "sou eu" é cada plugin, no arquivo dele.
+-- ============================================================================
+
+CREATE TABLE IF NOT EXISTS app.product_stock_source (
+  tenant_id  uuid PRIMARY KEY REFERENCES public.tenants(id) ON DELETE CASCADE,
+  source     text NOT NULL CHECK (source IN ('inventory', 'shop')),
+  note       text,
+  created_at timestamptz NOT NULL DEFAULT now(),
+  updated_at timestamptz NOT NULL DEFAULT now()
+);
+
+COMMENT ON TABLE app.product_stock_source IS
+  'Quem mantém public.products.stock nesta conta (146). Linha ausente = inventory, que é o contrato declarado pelo 012. Um registro e não uma inferência: uma coluna que muda de dono conforme o dado do dia não tem dono.';
+
+ALTER TABLE app.product_stock_source ENABLE ROW LEVEL SECURITY;
+DROP POLICY IF EXISTS product_stock_source_read ON app.product_stock_source;
+CREATE POLICY product_stock_source_read ON app.product_stock_source
+  FOR SELECT TO authenticated USING (true);
+GRANT SELECT ON app.product_stock_source TO authenticated;
+
+CREATE OR REPLACE FUNCTION app.product_stock_owner(p_tenant uuid)
+RETURNS text
+LANGUAGE sql STABLE SECURITY DEFINER
+SET search_path = ''
+AS $$
+  SELECT coalesce(
+    (SELECT s.source FROM app.product_stock_source s WHERE s.tenant_id = p_tenant),
+    'inventory')
+$$;
+
+COMMENT ON FUNCTION app.product_stock_owner(uuid) IS
+  'Qual livro mantém products.stock nesta conta: inventory (padrão, contrato do 012) ou shop. Todo escritor daquela coluna pergunta antes de escrever — é o que a #143 chamava de arbitragem ausente.';
+
+REVOKE ALL ON FUNCTION app.product_stock_owner(uuid) FROM public;
+GRANT EXECUTE ON FUNCTION app.product_stock_owner(uuid) TO authenticated, service_role;
+
+COMMENT ON COLUMN public.products.stock IS
+  'deprecated como fonte: o saldo real vive no livro de estoque. Mantido como espelho de UM escritor só, escolhido por app.product_stock_owner(tenant) (146). Nunca escrever sem perguntar — dois escritores nesta coluna foi a #143.';