@luanpdd/kit-mcp 1.8.1 → 1.10.0

package/kit/skills/blameless-postmortems/SKILL.md

@@ -0,0 +1,340 @@
+---
+name: blameless-postmortems
+description: Use após incident SEV1/SEV2 — template canônico (9 seções), cultura blameless (foco em sistema, não pessoas), no postmortem left unreviewed, Wheel of Misfortune.
+---
+
+# SRE — Blameless Postmortems
+
+## Quando usar
+
+LLM carrega esta skill ao escrever postmortem após incident, revisar postmortem de par, ou conduzir Wheel of Misfortune. Trigger phrases:
+
+- "postmortem", "post-mortem"
+- "incident review"
+- "blameless", "sem culpa"
+- "root cause analysis", "5 whys"
+- "Wheel of Misfortune"
+- "lessons learned"
+- "Google SRE cap 15"
+- "no postmortem left unreviewed"
+
+## Regras absolutas
+
+- **Foco em sistema/processo, NÃO em pessoas** — root cause é "ausência de canary release" ou "RPS limit não documentado", NÃO "Maria fez deploy errado". Pessoas são parte do sistema. Se Maria errou, pergunte: "que processo permitiu o erro chegar a prod?".
+- **Trigger postmortem para SEV1/SEV2 + near-miss notáveis** — todo incident customer-facing com impacto ≥ 1 min de SLO burn ou ≥ 1 user reportado. Near-miss (incident detectado antes de impacto) também: oportunidade de aprender sem custo.
+- **"No postmortem left unreviewed"** — todo postmortem revisado por par sênior antes de arquivar. Sem revisão, postmortem mente (involuntariamente — autor está perto demais).
+- **Action items SMART com owner nomeado** — Specific, Measurable, Assignable, Realistic, Time-bound. "Melhorar monitoring" NÃO é SMART. "Adicionar alert SLO burn rate em /api/v1/orders por @bob até 2026-05-15" É SMART.
+- **Timeline em UTC** — não "horário local Brasília" ou ambíguo. Times distribuídos compõem timeline e UTC é o único timezone universal. Sempre `HH:MM UTC`.
+- **Quantificar impact** — usuários afetados (número/percentual), revenue impact, SLO budget consumido. Sem quantificação, severity é subjetivo.
+- **Lições generalizáveis, não específicas** — "Adicionar alert para essa query específica" é local. "Adicionar alert SLO em todas as queries de write em paths críticos" é generalizável.
+- **Wheel of Misfortune trimestral** — exercício de role-play onde uma pessoa narra um incident histórico e o time pratica response (sem dados reais expostos a stress real). Treina muscle memory para SEV1.
+
+## Patterns canônicos
+
+### Pattern: template canônico de postmortem (9 seções)
+
+````markdown
+```markdown
+# Postmortem: <incident-id> — <título-curto>
+
+**Data do incident:** YYYY-MM-DD
+**Autores:** <nomes>
+**Status:** Draft | Reviewed | Final
+**Severidade:** SEV1 | SEV2 | SEV3
+**Tempo até detecção:** XX min (entre trigger e alerta)
+**Tempo até resolução:** XX min (entre alerta e SLO restored)
+
+## Summary
+
+1-2 parágrafos: o que aconteceu, quem foi afetado, como foi resolvido.
+Escrito para audiência não-técnica (executivos, customer success, support).
+
+## Impact
+
+- Usuários afetados: XX% (X de Y usuários ativos no período)
+- Duração: HH:MM (de HH:MM UTC a HH:MM UTC)
+- SLO budget consumido: X% do budget mensal
+- Revenue impact: $X (estimado por # de transações falhadas × ticket médio)
+- Serviços downstream impactados: <lista>
+- Customer support tickets gerados: X
+- Reputação/marca: <impacto qualitativo, se houver>
+
+## Root Causes
+
+Condição mais profunda que, removida, previne recorrência.
+NÃO é "deploy do fulano" ou "código tinha bug" — é a condição sistêmica que
+permitiu o bug chegar a prod (ausência de canary, ausência de SLO alert,
+teste não cobria o caso).
+
+Use **5 Whys** para chegar lá. Pode haver múltiplas root causes (separadas
+em subseções `### Root Cause 1`, `### Root Cause 2`).
+
+## Trigger
+
+Evento que iniciou a falha (deploy X às HH:MM UTC, config change Y, traffic
+spike Z, dependency outage W). Trigger ≠ Root Cause — trigger é o "quando";
+root cause é o "porquê o trigger virou incident".
+
+## Resolution
+
+Passos tomados para recuperar serviço, em ordem cronológica com horários UTC:
+
+- HH:MM UTC — <ação>
+- HH:MM UTC — <ação>
+
+Inclui rollbacks, hotfixes, scaling decisions, manual interventions.
+
+## Detection
+
+Como descobrimos: alerta SLO burn rate? cliente reportou? monitoramento
+interno? heartbeat?
+
+Tempo de detecção (gap entre trigger e detecção). Se > 5 min, action item
+para reduzir.
+
+## Action Items
+
+| # | Action (SMART) | Owner | Priority | Due |
+|---|----------------|-------|----------|-----|
+| 1 | Adicionar SLO burn rate alert em /api/v1/orders/{id} | @bob | P0 | 2026-05-15 |
+| 2 | Documentar RPS limit por tier em runbook do orders-service | @alice | P1 | 2026-05-22 |
+| 3 | Implementar canary release em CI para todos os Edge Functions | @platform | P1 | 2026-06-01 |
+
+## Lessons Learned
+
+Insights generalizáveis. Estrutura recomendada:
+
+### O que fizemos bem
+- <coisa que funcionou — reforçar>
+
+### Onde podemos melhorar
+- <gap identificado, generalizável a outros sistemas>
+
+### Foi lucky?
+- <foi sorte que detectamos rápido? que não escalou? — capturar para fix proativo>
+
+## Timeline (UTC)
+
+- 14:23 — <evento>
+- 14:27 — <evento>
+- 14:33 — <evento>
+- 14:42 — <evento>
+- 15:25 — Incident resolvido
+
+## Supporting evidence
+
+- Link para incident channel #inc-2026-05-06-01
+- Link para SLO dashboard
+- Link para investigation .planning/investigations/<id>.md (de incident-investigator v1.9)
+- Screenshots/queries de chave
+```
+````
+
+### Pattern: 5 whys para encontrar root cause
+
+```text
+Sintoma: SLO burn rate de checkout_success disparou às 14:31 UTC.
+
+Why 1: Por que o burn rate disparou?
+→ Porque taxa de erro em /api/v1/orders saltou de 0.05% para 8%.
+
+Why 2: Por que a taxa de erro saltou?
+→ Porque deploy v2.3.0 introduziu N+1 query.
+
+Why 3: Por que o deploy v2.3.0 chegou a prod com N+1?
+→ Porque o teste de carga não cobria carrinhos com > 10 itens.
+
+Why 4: Por que o teste de carga não cobria > 10 itens?
+→ Porque o teste foi escrito antes do feature de "bulk add to cart" e não foi atualizado.
+
+Why 5: Por que o teste não foi atualizado quando bulk add foi mergeado?
+→ Porque não há gate de CI que exige re-rodar load test ao mudar paths críticos.
+
+ROOT CAUSE: ausência de gate de CI obrigando re-rodar load test em mudanças de paths críticos.
+ACTION ITEM: implementar gate `load-test-required-for-critical-paths` no CI.
+```
+
+### Pattern: revisão por par sênior ("no postmortem left unreviewed")
+
+```markdown
+Reviewer pergunta autor:
+
+1. **Root cause é sistêmico, não pessoal?** — se cita pessoa, redirecionar para processo
+2. **Action items são SMART?** — owner nomeado, due date, mensurável
+3. **Timeline em UTC?** — sem ambiguidade timezone
+4. **Impact quantificado?** — # usuários, duração, revenue
+5. **Lessons generalizáveis?** — aplicáveis a outros serviços/incidents
+6. **Detection time razoável?** — < 5 min ideal; se > 5, action item para reduzir
+7. **Algo "lucky" capturado?** — foi sorte? Como remover dependência de sorte?
+8. **5 whys aplicado?** — ou parou em "deploy ruim" sem ir mais fundo?
+```
+
+### Pattern: Wheel of Misfortune (training canônico)
+
+```text
+Frequência: trimestral (1× por quarter)
+Duração: 60-90 min
+Participantes: time on-call + interessados (4-8 pessoas idealmente)
+
+Setup:
+1. Facilitator escolhe um postmortem REAL de incident passado (>3 meses,
+   para não ter risco emocional fresco) — pode ser de outro time/empresa.
+2. Facilitator narra timeline progressivamente, parando em pontos-chave.
+3. Em cada parada, time discute: "O que vocês fariam agora? Por quê?"
+4. Comparar respostas com decisão real do incident.
+5. Discutir: "Quais decisões foram boas? Quais foram piores em retrospecto?"
+
+Resultado:
+- Time pratica response sem stress real
+- Identifica gaps de conhecimento (nem todos sabem sobre runbook X)
+- Cria muscle memory para próximo SEV1
+- Materializa lições do postmortem original em ação prática
+
+Anti-objetivo:
+NÃO é "humilhar quem tomou decisão errada no incident original".
+É blameless training — focar em sistema/processo de decisão.
+```
+
+### Pattern: postmortem chain — `/forense` → `/postmortem`
+
+```text
+Fluxo natural após incident:
+
+1. Detecção: alerta SLO burn rate dispara → on-call ack → Slack channel #inc-NN
+2. Mitigation: rollback ou hotfix → SLO restored → incident closed
+3. /forense (framework v1.10): Core Analysis Loop sobre logs/git/state →
+   gera .planning/investigations/<id>.md com hipóteses validadas e root cause
+4. /postmortem --from-investigation <id> (Phase 38):
+   postmortem-writer (Phase 37) consome <id>.md e gera template preenchido
+   em .planning/postmortems/<id>.md
+5. Reviewer lê draft e exige fixes (no postmortem left unreviewed)
+6. Final marked + archived em milestone correspondente
+7. Action items P0 viram phases inseridas no roadmap próximo (`/inserir-fase`)
+```
+
+## Anti-patterns
+
+### ANTI: blame culture
+
+```text
+ANTI: postmortem nomeia "fulano fez deploy errado", "@maria não testou direito",
+      "o time de X causou o problema"
+
+PROBLEMA: engineers escondem incidents próximos ao limite por medo de retaliação;
+          psychological safety colapsa; replicação garantida (próximo near-miss
+          vira full incident porque ninguém reportou); team rotation aumenta;
+          quem fica deixa de propor mudanças arriscadas (mesmo as boas).
+
+CERTO: foco em sistema/processo (ausência de canary, ausência de rollback
+       automatizado, gate de CI faltante); pessoas são parte do sistema, NÃO
+       o root cause; revisão por par sênior antes de arquivar — reviewer
+       redireciona toda menção a pessoa para "que processo permitiu?".
+```
+
+### ANTI: action items vagos
+
+```text
+ANTI: "Melhorar monitoring", "Revisitar processo de deploy", "Investigar mais",
+      "Documentar melhor"
+
+PROBLEMA: sem owner, sem due date, sem critério de "feito"; ficam pendentes
+          para sempre; mesma falha repete em 6 meses porque nada concreto
+          aconteceu; aprendizado do incident é perdido na próxima sprint.
+
+CERTO: SMART (Specific, Measurable, Assignable, Realistic, Time-bound) —
+       "Bob adiciona SLO burn alert em /api/v1/orders até 2026-05-15";
+       "Alice documenta RPS limit em runbook orders-service até 2026-05-22".
+```
+
+### ANTI: postmortem left unreviewed
+
+```text
+ANTI: autor escreve postmortem, ninguém revisa, vai direto para o arquivo
+
+PROBLEMA: autor está perto demais (mente involuntariamente sobre próprio
+          papel — sem má-fé, é a natureza humana); root cause errado
+          documentado; lições não-generalizáveis; mesma falha repete porque
+          ação errada foi tomada com base em diagnóstico errado.
+
+CERTO: revisor sênior aplica checklist (8 perguntas — ver Pattern: revisão
+       por par sênior); só depois `Final` status; "no postmortem left
+       unreviewed" é regra absoluta — incident sem postmortem revisado
+       conta como aberto, mesmo que serviço esteja restaurado.
+```
+
+### ANTI: postmortem só para SEV1
+
+```text
+ANTI: "só investigar incident que pagou on-call"; SEV2/SEV3 ignorados;
+      near-misses (detecção rápida evitou impacto) descartados
+
+PROBLEMA: near-misses são oportunidade de aprender SEM CUSTO — perdê-los
+          é desperdício; SEV3s acumulam até virar SEV1 (mesma classe de
+          falha, escala diferente); tendências invisíveis (3 SEV3s em 1 mês
+          no mesmo serviço = sinal); team perde músculo de investigação.
+
+CERTO: SEV1/SEV2 mandatório; SEV3 opcional mas encorajado; near-miss notável
+       (detection rápida evitou impacto) é candidato a postmortem leve
+       (Summary + Impact + Lessons Learned, sem timeline detalhada se durou
+       < 1 min). Investigation barata, lição grátis.
+```
+
+### ANTI: timeline ambígua
+
+```text
+ANTI: "Por volta das 14h", "After lunch", "Em horário de pico",
+      "Ontem à tarde"
+
+PROBLEMA: reviewers de outros timezones perdem contexto (15h Brasília
+          = 18h UTC = 11h US-East); reconstrução em > 30 dias impossível
+          (lembra "horário de pico"?); análise estatística (MTTR
+          distribution, time-to-detect) impossível sem timestamps; cross-
+          incident correlation falha.
+
+CERTO: sempre `HH:MM UTC` no formato 24h; cada evento na timeline com
+       timestamp; UTC é o único timezone universal — converter quando
+       compartilhar com stakeholders locais, NUNCA armazenar local.
+```
+
+### ANTI: copy-paste de postmortem template sem investigation
+
+```text
+ANTI: abrir template, preencher campos genéricos, "Resolution: investigamos
+      e resolvemos", "Root Cause: bug no código"; sem dados, sem 5 whys
+
+PROBLEMA: root cause errado documentado; action items irrelevantes;
+          lessons learned superficiais; falha equivalente em 3 meses
+          porque diagnóstico verdadeiro nunca foi feito; postmortem vira
+          ritual burocrático em vez de instrumento de aprendizado.
+
+CERTO: postmortem nasce de investigation real (Core Analysis Loop, /forense,
+       ou logs/state via mcp__supabase__get_logs); preencher com EVIDÊNCIAS
+       (queries que rodaram, logs específicos, métricas observadas), não
+       impressões; cada Root Cause precisa de prova citável.
+```
+
+## Verificação
+
+Antes de marcar postmortem como `Final`:
+
+1. **9 seções canônicas presentes** — Summary, Impact, Root Causes, Trigger, Resolution, Detection, Action Items, Lessons Learned, Timeline UTC
+2. **Root cause sistêmico** — não nomeia pessoa; passou pelo 5 whys
+3. **Action items SMART** — Specific, Measurable, Assignable (owner @user), Realistic, Time-bound (due date)
+4. **Timeline em UTC** — sem timezone ambíguo
+5. **Impact quantificado** — # usuários, duração HH:MM, SLO budget consumido, revenue
+6. **Lições generalizáveis** — aplicáveis a outros serviços/incidents
+7. **Reviewed por par sênior** — checklist 8 perguntas aplicado
+8. **Supporting evidence linkada** — investigation, dashboards, queries
+9. **Action items P0 escalonados** — viraram phases ou tasks no roadmap próximo
+
+## Ver também
+
+- [`_shared-sre/glossary.md`](../_shared-sre/glossary.md) — termos canônicos postmortem, blameless, root cause, Wheel of Misfortune
+- [`core-analysis-loop`](../core-analysis-loop/SKILL.md) (v1.9) — Core Analysis Loop alimenta investigation que vira postmortem
+- [`sre-risk-management`](../sre-risk-management/SKILL.md) — postmortem documenta budget consumido
+- [`production-readiness-review`](../production-readiness-review/SKILL.md) — PRR axis "Emergency Response" exige postmortem culture
+- [`eliminating-toil`](../eliminating-toil/SKILL.md) — toil-induced incidents geram postmortems
+
+---
+
+*Material-fonte: Site Reliability Engineering — Beyer, Jones, Petoff, Murphy (Google/O'Reilly, 2016) — Cap 15: "Postmortem Culture: Learning from Failure".*

package/kit/skills/burn-rate-alerting/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: burn-rate-alerting
+description: Use ao calcular burn rate predictive — lookahead/baseline window com fator 4×, context-aware vs short-term, fórmula de extrapolação para alert page vs ticket.
+---
+
+# Observabilidade — Burn Rate Alerting
+
+## Quando usar
+
+LLM carrega esta skill ao configurar alertas SLO ou avaliar burn rate. Trigger phrases:
+
+- "burn rate alert", "burn rate forecast"
+- "lookahead window", "baseline window"
+- "predictive vs context-aware"
+- "quando paginar vs quando criar ticket"
+- "extrapolar exhaustão de budget"
+
+## Fórmula canônica
+
+```
+burn_rate = error_rate / (1 - SLO_target)
+```
+
+| Burn rate | Significado |
+|---|---|
+| 1× | Budget durará exatamente a janela do SLO |
+| 2× | Budget acabará em metade da janela |
+| 10× | Budget acabará em 1/10 da janela |
+| 100× | Budget esgotado em horas, não dias |
+
+**Predictive forecast (Cap 13 p145):**
+
+```
+projected_remaining_at_lookahead = current_remaining - (burn_rate_now × lookahead_window)
+ALERT iff projected_remaining_at_lookahead < 0
+```
+
+## Regras absolutas
+
+- **Lookahead ≤ 4× baseline** — extrapolar 4 horas a partir de baseline 1h é confiável; extrapolar 1 dia a partir de 1h é flappy. (Sem ajuste de seasonality)
+- **Sliding window 30d** para o SLO — alinha com customer memory (skill [`event-based-slos`](../skills/event-based-slos/SKILL.md))
+- **2 alertas por SLO** — short-term (page) + long-term (ticket). Não 1 só, não 5+.
+- **Short-term: lookahead 4h, baseline 1h** — paga on-call em horas
+- **Long-term: lookahead 3d, baseline 18h** — abre ticket, não acorda alguém
+- **Context-aware vs short-term** — escolher por trade-off de custo vs sensibilidade. Default short-term para a maioria; context-aware se "10% restante = mais urgente que 90%".
+- **Não alertar zero-level** — se você só alerta quando budget = 0, não há tempo de reagir. Use predictive sempre.
+
+## Patterns canônicos
+
+### Pattern: 2 alertas canônicos por SLO
+
+```yaml
+# PT-BR: para SLO 99.9% checkout_success com window 30d
+slo: checkout_success
+target: 0.999
+window: 30d_sliding
+
+alerts:
+  # PT-BR: PAGE — paginar on-call (urgent)
+  - name: short_term_burn
+    type: predictive
+    lookahead: 4h          # PT-BR: forecast 4h à frente
+    baseline: 1h           # PT-BR: 4× regra (4h ≤ 4× 1h ✓)
+    severity: page
+    threshold_burn_rate: 14.4   # PT-BR: 4h × 14.4 = ~58h, esgota budget de 30d×0.001 = 43.2min em <4h
+    routing: pagerduty:on-call
+  
+  # PT-BR: TICKET — criar ticket Jira/Linear (não-urgent)
+  - name: long_term_burn
+    type: predictive
+    lookahead: 3d
+    baseline: 18h          # PT-BR: 4× regra (3d ≤ 4× 18h = 72h ✓)
+    severity: ticket
+    threshold_burn_rate: 1.0    # PT-BR: 1× = vai esgotar em 30d se continuar
+    routing: jira:engineering
+```
+
+### Pattern: query de burn rate atual (Postgres)
+
+```sql
+-- PT-BR: burn rate atual em janela baseline (último 1h)
+-- Para SLO 99.9% checkout_success
+with baseline as (
+  select
+    sum(good) as good,
+    sum(bad) as bad,
+    sum(total) as total
+  from obs.sli_checkout_success
+  where bucket > now() - interval '1 hour'   -- baseline window
+)
+select
+  total,
+  bad,
+  bad::float / nullif(total, 0) as error_rate,
+  (bad::float / nullif(total, 0)) / (1 - 0.999) as burn_rate,
+  case
+    when bad::float / nullif(total, 0) >= 0.0144 then 'PAGE'   -- burn_rate ≥ 14.4
+    when bad::float / nullif(total, 0) >= 0.001 then 'TICKET'   -- burn_rate ≥ 1
+    else 'OK'
+  end as alert_status
+from baseline;
+```
+
+### Pattern: predictive forecast — esgotamento
+
+```sql
+-- PT-BR: ETA exhaustão do budget em horas
+with current_state as (
+  select
+    sum(case when bucket > now() - interval '30 days' then bad else 0 end) as bad_30d,
+    sum(case when bucket > now() - interval '30 days' then total else 0 end) as total_30d,
+    sum(case when bucket > now() - interval '1 hour' then bad else 0 end) as bad_1h,
+    sum(case when bucket > now() - interval '1 hour' then total else 0 end) as total_1h
+  from obs.sli_checkout_success
+)
+select
+  -- PT-BR: budget restante em eventos
+  (1 - 0.999) * total_30d - bad_30d as remaining_budget,
+  -- PT-BR: taxa atual de queima (eventos/hora)
+  bad_1h::float / 1 as burn_per_hour,
+  -- PT-BR: ETA = budget restante / taxa
+  case
+    when bad_1h = 0 then 'NO_BURN'
+    else round(((1 - 0.999) * total_30d - bad_30d) / nullif(bad_1h, 0))::text || 'h'
+  end as eta_to_exhaustion
+from current_state;
+```
+
+### Pattern: context-aware vs short-term
+
+```text
+SHORT-TERM (cheap):
+  - Olha apenas baseline window (último 1h)
+  - Não considera quanto budget já foi gasto
+  - Mais barato; default para maioria
+  - Pode causar false positive se budget está cheio (90% restante)
+
+CONTEXT-AWARE (expensive):
+  - Considera budget remanescente
+  - "Remaining budget × tolerable_burn_rate ≥ lookahead × current_burn_rate"
+  - Mais caro (query SLO total + recente)
+  - Recomendado para SLOs de alto risco onde 10% restante > 90% restante
+```
+
+### Pattern: dashboard de burn rate (Markdown gerado por `/burn-rate-status`)
+
+```markdown
+# Burn Rate Status — 2026-05-06 14:32 UTC
+
+| SLO | Target | Window | Budget gasto | Burn rate atual | ETA exhaustão | Ação |
+|---|---|---|---|---|---|---|
+| checkout_success | 99.9% | 30d sliding | 23% | 1.4× | 12d | informativo |
+| login_success | 99.95% | 30d sliding | 78% | 8.0× | 4h | **PAGE on-call** |
+| search_latency | 99% | 30d sliding | 15% | 0.7× | — | OK |
+| admin_panel | (sem SLO) | — | — | — | — | — |
+```
+
+### Pattern: tightening alerts gradualmente
+
+```text
+SEMANA 1: SLO + alerts em test channel (não real page)
+SEMANA 2: SLO + alerts em low-priority email
+SEMANA 3-4: validar que SLO detecta incidents reais
+SEMANA 5+: alerts SLO viram primários, threshold antigos para test channel
+SEMANA 8+: deletar threshold antigos completamente
+
+PT-BR: case study Honeycomb (Cap 12 p135) — SLO detectou outage 8h antes
+       de threshold tradicional alertar. Confiança = deletar antigos.
+```
+
+## Anti-patterns
+
+### ANTI: 1 alerta apenas (zero-level)
+
+```text
+ANTI: alert dispara quando budget == 0 (totalmente exausto)
+
+PROBLEMA: você não tem tempo de reagir. Budget zerou, SLO violado, cliente afetado.
+
+CERTO: 2 alertas:
+  - Short-term: burn rate 14.4× → page (4h de runway)
+  - Long-term: burn rate 1× → ticket (3d de runway)
+```
+
+### ANTI: lookahead >> baseline
+
+```text
+ANTI: lookahead 1d a partir de baseline 1h (24×)
+
+PROBLEMA: extrapolação linear de janela curta para janela longa é inválida.
+          Ciclos diários, semanais, sazonalidades distorcem.
+          Alert flappa (entra/sai a cada hora).
+
+CERTO: lookahead ≤ 4× baseline (regra empírica do livro p145)
+       Para alertar 1d à frente: baseline ≥ 6h
+```
+
+### ANTI: burn rate threshold = 1×
+
+```text
+ANTI: page on-call quando burn rate >= 1× (igual à taxa que esgota a janela)
+
+PROBLEMA: 1× sustained durante 1 mês = budget zerou ao final.
+          Time tem 30d para reagir. NÃO é page-worthy.
+
+CERTO: page = 14.4× (esgota em 4h, ação imediata)
+       ticket = 1× (esgota em 30d, ação planejada)
+```
+
+### ANTI: burn rate calculation com janela errada
+
+```text
+ANTI: calcular burn rate sobre janela inteira de SLO (30d)
+
+PROBLEMA: smooth out spikes recentes. Você vê "compliance ok 99.7%" mesmo
+          quando última 1h queimou 30% do budget. Reage tarde.
+
+CERTO: burn rate sobre baseline window (1h ou 18h), comparado ao SLO inteiro
+       para avaliar remaining budget.
+```
+
+### ANTI: ignorar seasonality
+
+```text
+ANTI: alertar 1d à frente sem considerar que sábado tem 1/3 do tráfego
+
+PROBLEMA: false positive sexta à noite (sábado vai ser baixo);
+          false negative segunda de manhã (sábado foi baixo, segunda explode).
+
+CERTO: ou (a) usar baseline window grande o suficiente para capturar 1 ciclo
+            (≥ 24h cobre dia/noite; ≥ 7d cobre semana);
+       ou (b) modelar seasonality (cíclico) — context-aware burn alerts
+            que conhecem padrões.
+```
+
+## Verificação
+
+Antes de promover burn alerts a produção:
+
+1. **2 alertas por SLO** — short-term (page) + long-term (ticket)
+2. **Lookahead ≤ 4× baseline** — verifique aritmética em cada
+3. **Threshold burn rate calculado** — `target=99.9% → page=14.4×, ticket=1×`
+4. **Routing nomeado** — `pagerduty:on-call` ou `jira:engineering`
+5. **Test channel primeiro** — 1+ semana em low-priority antes de promover
+6. **SLO já provou valor** — detectou incident antes de threshold antigo
+7. **Documentação** — runbook de "o que fazer quando alert dispara"
+
+---
+
+## Ver também
+
+- `kit/skills/_shared-observability/glossary.md` — burn rate, lookahead/baseline
+- `kit/skills/event-based-slos/SKILL.md` — SLO definition
+- `kit/skills/core-analysis-loop/SKILL.md` — investigar root cause após alert
+- `kit/agents/burn-rate-forecaster.md` — agente que calcula via SQL
+- `kit/commands/burn-rate-status.md` — comando que invoca forecaster
+
+*Material-fonte: Observability Engineering (O'Reilly, 2022) — Cap 13: "Acting on and Debugging SLO-Based Alerts".*