@luanpdd/kit-mcp 1.8.1 → 1.10.0

package/kit/commands/prr.md

@@ -0,0 +1,205 @@
+---
+name: prr
+description: Invoca prr-conductor — Production Readiness Review scored em 6 axes (cap 32); modos --service <name> ou --feature <desc>; offline fallback se MCP ausente.
+argument-hint: "(--service <name> | --feature \"<desc>\") [--engagement simple|early|platform] [--reviewer @sre]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+  - Task
+  - AskUserQuestion
+---
+
+<objective>
+Conduzir **Production Readiness Review** (PRR — cap 32 do livro Google SRE) para serviço/feature antes de production. Invoca o agente [`prr-conductor`](../agents/prr-conductor.md) que aplica a skill [`production-readiness-review`](../skills/production-readiness-review/SKILL.md) — checklist canônico **6 axes** + **3 engagement models** + handoff dev→SRE.
+
+**6 axes obrigatórios** (pular um = aprovação inválida):
+1. System Architecture — design, dependencies, blast radius, isolation
+2. Instrumentation/Metrics/Monitoring — 4 golden signals, SLOs, alerting
+3. Emergency Response — runbooks, on-call, rollback, communication
+4. Capacity Planning — load testing, scaling, headroom
+5. Change Management — canary, feature flags, rollback < 60s
+6. Performance — latency budgets, throughput, optimization
+
+**Cria/Atualiza:**
+- `.planning/prr/<service>.md` (Modo A) OR `.planning/prr/feature-<slug>.md` (Modo B) — PRR-REPORT.md scored
+
+**Após:** o user tem decisão `Approved` / `Approved with conditions` / `Blocked` + lista canônica de P0 items por axe + reviewer signature. Phase 40 INT-FW-V2-02 integra `/concluir-marco` com gate PRR opcional.
+</objective>
+
+<context>
+**Argumentos:** `$ARGUMENTS` — comando suporta **2 modos mutuamente exclusivos**.
+
+**Modo A: `--service <name>` (audit de serviço existente)**
+
+Para serviços já em production OU prestes a entrar — agent lê schema (Supabase MCP), Edge Functions code, SLOs definidos (`.planning/slos/`), advisors. Output: `.planning/prr/<service>.md`.
+
+**Modo B: `--feature <description>` (audit pré-launch)**
+
+Para feature em design/dev — agent lê design docs, SLOs propostos, código WIP. Output: `.planning/prr/feature-<slug>.md`.
+
+**Engagement models (cap 32):**
+- `simple` — outage cost < $1k/min OR internal tool — 4-8h, 1 sessão
+- `early` — outage cost $1k-100k/min OR customer-facing — semanas, SRE no design
+- `platform` — outage cost > $100k/min OR built on Frameworks/SRE Platform — PRR é confirmação
+
+**Flags:**
+- `--engagement <simple|early|platform>` — engagement model (default: AskUserQuestion baseado em outage cost)
+- `--reviewer <@handle>` — handle do reviewer SRE (default: AskUserQuestion — **NUNCA pode ser team dev**, anti-pattern auto-PRR)
+- `--outage-cost <usd>` — custo de outage por minuto (default: AskUserQuestion para escolher engagement)
+- `--output <path>` — caminho do output (override de default canônico)
+
+**Exemplos:**
+```
+/prr --service orders-api                                          # Modo A — defaults
+/prr --service orders-api --engagement early --reviewer @ops-lead  # Modo A com config
+/prr --feature "RAG sobre documentos privados" --reviewer @sre     # Modo B
+/prr --service edge-process-emails --engagement simple             # Edge Function simples
+```
+
+**Pré-requisito (Full mode):** projeto Supabase configurado, `mcp__supabase__*` disponível. Modo offline funciona com fallback graceful (filesystem only — itens MCP-dependentes ficam `EVIDENCE_PENDING_MCP`).
+</context>
+
+<process>
+
+## 1. Parsear argumentos (2 modos)
+
+```bash
+SERVICE=$(echo "$ARGUMENTS" | grep -oE -- '--service [^ ]+' | awk '{print $2}')
+FEATURE=$(echo "$ARGUMENTS" | grep -oE -- '--feature "[^"]+"' | sed 's/--feature //; s/^"//; s/"$//')
+ENGAGEMENT=$(echo "$ARGUMENTS" | grep -oE -- '--engagement [^ ]+' | awk '{print $2}')
+REVIEWER=$(echo "$ARGUMENTS" | grep -oE -- '--reviewer [^ ]+' | awk '{print $2}')
+OUTAGE_COST=$(echo "$ARGUMENTS" | grep -oE -- '--outage-cost [^ ]+' | awk '{print $2}')
+OUTPUT_PATH=$(echo "$ARGUMENTS" | grep -oE -- '--output [^ ]+' | awk '{print $2}')
+
+# PT-BR: validar mutuamente exclusivos
+if [ -n "$SERVICE" ] && [ -n "$FEATURE" ]; then
+  echo "✗ Erro: --service e --feature são mutuamente exclusivos. Escolha um."
+  exit 1
+fi
+
+# PT-BR: nenhum dos 2 → erro com sugestão
+if [ -z "$SERVICE" ] && [ -z "$FEATURE" ]; then
+  echo "✗ Forneça --service <name> OU --feature \"<descrição>\""
+  echo "  Exemplos:"
+  echo "    /prr --service orders-api"
+  echo "    /prr --feature \"RAG sobre documentos privados\""
+  exit 1
+fi
+```
+
+## 2. Resolver output_path + idempotência
+
+```bash
+if [ -n "$SERVICE" ]; then
+  [ -z "$OUTPUT_PATH" ] && OUTPUT_PATH=".planning/prr/${SERVICE}.md"
+else
+  SLUG=$(echo "$FEATURE" | tr ' ' '-' | tr -cd 'a-zA-Z0-9-' | head -c 30 | sed 's/-$//')
+  [ -z "$OUTPUT_PATH" ] && OUTPUT_PATH=".planning/prr/feature-${SLUG}.md"
+fi
+mkdir -p "$(dirname "$OUTPUT_PATH")"
+
+# PT-BR: PRR pode ser re-PRR (após mudança grande) — informar mas permitir
+if [ -f "$OUTPUT_PATH" ]; then
+  LAST_DATE=$(grep -m1 '**Date:**' "$OUTPUT_PATH" 2>/dev/null | sed 's/.*Date:\*\* //' || echo "?")
+  echo "ℹ PRR-REPORT.md anterior detectado ($LAST_DATE) em $OUTPUT_PATH."
+  echo "  Re-PRR válido (após mudança grande, incident, ou anual). Continuando — vai sobrescrever."
+fi
+```
+
+## 3. Detectar `supabase/config.toml` (Full mode)
+
+```bash
+PROJECT_ID=""
+if [ -f supabase/config.toml ]; then
+  PROJECT_ID=$(grep -E '^project_id\s*=' supabase/config.toml | sed 's/.*= *"\(.*\)".*/\1/' | head -1)
+  echo "✓ project_id detectado: $PROJECT_ID (Full mode com MCP Supabase)"
+else
+  echo "ℹ Sem supabase/config.toml — agent pode rodar em modo offline (fallback graceful)"
+fi
+```
+
+## 4. AskUserQuestion — engagement model + reviewer
+
+Se `--engagement` não fornecido E `--outage-cost` ausente:
+
+> **AskUserQuestion**
+> header: "PRR Engagement Model"
+> question: "Qual custo estimado de outage para este target?"
+> options:
+> - "< $1k/min OR internal tool → Simple PRR (4-8h, 1 sessão)"
+> - "$1k-100k/min OR customer-facing → Early Engagement (semanas, SRE no design)"
+> - "> $100k/min OR built on platform → Frameworks/Platform (PRR é confirmação)"
+
+Se `--reviewer` não fornecido (anti-pattern auto-PRR):
+
+> **AskUserQuestion**
+> header: "PRR Reviewer (anti auto-PRR)"
+> question: "Quem é o reviewer? Reviewer DEVE ser SRE OU par externo ao time dev (anti-pattern: time dev faz auto-PRR — confirmation bias)."
+> options: (texto livre — handle/email)
+
+## 5. Dispatch para `prr-conductor`
+
+```text
+Task(
+  subagent_type="prr-conductor",
+  prompt="
+${SERVICE:+service_name: ${SERVICE}}
+${FEATURE:+feature_description: ${FEATURE}}
+output_path: ${OUTPUT_PATH}
+${ENGAGEMENT:+engagement_model: ${ENGAGEMENT}}
+${REVIEWER:+reviewer: ${REVIEWER}}
+${OUTAGE_COST:+outage_cost_per_min: ${OUTAGE_COST}}
+${PROJECT_ID:+project_id: ${PROJECT_ID}}
+
+Aplicar skill production-readiness-review. Audit em 6 axes (todos obrigatórios — pular = inválido):
+1. System Architecture — design, dependencies, blast radius, isolation, single points of failure
+2. Instrumentation/Metrics/Monitoring — 4 golden signals, SLOs definidos, alerting com burn rates
+3. Emergency Response — runbooks atualizados, on-call rotation, rollback < 60s, communication plan
+4. Capacity Planning — load testing recente, scaling docs, headroom % atual vs peak
+5. Change Management — canary deployment, feature flags, rollback drills
+6. Performance — latency p50/p95/p99 vs budget, throughput vs target, optimization headroom
+
+Padrão obrigatório: cada item evidence-based (NÃO 'acreditamos que está pronto' — exigir query/log/runbook/test).
+Modo offline: se MCP ausente, declarar [MODO OFFLINE] e marcar items MCP-dependentes EVIDENCE_PENDING_MCP.
+Output: PRR-REPORT.md com scoring 0-5 por axe + status Pass/Pass with gaps/Fail + decisão Approved/Approved with conditions/Blocked + reviewer signature + Re-PRR triggers.
+"
+)
+```
+
+## 6. Pós-output
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► PRR ▸ ${SERVICE:-feature-${SLUG}}
+═══════════════════════════════════════════════════════════
+
+[output do prr-conductor — ver Step 3 do agent]
+
+## Estado salvo
+${OUTPUT_PATH}
+
+## Próximos passos
+1. Reviewer (`${REVIEWER}`) precisa assinar — anti-pattern: rubber stamp sem ler evidence
+2. P0 items são bloqueadores; P1 items são conditions; P2 items são monitoramento
+3. Re-PRR triggers (anual, mudança arquitetural grande, incident SEV1+) — agendar
+4. Se status `Approved` → liberar para production; se `Blocked` → fechar P0s antes de re-submit
+5. Cross-ref OMM: PRR alimenta Capacidade 4 (Production Readiness) — `/observabilidade omm`
+6. Phase 40 INT-FW-V2-02: `/concluir-marco` pode exigir PRR `Approved` se `workflow.complete_milestone_prr_gate=true`
+```
+
+</process>
+
+<success_criteria>
+- [ ] `--service <name>` E `--feature "<desc>"` parseados (mutuamente exclusivos)
+- [ ] Modo A: output canônico `.planning/prr/<service>.md` (override via `--output`)
+- [ ] Modo B: output canônico `.planning/prr/feature-<slug>.md` (slug auto-gerado)
+- [ ] Re-PRR não-bloqueante (informa mas permite — re-PRR é válido após mudança grande)
+- [ ] `supabase/config.toml` detectado para passar `project_id` (Full mode)
+- [ ] AskUserQuestion para engagement model (se ausente) E reviewer (se ausente — anti auto-PRR)
+- [ ] `prr-conductor` invocado via `Task(subagent_type=...)` com prompt completo (6 axes literalmente + modo offline)
+- [ ] Output forwarded transparentemente do agent
+- [ ] Próximos passos sugerem cross-ref para `/observabilidade omm`, `/concluir-marco`, P0/P1/P2 priorização
+</success_criteria>

package/kit/commands/risk-budget.md

@@ -0,0 +1,220 @@
+---
+name: risk-budget
+description: Exibe error budget atual vs risk continuum (cap 3 SRE) — lê .planning/slos/, posiciona no continuum 99% → 99.999%, aplica sabedoria 99.99% e "as reliable as needs to be".
+argument-hint: "[<slo_name>] [--format table|json]"
+allowed-tools:
+  - Read
+  - Bash
+  - Grep
+  - Glob
+---
+
+<objective>
+Snapshot read-only de **error budget vs risk continuum** (cap 3 do livro Google SRE) para 1 SLO ou todos. Aplica skill [`sre-risk-management`](../skills/sre-risk-management/SKILL.md) — risk continuum como decisão explícita, error budget como balanço risk × innovation, sabedoria 99.99% (user em smartphone 99% NÃO distingue 99.99% vs 99.999%), "as reliable as needs to be, no more".
+
+Lê SLOs definidos em [`event-based-slos`](../skills/event-based-slos/SKILL.md) (v1.9) — `.planning/slos/*.md`. Complementa [`burn-rate-status`](./burn-rate-status.md) (v1.9 — burn rate forecast) com **decisão estratégica** sobre target apropriado.
+
+**Cria/Atualiza:** nada — comando read-only.
+
+**Após:** o user vê posição de cada SLO no continuum, % budget gasto, custo relativo (1× → 100×+), e recomendação de tier (free/paid/enterprise) consistente com user-perception.
+</objective>
+
+<context>
+**Argumentos:** `$ARGUMENTS` — opcional `<slo_name>` para 1 SLO; sem args = todos os SLOs.
+
+**Flags:**
+- `--format <table|json>` — output format (default: `table`)
+- `--explain` — incluir bloco "sabedoria 99.99%" + anti-patterns inline (verbose)
+
+**Pré-requisito:** SLOs definidos em `.planning/slos/*.md` (v1.9 — comando `/observabilidade slo` ou `/definir-slo`).
+
+**Risk continuum canônico** (cap 3, aplicado inline pela skill):
+
+| Target | Tolerância 30d | User-perceptible? | Recomendação | Custo relativo |
+|---|---|---|---|---|
+| 99% | 7.2 h | Sim | Tier free, beta, internal | 1× |
+| 99.5% | 3.6 h | Notável | Tier free de produção | 2× |
+| 99.9% | 43.2 min | Aceitável para UX | Tier paid default | 5× |
+| 99.95% | 21.6 min | Quase imperceptível | Tier enterprise / mission-critical | 10× |
+| 99.99% | 4.3 min | Imperceptível em smartphone | Apenas se justificado (raro) | 50×+ |
+| 99.999% | 26 s | NÃO perceptível | NUNCA para user-facing | 100×+ |
+
+**Loop pattern:** rodar via skill `loop` para monitoramento contínuo.
+
+```text
+/loop 1h /risk-budget
+```
+
+**Exemplos:**
+```
+/risk-budget                              # todos SLOs, formato table
+/risk-budget checkout_success             # 1 SLO específico
+/risk-budget --format json                # output estruturado
+/risk-budget login_success --explain      # com sabedoria 99.99% + anti-patterns inline
+```
+</context>
+
+<process>
+
+## 1. Parsear argumentos
+
+```bash
+SLO_NAME=$(echo "$ARGUMENTS" | awk '{print $1}' | grep -v '^--' || true)
+FORMAT=$(echo "$ARGUMENTS" | grep -oE -- '--format [^ ]+' | awk '{print $2}')
+EXPLAIN=$(echo "$ARGUMENTS" | grep -c -- '--explain' || echo 0)
+
+[ -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 em .planning/slos/."
+  echo "Defina um com: /observabilidade slo <feature>  (v1.9)"
+  exit 0
+fi
+```
+
+## 3. Para cada SLO, extrair metadados + computar posição no continuum
+
+Para cada `SLO_FILE`:
+
+```bash
+SLO_NAME=$(basename "$SLO_FILE" .md)
+TARGET=$(grep -m1 -oE 'target.*[0-9.]+' "$SLO_FILE" | grep -oE '[0-9.]+')
+WINDOW=$(grep -m1 -oE 'window.*[0-9]+[dh]' "$SLO_FILE" | grep -oE '[0-9]+[dh]' || echo "30d")
+TIER_LABEL=$(grep -m1 'tier:' "$SLO_FILE" | sed 's/.*tier: //' || echo "(unset)")
+OWNER=$(grep -m1 'owner:' "$SLO_FILE" | sed 's/.*owner: //' || echo "(unset)")
+```
+
+**Mapear target → posição no risk continuum** (skill `sre-risk-management` Pattern 1):
+
+| Target faixa | Posição | Custo relativo | Tier típico | User-perceptible |
+|---|---|---|---|---|
+| < 0.99 | abaixo do continuum (under-spec) | <1× | beta/dev | sim |
+| 0.99 ≤ t < 0.995 | 99% | 1× | free, beta, internal | sim (notável) |
+| 0.995 ≤ t < 0.999 | 99.5% | 2× | free de produção | notável em paths críticos |
+| 0.999 ≤ t < 0.9995 | 99.9% | 5× | paid default | aceitável para UX |
+| 0.9995 ≤ t < 0.9999 | 99.95% | 10× | enterprise/mission-critical | quase imperceptível |
+| 0.9999 ≤ t < 0.99999 | 99.99% | 50×+ | só com checklist 4-perguntas | imperceptível em smartphone |
+| t ≥ 0.99999 | 99.999% | 100×+ | NUNCA para user-facing | NÃO perceptível |
+
+**Computar budget gasto** (heurística — leitura grosseira do SLO file):
+
+```bash
+# PT-BR: SLO file pode ter linha "**Budget consumido (snapshot):** XX%" atualizada por job
+BUDGET_USED_PCT=$(grep -m1 -oE 'Budget consumido.*[0-9]+%' "$SLO_FILE" | grep -oE '[0-9]+%' || echo "?")
+
+# PT-BR: se não, sugerir invocar /burn-rate-status (que tem queries live)
+if [ "$BUDGET_USED_PCT" = "?" ]; then
+  BUDGET_USED_PCT="(invoque /burn-rate-status para snapshot live)"
+fi
+```
+
+**Status no continuum** (4 níveis enum — interpretação canônica):
+
+- `OPTIMAL` — target apropriado para tier; budget < 50% gasto → "as reliable as needs to be"
+- `OVER-SPEC` — target acima do necessário (ex: tier free com 99.99%) → desperdício; baixar target
+- `UNDER-SPEC` — target abaixo do esperado (ex: enterprise com 99% só) → SLA risk; subir target
+- `BUDGET-EXHAUSTED` — budget < 10% restante → freeze releases; revisitar postmortems
+
+## 4. Agregar resultados em tabela
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► RISK-BUDGET ▸ {timestamp}
+═══════════════════════════════════════════════════════════
+
+| SLO | Target | Posição | Tier | Custo relativo | Budget gasto | Status | Decisão |
+|---|---|---|---|---|---|---|---|
+| checkout_success | 99.9% | 99.9% (5×) | paid | 5× | 23% | OPTIMAL | manter |
+| login_success | 99.99% | 99.99% (50×+) | enterprise | 50×+ | 78% | BUDGET-EXHAUSTED | freeze releases; checklist 4-perguntas? |
+| search_latency | 99% | 99% (1×) | free | 1× | 15% | OPTIMAL | manter (tier free OK) |
+| admin_panel | 99.95% | 99.95% (10×) | (?internal) | 10× | 5% | OVER-SPEC | baixar para 99% (internal tool, custo desperdício) |
+```
+
+Output JSON (`--format json`) — mesmo conteúdo serializado:
+
+```json
+{
+  "timestamp": "2026-05-07T...",
+  "slos": [
+    {
+      "name": "checkout_success",
+      "target": 0.999,
+      "position": "99.9%",
+      "cost_multiplier": "5×",
+      "tier": "paid",
+      "budget_used_pct": 23,
+      "status": "OPTIMAL",
+      "decision": "manter"
+    }
+  ]
+}
+```
+
+## 5. Modo `--explain` — sabedoria 99.99% + anti-patterns inline
+
+Se `--explain` setado, anexar após tabela:
+
+```markdown
+## Sabedoria 99.99% (cap 3)
+
+> Smartphone tem ~99% de disponibilidade (sinal cai, bateria acaba, app trava).
+> Usuário em 99% smartphone NÃO distingue serviço 99.99% vs 99.999% — ambos
+> parecem "sempre funcionando" no contexto dele. Cada nove adicional **multiplica
+> custo** mas **divide benefício marginal**. Cliente final (humano em smartphone
+> com ISP residencial ~99%) tem disponibilidade no canal de comunicação inferior
+> à do seu serviço 99.99%. Essa é a sabedoria 99.99%.
+
+## Anti-patterns detectados
+
+{Para cada SLO em status OVER-SPEC, BUDGET-EXHAUSTED:}
+- **{slo_name}** ({status}): {explicação curta}
+  - {ação recomendada}
+
+Exemplos:
+- **admin_panel** (OVER-SPEC): tier internal com 99.95% (10× custo). Internal tool não exige tier paid.
+  - Ação: editar `.planning/slos/admin_panel.md` → target: 0.99 (1×); ou remover SLO formal (apenas métrica informativa).
+- **login_success** (BUDGET-EXHAUSTED 78%): 99.99% sem checklist 4-perguntas justificada?
+  - Ação: revisar Pattern "justificar 99.99%+ excepcional" (skill sre-risk-management); se NÃO atende 4 critérios, baixar para 99.95%.
+```
+
+## 6. Sugerir próximas ações
+
+Se algum SLO em status `BUDGET-EXHAUSTED` ou `OVER-SPEC`:
+
+```
+## ⚠ Decisões pendentes
+
+{Para cada SLO em alerta:}
+- {slo_name} ({status}): {recomendação curta}
+  → /investigar-producao "{slo_name} budget exhausted às {timestamp}"   # se BUDGET-EXHAUSTED
+  → editar `.planning/slos/{slo_name}.md` target: {sugestão}            # se OVER-SPEC
+
+## Cross-refs
+- `/burn-rate-status {slo_name}` — burn rate live (forecast ETA)
+- `/postmortem --incident "..."` — se budget exhausted virou incident
+- `/observabilidade omm` — Capacidade 1 (Embracing Risk) consome este snapshot
+```
+
+</process>
+
+<success_criteria>
+- [ ] `<slo_name>` opcional + flags `--format` e `--explain` parseadas
+- [ ] SLOs listados via glob `.planning/slos/*.md`
+- [ ] Cada SLO mapeado para posição no risk continuum (1× a 100×+)
+- [ ] 4 status enum: OPTIMAL / OVER-SPEC / UNDER-SPEC / BUDGET-EXHAUSTED
+- [ ] Tabela agregada com 8 colunas (SLO, Target, Posição, Tier, Custo relativo, Budget gasto, Status, Decisão)
+- [ ] Modo `--explain` anexa sabedoria 99.99% + anti-patterns detectados inline
+- [ ] Cross-refs para `/burn-rate-status`, `/postmortem`, `/observabilidade omm` (Capacidade 1 Embracing Risk)
+- [ ] Idempotente — rodável em `/loop` sem state acumulado
+- [ ] Read-only — comando NÃO modifica arquivos
+</success_criteria>

package/kit/commands/sre.md

@@ -0,0 +1,227 @@
+---
+name: sre
+description: Orquestrador da Suíte SRE (v1.10) — dispatch para agents (golden-signals-instrumenter, toil-auditor, postmortem-writer, prr-conductor) com sinônimos PT/EN.
+argument-hint: "<subcomando> [args...]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+  - Task
+  - AskUserQuestion
+---
+
+<objective>
+Orquestrador único da Suíte SRE (v1.10) — terceiro orquestrador da família após [`/supabase`](./supabase.md) (v1.8) e [`/observabilidade`](./observabilidade.md) (v1.9). Recebe subcomando + args, faz dispatch via `Task(subagent_type=...)` para o agent SRE correto. **Único ponto de chain de agents SRE** (anti-pitfall A10 mantido — agents permanecem função pura).
+
+**Subcomandos cobrem cap 3, 5, 6, 15, 32 do livro Google SRE:**
+- `golden-signals` — 4 signals universais (cap 6)
+- `auditar-toil`/`audit-toil` — eliminating toil (cap 5)
+- `postmortem` — blameless postmortem (cap 15)
+- `prr` — Production Readiness Review (cap 32)
+- `risk-budget`/`budget` — risk continuum (cap 3)
+
+**Cria/Atualiza:** o que cada agent invocado cria (patches OTel, TOIL-AUDIT.md, postmortem, PRR-REPORT.md, snapshot risk-budget).
+
+**Após:** o usuário tem o output do agent (instrumentação aplicada, audit, postmortem revisável, PRR scored, ou snapshot de budget).
+</objective>
+
+<execution_context>
+Skills consultadas pelos agents (Phase 36): [`kit/skills/sre-risk-management/SKILL.md`](../skills/sre-risk-management/SKILL.md), [`kit/skills/four-golden-signals/SKILL.md`](../skills/four-golden-signals/SKILL.md), [`kit/skills/eliminating-toil/SKILL.md`](../skills/eliminating-toil/SKILL.md), [`kit/skills/blameless-postmortems/SKILL.md`](../skills/blameless-postmortems/SKILL.md), [`kit/skills/production-readiness-review/SKILL.md`](../skills/production-readiness-review/SKILL.md) + glossário em [`kit/skills/_shared-sre/glossary.md`](../skills/_shared-sre/glossary.md).
+
+Agents disponíveis (Phase 37):
+- [`golden-signals-instrumenter`](../agents/golden-signals-instrumenter.md) — AGCORE-SRE-01
+- [`toil-auditor`](../agents/toil-auditor.md) — AGCORE-SRE-02
+- [`postmortem-writer`](../agents/postmortem-writer.md) — AGCORE-SRE-03
+- [`prr-conductor`](../agents/prr-conductor.md) — AGCORE-SRE-04
+
+**Subcomando `risk-budget`** é caso especial — comando direto (Plan 05 não usa agent); orquestrador delega aplicando skill [`sre-risk-management`](../skills/sre-risk-management/SKILL.md) inline ou re-encaminhando para `/risk-budget`.
+</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 | Cap livro |
+|---|---|---|---|
+| `golden-signals` | `signals`, `4signals`, `golden` | `golden-signals-instrumenter` | 6 |
+| `auditar-toil` | `audit-toil`, `toil`, `auditar` | `toil-auditor` | 5 |
+| `postmortem` | `pm`, `post-mortem` | `postmortem-writer` | 15 |
+| `prr` | `production-readiness`, `readiness-review` | `prr-conductor` | 32 |
+| `risk-budget` | `budget`, `risk`, `continuum` | (comando direto — `/risk-budget`) | 3 |
+| `help` | `ajuda`, `?` | exibe esta tabela inline | — |
+
+**Roteamento de flags por subcomando:**
+
+- `golden-signals <target>` — args passados como `<target>` + flags `--service` `--saturation` `--runtime`
+- `auditar-toil` — flags `--time-window` `--team-size` `--output` `--runbooks-paths`
+- `postmortem` — flags **mutuamente exclusivas** `--from-investigation <id>` OU `--incident "<desc>"` + `--severity`
+- `prr` — flags **mutuamente exclusivas** `--service <name>` OU `--feature "<desc>"` + `--engagement` `--reviewer`
+- `risk-budget` — `[<slo_name>]` opcional + `--format` `--explain`
+
+**Exemplos:**
+
+```
+/sre golden-signals supabase/functions/process-emails    # instrumentar Edge Function
+/sre auditar-toil --time-window 6m                       # audit toil últimos 6 meses
+/sre postmortem --from-investigation incident-2026-05-06-1432-checkout-burn  # continuação de v1.9
+/sre prr --service orders-api --reviewer @sre-lead       # PRR de serviço existente
+/sre risk-budget checkout_success --explain              # budget + sabedoria 99.99% inline
+/sre help                                                # exibe tabela de subcomandos
+```
+</context>
+
+<process>
+
+## 1. Parsear subcomando
+
+```bash
+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 para agent canônico
+
+```text
+golden-signals, signals, 4signals, golden          → golden-signals-instrumenter
+auditar-toil, audit-toil, toil, auditar            → toil-auditor
+postmortem, pm, post-mortem                        → postmortem-writer
+prr, production-readiness, readiness-review        → prr-conductor
+risk-budget, budget, risk, continuum               → (comando direto — /risk-budget)
+```
+
+**Se subcomando não resolve:** exibir erro inline com lista de subcomandos válidos. Sair.
+
+```
+✗ Subcomando desconhecido: '<SUBCMD>'
+
+Subcomandos válidos:
+  golden-signals    → instrumentar 4 signals OTel (Latency/Traffic/Errors/Saturation)
+  auditar-toil      → audit toil priorizado P0/P1/P2 + esforço de automação
+  postmortem        → postmortem blameless 9 seções (--from-investigation OU --incident)
+  prr               → Production Readiness Review 6 axes (--service OU --feature)
+  risk-budget       → error budget vs risk continuum + sabedoria 99.99%
+
+Uso: /sre <subcomando> <args...>
+Exemplo: /sre prr --service orders-api
+```
+
+## 3. Detectar `supabase/config.toml` (passar `project_id` para agents que usam MCP)
+
+```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
+```
+
+Apenas `prr-conductor` usa `mcp__supabase__*` — outros 3 agents não precisam de `project_id` (instrumentação/audit/postmortem são filesystem only).
+
+## 4. Dispatch — caminhos por subcomando
+
+### 4a. `golden-signals` → `golden-signals-instrumenter`
+
+```text
+Task(
+  subagent_type="golden-signals-instrumenter",
+  prompt="
+${ARGS}
+
+Aplicar skill four-golden-signals. Gerar patches OTel para os 4 signals (Latency: histogram bucketed; Traffic: counter; Errors: counter por error.type; Saturation: gauge resource-specific).
+"
+)
+```
+
+### 4b. `auditar-toil` → `toil-auditor`
+
+```text
+Task(
+  subagent_type="toil-auditor",
+  prompt="
+project_root: .
+output_path: .planning/TOIL-AUDIT.md
+${ARGS}
+
+Aplicar skill eliminating-toil. Scan git log + scripts + runbooks; aplicar 6 critérios canônicos; priorizar P0/P1/P2; estimar esforço de automação L0-L4.
+"
+)
+```
+
+### 4c. `postmortem` → `postmortem-writer`
+
+Validar mutuamente exclusivos (`--from-investigation` E `--incident` ambos = ERROR; nenhum = AskUserQuestion sugerido).
+
+```text
+Task(
+  subagent_type="postmortem-writer",
+  prompt="
+${ARGS}
+
+Aplicar skill blameless-postmortems. Modo conforme flag (--from-investigation lê investigation v1.9; --incident standalone com 9 perguntas guiadas). 9 seções obrigatórias: Summary, Impact, Root Causes, Trigger, Resolution, Detection, Action Items, Lessons Learned, Timeline UTC. Foco em sistema/processo (NUNCA pessoas).
+"
+)
+```
+
+### 4d. `prr` → `prr-conductor`
+
+Validar mutuamente exclusivos (`--service` E `--feature` ambos = ERROR; nenhum = ERROR com sugestão). Se `--reviewer` ausente: AskUserQuestion (anti-pattern auto-PRR).
+
+```text
+Task(
+  subagent_type="prr-conductor",
+  prompt="
+${ARGS}
+${PROJECT_ID:+project_id: ${PROJECT_ID}}
+
+Aplicar skill production-readiness-review. Audit em 6 axes (System Architecture, Instrumentation, Emergency Response, Capacity Planning, Change Management, Performance) — todos obrigatórios. Engagement model conforme outage cost. Modo offline fallback graceful.
+"
+)
+```
+
+### 4e. `risk-budget` → comando direto `/risk-budget`
+
+Caso especial — não há agent. Re-encaminhar via shell ou aplicar skill `sre-risk-management` direto.
+
+```bash
+# PT-BR: invocar comando /risk-budget passando args
+# Em Claude Code, isso é equivalente a executar o comando file diretamente
+# (orquestrador apenas valida sinônimo e delega)
+/risk-budget ${ARGS}
+```
+
+Alternativa inline (se não há shell call): orquestrador lê `.planning/slos/*.md`, mapeia para tabela continuum (skill `sre-risk-management` Pattern 1), exibe tabela com status (OPTIMAL/OVER-SPEC/UNDER-SPEC/BUDGET-EXHAUSTED).
+
+## 5. Output
+
+Output do agent (ou do comando direto risk-budget) é o output do orquestrador. Sem post-processing — agent já formata estruturado.
+
+## 6. Sugestões de chains comuns (pós-output)
+
+Após dispatch, orquestrador pode sugerir chains comuns:
+
+| Subcomando rodado | Chain natural |
+|---|---|
+| `golden-signals` | `/sre prr --service <same>` (validar production-readiness) |
+| `auditar-toil` | `/observabilidade omm` (alimentar OMM Capacidade 3) |
+| `postmortem` | `/sre prr --service <affected>` OR `/observabilidade omm` (Capacidade 5 Incident Response) |
+| `prr` | (se Approved) deploy; (se Blocked) fechar P0s e re-PRR |
+| `risk-budget` | `/burn-rate-status` (live forecast) OR `/sre postmortem --incident "..."` se BUDGET-EXHAUSTED |
+
+</process>
+
+<success_criteria>
+- [ ] Subcomando resolvido para agent canônico (5 subcomandos × seus sinônimos)
+- [ ] `project_id` extraído de `supabase/config.toml` se presente (apenas relevante para `prr`)
+- [ ] Dispatch via `Task(subagent_type=...)` — único ponto de chain (anti-pitfall A10)
+- [ ] Subcomando `risk-budget` delega para comando direto `/risk-budget` (não usa Task)
+- [ ] Subcomando `postmortem` valida `--from-investigation` E `--incident` mutuamente exclusivos antes de dispatch
+- [ ] Subcomando `prr` valida `--service` E `--feature` mutuamente exclusivos + AskUserQuestion para reviewer (anti auto-PRR)
+- [ ] Subcomando inválido → mensagem clara com lista de 5 subcomandos válidos
+- [ ] Subcomando `help`/`ajuda`/`?` → exibe tabela inline com 6 linhas (5 + help)
+- [ ] Args após subcomando passam transparentemente para o agent
+- [ ] Sugestões de chains comuns na tabela final (5 chains documentadas)
+</success_criteria>