@luanpdd/kit-mcp 1.7.0 → 1.9.0

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

@@ -0,0 +1,258 @@
+---
+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)
+
+## Observabilidade integrada
+
+Upload events são quentes em custo (egress + storage) e em UX (lentidão de upload = abandono). Instrumentar SEMPRE.
+
+1. **Span por upload/download** (skill [`structured-events`](../skills/structured-events/SKILL.md)) com atributos:
+   - `bucket.name`, `bucket.public` (bool)
+   - `file.size_bytes`, `file.mime_type`, `file.path`
+   - `operation`: `upload` | `download` | `signed_url` | `delete`
+   - `result.success`, `error.type` (enum: `quota_exceeded`, `unauthorized`, `mime_blocked`, `size_exceeded`, `network`)
+   - `duration_ms`, `transfer.bytes_per_second` (calculado)
+   - `user.id`, `tenant_id` (do `auth.uid()`)
+2. **Sampling** (skill [`telemetry-sampling`](../skills/telemetry-sampling/SKILL.md) *Phase 34*): 100% errors, 100% uploads > 10 MB (cardinalidade baixa, valor alto), 5% baseline para downloads pequenos (alto volume).
+3. **Audit log** para uploads em buckets sensíveis (`audit_log` table com `actor`, `op`, `resource`, `geo`, `user_agent`).
+
+**Output adicionado:** seção "## Observability hooks" com snippet de upload/download wrapper.
+
+## 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()`
+- [structured-events](../skills/structured-events/SKILL.md) — campos canônicos para upload/download events
+- [telemetry-sampling](../skills/telemetry-sampling/SKILL.md) *(Phase 34)* — head-based sampling por size_bytes

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/auditar-marco.md

