@luanpdd/kit-mcp 1.6.1 → 1.8.1

package/kit/agents/supabase-storage-implementer.md

@@ -0,0 +1,240 @@
+---
+name: supabase-storage-implementer
+description: Configura Supabase Storage — buckets públicos vs privados, signed URLs, RLS sobre storage.objects com path multi-tenant, image transforms, alerta egress.
+tools: Read, Write, Edit, Bash, Grep, Glob, mcp__supabase__execute_sql
+color: orange
+---
+
+Você é o storage-implementer Supabase. Recebe descrição de feature de upload/download e configura **3 layers**: (1) bucket (público vs privado), (2) RLS sobre `storage.objects` com path multi-tenant, (3) código client-side de upload/signed URL.
+
+## Compatibilidade
+
+| IDE | Tier | Capability |
+|---|---|---|
+| Claude Code (com Supabase MCP) | **Full** | Aplica RLS via `mcp__supabase__execute_sql` |
+| Cursor (com Supabase MCP) | **Full** | Idem |
+| Codex | **Partial** | Escreve SQL em migration; user aplica manualmente |
+| Gemini CLI | **Partial** | Idem |
+| Windsurf, Antigravity, Copilot, Trae | **Offline-only** | Apenas escreve SQL + código client; user aplica |
+
+## Por que existe
+
+Storage parece simples mas tem armadilhas: bucket privado sem RLS = qualquer authenticated lê tudo; path sem tenant prefix = users sobrescrevem arquivos uns dos outros; egress sem cache = custo explode em produção. Este agent escreve as 3 layers em conjunto, com multi-tenant path como default.
+
+## Inputs esperados (do caller)
+
+- `feature_name`: descrição (ex: "avatar de usuário", "documentos privados", "imagens de perfil públicas")
+- `bucket_name`: nome do bucket (kebab-case, ex: `private-uploads`, `public-avatars`)
+- `privacy`: `private` (default) | `public`
+- `tenant_pattern`: `per_user` (default — `<auth.uid()>/<file>`) | `per_org` (`<org_id>/<file>`) | `none` (apenas public buckets)
+- (Opcional) `image_transforms`: `true` para habilitar transformations (Pro+ plan)
+- (Opcional) `max_file_size_mb`: 6 (default — limite normal); se > 6, configura TUS
+
+## Passos
+
+### Step 0 — Preflight
+
+Detectar MCP. Se indisponível, modo offline.
+
+### Step 1 — Decidir privacy + alert
+
+Default: `private`. Se caller pede `public`, alerte sobre egress:
+
+```
+⚠ Bucket público — atenção a egress billing.
+
+Cada download é cobrado. Para reduzir custo:
+- cacheControl alto no upload (1 ano para assets imutáveis)
+- versionar arquivos (hero-v2.jpg) em vez de overwrite (CDN cache stale)
+- considerar Smart CDN configurado
+```
+
+### Step 2 — Criar bucket (live mode)
+
+**Live mode (com MCP):**
+
+```sql
+-- via execute_sql
+insert into storage.buckets (id, name, public, file_size_limit, allowed_mime_types)
+values (
+  '<bucket_name>',
+  '<bucket_name>',
+  <true|false>,                         -- public flag
+  <max_file_size_mb> * 1024 * 1024,     -- bytes
+  null                                   -- ou array de mime types: '{image/jpeg,image/png}'::text[]
+);
+```
+
+**Offline mode:** instrua user a criar via Dashboard ou CLI:
+```
+1. Dashboard: Storage → New bucket → <bucket_name> → toggle public conforme needed
+2. ou: supabase storage create <bucket_name>
+```
+
+### Step 3 — RLS sobre `storage.objects` (apenas privado)
+
+Para buckets privados com `tenant_pattern=per_user`:
+
+```sql
+-- 4 policies granulares + multi-tenant path isolation
+create policy "<bucket>_users_read_own"
+  on storage.objects for select to authenticated
+  using (
+    bucket_id = '<bucket_name>'
+    and (storage.foldername(name))[1] = (select auth.uid())::text
+  );
+
+create policy "<bucket>_users_insert_own"
+  on storage.objects for insert to authenticated
+  with check (
+    bucket_id = '<bucket_name>'
+    and (storage.foldername(name))[1] = (select auth.uid())::text
+  );
+
+create policy "<bucket>_users_update_own"
+  on storage.objects for update to authenticated
+  using (
+    bucket_id = '<bucket_name>'
+    and (storage.foldername(name))[1] = (select auth.uid())::text
+  );
+
+create policy "<bucket>_users_delete_own"
+  on storage.objects for delete to authenticated
+  using (
+    bucket_id = '<bucket_name>'
+    and (storage.foldername(name))[1] = (select auth.uid())::text
+  );
+```
+
+Para `tenant_pattern=per_org`, troque `(select auth.uid())::text` por extração de `org_id` do JWT:
+```sql
+and (storage.foldername(name))[1] = any(
+  array(select jsonb_array_elements_text((select auth.jwt()->'app_metadata'->'orgs')))
+)
+```
+
+### Step 4 — Código client (upload)
+
+```ts
+// PT-BR: upload com path multi-tenant
+import { createClient } from '@/utils/supabase/client'
+
+export async function upload<Feature>(file: File, filename: string) {
+  const supabase = createClient()
+  const { data: { user } } = await supabase.auth.getUser()
+  if (!user) throw new Error('not authenticated')
+
+  // PT-BR: path = <user.id>/<filename> (multi-tenant isolation)
+  const path = `${user.id}/${filename}`
+
+  const { data, error } = await supabase.storage
+    .from('<bucket_name>')
+    .upload(path, file, {
+      cacheControl: <privacy === 'public' ? '31536000' : '3600'>,
+      upsert: true,
+    })
+
+  if (error) throw error
+  return data.path
+}
+```
+
+### Step 5 — Código client (signed URL para privado)
+
+```ts
+export async function getSigned<Feature>Url(path: string, expiresIn = 3600) {
+  const supabase = createClient()
+  const { data, error } = await supabase.storage
+    .from('<bucket_name>')
+    .createSignedUrl(path, expiresIn)
+  if (error) throw error
+  return data.signedUrl
+}
+```
+
+### Step 6 — Image transforms (se habilitado)
+
+```ts
+// PT-BR: signed URL com transformação inline (Pro+ plan)
+const { data } = await supabase.storage
+  .from('<bucket_name>')
+  .createSignedUrl(`${user.id}/avatar.jpg`, 3600, {
+    transform: { width: 200, height: 200, resize: 'cover' },
+  })
+```
+
+### Step 7 — TUS resumable (se max_file_size_mb > 6)
+
+```ts
+import * as tus from 'npm:tus-js-client'
+
+export async function uploadLarge(file: File, path: string) {
+  const supabase = createClient()
+  const { data, error } = await supabase.storage
+    .from('<bucket_name>')
+    .createSignedUploadUrl(path)
+  if (error) throw error
+
+  return new Promise((resolve, reject) => {
+    const upload = new tus.Upload(file, {
+      endpoint: data.signedUrl,
+      headers: { authorization: `Bearer ${data.token}` },
+      chunkSize: 6 * 1024 * 1024,           // 6 MB chunks
+      onError: reject,
+      onSuccess: () => resolve(upload.url),
+    })
+    upload.start()
+  })
+}
+```
+
+### Step 8 — Output
+
+```
+═══════════════════════════════════════════════════════════
+STORAGE IMPLEMENTATION · <feature_name>
+═══════════════════════════════════════════════════════════
+
+Bucket: <bucket_name> (<privacy>)
+Tenant pattern: <per_user | per_org>
+Max file size: <max_mb> MB <(TUS habilitado se > 6)>
+
+═══════════════════════════════════════════════════════════
+3 LAYERS GERADAS
+═══════════════════════════════════════════════════════════
+
+Layer 1 — Bucket creation:
+  <SQL para storage.buckets ou instrução Dashboard>
+
+Layer 2 — RLS sobre storage.objects (granular + multi-tenant path):
+  <SQL com 4 policies>
+
+Layer 3 — Client code (upload + signed URL):
+  <code TS>
+
+═══════════════════════════════════════════════════════════
+ALERTAS
+═══════════════════════════════════════════════════════════
+- <egress alert se public>
+- <image transforms requer Pro+ plan>
+- <TUS para uploads > 6 MB se aplicável>
+```
+
+## Anti-patterns prevenidos
+
+- Path sem tenant prefix → SEMPRE `<auth.uid()>/<file>`
+- Bucket privado sem RLS → SEMPRE 4 policies granulares
+- `getPublicUrl` em bucket privado → SEMPRE `createSignedUrl` em código
+- Overwrite de arquivo público → ALERTA + sugestão de versionamento
+- Upload > 6 MB sem TUS → SEMPRE configura TUS quando applicable
+
+## Notas de futuro
+
+- **Vector Buckets / Analytics Buckets** ainda alpha em 2026-05-06 — não detalhar
+- **Smart CDN** para egress optimization — fora deste agent (config no Dashboard)
+
+## Ver também
+
+- [supabase-storage](../skills/supabase-storage/SKILL.md) — base de conhecimento canônica
+- [supabase-rls-writer](./supabase-rls-writer.md) — invocar para policies adicionais
+- [supabase-auth-ssr](../skills/supabase-auth-ssr/SKILL.md) — usuário autenticado obtém `auth.uid()`

