@luanpdd/kit-mcp 1.7.0 → 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/user-profiler.md

@@ -1,6 +1,6 @@
 ---
 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
 ---

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:

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/fazer.md

@@ -19,10 +19,25 @@ allowed-tools:
 | 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.

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/workflows/discuss-phase.md

@@ -43,6 +43,25 @@ Pergunte sobre visão e escolhas; capture decisões pra agentes downstream.
 **Quando usuário sugere expansão:** "[X] seria nova capacidade — fase própria. Anoto pro backlog. De volta a [tópico]." Capture em "Ideias Adiadas". Não perca, não aja.
 </scope_guardrail>
 
+<supabase_detection>
+**Detecção de fase Supabase:** antes de identificar áreas cinzentas genéricas, verifique se a fase mexe em Supabase (DB/Auth/Realtime/Edge Functions/Storage/RLS/migrations).
+
+Sinais de fase Supabase no objetivo do ROADMAP.md ou nos REQs mapeados:
+- Menções a "Supabase", "Postgres", "RLS", "policy", "migration", "supabase/migrations/", "supabase/schemas/", "supabase/functions/"
+- Menções a "Auth Next.js", "@supabase/ssr", "magic link", "OAuth", "MFA"
+- Menções a "broadcast", "realtime", "presence", "postgres_changes"
+- Menções a "Edge Function", "Deno", "pgvector", "RAG", "pg_cron", "pgmq"
+- Menções a "bucket", "signed URL", "storage.objects"
+
+**Se for fase Supabase:** considere delegar a discussão para o agent `supabase-architect` em vez de gerar áreas cinzentas genéricas. O architect já tem template de perguntas Supabase-específicas (tier Free/Pro, branches, RLS strategy multi-tenant, schema design, topology realtime, custos de egress/branches).
+
+```
+Task(subagent_type=supabase-architect, prompt="Projete schema + RLS + topologia para esta fase Supabase: {phase_goal}. Retorne plano em formato Markdown estruturado para servir de base ao CONTEXT.md.")
+```
+
+Use o output do architect como base do `<decisions>` do CONTEXT.md em vez de fazer questionamento manual. **Para fases mistas** (parte Supabase, parte genérica) — use architect só para a parte Supabase, depois faça discussão padrão para o resto.
+</supabase_detection>
+
 <gray_area_identification>
 Áreas cinzentas são **decisões de implementação que o usuário se importa** — coisas que podem ir de múltiplas formas e mudariam o resultado.
 

package/kit/framework/workflows/plan-phase.md

@@ -13,8 +13,33 @@ Tipos de subagentes framework válidos (use nomes exatos — não use 'general-p
 - phase-researcher — Pesquisa abordagens técnicas para uma fase
 - planner — Cria planos detalhados a partir do escopo da fase
 - plan-checker — Revisa qualidade do plano antes da execução
+
+**Agents especializados por domínio** (use ao invés de phase-researcher quando aplicável):
+- supabase-architect — para fases Supabase (DB/Auth/Realtime/Edge/Storage), substitui phase-researcher genérico. Já tem questionamento Supabase-específico (tier, branches, RLS strategy, multi-tenant).
+- supabase-{migration-writer,rls-writer,edge-fn-writer,realtime-implementer,auth-bootstrapper,storage-implementer} — destinos de delegação que o `planner` pode incluir como `subagent_type` em tasks específicas do PLAN.md.
+- schema-checker — pré-validação de SQL para tasks que tocam migrations existentes.
 </available_agent_types>
 
+<supabase_phase_detection>
+**Detecção de fase Supabase no Step 1:** após carregar contexto via `init plan-phase`, verifique se a fase mexe em domínios Supabase (DB/Auth/Realtime/Edge/Storage/RLS/migrations). Sinais no objetivo do ROADMAP.md ou nos REQs mapeados: "Supabase", "Postgres", "RLS", "migration", "Edge Function", "broadcast", "pgvector", "bucket", `supabase/migrations/`, `supabase/schemas/`, `supabase/functions/`.
+
+**Se for fase Supabase:**
+1. **Pesquisa:** invoque `supabase-architect` em vez de `phase-researcher` genérico no Step 5 (Tratar Pesquisa). Architect produz plano de schema/RLS/topology que o planner usa como base.
+2. **Plano:** o `planner` deve incluir tasks com `subagent_type` apontando para o agent especializado correto (ver tabela abaixo). O `executor` lê e dispatcha automaticamente.
+
+| Task no plano envolve | `subagent_type:` para o `executor` dispatch |
+|---|---|
+| Migration ou schema declarative | `supabase-migration-writer` |
+| RLS policies | `supabase-rls-writer` |
+| Edge Function | `supabase-edge-fn-writer` |
+| Realtime (3 layers) | `supabase-realtime-implementer` |
+| Bootstrap auth Next.js | `supabase-auth-bootstrapper` |
+| Storage bucket + RLS | `supabase-storage-implementer` |
+| Validar SQL pre-apply | `schema-checker` |
+
+**Anti-pitfall:** agents `supabase-*` não devem se invocar uns aos outros — toda chain passa pelo `executor` lendo o plan. (Gate `agent-no-recursive-dispatch` valida.)
+</supabase_phase_detection>
+
 <process>
 
 ## 1. Inicializar