@fayz-ai/db 0.11.0 → 0.13.0

package/migrations/108_authz_write_guards.sql

@@ -0,0 +1,149 @@
+-- 108_authz_write_guards.sql
+--
+-- Closes the two privilege escalations the Phase 0 acceptance audit reproduced
+-- against a live database (#196, #197). Both are the same shape: a rule that
+-- exists in ONE writer, while the table underneath accepts the write from
+-- anywhere else.
+--
+-- #196 — `members.manage` was enough to become owner. `memberships_insert` and
+-- `memberships_delete` already carry `user_id <> auth.uid()`; `memberships_update`
+-- does not, and `public.v_authz_memberships` is auto-updatable and granted UPDATE
+-- to `authenticated` (043). So one PostgREST call promoted a seeded manager to
+-- owner and handed her `billing.manage`. Two rules were missing, and neither is
+-- new to this codebase — `invite_member` (052) has enforced both since #134:
+--   (a) you never write your own membership row;
+--   (b) you never grant a role holding a permission you do not hold.
+--
+-- #197 — the owner role was immutable only inside `role_set_permissions` (062).
+-- `trg_legacy_overrides_redirect` (063) resolves the role by key with no
+-- `is_system` filter and is SECURITY INVOKER, so an INSERT into the deprecated
+-- `public.tenant_role_overrides` facade revoked `financial.read` from the salon
+-- owner, permanently — `permissions_grant_owner` only fires for NEW catalog keys.
+--
+-- Why triggers and not policies. `app.memberships` and `app.role_permissions` are
+-- FORCE RLS, but `postgres` holds BYPASSRLS, which is how the SECURITY DEFINER
+-- RPCs (`create_tenant`, `accept_invitation`, `role_set_permissions`, the seed)
+-- write these tables at all. A policy therefore cannot see those writers, and a
+-- policy on the base table would not have closed #197 either — the facade writes
+-- as the *invoker*. Triggers fire for everyone, which is what these rules need.
+--
+-- Why `current_user = 'authenticated'` is the gate. It separates the two worlds
+-- exactly, with no session flag to set and no existing function to rewrite:
+--   · SECURITY DEFINER RPCs owned by postgres run as `postgres`  → skipped, they
+--     carry their own guards (and `create_tenant` legitimately inserts the
+--     caller's OWN owner membership, which rule (a) would otherwise refuse);
+--   · `service_role` and migrations/seeds run as themselves        → skipped,
+--     matching the posture of every `TO authenticated` policy in the chain;
+--   · a PostgREST call, and the SECURITY INVOKER legacy projections and facade,
+--     run as `authenticated`                                       → enforced.
+--
+-- Replay-safe: functions are CREATE OR REPLACE, triggers are dropped and
+-- recreated, no data is touched.
+
+-- ── #196: memberships ─────────────────────────────────────────────────────
+CREATE OR REPLACE FUNCTION app.authz_membership_guard()
+RETURNS trigger LANGUAGE plpgsql SECURITY INVOKER SET search_path = '' AS $$
+DECLARE v_actor uuid;
+BEGIN
+  IF current_user <> 'authenticated' THEN
+    RETURN NEW;
+  END IF;
+  v_actor := (select auth.uid());
+  IF v_actor IS NULL THEN
+    RETURN NEW;
+  END IF;
+
+  -- (a) your own membership is never written directly: not the row you are on,
+  --     and not a row you are moving onto yourself. Scope and role of the actor
+  --     change through create_tenant, an invitation, or another member's action.
+  IF NEW.user_id = v_actor OR (TG_OP = 'UPDATE' AND OLD.user_id = v_actor) THEN
+    RAISE EXCEPTION
+      'app.memberships: you cannot write your own membership (self-promotion and self-widening are refused; use an invitation or another member with members.manage)'
+      USING ERRCODE = '42501';
+  END IF;
+
+  -- (b) no escalation: every permission of the granted role must be held by the
+  --     actor, tenant-wide. Same rule and same wording as invite_member (052).
+  IF EXISTS (SELECT 1 FROM app.role_permissions rp
+              WHERE rp.tenant_id = NEW.tenant_id AND rp.role_id = NEW.role_id
+                AND NOT app.has_permission(rp.permission)) THEN
+    RAISE EXCEPTION
+      'app.memberships: cannot grant a role holding permissions you do not have'
+      USING ERRCODE = '42501';
+  END IF;
+
+  RETURN NEW;
+END $$;
+REVOKE ALL ON FUNCTION app.authz_membership_guard() FROM public, anon, authenticated;
+
+DROP TRIGGER IF EXISTS memberships_write_guard ON app.memberships;
+CREATE TRIGGER memberships_write_guard
+  BEFORE INSERT OR UPDATE ON app.memberships
+  FOR EACH ROW EXECUTE FUNCTION app.authz_membership_guard();
+
+-- The same two rules on the per-unit half: `membership_units` carries the unit
+-- scope and an optional `role_override_id`, so without this a manager could widen
+-- her own scope one unit at a time, or override herself into a stronger role.
+CREATE OR REPLACE FUNCTION app.authz_membership_unit_guard()
+RETURNS trigger LANGUAGE plpgsql SECURITY INVOKER SET search_path = '' AS $$
+DECLARE v_actor uuid; v_row record;
+BEGIN
+  IF current_user <> 'authenticated' THEN
+    RETURN CASE WHEN TG_OP = 'DELETE' THEN OLD ELSE NEW END;
+  END IF;
+  v_actor := (select auth.uid());
+  IF v_actor IS NULL THEN
+    RETURN CASE WHEN TG_OP = 'DELETE' THEN OLD ELSE NEW END;
+  END IF;
+  v_row := CASE WHEN TG_OP = 'DELETE' THEN OLD ELSE NEW END;
+
+  IF v_row.user_id = v_actor OR (TG_OP = 'UPDATE' AND OLD.user_id = v_actor) THEN
+    RAISE EXCEPTION
+      'app.membership_units: you cannot write your own unit scope'
+      USING ERRCODE = '42501';
+  END IF;
+
+  IF TG_OP IN ('INSERT', 'UPDATE') AND NEW.role_override_id IS NOT NULL
+     AND EXISTS (SELECT 1 FROM app.role_permissions rp
+                  WHERE rp.tenant_id = NEW.tenant_id AND rp.role_id = NEW.role_override_id
+                    AND NOT app.has_permission(rp.permission)) THEN
+    RAISE EXCEPTION
+      'app.membership_units: cannot override to a role holding permissions you do not have'
+      USING ERRCODE = '42501';
+  END IF;
+
+  RETURN v_row;
+END $$;
+REVOKE ALL ON FUNCTION app.authz_membership_unit_guard() FROM public, anon, authenticated;
+
+DROP TRIGGER IF EXISTS membership_units_write_guard ON app.membership_units;
+CREATE TRIGGER membership_units_write_guard
+  BEFORE INSERT OR UPDATE OR DELETE ON app.membership_units
+  FOR EACH ROW EXECUTE FUNCTION app.authz_membership_unit_guard();
+
+-- ── #197: the owner role is immutable, from every direction ───────────────
+-- The guard moves off role_set_permissions and onto the data, so the RPC, the
+-- deprecated facade, and any future writer all inherit it. `permissions_grant_owner`
+-- (043) keeps working: it runs as the definer while a catalog key is added.
+CREATE OR REPLACE FUNCTION app.authz_owner_role_immutable()
+RETURNS trigger LANGUAGE plpgsql SECURITY INVOKER SET search_path = '' AS $$
+DECLARE v_role uuid;
+BEGIN
+  IF current_user <> 'authenticated' THEN
+    RETURN CASE WHEN TG_OP = 'DELETE' THEN OLD ELSE NEW END;
+  END IF;
+  v_role := coalesce(NEW.role_id, OLD.role_id);
+  IF EXISTS (SELECT 1 FROM app.roles r
+              WHERE r.id = v_role AND r.is_system AND r.key = 'owner') THEN
+    RAISE EXCEPTION
+      'app.role_permissions: the owner role is immutable — it always holds the whole catalog'
+      USING ERRCODE = '42501';
+  END IF;
+  RETURN CASE WHEN TG_OP = 'DELETE' THEN OLD ELSE NEW END;
+END $$;
+REVOKE ALL ON FUNCTION app.authz_owner_role_immutable() FROM public, anon, authenticated;
+
+DROP TRIGGER IF EXISTS role_permissions_owner_immutable ON app.role_permissions;
+CREATE TRIGGER role_permissions_owner_immutable
+  BEFORE INSERT OR UPDATE OR DELETE ON app.role_permissions
+  FOR EACH ROW EXECUTE FUNCTION app.authz_owner_role_immutable();

package/migrations/109_catalog_migration_promoted_columns.sql

@@ -0,0 +1,126 @@
+-- 109_catalog_migration_promoted_columns.sql
+--
+-- Every migrated V1 service would have arrived 30 minutes long. Fix for #198.
+--
+-- 091 maps `duration_minutes` and `service_kind` into the JSONB payload, with the
+-- note "until #139 promotes it". #139 promoted both to real columns on
+-- public.products (075:41-42) -- and `migration.upsert_product` was never taught
+-- about them, so the destination wrote neither. `v_public_services` then does
+-- COALESCE(duration_minutes, 30), so the entire migrated catalogue silently
+-- became half-hour appointments with the schedulable state flattened to
+-- 'standard'. Nothing raised; the ledger recorded a successful upsert.
+--
+-- Two changes, and they belong together -- repointing the allowlist without
+-- teaching the writer just moves the drop one layer down:
+--   1. the `services` allowlist row maps both to the real columns;
+--   2. upsert_product writes them, translating V1's vocabulary to V2's
+--      (`service` -> `standard`, the rest pass through) and QUARANTINING rather
+--      than correcting anything outside it -- an unknown service_kind, one on a
+--      good, or a non-positive duration. Silent correction is what #148 forbids,
+--      and a defaulted duration is exactly the bug being fixed here.
+--
+-- Replay-safe: `_allow` upserts by source_table, the function is CREATE OR
+-- REPLACE, no data is touched.
+
+-- ── 1. the allowlist tells the truth about where these two land ───────────
+-- The row is frozen, and the freeze exists to say exactly this: "core-A
+-- allowlist changes are a migration file, not a write". This is that file, so it
+-- takes the documented unlock. set_config(..., true) is transaction-scoped and a
+-- DO block is one transaction, so the unlock cannot leak past these lines.
+DO $unlock$
+BEGIN
+  PERFORM set_config('migration.allowlist_unlock', 'on', true);
+  PERFORM migration._allow('services', 'public.products', 'catalog', 'product', '{"kind":"service"}', '{}',
+    '{"uuid":"id","tenant_id":"-","name":"name","description":"description","internal_code":"sku","category_id":"category_id@service_categories","price":"price","active":"is_active","duration_minutes":"duration_minutes","color":"jsonb:catalog.color","service_kind":"service_kind","revision_count":"jsonb:beauty.revision_count","revision_price":"jsonb:beauty.revision_price","revision_deadline_days":"jsonb:beauty.revision_deadline_days","validity_days":"jsonb:catalog.validity_days","contract_text":"jsonb:beauty.contract_text","post_service_text":"jsonb:beauty.post_service_text","reminder_text":"jsonb:beauty.reminder_text","scheduling_alert_text":"jsonb:beauty.scheduling_alert_text","always_ask_used_products":"jsonb:beauty.always_ask_used_products","suggest_quote_on_execution":"jsonb:beauty.suggest_quote_on_execution","category":"-","search_text":"-"}',
+    'PRD 04 R1: a service is a catalog item kind=service (public.services is drift, folded by #139). duration_minutes and service_kind are PROMOTED COLUMNS since #139 (ADR 0009, RN-CAT-03) -- they are core columns, not metadata; an unknown service_kind is quarantined, never defaulted (#198).');
+END $unlock$;
+
+-- ── 2. the writer that actually puts them there ───────────────────────────
+CREATE OR REPLACE FUNCTION migration.upsert_product(p_tenant uuid, p_id uuid, p_row jsonb, p_args jsonb DEFAULT '{}'::jsonb)
+RETURNS jsonb LANGUAGE plpgsql SECURITY DEFINER SET search_path = '' AS $$
+DECLARE
+  v_kind text := coalesce(p_args ->> 'kind', 'good');
+  v_meta jsonb := coalesce(p_row -> 'metadata', '{}'::jsonb);
+  -- #139 promoted these two out of JSONB and onto public.products; 091 still
+  -- described them as metadata and this writer wrote neither, so every migrated
+  -- service arrived with duration_minutes NULL and v_public_services COALESCEd
+  -- it to 30. See #198.
+  v_duration integer := nullif(btrim(coalesce(p_row ->> 'duration_minutes', '')), '')::integer;
+  -- V1 vocabulary is service|evaluation|return; V2's is standard|evaluation|return
+  -- ('service' was renamed because `kind` had already taken the archetype word).
+  -- 04-catalog-contract.md §V1 map, row `service_kind`.
+  v_service_kind_v1 text := nullif(btrim(lower(coalesce(p_row ->> 'service_kind', ''))), '');
+  v_service_kind text := CASE v_service_kind_v1
+                           WHEN 'service' THEN 'standard'
+                           ELSE v_service_kind_v1
+                         END;
+  v_existing_tenant uuid;
+  v_created boolean := false;
+  v_active boolean := coalesce((p_row ->> 'is_active')::boolean, true);
+  v_standalone boolean := migration._standalone();
+BEGIN
+  IF v_standalone THEN PERFORM migration._assert_fence(p_tenant); PERFORM set_config('migration.writer', 'on', true); END IF;
+  IF p_id IS NULL OR nullif(btrim(coalesce(p_row ->> 'name', '')), '') IS NULL THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'state', 'reason', 'a product needs an id and a name');
+  END IF;
+  -- No silent correction (#148): a service_kind outside the vocabulary is a
+  -- decision for a human, not a default. A good never carries one.
+  IF v_service_kind IS NOT NULL AND v_kind <> 'service' THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'value',
+      'reason', format('service_kind %L on a %L: only a service carries a schedulable state', v_service_kind_v1, v_kind));
+  END IF;
+  IF v_service_kind IS NOT NULL AND v_service_kind NOT IN ('standard', 'evaluation', 'return') THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'value',
+      'reason', format('unknown service_kind %L (V1 vocabulary is service|evaluation|return)', v_service_kind_v1));
+  END IF;
+  IF v_duration IS NOT NULL AND v_duration <= 0 THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'value',
+      'reason', format('duration_minutes %s is not a duration', v_duration));
+  END IF;
+  v_meta := migration._deep_set(v_meta, ARRAY['catalog', 'kind'], to_jsonb(v_kind));
+  SELECT tenant_id INTO v_existing_tenant FROM public.products WHERE id = p_id;
+  IF v_existing_tenant IS NOT NULL AND v_existing_tenant <> p_tenant THEN
+    RETURN jsonb_build_object('status', 'quarantined', 'kind', 'tenant', 'reason', format('product %s already exists in another tenant', p_id));
+  END IF;
+  IF v_existing_tenant IS NULL THEN
+    INSERT INTO public.products (id, tenant_id, category_id, name, description, sku, price, cost, currency, unit, image_url, status, is_active, metadata,
+                                 duration_minutes, service_kind)
+    VALUES (p_id, p_tenant, (p_row ->> 'category_id')::uuid, p_row ->> 'name', p_row ->> 'description', p_row ->> 'sku',
+            (p_row ->> 'price')::numeric, (p_row ->> 'cost')::numeric, coalesce(p_row ->> 'currency', 'BRL'), p_row ->> 'unit',
+            p_row ->> 'image_url', CASE WHEN v_active THEN 'active' ELSE 'inactive' END, v_active, v_meta,
+            v_duration, NULL);   -- service_kind is set below, after `kind` lands
+    v_created := true;
+  ELSE
+    UPDATE public.products SET
+      name = p_row ->> 'name',
+      category_id = CASE WHEN p_row ? 'category_id' THEN (p_row ->> 'category_id')::uuid ELSE category_id END,
+      description = CASE WHEN p_row ? 'description' THEN p_row ->> 'description' ELSE description END,
+      sku = CASE WHEN p_row ? 'sku' THEN p_row ->> 'sku' ELSE sku END,
+      price = CASE WHEN p_row ? 'price' THEN (p_row ->> 'price')::numeric ELSE price END,
+      cost = CASE WHEN p_row ? 'cost' THEN (p_row ->> 'cost')::numeric ELSE cost END,
+      unit = CASE WHEN p_row ? 'unit' THEN p_row ->> 'unit' ELSE unit END,
+      image_url = CASE WHEN p_row ? 'image_url' THEN p_row ->> 'image_url' ELSE image_url END,
+      status = CASE WHEN p_row ? 'is_active' THEN (CASE WHEN v_active THEN 'active' ELSE 'inactive' END) ELSE status END,
+      is_active = CASE WHEN p_row ? 'is_active' THEN v_active ELSE is_active END,
+      metadata = migration._merge_meta(metadata, v_meta),
+      duration_minutes = CASE WHEN p_row ? 'duration_minutes' THEN v_duration ELSE duration_minutes END
+    WHERE id = p_id;
+  END IF;
+  IF migration._has_column('public.products', 'kind') THEN
+    EXECUTE 'UPDATE public.products SET kind = $1 WHERE id = $2' USING v_kind, p_id;
+  END IF;
+  -- ORDER MATTERS. `kind` is applied in its own statement above, so anything
+  -- written to service_kind before this point is undone by
+  -- app.trg_catalog_products_normalise: it clears the column for a good and
+  -- re-defaults it to 'standard' for a service. Writing it here, after kind has
+  -- landed, is the only point where the value survives — and only when the source
+  -- actually carried one, so a service that arrived without a state keeps the
+  -- trigger's 'standard' rather than being reset to NULL against the pairing CHECK.
+  IF v_service_kind IS NOT NULL AND v_kind = 'service'
+     AND migration._has_column('public.products', 'service_kind') THEN
+    EXECUTE 'UPDATE public.products SET service_kind = $1 WHERE id = $2' USING v_service_kind, p_id;
+  END IF;
+  PERFORM migration._set_unit('public.products', p_id, (p_row ->> 'unit_id')::uuid);
+  IF v_standalone THEN PERFORM migration._audit(p_tenant, 'public.products', p_id, jsonb_build_object('reason', CASE WHEN v_created THEN 'created' ELSE 'updated' END)); END IF;
+  RETURN jsonb_build_object('status', 'migrated', 'target_id', p_id, 'reason', CASE WHEN v_created THEN 'created' ELSE 'updated' END);
+END $$;