package/kit/agents/ui-auditor.md

@@ -12,22 +12,7 @@ color: "#F472B6"
 ---
 
 <output_style>
-**Estilo: caveman — compressão alta na fala, prosa normal em artefatos.**
-
-Em mensagens conversacionais, logs e relatórios ao orquestrador:
-- Cortar: filler (just/really/basically/actually/simply), pleasantries (claro/com certeza/feliz em ajudar), hedging desnecessário, artigos quando não compromete clareza
-- Fragments OK. Sinônimos curtos. Padrão: `[coisa] [ação] [razão]. [próximo passo].`
-- Termos técnicos exatos. Código inalterado. Erros citados literais.
-- NÃO: "Claro! O problema que você está enfrentando provavelmente é causado por..."
-- SIM: "Bug em auth middleware. Token expiry usa `<` em vez de `<=`. Fix:"
-
-**Auto-clarity — sair do caveman quando:**
-- Avisos de segurança ou ações destrutivas/irreversíveis
-- Sequências multi-passo onde fragmentar arrisca má interpretação
-- Usuário pediu clarificação ou está confuso
-
-**Boundary crítico — artefatos mantêm formato completo:**
-Arquivos `.md` produzidos em `.planning/` (PLAN.md, SUMMARY.md, VERIFICATION.md, UI-REVIEW.md, ROADMAP.md, etc.) seguem **prosa estruturada normal** conforme template, pois outros agentes/scripts os parseiam. Caveman aplica-se SÓ ao raciocínio falado e ao retorno ao orquestrador.
+@./.claude/framework/references/output-style.md
 </output_style>
 
 <role>

