@luanpdd/kit-mcp 1.9.0 → 1.11.0

package/kit/commands/refactor-seguro.md

@@ -0,0 +1,321 @@
+---
+name: refactor-seguro
+description: Orquestrador de refactor seguro — chain canônico encontrar-seams → caracterizar → auditar-refactor → executar. Suporta modos --mode=full|sprout|safe-extract|override. Substitui edit-and-pray por cover-and-modify.
+argument-hint: "<target_file> [--mode full|sprout|safe-extract|override] [--ticket REQ-N] [--reason \"...\"] [--skip-seams] [--skip-characterize]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+  - Task
+  - AskUserQuestion
+---
+
+<objective>
+Orquestrar fluxo canônico de refactor seguro em código legado: (1) identificar seams + quebrar deps; (2) caracterizar comportamento; (3) auditar safety net; (4) executar refactor com cover-and-modify. Substitui o pattern edit-and-pray (cap 1 Feathers) por cover-and-modify, baseado em characterization tests como oracle.
+
+**Chain padrão (`--mode=full`):**
+
+```
+seam-finder → legacy-characterizer → refactor-safety-auditor → executor
+   (se necessário)    (sempre)              (gate)               (refactor real)
+```
+
+**Modos alternativos** (atalhos quando mudança não justifica chain completo):
+- `--mode=sprout` — usa `legacy-sprout-wrap-techniques`; legado intocado, comportamento adicionado em sprout testado isoladamente
+- `--mode=safe-extract` — refactor mecânico (rename, IDE-extract bloco contíguo); checklist signed-off + sem characterization
+- `--mode=override` — bypass com audit trail (--ticket + --reason obrigatórios)
+
+**Cria/Atualiza:**
+- Em modo full: `.planning/SEAM-ANALYSIS.md`, `tests/characterization/<file_stem>/`, `.planning/REFACTOR-SAFETY.md`
+- Em modo sprout: novo módulo + tests
+- Em modo safe-extract: refactor commit + checklist em `.planning/SAFE-EXTRACT-<file>.md`
+- Em modo override: `.planning/REFACTOR-SAFETY.md` com audit trail
+
+**Após:** o user terminou refactor com confiança proporcional ao nível de safety net adotado.
+</objective>
+
+<context>
+**Argumentos:**
+- `<target_file>` — caminho do arquivo a refatorar — OBRIGATÓRIO
+- `--mode <full|sprout|safe-extract|override>` — modo do orquestrador (default: `full`)
+- `--ticket REQ-N` — ticket linkado (obrigatório com `--mode=override`)
+- `--reason "<texto>"` — justificativa (obrigatória com `--mode=override`)
+- `--skip-seams` — pular seam-finder (assume deps já controláveis)
+- `--skip-characterize` — pular caracterizar (assume safety net já existe)
+- `--symbol <name>` — escopo limitado a símbolo específico
+- `--feature-description "<texto>"` — em mode=sprout, descreve feature a adicionar
+
+**Modos detalhados:**
+
+```
+--mode=full (default)
+=====================
+1. /encontrar-seams <file>            (se necessário, deps externas presentes)
+2. Aplicar técnicas de break-deps     (commits 1-N, manual ou via executor)
+3. /caracterizar <file>                (gera safety net)
+4. /auditar-refactor <file>           (gate retorna GO)
+5. Refactor real                      (cover-and-modify, suite verde a cada commit)
+6. Re-rodar suite final                (regressão = 0)
+
+--mode=sprout
+=============
+1. AskUserQuestion para feature description
+2. Aplicar legacy-sprout-wrap-techniques
+3. Gerar sprout method/class testável
+4. Conectar ao legado em 1-2 linhas
+5. Tests do sprout (100% cobertura no novo)
+6. PR criado com TODO de débito técnico (legado ainda untested)
+
+--mode=safe-extract
+====================
+1. Validar checklist canônico:
+   - Bloco a extrair é CONTÍGUO?
+   - Sem control flow saindo do meio (return/throw/break)?
+   - Variáveis lidas/escritas mapeadas?
+   - Sem mover lógica entre escopos?
+2. Aplicar refactor IDE-assisted
+3. Compilação verde + smoke run
+4. PR com SAFE-EXTRACT-<file>.md como artefato
+
+--mode=override
+================
+1. Validar --ticket E --reason
+2. Auditoria do refactor-safety-auditor com flag override
+3. Audit trail registrado em REFACTOR-SAFETY.md
+4. Refactor pode prosseguir SEM characterization
+5. Débito técnico documentado no ticket
+```
+
+**Exemplos:**
+```
+/refactor-seguro src/orders/handler.ts                                # full chain (recomendado)
+/refactor-seguro src/orders/handler.ts --mode=sprout                  # adicionar feature sem tocar legado
+/refactor-seguro src/orders/handler.ts --mode=safe-extract            # rename/extract mecânico
+/refactor-seguro src/orders/handler.ts --mode=override \
+  --ticket REQ-2026-Q2-1234 --reason "hot fix SEV1, char em REQ-...1235"
+/refactor-seguro src/orders/handler.ts --skip-seams                   # deps já testáveis
+/refactor-seguro src/orders/handler.ts --symbol processOrder          # método específico
+```
+
+**Quando este comando é o caminho certo:**
+- Você vai modificar arquivo > 200 linhas com cobertura < 60%
+- Webhook/API/Edge Function precisa refactor (contrato externo)
+- Equipe quer disciplina cover-and-modify em vez de edit-and-pray
+- `/discutir-fase` ou `/planejar-fase` detectaram refactor intent
+
+**Quando NÃO é o caminho:**
+- Bug fix → use TDD direto (escrever test do comportamento correto, depois fix)
+- Feature nova em código novo → use `/discutir-fase` + `/planejar-fase` normais
+- Arquivo trivial → refactor inline sem ceremonial
+</context>
+
+<process>
+
+## 1. Parsear argumentos + validações
+
+```bash
+TARGET_FILE=$(echo "$ARGUMENTS" | awk '{print $1}')
+MODE=$(echo "$ARGUMENTS" | grep -oE -- '--mode[= ][^ ]+' | sed 's/--mode[= ]//')
+TICKET=$(echo "$ARGUMENTS" | grep -oE -- '--ticket [^ ]+' | awk '{print $2}')
+REASON=$(echo "$ARGUMENTS" | grep -oE -- '--reason "[^"]+"' | sed 's/--reason "\(.*\)"/\1/')
+SYMBOL=$(echo "$ARGUMENTS" | grep -oE -- '--symbol [^ ]+' | awk '{print $2}')
+FEATURE_DESC=$(echo "$ARGUMENTS" | grep -oE -- '--feature-description "[^"]+"' | sed 's/--feature-description "\(.*\)"/\1/')
+SKIP_SEAMS=false
+SKIP_CHAR=false
+
+echo "$ARGUMENTS" | grep -qE -- '--skip-seams'        && SKIP_SEAMS=true
+echo "$ARGUMENTS" | grep -qE -- '--skip-characterize' && SKIP_CHAR=true
+
+[ -z "$MODE" ] && MODE="full"
+
+if [ -z "$TARGET_FILE" ]; then
+  echo "ERROR: target_file é obrigatório."
+  echo "Uso: /refactor-seguro <target_file> [opções]"
+  exit 1
+fi
+
+if [ ! -f "$TARGET_FILE" ]; then
+  echo "ERROR: arquivo não encontrado: $TARGET_FILE"
+  exit 1
+fi
+
+# PT-BR: validações por mode
+case "$MODE" in
+  full|sprout|safe-extract|override) ;;
+  *)
+    echo "ERROR: --mode inválido: $MODE"
+    echo "Valores válidos: full, sprout, safe-extract, override"
+    exit 1
+    ;;
+esac
+
+if [ "$MODE" = "override" ]; then
+  if [ -z "$TICKET" ] || [ -z "$REASON" ]; then
+    echo "ERROR: --mode=override requer --ticket REQ-N E --reason \"<texto>\"."
+    exit 1
+  fi
+fi
+```
+
+## 2. Roteamento por mode
+
+### Mode=full (default chain)
+
+```text
+Step 1 — Seam analysis (skip se --skip-seams)
+  /encontrar-seams ${TARGET_FILE} ${SYMBOL:+--symbol $SYMBOL}
+  → produz .planning/SEAM-ANALYSIS.md
+  → user aplica técnicas (commits 1-N)
+
+Step 2 — Verificar suite verde após break-deps
+  Run test suite, abort se vermelho
+
+Step 3 — Characterization (skip se --skip-characterize)
+  /caracterizar ${TARGET_FILE} ${SYMBOL:+--symbol $SYMBOL}
+  → produz tests/characterization/<file_stem>/
+  → user revisa snapshots manualmente
+  → user commita como `chore: characterize <file_stem>`
+
+Step 4 — Audit do safety net
+  /auditar-refactor ${TARGET_FILE} --change-kind=refactor
+  → produz .planning/REFACTOR-SAFETY.md com veredito GO/WARN/BLOCK
+  → SE BLOCK ainda → loop de volta para step 3 (com --gap-fill)
+  → SE GO → prossegue
+
+Step 5 — Refactor real
+  Delegar para executor OR prompt user para refactor manual
+  Após cada commit: rodar suite (verde)
+  Após cada commit: characterization tests (verdes — comportamento preservado)
+
+Step 6 — Verificação final
+  Suite verde
+  Characterization VERDE (regressão = 0)
+  Mutation kill ≥ 70% (validar safety net)
+  PR pode ser aberto
+```
+
+### Mode=sprout
+
+```text
+Step 1 — Coletar feature description
+  Se $FEATURE_DESC vazio → AskUserQuestion:
+    "Descreva a feature a ser adicionada (será encapsulada em sprout):"
+
+Step 2 — Aplicar legacy-sprout-wrap-techniques
+  Decision: sprout method vs sprout class vs wrap method vs wrap class
+    - feature ≤ 30 linhas, 1 responsabilidade → sprout method
+    - feature > 30 linhas OR multi-responsibility → sprout class
+    - feature transforma input/output do legado inteiro → wrap method
+    - feature atravessa N métodos da classe → wrap class
+
+Step 3 — Gerar sprout
+  Criar arquivo novo (sprout module) com lógica testável
+  DI explícita para qualquer dep
+
+Step 4 — Conectar ao legado em 1-2 linhas
+  Inserir chamada ao sprout no legado
+  Comment canônico: [legacy-debt #issue-N] sprout — <descrição>
+
+Step 5 — Tests do sprout (100% cobertura)
+  Escrever 5+ tests cobrindo grupos de equivalência
+  Mutation testing no sprout (não no legado)
+
+Step 6 — PR
+  Diff esperado: arquivo novo + 1-2 linhas no legado
+  README/CHANGELOG atualizado se aplicável
+  Ticket de débito técnico criado se ainda não existia
+```
+
+### Mode=safe-extract
+
+```text
+Step 1 — Validar checklist canônico
+  AskUserQuestion ou inline-confirm:
+    □ Bloco a extrair é CONTÍGUO?           (não pode ter return/throw/break/continue saindo)
+    □ Variáveis lidas dentro mas declaradas fora → parâmetros (in)?
+    □ Variáveis escritas dentro mas usadas fora → return values (out)?
+    □ NÃO move lógica entre escopos? (sem move method)
+    □ NÃO muda control flow? (sem inverter ifs, sem early return novo)
+    □ NÃO modifica sintaxe além de extract/rename?
+  Qualquer NÃO → veto, voltar para mode=full
+
+Step 2 — Identificar refactor IDE-assisted
+  Se Cursor/VS Code/IntelliJ disponível → usar Refactor → Extract Function/Method/Variable
+  Caso contrário → manual mas mecânico
+
+Step 3 — Aplicar refactor (commits single-goal)
+  Após cada commit: compilação verde
+  Após cada commit: smoke run (qualquer comando que rodava antes)
+
+Step 4 — Output checklist signed-off
+  Escrever .planning/SAFE-EXTRACT-<file_stem>.md com:
+    - Checklist canônico (todos os itens marcados)
+    - Lista de commits (cada um single-goal)
+    - Validação de comportamento (smoke verde)
+```
+
+### Mode=override
+
+```text
+Step 1 — Validar --ticket E --reason (já feito acima)
+
+Step 2 — Auditar com flag override
+  /auditar-refactor ${TARGET_FILE} \
+    --change-kind=override \
+    --ticket ${TICKET} \
+    --reason "${REASON}"
+  → audit trail registrado em REFACTOR-SAFETY.md
+
+Step 3 — Refactor pode prosseguir
+  Output:
+    ⚠ MODE=OVERRIDE — refactor sem characterization
+    Ticket: ${TICKET}
+    Reason: ${REASON}
+    Audit trail: .planning/REFACTOR-SAFETY.md
+    
+    Você aceitou o débito técnico. Refactor pode iniciar AGORA.
+    Lembre-se: regressão silenciosa em prod é responsabilidade do owner do ticket.
+```
+
+## 3. Output canônico
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► REFACTOR-SEGURO ▸ ${TARGET_FILE} (mode: ${MODE})
+═══════════════════════════════════════════════════════════
+
+[output específico do mode escolhido]
+
+## Sumário do que foi feito
+
+| Step | Ação | Output |
+|---|---|---|
+| 1 | Seam analysis | .planning/SEAM-ANALYSIS.md |
+| 2 | Characterization | tests/characterization/<file_stem>/ |
+| 3 | Safety audit | .planning/REFACTOR-SAFETY.md (veredito: GO) |
+| 4 | Refactor | <commits sequenciais> |
+| 5 | Verificação final | suite verde, mutation kill ≥ 70% |
+
+## Cross-suite
+
+- **/instrumentar-fase** (v1.9) — adicionar instrumentação para detectar regressão precoce em prod via golden signals
+- **/burn-rate-status** (v1.9) — monitor SLO budget pós-deploy do refactor
+- **/prr** (v1.10) — PRR Axe 5 (Change Management) — invoque após refactor para validar production-readiness
+- **/postmortem** (v1.10) — pronto para usar se algo regredir em prod (audit trail completo via REFACTOR-SAFETY.md)
+- **/concluir-marco** — gate `legacy-refactor-safety` (opt-in) bloqueia close se há refactors com mode=override sem ticket close
+```
+
+</process>
+
+<success_criteria>
+- [ ] $ARGUMENTS parseados (target_file obrigatório, --mode opcional com 4 valores)
+- [ ] Validações por mode aplicadas (override → ticket + reason; safe-extract → checklist)
+- [ ] Mode=full executa chain canônico (seam-finder → characterizer → safety-auditor → refactor)
+- [ ] Mode=sprout aplica legacy-sprout-wrap-techniques + AskUserQuestion para feature
+- [ ] Mode=safe-extract valida checklist + commits single-goal
+- [ ] Mode=override registra audit trail completo via refactor-safety-auditor
+- [ ] Steps 1-5 e cross-suite documentados no output
+- [ ] Each sub-comando invocado via syntax canônica (`/encontrar-seams`, `/caracterizar`, `/auditar-refactor`)
+</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>