@luanpdd/kit-mcp 1.7.0 → 1.9.0

package/kit/skills/distributed-tracing/SKILL.md

@@ -0,0 +1,362 @@
+---
+name: distributed-tracing
+description: Use ao instrumentar tracing — trace_id/span_id/parent_id, propagar W3C TraceContext via header traceparent, stitching além de RPCs (batch, lambda, queue).
+---
+
+# Observabilidade — Distributed Tracing
+
+## Quando usar
+
+LLM carrega esta skill ao instrumentar tracing distribuído ou stitching de spans. Trigger phrases:
+
+- "distributed tracing", "traces", "spans"
+- "propagar contexto entre serviços", "trace cross-service"
+- "W3C TraceContext", "traceparent header"
+- "trace_id span_id parent_span_id"
+- "ligar lambda batch job ao trace"
+- "stitching de eventos"
+
+## Regras absolutas
+
+- **trace_id é compartilhado** entre todos os spans de um único request distribuído. **NÃO** mude por hop.
+- **span_id é único por span** — gere novo a cada `startSpan()`. 16 hex chars (8 bytes).
+- **parent_span_id aponta para span pai** — null no root span. Define a árvore.
+- **W3C TraceContext é o padrão** — header HTTP `traceparent: 00-{trace_id}-{span_id}-{flags}`. Adote sempre. B3 é fallback para legacy.
+- **Propague ANTES de fazer call cross-service** — extrair contexto do request inbound, propagar no request outbound. Sem isso, trace quebra.
+- **Stitching ≠ apenas RPC** — também batch jobs, queue messages, lambda invocations, S3 uploads. Carregue `traceparent` em metadata da queue, env var do lambda, header da Step Function.
+- **Sample decision propaga** — bit `01` em flags de `traceparent` significa "sample=true". Decisão tomada no head propaga downstream.
+- **Não invente trace_id** — sempre derive do contexto inbound ou gere via SDK (não `crypto.randomUUID()`).
+- **Spans devem ter `kind`** — `SERVER` (handler de inbound), `CLIENT` (call outbound), `PRODUCER`/`CONSUMER` (queue), `INTERNAL` (subspan dentro do mesmo process).
+
+## Patterns canônicos
+
+### Pattern: extrair contexto inbound + propagar outbound (Node)
+
+```ts
+// PT-BR: handler HTTP — extrai traceparent do request inbound, propaga em call outbound
+import { trace, context, propagation } from '@opentelemetry/api'
+
+const tracer = trace.getTracer('orders-service')
+
+export async function placeOrder(req: Request) {
+  // PT-BR: 1 — extrair contexto inbound do header traceparent
+  const inboundContext = propagation.extract(context.active(), req.headers)
+
+  return tracer.startActiveSpan(
+    'place_order',
+    { kind: SpanKind.SERVER },
+    inboundContext,
+    async (span) => {
+      span.setAttribute('user.id', req.user.id)
+
+      // PT-BR: 2 — fazer call outbound — propagation injeta traceparent automaticamente
+      //         se você usar fetch/grpc instrumentados (ver skill opentelemetry-standard)
+      const outboundHeaders: Record<string, string> = {}
+      propagation.inject(context.active(), outboundHeaders)
+
+      const inventoryRes = await fetch('http://inventory/check', {
+        headers: outboundHeaders,  // PT-BR: traceparent injetado aqui
+        body: JSON.stringify({ items: req.items })
+      })
+
+      span.end()
+      return inventoryRes.json()
+    }
+  )
+}
+```
+
+### Pattern: traceparent format
+
+```text
+traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
+             ^  ^                                ^                 ^
+             |  |                                |                 |
+             version                             |                 flags (sampled bit)
+                trace_id (32 hex / 16 bytes)     |
+                                                 span_id (16 hex / 8 bytes)
+```
+
+```text
+flags:
+  01 = sampled    (decisão upstream: capture este trace)
+  00 = not sampled (decisão upstream: skip)
+```
+
+### Pattern: trace cross-service via Supabase Edge Function
+
+```ts
+// PT-BR: Edge Function recebe request → propaga para outro service
+import { trace, context, propagation } from 'npm:@opentelemetry/api@1.9.0'
+import { W3CTraceContextPropagator } from 'npm:@opentelemetry/core@1.27.0'
+
+propagation.setGlobalPropagator(new W3CTraceContextPropagator())
+
+const tracer = trace.getTracer('edge-orders')
+
+Deno.serve(async (req) => {
+  // PT-BR: extrair traceparent inbound
+  const inboundCtx = propagation.extract(context.active(), {
+    traceparent: req.headers.get('traceparent') ?? '',
+  })
+
+  return tracer.startActiveSpan(
+    'edge_handler',
+    { kind: 1 /* SERVER */ },
+    inboundCtx,
+    async (span) => {
+      span.setAttribute('endpoint', new URL(req.url).pathname)
+
+      // PT-BR: call outbound para Postgres via PostgREST — injeta traceparent
+      const outHeaders: Record<string, string> = {}
+      propagation.inject(context.active(), outHeaders)
+
+      const dbRes = await fetch(Deno.env.get('SUPABASE_URL') + '/rest/v1/orders', {
+        method: 'POST',
+        headers: {
+          ...outHeaders,
+          'apikey': Deno.env.get('SUPABASE_ANON_KEY')!,
+          'content-type': 'application/json',
+        },
+        body: await req.text(),
+      })
+
+      span.setAttribute('db.status_code', dbRes.status)
+      span.end()
+      return dbRes
+    }
+  )
+})
+```
+
+### Pattern: stitching além de RPC — queue message (não-RPC)
+
+```ts
+// PT-BR: producer — anexa traceparent ao payload da queue (pgmq, SQS, RabbitMQ)
+import { trace, context, propagation } from '@opentelemetry/api'
+
+const tracer = trace.getTracer('producer')
+
+export async function enqueueEmail(emailJob: EmailJob) {
+  return tracer.startActiveSpan(
+    'enqueue_email',
+    { kind: SpanKind.PRODUCER },
+    async (span) => {
+      span.setAttribute('queue.name', 'emails')
+      span.setAttribute('email.recipient', emailJob.to)
+
+      // PT-BR: serializar contexto no payload da mensagem
+      const carrier: Record<string, string> = {}
+      propagation.inject(context.active(), carrier)
+
+      await pgmqEnqueue('emails', {
+        ...emailJob,
+        _trace_context: carrier,  // PT-BR: viaja com o job
+      })
+
+      span.end()
+    }
+  )
+}
+
+// PT-BR: consumer — extrai traceparent do payload, continua o trace
+export async function processEmailJob(job: EmailJobWithContext) {
+  const inboundCtx = propagation.extract(
+    context.active(),
+    job._trace_context ?? {}  // PT-BR: se vazio, novo trace
+  )
+
+  return tracer.startActiveSpan(
+    'process_email',
+    { kind: SpanKind.CONSUMER },
+    inboundCtx,
+    async (span) => {
+      span.setAttribute('email.recipient', job.to)
+      // PT-BR: agora o span do worker faz parte do mesmo trace do producer
+      await sendEmail(job)
+      span.end()
+    }
+  )
+}
+```
+
+### Pattern: stitching de batch job (não-RPC)
+
+```ts
+// PT-BR: cron job processa N items — 1 span por item, todos com mesmo trace_id
+const tracer = trace.getTracer('billing-cron')
+
+export async function dailyBillingJob() {
+  return tracer.startActiveSpan('daily_billing', async (rootSpan) => {
+    rootSpan.setAttribute('job.type', 'cron')
+    rootSpan.setAttribute('build_id', BUILD_ID)
+
+    const customers = await db.getCustomersDueForBilling()
+    rootSpan.setAttribute('customers.count', customers.length)
+
+    // PT-BR: cada customer vira span filho com mesmo trace_id
+    for (const customer of customers) {
+      await tracer.startActiveSpan(
+        'bill_customer',
+        { kind: SpanKind.INTERNAL },
+        async (span) => {
+          span.setAttribute('customer.id', customer.id)
+          span.setAttribute('customer.tier', customer.tier)
+          try {
+            await chargeCustomer(customer)
+            span.setAttribute('result.success', true)
+          } catch (e) {
+            span.setAttribute('result.success', false)
+            span.setAttribute('error.type', classify(e))
+          } finally {
+            span.end()
+          }
+        }
+      )
+    }
+
+    rootSpan.end()
+  })
+}
+```
+
+### Pattern: span kinds
+
+| Kind | Quando usar | Exemplo |
+|---|---|---|
+| `SERVER` | Recebendo request inbound | Handler HTTP, gRPC server method |
+| `CLIENT` | Fazendo call outbound | `fetch()`, gRPC client call, DB query |
+| `PRODUCER` | Enviando msg para queue | `pgmq.enqueue()`, SQS publish |
+| `CONSUMER` | Processando msg de queue | Worker recebendo job |
+| `INTERNAL` | Subdivisão dentro do mesmo process | "json_parse", "validation_step" |
+
+### Pattern: query traces — montar waterfall
+
+```sql
+-- PT-BR: pegar todos os spans de um trace em ordem cronológica
+select
+  span_id,
+  parent_span_id,
+  span_name,
+  span_kind,
+  service_name,
+  duration_ms,
+  start_time
+from observability.spans
+where trace_id = '4bf92f3577b34da6a3ce929d0e0e4736'
+order by start_time asc;
+
+-- PT-BR: encontrar root span — parent_span_id IS NULL ou span sem parent no mesmo trace
+select * 
+from observability.spans
+where trace_id = '4bf92f3577b34da6a3ce929d0e0e4736'
+  and parent_span_id is null;
+
+-- PT-BR: spans mais lentos cross-trace, último 1h
+select 
+  service_name, 
+  span_name,
+  percentile_cont(0.99) within group (order by duration_ms) as p99,
+  count(*) as samples
+from observability.spans
+where start_time > now() - interval '1 hour'
+group by service_name, span_name
+having count(*) > 100
+order by p99 desc
+limit 20;
+```
+
+## Anti-patterns
+
+### ANTI: gerar trace_id por hop
+
+```ts
+// PT-BR: BAD — quebra a cadeia, cada service vê trace diferente
+const traceId = crypto.randomUUID().replace(/-/g, '').slice(0, 32)
+
+// PT-BR: GOOD — extrair do header inbound; deixar SDK gerar root
+const inboundCtx = propagation.extract(context.active(), req.headers)
+tracer.startActiveSpan('handler', {}, inboundCtx, ...)
+```
+
+### ANTI: esquecer de propagar em call outbound
+
+```ts
+// PT-BR: BAD — outbound call sem traceparent — trace quebra no service B
+await fetch('http://service-b/api', { body: ... })
+
+// PT-BR: GOOD — injetar traceparent
+const headers: Record<string, string> = {}
+propagation.inject(context.active(), headers)
+await fetch('http://service-b/api', { headers, body: ... })
+```
+
+### ANTI: trace só de RPCs, não de batch/queue
+
+```ts
+// PT-BR: BAD — producer/consumer não compartilham trace, debug fica fragmentado
+await pgmqEnqueue('emails', payload)  // sem trace context
+// ... depois worker processa sem saber que veio do request X
+
+// PT-BR: GOOD — propagar contexto via metadata da queue
+const carrier = {}
+propagation.inject(context.active(), carrier)
+await pgmqEnqueue('emails', { ...payload, _trace_context: carrier })
+```
+
+### ANTI: span sem `end()`
+
+```ts
+// PT-BR: BAD — span fica aberto forever, duration_ms não calculado, memory leak
+const span = tracer.startSpan('handler')
+// ... handler logic
+return result  // PT-BR: ESQUECEU span.end()
+
+// PT-BR: GOOD — sempre `try/finally`
+const span = tracer.startSpan('handler')
+try {
+  // ... logic
+} finally {
+  span.end()
+}
+```
+
+### ANTI: span hierarchy errada
+
+```ts
+// PT-BR: BAD — usar startSpan sem startActiveSpan, parent não é settado automático
+const parent = tracer.startSpan('parent')
+const child = tracer.startSpan('child')  // PT-BR: parent_span_id ficou null
+parent.end()
+child.end()
+
+// PT-BR: GOOD — startActiveSpan empurra contexto, child herda parent
+tracer.startActiveSpan('parent', (parent) => {
+  tracer.startActiveSpan('child', (child) => {
+    // PT-BR: child.parent_span_id === parent.span_id
+    child.end()
+  })
+  parent.end()
+})
+```
+
+## Verificação
+
+1. **1 trace_id por request** — enviar 1 request, queryar `SELECT DISTINCT trace_id FROM spans WHERE request_id = X` → 1 resultado.
+2. **Cross-service stitching** — request HTTP service A → service B → DB. Queryar `SELECT count(distinct service_name) FROM spans WHERE trace_id = X` → ≥ 3.
+3. **Root span identificável** — `SELECT * FROM spans WHERE trace_id = X AND parent_span_id IS NULL` → 1 row (o root).
+4. **Span hierarchy correta** — graficar via tool (Jaeger UI, Honeycomb, etc.) ou recursivo SQL — deve formar árvore válida (sem ciclos).
+5. **Duration não-zero** — `SELECT min(duration_ms), max(duration_ms) FROM spans` — min ≥ 0, max razoável.
+6. **Sampled flag respeitado** — verificar que se traceparent inbound = `01`, downstream também sample=true.
+7. **Queue stitching funciona** — enqueue + consume → mesmo `trace_id` em ambos os spans.
+
+---
+
+## Ver também
+
+- `kit/skills/_shared-observability/glossary.md` — W3C TraceContext, B3, span kinds
+- `kit/skills/structured-events/SKILL.md` — atributos canônicos por span
+- `kit/skills/opentelemetry-standard/SKILL.md` — SDK que faz extract/inject
+- `kit/skills/telemetry-sampling/SKILL.md` *(Phase 34)* — head vs tail sampling decisão
+
+*Material-fonte: Observability Engineering (O'Reilly, 2022) — Cap 6: "Stitching Events into Traces".*

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

@@ -0,0 +1,274 @@
+---
+name: event-based-slos
+description: Use ao definir SLO — SLI event-based (não time-based), sliding window 30d, decouple what/why. SLO-based alerts substituem thresholds brutos como CPU/memória.
+---
+
+# Observabilidade — Event-Based SLOs
+
+## Quando usar
+
+LLM carrega esta skill ao definir/avaliar SLOs ou substituir alertas threshold por SLO-based. Trigger phrases:
+
+- "definir SLO", "criar SLI"
+- "alertas confiáveis", "alert fatigue"
+- "error budget", "sliding window"
+- "como medir saúde do serviço"
+- "decouple what from why"
+
+## Regras absolutas
+
+- **SLI sempre event-based, nunca time-based** — "% de eventos com `result.success=true` em 30d" > "% de janelas de 5min com p99 < 300ms"
+- **Sliding window 30d por default** — fixed window (calendário) gera comportamento perverso (cliente não esquece bug por causa de reset).
+- **Target ≤ 99.95%** — para SLO 99.99%+ você não tem tempo de reagir antes do budget acabar; use métricas/dashboards informativos em vez de SLO.
+- **Decouple "what" do "why"** — SLO alert diz que tem dor (sintoma); investigation descobre porquê (use [`core-analysis-loop`](../skills/core-analysis-loop/SKILL.md)). NUNCA misturar (anti-pattern: "alert se memória > 80% AND p99 > 300ms").
+- **Customer-facing journey, não system metric** — SLI mede o que o cliente sente ("login funcionou em < 800ms"), não estado interno ("threads ativas").
+- **Granular por endpoint/feature** — 1 SLO por jornada crítica do user. Não SLO global "site availability" — específico demais para ser ignorável.
+- **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.
+
+## Patterns canônicos
+
+### Pattern: SLI event-based vs time-based
+
+```sql
+-- PT-BR: BAD — SLI time-based (anti-pattern)
+-- "99% das janelas de 5 min têm p99 < 300ms"
+-- Problema: pre-aggregation perde fidelidade; janela com 1 outlier puxa p99.
+
+-- PT-BR: GOOD — SLI event-based
+-- "99.9% dos eventos individuais têm duration < 300ms e result_success = true"
+select 
+  count(*) filter (where duration_ms < 300 and result_success = true) as good,
+  count(*) as total,
+  count(*) filter (where duration_ms < 300 and result_success = true)::float / count(*) as compliance
+from observability.events
+where 
+  event_name = 'http_request' 
+  and endpoint = '/api/v1/orders'
+  and timestamp > now() - interval '30 days';
+```
+
+### Pattern: SLO definition canônico
+
+```yaml
+# PT-BR: SLO documentado em formato YAML — alimenta agent slo-engineer
+slo:
+  name: checkout_success
+  description: "Checkout completes successfully within 800ms (customer perception)"
+  owner: orders-team@company.com   # PT-BR: dono nomeado
+  
+  sli:
+    type: event_based              # PT-BR: NUNCA time-based
+    event_filter:
+      service: orders-api
+      endpoint: /api/v1/checkout
+      http_method: POST
+    good_event:                    # PT-BR: predicate booleano
+      result_success: true
+      duration_ms: { lt: 800 }
+    bad_event:                     # PT-BR: complemento
+      operator: not_good           # qualquer evento que não é "good"
+  
+  target: 0.999                    # PT-BR: 99.9% — não 99.99%+ por design
+  window: 30d_sliding              # PT-BR: nunca fixed/calendar
+  
+  alerts:                          # PT-BR: ver skill burn-rate-alerting
+    - name: page_short_term
+      lookahead: 4h
+      baseline: 1h
+      severity: page
+    - name: ticket_long_term
+      lookahead: 3d
+      baseline: 18h
+      severity: ticket
+```
+
+### Pattern: SLI materialized view (Postgres)
+
+```sql
+-- PT-BR: view materializa SLI events para queries baratas
+-- Refresh agendado (pg_cron) ou em tempo real (trigger)
+create materialized view obs.sli_checkout_success as
+select
+  date_trunc('minute', timestamp) as bucket,
+  count(*) filter (where result_success = true and duration_ms < 800) as good,
+  count(*) filter (where not (result_success = true and duration_ms < 800)) as bad,
+  count(*) as total
+from observability.events
+where 
+  service = 'orders-api'
+  and endpoint = '/api/v1/checkout'
+  and http_method = 'POST'
+  and timestamp > now() - interval '35 days'  -- 30d + buffer
+group by 1
+with no data;
+
+-- PT-BR: índice para queries de burn rate
+create index on obs.sli_checkout_success (bucket);
+
+-- PT-BR: refresh schedule via pg_cron — a cada 30s
+select cron.schedule(
+  'refresh_sli_checkout_success',
+  '*/30 * * * * *',
+  $$ refresh materialized view concurrently obs.sli_checkout_success $$
+);
+```
+
+### Pattern: SLO compliance query (atual e histórico)
+
+```sql
+-- PT-BR: compliance atual — % good no último 30d
+select 
+  sum(good)::float / nullif(sum(total), 0) as compliance_30d,
+  0.999 as target,
+  case 
+    when sum(good)::float / nullif(sum(total), 0) >= 0.999 then 'IN_BUDGET'
+    else 'OUT_OF_BUDGET'
+  end as status
+from obs.sli_checkout_success
+where bucket > now() - interval '30 days';
+
+-- PT-BR: error budget remaining
+-- Budget = (1 - target) × total_events
+-- Remaining = budget - bad_events_so_far
+select
+  (1 - 0.999) * sum(total) as budget,
+  sum(bad) as burned,
+  (1 - 0.999) * sum(total) - sum(bad) as remaining,
+  100.0 * (1 - sum(bad) / nullif((1 - 0.999) * sum(total), 0)) as remaining_pct
+from obs.sli_checkout_success
+where bucket > now() - interval '30 days';
+```
+
+### Pattern: SLO replacing thresholds (case study Honeycomb)
+
+```text
+ANTES (cap 12 do livro):
+  - Alert: CPU > 80% (false positive: garbage collector)
+  - Alert: memory > 90% (false positive: cache warming)
+  - Alert: 5xx > 1% in 5min (false negative: 0.5% por 1h burns 60% do budget)
+  - Alert: p99 latency > 500ms in 5min (false positive: 1 spike isolado)
+
+DEPOIS:
+  - 1 SLO: checkout_success em 30d sliding
+  - 1 alert preditivo: burn rate sustained 4h+
+  - 1 alert ticket: burn rate sustained 3d+
+  
+RESULTADO: 60% menos paginations, 100% dos incidents reais detectados.
+```
+
+### Pattern: customer-facing SLI dimensions
+
+| Dimensão | Valor | Por quê SLI deve incluir |
+|---|---|---|
+| `endpoint` | `/api/v1/checkout` | Granular — não SLO global |
+| `customer.tier` | `'enterprise'` | Diferentes targets por tier (Pro = 99.95% vs Free = 99.5%) |
+| `region` | `us-east-1` | Identificar problema regional vs global |
+| `feature_flag.<name>` | `true`/`false` | SLO durante rollout incremental |
+| `tenant_id` | `'acme'` | Big customers podem ter SLOs próprios |
+
+## Anti-patterns
+
+### ANTI: SLO 99.99% ou 99.999%
+
+```text
+ANTI: target 99.99% em SLO de 30d sliding
+  - 30d × 24h × 60min × (1-0.9999) = 4.3 minutos de tolerância
+  - Sem tempo para reagir antes do budget esgotar
+  - Burn rate alerts disparam após o budget acabar (zero-level)
+
+CERTO: target ≤ 99.95% para SLO real
+       Para 99.99%+, use métricas/dashboards informativos (não alerta)
+```
+
+### ANTI: SLO global "site up"
+
+```text
+ANTI: 1 SLO "site availability" para tudo
+  - Falha em /api/v1/admin não conta para 99% dos clientes
+  - Falha em /api/v1/checkout = catastrófico
+  - Misturar = alarmes confusos, ações vagas
+
+CERTO: 1 SLO por jornada crítica do user
+  - checkout_success: 99.9%
+  - login_success: 99.95%
+  - search_p95_latency: 99% < 200ms
+  - admin_panel: SEM SLO (uso baixo, latência aceitável)
+```
+
+### ANTI: SLO sem owner
+
+```text
+ANTI: SLO definido em retrospectiva, sem dono nomeado
+  - Burn alert dispara → ninguém atende → escalation
+  - Sem follow-up no fim do mês
+
+CERTO: SLO tem owner em arquivo (yaml ou tabela DB)
+       owner = team email ou pessoa específica
+       Burn alert roteia direto para owner antes de escalation
+```
+
+### ANTI: SLO == SLA externo
+
+```text
+ANTI: usar SLA do contrato (99.9% uptime) como SLO interno
+
+PROBLEMA: 0 margem de segurança. Atinge SLA mínimo no fio = 1 incident e quebra.
+
+CERTO: SLO interno mais rígido que SLA externo
+       SLA externo: 99.9% (compromisso com cliente)
+       SLO interno: 99.95% (margem de 5× para reagir)
+```
+
+### ANTI: alterar SLI quando burn ocorre
+
+```text
+ANTI: SLO está queimando → "vamos relaxar SLI para reduzir false positives"
+       (definir bad_event mais frouxo)
+
+PROBLEMA: você está mascarando dor real. Próximo incident similar passa silencioso.
+
+CERTO: SLI é compromisso com customer experience. Se está queimando, fixar
+       o problema (root cause via core-analysis-loop), não o SLI.
+       Se SLI sistematicamente errado (mede coisa errada): substituir, não relaxar.
+```
+
+### ANTI: fixed window (mensal/calendário)
+
+```text
+ANTI: error budget reseta dia 1 do mês
+
+PROBLEMA: 
+  - "Tivemos outage dia 31, reseta amanhã" — cliente NÃO esquece
+  - Pressão para postergar fixes para "depois do reset"
+  - Behavioral hazard: deploy arriscado dia 30
+
+CERTO: sliding window 30d
+       Outage dia 31 fica no budget até dia 30 do mês seguinte (sai gradualmente)
+       Sem incentivo perverso, comportamento humano realista
+```
+
+## Verificação
+
+Antes de marcar SLO como produção-pronto:
+
+1. **Owner nomeado** — email/team em `slo.owner`
+2. **SLI event-based** — pred boolean, não time-bucket
+3. **Target ≤ 99.95%** — > 99.95% sinaliza informativo, não SLO
+4. **Window 30d sliding** — não fixed
+5. **Customer-facing journey** — SLI mede o que o cliente sente
+6. **Materialized view** existe e é refreshable (pg_cron)
+7. **Burn alerts** configurados (ver skill `burn-rate-alerting`)
+8. **Quero SLO ou metric?** — se a resposta é "informativo", crie metric, não SLO
+
+---
+
+## Ver também
+
+- `kit/skills/_shared-observability/glossary.md` — termos canônicos SLI/SLO/error budget
+- `kit/skills/structured-events/SKILL.md` — eventos canônicos para alimentar SLI
+- `kit/skills/burn-rate-alerting/SKILL.md` — lookahead/baseline windows
+- `kit/skills/core-analysis-loop/SKILL.md` — investigar quando SLO queima
+- `kit/agents/slo-engineer.md` — gera SLO.md + SQL para materializar SLI
+
+*Material-fonte: Observability Engineering (O'Reilly, 2022) — Cap 12: "Using Service-Level Objectives for Reliability".*