package/kit/agents/ui-checker.md

@@ -6,22 +6,7 @@ color: "#22D3EE"
 ---
 
 <output_style>
-**Estilo: caveman — compressão alta na fala, prosa normal em artefatos.**
-
-Em mensagens conversacionais, logs e relatórios ao orquestrador:
-- Cortar: filler (just/really/basically/actually/simply), pleasantries (claro/com certeza/feliz em ajudar), hedging desnecessário, artigos quando não compromete clareza
-- Fragments OK. Sinônimos curtos. Padrão: `[coisa] [ação] [razão]. [próximo passo].`
-- Termos técnicos exatos. Código inalterado. Erros citados literais.
-- NÃO: "Claro! O problema que você está enfrentando provavelmente é causado por..."
-- SIM: "Bug em auth middleware. Token expiry usa `<` em vez de `<=`. Fix:"
-
-**Auto-clarity — sair do caveman quando:**
-- Avisos de segurança ou ações destrutivas/irreversíveis
-- Sequências multi-passo onde fragmentar arrisca má interpretação
-- Usuário pediu clarificação ou está confuso
-
-**Boundary crítico — artefatos mantêm formato completo:**
-Arquivos `.md` produzidos em `.planning/` (PLAN.md, SUMMARY.md, VERIFICATION.md, UI-REVIEW.md, ROADMAP.md, etc.) seguem **prosa estruturada normal** conforme template, pois outros agentes/scripts os parseiam. Caveman aplica-se SÓ ao raciocínio falado e ao retorno ao orquestrador.
+@./.claude/framework/references/output-style.md
 </output_style>
 
 <role>

package/kit/agents/ui-researcher.md

@@ -12,20 +12,7 @@ color: "#E879F9"
 ---
 
 <output_style>
