@luanpdd/kit-mcp 1.9.0 → 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/eliminating-toil/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: eliminating-toil
+description: Use ao identificar/eliminar toil — 6 critérios canônicos (manual, repetitivo, automatizável, tático, sem valor durável, escala linear), regra ≤ 50%, automação como invariante.
+---
+
+# SRE — Eliminating Toil
+
+## Quando usar
+
+LLM carrega esta skill ao auditar tarefas operacionais, classificar trabalho como toil/non-toil, ou propor automação. Trigger phrases:
+
+- "toil", "trabalho operacional"
+- "eliminar toil", "reduzir toil"
+- "≤ 50% toil", "regra 50%"
+- "automation", "automatizar tarefa repetitiva"
+- "isso é toil ou overhead?"
+- "Google SRE cap 5"
+- "TOIL-AUDIT"
+
+## Regras absolutas
+
+- **Toil tem 6 critérios canônicos** — uma tarefa É toil se TODOS os 6 valem: (1) **Manual** — humano executa cada vez; (2) **Repetitivo** — você já fez isso 3+ vezes; (3) **Automatizável** — script/cron resolve sem julgamento humano; (4) **Tático** — reage a evento, não planeja; (5) **Sem valor durável** — não cria asset permanente; (6) **Escala linear** — mais users = mais trabalho. Se QUALQUER um dos 6 = não, NÃO é toil (é overhead ou grungy work).
+- **Regra ≤ 50%** — SRE não pode gastar mais que 50% do tempo em toil; restante é engineering (automação, capacity planning, instrumentation, postmortems). Se medindo > 50% por 1+ trimestre, é red flag — peça ajuda à liderança.
+- **Toil ≠ overhead** — reuniões, RH, planejamento de quarter, performance review são **overhead** — necessários, não-elimináveis, NÃO contam para a regra ≤ 50%. Confundir overhead com toil = sub-medir.
+- **Toil ≠ grungy work** — refactor de código legado, security cleanup, DB rebuild para reduzir bloat são **grungy work** — necessários, têm valor durável, são engineering trabalho. NÃO contam como toil.
+- **Automação é o objetivo, não o meio** — automatizar parcialmente (humano clica botão A, depois B, depois C) ainda é toil. Automação completa (cron + script + alert se falhar) elimina toil. Meias-medidas perpetuam.
+- **Toil tax cresce com produto** — cada feature nova adiciona toil potencial: deploy manual, migration manual, feature flag rotation, customer-specific config. Prevenir > remediar — design feature considerando "como auto-operar isso?".
+- **Quantificar toil em horas-pessoa** — "TOIL-AUDIT.md" deve ter coluna `hours_per_week_per_person` para cada item. Sem quantificação, "muito toil" é subjetivo e não-acionável.
+- **Priorizar por (frequency × pain) / automation_effort** — P0 = alto frequency + alto pain + baixo effort. P2 = baixa frequency OU alto effort. Não automatizar tudo de uma vez — começar pelo P0.
+
+## Patterns canônicos
+
+### Pattern: decision tree para classificar trabalho
+
+```text
+Tarefa repetitiva detectada → aplicar 6 critérios canônicos:
+
+1. Manual?           (humano executa cada vez)             ┐
+2. Repetitiva?       (já fiz isso 3+ vezes)                 │
+3. Automatizável?    (script/cron resolve sem julgamento)   │── Se TODOS sim → TOIL
+4. Tática?           (reage a evento, não planeja)          │   → automatizar / eliminar
+5. Sem valor durável? (não cria asset permanente)           │   → contar em ≤ 50% rule
+6. Escala linear?    (mais users = mais trabalho)          ─┘
+
+Se NÃO for toil mas repetitivo, classificar:
+- OVERHEAD       (reuniões, RH, planning) → não-eliminável; NÃO conta em ≤ 50%
+- GRUNGY WORK    (refactor, sec cleanup) → necessário, valor durável → projeto engineering
+- PROJECT WORK   (criar novo serviço) → engineering trabalho ≠ toil
+```
+
+### Pattern: template `TOIL-AUDIT.md`
+
+Formato canônico que `toil-auditor` (Phase 37) gera:
+
+```markdown
+# TOIL-AUDIT — <projeto> — <data>
+
+## Métrica agregada
+
+- Toil estimado: X.X horas-pessoa/semana (Y% do tempo do time)
+- **Status vs ≤ 50% rule:** [GREEN: < 30%] | [YELLOW: 30-50%] | [RED: > 50%]
+- Top 3 áreas: <lista>
+
+## Itens identificados
+
+| # | Item | Frequência | Hours/week | Pain (1-5) | Automation effort | Priority |
+|---|------|------------|------------|------------|-------------------|----------|
+| 1 | Reset DB seed manual antes de cada test run | 2×/dia | 1.5 h | 4 | M (3 dias) | P0 |
+| 2 | Rotation de access_token de Edge Function | 1×/semana | 0.5 h | 2 | S (1 dia) | P1 |
+| 3 | Rebuild de índice fts_search após batch import | 1×/mês | 0.5 h | 3 | M (2 dias) | P1 |
+| 4 | Limpeza manual de orphan rows em audit_log | 1×/semana | 0.3 h | 1 | S (1 dia) | P2 |
+
+## P0 (automatizar agora)
+
+### Item 1: Reset DB seed manual
+
+**Por que é toil:** atende 6 critérios canônicos (manual, repetitivo 2×/dia, automatizável via script + pg_cron, tática reativa, sem valor durável, escala com #devs).
+
+**Automação proposta:** `make db-reset` que invoca `supabase db reset && pnpm run seed`. Adicionar pre-test hook em CI.
+
+**Esforço estimado:** 3 dias (Med — script existe parcialmente, falta seed deterministic).
+
+**Owner sugerido:** @dev-tools-team
+
+## P1 / P2 (escalonar)
+
+...
+
+## Não-toil identificado
+
+- **Overhead:** sprint planning (2h × semana × 5 pessoas = 10h/semana) — NÃO conta no ≤ 50%
+- **Grungy work:** refactor de `legacy_orders_service` (8h × semana × 1 pessoa = 8h/semana) — projeto, não toil
+```
+
+### Pattern: estágios de automação (níveis Google)
+
+| Estágio | Descrição | Exemplo |
+|---|---|---|
+| **L0: Manual** | 100% humano | "Cada deploy: SSH no host, copy binary, kill+restart" |
+| **L1: Documented** | Runbook escrito; humano segue passos | "Doc passo-a-passo de deploy em wiki" |
+| **L2: Tooled** | Script executa passos; humano invoca | "`./deploy.sh prod`" |
+| **L3: Self-service** | UI/CLI trigger; humano clica | "GitHub Actions deploy on PR merge" |
+| **L4: Autonomous** | Sem humano; só fail-state intervenção | "Auto-rollback se SLO burn rate > 4 nos primeiros 5 min após deploy" |
+
+Meta SRE é mover toda toil de L0/L1 para L3/L4. L2 é meio-passo aceitável quando L3+ requer investimento maior. **L1 (apenas runbook) é toil disfarçado** — runbook é manual com passo extra de "ler doc".
+
+### Pattern: identificação de toil via git log + scripts
+
+```bash
+# PT-BR: scripts shell em runbooks/ ou docs/runbooks/
+find . -name "*.sh" -path "*runbook*" -o -path "*ops*" | head -20
+
+# PT-BR: "manual steps" em README/docs (heurística — frase canônica)
+grep -rn "manually\|por favor\|run this\|every week\|cada semana" --include="*.md" .
+
+# PT-BR: tarefas repetitivas via git log — commits de mesmo tipo
+git log --since="3 months ago" --pretty=format:"%s" | sort | uniq -c | sort -rn | head -20
+# Ex: "20× Re-run failed migration in prod"  → TOIL candidato
+# Ex: "15× Bump deploy-token"                → TOIL candidato
+
+# PT-BR: cron jobs já automatizados (saída esperada)
+crontab -l 2>/dev/null
+cat /etc/cron.d/* 2>/dev/null
+```
+
+### Pattern: "toil tax" — prevenir feature nascer com toil
+
+```text
+Antes de mergear PR de nova feature, perguntar:
+
+1. "Como auto-operar isso em prod?"          → instrumentação ODD
+2. "Como auto-monitorar?"                     → 4 golden signals
+3. "Como auto-recuperar de fail comum?"       → retry, circuit breaker
+4. "Como auto-rotacionar credenciais?"        → vault + cron rotation
+5. "Como auto-limpar dados históricos?"       → retention policy + scheduled cleanup
+6. "Como onboarding de novo cliente?"         → self-service signup, não Slack ping
+
+Se QUALQUER resposta = "humano fará isso" → toil tax. Bloqueie ou descontar do release budget.
+```
+
+## Anti-patterns
+
+### ANTI: confundir overhead com toil
+
+```text
+ANTI: contar reuniões, RH, planning, performance review como toil — toda
+      atividade não-codificadora vira "toil" no audit.
+
+PROBLEMA: métrica inflada (e.g., 60% "toil" falso); ações erradas — cortar
+          reunião não diminui toil real; equipe perde tempo em automação
+          de overhead (que é não-eliminável por design).
+
+CERTO: overhead é categoria separada; ≤ 50% rule conta APENAS toil estrito
+       (6 critérios canônicos). Audit lista overhead em seção própria,
+       fora do total.
+```
+
+### ANTI: hero culture (toil mascara via heroísmo)
+
+```text
+ANTI: engineer fica 2h por dia executando deploys manuais e é "celebrado
+      por dedicação" / "salvador" — toil nunca aparece em métrica.
+
+PROBLEMA: toil invisível para liderança; investimento em automação adiado
+          indefinidamente; engineer pede demissão; sucessor herda toil sem
+          context — incidente garantido. Ciclo se repete.
+
+CERTO: TOIL-AUDIT trimestral mandatório; quantificar em hours/week por
+       pessoa; tornar visível em dashboards de produtividade. Heroísmo
+       sustentado = sinal de underinvestment, não de mérito.
+```
+
+### ANTI: documentar runbook em vez de automatizar
+
+```text
+ANTI: "Vamos só escrever um doc detalhado de como fazer isso passo-a-passo"
+      — runbook de 30 passos no wiki, sem script.
+
+PROBLEMA: L1 (Documented) ainda é toil — humano lê doc, segue passos,
+          falha em algum, doc desatualiza em 3 meses; primeira pessoa que
+          segue após drift quebra prod; ninguém atualiza doc retroativamente.
+
+CERTO: doc como passo intermediário (L1); meta é L3/L4 (autonomous);
+       marcar runbook com TODO de automação + owner + due date; sprint
+       seguinte transforma em script (L2) ou melhor.
+```
+
+### ANTI: automatizar parcialmente
+
+```text
+ANTI: script faz 3 dos 5 passos; humano completa os outros 2 — "execute
+      primeiro ./step1.sh, depois manualmente faça X em prod, depois
+      ./step3.sh".
+
+PROBLEMA: ainda é toil (humano envolvido); contexto-switch entre script e
+          humano dobra tempo total; script raramente atualizado por estar
+          "incompleto"; degrada para chain frágil que ninguém quer mexer.
+
+CERTO: automação completa OU não automatizar — meias-medidas perpetuam.
+       Se faltam 2 passos manuais, gastar mais 1 dia para fechar o loop;
+       resultado é L3/L4 autônomo, não L1.5 frankenstein.
+```
+
+### ANTI: ignorar toil de baixa frequência
+
+```text
+ANTI: "Só faço isso 1× por trimestre, não vale automatizar" — descartar
+      tarefas raras do audit.
+
+PROBLEMA: cumulative impact alto (10 tarefas trimestrais × 4 trimestres ×
+          30 min = 20h/ano); cada vez que retorna, pessoa esquece passos;
+          documentação envelhece entre execuções; DR exercises e migrations
+          raras são exatamente onde erro humano custa mais.
+
+CERTO: priorizar por (frequency × pain) / effort; baixa frequência +
+       alto pain (e.g., DR exercise, schema migration crítica) = ainda
+       P1. Frequência baixa ≠ toil baixo — soma de raras é alta.
+```
+
+## Verificação
+
+Antes de marcar audit de toil como completo:
+
+1. **Aplicado os 6 critérios canônicos** — cada item passou pelo decision tree (manual, repetitivo, automatizável, tático, sem valor durável, escala linear)
+2. **Quantificado em hours/week** — não "muito toil" mas "3.5h/week por pessoa"
+3. **% do tempo do time** computado — comparado contra ≤ 50% rule
+4. **Priorização por (frequency × pain) / effort** — P0/P1/P2 atribuído
+5. **Owner nomeado** para cada item P0
+6. **Overhead identificado separadamente** — não conta para ≤ 50%
+7. **Grungy work identificado separadamente** — projeto engineering, não toil
+8. **Pelo menos 1 item P0 escalonado** com automação proposta + esforço estimado
+
+---
+
+## Ver também
+
+- [`_shared-sre/glossary.md`](../_shared-sre/glossary.md) — termos canônicos toil, overhead, grungy work, automation
+- [`observability-maturity-model`](../observability-maturity-model/SKILL.md) (v1.9) — Capacidade 3 (Complexidade/Tech Debt) consome toil score
+- [`production-readiness-review`](../production-readiness-review/SKILL.md) — PRR axis "Change Management" verifica deploy não é toil
+- [`blameless-postmortems`](../blameless-postmortems/SKILL.md) — postmortems de toil-induced incidents alimentam audit
+- [`sre-risk-management`](../sre-risk-management/SKILL.md) — toil reduz tempo para reduzir risk
+
+*Material-fonte: Site Reliability Engineering — Beyer, Jones, Petoff, Murphy (Google/O'Reilly, 2016) — Cap 5: "Eliminating Toil".*

package/kit/skills/event-based-slos/SKILL.md

@@ -26,6 +26,28 @@ LLM carrega esta skill ao definir/avaliar SLOs ou substituir alertas threshold p
 - **Owner explícito** — cada SLO tem dono nomeado. Sem owner = sem ação = sem valor.
 - **Substituir alertas threshold gradualmente** — após SLO comprovar valor (1+ incident detectado por SLO antes de threshold), DELETAR threshold antigo.
 
+## Risk continuum — SLO target é decisão explícita
+
+> Cross-ref canônico: [sre-risk-management](../sre-risk-management/SKILL.md) (cap 3 do livro Google SRE — Embracing Risk).
+
+SLO target NÃO é meta arbitrária ("queremos 99.99% porque soa bom"). É uma escolha consciente no **continuum risk × innovation**: cada nove adicional **multiplica custo** mas **divide benefício marginal** percebido pelo cliente.
+
+| Target | Tolerância 30d | User-perceptible? | Quando faz sentido |
+|---|---|---|---|
+| 99% | 7.2 h | Sim, notável | Tier free, beta features, internal tools |
+| 99.5% | 3.6 h | Notável em paths críticos | Tier free de produção |
+| 99.9% | 43.2 min | Aceitável para maior parte de UX | Tier paid default |
+| 99.95% | 21.6 min | Quase imperceptível | Tier enterprise / mission-critical |
+| 99.99% | 4.3 min | Imperceptível em smartphone (~99% no canal do user) | Apenas se justificado por user perception (raro) |
+
+**Sabedoria 99.99%** — cliente final acessa via smartphone (~99% disponibilidade) com ISP residencial (~99%). Serviço 99.99% **não é distinguível** de 99.999% nesse contexto: ambos parecem "sempre funcionando". Esforço além de 99.95% para serviço user-facing é tipicamente desperdício.
+
+**Error budget é o instrumento contábil dessa decisão.** Para SLO 99.9% em 30d com 10M eventos: budget = `0.001 × 10M = 10k bad events`. Esse 10k é orçamento explícito para gastar em deploys arriscados, experimentos, refactors. Quando esgota, releases freezam até regenerar — não como punição, mas como **balanço explícito risk × innovation**.
+
+**Diferentes tiers, diferentes targets** — `customer.tier='enterprise'` pode justificar 99.95%; `tier='free'` pode operar em 99.5%. Tratar todos como tier-1 desperdiça budget; tratar todos como tier-3 frustra clientes pagantes. A skill `sre-risk-management` documenta o framework completo de decisão.
+
+> Em resumo: a regra `Target ≤ 99.95%` desta skill (acima) é **consequência** do risk continuum, não restrição arbitrária. Para 99.99%+ trate como métrica informativa (dashboard), NÃO como SLO acionável (alerts).
+
 ## Patterns canônicos
 
 ### Pattern: SLI event-based vs time-based