@luanpdd/kit-mcp 1.20.0 → 1.21.0

package/kit/skills/permission-gate-react-pattern/SKILL.md

@@ -0,0 +1,271 @@
+---
+name: permission-gate-react-pattern
+description: Use ao implementar permission gates React em B2B SaaS multi-tenant — CASL `@casl/ability` 6.8 + `@casl/react` 4.x para gates declarativos `<PermissionGate permission="leads:create">`, hook `usePermission(action, resource)`, anti-pattern explícito permission check só client (server-side enforcement obrigatório via RLS).
+---
+
+# Permission Gate — React Pattern (CASL)
+
+## Quando usar
+
+LLM carrega esta skill ao implementar gates de permissão UI em React. Trigger phrases:
+
+- "permission gate React", "PermissionGate component"
+- "CASL React permissions", "@casl/ability"
+- "usePermission hook", "ability check React"
+- "RBAC frontend gate"
+- "client-side permission anti-pattern"
+
+## Regras absolutas
+
+**REGRA #1 (UX-only, NUNCA segurança):** Permission gate React é **UX apenas**. Esconde botão para evitar erro 403 visível ao user. **Server-side enforcement obrigatório** via RLS (Phase 108) + `private.has_permission`.
+
+**REGRA #2 (CASL canônico 2026):** `@casl/ability` v6.8+ + `@casl/react` v4.x é a biblioteca canônica para React. Isomorfica (frontend + backend), bundle pequeno (~5KB), API declarativa.
+
+**REGRA #3 (build ability do JWT):** Construir `Ability` instance **uma vez** após login a partir das permissions do user (fetched via RPC). Re-build apenas após role change.
+
+**REGRA #4 (Hook `usePermission` + componente `<PermissionGate>`):** Padrões canônicos:
+- `usePermission(action, resource)` para condicionais inline
+- `<PermissionGate permission="leads:create">{children}</PermissionGate>` para wrap declarativo
+
+**REGRA #5 (sync com server após role change):** Após `assign_role` RPC, re-fetch permissions + rebuild Ability + update store. Sem isso, UI mostra cached state stale.
+
+## Patterns canônicos
+
+### Setup CASL — definir Ability
+
+```typescript
+// lib/abilities/build-ability.ts
+import { AbilityBuilder, Ability } from '@casl/ability'
+
+export type Action = 'create' | 'read' | 'update' | 'delete' | 'invite' | 'remove' | 'export' | 'view' | 'process'
+export type Subject = 'leads' | 'members' | 'org_settings' | 'audit_logs' | 'departments' | 'roles' | 'permissions' | 'dsr_requests' | 'all'
+
+export type AppAbility = Ability<[Action, Subject]>
+
+interface UserPermissions {
+  permissions: Array<{ action: Action; resource: Subject }>
+  isSuperAdmin: boolean
+}
+
+export function buildAbility({ permissions, isSuperAdmin }: UserPermissions): AppAbility {
+  const { can, build } = new AbilityBuilder<AppAbility>(Ability)
+
+  if (isSuperAdmin) {
+    can('manage' as any, 'all')
+    return build()
+  }
+
+  for (const p of permissions) {
+    can(p.action, p.resource)
+  }
+
+  return build()
+}
+```
+
+### Buscar permissions do user (RPC)
+
+```sql
+-- supabase RPC chamada após login
+create or replace function public.get_user_permissions(p_org_id uuid)
+returns table(action text, resource text)
+language sql
+stable
+security invoker
+set search_path = ''
+as $$
+  select p.action, p.resource
+  from public.organization_members om
+  join public.role_permissions rp on rp.role_id = om.role_id
+  join public.permissions p on p.id = rp.permission_id
+  where om.org_id = p_org_id
+    and om.user_id = (select auth.uid())
+    and om.status = 'active';
+$$;
+
+grant execute on function public.get_user_permissions(uuid) to authenticated;
+```
+
+### Provider — Ability disponível em toda app
+
+```typescript
+// app/providers/AbilityProvider.tsx
+'use client'
+
+import { createContext, useEffect, useState } from 'react'
+import { AppAbility, buildAbility } from '@/lib/abilities/build-ability'
+import { useOrgStore } from '@/lib/stores/org-store'
+import { supabase } from '@/lib/supabase'
+
+export const AbilityContext = createContext<AppAbility | null>(null)
+
+export function AbilityProvider({ children }: { children: React.ReactNode }) {
+  const [ability, setAbility] = useState<AppAbility | null>(null)
+  const activeOrgId = useOrgStore(s => s.activeOrgId)
+
+  useEffect(() => {
+    if (!activeOrgId) return
+
+    async function load() {
+      // REGRA #3: build ability do server data
+      const { data: { user } } = await supabase.auth.getUser()
+      const isSuperAdmin = user?.app_metadata.super_admin === true
+
+      const { data: permissions } = await supabase
+        .rpc('get_user_permissions', { p_org_id: activeOrgId })
+
+      setAbility(buildAbility({ permissions: permissions || [], isSuperAdmin }))
+    }
+    load()
+  }, [activeOrgId])
+
+  return <AbilityContext.Provider value={ability}>{children}</AbilityContext.Provider>
+}
+
+// Hook para acessar ability
+import { useContext } from 'react'
+export function useAbility() {
+  const ability = useContext(AbilityContext)
+  if (!ability) throw new Error('useAbility must be inside AbilityProvider')
+  return ability
+}
+```
+
+### Hook `usePermission` (REGRA #4)
+
+```typescript
+// lib/hooks/use-permission.ts
+import { useAbility } from '@/app/providers/AbilityProvider'
+import { Action, Subject } from '@/lib/abilities/build-ability'
+
+export function usePermission(action: Action, resource: Subject): boolean {
+  const ability = useAbility()
+  return ability.can(action, resource)
+}
+
+// Usage:
+function LeadsPage() {
+  const canCreateLead = usePermission('create', 'leads')
+  return (
+    <div>
+      <h1>Leads</h1>
+      {canCreateLead && <Button onClick={openCreateModal}>+ Novo Lead</Button>}
+    </div>
+  )
+}
+```
+
+### Componente `<PermissionGate>` (REGRA #4)
+
+```typescript
+// components/PermissionGate.tsx
+import { useAbility } from '@/app/providers/AbilityProvider'
+import type { Action, Subject } from '@/lib/abilities/build-ability'
+
+interface Props {
+  permission: `${Action}:${Subject}`
+  fallback?: React.ReactNode
+  children: React.ReactNode
+}
+
+export function PermissionGate({ permission, fallback = null, children }: Props) {
+  const ability = useAbility()
+  const [action, subject] = permission.split(':') as [Action, Subject]
+
+  if (ability.can(action, subject)) {
+    return <>{children}</>
+  }
+  return <>{fallback}</>
+}
+
+// Usage:
+<PermissionGate permission="leads:create">
+  <Button onClick={openCreateModal}>+ Novo Lead</Button>
+</PermissionGate>
+
+<PermissionGate
+  permission="org_settings:update"
+  fallback={<p>Você não tem permissão para alterar configurações.</p>}
+>
+  <SettingsForm />
+</PermissionGate>
+```
+
+### Refresh ability após role change (REGRA #5)
+
+```typescript
+// Em algum lugar após mudança de role (admin UI)
+async function changeRole(targetUserId: string, newRoleId: string) {
+  await supabase.rpc('assign_role', { ... })
+  await supabase.auth.refreshSession()  // JWT (cross-ref org-switcher)
+
+  // REGRA #5: re-fetch + rebuild ability
+  // Trigger AbilityProvider re-fetch via mudança em activeOrgId timestamp
+  // (use store version increment)
+  useOrgStore.getState().bumpVersion()
+}
+```
+
+## Anti-patterns
+
+### Anti-pattern 1: Permission check SÓ frontend (sem RLS)
+
+**Errado:**
+```typescript
+{ ability.can('delete', 'leads') && <DeleteButton onClick={() => api.delete(`/leads/${id}`)} /> }
+// Mas API endpoint não checa permission server-side
+```
+
+**Por quê:** REGRA #1 — atacante chama `curl -X DELETE /leads/...` direto, ignora gate React. Frontend gate é segurança teatro.
+
+**Certo:** RLS no Supabase com `private.has_permission` (Phase 108) + frontend gate como UX redundância.
+
+### Anti-pattern 2: Hard-coded role check em vez de permission
+
+**Errado:**
+```typescript
+{ user.role === 'admin' && <Button>Convidar</Button> }
+```
+
+**Por quê:** custom roles quebram. Custom role com permission `members:invite` deveria mostrar botão, mas não passa no check `=== 'admin'`. Acopla UI a role names.
+
+**Certo:** `usePermission('invite', 'members')` — funciona com qualquer role que tenha a permission.
+
+### Anti-pattern 3: Re-fetch permissions a cada render
+
+**Errado:**
+```typescript
+function MyComponent() {
+  const [perms, setPerms] = useState([])
+  useEffect(() => {
+    supabase.rpc('get_user_permissions', { ... }).then(setPerms)
+  })  // sem deps array — re-fetch infinito
+}
+```
+
+**Por quê:** N requests/min para Supabase, performance terrível.
+
+**Certo:** REGRA #3 — build Ability uma vez no Provider, consume via `useAbility()` hook.
+
+### Anti-pattern 4: Esquecer fallback em PermissionGate
+
+**Errado:**
+```typescript
+<PermissionGate permission="org_settings:update">
+  <SettingsForm />
+</PermissionGate>
+// User sem permission vê página vazia, sem feedback
+```
+
+**Por quê:** UX confusa — user não entende por que página é em branco.
+
+**Certo:** sempre passar `fallback` com mensagem clara ("Você não tem permissão...").
+
+## Ver também
+
+- [org-switcher-react-pattern](../org-switcher-react-pattern/SKILL.md) — sibling, OrgProvider + zustand store
+- [member-management-react-shadcn](../member-management-react-shadcn/SKILL.md) — sibling, usa PermissionGate
+- [rbac-permissions-matrix-supabase](../rbac-permissions-matrix-supabase/SKILL.md) — Phase 108, modelagem permissions
+- [multi-tenant-rls-hierarchy](../multi-tenant-rls-hierarchy/SKILL.md) — Phase 108, server-side RLS enforcement
+- [_shared-multi-tenant/glossary.md](../_shared-multi-tenant/glossary.md) — `permission gate`, `CASL`, `JWT stale`
+- [CASL Documentation](https://casl.js.org/)

package/kit/skills/rbac-permissions-matrix-supabase/SKILL.md

@@ -0,0 +1,301 @@
+---
+name: rbac-permissions-matrix-supabase
+description: Use ao modelar RBAC granular em Supabase B2B — permission strings resource:action, matrix N:M roles ↔ permissions, regra "user só atribui roles ≤ ao próprio", 3 roles built-in (owner/admin/member) + custom permitidos.
+---
+
+# RBAC Permissions Matrix — Supabase B2B Multi-Tenant
+
+## Quando usar
+
+LLM carrega esta skill ao desenhar autorização granular em B2B SaaS multi-tenant. Trigger phrases:
+
+- "RBAC granular", "permission matrix"
+- "permission string resource:action", "leads:create", "members:invite"
+- "custom roles", "role escalation rule"
+- "owner admin member built-in"
+- "role permissions table"
+
+## Regras absolutas
+
+**REGRA #1 (permission string format):** Permissions são strings `<resource>:<action>` em snake_case (ex: `leads:create`, `members:invite`, `org_settings:update`). Padrão convergente 2026 (Stripe, Linear, Auth0).
+
+**REGRA #2 (3 roles built-in mínimo):** Toda org tem 3 roles built-in com `is_built_in = true`:
+- `owner` — full control (criação org, billing, transfer ownership, delete org)
+- `admin` — manage members, settings, all data
+- `member` — operações standard (CRUD nos recursos da org)
+
+**REGRA #3 (role escalation rule):** Usuário só pode **criar/atribuir roles ≤ ao próprio role**. Member não pode criar admin. Admin não pode criar owner. Owner pode tudo. Enforced via policy + frontend gate.
+
+**REGRA #4 (custom roles permitidos):** Custom roles via `is_built_in = false` na mesma tabela `roles`. Org-scoped (não globais). Built-in não podem ser deletados (constraint).
+
+**REGRA #5 (NUNCA permission string em frontend hard-coded para enforce):** Permission gate React (skill [`permission-gate-react-pattern`](../permission-gate-react-pattern/SKILL.md)) é UX apenas. Server-side enforcement obrigatório via RLS + `private.has_permission`.
+
+## Patterns canônicos
+
+### Permission catalog — eventos canônicos
+
+```sql
+-- Catálogo global (compartilhado entre orgs)
+insert into public.permissions (action, resource, description) values
+  -- Members
+  ('invite',  'members',      'Convidar novos membros via email'),
+  ('remove',  'members',      'Remover membros existentes'),
+  ('update',  'members',      'Atualizar role/status de membros'),
+  ('list',    'members',      'Listar membros da org'),
+
+  -- Org settings
+  ('update',  'org_settings', 'Atualizar configurações gerais da org'),
+  ('update',  'org_billing',  'Acessar/alterar billing (Stripe)'),
+
+  -- Departments
+  ('create',  'departments',  'Criar departamentos'),
+  ('update',  'departments',  'Atualizar departamentos'),
+  ('delete',  'departments',  'Deletar departamentos'),
+
+  -- Roles + Permissions
+  ('create',  'roles',        'Criar custom roles'),
+  ('update',  'roles',        'Atualizar role permissions'),
+  ('delete',  'roles',        'Deletar custom roles (built-in protegidos)'),
+
+  -- Domain example: leads (CRM)
+  ('create',  'leads',        'Criar leads'),
+  ('update',  'leads',        'Atualizar leads'),
+  ('delete',  'leads',        'Deletar leads'),
+  ('export',  'leads',        'Exportar leads (CSV/JSON)'),
+
+  -- Audit
+  ('view',    'audit_logs',   'Ver audit logs'),
+  ('export',  'audit_logs',   'Exportar audit logs'),
+
+  -- LGPD
+  ('process', 'dsr_requests', 'Processar Data Subject Requests'),
+
+on conflict (action, resource) do nothing;
+```
+
+### 3 roles built-in com permissions default
+
+```sql
+-- Para cada nova org (idealmente em RPC create_organization), criar built-in roles
+-- com permissions atribuídas.
+
+-- OWNER — todas permissions
+insert into public.role_permissions (role_id, permission_id)
+select
+  r.id,
+  p.id
+from public.roles r
+cross join public.permissions p
+where r.org_id = '<org_id>'
+  and r.name = 'owner';
+
+-- ADMIN — tudo exceto org_billing + delete org
+insert into public.role_permissions (role_id, permission_id)
+select
+  r.id,
+  p.id
+from public.roles r
+cross join public.permissions p
+where r.org_id = '<org_id>'
+  and r.name = 'admin'
+  and not (p.action = 'update' and p.resource = 'org_billing');
+
+-- MEMBER — operações CRUD em domínio (sem members management)
+insert into public.role_permissions (role_id, permission_id)
+select
+  r.id,
+  p.id
+from public.roles r
+cross join public.permissions p
+where r.org_id = '<org_id>'
+  and r.name = 'member'
+  and p.resource in ('leads', 'departments')
+  and p.action in ('create', 'update', 'list');
+```
+
+### Role escalation rule — enforcement via RPC + RLS
+
+```sql
+-- Função que retorna o "rank" de uma role (owner=3, admin=2, member=1, custom=0)
+create or replace function private.role_rank(p_role_name text)
+returns int
+language sql
+stable
+security invoker
+set search_path = ''
+as $$
+  select case p_role_name
+    when 'owner' then 3
+    when 'admin' then 2
+    when 'member' then 1
+    else 0  -- custom roles têm rank 0 (não comparáveis)
+  end;
+$$;
+
+-- RPC que assign role a um membro — só permite role ≤ ao próprio
+create or replace function public.assign_role(
+  p_org_id uuid,
+  p_target_user_id uuid,
+  p_role_id uuid
+)
+returns void
+language plpgsql
+security invoker
+set search_path = ''
+as $$
+declare
+  caller_role_name text;
+  target_role_name text;
+begin
+  -- 1. Buscar role do caller na org
+  select r.name into caller_role_name
+  from public.organization_members om
+  join public.roles r on r.id = om.role_id
+  where om.org_id = p_org_id
+    and om.user_id = (select auth.uid())
+    and om.status = 'active';
+
+  if caller_role_name is null then
+    raise exception 'caller is not member of org';
+  end if;
+
+  -- 2. Buscar role alvo
+  select r.name into target_role_name
+  from public.roles r
+  where r.id = p_role_id and r.org_id = p_org_id;
+
+  if target_role_name is null then
+    raise exception 'role does not exist in org';
+  end if;
+
+  -- 3. REGRA #3: caller role rank >= target role rank
+  if private.role_rank(caller_role_name) < private.role_rank(target_role_name) then
+    raise exception
+      'role escalation forbidden: caller is %, cannot assign %',
+      caller_role_name, target_role_name;
+  end if;
+
+  -- 4. Assign
+  update public.organization_members
+  set role_id = p_role_id
+  where org_id = p_org_id and user_id = p_target_user_id;
+end;
+$$;
+
+grant execute on function public.assign_role(uuid, uuid, uuid) to authenticated;
+```
+
+### Frontend — listar roles que user pode atribuir
+
+```typescript
+// Buscar roles que current user pode atribuir (rank ≤ próprio)
+const { data: assignableRoles } = await supabase
+  .from('roles')
+  .select('id, name, description')
+  .eq('org_id', orgId)
+  // RPC retorna apenas roles que caller pode atribuir
+  .rpc('list_assignable_roles', { p_org_id: orgId })
+```
+
+### RLS policy usando `private.has_permission`
+
+```sql
+-- Tabela leads — INSERT requer permission leads:create
+create policy "leads_insert_with_permission"
+  on public.leads
+  for insert
+  to authenticated
+  with check (
+    private.has_permission('create', 'leads', org_id)
+  );
+
+-- Tabela members management — UPDATE role requer permission members:update
+create policy "members_update_role_with_permission"
+  on public.organization_members
+  for update
+  to authenticated
+  using (
+    private.has_permission('update', 'members', org_id)
+  )
+  with check (
+    private.has_permission('update', 'members', org_id)
+  );
+```
+
+## Anti-patterns
+
+### Anti-pattern 1: Permission string sem padrão
+
+**Errado:**
+```sql
+-- Mistura formats
+'canCreateLeads', 'leads.create', 'CREATE_LEAD', 'leads:write'
+```
+
+**Por quê:** inconsistência confunde devs (qual é a forma certa?), quebra autocomplete, dificulta migração.
+
+**Certo:** sempre `<resource>:<action>` em snake_case (REGRA #1). Pode usar enum em TypeScript:
+```typescript
+type Permission = `${Resource}:${Action}`
+```
+
+### Anti-pattern 2: Hard-coded role check em vez de permission
+
+**Errado:**
+```typescript
+// Permission gate frontend
+{ user.role === 'admin' && <Button>Convidar</Button> }
+```
+
+**Por quê:** custom roles quebram (custom role com permission `members:invite` não passa no check). Acopla UI a roles built-in.
+
+**Certo:**
+```typescript
+{ usePermission('invite', 'members') && <Button>Convidar</Button> }
+```
+
+E server-side: RLS com `private.has_permission`.
+
+### Anti-pattern 3: Built-in role pode ser deletada
+
+**Errado:**
+```sql
+-- Sem proteção
+delete from public.roles where name = 'owner' and org_id = '...';
+-- Org fica sem owner, ninguém consegue fazer nada
+```
+
+**Por quê:** org sem owner é unrecoverable sem service_role intervention. Compromete recovery.
+
+**Certo:** policy DELETE em `roles` que rejeita built-in:
+```sql
+create policy "roles_delete_custom_only"
+  on public.roles
+  for delete
+  to authenticated
+  using (
+    not is_built_in
+    and private.has_permission('delete', 'roles', org_id)
+  );
+```
+
+### Anti-pattern 4: Frontend permission gate sem server-side enforce
+
+**Errado:**
+```typescript
+// Esconder botão UI = "segurança"
+{ usePermission('delete', 'leads') && <DeleteButton /> }
+// Mas API endpoint /leads/{id} aceita DELETE sem checar permission
+```
+
+**Por quê:** atacante chama API direto via curl — ignora gate frontend. Permission gate React é **UX**, não segurança.
+
+**Certo:** REGRA #5. Server-side via RLS + `private.has_permission` é enforcement real.
+
+## Ver também
+
+- [multi-tenant-rls-hierarchy](../multi-tenant-rls-hierarchy/SKILL.md) — `private.has_permission` é a função canônica usada em policies
+- [b2b-saas-architecture](../b2b-saas-architecture/SKILL.md) — schema das tabelas `roles`, `permissions`, `role_permissions`
+- [permission-gate-react-pattern](../permission-gate-react-pattern/SKILL.md) — Phase 115, permission gate UX em React
+- [super-admin-platform-pattern](../super-admin-platform-pattern/SKILL.md) — Phase 111, super_admin bypassa RBAC normal
+- [_shared-multi-tenant/glossary.md](../_shared-multi-tenant/glossary.md) — termos `RBAC`, `permission matrix`, `role escalation rule`