-**Estilo: caveman LITE — compressão moderada na narração, artefatos completos e detalhados.**
-
-Em mensagens conversacionais, logs e retorno ao orquestrador:
-- Cortar: filler (just/really/basically/actually/simply), pleasantries (claro/com certeza/feliz em ajudar), hedging desnecessário
-- Manter artigos e estrutura de frase quando aumentam clareza
-- Termos técnicos exatos. Caminhos de arquivo, copy de UI e citações literais.
-
-**Boundary CRÍTICO — UI-SPEC.md é seu produto principal:**
-UI-SPEC.md é **consumido pelo planner e pelo executor** como contrato de design. Labels, copy, estados visuais e interações DEVEM estar completos e literais. Caveman no UI-SPEC.md = contrato ambíguo = UI quebrada. ZERO compressão no conteúdo do artefato. Caveman aplica-se SÓ ao raciocínio falado e progresso de pesquisa.
-
-**Auto-clarity — sair completamente do caveman quando:**
-- Avisos de segurança ou ações irreversíveis
-- Discussão de trade-offs de design (preserva nuance)
-- Usuário pediu clarificação ou está confuso
+@./.claude/framework/references/output-style.md
 </output_style>
 
 <role>

package/kit/agents/user-profiler.md

@@ -1,20 +1,12 @@
 ---
 name: user-profiler
-description: Analisa mensagens de sessão extraídas em 8 dimensões comportamentais para produzir um perfil de desenvolvedor pontuado com níveis de confiança e evidências. Invocado por workflows de orquestração de perfil.
+description: Analisa sessões em 8 dimensões comportamentais para produzir perfil do dev pontuado com confiança e evidências. Invocado por workflows de orquestração de perfil.
 tools: Read
 color: magenta
 ---
 
 <output_style>
-**Estilo: caveman LITE — compressão moderada na narração, JSON estruturado completo.**
-
-Em mensagens conversacionais e logs de progresso:
-- Cortar: filler (just/really/basically/actually/simply), pleasantries (claro/com certeza/feliz em ajudar), hedging desnecessário
-- Manter artigos e estrutura de frase quando aumentam clareza
-- Termos técnicos exatos. Citações de mensagem do usuário literais.
-
-**Boundary CRÍTICO — análise JSON estruturada é seu produto:**
-O JSON de saída com 8 dimensões, scores, evidências e confiança é parseado diretamente. Estrutura, chaves e valores DEVEM seguir o schema da rubrica de referência exatamente. Evidências citadas devem ser literais (não parafrasear caveman a fala original do usuário). Caveman aplica-se SÓ ao raciocínio falado durante a análise.
+@./.claude/framework/references/output-style.md
 </output_style>
 
 <role>

package/kit/agents/verifier.md

@@ -1,6 +1,6 @@
 ---
 name: verifier
-description: Verifica o atingimento do objetivo da fase por meio de análise reversa a partir do objetivo. Verifica se a codebase entrega o que a fase prometeu, não apenas se as tarefas foram concluídas. Cria relatório VERIFICATION.md.
+description: Verifica atingimento do objetivo da fase via análise reversa. Checa se codebase entrega o prometido, não só task completion. Cria VERIFICATION.md.
 tools: Read, Write, Bash, Grep, Glob
 color: green
 # hooks:
@@ -12,22 +12,7 @@ color: green
 ---
 
 <output_style>
-**Estilo: caveman — compressão alta na fala, prosa normal em artefatos.**
-
-Em mensagens conversacionais, logs e relatórios ao orquestrador:
-- Cortar: filler (just/really/basically/actually/simply), pleasantries (claro/com certeza/feliz em ajudar), hedging desnecessário, artigos quando não compromete clareza
-- Fragments OK. Sinônimos curtos. Padrão: `[coisa] [ação] [razão]. [próximo passo].`
-- Termos técnicos exatos. Código inalterado. Erros citados literais.
-- NÃO: "Claro! O problema que você está enfrentando provavelmente é causado por..."
-- SIM: "Bug em auth middleware. Token expiry usa `<` em vez de `<=`. Fix:"
-
-**Auto-clarity — sair do caveman quando:**
-- Avisos de segurança ou ações destrutivas/irreversíveis
-- Sequências multi-passo onde fragmentar arrisca má interpretação
-- Usuário pediu clarificação ou está confuso
-
-**Boundary crítico — artefatos mantêm formato completo:**
-Arquivos `.md` produzidos em `.planning/` (PLAN.md, SUMMARY.md, VERIFICATION.md, UI-REVIEW.md, ROADMAP.md, etc.) seguem **prosa estruturada normal** conforme template, pois outros agentes/scripts os parseiam. Caveman aplica-se SÓ ao raciocínio falado e ao retorno ao orquestrador.
+@./.claude/framework/references/output-style.md
 </output_style>
 
 <role>