@@ -33,4 +33,25 @@ Glob: .planning/phases/*/*-VERIFICATION.md
 <process>
 Execute o workflow audit-milestone de @./.claude/framework/workflows/audit-milestone.md do início ao fim.
 Preserve todos os checkpoints do workflow (determinação de escopo, leitura de verificações, checagem de integração, cobertura de requisitos, roteamento).
-</process>
+</process>
+
+<observability_integration>
+**OMM scoring (v1.9 — INT-FW-04):**
+
+Quando `workflow.audit_milestone_omm = true` (default), o workflow inclui passo OMM scoring:
+
+```text
+Skill(skill="framework:auditar-observabilidade")
+```
+
+O comando `/auditar-observabilidade` invoca o agente [`omm-auditor`](../agents/omm-auditor.md) que pontua as 5 capacidades (resiliência, qualidade, complexidade, cadência, comportamento) contra o marco anterior. O OMM-REPORT.md gerado é incluído como anexo no MILESTONE-AUDIT.md.
+
+Resultado de regression OMM:
+- **0 regressions:** audit aprovado
+- **1+ regressions, blocking=false:** warn explícito; audit aprovado com nota
+- **1+ regressions, blocking=true (`workflow.omm_no_regression=true`):** audit fail → user escolha entre fix lacunas ou aceitar
+
+Skill consultada: [`observability-maturity-model`](../skills/observability-maturity-model/SKILL.md).
+
+**REQ:** INT-FW-04.
+</observability_integration>

package/kit/commands/auditar-observabilidade.md

@@ -0,0 +1,103 @@
+---
+name: auditar-observabilidade
+description: Invoca omm-auditor para gerar OMM-REPORT.md scored. 5 capacidades com trend vs marco anterior. Action items priorizados P0-P3.
+argument-hint: "[--previous <marco>] [--ci]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Task
+---
+
+<objective>
+Gerar OMM-REPORT.md com snapshot scored das 5 capacidades de observabilidade. Aplica skill [`observability-maturity-model`](../skills/observability-maturity-model/SKILL.md) — sintomas qualitativos doing well/poorly por capacidade.
+
+**Cria/Atualiza:**
+- `.planning/OMM-REPORT.md` — snapshot atual
+- (Em `/concluir-marco`) `.planning/milestones/<v>/OMM-REPORT.md` — snapshot arquivado
+
+**Após:** time tem 5 scores + trend + action items priorizados.
+</objective>
+
+<context>
+**Argumentos:** `$ARGUMENTS`
+
+**Flags:**
+- `--previous <marco>` — comparar com marco específico (default: detecta automaticamente do MILESTONES.md)
+- `--ci` — modo CI: exit code 0 se OK, 1 se regression em qualquer capacidade
+
+**Quando rodar:**
+- Manualmente para snapshot informal
+- Em `/auditar-marco` (audit pre-conclusion) — Phase 35 INT-FW-04
+- Em `/concluir-marco` (gate de regression) — Phase 35 INT-FW-05
+</context>
+
+<process>
+
+## 1. Parsear argumentos
+
+```bash
+PREVIOUS=$(echo "$ARGUMENTS" | grep -oE -- '--previous [^ ]+' | awk '{print $2}')
+CI_MODE=$(echo "$ARGUMENTS" | grep -c -- '--ci' || true)
+```
+
+## 2. Detectar previous milestone
+
+```bash
+if [ -z "$PREVIOUS" ]; then
+  # PT-BR: extrair último concluído de MILESTONES.md
+  PREVIOUS=$(grep -E '^### v[0-9.]+\b' .planning/MILESTONES.md | head -2 | tail -1 | grep -oE 'v[0-9.]+')
+fi
+```
+
+## 3. Dispatch para `omm-auditor`
+
+```text
+Task(
+  subagent_type="omm-auditor",
+  prompt="
+${PREVIOUS:+previous_milestone: ${PREVIOUS}}
+mode: ${CI_MODE:+ci}snapshot
+
+Gerar OMM-REPORT.md com:
+1. Score 1-5 por capacidade (5 capacidades)
+2. Trend vs ${PREVIOUS:-último marco}
+3. Action items priorizados P0-P3
+4. Regression alerts (se alguma capacidade regrediu)
+5. Comparação por marco
+"
+)
+```
+
+## 4. Pós-output
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► AUDITAR-OBSERVABILIDADE
+═══════════════════════════════════════════════════════════
+
+[output do omm-auditor — snapshot inline]
+
+OMM-REPORT.md: .planning/OMM-REPORT.md
+
+${CI_MODE:+## CI Mode}
+${CI_MODE:+Exit code: 0 (OK) / 1 (regression detectada)}
+```
+
+## 5. Modo `--ci`
+
+Se `--ci` setado:
+- Parse OMM-REPORT.md para detectar regression alerts
+- Se ≥ 1 regression → exit 1 (CI fails)
+- Senão → exit 0 (OK)
+
+</process>
+
+<success_criteria>
+- [ ] omm-auditor invocado via Task
+- [ ] OMM-REPORT.md gerado em `.planning/OMM-REPORT.md`
+- [ ] 5 capacidades scored
+- [ ] Trend calculado vs `--previous` ou auto-detectado
+- [ ] Action items P0-P3 listados
+- [ ] Modo `--ci` exit code apropriado se regression
+</success_criteria>

package/kit/commands/burn-rate-status.md

@@ -0,0 +1,140 @@
+---
+name: burn-rate-status
+description: Tabela de burn rate por SLO — % budget gasto, ETA exhaustão, ação (page/ticket/warn/ok). Rodável manualmente ou em /loop. Aplica skill burn-rate-alerting.
+argument-hint: "[<slo_name>] [--lookahead 4h] [--baseline 1h]"
+allowed-tools:
+  - Read
+  - Bash
+  - Task
+  - Glob
+---
+
+<objective>
+Snapshot de burn rate para 1 SLO (se especificado) ou TODOS os SLOs definidos. Aplica skill [`burn-rate-alerting`](../skills/burn-rate-alerting/SKILL.md) — fórmula `burn_rate = error_rate / (1 - target)`, lookahead ≤ 4× baseline.
+
+**Cria/Atualiza:** nada — comando read-only.
+
+**Após:** o user vê tabela com status (PAGE / TICKET / WARN / OK) e pode escolher invocar `/investigar-producao` se há burn ativo.
+</objective>
+
+<context>
+**Argumentos:** `$ARGUMENTS` — opcional `<slo_name>` para 1 SLO; sem args = todos.
+
+**Flags:**
+- `--lookahead <duration>` — janela predictive (default: `4h` para short-term)
+- `--baseline <duration>` — janela base (default: `1h`)
+- `--format <table|json>` — output format (default: `table`)
+
+**Combinações canônicas:**
+- short-term: lookahead 4h, baseline 1h (page-tier)
+- long-term: lookahead 3d, baseline 18h (ticket-tier)
+
+**Loop pattern:** rodar este comando via skill `loop` com intervalo 5min para monitoramento contínuo.
+
+```text
+/loop 5m /burn-rate-status
+```
+</context>
+
+<process>
+
+## 1. Parsear argumentos
+
+```bash
+SLO_NAME=$(echo "$ARGUMENTS" | awk '{print $1}' | grep -v '^--' || true)
+LOOKAHEAD=$(echo "$ARGUMENTS" | grep -oE -- '--lookahead [^ ]+' | awk '{print $2}')
+BASELINE=$(echo "$ARGUMENTS" | grep -oE -- '--baseline [^ ]+' | awk '{print $2}')
+FORMAT=$(echo "$ARGUMENTS" | grep -oE -- '--format [^ ]+' | awk '{print $2}')
+
+[ -z "$LOOKAHEAD" ] && LOOKAHEAD="4h"
+[ -z "$BASELINE" ] && BASELINE="1h"
+[ -z "$FORMAT" ] && FORMAT="table"
+```
+
+## 2. Listar SLOs
+
+```bash
+if [ -n "$SLO_NAME" ]; then
+  SLO_FILES=(".planning/slos/${SLO_NAME}.md")
+else
+  SLO_FILES=(.planning/slos/*.md)
+fi
+
+if [ ${#SLO_FILES[@]} -eq 0 ] || [ ! -f "${SLO_FILES[0]}" ]; then
+  echo "Nenhum SLO definido. Rode /definir-slo <feature> primeiro."
+  exit 0
+fi
+```
+
+## 3. Para cada SLO, dispatch para `burn-rate-forecaster`
+
+Para cada `SLO_FILE`:
+
+```bash
+SLO_NAME=$(basename "$SLO_FILE" .md)
+TARGET=$(grep -oE 'Target.*[0-9.]+' "$SLO_FILE" | head -1 | grep -oE '[0-9.]+')
+```
+
+```text
+Task(
+  subagent_type="burn-rate-forecaster",
+  prompt="
+slo_name: ${SLO_NAME}
+target: ${TARGET}
+lookahead: ${LOOKAHEAD}
+baseline: ${BASELINE}
+
+Calcular burn rate atual + ETA + status (PAGE/TICKET/WARN/OK).
+Output formato compatível com tabela mestra.
+"
+)
+```
+
+## 4. Agregar resultados em tabela
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► BURN-RATE-STATUS ▸ {timestamp}
+═══════════════════════════════════════════════════════════
+
+| SLO | Target | Window | Budget gasto | Burn rate | ETA exhaustão | Status | Ação |
+|---|---|---|---|---|---|---|---|
+| checkout_success | 99.9% | 30d | 23% | 1.4× | 12d | OK | informativo |
+| login_success | 99.95% | 30d | 78% | 8.0× | 4h | **PAGE** | invocar /investigar-producao |
+| search_latency | 99% | 30d | 15% | 0.7× | — | OK | — |
+```
+
+## 5. Sugerir próximas ações
+
+Se algum SLO em status PAGE ou TICKET:
+
+```
+## ⚠ SLOs em alerta:
+1. login_success — burn rate 8.0×, ETA 4h
+   → /investigar-producao "login_success burn rate = 8.0× às {timestamp}"
+
+## SLOs em WARN (>= 80% gasto):
+- (nenhum)
+
+## SLOs OK:
+- 2 SLOs em compliance saudável
+```
+
+## 6. Modo `/loop`
+
+Se chamado dentro de `/loop`, comportamento idempotente:
+- Não acumular state entre invocações (snapshot fresh)
+- Output curto se nada mudou (apenas status; sem repetir tabela completa em todo loop)
+- Acionar AskUserQuestion APENAS quando status muda de OK → WARN/TICKET/PAGE (transição)
+
+</process>
+
+<success_criteria>
+- [ ] $ARGUMENTS parseados (SLO opcional + flags)
+- [ ] SLOs descobertos via glob `.planning/slos/*.md`
+- [ ] `burn-rate-forecaster` invocado para cada SLO
+- [ ] Tabela agregada em formato consistente
+- [ ] Status enum: PAGE / TICKET / WARN / OK
+- [ ] Sugestões de próximas ações para SLOs em alerta
+- [ ] Idempotente (rodável em /loop sem acúmulo)
+</success_criteria>

package/kit/commands/concluir-marco.md

@@ -133,4 +133,22 @@ Saída: Milestone arquivado (roadmap + requisitos), PROJECT.md evoluído, tag gi
 - **Resumo de uma linha:** Milestone colapsado no ROADMAP.md deve ser uma única linha com link
 - **Eficiência de contexto:** Arquivo mantém ROADMAP.md e REQUIREMENTS.md com tamanho constante por milestone
 - **Novos requisitos:** Próximo milestone começa com `/novo-marco` que inclui definição de requisitos
-  </critical_rules>
+  </critical_rules>
+
+<observability_integration>
+**OMM no-regression gate (v1.9 — INT-FW-05):**
+
+Quando `workflow.complete_milestone_omm_gate = true` (default), o workflow inclui passo OMM regression check antes de arquivar:
+
+1. Procurar `.planning/OMM-REPORT.md` atual. Se ausente: rodar `/auditar-observabilidade` primeiro.
+2. Comparar scores das 5 capacidades com `.planning/milestones/<previous>/OMM-REPORT.md`.
+3. Se alguma capacidade regrediu E `workflow.omm_no_regression = true`: BLOQUEAR conclusion.
+4. Se regression detectada mas `workflow.omm_no_regression = false`: WARN explícito; user decide entre aceitar ou pausar.
+5. OMM-REPORT.md final é arquivado em `.planning/milestones/v<version>/OMM-REPORT.md`.
+
+Gate executável: `gates/omm-no-regression.md`.
+
+Skill consultada: [`observability-maturity-model`](../skills/observability-maturity-model/SKILL.md).
+
+**REQ:** INT-FW-05.
+</observability_integration>

package/kit/commands/definir-slo.md

@@ -0,0 +1,108 @@
+---
+name: definir-slo
+description: Invoca slo-engineer para gerar SLO.md + SQL materialização SLI events. Aplica skill event-based-slos. Default 30d sliding window, target ≤ 99.95%.
+argument-hint: "<feature> [--target 99.9] [--owner email]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Task
+  - AskUserQuestion
+---
+
+<objective>
+Definir um SLO event-based para uma feature/jornada do usuário. Invoca o agente [`slo-engineer`](../agents/slo-engineer.md) que aplica a skill [`event-based-slos`](../skills/event-based-slos/SKILL.md) — SLI event-based, sliding window 30d, target ≤ 99.95%, owner nomeado, materialização em Postgres.
+
+**Cria/Atualiza:**
+- `.planning/slos/<slo_name>.md` — definição canônica do SLO
+- `supabase/migrations/<timestamp>_create_sli_<slo_name>.sql` — view materializada SLI
+
+**Após:** SLO está em `draft` status. Próximo passo: `/burn-rate-status <slo_name>` para validar baseline; após 1+ semana, promover de `draft` → `test_channel` → `primary`.
+</objective>
+
+<context>
+**Argumentos:** `$ARGUMENTS` — primeiro token é a feature/jornada (ex: `checkout`, `login`, `bulk-orders`); restante são flags.
+
+**Flags:**
+- `--target <percent>` — target % do SLO (default: agent sugere baseado em criticality, sempre ≤ 99.95%)
+- `--owner <email>` — owner do SLO (default: AskUserQuestion)
+- `--window <duration>` — sliding window (default: `30d`)
+
+**Pré-requisito (Full mode):** projeto Supabase configurado, schema `observability` com tabela de events (Phase 31 supabase-architect projeta isso).
+</context>
+
+<process>
+
+## 1. Parsear argumentos
+
+```bash
+FEATURE=$(echo "$ARGUMENTS" | awk '{print $1}')
+TARGET=$(echo "$ARGUMENTS" | grep -oE -- '--target [0-9.]+' | awk '{print $2}')
+OWNER=$(echo "$ARGUMENTS" | grep -oE -- '--owner [^ ]+' | awk '{print $2}')
+WINDOW=$(echo "$ARGUMENTS" | grep -oE -- '--window [^ ]+' | awk '{print $2}')
+
+[ -z "$FEATURE" ] && {
+  echo "Uso: /definir-slo <feature> [--target N] [--owner email]"
+  exit 1
+}
+
+[ -z "$WINDOW" ] && WINDOW="30d"
+```
+
+## 2. Detectar `supabase/config.toml`
+
+```bash
+PROJECT_ID=""
+if [ -f supabase/config.toml ]; then
+  PROJECT_ID=$(grep -E '^project_id\s*=' supabase/config.toml | sed 's/.*= *"\(.*\)".*/\1/' | head -1)
+fi
+```
+
+## 3. Dispatch para `slo-engineer`
+
+```text
+Task(
+  subagent_type="slo-engineer",
+  prompt="
+feature: ${FEATURE}
+${TARGET:+target: ${TARGET}}
+${OWNER:+owner: ${OWNER}}
+window: ${WINDOW}
+${PROJECT_ID:+project_id: ${PROJECT_ID}}
+
+Aplicar skill event-based-slos. Gerar:
+1. .planning/slos/<slo_name>.md (SLO definition canônico)
+2. supabase/migrations/<timestamp>_create_sli_<slo_name>.sql (materialized view + pg_cron refresh)
+
+Se target > 99.95%, recusar e explicar — métrica informativa, não SLO.
+Se Full mode (mcp__supabase disponível), apply_migration; senão, output text.
+"
+)
+```
+
+## 4. Pós-output
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► DEFINIR-SLO ▸ {slo_name}
+═══════════════════════════════════════════════════════════
+
+[output do slo-engineer — ver Step 8 do agent]
+
+## Próximos passos
+1. `/burn-rate-status {slo_name}` — checar baseline atual
+2. Após 1+ semana validando que SLO detecta incidents reais:
+   - Editar `.planning/slos/{slo_name}.md` → status: `test_channel` → `primary`
+3. Configurar alerts (page + ticket) — invocar `burn-rate-forecaster` ou config manual
+```
+
+</process>
+
+<success_criteria>
+- [ ] FEATURE parseado de $ARGUMENTS
+- [ ] `slo-engineer` invocado via Task
+- [ ] `.planning/slos/<slo_name>.md` criado
+- [ ] Migration SQL criada (Full mode applied; Offline mode escrita)
+- [ ] Target ≤ 99.95% enforced
+- [ ] Owner registrado (via flag ou AskUserQuestion)
+</success_criteria>