@fayz-ai/db 0.10.0 → 0.12.0

package/migrations/042_unit_scope_policies.sql

@@ -0,0 +1,145 @@
+-- ============================================================================
+-- 042_unit_scope_policies.sql — the only file here that changes an answer.
+--
+-- WHY A RESTRICTIVE POLICY AND NOT A REWRITE. The obvious move is to extend the
+-- canonical predicate — `tenant_id IN (SELECT public.user_tenant_ids()) AND …`
+-- — on every table. That would mean re-emitting ~321 policy definitions across
+-- 148 tables in db, shop, courses and eight plugin trees, and the migrations
+-- that created them CANNOT be edited: a checksum change on an applied file is a
+-- MigrationDriftError, a hard stop in cli/src/lib/ledger.ts.
+--
+-- Postgres already has the operator for this. Restrictive policies are ANDed
+-- with the OR of every permissive policy on the table. So one policy per table,
+-- added here, composes with everything that already exists — no plugin SQL
+-- changes, no CI-gate contortion, and `DROP POLICY unit_scope ON …` reverts the
+-- entire feature.
+--
+-- It also closes a hole a rewrite would have left open. `storefront_public_read`
+-- on plg_shop_products is `TO anon, authenticated`; because RLS ORs permissive
+-- policies, a signed-in staff member reads the whole catalogue through that
+-- door — which is exactly the "Botox in 2 of 15 units" case, defeated. A
+-- restrictive policy ANDs on top and shuts it.
+--
+-- WHY THE PREDICATE IS LITERAL TEXT AND NOT A FUNCTION. A helper taking the
+-- row's own columns — record_visible(id, unit_id, owner_id) — is CORRELATED.
+-- RLS predicates are injected into RangeTblEntry.securityQuals, which
+-- pull_up_sublinks never sees, so a sublink there is never turned into a
+-- semijoin; a correlated one becomes a SubPlan re-executed once PER ROW. Worse,
+-- such a helper must be SECURITY DEFINER with SET search_path, and either of
+-- those alone makes it non-inlinable. Every disjunct below is UNCORRELATED: one
+-- InitPlan per query, hashed, then a cheap probe per row.
+--
+-- WHAT IT COSTS A TENANT THAT DOES NOT USE UNITS. The first disjunct is a
+-- zero-argument STABLE function wrapped in `(SELECT …)`, so it is one InitPlan
+-- per query. On a pool where nobody has flipped the switch it returns false,
+-- `NOT false` is true, and OR does not evaluate its remaining arms — one
+-- boolean test per row, no hash built, plan shape unchanged.
+--
+-- Idempotent: every policy is dropped by name before being created.
+-- ============================================================================
+
+DO $$
+DECLARE
+  r record;
+  v_read text;
+  v_write text;
+BEGIN
+  FOR r IN SELECT resource_table, unit_column FROM public.scoped_resources ORDER BY resource_table LOOP
+    CONTINUE WHEN to_regclass('public.' || r.resource_table) IS NULL;
+
+    -- %1$s is the table name as a STRING LITERAL for the helper arguments, and
+    -- %2$I / %3$I are the identifiers. Baking the name in as a constant is what
+    -- keeps granted_record_ids() uncorrelated.
+    v_read := format($p$
+         NOT (SELECT public.unit_scoping_active())
+      OR tenant_id NOT IN (SELECT public.unit_scoped_tenants())
+      OR tenant_id NOT IN (SELECT public.user_tenant_ids())
+      OR tenant_id IN (SELECT public.user_admin_tenant_ids())
+      OR %3$I = (SELECT auth.uid())
+      OR id IN (SELECT public.granted_record_ids(%1$L))
+      OR (
+           tenant_id IN (SELECT public.resource_mode_tenants(%1$L, 'tenant'))
+           AND id NOT IN (SELECT public.restricted_record_ids(%1$L))
+         )
+      OR (
+           (
+                tenant_id IN (SELECT public.resource_mode_tenants(%1$L, 'unit'))
+             OR (%3$I IS NULL AND tenant_id IN (SELECT public.resource_mode_tenants(%1$L, 'owner')))
+           )
+           AND (
+                %2$I IN (SELECT public.user_unit_ids())
+             OR (%2$I IS NULL AND id NOT IN (SELECT public.restricted_record_ids(%1$L)))
+           )
+         )
+    $p$, r.resource_table, r.unit_column, 'owner_id');
+
+    v_write := format($p$
+         NOT (SELECT public.unit_scoping_active())
+      OR tenant_id NOT IN (SELECT public.unit_scoped_tenants())
+      OR tenant_id NOT IN (SELECT public.user_tenant_ids())
+      OR tenant_id IN (SELECT public.user_admin_tenant_ids())
+      OR (
+           (%2$I IS NULL OR %2$I IN (SELECT public.user_unit_ids()))
+           AND (%3$I IS NULL OR %3$I = (SELECT auth.uid()))
+         )
+    $p$, r.resource_table, r.unit_column, 'owner_id');
+
+    EXECUTE format('ALTER TABLE public.%I ENABLE ROW LEVEL SECURITY', r.resource_table);
+    EXECUTE format('DROP POLICY IF EXISTS unit_scope ON public.%I', r.resource_table);
+    -- `AS RESTRICTIVE` sits on its own concatenated line because it is the
+    -- single word this whole file depends on: without it the policy becomes
+    -- permissive, ORs with everything else on the table and grants MORE access
+    -- than there was before. negative-control.sh deletes exactly this line and
+    -- demands the bench go red — see the case list there.
+    EXECUTE format(
+      'CREATE POLICY unit_scope ON public.%I '
+      || ' AS RESTRICTIVE '
+      || ' FOR ALL TO authenticated USING (%s) WITH CHECK (%s)',
+      r.resource_table, v_read, v_write);
+  END LOOP;
+END $$;
+
+-- ── What the predicate says, in words ───────────────────────────────────────
+--
+-- READ. A row is visible when ANY of these holds, checked left to right:
+--
+--   1. no tenant in this pool uses units                    → the whole feature is off
+--   2. this row's tenant does not use units                 → that tenant is unchanged
+--   3. the row is not mine to begin with                    → a shopper browsing a
+--                                                             storefront is governed by
+--                                                             whatever let them in, not
+--                                                             by this
+--   4. I am owner/admin of the tenant                       → the franchisor sees the brand
+--   5. I own the row
+--   6. the row was explicitly shared with me, my team or a unit I reach
+--   7. this record type is org-wide for this tenant, AND nobody has named the
+--      units it belongs to                                  → the ordinary case
+--   8. this record type is unit-scoped (or is owner-scoped and has no owner at
+--      all), AND the row's unit is one I reach, or it has no unit and nobody
+--      named units for it
+--
+-- Rule 7's second half and rule 8's are the same idea, and it is what makes
+-- "Botox in 2 of 15" work with no extra table: a record with NO unit grant
+-- belongs to the whole brand; the moment somebody grants it to two units, the
+-- org-wide pass stops applying and only those two units (rule 6) see it.
+--
+-- An ownerless row can never be private (rule 8's parenthesis). Records that
+-- predate 025 have no author and therefore no owner, and a tenant switching a
+-- record type to "only the owner" must not make its whole history vanish.
+--
+-- WRITE. You may stamp a row with no unit, or with a unit you actually reach,
+-- and you may not hand a record to somebody else. Reassigning a record AWAY
+-- from yourself is allowed — that is a legitimate handoff, and losing your own
+-- access is the correct consequence. Claiming someone else's is blocked by the
+-- USING clause, which the pre-image must satisfy before WITH CHECK ever runs.
+--
+-- Writing a row with NO unit is deliberately permitted: product decision — a
+-- NULL unit is a legitimate, permanent state ("belongs to the whole
+-- organization"), and forbidding it would break every insert path the day a
+-- tenant flips the switch.
+--
+-- WHERE THIS GUARANTEE STOPS. `service_role` has BYPASSRLS, so every edge
+-- function reads across units by construction; any edge function returning rows
+-- to a person must filter for itself. The sharpest edge is public.agent_guard
+-- (015), which has no unit dimension yet — an agent RPC acting for a
+-- unit-restricted user is not restricted. That is tracked, not solved here.

package/migrations/043_view_invoker.sql

@@ -0,0 +1,81 @@
+-- ============================================================================
+-- 043_view_invoker.sql — the views that were never anybody's tenant.
+--
+-- THIS IS NOT PART OF UNIT SCOPING. It is a cross-tenant hole that predates it,
+-- found while auditing what 042's predicate would and would not reach, and it
+-- has to close first or "the guarantee is the API's" is false on the day it
+-- ships.
+--
+-- A Postgres view runs with the privileges of its OWNER unless it is created
+-- `WITH (security_invoker = true)`. Migrations here are applied as `postgres`,
+-- who owns the tables, and a table owner is exempt from that table's RLS unless
+-- the table is set FORCE ROW LEVEL SECURITY — which nothing in this tree does.
+-- Meanwhile 001_core and 008_grants hand `authenticated` a blanket SELECT.
+--
+-- Put together, on a shared industry pool — one Supabase project carrying
+-- several clinics — any signed-in user of ANY tenant could
+--
+--     SELECT * FROM public.v_documents;
+--
+-- and read every tenant's patient documents. Same for invoice balances and the
+-- agenda's five report views. Twenty-one views in the tree already carry
+-- `security_invoker`; these did not, and nothing distinguishes them except who
+-- wrote them.
+--
+-- WHY A CORE SWEEP AND NOT A FIX IN EACH PLUGIN. Fixing it where it lives means
+-- a new migration in plugin-forms, plugin-financial, plugin-agenda and courses,
+-- each of which only reaches a pool when that plugin is next applied. The hole
+-- is open now, on live pools, and one file that closes it everywhere is worth
+-- the ownership smudge. The plugins should still carry the fix forward in their
+-- own next migration; this file is idempotent and will simply agree with them.
+--
+-- WHAT IS DELIBERATELY LEFT ALONE — the three anon-facing views:
+--
+--     public.plg_shop_catalog       the storefront's product list
+--     public.v_public_services      public booking
+--     public.v_public_blog_posts    the public blog
+--
+-- Those are MEANT to answer without a session, and flipping them to invoker
+-- makes them resolve as `anon`, which returns rows only if every table they
+-- touch carries an anon policy. Some do (shop 0020's storefront_public_read),
+-- some are unverified. Turning a storefront dark is not an acceptable way to
+-- fix a leak in a report screen, so they are handled separately, against a live
+-- pool, with the storefront actually open in a browser.
+--
+-- ALTER VIEW ... SET is additive and idempotent. Every statement is guarded, so
+-- a pool without a given plugin simply skips it.
+-- ============================================================================
+
+DO $$
+DECLARE
+  v text;
+  -- Named one by one rather than swept, so this file can never silently reach a
+  -- view somebody adds later for anon.
+  leaky text[] := ARRAY[
+    -- plugin-forms: the patient record, and the one that joins it to people
+    'v_documents',
+    'v_frm_documents',
+    -- plugin-financial: what is still owed, per invoice
+    'v_invoice_balances',
+    -- plugin-agenda: the five report read-models
+    'rep_appointments_by_period',
+    'rep_confirmation_queue',
+    'rep_new_clients',
+    'rep_revenue_by_professional',
+    'rep_revenue_by_service',
+    -- courses
+    'plg_courses_rep_revenue'
+  ];
+BEGIN
+  FOREACH v IN ARRAY leaky LOOP
+    -- to_regclass and not information_schema: a pool has whichever plugins it
+    -- has, and the ledger is not a reliable account of that.
+    CONTINUE WHEN to_regclass('public.' || v) IS NULL;
+    EXECUTE format('ALTER VIEW public.%I SET (security_invoker = true)', v);
+  END LOOP;
+END $$;
+
+-- What changes on screen: a report that was quietly summing other tenants' rows
+-- now sums only its own. That is a smaller number and it is the correct one —
+-- but it IS a visible change, which is why this lives in its own file and can
+-- be rolled back on its own.

package/migrations/044_unit_member_facts.sql

@@ -0,0 +1,47 @@
+-- ============================================================================
+-- 044_unit_member_facts.sql — the two facts a unit roster is asked for.
+--
+-- "Quem trabalha aqui" is never only a list of names. The two questions that
+-- follow it are always the same: since when, and are they actually using it.
+--
+--   since when   → location_members.created_at, which 001 never gave it.
+--   last access  → auth.users.last_sign_in_at, which no client role can read,
+--                  and should not be able to: that table also holds password
+--                  hashes and recovery tokens.
+--
+-- So the second one comes through a function that returns ONLY the two harmless
+-- columns, only for members of a tenant the caller administers. An admin can
+-- already see every member's name and e-mail on the team screen; when they last
+-- signed in is strictly less than that, and it is the difference between "we
+-- gave Ana access" and "Ana has been using it".
+--
+-- Additive and idempotent.
+-- ============================================================================
+
+ALTER TABLE public.location_members
+  ADD COLUMN IF NOT EXISTS created_at timestamptz NOT NULL DEFAULT now();
+
+COMMENT ON COLUMN public.location_members.created_at IS
+  'When this person was given access to this unit.';
+
+-- Rows that predate the column all default to now(), which would claim everyone
+-- was bound today. Left as-is deliberately: a wrong date is worse than a vague
+-- one, and the screen shows nothing older than the column itself is.
+
+CREATE OR REPLACE FUNCTION public.tenant_member_activity(p_tenant_id uuid)
+RETURNS TABLE (user_id uuid, last_sign_in_at timestamptz, signed_up_at timestamptz)
+LANGUAGE sql STABLE SECURITY DEFINER
+SET search_path = public, pg_temp
+AS $$
+  SELECT u.id, u.last_sign_in_at, u.created_at
+    FROM auth.users u
+    JOIN public.tenant_members tm ON tm.user_id = u.id
+   WHERE tm.tenant_id = p_tenant_id
+     -- The gate, and the only one: an admin of THIS tenant, and nobody else.
+     -- Without it the function is a directory of every last_sign_in_at in the
+     -- pool, reachable by anyone with an anon key.
+     AND p_tenant_id IN (SELECT public.user_admin_tenant_ids());
+$$;
+
+REVOKE ALL ON FUNCTION public.tenant_member_activity(uuid) FROM public, anon;
+GRANT EXECUTE ON FUNCTION public.tenant_member_activity(uuid) TO authenticated, service_role;

package/migrations/045_unit_entry.sql

@@ -0,0 +1,236 @@
+-- ============================================================================
+-- 045_unit_entry.sql — entrar no sistema já na unidade certa.
+--
+-- A fronteira de unidade existe desde a 039. O que faltava era a pergunta que
+-- todo funcionário de rede responde toda manhã: "em qual loja eu estou?".
+--
+-- Responder isso com um seletor vazio é empurrar trabalho para quem só queria
+-- abrir a agenda. Três fatos resolvem quase todos os casos, e nenhum deles
+-- precisa de permissão do navegador:
+--
+--   1. o que ESTA MÁQUINA abriu por último  → a recepcionista do balcão da
+--      Ipanema usa sempre o mesmo computador, e ele fica na Ipanema;
+--   2. o que ESTA PESSOA abriu por último em qualquer lugar → ela trocou de
+--      máquina, mas não de hábito;
+--   3. só existe uma unidade ao alcance dela → não há escolha a fazer.
+--
+-- Só o que sobra depois disso justifica pedir a localização do navegador, e por
+-- isso as coordenadas aqui são OPCIONAIS e a tela só oferece o botão quando
+-- elas existem. Ninguém leva um pedido de permissão de GPS por ter feito login.
+--
+-- NADA AQUI CONCEDE ACESSO. O pino é preferência, não autorização: a unidade
+-- ativa só ESTREITA o que o RLS já deixou passar (ver 042). Um pino apontando
+-- para uma unidade que a pessoa não alcança não vaza nada — é ignorado na
+-- leitura e recusado na escrita, e as duas coisas estão abaixo.
+--
+-- Aditiva e idempotente.
+-- ============================================================================
+
+-- ── Coordenadas da unidade (opcionais) ──────────────────────────────────────
+-- Sem serviço de geocodificação: quem cadastra a unidade informa, ou não
+-- informa. Nulo é o estado normal, e "achar a mais perto" simplesmente não é
+-- oferecido para uma rede que nunca preencheu isso.
+ALTER TABLE public.locations
+  ADD COLUMN IF NOT EXISTS latitude  numeric(9,6),
+  ADD COLUMN IF NOT EXISTS longitude numeric(9,6);
+
+DO $$
+BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'locations_coords_range'
+  ) THEN
+    ALTER TABLE public.locations
+      ADD CONSTRAINT locations_coords_range CHECK (
+        (latitude IS NULL OR (latitude BETWEEN -90 AND 90)) AND
+        (longitude IS NULL OR (longitude BETWEEN -180 AND 180))
+      ) NOT VALID;
+  END IF;
+END $$;
+
+COMMENT ON COLUMN public.locations.latitude IS
+  'Opcional. Só serve para oferecer "a unidade mais perto de mim" na entrada.';
+
+-- ── O pino, por pessoa, por conta, por máquina ──────────────────────────────
+-- A chave inclui o dispositivo porque a máquina é um proxy melhor de "onde eu
+-- estou fisicamente" do que a conta: o mesmo gerente abre o Leblon no celular
+-- de casa à noite e a Ipanema no balcão de manhã, e nenhuma das duas escolhas
+-- deveria estragar a outra.
+--
+-- Não existe linha "da conta": a preferência da conta é a linha mais recente
+-- entre os dispositivos. Um estado derivado não pode divergir do outro.
+CREATE TABLE IF NOT EXISTS public.user_unit_prefs (
+  user_id    uuid NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
+  tenant_id  uuid NOT NULL REFERENCES public.tenants(id) ON DELETE CASCADE,
+  -- Opaco e sorteado no navegador, nunca uma impressão digital do aparelho:
+  -- ele só precisa distinguir "este computador" de "aquele", e um identificador
+  -- que não descreve nada não pode ser usado para mais nada.
+  device_id  text NOT NULL,
+  -- Nulo = a pessoa escolheu "todas as unidades" explicitamente, que é uma
+  -- escolha e não uma ausência de escolha.
+  unit_id    uuid REFERENCES public.locations(id) ON DELETE CASCADE,
+  updated_at timestamptz NOT NULL DEFAULT now(),
+  PRIMARY KEY (user_id, tenant_id, device_id)
+);
+
+CREATE INDEX IF NOT EXISTS user_unit_prefs_recent_idx
+  ON public.user_unit_prefs (user_id, tenant_id, updated_at DESC);
+
+COMMENT ON TABLE public.user_unit_prefs IS
+  'Onde cada pessoa estava por último, por máquina. Preferência de entrada — nunca autorização.';
+
+ALTER TABLE public.user_unit_prefs ENABLE ROW LEVEL SECURITY;
+
+-- Permissivas: eu leio e escrevo o meu pino, e só o meu.
+DROP POLICY IF EXISTS "user_unit_prefs_own" ON public.user_unit_prefs;
+CREATE POLICY "user_unit_prefs_own" ON public.user_unit_prefs
+  FOR ALL TO authenticated
+  USING (user_id = (SELECT auth.uid()))
+  WITH CHECK (user_id = (SELECT auth.uid()));
+
+-- Restritivas, pelo mesmo motivo da 040: esta tabela tem `tenant_id` e não está
+-- na lista de tabelas do núcleo, então a varredura da 002 a redescobre a cada
+-- reaplicação e acrescenta uma policy PERMISSIVA por conta inteira. Permissivas
+-- se somam com OU — sem o par restritivo abaixo, um colega da mesma conta
+-- passaria a ler (e a escrever) em que unidade eu estava.
+DROP POLICY IF EXISTS "user_unit_prefs_select_guard" ON public.user_unit_prefs;
+CREATE POLICY "user_unit_prefs_select_guard" ON public.user_unit_prefs
+  AS RESTRICTIVE FOR SELECT TO authenticated
+  USING (user_id = (SELECT auth.uid()));
+
+DROP POLICY IF EXISTS "user_unit_prefs_insert_guard" ON public.user_unit_prefs;
+CREATE POLICY "user_unit_prefs_insert_guard" ON public.user_unit_prefs
+  AS RESTRICTIVE FOR INSERT TO authenticated
+  WITH CHECK (user_id = (SELECT auth.uid()));
+
+DROP POLICY IF EXISTS "user_unit_prefs_update_guard" ON public.user_unit_prefs;
+CREATE POLICY "user_unit_prefs_update_guard" ON public.user_unit_prefs
+  AS RESTRICTIVE FOR UPDATE TO authenticated
+  USING (user_id = (SELECT auth.uid()))
+  WITH CHECK (user_id = (SELECT auth.uid()));
+
+DROP POLICY IF EXISTS "user_unit_prefs_delete_guard" ON public.user_unit_prefs;
+CREATE POLICY "user_unit_prefs_delete_guard" ON public.user_unit_prefs
+  AS RESTRICTIVE FOR DELETE TO authenticated
+  USING (user_id = (SELECT auth.uid()));
+
+GRANT SELECT, INSERT, UPDATE, DELETE ON public.user_unit_prefs TO authenticated;
+GRANT ALL ON public.user_unit_prefs TO service_role;
+
+-- Um navegador novo a cada limpeza de cookies gera um device_id novo, e sem
+-- teto a tabela acumularia uma linha por sessão para sempre. Cinco é mais do
+-- que qualquer pessoa usa e menos do que qualquer coisa que incomode.
+CREATE OR REPLACE FUNCTION public.trim_user_unit_prefs()
+RETURNS trigger LANGUAGE plpgsql SECURITY DEFINER
+SET search_path = public, pg_temp AS $$
+BEGIN
+  DELETE FROM public.user_unit_prefs p
+   WHERE p.user_id = NEW.user_id
+     AND p.tenant_id = NEW.tenant_id
+     AND p.device_id NOT IN (
+       SELECT device_id FROM public.user_unit_prefs
+        WHERE user_id = NEW.user_id AND tenant_id = NEW.tenant_id
+        ORDER BY updated_at DESC
+        LIMIT 5
+     );
+  RETURN NULL;
+END $$;
+
+DROP TRIGGER IF EXISTS user_unit_prefs_trim ON public.user_unit_prefs;
+CREATE TRIGGER user_unit_prefs_trim
+  AFTER INSERT OR UPDATE ON public.user_unit_prefs
+  FOR EACH ROW EXECUTE FUNCTION public.trim_user_unit_prefs();
+
+-- ── Gravar o pino ───────────────────────────────────────────────────────────
+-- Por função e não por upsert direto para poder recusar um pino impossível. Um
+-- pino inválido não vazaria nada (ele só estreita), mas uma tabela de
+-- preferências que guarda unidades inalcançáveis mente para quem a lê depois.
+CREATE OR REPLACE FUNCTION public.set_entry_unit(
+  p_tenant_id uuid,
+  p_unit_id   uuid,
+  p_device_id text
+)
+RETURNS void LANGUAGE plpgsql SECURITY INVOKER
+SET search_path = public, pg_temp AS $$
+BEGIN
+  IF p_device_id IS NULL OR length(trim(p_device_id)) = 0 THEN
+    RAISE EXCEPTION 'device_id obrigatório';
+  END IF;
+
+  -- "Todas as unidades" (nulo) é sempre válido. Uma unidade só é aceita se a
+  -- pessoa a alcança de verdade — a mesma função que o RLS usa, não uma cópia.
+  IF p_unit_id IS NOT NULL AND p_unit_id NOT IN (SELECT public.user_unit_ids()) THEN
+    RAISE EXCEPTION 'unidade fora do alcance';
+  END IF;
+
+  INSERT INTO public.user_unit_prefs (user_id, tenant_id, device_id, unit_id, updated_at)
+  VALUES ((SELECT auth.uid()), p_tenant_id, p_device_id, p_unit_id, now())
+  ON CONFLICT (user_id, tenant_id, device_id)
+  DO UPDATE SET unit_id = EXCLUDED.unit_id, updated_at = now();
+END $$;
+
+GRANT EXECUTE ON FUNCTION public.set_entry_unit(uuid, uuid, text) TO authenticated;
+
+-- ── Tudo que a entrada precisa, numa viagem ─────────────────────────────────
+-- A tela pagava cinco idas ao servidor antes de saber em que unidade estava:
+-- chave da conta, árvore, vínculos, registro de tabelas escopadas e pinos. Em
+-- rede móvel isso é o intervalo inteiro entre o login e a primeira lista — e
+-- durante ele a lista já pintou, sem unidade, mostrando linhas que o seletor
+-- diz não estar mostrando.
+--
+-- SECURITY INVOKER de propósito: tudo aqui dentro passa pelo RLS de quem
+-- chamou. Esta função junta viagens, não privilégios.
+CREATE OR REPLACE FUNCTION public.unit_bootstrap(
+  p_tenant_id uuid,
+  p_device_id text DEFAULT NULL
+)
+RETURNS jsonb LANGUAGE sql STABLE SECURITY INVOKER
+SET search_path = public, pg_temp AS $$
+  SELECT jsonb_build_object(
+    'mode', COALESCE((
+      SELECT t.unit_scoping_enabled FROM public.tenants t WHERE t.id = p_tenant_id
+    ), false),
+    'units', COALESCE((
+      SELECT jsonb_agg(to_jsonb(l) ORDER BY l.is_headquarters DESC NULLS LAST, l.name)
+        FROM public.locations l WHERE l.tenant_id = p_tenant_id
+    ), '[]'::jsonb),
+    'bindings', COALESCE((
+      SELECT jsonb_agg(jsonb_build_object('location_id', lm.location_id, 'role', lm.role))
+        FROM public.location_members lm WHERE lm.user_id = (SELECT auth.uid())
+    ), '[]'::jsonb),
+    'scoped', COALESCE((
+      SELECT jsonb_object_agg(sr.resource_table, jsonb_build_object(
+               'unit_column', sr.unit_column, 'shareable', sr.shareable))
+        FROM public.scoped_resources sr
+    ), '{}'::jsonb),
+    -- O pino desta máquina ganha do pino da conta quando os dois existem: a
+    -- máquina fica na loja, a conta viaja com a pessoa.
+    'device_pin', (
+      SELECT p.unit_id FROM public.user_unit_prefs p
+       WHERE p.user_id = (SELECT auth.uid())
+         AND p.tenant_id = p_tenant_id
+         AND p.device_id = p_device_id
+    ),
+    'device_pin_set', EXISTS (
+      SELECT 1 FROM public.user_unit_prefs p
+       WHERE p.user_id = (SELECT auth.uid())
+         AND p.tenant_id = p_tenant_id
+         AND p.device_id = p_device_id
+    ),
+    'account_pin', (
+      SELECT p.unit_id FROM public.user_unit_prefs p
+       WHERE p.user_id = (SELECT auth.uid())
+         AND p.tenant_id = p_tenant_id
+       ORDER BY p.updated_at DESC
+       LIMIT 1
+    ),
+    'account_pin_set', EXISTS (
+      SELECT 1 FROM public.user_unit_prefs p
+       WHERE p.user_id = (SELECT auth.uid()) AND p.tenant_id = p_tenant_id
+    )
+  );
+$$;
+
+GRANT EXECUTE ON FUNCTION public.unit_bootstrap(uuid, text) TO authenticated;
+
+COMMENT ON FUNCTION public.unit_bootstrap(uuid, text) IS
+  'Uma viagem para tudo que a entrada precisa. Invoker: agrupa requisições, não privilégios.';

package/migrations/046_membership_visible_to_members.sql

@@ -0,0 +1,85 @@
+-- ============================================================================
+-- 046_membership_visible_to_members.sql — a tela de equipe consegue ler a
+-- própria equipe.
+--
+-- `members_select` da 001 é `user_id = auth.uid()`: cada pessoa enxerga **só a
+-- própria linha** de `tenant_members`. A consequência não é sutil.
+--
+-- A tela de Equipe monta a lista a partir de `people` e usa `tenant_members`
+-- como camada de acesso por cima. Com a policy de hoje essa camada tem uma
+-- linha. Na prática:
+--
+--   * a coluna "função" só está certa para quem está olhando;
+--   * quem tem login e NÃO tem cadastro de pessoa (o dono que criou o espaço, o
+--     contador, o sócio) simplesmente **não aparece** — a tela de "quem tem
+--     acesso" omite justamente quem tem acesso;
+--   * a mesma cegueira atinge o vínculo `person_id`, então o sistema não
+--     consegue dizer que a Dra. Silvania do cadastro e o login dela são a mesma
+--     pessoa, mesmo tendo a coluna para isso desde a 019.
+--
+-- Verificado num pool vivo antes de mexer: numa conta com três membros, um
+-- administrador logado lia **um**.
+--
+-- Função de colega não é segredo em lugar nenhum — é o que toda ferramenta de
+-- trabalho mostra na lista de gente. E é a diferença entre uma tela de acesso e
+-- uma tela que finge ser uma.
+--
+-- ESCREVER continua sendo de administrador. `members_update` e `members_delete`
+-- não são tocados: passar a enxergar quem está na equipe não é passar a poder
+-- mudar o papel de ninguém.
+--
+-- `tenant_members` está na lista de tabelas do núcleo da 002, então a varredura
+-- não a alcança e não existe policy permissiva chegando por trás — não precisa
+-- de par restritivo, ao contrário das tabelas novas da 040 e da 045.
+--
+-- Aditiva e idempotente.
+-- ============================================================================
+
+-- Uma policy numa tabela sem RLS ligado é uma mentira: ela existe no catálogo e
+-- não filtra nada. A 001 já liga, então aqui é no-op em qualquer pool de
+-- verdade — e é o que faz este arquivo bastar por si em qualquer outro.
+ALTER TABLE public.tenant_members ENABLE ROW LEVEL SECURITY;
+
+DROP POLICY IF EXISTS "members_select" ON public.tenant_members;
+CREATE POLICY "members_select" ON public.tenant_members
+  FOR SELECT
+  USING (tenant_id IN (SELECT public.user_tenant_ids()));
+
+-- ── E o nome de quem está na lista ──────────────────────────────────────────
+-- Só ampliar `tenant_members` deixaria a tela pior, não melhor: as linhas dos
+-- colegas passariam a aparecer **em branco**. Quem tem login e não tem ficha é
+-- nomeado a partir de `profiles`, e `profiles_select` da 001 é
+-- `id = auth.uid()` — cada um só lê o próprio nome.
+--
+-- `profiles` tem exatamente id, e-mail, nome e foto. Nome e foto são a razão de
+-- a tabela existir, e o e-mail do colega a tela de equipe já mostra pela ficha
+-- e pelo convite. O que não pode acontecer é ler gente de outra empresa, e é
+-- por isso que o segundo braço passa por `tenant_members` (que acabou de ficar
+-- limitado às minhas contas) em vez de liberar geral.
+--
+-- O braço é uma subconsulta NÃO correlacionada: um InitPlan por consulta, não
+-- uma busca por linha. É a mesma disciplina do predicado de unidade da 042.
+DROP POLICY IF EXISTS "profiles_select" ON public.profiles;
+CREATE POLICY "profiles_select" ON public.profiles
+  FOR SELECT
+  USING (
+    id = (SELECT auth.uid())
+    OR id IN (
+      SELECT tm.user_id FROM public.tenant_members tm
+       WHERE tm.tenant_id IN (SELECT public.user_tenant_ids())
+    )
+  );
+
+-- O ledger não é confiável em todo pool (há tabela aplicada à mão fora dele),
+-- então a coluna é conferida em vez de presumida.
+DO $$
+BEGIN
+  IF EXISTS (
+    SELECT 1 FROM information_schema.columns
+     WHERE table_schema = 'public' AND table_name = 'tenant_members'
+       AND column_name = 'person_id'
+  ) THEN
+    EXECUTE 'COMMENT ON COLUMN public.tenant_members.person_id IS '
+      || quote_literal('O cadastro de 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.');
+  END IF;
+END $$;