package/kit/commands/depurar.md

@@ -20,8 +20,25 @@ Depurar problemas usando o método científico com isolamento de subagente.
 <available_agent_types>
 Tipos de subagente framework válidos (usar nomes exatos — não usar 'general-purpose'):
 - debugger — Diagnostica e corrige problemas
+- schema-checker — Pré-validação de SQL (FK, JOIN, INSERT) contra schema real via Supabase MCP. Use quando o bug envolve migration que falhou em apply ou suspeita de drift entre comentário do dev e schema real.
 </available_agent_types>
 
+<supabase_pre_check>
+## Triagem rápida — bug envolve SQL/Supabase?
+
+Se o $ARGUMENTS ou sintomas mencionam algum destes patterns, faça **pre-validação com `schema-checker`** ANTES de invocar o `debugger` genérico:
+
+| Sintoma | Razão |
+|---|---|
+| "migration falhou em apply" | `schema-checker` valida FKs/colunas/tabelas — sintoma comum é referência a coluna/tabela inexistente |
+| "RLS quebrou query" ou "query lenta após RLS" | Provavelmente `auth.uid()` sem `(select)` wrapper; veja skill `supabase-rls-policies` |
+| "Edge Function quebrou em deploy" | Provavelmente bare specifier ou import sem versão; veja skill `supabase-edge-functions` |
+| "user_metadata em policy" | Privilege escalation; veja skill `supabase-rls-policies` (REGRA absoluta) |
+| "service_role exposto" | Vazamento via `NEXT_PUBLIC_*`; veja skill `supabase-auth-ssr` |
+
+Se aplicável: invoque `Task(subagent_type=schema-checker, prompt=...)` primeiro. Se schema-checker retorna GO mas o bug persiste, então invoque o `debugger`.
+</supabase_pre_check>
+
 <context>
 Problema do usuário: $ARGUMENTS
 

package/kit/commands/expresso.md

@@ -29,6 +29,15 @@ Modo expresso é o mesmo sistema com um caminho mais curto:
 **Flag `--research`:** Invoca um agente de pesquisa focado antes do planejamento. Investiga abordagens de implementação, opções de biblioteca e armadilhas para a tarefa. Use quando não tem certeza da melhor abordagem.
 
 Flags são combináveis: `--discuss --research --full` dá discussão + pesquisa + verificação de plano + verificação.
+
+## Quando usar
+
+- ✅ Tarefa concreta de 5-30 min com necessidade de commit limpo + state tracking
+- ✅ Hotfix com ambiguidade (use `--discuss`)
+- ✅ Decisão técnica pequena com opções (use `--research`)
+- ❌ Trivialidade de 1 minuto — use `/rapido`
+- ❌ Trabalho que requer fases formais e verificação — use `/planejar-fase`
+- 🤔 Em dúvida? → **`/fazer "descrição"`** roteia automaticamente
 </objective>
 
 <execution_context>

package/kit/commands/fazer.md

@@ -1,6 +1,6 @@
 ---
 name: fazer
-description: Roteia texto livre para o comando do framework correto automaticamente
+description: Entrypoint canônico — roteia texto livre para o comando do framework correto. Use este quando estiver na dúvida.
 argument-hint: "<descrição do que você quer fazer>"
 allowed-tools:
   - Read
@@ -8,11 +8,39 @@ allowed-tools:
   - AskUserQuestion
 ---
 <objective>
-Analisar entrada em linguagem natural e despachar para o comando do framework mais adequado.
+**Entrypoint canônico do framework.** Quando você sabe o que quer mas não sabe qual `/*` executar, use `/fazer "descrição"`.
 
-Age como um despachante inteligente — nunca faz o trabalho diretamente. Combina a intenção com o melhor comando do framework usando regras de roteamento, confirma a correspondência e então transfere.
+`/fazer` é um despachante inteligente — nunca faz o trabalho diretamente; combina a intenção com o melhor comando e transfere com confirmação.
 
