@fayz-ai/db 0.12.0 → 0.14.0

package/migrations/008_the_switchers_see_across_accounts.sql

@@ -0,0 +1,150 @@
+-- 008_the_switchers_see_across_accounts.sql — the two switchers stop lying.
+--
+-- 001 gave a tenant its apps and the switcher started working. What it got
+-- wrong is WHOSE question each switcher answers, and the symptom was visible in
+-- both directions at once:
+--
+--   · ChefControl listed "Clínica Sol" and "Espaco Renova Rio" as workspaces.
+--     Neither runs the restaurant app. Opening one put a beauty account inside
+--     a restaurant product, with a rail full of screens its data cannot fill.
+--
+--   · The same session could not reach StudioControl at all. `apps` was read
+--     from the ACTIVE tenant, and Papa Léguas Tacos runs resto + shop — so the
+--     product the person plainly has access to, through another account of
+--     their own, simply was not in the list.
+--
+-- Fixing either alone makes it worse: a Chef that hides Clínica Sol, in a
+-- session whose app list cannot show Studio, has no route to the beauty data at
+-- all. They are one change.
+--
+-- THE MODEL, stated once: the app comes first, the account second.
+--
+--   apps  = the union across every account you belong to. It answers "which
+--           products do I have", not "which does this account run".
+--   accounts = filtered to those that run the app you are looking at. It
+--           answers "which of my workspaces does THIS product serve".
+--
+-- So each app carries `tenant_id` — where clicking it lands. The active tenant
+-- when it runs the app (staying put is the common case), otherwise the first
+-- account that does. Without it, clicking Studio from a restaurant account
+-- would arrive at StudioControl and fall back to memberships[0], which is how
+-- somebody lands in an account they did not pick.
+--
+-- There is deliberately no `current` flag here. Which app you are LOOKING at is
+-- the bundle's own fact — VITE_APP_ID, resolved client-side — and the database
+-- cannot see it: Papa Léguas runs both resto and shop, so any server-side
+-- "current" would mark two apps at once and the checkmark would land on both.
+-- Whether the active account runs an app is already readable from `tenant_id`
+-- (it equals the active tenant, or it does not), so a second field would only
+-- be a second chance to disagree.
+
+-- ── §1  the bridge view ────────────────────────────────────────────────────
+--
+-- PostgREST cannot reach the `app` schema, so the workspace list — which runs
+-- in the client, through supabase-js — has no way to ask which accounts run an
+-- app. Same reason v_team_members and the other v_* bridges exist (#134).
+--
+-- security_invoker: app.tenant_apps' own RLS (tenant_apps_read, scoped to
+-- user_tenant_ids()) decides the rows. The view adds no reach of its own.
+
+CREATE OR REPLACE VIEW public.v_tenant_apps WITH (security_invoker = 'true') AS
+  SELECT ta.tenant_id,
+         ta.app_id,
+         ta.status,
+         a.name  AS app_name,
+         a.icon  AS app_icon,
+         a.url   AS app_url
+    FROM app.tenant_apps ta
+    JOIN app.apps a ON a.id = ta.app_id
+   WHERE ta.status = 'active'
+     AND a.active;
+
+COMMENT ON VIEW public.v_tenant_apps IS
+  'Which accounts run which apps (008), for the workspace switcher to filter itself by the app it is inside. security_invoker — app.tenant_apps RLS decides the rows.';
+
+GRANT SELECT ON public.v_tenant_apps TO authenticated;
+GRANT ALL    ON public.v_tenant_apps TO service_role;
+
+-- ── §2  app_config() answers for the person, not just the account ──────────
+--
+-- Re-emitted whole, for the reason 001 gave: this is the one function the shell
+-- asks on boot, and a reader should see the entire answer in one place. Every
+-- other key is byte-identical to 001; only 'apps' changed.
+
+CREATE OR REPLACE FUNCTION public.app_config() RETURNS jsonb
+    LANGUAGE plpgsql STABLE SECURITY DEFINER
+    SET search_path TO ''
+    AS $$
+DECLARE
+  v_tenant uuid := app.current_tenant_id();
+BEGIN
+  IF v_tenant IS NULL THEN
+    -- Fail closed and legibly: a caller with no resolvable tenant gets an empty
+    -- configuration, not somebody else's.
+    RETURN jsonb_build_object('tenant_id', NULL, 'plugins', '[]'::jsonb, 'nav', '[]'::jsonb, 'apps', '[]'::jsonb);
+  END IF;
+
+  RETURN jsonb_build_object(
+    'tenant_id', v_tenant,
+    'branding',  public.tenant_branding(),
+    'settings',  public.tenant_settings(),
+    'plugins', coalesce((
+      SELECT jsonb_agg(jsonb_build_object(
+               'plugin', t.plugin_id,
+               'facet',  nullif(t.facet, ''),
+               'status', t.status,
+               'source', t.source,
+               'config', t.config,
+               'expires_at', t.expires_at
+             ) ORDER BY t.plugin_id, t.facet)
+        FROM app.tenant_plugins t
+       WHERE t.tenant_id = v_tenant
+         AND t.status = 'active'
+         AND (t.expires_at IS NULL OR t.expires_at > now())
+    ), '[]'::jsonb),
+    -- The union across the caller's accounts. One row per app, however many of
+    -- the person's accounts run it.
+    'apps', coalesce((
+      SELECT jsonb_agg(x.obj ORDER BY x.sort_name)
+        FROM (
+          SELECT a.name AS sort_name,
+                 jsonb_build_object(
+                   'id',           a.id,
+                   'name',         a.name,
+                   'icon',         a.icon,
+                   'accent_color', a.accent_color,
+                   'url',          a.url,
+                   -- Where clicking lands. Staying in the active account wins;
+                   -- otherwise the first that runs it, ordered by name so the
+                   -- answer does not move between two identical calls.
+                   'tenant_id',    (array_agg(ta.tenant_id
+                                     ORDER BY (ta.tenant_id = v_tenant) DESC, tn.name))[1]
+                 ) AS obj
+            FROM app.tenant_apps ta
+            JOIN app.apps a       ON a.id  = ta.app_id
+            JOIN public.tenants tn ON tn.id = ta.tenant_id
+           WHERE ta.status = 'active'
+             AND a.active
+             AND ta.tenant_id IN (
+                   SELECT m.tenant_id FROM app.memberships m
+                    WHERE m.user_id = auth.uid() AND m.active)
+           GROUP BY a.id, a.name, a.icon, a.accent_color, a.url
+        ) x
+    ), '[]'::jsonb),
+    'nav', coalesce((
+      SELECT jsonb_agg(jsonb_build_object(
+               'key', n.entry_key, 'hidden', n.hidden, 'label', n.label,
+               'section', n.section, 'position', n.position
+             ) ORDER BY coalesce(n.position, 999), n.entry_key)
+        FROM app.tenant_nav n
+       WHERE n.tenant_id = v_tenant
+    ), '[]'::jsonb),
+    'permissions', coalesce((
+      SELECT jsonb_agg(DISTINCT rp.permission)
+        FROM app.memberships m
+        JOIN app.role_permissions rp ON rp.role_id = m.role_id AND rp.tenant_id = m.tenant_id
+       WHERE m.tenant_id = v_tenant AND m.user_id = auth.uid() AND m.active
+    ), '[]'::jsonb),
+    'generated_at', now()
+  );
+END $$;

