@luanpdd/kit-mcp 1.22.0 → 1.26.0

package/README.md

@@ -24,7 +24,7 @@ Inspired by [vinilana/dotcontext](https://github.com/vinilana/dotcontext) — se
 ---
 
 <!-- AUTOGEN-COUNTS-START -->
-**Bundled workflow:** 60 agents · 89 commands · 67 skills · 23 gates
+**Bundled workflow:** 64 agents · 89 commands · 71 skills · 23 gates
 <!-- AUTOGEN-COUNTS-END -->
 
 ## What ships in the box
@@ -165,6 +165,272 @@ A production engineering layer derived from *Site Reliability Engineering: How G
 
 ---
 
+## Slash Commands Reference (89 commands)
+
+Comandos do kit são organizados em **workflow lifecycle** (brownfield planning canônico) + **8 suítes especializadas** (Supabase, Observability, SRE, Legacy, Multi-Tenant, DDIA, etc.) + **quick actions** + **utilities**.
+
+### Workflow Lifecycle (brownfield planning)
+
+O fluxo canônico de um projeto: bootstrap → milestone → phase → execute → audit → publish.
+
+| Comando | Objetivo |
+|---------|----------|
+| `/novo-projeto` | Inicializa novo projeto com coleta profunda de contexto e PROJECT.md |
+| `/novo-marco` | Inicia novo ciclo de milestone — atualiza PROJECT.md, encaminha para requisitos |
+| `/novo-workspace` | Cria workspace isolado com cópias de repos e .planning/ independente |
+| `/discutir-fase N` | Reúne contexto da fase por questionamento adaptativo antes do planejamento |
+| `/listar-hipoteses-fase N` | Mostra hipóteses do Claude sobre abordagem antes do planejamento |
+| `/planejar-fase N` | Cria plano detalhado da fase (PLAN.md) com loop de verificação |
+| `/pesquisar-fase N` | Pesquisa como implementar uma fase (standalone — geralmente use planejar) |
+| `/executar-fase N` | Executa todos os planos de uma fase com paralelização por ondas |
+| `/autonomo` | Executa todas as fases restantes autônomamente — discuss→plan→execute por fase |
+| `/auditar-marco` | Audita conclusão do milestone contra intenção original antes de arquivar |
+| `/concluir-marco` | Arquiva milestone concluído, cria tag git, prepara para próxima versão |
+| `/publicar` | Publica milestone — cria doc no Notion, abre PR no GitHub com link |
+| `/publicar-rapido` | Variante leve do publicar para hotfix/quick-task — sem ROADMAP dependency |
+| `/branch-pr` | Cria branch limpo para PR filtrando commits de .planning/ |
+
+### Phase Lifecycle (gerenciar fases)
+
+| Comando | Objetivo |
+|---------|----------|
+| `/adicionar-fase` | Adiciona fase ao final do milestone atual no roadmap |
+| `/inserir-fase` | Insere trabalho urgente como fase decimal (ex: 72.1) entre fases existentes |
+| `/remover-fase N` | Remove fase futura do roadmap e renumera subsequentes |
+| `/planejar-lacunas` | Cria fases para fechar lacunas identificadas pela auditoria de milestone |
+| `/validar-fase N` | Audita retroativamente e preenche lacunas de validação para fase concluída |
+| `/adicionar-testes N` | Gera testes para fase concluída com base em UAT + implementação |
+| `/auditar-uat` | Auditoria multi-fase de todos itens de UAT e verificação pendentes |
+| `/verificar-trabalho` | Valida funcionalidades construídas através de UAT conversacional |
+| `/pausar-trabalho` | Cria handoff de contexto ao pausar trabalho no meio de uma fase |
+| `/retomar-trabalho` | Retoma trabalho da sessão anterior com restauração completa de contexto |
+
+### Suite `/supabase` (v1.8 + v1.23-v1.26 — 4 camadas de segurança canônicas)
+
+Orquestrador `/supabase <subcomando>` com 14 subcomandos (sinônimos PT/EN). Toda a trilha de segurança Supabase canônica está implementada.
+
+| Subcomando | Objetivo | Cross-ref |
+|------------|----------|-----------|
+| `/supabase arquiteto` | Projeta schema + RLS + topologia realtime ANTES da implementação | v1.8 |
+| `/supabase migration` | Escreve migration SQL com 5 blocos obrigatórios + auto-chain hardener | v1.23 |
+| `/supabase rls` | Gera RLS policies granulares com GRANT + IS NOT NULL + views security_invoker | v1.23 |
+| `/supabase hardener` | Canonical materializer RLS — recebe draft via Task, verdicts GO/STRENGTHEN/REWRITE | v1.23 |
+| `/supabase column` | Column-Level privileges (REVOKE table-level + GRANT (col)) — PII/audit/billing | v1.24 |
+| `/supabase rbac` | Custom Claims via Auth Hook (enum + user_roles + auth hook + authorize() function) | v1.25 |
+| `/supabase role` | Postgres Roles (CREATE ROLE + INHERIT/NOINHERIT + GRANT/REVOKE) — system access | v1.26 |
+| `/supabase edge` | Escreve Deno Edge Functions com imports npm:/jsr: + env vars + EdgeRuntime |  |
+| `/supabase realtime` | Configura canais Realtime — broadcast com private:true + RLS sobre realtime.messages |  |
+| `/supabase auth` | Bootstrap Next.js v16 + Supabase Auth com @supabase/ssr + jwt-decode listener |  |
+| `/supabase storage` | Configura buckets (públicos vs privados) + signed URLs + RLS sobre storage.objects |  |
+| `/supabase rag` | Edge Function com embeddings + pgvector (HNSW/IVFFlat + RLS with permissions) |  |
+| `/supabase cron` | Pattern `pg_cron + pgmq + pg_net` (cron → pgmq → Edge Function) |  |
+| `/supabase check` | Valida SQL antes de apply (schema-checker — FKs/colunas/tabelas referenciadas) |  |
+
+### Suite `/observabilidade` (v1.9)
+
+| Comando | Objetivo |
+|---------|----------|
+| `/observabilidade <sub>` | Orquestrador — dispatcha para instrumenter, investigator, slo-engineer, burn-rate-forecaster, omm-auditor |
+| `/instrumentar-fase N` | Após `/planejar-fase`, gera INSTRUMENTATION.md por plano (spans + atributos canônicos) |
+| `/investigar-producao` | Core Analysis Loop guiado em incidente real — estado persistente em `.planning/investigations/` |
+| `/definir-slo` | Gera SLO.md + SQL para materializar SLI events em view/MV no Postgres |
+| `/burn-rate-status` | Tabela dual-window por SLO (fast 1h + slow 6h) — page/ticket/warn alerts |
+| `/auditar-observabilidade` | OMM-REPORT.md scored em 5 capacidades (resiliência/qualidade/complexidade/cadência/comportamento) |
+| `/auditar-observabilidade-cobertura` | X/N Edge Functions com 4 golden signals + Y/N com SLO + Z/N com burn alert |
+
+### Suite `/sre` (v1.10 + v1.11)
+
+| Comando | Objetivo |
+|---------|----------|
+| `/sre <sub>` | Orquestrador — dispatcha para golden-signals-instrumenter, toil-auditor, postmortem-writer, prr-conductor, etc. |
+| `/golden-signals` | Instrumenta serviço/Edge Function com 4 golden signals OTel (Latency/Traffic/Errors/Saturation) |
+| `/auditar-toil` | Identifica toil no projeto (6 critérios canônicos) + sugere automação via pg_cron |
+| `/auditar-cascading` | Audita código para 5 triggers de cascading failure (sem timeout, retry sem jitter, etc.) |
+| `/auditar-release` | Audita CI/CD para hermeticidade + reprodutibilidade + policy enforcement |
+| `/load-shedding` | Aplica patches de load shedding em Edge Function/handler HTTP (drop policy, deadline-aware) |
+| `/postmortem` | Postmortem blameless 9 seções (modo `--from-investigation` ou `--incident`) |
+| `/prr` | Production Readiness Review scored em 6 axes (System/Instrumentation/Emergency/Capacity/Change/Performance) |
+| `/risk-budget` | Error budget atual vs risk continuum (cap 3 SRE) — posiciona no continuum 99% → 99.999% |
+
+### Suite `/legacy` (v1.12 — Working Effectively with Legacy Code, Feathers 2004)
+
+| Comando | Objetivo |
+|---------|----------|
+| `/legacy <sub>` | Orquestrador — dispatcha para legacy-characterizer, seam-finder, refactor-safety-auditor |
+| `/caracterizar` | Gera characterization tests (cap 13 Feathers) — golden snapshots como oracle imutável |
+| `/caracterizar-prompt` | Characterization de prompts/tools LLM em produção — temperature=0 + seed fixo |
+| `/encontrar-seams` | Analisa código para identificar seams (object/link/preprocessing) — pré-requisito refactor |
+| `/auditar-refactor` | Gate canônico ANTES de refactor — veredito GO/BLOCK/WARN |
+| `/refactor-seguro` | Chain canônico — encontrar-seams → caracterizar → auditar-refactor → executar |
+| `/capturar-payloads` | Instrumenta Edge Function para captura via mcp__supabase__get_logs por N dias |
+| `/detectar-duplicacao` | Shotgun surgery — duplicação sintática (jscpd/regex) + semântica (embeddings) |
+| `/storytelling` | IA gera mental model de codebase desconhecido (story 5 frases + naked CRC) |
+
+### Suite `/multi-tenant` (v1.21) e `/dados-distribuidos` (v1.22)
+
+| Comando | Objetivo |
+|---------|----------|
+| `/multi-tenant <sub>` | Orquestrador B2B SaaS — 10 agents implementers (architect, rls, onboarding, invite, super-admin, audit-log, whatsapp, crm, lgpd, isolation-audit) |
+| `/dados-distribuidos <sub>` | Orquestrador DDIA Foundations — auditor-consistencia-isolamento, detector-tenant-quente, validador-evolucao-schema |
+
+### UI Phase (frontend design contract)
+
+| Comando | Objetivo |
+|---------|----------|
+| `/fase-ui N` | Gera contrato de design UI (UI-SPEC.md) para fases frontend |
+| `/revisar-ui N` | Auditoria visual retroativa de 6 pilares do código frontend implementado |
+
+### Backlog & Ideas
+
+| Comando | Objetivo |
+|---------|----------|
+| `/adicionar-backlog` | Adiciona ideia ao estacionamento de backlog (numeração 999.x) |
+| `/revisar-backlog` | Revisa e promove itens do backlog para milestone ativo |
+| `/plantar-ideia` | Captura ideia prospectiva com condições de gatilho — surge automaticamente no milestone certo |
+| `/nota` | Captura de ideias sem fricção. Adicionar, listar ou promover notas para todos |
+| `/adicionar-tarefa` | Captura ideia ou tarefa como todo a partir do contexto da conversa |
+| `/verificar-tarefas` | Lista todos pendentes e seleciona um para trabalhar |
+
+### Quick Actions & Routing
+
+| Comando | Objetivo |
+|---------|----------|
+| `/fazer "<task>"` | **Entrypoint canônico** — roteia texto livre para o comando correto. Use este na dúvida |
+| `/proximo` | Avança automaticamente para o próximo passo lógico no workflow |
+| `/progresso` | Verifica progresso do projeto, mostra contexto e roteia para próxima ação |
+| `/expresso` | Tarefa rápida com garantias framework (commits atômicos + state tracking) sem agents opcionais |
+| `/rapido` | Tarefa trivial inline — sem subagentes, sem overhead de planejamento |
+| `/autonomo` | Executa fases restantes autônomamente — discuss→plan→execute por fase |
+| `/depurar` | Depuração sistemática com estado persistente entre resets de contexto |
+| `/forense` | Investigação post-mortem de workflows com falha — analisa git + artefatos + estado |
+
+### Workspace & Workflows (paralelos)
+
+| Comando | Objetivo |
+|---------|----------|
+| `/fluxos-trabalho` | Gerencia fluxos paralelos — listar, criar, alternar, status, progresso, concluir, retomar |
+| `/listar-workspaces` | Lista workspaces framework ativos e seu status |
+| `/remover-workspace` | Remove workspace framework e limpa worktrees |
+| `/fio` | Gerencia threads de contexto persistentes para trabalho entre sessões |
+| `/gerenciador` | Central de comando interativa para gerenciar múltiplas fases em um terminal |
+
+### Utilities
+
+| Comando | Objetivo |
+|---------|----------|
+| `/ajuda` | Mostra comandos disponíveis e guia de uso |
+| `/atualizar` | Atualiza framework para versão mais recente com changelog |
+| `/configuracoes` | Configura toggles de workflow e perfil de modelo |
+| `/definir-perfil` | Altera perfil de modelo para agents framework (quality/balanced/budget/inherit) |
+| `/perfil-usuario` | Gera perfil comportamental do desenvolvedor (artefatos descobríveis pelo Claude) |
+| `/mapear-codebase` | Analisa base de código com agents paralelos para produzir docs em .planning/codebase/ |
+| `/relatorio-sessao` | Relatório da sessão com estimativas de tokens, resumo de trabalho e resultados |
+| `/estatisticas` | Estatísticas do projeto — fases, planos, requisitos, métricas git e timeline |
+| `/saude` | Diagnostica integridade do diretório de planejamento e opcionalmente repara |
+| `/sync-main` | Atualiza branch local com commits da main (pergunta qual priorizar em conflito) |
+| `/limpeza` | Arquiva diretórios de fase acumulados de milestones concluídos |
+| `/reaplicar-patches` | Reaplica modificações locais após atualização do framework |
+| `/revisar` | Solicita revisão entre IAs de planos de fase a partir de CLIs externas |
+| `/resumo-marco` | Resumo abrangente do projeto a partir dos artefatos do milestone |
+| `/setup-notion` | Cria estrutura de páginas Notion para novo projeto + gera `.claude/notion-config.json` |
+| `/entrar-discord` | Entrar na comunidade framework no Discord |
+
+---
+
+## Workflow exemplos
+
+### Exemplo 1: Ciclo completo de um milestone (brownfield)
+
+```bash
+# 1. iniciar milestone
+/novo-marco
+# → coleta objetivos, opcionalmente pesquisa (4 agents paralelos), define REQUIREMENTS.md,
+#   invoca roadmapper para criar ROADMAP.md, commita
+
+# 2. executar fase (manual passo-a-passo)
+/discutir-fase 124          # gather context via questionamento adaptativo
+/planejar-fase 124          # plan-checker → planner → PLAN.md
+/executar-fase 124          # executor com atomic commits + verifier
+
+# OU: executar todas as fases autônomamente
+/autonomo                   # discuss → plan → execute por fase + commit atômico
+
+# 3. auditar
+/auditar-marco              # verifica cobertura, integration entre phases, fluxos E2E
+
+# 4. concluir e publicar
+/concluir-marco             # archive .planning/milestones/v{X.Y}-* + tag git
+/publicar                   # Notion + PR GitHub com link Notion no body
+```
+
+### Exemplo 2: Trilha de segurança Supabase (v1.23-v1.26 cumulativos)
+
+```bash
+# 1. arquitetura inicial — projeta schema + RLS + Postgres roles upfront
+/supabase arquiteto "B2B SaaS com leads + audit log + invites + super-admin"
+
+# 2. migration com 5 blocos obrigatórios (CREATE TABLE + GRANTs + RLS + 4 policies + INDEX)
+/supabase migration "create_orgs_and_members"
+# → auto-chain cooperativo com supabase-rls-hardener (Detector 1-10)
+
+# 3. column-level para PII (v1.24)
+/supabase column "audit_log payload protected — só security_admin"
+
+# 4. RBAC via Custom Claims (v1.25)
+/supabase rbac "roles admin/moderator/user + 8 permissions"
+# → cria enum types + user_roles + auth hook + authorize() + RLS policies
+
+# 5. Custom Postgres role para service accounts (v1.26)
+/supabase role "platform_admin para super-admin operations"
+```
+
+### Exemplo 3: Investigação de incidente (Observability + SRE)
+
+```bash
+# 1. diagnóstico
+/investigar-producao        # Core Analysis Loop com estado persistente
+# → 4 fases: dados/hipótese/validação/root cause
+# → arquiva em .planning/investigations/<id>.md
+
+# 2. postmortem após fix
+/postmortem --from-investigation <id>
+# → blameless 9 seções (cap 15 livro Google SRE)
+
+# 3. ajustar SLO se necessário
+/definir-slo                # SLI event-based + SQL materialization
+/burn-rate-status           # tabela dual-window — page/ticket/warn
+
+# 4. PRR antes de scaled release
+/prr --service "checkout"   # scored em 6 axes
+```
+
+### Exemplo 4: Refactor seguro de código legado (v1.12)
+
+```bash
+# Chain canônico — bloqueia se gates falhares
+/refactor-seguro src/foo.ts
+# 1. encontrar-seams — identifica object/link/preprocessing seams (cap 25 Feathers)
+# 2. caracterizar — gera characterization tests (cap 13) cobrindo 5+ grupos de equivalência
+# 3. auditar-refactor — veredito GO/BLOCK/WARN baseado em coverage + mutation
+# 4. executor com safety net
+```
+
+### Exemplo 5: Quick action via roteamento canônico
+
+```bash
+# Texto livre — kit roteia para o comando certo
+/fazer "preciso adicionar uma tabela leads com phone email e org_id"
+# → roteia para /supabase migration (que auto-chain para hardener + RLS)
+
+/fazer "quero entender por que esse codebase está confuso"
+# → roteia para /storytelling ou /mapear-codebase
+
+/fazer "meu teste de produção tá flaky — não sei por que"
+# → roteia para /depurar (cria sessão persistente)
+```
+
+---
+
 ## Prerequisites
 
 - **Node.js ≥ 20** (uses native ESM, no transpiler)

package/kit/agents/audit-log-implementer.md

@@ -165,8 +165,146 @@ AUDIT-LOG-IMPLEMENTER · output integrado
 - Histogram `audit.log.payload_size_bytes` (detectar payload bloat)
 - Alarme se `audit.log.events.count{event_type=super_admin_action}` > baseline → suspeita de comprometimento
 
+## Cooperative handoff to supabase-rls-hardener (v1.23)
+
+Após gerar CREATE TABLE audit_log + REVOKE DELETE/UPDATE + helper function `private.audit_log` + retention scheduler pg_cron, faça handoff cooperativo:
+
+```python
+Task(subagent_type="supabase-rls-hardener", prompt=f"""
+<upstream_intent>
+Source agent: audit-log-implementer
+Original goal: implementar audit log multi-tenant append-only para {org_context}
+Constraints: REVOKE DELETE/UPDATE obrigatório (append-only); helper function private.audit_log com PII hashing; retention pg_cron 3 tiers (30d/90d/365d); legal_hold flag para LGPD
+</upstream_intent>
+
+<draft_sql>{generated_audit_log_sql}</draft_sql>
+
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+Hardener valida que append-only é blindado (sem policy de DELETE/UPDATE), GRANTs corretos, RLS ativa. **NUNCA descarte intent upstream silenciosamente**.
+
+## Cooperative handoff column-level (v1.24 — CROSS-11)
+
+Audit log tem coluna `payload` (jsonb) que pode conter PII (IP, user agent, email em event login). Aplique Camada 8 de defense-in-depth via handoff cooperativo:
+
+```python
+Task(subagent_type="supabase-column-privileges-writer", prompt=f"""
+<upstream_intent>
+Source agent: audit-log-implementer
+Original goal: PII sanitization granular por coluna em audit_log para compliance LGPD/GDPR
+Constraints: payload jsonb tem PII em events de login (IP, UA) + member_invited (email); legível só por security_admin + service_role
+</upstream_intent>
+
+<table>schema: public, name: audit_log</table>
+
+<sensitive_columns>
+- payload (jsonb — PII em events)
+- actor_email (PII se presente)
+</sensitive_columns>
+
+<allowed_roles>
+- service_role: SELECT all
+- security_admin: SELECT all
+- authenticated: SELECT (id, event_type, user_id, org_id, occurred_at) — excluding payload + actor_email
+</allowed_roles>
+
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+**Princípio canônico v1.23 (herdado em v1.24):** agents não-Supabase pensam/planejam; agents Supabase materializam/hardenam.
+
+## Cooperative handoff Postgres Roles (v1.26 — CROSS-19)
+
+Para acessar `audit_log.payload` (PII) com column-level GRANT (Camada 8 v1.24), crie role dedicado `security_admin` em vez de usar service_role API key. Auditabilidade superior via pg_stat_statements + role com BYPASSRLS específico. Aplique handoff cooperativo:
+
+```python
+Task(subagent_type="supabase-roles-implementer", prompt=f"""
+<upstream_intent>
+Source agent: audit-log-implementer
+Original goal: criar role security_admin para acesso payload PII do audit_log (system access)
+Constraints: BYPASSRLS necessário (security_admin precisa ver todas orgs); column-level GRANT em payload (cross-ref v1.24); login opcional (pode ser group role usado via SET ROLE de DBA)
+</upstream_intent>
+
+<roles_to_create>
+- name: security_admin
+  type: group  # ou user se DBA precisa login direto
+  login: false
+  bypassrls: true
+  inherit: false
+  description: "Role para acesso payload PII em audit_log. Usado via SET ROLE por DBAs."
+  owner: "security-team@company.com"
+</roles_to_create>
+
+<grants>
+security_admin:
+  - schema: public, usage: true
+  - table: public.audit_log, ops: [SELECT]  # column-level já aplicado via v1.24
+</grants>
+
+<use_case>system_access</use_case>
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+## Cooperative handoff RBAC via Custom Claims (v1.25 — CROSS-18)
+
+Mudanças em roles (INSERT/UPDATE/DELETE em `public.user_roles`) devem gerar audit log automaticamente — pattern canônico v1.25 via trigger Postgres que dispara `audit_log` event quando role muda. Aplique handoff cooperativo:
+
+```python
+Task(subagent_type="supabase-rbac-implementer", prompt=f"""
+<upstream_intent>
+Source agent: audit-log-implementer
+Original goal: instalar audit trigger em user_roles table para registrar mudanças de role (event taxonomy: 'role_assigned', 'role_revoked')
+Constraints: trigger AFTER INSERT/UPDATE/DELETE em public.user_roles dispara INSERT em audit_log com event_type, user_id, role, actor_id (auth.uid()), occurred_at; PII sanitization em payload (Camada 8 v1.24 column-level já aplicada)
+</upstream_intent>
+
+<roles>{detected_from_user_roles_table}</roles>
+<permissions_matrix>{role_change_audit_permissions}</permissions_matrix>
+<multi_tenant>{multi_tenant_flag}</multi_tenant>
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+**Trigger canônico (output esperado do rbac-implementer):**
+
+```sql
+create or replace function public.audit_role_change()
+returns trigger language plpgsql security definer set search_path = '' as $$
+begin
+  if (tg_op = 'INSERT') then
+    insert into public.audit_log (event_type, user_id, payload, actor_id, occurred_at)
+    values ('role_assigned', new.user_id,
+            jsonb_build_object('role', new.role),
+            auth.uid(), now());
+  elsif (tg_op = 'DELETE') then
+    insert into public.audit_log (event_type, user_id, payload, actor_id, occurred_at)
+    values ('role_revoked', old.user_id,
+            jsonb_build_object('role', old.role),
+            auth.uid(), now());
+  end if;
+  return coalesce(new, old);
+end; $$;
+
+create trigger user_roles_audit
+  after insert or update or delete on public.user_roles
+  for each row execute function public.audit_role_change();
+```
+
+**Eventos canônicos adicionados (event taxonomy v1.25):**
+- `role_assigned` (action: INSERT em user_roles)
+- `role_revoked` (action: DELETE em user_roles)
+- `role_updated` (action: UPDATE — raro, usualmente DELETE+INSERT)
+
+Cross-ref skill `audit-log-multi-tenant` event taxonomy + skill `supabase-custom-claims-rbac` v1.25.
+
 ## Ver também
 
+- [supabase-rls-hardener](./supabase-rls-hardener.md) — canonical handoff target v1.23 (validation append-only)
+- [supabase-column-privileges-writer](./supabase-column-privileges-writer.md) — canonical handoff target v1.24 (column-level PII sanitization)
+- [supabase-rbac-implementer](./supabase-rbac-implementer.md) — canonical handoff target v1.25 (Custom Claims + audit trigger)
 - [audit-log-multi-tenant](../skills/audit-log-multi-tenant/SKILL.md) — base de conhecimento (DDL + regras)
 - [supabase-cron-queues](../skills/supabase-cron-queues/SKILL.md) — pattern pg_cron (cross-suite)
 - [supabase-migration-writer](./supabase-migration-writer.md) — agent invocado para SQL final

package/kit/agents/auditor-consistencia-isolamento.md

@@ -368,6 +368,37 @@ Quando este agent detecta problema, **propõe fix mas NÃO escreve**. Delega via
 - Histogram `audit.consistency.duration_ms` (latência total da auditoria)
 - Cada finding fica registrado em `obs.events` com `audit_run_id` para rastreabilidade
 
+## Validação de RLS hardener cooperativo (v1.23 — CROSS-09)
+
+Para cada migration recente analisada pelos 6 detectores, este agent adicionalmente valida que a migration **passou pelo `supabase-rls-hardener`** antes de ser aplicada — Camada 7 de defense-in-depth + auditoria cross-suite.
+
+**Detector adicional (D7 — hardener bypass):** consulta git log + procura por commits de migration que NÃO incluem trace de handoff cooperativo:
+
+```bash
+# Detectar migrations sem hardener trace
+git log --oneline --all -- supabase/migrations/*.sql | while read commit msg; do
+  if ! git show $commit -- supabase/migrations/ | grep -q "supabase-rls-hardener\|HARDENER OK\|verdict: GO"; then
+    echo "$commit  $msg  ⚠ MIGRATION SEM TRACE DE HARDENER"
+  fi
+done
+```
+
+**Output enriquecido com campo `hardener_passed`:**
+
+```markdown
+## Detector 7 — Migration sem hardener cooperativo (v1.23)
+
+| Migration | Hardener | Verdict | Risk |
+|-----------|----------|---------|------|
+| 20260510120000_create_orders.sql | ✅ passed | STRENGTHEN | low |
+| 20260510130000_legacy_table.sql | ❌ bypass | n/a | **P1** |
+| 20260510140000_add_org_id.sql | ✅ passed | GO | low |
+```
+
+Migrations com `hardener_passed: false` são P1 (high severity) — recomendação é re-rodar via `Task(subagent_type=supabase-rls-hardener, prompt=<old_sql>)` retroativamente e aplicar fix-up migration.
+
+**Princípio canônico v1.23:** Este agent **não escreve fix** — apenas detecta gap e delega para `supabase-rls-hardener` (handoff cooperativo) que produz SQL ajustado preservando intent original.
+
 ## Ver também
 
 - [`postgres-isolamento-concorrencia`](../skills/postgres-isolamento-concorrencia/SKILL.md) (v1.22) — base para Detectores 1, 2, 5 (FOR UPDATE, SERIALIZABLE, advisory locks)
@@ -378,3 +409,5 @@ Quando este agent detecta problema, **propõe fix mas NÃO escreve**. Delega via
 - [`supabase-migration-writer`](./supabase-migration-writer.md) (v1.8) — destino do cross-suite handoff (escreve migration corrigida)
 - [`supabase-edge-fn-writer`](./supabase-edge-fn-writer.md) (v1.8) — destino do cross-suite handoff (escreve Edge Function corrigida)
 - [`multi-tenant-isolation-auditor`](./multi-tenant-isolation-auditor.md) (v1.21) — agent irmão que audita gaps de RLS (complementar — RLS é defesa em depth, este agent foca em race conditions)
+- [`supabase-rls-hardener`](./supabase-rls-hardener.md) (v1.23) — canonical handoff target; Detector 7 valida que migrations passaram por este agent
+- [`supabase-rls-defense-in-depth`](../skills/supabase-rls-defense-in-depth/SKILL.md) (v1.23) — 6 camadas defense-in-depth referenciadas em Detector 7

package/kit/agents/crm-pipeline-implementer.md

@@ -157,8 +157,97 @@ END;
 $$ LANGUAGE plpgsql;
 ```
 
+## Cooperative handoff to supabase-rls-hardener (v1.23)
+
+Após gerar CREATE TABLE leads (6 stages canônicos) + tabela lead_stage_transitions + trigger BEFORE UPDATE validate_lead_stage_transition + trigger AFTER UPDATE audit_lead_ownership_change, faça handoff cooperativo:
+
+```python
+Task(subagent_type="supabase-rls-hardener", prompt=f"""
+<upstream_intent>
+Source agent: crm-pipeline-implementer
+Original goal: implementar CRM lead pipeline com 6 stages canônicos para {org_context}
+Constraints: lead dedup (unique org_id,phone) + (unique org_id,email); state machine via trigger BEFORE UPDATE (não só CHECK constraint); ownership transfer com notification; integration WhatsApp lookup contact_phone
+</upstream_intent>
+
+<draft_sql>{generated_leads_sql}</draft_sql>
+
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+Hardener valida policies por org_id, GRANTs corretos, trigger SECURITY DEFINER em schema private (se aplicável). **NUNCA descarte intent upstream silenciosamente**.
+
+## Cooperative handoff Postgres Roles (v1.26 — CROSS-21)
+
+Crie role `lead_manager` para acesso PII columns dos leads (phone, email, notes). Role dedicado complementa column-level GRANTs (v1.24 CROSS-13). Auditabilidade superior + governance.
+
+```python
+Task(subagent_type="supabase-roles-implementer", prompt=f"""
+<upstream_intent>
+Source agent: crm-pipeline-implementer
+Original goal: criar role lead_manager para acesso PII columns dos leads (cross-ref v1.24 column-level)
+Constraints: NÃO BYPASSRLS (deve respeitar org boundary via RLS hierárquica multi-tenant v1.21); column-level GRANT em phone/email/notes; login opcional (pode ser group usado por managers via SET ROLE)
+</upstream_intent>
+
+<roles_to_create>
+- name: lead_manager
+  type: group
+  login: false
+  bypassrls: false  # respeita org boundary
+  inherit: false
+  description: "Acesso PII columns dos leads (phone, email, notes). Usado por sales managers via SET ROLE."
+  owner: "sales-team@company.com"
+</roles_to_create>
+
+<grants>
+lead_manager:
+  - schema: public, usage: true
+  - table: public.leads, ops: [SELECT]  # column-level já aplicado via v1.24 CROSS-13
+</grants>
+
+<use_case>system_access</use_case>
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+**Caveat:** este role complementa RLS row-level (org boundary) + column-level (PII). NÃO substitui auth.users + custom claims (v1.25) — lead_manager é Postgres role para DBA/sales-ops, não para end-user via app.
+
+## Cooperative handoff column-level (v1.24 — CROSS-13)
+
+Lead PII columns (phone, email) podem precisar de column-level restriction para LGPD compliance — apenas owner do lead ou lead_manager role vê os dados de contato completos. Aplique handoff cooperativo:
+
+```python
+Task(subagent_type="supabase-column-privileges-writer", prompt=f"""
+<upstream_intent>
+Source agent: crm-pipeline-implementer
+Original goal: lead PII columns (phone, email) com REVOKE select cross-user para LGPD compliance
+Constraints: lead.phone e lead.email são PII; visível apenas para owner (RLS) + lead_manager role (column-level); company_name e job_title públicos para membros da org
+</upstream_intent>
+
+<table>schema: public, name: leads</table>
+
+<sensitive_columns>
+- phone
+- email
+- notes (jsonb — pode ter PII em call notes)
+</sensitive_columns>
+
+<allowed_roles>
+- service_role: SELECT all
+- lead_manager: SELECT all (admin do CRM)
+- authenticated: SELECT (id, org_id, owner_id, company_name, job_title, stage, lead_value, created_at) — sem PII
+</allowed_roles>
+
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+**Importante:** combinar com RLS row-level (owner vê próprio lead inteiro) — RLS filtra qual lead; column-level filtra quais colunas DENTRO do lead. Owner pode precisar SELECT phone do PRÓPRIO lead — considere policy `for select to authenticated using (owner_id = (select auth.uid()))` granted em todas colunas, e usar column-level apenas para cross-user (outro member da org tentando ver lead alheio).
+
 ## Ver também
 
+- [supabase-rls-hardener](./supabase-rls-hardener.md) — canonical handoff target v1.23
+- [supabase-column-privileges-writer](./supabase-column-privileges-writer.md) — canonical handoff target v1.24 (column-level lead PII)
 - [crm-lead-pipeline-patterns](../skills/crm-lead-pipeline-patterns/SKILL.md) — base de conhecimento
 - [evolution-go-integrator](./evolution-go-integrator.md) — Phase 112 (cross-phase handoff)
 - [supabase-migration-writer](./supabase-migration-writer.md) — invoked via Task() para SQL

package/kit/agents/debugger.md

@@ -770,3 +770,44 @@ O orquestrador apresenta o checkpoint ao usuário, obtém resposta, invoca agent
 - [ ] Correção verificada contra sintomas originais
 - [ ] Formato de retorno apropriado baseado no modo
 </success_criteria>
+
+<sql_auto_handoff_cooperativo>
+## SQL auto-handoff cooperativo (v1.23 — CROSS-10)
+
+Ao investigar bug que envolve RLS/policy/SQL (hipótese: "policy negando", "auth.uid() retornando null", "RLS bypass via view", "permission denied"), antes de propor fix SQL, faça handoff cooperativo para `supabase-rls-hardener` para validation.
+
+**Heurística de detecção (hipótese mention):**
+
+```regex
+(RLS|policy|auth\.uid|permission\s+denied|42501|insufficient_privilege|user_metadata|security_definer|security_invoker|grant\s+.*on)
+```
+
+Se ≥ 1 match em current focus do debug → invoca handoff antes de propor fix:
+
+```python
+hardener_validation = Task(
+  subagent_type="supabase-rls-hardener",
+  prompt=f"""
+  <upstream_intent>
+  Source agent: debugger
+  Original goal: investigar {bug_description} relacionado a RLS/policy
+  Constraints: hipótese atual é {current_hypothesis}; testando fix proposto: {proposed_fix_sql}
+  </upstream_intent>
+
+  <draft_sql>{proposed_fix_sql}</draft_sql>
+
+  <user_facing_caller>true</user_facing_caller>
+  """
+)
+```
+
+**Uso do output do hardener:**
+- **GO** → fix proposto não introduz anti-pattern; pode aplicar
+- **STRENGTHEN** → fix tem anti-pattern; absorver diff sugerido na hipótese (ex: faltou IS NOT NULL, faltou GRANT)
+- **REWRITE** → fix tem anti-pattern crítico; descartar e propor abordagem hardener-sugerida
+
+**Princípio canônico v1.23:** Debugger pensa (gera hipóteses, propõe fixes); supabase-rls-hardener valida (defense-in-depth). Hipóteses ruins não são descartadas silenciosamente — viram diff explícito que enriquece o debug.
+
+**Evidence adicionada no DEBUG.md:** verdict do hardener + diff são incorporados como evidence da hipótese atual (rastreabilidade pós-reset).
+
+</sql_auto_handoff_cooperativo>

package/kit/agents/evolution-go-integrator.md

@@ -168,8 +168,29 @@ EVOLUTION-GO-INTEGRATOR · output integrado
 - Counter `whatsapp.send.rate_limited{org_id}` por 131056 hit
 - Alarme se `whatsapp.send.rate_limited > baseline` → review queue/throttle
 
+## Cooperative handoff to supabase-rls-hardener (v1.23)
+
+Após gerar webhook handler + idempotency unique constraint + rate limit pgmq, faça handoff cooperativo para SQL bloco:
+
+```python
+Task(subagent_type="supabase-rls-hardener", prompt=f"""
+<upstream_intent>
+Source agent: evolution-go-integrator
+Original goal: integrar WhatsApp (Evolution Go ou Meta Cloud API) com Supabase B2B multi-tenant para {org_context}
+Constraints: webhook URL path /functions/v1/whatsapp/{org_id}/webhook (tenant_id ANTES do parse); HMAC-SHA256 (Meta) ou API key + IP whitelist (Evolution Go); idempotência unique(org_id, message_id); rate limit Meta 80msg/s via pgmq queue
+</upstream_intent>
+
+<draft_sql>{generated_webhook_sql}</draft_sql>
+
+<user_facing_caller>true</user_facing_caller>
+""")
+```
+
+Hardener valida tenant isolation (org_id em todas policies), HMAC validation ANTES do parse, idempotency constraint correto. **NUNCA descarte intent upstream silenciosamente**.
+
 ## Ver também
 
+- [supabase-rls-hardener](./supabase-rls-hardener.md) — canonical handoff target v1.23
 - [evolution-go-whatsapp-integration](../skills/evolution-go-whatsapp-integration/SKILL.md) — base de conhecimento
 - [whatsapp-conversation-state-machine](../skills/whatsapp-conversation-state-machine/SKILL.md) — sibling skill
 - [supabase-edge-fn-writer](./supabase-edge-fn-writer.md) — invoked para Edge Functions (cross-suite)