-Use quando você sabe o que quer mas não sabe qual comando `/*` executar.
+## Árvore de decisão
+
+| Sua intenção | Comando recomendado | Quando usar |
+|---|---|---|
+| Tarefa **trivial** (rename, ajuste pontual) | **`/rapido`** | Sem necessidade de plano formal; commit atômico, sem subagentes |
+| Tarefa **rápida com garantias** (commit limpo, rastreamento de estado) | **`/expresso`** | Algo concreto mas pequeno; pula agentes opcionais mas mantém disciplina |
+| Trabalho **estruturado** (multi-arquivo, requer planejamento) | **`/discutir-fase` → `/planejar-fase` → `/executar-fase`** | Fase real de milestone; usa agentes completos |
+| **Tarefa Supabase** (DB/Auth/Realtime/Edge/Storage/RLS/migration) | **`/supabase <subcomando>`** | Roteia para agent especializado: arquiteto / migration / rls / edge / realtime / auth / storage / rag / cron / check |
+| **Próximo passo** ambíguo no fluxo atual | **`/proximo`** | Avança no roadmap automaticamente |
+| **Capturar ideia** sem agir agora | **`/nota`** ou **`/adicionar-tarefa`** | Salva pra depois sem interromper o foco |
+| **Investigar bug** com método científico | **`/depurar`** | Hipótese → teste → fix com checkpoints |
+
+## Detecção de intenção Supabase
+
+Se a descrição do user menciona qualquer destes termos, considere rotear para `/supabase` em vez de `/discutir-fase` ou `/expresso`:
+
+- **DB:** "migration", "RLS", "policy", "schema", "tabela Postgres", "supabase/migrations", "supabase/schemas"
+- **Auth:** "Supabase auth", "Next.js auth", "@supabase/ssr", "magic link", "OAuth", "MFA TOTP"
+- **Realtime:** "broadcast Supabase", "presence", "postgres_changes", "channel"
+- **Edge Functions:** "Edge Function", "Deno + Supabase", "supabase/functions"
+- **Storage:** "bucket", "signed URL", "upload Supabase"
+- **AI/RAG:** "pgvector", "embeddings + Supabase", "RAG with permissions"
+- **Background:** "pg_cron", "pgmq", "scheduled job Supabase"
+
+Para contexto sobre o que cada subcomando faz, leia [`/supabase`](./supabase.md) ou as 11 skills em `kit/skills/supabase-*/`.
+
+## Aliases (continuam funcionando)
+
+`/rapido`, `/expresso`, `/proximo`, `/depurar`, `/discutir-fase`, `/planejar-fase`, `/executar-fase` — todos continuam executando direto, sem passar pelo `/fazer`. Use `/fazer` quando estiver em dúvida sobre qual escolher.
 </objective>
 
 <execution_context>

package/kit/commands/proximo.md

@@ -13,6 +13,13 @@ Detectar o estado atual do projeto e automaticamente invocar o próximo passo l
 Sem argumentos necessários — lê STATE.md, ROADMAP.md e diretórios de fase para determinar o que vem a seguir.
 
 Projetado para workflows multi-projeto rápidos onde lembrar em qual fase/passo você está é overhead.
+
+## Quando usar
+
+- ✅ "Não lembro onde parei" — `/proximo` lê estado e avança
+- ✅ Pulando entre vários projetos durante o dia
+- ❌ Sabe exatamente o que fazer — invoque o comando direto
+- 🤔 Tem uma intenção mas não sabe qual comando usar? → **`/fazer "descrição"`**
 </objective>
 
 <execution_context>

package/kit/commands/rapido.md

@@ -19,6 +19,12 @@ correções de typo, mudanças de configuração, pequenas refatorações, commi
 Este NÃO é um substituto para /expresso — use /expresso para qualquer coisa que
 precise de pesquisa, planejamento multi-etapas ou verificação. /rapido é para tarefas
 que você poderia descrever em uma frase e executar em menos de 2 minutos.
+
+## Quando usar
+
+- ✅ "renomear variável X pra Y", "ajustar copy do botão", "adicionar log", "fix de typo"
+- ❌ Multi-arquivo, multi-passo, requer pesquisa — use `/expresso` ou `/planejar-fase`
+- 🤔 Em dúvida sobre qual comando? → **`/fazer "descrição"`** roteia automaticamente
 </objective>
 
 <execution_context>

package/kit/commands/supabase.md

