@luanpdd/kit-mcp 1.9.0 → 1.11.0

package/kit/skills/cascading-failures/SKILL.md

@@ -0,0 +1,307 @@
+---
+name: cascading-failures
+description: Use ao desenhar/auditar serviços com deps externas — cap 22 livro Google SRE. Triggers de cascade, loops de feedback, prevenção via timeout/jitter/deadline/circuit breaker, immediate response.
+---
+
+# SRE — Addressing Cascading Failures
+
+## Quando usar
+
+LLM carrega esta skill ao analisar serviço com risco de cascade, ou durante incident em progresso onde failure se amplifica. Trigger phrases:
+
+- "cascading failure", "falha em cascata"
+- "retry storm", "thundering herd"
+- "outage propagando", "serviço caindo um após outro"
+- "como prevenir cascade?", "circuit breaker"
+- "cap 22 Google SRE"
+- "deadline propagation", "load shedding"
+
+## Regras absolutas
+
+- **Cascade tem 5 triggers canônicos:** server overload, resource exhaustion, service unavailability, latency spike sem timeout, retry sem jitter. Memorize-os.
+- **Prevenção custa 1×, recuperação custa 100×.** Toda dep crítica DEVE ter timeout + retry com jitter + circuit breaker + deadline propagation. Sem isso, cascade é questão de tempo.
+- **Saturation (cap 6 v1.10) é early warning de cascade.** Quando saturation > 80%, ainda há tempo. Quando hit 100%, já está em cascade.
+- **Retry SEMPRE com jitter.** Full jitter por default (`delay = random(0, base × 2^attempt)`). Sem jitter = thundering herd garantido.
+- **Retry SEMPRE com deadline.** Retry sem timeout amplifica cascade — call de 30s vira 90s vira 270s. Deadline propagation evita work zumbi.
+- **Circuit breaker DEFAULT em qualquer dep externa.** Estados closed/open/half-open. Open dispara após N failures consecutivas; half-open permite 1 probe; closed após probe verde.
+- **Load shedding > 503 graceful > queue overflow.** Server saturated DEVE retornar 503 com Retry-After ANTES de aceitar request que vai falhar. Aceitar e cair = pior que rejeitar.
+- **Slow start em recovery.** Após outage, ramp-up gradual (10% → 25% → 50% → 100%). Full blast em recovery = falha de novo (caches frios, conn pools).
+
+## Patterns canônicos
+
+### Pattern 1: 5 triggers canônicos de cascade (cap 22)
+
+```text
+1. SERVER OVERLOAD
+   Sintoma: load > capacity → latency p99 sobe 10× → errors 5xx → crashes
+   Trigger upstream: traffic spike, outage de cache, batch job rodou em horário ruim
+   Detect: Saturation gauge (cap 6) > 80% por > 5 min
+   Resposta: load shedding + escalação manual
+
+2. RESOURCE EXHAUSTION
+   Tipos: CPU, memory, file descriptors, threads, connection pool
+   Sintoma específico:
+     CPU 100% → latency sobe; FDs esgotados → "too many open files"
+     Memory OOM → process kill; threads → deadlock; conn pool empty → wait
+   Detect: monitor por recurso específico; alarmes em 80% de cada
+   Resposta: configure limits; circuit breaker; rate limit caller
+
+3. SERVICE UNAVAILABILITY (DEP DOWN)
+   Sintoma: dep externa retorna 5xx ou timeout. Sem circuit breaker:
+   N clients × M retries × T deadline = explosão de calls
+   Detect: error rate de dep > 50% por 1 min; latency dep > p99 normal × 5
+   Resposta: circuit breaker abre; fallback (cache, default value, degraded mode)
+
+4. LATENCY SPIKE SEM TIMEOUT
+   Sintoma: dep responde lento mas não falha. Caller fica esperando.
+   Conn pool de caller esgota; novos requests também ficam pendurados.
+   Detect: dep latency p99 > baseline × 5
+   Resposta: timeout AGRESSIVO (ex: p99.9 baseline + 50%); circuit breaker
+
+5. RETRY SEM JITTER
+   Sintoma: 1000 clients retentam ao mesmo tempo após dep recovery.
+   Server recém-recuperado é matado pelo wake-up.
+   Detect: traffic spike no momento exato de recovery
+   Resposta: full jitter; retry budget global; slow start
+```
+
+### Pattern 2: Defesa em camadas (cap 22)
+
+Cada chamada externa precisa de **5 camadas de defesa**:
+
+```ts
+// Camada 1: Timeout agressivo
+const TIMEOUT_MS = 2000  // p99.9 baseline + 50%
+
+// Camada 2: Retry com jitter + deadline
+async function callDep(input: Input, deadline: number): Promise<Output> {
+  const startMs = performance.now()
+  let attempt = 0
+  let lastError: Error | undefined
+
+  while (true) {
+    const remaining = deadline - performance.now()
+    if (remaining <= 0) throw new DeadlineExceededError(lastError)
+
+    const callTimeoutMs = Math.min(TIMEOUT_MS, remaining)
+
+    try {
+      // Camada 3: Circuit breaker
+      if (circuitBreaker.isOpen()) throw new CircuitOpenError()
+
+      const result = await withTimeout(
+        depClient.call(input),
+        callTimeoutMs
+      )
+      circuitBreaker.recordSuccess()
+      return result
+    } catch (e) {
+      lastError = e as Error
+      circuitBreaker.recordFailure()
+
+      // Camada 4: Não retentar erros não-retentáveis
+      if (!isRetryable(e)) throw e
+
+      // Camada 5: Retry budget global
+      if (!retryBudget.tryAcquire()) throw new RetryBudgetExhaustedError(e)
+
+      attempt++
+      if (attempt >= MAX_RETRIES) throw e
+
+      // Full jitter
+      const baseMs = 100 * Math.pow(2, attempt - 1)
+      const jitterMs = Math.random() * baseMs * 2
+      await sleep(Math.min(jitterMs, remaining))
+    }
+  }
+}
+
+function isRetryable(e: any): boolean {
+  // 4xx (validation, auth, not_found) → não retry
+  // 5xx, timeout, connection reset → retry
+  if (e.statusCode >= 400 && e.statusCode < 500) return false
+  if (e.statusCode === 429) return true  // rate limited — retry com backoff
+  return true
+}
+```
+
+### Pattern 3: Circuit breaker — estados canônicos
+
+```text
+                    ┌────────────────────┐
+                    │    CLOSED (normal) │
+                    │  request flows OK  │
+                    └─────────┬──────────┘
+                              │ N consecutive failures
+                              ▼
+                    ┌────────────────────┐
+                    │       OPEN         │
+                    │  fail fast for T   │
+                    │   no calls to dep  │
+                    └─────────┬──────────┘
+                              │ T elapsed
+                              ▼
+                    ┌────────────────────┐
+                    │    HALF-OPEN       │
+                    │  allow 1-N probes  │
+                    └────┬───────────┬───┘
+                  success │           │ failure
+                          ▼           ▼
+                       CLOSED        OPEN
+
+Configuração canônica:
+  N (failures-to-open):    5-10 consecutive
+  T (open duration):       30-60s
+  half-open probe count:   1-5
+  failure detection window: 30-60s rolling
+```
+
+### Pattern 4: Deadline propagation across hops
+
+```text
+Client → Service A (deadline=30s) → Service B (deadline=?) → Service C (deadline=?)
+
+WRONG (cascade amplification):
+  A: receives deadline=30s, calls B with timeout=30s
+  B: receives no deadline, default 30s, calls C with timeout=30s
+  C: takes 30s
+  Total: 30s in C, plus parent overhead. Client gone at 30s, A-B-C still working.
+
+RIGHT (deadline propagation):
+  A: receives TTL=30s; takes 100ms processing; calls B with TTL=29.9s
+  B: receives TTL=29.9s; takes 50ms; calls C with TTL=29.85s
+  C: receives TTL=29.85s; works until that limit, no more
+  When TTL hits 0, ALL hops fail fast. No zombie work.
+
+Implementação:
+  - HTTP: header `Deadline-Ms` ou similar (custom)
+  - gRPC: built-in `grpc-timeout` header
+  - JS/TS: AbortSignal.timeout(remainingMs)
+  - Each hop: deadline = received_deadline - elapsed_local; abort se ≤ 0
+```
+
+### Pattern 5: Defesas server-side
+
+Server protege a si próprio (não confia em clientes):
+
+| Defesa | Técnica | Exemplo |
+|---|---|---|
+| **Rate limit per-client** | Token bucket no proxy/gateway | Kong/Envoy rate limit; 100 req/s/client |
+| **Concurrency limit** | Semaphore no handler | Máx 1000 in-flight; reject 503 if cheio |
+| **Queue depth limit** | Bound + drop policy | Queue máx 10k msgs; drop oldest > 5k |
+| **Resource budget** | Cgroups / container limits | CPU 4 cores, memory 8GB hard cap |
+| **Slow start na recovery** | Gradual ramp | Aceita 10% → 25% → 50% → 100% por 5 min |
+
+### Pattern 6: Testing for cascading failures
+
+Antes de prod, exercitar cascade scenarios:
+
+```text
+1. Game day exercise
+   - Cap 1 dep crítica em 50% errors via fault injection
+   - Observar: caller circuit breakers abrem? Latency caller estável?
+   - Métrica: zero impacto a clientes (degraded mode kicks in)
+
+2. Load test até saturação
+   - Ramp traffic até 1.5× expected peak
+   - Confirmar: load shedding ativa antes de crash
+   - Métrica: error rate sob 1% mesmo em 1.5× load
+
+3. Chaos engineering
+   - Random kill de instâncias (Chaos Monkey)
+   - Confirmar: retries com jitter espalham wake-up
+   - Métrica: SLO mantido durante 10 kills/hour
+```
+
+## Anti-patterns
+
+### ANTI: timeout otimista
+
+```text
+ANTI: timeout = p99 baseline. "Maioria das requests fica abaixo".
+
+PROBLEMA: tail latency (1%) sempre estoura. Cada 100 requests, 1
+          consome timeout inteiro. Conn pool acumula slow requests.
+
+CERTO: timeout = p99.9 baseline + 50% margem. Aceita que 0.1% será
+       cancelado. Tail é problema de dep, não cliente.
+```
+
+### ANTI: retry infinito com backoff "razoável"
+
+```text
+ANTI: retry até sucesso, com 1s/2s/4s/8s/... exponencial sem cap.
+
+PROBLEMA: durante outage de 30 min, último retry seria após 30 min
+          esperando. Conn fica pendurada. Memory leak.
+
+CERTO: max retries = 3-5; max backoff = 30s; deadline global
+       (request terminada após T segundos não importa quantos
+       retries). Após max, fallback ou error final.
+```
+
+### ANTI: circuit breaker per-instance (não compartilhado)
+
+```text
+ANTI: cada instância de service A tem seu próprio circuit breaker
+      pra dep B. Quando B fica lenta, instância 1 abre circuito,
+      mas instâncias 2-100 ainda pingam B até abrirem.
+
+PROBLEMA: 100× mais carga em B doente. B nunca recupera.
+
+CERTO: circuit breaker compartilhado (e.g., via Redis/Memcached para
+       state) OR lib que detecta failure rate cross-instance via
+       gossip/coordination. Open = cluster all stop.
+```
+
+### ANTI: load shedding via reject ao invés de 503 + Retry-After
+
+```text
+ANTI: server saturated → drop conn TCP-level (RST).
+
+PROBLEMA: client não sabe que precisa esperar. Retry imediato.
+          Mais carga. Retry storm.
+
+CERTO: 503 Service Unavailable + Retry-After: 30 (segundos).
+       Client aware retry com delay. Backoff respeitado.
+```
+
+### ANTI: graceful degradation só em prod
+
+```text
+ANTI: degraded mode só liga durante incident; nunca exercitado.
+
+PROBLEMA: quando precisa, descobre bug no degraded mode. Outage
+          piora.
+
+CERTO: degraded mode é PATH PRINCIPAL em alguma fração de tráfego
+       (1%) por padrão. Sempre exercitado. Quando dep cai, ramp pra
+       100% degraded é tested transition.
+```
+
+## Verificação
+
+Antes de aceitar serviço em prod:
+
+1. Toda chamada a dep externa tem timeout < p99.9 baseline + 50%
+2. Toda retry tem jitter (full jitter default)
+3. Toda chamada respeita deadline propagation
+4. Circuit breaker ativo em deps críticas (estados closed/open/half-open)
+5. Server-side: rate limit + concurrency limit + queue depth bound
+6. Slow start configurado em deploy/recovery
+7. Game day exercise rodado nos últimos 90 dias
+8. Saturation gauge (cap 6) instrumentado e alertado em 80%
+
+---
+
+## Ver também
+
+- [`_shared-sre/glossary.md`](../_shared-sre/glossary.md) — vocabulário cap 22 (cascading failure, retry storm, etc.)
+- [`retry-strategies`](../retry-strategies/SKILL.md) (v1.11) — detalhes de jitter + deadline propagation
+- [`load-shedding-graceful-degradation`](../load-shedding-graceful-degradation/SKILL.md) (v1.11) — defesas server-side
+- [`four-golden-signals`](../four-golden-signals/SKILL.md) (v1.10) — Saturation como early warning de cascade
+- [`production-readiness-review`](../production-readiness-review/SKILL.md) (v1.10) — PRR Axe 4 verifica defesas
+- [`omm-auditor`](../../agents/omm-auditor.md) (v1.9) — Capacidade 1 (Resilience) consume cascading-failures-auditor
+- [`cascading-failures-auditor`](../../agents/cascading-failures-auditor.md) (v1.11) — agent que detecta gaps automaticamente
+
+*Material-fonte: Site Reliability Engineering — Beyer/Jones/Petoff/Murphy (Google/O'Reilly, 2016) — Cap 22: "Addressing Cascading Failures".*

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