package/migrations/110_people_kind_vocabulary.sql

@@ -0,0 +1,120 @@
+-- 110_people_kind_vocabulary.sql
+--
+-- A Person with no role at all. Fix for #204.
+--
+-- `person_kind_to_role` (070) maps the legacy `people.kind` vocabulary onto the
+-- roles this slice made canonical, and returns NULL for anything outside it --
+-- deliberately, so an app's own 'teacher' or 'patient' is left alone rather than
+-- guessed at. But two shipped plugins default to a kind that IS meant to be in
+-- the vocabulary and simply is not spelled the same way:
+--
+--   plugins/plugin-financial/src/index.ts:228   archetypeKind ?? 'client'
+--   plugins/plugin-crm/src/data/supabase.ts:766 archetypeKind ?? 'client'
+--
+-- so those Persons resolve to no role. The seed already contains one. It is
+-- invisible while readers query public.people directly and appears the moment a
+-- reader moves to v_people_active_roles -- which is the contract #137 tells
+-- everyone to use. At that point those customers are simply not there.
+--
+-- `client` is a synonym of `customer`, not a new concept, so it joins the map
+-- rather than the CHECK. The plugin defaults are corrected in the same commit;
+-- the alias is what covers the rows already written by the versions in the wild.
+--
+-- Second fix, same slice and the same class of bug: the role -> kind convergence
+-- had nothing behind `is_primary`. `trg_people_kind_from_roles` (070) clears the
+-- other primaries and sets one, which is correct in a single transaction and
+-- races in two -- both can read "no primary" and both write one, after which
+-- `people.kind` stops being derivable. Fixed in two layers: promotion demotes the
+-- others atomically (so callers stop having to order two statements correctly,
+-- which is what made the race reachable), and a partial unique index stands
+-- behind it for any writer that skips the trigger.
+--
+-- Replay-safe: CREATE OR REPLACE + CREATE UNIQUE INDEX IF NOT EXISTS. The index
+-- is created against existing data, so a pool that already raced will refuse it
+-- -- which is the right outcome: that data needs a human, not a silent pick.
+
+-- A PHONE IS NOT AN IDENTITY, AND THIS IS THE FILE THAT PROVES IT.
+--
+-- agenda/001 put a UNIQUE index on people (tenant_id, phone) WHERE kind =
+-- 'customer' — sound while `kind` was typed by hand and only the public booking
+-- form wrote customers. This file is what breaks that: `client` becomes
+-- `customer`, so every Person an import ever labelled 'client' arrives under the
+-- index at once, and a salon pool refuses the whole migration on eight people
+-- who share the placeholder 21111111111 somebody typed to get past a required
+-- field. They are eight different women with eight different appointment
+-- histories, and no rule that treats them as one row is worth keeping.
+--
+-- Identity in this slice is the CPF (081, people_tenant_document_uidx). Phone is
+-- a way to REACH someone: a mother books for a daughter, a couple shares a
+-- landline, an import fills the column with 1s.
+--
+-- The booking upsert does not need the index — agenda/003 already replaced it
+-- with a per-(tenant, phone) advisory lock, precisely because a
+-- tenant-configured client kind could not be arbitrated by a customer-only
+-- index. 001 now creates the index non-unique (it was always about lookup speed)
+-- and 009 takes the same lock instead of ON CONFLICT. Dropping it here is what
+-- lets a pool that already ran the old 001 move.
+DROP INDEX IF EXISTS public.people_tenant_customer_phone;
+
+CREATE OR REPLACE FUNCTION public.person_kind_to_role(p_kind text)
+RETURNS text LANGUAGE sql IMMUTABLE PARALLEL SAFE AS $$
+  SELECT CASE p_kind
+    WHEN 'customer'     THEN 'customer'
+    WHEN 'client'       THEN 'customer'   -- plugin-financial / plugin-crm default (#204)
+    WHEN 'staff'        THEN 'employee'
+    WHEN 'employee'     THEN 'employee'
+    WHEN 'professional' THEN 'professional'
+    WHEN 'lead'         THEN 'lead'
+    WHEN 'supplier'     THEN 'supplier'
+    WHEN 'vendor'       THEN 'supplier'
+    WHEN 'contact'      THEN 'contact'
+  END
+$$;
+
+-- Promotion becomes one atomic act: naming a primary demotes the others in the
+-- same statement, so a caller no longer has to clear the old hat first and there
+-- is no window where a person has two or none. Two concurrent promotions now
+-- serialise on the row lock the demote takes, instead of both succeeding.
+CREATE OR REPLACE FUNCTION app.trg_person_roles_single_primary()
+RETURNS trigger LANGUAGE plpgsql SET search_path = '' AS $$
+BEGIN
+  IF NEW.is_primary THEN
+    UPDATE public.person_roles r SET is_primary = false
+     WHERE r.tenant_id = NEW.tenant_id AND r.person_id = NEW.person_id
+       AND r.is_primary AND r.id <> NEW.id;
+  END IF;
+  RETURN NEW;
+END $$;
+DROP TRIGGER IF EXISTS person_roles_single_primary ON public.person_roles;
+CREATE TRIGGER person_roles_single_primary
+  BEFORE INSERT OR UPDATE OF is_primary ON public.person_roles
+  FOR EACH ROW WHEN (NEW.is_primary) EXECUTE FUNCTION app.trg_person_roles_single_primary();
+
+-- …and the backstop the trigger cannot be, if a future writer bypasses it.
+CREATE UNIQUE INDEX IF NOT EXISTS person_roles_one_primary_uidx
+  ON public.person_roles (tenant_id, person_id) WHERE is_primary;
+
+-- Backfill the roles the alias was silently denying. Only for people whose kind
+-- resolves to a role and who have none at all -- a person who already carries
+-- hats is left exactly as she is.
+DO $$
+DECLARE v_added integer;
+BEGIN
+  WITH missing AS (
+    SELECT p.tenant_id, p.id, public.person_kind_to_role(p.kind) AS role, p.unit_id
+      FROM public.people p
+     WHERE public.person_kind_to_role(p.kind) IS NOT NULL
+       AND NOT EXISTS (SELECT 1 FROM public.person_roles r
+                        WHERE r.tenant_id = p.tenant_id AND r.person_id = p.id)
+  ), ins AS (
+    INSERT INTO public.person_roles (tenant_id, person_id, role, unit_id, is_primary, metadata)
+    SELECT tenant_id, id, role, unit_id, true, jsonb_build_object('source', 'migration:100')
+      FROM missing
+    ON CONFLICT DO NOTHING
+    RETURNING 1
+  )
+  SELECT count(*)::int INTO v_added FROM ins;
+  IF v_added > 0 THEN
+    RAISE NOTICE '110_people_kind_vocabulary: gave a primary role to % person(s) whose kind resolved but had none', v_added;
+  END IF;
+END $$;