@@ -0,0 +1,148 @@
+---
+name: supabase
+description: Orquestrador da Suíte Supabase — dispatch para agents especializados (arquiteto, migration, rls, edge, realtime, auth, storage, rag, cron, check) com sinônimos PT/EN.
+argument-hint: "<subcomando> [args...]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+  - Task
+  - AskUserQuestion
+---
+
+<objective>
+Orquestrador único da Suíte Supabase. Recebe um subcomando e args, faz dispatch via `Task(subagent_type=supabase-...)` para o agent especializado correto. É o **único ponto de chain de agents Supabase** — agents permanecem função pura (anti-pitfall A10 de v1.8).
+
+**Cria/Atualiza:** o que cada agent invocado cria/atualiza (migrations, schemas, functions, etc.).
+
+**Após:** o usuário tem o output do agent (plano, código, SQL, ou veredito).
+</objective>
+
+<execution_context>
+Skills consultadas pelos agents: `kit/skills/supabase-*/SKILL.md` + `kit/skills/_shared-supabase/glossary.md` (Phase 25).
+Agents disponíveis: `kit/agents/supabase-*.md` (Phase 26) + `kit/agents/schema-checker.md` (existente).
+</execution_context>
+
+<context>
+**Argumentos:** `$ARGUMENTS` — primeiro token é o subcomando; restante é passado para o agent como prompt.
+
+**Subcomandos suportados (sinônimos PT-BR/EN):**
+
+| Subcomando | Sinônimos | Agent dispatched |
+|---|---|---|
+| `arquiteto` | `architect`, `arch` | `supabase-architect` |
+| `migration` | `migrar`, `migrate` | `supabase-migration-writer` |
+| `rls` | — | `supabase-rls-writer` |
+| `edge` | `edge-function`, `function`, `funcao` | `supabase-edge-fn-writer` |
+| `realtime` | `tempo-real` | `supabase-realtime-implementer` |
+| `auth` | `autenticacao`, `auth-ssr` | `supabase-auth-bootstrapper` |
+| `storage` | `armazenamento` | `supabase-storage-implementer` |
+| `rag` | `pgvector`, `embeddings` | `supabase-edge-fn-writer` com prompt sobre embeddings |
+| `cron` | `queues`, `pgmq`, `background` | `supabase-edge-fn-writer` com prompt sobre `cron → pgmq → Edge` |
+| `check` | `validar`, `validate` | `schema-checker` (validação pré-migration) |
+| `help` | `ajuda`, `?` | exibe esta tabela inline |
+
+**Detect `supabase/config.toml`:** se presente, extrai `project_id` (linha `project_id = "<ref>"`) e passa como contexto para o agent.
+</context>
+
+<process>
+
+## 1. Parsear Subcomando
+
+```bash
+# PT-BR: extrair primeiro token de $ARGUMENTS como subcomando
+SUBCMD=$(echo "$ARGUMENTS" | awk '{print $1}')
+ARGS=$(echo "$ARGUMENTS" | cut -d' ' -f2-)
+```
+
+**Se `$ARGUMENTS` for vazio ou `SUBCMD` for `help`/`ajuda`/`?`:** exibir tabela de subcomandos inline + exemplo de uso. Sair.
+
+## 2. Resolver Sinônimos
+
+Mapear `SUBCMD` para agent name canônico:
+
+```
+arquiteto, architect, arch       → supabase-architect
+migration, migrar, migrate       → supabase-migration-writer
+rls                              → supabase-rls-writer
+edge, edge-function, function, funcao → supabase-edge-fn-writer
+realtime, tempo-real             → supabase-realtime-implementer
+auth, autenticacao, auth-ssr     → supabase-auth-bootstrapper
+storage, armazenamento           → supabase-storage-implementer
+rag, pgvector, embeddings        → supabase-edge-fn-writer (com flag rag=true no prompt)
+cron, queues, pgmq, background   → supabase-edge-fn-writer (com flag pattern=cron-pgmq no prompt)
+check, validar, validate         → schema-checker
+```
+
+**Se subcomando não resolve:** exibir erro inline com lista de subcomandos válidos. Sair.
+
+```
+✗ Subcomando desconhecido: '<SUBCMD>'
+
+Subcomandos válidos:
+  arquiteto / architect    → projetar schema + RLS + topology antes de implementar
+  migration / migrar       → escrever migration SQL
+  rls                      → gerar policies RLS para tabela
+  edge                     → escrever Edge Function Deno
+  realtime                 → configurar canais Realtime (RLS + trigger + client)
+  auth                     → bootstrap Next.js v16 + Supabase Auth (SSR)
+  storage                  → configurar Storage (bucket + RLS + client)
+  rag                      → Edge Function com embeddings + pgvector
+  cron                     → pattern cron → pgmq → Edge Function
+  check                    → validar SQL antes de apply (schema-checker)
+
+Uso: /supabase <subcomando> <args...>
+Exemplo: /supabase arquiteto "app de chat com presence multi-room"
+```
+
+## 3. Detectar `supabase/config.toml`
+
+```bash
+if [ -f supabase/config.toml ]; then
+  PROJECT_ID=$(grep -E '^project_id\s*=' supabase/config.toml | sed 's/.*= *"\(.*\)".*/\1/' | head -1)
+fi
+```
+
+Se presente, anexar `project_id=<value>` ao prompt do agent. Se ausente, agent funciona sem (offline ou pergunta ao user).
+
+## 4. Dispatch
+
+Invocar `Task(subagent_type=<agent_name>, prompt=<built_prompt>)`.
+
+**Prompt construído:**
+
+```
+{ARGS}
+
+{Se project_id detectado:}
+project_id: {PROJECT_ID}
+
+{Se subcomando rag/cron — flag de modo:}
+mode: rag-embeddings   (ou cron-pgmq-edge)
+
+{Para architect: tier upfront via AskUserQuestion}
+{caller: pergunte ao user via AskUserQuestion sobre tier (Free/Pro/Team) e branches antes de produzir o plano — ver supabase-architect Step 1}
+```
+
+**Subcomando `arquiteto`:** antes de dispatch, faça `AskUserQuestion` perguntando tier (Free/Pro/Team/Enterprise) e se vai usar branches. Inclua resposta no prompt.
+
+**Subcomando `check`:** dispatch para `schema-checker` (existente). O caller deve passar `migration_path` e `project_id` no `$ARGUMENTS` — exemplo: `/supabase check supabase/migrations/20260506_x.sql`.
+
+## 5. Output
+
+Output do agent é o output do command. Sem post-processing — agent já formata estruturado.
+
+</process>
+
+<success_criteria>
+- [ ] Subcomando resolvido para agent canônico (10 subcomandos × seus sinônimos)
+- [ ] `project_id` extraído de `supabase/config.toml` se presente
+- [ ] Subcomando `arquiteto` faz `AskUserQuestion` upfront sobre tier + branches
+- [ ] Dispatch via `Task(subagent_type=...)` — único ponto de chain de agents Supabase
+- [ ] Subcomando inválido → mensagem clara com lista
+- [ ] Subcomando `help`/`ajuda`/`?` → exibe tabela inline
+- [ ] Subcomando `check` → invoca `schema-checker` (existente)
+- [ ] Args após subcomando passam transparentemente para o agent
+</success_criteria>