package/migrations/009_the_compat_aliases_nobody_adopted.sql

@@ -0,0 +1,57 @@
+-- ---------------------------------------------------------------------------
+-- 009_the_compat_aliases_nobody_adopted — four of 141's shims leave (#352).
+--
+-- 141 renamed a set of core tables out of the `plg_` prefix and left a VIEW
+-- answering to the old name, under one contract: "callers move to the real
+-- name; this view is dropped when the last one has." The first half ran. The
+-- second half never did, so the shims have been sitting in the schema ever
+-- since — and a name in the schema is not inert, it is an instruction. The
+-- measured cost of leaving them: `plg_connections` has 13 callers and
+-- `connections` has none. The alias won. That is what this file starts undoing.
+--
+-- WHAT LEAVES HERE, AND WHY ONLY THESE FOUR. A shim is droppable when nothing
+-- reads it — in TypeScript, in an edge function, or in SQL inside an applied
+-- baseline, which is the one that bites, because the chain force-replays every
+-- file and an applied migration cannot be edited to stop reading a name.
+--
+--     plg_analytics_read_models   no reader of any kind
+--     plg_connection_secrets      no reader of any kind
+--     plg_entity_fields           packages/core/src/fields/store.ts now names
+--                                 public.entity_fields
+--     plg_event_log               packages/core/src/events/log.ts now names
+--                                 public.event_log
+--
+-- The other six 141 shims stay for now, each for a reason that is a task and
+-- not an opinion: `plg_connector_schedules` and `plg_sync_schedule` are WRITTEN
+-- THROUGH by packages/shop/migrations/000_baseline.sql (an `UPDATE ... FROM` at
+-- 4875), which runs after the spine, so dropping them here breaks the shop's
+-- replay rather than the shop's code; `fayz_search_sources` is read by a spine
+-- function; `fayz_projects` is joined by a view in plugin-marketing's baseline,
+-- which makes its drop CROSS-PACKAGE and therefore not a spine file at all.
+-- Those move with their readers, in #352 wave 3.
+--
+-- Dropping the view does not touch the table it pointed at, and every one of
+-- these had `security_invoker` semantics only by accident of ownership — the
+-- canonical tables carry their own RLS and policies, which is what the callers
+-- now reach.
+--
+-- ── Numbered 009, and why this file is the one that moved ─────────────────
+-- It was 001. #355 also has a 001 in this directory, and the chain runner sorts
+-- by FILENAME, so two files on the same number run in whatever order the words
+-- after it happen to give — an order nobody chose (#301).
+--
+-- The other file could not move. `001_the_tenant_has_apps` creates app.apps and
+-- app.tenant_apps, and `008_the_switchers_see_across_accounts` builds a VIEW on
+-- both — a hard dependency, so it has to stay below 008, and 002-007 are taken.
+-- This file drops four views nothing reads: no migration before it needs them
+-- gone, none after it needs them present. Its position is the free one, so it
+-- is the one that gives way.
+--
+-- Idempotent and replay-safe by construction: IF EXISTS, and a view that is
+-- already gone is not an error.
+-- ---------------------------------------------------------------------------
+
+DROP VIEW IF EXISTS public.plg_analytics_read_models;
+DROP VIEW IF EXISTS public.plg_connection_secrets;
+DROP VIEW IF EXISTS public.plg_entity_fields;
+DROP VIEW IF EXISTS public.plg_event_log;

package/migrations/010_the_new_tenant_is_born_with_its_trade.sql

@@ -0,0 +1,201 @@
+-- 010_the_new_tenant_is_born_with_its_trade.sql
+--
+-- Um tenant criado pela UI nascia sem plugin e sem app. Quem criava conseguia
+-- lançar — a RLS de INSERT só olha tenant, unidade e permissão, e essas estavam
+-- certas — e perdia tudo no reload, porque a casca monta o que `app_config()`
+-- devolve em `plugins`, e ali não havia nada.
+--
+-- Três defeitos somados, no mesmo caminho:
+--
+-- 1. `create_tenant()` cria tenant, papéis, unidade HQ e a membership do dono,
+--    e PARA. Nunca semeou nem `app.tenant_plugins` nem `app.tenant_apps`.
+--
+-- 2. `app.vertical_defaults` semeia FACETS e nenhuma linha do plugin em si. Mas
+--    o contrato é "o plugin é a facet de nome vazio" (PluginFacet), e a casca
+--    filtra `status === 'active' && !facet`. Ligar só facets acende zero plugin.
+--
+-- 3. Nada nunca escreveu `app.tenant_apps`, que é o que o switcher lê — então
+--    mesmo com plugin aceso o tenant novo não tinha app nenhum.
+--
+-- A semeadura passa a ter DUAS fontes, e nenhuma substitui a outra:
+--
+--   `app.vertical_defaults` continua decidindo as FACETS do ramo — é onde
+--   "um salão agenda, e não vende online" está escrito, no grão em que foi
+--   escrito. Este arquivo não toca nela.
+--
+--   `app.apps` passa a decidir os APPS e os plugins que eles exigem, que é o
+--   grão que faltava: `requires` já lista os plugins, e `tenant_apps` é o que o
+--   switcher lê. O ramo que cada app atende vira uma coluna DELE em vez de uma
+--   tabela de-para separada.
+--
+-- E toda facet acesa garante a linha sem facet do seu plugin: acender
+-- `agenda.scheduling` sem acender `agenda` é a forma exata do defeito 2.
+
+-- ── o app declara o ramo que atende ─────────────────────────────────────────
+ALTER TABLE app.apps ADD COLUMN IF NOT EXISTS serves_verticals text[] NOT NULL DEFAULT '{}';
+
+UPDATE app.apps SET serves_verticals = ARRAY['beauty','salon','clinic','health'] WHERE id = 'beauty';
+UPDATE app.apps SET serves_verticals = ARRAY['food','restaurant']                WHERE id = 'resto';
+UPDATE app.apps SET serves_verticals = ARRAY['retail','commerce','ecommerce']    WHERE id = 'shop';
+UPDATE app.apps SET serves_verticals = ARRAY['education','school']               WHERE id = 'school';
+
+COMMENT ON COLUMN app.apps.serves_verticals IS
+  'Os ramos que este app atende. O onboarding manda um vertical; é por aqui que ele vira app, e o app diz em requires quais plugins acender.';
+
+-- ── as facets do ramo, mais os apps e os plugins que eles exigem ────────────
+CREATE OR REPLACE FUNCTION public.tenant_apply_vertical_defaults(p_tenant uuid, p_vertical text DEFAULT NULL::text)
+ RETURNS jsonb
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  v_vertical text;
+  v_row      record;
+  v_app      record;
+  v_plugin   text;
+  v_on       integer := 0;
+  v_apps     text[] := ARRAY[]::text[];
+  v_skipped  text[] := ARRAY[]::text[];
+BEGIN
+  IF p_tenant IS NULL THEN
+    RAISE EXCEPTION 'tenant_apply_vertical_defaults: no tenant' USING ERRCODE = '22023';
+  END IF;
+
+  v_vertical := coalesce(p_vertical, (SELECT t.vertical_id FROM public.tenants t WHERE t.id = p_tenant));
+  IF v_vertical IS NULL THEN
+    RETURN jsonb_build_object('tenant_id', p_tenant, 'vertical', NULL, 'enabled', 0, 'apps', '[]'::jsonb,
+                              'note', 'no vertical on this tenant - nothing to seed');
+  END IF;
+
+  -- ── as facets do ramo (160), inalteradas ─────────────────────────────────
+  FOR v_row IN
+    SELECT d.plugin_id, d.facet FROM app.vertical_defaults d WHERE d.vertical_id = v_vertical
+  LOOP
+    -- O teto vence o default, sempre: um plano que não permite significa que o
+    -- tenant não recebe aquilo aceso — não que a semeadura falhe.
+    IF NOT public.plan_permits(v_row.plugin_id, v_row.facet, p_tenant) THEN
+      v_skipped := v_skipped || (v_row.plugin_id || coalesce(nullif('.' || v_row.facet, '.'), ''));
+      CONTINUE;
+    END IF;
+
+    INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+    VALUES (p_tenant, v_row.plugin_id, v_row.facet, 'active', 'default')
+    -- Nunca sobrescreve decisão que alguém já tomou.
+    ON CONFLICT (tenant_id, plugin_id, facet) DO NOTHING;
+    IF FOUND THEN v_on := v_on + 1; END IF;
+
+    -- A facet acesa sem a linha do plugin é o defeito 2: a casca conta
+    -- `status = 'active' AND facet = ''`, então `agenda.scheduling` sozinha
+    -- acende zero agenda. Só quando o plano também permite o plugin inteiro.
+    IF v_row.facet <> '' AND public.plan_permits(v_row.plugin_id, '', p_tenant) THEN
+      INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+      VALUES (p_tenant, v_row.plugin_id, '', 'active', 'default')
+      ON CONFLICT (tenant_id, plugin_id, facet) DO NOTHING;
+    END IF;
+  END LOOP;
+
+  -- ── os apps do ramo, e os plugins que cada um exige ──────────────────────
+  FOR v_app IN
+    SELECT a.id, a.requires FROM app.apps a
+     WHERE a.active AND v_vertical = ANY (a.serves_verticals)
+  LOOP
+    -- O app entra no diretório do tenant: é o que o switcher lê.
+    INSERT INTO app.tenant_apps (tenant_id, app_id, status, source)
+    VALUES (p_tenant, v_app.id, 'active', 'default')
+    ON CONFLICT (tenant_id, app_id) DO NOTHING;
+    v_apps := v_apps || v_app.id;
+
+    FOREACH v_plugin IN ARRAY coalesce(v_app.requires, ARRAY[]::text[]) LOOP
+      IF NOT public.plan_permits(v_plugin, '', p_tenant) THEN
+        v_skipped := v_skipped || v_plugin;
+        CONTINUE;
+      END IF;
+      INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+      VALUES (p_tenant, v_plugin, '', 'active', 'default')
+      ON CONFLICT (tenant_id, plugin_id, facet) DO NOTHING;
+      IF FOUND THEN v_on := v_on + 1; END IF;
+    END LOOP;
+  END LOOP;
+
+  RETURN jsonb_build_object('tenant_id', p_tenant, 'vertical', v_vertical,
+                            'apps', to_jsonb(v_apps), 'enabled', v_on,
+                            'not_permitted_by_plan', to_jsonb(v_skipped));
+END $function$;
+
+-- ── 1. o fluxo de criação passa a semear ───────────────────────────────────
+CREATE OR REPLACE FUNCTION public.create_tenant(p_name text, p_slug text, p_kind text DEFAULT 'business'::text, p_vertical_id text DEFAULT NULL::text, p_template text DEFAULT 'generic'::text, p_settings jsonb DEFAULT '{}'::jsonb, p_hq_name text DEFAULT NULL::text)
+ RETURNS jsonb
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  v_uid        uuid := auth.uid();
+  v_tenant     uuid;
+  v_unit       uuid;
+  v_membership uuid;
+  v_owner_role uuid;
+  v_template   text;
+  v_slug       text;
+  v_name       text;
+  v_seeded     jsonb;
+BEGIN
+  IF v_uid IS NULL THEN
+    RAISE EXCEPTION 'create_tenant: the actor is derived from the session and there is no session'
+      USING ERRCODE = '42501';
+  END IF;
+  IF p_kind IS NULL OR p_kind NOT IN ('network', 'business') THEN
+    RAISE EXCEPTION 'create_tenant: kind must be network or business (got %)', coalesce(p_kind, '<null>')
+      USING ERRCODE = '22023';
+  END IF;
+  v_name := nullif(btrim(coalesce(p_name, '')), '');
+  IF v_name IS NULL THEN
+    RAISE EXCEPTION 'create_tenant: name is required' USING ERRCODE = '22023';
+  END IF;
+  v_slug := lower(btrim(coalesce(p_slug, '')));
+  IF v_slug !~ '^[a-z0-9]+([._-][a-z0-9]+)*$' OR length(v_slug) > 100 THEN
+    RAISE EXCEPTION 'create_tenant: slug must be lowercase letters and digits separated by single . _ - (got %)', coalesce(nullif(v_slug, ''), '<empty>')
+      USING ERRCODE = '22023';
+  END IF;
+  IF EXISTS (SELECT 1 FROM public.tenants t WHERE t.slug = v_slug) THEN
+    RAISE EXCEPTION 'create_tenant: slug % is already taken', v_slug USING ERRCODE = '23505';
+  END IF;
+
+  -- Template: explicit, else the vertical's own template when one exists, else generic.
+  v_template := coalesce(
+    p_template,
+    CASE WHEN p_vertical_id IS NOT NULL AND EXISTS (SELECT 1 FROM app.role_templates rt WHERE rt.template = p_vertical_id)
+         THEN p_vertical_id ELSE 'generic' END);
+  IF NOT EXISTS (SELECT 1 FROM app.role_templates rt WHERE rt.template = v_template) THEN
+    RAISE EXCEPTION 'create_tenant: unknown role template %', v_template USING ERRCODE = '22023';
+  END IF;
+
+  INSERT INTO public.tenants (name, slug, plan, vertical_id, kind, settings, role_template)
+  VALUES (v_name, v_slug, 'free', p_vertical_id, p_kind, coalesce(p_settings, '{}'::jsonb), v_template)
+  RETURNING id INTO v_tenant;
+
+  v_owner_role := app.seed_role_template(v_tenant, v_template);
+
+  INSERT INTO app.units (tenant_id, kind, name, slug, active)
+  VALUES (v_tenant, 'hq', coalesce(nullif(btrim(coalesce(p_hq_name, '')), ''), v_name), 'hq', true)
+  RETURNING id INTO v_unit;
+
+  -- The owner: role from the template (holds the whole catalog), every unit.
+  INSERT INTO app.memberships (tenant_id, user_id, role_id, all_units, active)
+  VALUES (v_tenant, v_uid, v_owner_role, true, true)
+  RETURNING id INTO v_membership;
+
+  -- Os plugins do ramo. Mesma transação de propósito: um tenant que existe sem
+  -- plugin nenhum abre uma casca vazia, e quem cria acha que perdeu o que
+  -- digitou. Sem vertical (ou vertical desconhecido) devolve enabled 0 e segue
+  -- — nascer sem ramo é legítimo, nascer pela metade não.
+  v_seeded := public.tenant_apply_vertical_defaults(v_tenant, p_vertical_id);
+
+  RETURN jsonb_build_object(
+    'tenant',     (SELECT to_jsonb(t) FROM public.tenants t WHERE t.id = v_tenant),
+    'hq_unit',    (SELECT to_jsonb(u) FROM app.units u WHERE u.id = v_unit),
+    'membership', (SELECT to_jsonb(m) FROM app.memberships m WHERE m.id = v_membership),
+    'plugins',    v_seeded
+  );
+END $function$;

package/migrations/011_leadcontrol_joins_the_family.sql

@@ -0,0 +1,116 @@
+-- ---------------------------------------------------------------------------
+-- 011_leadcontrol_joins_the_family.sql — the sales app gets a row.
+--
+-- The registry has held four products since 001, and every one of them is a
+-- TRADE: a kitchen, a shop, a studio, a school. LeadControl is the first that
+-- is not. Nobody's business is "sales" — every one of those four sells, and
+-- until now the place they did it was a tab inside the app they run their trade
+-- from (the CRM row in StudioControl, the leads the school never had a screen
+-- for). That is why this row exists: the pipeline outgrew being a tab.
+--
+-- Two consequences follow from that, and they are the whole content of this
+-- file beyond the INSERT.
+--
+-- ── 1. `serves_verticals` stays EMPTY, deliberately ─────────────────────────
+--
+-- 010 made that column the trigger for automatic seeding: a tenant declaring a
+-- vertical gets every app that serves it. Listing all seven verticals here
+-- would be true — everybody sells — and would also mean every restaurant
+-- created from tomorrow silently grows a second product in its switcher that
+-- nobody asked for and nobody set up. An app that arrives uninvited is not a
+-- feature, it is a support ticket about an empty inbox.
+--
+-- So this one is opt-in: `tenant_app_set('crm', ...)`, called by a person or by
+-- onboarding when the account says it wants it. §3 below does exactly that for
+-- the accounts where the evidence is already in the database.
+--
+-- ── 2. `requires` names four plugins, not one ───────────────────────────────
+--
+-- The other rows require the plugins that draw their trade. This one requires
+-- the four that make a lead worth capturing: `crm` holds the lead and the deal,
+-- `conversations` is where the lead first speaks, `marketing` says which
+-- channel it came from, `automations` is what answers while nobody is looking.
+-- A LeadControl with only `crm` on is a list of names.
+--
+-- Note what is NOT there: `financial`. A won deal in this product hands off to
+-- whichever app owns the money — that is the point of one tenant running
+-- several apps, and duplicating the ledger here would give the same invoice two
+-- front doors.
+-- ---------------------------------------------------------------------------
+
+-- ── §1  the registry row ───────────────────────────────────────────────────
+--
+-- The name is the OUTWARD name (ADR: "Control" is the family, not the app).
+-- The rail inside says only "Lead"; the switcher's list is outward, so it
+-- carries the whole thing.
+--
+-- `#2563EB` and not another blue: the tile IS the product in a launcher, and
+-- the four colours already spoken for are red (Chef), green (Store), violet
+-- (Studio) and amber (Escola).
+--
+-- `url` is the dev origin, as it is for every other row. A cluster that
+-- publishes these apps elsewhere updates the row; nothing in code hardcodes a
+-- port.
+INSERT INTO app.apps (id, name, icon, accent_color, url, requires, serves_verticals) VALUES
+  ('crm', 'LeadControl', 'Target', '#2563EB', 'http://localhost:5307',
+   ARRAY['crm', 'conversations', 'marketing', 'automations'],
+   ARRAY[]::text[])
+ON CONFLICT (id) DO UPDATE
+  SET name = EXCLUDED.name, icon = EXCLUDED.icon, accent_color = EXCLUDED.accent_color,
+      url = EXCLUDED.url, requires = EXCLUDED.requires;
+
+COMMENT ON TABLE app.apps IS
+  'Which applications exist on this cluster (001, 011). The registry the app switcher reads. An app is a LENS over a tenant''s rows — it never scopes them; two apps on one tenant share public.people by design. `requires` names the plugins the app cannot work without; `url` doubles as the allow-list for the session handoff. `serves_verticals` empty means opt-in: the app is never seeded by a tenant''s trade, only by someone asking for it.';
+
+-- ── §2  the plugins it stands on must be activatable ───────────────────────
+--
+-- `requires` is honoured by tenant_app_set() and by tenant_apply_vertical_defaults(),
+-- both of which walk the array and INSERT into app.tenant_plugins. Nothing here
+-- needs to change for that to work — this comment exists because the first
+-- reading of "requires" is "a dependency check", and it is not one: it is a
+-- SEEDING list. Removing the app never removes them, because another app on the
+-- same tenant may be standing on the same plugin (StudioControl requires `crm`
+-- too, and always has).
+
+-- ── §3  who gets it now ────────────────────────────────────────────────────
+--
+-- Every tenant that already has the CRM plugin active. That is the honest
+-- evidence in the database that this account is already doing the work this app
+-- is for — they have been doing it inside another product's tab, which is the
+-- situation the row in §1 exists to end.
+--
+-- `source = 'default'` and not 'manual': nobody clicked. It marks these rows as
+-- something the platform decided, so a later screen can tell them apart from
+-- the ones an administrator chose.
+--
+-- Deliberately NOT a trigger, for the reason 001 §7 gives: vertical_id applied
+-- once at INSERT and never revisited is the defect that file exists to end, and
+-- a trigger here would reproduce it one table over.
+INSERT INTO app.tenant_apps (tenant_id, app_id, status, source)
+SELECT DISTINCT tp.tenant_id, 'crm', 'active', 'default'
+  FROM app.tenant_plugins tp
+ WHERE tp.plugin_id = 'crm'
+   AND tp.facet = ''
+   AND tp.status = 'active'
+ON CONFLICT (tenant_id, app_id) DO NOTHING;
+
+-- And the plugins LeadControl needs, for exactly those tenants — otherwise the
+-- app opens on a rail with a Dashboard and nothing else, because the shell
+-- builds the rail from what app_config() returns in `plugins`.
+--
+-- DISTINCT, because a tenant reaching this from two directions (the CRM row
+-- above and an app that already required the same plugin) would make
+-- ON CONFLICT DO UPDATE refuse to touch the row twice. Here it is DO NOTHING,
+-- so the hazard is only latent — but the next person to change the conflict
+-- action should not have to rediscover it.
+INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+SELECT DISTINCT ta.tenant_id, r.plugin_id, '', 'active', 'default'
+  FROM app.tenant_apps ta
+  JOIN app.apps a ON a.id = ta.app_id
+  CROSS JOIN LATERAL unnest(a.requires) AS r(plugin_id)
+ WHERE ta.app_id = 'crm'
+   AND ta.status = 'active'
+   -- The plan ceiling wins over a default, always: an account whose plan does
+   -- not include the plugin does not get it lit — the seeding does not fail.
+   AND public.plan_permits(r.plugin_id, '', ta.tenant_id)
+ON CONFLICT (tenant_id, plugin_id, facet) DO NOTHING;

package/migrations/012_chefcontrol_wears_its_own_mark.sql

@@ -0,0 +1,28 @@
+-- ---------------------------------------------------------------------------
+-- 012_chefcontrol_wears_its_own_mark.sql — the launcher stops drawing a
+-- stand-in for a product that has a brand.
+--
+-- 001 seeded ChefControl with lucide's `ChefHat` on red, because in 001 the
+-- product had no mark of its own. It has one now (brand book v4.0, §3.0), and
+-- the switcher is the ONE screen where the four products stand side by side —
+-- so it is also the one screen where a stand-in glyph is legible as "this app
+-- was never branded". The mark ships in @fayz-ai/ui's icon registry
+-- (packages/ui/src/brand-marks.tsx) under the name this row now carries, so
+-- every sibling app draws the Chef row the same way, from StoreControl's window
+-- as from Chef's own.
+--
+-- The colour moves with it: #FBAC00 is the family's gold, the only colour the
+-- brand book gives ChefControl, and the red it replaces was a placeholder
+-- picked to be distinguishable from green and violet rather than to be the
+-- product. The tile's ink is no longer hardcoded white on the client — a gold
+-- tile is a LIGHT ground and takes charcoal — so the row keeps its contrast
+-- without a second row of colour data to maintain here.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps
+   SET icon = 'ChefControlMark',
+       accent_color = '#FBAC00'
+ WHERE id = 'resto';
+
+COMMENT ON COLUMN app.apps.icon IS
+  'The name the client resolves this app''s glyph by (001, 012). Usually a lucide name; for a product with a mark of its own it is that mark''s name in @fayz-ai/ui''s registry (e.g. ChefControlMark). A name the registry does not know falls back to the app''s initials, never to a broken tile.';