@kontrolia/db 2.1.0 → 2.1.2

package/migrations/0024_extend_audit_triggers.sql

@@ -0,0 +1,77 @@
+-- Suspending/reactivating a member (organization-members PATCH) and
+-- revoking or resending an invitation (admin-panel's Invitaciones page)
+-- previously left no audit trail: the membership trigger only ran on
+-- INSERT/DELETE (0013), and invitations had no DELETE trigger at all.
+-- Extends both to keep 0013's own promise — "the database logs it, not
+-- application code" — up to date with what the UI can now do.
+
+create or replace function kontrolia_auth.log_membership_change()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+begin
+  if tg_op = 'INSERT' then
+    insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+    values (new.organization_id, coalesce(auth.uid(), new.user_id), 'membership.created', 'membership', new.id::text, jsonb_build_object('user_id', new.user_id, 'status', new.status));
+    return new;
+  elsif tg_op = 'UPDATE' then
+    if old.status is distinct from new.status then
+      insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+      values (new.organization_id, auth.uid(), 'membership.status_changed', 'membership', new.id::text, jsonb_build_object('user_id', new.user_id, 'from_status', old.status, 'to_status', new.status));
+    end if;
+    return new;
+  else
+    if exists (select 1 from kontrolia_auth.organizations where id = old.organization_id) then
+      insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+      values (old.organization_id, auth.uid(), 'membership.removed', 'membership', old.id::text, jsonb_build_object('user_id', old.user_id));
+    end if;
+    return old;
+  end if;
+end;
+$$;
+
+drop trigger if exists audit_membership_change on kontrolia_auth.memberships;
+create trigger audit_membership_change
+  after insert or update or delete on kontrolia_auth.memberships
+  for each row execute function kontrolia_auth.log_membership_change();
+
+create or replace function kontrolia_auth.log_invitation_deleted()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+begin
+  if exists (select 1 from kontrolia_auth.organizations where id = old.organization_id) then
+    insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+    values (old.organization_id, auth.uid(), 'invitation.revoked', 'invitation', old.id::text, jsonb_build_object('email', old.email));
+  end if;
+  return old;
+end;
+$$;
+
+create trigger audit_invitation_deleted
+  after delete on kontrolia_auth.invitations
+  for each row execute function kontrolia_auth.log_invitation_deleted();
+
+-- Resend (extend expires_at on a still-pending invitation) shares the same
+-- AFTER UPDATE trigger slot as "accepted" — one function, two cases.
+create or replace function kontrolia_auth.log_invitation_accepted()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+begin
+  if old.accepted_at is null and new.accepted_at is not null then
+    insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+    values (new.organization_id, auth.uid(), 'invitation.accepted', 'invitation', new.id::text, jsonb_build_object('email', new.email));
+  elsif new.accepted_at is null and old.expires_at is distinct from new.expires_at then
+    insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+    values (new.organization_id, auth.uid(), 'invitation.resent', 'invitation', new.id::text, jsonb_build_object('email', new.email, 'new_expires_at', new.expires_at));
+  end if;
+  return new;
+end;
+$$;

package/migrations/0025_prevent_last_owner_role_removal.sql

@@ -0,0 +1,57 @@
+-- wouldRemoveLastOwner() (organization-members API route) already stops a
+-- caller from suspending/removing the org's only active Owner — but that
+-- guard lives at the API-route layer, not the DB layer. The RLS policy
+-- actually governing kontrolia_auth.membership_roles ("org admins manage
+-- membership roles", 0010) is a bare is_org_admin() check with no owner
+-- protection at all, so any org Admin can DELETE the sole Owner's role
+-- row directly and reproduce the exact same lockout through a door the
+-- API-layer fix never covered. Enforce it where it can't be bypassed: in
+-- the database, on every DELETE, regardless of which code path issued it.
+
+create or replace function kontrolia_auth.prevent_last_owner_role_removal()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_organization_id uuid;
+  v_role_slug text;
+  v_active_owner_count int;
+begin
+  select organization_id into v_organization_id
+  from kontrolia_auth.memberships
+  where id = old.membership_id;
+
+  -- Membership already gone (e.g. cascaded from an org delete, or from a
+  -- membership delete the API route already validated before issuing) —
+  -- nothing left to protect. Mirrors 0023's org-delete cascade guard.
+  if v_organization_id is null or not exists (select 1 from kontrolia_auth.organizations where id = v_organization_id) then
+    return old;
+  end if;
+
+  select slug into v_role_slug from kontrolia_auth.roles where id = old.role_id;
+
+  if v_role_slug is distinct from 'owner' then
+    return old;
+  end if;
+
+  select count(*) into v_active_owner_count
+  from kontrolia_auth.membership_roles mr
+  join kontrolia_auth.memberships m on m.id = mr.membership_id
+  join kontrolia_auth.roles r on r.id = mr.role_id
+  where m.organization_id = v_organization_id
+    and m.status = 'active'
+    and r.slug = 'owner';
+
+  if v_active_owner_count <= 1 then
+    raise exception 'No puedes quitar el rol de Owner al único Owner activo de la organización.';
+  end if;
+
+  return old;
+end;
+$$;
+
+create trigger prevent_last_owner_role_removal
+  before delete on kontrolia_auth.membership_roles
+  for each row execute function kontrolia_auth.prevent_last_owner_role_removal();

package/migrations/0026_prevent_last_owner_membership_removal.sql

@@ -0,0 +1,111 @@
+-- 0025 closed the last-owner lockout for one specific vector — deleting the
+-- membership_roles row directly. Same-day re-audit found the identical
+-- outcome (an org left with zero active Owners) still reachable through two
+-- sibling doors on kontrolia_auth.memberships itself, neither guarded by
+-- any DB-level check: a direct DELETE of the membership row (RLS policy
+-- "org admins remove memberships" is a bare is_org_admin() check), and a
+-- direct UPDATE of its status to anything other than 'active' (RLS policy
+-- "org admins update memberships", same bare check — this is the exact
+-- suspend-to-zero-Owners bug already fixed once at the API layer in
+-- 4579870, reachable again via raw PostgREST). Close both at the table
+-- that actually matters, the same way 0025 closed membership_roles.
+
+create or replace function kontrolia_auth.prevent_last_owner_membership_removal()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_is_owner boolean;
+  v_active_owner_count int;
+begin
+  -- Cascaded from the organization's own deletion — nothing left to
+  -- protect, and blocking here would make "delete organization" itself
+  -- impossible. Mirrors 0023/0025's cascade-safety guard.
+  if not exists (select 1 from kontrolia_auth.organizations where id = old.organization_id) then
+    return old;
+  end if;
+
+  -- A membership that wasn't active wasn't counted among active Owners
+  -- anyway, so removing it can't be what drops the count to zero.
+  if old.status is distinct from 'active' then
+    return old;
+  end if;
+
+  select exists (
+    select 1
+    from kontrolia_auth.membership_roles mr
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where mr.membership_id = old.id and r.slug = 'owner'
+  ) into v_is_owner;
+
+  if not v_is_owner then
+    return old;
+  end if;
+
+  select count(*) into v_active_owner_count
+  from kontrolia_auth.membership_roles mr
+  join kontrolia_auth.memberships m on m.id = mr.membership_id
+  join kontrolia_auth.roles r on r.id = mr.role_id
+  where m.organization_id = old.organization_id
+    and m.status = 'active'
+    and r.slug = 'owner';
+
+  if v_active_owner_count <= 1 then
+    raise exception 'No puedes quitar al único Owner activo de la organización.';
+  end if;
+
+  return old;
+end;
+$$;
+
+create trigger prevent_last_owner_membership_delete
+  before delete on kontrolia_auth.memberships
+  for each row execute function kontrolia_auth.prevent_last_owner_membership_removal();
+
+create or replace function kontrolia_auth.prevent_last_owner_deactivation()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_is_owner boolean;
+  v_active_owner_count int;
+begin
+  -- Only relevant when a membership is moving OUT of active status.
+  if old.status is distinct from 'active' or new.status = 'active' then
+    return new;
+  end if;
+
+  select exists (
+    select 1
+    from kontrolia_auth.membership_roles mr
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where mr.membership_id = old.id and r.slug = 'owner'
+  ) into v_is_owner;
+
+  if not v_is_owner then
+    return new;
+  end if;
+
+  select count(*) into v_active_owner_count
+  from kontrolia_auth.membership_roles mr
+  join kontrolia_auth.memberships m on m.id = mr.membership_id
+  join kontrolia_auth.roles r on r.id = mr.role_id
+  where m.organization_id = old.organization_id
+    and m.status = 'active'
+    and r.slug = 'owner';
+
+  if v_active_owner_count <= 1 then
+    raise exception 'No puedes suspender al único Owner activo de la organización.';
+  end if;
+
+  return new;
+end;
+$$;
+
+create trigger prevent_last_owner_deactivation
+  before update on kontrolia_auth.memberships
+  for each row execute function kontrolia_auth.prevent_last_owner_deactivation();

package/migrations/0027_prevent_last_owner_org_reassignment.sql

@@ -0,0 +1,56 @@
+-- 0026's UPDATE trigger only inspected `status`, never `organization_id` —
+-- a caller with admin rights in the Owner's org AND the destination org
+-- (the RLS policy's implicit WITH CHECK, reusing USING since none is
+-- declared, already requires both) could move the sole active Owner's
+-- membership to a different organization while leaving status untouched,
+-- leaving the source org with zero active Owners the same way a status
+-- flip to 'suspended' would. Narrower precondition than 0026's two fixes
+-- (needs dual-org admin, not just single-org), but the same bug class —
+-- extend the same trigger rather than leave it half-covering "leaving
+-- active status" as the only way to lose the last Owner.
+
+create or replace function kontrolia_auth.prevent_last_owner_deactivation()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_is_owner boolean;
+  v_active_owner_count int;
+  v_leaving_org boolean;
+begin
+  -- "Leaving" now covers both ways a membership stops counting toward its
+  -- (original) org's active Owners: no longer active, or reassigned away.
+  v_leaving_org := (new.organization_id is distinct from old.organization_id) or (new.status is distinct from 'active');
+
+  if old.status is distinct from 'active' or not v_leaving_org then
+    return new;
+  end if;
+
+  select exists (
+    select 1
+    from kontrolia_auth.membership_roles mr
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where mr.membership_id = old.id and r.slug = 'owner'
+  ) into v_is_owner;
+
+  if not v_is_owner then
+    return new;
+  end if;
+
+  select count(*) into v_active_owner_count
+  from kontrolia_auth.membership_roles mr
+  join kontrolia_auth.memberships m on m.id = mr.membership_id
+  join kontrolia_auth.roles r on r.id = mr.role_id
+  where m.organization_id = old.organization_id
+    and m.status = 'active'
+    and r.slug = 'owner';
+
+  if v_active_owner_count <= 1 then
+    raise exception 'No puedes quitar al único Owner activo de la organización.';
+  end if;
+
+  return new;
+end;
+$$;

package/migrations/0028_restrict_owner_grant_and_membership_identity.sql

@@ -0,0 +1,70 @@
+-- Fourth same-day Phase 2 audit found two CRITICALs that fully defeat every
+-- last-owner protection added today (0025-0027), because those all guard
+-- operations against an *existing* Owner's own row — none of them restrict
+-- who can become an Owner in the first place, or what a membership row's
+-- identity means. Both are day-one gaps in migration 0010's RLS policies,
+-- live-exploited this session by a plain org Admin (no dual-org privilege
+-- needed, unlike 0027's narrower finding):
+--
+-- 1. "org admins manage membership roles" is a bare is_org_admin() check
+--    with no restriction on which role_id may be inserted — any Admin can
+--    grant themselves (or anyone) the 'owner' role directly, then use the
+--    now-legitimate 2-owner path to suspend the real Owner.
+-- 2. "org admins update memberships" permits changing ANY column,
+--    including user_id, as long as organization_id is unchanged — an Admin
+--    can silently reassign the sole Owner's membership row to an arbitrary
+--    third-party user, and since the audit trigger only fires on status
+--    changes, this leaves zero trail.
+--
+-- No legitimate code path in this app ever updates memberships.user_id
+-- (grepped: the only UPDATE anywhere is the status PATCH in
+-- organization-members/route.ts) — a membership's identity is created once
+-- via invitation-accept or org-bootstrap and never reassigned, so blocking
+-- any change to it entirely, for every membership, is safe.
+
+create or replace function kontrolia_auth.prevent_admin_granting_owner_role()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_role_slug text;
+  v_organization_id uuid;
+begin
+  select slug into v_role_slug from kontrolia_auth.roles where id = new.role_id;
+  if v_role_slug is distinct from 'owner' then
+    return new;
+  end if;
+
+  select organization_id into v_organization_id from kontrolia_auth.memberships where id = new.membership_id;
+
+  if not kontrolia_auth.is_org_owner(v_organization_id) then
+    raise exception 'Solo un Owner puede otorgar el rol de Owner.';
+  end if;
+
+  return new;
+end;
+$$;
+
+create trigger prevent_admin_granting_owner_role
+  before insert on kontrolia_auth.membership_roles
+  for each row execute function kontrolia_auth.prevent_admin_granting_owner_role();
+
+create or replace function kontrolia_auth.prevent_membership_identity_change()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+begin
+  if new.user_id is distinct from old.user_id then
+    raise exception 'No se puede reasignar la identidad de una membresía existente.';
+  end if;
+  return new;
+end;
+$$;
+
+create trigger prevent_membership_identity_change
+  before update on kontrolia_auth.memberships
+  for each row execute function kontrolia_auth.prevent_membership_identity_change();

package/migrations/0029_membership_roles_update_guard.sql

@@ -0,0 +1,108 @@
+-- Fifth same-day Phase 2 audit found kontrolia_auth.membership_roles had no
+-- trigger on UPDATE at all — 0025 guards DELETE and 0028 guards INSERT, but
+-- role_id (part of the table's own primary key) could be changed directly
+-- via a plain UPDATE, sidestepping both guards entirely: self-promote to
+-- Owner, demote the sole active Owner, or hijack an existing Owner row
+-- outright, all live-exploited this session by a plain org Admin.
+--
+-- The same audit also found a functional regression 0028 introduced:
+-- is_org_owner() depends on auth.uid(), which is NULL under the
+-- service-role connection apps/auth-server/app/api/invitations/accept/
+-- route.ts uses to grant an invited role — so accepting any invitation
+-- offering the 'owner' role now silently fails its role grant, for every
+-- organization. Service-role connections are already the top of this app's
+-- trust chain (RLS doesn't even apply to them, via BYPASSRLS) — govern them
+-- by application code review the same way the rest of the schema already
+-- does, not by re-deriving auth.uid() a service-role session never has.
+--
+-- Detecting that trust boundary needs auth.role() (reads the
+-- request.jwt.claims GUC), not current_user: these trigger functions are
+-- `security definer`, so current_user inside the function body reports the
+-- function's OWNER, not the caller — confirmed by direct experimentation
+-- against this migration's first draft, which used current_user and still
+-- blocked the legitimate service-role grant.
+
+create or replace function kontrolia_auth.prevent_admin_granting_owner_role()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_role_slug text;
+  v_organization_id uuid;
+begin
+  if auth.role() = 'service_role' then
+    return new;
+  end if;
+
+  select slug into v_role_slug from kontrolia_auth.roles where id = new.role_id;
+  if v_role_slug is distinct from 'owner' then
+    return new;
+  end if;
+
+  select organization_id into v_organization_id from kontrolia_auth.memberships where id = new.membership_id;
+
+  if not kontrolia_auth.is_org_owner(v_organization_id) then
+    raise exception 'Solo un Owner puede otorgar el rol de Owner.';
+  end if;
+
+  return new;
+end;
+$$;
+
+create or replace function kontrolia_auth.prevent_membership_role_update()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_organization_id uuid;
+  v_old_slug text;
+  v_new_slug text;
+  v_active_owner_count int;
+begin
+  -- No legitimate flow ever reassigns a role_id row to a different
+  -- membership — same reasoning as 0028's blanket ban on
+  -- memberships.user_id. Unlike the owner-grant/removal checks below,
+  -- there's no service-role exception: nothing legitimate does this either.
+  if new.membership_id is distinct from old.membership_id then
+    raise exception 'No se puede reasignar un rol de membresía a otra membresía.';
+  end if;
+
+  -- A true no-op UPDATE (e.g. an ON CONFLICT DO UPDATE upsert that hit an
+  -- already-identical row, as invitation-accept's upsert can) changes
+  -- nothing here — skip straight through rather than re-running checks
+  -- against a role that never actually changed.
+  if old.role_id is distinct from new.role_id and auth.role() is distinct from 'service_role' then
+    select slug into v_old_slug from kontrolia_auth.roles where id = old.role_id;
+    select slug into v_new_slug from kontrolia_auth.roles where id = new.role_id;
+    select organization_id into v_organization_id from kontrolia_auth.memberships where id = old.membership_id;
+
+    if v_new_slug = 'owner' and not kontrolia_auth.is_org_owner(v_organization_id) then
+      raise exception 'Solo un Owner puede otorgar el rol de Owner.';
+    end if;
+
+    if v_old_slug = 'owner' and v_new_slug is distinct from 'owner' then
+      select count(*) into v_active_owner_count
+      from kontrolia_auth.membership_roles mr
+      join kontrolia_auth.memberships m on m.id = mr.membership_id
+      join kontrolia_auth.roles r on r.id = mr.role_id
+      where m.organization_id = v_organization_id
+        and m.status = 'active'
+        and r.slug = 'owner';
+
+      if v_active_owner_count <= 1 then
+        raise exception 'No puedes quitar el rol de Owner al único Owner activo de la organización.';
+      end if;
+    end if;
+  end if;
+
+  return new;
+end;
+$$;
+
+create trigger prevent_membership_role_update
+  before update on kontrolia_auth.membership_roles
+  for each row execute function kontrolia_auth.prevent_membership_role_update();

package/migrations/0030_anchor_authority_to_system_roles.sql

@@ -0,0 +1,392 @@
+-- Sixth same-day audit found the real root cause underlying every
+-- last-owner fix today (0025-0029): is_org_owner()/is_org_admin() only
+-- ever checked roles.slug — a column no trigger and no RLS policy on
+-- kontrolia_auth.roles actually protects. "org admins can update custom
+-- roles" (0019) never inspects slug at all. Any org Admin could create an
+-- ordinary custom role, grant it to themselves, then UPDATE its slug to
+-- 'owner', becoming recognized as Owner by every check in the system —
+-- live-exploited this session, a complete bypass of migrations 0025-0029
+-- through a table none of them touch.
+--
+-- The actual invariant that matters isn't the slug string, it's
+-- is_system_role: 0019's INSERT/UPDATE policies on kontrolia_auth.roles
+-- already guarantee a custom role can never be created with, or updated
+-- to, is_system_role = true (the policies' implicit WITH CHECK — reusing
+-- USING, since neither specifies one — requires "not is_system_role" on
+-- the row both before AND after the write). That flag is only ever set by
+-- the original global-role seed data and the SECURITY DEFINER
+-- handle_application_enabled() trigger (0019), both outside any
+-- RLS-writable path. Anchor every authority check to that flag instead of
+-- the freely-writable slug string it was never actually protecting.
+
+create or replace function kontrolia_auth.is_org_admin(org_id uuid)
+returns boolean
+language sql
+stable
+security definer
+set search_path = ''
+as $$
+  select exists (
+    select 1
+    from kontrolia_auth.memberships m
+    join kontrolia_auth.membership_roles mr on mr.membership_id = m.id
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where m.organization_id = org_id
+      and m.user_id = auth.uid()
+      and m.status = 'active'
+      and r.is_system_role
+      and r.slug in ('owner', 'admin')
+  );
+$$;
+
+create or replace function kontrolia_auth.is_org_owner(org_id uuid)
+returns boolean
+language sql
+stable
+security definer
+set search_path = ''
+as $$
+  select exists (
+    select 1
+    from kontrolia_auth.memberships m
+    join kontrolia_auth.membership_roles mr on mr.membership_id = m.id
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where m.organization_id = org_id
+      and m.user_id = auth.uid()
+      and m.status = 'active'
+      and r.is_system_role
+      and r.slug = 'owner'
+  );
+$$;
+
+-- Same gap in the JWT's "roles" claim: a hijacked custom role's slug
+-- would show up as "owner"/"admin" in the token itself, fooling any
+-- client-side hasRole(['owner']) UI gate even though the DB-level fix
+-- above already stops it from granting any real privilege. Restricting
+-- this to system roles only doesn't remove any real capability — no
+-- caller in this codebase checks hasRole() against a custom role's slug
+-- (grepped: only 'owner'/'admin' are ever checked), and a custom role's
+-- actual permissions are still fully exposed via the separate
+-- "permissions" claim below, unaffected.
+create or replace function kontrolia_auth.custom_access_token_hook(event jsonb)
+returns jsonb
+language plpgsql
+stable
+security definer
+set search_path = ''
+as $$
+declare
+  claims jsonb;
+  target_user_id uuid;
+  active_org_id uuid;
+  active_membership_id uuid;
+  role_names text[];
+  permission_keys text[];
+begin
+  claims := coalesce(event->'claims', '{}'::jsonb);
+  target_user_id := (event->>'user_id')::uuid;
+
+  select active_organization_id into active_org_id
+  from kontrolia_auth.sessions_context
+  where user_id = target_user_id;
+
+  if active_org_id is null then
+    select organization_id into active_org_id
+    from kontrolia_auth.memberships
+    where user_id = target_user_id and status = 'active'
+    order by created_at asc
+    limit 1;
+  end if;
+
+  if active_org_id is not null then
+    select id into active_membership_id
+    from kontrolia_auth.memberships
+    where user_id = target_user_id
+      and organization_id = active_org_id
+      and status = 'active';
+  end if;
+
+  if active_membership_id is not null then
+    select coalesce(array_agg(distinct r.slug), '{}')
+      into role_names
+    from kontrolia_auth.membership_roles mr
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where mr.membership_id = active_membership_id and r.is_system_role;
+
+    select coalesce(array_agg(distinct p.key), '{}')
+      into permission_keys
+    from (
+      select p.id, p.key
+      from kontrolia_auth.membership_roles mr
+      join kontrolia_auth.role_permissions rp on rp.role_id = mr.role_id
+      join kontrolia_auth.permissions p on p.id = rp.permission_id
+      where mr.membership_id = active_membership_id
+      union
+      select p.id, p.key
+      from kontrolia_auth.user_permissions up
+      join kontrolia_auth.permissions p on p.id = up.permission_id
+      where up.membership_id = active_membership_id and up.effect = 'allow'
+    ) p
+    where not exists (
+      select 1 from kontrolia_auth.user_permissions up_deny
+      where up_deny.membership_id = active_membership_id
+        and up_deny.permission_id = p.id
+        and up_deny.effect = 'deny'
+    );
+  else
+    role_names := '{}';
+    permission_keys := '{}';
+  end if;
+
+  claims := jsonb_set(claims, '{organization_id}', coalesce(to_jsonb(active_org_id), 'null'::jsonb));
+  claims := jsonb_set(claims, '{roles}', to_jsonb(coalesce(role_names, '{}')));
+  claims := jsonb_set(claims, '{permissions}', to_jsonb(coalesce(permission_keys, '{}')));
+
+  event := jsonb_set(event, '{claims}', claims);
+  return event;
+end;
+$$;
+
+-- The last-owner "how many active Owners remain" counting queries in
+-- 0025-0029 have the exact same blind-slug-trust gap: a hijacked custom
+-- role sitting in membership_roles with slug = 'owner' would inflate the
+-- count, letting the real Owner be removed right alongside it — live-
+-- chained and exploited this session. Add "and r.is_system_role" to every
+-- one of them, redefining each function in place (same names/triggers,
+-- only the queries change).
+
+create or replace function kontrolia_auth.prevent_last_owner_role_removal()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_organization_id uuid;
+  v_role_slug text;
+  v_is_system_role boolean;
+  v_active_owner_count int;
+begin
+  select organization_id into v_organization_id
+  from kontrolia_auth.memberships
+  where id = old.membership_id;
+
+  if v_organization_id is null or not exists (select 1 from kontrolia_auth.organizations where id = v_organization_id) then
+    return old;
+  end if;
+
+  select slug, is_system_role into v_role_slug, v_is_system_role from kontrolia_auth.roles where id = old.role_id;
+
+  if v_role_slug is distinct from 'owner' or not v_is_system_role then
+    return old;
+  end if;
+
+  select count(*) into v_active_owner_count
+  from kontrolia_auth.membership_roles mr
+  join kontrolia_auth.memberships m on m.id = mr.membership_id
+  join kontrolia_auth.roles r on r.id = mr.role_id
+  where m.organization_id = v_organization_id
+    and m.status = 'active'
+    and r.slug = 'owner'
+    and r.is_system_role;
+
+  if v_active_owner_count <= 1 then
+    raise exception 'No puedes quitar el rol de Owner al único Owner activo de la organización.';
+  end if;
+
+  return old;
+end;
+$$;
+
+create or replace function kontrolia_auth.prevent_last_owner_membership_removal()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_is_owner boolean;
+  v_active_owner_count int;
+begin
+  if not exists (select 1 from kontrolia_auth.organizations where id = old.organization_id) then
+    return old;
+  end if;
+
+  if old.status is distinct from 'active' then
+    return old;
+  end if;
+
+  select exists (
+    select 1
+    from kontrolia_auth.membership_roles mr
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where mr.membership_id = old.id and r.slug = 'owner' and r.is_system_role
+  ) into v_is_owner;
+
+  if not v_is_owner then
+    return old;
+  end if;
+
+  select count(*) into v_active_owner_count
+  from kontrolia_auth.membership_roles mr
+  join kontrolia_auth.memberships m on m.id = mr.membership_id
+  join kontrolia_auth.roles r on r.id = mr.role_id
+  where m.organization_id = old.organization_id
+    and m.status = 'active'
+    and r.slug = 'owner'
+    and r.is_system_role;
+
+  if v_active_owner_count <= 1 then
+    raise exception 'No puedes quitar al único Owner activo de la organización.';
+  end if;
+
+  return old;
+end;
+$$;
+
+create or replace function kontrolia_auth.prevent_last_owner_deactivation()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_is_owner boolean;
+  v_active_owner_count int;
+  v_leaving_org boolean;
+begin
+  v_leaving_org := (new.organization_id is distinct from old.organization_id) or (new.status is distinct from 'active');
+
+  if old.status is distinct from 'active' or not v_leaving_org then
+    return new;
+  end if;
+
+  select exists (
+    select 1
+    from kontrolia_auth.membership_roles mr
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where mr.membership_id = old.id and r.slug = 'owner' and r.is_system_role
+  ) into v_is_owner;
+
+  if not v_is_owner then
+    return new;
+  end if;
+
+  select count(*) into v_active_owner_count
+  from kontrolia_auth.membership_roles mr
+  join kontrolia_auth.memberships m on m.id = mr.membership_id
+  join kontrolia_auth.roles r on r.id = mr.role_id
+  where m.organization_id = old.organization_id
+    and m.status = 'active'
+    and r.slug = 'owner'
+    and r.is_system_role;
+
+  if v_active_owner_count <= 1 then
+    raise exception 'No puedes quitar al único Owner activo de la organización.';
+  end if;
+
+  return new;
+end;
+$$;
+
+create or replace function kontrolia_auth.prevent_admin_granting_owner_role()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_role_slug text;
+  v_is_system_role boolean;
+  v_organization_id uuid;
+begin
+  if auth.role() = 'service_role' then
+    return new;
+  end if;
+
+  select slug, is_system_role into v_role_slug, v_is_system_role from kontrolia_auth.roles where id = new.role_id;
+  if v_role_slug is distinct from 'owner' or not v_is_system_role then
+    return new;
+  end if;
+
+  select organization_id into v_organization_id from kontrolia_auth.memberships where id = new.membership_id;
+
+  if not kontrolia_auth.is_org_owner(v_organization_id) then
+    raise exception 'Solo un Owner puede otorgar el rol de Owner.';
+  end if;
+
+  return new;
+end;
+$$;
+
+create or replace function kontrolia_auth.prevent_membership_role_update()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_organization_id uuid;
+  v_old_slug text;
+  v_old_is_system boolean;
+  v_new_slug text;
+  v_new_is_system boolean;
+  v_active_owner_count int;
+begin
+  if new.membership_id is distinct from old.membership_id then
+    raise exception 'No se puede reasignar un rol de membresía a otra membresía.';
+  end if;
+
+  if old.role_id is distinct from new.role_id and auth.role() is distinct from 'service_role' then
+    select slug, is_system_role into v_old_slug, v_old_is_system from kontrolia_auth.roles where id = old.role_id;
+    select slug, is_system_role into v_new_slug, v_new_is_system from kontrolia_auth.roles where id = new.role_id;
+    select organization_id into v_organization_id from kontrolia_auth.memberships where id = old.membership_id;
+
+    if v_new_slug = 'owner' and v_new_is_system and not kontrolia_auth.is_org_owner(v_organization_id) then
+      raise exception 'Solo un Owner puede otorgar el rol de Owner.';
+    end if;
+
+    if v_old_slug = 'owner' and v_old_is_system and (v_new_slug is distinct from 'owner' or not v_new_is_system) then
+      select count(*) into v_active_owner_count
+      from kontrolia_auth.membership_roles mr
+      join kontrolia_auth.memberships m on m.id = mr.membership_id
+      join kontrolia_auth.roles r on r.id = mr.role_id
+      where m.organization_id = v_organization_id
+        and m.status = 'active'
+        and r.slug = 'owner'
+        and r.is_system_role;
+
+      if v_active_owner_count <= 1 then
+        raise exception 'No puedes quitar el rol de Owner al único Owner activo de la organización.';
+      end if;
+    end if;
+  end if;
+
+  return new;
+end;
+$$;
+
+-- roles: neither the INSERT nor the UPDATE policy (0019) has ever
+-- inspected `slug` — "not is_system_role" only ever governed
+-- is_system_role itself, never the string a custom role's slug could be
+-- set to. Defense in depth on top of the is_system_role anchoring above:
+-- even if some future check forgets to require is_system_role, a custom
+-- role can no longer be given a reserved slug in the first place.
+create or replace function kontrolia_auth.prevent_custom_role_reserved_slug()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+begin
+  if not new.is_system_role and new.slug in ('owner', 'admin', 'member') then
+    raise exception 'No puedes usar "%" como slug de un rol personalizado — está reservado.', new.slug;
+  end if;
+  return new;
+end;
+$$;
+
+drop trigger if exists prevent_custom_role_reserved_slug on kontrolia_auth.roles;
+create trigger prevent_custom_role_reserved_slug
+  before insert or update on kontrolia_auth.roles
+  for each row execute function kontrolia_auth.prevent_custom_role_reserved_slug();

package/migrations/0031_allow_owner_bootstrap_grant.sql

@@ -0,0 +1,121 @@
+-- 0028's owner-grant guard ("Solo un Owner puede otorgar el rol de Owner")
+-- broke organization creation itself: 0011's bootstrap trigger auto-enrolls
+-- a brand-new organization's creator as its first Owner, in the same
+-- transaction as the org's own insert — at that exact moment
+-- is_org_owner() correctly returns false (there is, by definition, no
+-- Owner yet), so 0028 rejected the very grant it needed to allow. Every
+-- "create organization" request has been failing with "Solo un Owner
+-- puede otorgar el rol de Owner" since 0028 shipped today.
+--
+-- The fix: also allow the grant when the target organization currently has
+-- zero active Owners. That can only be genuinely true for a brand-new org
+-- (0025-0027 already block every path that would let an *existing* org's
+-- active-Owner count reach zero), so this reopens nothing PQ-SEC-006
+-- closed — it only restores the one case those very fixes made
+-- impossible to reach any other way: establishing an org's first Owner.
+
+create or replace function kontrolia_auth.prevent_admin_granting_owner_role()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_role_slug text;
+  v_is_system_role boolean;
+  v_organization_id uuid;
+  v_existing_owner_count int;
+begin
+  if auth.role() = 'service_role' then
+    return new;
+  end if;
+
+  select slug, is_system_role into v_role_slug, v_is_system_role from kontrolia_auth.roles where id = new.role_id;
+  if v_role_slug is distinct from 'owner' or not v_is_system_role then
+    return new;
+  end if;
+
+  select organization_id into v_organization_id from kontrolia_auth.memberships where id = new.membership_id;
+
+  if kontrolia_auth.is_org_owner(v_organization_id) then
+    return new;
+  end if;
+
+  select count(*) into v_existing_owner_count
+  from kontrolia_auth.membership_roles mr
+  join kontrolia_auth.memberships m on m.id = mr.membership_id
+  join kontrolia_auth.roles r on r.id = mr.role_id
+  where m.organization_id = v_organization_id
+    and m.status = 'active'
+    and r.slug = 'owner'
+    and r.is_system_role;
+
+  if v_existing_owner_count > 0 then
+    raise exception 'Solo un Owner puede otorgar el rol de Owner.';
+  end if;
+
+  return new;
+end;
+$$;
+
+-- Same latent bug in 0029's UPDATE-path owner-grant check — not currently
+-- reachable by any shipped code path (nothing upserts a role_id change to
+-- 'owner' outside the service-role-exempt invitation-accept flow), but
+-- fixing it for the same reason: a zero-Owner org has nothing to bypass.
+create or replace function kontrolia_auth.prevent_membership_role_update()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_organization_id uuid;
+  v_old_slug text;
+  v_old_is_system boolean;
+  v_new_slug text;
+  v_new_is_system boolean;
+  v_active_owner_count int;
+begin
+  if new.membership_id is distinct from old.membership_id then
+    raise exception 'No se puede reasignar un rol de membresía a otra membresía.';
+  end if;
+
+  if old.role_id is distinct from new.role_id and auth.role() is distinct from 'service_role' then
+    select slug, is_system_role into v_old_slug, v_old_is_system from kontrolia_auth.roles where id = old.role_id;
+    select slug, is_system_role into v_new_slug, v_new_is_system from kontrolia_auth.roles where id = new.role_id;
+    select organization_id into v_organization_id from kontrolia_auth.memberships where id = old.membership_id;
+
+    if v_new_slug = 'owner' and v_new_is_system and not kontrolia_auth.is_org_owner(v_organization_id) then
+      select count(*) into v_active_owner_count
+      from kontrolia_auth.membership_roles mr
+      join kontrolia_auth.memberships m on m.id = mr.membership_id
+      join kontrolia_auth.roles r on r.id = mr.role_id
+      where m.organization_id = v_organization_id
+        and m.status = 'active'
+        and r.slug = 'owner'
+        and r.is_system_role;
+
+      if v_active_owner_count > 0 then
+        raise exception 'Solo un Owner puede otorgar el rol de Owner.';
+      end if;
+    end if;
+
+    if v_old_slug = 'owner' and v_old_is_system and (v_new_slug is distinct from 'owner' or not v_new_is_system) then
+      select count(*) into v_active_owner_count
+      from kontrolia_auth.membership_roles mr
+      join kontrolia_auth.memberships m on m.id = mr.membership_id
+      join kontrolia_auth.roles r on r.id = mr.role_id
+      where m.organization_id = v_organization_id
+        and m.status = 'active'
+        and r.slug = 'owner'
+        and r.is_system_role;
+
+      if v_active_owner_count <= 1 then
+        raise exception 'No puedes quitar el rol de Owner al único Owner activo de la organización.';
+      end if;
+    end if;
+  end if;
+
+  return new;
+end;
+$$;

package/migrations/0032_application_api_key_lifecycle.sql

@@ -0,0 +1,66 @@
+-- kontrolia-integration-surface audit (INT-KEY-001, HIGH): the application
+-- sync API key had no rotation, no revocation UI, no "last used" signal, and
+-- no logging — a leak was both undetectable and recoverable only by
+-- destructively deleting and re-registering the whole application. Also
+-- found while implementing the fix: api_key_hash was readable by ANY
+-- authenticated user for ANY application. RLS is row-level only — 0018's
+-- "browse the application catalog" SELECT policy (`using (true)`) makes
+-- every application row visible to every authenticated user, and 0008's
+-- blanket `grant select ... on all tables ... to authenticated` never
+-- carved out an exception for this one sensitive column. The stored value
+-- is a plain, unsalted sha256 digest (packages/db/src/api-key.ts) — not
+-- practically reversible given the key's 192 bits of entropy, but a hash
+-- that any user can read for any organization's application is needless
+-- exposure regardless, and worth closing at the same time as the rest of
+-- this key's lifecycle.
+
+alter table kontrolia_auth.applications add column api_key_last_used_at timestamptz;
+
+comment on column kontrolia_auth.applications.api_key_last_used_at is
+  'Updated on every successful POST /api/applications/sync auth — lets an operator tell an active integration from an abandoned one before rotating/revoking its key.';
+
+-- Column-level ACL, layered under the existing row-level policies. Table-
+-- level `grant select` (0008) makes every column readable regardless of a
+-- later per-column `revoke` — Postgres's column privileges are additive on
+-- top of the table-level grant, not a restriction of it, so blocking one
+-- column means revoking the table-level grant entirely and re-granting an
+-- explicit column list for everything else. Rotating/revoking the key
+-- still works (that's an UPDATE, untouched by this). The sync route's own
+-- lookup runs as service_role, which needs its own explicit grant since
+-- column privileges aren't inherited from a table-level grant either.
+revoke select on kontrolia_auth.applications from authenticated;
+grant select (
+  id, name, slug, owner_organization_id, environment, redirect_urls,
+  created_at, updated_at, homepage_url, api_key_last_used_at
+) on kontrolia_auth.applications to authenticated;
+grant select (id, api_key_hash) on kontrolia_auth.applications to service_role;
+
+-- Same "the database logs it, not application code" pattern as every other
+-- audit trigger in this schema (0013, 0024) — rotation/revocation are
+-- exactly the kind of security-relevant event that should never depend on
+-- whichever code path happened to perform the UPDATE remembering to log it.
+create or replace function kontrolia_auth.log_application_api_key_change()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+begin
+  if old.api_key_hash is distinct from new.api_key_hash then
+    insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+    values (
+      new.owner_organization_id,
+      auth.uid(),
+      case when new.api_key_hash is null then 'application.api_key_revoked' else 'application.api_key_rotated' end,
+      'application',
+      new.id::text,
+      jsonb_build_object('slug', new.slug)
+    );
+  end if;
+  return new;
+end;
+$$;
+
+create trigger audit_application_api_key_change
+  after update on kontrolia_auth.applications
+  for each row execute function kontrolia_auth.log_application_api_key_change();

package/migrations/0033_prevent_owner_role_invitation.sql

@@ -0,0 +1,53 @@
+-- Found while designing the external applications/members API (which
+-- creates invitations via a service-role client, same as invitation-accept
+-- already does): invitation-accept (apps/auth-server/app/api/invitations/
+-- accept/route.ts) grants invitation.role_id through a service_role admin
+-- client, and prevent_admin_granting_owner_role's own `auth.role() =
+-- 'service_role' then return new` bypass (0028) means it never checked
+-- whether that role is 'owner'. An org Admin has always been able to create
+-- an invitation with role_id pointing at the Owner role (POST
+-- /api/invitations only enforces "org admins manage invitations" RLS, which
+-- never inspects role_id), and accepting it would silently grant Owner with
+-- no is_org_owner() check at all — a live, reachable bypass of every
+-- owner-grant protection built in 0025-0031, through a channel none of them
+-- touch.
+--
+-- Rather than trying to teach the service-role-exempt accept flow to tell a
+-- legitimate bootstrap grant apart from this, remove the capability at its
+-- source: an invitation can never carry the Owner role. This is also just a
+-- reasonable product invariant on its own — you can't invite someone
+-- straight into ownership, an existing Owner has to promote them after they
+-- join. No legitimate code path creates an owner-role invitation today
+-- (grepped: POST /api/invitations never special-cases role slugs), so this
+-- forecloses nothing that worked before.
+
+create or replace function kontrolia_auth.prevent_owner_role_invitation()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+declare
+  v_role_slug text;
+  v_is_system_role boolean;
+begin
+  if new.role_id is null then
+    return new;
+  end if;
+
+  select slug, is_system_role into v_role_slug, v_is_system_role
+  from kontrolia_auth.roles
+  where id = new.role_id;
+
+  if v_role_slug = 'owner' and v_is_system_role then
+    raise exception 'No se puede invitar directamente con el rol de Owner.';
+  end if;
+
+  return new;
+end;
+$$;
+
+drop trigger if exists prevent_owner_role_invitation on kontrolia_auth.invitations;
+create trigger prevent_owner_role_invitation
+  before insert or update on kontrolia_auth.invitations
+  for each row execute function kontrolia_auth.prevent_owner_role_invitation();

package/migrations/0034_application_ownership_claim.sql

@@ -0,0 +1,91 @@
+-- Closes INT-API-007/INT-API-008/PQ-TECH-010: applications.owner_organization_id
+-- was never written by any code path in the repo — registerApplication()'s
+-- INSERT omits it, the CLI wizard runs before any organization necessarily
+-- exists and never asks who should own the app, and no INSERT/ownership-claim
+-- RLS policy ever existed for a regular user. Three real, shipped
+-- capabilities (0022's owning-org UPDATE policy, the admin-panel rotate/
+-- revoke API-key UI, the applications/members API) were all correctly built
+-- but unreachable for any application registered the intended way.
+--
+-- The actual fix is POST /api/applications/claim (auth-server), a
+-- platform-admin-gated route that runs as service_role — matching this
+-- table's original design comment (migration 0010: "applications catalog:
+-- platform-level, managed via service_role from the auth-server admin API").
+-- This migration only prepares the database side of that: audit logging for
+-- the new action, and a guard against a related gap found while designing
+-- it (see below).
+
+-- Extend the existing "database logs it, not application code" trigger
+-- (0032) to also cover ownership changes, the same way it already covers
+-- api_key_hash changes.
+create or replace function kontrolia_auth.log_application_api_key_change()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+begin
+  if old.api_key_hash is distinct from new.api_key_hash then
+    insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+    values (
+      new.owner_organization_id,
+      auth.uid(),
+      case when new.api_key_hash is null then 'application.api_key_revoked' else 'application.api_key_rotated' end,
+      'application',
+      new.id::text,
+      jsonb_build_object('slug', new.slug)
+    );
+  end if;
+
+  if old.owner_organization_id is distinct from new.owner_organization_id then
+    insert into kontrolia_auth.audit_logs (organization_id, actor_user_id, action, target_type, target_id, metadata)
+    values (
+      new.owner_organization_id,
+      auth.uid(),
+      case when old.owner_organization_id is null then 'application.ownership_claimed' else 'application.ownership_transferred' end,
+      'application',
+      new.id::text,
+      jsonb_build_object('slug', new.slug, 'previous_owner_organization_id', old.owner_organization_id)
+    );
+  end if;
+
+  return new;
+end;
+$$;
+
+-- Found while designing the claim route, reading every existing policy on
+-- this table: 0022's "owning org admins can update their application" UPDATE
+-- policy checks USING/WITH CHECK is_org_admin(owner_organization_id) against
+-- the OLD row and the NEW row independently — it never requires those two
+-- organization ids to be the SAME org. A user who administers two different
+-- organizations, one of which already owns an application, could already
+-- reassign that application to their other org via a plain RLS-authenticated
+-- UPDATE, with neither org's other admins involved — the same dual-org-admin
+-- shape as this session's earlier PQ-SEC-005, on a different table. Since the
+-- product has no legitimate "transfer ownership" capability (only "claim an
+-- unowned application", which the new route performs as service_role), the
+-- simplest correct fix is to remove the capability entirely for any other
+-- caller: once owner_organization_id is set, only service_role may change it.
+create or replace function kontrolia_auth.prevent_application_ownership_reassignment()
+returns trigger
+language plpgsql
+security definer
+set search_path = ''
+as $$
+begin
+  if auth.role() = 'service_role' then
+    return new;
+  end if;
+
+  if old.owner_organization_id is not null and new.owner_organization_id is distinct from old.owner_organization_id then
+    raise exception 'No se puede reasignar la propiedad de una aplicación ya reclamada.';
+  end if;
+
+  return new;
+end;
+$$;
+
+drop trigger if exists prevent_application_ownership_reassignment on kontrolia_auth.applications;
+create trigger prevent_application_ownership_reassignment
+  before update on kontrolia_auth.applications
+  for each row execute function kontrolia_auth.prevent_application_ownership_reassignment();

package/migrations/0035_restore_is_platform_admin_claim.sql

@@ -0,0 +1,102 @@
+-- CRITICAL regression found live while testing the new applications/claim
+-- route (migration 0034): migration 0030's `create or replace function
+-- kontrolia_auth.custom_access_token_hook` fully replaced the function body
+-- to anchor roles/permissions to is_system_role, but its jsonb_set calls only
+-- covered organization_id/roles/permissions — it silently dropped the
+-- is_platform_admin claim that 0020's version set. `create or replace`
+-- replaces the whole body, so anything not repeated in the new version is
+-- gone, not merged.
+--
+-- Live-reproduced: generated a real magic-link session for a genuine
+-- platform_admins row (raul.dolores@gmail.com) against the running local
+-- sandbox and decoded the resulting JWT — no is_platform_admin claim present
+-- at all. Every platform-admin-gated route (POST/DELETE /api/platform-admins,
+-- GET/POST/PUT /api/oauth-clients, and the new POST /api/applications/claim)
+-- has been checking `claims.is_platform_admin`, which has been `undefined`
+-- (falsy, so at least fails closed — no privilege escalation, just a broken
+-- feature) for every real user since 0030 shipped earlier today. Nothing
+-- caught this because verification since 0030 used direct-SQL/service-role
+-- testing for those routes rather than a real fresh login.
+
+create or replace function kontrolia_auth.custom_access_token_hook(event jsonb)
+returns jsonb
+language plpgsql
+stable
+security definer
+set search_path = ''
+as $$
+declare
+  claims jsonb;
+  target_user_id uuid;
+  active_org_id uuid;
+  active_membership_id uuid;
+  role_names text[];
+  permission_keys text[];
+  platform_admin boolean;
+begin
+  claims := coalesce(event->'claims', '{}'::jsonb);
+  target_user_id := (event->>'user_id')::uuid;
+
+  select active_organization_id into active_org_id
+  from kontrolia_auth.sessions_context
+  where user_id = target_user_id;
+
+  if active_org_id is null then
+    select organization_id into active_org_id
+    from kontrolia_auth.memberships
+    where user_id = target_user_id and status = 'active'
+    order by created_at asc
+    limit 1;
+  end if;
+
+  if active_org_id is not null then
+    select id into active_membership_id
+    from kontrolia_auth.memberships
+    where user_id = target_user_id
+      and organization_id = active_org_id
+      and status = 'active';
+  end if;
+
+  if active_membership_id is not null then
+    select coalesce(array_agg(distinct r.slug), '{}')
+      into role_names
+    from kontrolia_auth.membership_roles mr
+    join kontrolia_auth.roles r on r.id = mr.role_id
+    where mr.membership_id = active_membership_id and r.is_system_role;
+
+    select coalesce(array_agg(distinct p.key), '{}')
+      into permission_keys
+    from (
+      select p.id, p.key
+      from kontrolia_auth.membership_roles mr
+      join kontrolia_auth.role_permissions rp on rp.role_id = mr.role_id
+      join kontrolia_auth.permissions p on p.id = rp.permission_id
+      where mr.membership_id = active_membership_id
+      union
+      select p.id, p.key
+      from kontrolia_auth.user_permissions up
+      join kontrolia_auth.permissions p on p.id = up.permission_id
+      where up.membership_id = active_membership_id and up.effect = 'allow'
+    ) p
+    where not exists (
+      select 1 from kontrolia_auth.user_permissions up_deny
+      where up_deny.membership_id = active_membership_id
+        and up_deny.permission_id = p.id
+        and up_deny.effect = 'deny'
+    );
+  else
+    role_names := '{}';
+    permission_keys := '{}';
+  end if;
+
+  select exists(select 1 from kontrolia_auth.platform_admins where user_id = target_user_id) into platform_admin;
+
+  claims := jsonb_set(claims, '{organization_id}', coalesce(to_jsonb(active_org_id), 'null'::jsonb));
+  claims := jsonb_set(claims, '{roles}', to_jsonb(coalesce(role_names, '{}')));
+  claims := jsonb_set(claims, '{permissions}', to_jsonb(coalesce(permission_keys, '{}')));
+  claims := jsonb_set(claims, '{is_platform_admin}', to_jsonb(coalesce(platform_admin, false)));
+
+  event := jsonb_set(event, '{claims}', claims);
+  return event;
+end;
+$$;

package/migrations/0036_application_oauth_client_link.sql

@@ -0,0 +1,20 @@
+-- Lets an application's own row remember which GoTrue OAuth 2.1 client it
+-- registered, so admin-panel can manage OAuth-client credentials from
+-- inside that application's row instead of a separate, disconnected
+-- top-level "Clientes OAuth" screen. No real FK is possible — GoTrue's
+-- OAuth clients live entirely outside this schema, reachable only via its
+-- own admin HTTP API (see apps/auth-server/app/api/oauth-clients/route.ts),
+-- not a Postgres table this database has any relationship to. This is
+-- purely a pointer, populated by the application layer after a successful
+-- POST to that route.
+--
+-- An old day-one migration comment (0003_applications_and_permissions.sql:
+-- "oauth_clients (v2) attach real OAuth2 credentials to a row here") shows
+-- this link was the original intended design; it was never implemented and
+-- the two concepts drifted apart into fully separate admin-panel pages.
+-- This finally closes that gap.
+
+alter table kontrolia_auth.applications add column oauth_client_id text;
+
+comment on column kontrolia_auth.applications.oauth_client_id is
+  'GoTrue OAuth 2.1 client_id registered for this application, if any — set by admin-panel after POST /api/oauth-clients succeeds. Not a foreign key: GoTrue''s own oauth_clients table lives outside kontrolia_auth, reachable only via its admin API.';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kontrolia/db",
-  "version": "2.1.0",
+  "version": "2.1.2",
   "license": "MIT",
   "description": "KontrolIA Auth database layer: SQL migrations for the `kontrolia` schema (organizations, RBAC, Custom Access Token Hook) and a connection-string-agnostic migration runner.",
   "keywords": [