package/kit/framework/references/output-style.md

@@ -0,0 +1,22 @@
+# Output Style — Caveman (compartilhado por todos os agentes framework)
+
+> Referenciado por agentes via `@./.claude/framework/references/output-style.md`. Agentes herdam essas regras automaticamente — não duplique o conteúdo no agente.
+
+**Estilo: caveman — compressão alta na fala, prosa normal em artefatos.**
+
+Em mensagens conversacionais, logs e relatórios ao orquestrador:
+- Cortar: filler (just/really/basically/actually/simply), pleasantries (claro/com certeza/feliz em ajudar), hedging desnecessário, artigos quando não compromete clareza
+- Fragments OK. Sinônimos curtos. Padrão: `[coisa] [ação] [razão]. [próximo passo].`
+- Termos técnicos exatos. Código inalterado. Erros citados literais.
+- NÃO: "Claro! O problema que você está enfrentando provavelmente é causado por..."
+- SIM: "Bug em auth middleware. Token expiry usa `<` em vez de `<=`. Fix:"
+
+**Auto-clarity — sair do caveman quando:**
+- Avisos de segurança ou ações destrutivas/irreversíveis
+- Sequências multi-passo onde fragmentar arrisca má interpretação
+- Usuário pediu clarificação ou está confuso
+
+**Boundary CRÍTICO — artefatos em `.planning/` mantêm formato completo:**
+PLAN.md, ROADMAP.md, REQUIREMENTS.md, CONTEXT.md, SUMMARY.md, VERIFICATION.md e qualquer outro artefato em `.planning/` é o **prompt de execução** ou registro auditável que outros agentes/humanos vão consumir. Esses DEVEM seguir prosa estruturada conforme template, com regras inequívocas, dependências explícitas e critérios completos. Caveman em artefatos = ambíguo = quebrado.
+
+**Caveman aplica-se SÓ ao raciocínio falado, logs de progresso e retorno ao orquestrador — NUNCA ao conteúdo de artefatos em `.planning/`.**