@luanpdd/kit-mcp 1.22.0 → 1.26.0

package/kit/file-manifest.json

@@ -1,6 +1,6 @@
 {
-  "version": "1.22.0",
-  "timestamp": "2026-05-10T17:15:57.744Z",
+  "version": "1.26.0",
+  "timestamp": "2026-05-11T04:13:53.239Z",
   "files": {
     "COMANDOS.md": "d24ec61a6ec35db314cc5f2ae287bfb927b794789c8f1d558c55862f5e6534b2",
     "COMPATIBILITY.md": "794e336a87045cdf0161785b9a7a0975a49abbd80bdd816b8852251fcc8126ca",
@@ -8,36 +8,36 @@
     "agents/advisor-researcher.md": "2ecc52247af1f379c7d0a85847a966095f71d8e5a6140f62611f04c9e4fe264b",
     "agents/ai-mutation-tester.md": "bbdedc2d41440340c403bf4b71fb902eec057f3771667703c32309885aa4f4db",
     "agents/assumptions-analyzer.md": "b730268a8c588bc16e30330df874f64d1dc0bbd4573e696f7a316ea9e4c1f57c",
-    "agents/audit-log-implementer.md": "b8520400c6dfd27ec3675ee84fdac6f8bddb314e4800b6edcac9bbc761a726ae",
-    "agents/auditor-consistencia-isolamento.md": "81d38ac83ca84c0ad42eec8859947fbd29835ec2cbae9a032faf45f9ce0c0d93",
+    "agents/audit-log-implementer.md": "9ef8239b0186b3e3526f6c61a8fa2cca73738bca1cdfd0d85e4187efda6156d1",
+    "agents/auditor-consistencia-isolamento.md": "0d067455d39a8ad3fcc4eccea6fecaeaf3ba9d724b29e58c3612d33dfe6b6236",
     "agents/b2b-saas-architect.md": "6e613518b6c101a1d7cf0d86ef9337347662db863e47a492c3a2415a9b43ec3d",
     "agents/burn-rate-forecaster.md": "a4f2efccc7073ef0ab1a225895f68dff7c95d4f9e1c04319569cad47c13dffac",
     "agents/cascading-failures-auditor.md": "6c44929a90a2fc59d3ba59dd67814a85dc08f1b86d41933c5f19cefc8d33bdd5",
     "agents/codebase-mapper.md": "e1500018c3c67c8408f6b9fbc2543221d69c2884083d14327fe27e751fc920bc",
-    "agents/crm-pipeline-implementer.md": "881363ff4f81b44a753c66933f426634ca025d1af4bb9ee70496e5f056697a56",
-    "agents/debugger.md": "bc9bf46863af9028920780f21894778f3c07f1f02dc2ad84246520f54d33a6f0",
+    "agents/crm-pipeline-implementer.md": "bf69eebbad5f35b7eb733fadf90b4655a6a3b72913cea3aa9f6b6902e9f1fa04",
+    "agents/debugger.md": "57d55aa17e96caba5294a632d56ed3d0c4952032ec30d23ee3adba74dd7f7a46",
     "agents/detector-tenant-quente.md": "850630f254422e39166a6c9e8f08164aae975ef93fd99759bac7acedd26cc5cd",
-    "agents/evolution-go-integrator.md": "841b0d1fa1c962def8d47f8dc159a21a896a7fa6d7888eb42b6827d0bcab53e6",
+    "agents/evolution-go-integrator.md": "8d45d81ee71a4655267959279bced1e38e94d93a83943f4572afbd8ca4c457ad",
     "agents/example-reviewer.md": "cad1dcd4cafffc73e96de653809fdc2a9a8b1d8dc51865efd4d1daaf4284755f",
-    "agents/executor.md": "bc3af696fd820d32b0c5742c3c27a5f0ae527ae1627fb967b549ac193b34a853",
+    "agents/executor.md": "f62f125d1c9523d61d2a2aec1534cadc9a2bae69a441b2662a2e4e1e34bbbdbf",
     "agents/golden-signals-instrumenter.md": "de85b79ea09157ccc37c2de0facc3e6d4b9dba087e780330bc78be9ddd447297",
     "agents/incident-investigator.md": "521fcd4add75d2d4668162d19373823a9826bc45f23afdaf813b19f34113082d",
     "agents/integration-checker.md": "15c2badc2a8b650b7229e9ba32f481b08370afd3b80f41c7ae1c4cda7652811e",
-    "agents/invite-flow-implementer.md": "8ed29134ef89b1464df618c5ee9e7bbc9e2a28d235f72614f4a9b6535c2a38ed",
+    "agents/invite-flow-implementer.md": "9590a8ac8a430cb1a98cdbb59370b1890a53aee78f279aeb4116c9f4e09be938",
     "agents/legacy-characterizer.md": "1e9da6e7a0518a19788052e60554740f582fa2cd27b8dc1dc73251df3e712714",
-    "agents/lgpd-compliance-auditor.md": "ddde11f1867340b7e10c336696157538d1666df97997fcedc4dcaf997937fc56",
+    "agents/lgpd-compliance-auditor.md": "a34b1ddb76e6fcde0482fea309964f7a7450f2514745a23522e938d5181db83a",
     "agents/load-shedding-instrumenter.md": "63db224e3d8033a18cfe47ec8fc631685e356bf456d98b35c9c5d42d80fc5630",
     "agents/multi-tenant-isolation-auditor.md": "b4c03df48bb563711922880144c2a3a71139559455eeb2fd444df77ee9e3cdc0",
-    "agents/multi-tenant-rls-writer.md": "cd23e46cf5d00ed09bf1a1a1f51f517d75531d1a9078d46239eab4abcd67de20",
+    "agents/multi-tenant-rls-writer.md": "74b1af763125e77e54976be9544db60bb8265eccf40429a8b29e9a24aa60fbbc",
     "agents/nyquist-auditor.md": "1d7590f356714eaacbdc92831dd100f9ca230a9c461e34223eb4bdf67ebaf076",
     "agents/observability-coverage-auditor.md": "e2c68e145182446ec47753b63063fea1d12b4356b390f33dffd4890f2c1a4352",
     "agents/observability-instrumenter.md": "6d40d96fdc3281b85d7db6d2e82f0e018945f2d148ab1b39c951774e6873aad2",
     "agents/omm-auditor.md": "8e09dca83495ba869f0f4c79c156f909a22b272e9ed77a0fe8a6658887cff7c0",
-    "agents/org-onboarding-implementer.md": "c63dc139be4b03db2019c83f75a21c37b2005eebd1638012b4a5b3f6ed9b60cf",
+    "agents/org-onboarding-implementer.md": "4887c62e5b0f235bff81ee008f481732d493356cad08f7905172acc1901e2cbb",
     "agents/payload-capture-instrumenter.md": "f1517b1a5d5cb10f8229de7402d4b6a786e8bd0ac9f6de3701a0a9dcebeb6cd5",
     "agents/phase-researcher.md": "3e431d8d6bd4f1459b049771a30f7176cfb6ccc21bf49e8a4cfb0bb03f9e7f7d",
     "agents/plan-checker.md": "32982f3713b4251d123e981c3f723c2a8702625edbbba4d862d64155086b94ae",
-    "agents/planner.md": "0cd395e7d235c8d103005a2e58a81d7f5dc2e9807d355234a7ddf8f3bf148c8e",
+    "agents/planner.md": "395ddace0a708de89a3e2fb66bbf36df706f172bdc2a66023012d056b9c30ac4",
     "agents/postmortem-writer.md": "d8c30abd537920bfc7b060a7b1e4ba98e8c0ca59ad4297e89eee3d35992f9509",
     "agents/project-researcher.md": "3cf77520ff888cf0a4c879e147180f6f9c3ba04bd9b0def10ef8f35e7ccedbf6",
     "agents/prr-conductor.md": "22710f35f702f132a9cdd5c6e3fe2dcf44cda24af36a2cd91060799dd19e9a02",
@@ -50,14 +50,18 @@
     "agents/shotgun-surgery-detector.md": "334966916715c4c5eff3324b81a09e17b312defd9a8549f17bfe19c06dbd9e92",
     "agents/slo-engineer.md": "1e6ec6e3031a40be6a6d631400f0dd12bb2b94ce37a9816d89d1badae1e7d7ca",
     "agents/storytelling-analyst.md": "dd68f9e8cb01bbd102acb9a2021be81a0b8d6f2528f30971f9aa5ef331f7e563",
-    "agents/supabase-architect.md": "6582da73da2dda764b59c6cabc53f2e8a87482f91eaab26c946a74466f17a1ef",
-    "agents/supabase-auth-bootstrapper.md": "91a1f2d7df10cebf855e53364afc248a23b222dba2522d3084c9db0dfa5747f3",
+    "agents/supabase-architect.md": "523247c1ae7f69158d42971b19d51d299bc94a386ed871bdfe7eefbf3471a076",
+    "agents/supabase-auth-bootstrapper.md": "a197c3cd2c817f67a53400d5ba4fbf491f365a45e601fc60cd708ed07340272b",
+    "agents/supabase-column-privileges-writer.md": "dc6ed23511008cda6b9698afc3b577512547aaaf555d2a4de9273417f247ee6b",
     "agents/supabase-edge-fn-writer.md": "7b470664173f8c5c9ab12af74f58ddaeee3eb46bb3d2ca8de21b1c284961d9dd",
-    "agents/supabase-migration-writer.md": "7632e7284c94369c0174b18a4219929d9d4b41153edbf4e14b095e9a9f29f236",
+    "agents/supabase-migration-writer.md": "a964dd676362184fe657446415202e0c620b0d4ce26ebe25125b6a55937c2fba",
+    "agents/supabase-rbac-implementer.md": "605de2d2a43a3d1eda2e181b98f53aae45b0c80123acc059305b65adf51f9f74",
     "agents/supabase-realtime-implementer.md": "e10d7f723734da0dd930d6e0481e2afb2abde5b470d9c45e4364889dac19f3d6",
-    "agents/supabase-rls-writer.md": "0ac667ba0f6543699b0053e5e8ec3eca43aff6e3307adde3959e9ce2056a9136",
+    "agents/supabase-rls-hardener.md": "2d20a112d9fac3e2d6f7012acfd1aa141608952bfe0412878dad0201411c1a56",
+    "agents/supabase-rls-writer.md": "d631cc957020f20612589b2b832c52d598c1a6eb70a263117071d9e0212165fb",
+    "agents/supabase-roles-implementer.md": "57936bdb20aca00177efe2db9043205ba266809d5d1dd5ea50675784dbe8f08c",
     "agents/supabase-storage-implementer.md": "28d57bc1750acb5b0624ecc33bac6e7855e16dec40df4c490865df885a0980f8",
-    "agents/super-admin-implementer.md": "dd3d7897396d96ad3a1a91e43128f1fac26c010b8974b08f1d0ddc6cf2e831c3",
+    "agents/super-admin-implementer.md": "2cc926adb3f0deb23c319fd301dd187e68be5edd095ca5d8d3b5fa9e1054ae57",
     "agents/toil-auditor.md": "58770f11805e7b3d8cc7b70d79ed73a6a33dc7d17b66fdc7716454406acefd61",
     "agents/ui-auditor.md": "a94816e9535757b02c6fcc8ae1e51f6378813c9f256e26859e01757e49c38d31",
     "agents/ui-checker.md": "be3308db8733d8f9ce3db1d2cef924738498ed03c7aa15c0fca21a9c15e79da2",
@@ -149,7 +153,7 @@
     "commands/setup-notion.md": "d1cd970ddecce7211c2cec1a42f0b5c74ea537b4f5e498924d52813542508ae9",
     "commands/sre.md": "eb4701d8d5fd98671ef562eddc4f021fce6ca5474cd840bb06df5b81f4741c2d",
     "commands/storytelling.md": "84b3344392e4562d9b92da86be70cf4d4804ca75fbdfcb11265511be801f390e",
-    "commands/supabase.md": "bda09c62f1c1d1ce5c339f0f4421347abffb86591c1af49880a1f2ac437a2c6b",
+    "commands/supabase.md": "136286e6d127d50963c989d60031907471f5826d5f7386cbad3c3a40aa6e5ecc",
     "commands/sync-main.md": "6a62ec23e0d4a9bf4b68f531fb65caad67583ce4bb73bcf8f63945dc793b664c",
     "commands/validar-fase.md": "43f18fb86d86e3b685581c242fc63169186725e2077cdacad047ca1fdfbcfb61",
     "commands/verificar-tarefas.md": "4e8af66691b1fd4895db1dea8a0eabd8f8e46682e259dbf9a8c5f6e1687c1a06",
@@ -301,7 +305,7 @@
     "skills/_shared-multi-tenant/glossary.md": "1e040a36025489859312430771dde13bde9c62098fcd100440a82a2bb4d22b6a",
     "skills/_shared-observability/glossary.md": "ec3892c226af03299c0875e36fd0170cc9f801b02df52a2e0ec5c7468229912a",
     "skills/_shared-sre/glossary.md": "55a052c7d2292622150ed1cbb5aa0d675c332287b00ee4e3dd84900f9cf0ec84",
-    "skills/_shared-supabase/glossary.md": "2ebb4e09d9eda88a4f388f406f5cdb36fafa26a3ce6fb33d5c1976bcfac19327",
+    "skills/_shared-supabase/glossary.md": "24a794d195bdcf7ee6a5cc5c81b0ca93e3c8470afee6965fb104d9490072c450",
     "skills/ai-prompt-characterization/SKILL.md": "1a8114296c754e2018b1c1fd428c364f8de4485fedd5df78d3afcb33c3fef1a4",
     "skills/armadilhas-sistemas-distribuidos/SKILL.md": "fd33913c41a03f37eaa5fbc2aa3c33321397daa98a505ccb5f2d692dd8a00d5a",
     "skills/audit-log-multi-tenant/SKILL.md": "877871e609008ec04c805c3f1c6de494c80adc838285eae119a23355a13bbe48",
@@ -347,22 +351,26 @@
     "skills/postgres-isolamento-concorrencia/SKILL.md": "7398de91667f7701dd47d0f03800a2fd97ac15e9b13c52be9ac9171f9cf3d8f5",
     "skills/pre-refactor-characterization/SKILL.md": "9124f9ca0636a75474ea3f6d851e587be2f75505b3a835af0a4aaa0855bd20d3",
     "skills/production-readiness-review/SKILL.md": "2a9731265163c9fe7ba4fd05ceaf164ee4d1188b0d147ddff3b13bd9d3058c04",
-    "skills/rbac-permissions-matrix-supabase/SKILL.md": "7cf6aafe6d0de895165fb67649d54147341a4f103f13624c8981fe16d2c7d2c9",
+    "skills/rbac-permissions-matrix-supabase/SKILL.md": "8c0bf2b2f7935fdb3024954e797ac11604457a4646a61dc01eb06a985ee1eabd",
     "skills/release-engineering/SKILL.md": "01e69f50d2bb207d348552a01d0d69b6159b47573fe7e31aec53f6df52c3d057",
     "skills/retry-strategies/SKILL.md": "017a38146787592cde5c009bc06c8f483ca2b609a018d0b526972ddf5e46f52a",
     "skills/sre-risk-management/SKILL.md": "6e56a30b081abffbf9ce97e86b9c376361d6af765fe5475970f1646351c54e39",
     "skills/streams-eventos-cdc/SKILL.md": "64af5564e999ec0d8c3a0e1edbbea9f80a212d8ce8d03b0dfcf9c2db29b76d8f",
     "skills/structured-events/SKILL.md": "a693c8a19709066ea60860a01ba54731406d7daf41ed51adea9c29a2de131fac",
     "skills/supabase-auth-ssr/SKILL.md": "941d80ad88b4cbeccadf852d82f64f0167bce204005f72b32bc2aaf81a460af6",
+    "skills/supabase-column-level-security/SKILL.md": "0fcdac70be44ffbdccb56d5b0ca4f80c1267ddba037a757fcf969013754e521f",
     "skills/supabase-cron-queues/SKILL.md": "4f48ed9cea9b5b2bc187983ffbbb63f9e46ad65ff6a6306b5c8b4b01b4e6911a",
-    "skills/supabase-database-functions/SKILL.md": "9eaf17a5b75f3e8c398211f032a939fa4f7517c0453e977d84bf364f39cf550d",
+    "skills/supabase-custom-claims-rbac/SKILL.md": "2120bd49e0b6f1ee9723128654550836634f93dee5a80e6c6409fe96af223a0c",
+    "skills/supabase-database-functions/SKILL.md": "77b49f2930d61667e4ae1839944dbee012267253444aef63cc1dc24d227deff7",
     "skills/supabase-declarative-schema/SKILL.md": "8a78cae2d74287002c02bafdfb8218a9ac20b7d75047c269c702d9b8e3d22476",
     "skills/supabase-edge-functions/SKILL.md": "bf195e3fbce2bd94cb782ce15ecc60260217ac40d9ac5cbc787362de6629f960",
-    "skills/supabase-migrations/SKILL.md": "188c0a5d129e9eaeec5879cc89ae9ef248e0e414ef0c324afdb74e868ba7f428",
+    "skills/supabase-migrations/SKILL.md": "bd7a4e43e2c135d0f15f3ac4045c22e378b863b2c878c1895486cdfb39f4e968",
     "skills/supabase-pgvector-rag/SKILL.md": "cd50663c5b19d08d9bc17bc9b4444f7fc2f6910f5c52502e7c50b1578ebe7e70",
+    "skills/supabase-postgres-roles/SKILL.md": "eec741701e1f71b380c0275c318968d0674e20017437a00e39808b33115e62fa",
     "skills/supabase-postgres-style/SKILL.md": "4e48bd0a9ed46bea7c3be97ef749e5c148369ceca08ef3dc8d813d8a03a48703",
     "skills/supabase-realtime/SKILL.md": "ca2584a59742b30f5351fad23f4a1957218ca730ce3af990affe79f03854f460",
-    "skills/supabase-rls-policies/SKILL.md": "b8cab2e5813a00fea6aa19a59be94dfa536d675067c2e87c94576e97d472d16e",
+    "skills/supabase-rls-defense-in-depth/SKILL.md": "8881cac68fd72cf162dfc765baaffb0fa5d0f282d730792cdc05ab602cbe5efd",
+    "skills/supabase-rls-policies/SKILL.md": "eae0bc3ae5e775e72c767de9f721b87a044613e801304dad2389c33dd620995d",
     "skills/supabase-storage/SKILL.md": "f7360aa9149e55f68fa794a91c18994329e4f304cc263f90f0607e43053e9da8",
     "skills/super-admin-platform-pattern/SKILL.md": "aec4c25fd8f8314e6cd5b45037a56ccad5ef1599f09daa70d089b92ef2ac28df",
     "skills/telemetry-pipelines/SKILL.md": "7623244afdf8e6b0b865e572c8e8537c73255914a4562a95f99f22be7448f80e",

package/kit/skills/_shared-supabase/glossary.md

@@ -21,6 +21,33 @@
 | **authenticated** | Role para usuário autenticado. RLS aplicado normalmente. |
 | **public** | Role default — equivale a anon + authenticated juntos. Evite — sempre use `to authenticated` ou `to anon` explícito. |
 | **AAL** | Authentication Assurance Level. `aal1` = senha apenas; `aal2` = senha + 2FA. Verifica via `(auth.jwt()->>'aal')::text`. |
+| **defense-in-depth** (v1.23) | Defesa em profundidade — múltiplas camadas independentes de proteção RLS (policy + event trigger + GRANT explícito + bypass controlado + views security_invoker + service_role caveat). Princípio canônico contra esquecimento humano + third-party tooling. |
+| **hardener** (v1.23) | Agent `supabase-rls-hardener` (canônico v1.23) — recebe draft SQL via `Task()` upstream context + intent original e produz SQL final hardenado preservando intent. Verdicts: **GO** (já bom), **STRENGTHEN** (ajusta com diff), **REWRITE** (anti-pattern crítico, requer confirmação). NUNCA descarta upstream silenciosamente. |
+| **cooperative-handoff** (v1.23) | Pattern de handoff entre agents do kit em que agents externos (multi-tenant, debugger, planner, etc.) planejam/sugerem SQL via draft, e agents Supabase materializam o output final hardenado preservando intent upstream. Substitui pattern "BLOCK rígido" — não descarta tokens já gastos. |
+| **event-trigger-rls-auto-enable** (v1.23) | Event trigger Postgres (`rls_auto_enable`) registrado em `ddl_command_end` que ativa RLS automaticamente em `CREATE TABLE` em schemas configurados (`public` por default). Defense-in-depth contra esquecimento humano. Skill: `supabase-rls-defense-in-depth`. |
+| **bypassrls** (v1.23) | Privilégio Postgres `alter role <name> with bypassrls` que permite role bypass total de RLS sempre. Use para roles internos (`postgres`, custom admin role para scripts/cron). NUNCA conceda a role que recebe requisições de cliente. Alternativa Postgres-native ao service_role API key. |
+| **security_invoker** (v1.23) | Atributo de view em Postgres 15+ (`with (security_invoker = true)`) — faz a view respeitar RLS do role chamador, não do criador. Default views são `security_definer` e **bypassam** RLS — defense-in-depth Camada 5. |
+| **column-level privileges** (v1.24) | `GRANT/REVOKE (col1, col2) ON TABLE TO role` — privilégios granulares por coluna. Subset do table-level. Feature AVANÇADA — usar apenas com PII real (LGPD/GDPR), audit log payload, billing, tokens. Camada 8 de defense-in-depth. |
+| **table-level privileges** (v1.24) | `GRANT/REVOKE ON TABLE TO role` — privilégio em **todas** colunas da tabela. Default em CREATE TABLE. Mais permissivo que column-level — quando ambos existem, table-level prevalece (mais permissivo vence). |
+| **wildcard restriction** (v1.24) | Restricted roles (com column-level privilege em apenas algumas colunas) **NÃO** podem usar `SELECT *` — falha com "permission denied for column". Devem listar colunas explicitamente. Aplicação prática: `supabase.from(t).select()` falha; use `.select('col1, col2, col3')`. |
+| **dedicated role table pattern** (v1.24) | Tabela `user_roles` com flags booleans (`is_admin`, `can_view_pii`, etc.) + helper function PG (`public.can_view_pii()` STABLE) consultada em RLS policies. Alternativa **PREFERIDA** ao column-level privileges para casos comuns (admin/user roles). Dinâmico, auditável, sem caveat de wildcard. Recomendado pela doc oficial Supabase. |
+| **column privilege auditing** (v1.24) | Query SQL em `information_schema.column_privileges` para detectar tabelas com colunas potencialmente sensíveis (PII via keyword match: email, phone, ssn, cpf, token, password, credit_card, bank_account, salary, payload) sem column-level GRANT/REVOKE. Usado por Detector 8 do `supabase-rls-hardener` (v1.24). |
+| **custom claims** (v1.25) | Claims customizados injetados no JWT via Custom Access Token Auth Hook durante geração do token. Exemplo canônico: `user_role` adicionado em `claims->>'user_role'` para uso em RLS policies via `authorize()` function. Alternativa moderna a helper function STABLE com JOIN. Camada 9 de defense-in-depth. |
+| **Custom Access Token Auth Hook** (v1.25) | Função Postgres (`custom_access_token_hook(event jsonb) returns jsonb`) invocada pelo Supabase Auth service ANTES de issuing token JWT. Recebe event com user_id + claims atuais, retorna event modificado com claims adicionais. Habilitada via Dashboard (Auth > Hooks Beta) ou config.toml local. |
+| **JWT user_role claim** (v1.25) | Claim canônico `user_role` no JWT (string ou null) lido via `auth.jwt() ->> 'user_role'` em RLS policies ou via `jwt-decode` no cliente. Delivered por Custom Access Token Auth Hook. Eventually consistent — refresh TTL 1h. |
+| **authorize() function** (v1.25) | Função `public.authorize(requested_permission app_permission) returns boolean` — lê `user_role` do JWT e checa permission em `role_permissions` table. `security definer + set search_path = '' + stable`. Pattern canônico para policies: `using ((SELECT authorize('channels.delete')))`. |
+| **supabase_auth_admin role** (v1.25) | Postgres role usado pelo Supabase Auth service ao invocar Auth Hooks (Custom Access Token, etc.). Precisa de GRANTs específicos: `GRANT USAGE ON SCHEMA public`, `GRANT EXECUTE ON FUNCTION <hook>`, `GRANT ALL ON TABLE user_roles`, + RLS policy permissive permitindo SELECT em user_roles. Hook function deve `REVOKE EXECUTE FROM authenticated, anon, public`. |
+| **app_role enum** (v1.25) | Enum Postgres canônico para roles aplicação (`create type public.app_role as enum (...)`). Exemplo: `('admin', 'moderator', 'user')`. Type-safe, refactorable. Caveat: `ALTER TYPE ADD VALUE` não pode ser feito dentro de transação Postgres. |
+| **app_permission enum** (v1.25) | Enum Postgres canônico para permissions formato `<resource>.<action>` (`create type public.app_permission as enum (...)`). Exemplo: `('channels.delete', 'channels.create', 'messages.delete', 'users.ban')`. Consultado por `authorize()` function. |
+| **jwt-decode client pattern** (v1.25) | Package npm `jwt-decode` para decodificar JWT access_token no cliente JavaScript. Usado dentro de `onAuthStateChange` listener para acessar custom claims após login/refresh. Caveat: apenas decode (NÃO valida assinatura) — para validação server-side use `@supabase/ssr` `getUser()`. |
+| **Postgres roles** (v1.26) | Entidades Postgres que podem ter permissions. Podem ser **users** (com LOGIN) ou **groups** (sem LOGIN). Para **system access** (cron jobs, BI tools, ETL, admin scripts). NÃO usar para application access (use RLS + Custom Claims v1.25). Camada 10 de defense-in-depth. |
+| **INHERIT / NOINHERIT** (v1.26) | INHERIT (default): child role herda permissions do parent automaticamente. NOINHERIT: child role precisa `SET ROLE parent` explícito para usar permissions. NOINHERIT preferido para roles superuser-like (audit trail mais claro). |
+| **LOGIN PASSWORD** (v1.26) | `create role "name" with login password 'pwd'` — cria role que pode autenticar via senha. Best practices: 12+ chars, password manager, mixed case+symbols, percent-encode em connection string. Sem LOGIN, role é group para hierarchy. |
+| **GRANT/REVOKE syntax** (v1.26) | `GRANT <permission> ON <object> TO <role>` / `REVOKE <permission> ON <object> FROM <role>`. Permission types: SELECT, INSERT, UPDATE, DELETE, EXECUTE, USAGE. Objects: tables, views, functions, schemas, sequences. Use `ALTER DEFAULT PRIVILEGES` para tabelas futuras. |
+| **role hierarchy** (v1.26) | Padrão Postgres de role inheritance via `GRANT <parent_role> TO <child_role>`. Multi-level (readers ← admins ← bob). Simplifica permission management. Combine com NOINHERIT para superuser roles. |
+| **predefined Supabase roles** (v1.26) | 10 roles configurados automaticamente em todo projeto Supabase: `postgres` (admin), `anon` (unauthenticated), `authenticator` (PostgREST switch), `authenticated` (logged-in), `service_role` (bypass RLS), `supabase_auth_admin` (Auth middleware), `supabase_storage_admin` (Storage middleware), `supabase_etl_admin` (Replication), `dashboard_user` (UI), `supabase_admin` (internal). NÃO criar substitutos — documentar uso direto. |
+| **role switching authenticator** (v1.26) | PostgREST recebe JWT, valida via `authenticator` role, e switches para `anon` ou `authenticated` baseado em claims. `authenticator` tem acesso muito limitado — apenas SWITCH ROLE. Pattern interno do Supabase. |
+| **percent-encoding password** (v1.26) | Special symbols em password Postgres precisam ser percent-encoded em connection string URL (`=` → `%3D`, `&` → `%26`, `+` → `%2B`, `#` → `%23`, `:` → `%3A`, `/` → `%2F`, `@` → `%40`, space → `%20`). Necessário em `postgresql://user:p%3Dssword@host/db`. |
 
 ### Database e Schema
 

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

@@ -222,6 +222,43 @@ create policy "members_update_role_with_permission"
   );
 ```
 
+## Mecanismo de delivery dos claims (v1.25 update)
+
+Os patterns acima usam **helper function PG STABLE** (`private.has_permission(action, resource, org_id)`) que faz JOIN em `role_permissions` table dentro de cada policy evaluation. Funciona bem para casos multi-tenant complexos (role depende de org context) mas adiciona JOIN custoso em policies hot.
+
+A partir de **v1.25**, kit-mcp adiciona alternativa moderna via **Custom Access Token Auth Hook** (skill [`supabase-custom-claims-rbac`](../supabase-custom-claims-rbac/SKILL.md)) que injeta `user_role` direto no JWT — RLS policies leem o claim via `authorize(permission)` sem JOIN.
+
+**Comparação canônica (v1.25):**
+
+| | Helper function STABLE (v1.21) | Custom Claim via Auth Hook (v1.25) |
+|---|---|---|
+| Performance | JOIN em role_permissions por query | Zero-JOIN — claim no JWT |
+| Multi-tenant context | ✅ `has_permission('update', 'members', org_id)` — context-aware | ❌ Claim é per-user, não per-org-context |
+| Mudança em real-time | ✅ Imediata (UPDATE em role_permissions reflete) | ⚠ Eventually consistent (TTL refresh 1h) |
+| Type safety | String permission `'update:members'` | Enum `app_permission` |
+| Setup complexity | Média (helper function + RLS) | Alta (auth hook + auth_admin grants + jwt-decode cliente) |
+
+**Recomendação canônica v1.25 para B2B multi-tenant:**
+
+**Combine ambos:**
+- **Custom claim** para role global (`super_admin`, `org_owner`) — zero-JOIN, fácil consulta cliente
+- **Helper function STABLE** para context-aware (`has_permission(action, resource, org_id)`) — quando role muda por org
+
+Exemplo de policy combinada:
+
+```sql
+create policy "members_select" on public.members for select
+to authenticated
+using (
+  -- claim no JWT (zero-JOIN, fast path)
+  (SELECT authorize('members:read'))
+  -- OU helper function PG (context-aware, slow path)
+  or private.has_permission('read', 'members', org_id)
+);
+```
+
+Pattern detalhado em [`supabase-custom-claims-rbac`](../supabase-custom-claims-rbac/SKILL.md) (v1.25) section "Cross-suite integration".
+
 ## Anti-patterns
 
 ### Anti-pattern 1: Permission string sem padrão

package/kit/skills/supabase-column-level-security/SKILL.md

@@ -0,0 +1,426 @@
+---
+name: supabase-column-level-security
+description: Use ao implementar Column-Level Security (CLS) em Supabase — complementa RLS com privilégios granulares por coluna via GRANT/REVOKE (col1, col2) ON TABLE. Feature AVANÇADA — para maioria dos casos, prefira RLS + dedicated role table. Caveats canônicos (wildcard * restriction, impacto cross-operation) + integração com RLS row-level. v1.24 incorpora 100% da doc oficial Supabase.
+---
+
+# Supabase — Column Level Security
+
+## ⚠ Quando usar (e quando NÃO usar)
+
+**Column-Level Security é feature AVANÇADA.** Para a maioria dos casos de controle de acesso, **NÃO** recomendamos column-level privileges. Prefira:
+
+1. **RLS policies row-level** (skill [`supabase-rls-policies`](../supabase-rls-policies/SKILL.md)) — primeira linha de defesa
+2. **Dedicated role table** — tabela `user_roles` com `is_admin`, `can_edit_billing`, etc.; RLS consulta esta tabela em policies; permite mudança dinâmica de roles sem reescrever GRANT/REVOKE
+
+**Use column-level privileges APENAS quando:**
+
+- **Compliance LGPD/GDPR** exige restrição granular por coluna (PII columns como SSN, CPF, salary)
+- **Audit log sanitization** — coluna `payload` da audit_log deve ser legível só por security_admin
+- **Billing data restrito** — `credit_card_token`, `bank_account` lisíveis apenas pelo billing_admin role
+- **Token raw em tabelas** — `org_invites.token_raw` (apenas service_role) — depois TTL, hash apenas
+
+**NÃO use para:**
+
+- Hide/show colunas por user role normal (use view + RLS ao invés)
+- Filtrar dados por linha (isso é RLS, não CLS)
+- "Esconder" colunas no UI (cliente sempre vê o schema; CLS apenas restringe acesso runtime)
+
+Trigger phrases:
+
+- "column-level privileges", "column privileges Postgres"
+- "GRANT (col) ON TABLE", "REVOKE (col) FROM role"
+- "PII column restriction"
+- "audit log payload column protected"
+
+## Princípio canônico
+
+Postgres tem **dois níveis** de privileges:
+
+1. **Table-level (`GRANT/REVOKE ON TABLE`)** — default, aplica a todas colunas
+2. **Column-level (`GRANT/REVOKE (col1, col2) ON TABLE`)** — granular por coluna; **subset** do table-level
+
+**Hierarquia:** se você tem table-level `UPDATE` + column-level `UPDATE (title)` simultaneamente, o table-level **prevalece** (mais permissivo vence). Para restringir, você precisa **REVOKE table-level primeiro**, depois **GRANT column-level apenas nas colunas permitidas**.
+
+```sql
+-- ANTES: authenticated tem table-level UPDATE (default)
+-- pode UPDATE todas colunas
+
+-- PASSO 1: REVOKE table-level (perde acesso a TODAS colunas)
+revoke update on table public.posts from authenticated;
+
+-- PASSO 2: GRANT column-level apenas em title + content
+grant update (title, content) on table public.posts to authenticated;
+
+-- AGORA: authenticated só pode UPDATE title + content
+-- tentativa de UPDATE em user_id, created_at, etc. falha com "permission denied for column"
+```
+
+## ⚠ Caveat #1 — Wildcard `*` restriction
+
+**Restricted roles NÃO podem usar `SELECT *`.** Se uma role tem column-level privilege em **apenas algumas colunas** (não todas), `SELECT * FROM <table>` falha com:
+
+```
+ERROR: permission denied for column <restricted_col>
+```
+
+**Implicação prática:**
+
+```sql
+-- restrict authenticated role a apenas alguns SELECTs
+revoke select on table public.posts from authenticated;
+grant select (id, title, content) on table public.posts to authenticated;
+
+-- depois disso:
+-- ❌ select * from posts;  -- FALHA (tenta acessar created_at, user_id, etc.)
+-- ✅ select id, title, content from posts;  -- OK
+```
+
+**Aplicação em SDK Supabase:**
+
+```js
+// errado — usa wildcard implícito quando você omite columns
+const { data } = supabase.from('posts').select()  // SELECT * by default
+
+// certo — sempre liste colunas explicitamente em tabelas com column-level
+const { data } = supabase.from('posts').select('id, title, content')
+```
+
+**Defensive practice:** em tabelas com qualquer column-level privilege, **NUNCA** use `.select()` sem argumento. Sempre `.select('col1, col2, col3')`.
+
+## ⚠ Caveat #2 — Impacto cross-operation
+
+Quando você restringe uma coluna, **todas as operações** que tocam essa coluna falham:
+
+- **SELECT** — `SELECT col_restricted` falha; `SELECT *` também falha (wildcard)
+- **INSERT** — `INSERT (col_restricted) VALUES (...)` falha se role não tem `INSERT (col_restricted)`
+- **UPDATE** — `UPDATE SET col_restricted = ...` falha
+- **DELETE** — opera no nível de linha, NÃO afetado por column privileges (DELETE bypassa column check)
+
+**Exemplo concreto:**
+
+```sql
+revoke update (price) on table public.products from authenticated;
+
+-- depois disso:
+-- ❌ update products set price = 100 where id = 1;  -- FALHA
+-- ❌ update products set title = 'x', price = 100;  -- FALHA (price restringido)
+-- ✅ update products set title = 'x';                -- OK (não toca price)
+-- ✅ delete from products where price > 50;         -- OK (DELETE ignora column priv)
+-- ❌ select * from products;                         -- FALHA se SELECT (price) revoked tb
+```
+
+**Implicação para INSERT:** mesmo em INSERT, role precisa ter privilege em **todas as colunas que vão receber valor** (incluindo defaults explícitos).
+
+## Patterns canônicos
+
+### Pattern 1 — Restringir UPDATE em colunas específicas
+
+```sql
+-- caso: post.title e post.content podem ser editados pelo owner
+-- mas user_id e created_at NÃO podem ser mudados
+
+-- 1. REVOKE table-level UPDATE
+revoke update on table public.posts from authenticated;
+
+-- 2. GRANT column-level UPDATE apenas onde é seguro
+grant update (title, content, updated_at) on table public.posts to authenticated;
+
+-- 3. RLS row-level garante que só o owner pode editar (combinação canônica)
+create policy "users_update_own_posts"
+  on public.posts for update
+  to authenticated
+  using (
+    (select auth.uid()) is not null
+    and (select auth.uid()) = user_id
+  )
+  with check (
+    (select auth.uid()) is not null
+    and (select auth.uid()) = user_id
+  );
+```
+
+### Pattern 2 — Restringir SELECT em PII columns
+
+```sql
+-- caso: tabela users tem ssn (sensitive) — visível APENAS para security_admin role
+
+-- 1. criar role específico (skill `supabase-rls-defense-in-depth` Camada 2)
+create role security_admin with login password '<strong>';
+
+-- 2. REVOKE table-level SELECT de roles padrão
+revoke select on table public.users from anon, authenticated;
+
+-- 3. GRANT column-level SELECT apenas em colunas não-sensíveis para authenticated
+grant select (id, email, display_name, created_at) on table public.users to authenticated;
+
+-- 4. GRANT table-level SELECT (acesso total) APENAS para security_admin
+grant select on table public.users to security_admin;
+
+-- 5. RLS row-level continua aplicada (ex: user vê apenas próprio registro)
+create policy "users_select_own" on public.users for select to authenticated
+  using ((select auth.uid()) = id);
+
+-- IMPORTANTE: cliente precisa usar select('id, email, display_name, created_at') — não select(*)
+```
+
+### Pattern 3 — Audit log com payload protegido
+
+```sql
+-- caso: audit_log tem payload jsonb com PII; só security_admin vê payload completo
+
+revoke select on table public.audit_log from authenticated;
+
+grant select (id, event_type, user_id, org_id, occurred_at) on table public.audit_log to authenticated;
+
+grant select on table public.audit_log to security_admin;  -- payload visível só aqui
+
+-- bonus: combine com RLS row-level (user vê só audit_log da própria org)
+create policy "audit_log_select_own_org" on public.audit_log for select to authenticated
+  using (
+    org_id::text = any(
+      select jsonb_array_elements_text((select auth.jwt()->'app_metadata'->'orgs'))
+    )
+  );
+```
+
+### Pattern 4 — Token raw em invites (apenas service_role)
+
+```sql
+-- caso: org_invites.token_raw é gerado durante create, hash armazenado, raw enviado por email
+-- depois, nenhum role além de service_role deve poder ler o raw (cross-ref invite-flow-implementer)
+
+revoke select on table public.org_invites from anon, authenticated;
+
+-- nem authenticated nem anon podem ver token_raw
+grant select (id, org_id, email, status, expires_at, created_at) on table public.org_invites to authenticated;
+
+-- service_role vê tudo (incluindo token_raw) — usado durante envio de email
+grant select on table public.org_invites to service_role;
+```
+
+## Dedicated role table pattern (RECOMENDADO pela doc oficial)
+
+Em vez de column-level privileges complexos, prefira a abordagem canônica:
+
+```sql
+-- 1. tabela de roles
+create table public.user_roles (
+  user_id uuid primary key references auth.users (id),
+  is_admin boolean default false,
+  can_view_pii boolean default false,
+  can_edit_billing boolean default false
+);
+
+-- 2. RLS na tabela de roles (só service_role pode mutar)
+alter table public.user_roles enable row level security;
+create policy "users_view_own_role" on public.user_roles for select to authenticated
+  using ((select auth.uid()) = user_id);
+
+-- 3. helper function
+create or replace function public.can_view_pii()
+returns boolean
+language sql
+stable
+as $$
+  select coalesce(
+    (select can_view_pii from public.user_roles where user_id = (select auth.uid())),
+    false
+  );
+$$;
+
+-- 4. usar em RLS policies (sem column-level)
+create policy "select_users_with_pii" on public.users for select to authenticated
+  using (public.can_view_pii());
+```
+
+**Vantagens vs column-level:**
+
+- **Dinâmico:** roles mudam via UPDATE simples (`update user_roles set can_view_pii = true where user_id = ...`); column-level exige REVOKE/GRANT
+- **Auditável:** mudanças em user_roles ficam em audit_log; mudanças em GRANT são silent
+- **Sem caveat de wildcard:** `select *` funciona; column-level força listar colunas
+- **Composable:** combinar múltiplos predicados em policy é mais expressivo que multi-column GRANT
+- **Self-service:** users podem ver próprio role; column privileges não tem auto-discovery
+
+**Quando column-level continua melhor:**
+
+- Defesa em profundidade adicional (camada extra além de RLS) — Camada 8 de defense-in-depth (skill [`supabase-rls-defense-in-depth`](../supabase-rls-defense-in-depth/SKILL.md))
+- Compliance exige restrição **no banco** (não apenas na app) — ex: LGPD audit
+- Third-party tooling acessa banco direto (Metabase, dbt) — column-level protege mesmo sem app
+
+## Studio Dashboard (Supabase UI)
+
+A UI de column-level privileges fica em **Feature Preview** no dashboard Supabase (intencionalmente escondida — recomendação implícita de não usar):
+
+```
+Dashboard → Database → Column Privileges
+(Feature Preview)
+```
+
+**Caveat:** Studio UI permite mudanças mas **não versiona** — mudanças via UI não geram migration automática. Para projetos sérios, gerencie via migrations (`supabase migration new`) — ver pattern em skill [`supabase-migrations`](../supabase-migrations/SKILL.md) BLOCO 6 (v1.24).
+
+## Manage column privileges in migrations
+
+Pattern canônico para uma migration completa com column-level:
+
+```sql
+/*
+  Migration: create_posts_with_column_privileges
+  Created: 2026-05-11
+  Purpose: Create posts table with row-level + column-level security
+  Affects: public.posts (new), policies (new), column privileges (new)
+*/
+
+-- BLOCO 1: CREATE TABLE
+create table public.posts (
+  id bigint primary key generated always as identity,
+  user_id uuid references auth.users (id),
+  title text,
+  content text,
+  created_at timestamptz default now(),
+  updated_at timestamptz default now()
+);
+
+-- BLOCO 2: GRANTs table-level (default)
+grant select on public.posts to anon;
+grant select, insert, update, delete on public.posts to authenticated;
+grant select, insert, update, delete on public.posts to service_role;
+
+-- BLOCO 3: ENABLE RLS
+alter table public.posts enable row level security;
+
+-- BLOCO 4: RLS policies row-level
+create policy "users_update_own_posts" on public.posts for update
+  to authenticated
+  using ((select auth.uid()) = user_id);
+
+-- BLOCO 5: Index
+create index posts_user_id_idx on public.posts (user_id);
+
+-- BLOCO 6 (v1.24): Column-Level Privileges (OPCIONAL — apenas se PII)
+-- REVOKE table-level UPDATE de authenticated (perde acesso a TODAS colunas)
+revoke update on table public.posts from authenticated;
+
+-- GRANT column-level UPDATE apenas em title + content
+grant update (title, content, updated_at) on table public.posts to authenticated;
+
+-- service_role mantém acesso total (não precisa GRANT extra — já tem)
+```
+
+## Auditoria — detectar tabelas com PII sem column privileges
+
+```sql
+-- listar tabelas com colunas potencialmente sensíveis sem column-level GRANT/REVOKE
+select
+  c.table_schema,
+  c.table_name,
+  c.column_name,
+  c.data_type
+from information_schema.columns c
+where c.table_schema = 'public'
+  and (
+    c.column_name ilike '%email%'
+    or c.column_name ilike '%phone%'
+    or c.column_name ilike '%ssn%'
+    or c.column_name ilike '%cpf%'
+    or c.column_name ilike '%token%'
+    or c.column_name ilike '%password%'
+    or c.column_name ilike '%credit_card%'
+    or c.column_name ilike '%bank_account%'
+    or c.column_name ilike '%salary%'
+  )
+  and not exists (
+    -- check se há column_privilege específico para esta coluna
+    select 1
+    from information_schema.column_privileges p
+    where p.table_schema = c.table_schema
+      and p.table_name = c.table_name
+      and p.column_name = c.column_name
+  )
+order by c.table_schema, c.table_name, c.column_name;
+```
+
+Cross-ref auditoria sistemática em agent [`supabase-rls-hardener`](../../agents/supabase-rls-hardener.md) Detector 8 (v1.24).
+
+## Anti-patterns
+
+### Anti-pattern 1 — Column-level sem revoke table-level prévio
+
+**Errado:**
+```sql
+-- column-level GRANT sem revoke table-level
+grant update (title) on table public.posts to authenticated;
+-- authenticated AINDA pode update todas colunas (table-level vence)
+```
+
+**Por quê:** Postgres aplica privilege mais permissivo — column-level GRANT sem REVOKE table-level prévio é no-op.
+
+**Certo:**
+```sql
+revoke update on table public.posts from authenticated;
+grant update (title) on table public.posts to authenticated;
+```
+
+### Anti-pattern 2 — Esperar que `SELECT *` funcione com column-level
+
+**Errado:**
+```sql
+revoke select (sensitive_col) on table public.users from authenticated;
+-- esperar que select * automaticamente skipe sensitive_col — NÃO FUNCIONA
+```
+
+```js
+const { data } = supabase.from('users').select()  // SELECT * — FALHA
+```
+
+**Por quê:** Postgres aplica permission check à query inteira. `SELECT *` é `SELECT col1, col2, ..., sensitive_col` expandido — falha se qualquer coluna sem permission.
+
+**Certo:** sempre listar colunas explicitamente:
+```js
+const { data } = supabase.from('users').select('id, email, display_name')
+```
+
+### Anti-pattern 3 — Column-level em vez de dedicated role table
+
+**Errado (para caso "admin vê PII"):**
+```sql
+revoke select (ssn, salary) on table public.employees from authenticated;
+-- agora você precisa criar role separado, granular GRANT a cada admin, etc.
+```
+
+**Por quê:** muda admin = REVOKE/GRANT manual; sem audit trail; sem self-discovery.
+
+**Certo:** dedicated role table + RLS function — ver section "Dedicated role table pattern (RECOMENDADO)" acima.
+
+### Anti-pattern 4 — Column-level em INSERT esquecendo DEFAULTs
+
+**Errado:**
+```sql
+revoke insert on table public.audit_log from authenticated;
+grant insert (event_type, payload) on table public.audit_log to authenticated;
+
+-- código tenta:
+insert into audit_log (event_type, payload) values ('login', '{}');
+-- FALHA porque user_id (PK default gen_random_uuid) também precisa de GRANT
+```
+
+**Certo:** lista TODAS colunas que recebem valor (incluindo defaults gerados):
+```sql
+grant insert (event_type, payload, user_id, occurred_at) on table public.audit_log to authenticated;
+```
+
+Ou prefira que cliente não faça INSERT direto — use RPC function `SECURITY DEFINER` que tem privilege total.
+
+## Cross-suite integration (v1.24)
+
+Esta skill é base para o agent novo `supabase-column-privileges-writer` (Phase 133) — recebe spec de table + colunas sensíveis via `Task()` e produz REVOKE/GRANT column-level SQL preservando intent upstream.
+
+Princípio canônico v1.23 (herdado): agents não-Supabase pensam/planejam; agents Supabase materializam/hardenam; ninguém descarta upstream. Para column-level, o agent canonical é `supabase-column-privileges-writer`.
+
+## Ver também
+
+- [supabase-rls-policies](../supabase-rls-policies/SKILL.md) (v1.23) — RLS row-level (primeira camada de defesa)
+- [supabase-rls-defense-in-depth](../supabase-rls-defense-in-depth/SKILL.md) (v1.23) — column-level é Camada 8 de defesa em profundidade (v1.24)
+- [supabase-migrations](../supabase-migrations/SKILL.md) (v1.24) — BLOCO 6 opcional com column-level no template canônico
+- [supabase-column-privileges-writer](../../agents/supabase-column-privileges-writer.md) (v1.24) — agent canonical materializador
+- [supabase-rls-hardener](../../agents/supabase-rls-hardener.md) (v1.23) — Detector 8 valida column-level em tabelas com PII (v1.24)
+- [glossário compartilhado](../_shared-supabase/glossary.md) — termos column-level privileges, table-level privileges, wildcard restriction, dedicated role table pattern