@fayz-ai/db 0.11.0 → 0.13.0

package/migrations/163_a_species_nobody_declared_goes_to_quarantine.sql

@@ -0,0 +1,184 @@
+-- ---------------------------------------------------------------------------
+-- 163_a_species_nobody_declared_goes_to_quarantine.sql — the half of #274 that
+-- 147 could only refuse (#274, ADR 0017).
+--
+-- 147's rule is that a V1 row whose species nobody declared goes to quarantine
+-- and NEVER weakens the constraint. It kept the second half absolutely: a value
+-- outside the identifier format raises, and the FK it is about to create is not
+-- softened to accommodate it. What it could not do is the first half — moving
+-- the row — because at that point in the file there is nowhere to move it to.
+--
+-- This is that half, and it is deliberately non-destructive. Three things
+-- happen to a row whose species has no owner:
+--
+--   1. the row is RECORDED, whole, in `migration.kind_quarantine` — so the
+--      original value survives even after the column is repaired;
+--   2. the column is repointed at `unclassified`, a species the base declares
+--      for exactly this, so the foreign key holds;
+--   3. nothing is deleted. Not the row, not the value, not the history.
+--
+-- ── Why `unclassified` and not NULL ────────────────────────────────────────
+-- `kind` is NOT NULL on every archetype, and it should be: a Compromisso with
+-- no species is a row nothing can render. A declared species meaning "nobody
+-- has said what this is" is honest, queryable, and impossible to mistake for a
+-- real classification — which is what a silently-invented species would be.
+--
+-- ── Why this cannot fix a pool that 147 already refused ────────────────────
+-- 147 runs first and raises before this file exists. That ordering is correct:
+-- refusing is safer than repairing something nobody has looked at. The runbook
+-- for a pool in that state is to apply up to 146, run the body of §2 by hand,
+-- then continue — which is why §2 is a FUNCTION rather than a loose DO block.
+-- ---------------------------------------------------------------------------
+
+-- ─────────────────────────────────────────────────────────────────────────
+-- §1  Where an undeclared species goes
+-- ─────────────────────────────────────────────────────────────────────────
+
+CREATE SCHEMA IF NOT EXISTS migration;
+
+CREATE TABLE IF NOT EXISTS migration.kind_quarantine (
+  id           bigserial PRIMARY KEY,
+  tenant_id    uuid,
+  archetype    text NOT NULL,
+  table_name   text NOT NULL,
+  column_name  text NOT NULL,
+  row_id       uuid,
+  -- The value as it was, before the column was repaired. This is the whole
+  -- point: a species is a business word, and the word is the evidence.
+  original_kind text NOT NULL,
+  payload      jsonb,
+  reason       text NOT NULL,
+  created_at   timestamptz NOT NULL DEFAULT now(),
+  resolved_at  timestamptz,
+  resolution   text
+);
+
+COMMENT ON TABLE migration.kind_quarantine IS
+  'Rows whose species no plugin declared (163, #274). The original value is kept here and the live column is repointed at `unclassified`, so the foreign key holds without anything being deleted or any constraint being weakened. A human registers the species and re-points the rows.';
+
+CREATE INDEX IF NOT EXISTS kind_quarantine_open_idx
+  ON migration.kind_quarantine (archetype, original_kind) WHERE resolved_at IS NULL;
+
+-- The migration schema's contract: RLS on every table, no policies, so
+-- PostgREST is deny-all and only the service role (which bypasses RLS) reaches
+-- it. Asserted by 090_migration_ledger/001.
+ALTER TABLE migration.kind_quarantine ENABLE ROW LEVEL SECURITY;
+REVOKE ALL ON migration.kind_quarantine FROM public, anon, authenticated;
+GRANT ALL ON migration.kind_quarantine TO service_role;
+GRANT USAGE, SELECT ON SEQUENCE migration.kind_quarantine_id_seq TO service_role;
+
+-- The species that means "nobody has said what this is". Declared on every
+-- archetype so the repair has somewhere to point, whatever the table.
+DO $$
+DECLARE
+  v_archetype text;
+BEGIN
+  IF to_regprocedure('public.register_kind(text, text, text, text[], jsonb, text)') IS NULL THEN
+    RETURN;
+  END IF;
+  FOREACH v_archetype IN ARRAY ARRAY['person', 'person_role', 'category', 'appointment', 'schedule', 'order', 'document']
+  LOOP
+    BEGIN
+      PERFORM public.register_kind(
+        v_archetype, 'unclassified', 'base', NULL, NULL,
+        'Nobody has declared what this row is. Set by 163 when a V1 value had no owner — the original is in migration.kind_quarantine, and this is not a classification, it is the absence of one.');
+    EXCEPTION WHEN OTHERS THEN
+      RAISE NOTICE '163: could not declare unclassified for % (%)', v_archetype, SQLERRM;
+    END;
+  END LOOP;
+END $$;
+
+-- ─────────────────────────────────────────────────────────────────────────
+-- §2  The sweep
+-- ─────────────────────────────────────────────────────────────────────────
+
+CREATE OR REPLACE FUNCTION public.quarantine_unregistered_kinds(p_dry_run boolean DEFAULT true)
+RETURNS TABLE (archetype text, table_name text, original_kind text, rows_affected bigint, action text)
+LANGUAGE plpgsql SECURITY DEFINER SET search_path = ''
+AS $$
+DECLARE
+  v_pair    record;
+  v_bad     record;
+  v_registry text;
+  v_n       bigint;
+BEGIN
+  FOR v_pair IN SELECT * FROM (VALUES
+    ('person',      'people',        'kind'),
+    ('person_role', 'person_roles',  'role'),
+    ('category',    'categories',    'kind'),
+    ('appointment', 'appointments',  'kind'),
+    ('schedule',    'schedules',     'kind'),
+    ('order',       'orders',        'kind'),
+    ('document',    'documents',     'kind')
+  ) AS p(arch, tbl, col)
+  LOOP
+    IF to_regclass('public.' || quote_ident(v_pair.tbl)) IS NULL THEN CONTINUE; END IF;
+    v_registry := public.kind_registry_table(v_pair.arch);
+    IF v_registry IS NULL OR to_regclass('public.' || quote_ident(v_registry)) IS NULL THEN CONTINUE; END IF;
+
+    -- Every distinct value in the data that the registry does not know.
+    FOR v_bad IN EXECUTE format(
+      'SELECT t.%I AS k, count(*)::bigint AS n FROM public.%I t
+         WHERE t.%I IS NOT NULL
+           AND NOT EXISTS (SELECT 1 FROM public.%I r WHERE r.kind = t.%I)
+         GROUP BY t.%I',
+      v_pair.col, v_pair.tbl, v_pair.col, v_registry, v_pair.col, v_pair.col)
+    LOOP
+      archetype     := v_pair.arch;
+      table_name    := v_pair.tbl;
+      original_kind := v_bad.k;
+      rows_affected := v_bad.n;
+
+      IF p_dry_run THEN
+        action := 'would quarantine';
+        RETURN NEXT;
+        CONTINUE;
+      END IF;
+
+      -- Record first, repair second. In that order, because a crash between
+      -- the two must lose the repair, never the evidence.
+      EXECUTE format(
+        'INSERT INTO migration.kind_quarantine (tenant_id, archetype, table_name, column_name, row_id, original_kind, payload, reason)
+           SELECT t.tenant_id, %L, %L, %L, t.id, t.%I, to_jsonb(t),
+                  ''No plugin declared this species. Repointed at unclassified by 163 so the FK holds - the word is kept here.''
+             FROM public.%I t WHERE t.%I = %L',
+        v_pair.arch, v_pair.tbl, v_pair.col, v_pair.col, v_pair.tbl, v_pair.col, v_bad.k);
+
+      EXECUTE format('UPDATE public.%I SET %I = ''unclassified'' WHERE %I = %L',
+                     v_pair.tbl, v_pair.col, v_pair.col, v_bad.k);
+      GET DIAGNOSTICS v_n = ROW_COUNT;
+      rows_affected := v_n;
+      action := 'quarantined';
+      RETURN NEXT;
+    END LOOP;
+  END LOOP;
+END $$;
+
+COMMENT ON FUNCTION public.quarantine_unregistered_kinds(boolean) IS
+  'Moves rows whose species nobody declared out of the way WITHOUT deleting anything (163, #274): the original value goes to migration.kind_quarantine and the column is repointed at `unclassified`. Dry run by default — an irreversible-looking sweep should have to be asked for twice.';
+
+REVOKE ALL ON FUNCTION public.quarantine_unregistered_kinds(boolean) FROM public, anon, authenticated;
+GRANT EXECUTE ON FUNCTION public.quarantine_unregistered_kinds(boolean) TO service_role;
+
+-- ─────────────────────────────────────────────────────────────────────────
+-- §3  The census, from the database rather than from CI
+--
+-- `scripts/check-kind-registry.mjs` reads the repository and answers "does the
+-- code declare what the code writes". This answers the other question: does
+-- anything in THIS pool still have no owner. 147 adopted every value it found
+-- with owner `unattributed`, and that is the backlog.
+-- ─────────────────────────────────────────────────────────────────────────
+
+CREATE OR REPLACE VIEW public.v_species_without_owner
+WITH (security_invoker = true) AS
+  SELECT 'person'::text AS archetype, k.kind, k.plugin, k.status FROM public.person_kinds k WHERE k.plugin = 'unattributed'
+  UNION ALL SELECT 'person_role', k.kind, k.plugin, k.status FROM public.person_role_kinds k WHERE k.plugin = 'unattributed'
+  UNION ALL SELECT 'category',    k.kind, k.plugin, k.status FROM public.category_kinds k    WHERE k.plugin = 'unattributed'
+  UNION ALL SELECT 'appointment', k.kind, k.plugin, k.status FROM public.appointment_kinds k WHERE k.plugin = 'unattributed'
+  UNION ALL SELECT 'schedule',    k.kind, k.plugin, k.status FROM public.schedule_kinds k    WHERE k.plugin = 'unattributed'
+  UNION ALL SELECT 'order',       k.kind, k.plugin, k.status FROM public.order_kinds k       WHERE k.plugin = 'unattributed';
+
+COMMENT ON VIEW public.v_species_without_owner IS
+  'Species present in this pool that 147 adopted with no owner (163, #274). Each row is a plugin that has not declared something it writes — the census that turns adoption into work rather than into a permanent state.';
+
+GRANT SELECT ON public.v_species_without_owner TO authenticated, service_role;

package/migrations/164_the_sequence_table_joins_the_register.sql

@@ -0,0 +1,26 @@
+-- ---------------------------------------------------------------------------
+-- 164_the_sequence_table_joins_the_register.sql — one more name whose creator
+-- changed (#285, #283).
+--
+-- `public.sequences` — per-tenant document numbering — has been base-owned since
+-- spine 097. plugin-financial created it in its own 004 and stopped, and the
+-- assertion that replaced the CREATE is plugin-financial 037.
+--
+-- ── Why this is a new file and not a line added to 162 ─────────────────────
+-- Because 162 had already been applied to a pool, and the ledger treats a
+-- changed checksum on an applied file as a hard stop. I learned that here the
+-- hard way, one migration after watching the same rule stop #285's edit to
+-- plugin-financial 004 — which is the better argument for the rule than any
+-- comment: it catches the person who wrote it, on the same afternoon, and it
+-- catches them before a pool is left in a state nobody can describe.
+--
+-- The register is append-only in practice for exactly this reason. A name that
+-- changes hands gets a new file, every time.
+-- ---------------------------------------------------------------------------
+
+INSERT INTO app.adopted_table_names (table_name, former_creator, new_owner, adopted_in, disposition, note) VALUES
+  ('sequences', 'financial', 'base', '097', 'adopted',
+   'Per-tenant document numbering, base-owned since spine 097. plugin-financial created it in 004 and stopped — the assertion that replaced the CREATE is financial 037, a NEW file, because 004 had already run on every pool.')
+ON CONFLICT (table_name) DO UPDATE
+  SET former_creator = EXCLUDED.former_creator, new_owner = EXCLUDED.new_owner,
+      adopted_in = EXCLUDED.adopted_in, disposition = EXCLUDED.disposition, note = EXCLUDED.note;

package/migrations/165_a_view_is_not_a_way_in.sql

@@ -0,0 +1,90 @@
+-- ---------------------------------------------------------------------------
+-- 165_a_view_is_not_a_way_in.sql — every view in `public` stops being born
+-- writable by anon.
+--
+-- ── The hole, measured ─────────────────────────────────────────────────────
+-- `ALTER DEFAULT PRIVILEGES` in this schema grants anon, authenticated and
+-- service_role `arwdDxtm` on every table AND VIEW that postgres creates in
+-- `public` — and migrations run as postgres. So a view is BORN with insert,
+-- update and delete for an unauthenticated caller, whatever the table beneath
+-- it grants, and a hand-written `GRANT SELECT` after the fact adds nothing
+-- because the default already gave more.
+--
+-- On the ecommerce cluster, read the day this was written: **85 of 94 views in
+-- `public` accept INSERT from `anon`.** Eleven tenants share that database.
+--
+-- Why it is not always exploitable is not a reason to leave it: a simple view
+-- is auto-updatable, so a write through it reaches the table. Where the view
+-- carries `security_invoker` the caller's own RLS still applies and anon is
+-- usually stopped there — but a view WITHOUT invoker runs as its owner and RLS
+-- does not apply at all. That combination is a straight bypass, and the only
+-- thing standing between the two cases is which flag somebody remembered.
+--
+-- ── What this does ─────────────────────────────────────────────────────────
+-- Revokes INSERT, UPDATE, DELETE and TRUNCATE from anon and authenticated on
+-- every view in `public`. SELECT is left exactly as it was: reading is what a
+-- view is for, and this file is not the place to relitigate who may read what.
+-- service_role keeps everything — it bypasses RLS by design and is the runner.
+--
+-- A view that genuinely needs to be written through (an INSTEAD OF trigger, a
+-- deliberate write surface) grants that back in its own migration, where the
+-- decision is visible. None exists today.
+--
+-- Found by a parallel session reviewing 148's compat alias, which is the
+-- narrow case; the census showed it was every view.
+-- ---------------------------------------------------------------------------
+
+DO $$
+DECLARE
+  v_view record;
+  v_fixed integer := 0;
+BEGIN
+  FOR v_view IN
+    SELECT c.relname
+      FROM pg_class c
+      JOIN pg_namespace n ON n.oid = c.relnamespace
+     WHERE n.nspname = 'public'
+       AND c.relkind IN ('v', 'm')
+     ORDER BY c.relname
+  LOOP
+    IF has_table_privilege('anon', format('public.%I', v_view.relname), 'INSERT')
+       OR has_table_privilege('anon', format('public.%I', v_view.relname), 'UPDATE')
+       OR has_table_privilege('anon', format('public.%I', v_view.relname), 'DELETE')
+       OR has_table_privilege('authenticated', format('public.%I', v_view.relname), 'INSERT')
+       OR has_table_privilege('authenticated', format('public.%I', v_view.relname), 'UPDATE')
+       OR has_table_privilege('authenticated', format('public.%I', v_view.relname), 'DELETE') THEN
+      EXECUTE format('REVOKE INSERT, UPDATE, DELETE, TRUNCATE ON public.%I FROM anon, authenticated', v_view.relname);
+      v_fixed := v_fixed + 1;
+    END IF;
+  END LOOP;
+  RAISE NOTICE '165: closed the write grant on % view(s)', v_fixed;
+END $$;
+
+-- And stop the next one being born with it. The default privilege is what
+-- created the hole, so narrowing the default is what stops it coming back on
+-- the next view any migration creates.
+ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE INSERT, UPDATE, DELETE, TRUNCATE ON TABLES FROM anon;
+
+-- ── the census ─────────────────────────────────────────────────────────────
+
+CREATE OR REPLACE VIEW public.v_views_anon_can_write
+WITH (security_invoker = true) AS
+  SELECT c.relname::text AS view_name,
+         c.relkind = 'm' AS materialized,
+         -- A view without security_invoker runs as its OWNER, so RLS does not
+         -- apply to what it reads. Writable AND definer is the straight bypass.
+         NOT coalesce((SELECT option_value = 'true' FROM pg_options_to_table(c.reloptions)
+                        WHERE option_name = 'security_invoker'), false) AS runs_as_owner
+    FROM pg_class c
+    JOIN pg_namespace n ON n.oid = c.relnamespace
+   WHERE n.nspname = 'public'
+     AND c.relkind IN ('v', 'm')
+     AND (has_table_privilege('anon', c.oid, 'INSERT')
+       OR has_table_privilege('anon', c.oid, 'UPDATE')
+       OR has_table_privilege('anon', c.oid, 'DELETE'))
+   ORDER BY c.relname;
+
+COMMENT ON VIEW public.v_views_anon_can_write IS
+  'Views an unauthenticated caller can write through (165). Zero is the expected reading. `runs_as_owner` true is the worse half: without security_invoker the view reads as its owner and RLS does not apply.';
+
+GRANT SELECT ON public.v_views_anon_can_write TO authenticated, service_role;

package/migrations/166_the_platform_billing_leftovers_go.sql

@@ -0,0 +1,72 @@
+-- ---------------------------------------------------------------------------
+-- 166_the_platform_billing_leftovers_go.sql — three Stripe-shaped tables that
+-- were never the pool's business (#183).
+--
+-- `001_core.sql` created `invoices`, `payment_events` and `subscriptions` in the
+-- Fayz Cloud era, when one database was meant to hold both moneys: what a
+-- tenant's CUSTOMER pays the tenant, and what the TENANT pays Fayz. DECISIONS
+-- 2026-07-24 split those — industry pools superseded Fayz Cloud, and platform
+-- billing moved to the platform side.
+--
+-- What is left in the pool is the wrong half, and it costs more than the space:
+-- these three compete for the word "invoice" with `plg_financial_invoices`,
+-- which is exactly the confusion that made `plg_financial_titles` need renaming
+-- in the first place. A reader who greps "invoice" in a pool should find one
+-- answer.
+--
+-- ── Measured before dropping ───────────────────────────────────────────────
+-- Zero rows on ecommerce and salon, the two largest pools. Zero readers in the
+-- TypeScript: the only `'subscriptions'` matches are a nav-tab label in
+-- plugin-courses, unrelated to this table.
+--
+-- ── `plans` STAYS ─────────────────────────────────────────────────────────
+-- It is load-bearing and not a leftover: `agent_guard()` resolves role × plan ×
+-- limits through `tenants.plan → plans.entitlements` in SQL, and 154's ceiling
+-- reads `tenants.settings billing.plan_id`. Entitlements are enforced in the
+-- database, so the catalogue belongs in the database.
+--
+-- ── Empty or nothing ──────────────────────────────────────────────────────
+-- The drop is guarded on the table being EMPTY. A pool that turns out to hold
+-- rows keeps them and says so — nobody's billing history is deleted to tidy a
+-- schema, and finding rows here would mean the assumption above is wrong for
+-- that pool, which is worth knowing rather than erasing.
+-- ---------------------------------------------------------------------------
+
+DO $$
+DECLARE
+  v_table text;
+  v_rows  bigint;
+BEGIN
+  FOREACH v_table IN ARRAY ARRAY['payment_events', 'invoices', 'subscriptions']
+  LOOP
+    IF to_regclass('public.' || quote_ident(v_table)) IS NULL THEN CONTINUE; END IF;
+
+    EXECUTE format('SELECT count(*) FROM public.%I', v_table) INTO v_rows;
+    IF v_rows > 0 THEN
+      RAISE NOTICE '166: public.% holds % row(s) — kept. Platform billing was supposed to have moved off the pool; a row here says otherwise for this cluster.', v_table, v_rows;
+      CONTINUE;
+    END IF;
+
+    -- CASCADE only reaches views over an empty table, and any such view is
+    -- reporting on nothing. A dependent TABLE would be a foreign key, which
+    -- would have made the count non-zero on the other side.
+    EXECUTE format('DROP TABLE public.%I CASCADE', v_table);
+    RAISE NOTICE '166: dropped public.% — platform billing is the platform''s (DECISIONS 2026-07-24)', v_table;
+  END LOOP;
+END $$;
+
+-- What is left, for a pool where something was kept.
+CREATE OR REPLACE VIEW public.v_platform_billing_leftovers
+WITH (security_invoker = true) AS
+  SELECT c.relname::text AS table_name,
+         (SELECT n_live_tup FROM pg_stat_user_tables s WHERE s.relid = c.oid) AS approx_rows
+    FROM pg_class c
+    JOIN pg_namespace n ON n.oid = c.relnamespace
+   WHERE n.nspname = 'public'
+     AND c.relkind = 'r'
+     AND c.relname IN ('invoices', 'payment_events', 'subscriptions');
+
+COMMENT ON VIEW public.v_platform_billing_leftovers IS
+  'Fayz Cloud-era platform billing tables still present in this pool (166, #183). Empty is the expected reading — 166 drops them when they hold nothing. A row here means that cluster still records what the TENANT pays Fayz, which belongs on the platform side.';
+
+GRANT SELECT ON public.v_platform_billing_leftovers TO service_role;

package/migrations/167_a_view_gets_back_what_its_table_grants.sql

@@ -0,0 +1,112 @@
+-- ---------------------------------------------------------------------------
+-- 167_a_view_gets_back_what_its_table_grants.sql — undoing the half of 165 that
+-- was too blunt.
+--
+-- ── What 165 got right, and what it broke ──────────────────────────────────
+-- 165 closed a real hole: `ALTER DEFAULT PRIVILEGES` gives every view postgres
+-- creates in `public` full write access for **anon**, and 85 of 94 views on the
+-- ecommerce pool carried it. Revoking anon was correct and stays.
+--
+-- Revoking `authenticated` in the same sweep was not. A signed-in user's writes
+-- are governed by **RLS**, which is the actual control — and several of these
+-- views are not read models at all but **compat aliases** created by 141's
+-- rename mechanism, whose entire purpose is that the old name keeps working
+-- exactly as it did. A read-only alias does not make a rename unsynchronised;
+-- it moves the breakage from "the table is gone" to "permission denied for
+-- view", which is worse because it looks like a permissions bug.
+--
+-- Measured after 165, on the ecommerce pool: **94 views** lost INSERT for
+-- `authenticated`. Most are read models nobody writes. These are not:
+--
+--   shipping_zones · shipping_settings   the merchant's delivery screen —
+--                                        `packages/shop/src/data/tables.ts`
+--                                        still writes through the old name
+--   plg_connections · plg_connection_secrets · plg_connector_schedules
+--                                        connector setup
+--   plg_sync_runs · plg_sync_schedule    connector sync
+--   plg_event_log                        the domain-event log's own alias
+--   v_documents                          attachment uploads
+--
+-- ── The rule this file states ──────────────────────────────────────────────
+-- A view gets back exactly what its underlying table grants — no more, no less.
+-- That is 141's alias rule made mechanical instead of hand-written, and it is
+-- self-correcting: a table that is tightened later tightens its alias on the
+-- next run, and a view over a table nobody may write stays unwritable.
+--
+-- `anon` is excluded unconditionally. It is the role the hole was about, and no
+-- alias needs it: an anonymous writer reaches the base table through its own
+-- policy or not at all.
+-- ---------------------------------------------------------------------------
+
+DO $$
+DECLARE
+  v_view   record;
+  v_priv   text;
+  v_fixed  integer := 0;
+BEGIN
+  FOR v_view IN
+    -- Only views over exactly ONE base table can be written through at all
+    -- (Postgres refuses the rest), so those are the only ones worth granting.
+    SELECT u.view_name, min(u.table_name) AS base_table
+      FROM information_schema.view_table_usage u
+     WHERE u.view_schema = 'public' AND u.table_schema = 'public'
+     GROUP BY u.view_name
+    HAVING count(DISTINCT u.table_name) = 1
+  LOOP
+    IF to_regclass('public.' || quote_ident(v_view.view_name)) IS NULL
+       OR to_regclass('public.' || quote_ident(v_view.base_table)) IS NULL THEN
+      CONTINUE;
+    END IF;
+
+    FOREACH v_priv IN ARRAY ARRAY['INSERT', 'UPDATE', 'DELETE']
+    LOOP
+      -- Mirror, never widen: the table decides.
+      IF has_table_privilege('authenticated', format('public.%I', v_view.base_table), v_priv)
+         AND NOT has_table_privilege('authenticated', format('public.%I', v_view.view_name), v_priv) THEN
+        EXECUTE format('GRANT %s ON public.%I TO authenticated', v_priv, v_view.view_name);
+        v_fixed := v_fixed + 1;
+      END IF;
+    END LOOP;
+  END LOOP;
+
+  RAISE NOTICE '167: restored % view privilege(s) to authenticated, mirroring the base table', v_fixed;
+END $$;
+
+-- anon stays out, whatever the table says. This is the half of 165 that was
+-- right, restated so a re-run of this file cannot undo it.
+DO $$
+DECLARE
+  v_view record;
+BEGIN
+  FOR v_view IN
+    SELECT c.relname FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
+     WHERE n.nspname = 'public' AND c.relkind IN ('v', 'm')
+       AND (has_table_privilege('anon', c.oid, 'INSERT')
+         OR has_table_privilege('anon', c.oid, 'UPDATE')
+         OR has_table_privilege('anon', c.oid, 'DELETE'))
+  LOOP
+    EXECUTE format('REVOKE INSERT, UPDATE, DELETE, TRUNCATE ON public.%I FROM anon', v_view.relname);
+  END LOOP;
+END $$;
+
+-- ── the census, both directions ────────────────────────────────────────────
+--
+-- 165 gave us "which views can anon write". The other half was missing and is
+-- what this file exists because of: which views an alias's users can NO LONGER
+-- write, though the table beneath still allows it.
+
+CREATE OR REPLACE VIEW public.v_views_missing_table_grants
+WITH (security_invoker = true) AS
+  SELECT u.view_name::text,
+         min(u.table_name)::text AS base_table
+    FROM information_schema.view_table_usage u
+   WHERE u.view_schema = 'public' AND u.table_schema = 'public'
+   GROUP BY u.view_name
+  HAVING count(DISTINCT u.table_name) = 1
+     AND bool_or(has_table_privilege('authenticated', format('public.%I', u.table_name), 'INSERT'))
+     AND NOT bool_or(has_table_privilege('authenticated', format('public.%I', u.view_name), 'INSERT'));
+
+COMMENT ON VIEW public.v_views_missing_table_grants IS
+  'Views a signed-in user can no longer write although the table beneath still allows it (167). Zero is the expected reading — a compat alias that lost its grants reads as a permissions bug on a screen, which is the most expensive kind of breakage to diagnose.';
+
+GRANT SELECT ON public.v_views_missing_table_grants TO authenticated, service_role;

package/migrations/168_the_grant_census_stops_crying_wolf.sql

@@ -0,0 +1,33 @@
+-- ---------------------------------------------------------------------------
+-- 168_the_grant_census_stops_crying_wolf.sql — 167's census counted a view over
+-- a view.
+--
+-- `information_schema.view_table_usage` reports every relation a view reads,
+-- and a VIEW is one of them. So `plg_crm_rep_leads`, which reads `v_leads`,
+-- looked like an alias missing its table's grants — when neither is writable
+-- and neither ever will be.
+--
+-- A census that reads 1 forever is a census people learn to ignore, which is
+-- worse than not having one. It now counts only views over an actual TABLE.
+-- ---------------------------------------------------------------------------
+
+CREATE OR REPLACE VIEW public.v_views_missing_table_grants
+WITH (security_invoker = true) AS
+  SELECT u.view_name::text,
+         min(u.table_name)::text AS base_table
+    FROM information_schema.view_table_usage u
+    JOIN pg_class c ON c.relname = u.table_name
+    JOIN pg_namespace n ON n.oid = c.relnamespace AND n.nspname = u.table_schema
+   WHERE u.view_schema = 'public' AND u.table_schema = 'public'
+     -- A base that is itself a view cannot be written through either, so a
+     -- missing grant there is not a regression, it is the shape of the thing.
+     AND c.relkind = 'r'
+   GROUP BY u.view_name
+  HAVING count(DISTINCT u.table_name) = 1
+     AND bool_or(has_table_privilege('authenticated', format('public.%I', u.table_name), 'INSERT'))
+     AND NOT bool_or(has_table_privilege('authenticated', format('public.%I', u.view_name), 'INSERT'));
+
+COMMENT ON VIEW public.v_views_missing_table_grants IS
+  'Views a signed-in user can no longer write although the TABLE beneath still allows it (167, narrowed by 168). Zero is the expected reading — a compat alias that lost its grants reads as a permissions bug on a screen, which is the most expensive kind of breakage to diagnose.';
+
+GRANT SELECT ON public.v_views_missing_table_grants TO authenticated, service_role;

package/migrations/169_the_census_asks_postgres_instead_of_guessing.sql

@@ -0,0 +1,45 @@
+-- ---------------------------------------------------------------------------
+-- 169_the_census_asks_postgres_instead_of_guessing.sql — third and last attempt
+-- at the same census, this time asking the only source that knows.
+--
+-- The question is "which compat alias lost the write access its table has".
+-- 167 approximated it as "a view reading exactly one relation", which counted
+-- a view over a view. 168 narrowed to a view over a TABLE, which then counted
+-- seven aggregate read models — `v_financial_ledger`, `v_invoice_balances`,
+-- `plg_courses_rep_sales` and friends. Each reads one table and none is
+-- writable, because they aggregate.
+--
+-- Both attempts were guessing at a property Postgres already computes:
+-- `information_schema.views.is_insertable_into` is YES only for a view you can
+-- actually INSERT through. A view that aggregates, joins, DISTINCTs or windows
+-- is NO, and no grant changes that.
+--
+-- The lesson is worth more than the fix. Two rounds of a census reading
+-- non-zero for a reason nobody needed to act on is exactly how a check gets
+-- ignored — and a check people ignore is worse than no check, because it
+-- occupies the space where a real one would go.
+-- ---------------------------------------------------------------------------
+
+CREATE OR REPLACE VIEW public.v_views_missing_table_grants
+WITH (security_invoker = true) AS
+  SELECT v.table_name::text AS view_name,
+         min(u.table_name)::text AS base_table
+    FROM information_schema.views v
+    JOIN information_schema.view_table_usage u
+      ON u.view_schema = v.table_schema AND u.view_name = v.table_name
+    JOIN pg_class c ON c.relname = u.table_name
+    JOIN pg_namespace n ON n.oid = c.relnamespace AND n.nspname = u.table_schema
+   WHERE v.table_schema = 'public'
+     AND u.table_schema = 'public'
+     -- The whole predicate, from the planner rather than from a heuristic.
+     AND v.is_insertable_into = 'YES'
+     AND c.relkind = 'r'
+   GROUP BY v.table_name
+  HAVING count(DISTINCT u.table_name) = 1
+     AND bool_or(has_table_privilege('authenticated', format('public.%I', u.table_name), 'INSERT'))
+     AND NOT bool_or(has_table_privilege('authenticated', format('public.%I', v.table_name), 'INSERT'));
+
+COMMENT ON VIEW public.v_views_missing_table_grants IS
+  'Views a signed-in user can no longer write although the table beneath allows it AND Postgres considers the view insertable (167→169). Zero is the expected reading. An alias that lost its grants reads as a permissions bug on a screen — the most expensive kind to diagnose, and the reason 165 had to be narrowed.';
+
+GRANT SELECT ON public.v_views_missing_table_grants TO authenticated, service_role;

package/package.json

@@ -3,7 +3,7 @@
   "fayz": {
     "status": "beta"
   },
-  "version": "0.11.0",
+  "version": "0.13.0",
   "description": "Fayz SDK database layer — Drizzle schema primitives, spine references, and migration helpers shared across plugins.",
   "type": "module",
   "sideEffects": false,
@@ -19,7 +19,8 @@
   },
   "files": [
     "dist",
-    "migrations"
+    "migrations",
+    "canonical-schema.json"
   ],
   "dependencies": {
     "drizzle-orm": "^0.36.4"
@@ -38,12 +39,12 @@
   ],
   "peerDependencies": {},
   "scripts": {
-    "build": "tsup && tsc --emitDeclarationOnly --declaration --declarationMap --noEmit false",
+    "build": "tsup && tsc -b --force",
     "dev": "tsup --watch",
-    "typecheck": "tsc --noEmit",
+    "typecheck": "tsc -b",
     "test": "bash test/run-migrations.sh",
     "test:migrations": "bash test/run-migrations.sh",
     "test:negative-control": "bash test/negative-control.sh",
-    "clean": "rm -rf dist"
+    "clean": "rm -rf dist .tsbuildinfo"
   }
 }