@luanpdd/kit-mcp 1.9.0 → 1.11.0

package/kit/skills/retry-strategies/SKILL.md

@@ -0,0 +1,372 @@
+---
+name: retry-strategies
+description: Use ao implementar retry — full/equal/decorrelated jitter, exponential backoff cap, retry budget, idempotency keys, when NOT to retry. Cap 22 livro Google SRE.
+---
+
+# SRE — Retry Strategies
+
+## Quando usar
+
+LLM carrega esta skill ao escrever código que chama dep externa e precisa lidar com failure transient. Trigger phrases:
+
+- "retry", "exponential backoff"
+- "jitter", "thundering herd"
+- "retry budget"
+- "idempotency key", "safe to retry?"
+- "quando NÃO retentar?"
+- "retry storm"
+
+## Regras absolutas
+
+- **Retry SEM jitter = retry storm garantido.** Sempre adicione jitter (full por default).
+- **Retry SEM deadline = work zumbi.** Cada retry respeita deadline propagation; após deadline aborta.
+- **Retry SOMENTE em erros retentáveis.** 5xx, timeout, connection reset = retry. 4xx (validation, auth, not_found) = NÃO retry.
+- **Idempotency key OBRIGATÓRIA em retry de write operation.** Sem idempotency, retry pode duplicar (charge double, send email twice, etc.).
+- **Retry budget global limita amplificação.** Sem budget, retry total = N clients × M retries × cascading.
+- **Max retries ≤ 3-5.** Mais que isso = bug não-transient mascarado.
+- **Backoff cap obrigatório.** Sem cap, último retry pode ser horas. `min(base × 2^attempt, cap)`.
+- **Não retry em rate limit a menos que respeite Retry-After.** 429 sem header → wait default; com header → respeita.
+
+## Patterns canônicos
+
+### Pattern 1: Tipos de jitter (cap 22)
+
+```ts
+// Full jitter — DEFAULT canônico (Google SRE recomenda)
+function fullJitter(baseMs: number, attempt: number, capMs = 30000): number {
+  const expBase = Math.min(baseMs * Math.pow(2, attempt), capMs)
+  return Math.random() * expBase  // [0, expBase)
+}
+
+// Equal jitter — variação; metade fixa, metade jitter
+function equalJitter(baseMs: number, attempt: number, capMs = 30000): number {
+  const expBase = Math.min(baseMs * Math.pow(2, attempt), capMs)
+  return expBase / 2 + Math.random() * (expBase / 2)
+}
+
+// Decorrelated jitter — para bursty load (AWS recomenda)
+function decorrelatedJitter(baseMs: number, lastDelayMs: number, capMs = 30000): number {
+  return Math.min(capMs, Math.random() * (lastDelayMs * 3 - baseMs) + baseMs)
+}
+
+// Comparação:
+//   FULL JITTER: spread máximo, simples, default canônico
+//   EQUAL JITTER: spread parcial, predictable mínimo
+//   DECORRELATED: spread depende do último; melhor pra long outages
+```
+
+### Pattern 2: Retry com deadline propagation
+
+```ts
+async function callWithRetry<T>(
+  call: () => Promise<T>,
+  opts: {
+    maxRetries: number
+    baseMs: number
+    capMs?: number
+    deadlineMs: number  // unix ms; retry só se ainda há tempo
+    isRetryable?: (e: Error) => boolean
+    retryBudget?: RetryBudget
+  }
+): Promise<T> {
+  const startMs = performance.now()
+  let lastError: Error | undefined
+
+  for (let attempt = 0; attempt <= opts.maxRetries; attempt++) {
+    // Check deadline antes de cada attempt
+    if (Date.now() > opts.deadlineMs) {
+      throw new DeadlineExceededError(lastError)
+    }
+
+    try {
+      return await call()
+    } catch (e) {
+      lastError = e as Error
+
+      // Não-retentável → throw imediato
+      if (opts.isRetryable && !opts.isRetryable(lastError)) throw lastError
+
+      // Retry budget global
+      if (opts.retryBudget && !opts.retryBudget.tryAcquire()) {
+        throw new RetryBudgetExhaustedError(lastError)
+      }
+
+      // Last attempt — não delay
+      if (attempt >= opts.maxRetries) throw lastError
+
+      // Calcula delay com full jitter
+      const delayMs = fullJitter(opts.baseMs, attempt, opts.capMs)
+
+      // Não exceder deadline
+      const remainingMs = opts.deadlineMs - Date.now()
+      if (delayMs >= remainingMs) {
+        throw new DeadlineExceededError(lastError)
+      }
+
+      await sleep(delayMs)
+    }
+  }
+  throw lastError!
+}
+```
+
+### Pattern 3: When NOT to retry — decision tree
+
+```text
+Erro recebido. Retry?
+
+1. HTTP status 4xx (excluding 408, 429)?
+   → NÃO retry. Validation/auth/not_found.
+   400, 401, 403, 404, 422 → throw imediato.
+
+2. HTTP status 408 (Request Timeout)?
+   → SIM retry. Servidor pediu (request expirou no servidor).
+
+3. HTTP status 429 (Too Many Requests)?
+   → SIM retry, COM Retry-After header se presente.
+   Sem Retry-After → backoff default + retry budget.
+
+4. HTTP status 5xx?
+   → SIM retry. Server error transient.
+
+5. Network error (connection reset, DNS failure)?
+   → SIM retry. Network transient.
+
+6. Timeout local (AbortSignal.timeout estourou)?
+   → SIM retry, mas check deadline global.
+
+7. Custom error (validation interna, business rule)?
+   → NÃO retry. Bug; retry não resolve.
+
+8. OperationCancelled (deadline upstream)?
+   → NÃO retry. Caller já desistiu.
+```
+
+```ts
+function isRetryable(e: any): boolean {
+  // 4xx geralmente não retry
+  if (e.statusCode >= 400 && e.statusCode < 500) {
+    if (e.statusCode === 408) return true
+    if (e.statusCode === 429) return true
+    return false
+  }
+
+  // 5xx retry
+  if (e.statusCode >= 500 && e.statusCode < 600) return true
+
+  // Network errors
+  if (e.code === 'ECONNRESET' || e.code === 'ETIMEDOUT' || e.code === 'EAI_AGAIN') return true
+
+  // Aborts não retry (caller desistiu)
+  if (e.name === 'AbortError' || e instanceof DeadlineExceededError) return false
+
+  // Default: não retry
+  return false
+}
+```
+
+### Pattern 4: Idempotency key em writes
+
+```ts
+// PT-BR: idempotency key permite retry seguro de writes
+import { randomUUID } from 'crypto'
+
+interface CreateOrderInput {
+  customerId: string
+  items: OrderItem[]
+  idempotencyKey?: string  // gerado se não fornecido
+}
+
+async function createOrderSafe(client: PaymentClient, input: CreateOrderInput): Promise<Order> {
+  const key = input.idempotencyKey ?? randomUUID()
+
+  return callWithRetry(
+    () => client.createOrder({ ...input, idempotencyKey: key }),  // ← SAME KEY em retry
+    {
+      maxRetries: 3,
+      baseMs: 500,
+      capMs: 30000,
+      deadlineMs: Date.now() + 30000,
+      isRetryable,
+    }
+  )
+}
+
+// Server-side
+async function createOrderHandler(input: CreateOrderInput): Promise<Order> {
+  // Check se já processamos esta key
+  const existing = await db.findByIdempotencyKey(input.idempotencyKey)
+  if (existing) return existing  // retorna mesmo result; safe to retry
+
+  // Process; record com idempotency_key (UNIQUE constraint)
+  return await db.transaction(async (tx) => {
+    const order = await tx.orders.insert({
+      ...input,
+      idempotency_key: input.idempotencyKey,  // UNIQUE constraint catches duplicate
+      created_at: new Date(),
+    })
+    return order
+  })
+}
+```
+
+**Anti-corruption:** idempotency keys SEMPRE em writes. Stripe, AWS S3, todos suportam. Se sua API não suporta, adicione (1 column UNIQUE).
+
+### Pattern 5: Retry budget (cap 22)
+
+```ts
+// PT-BR: retry budget global limita amplificação
+class RetryBudget {
+  private tokens: number
+  private readonly maxTokens: number
+  private readonly refillRate: number  // tokens per second
+  private lastRefillMs: number
+
+  constructor(opts: { maxTokens: number; refillPerSec: number }) {
+    this.tokens = opts.maxTokens
+    this.maxTokens = opts.maxTokens
+    this.refillRate = opts.refillPerSec
+    this.lastRefillMs = Date.now()
+  }
+
+  tryAcquire(): boolean {
+    this.refill()
+    if (this.tokens < 1) return false
+    this.tokens--
+    return true
+  }
+
+  private refill(): void {
+    const now = Date.now()
+    const elapsed = (now - this.lastRefillMs) / 1000
+    const refill = elapsed * this.refillRate
+    this.tokens = Math.min(this.maxTokens, this.tokens + refill)
+    this.lastRefillMs = now
+  }
+}
+
+// Configuração canônica:
+// - maxTokens = 10% da capacidade normal de calls/sec
+// - refillPerSec = mesmo
+// Se sua dep aguenta 1000 RPS, retry budget = 100 RPS de retries.
+// Excede = circuit breaker abre OR caller falha rápido.
+
+const retryBudget = new RetryBudget({ maxTokens: 100, refillPerSec: 100 })
+```
+
+### Pattern 6: Configuração canônica por tipo de call
+
+| Tipo de call | Max retries | Base | Cap | Jitter |
+|---|---|---|---|---|
+| **Read DB query** | 3 | 50ms | 1000ms | full |
+| **Write DB transaction** | 3 (com idempotency key) | 100ms | 5000ms | full |
+| **HTTP API third-party** | 3 | 500ms | 30000ms | full |
+| **Webhook delivery** | 5 | 1000ms | 60000ms | decorrelated |
+| **Background job** | 5+ | 5000ms | 600000ms (10min) | decorrelated |
+| **Real-time message** | 0-1 | — | — | — (deadline tight) |
+
+### Pattern 7: Observability de retry
+
+Métricas a instrumentar:
+
+```ts
+// Counter de retries por (dep, attempt)
+metrics.counter('retries_total', { dep: 'stripe', attempt: '1' })  // attempt 1, 2, 3
+
+// Counter de outcomes finais
+metrics.counter('retry_outcomes_total', { dep: 'stripe', outcome: 'success_after_retry' })
+metrics.counter('retry_outcomes_total', { dep: 'stripe', outcome: 'exhausted_max' })
+metrics.counter('retry_outcomes_total', { dep: 'stripe', outcome: 'budget_exhausted' })
+metrics.counter('retry_outcomes_total', { dep: 'stripe', outcome: 'deadline_exceeded' })
+
+// Histogram de delay total adicionado por retry
+metrics.histogram('retry_delay_added_ms', delayMs, { dep: 'stripe' })
+```
+
+Alertas:
+- `rate(retries_total) > 10% × rate(requests_total)` → dep degradada; investigate
+- `retry_outcomes{outcome="budget_exhausted"} > 0` → sistema sob storm; load shedding pode ajudar
+- `histogram retry_delay_added_ms > p99 baseline × 5` → delays inflados; deps lentas
+
+## Anti-patterns
+
+### ANTI: retry sem jitter
+
+```text
+ANTI: setTimeout(call, 1000 * 2^attempt) — fixed exponential.
+
+PROBLEMA: 1000 clients sincroniza retries. Storm na recovery.
+
+CERTO: Math.random() * 1000 * 2^attempt — full jitter.
+```
+
+### ANTI: retry em 4xx
+
+```text
+ANTI: catch (e) { return retry(call) } sem checar status.
+
+PROBLEMA: 400/422/404 retentado infinitamente. Bug não corrige sozinho.
+
+CERTO: isRetryable(e) check antes de retry. 4xx (excluding 408, 429)
+       throw imediato.
+```
+
+### ANTI: retry sem deadline
+
+```text
+ANTI: retry com max=5, base=1s. Worst case: 1+2+4+8+16=31s de delays.
+      Plus call time. Cliente já desistiu.
+
+PROBLEMA: work zumbi. Recursos consumidos sem benefit.
+
+CERTO: deadline propagation. Cada attempt checa Date.now() vs deadline.
+       Aborta cedo.
+```
+
+### ANTI: idempotency key per-attempt
+
+```text
+ANTI: retry gera NEW idempotency key cada attempt.
+
+PROBLEMA: cada attempt vira write distinta. Charge double, email
+          duplicado.
+
+CERTO: idempotency key gerada UMA vez por call lógica. Mesma key
+       em todos os attempts.
+```
+
+### ANTI: max retries muito alto
+
+```text
+ANTI: maxRetries = 20.
+
+PROBLEMA: bug não-transient mascarado. Erro real demora pra aparecer.
+          Logs de retry inundam observability.
+
+CERTO: max 3-5. Mais que isso = error real, não transient. Falha
+       rápido + alert > retry esperançoso.
+```
+
+## Verificação
+
+1. Toda retry tem jitter (full por default)
+2. Toda retry respeita deadline propagation
+3. isRetryable() check em cada attempt
+4. Idempotency key em writes
+5. Retry budget global ativo
+6. Max retries ≤ 5
+7. Backoff cap ≤ 60s para user-facing
+8. Métricas instrumentadas (counter retries, outcome, histogram delay)
+
+---
+
+## Ver também
+
+- [`_shared-sre/glossary.md`](../_shared-sre/glossary.md) — vocabulário (jitter types, retry storm, etc.)
+- [`cascading-failures`](../cascading-failures/SKILL.md) (v1.11) — retry sem jitter é trigger principal de cascade
+- [`load-shedding-graceful-degradation`](../load-shedding-graceful-degradation/SKILL.md) (v1.11) — server-side coopera (503 + Retry-After)
+- [`four-golden-signals`](../four-golden-signals/SKILL.md) (v1.10) — métricas de retry instrumentadas seguindo padrão
+- [`supabase-edge-fn-writer`](../../agents/supabase-edge-fn-writer.md) (v1.8 + patch v1.11) — Edge Functions ganham retry-with-jitter built-in
+- [`cascading-failures-auditor`](../../agents/cascading-failures-auditor.md) (v1.11) — agent detecta retry sem jitter
+
+*Material-fonte: Site Reliability Engineering — Beyer/Jones/Petoff/Murphy (Google/O'Reilly, 2016) — Cap 22 (subsections sobre retry, jitter, deadline propagation).*

package/kit/skills/sre-risk-management/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: sre-risk-management
+description: Use ao escolher SLO target — risk continuum, error budget como balanço explícito risk × innovation, "as reliable as needs to be, no more", sabedoria 99.99%.
+---
+
+# SRE — Risk Management
+
+## Quando usar
+
+LLM carrega esta skill ao definir SLO target, debater "qual disponibilidade precisamos?", ou justificar trade-off entre velocidade de release e estabilidade. Trigger phrases:
+
+- "SLO target", "qual disponibilidade?"
+- "99.9% vs 99.99%", "quantos noves?"
+- "error budget", "risk budget"
+- "risk continuum"
+- "as reliable as needs to be"
+- "sabedoria 99.99%", "smartphone dilui SLO"
+- "embracing risk", "Google SRE cap 3"
+
+## Regras absolutas
+
+- **100% disponibilidade NÃO é o objetivo** — custo cresce não-linearmente acima de 99.95%; benefício marginal cai a zero porque outros componentes (ISP do usuário, smartphone, ar do ambiente) já têm < 99.99% de disponibilidade. Esforço além disso é desperdício.
+- **"As reliable as needs to be, no more"** — disponibilidade é decisão de produto, não de engenharia. Pergunta: "qual nível o usuário percebe como aceitável e está disposto a pagar?" — não "qual o máximo que conseguimos?".
+- **Sabedoria 99.99%** — 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.
+- **Error budget é balanço explícito risk × innovation** — `(1 - SLO_target) × total_events` é orçamento de "bad" que pode ser gasto em deploys arriscados, experimentos, refactors. Se budget esgota, freeze releases até regenerar.
+- **Target ≤ 99.95% para SLO real** — 99.99% = 4.3 min de tolerância em 30d; sem tempo de reagir antes do budget esgotar; alerts viram zero-level. Para 99.99%+, use métricas/dashboards informativos, NÃO SLO acionável.
+- **SLI deve refletir customer perception** — meça o que o usuário sente ("checkout completou em < 800ms"), não estado interno ("threads ativas"). Risk é sobre consequência do customer, não engenharia.
+- **Diferentes tiers, diferentes targets** — `customer.tier='enterprise'` pode ter SLO 99.95%; `tier='free'` pode ter 99.5%. Risk é gradual; tratar todos clientes como tier-1 desperdiça budget.
+
+## Patterns canônicos
+
+### Pattern: risk continuum como decisão explícita
+
+| Target | Tolerância 30d | User-perceptible? | Recomendação | Custo relativo |
+|---|---|---|---|---|
+| 99% | 7.2 h | Sim (notável) | Tier free, beta features, internal tools | 1× |
+| 99.5% | 3.6 h | Notável em paths críticos | Tier free de produção | 2× |
+| 99.9% | 43.2 min | Aceitável para maior parte de 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 por user perception (raro) | 50×+ |
+| 99.999% | 26 s | NÃO perceptível | NUNCA para serviço user-facing | 100×+ |
+
+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%.
+
+### Pattern: error budget como decisão de release
+
+```yaml
+# PT-BR: SLO documenta target + política de budget
+slo:
+  name: checkout_success
+  target: 0.999          # 99.9% — escolha explícita no risk continuum
+  window: 30d_sliding
+
+# PT-BR: política de budget — o que fazer quando queima
+budget_policy:
+  green:                 # > 50% restante
+    action: "Releases livres; experimentos OK"
+  yellow:                # 10-50% restante
+    action: "Aumentar canary % menor; review extra de PRs riscados"
+  red:                   # < 10% restante
+    action: "Freeze de features; foco em stability; postmortems revisitados"
+  exhausted:             # 0%
+    action: "Freeze total; rollback de releases recentes; SEV1 incident review"
+```
+
+Budget esgotado **não é punição** — é sinal de que o time gastou risk em demais releases arriscadas e precisa pausar para investir em stability. Restaurar budget = entregar trabalho que reduz erro, não pular o reset.
+
+### Pattern: target diferenciado por customer.tier
+
+```sql
+-- PT-BR: SLO compliance por tier — diferentes targets, diferentes alarmes
+select
+  customer_tier,
+  count(*) as total,
+  count(*) filter (where result_success = true and duration_ms < 800) as good,
+  count(*) filter (where result_success = true and duration_ms < 800)::float / count(*) as compliance,
+  case customer_tier
+    when 'enterprise' then 0.9995    -- PT-BR: 99.95% — paga por SLO rigoroso
+    when 'pro' then 0.999            -- PT-BR: 99.9%
+    when 'free' then 0.995           -- PT-BR: 99.5% — best effort
+  end as target,
+  case
+    when count(*) filter (where result_success = true and duration_ms < 800)::float / count(*) >= (
+      case customer_tier
+        when 'enterprise' then 0.9995
+        when 'pro' then 0.999
+        when 'free' then 0.995
+      end
+    ) then 'IN_BUDGET'
+    else 'OUT_OF_BUDGET'
+  end as status
+from observability.events
+where service = 'orders-api' and timestamp > now() - interval '30 days'
+group by customer_tier;
+```
+
+### Pattern: justificar 99.99%+ excepcional
+
+```text
+Para SLO ≥ 99.99%, o time DEVE responder afirmativamente a TODAS as perguntas:
+
+1. User percebe diretamente a falha? (não apenas erro 500 — UX colapsa, dados perdidos)
+   Ex: trading platform de high-frequency, controle de fluxo industrial, healthcare critical
+
+2. Custo de outage > 10× custo de engineering p/ atingir target?
+   (calcular: 4.3 min outage por mês × revenue/min impactado)
+
+3. Sistema componentes downstream também são ≥ 99.99%?
+   (cliente em ISP 99% — investir aqui é desperdício; trocar de ISP/CDN primeiro)
+
+4. Time tem cultura para sustentar (canary obrigatório, rollback < 60s, on-call < 30s page)?
+   (sem isso, 99.99% é aspiracional — real será 99.5%)
+
+Se QUALQUER resposta = NÃO → use 99.95% ou menos. Justificar em SLO.md comentário inline.
+```
+
+## Anti-patterns
+
+### ANTI: pursuit of 100% availability
+
+```text
+ANTI: perseguir 100% como meta de disponibilidade — rejeitar qualquer outage como
+      falha de engenharia; medir sucesso por "zero downtime"
+
+PROBLEMA: custo cresce assintoticamente perto de 100%; benefício marginal cai a zero
+          porque downstream (ISP do usuário, smartphone, ar do ambiente) já tem
+          < 99.99%; time burns out perseguindo target inalcançável; budget de
+          inovação some — toda capacidade vai para reliability sem ganho real.
+
+CERTO: aceitar imperfeição como design — error budget existe PARA SER GASTO em
+       deploys arriscados, experimentos, refactors. Reliability é trade-off
+       contra velocity, não absoluto.
+```
+
+### ANTI: SLO 99.99% sem justificativa
+
+```text
+ANTI: definir 99.99% como target por default — "queremos o melhor possível";
+      copiar número do AWS SLA; impor 99.99% sem checklist de justificação
+
+PROBLEMA: 4.3 min de tolerância em 30d é zero margem de manobra; alerts disparam
+          após budget esgotar (zero-level — tarde demais para ação preventiva);
+          comportamentos perversos (esconder outages para preservar number);
+          time-pressure compulsiva; aspiração ≠ realidade — real será 99.5%
+          por falta de cultura para sustentar.
+
+CERTO: ≤ 99.95% por default; 99.99%+ exige passar checklist de 4 perguntas
+       (ver Pattern: justificar 99.99%+ excepcional). Documentar racional em
+       SLO.md como comentário inline auditável.
+```
+
+### ANTI: SLO global "site availability"
+
+```text
+ANTI: 1 SLO genérico "site availability 99.9%" cobrindo tudo — /admin, /api,
+      /checkout, /search, /docs com mesmo target
+
+PROBLEMA: falha em /admin (uso 1×/dia por staff) não importa para customer;
+          falha em /checkout (uso 100×/min com revenue impact) é catastrófico;
+          mistura tudo no mesmo budget — alerts confusos, ações vagas; quando
+          burn dispara, time não sabe o que priorizar.
+
+CERTO: 1 SLO por jornada crítica do user (`checkout_success: 99.9%`,
+       `login_success: 99.95%`, `search_p95: 99% < 200ms`); cada um com target
+       apropriado ao seu risk; admin/docs SEM SLO formal (só metric informativo).
+```
+
+### ANTI: budget como score de "performance"
+
+```text
+ANTI: celebrar "atingimos SLO 99.99% este mês!" como vitória; KPIs comparam
+      times por % budget intacto; pressão de leadership para subir target
+
+PROBLEMA: budget vira métrica de vaidade; budget intacto significa SUBUTILIZAÇÃO
+          (não shippamos suficientes deploys arriscados/experimentos); leadership
+          pressiona por mais features sem reconhecer trade-off; quando budget
+          esgota uma vez, vira "fracasso" — time esconde problemas no próximo mês.
+
+CERTO: budget é orçamento — gastá-lo é OK e esperado. KPI é "shippamos N deploys
+       de valor sem queimar budget", não "budget alto". Budget esgotado = sinal
+       de aprender (quais releases custaram caro?), não punição.
+```
+
+### ANTI: SLA == SLO
+
+```text
+ANTI: usar SLA do contrato (99.9%) como SLO interno — "se prometemos 99.9% no
+      contrato, basta atingir 99.9% internamente"
+
+PROBLEMA: 0 margem de segurança entre compromisso comercial e meta interna;
+          primeira anomalia operacional quebra contrato; sem buffer para reagir;
+          SEV1 vira liability legal; cliente perde confiança no primeiro burn.
+
+CERTO: SLO interno mais rígido que SLA externo — fator de margem 5×.
+       SLA externo: 99.9% (compromisso ao cliente);
+       SLO interno: 99.95% (meta de engenharia com folga para reagir).
+```
+
+## Verificação
+
+Antes de marcar SLO target como decidido:
+
+1. **Target justificado por customer perception** — não "queremos 99.99%" mas "usuário em smartphone percebe falha acima de X%"
+2. **Target ≤ 99.95%** OU passou checklist de 99.99%+ (ver Pattern: justificar 99.99%+ excepcional)
+3. **Tier-aware** — diferentes targets para `customer.tier` quando aplicável (enterprise/pro/free)
+4. **Budget policy documentada** — 4 estados (green/yellow/red/exhausted) com ações claras
+5. **Owner nomeado** — SLO sem dono = sem ação = sem valor
+6. **SLI customer-facing** — mede o que cliente sente, não estado interno
+7. **SLA externo > SLO interno** — margem entre compromisso comercial e meta interna
+
+## Ver também
+
+- [`_shared-sre/glossary.md`](../_shared-sre/glossary.md) — termos canônicos risk continuum, error budget, MTTR/MTBF
+- [`event-based-slos`](../event-based-slos/SKILL.md) (v1.9) — definir SLO event-based com sliding window
+- [`burn-rate-alerting`](../burn-rate-alerting/SKILL.md) (v1.9) — alertas predictive sobre error budget
+- [`production-readiness-review`](../production-readiness-review/SKILL.md) — PRR axis "Performance" usa risk continuum
+- [`blameless-postmortems`](../blameless-postmortems/SKILL.md) — postmortem documenta budget consumido
+
+---
+
+*Material-fonte: Site Reliability Engineering — Beyer, Jones, Petoff, Murphy (Google/O'Reilly, 2016) — Cap 3: "Embracing Risk".*

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@luanpdd/kit-mcp",
-  "version": "1.9.0",
+  "version": "1.11.0",
   "description": "Generic infrastructure to ship YOUR personal kit of agents/commands/skills as an MCP server, with cross-IDE sync (Claude Code, Cursor, Codex, Gemini, Windsurf, Antigravity, Copilot, Trae).",
   "type": "module",
   "bin": {
@@ -51,7 +51,7 @@
     "@inquirer/prompts": "^8.4.2",
     "@modelcontextprotocol/sdk": "^1.0.0",
     "chokidar": "^5.0.0",
-    "commander": "^12.1.0",
+    "commander": "^14.0.3",
     "open": "^11.0.0",
     "picocolors": "^1.1.1"
   }